Messages in this thread | | | Date | Fri, 24 Apr 2015 20:42:49 +0300 | From | Sergei Shtylyov <> | Subject | Re: [PATCH] net: mdio-gpio: support access that may sleep |
| |
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@savoirfairelinux.com>
>>>> 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
| |