From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Garry Subject: Re: [PATCH v13 7/9] ACPI: Translate the I/O range of non-MMIO devices before scanning Date: Fri, 16 Feb 2018 14:48:46 +0000 Message-ID: References: <1518543933-22456-1-git-send-email-john.garry@huawei.com> <1518543933-22456-8-git-send-email-john.garry@huawei.com> <59e5293f-0ea5-12f4-27db-b13bbcf0918b@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Shevchenko Cc: Mika Westerberg , "Rafael J. Wysocki" , Lorenzo Pieralisi , "Rafael J. Wysocki" , Hanjun Guo , Rob Herring , Bjorn Helgaas , Arnd Bergmann , Mark Rutland , Olof Johansson , Dann Frazier , Rob Herring , Joe Perches , Benjamin Herrenschmidt , linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel Mailing List , ACPI Devel Maling List , Linuxarm , Corey Minyard , devic List-Id: linux-acpi@vger.kernel.org On 16/02/2018 14:42, Andy Shevchenko wrote: > On Thu, Feb 15, 2018 at 7:07 PM, John Garry wrote: >> On 14/02/2018 16:16, Andy Shevchenko wrote: > >>>>>>>>> + list_for_each_entry(rentry, &resource_list, node) >>>>>>>>> + resources[count++] = *rentry->res; >>>>> >>>>>>> It has similarities with acpi_create_platform_device(). >>>>>>> I guess we can utilize existing code. >>>> >>>>> For sure, this particular segment is effectively same as part of >>>>> acpi_create_platform_device(): >>> >>> Not the same, acpi_create_platform_device() does a bit more than >>> copying the resources. If it indeed makes no hurt... >>> >>>>> list_for_each_entry(rentry, &resource_list, node) >>>>> acpi_platform_fill_resource(adev, rentry->res, >>>>> &resources[count++]); >>>>> So is your idea to refactor this common segment into a helper function? >>> >>> ...I would go with helper. >>> >> >> Hi Andy, >> >> Since the plan now is that this code is no longer going to be added to >> drivers/acpi, but instead pushed to the LLDD, I am pondering whether we >> should still factor out of this common code. Opinion? > > I would still go with a common helper. Though, as first step, we can > make it lazy, i.e. put a comment in your code, like a todo notice (w/o > TODO word :-) ) to consider a common helper. Fine, I was also thinking that I don't want to do this now as it could make merging the patchset more complex. For now, the ACPI change I plan creates no dependencies. Cheers, John > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html