linux-kernel - Re: [PATCH] net: mdio: mdio-bcm-unimac: Delay before first poll

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] [day] [month] [year] [list]

Message-ID: <9c51ecda-4930-4c27-91d6-407efd860aa9@lunn.ch>
Date:   Wed, 13 Dec 2023 23:00:39 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Justin Chen <justin.chen@...adcom.com>, netdev@...r.kernel.org,
        Doug Berger <opendmb@...il.com>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: mdio: mdio-bcm-unimac: Delay before first poll

On Wed, Dec 13, 2023 at 03:01:09PM +0000, Russell King (Oracle) wrote:
> On Wed, Dec 13, 2023 at 11:57:52AM +0100, Andrew Lunn wrote:
> > On Tue, Dec 12, 2023 at 04:02:49PM -0800, Justin Chen wrote:
> > > With a clock interval of 400 nsec and a 64 bit transactions (32 bit
> > > preamble & 16 bit control & 16 bit data), it is reasonable to assume
> > > the mdio transaction will take 25.6 usec. Add a 30 usec delay before
> > > the first poll to reduce the chance of a 1000-2000 usec sleep.
> > 
> > #define  MDIO_C45               0
> > 
> > suggests the hardware can do C45? The timing works out different then.
> > Maybe add a comment by the udelay() that is assumes C22, to give a
> > clue to somebody who is adding C45 support the delay needs to be
> > re-evaluated.
> 
> Note, however, that the driver only supports C22 operations (it only
> populates the read|write functions, not the c45 variants).

Yes, i checked that. Which is why i used the wording 'a clue to
somebody who is adding C45'. Not everybody adding such support would
figure out the relevance of 30us and that it might not be optimal for
C45. A comment might point them on the right line of thinking. That is
all i was trying to say.

    Andrew