[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201030233627.GA1054829@lunn.ch>
Date: Sat, 31 Oct 2020 00:36:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Ioana Ciornei <ciorneiioana@...il.com>,
Russell King <linux@...linux.org.uk>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
Ioana Ciornei <ioana.ciornei@....com>,
Alexandru Ardelean <alexandru.ardelean@...log.com>,
Andre Edich <andre.edich@...rochip.com>,
Antoine Tenart <atenart@...nel.org>,
Baruch Siach <baruch@...s.co.il>,
Christophe Leroy <christophe.leroy@....fr>,
Dan Murphy <dmurphy@...com>,
Divya Koppera <Divya.Koppera@...rochip.com>,
Florian Fainelli <f.fainelli@...il.com>,
Hauke Mehrtens <hauke@...ke-m.de>,
Jerome Brunet <jbrunet@...libre.com>,
Kavya Sree Kotagiri <kavyasree.kotagiri@...rochip.com>,
Linus Walleij <linus.walleij@...aro.org>,
Marco Felsch <m.felsch@...gutronix.de>,
Marek Vasut <marex@...x.de>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Mathias Kresin <dev@...sin.me>,
Maxim Kochetkov <fido_max@...ox.ru>,
Michael Walle <michael@...le.cc>,
Neil Armstrong <narmstrong@...libre.com>,
Nisar Sayed <Nisar.Sayed@...rochip.com>,
Oleksij Rempel <o.rempel@...gutronix.de>,
Philippe Schenker <philippe.schenker@...adex.com>,
Willy Liu <willy.liu@...ltek.com>,
Yuiko Oshino <yuiko.oshino@...rochip.com>
Subject: Re: [PATCH net-next 00/19] net: phy: add support for shared
interrupts (part 1)
> > - Every PHY driver gains a .handle_interrupt() implementation that, for
> > the most part, would look like below:
> >
> > irq_status = phy_read(phydev, INTR_STATUS);
> > if (irq_status < 0) {
> > phy_error(phydev);
> > return IRQ_NONE;
> > }
> >
> > if (irq_status == 0)
>
> Here I have a concern, bits may be set even if the respective interrupt
> source isn't enabled. Therefore we may falsely blame a device to have
> triggered the interrupt. irq_status should be masked with the actually
> enabled irq source bits.
Hi Heiner
I would say that is a driver implementation detail, for each driver to
handle how it needs to handle it. I've seen some hardware where the
interrupt status is already masked with the interrupt enabled
bits. I've soon other hardware where it is not.
For example code, what is listed above is O.K. The real implementation
in a driver need knowledge of the hardware.
Andrew
Powered by blists - more mailing lists