On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo <jh...@codeaurora.org> wrote: > On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> >>>> -----Original Message----- >>>> From: Sinan Kaya [mailto:ok...@codeaurora.org] >>>> Sent: 13 June 2016 15:03 >>>> To: Gabriele Paoloni; liudongdong (C); helg...@kernel.org; >>>> a...@arndb.de; will.dea...@arm.com; catalin.mari...@arm.com; >>>> raf...@kernel.org; hanjun....@linaro.org; lorenzo.pieral...@arm.com; >>>> jchan...@broadcom.com; t...@semihalf.com >>>> Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com; >>>> liviu.du...@arm.com; dda...@caviumnetworks.com; Wangyijing; >>>> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux- >>>> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- >>>> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro- >>>> a...@lists.linaro.org; j...@redhat.com; andrea.ga...@linaro.org; >>>> dhd...@apm.com; jeremy.lin...@arm.com; c...@codeaurora.org; Chenxin >>>> (Charles); Linuxarm >>>> Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space >>>> accessors against platfrom specific ECAM quirks >>>> >>>> On 6/13/2016 9:54 AM, Gabriele Paoloni wrote: >>>> > 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?) >>>> > >>>> > 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. >>>> > >>>> > Can these vendors confirm this? >>>> > >>>> > Tomasz do you think this can work for Cavium Thunder? >>>> > >>>> > Thanks >>>> > >>>> > Gab >>>> >>>> Why not have all three of them? >>>> >>>> The initial approach was OEM id and revision id. >>>> >>>> Jeff Hugo indicated that addition (not removing any other fields) of >>>> table id >>>> would make more sense. >>> >>> >>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match >>> PCI config space accessors against platfrom specific ECAM quirks." >>> >>> I quote: >>> >>> "Using the OEM revision >>> field does not seem to be appropriate since these are different >>> platforms and the revision field appears to be for the purpose of >>> tracking differences within a single platform. Therefore, Cov is >>> proposing using the OEM table id as a mechanism to distinguish >>> platform A (needs quirk applied) vs platform B (no quirks) from the >>> same OEM." >>> >>> So it looks to me that he pointed out that using the OEM revision field >>> is wrong...and this is why I have asked if replacing it with the table >>> id can work for other vendors.... >>> >>> Thanks >>> >>> Gab >>> >> >> I had an internal discussion with jeff and cov before posting on the >> maillist. >> >> I think there is missing info in the email. >> >> Usage of oem id + table id + revision is ok. >> >> Usage of oem id + revision is not ok as one oem can build multiple chips >> with the same oem id and revision id but different table id. Otherwise, >> we can run out of revisions very quickly. > > > Agreed. > > I'm sorry for the confusion. My intent was to point out that revision alone > appeared insufficient to address all the identified problems, but I believe > there is still a case for using revision. Table id is useful for > differentiating between platforms/chips. Revision is useful for > differentiation between different versions of a single platform/chip > assuming the silicon is respun or some other fix is applied. Both solve > different scenarios, and I'm not aware of a reason why they could not be > used together to solve all currently identified cases.
Using OEM ID + Table ID + Revision will work for X-Gene platforms as well. Regards, Duc Dang. > >> >>> >>>> >>>> -- >>>> Sinan Kaya >>>> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, >>>> Inc. >>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >>>> Linux Foundation Collaborative Project >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > -- > Jeffrey Hugo > Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux > Foundation Collaborative Project