Messages in this thread | | | Date | Mon, 13 Dec 2021 12:50:12 +0200 | From | Sean Nyekjaer <> | Subject | Re: [PATCH v5 3/4] mtd: core: protect access to MTD devices while in suspend |
| |
Hi Miquel and Boris,
On Mon, Dec 13, 2021 at 10:53:36AM +0100, Boris Brezillon wrote: > On Mon, 13 Dec 2021 10:33:50 +0100 > Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > Hello, > > > > boris.brezillon@collabora.com wrote on Mon, 13 Dec 2021 10:28:01 +0100: > > > > > On Mon, 13 Dec 2021 10:10:25 +0100 > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > Hi Sean, > > > > > > > > sean@geanix.com wrote on Fri, 10 Dec 2021 14:25:35 +0100: > > > > > > > > > On Thu, Dec 09, 2021 at 03:28:11PM +0100, Miquel Raynal wrote: > > > > > > Hi Sean, > > > > > > > > > > > > sean@geanix.com wrote on Thu, 9 Dec 2021 15:07:21 +0100: > > > > > > > > > > > > > On Fri, Dec 03, 2021 at 02:39:58PM +0100, Miquel Raynal wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > Fine by me, lets drop this series. > > > > > > > > > > > > > > > > FYI I've dropped the entire series from mtd/next. I'm waiting for the > > > > > > > > fix discussed below (without abusing the chip mutex ;-) ). > > > > > > > > > > > > > > Cool, looking forward to test a patch series :) > > > > > > > > > > > > Test? You mean "write"? :) > > > > > > > > > > > > Cheers, > > > > > > Miquèl > > > > > > > > > > Hi Miquel, > > > > > > > > > > Should we us a atomic for the suspended variable? > > > > > > > > I haven't thought about it extensively, an atomic variable sound fine > > > > but I am definitely not a locking expert... > > > > > > No need to use an atomic if the variable is already protected by a lock > > > when accessed, and this seems to be case. > > > > Maybe there was a confusion about this lock: I think Boris just do not > > want the core to take any lock during a suspend operation. But you can > > still use locks, as long as you release them before suspending. > > > > And also, that chip lock might not be the one you want to take because > > it's been introduced for another purpose. > > Access to the suspended field is already protected by the chip lock, > and I think it's just fine to keep it this way.
I'm reading the suspended variable in wait_event() outside the lock :/
/Sean
| |