Le Thu, 10 Jul 2025 15:32:11 +0000,
Piotr Kubik [off-list ref] a écrit :

On 7/7/25 15:17, Kory Maincent wrote:

quoted

...

  

quoted

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