PoE support

PoE support

[Köry Maincent]

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?

Köry

Re: PoE support

[Oleksij Rempel]

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 |

Re: PoE support

[Köry Maincent]

On Tue, 12 Sep 2023 13:06:37 +0200
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> > 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. 

Ok, it will add more code duplication but indeed, it will be more flexible
for future standard evolution. I will go for this solution then.