All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	David Miller <davem@davemloft.net>,
	vivien.didelot@savoirfairelinux.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel@savoirfairelinux.com
Subject: Re: [PATCH] net: mdio-gpio: support access that may sleep
Date: Fri, 24 Apr 2015 10:36:40 -0700	[thread overview]
Message-ID: <553A7F28.4040109@gmail.com> (raw)
In-Reply-To: <553A7C73.7040002@cogentembedded.com>

On 24/04/15 10:25, Sergei Shtylyov wrote:
> On 04/24/2015 06:56 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, 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.

Thanks for the reminder though, that needs fixing ;)
--
Florian

  reply	other threads:[~2015-04-24 17:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-22 17:06 [PATCH] net: mdio-gpio: support access that may sleep Vivien Didelot
2015-04-24 15:04 ` David Miller
2015-04-24 15:56   ` Florian Fainelli
2015-04-24 16:01     ` David Miller
2015-04-24 16:19       ` Florian Fainelli
2015-04-24 16:25         ` David Miller
2015-04-24 17:25     ` Sergei Shtylyov
2015-04-24 17:36       ` Florian Fainelli [this message]
2015-04-24 17:42         ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553A7F28.4040109@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kernel@savoirfairelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=vivien.didelot@savoirfairelinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.