Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752427AbdGDPrD (ORCPT ); Tue, 4 Jul 2017 11:47:03 -0400 Received: from mail-qk0-f176.google.com ([209.85.220.176]:35578 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752249AbdGDPrB (ORCPT ); Tue, 4 Jul 2017 11:47:01 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170613151013.GT3187@lahna.fi.intel.com> <20170613200339.GX3187@lahna.fi.intel.com> <20170616083313.GY3187@lahna.fi.intel.com> <20170616120048.GC629@lahna.fi.intel.com> <20170619100209.GC629@lahna.fi.intel.com> From: Andy Shevchenko Date: Tue, 4 Jul 2017 18:46:59 +0300 Message-ID: Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning To: Gabriele Paoloni Cc: Mika Westerberg , "Rafael J. Wysocki" , Lorenzo Pieralisi , "Rafael J. Wysocki" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "robh+dt@kernel.org" , "frowand.list@gmail.com" , "bhelgaas@google.com" , "arnd@arndb.de" , "linux-arm-kernel@lists.infradead.org" , "mark.rutland@arm.com" , "brian.starkey@arm.com" , "olof@lixom.net" , "benh@kernel.crashing.org" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Linuxarm , "linux-pci@vger.kernel.org" , "minyard@acm.org" , John Garry , "xuwei (O)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1964 Lines: 49 On Tue, Jul 4, 2017 at 6:14 PM, Gabriele Paoloni wrote: >> > In my case I'd like to have a platform device using the resources >> that are >> > parsed from the ACPI table (i.e. as it is done now by >> > acpi_create_platform_device()). >> >> So far so good. Nothing prevents you to do that. >> >> > If my understanding is correct, if I declared an mfd_cell for my IPMI >> child >> > the mfd subsystem would create a platform device for such child and >> > therefore acpi_create_platform_device() would fail to create a new >> platform >> > device as adev->physical_node_count will be non zero. >> > However as things stand now mfd_cell devices can only use the >> resources >> > that are statically defined in the code (and therefore not the ones >> in the >> > ACPI nodes)...am I right? >> >> You may file resources first and then register MFD cells. See many >> existing examples in the kernel. > > Well I had a look around the Kernel I have seen no mfd cells using > Resources that are not statically defined: > i.e. cell->resources in mfd_add_device() always points to statically > defined resource structures. > > Usually for ACPI devices first you need to parse the ACPI resources > from the table calling acpi_dev_get_resources(), then you iterate > over the resource list and fill the resource array by calling > acpi_platform_fill_resurces() (as in acpi_create_platform_device()) > > With respect to my case are you suggesting dynamically allocate a > resource array and fill it using the same fashion as > acpi_create_platform_device(), then point cell->resources to such > array before calling mfd_add_device() ? You may do it on stack. Define your cell statically (but not const) and apply resources just before mfd_add_devices() call. There are examples in the existing drivers. Intel LPC comes to my mind and perhaps PMC (Broxton), though latter has too much other stuff around. -- With Best Regards, Andy Shevchenko