From: Vladimir Oltean <olteanv@gmail.com>
To: "Marek Behún" <kabel@kernel.org>
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:41:31 +0200 [thread overview]
Message-ID: <20211208164131.fy2h652sgyvhm7jx@skbuf> (raw)
In-Reply-To: <20211208172104.75e32a6b@thinkpad>
On Wed, Dec 08, 2021 at 05:21:04PM +0100, Marek Behún wrote:
> Hello Vladimir,
> > > > but the mv88e6xxx driver also drives switches that allow changing serdes
> > > > modes. There does not need be dedicated TX amplitude register for each serdes
> > > > mode, the point is that we may want to declare different amplitudes for
> > > > different modes.
> > > >
> > > > So the question is: if we go with your binding proposal for the whole mv88e6xxx
> > > > driver, and in the future someone will want to declare different amplitudes for
> > > > different modes on another model, would he need to deprecate your binding or
> > > > would it be easy to extend?
> > > >
> > >
> > > ok I see. So if I follow your proposal in my case it would be something like:
> > > serdes-sgmii-tx-amplitude-millivolt to start with ?
> > >
> > > I can do that. Andrew what do you think?
> >
> > Or maybe two properties:
> > serdes-tx-amplitude-millivolt = <700 1000 1100>;
> > serdes-tx-amplitude-modes = "sgmii", "2500base-x", "10gbase-r";
> > ?
> >
> > If
> > serdes-tx-amplitude-modes
> > is omitted, then
> > serdes-tx-amplitude-millivolt
> > should only contain one value, and this is used for all serdes modes.
> >
> > This would be compatible with your change. You only need to define the
> > bidning for now, your code can stay the same - you don't need to add
> > support for multiple values or for the second property now, it can be
> > done later when needed. But the binding should be defined to support
> > those different modes.
>
> 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.
next prev parent reply other threads:[~2021-12-08 16:41 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 [this message]
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
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=20211208164131.fy2h652sgyvhm7jx@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=holger.brunck@hitachienergy.com \
--cc=kabel@kernel.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 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).