From: Andrew Lunn <andrew@lunn.ch>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
devicetree@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH net-next 0/7] net: sfp: improve high power module implementation
Date: Fri, 21 Oct 2022 17:42:24 +0200 [thread overview]
Message-ID: <Y1K94ImMTITNaYE/@lunn.ch> (raw)
In-Reply-To: <Y0/7dAB8OU3jrbz6@shell.armlinux.org.uk>
On Wed, Oct 19, 2022 at 02:28:20PM +0100, Russell King (Oracle) wrote:
> Hi,
>
> This series aims to improve the power level switching between standard
> level 1 and the higher power levels.
>
> The first patch updates the DT binding documentation to include the
> minimum and default of 1W, which is the base level that every SFP cage
> must support. Hence, it makes sense to document this in the binding.
>
> The second patch enforces a minimum of 1W when parsing the firmware
> description, and optimises the code for that case; there's no need to
> check for SFF8472 compliance since we will not need to touch the
> A2h registers.
>
> Patch 3 validates that the module supports SFF-8472 rev 10.2 before
> checking for power level 2 - rev 10.2 is where support for power
> levels was introduced, so if the module doesn't support this revision,
> it doesn't support power levels. Setting the power level 2 declaration
> bit is likely to be spurious.
Or it is yet another case of violating the standard. The bit is valid,
the revision is wrong in the EEPROM. How long do you think it will be
before we see a quirk like this?
> Patch 4 does the same for power level 3, except this was introduced in
> SFF-8472 rev 11.9. The revision code was never updated, so we use the
> rev 11.4 to signify this.
Great, the standard itself is broken.
Andrew
prev parent reply other threads:[~2022-10-21 16:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 13:28 [PATCH net-next 0/7] net: sfp: improve high power module implementation Russell King (Oracle)
2022-10-19 13:28 ` [PATCH net-next 1/7] dt-bindings: net: sff,sfp: update binding Russell King (Oracle)
2022-10-19 23:31 ` Rob Herring
2022-10-20 8:28 ` Russell King (Oracle)
2022-10-20 14:19 ` Rob Herring
2022-10-20 14:27 ` Rob Herring
2022-10-20 16:08 ` Russell King (Oracle)
2022-10-20 22:06 ` Rob Herring
2022-10-20 14:31 ` Russell King (Oracle)
2022-10-21 15:42 ` Andrew Lunn [this message]
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=Y1K94ImMTITNaYE/@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh+dt@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).