linux-kernel - Query on device links

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 for Android: free password hash cracker in your pocket

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

Message-ID: <7f7d9b37-3f10-fefb-db23-86c8f83e8885@huawei.com>
Date:   Thu, 6 Feb 2020 10:31:59 +0000
From:   John Garry <john.garry@...wei.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
CC:     Saravana Kannan <saravanak@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Query on device links

Hi guys,

According to "Limitations" section @ 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/device_link.rst#n110, 
for a managed link, lack of the supplier driver may cause indefinite 
delay in probing of the consumer. Is there any way around this?

So I just want the probe order attempt of the supplier and consumer to 
be guaranteed, but the supplier probe may not be successful, i.e. does 
not actually bind.

In my case, I would like to use device_link_add(supplier, consumer, 
DL_FLAG_AUTOPROBE_CONSUMER), but I find the supplier probe may fail (and 
not due to -EPROBE_DEFER), and my consumer remains in limbo.

You may ask my I want this ordering at all - it is because in 
really_probe(), we do the device DMA configure before the actual device 
driver probe, and I just need that ordering to be ensured between devices.

Thanks,
John