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

...

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.


Thanks, 
/Piotr