linux-kernel - Re: [EXTERNAL]Re: [PATCH net-next v4 2/2] net: pse-pd: Add Si3474 PSE controller driver

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] [day] [month] [year] [list]

Message-ID: <20250710200557.41e5876a@kmaincent-XPS-13-7390>
Date: Thu, 10 Jul 2025 20:05:57 +0200
From: Kory Maincent <kory.maincent@...tlin.com>
To: Piotr Kubik <piotr.kubik@...ran.com>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [EXTERNAL]Re: [PATCH net-next v4 2/2] net: pse-pd: Add Si3474
 PSE controller driver

Le Thu, 10 Jul 2025 15:32:11 +0000,
Piotr Kubik <piotr.kubik@...ran.com> a écrit :

> On 7/7/25 15:17, Kory Maincent wrote:
> > ...
> > 
> >   
> >> +
> >> +static int si3474_pi_enable(struct pse_controller_dev *pcdev, int id)
> >> +{
> >> +	struct si3474_priv *priv = to_si3474_priv(pcdev);
> >> +	struct i2c_client *client;
> >> +	u8 chan0, chan1;
> >> +	u8 val = 0;
> >> +	s32 ret;
> >> +
> >> +	if (id >= SI3474_MAX_CHANS)
> >> +		return -ERANGE;
> >> +
> >> +	si3474_get_channels(priv, id, &chan0, &chan1);
> >> +	client = si3474_get_chan_client(priv, chan0);
> >> +
> >> +	/* Release PI from shutdown */
> >> +	ret = i2c_smbus_read_byte_data(client, PORT_MODE_REG);
> >> +	if (ret < 0)
> >> +		return ret;
> >> +
> >> +	val = (u8)ret;
> >> +	val |= CHAN_MASK(chan0);
> >> +	val |= CHAN_MASK(chan1);
> >> +
> >> +	ret = i2c_smbus_write_byte_data(client, PORT_MODE_REG, val);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	/* DETECT_CLASS_ENABLE must be set when using AUTO mode,
> >> +	 * otherwise PI does not power up - datasheet section 2.10.2
> >> +	 */  
> > 
> > What happen in a PD disconnection case? According to the datasheet it simply
> > raise a disconnection interrupt and disconnect the power with a
> > DISCONNECT_PCUT_FAULT fault. But it is not clear if it goes back to the
> > detection + classification process. If it is not the case you will face the
> > same issue I did and will need to deal with the interrupt and the
> > disconnection management.
> > 
> > Could you try to enable a port, plug a PD then disconnect it and plug
> > another PD which belong to another power class. Finally read the class
> > detected to verify that the class detected have changed.  
> 
> Yes, I did this test, also with disabling/enabling PI in between PD
> disconnects/connects. Each time class was detected correctly (class4 vs 3 in
> my case). I checked also class results when no PD was connected or PI was
> disabled, all OK.

Ok great! It behaves differently than the TPS23881, so there is no need to deal
with the disconnection management. That wasn't clear at first sight.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com