IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
[ Upstream commit 71d46f1ff2212ced4852c7e77c5176382a1bdcec ]
The simple_write_to_buffer() function will return positive/success if it
is able to write a single byte anywhere within the buffer. However that
potentially leaves a lot of the buffer uninitialized.
In this code it's better to return 0 if the offset is non-zero. This
code is not written to support partial writes. And then return -EFAULT
if the buffer is not completely initialized.
Fixes: cfad6425382e ("eeprom: Add IDT 89HPESx EEPROM/CSR driver")
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/Ysg1Pu/nzSMe3r1q@kili
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c0689e46be23160d925dca95dfc411f1a0462708 upstream.
Commit effa453168a7 ("i2c: i801: Don't silently correct invalid transfer
size") revealed that ee1004_eeprom_read() did not properly limit how
many bytes to read at once.
In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the
length to read as an u8. If count == 256 after taking into account the
offset and page boundary, the cast to u8 overflows. And this is common
when user space tries to read the entire EEPROM at once.
To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already
the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows.
Fixes: effa453168a7 ("i2c: i801: Don't silently correct invalid transfer size")
Cc: stable@vger.kernel.org
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jonas Malaco <jonas@protocubo.io>
Link: https://lore.kernel.org/r/20220203165024.47767-1-jonas@protocubo.io
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 5b557298d7d09cce04e0565a535fbca63661724a ]
The commit f60e7074902a ("misc: at25: Make use of device property API")
made a good job by enabling the driver for non-OF platforms, but the
recent commit 604288bc6196 ("nvmem: eeprom: at25: fix type compiler warnings")
brought that back.
Restore greatness of the driver once again.
Fixes: eab61fb1cc2e ("nvmem: eeprom: at25: fram discovery simplification")
Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support")
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125212729.86585-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9a626577398c24ecab63c0a684436c8928092367 upstream.
Commit fd307a4ad332 ("nvmem: prepare basics for FRAM support") added
support for FRAM devices such as the Cypress FM25V. During testing, it
was found that the FRAM detects properly, however reads and writes fail.
Upon further investigation, two problem were found in at25_probe() routine.
1) In the case of an FRAM device without platform data, eg.
fram == true && spi->dev.platform_data == NULL
the stack local variable "struct spi_eeprom chip" is not initialized
fully, prior to being copied into at25->chip. The chip.flags field in
particular can cause problems.
2) The byte_len of FRAM is computed from its ID register, and is stored
into the stack local "struct spi_eeprom chip" structure. This happens
after the same structure has been copied into at25->chip. As a result,
at25->chip.byte_len does not contain the correct length of the device.
In turn this can cause checks at beginning of at25_ee_read() to fail
(or equally, it could allow reads beyond the end of the device length).
Fix both of these issues by eliminating the on-stack struct spi_eeprom.
Instead use the one inside at25_data structure, which starts of zeroed.
Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Link: https://lore.kernel.org/r/20211108181627.645638-1-ralph.siemsen@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The newly added SPI device ID table does not work because the
entry is incorrectly copied from the OF device table.
During build testing, this shows as a compile failure when building
it as a loadable module:
drivers/misc/eeprom/eeprom_93xx46.c:424:1: error: redefinition of '__mod_of__eeprom_93xx46_of_table_device_table'
MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
Change the entry to refer to the correct symbol.
Fixes: 137879f7ff23 ("eeprom: 93xx46: Add SPI device ID table")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211014153730.3821376-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding a SPI device ID table.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210922184048.34770-1-broonie@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210923172453.4921-1-broonie@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <fomichev.ru@gmail.com>
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 <jglisse@redhat.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Fixes:
drivers/misc/eeprom/at25.c:181:28: warning: field width should have type 'int', but argument has type 'unsigned long'
drivers/misc/eeprom/at25.c:386:13: warning: cast to smaller integer type 'int' from 'const void *'
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jiri Prchal <jiri.prchal@aksignal.cz>
Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support")
Link: https://lore.kernel.org/r/20210611142706.27336-1-jiri.prchal@aksignal.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Added enum and string for FRAM (ferroelectric RAM) to expose it as file
named "fram".
Added documentation of sysfs file.
Signed-off-by: Jiri Prchal <jiri.prchal@aksignal.cz>
Link: https://lore.kernel.org/r/20210611094601.95131-2-jiri.prchal@aksignal.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When iterating over child firmware nodes restore printing the name of ones
that are not supported.
While at it, refactor loop body to clearly show that we stop at the first match.
Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing")
Cc: Huy Duong <qhuyduong@hotmail.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210607221757.81465-2-andy.shevchenko@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
device_get_next_child_node() bumps a reference counting of a returned variable.
We have to balance it whenever we return to the caller.
Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing")
Cc: Huy Duong <qhuyduong@hotmail.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210607221757.81465-1-andy.shevchenko@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moving the call to ee1004_set_current_page() to ee1004_eeprom_read()
allows to simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/2829a131-51e3-8865-462a-564080158b0b@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The value of ee1004_current_page applies to all SPD eeproms connected
to the adapter. Therefore it's sufficient if we set ee1004_current_page
when the first device is added.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/b9240e58-08bb-3d71-7a9c-9a323b470ab6@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c_new_dummy_device() calls i2c_new_client_device() that complains
if it fails to create the device. Therefore we don't have to emit an
error message in case of failure. In addition ensure that
ee1004_set_page is only set if creating the device succeeded.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/d38df5ac-6ecb-7d5f-b5c3-39bfc6a1e8a1@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We have to read 512 bytes only, therefore read performance isn't really
a concern. Don't bother the user if i2c block read isn't supported.
For i2c_smbus_read_i2c_block_data_or_emulated() to work it's sufficient
if I2C_FUNC_SMBUS_READ_I2C_BLOCK or I2C_FUNC_SMBUS_READ_BYTE_DATA is
supported. Therefore remove the check for I2C_FUNC_SMBUS_READ_WORD_DATA.
In addition check for I2C_FUNC_SMBUS_WRITE_BYTE (included in
I2C_FUNC_SMBUS_BYTE) which is needed for setting the page.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/840c668e-6310-e933-e50e-5abeaecfb39c@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c_smbus_read_i2c_block_data_or_emulated() checks its length argument,
so we don't have to do it. In addition remove the unlikely hint from
the checks, we do i2c reads and therefore are in a slow path.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/eb2a8bff-43ec-c763-a417-9d741e6f0034@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sysfs_kf_bin_read() checks this for us already. In addition
the function works correctly also w/o this check.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/33889bff-3614-4b73-5010-701635e1edab@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of creating/removing the attribute ourselves, just declare the
attribute and let the device core handle it. This allows to simplify
the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/8a6c77f2-f84a-311b-c2b9-21798f690e4d@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <stable@vger.kernel.org>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Link: https://lore.kernel.org/r/20210420133050.377209-1-hsinyi@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These two devices have respectively 2048 and 4096 bits of storage,
compared to 1024 for the 93c46.
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Link: https://lore.kernel.org/r/20210511210727.24895-3-linkmauve@linkmauve.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This avoids using magic numbers based on the length of an address or a
command, while we only want to differentiate between 8-bit and 16-bit.
The driver was previously wrapping around the offset in the write
operation, this now returns -EINVAL instead (but should never happen in
the first place).
If two pointer indirections are too many, we could move the flags to the
main struct instead, but I doubt it’s going to make any sensible
difference on any hardware.
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Link: https://lore.kernel.org/r/20210511210727.24895-2-linkmauve@linkmauve.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A dummy zero bit is sent preceding the data during a read transfer by the
Microchip 93LC46B eeprom (section 2.7 of[1]). This results in right shift
of data during a read. In order to ignore this bit a quirk can be added to
send an extra zero bit after the read address.
Add a quirk to ignore the zero bit sent before data by adding a zero bit
after the read address.
[1] - https://www.mouser.com/datasheet/2/268/20001749K-277859.pdf
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20210105105817.17644-3-a-govindraju@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Module alias "spi:93xx46" is used by non device tree users like
drivers/misc/eeprom/digsy_mtc_eeprom.c and removing it will
break support for them.
Fix this by adding back the module alias "spi:93xx46".
Fixes: 13613a2246bf ("misc: eeprom_93xx46: Fix module alias to enable module autoprobe")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20210113051253.15061-1-a-govindraju@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add module alias to enable autoprobe for microchip 93LC46B eeprom by using
/sys/class/.../spi1.0/modalias content.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20210107163957.28664-3-a-govindraju@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix module autoprobe by correcting module alias to match the string from
/sys/class/.../spi1.0/modalias content.
Fixes: 06b4501e88ad ("misc/eeprom: add driver for microwire 93xx46 EEPROMs")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20210107163957.28664-2-a-govindraju@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here is the big char/misc driver update for 5.11-rc1.
Continuing the tradition of previous -rc1 pulls, there seems to be more
and more tiny driver subsystems flowing through this tree.
Lots of different things, all of which have been in linux-next for a
while with no reported issues:
- extcon driver updates
- habannalab driver updates
- mei driver updates
- uio driver updates
- binder fixes and features added
- soundwire driver updates
- mhi bus driver updates
- phy driver updates
- coresight driver updates
- fpga driver updates
- speakup driver updates
- slimbus driver updates
- various small char and misc driver updates
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCX9iDZA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylRMACgqxKS2CUcY8tPnR5weHEsbz6O+KAAn3BtEFnK
7V9EnSuZe4L1jNOHOB5V
=xzHh
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char / misc driver updates from Greg KH:
"Here is the big char/misc driver update for 5.11-rc1.
Continuing the tradition of previous -rc1 pulls, there seems to be
more and more tiny driver subsystems flowing through this tree.
Lots of different things, all of which have been in linux-next for a
while with no reported issues:
- extcon driver updates
- habannalab driver updates
- mei driver updates
- uio driver updates
- binder fixes and features added
- soundwire driver updates
- mhi bus driver updates
- phy driver updates
- coresight driver updates
- fpga driver updates
- speakup driver updates
- slimbus driver updates
- various small char and misc driver updates"
* tag 'char-misc-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (305 commits)
extcon: max77693: Fix modalias string
extcon: fsa9480: Support TI TSU6111 variant
extcon: fsa9480: Rewrite bindings in YAML and extend
dt-bindings: extcon: add binding for TUSB320
extcon: Add driver for TI TUSB320
slimbus: qcom: fix potential NULL dereference in qcom_slim_prg_slew()
siox: Make remove callback return void
siox: Use bus_type functions for probe, remove and shutdown
spmi: Add driver shutdown support
spmi: fix some coding style issues at the spmi core
spmi: get rid of a warning when built with W=1
uio: uio_hv_generic: use devm_kzalloc() for private data alloc
uio: uio_fsl_elbc_gpcm: use device-managed allocators
uio: uio_aec: use devm_kzalloc() for uio_info object
uio: uio_cif: use devm_kzalloc() for uio_info object
uio: uio_netx: use devm_kzalloc() for or uio_info object
uio: uio_mf624: use devm_kzalloc() for uio_info object
uio: uio_sercos3: use device-managed functions for simple allocs
uio: uio_dmem_genirq: finalize conversion of probe to devm_ handlers
uio: uio_dmem_genirq: convert simple allocations to device-managed
...
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 <Diego.SantaCruz@spinetix.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
To save the interested reader some time, add examples of AT25 part
numbers that correspond to EEPROMs rather than flashes.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20201107133337.1066271-1-j.neuschaefer@gmx.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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
...
- add support for masking sensitive data in VAIO EEPROMs
- set the nvmem TYPE to NVMEM_TYPE_EEPROM
- add support for the new 'label' property
- set the nvmem ID to NVMEM_DEVID_AUTO by default (for backward
compatibility) or to NVMEM_DEVID_NONE if label is defined
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAl9t8ecACgkQEacuoBRx
13KQCQ/6A7ijeBaBBHniisx3vcZQiYXGqvjQ/kvbF32mi4CWzfeC7QyWSpbhzVpY
ZpuR6ER85gUOKhSHg6g/3iT2Yg3reZF2Hea27sH00TKJUh+BPCX+wZAdQ00My6AB
gY3DnbDf6KRrjsFCYKbQ7C9z1c73diGXk6oHirpuUJMQ21pkiTvcE67iPI/m0gsn
c5CvOz9V4fXeV/RwEPt1VKEOxf+HoRablOYEM2weK2xLVAdFgI4+pKpzAYkZoqsb
PLM0bPQUf/5wVe+W56JWWMBSWUA7eWj4suMCsZG0Jjgq53r5oXALcI18snv8M5mh
dHZZ1+mYwLQ+wUQ2ARPGUL66sk6/eGqFVJxaHjTQrSo7kjQkUHTtelH1MdmC78pe
qFQOWkTSF11sxmAjnU17eUJKJWUgyGiuDBAE6aQa3sCaShyN/tkSDCcGfI8e5lSw
FWqtTNNGHE9JiMlSGMOjwpzwae3K6+r62TPmr+YpvQpwYFhXLwMF2E+WlS29SrpP
2OaJkIaKNzVkmQuwGjXSBxE2ftFH80xj5GtfZ+w6eEvT6ZxWfx9GPaK3hWxwmeQp
krd77IuTKCdgmKLQmZc5KWANT5NT6NKgkDSHq8iDKGdP+ne8jMbxyu1vBPdct1SO
gHFdcowKQPoxarS6yhMwPd6ckisDqBy/eJ/OankrEfQAFdRBVVw=
=KexW
-----END PGP SIGNATURE-----
Merge tag 'at24-updates-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-5.10
at24 updates for v5.10
- add support for masking sensitive data in VAIO EEPROMs
- set the nvmem TYPE to NVMEM_TYPE_EEPROM
- add support for the new 'label' property
- set the nvmem ID to NVMEM_DEVID_AUTO by default (for backward
compatibility) or to NVMEM_DEVID_NONE if label is defined
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 <jonathanh@nvidia.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <jonathanh@nvidia.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Slightly easier to read.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Set type as NVMEM_TYPE_EEPROM to expose this info via
sysfs:
$ cat /sys/bus/nvmem/devices/{DEVICE}/type
EEPROM
Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
Link: https://lore.kernel.org/r/20200916170933.20302-4-vadym.kochan@plvision.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Set type as NVMEM_TYPE_EEPROM to expose this info via
sysfs:
$ cat /sys/bus/nvmem/devices/{DEVICE}/type
EEPROM
Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
Link: https://lore.kernel.org/r/20200916170933.20302-3-vadym.kochan@plvision.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
