netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Holger Brunck <holger.brunck@hitachienergy.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [v3 2/2] dsa: mv88e6xxx: make serdes SGMII/Fiber output amplitude configurable
Date: Wed, 8 Dec 2021 18:10:09 +0100	[thread overview]
Message-ID: <20211208181009.3cc65cec@thinkpad> (raw)
In-Reply-To: <20211208165938.tbjhuyf6pvzqgn3t@skbuf>

On Wed, 8 Dec 2021 18:59:38 +0200
Vladimir Oltean <olteanv@gmail.com> wrote:

> On Wed, Dec 08, 2021 at 05:51:29PM +0100, Marek Behún wrote:
> > > > Vladimir, can you send your thoughts about this proposal? We are trying
> > > > to propose binding for defining serdes TX amplitude.  
> > >
> > > I don't have any specific concern here. It sounds reasonable for
> > > different data rates to require different transmitter configurations.
> > > Having separate "serdes-tx-amplitude-millivolt" and "serdes-tx-amplitude-modes"
> > > properties sounds okay, although I think a prefix with "-names" at the
> > > end is more canonical ("pinctrl-names", "clock-names", "reg-names" etc),
> > > so maybe "serdes-tx-amplitude-millivolt-names"?
> > > Maybe we could name the first element "default", and just the others
> > > would be named after a phy-mode. This way, if a specific TX amplitude is
> > > found in the device tree for the currently operating PHY mode, it can be
> > > used, otherwise the default (first) amplitude can be used.  
> >
> > Yes, the pair
> >   serdes-tx-amplitude-millivolt
> >   serdes-tx-amplitude-millivolt-names
> > is the best.
> >
> > If the second is not defined, the first should contain only one value,
> > and that is used as default.
> >
> > If multiple values are defined, but "default" is not, the driver should
> > set default value as the default value of the corresponding register.
> >
> > The only remaining question is this: I need to implement this also for
> > comphy driver. In this case, the properties should be defined in the
> > comphy node, not in the MAC node. But the comphy also supports PCIe,
> > USB3 and SATA modes. We don't have strings for them. So this will need
> > to be extended in the future.
> >
> > But for now this proposal seems most legit. I think the properties
> > should be defined in common PHY bindings, and other bindings should
> > refer to them via $ref.  
> 
> I wouldn't $ref the tx-amplitude-millivolt-names from the phy-mode,
> because (a) not all phy-mode values are valid (think of parallel interfaces
> like rgmii) and (b) because sata, pcie, usb are also valid SERDES
> protocols as you point out. With the risk of a bit of duplication, I
> think I'd keep the SERDES protocol names a separate thing for the YAML
> validator.

Not what I meant. What I meant was that the tx-amplitude-millivolt*
properties should be defined in binding for common PHY (not network PHY)
  Documentation/devicetree/bindings/phy/phy-bindings.txt,
and then the mv88e6xxx binding should refer it's
tx-amplitude-millivolt* properties from there.

And the definition in common PHY binding should list all modes in an
enum, containing all network SerDes modes, plus the other modes like
PCIe, USB3, DisplayPort, LVDS, SATA, ...

Marek

  reply	other threads:[~2021-12-08 17:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07 19:07 [v3 1/2] Docs/devicetree: add serdes.yaml Holger Brunck
2021-12-07 19:07 ` [v3 2/2] dsa: mv88e6xxx: make serdes SGMII/Fiber output amplitude configurable Holger Brunck
2021-12-07 19:27   ` Marek Behún
2021-12-08 12:29     ` Holger Brunck
2021-12-08 15:28       ` Marek Behún
2021-12-08 15:49         ` Holger Brunck
2021-12-08 16:17           ` Marek Behún
2021-12-08 16:21             ` Marek Behún
2021-12-08 16:41               ` Vladimir Oltean
2021-12-08 16:49                 ` Vladimir Oltean
2021-12-08 17:00                   ` Marek Behún
2021-12-08 17:19                     ` Vladimir Oltean
2021-12-08 17:36                       ` Marek Behún
2021-12-08 17:55                         ` Andrew Lunn
2021-12-08 18:15                           ` Marek Behún
2021-12-08 16:51                 ` Marek Behún
2021-12-08 16:59                   ` Vladimir Oltean
2021-12-08 17:10                     ` Marek Behún [this message]
2021-12-08 17:12                       ` Marek Behún
2021-12-08 17:20                       ` Vladimir Oltean
2021-12-08 17:00             ` Andrew Lunn
2021-12-08 17:16               ` Marek Behún
2021-12-15 10:27                 ` Holger Brunck
2021-12-15 20:53                   ` Marek Behún
2022-01-20  7:52                     ` Holger Brunck
2022-01-20 17:57                       ` Marek Behún

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=20211208181009.3cc65cec@thinkpad \
    --to=kabel@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=holger.brunck@hitachienergy.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.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 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).