netdev - Re: [PATCH net-next v3 1/7] net: ethtool: pse-pd: Expand C33 PSE status with class, power and extended state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 17 Jun 2024 21:55:25 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Kory Maincent <kory.maincent@...tlin.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Donald Hunter <donald.hunter@...il.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Dent Project <dentproject@...uxfoundation.org>,
	kernel@...gutronix.de, UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next v3 1/7] net: ethtool: pse-pd: Expand C33 PSE
 status with class, power and extended state

On Mon, Jun 17, 2024 at 03:47:12PM +0200, Kory Maincent wrote:
> > According to 33.2.4.7
> > State diagrams we have CLASSIFICATION_EVAL function which evaluates
> > results of classification.
> > In case of class_num_events = 1, we have only tpdc_timer. In case of
> > error, will we get some timer related error?
> > 
> > In case of class_num_events = 2, if i see it correctly, PSE is doing
> > double classification and if results do not match, PSE will go to faul
> > state. See CLASS_EV2->(mr_pd_class_detected != temp_var) case.
> > 
> > Is it what we have here?
> 
> Mmh not really indeed, maybe we can put it in error_condition substate?

I'm not sure how this error can help user, if even we do not understand
what is says. May be map everything what is not clear right not to
unsupported error value. This give us some time to communicate with
vendor and prevent us from making pointless UAPi?

> > The difference between open and underload is probably:
> > - open: Iport = 0, detection state
> > - underload: Iport < Imin (or Ihold?), Iport can be 0. related to powered/MPS
> >   state.
> 
> Should I put it under MPS substate then?

If my understand is correct, then yes. Can you test it? Do you have PD
with adjustable load?

> > May be you will need to contact Microchip directly. Usually it helps :)
> 
> Lets keep it like that for now?

let's map it to unsupported error for now

> > > +enum ethtool_c33_pse_ext_substate_pd_dll_power_type {
> > > +
> > > ETHTOOL_C33_PSE_EXT_SUBSTATE_PD_DLL_POWER_TYPE_NON_802_3AF_AT_DEVICE = 1,
> > > +};  
> > 
> > Here i was potentially wrong. LLDP stage is after power up, and this
> > values was probably set on early stage of signature detection. How can
> > we detect a device which is not conform to the 802.3AF/AT standard? Is
> > it something pre-802.3AF/AT, micorosemi specific vendor specific signature?
> 
> Don't really know.

Same here, if we do not really know what it is, make it unsupported error value

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 |