Re: [PATCH] mmc: allow mmc to block wait_for_device_probe()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Mar 28, 2023 at 03:37:40PM -0700, Dennis Zhou wrote:
> I've been hitting a failed data device lookup when using dm-verity and a
> root device on an emmc partition. This is because there is a race where
> dm-verity is looking for a data device, but the partitions on the emmc
> device haven't been probed yet.
> 
> Initially I looked at solving this by changing devt_from_devname() to
> look for partitions, but it seems there is legacy reasons and issues due
> to dm.
> 
> MMC uses 2 levels of probing. The first to handle initializing the
> host and the second to iterate attached devices. The second is done by
> a workqueue item. However, this paradigm makes wait_for_device_probe()
> useless as a barrier for when we can assume attached devices have been
> probed.
> 
> This patch fixes this by exposing 2 methods inc/dec_probe_count() to
> allow device drivers that do asynchronous probing to delay waiters on
> wait_for_device_probe() so that when they are released, they can assume
> attached devices have been probed.

Please no.  For 2 reasons:
  - the api names you picked here do not make much sense from a global
    namespace standpoint.  Always try to do "noun/verb" as well, so if
    we really wanted to do this it would be "driver_probe_incrememt()"
    or something like that.
 - drivers and subsystems should not be messing around with the probe
   count as it's a hack in the first place to get around other issues.
   Please let's not make it worse and make a formal api for it and allow
   anyone to mess with it.

Why can't you just use normal deferred probing for this?

thanks,

greg k-h