On Tue, Oct 18, 2022 at 10:33 AM Marek Vasut <marex@xxxxxxx> wrote: > On 10/17/22 12:23, Linus Walleij wrote: > > On Fri, Oct 14, 2022 at 12:00 AM Marek Vasut <marex@xxxxxxx> wrote: > > > >> The driver currently performs register read-modify-write without locking > >> in its irqchip part, this could lead to a race condition when configuring > >> interrupt mode setting. Add the missing bgpio spinlock lock/unlock around > >> the register read-modify-write. > >> > >> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > >> Reviewed-by: Marc Zyngier <maz@xxxxxxxxxx> > >> Fixes: 07bd1a6cc7cbb ("MXC arch: Add gpio support for the whole platform") > >> Signed-off-by: Marek Vasut <marex@xxxxxxx> > > > > Unrelated, but Marek can you have a look at this MXC patch since > > you're obviously working on the platform: > > https://lore.kernel.org/linux-gpio/20221007152853.838136-1-shenwei.wang@xxxxxxx/ > > Errrr, that's i.MX8, which is completely different chip than the i.MX8M > (except for the naming, which ... oh well). I work on the simpler i.MX8M. Yeah, I think a part of the problem is that the MXC GPIO is not connected to the back-end pin controller for i.MX so one rarely know which SoC it is used on. > But looking at the patch, don't we already have a DT property which lets > one set GPIO as wake up source, without massive enumeration tables in > each GPIO driver ? It seems to me that's what NXP is trying to > implement, per GPIO wake up. I had to bite the bullet and write a longer reply, hoping the i.MX and MXC maintainers wake up: https://lore.kernel.org/linux-gpio/CACRpkdaKncznz5qej6owA2OGMeqbrif9e_QO3CWN6+sGhEApDw@xxxxxxxxxxxxxx/T/#mac3a8d5399c486657c5e168107ed591694d4b155 Yours, Linus Walleij