On 4/9/20 8:30 AM, Robert Hancock wrote: > On 2020-04-09 9:16 a.m., Guenter Roeck wrote: >> Hi Michal, >> >> On 4/9/20 7:29 AM, Michal Simek wrote: >> [ ... ] >>> >>> Just to let you know issue is with i2c driver. Here is my output for the >>> record. >>> >> Thanks a lot for the update. >> >>> irps5401-i2c-3-43 >>> Adapter: i2c-0-mux (chan_id 2) >>> vin1: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>> vin2: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>> vin3: 11.56 V (min = +9.00 V, crit max = +14.00 V) >>> vin4: N/A >> >> This is interesting; it means that the rail is not active (?) or >> not supported, or maybe even that the driver has a bug. The second >> chip reports a value here, so I guess the rail is inactive. >> If possible, it would be desirable to detect this during probe >> and not try to report values for this rail. It would be great if >> you can find the time to figure out what is going on. > > I would assume that either that rail is not used in that board design and was disabled in the non-volatile config on the chip, or alternately the chip allows combining outputs C and D (i.e. 3 and 4) into a single output in which case only one will report valid data. Not sure offhand if there is a way to detect those cases from the PMBus interface at probe time. > I think it may be the output disable register (0x38). One would have to know the i2c address, read the register, and set page bits accordingly. Overall, I am not sure if it is worth the trouble. Maybe we should just just add a note to the driver documentation. Thanks, Guenter
