Commit graph

13 commits

Author SHA1 Message Date
Nick Ward 30fe8702de drivers: eeprom_emulator: fix compile warning
Fixes compile warning:
drivers/eeprom/eeprom_emulator.c:645:13:
warning: 'rc' may be used uninitialized [-Wmaybe-uninitialized]
  645 |         int rc;

Signed-off-by: Nick Ward <nix.ward@gmail.com>
2023-11-06 23:59:05 +01:00
Henrik Brix Andersen 39bb5cd06a drivers: eeprom: emulator: fix size_t format specifier
Fix the format specifier for logging size_t values.

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2022-11-03 16:38:48 -05:00
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
Kumar Gala 861b14bd2e drivers: eeprom_emulator: Remove dead code
Remove unused PART_DEV_NAME macro.

Signed-off-by: Kumar Gala <galak@kernel.org>
2022-07-14 10:40:07 +02:00
Gerard Marull-Paretas fb60aab245 drivers: migrate includes to <zephyr/...>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 19:58:21 +02:00
Gerard Marull-Paretas f5effdde6c drivers: eeprom: drop DEV_DATA/DEV_CFG usage
Stop using redundant DEV_DATA/DEV_CFG macros and use dev->data and
dev->config instead.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-01-19 18:16:02 +01:00
Gerard Marull-Paretas b7ee4e2951 drivers: eeprom: emulator: use instance based macros
Replace usage of DT_DRV_INST with instance based macros.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2021-12-17 17:30:06 +01:00
Maureen Helm 32b4950c61 drivers: eeprom: Refactor drivers to use shared init priority
Refactors all of the EEPROM drivers to use a shared driver class
initialization priority configuration, CONFIG_EEPROM_INIT_PRIORITY, to
allow configuring EEPROM drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.

The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The
exceptions are at2x and emul drivers which have dependencies on SPI,
I2C, or flash drivers and must therefore initialize later than the
default device priority.

Signed-off-by: Maureen Helm <maureen.helm@intel.com>
2021-11-04 07:33:01 -04:00
Andrzej Puzdrowski f6641d70d5 drivers/eeprom/eeprom_emulator: fix mutex usage with rambuf
In the eeprom read operation, when rambuf was available
mutex was not unlocked after the read. Consequence of that is
that device was blocked after that read for incoming operations.

This commit fixes the issue

Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
2021-07-26 12:27:22 -04:00
Gerard Marull-Paretas 36b8f96ddc drivers: eeprom: remove usage of device_pm_control_nop
device_pm_control_nop is now deprecated in favour of NULL.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2021-04-28 10:55:22 -04:00
Andrzej Puzdrowski bd48673fb5 drivers/eeprom/eeprom_emulator: remove flash_write_protection_set() usage
This patch removes scenario which was testing deprecated
API behaviors. Needed as As flash_write_protection_set() was
deprecated and became no-operation.

Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
2021-03-29 13:43:55 -04:00
Laczen JMS decf521660 drivers: eeprom: add emulated eeprom in flash
Modifications to incorporate latest write to new flash area
Modification to avoid writing garbage to new flash area when compactor
is called during init.
Modifications to allow erase at partition size instead of eeprom
pagesize.
Modifications to better separate rambuf usage from flash usage.
Corrected some errors in compactor

Signed-off-by: Laczen JMS <laczenjms@gmail.com>
2021-02-19 14:06:15 +01:00
Laczen JMS 232272cff8 drivers: eeprom: EEPROM emulation in flash memory
This driver emulates a EEPROM device in flash.

Reworked implementation with modified flash layout.

The emulation represents the EEPROM in flash as a region that is a
direct map of the eeprom data followed by a region where changes to
the eeprom data is stored. Changes are written as address-data
combinations. The size of such a combination is determined by the
flash write block size and the size of the eeprom (required address
space), with a minimum of 4 byte.
The eeprom page needs to be a multiple of the flash page. Multiple
eeprom pages is also so supported and increases the number of writes
that can be performed.

The eeprom size, pagesize and the flash partition used for the eeprom
are defined in the dts. The flash partition should allow at least two
eeprom pages. For fast read access a rambuffer can be enabled for the
eeprom (by setting the option rambuf in the dts).

Signed-off-by: Laczen JMS <laczenjms@gmail.com>
2021-02-19 14:06:15 +01:00