On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote: > On 6/13/2016 9:12 AM, okaya@xxxxxxxxxxxxxx wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> >>>> -----Original Message----- >>>> From: Sinan Kaya [mailto:okaya@xxxxxxxxxxxxxx] >>>> Sent: 13 June 2016 15:03 >>>> To: Gabriele Paoloni; liudongdong (C); helgaas@xxxxxxxxxx; >>>> arnd@xxxxxxxx; will.deacon@xxxxxxx; catalin.marinas@xxxxxxx; >>>> rafael@xxxxxxxxxx; hanjun.guo@xxxxxxxxxx; Lorenzo.Pieralisi@xxxxxxx; >>>> jchandra@xxxxxxxxxxxx; tn@xxxxxxxxxxxx >>>> Cc: robert.richter@xxxxxxxxxxxxxxxxxx; mw@xxxxxxxxxxxx; >>>> Liviu.Dudau@xxxxxxx; ddaney@xxxxxxxxxxxxxxxxxx; Wangyijing; >>>> Suravee.Suthikulpanit@xxxxxxx; msalter@xxxxxxxxxx; linux- >>>> pci@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux- >>>> acpi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linaro- >>>> acpi@xxxxxxxxxxxxxxxx; jcm@xxxxxxxxxx; andrea.gallo@xxxxxxxxxx; >>>> dhdang@xxxxxxx; jeremy.linton@xxxxxxx; cov@xxxxxxxxxxxxxx; 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-kernel@xxxxxxxxxxxxxxxxxxx >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
