Re: [PATCH v2] net: sfp: workaround GPIO input signals bounce

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Sep 20, 2022 at 08:19:11AM -0700, Jakub Kicinski wrote:
> On Wed, 14 Sep 2022 08:36:35 +0300 Baruch Siach wrote:
> > From: Baruch Siach <baruch.siach@siklu.com>
> > 
> > Add a trivial debounce to avoid miss of state changes when there is no
> > proper hardware debounce on the input signals. Otherwise a GPIO might
> > randomly indicate high level when the signal is actually going down,
> > and vice versa.
> > 
> > This fixes observed miss of link up event when LOS signal goes down on
> > Armada 8040 based system with an optical SFP module.
> > 
> > Signed-off-by: Baruch Siach <baruch.siach@siklu.com>
> > ---
> > v2:
> >   Skip delay in the polling case (RMK)
> 
> Is this acceptable now, Russell?

I don't think so. The decision to poll is not just sfp->need_poll,
we also do it when need_poll is false, but we need to use the soft
state as well:

        if (sfp->state_soft_mask & (SFP_F_LOS | SFP_F_TX_FAULT) &&
            !sfp->need_poll)
                mod_delayed_work(system_wq, &sfp->poll, poll_jiffies);

I think, if we're going to use this "simple" debounce, we need to
add a flag to sfp_gpio_get_state() that indicates whether it's been
called from an interrupt.

However, even that isn't ideal, because if we poll, we get no
debouncing.

The unfortunate thing is, on the Macchiatobin (which I suspect is
the platform that Baruch is addressing here) there are no pull-up
resistors on the lines as required by the SFP MSA, so they tend to
float around when not being actively driven. Debouncing will help
to avoid some of the problems stemming from that, but ultimately
some will still get through. The only true real is a hardware one
which isn't going to happen.

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