<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/misc/eeprom/at24.c, branch v6.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-08-16T10:46:26+00:00</updated>
<entry>
<title>i2c: Make remove callback return void</title>
<updated>2022-08-16T10:46:26+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2022-08-15T08:02:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed5c2f5fd10dda07263f79f338a512c0f49f76f5'/>
<id>urn:sha1:ed5c2f5fd10dda07263f79f338a512c0f49f76f5</id>
<content type='text'>
The value returned by an i2c driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)

So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.

Reviewed-by: Peter Senna Tschudin &lt;peter.senna@gmail.com&gt;
Reviewed-by: Jeremy Kerr &lt;jk@codeconstruct.com.au&gt;
Reviewed-by: Benjamin Mugnier &lt;benjamin.mugnier@foss.st.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Reviewed-by: Crt Mori &lt;cmo@melexis.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Acked-by: Marek Behún &lt;kabel@kernel.org&gt; # for leds-turris-omnia
Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Petr Machata &lt;petrm@nvidia.com&gt; # for mlxsw
Reviewed-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt; # for surface3_power
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt; # for bmc150-accel-i2c + kxcjk-1013
Reviewed-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt; # for media/* + staging/media/*
Acked-by: Miguel Ojeda &lt;ojeda@kernel.org&gt; # for auxdisplay/ht16k33 + auxdisplay/lcd2s
Reviewed-by: Luca Ceresoli &lt;luca.ceresoli@bootlin.com&gt; # for versaclock5
Reviewed-by: Ajay Gupta &lt;ajayg@nvidia.com&gt; # for ucsi_ccg
Acked-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt; # for iio
Acked-by: Peter Rosin &lt;peda@axentia.se&gt; # for i2c-mux-*, max9860
Acked-by: Adrien Grassein &lt;adrien.grassein@gmail.com&gt; # for lontium-lt8912b
Reviewed-by: Jean Delvare &lt;jdelvare@suse.de&gt; # for hwmon, i2c-core and i2c/muxes
Acked-by: Corey Minyard &lt;cminyard@mvista.com&gt; # for IPMI
Reviewed-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Acked-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Acked-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt; # for drivers/power
Acked-by: Krzysztof Hałasa &lt;khalasa@piap.pl&gt;
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>eeprom: at24: Add support for 24c1025 EEPROM</title>
<updated>2021-12-13T13:42:39+00:00</updated>
<author>
<name>Maxim Kochetkov</name>
<email>fido_max@inbox.ru</email>
</author>
<published>2021-12-10T18:26:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d08aea21c89dc2d302cadb5c2cc5410b6c3395c8'/>
<id>urn:sha1:d08aea21c89dc2d302cadb5c2cc5410b6c3395c8</id>
<content type='text'>
Microchip EEPROM 24xx1025 is like a 24c1024. The only difference
between them is that the I2C address bit used to select between the
two banks is bit 2 for the 1025 and not bit 0 as in the 1024.

Signed-off-by: Maxim Kochetkov &lt;fido_max@inbox.ru&gt;
Signed-off-by: Bartosz Golaszewski &lt;brgl@bgdev.pl&gt;
</content>
</entry>
<entry>
<title>eeprom: at24: remove struct at24_client</title>
<updated>2021-12-01T11:57:06+00:00</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2021-11-28T18:14:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=92e1764787e57417b8890db0f154c0f405548cdd'/>
<id>urn:sha1:92e1764787e57417b8890db0f154c0f405548cdd</id>
<content type='text'>
We use member client only to get a reference to the associated struct
device, via &amp;client-&gt;dev. However we can get the same reference from
the associated regmap, via regmap_get_device(regmap).
Therefore struct at24_client can be removed and replaced with a regmap
pointer.

Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;brgl@bgdev.pl&gt;
</content>
</entry>
<entry>
<title>at24: Support probing while in non-zero ACPI D state</title>
<updated>2021-11-03T18:03:55+00:00</updated>
<author>
<name>Sakari Ailus</name>
<email>sakari.ailus@linux.intel.com</email>
</author>
<published>2021-10-18T12:17:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1e96078e0ae456cda0e02afd42b9a2b3734f45ba'/>
<id>urn:sha1:1e96078e0ae456cda0e02afd42b9a2b3734f45ba</id>
<content type='text'>
In certain use cases (where the chip is part of a camera module, and the
camera module is wired together with a camera privacy LED), powering on
the device during probe is undesirable. Add support for the at24 to
execute probe while being in ACPI D state other than 0 (which means fully
powered on).

Signed-off-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Reviewed-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Acked-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>misc: eeprom: at24: Always append device id even if label property is set.</title>
<updated>2021-07-01T16:49:37+00:00</updated>
<author>
<name>Jérôme Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2021-07-01T15:28:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c36748ac545421d94a5091c754414c0f3664bf10'/>
<id>urn:sha1:c36748ac545421d94a5091c754414c0f3664bf10</id>
<content type='text'>
We need to append device id even if eeprom have a label property set as some
platform can have multiple eeproms with same label and we can not register
each of those with same label. Failing to register those eeproms trigger
cascade failures on such platform (system is no longer working).

This fix regression on such platform introduced with 4e302c3b568e

Reported-by: Alexander Fomichev &lt;fomichev.ru@gmail.com&gt;
Fixes: 4e302c3b568e ("misc: eeprom: at24: fix NVMEM name with custom AT24 device name")
Cc: stable@vger.kernel.org
Signed-off-by: Jérôme Glisse &lt;jglisse@redhat.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
</content>
</entry>
<entry>
<title>misc: eeprom: at24: check suspend status before disable regulator</title>
<updated>2021-05-14T11:50:59+00:00</updated>
<author>
<name>Hsin-Yi Wang</name>
<email>hsinyi@chromium.org</email>
</author>
<published>2021-04-20T13:30:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2962484dfef8dbb7f9059822bc26ce8a04d0e47c'/>
<id>urn:sha1:2962484dfef8dbb7f9059822bc26ce8a04d0e47c</id>
<content type='text'>
cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables
regulator in runtime suspend. If runtime suspend is called before
regulator disable, it will results in regulator unbalanced disabling.

Fixes: cd5676db0574 ("misc: eeprom: at24: support pm_runtime control")
Cc: stable &lt;stable@vger.kernel.org&gt;
Acked-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Signed-off-by: Hsin-Yi Wang &lt;hsinyi@chromium.org&gt;
Link: https://lore.kernel.org/r/20210420133050.377209-1-hsinyi@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: eeprom: at24: fix NVMEM name with custom AT24 device name</title>
<updated>2020-12-04T09:46:36+00:00</updated>
<author>
<name>Diego Santa Cruz</name>
<email>Diego.SantaCruz@spinetix.com</email>
</author>
<published>2020-12-03T21:47:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4e302c3b568eaf2aeebba804c07aba5d921a8c9e'/>
<id>urn:sha1:4e302c3b568eaf2aeebba804c07aba5d921a8c9e</id>
<content type='text'>
When the "label" property is set on the AT24 EEPROM the NVMEM devid is
set to NVMEM_DEVID_NONE, but it is not effective since there is a
leftover line setting it back to NVMEM_DEVID_AUTO a few lines after.

Fixes: 61f764c307f6 ("eeprom: at24: Support custom device names for AT24 EEPROMs")
Signed-off-by: Diego Santa Cruz &lt;Diego.SantaCruz@spinetix.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'i2c/for-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux</title>
<updated>2020-10-21T17:54:05+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-10-21T17:54:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b5df4b5c28b232d1fc0b48660f44668faebb0bcb'/>
<id>urn:sha1:b5df4b5c28b232d1fc0b48660f44668faebb0bcb</id>
<content type='text'>
Pull i2c updates from Wolfram Sang:

 - if a host can be a client, too, the I2C core can now use it to
   emulate SMBus HostNotify support (STM32 and R-Car added this so far)

 - also for client mode, a testunit has been added. It can create rare
   situations on the bus, so host controllers can be tested

 - a binding has been added to mark the bus as "single-master". This
   allows for better timeout detections

 - new driver for Mellanox Bluefield

 - massive refactoring of the Tegra driver

 - EEPROMs recognized by the at24 driver can now have custom names

 - rest is driver updates

* 'i2c/for-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (80 commits)
  Documentation: i2c: add testunit docs to index
  i2c: tegra: Improve driver module description
  i2c: tegra: Clean up whitespaces, newlines and indentation
  i2c: tegra: Clean up and improve comments
  i2c: tegra: Clean up printk messages
  i2c: tegra: Clean up variable names
  i2c: tegra: Improve formatting of variables
  i2c: tegra: Check errors for both positive and negative values
  i2c: tegra: Factor out hardware initialization into separate function
  i2c: tegra: Factor out register polling into separate function
  i2c: tegra: Factor out packet header setup from tegra_i2c_xfer_msg()
  i2c: tegra: Factor out error recovery from tegra_i2c_xfer_msg()
  i2c: tegra: Rename wait/poll functions
  i2c: tegra: Remove "dma" variable from tegra_i2c_xfer_msg()
  i2c: tegra: Remove redundant check in tegra_i2c_issue_bus_clear()
  i2c: tegra: Remove likely/unlikely from the code
  i2c: tegra: Remove outdated barrier()
  i2c: tegra: Clean up variable types
  i2c: tegra: Reorder location of functions in the code
  i2c: tegra: Clean up probe function
  ...
</content>
</entry>
<entry>
<title>eeprom: at24: Support custom device names for AT24 EEPROMs</title>
<updated>2020-09-25T13:33:04+00:00</updated>
<author>
<name>Jon Hunter</name>
<email>jonathanh@nvidia.com</email>
</author>
<published>2020-09-24T13:20:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=61f764c307f6b2079b7af0d4fb7951402b824967'/>
<id>urn:sha1:61f764c307f6b2079b7af0d4fb7951402b824967</id>
<content type='text'>
By using the label property, a more descriptive name can be populated
for AT24 EEPROMs NVMEM device. Update the AT24 driver to check to see
if the label property is present and if so, use this as the name for
NVMEM device. Please note that when the 'label' property is present for
the AT24 EEPROM, we do not want the NVMEM driver to append the 'devid'
to the name and so the nvmem_config.id is initialised to
NVMEM_DEVID_NONE.

Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
</content>
</entry>
<entry>
<title>eeprom: at24: Initialise AT24 NVMEM ID field</title>
<updated>2020-09-24T13:18:46+00:00</updated>
<author>
<name>Jon Hunter</name>
<email>jonathanh@nvidia.com</email>
</author>
<published>2020-09-24T13:18:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f434f9b7afca80e8abfe5d52b20fe34c39dd2c14'/>
<id>urn:sha1:f434f9b7afca80e8abfe5d52b20fe34c39dd2c14</id>
<content type='text'>
The AT24 EEPROM driver does not initialise the 'id' field of the
nvmem_config structure and because the entire structure is not
initialised, it ends up with a random value. This causes the NVMEM
driver to append the device 'devid' value to name of the NVMEM
device. Ideally for I2C devices such as the AT24 that already have a
unique name, we would not bother to append the 'devid'. However, given
that this has always been done for AT24 devices, we cannot remove the
'devid' as this will change the name of the userspace sysfs node for
the NVMEM device. Nonetheless we should ensure that the 'id' field of
the nvmem_config structure is initialised so that there is no chance of
a random value causes problems in the future. Therefore, set the NVMEM
config.id to NVMEM_DEVID_AUTO for AT24 EEPROMs so that the 'devid' is
always appended.

Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
</content>
</entry>
</feed>
