On 4.01.2024 08:58, Miquel Raynal wrote:
r...@kernel.org wrote on Wed, 3 Jan 2024 17:11:29 -0700:
On Thu, Dec 21, 2023 at 06:34:16PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various
From: Rafał Miłecki
Move all generic (NVMEM devices independent) code from NVMEM device
driver to NVMEM layout driver. Then add a simple NVMEM layout code on
top of it.
Thanks to proper layout it's possible to support U-Boot env data stored
on any kind of NVMEM device.
For backward
From: Rafał Miłecki
1. Prefer kzalloc() over kcalloc()
See memory-allocation.rst which says: "to be on the safe side it's
best to use routines that set memory to zero, like kzalloc()"
2. Drop dev_err() for u_boot_env_add_cells() fail
It can fail only on -ENOMEM. We don't wan
From: Rafał Miłecki
Use nvmem_dev_size() and nvmem_device_read() to make this driver less
mtd dependent.
Signed-off-by: Rafał Miłecki
Reviewed-by: Miquel Raynal
---
V2: Don't introduce memleak when handling nvmem_device_read() failures
V3: Split PATCH 3/3 into two
drivers/nvmem/u-boot-env.c
From: Rafał Miłecki
Simplify adding NVMEM cells.
Signed-off-by: Rafał Miłecki
Reviewed-by: Miquel Raynal
---
V3: Split PATCH 3/3 into two
drivers/nvmem/u-boot-env.c | 55 +++---
1 file changed, 21 insertions(+), 34 deletions(-)
diff --git a/drivers/nvmem/u
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).
Signed-off-by: Rafał Miłecki
Reviewed-by: Miquel Raynal
---
drivers/nvmem/core.c | 13
From: Rafał Miłecki
U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead of a standalone device.
This patch adds layout binding which allows using it on top of MTD NVMEM
device
On 19.12.2023 19:13, Greg Kroah-Hartman wrote:
On Tue, Dec 19, 2023 at 06:40:23PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
mtd dependent
2. Use nvmem_add_one_cell() to simplify adding NVMEM cells
Shouldn't
From: Rafał Miłecki
This patch moves all generic (NVMEM devices independent) code from NVMEM
device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
code on top of it.
Thanks to proper layout it's possible to support U-Boot env data stored
on any kind of NVMEM device
From: Rafał Miłecki
1. Prefer kzalloc() over kcalloc()
See memory-allocation.rst which says: "to be on the safe side it's
best to use routines that set memory to zero, like kzalloc()"
2. Drop dev_err() for u_boot_env_add_cells() fail
It can fail only on -ENOMEM. We don't wan
From: Rafał Miłecki
1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
mtd dependent
2. Use nvmem_add_one_cell() to simplify adding NVMEM cells
Signed-off-by: Rafał Miłecki
Reviewed-by: Miquel Raynal
---
V2: Don't introduce memleak when handling nvmem_device_read
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).
Signed-off-by: Rafał Miłecki
Reviewed-by: Miquel Raynal
---
drivers/nvmem/core.c | 13
From: Rafał Miłecki
U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead of a standalone device.
This patch adds layout binding which allows using it on top of MTD NVMEM
device
On 19.12.2023 10:55, Rafał Miłecki wrote:
On 19.12.2023 08:55, Miquel Raynal wrote:
Hi Rafał,
zaj...@gmail.com wrote on Mon, 18 Dec 2023 23:10:20 +0100:
On 18.12.2023 15:21, Miquel Raynal wrote:
Hi Rafał,
zaj...@gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
From: Rafał Miłecki
On 19.12.2023 08:55, Miquel Raynal wrote:
Hi Rafał,
zaj...@gmail.com wrote on Mon, 18 Dec 2023 23:10:20 +0100:
On 18.12.2023 15:21, Miquel Raynal wrote:
Hi Rafał,
zaj...@gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
From: Rafał Miłecki
This patch moves all generic (NVMEM
On 18.12.2023 15:48, Rob Herring wrote:
On Mon, 18 Dec 2023 14:37:19 +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead
On 18.12.2023 15:21, Miquel Raynal wrote:
Hi Rafał,
zaj...@gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
From: Rafał Miłecki
This patch moves all generic (NVMEM devices independent) code from NVMEM
device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
code on top
On 14.12.2023 22:27, Simon Glass wrote:
On Thu, 14 Dec 2023 at 08:36, Rafał Miłecki wrote:
From: Rafał Miłecki
So far we had a property for "ethaddr" NVMEM cell containing base
Ethernet MAC address. The problem is vendors often pick non-standard
names for storing MAC(s) (other tha
From: Rafał Miłecki
1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
mtd dependent
2. Use nvmem_add_one_cell() to simplify adding NVMEM cells
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/u-boot-env.c | 79 +-
1 file changed, 35
From: Rafał Miłecki
This patch moves all generic (NVMEM devices independent) code from NVMEM
device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
code on top of it.
Thanks to proper layout it's possible to support U-Boot env data stored
on any kind of NVMEM device
From: Rafał Miłecki
U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead of a standalone device.
This patch adds layout binding which allows using it on top of MTD NVMEM
device
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/core.c | 13 +
include/linux
From: Rafał Miłecki
So far we had a property for "ethaddr" NVMEM cell containing base
Ethernet MAC address. The problem is vendors often pick non-standard
names for storing MAC(s) (other than "ethaddr"). A few names were
noticed over years:
1. "wanaddr" (Edim
From: Rafał Miłecki
It's totally valid for read() to provide less bytes than requested
maximum. It may happen if there is no more data available yet or source
pushes data in small chunks.
This actually happens when trying to read env data from NVMEM device.
Kernel may provide NVMEM content
From: Rafał Miłecki
Rename "addr0" and "addr1" to "buf0" and "buf1" accordingly. Name "addr"
suggests that variable contains a numeric value being some kind of
address. Name "buf" is de facto a standard name for pointer to allocated
me
From: Rafał Miłecki
Call to fread() was changed to check for return value. The problem is it
can't be checked for returning 1 (as it is) to determine success.
We call fread() with buffer size as "size" argument. Reading any
"compatible" value shorter than buffer size will r
;)
AUX/SHD/bcm54xx_config_clock_delay update ported from Linux 6.5-rc4 commit
28e219aea0b9e ("net: phy: broadcom: drop brcm_phy_setbits() and use phy_set_bits()
instead")
Signed-off-by: Marek Vasut
Reviewed-by: Rafał Miłecki
On 5.08.2023 05:38, Marek Vasut wrote:
It's Broadcom PHY simply described as single-port
RGMII 10/100/1000BASE-T PHY. It requires disabling
delay skew and GTXCLK bits.
Ported from Linux kernel commit
0fc9ae1076697 ("net: phy: broadcom: add support for BCM54210E")
Signed-off-by: Marek Vasut
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drive
From: Rafał Miłecki
Callback .read_post_process() is designed to modify raw cell content
before providing it to the consumer. So far we were dealing with
modifications that didn't affect cell size (length). In some cases
however cell content needs to be reformatted and resized.
It's required
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
This change is required for NVMEM consumers to get expected MAC address
from U-Boot env data variable "ethaddr".
To address some previous concerns:
1. Yes, U-Boot env binding & driver should be converted to NVMEM layout
2. My priority is to get working MAC rat
, 9 Mar 2023 10:53:07 >> +:
>> >>> On 09/03/2023 10:32, Miquel Raynal wrote:
>>>> Hi Srinivas,
>>>> >>>> srinivas.kandaga...@linaro.org wrote on Thu, 9 Mar 2023 10:12:24 >>>>
+:
>>>> >>>&g
:12:24
+:
On 22/02/2023 17:22, Rafał Miłecki wrote:
@@ -1791,11 +1792,15 @@ ssize_t nvmem_device_cell_read(struct
nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
> + /* Cells with read_post_process hook may realloc buffer we
can't allow h
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drive
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. it
may require resizing available buffer. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off-by: Rafał
From: Michael Walle
Instead of relying on the name the consumer is using for the cell, like
it is done for the nvmem .cell_post_process configuration parameter,
provide a per-cell post processing hook. This can then be populated by
the NVMEM provider (or the NVMEM layout) when adding the cell.
From: Rafał Miłecki
U-Boot environment variables are stored using ASCII format. One of
important entries is "ethaddr" which contains base MAC address.
That NVMEM cell requires some extra processing when reading:
1. ASCII needs translating into binary MAC format
2. Final
On 30.01.2023 11:56, Miquel Raynal wrote:
Hi Rafał,
zaj...@gmail.com wrote on Fri, 27 Jan 2023 13:57:04 +0100:
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
U-Boot environment variables can be found on various NVMEM devices (not
just MTD) so convert this driver to a generic layout one.
This way - thanks to using NVMEM generic API - this driver can be reused
in other scenarios.
For backward DT compatibility we need to support
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. it
may require resizing available buffer. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off-by: Rafał
From: Rafał Miłecki
U-Boot environment variables can be found of various underlaying storage
entities. This binding should be defined as a layout on top on NVMEM
device not a NVMEM device itself.
Signed-off-by: Rafał Miłecki
Reviewed-by: Rob Herring
---
.../bindings/nvmem/layouts/nvmem
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block).
Signed-off-by: Rafał Miłecki
---
V2: Drop "const" from "const size_t"
---
drivers/nvmem/c
On 26.01.2023 02:14, William Zhang wrote:
On 01/21/2023 03:43 PM, Linus Walleij wrote:
For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the
D-Link DIR-885L and DIR-890L routers, we need to explicitly
select the ECC like this in the device tree:
nand-ecc-algo = "bch";
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem
From: Rafał Miłecki
U-Boot environment variables can be found on various NVMEM devices (not
just MTD) so convert this driver to a generic layout one.
This way - thanks to using NVMEM generic API - this driver can be reused
in other scenarios.
For backward DT compatibility we need to support
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
U-Boot environment variables can be found of various underlaying storage
entities. This binding should be defined as a layout on top on NVMEM
device not a NVMEM device itself.
Signed-off-by: Rafał Miłecki
---
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
.../nvmem
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. it
may require resizing available buffer. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off-by: Rafał
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block).
Signed-off-by: Rafał Miłecki
---
V2: Drop "const" from "const size_t"
---
drivers/nvmem/c
On 10.01.2023 13:19, Michael Walle wrote:
Hi,
Am 2023-01-10 11:54, schrieb Rafał Miłecki:
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support f
From: Rafał Miłecki
U-Boot environment variables can be found on various NVMEM devices (not
just MTD) so convert this driver to a generic layout one.
This way - thanks to using NVMEM generic API - this driver can be reused
in other scenarios.
For backward DT compatibility we need to support
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
U-Boot environment variables can be found of various underlaying storage
entities. This binding should be defined as a layout on top on NVMEM
device not a NVMEM device itself.
Signed-off-by: Rafał Miłecki
---
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
.../nvmem
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. It
requires passing updated size value to the caller. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block).
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/core.c | 13 +
include/linux/nvmem-consumer.h
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nv
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. It
requires passing updated size value to the caller. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
On 28.11.2022 20:52, Tom Rini wrote:
On Tue, Nov 08, 2022 at 02:17:28PM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: "Ying-Chun Liu (PaulLiu)"
Currently file transfers are done using tftp or NFS both
over udp. This requires a request to be sent from client
(u-boot) to the boot server.
The
From: Rafał Miłecki
NVMEM consumers expect MAC in a byte-based format (see e.g.
nvmem_get_mac_address()). U-Boot environment data stores all values in
ASCII form.
Add post processing callback detecting "ethaddr" reads and reformat data
as expected. This fixes Ethernet drivers readin
From: Rafał Miłecki
Pass whole NVMEM cell struct and length pointer as arguments to callback
functions.
This allows:
1. Cells content to be modified based on more info
Some cells (identified by their names) contain specific data that
needs further processing. This can be e.g. MAC address
From: Rafał Miłecki
NVMEM consumers expect MAC in a byte-based format (see e.g.
nvmem_get_mac_address()). U-Boot environment data stores all values in
ASCII form.
Add post processing callback detecting "ethaddr" reads and reformat data
as expected. This fixes Ethernet drivers readin
From: Rafał Miłecki
Pass whole NVMEM cell struct and length pointer as arguments to callback
functions.
This allows:
1. Cells content to be modified based on more info
Some cells (identified by their names) contain specific data that
needs further processing. This can be e.g. MAC address
On 17.10.2022 09:17, Rafał Miłecki wrote:
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. They
decided to store U-Boot environment data inside U-Boot partition and to
use a custom header (with "uEnv" magic and env data length).
Add support for
On 18.10.2022 17:50, Conor Dooley wrote:
On Tue, Oct 18, 2022 at 05:42:01PM +0200, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot partition may contain subpartitions. For example Broadcom
includes environment data block in the middle of its U-Boot partition.
This allows describing
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. U-Boot
stores its configuration in an environment data block.
Such blocks are usually stored on flash as a separated partition at
hardcoded address. Broadcom however decided to:
1. Store env data block inside U
From: Rafał Miłecki
U-Boot partition may contain subpartitions. For example Broadcom
includes environment data block in the middle of its U-Boot partition.
This allows describing Broadcom's U-Boot env data and will allow
referencing its NVMEM cell in the future.
Reg: 118f3fbe517f4 (&qu
On 18.10.2022 12:19, Conor Dooley wrote:
On Fri, Oct 14, 2022 at 04:09:40PM -0500, Rob Herring wrote:
On Fri, 30 Sep 2022 18:36:31 +0200, Rafał Miłecki wrote:
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. U-Boot
stores its configuration
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. They
decided to store U-Boot environment data inside U-Boot partition and to
use a custom header (with "uEnv" magic and env data length).
Add support for Broadcom's specific binding and their cus
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. U-Boot
stores its configuration in an environment data block.
Such blocks are usually stored on flash as a separated partition at
hardcoded address. Broadcom however decided to:
1. Store env data block inside U
On 7.04.2022 20:17, Rob Herring wrote:
On Thu, Apr 07, 2022 at 04:55:14AM -0700, Joel Peshkin wrote:
The first 32b value is a magic number (endian swapped mnemonic of "uEnv"
short for "u-boot environment"). Finding that magic number of a 4K
boundary followed by a length and then a u-boot
From: Rafał Miłecki
DT binding allows specifying NVMEM cells as NVMEM device (provider)
subnodes. Looks for such subnodes when building NVMEM cells.
This allows NVMEM consumers to use U-Boot environment variables.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/u-boot-env.c | 1 +
1 file
From: Rafał Miłecki
This fixes:
drivers/nvmem/u-boot-env.c:141:17: sparse: sparse: cast to restricted __le32
Reported-by: kernel test robot
Fixes: f955dc1445069 ("nvmem: add driver handling U-Boot environment variables")
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/u-boot-env.c
On 3.07.2022 10:48, Rafał Miłecki wrote:
U-Boot doesn't have cells at hardcoded addresses. They are stored in
internal format. It's still important to define relevant cells in DT so
NVMEM consumers can reference them.
Update binding to allow including basic cells as NVMEM device subnodes
On 2.08.2022 00:03, William Zhang wrote:
This driver supports the peripheral block timer found on the Broadcom
BCA SoCs. It is 30-bit up-count timer running at 50MHz and can be used
as the system clock source such as on BCM63138.
Signed-off-by: William Zhang
(...)
+static const struct
From: Rafał Miłecki
Broadcom stores environment variables blocks inside U-Boot partition
itself. This driver finds & registers them.
Signed-off-by: Rafał Miłecki
---
drivers/mtd/parsers/Kconfig | 10
drivers/mtd/parsers/Makefile | 1 +
drivers/mtd/parsers/brcm_u-boot.c
From: Rafał Miłecki
Right now there is no (known) real reason for a custom binding for
standard U-Boot partitions. Broadcom's U-Boot however requires extra
handling - looking for environment variables subblocks. This commit adds
Broadcom specific binding.
Signed-off-by: Rafał Miłecki
From: Rafał Miłecki
U-Boot doesn't have cells at hardcoded addresses. They are stored in
internal format. It's still important to define relevant cells in DT so
NVMEM consumers can reference them.
Update binding to allow including basic cells as NVMEM device subnodes.
Signed-off-by: Rafał
From: Rafał Miłecki
A new DT binding for describing environment data block has been added in
Linux's commit 5db1c2dbc04c ("dt-bindings: nvmem: add U-Boot environment
variables binding"). Once we get a proper Linux NVMEM driver it'll be
possible to use Linux's binary interface for
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
Current Linux's
From: Rafał Miłecki
MTD subsystem API allows interacting with MTD devices (e.g. reading,
writing, handling bad blocks). So far a random driver could get MTD
device only by its name (get_mtd_device_nm()). This change allows
getting them also by a DT node.
This API is required for drivers
On 14.06.2022 08:45, Ahmad Fatoum wrote:
+ if (err && !mtd_is_bitflip(err)) {
+ dev_err(dev, "Failed to read from mtd: %d\n", err);
Nitpick: %pe
My "err" variable in int, not a pointer (I don't use PTR_ERR()).
+static int u_boot_env_add_cells(struct u_boot_env *priv,
On 13.06.2022 16:04, Miquel Raynal wrote:
@@ -1154,6 +1154,34 @@ int __get_mtd_device(struct mtd_info *mtd)
}
EXPORT_SYMBOL_GPL(__get_mtd_device);
+/**
+ * of_get_mtd_device_by_node - obtain an MTD device associated with a given
node
+ *
+ * @np: device tree node
+ */
+struct mtd_info
From: Rafał Miłecki
MTD subsystem API allows interacting with MTD devices (e.g. reading,
writing, handling bad blocks). So far a random driver could get MTD
device only by its name (get_mtd_device_nm()). This change allows
getting them also by a DT node.
This API is required for drivers
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
Current Linux's
On 4.05.2022 11:23, Ahmad Fatoum wrote:
Hello Rafał,
On 03.05.22 18:56, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides
On 25.04.2022 03:20, Daniel Golle wrote:
On Mon, Apr 11, 2022 at 11:00:32AM +0200, Miquel Raynal wrote:
On Wed, 2022-04-06 at 14:32:24 UTC, =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= wrote:
From: Rafał Miłecki
Until this change MTD subsystem supported handling partitions only with
MTD partitions
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
It can be used
Hi Rob, could you re-review my patch as I provided answers (see below), please?
On 3.03.2022 09:32, Rafał Miłecki wrote:
On 2.03.2022 22:59, Rob Herring wrote:
On Thu, Feb 17, 2022 at 11:24:48AM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
UBI is often used on embedded devices to store
From: Rafał Miłecki
Broadcom uses U-Boot for some of their recent platforms like BCM4908.
They decided to use modified environment variables variables format
though. Their header includes 2 extra 32 b fields at the beginning.
The first field meaning is unknown, the second one stores length
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
It can be used
From: Rafał Miłecki
Until this change MTD subsystem supported handling partitions only with
MTD partitions parsers. That's a specific / limited API designed around
partitions.
Some MTD partitions may however require different handling. They may
contain specific data that needs to be parsed
On 10.03.2022 09:45, Michal Simek wrote:
On 3/9/22 16:40, Rob Herring wrote:
On Wed, Mar 09, 2022 at 02:42:43PM +0100, Michal Simek wrote:
On 2/28/22 14:12, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs
On 9.03.2022 14:42, Michal Simek wrote:
On 2/28/22 14:12, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs to be accessed by a bootloader, kernel and often
user-space.
This binding allows describing environment data
On 7.03.2022 11:24, Alexander Dahl wrote:
Hei hei,
just want to give a little more background here from embedded non
openwrt point of view. See below.
Am Mon, Feb 28, 2022 at 12:32:11PM +0100 schrieb Rafał Miłecki:
On 25.02.2022 17:42, Rob Herring wrote:
On Thu, Feb 17, 2022 at 02:02:35PM
1 - 100 of 120 matches
Mail list logo
