All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Andrew Lunn <andrew@lunn.ch>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: mdiobus: Prevent spike on MDIO bus reset signal
Date: Wed, 27 Jan 2021 14:54:37 -0800	[thread overview]
Message-ID: <20210127145437.1f5227b5@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <c640eb02-fe31-d460-521b-c7e5b85f016f@topic.nl>

On Wed, 27 Jan 2021 08:08:29 +0100 Mike Looijmans wrote:
> > 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.
> >  
> Thanks, excellent explanation.
> 
> As a bit of background, we were using a Marvell PHY where the datasheet 
> states that thou shallt not release the reset within 50 ms of power-up. 
> A pull-down on the active-low reset was thus added. Looking at the reset 
> signal with a scope revealed a short spike, visible only because it was 
> being controlled by an I2C GPIO expander. So it's indeed point "B" that 
> we wanted to eliminate.

This is all useful information - can we roll more of it into the commit
message? I'd think that calling out the part and the 50ms value could
make things more "concrete" for a reader down the line?

  reply	other threads:[~2021-01-27 22:56 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
     [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 [this message]
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=20210127145437.1f5227b5@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.