On Tue, Feb 18, 2025 at 10:26:58AM +0100, Stephan Gerhold wrote: > On Tue, Feb 18, 2025 at 08:54:47AM +0100, Johan Hovold wrote: > > On Fri, Feb 14, 2025 at 09:52:33AM +0100, Johan Hovold wrote: > > > On Thu, Feb 06, 2025 at 11:28:28AM +0200, Abel Vesa wrote: > > > > The Parade PS8830 is a USB4, DisplayPort and Thunderbolt 4 retimer, > > > > controlled over I2C. It usually sits between a USB/DisplayPort PHY > > > > and the Type-C connector, and provides orientation and altmode handling. > > [...] > > > > + /* skip resetting if already configured */ > > > > + if (regmap_test_bits(retimer->regmap, REG_USB_PORT_CONN_STATUS_0, > > > > + CONN_STATUS_0_CONNECTION_PRESENT) == 1) > > > > + return gpiod_direction_output(retimer->reset_gpio, 0); > > > > > > I'm still a little concerned about this. Won't you end up with i2c > > > timeout errors in the logs if the device is held in reset before probe? > > > > You should be able to use i2c_smbus_read_byte() to avoid logging errors > > when the boot firmware has *not* enabled the device. > > FWIW, regmap_test_bits() doesn't seem to print any errors either, so I > don't think switching to i2c_smbus_read_byte() is necessary. Thanks for checking. > Since I was curious, I tried booting the X1E80100 with > 1. One PS8830 instance left as-is > 2. One PS8830 instance changed to invalid I2C address > 3. One PS8830 instance changed to have reset pin asserted via pinctrl > > There are no errors whatsoever, even for the one with invalid I2C > address. In other words, the slightly more concerning part is that the > driver doesn't check that any of the regmap reads/writes actually > succeed. Indeed. > The diff I used for testing is below. (1) prints "skipping reset", (2) > and (3) print "continuing reset". And thanks for confirming. I've found a few more issues that should be addressed so I'm preparing follow-up series. Johan
