All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: "Bjørn Mork" <bjorn@mork.no>, "Andrew Lunn" <andrew@lunn.ch>,
	davem@davemloft.net, "Jakub Kicinski" <kuba@kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	thomas.petazzoni@bootlin.com,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Köry Maincent" <kory.maincent@bootlin.com>,
	"Simon Horman" <horms@kernel.org>,
	"Romain Gantois" <romain.gantois@bootlin.com>,
	"Antoine Tenart" <atenart@kernel.org>,
	"Marek Behún" <kabel@kernel.org>
Subject: Re: [PATCH net-next 0/2] net: phy: sfp: Add single-byte SMBus SFP access
Date: Mon, 24 Feb 2025 10:35:26 +0100	[thread overview]
Message-ID: <20250224103526.5164e637@fedora> (raw)
In-Reply-To: <Z7wyFolx3q6ACUHO@shell.armlinux.org.uk>

On Mon, 24 Feb 2025 08:47:18 +0000
"Russell King (Oracle)" <linux@armlinux.org.uk> wrote:

> On Mon, Feb 24, 2025 at 08:13:22AM +0100, Bjørn Mork wrote:
> > Andrew Lunn <andrew@lunn.ch> writes:
> >   
> > >> So, not only do I think that hwmon should be disabled if using SMBus,
> > >> but I also think that the kernel should print a warning that SMBus is
> > >> being used and therefore e.g. copper modules will be unreliable. We
> > >> don't know how the various firmwares in various microprocessors that
> > >> convert I2C to MDIO will behave when faced with SMBus transfers.  
> > >
> > > I agree, hwmon should be disabled, and that the kernel should printing
> > > a warning that the hardware is broken and that networking is not
> > > guaranteed to be reliable.  
> > 
> > What do you think will be the effect of such a warning?  Who is the
> > target audience?
> > 
> > You can obviously add it, and I don't really care.  But I believe the
> > result will be an endless stream of end users worrying about this scary
> > warning and wanting to know what they can do about it.  What will be
> > your answer?  
> 
> ... which is good, because it raises the visibility of crap hardware
> and will make people think twice about whether to purchase it, thus
> penalising (a little) the sales of badly designed hardware.

It's also going to allow users to understand a bit more why all
features aren't available. Plugging modules in a true i2c connected
cage will report all the features, while plugging on an smbus cage will
cause the use of a degraded mode. Not only for hwmon, but as Russell
specifies, I doubt all SFP PHY will behave exactly the same...

I'll respin without hwmon and with the warning then.

Maxime

  reply	other threads:[~2025-02-24  9:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-23 17:28 [PATCH net-next 0/2] net: phy: sfp: Add single-byte SMBus SFP access Maxime Chevallier
2025-02-23 17:28 ` [PATCH net-next 1/2] net: phy: sfp: Add support for SMBus module access Maxime Chevallier
2025-02-23 17:28 ` [PATCH net-next 2/2] net: mdio: mdio-i2c: Add support for single-byte SMBus operations Maxime Chevallier
2025-02-24  3:36   ` Andrew Lunn
2025-02-24 10:03     ` Maxime Chevallier
2025-02-23 17:40 ` [PATCH net-next 0/2] net: phy: sfp: Add single-byte SMBus SFP access Russell King (Oracle)
2025-02-23 17:48   ` Maxime Chevallier
2025-02-25 12:38   ` Bjørn Mork
2025-02-25 13:06     ` Maxime Chevallier
2025-02-25 13:29       ` Andrew Lunn
2025-02-25 17:15     ` Russell King (Oracle)
2025-02-25 18:07       ` Bjørn Mork
2025-02-25 18:40         ` Russell King (Oracle)
2025-02-23 18:37 ` Bjørn Mork
2025-02-23 20:31   ` Russell King (Oracle)
2025-02-24  3:32     ` Andrew Lunn
2025-02-24  7:13       ` Bjørn Mork
2025-02-24  8:47         ` Russell King (Oracle)
2025-02-24  9:35           ` Maxime Chevallier [this message]
2025-02-24 13:31         ` Andrew Lunn
2025-02-24 13:48           ` Russell King (Oracle)
2025-02-24 14:18             ` Andrew Lunn
2025-02-24 14:32             ` Marek Behún
2025-02-24 14:38               ` Russell King (Oracle)
2025-02-24 16:24             ` Maxime Chevallier
2025-02-25  8:08               ` Maxime Chevallier
2025-02-24  9:38   ` Maxime Chevallier
2025-02-24 10:36     ` Marek Behún
2025-02-24 16:30 ` Sean Anderson

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=20250224103526.5164e637@fedora \
    --to=maxime.chevallier@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=atenart@kernel.org \
    --cc=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kabel@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=romain.gantois@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    /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.