Re: [PATCH] spi: Fix spi device unregister flow

[Saravana Kannan <saravanak@xxxxxxxxxx>]

On Tue, Apr 27, 2021 at 4:49 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Apr 27, 2021 at 02:42:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 27, 2021 at 1:49 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Apr 27, 2021 at 09:52:48AM +0300, Andy Shevchenko wrote:
> > > > +Cc Lukas
> > >
> > > The cleanup callback has been in release() since the framework was
> > > merged AFAICT.
> >
> > Yep.
> >
> > Personally it feels to me wrong to require device_release() being
> > atomic. It might be that I missed something in documentation or
> > somewhere else that suggests the opposite.
> > But let's wait for other comments if any.
>
> There is no requirement from the driver core to have the release
> callback be "atomic", you should be able to sleep just fine in there.
>
> If not, something is wrong and has changed...

This patch is not just about the atomic thing though. I can drop that
from the commit text and I think this still fixes a real issue.
Calling code from another driver (not even the device's own driver)
during a device's release is not guaranteed to work at all (what if
the module gets unloaded?). And this patch also fixes some mismatched
setup/cleanup calls. Using device release for the cleanup() isn't
necessary and we can avoid this bug. This patch tries to fix that too.

As for the atomic thing, that seems to be a generic device link SRCU
implementation issue. It does a put_device() in an atomic context. I'm
not too familiar with the SRCU implementation or why it was needed.
Rafael would have a better idea on that. I can drop that part from the
commit text and move the atomic discussion back to Andy's "atomic
context" thread[1].

-Saravana