linux-kernel - Re: [PATCH 3/3] driver core: bus: Correct API bus_rescan

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b4106831-f1bd-44d9-aed7-18097d3ddead@icloud.com>
Date: Wed, 4 Sep 2024 23:42:43 +0800
From: Zijun Hu <zijun_hu@...oud.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, linux-kernel@...r.kernel.org,
 Zijun Hu <quic_zijuhu@...cinc.com>
Subject: Re: [PATCH 3/3] driver core: bus: Correct API bus_rescan_devices()
 behavior

On 2024/9/4 22:44, Greg Kroah-Hartman wrote:
> On Wed, Sep 04, 2024 at 10:26:39PM +0800, Zijun Hu wrote:
>> On 2024/9/4 21:54, Greg Kroah-Hartman wrote:
>>> On Wed, Sep 04, 2024 at 08:56:44PM +0800, Zijun Hu wrote:
>>>> From: Zijun Hu <quic_zijuhu@...cinc.com>
>>>>
>>>> API bus_rescan_devices() should ideally scan drivers for a bus's devices
>>>> as many as possible, but it really stops scanning for remaining devices
>>>> even if a device encounters inconsequential errors such as -EPROBE_DEFER
>>>
>>> -EPROBE_DEFER should not be an issue for scanning the bus, that's only
>>> for probe errors, so who is returning that mess today?  Let's fix that
>>> up please.
>>>
>>
>> drivers/amba/bus.c:
>> struct bus_type amba_bustype = {
>> ...
>>         .match          = amba_match,
>> ...
>> };
>> amba_match() may return -EPROBE_DEFER.
> 
> Why?  That feels wrong.
> 

i have below understanding after reading drivers/amba/bus.c.

amba_device_add() needs to read ID from device to add device.
but resources such as clocks may be not ready to read ID at that time

so it registers a empty amba_driver @amba_proxy_drv which will trigger
reading ID within bus_type match() when add a device by amba_device_add()

bus_type match() will defer device probe when resources is not ready
during match().

at deferral probe() time, match() is able to read ID since resources is
ready at that time, and it notify device adding by uevent to user.

user loads matched driver for the device which has ID read out.

>> you maybe also look at below AMBA bus related commit.
>> Commit: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from
>> bus_type.match()"
> 
> Ah, ick, clocks.  What a mess.
> 
> I don't think we need this anymore with the genric device link stuff
> anymore, but I'm not quite sure.
> 
yes, i agree with you.

>> is it proper to change bus_type match()'s return value type to bool type
>> back if this issue is fixed?
> 
> Yes, I would like to.  Care to look into it, odds are you can test this
> better than I can :)
> 
actually, i also does not have AMBA test environment. let me send a AMBA
patch to start a topic to check if AMBA maintainers have good ideas to
help us at spare time.

> thanks,
> 
> greg k-h