netdev - Re: [PATCH v2 1/4] net: macb: Check MDIO state before read/write and use timeouts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFcVECK=4e-+1u3X+OuLoAEicUtrkTX3C0wzAugMRcJSP0N-Vg@mail.gmail.com>
Date:   Tue, 27 Nov 2018 11:06:36 +0530
From:   Harini Katakam <harinik@...inx.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Claudiu Beznea <Claudiu.Beznea@...rochip.com>,
        Harini Katakam <harini.katakam@...inx.com>,
        Nicolas Ferre <Nicolas.Ferre@...rochip.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Michal Simek <michal.simek@...inx.com>,
        Shubhrajyoti Datta <shubhrajyoti.datta@...inx.com>,
        sai.pavan.boddu@...inx.com
Subject: Re: [PATCH v2 1/4] net: macb: Check MDIO state before read/write and
 use timeouts

Hi Claudiu,
On Mon, Nov 26, 2018 at 8:22 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Mon, Nov 26, 2018 at 02:46:01PM +0000, Claudiu.Beznea@...rochip.com wrote:
> > Hi Harini,
> >
> > On 26.11.2018 09:07, Harini Katakam wrote:
> > > From: Harini Katakam <harinik@...inx.com>
> > >
> > > Replace the while loop in MDIO read/write functions with a timeout.
> > > In addition, add a check for MDIO bus busy before initiating a new
> > > operation as well to make sure there is no ongoing MDIO operation.
> >
> > Is this MDIO bus busy check necessary? The caller of
> > macb_mdio_read/macb_mdio_write locks the mdio bus mutex before calling it
> > (e.g. mdiobus_read).
>
> Hi Claudiu
>
> It depends on the implementation. A write operation you could just
> launch, but not wait for it to complete, allowing you to do other
> stuff while the hardware is busy. For the next operation you then do
> need to check the previous operation has completed.
>
> I've not checked it is actually implemented this way.

Yes, as Andrew mentioned, a previous MDIO bus operation cannot
be assumed to be complete always - for ex., in case of a timeout.
There is a chance that the MDIO bus bit is busy when mdio_read/write
is called.

Regards,
Harini