linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Serge Semin <fancer.lancer@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>,
	Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
	linux-spi <linux-spi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method
Date: Tue, 17 Nov 2020 14:28:23 +0300	[thread overview]
Message-ID: <20201117112823.fwadsn5ld7ovjqun@mobilestation> (raw)
In-Reply-To: <CAHp75VfgdtLxh3uWd-79vEL9bDA0CH2Jiug2g2cJ0R0mQRhW2A@mail.gmail.com>

On Tue, Nov 17, 2020 at 12:56:44PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 17, 2020 at 11:45 AM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> >
> > I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw:
> > Explicitly de-assert CS on SPI transfer completion") a concurrent usage of
> > the spidev devices with different chip-selects causes the "SPI transfer
> > timed out" error.
> 
> I'll read this later...
> 
> > +       mutex_lock(&spi->controller->io_mutex);
> > +
> >         if (spi->controller->setup)
> >                 status = spi->controller->setup(spi);
> >
> >         if (spi->controller->auto_runtime_pm && spi->controller->set_cs) {
> >                 status = pm_runtime_get_sync(spi->controller->dev.parent);
> 

> I didn't check what this lock is protecting,

It is used to protect the SPI io operations. So it's locked only
during the SPI memory operations and the SPI-message execution. That's
the time when the core toggles the controller chip-selects by calling
the spi_set_cs() method and the set_cs callback.

> but have you checked all
> PM runtime callbacks if they are not taking the lock. When you call PM
> runtime functions with 'sync' it may include a lot of work, some of
> which may sleep (not a problem for mutex) and may take arbitrary locks
> (might be a deadlock in case of trying the same lock).

Yeah, I understand that. Simple grepping hasn't showed anyone else but
the SPI-core using it. So unless the controllers PM methods also call
spi_setup() or request SPI-transfers, there shouldn't be a deadlock.
Moreover as I can see from the __spi_pump_messages() method the
IO-mutex is locked during the sync-suffixed PM-methods invocation.
AFAICS locking io_mutex around the PM-methods here shouldn't cause
problems. But of course testing it in various platforms/controllers is
always welcome.

-Sergey

> 
> >                 if (status < 0) {
> > +                       mutex_unlock(&spi->controller->io_mutex);
> >                         pm_runtime_put_noidle(spi->controller->dev.parent);
> >                         dev_err(&spi->controller->dev, "Failed to power device: %d\n",
> >                                 status);
> > @@ -3354,6 +3357,8 @@ int spi_setup(struct spi_device *spi)
> >                 spi_set_cs(spi, false);
> >         }
> >
> > +       mutex_unlock(&spi->controller->io_mutex);
> > +
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko

  reply	other threads:[~2020-11-17 11:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17  9:45 [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method Serge Semin
2020-11-17 10:56 ` Andy Shevchenko
2020-11-17 11:28   ` Serge Semin [this message]
2020-11-18 13:16 ` Mark Brown
2020-11-18 16:29   ` Serge Semin
2020-11-19 18:43     ` Mark Brown
2020-11-19 19:30       ` Geert Uytterhoeven
2020-11-20 17:17 ` Mark Brown
2020-11-20 17:26   ` Serge Semin
2020-11-20 21:35 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201117112823.fwadsn5ld7ovjqun@mobilestation \
    --to=sergey.semin@baikalelectronics.ru \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Ramil.Zaripov@baikalelectronics.ru \
    --cc=andy.shevchenko@gmail.com \
    --cc=broonie@kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).