regmap-i2c: add missing MODULE_DESCRIPTION() macro

With ARCH=arm64, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-i2c.o

Add

regmap-i2c: add missing MODULE_DESCRIPTION() macro

With ARCH=arm64, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-i2c.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson <[email protected]>
Link: https://lore.kernel.org/r/20240613-md-arm64-drivers-base-regmap-v1-1-222be554d520@quicinc.com
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap-i2c: Subtract reg size from max_write

Currently, when an adapter defines a max_write_len quirk,
the data will be chunked into data sizes equal to the
max_write_len quirk value. But the paylo

regmap-i2c: Subtract reg size from max_write

Currently, when an adapter defines a max_write_len quirk,
the data will be chunked into data sizes equal to the
max_write_len quirk value. But the payload will be increased by
the size of the register address before transmission. The
resulting value always ends up larger than the limit set
by the quirk.

Avoid this error by setting regmap's max_write to the quirk's
max_write_len minus the number of bytes for the register and
padding. This allows the chunking to work correctly for this
limited case without impacting other use-cases.

Signed-off-by: Jim Wylder <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Account for register length in SMBus I/O limits

The SMBus I2C buses have limits on the size of transfers they can do but
do not factor in the register length meaning we may try to do a trans

regmap: Account for register length in SMBus I/O limits

The SMBus I2C buses have limits on the size of transfers they can do but
do not factor in the register length meaning we may try to do a transfer
longer than our length limit, the core will not take care of this.
Future changes will factor this out into the core but there are a number
of users that assume current behaviour so let's just do something
conservative here.

This does not take account padding bits but practically speaking these
are very rarely if ever used on I2C buses given that they generally run
slowly enough to mean there's no issue.

Cc: [email protected]
Signed-off-by: Mark Brown <[email protected]>
Reviewed-by: Xu Yilun <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap-i2c: Set regmap max raw r/w from quirks

Set regmap raw read/write from i2c quirks max read/write
so regmap_raw_read/write can split the access into chunks

Signed-off-by: Lucas Tanure <tanure

regmap-i2c: Set regmap max raw r/w from quirks

Set regmap raw read/write from i2c quirks max read/write
so regmap_raw_read/write can split the access into chunks

Signed-off-by: Lucas Tanure <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap-i2c: add 16-bit width registers support

This allows to access data with 16-bit width of registers
via i2c SMBus block functions.

The multi-command sequence of the reading function is not saf

regmap-i2c: add 16-bit width registers support

This allows to access data with 16-bit width of registers
via i2c SMBus block functions.

The multi-command sequence of the reading function is not safe
and may read the wrong data from other address if other commands
are sent in-between the SMBus commands in the read function.

Read performance:
32768 bytes (33 kB, 32 KiB) copied, 11.4869 s, 2.9 kB/s
Write performance(with 1-byte page):
32768 bytes (33 kB, 32 KiB) copied, 129.591 s, 0.3 kB/s

The implementation is inspired by below commit
https://patchwork.ozlabs.org/patch/545292/

v2: add more descriptions about the issue that maybe introduced
by this commit

Signed-off-by: AceLan Kao <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap-i2c: constify regmap_bus structures

regmap_bus structures are not changed anywhere. Mark them const.

Signed-off-by: Michał Mirosław <[email protected]>
Link: https://lore.kernel.org/r/

regmap-i2c: constify regmap_bus structures

regmap_bus structures are not changed anywhere. Mark them const.

Signed-off-by: Michał Mirosław <[email protected]>
Link: https://lore.kernel.org/r/85e4141348db00ecf1f2bc5c2ff6ba3de75e8ff4.1578134920.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: add proper SPDX identifiers on files that did not have them.

There were a few files in the regmap code that did not have SPDX
identifiers on them, so fix that up. At the same time, remove t

regmap: add proper SPDX identifiers on files that did not have them.

There were a few files in the regmap code that did not have SPDX
identifiers on them, so fix that up. At the same time, remove the "free
form" text that specified the license of the file, as that is impossible
for any tool to properly parse.

Also, as Mark loves // comment markers, convert all of the headers to be
the same to make things look consistent :)

Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap-i2c: Off by one in regmap_i2c_smbus_i2c_read/write()

The commit message says that we are allowed to read and write up to 32
bytes but the code only allows us to write 31 bytes. In other word

regmap-i2c: Off by one in regmap_i2c_smbus_i2c_read/write()

The commit message says that we are allowed to read and write up to 32
bytes but the code only allows us to write 31 bytes. In other words,
the ">=" should be changed to ">". But this is already checked in
regmap_raw_read()/write() so we can just remove the if statemetents.

Fixes: 29332534e2b6 ("regmap-i2c: Add smbus i2c block support")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap-i2c: Use i2c block command only if register value width is 8 bit

Chips with 16-bit registers don't usually work well with I2C block
commands. For example, neither the LM75 datasheet nor the T

regmap-i2c: Use i2c block command only if register value width is 8 bit

Chips with 16-bit registers don't usually work well with I2C block
commands. For example, neither the LM75 datasheet nor the TMP102 datasheet
mentions block command support, and in fact it does not work for any of
those chips. Also, it is not clear how the block command would handle
16-bit SMBus operations in the fist place, since the data format associated
with those commands is either little endian or big endian, which requires
some kind of conversion to or from host byte order.

Only use i2c block commands if both register and value width is 8 bit.

Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap-i2c: Add smbus i2c block support

This allows to read/write up to 32 bytes of data and is to be prefered
if supported before the register read/write smbus support.

Signed-off-by: Markus Pargm

regmap-i2c: Add smbus i2c block support

This allows to read/write up to 32 bytes of data and is to be prefered
if supported before the register read/write smbus support.

Signed-off-by: Markus Pargmann <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Move documentation to regmap.h

Init functions defined in regmap*.c files are now prefixed with
__, take lockdep key and class parameters, and should not be
called directly: move the document

regmap: Move documentation to regmap.h

Init functions defined in regmap*.c files are now prefixed with
__, take lockdep key and class parameters, and should not be
called directly: move the documentation to regmap.h, where the
macros are defined.

Signed-off-by: Nicolas Boichat <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Use different lockdep class for each regmap init call

Lockdep validator complains about recursive locking and deadlock
when two different regmap instances are called in a nested order.
That

regmap: Use different lockdep class for each regmap init call

Lockdep validator complains about recursive locking and deadlock
when two different regmap instances are called in a nested order.
That happens anytime a regmap read/write call needs to access
another regmap.

This is because, for performance reason, lockdep groups all locks
initialized by the same mutex_init() in the same lock class.
Therefore all regmap mutexes are in the same lock class, leading
to lockdep "nested locking" warnings if a regmap accesses another
regmap.

In general, it is impossible to establish in advance the hierarchy
of regmaps, so we make sure that each regmap init call initializes
its own static lock_class_key. This is done by wrapping all
regmap_init calls into macros.

This also allows us to give meaningful names to the lock_class_key.
For example, in rt5677 case, we have in /proc/lockdep_chains:
irq_context: 0
[ffffffc0018d2198] &dev->mutex
[ffffffc0018d2198] &dev->mutex
[ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock
[ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock
[ffffffc001b95448] &(&base->lock)->rlock

The above would have resulted in a lockdep recursive warning
previously. This is not the case anymore as the lockdep validator
now clearly identifies the 2 regmaps as separate.

Signed-off-by: Nicolas Boichat <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Fix i2c word access when using SMBus access functions

SMBus access functions assume that 16-bit values are formatted as
little endian numbers. The direct i2c access functions in regmap,
howe

regmap: Fix i2c word access when using SMBus access functions

SMBus access functions assume that 16-bit values are formatted as
little endian numbers. The direct i2c access functions in regmap,
however, assume that 16-bit values are formatted as big endian numbers.
As a result, the current code returns different values if an i2c chip's
16-bit registers are accessed through i2c access functions vs. SMBus
access functions.

Use regmap_smbus_read_word_swapped and regmap_smbus_write_word_swapped
for 16-bit SMBus accesses if a chip is configured as REGMAP_ENDIAN_BIG.
If the chip is configured as REGMAP_ENDIAN_LITTLE, keep using
regmap_smbus_write_word_data and regmap_smbus_read_word_data. Otherwise
reject registration if the controller does not support direct i2c accesses.

Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: add DT endianness binding support.

For many drivers which will support rich endianness of Devices
need define DT properties by itself with the binding support.

The endianness using regmap:

regmap: add DT endianness binding support.

For many drivers which will support rich endianness of Devices
need define DT properties by itself with the binding support.

The endianness using regmap:
Index Device Properties if needs bytes-swap,
or just ignore it
-------------------------------------------------------------
1 BE 'big-endian'
2 LE 'little-endian'

The properties include all the register values and the buffers.
And these properties are very usful for the MMIO devices:

Such as: a memory-mapped device, on one SoC is in BE mode, while
in another SoC will be in LE mode, and the CPU will always in LE
mode.

For the first case, we must use cpu_to_be32/be32_to_cpu for
32-bit registers accessing, so the 'big-endian' property is needed.

For the second case, we can just ignore the bytes-swap
functions like cpu_to_le32/le32_to_cpu, so the 'little-endian'
property could be abscent.

And vice versa...

Signed-off-by: Xiubo Li <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: i2c: fallback to SMBus if the adapter does not support standard I2C

Some I2C adapters are only compatible with the SMBus protocol and do not
support standard I2C transfers.

Fallback to SMBu

regmap: i2c: fallback to SMBus if the adapter does not support standard I2C

Some I2C adapters are only compatible with the SMBus protocol and do not
support standard I2C transfers.

Fallback to SMBus transfers if we encounter such kind of adapters.
The transfer type is chosen according to the val_bits field in the regmap
config.

Signed-off-by: Boris BREZILLON <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

drivers/base: delete non-required instances of include <linux/init.h>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just

drivers/base: delete non-required instances of include <linux/init.h>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

Cc: Len Brown <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING

Since there are uses for I2C_M_NOSTART which are much more sensible and
standard than most of the protocol mangling functionality (

i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING

Since there are uses for I2C_M_NOSTART which are much more sensible and
standard than most of the protocol mangling functionality (the main one
being gather writes to devices where something like a register address
needs to be inserted before a block of data) create a new I2C_FUNC_NOSTART
for this feature and update all the users to use it.

Also strengthen the disrecommendation of the protocol mangling while we're
at it.

In the case of regmap-i2c we remove the requirement for mangling as
I2C_M_NOSTART is the only mangling feature which is being used.

Signed-off-by: Mark Brown <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>

show more ...

regmap: introduce explicit bus_context for bus callbacks

The only context needed by I2C and SPI bus definitions is the device
itself; this can be converted to an i2c_client or spi_device in order
to

regmap: introduce explicit bus_context for bus callbacks

The only context needed by I2C and SPI bus definitions is the device
itself; this can be converted to an i2c_client or spi_device in order
to perform IO on the device. However, other bus types may need more
context in order to perform IO. Enable this by having regmap_init accept
a bus_context parameter, and pass this to all bus callbacks. The
existing callbacks simply pass the struct device here. Future bus types
may pass something else.

Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: introduce explicit bus_context for bus callbacks

The only context needed by I2C and SPI bus definitions is the device
itself; this can be converted to an i2c_client or spi_device in order
to

regmap: introduce explicit bus_context for bus callbacks

The only context needed by I2C and SPI bus definitions is the device
itself; this can be converted to an i2c_client or spi_device in order
to perform IO on the device. However, other bus types may need more
context in order to perform IO. Enable this by having regmap_init accept
a bus_context parameter, and pass this to all bus callbacks. The
existing callbacks simply pass the struct device here. Future bus types
may pass something else.

Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Implement managed regmap_init()

Save error handling and unwinding code in drivers by providing managed
versions of the regmap init functions, simplifying usage.

Signed-off-by: Mark Brown <b

regmap: Implement managed regmap_init()

Save error handling and unwinding code in drivers by providing managed
versions of the regmap init functions, simplifying usage.

Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Remove redundant owner field from the bus type struct

No longer used as users link directly with the bus types so the core
module infrastructure does refcounting for us.

Signed-off-by: Mark

regmap: Remove redundant owner field from the bus type struct

No longer used as users link directly with the bus types so the core
module infrastructure does refcounting for us.

Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Specify a module license

CONFIG_REGMAP_I2C/SPI are set to m when selected by a tristate config
option that's set to m. The regmap modules don't specify a license, so
fail to link to regmap_i

regmap: Specify a module license

CONFIG_REGMAP_I2C/SPI are set to m when selected by a tristate config
option that's set to m. The regmap modules don't specify a license, so
fail to link to regmap_init at load time, since that is EXPORT_SYMBOL_GPL.
Fix this by specifying a license for the regmap modules.

Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Remove unused type and list fields from bus interface

We no longer enumerate the bus types, we rely on the driver telling us
this on init.

Signed-off-by: Mark Brown <[email protected]

regmap: Remove unused type and list fields from bus interface

We no longer enumerate the bus types, we rely on the driver telling us
this on init.

Signed-off-by: Mark Brown <[email protected]>

show more ...

regmap: Add I2C bus support

Signed-off-by: Mark Brown <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Acked-by: Grant Likely

regmap: Add I2C bus support

Signed-off-by: Mark Brown <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Acked-by: Grant Likely <[email protected]>

show more ...