From mboxrd@z Thu Jan 1 00:00:00 1970 From: Duc Dang Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks Date: Mon, 13 Jun 2016 14:07:23 -0700 Message-ID: References: <1465822923-33599-1-git-send-email-liudongdong3@huawei.com> <1465822923-33599-2-git-send-email-liudongdong3@huawei.com> <575EBD13.8080808@codeaurora.org> <036882b9-b781-cb56-2bcf-35afb21b2812@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <036882b9-b781-cb56-2bcf-35afb21b2812@codeaurora.org> Sender: linux-pci-owner@vger.kernel.org To: Jeffrey Hugo Cc: okaya@codeaurora.org, Gabriele Paoloni , Rafael Wysocki , linux-pci@vger.kernel.org, Will Deacon , Linuxarm , "Chenxin (Charles)" , Wangyijing , Andrea Gallo , Lorenzo Pieralisi , Tomasz Nowicki , linaro-acpi@lists.linaro.org, David Daney , linux-acpi@vger.kernel.org, robert.richter@caviumnetworks.com, Bjorn Helgaas , "liudongdong (C)" , Catalin Marinas , Jon Masters , Arnd Bergmann , Liviu Dudau , Mark Salter , Christopher Covington , Marcin Wojtas linu List-Id: linux-acpi@vger.kernel.org On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo wrote: > On 6/13/2016 9:12 AM, okaya@codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> >>>> -----Original Message----- >>>> From: Sinan Kaya [mailto:okaya@codeaurora.org] >>>> Sent: 13 June 2016 15:03 >>>> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org; >>>> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com; >>>> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; >>>> jchandra@broadcom.com; tn@semihalf.com >>>> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com; >>>> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing; >>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux- >>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux- >>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro- >>>> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org; >>>> dhdang@apm.com; jeremy.linton@arm.com; cov@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-kernel@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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423467AbcFMVH4 (ORCPT ); Mon, 13 Jun 2016 17:07:56 -0400 Received: from mail-vk0-f41.google.com ([209.85.213.41]:33209 "EHLO mail-vk0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161278AbcFMVHy (ORCPT ); Mon, 13 Jun 2016 17:07:54 -0400 MIME-Version: 1.0 In-Reply-To: <036882b9-b781-cb56-2bcf-35afb21b2812@codeaurora.org> References: <1465822923-33599-1-git-send-email-liudongdong3@huawei.com> <1465822923-33599-2-git-send-email-liudongdong3@huawei.com> <575EBD13.8080808@codeaurora.org> <036882b9-b781-cb56-2bcf-35afb21b2812@codeaurora.org> From: Duc Dang Date: Mon, 13 Jun 2016 14:07:23 -0700 Message-ID: Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks To: Jeffrey Hugo Cc: okaya@codeaurora.org, Gabriele Paoloni , Rafael Wysocki , linux-pci@vger.kernel.org, Will Deacon , Linuxarm , "Chenxin (Charles)" , Wangyijing , Andrea Gallo , Lorenzo Pieralisi , Tomasz Nowicki , linaro-acpi@lists.linaro.org, David Daney , linux-acpi@vger.kernel.org, robert.richter@caviumnetworks.com, Bjorn Helgaas , "liudongdong (C)" , Catalin Marinas , Jon Masters , Arnd Bergmann , Liviu Dudau , Mark Salter , Christopher Covington , Marcin Wojtas , linux-arm , Jayachandran C , Linux Kernel Mailing List , jeremy.linton@arm.com, Hanjun Guo , Suravee Suthikulpanit Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo wrote: > On 6/13/2016 9:12 AM, okaya@codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> >>>> -----Original Message----- >>>> From: Sinan Kaya [mailto:okaya@codeaurora.org] >>>> Sent: 13 June 2016 15:03 >>>> To: Gabriele Paoloni; liudongdong (C); helgaas@kernel.org; >>>> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com; >>>> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; >>>> jchandra@broadcom.com; tn@semihalf.com >>>> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com; >>>> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing; >>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux- >>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux- >>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro- >>>> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org; >>>> dhdang@apm.com; jeremy.linton@arm.com; cov@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-kernel@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: dhdang@apm.com (Duc Dang) Date: Tue, 05 Jul 2016 04:36:18 -0000 Subject: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks In-Reply-To: <036882b9-b781-cb56-2bcf-35afb21b2812@codeaurora.org> References: <1465822923-33599-1-git-send-email-liudongdong3@huawei.com> <1465822923-33599-2-git-send-email-liudongdong3@huawei.com> <575EBD13.8080808@codeaurora.org> <036882b9-b781-cb56-2bcf-35afb21b2812@codeaurora.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo wrote: > On 6/13/2016 9:12 AM, okaya at codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> >>>> -----Original Message----- >>>> From: Sinan Kaya [mailto:okaya at codeaurora.org] >>>> Sent: 13 June 2016 15:03 >>>> To: Gabriele Paoloni; liudongdong (C); helgaas at kernel.org; >>>> arnd at arndb.de; will.deacon at arm.com; catalin.marinas at arm.com; >>>> rafael at kernel.org; hanjun.guo at linaro.org; Lorenzo.Pieralisi at arm.com; >>>> jchandra at broadcom.com; tn at semihalf.com >>>> Cc: robert.richter at caviumnetworks.com; mw at semihalf.com; >>>> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing; >>>> Suravee.Suthikulpanit at amd.com; msalter at redhat.com; linux- >>>> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux- >>>> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linaro- >>>> acpi at lists.linaro.org; jcm at redhat.com; andrea.gallo at linaro.org; >>>> dhdang at apm.com; jeremy.linton at arm.com; cov at 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-kernel at 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