On 2019-02-25 16:51, Robert Shearman wrote: > From: Robert Shearman <robert.shearman@xxxxxxx> > > The behaviour, by default, to not deselect after each transfer is > unsafe when there is a device with an address that conflicts with > another device on another pca954x mux on the same parent bus, and it > may not be convenient to use devicetree to set the deselect mux, > e.g. when running on x86_64 when ACPI is used to discover most of the > device hierarchy. > > Therefore, provide the ability to set the idle state behaviour using a > new sysfs file, idle_state as a complement to the method of > instantiating the device via sysfs. The possible behaviours are > disconnect, i.e. to deselect all channels from the mux, as-is (the > default), i.e. leave the last channel selected, and set a > predetermined channel. > > The current behaviour of leaving the channel as-is after each > transaction is preserved. > > Signed-off-by: Robert Shearman <robert.shearman@xxxxxxx> > --- > .../ABI/testing/sysfs-bus-i2c-devices-pca954x | 20 +++++ Should not ABI/... patches go to someone? Who? Did you use get_maintainer.pl? I think you should at least include the main kernel list? Maybe someone filters messages looking for ABI changes? > drivers/i2c/muxes/i2c-mux-pca954x.c | 84 +++++++++++++++++-- > 2 files changed, 97 insertions(+), 7 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-pca954x > > diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-pca954x b/Documentation/ABI/testing/sysfs-bus-i2c-devices-pca954x > new file mode 100644 > index 000000000000..809545a5f9e4 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-pca954x > @@ -0,0 +1,20 @@ > +What: /sys/bus/i2c/.../idle_state > +Date: January 2019 > +KernelVersion: 5.2 > +Contact: Robert Shearman <robert.shearman@xxxxxxx> > +Description: > + Value that can be written to control the behaviour of > + the multiplexer on idle. Possible values: > + -2 - disconnect on idle, i.e. deselect the last used > + channel, which is useful when there is a device > + with an address that conflicts with another > + device on another pca954x mux on the same parent Nit: It doesn't need to be a PCA954x mux, it could be any mux. Cheers, Peter
