On 10/18/22 10:46, Linus Walleij wrote:
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.
The MXC GPIO is traditionally completely separate from IOMUXC pinmux
controller, the MX8 (the non-M and non-X) is just a bit odd and I have
little experience with that one.
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
I saw that one, thanks for CCing me, I actually dropped the request from
you here yesterday by accident (sorry).
