Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang <dhdang@apm.com>]

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters <jcm@redhat.com> wrote:
> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>> Hi Tomasz, Jon
>
> Hi Gab,
>
> Sorry for the lag in following up.
>
> <snip>
>
>> As you can see here Liudongdong has replaced oem_revision with
>> oem_table_id.
>>
>> Now it seems that there are some platforms that have already shipped
>> using a matching based on the oem_revision (right Jon?)
>
> Actually, it turns out (Cov is correct) that we can just match on OEM
> Table ID. The revision should not generally be needed and the vendors
> will just need to make sure that they change OEM Table ID in future
> silicon. An example from two shipping platforms:
>
> 1). AppliedMicro Mustang:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 4A
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000002
> [01Ch 0028   4]              Asl Compiler ID : "INTL"
> [020h 0032   4]        Asl Compiler Revision : 20140724
>
> 2). HP(E[0]) Moonshot:
>
> [000h 0000   4]                    Signature : "MCFG"    [Memory Mapped
> Configuration table]
> [004h 0004   4]                 Table Length : 0000003C
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : 48
> [00Ah 0010   6]                       Oem ID : "APM   "
> [010h 0016   8]                 Oem Table ID : "XGENE   "
> [018h 0024   4]                 Oem Revision : 00000001
> [01Ch 0028   4]              Asl Compiler ID : "HP  "
> [020h 0032   4]        Asl Compiler Revision : 00000001
>
> I have pinged the semiconductor (Applied) and insisted upon a written
> plan (which I have now) for handling the first affect generation(s) and
> future chip roadmap stuff, along with how they plan to upstream this
> immediately as part of this thread. I have also done similar with each
> of the other vendors (this is something ARM or Linaro should be doing).
> But I particularly care about X-Gene because I want it to be loved as
> shipping silicon in production systems (Moonshot) that are sitting and
> waiting in the Fedora Phoenix datacenter in large quantity to come
> online if only an upstream kernel would actually boot on them :)

Thanks for the MCFG information on Moonshot system, Jon.

I will make sure the posted quirk for X-Gene takes care for HPE
Moonshot system as well.

Regards,
Duc Dang.

>
>> However I guess that if in FW they have defined oem_table_id properly
>> they should be able to use this mechanism without needing to a FW update.
>
> Correct.
>
>> Can these vendors confirm this?
>
> I've checked all current shipping silicon and prototypes.
>
>> Tomasz do you think this can work for Cavium Thunder?
>
> Will let the vendors followup directly as well.
>
> Jon.
>
> [0] Fortunately that name change doesn't factor when using semiconductor
> matching...hopefully none of the non-complaint IP companies in gen1
> stuff get bought and change their table names. In the unlikely event
> that that does happen, I will preemptively beat them up and ensure that
> something crazy doesn't happen with table contents.
>
> --
> Computer Architect | Sent from my Fedora powered laptop