i2c: mux: Remove class argument from i2c_mux_add_adapter()

99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
instantiation") removed the last call to i2c_mux_add_adapter() with a

i2c: mux: Remove class argument from i2c_mux_add_adapter()

99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
instantiation") removed the last call to i2c_mux_add_adapter() with a
non-null class argument. Therefore the class argument can be removed.

Note: Class-based device instantiation is a legacy mechanism which
shouldn't be used in new code, so we can rule out that this argument
may be needed again in the future.

Signed-off-by: Heiner Kallweit <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Acked-by: Peter Rosin <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Acked-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

i2c: mux: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variabl

i2c: mux: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
int stuff;
struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Peter Rosin <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 1

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 1

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
51 franklin street fifth floor boston ma 02110 1301 usa

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option [no]_[pad]_[ctrl] any later version this program is
distributed in the hope that it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details you should have received a copy of the gnu general
public license along with this program if not write to the free
software foundation inc 51 franklin street fifth floor boston ma
02110 1301 usa

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 176 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Jilayne Lovejoy <[email protected]>
Reviewed-by: Steve Winslow <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

i2c: mux: add support for 'i2c-mux', 'i2c-arb' and 'i2c-gate' DT subnodes

Backwards compatibility is preserved; the subnodes are in practice
optional.

However, the mux core needs to know what subno

i2c: mux: add support for 'i2c-mux', 'i2c-arb' and 'i2c-gate' DT subnodes

Backwards compatibility is preserved; the subnodes are in practice
optional.

However, the mux core needs to know what subnode it should examine, so add
a couple of new flags for i2c_mux_alloc for this purpose.

The rule is that if the mux core finds a 'reg' property in the appropriate
subnode, e.g. if 'reg' exists in the 'i2c-mux' subnode, then the mux core
will assume that this is an old style entry and not an i2c-mux subnode
(correspondingly for arbitrators and gates with 'i2c-arb' and 'i2c-gate').

Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Peter Rosin <[email protected]>

show more ...

i2c: mux: relax locking of the top i2c adapter during mux-locked muxing

With a i2c topology like the following

GPIO ---| ------ BAT1
| v /
I2

i2c: mux: relax locking of the top i2c adapter during mux-locked muxing

With a i2c topology like the following

GPIO ---| ------ BAT1
| v /
I2C -----+----------+---- MUX
| \
EEPROM ------ BAT2

there is a locking problem with the GPIO controller since it is a client
on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1)
will lock the whole i2c bus prior to attempting to switch the mux to the
correct i2c segment. In the above case, the GPIO device is an I/O expander
with an i2c interface, and since the GPIO subsystem knows nothing (and
rightfully so) about the lockless needs of the i2c mux code, this results
in a deadlock when the GPIO driver issues i2c transfers to modify the
mux.

So, observing that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect mux client operation. The mux itself needs to be
locked, so transfers to clients behind the mux are serialized, and the mux
needs to be stable during all i2c traffic (otherwise individual mux slave
segments might see garbage, or worse).

Introduce this new locking concept as "mux-locked" muxes, and call the
pre-existing mux locking scheme "parent-locked".

Modify the i2c mux locking so that muxes that are "mux-locked" locks only
the muxes on the parent adapter instead of the whole i2c bus when there is
a transfer to the slave side of the mux. This lock serializes transfers to
the slave side of the muxes on the parent adapter.

Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved
gpio/pinctrl devices have a parent that is an i2c adapter in the same
adapter tree that is muxed, and request a "mux-locked mux" if that is the
case.

Modify the select-transfer-deselect code for "mux-locked" muxes so
that each of the select-transfer-deselect ops locks the mux parent
adapter individually.

Signed-off-by: Peter Rosin <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

i2c: mux: drop old unused i2c-mux api

All i2c mux users are using an explicit i2c mux core, drop support
for implicit i2c mux cores.

Signed-off-by: Peter Rosin <[email protected]>
Signed-off-by: Wolf

i2c: mux: drop old unused i2c-mux api

All i2c mux users are using an explicit i2c mux core, drop support
for implicit i2c mux cores.

Signed-off-by: Peter Rosin <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

i2c: mux: add common data for every i2c-mux instance

All i2c-muxes have a parent adapter and one or many child
adapters. A mux also has some means of selection. Previously,
this was stored per child

i2c: mux: add common data for every i2c-mux instance

All i2c-muxes have a parent adapter and one or many child
adapters. A mux also has some means of selection. Previously,
this was stored per child adapter, but it is only needed
to keep track of this per mux.

Add an i2c mux core, that keeps track of this consistently.

Also add some glue for users of the old interface, which will
create one implicit mux core per child adapter.

Signed-off-by: Peter Rosin <[email protected]>
Tested-by: Antti Palosaari <[email protected]>
Tested-by: Crestez Dan Leonard <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

i2c: Make the return type of i2c_del_mux_adapter() void

i2c_del_mux_adapter always returns 0 and none of it current users check its
return value anyway. It is also an essential requirement of the Li

i2c: Make the return type of i2c_del_mux_adapter() void

i2c_del_mux_adapter always returns 0 and none of it current users check its
return value anyway. It is also an essential requirement of the Linux device
driver model, that functions which may be called from a device's remove callback
to free resources provided by the device, are not allowed to fail. This is the
case for i2c_del_mux_adapter(), so make its return type void to make the
fact that it won't fail explicit.

Signed-off-by: Lars-Peter Clausen <[email protected]>
Reviewed-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

i2c-mux: Add support for device auto-detection

Let I2C bus segments behind multiplexers have a class. This allows for
device auto-detection on these segments. As long as parent segments
don't share

i2c-mux: Add support for device auto-detection

Let I2C bus segments behind multiplexers have a class. This allows for
device auto-detection on these segments. As long as parent segments
don't share the same class, it should be fine.

I implemented support in drivers i2c-mux-gpio and i2c-mux-pca954x. I
left i2c-mux-pca9541 and i2c-mux-pinctrl alone for the moment as I
don't know if this feature makes sense for the use cases of these
drivers.

Signed-off-by: Jean Delvare <[email protected]>
Cc: Peter Korsgaard <[email protected]>
Cc: David Daney <[email protected]>
Cc: Michael Lawnick <[email protected]>
Cc: Rodolfo Giometti <[email protected]>

show more ...

i2c: Add a struct device * parameter to i2c_add_mux_adapter()

And adjust all callers.

The new device parameter is used in the next patch to initialize the
mux's of_node so that its children may be

i2c: Add a struct device * parameter to i2c_add_mux_adapter()

And adjust all callers.

The new device parameter is used in the next patch to initialize the
mux's of_node so that its children may be automatically populated.

Signed-off-by: David Daney <[email protected]>
Tested-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

i2c: Update the FSF address

Signed-off-by: Jean Delvare <[email protected]>

i2c: Multiplexed I2C bus core support

Add multiplexed bus core support. I2C multiplexer and switches
like pca954x get instantiated as new adapters per port.

Signed-off-by: Michael Lawnick <ml.lawni

i2c: Multiplexed I2C bus core support

Add multiplexed bus core support. I2C multiplexer and switches
like pca954x get instantiated as new adapters per port.

Signed-off-by: Michael Lawnick <[email protected]>
Acked-by: Rodolfo Giometti <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>

show more ...