All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	netdev@vger.kernel.org,
	Steve Glendinning <steve.glendinning@shawell.net>,
	UNGLinuxDriver@microchip.com, Oliver Neukum <oneukum@suse.com>,
	Andre Edich <andre.edich@microchip.com>,
	Oleksij Rempel <linux@rempel-privat.de>,
	Martyn Welch <martyn.welch@collabora.com>,
	Gabriel Hojda <ghojda@yo2urs.ro>,
	Christoph Fritz <chf.fritz@googlemail.com>,
	Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	Philipp Rosenberger <p.rosenberger@kunbus.com>,
	Ferry Toth <fntoth@gmail.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH net] net: phy: Don't trigger state machine while in suspend
Date: Mon, 6 Jun 2022 07:53:20 +0200	[thread overview]
Message-ID: <20220606055320.GA31220@wunner.de> (raw)
In-Reply-To: <Yp1bIdwLjiLftWgW@lunn.ch>

On Mon, Jun 06, 2022 at 03:40:49AM +0200, Andrew Lunn wrote:
> > +	if (phy_interrupt_is_valid(phydev)) {
> > +		phydev->irq_suspended = 0;
> > +		synchronize_irq(phydev->irq);
> > +
> > +		/* Rerun interrupts which were postponed by phy_interrupt()
> > +		 * because they occurred during the system sleep transition.
> > +		 */
> > +		if (phydev->irq_rerun) {
> > +			phydev->irq_rerun = 0;
> > +			enable_irq(phydev->irq);
> > +			irq_wake_thread(phydev->irq, phydev);
> > +		}
> > +	}
> 
> As i said in a previous thread, PHY interrupts are generally level,
> not edge. So when you call enable_irq(phydev->irq), doesn't it
> immediately fire?

Yes, if the interrupt is indeed level and the PHY is capable of
remembering that an interrupt occurred while the system was suspended
or was about to be suspended.

The irq_wake_thread() ensures that the IRQ handler is called,
should one of those conditions *not* be met.

Recall that phylib uses irq_default_primary_handler() as hardirq
handler.  That handler does nothing else but wake the IRQ thread,
which runs phy->handle_interrupt() in task context.

The irq_wake_thread() above likewise wakes the IRQ thread,
i.e. it tells the scheduler to put it on the run queue.

If, as you say, the interrupt is level and fires upon enable_irq(),
the result is that the scheduler is told twice to put the IRQ thread
on the run queue.  Usually this will happen faster than the IRQ thread
actually gets scheduled, so it will only run once.

In the unlikely event that the IRQ thread gets scheduled before the
call to irq_wake_thread(), the IRQ thread will run twice.
However, that's harmless.  IRQ handlers can cope with that.


> You need to first call the handler, and then re-enable the interrupt.

I guess I could call phy_interrupt() before the enable_irq(),
in lieu of irq_wake_thread().

However, it would mean that I'd invoke the IRQ handler behind the back
of the generic irq code.  That doesn't feel quite right.
Calling irq_wake_thread() is the correct way if one wants to be
compliant with the generic irq code's expectations.

If you feel strongly about it I can make that change but I would
advise against it.  Let me know what you think.

Thanks,

Lukas

  reply	other threads:[~2022-06-06  5:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20220526092819eucas1p2f05c11c571f47b0330e42d00b5d32b50@eucas1p2.samsung.com>
2022-05-26  9:28 ` [PATCH net] net: phy: Don't trigger state machine while in suspend Lukas Wunner
2022-05-26 10:34   ` Marek Szyprowski
2022-06-06  1:40   ` Andrew Lunn
2022-06-06  5:53     ` Lukas Wunner [this message]
2022-06-06 12:19       ` Andrew Lunn

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=20220606055320.GA31220@wunner.de \
    --to=lukas@wunner.de \
    --cc=LinoSanfilippo@gmx.de \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andre.edich@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=chf.fritz@googlemail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fntoth@gmail.com \
    --cc=ghojda@yo2urs.ro \
    --cc=hkallweit1@gmail.com \
    --cc=krzk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@rempel-privat.de \
    --cc=m.szyprowski@samsung.com \
    --cc=martyn.welch@collabora.com \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=p.rosenberger@kunbus.com \
    --cc=pabeni@redhat.com \
    --cc=steve.glendinning@shawell.net \
    /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.