linux-kernel - Re: [PATCH v4 05/15] drivers: platform: add fwnode base platform devices retrieval

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <06a6d839-639f-8a86-14a5-4c43bff593b7@linaro.org>
Date:   Tue, 6 Sep 2016 20:08:12 +0800
From:   Hanjun Guo <hanjun.guo@...aro.org>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     iommu@...ts.linux-foundation.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Will Deacon <will.deacon@....com>,
        Marc Zyngier <marc.zyngier@....com>,
        Robin Murphy <robin.murphy@....com>,
        Joerg Roedel <joro@...tes.org>,
        Tomasz Nowicki <tn@...ihalf.com>, Jon Masters <jcm@...hat.com>,
        Sinan Kaya <okaya@...eaurora.org>,
        Nate Watterson <nwatters@...eaurora.org>,
        Dennis Chen <dennis.chen@....com>, linux-acpi@...r.kernel.org,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 05/15] drivers: platform: add fwnode base platform
 devices retrieval

On 2016/9/5 22:57, Lorenzo Pieralisi wrote:
> On Mon, Sep 05, 2016 at 09:19:43PM +0800, Hanjun Guo wrote:
>> On 2016/8/15 23:23, Lorenzo Pieralisi wrote:
>>> The platform device kernel API does not provide functions to
>>> retrieve a platform device through the corresponding struct
>>> device fwnode pointer.
>>>
>>> Implement the fwnode platform_device look-up in drivers core
>>> code by using the bus_find_device() API and a corresponding
>>> matching function. The OF equivalent (eg of_find_device_by_node())
>>> will reuse the newly introduced function when OF code will
>>> take care of setting up the device->fwnode value that is
>>> currently left dangling for platform devices instantiated out
>>> of device tree nodes.
>>>
>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
>>> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>> Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>
>>> ---
>>> drivers/base/platform.c         | 23 +++++++++++++++++++++++
>>> include/linux/platform_device.h |  3 +++
>>> 2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>>> index 6482d47..3ef150d 100644
>>> --- a/drivers/base/platform.c
>>> +++ b/drivers/base/platform.c
>>> @@ -760,6 +760,29 @@ err_out:
>>> }
>>> EXPORT_SYMBOL_GPL(__platform_create_bundle);
>>>
>>> +static int fwnode_dev_match(struct device *dev, void *data)
>>> +{
>>> +	return dev->fwnode == data;
>>> +}
>>> +
>>> +/**
>>> + * platform_find_device_by_fwnode() - Find the platform_device associated
>>> + *				      with a fwnode
>>> + * @fwnode: Pointer to firmware node
>>> + *
>>> + * Returns platform_device pointer, or NULL if not found
>>> + */
>>> +struct platform_device *
>>> +platform_find_device_by_fwnode(struct fwnode_handle *fwnode)
>>> +{
>>> +	struct device *dev;
>>> +
>>> +	dev = bus_find_device(&platform_bus_type, NULL, fwnode,
>>> +			      fwnode_dev_match);
>>> +	return dev ? to_platform_device(dev) : NULL;
>>> +}
>>> +EXPORT_SYMBOL(platform_find_device_by_fwnode);
>>
>> As SMMU is registered as platform devices, I think we need such
>> API to retrieve the platform device with fwnode handle, actually
>> Kefeng introduced a similar patch [1], but your patch is more
>> generic, so this patch make sense to me,
>>
>> Reviewed-by: Hanjun Guo <hanjun.guo@...aro.org>
>
> Thanks ! Strictly speaking, with Robin's new series:
>
> https://lists.linuxfoundation.org/pipermail/iommu/2016-August/018230.html
>
>
> (and corresponding v5 of this one that I have rebased on top of it) we
> do not need this patch any longer and it is not really that generic
> keeping in mind that it can't be used for DT matching (because in DT
> dev->fwnode is dangling); I will see if I keep this patch according
> to dependencies.

OK, I think I will wait for your new version, then try another test
and review it, does it make sense?

>
> Side note: I have a problem with [1], since that code is there to
> implement DT phandles in ACPI IIUC and we must really prevent that :)

Agreed :)

Thanks
Hanjun