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]
Date:   Tue, 27 Nov 2018 16:19:28 +0530
From:   Harini Katakam <harinik@...inx.com>
To:     Claudiu Beznea <Claudiu.Beznea@...rochip.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        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,

<snip>
> >>>>
> >>>> 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.
>
> Thank you for your responses. I see it now.
>
> Then, do you think it would be better to have a new API part of struct
> mii_bus that drivers should register so that, the mii core to check if the
> bus is idle before lunching a new request?

Sure, let me explore this option.

Regards,
Harini

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ