From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks. Date: Fri, 03 Jun 2016 09:57:40 -0700 Message-ID: <5751B704.7010208@gmail.com> References: <1464856864-18049-1-git-send-email-tn@semihalf.com> <1464856864-18049-2-git-send-email-tn@semihalf.com> <57519F09.2010201@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Gabriele Paoloni Cc: "rafael@kernel.org" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "okaya@codeaurora.org" , Wangyijing , "andrea.gallo@linaro.org" , "Lorenzo.Pieralisi@arm.com" , Tomasz Nowicki , "linaro-acpi@lists.linaro.org" , "ddaney@caviumnetworks.com" , "linux-acpi@vger.kernel.org" , "robert.richter@caviumnetworks.com" , "helgaas@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "liudongdong (C)" , "msalter@redhat.com" , "arnd@arndb.de" , Liviu.Dudau@arm. List-Id: linux-acpi@vger.kernel.org On 06/03/2016 08:32 AM, Gabriele Paoloni wrote: [...] >>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root) >>> +{ >>> + int bus_num = root->secondary.start; >>> + int domain = root->segment; >>> + struct pci_cfg_fixup *f; >>> + >>> + if (!mcfg_table) >>> + return &pci_generic_ecam_ops; >>> + >>> + /* >>> + * Match against platform specific quirks and return >> corresponding >>> + * CAM ops. >>> + * >>> + * First match against PCI topology then use OEM ID >> and >>> + * OEM revision from MCFG table standard header. >>> + */ >>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; >> f++) { >>> + if ((f->domain == domain || f->domain == >> PCI_MCFG_DOMAIN_ANY) && >>> + (f->bus_num == bus_num || f->bus_num == >> PCI_MCFG_BUS_ANY) && >>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id, >>> + ACPI_OEM_ID_SIZE)) && >>> + (f->oem_revision == mcfg_table->header.oem_revision)) >> >> Is this more likely to be updated between quirky and fixed platforms >> than oem_table_id? What do folks think about using oem_table_id instead >> of, or in addition to, oem_revision? > > From my understanding we need to stick to this mechanism as (otherwise) > there are platforms out in the field that would need a FW update. > > So I don't think that using oem_table_id "instead" is possible; about > "in addition" I think it is doable, but I do not see the advantage much. > I mean that if a platform gets fixed the oem revision should change too, > Right? I think you are correct. My take away on discussions about using this style of quirk matching was that we would require the oem_revision to change as different quirks (or lack of quirks) were required. David Daney > > Thanks > > Gab > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932888AbcFCQ5t (ORCPT ); Fri, 3 Jun 2016 12:57:49 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:34215 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932882AbcFCQ5o (ORCPT ); Fri, 3 Jun 2016 12:57:44 -0400 Message-ID: <5751B704.7010208@gmail.com> Date: Fri, 03 Jun 2016 09:57:40 -0700 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Gabriele Paoloni CC: Christopher Covington , Tomasz Nowicki , "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" , "okaya@codeaurora.org" , "jchandra@broadcom.com" , "liudongdong (C)" , "linaro-acpi@lists.linaro.org" , "jcm@redhat.com" , "dhdang@apm.com" , "Liviu.Dudau@arm.com" , "ddaney@caviumnetworks.com" , "jeremy.linton@arm.com" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "robert.richter@caviumnetworks.com" , "msalter@redhat.com" , "Suravee.Suthikulpanit@amd.com" , "linux-pci@vger.kernel.org" , Wangyijing , "mw@semihalf.com" , "andrea.gallo@linaro.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks. References: <1464856864-18049-1-git-send-email-tn@semihalf.com> <1464856864-18049-2-git-send-email-tn@semihalf.com> <57519F09.2010201@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/03/2016 08:32 AM, Gabriele Paoloni wrote: [...] >>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root) >>> +{ >>> + int bus_num = root->secondary.start; >>> + int domain = root->segment; >>> + struct pci_cfg_fixup *f; >>> + >>> + if (!mcfg_table) >>> + return &pci_generic_ecam_ops; >>> + >>> + /* >>> + * Match against platform specific quirks and return >> corresponding >>> + * CAM ops. >>> + * >>> + * First match against PCI topology then use OEM ID >> and >>> + * OEM revision from MCFG table standard header. >>> + */ >>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; >> f++) { >>> + if ((f->domain == domain || f->domain == >> PCI_MCFG_DOMAIN_ANY) && >>> + (f->bus_num == bus_num || f->bus_num == >> PCI_MCFG_BUS_ANY) && >>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id, >>> + ACPI_OEM_ID_SIZE)) && >>> + (f->oem_revision == mcfg_table->header.oem_revision)) >> >> Is this more likely to be updated between quirky and fixed platforms >> than oem_table_id? What do folks think about using oem_table_id instead >> of, or in addition to, oem_revision? > > From my understanding we need to stick to this mechanism as (otherwise) > there are platforms out in the field that would need a FW update. > > So I don't think that using oem_table_id "instead" is possible; about > "in addition" I think it is doable, but I do not see the advantage much. > I mean that if a platform gets fixed the oem revision should change too, > Right? I think you are correct. My take away on discussions about using this style of quirk matching was that we would require the oem_revision to change as different quirks (or lack of quirks) were required. David Daney > > Thanks > > Gab > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Message-ID: <5751B704.7010208@gmail.com> Date: Fri, 03 Jun 2016 09:57:40 -0700 From: David Daney MIME-Version: 1.0 To: Gabriele Paoloni CC: Christopher Covington , Tomasz Nowicki , "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" , "okaya@codeaurora.org" , "jchandra@broadcom.com" , "liudongdong (C)" , "linaro-acpi@lists.linaro.org" , "jcm@redhat.com" , "dhdang@apm.com" , "Liviu.Dudau@arm.com" , "ddaney@caviumnetworks.com" , "jeremy.linton@arm.com" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "robert.richter@caviumnetworks.com" , "msalter@redhat.com" , "Suravee.Suthikulpanit@amd.com" , "linux-pci@vger.kernel.org" , Wangyijing , "mw@semihalf.com" , "andrea.gallo@linaro.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks. References: <1464856864-18049-1-git-send-email-tn@semihalf.com> <1464856864-18049-2-git-send-email-tn@semihalf.com> <57519F09.2010201@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-ID: On 06/03/2016 08:32 AM, Gabriele Paoloni wrote: [...] >>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root) >>> +{ >>> + int bus_num = root->secondary.start; >>> + int domain = root->segment; >>> + struct pci_cfg_fixup *f; >>> + >>> + if (!mcfg_table) >>> + return &pci_generic_ecam_ops; >>> + >>> + /* >>> + * Match against platform specific quirks and return >> corresponding >>> + * CAM ops. >>> + * >>> + * First match against PCI topology then use OEM ID >> and >>> + * OEM revision from MCFG table standard header. >>> + */ >>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; >> f++) { >>> + if ((f->domain == domain || f->domain == >> PCI_MCFG_DOMAIN_ANY) && >>> + (f->bus_num == bus_num || f->bus_num == >> PCI_MCFG_BUS_ANY) && >>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id, >>> + ACPI_OEM_ID_SIZE)) && >>> + (f->oem_revision == mcfg_table->header.oem_revision)) >> >> Is this more likely to be updated between quirky and fixed platforms >> than oem_table_id? What do folks think about using oem_table_id instead >> of, or in addition to, oem_revision? > > From my understanding we need to stick to this mechanism as (otherwise) > there are platforms out in the field that would need a FW update. > > So I don't think that using oem_table_id "instead" is possible; about > "in addition" I think it is doable, but I do not see the advantage much. > I mean that if a platform gets fixed the oem revision should change too, > Right? I think you are correct. My take away on discussions about using this style of quirk matching was that we would require the oem_revision to change as different quirks (or lack of quirks) were required. David Daney > > Thanks > > Gab > From mboxrd@z Thu Jan 1 00:00:00 1970 From: ddaney.cavm@gmail.com (David Daney) Date: Fri, 03 Jun 2016 09:57:40 -0700 Subject: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks. In-Reply-To: References: <1464856864-18049-1-git-send-email-tn@semihalf.com> <1464856864-18049-2-git-send-email-tn@semihalf.com> <57519F09.2010201@codeaurora.org> Message-ID: <5751B704.7010208@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/03/2016 08:32 AM, Gabriele Paoloni wrote: [...] >>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root) >>> +{ >>> + int bus_num = root->secondary.start; >>> + int domain = root->segment; >>> + struct pci_cfg_fixup *f; >>> + >>> + if (!mcfg_table) >>> + return &pci_generic_ecam_ops; >>> + >>> + /* >>> + * Match against platform specific quirks and return >> corresponding >>> + * CAM ops. >>> + * >>> + * First match against PCI topology then use OEM ID >> and >>> + * OEM revision from MCFG table standard header. >>> + */ >>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; >> f++) { >>> + if ((f->domain == domain || f->domain == >> PCI_MCFG_DOMAIN_ANY) && >>> + (f->bus_num == bus_num || f->bus_num == >> PCI_MCFG_BUS_ANY) && >>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id, >>> + ACPI_OEM_ID_SIZE)) && >>> + (f->oem_revision == mcfg_table->header.oem_revision)) >> >> Is this more likely to be updated between quirky and fixed platforms >> than oem_table_id? What do folks think about using oem_table_id instead >> of, or in addition to, oem_revision? > > From my understanding we need to stick to this mechanism as (otherwise) > there are platforms out in the field that would need a FW update. > > So I don't think that using oem_table_id "instead" is possible; about > "in addition" I think it is doable, but I do not see the advantage much. > I mean that if a platform gets fixed the oem revision should change too, > Right? I think you are correct. My take away on discussions about using this style of quirk matching was that we would require the oem_revision to change as different quirks (or lack of quirks) were required. David Daney > > Thanks > > Gab >