From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759248AbcIWKxQ (ORCPT ); Fri, 23 Sep 2016 06:53:16 -0400 Received: from mail-lf0-f54.google.com ([209.85.215.54]:33108 "EHLO mail-lf0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758775AbcIWKxM (ORCPT ); Fri, 23 Sep 2016 06:53:12 -0400 Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case To: Bjorn Helgaas , Duc Dang References: <20160919180900.GB13775@localhost> <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> <20160920133327.GB13855@localhost> <20160920140518.GD13855@localhost> <20160920191744.GA4941@localhost> <20160921140549.GA11968@red-moon> <20160921180457.GB20006@localhost> <20160921191845.GD20006@localhost> Cc: Lorenzo Pieralisi , Ard Biesheuvel , David Daney , Will Deacon , Catalin Marinas , Rafael Wysocki , Arnd Bergmann , Hanjun Guo , Sinan Kaya , Jayachandran C , Christopher Covington , Robert Richter , Marcin Wojtas , Liviu Dudau , Yijing Wang , Mark Salter , linux-pci@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , Linaro ACPI Mailman List , Jon Masters , Andrea Gallo , Jeremy Linton , Dongdong Liu , Gabriele Paoloni , Jeff Hugo , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Rafael J. Wysocki" From: Tomasz Nowicki Message-ID: Date: Fri, 23 Sep 2016 12:53:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160921191845.GD20006@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, On 21.09.2016 21:18, Bjorn Helgaas wrote: > On Wed, Sep 21, 2016 at 11:58:22AM -0700, Duc Dang wrote: >> On Wed, Sep 21, 2016 at 11:04 AM, Bjorn Helgaas wrote: >>> On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote: > >>> The existing x86 practice is to use PNP0C02 devices for this purpose, >>> and I think we should just follow that practice. >>> >>> ... >>> >>> My point is that the hard-coding should not be buried in a driver >>> where it's invisible to the rest of the kernel. If we hard-code it in >>> a quirk that adds _CRS entries, then the kernel will work just like it >>> would if the firmware had been correct in the first place. The >>> resource will appear in /sys/devices/pnp*/*/resources and /proc/iomem, >>> and if we ever used _SRS to assign or move ACPI devices, we would know >>> to avoid the bridge resource. >> >> Are you suggesting to add code similar to functions in >> linux/drivers/pnp/quirks.c to declare/attach the additional resource >> that the host need to have when the resource is not in MCFG table? > > Yes, but what I'm suggesting is actually a little stronger. This has > nothing to do with whether a resource is in the MCFG table or not. > > I'm suggesting ACPI firmware should always describe the resource. If the > firmware is defective and doesn't describe it, we should add a quirk in > pnp/quirks.c to add a resource for it. > Thanks for pointers Bjorn. ThunderX is the case where we cannot change firmware, also it has no PNP0c02 device in tables. So in order to use pnp/quirks.c we would have to fabricate PNP0c02 in kernel and then add quirk entry. I am looking for the best place to put such emulation code but it seems not trivial. Thanks, Tomasz