Re: [PATCH] net: mdio-gpio: support access that may sleep
From: Sergei Shtylyov
Date: Fri Apr 24 2015 - 13:43:11 EST
On 04/24/2015 08:36 PM, Florian Fainelli wrote:
Some systems using mdio-gpio may use gpio on message based busses,
which
require sleeping (e.g. gpio from an I2C I/O expander).
Since this driver does not use IRQ handler, it is safe to use the
_cansleep suffixed gpio accessors.
Signed-off-by: Vivien Didelot <vivien.didelot@xxxxxxxxxxxxxxxxxxxx>
Since this is down underneath the layer of an MII bus, you cannot
universally say that these routines are always called in a sleepable
context.
The PHY layer, and the driver itself above that, might call these
routines from timers, interruptes etc.
The PHY library calls these routines from its state machine workqueue
for that reason, or from process context (when invoked via ethtool
ioctl). The only special case is phy_mac_interrupt() which is callable
from interrupt context,
It is not (as we have discussed recently) -- cancel_work_sync() may
sleep.
True, but that does not invalidate my comment, I meant to write that
this is the only function that you *might* potentially want to call from
interrupt context,
Sure, I did want that. :-)
and yet it does not trigger low-level I/O accesses to
the underlying MDIO bus, but instead uses the PHY library state machine
workqueue to do that.
That's so.
Thanks for the reminder though, that needs fixing ;)
Hopefully it's fixable... I had to use GPIO interrupt for AVB_PHY_INT pin
since I didn't want to create a thread just to call phy_mac_interrupt().
--
Florian
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/