netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: "Köry Maincent" <kory.maincent@bootlin.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: PoE support
Date: Tue, 12 Sep 2023 13:06:37 +0200	[thread overview]
Message-ID: <20230912110637.GI780075@pengutronix.de> (raw)
In-Reply-To: <20230912122655.391e2c86@kmaincent-XPS-13-7390>

Hello Köry,

On Tue, Sep 12, 2023 at 12:26:55PM +0200, Köry Maincent wrote:
> Hello,
> 
> I am working on the PoE support and I am facing few questioning.
> I would like to use the same commands and core as PoDL, but non generic
> development raised questions.
> 
> The admin_state and admin_control are the same therefore I will use the
> ethtool_podl_pse_admin_state enumeration.
> The power detection status have few differences, I thought that adding PoE
> specific states to ethtool_podl_pse_pw_d_status rather than adding a new
> ethtool_pse_pw_d_status enum is the best way to avoid breaking the old API.
> 
> I also would like to remove PoDL reference to ethtool but keep
> "podl-pse-admin-control" command for old compatibility alongside a new
> "pse-admin-control" command.
> 
> What do you think? Do you think of a better way?

By defining UAPI for PoDL/PoE I decided to follow IEEE 802.3
specification as close as possible for following reasons:
- we should be backwards and forwards compatible. IEEE 802.3 is always
  extended, some existing objects and name spaces can be extended
  withing the specification. If we will merge some of them, it may get
  challenging to make it properly again.
- PoDL and PoE have separate attributes and actions withing the specification. 
- If we follow the spec, it is easier to understand for all who need to
  implement or extend related software
- I can imagine some industrial device implementing PoDL/PoE on same
  port. We should be able to see what is actually active.

IMO, it is better not to mix PoDL and PoE name spaces and keep it as
close as possible to the IEEE 802.3.
Same is about ethtool interface. 

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2023-09-12 11:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12 10:26 PoE support Köry Maincent
2023-09-12 11:06 ` Oleksij Rempel [this message]
2023-09-12 13:25   ` Köry Maincent

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=20230912110637.GI780075@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --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 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).