Hi Peter,
On 22/01/2019 08:41, Peter Rosin wrote:
Hi Robert,
Thanks, for your patches.
On 2019-01-21 17:47, Robert Shearman wrote:
From: Robert Shearman <robert.shearman@xxxxxxx>
The behaviour, by default, to not deselect after each transfer is
not safe/correct when there is a device with an address that conflicts
with another device either on the parent bus, or on another pca954x
mux on the same parent bus.
Right. The current way might not be the safest, but the way I see it,
this ship has sailed a long time ago. It might take quite a while
before someone reports a regression, but when that happens and we
need to revisit or even revert this, things will get ugly.
Also, doubling or even tripling the I2C traffic (most I2C xfers
are small) for unsuspecting users with more normal I2C setups
(w/o multiple muxes) just to accommodate the more complexes cases
is arguably not the correct balance.
Ok, thanks for considering the changes. Would a device-level sysfs
toggle or module parameter approach be more acceptable?
The use case where we are hitting this issue is on an x86_64 ACPI
platform where we desire to use a general purpose kernel, so the
existing devicetree and platform data toggle approaches are not ideal
for us.
Therefore, default to the least surprising mode, where the mux
channels are deselected after each transaction, which is safe in the
face of one or more devices hanging off the mux with addresses that
conflict with other devices on different muxes, or on the parent
Side note, and not that it matters since it's a NACK anyway, but
having an address conflict with the parent bus is not allowed and is
just bad hardware design that simply cannot work reliably, if at all.
Yes, good point.
Thanks,
Rob
