From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, Ido Schimmel <idosch@idosch.org>
Subject: Re: [PATCH net-next] net: sfp: add debugfs support
Date: Wed, 2 Dec 2020 13:03:18 +0000 [thread overview]
Message-ID: <20201202130318.GD1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20201124104640.GA738122@shredder.lan>
Jakub,
What's your opinion on this patch? It seems to have stalled...
Regards,
Russell
On Tue, Nov 24, 2020 at 12:46:40PM +0200, Ido Schimmel wrote:
> On Tue, Nov 24, 2020 at 09:49:16AM +0000, Russell King - ARM Linux admin wrote:
> > On Tue, Nov 24, 2020 at 10:41:51AM +0200, Ido Schimmel wrote:
> > > On Tue, Nov 24, 2020 at 01:14:31AM +0100, Andrew Lunn wrote:
> > > > On Mon, Nov 23, 2020 at 10:06:16PM +0000, Russell King wrote:
> > > > > Add debugfs support to SFP so that the internal state of the SFP state
> > > > > machines and hardware signal state can be viewed from userspace, rather
> > > > > than having to compile a debug kernel to view state state transitions
> > > > > in the kernel log. The 'state' output looks like:
> > > > >
> > > > > Module state: empty
> > > > > Module probe attempts: 0 0
> > > > > Device state: up
> > > > > Main state: down
> > > > > Fault recovery remaining retries: 5
> > > > > PHY probe remaining retries: 12
> > > > > moddef0: 0
> > > > > rx_los: 1
> > > > > tx_fault: 1
> > > > > tx_disable: 1
> > > > >
> > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > >
> > > > Hi Russell
> > > >
> > > > This looks useful. I always seem to end up recompiling the kernel,
> > > > which as you said, this should avoid.
> > >
> > > FWIW, another option is to use drgn [1]. Especially when the state is
> > > queried from the kernel and not hardware. We are using that in mlxsw
> > > [2][3].
> >
> > Presumably that requires /proc/kcore support, which 32-bit ARM doesn't
> > have.
>
> Yes, it does seem to be required for live debugging. I mostly work with
> x86 systems, I guess it's completely different for Andrew and you.
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2020-12-02 13:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-23 22:06 [PATCH net-next] net: sfp: add debugfs support Russell King
2020-11-24 0:14 ` Andrew Lunn
2020-11-24 8:41 ` Ido Schimmel
2020-11-24 9:49 ` Russell King - ARM Linux admin
2020-11-24 10:46 ` Ido Schimmel
2020-12-02 13:03 ` Russell King - ARM Linux admin [this message]
2020-12-02 16:59 ` Jakub Kicinski
2020-12-02 17:01 ` Jakub Kicinski
2020-12-07 16:06 ` Russell King - ARM Linux admin
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=20201202130318.GD1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=idosch@idosch.org \
--cc=kuba@kernel.org \
--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.