linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Mike Looijmans <mike.looijmans@topic.nl>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: mdiobus: Prevent spike on MDIO bus reset signal
Date: Tue, 26 Jan 2021 13:49:38 +0000	[thread overview]
Message-ID: <20210126134937.GI1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <YBAVwFlLsfVEHd+E@lunn.ch>

On Tue, Jan 26, 2021 at 02:14:40PM +0100, Andrew Lunn wrote:
> On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijmans wrote:
> > The mdio_bus reset code first de-asserted the reset by allocating with
> > GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if
> > the reset signal defaulted to asserted, there'd be a short "spike"
> > before the reset.
> > 
> > Instead, directly assert the reset signal using GPIOD_OUT_HIGH, this
> > removes the spike and also removes a line of code since the signal
> > is already high.
> 
> Hi Mike
> 
> This however appears to remove the reset pulse, if the reset line was
> already low to start with. Notice you left
> 
> fsleep(bus->reset_delay_us);
> 
> without any action before it? What are we now waiting for?  Most data
> sheets talk of a reset pulse. Take the reset line high, wait for some
> time, take the reset low, wait for some time, and then start talking
> to the PHY. I think with this patch, we have lost the guarantee of a
> low to high transition.
> 
> Is this spike, followed by a pulse actually causing you problems? If
> so, i would actually suggest adding another delay, to stretch the
> spike. We have no control over the initial state of the reset line, it
> is how the bootloader left it, we have to handle both states.

Andrew, I don't get what you're saying.

Here is what happens depending on the pre-existing state of the
reset signal:

Reset (previously asserted):   ~~~|_|~~~~|_______
Reset (previously deasserted): _____|~~~~|_______
                                  ^ ^    ^
                                  A B    C

At point A, the low going transition is because the reset line is
requested using GPIOD_OUT_LOW. If the line is successfully requested,
the first thing we do is set it high _without_ any delay. This is
point B. So, a glitch occurs between A and B.

We then fsleep() and finally set the GPIO low at point C.

Requesting the line using GPIOD_OUT_HIGH eliminates the A and B
transitions. Instead we get:

Reset (previously asserted)  : ~~~~~~~~~~|______
Reset (previously deasserted): ____|~~~~~|______
                                   ^     ^
                                   A     C

Where A and C are the points described above in the code. Point B
has been eliminated.

Therefore, to me the patch looks entirely reasonable and correct.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2021-01-26 13:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26  7:33 [PATCH] net: mdiobus: Prevent spike on MDIO bus reset signal Mike Looijmans
2021-01-26 13:14 ` Andrew Lunn
2021-01-26 13:49   ` Russell King - ARM Linux admin [this message]
     [not found]     ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.b4d05392-d8bb-4828-9ac6-5a63736d3625@emailsignatures365.codetwo.com>
     [not found]       ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.0d2bd5fa-15cc-4b27-b94e-83614f9e5b38.23e4b566-2e4d-4160-a40f-4bf79ef86f8a@emailsignatures365.codetwo.com>
2021-01-27  7:08         ` Mike Looijmans
2021-01-27 22:54           ` Jakub Kicinski
2021-01-28  0:00     ` Andrew Lunn
2021-01-28  0:25       ` Russell King - ARM Linux admin
2021-01-28  1:12         ` Andrew Lunn
     [not found]           ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.47109184-a5be-4b1d-bb22-724baf83e536@emailsignatures365.codetwo.com>
     [not found]             ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.0d2bd5fa-15cc-4b27-b94e-83614f9e5b38.a2a17a1f-7cb0-46c3-bdd8-65266e08a153@emailsignatures365.codetwo.com>
2021-02-02 11:40               ` Mike Looijmans
2021-02-02 13:51                 ` Andrew Lunn
2021-01-28  1:56 ` Andrew Lunn
     [not found]   ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.7228ddf2-6794-42a0-8b0b-3821446cdb40@emailsignatures365.codetwo.com>
     [not found]     ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.0d2bd5fa-15cc-4b27-b94e-83614f9e5b38.7855d092-e2c3-4ba5-a029-2a0bbce637e1@emailsignatures365.codetwo.com>
2021-01-28  8:45       ` Mike Looijmans
2021-01-29 20:23         ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210126134937.GI1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.looijmans@topic.nl \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).