When a spi device is unregistered and triggers a driver unbind, the
driver might need to access the spi device. So, don't have the
controller clean up the spi device before the driver is unbound. Clean
up the spi device after the driver is unbound.
Fixes: c7299fea6769 ("spi: Fix spi device unregister flow")
Reported-by: Lukas Wunner <[email protected]>
Signed-off-by: Saravana Kannan <[email protected]>
---
Lukas,
Can you test this out please?
Thanks,
Saravana
drivers/spi/spi.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 2350d131871b..b856f4a1e3a4 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -401,6 +401,12 @@ static int spi_probe(struct device *dev)
return ret;
}
+static void spi_cleanup(struct spi_device *spi)
+{
+ if (spi->controller->cleanup)
+ spi->controller->cleanup(spi);
+}
+
static int spi_remove(struct device *dev)
{
const struct spi_driver *sdrv = to_spi_driver(dev->driver);
@@ -415,6 +421,7 @@ static int spi_remove(struct device *dev)
ERR_PTR(ret));
}
+ spi_cleanup(to_spi_device(dev));
dev_pm_domain_detach(dev, true);
return 0;
@@ -554,12 +561,6 @@ static int spi_dev_check(struct device *dev, void *data)
return 0;
}
-static void spi_cleanup(struct spi_device *spi)
-{
- if (spi->controller->cleanup)
- spi->controller->cleanup(spi);
-}
-
/**
* spi_add_device - Add spi_device allocated with spi_alloc_device
* @spi: spi_device to register
@@ -714,8 +715,6 @@ void spi_unregister_device(struct spi_device *spi)
if (!spi)
return;
- spi_cleanup(spi);
-
if (spi->dev.of_node) {
of_node_clear_flag(spi->dev.of_node, OF_POPULATED);
of_node_put(spi->dev.of_node);
--
2.31.1.527.g47e6f16901-goog
On Tue, May 04, 2021 at 08:14:16PM -0700, Saravana Kannan wrote:
> @@ -415,6 +421,7 @@ static int spi_remove(struct device *dev)
> ERR_PTR(ret));
> }
>
> + spi_cleanup(to_spi_device(dev));
> dev_pm_domain_detach(dev, true);
>
> return 0;
Unfortunately this doesn't look right: spi_remove() is run on
driver unbind of the spi_device. With the above change,
->setup is called on spi_device addition and ->cleanup is called
on unbind, which is obviously assymetric. What can happen
here is that a slave-specific controller_state is allocated on
spi_device addition, then on unbind that controller_state is freed
and on a subsequent rebind it won't be recreated because ->setup
isn't run on spi_device ->probe.
As I've written yesterday, calling spi_cleanup() in
spi_unregister_device() should be fine if you move it to the end
of the function, but before the final put_device(). For that,
you need to open code the calls to device_del() and put_device()
that happen in device_unregister() so far.
Thanks,
Lukas
On Wed, May 05, 2021 at 07:48:38AM +0200, Lukas Wunner wrote:
> As I've written yesterday, calling spi_cleanup() in
> spi_unregister_device() should be fine if you move it to the end
> of the function, but before the final put_device(). For that,
> you need to open code the calls to device_del() and put_device()
> that happen in device_unregister() so far.
Indeed.
On Tue, May 4, 2021 at 10:48 PM Lukas Wunner <[email protected]> wrote:
>
> On Tue, May 04, 2021 at 08:14:16PM -0700, Saravana Kannan wrote:
> > @@ -415,6 +421,7 @@ static int spi_remove(struct device *dev)
> > ERR_PTR(ret));
> > }
> >
> > + spi_cleanup(to_spi_device(dev));
> > dev_pm_domain_detach(dev, true);
> >
> > return 0;
>
> Unfortunately this doesn't look right: spi_remove() is run on
> driver unbind of the spi_device. With the above change,
> ->setup is called on spi_device addition and ->cleanup is called
> on unbind, which is obviously assymetric. What can happen
> here is that a slave-specific controller_state is allocated on
> spi_device addition, then on unbind that controller_state is freed
> and on a subsequent rebind it won't be recreated because ->setup
> isn't run on spi_device ->probe.
Good point!
>
> As I've written yesterday, calling spi_cleanup() in
> spi_unregister_device() should be fine if you move it to the end
> of the function, but before the final put_device(). For that,
> you need to open code the calls to device_del() and put_device()
> that happen in device_unregister() so far.
Yeah, I saw that email after I sent out this patch. I'll send out a v2.
-Saravana