From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Date: Wed, 21 Sep 2016 13:59:20 -0500 Message-ID: <20160921185920.GC20006@localhost> References: <1473449047-10499-1-git-send-email-tn@semihalf.com> <1473449047-10499-4-git-send-email-tn@semihalf.com> <20160919180900.GB13775@localhost> <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> <20160920133327.GB13855@localhost> <20160920140518.GD13855@localhost> <20160920191744.GA4941@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail.kernel.org ([198.145.29.136]:46108 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933409AbcIUS70 (ORCPT ); Wed, 21 Sep 2016 14:59:26 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Gabriele Paoloni Cc: Ard Biesheuvel , Tomasz Nowicki , David Daney , Will Deacon , Catalin Marinas , Rafael Wysocki , Lorenzo Pieralisi , Arnd Bergmann , Hanjun Guo , Sinan Kaya , Jayachandran C , Christopher Covington , Duc Dang , Robert Richter , Marcin Wojtas , Liviu Dudau , Wangyijing , Mark Salter , "linux-pci@vger.kernel.org" lin On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote: > Hi Bjorn > > [...] > > > > > > If future hardware is completely ECAM-compliant and we don't need any > > more MCFG quirks, that would be great. > > > > But we'll still need to describe that memory-mapped config space > > somewhere. If that's done with PNP0C02 or similar devices (as is done > > on my x86 laptop), we'd be all set. > > > > If we need to work around firmware in the field that doesn't do that, > > one possibility is a PNP quirk along the lines of > > quirk_amd_mmconfig_area(). > > So, if my understanding is correct, for platforms that have not been > shipped yet you propose to use PNP0C02 in the ACPI table in order to > declare a motherboard reserved resource whereas for shipped platforms > you propose to have a quirk along pnp_fixups in order to track the > resource usage even if values are hardcoded...correct? Yes. I'm open to alternate proposals, but x86 uses PNP0C02, and following existing practice seems reasonable. > Before Tomasz came up with this patchset we had a call between the vendors > involved in this PCI quirks saga and other guys from Linaro and ARM. > > Lorenzo summarized the outcome as in the following link > http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html > > Since this quirks mechanism has been discussed for quite a long time now > IMHO it would be good to have a last call including also you (Bjorn) so > that we can all agree on what to do and we avoid changing our drivers again > and again... I think we're converging pretty fast. As far as I'm concerned, the v6 ECAM quirks implementation is perfect. The only remaining issue is reporting the ECAM resources, and I haven't seen objections to using PNP0C02 + PNP quirks for broken firmware. There is the question of how or whether to associate a PNP0A03 PCI bridge with resources from a different PNP0C02 device, but that's not super important. If the hard-coded resources appear both in a quirk and in the PCI bridge driver, it's ugly but not the end of the world. We've still achieved the objective of avoiding landmines in the address space. Bjorn From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Wed, 21 Sep 2016 13:59:20 -0500 From: Bjorn Helgaas To: Gabriele Paoloni Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Message-ID: <20160921185920.GC20006@localhost> References: <1473449047-10499-1-git-send-email-tn@semihalf.com> <1473449047-10499-4-git-send-email-tn@semihalf.com> <20160919180900.GB13775@localhost> <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> <20160920133327.GB13855@localhost> <20160920140518.GD13855@localhost> <20160920191744.GA4941@localhost> MIME-Version: 1.0 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Rafael Wysocki , "linux-pci@vger.kernel.org" , Will Deacon , Sinan Kaya , Wangyijing , Andrea Gallo , Lorenzo Pieralisi , Jeff Hugo , Tomasz Nowicki , Linaro ACPI Mailman List , David Daney , "linux-acpi@vger.kernel.org" , Robert Richter , "liudongdong \(C\)" , Mark Salter , Liviu Dudau , Arnd Bergmann , Jon Masters , Christopher Covington , Marcin Wojtas , "linux-arm-kernel@lists.infradead.org" , Jayachandran C , Ard Biesheuvel , Duc Dang , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Jeremy Linton , Hanjun Guo Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote: > Hi Bjorn > > [...] > > > > > > If future hardware is completely ECAM-compliant and we don't need any > > more MCFG quirks, that would be great. > > > > But we'll still need to describe that memory-mapped config space > > somewhere. If that's done with PNP0C02 or similar devices (as is done > > on my x86 laptop), we'd be all set. > > > > If we need to work around firmware in the field that doesn't do that, > > one possibility is a PNP quirk along the lines of > > quirk_amd_mmconfig_area(). > > So, if my understanding is correct, for platforms that have not been > shipped yet you propose to use PNP0C02 in the ACPI table in order to > declare a motherboard reserved resource whereas for shipped platforms > you propose to have a quirk along pnp_fixups in order to track the > resource usage even if values are hardcoded...correct? Yes. I'm open to alternate proposals, but x86 uses PNP0C02, and following existing practice seems reasonable. > Before Tomasz came up with this patchset we had a call between the vendors > involved in this PCI quirks saga and other guys from Linaro and ARM. > > Lorenzo summarized the outcome as in the following link > http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html > > Since this quirks mechanism has been discussed for quite a long time now > IMHO it would be good to have a last call including also you (Bjorn) so > that we can all agree on what to do and we avoid changing our drivers again > and again... I think we're converging pretty fast. As far as I'm concerned, the v6 ECAM quirks implementation is perfect. The only remaining issue is reporting the ECAM resources, and I haven't seen objections to using PNP0C02 + PNP quirks for broken firmware. There is the question of how or whether to associate a PNP0A03 PCI bridge with resources from a different PNP0C02 device, but that's not super important. If the hard-coded resources appear both in a quirk and in the PCI bridge driver, it's ugly but not the end of the world. We've still achieved the objective of avoiding landmines in the address space. Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: helgaas@kernel.org (Bjorn Helgaas) Date: Wed, 21 Sep 2016 13:59:20 -0500 Subject: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case In-Reply-To: References: <1473449047-10499-1-git-send-email-tn@semihalf.com> <1473449047-10499-4-git-send-email-tn@semihalf.com> <20160919180900.GB13775@localhost> <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> <20160920133327.GB13855@localhost> <20160920140518.GD13855@localhost> <20160920191744.GA4941@localhost> Message-ID: <20160921185920.GC20006@localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote: > Hi Bjorn > > [...] > > > > > > If future hardware is completely ECAM-compliant and we don't need any > > more MCFG quirks, that would be great. > > > > But we'll still need to describe that memory-mapped config space > > somewhere. If that's done with PNP0C02 or similar devices (as is done > > on my x86 laptop), we'd be all set. > > > > If we need to work around firmware in the field that doesn't do that, > > one possibility is a PNP quirk along the lines of > > quirk_amd_mmconfig_area(). > > So, if my understanding is correct, for platforms that have not been > shipped yet you propose to use PNP0C02 in the ACPI table in order to > declare a motherboard reserved resource whereas for shipped platforms > you propose to have a quirk along pnp_fixups in order to track the > resource usage even if values are hardcoded...correct? Yes. I'm open to alternate proposals, but x86 uses PNP0C02, and following existing practice seems reasonable. > Before Tomasz came up with this patchset we had a call between the vendors > involved in this PCI quirks saga and other guys from Linaro and ARM. > > Lorenzo summarized the outcome as in the following link > http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html > > Since this quirks mechanism has been discussed for quite a long time now > IMHO it would be good to have a last call including also you (Bjorn) so > that we can all agree on what to do and we avoid changing our drivers again > and again... I think we're converging pretty fast. As far as I'm concerned, the v6 ECAM quirks implementation is perfect. The only remaining issue is reporting the ECAM resources, and I haven't seen objections to using PNP0C02 + PNP quirks for broken firmware. There is the question of how or whether to associate a PNP0A03 PCI bridge with resources from a different PNP0C02 device, but that's not super important. If the hard-coded resources appear both in a quirk and in the PCI bridge driver, it's ugly but not the end of the world. We've still achieved the objective of avoiding landmines in the address space. Bjorn From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938975AbcIUS7b (ORCPT ); Wed, 21 Sep 2016 14:59:31 -0400 Received: from mail.kernel.org ([198.145.29.136]:46108 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933409AbcIUS70 (ORCPT ); Wed, 21 Sep 2016 14:59:26 -0400 Date: Wed, 21 Sep 2016 13:59:20 -0500 From: Bjorn Helgaas To: Gabriele Paoloni Cc: Ard Biesheuvel , Tomasz Nowicki , David Daney , Will Deacon , Catalin Marinas , Rafael Wysocki , Lorenzo Pieralisi , Arnd Bergmann , Hanjun Guo , Sinan Kaya , Jayachandran C , Christopher Covington , Duc Dang , Robert Richter , Marcin Wojtas , Liviu Dudau , Wangyijing , Mark Salter , "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linaro ACPI Mailman List , Jon Masters , Andrea Gallo , Jeremy Linton , "liudongdong (C)" , Jeff Hugo , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Rafael J. Wysocki" Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Message-ID: <20160921185920.GC20006@localhost> References: <1473449047-10499-1-git-send-email-tn@semihalf.com> <1473449047-10499-4-git-send-email-tn@semihalf.com> <20160919180900.GB13775@localhost> <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> <20160920133327.GB13855@localhost> <20160920140518.GD13855@localhost> <20160920191744.GA4941@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote: > Hi Bjorn > > [...] > > > > > > If future hardware is completely ECAM-compliant and we don't need any > > more MCFG quirks, that would be great. > > > > But we'll still need to describe that memory-mapped config space > > somewhere. If that's done with PNP0C02 or similar devices (as is done > > on my x86 laptop), we'd be all set. > > > > If we need to work around firmware in the field that doesn't do that, > > one possibility is a PNP quirk along the lines of > > quirk_amd_mmconfig_area(). > > So, if my understanding is correct, for platforms that have not been > shipped yet you propose to use PNP0C02 in the ACPI table in order to > declare a motherboard reserved resource whereas for shipped platforms > you propose to have a quirk along pnp_fixups in order to track the > resource usage even if values are hardcoded...correct? Yes. I'm open to alternate proposals, but x86 uses PNP0C02, and following existing practice seems reasonable. > Before Tomasz came up with this patchset we had a call between the vendors > involved in this PCI quirks saga and other guys from Linaro and ARM. > > Lorenzo summarized the outcome as in the following link > http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html > > Since this quirks mechanism has been discussed for quite a long time now > IMHO it would be good to have a last call including also you (Bjorn) so > that we can all agree on what to do and we avoid changing our drivers again > and again... I think we're converging pretty fast. As far as I'm concerned, the v6 ECAM quirks implementation is perfect. The only remaining issue is reporting the ECAM resources, and I haven't seen objections to using PNP0C02 + PNP quirks for broken firmware. There is the question of how or whether to associate a PNP0A03 PCI bridge with resources from a different PNP0C02 device, but that's not super important. If the hard-coded resources appear both in a quirk and in the PCI bridge driver, it's ugly but not the end of the world. We've still achieved the objective of avoiding landmines in the address space. Bjorn