[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220727132612.31445-1-alexandru.tachici@analog.com>
Date: Wed, 27 Jul 2022 16:26:12 +0300
From: <alexandru.tachici@...log.com>
To: <andrew@...n.ch>
CC: <alexandru.tachici@...log.com>, <d.michailidis@...gible.com>,
<davem@...emloft.net>, <devicetree@...r.kernel.org>,
<edumazet@...gle.com>, <geert+renesas@...der.be>,
<geert@...ux-m68k.org>, <gerhard@...leder-embedded.com>,
<joel@....id.au>, <krzysztof.kozlowski+dt@...aro.org>,
<kuba@...nel.org>, <l.stelmach@...sung.com>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<robh+dt@...nel.org>, <stefan.wahren@...e.com>,
<stephen@...workplumber.org>, <wellslutw@...il.com>
Subject: [net-next,v2,2/3] net: ethernet: adi: Add ADIN1110 support
> > +static irqreturn_t adin1110_irq(int irq, void *p)
> > +{
> > + struct adin1110_priv *priv = p;
> > + u32 status1;
> > + u32 val;
> > + int ret;
> > + int i;
> > +
> > + mutex_lock(&priv->lock);
>
> The MDIO bus operations are using the same lock. MDIO can be quite
> slow. Do you really need mutual exclusion between MDIO and interrupts?
> What exactly is this lock protecting?
>
> Andrew
Hi Andrew,
Thanks for all the help here.
With this lock I am mainly protecting SPI read/writes. The hardware doesn't expose the MDIO pins.
In order to read/write a PHY reg, there has to be a SPI read/write to the device, the same
line where the MAC is programmed and ethernet frames are sent/received, not very efficient I know.
Best regards,
Alexandru
Powered by blists - more mailing lists