From: Rafał Miłecki
This file was moved to the layouts/ subdirectory.
Signed-off-by: Rafał Miłecki
---
I missed this MAINTAINERS change in the commit 1b3f5b88c541
("dt-bindings: nvmem: convert U-Boot env to a layout").
Srini: I believe your policy is to rebase your tree and send
[rmilecki: simplify commit description & rebase]
Signed-off-by: Rafał Miłecki
---
V2: New patch in the series
drivers/nvmem/u-boot-env.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index 936e39b20b38..593f0bf4a395 100644
--- a/d
From: Rafał Miłecki
U-Boot environment variables are stored in a specific format. Actual
data can be placed in various storage sources (MTD, UBI volume, EEPROM,
NVRAM, etc.).
Move all generic (NVMEM device independent) code from NVMEM device
driver to an NVMEM layout driver. Then add a simple
From: Rafał Miłecki
U-Boot environment variables can be stored in various data sources. MTD
is just one of available options. Refactor DT binding into a layout so
it can be used with UBI volumes and other NVMEM devices.
Link: https://lore.kernel.org/all/20231221173421.13737-1-zaj...@gmail.com
From: Rafał Miłecki
U-Boot environment variables are stored in a specific format. Actual
data can be placed in various storage sources (MTD, UBI volume, EEPROM,
NVRAM, etc.).
Move all generic (NVMEM device independent) code from NVMEM device
driver to an NVMEM layout driver. Then add a simple
From: Rafał Miłecki
U-Boot environment variables can be stored in various data sources. MTD
is just one of available options. Refactor DT binding into a layout so
it can be used with UBI volumes and other NVMEM devices.
Link: https://lore.kernel.org/all/20231221173421.13737-1-zaj...@gmail.com
On 8.07.2024 08:32, Miquel Raynal wrote:
zaj...@gmail.com wrote on Sat, 6 Jul 2024 00:58:21 +0200:
From: Rafał Miłecki
U-Boot environment variables can be stored in various data sources. MTD
is just one of available options. Refactor DT binding into a layout so
it can be used with UBI
From: Rafał Miłecki
U-Boot environment variables can be stored in various data sources. MTD
is just one of available options. Refactor DT binding into a layout so
it can be used with UBI volumes and other NVMEM devices.
Link: https://lore.kernel.org/all/20231221173421.13737-1-zaj...@gmail.com
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 va
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 bac
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&
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-
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
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
devi
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&#
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&
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
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
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
devi
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 of
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
devi
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/
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 conte
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 w
")
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'
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 acros
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 here */
+
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 acros
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
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.
S
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 MAC n
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 acros
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
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";
nand-ecc-stren
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 acros
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
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 for
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 acros
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).
Sig
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).
Sig
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 acros
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 cur
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
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 in an
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 thei
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 e
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 devic
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 udev
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
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
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 in
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 Li
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, ui
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 *o
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 Li
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. Pro
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
1 - 100 of 128 matches
Mail list logo
