[PATCH] usb: dwc3: of-simple: remove unmatchable compatibles
Only three of the compatibles listed exist in up-to-date upstream device
trees. As barebox need not worry about backwards compatibility with
older device trees, remove the rest that would never be matched.
Signed-off-by: Ahmad Fatoum
---
drivers/usb/dwc3/dwc3-of-simple.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index e8155321ad22..1e622240152e 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -67,13 +67,7 @@ static void dwc3_of_simple_remove(struct device *dev)
static const struct of_device_id of_dwc3_simple_match[] = {
{.compatible = "rockchip,rk3399-dwc3"},
{.compatible = "xlnx,zynqmp-dwc3"},
- {.compatible = "fsl,ls1046a-dwc3"},
{.compatible = "fsl,imx8mp-dwc3"},
- {.compatible = "cavium,octeon-7130-usb-uctl"},
- {.compatible = "sprd,sc9860-dwc3"},
- {.compatible = "amlogic,meson-axg-dwc3"},
- {.compatible = "amlogic,meson-gxl-dwc3"},
- {.compatible = "allwinner,sun50i-h6-dwc3"},
{/* Sentinel */}};
MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
--
2.39.2
[PATCH] gitignore: ignore mvebu binary.0 firmware files
After a run of test/generate-dummy-fw.sh, following dummy firmware is generated and is not matched by any .gitignore: arch/arm/boards/globalscale-mirabox/binary.0 arch/arm/boards/lenovo-ix4-300d/binary.0 arch/arm/boards/marvell-armada-xp-db/binary.0 arch/arm/boards/marvell-armada-xp-gp/binary.0 arch/arm/boards/netgear-rn104/binary.0 arch/arm/boards/netgear-rn2120/binary.0 arch/arm/boards/plathome-openblocks-ax3/binary.0 arch/arm/boards/turris-omnia/binary.0 Add a top-level rule to make them not appear in git's untracked files list. Signed-off-by: Ahmad Fatoum --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 3b9cd6a25aff..f0afd899e1a8 100644 --- a/.gitignore +++ b/.gitignore @@ -34,6 +34,7 @@ *.so.dbg *.symtypes *.tab.[ch] +binary.0 Module.symvers *.dtb *.dtb.* -- 2.39.2
Re: [PATCH master 2/7] nvmem: bsec: correct regmap's max_register
On Mon, 8 Jan 2024 12:17:09 +0100 Robin van der Gracht wrote: ... > > > > barebox@Linux Automation MC-1 board:/ ls -l /dev/stm32-bsec > > crw---384 /dev/stm32-bsec > > Thats more like it. I'll apply the full series and recheck. This works as expected. Thanks. Minor note: As you mention in your patch notes: "struct regmap::max_register is in units of struct regmap::reg_stride" This used to be the value of the maximum register number (index). The doc in include/linux/regmap.h line 33 mentions 'index'. Maybe that needs some mentioning of stride as well.. Regardless: Tested-by: Robin van der Gracht
Re: [PATCH 2/4] kvx: set DMA_ALIGNMENT instead of defining dma_alloc
Hello Ahmad,
On 1/8/24 11:24, Ahmad Fatoum wrote:
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and we for need 64 for kvx,
define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/kvx/include/asm/dma.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/kvx/include/asm/dma.h b/arch/kvx/include/asm/dma.h
index f35eafba8fae..c6f67e76d024 100644
--- a/arch/kvx/include/asm/dma.h
+++ b/arch/kvx/include/asm/dma.h
@@ -6,11 +6,7 @@
#include
-#define dma_alloc dma_alloc
-static inline void *dma_alloc(size_t size)
-{
- return xmemalign(64, ALIGN(size, 64));
-}
+#define DMA_ALIGNMENT 64
#define dma_alloc_coherent dma_alloc_coherent
static inline void *dma_alloc_coherent(size_t size, dma_addr_t *dma_handle)
Small typo in the commit msg (`we for`) but otherwise Ack!
Reviewed-by: Yann Sionneau
--
Yann
Re: [PATCH master 2/7] nvmem: bsec: correct regmap's max_register
Hello Ahmad,
On Mon, 8 Jan 2024 11:44:00 +0100
Ahmad Fatoum wrote:
> Hello Robin,
>
> On 08.01.24 11:29, Robin van der Gracht wrote:
> > Hi Ahmad,
> >
> > Comments are below.
> >
> > On Tue, 2 Jan 2024 18:00:55 +0100
> > Ahmad Fatoum wrote:
> >
> >> The max_register must be a multiple of the register stride, which is not
> >> the case for (384 / 4) - 1 == 95. Instead, we should be setting 380, so
> >> fix the calculation to do this.
> >>
> >> Fixes: 094ce0ee7cdf ("nvmem: bsec: correct regmap's max_register")
> >> Reported-by: Robin van der Gracht
> >> Signed-off-by: Ahmad Fatoum
> >> ---
> >> drivers/nvmem/bsec.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/nvmem/bsec.c b/drivers/nvmem/bsec.c
> >> index 889f14428d59..22e30c6c2e82 100644
> >> --- a/drivers/nvmem/bsec.c
> >> +++ b/drivers/nvmem/bsec.c
> >> @@ -218,7 +218,7 @@ static int stm32_bsec_probe(struct device *dev)
> >>priv->map_config.reg_bits = 32;
> >>priv->map_config.val_bits = 32;
> >>priv->map_config.reg_stride = 4;
> >> - priv->map_config.max_register = (data->size / 4) - 1;
> >> + priv->map_config.max_register = data->size -
> >> priv->map_config.reg_stride;
> >>
> >>priv->lower = data->lower;
> >>
> >
> > This patch gives a bsec device size of 1520 bytes. Which means I'm now
> > allowed to read/write beyond register 95 without an error.
> >
> > barebox@board:/ ls -l /dev/stm32-bsec
> > crw--- 1520 /dev/stm32-bsec
> >
> > The device size is now in bytes, but the read/write offsets given to
> > the md and mw commands is still in bytes/stride.
> >
> > I.e. to read register 95:
> > md -l -s /dev/stm32-bsec 380+4
> > 017c:
> >
> > I can now also read register 100:
> > md -l -s /dev/stm32-bsec 400+4
> > 0190:
> >
> > This doesn't seem right.
> >
> > max_register should probably stay 95. See doc[1]
> >
> > 1:https://git.pengutronix.de/cgit/barebox/tree/include/linux/regmap.h?h=v2023.12.0#n33
> >
>
> Did you apply the whole series? With the whole series applied I have:
Argh. No. I missed it was part of a series. I was only cc'd to this
one.
>
> barebox@Linux Automation MC-1 board:/ ls -l /dev/stm32-bsec
> crw---384 /dev/stm32-bsec
Thats more like it. I'll apply the full series and recheck.
Robin
Re: [PATCH master 2/7] nvmem: bsec: correct regmap's max_register
Hello Robin,
On 08.01.24 11:29, Robin van der Gracht wrote:
> Hi Ahmad,
>
> Comments are below.
>
> On Tue, 2 Jan 2024 18:00:55 +0100
> Ahmad Fatoum wrote:
>
>> The max_register must be a multiple of the register stride, which is not
>> the case for (384 / 4) - 1 == 95. Instead, we should be setting 380, so
>> fix the calculation to do this.
>>
>> Fixes: 094ce0ee7cdf ("nvmem: bsec: correct regmap's max_register")
>> Reported-by: Robin van der Gracht
>> Signed-off-by: Ahmad Fatoum
>> ---
>> drivers/nvmem/bsec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/nvmem/bsec.c b/drivers/nvmem/bsec.c
>> index 889f14428d59..22e30c6c2e82 100644
>> --- a/drivers/nvmem/bsec.c
>> +++ b/drivers/nvmem/bsec.c
>> @@ -218,7 +218,7 @@ static int stm32_bsec_probe(struct device *dev)
>> priv->map_config.reg_bits = 32;
>> priv->map_config.val_bits = 32;
>> priv->map_config.reg_stride = 4;
>> -priv->map_config.max_register = (data->size / 4) - 1;
>> +priv->map_config.max_register = data->size -
>> priv->map_config.reg_stride;
>>
>> priv->lower = data->lower;
>>
>
> This patch gives a bsec device size of 1520 bytes. Which means I'm now
> allowed to read/write beyond register 95 without an error.
>
> barebox@board:/ ls -l /dev/stm32-bsec
> crw--- 1520 /dev/stm32-bsec
>
> The device size is now in bytes, but the read/write offsets given to
> the md and mw commands is still in bytes/stride.
>
> I.e. to read register 95:
> md -l -s /dev/stm32-bsec 380+4
> 017c:
>
> I can now also read register 100:
> md -l -s /dev/stm32-bsec 400+4
> 0190:
>
> This doesn't seem right.
>
> max_register should probably stay 95. See doc[1]
>
> 1:https://git.pengutronix.de/cgit/barebox/tree/include/linux/regmap.h?h=v2023.12.0#n33
Did you apply the whole series? With the whole series applied I have:
barebox@Linux Automation MC-1 board:/ ls -l /dev/stm32-bsec
crw---384 /dev/stm32-bsec
Because there are two issues (size in bsec driver is wrong, cdev size is
calculated wrong),
I need to decide which to fix first or squash them. I chose to make the size
intermittently
bigger (so reading valid offsets still work) instead of making it smaller and
breaking
bisect (or squashing all and making it less easy to review).
Cheers,
Ahmad
>
> Robin
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH master 2/7] nvmem: bsec: correct regmap's max_register
Hi Ahmad,
Comments are below.
On Tue, 2 Jan 2024 18:00:55 +0100
Ahmad Fatoum wrote:
> The max_register must be a multiple of the register stride, which is not
> the case for (384 / 4) - 1 == 95. Instead, we should be setting 380, so
> fix the calculation to do this.
>
> Fixes: 094ce0ee7cdf ("nvmem: bsec: correct regmap's max_register")
> Reported-by: Robin van der Gracht
> Signed-off-by: Ahmad Fatoum
> ---
> drivers/nvmem/bsec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/nvmem/bsec.c b/drivers/nvmem/bsec.c
> index 889f14428d59..22e30c6c2e82 100644
> --- a/drivers/nvmem/bsec.c
> +++ b/drivers/nvmem/bsec.c
> @@ -218,7 +218,7 @@ static int stm32_bsec_probe(struct device *dev)
> priv->map_config.reg_bits = 32;
> priv->map_config.val_bits = 32;
> priv->map_config.reg_stride = 4;
> - priv->map_config.max_register = (data->size / 4) - 1;
> + priv->map_config.max_register = data->size -
> priv->map_config.reg_stride;
>
> priv->lower = data->lower;
>
This patch gives a bsec device size of 1520 bytes. Which means I'm now
allowed to read/write beyond register 95 without an error.
barebox@board:/ ls -l /dev/stm32-bsec
crw--- 1520 /dev/stm32-bsec
The device size is now in bytes, but the read/write offsets given to
the md and mw commands is still in bytes/stride.
I.e. to read register 95:
md -l -s /dev/stm32-bsec 380+4
017c:
I can now also read register 100:
md -l -s /dev/stm32-bsec 400+4
0190:
This doesn't seem right.
max_register should probably stay 95. See doc[1]
1:https://git.pengutronix.de/cgit/barebox/tree/include/linux/regmap.h?h=v2023.12.0#n33
Robin
[PATCH 2/4] kvx: set DMA_ALIGNMENT instead of defining dma_alloc
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and we for need 64 for kvx,
define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/kvx/include/asm/dma.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/kvx/include/asm/dma.h b/arch/kvx/include/asm/dma.h
index f35eafba8fae..c6f67e76d024 100644
--- a/arch/kvx/include/asm/dma.h
+++ b/arch/kvx/include/asm/dma.h
@@ -6,11 +6,7 @@
#include
-#define dma_alloc dma_alloc
-static inline void *dma_alloc(size_t size)
-{
- return xmemalign(64, ALIGN(size, 64));
-}
+#define DMA_ALIGNMENT 64
#define dma_alloc_coherent dma_alloc_coherent
static inline void *dma_alloc_coherent(size_t size, dma_addr_t *dma_handle)
--
2.39.2
[PATCH 1/4] sandbox: set DMA_ALIGNMENT instead of defining dma_alloc
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and we for some reason, use 64 for
sandbox, define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/sandbox/include/asm/dma.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/sandbox/include/asm/dma.h b/arch/sandbox/include/asm/dma.h
index ac8b408aae0b..cafbb7fe6a4c 100644
--- a/arch/sandbox/include/asm/dma.h
+++ b/arch/sandbox/include/asm/dma.h
@@ -12,11 +12,7 @@
#include
#include
-#define dma_alloc dma_alloc
-static inline void *dma_alloc(size_t size)
-{
- return xmemalign(64, ALIGN(size, 64));
-}
+#define DMA_ALIGNMENT 64
#define dma_alloc_coherent dma_alloc_coherent
static inline void *dma_alloc_coherent(size_t size, dma_addr_t *dma_handle)
--
2.39.2
[PATCH 3/4] mips: set DMA_ALIGNMENT instead of defining dma_alloc
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and may not be applicable to the used
processor, we define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/mips/include/asm/dma.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/mips/include/asm/dma.h b/arch/mips/include/asm/dma.h
index d7570cce7109..5c5b6d5b3a58 100644
--- a/arch/mips/include/asm/dma.h
+++ b/arch/mips/include/asm/dma.h
@@ -14,13 +14,8 @@
#include
#include
-#define dma_alloc dma_alloc
-static inline void *dma_alloc(size_t size)
-{
- unsigned long max_linesz = max(current_cpu_data.dcache.linesz,
- current_cpu_data.scache.linesz);
- return xmemalign(max_linesz, ALIGN(size, max_linesz));
-}
+#define DMA_ALIGNMENT \
+ max(current_cpu_data.dcache.linesz, current_cpu_data.scache.linesz)
#define dma_alloc_coherent dma_alloc_coherent
static inline void *dma_alloc_coherent(size_t size, dma_addr_t *dma_handle)
--
2.39.2
[PATCH 4/4] dma: don't allow override of dma_alloc/dma_free
There are no architectures left defining their own dma_alloc/dma_free.
Instead, they define DMA_ALIGNMENT and use 's common
implementation.
This will be useful later on, as we can use DMA_ALIGNMENT for sanity
checking with CONFIG_DMA_DEBUG_API. Till then, ensure we get no new
architecture-specific definitions of dma_alloc/dma_free, by preventing
override of the implementation.
Signed-off-by: Ahmad Fatoum
---
include/dma.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/dma.h b/include/dma.h
index 266a7f323fa5..df9807b4f2e4 100644
--- a/include/dma.h
+++ b/include/dma.h
@@ -21,19 +21,15 @@
#define DMA_ALIGNMENT 32
#endif
-#ifndef dma_alloc
static inline void *dma_alloc(size_t size)
{
return xmemalign(DMA_ALIGNMENT, ALIGN(size, DMA_ALIGNMENT));
}
-#endif
-#ifndef dma_free
static inline void dma_free(void *mem)
{
free(mem);
}
-#endif
#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
--
2.39.2
[PATCH master 2/2] net: fsl-fman: fix CONFIG_DMA_API_DEBUG warnings
The first time a buffer is provided to a device, it needs to be mapped
with dma_map_single, before dma_sync_single_for_* may be called.
>From a cache coherence point of view, dma_map_single and
dma_sync_single_for_device have the same effect, but the former
is necessary, so DMA API debugging can catch issues.
Signed-off-by: Ahmad Fatoum
---
drivers/net/fsl-fman.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/fsl-fman.c b/drivers/net/fsl-fman.c
index baafe027c079..12cb240a37c0 100644
--- a/drivers/net/fsl-fman.c
+++ b/drivers/net/fsl-fman.c
@@ -583,7 +583,6 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth
*fm_eth)
void *rx_bd_ring_base;
void *rx_buf_pool;
u32 bd_ring_base_lo, bd_ring_base_hi;
- u32 buf_lo, buf_hi;
struct fm_port_bd *rxbd;
struct fm_port_qd *rxqd;
struct fm_bmi_rx_port *bmi_rx_port = fm_eth->rx_port;
@@ -631,19 +630,21 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth
*fm_eth)
/* init Rx BDs ring */
for (i = 0; i < RX_BD_RING_SIZE; i++) {
+ dma_addr_t dma;
+
rxbd = _eth->rx_bd_ring[i];
muram_writew(>status, RxBD_EMPTY);
muram_writew(>len, 0);
- buf_hi = upper_32_bits(virt_to_phys(rx_buf_pool +
- i * MAX_RXBUF_LEN));
- buf_lo = lower_32_bits(virt_to_phys(rx_buf_pool +
- i * MAX_RXBUF_LEN));
- dma_sync_single_for_device(fm_eth->dev,
- (unsigned long)rx_buf_pool + i *
MAX_RXBUF_LEN,
- MAX_RXBUF_LEN, DMA_FROM_DEVICE);
- muram_writew(>buf_ptr_hi, (u16)buf_hi);
- out_be32(>buf_ptr_lo, buf_lo);
+
+ dma = dma_map_single(fm_eth->dev,
+rx_buf_pool + i * MAX_RXBUF_LEN,
+MAX_RXBUF_LEN, DMA_FROM_DEVICE);
+ if (dma_mapping_error(fm_eth->dev, dma))
+ return -EFAULT;
+
+ muram_writew(>buf_ptr_hi, (u16)upper_32_bits(dma));
+ out_be32(>buf_ptr_lo, lower_32_bits(dma));
}
/* set the Rx queue descriptor */
--
2.39.2
[PATCH master 1/2] net: fsl-fman: fix alignment of RX buffer
The receive buffer needs to be cacheline aligned for cache maintenance to avoid invalidating unrelated malloc memory. This was so far not the case due to malloc's minimum alignment of 8-byte (with TLSF), so switch to dma_alloc instead. Signed-off-by: Ahmad Fatoum --- drivers/net/fsl-fman.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/fsl-fman.c b/drivers/net/fsl-fman.c index ff32fa8fc753..baafe027c079 100644 --- a/drivers/net/fsl-fman.c +++ b/drivers/net/fsl-fman.c @@ -620,9 +620,7 @@ static int fm_eth_rx_port_parameter_init(struct fm_eth *fm_eth) * RX_BD_RING_SIZE); /* alloc Rx buffer from main memory */ - rx_buf_pool = malloc(MAX_RXBUF_LEN * RX_BD_RING_SIZE); - if (!rx_buf_pool) - return -ENOMEM; + rx_buf_pool = dma_alloc(MAX_RXBUF_LEN * RX_BD_RING_SIZE); memset(rx_buf_pool, 0, MAX_RXBUF_LEN * RX_BD_RING_SIZE); -- 2.39.2
Re: [PATCH] rsatoc: fix typo in usage string
On Fri, Jan 05, 2024 at 02:10:00PM +0100, Ahmad Fatoum wrote:
> The commit introducing help text for the individual options,
> inadvertently modified the usage string. Revert that single line.
>
> Fixes: 94a2b2b28738 ("rsatoc: support generating standalone keys unreferenced
> by FIT keyring")
> Signed-off-by: Ahmad Fatoum
> ---
> scripts/rsatoc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks
Sascha
>
> diff --git a/scripts/rsatoc.c b/scripts/rsatoc.c
> index 6d10dca4169c..d5943d4a1154 100644
> --- a/scripts/rsatoc.c
> +++ b/scripts/rsatoc.c
> @@ -509,7 +509,7 @@ int main(int argc, char *argv[])
> }
>
> if (optind == argc) {
> - fprintf(stderr, "Usage: %s [-ods] OUTFIE:
> ...\n", argv[0]);
> + fprintf(stderr, "Usage: %s [-ods] : ...\n",
> argv[0]);
> fprintf(stderr, "\t-o FILE\twrite output into FILE instead of
> stdout\n");
> fprintf(stderr, "\t-d\tgenerate device tree snippet instead of
> C code\n");
> fprintf(stderr, "\t-s\tgenerate standalone key outside FIT
> image keyring\n");
> --
> 2.39.2
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] ARM: layerscape: ppa: fix type of C variable used in inline assembly
clang warns that cr should be an unsigned long as it's used to
initialize a register argument for the mrs instruction.
Change the type from unsigned int to unsigned long to fix this.
Signed-off-by: Ahmad Fatoum
---
arch/arm/mach-layerscape/ppa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-layerscape/ppa.c b/arch/arm/mach-layerscape/ppa.c
index 37d467386f6f..1f69aacf083a 100644
--- a/arch/arm/mach-layerscape/ppa.c
+++ b/arch/arm/mach-layerscape/ppa.c
@@ -124,7 +124,7 @@ int ls1046a_ppa_init(resource_size_t ppa_start,
resource_size_t ppa_size)
get_builtin_firmware(ppa_ls1046a_bin, _fw, _fw_size);
if (el == 3) {
- unsigned int cr;
+ unsigned long cr;
asm volatile("mrs %0, sctlr_el3" : "=r" (cr) : : "cc");
remap_range((void *)ppa_start, ppa_size, MAP_CACHED);
--
2.39.2
Re: [PATCH 0/6] cdev: delete partitions when deleting master cdev
On Wed, Jan 03, 2024 at 11:16:23AM +0100, Ahmad Fatoum wrote: > blockdevice_unregister only calls devfs_remove on the root cdev and > leaves the partition cdevs dangling. This doesn't break until the > block device parent struct device is freed at which time, it will > iterate over its cdevs to free them. If there's partitions there, > list_del on the partitions triggers a use after free. > > This series fixes this by removing partitions whenever the master cdev > is deleted. > > Code has been this way since for ever, but virtio deletes its devices on > shutdown triggering this issue. As virtio isn't that critical, I think > it's ok to not go into master right away and sit in next first. Applied, thanks Sascha > > common/partitions.c| 12 +++ > drivers/base/driver.c | 2 +- > drivers/of/partition.c | 16 +++ > fs/devfs-core.c| 45 +++--- > include/driver.h | 12 +++ > lib/bootstrap/devfs.c | 2 +- > 6 files changed, 55 insertions(+), 34 deletions(-) > > -- > 2.39.2 > > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH master 0/7] regmap: fix size of regmap-backed cdev and nvmem
On Tue, Jan 02, 2024 at 06:00:53PM +0100, Ahmad Fatoum wrote: > struct regmap::max_register is in units of struct regmap::reg_stride. > To get the total number or registers, we need to divide by reg_stride > before adding one, but we ended up adding one before division. > > This is wrong at different places across the tree, leading to the last > fuse to be inaccessible when not using the regmap API directly, i.e. > when using a NVMEM registered by nvmem_register_regmap or the cdev > instantiated in /dev. > > Ahmad Fatoum (6): > regmap: fix calculation of regmap size when reg_stride != 1 > nvmem: bsec: correct regmap's max_register > nvmem: startfive-otp: correct regmap's max_register > nvmem: imx-ocotp-ele: correct regmap's max_register > nvmem: ocotp: correct regmap's max_register > nvmem: ocotp: align OCOTP bank count with Linux > > Robin van der Gracht (1): > nvmem: regmap: Fix nvmem size Applied, thanks Sascha > > drivers/base/regmap/regmap.c | 28 ++-- > drivers/nvmem/bsec.c | 2 +- > drivers/nvmem/imx-ocotp-ele.c | 2 +- > drivers/nvmem/ocotp.c | 24 > drivers/nvmem/regmap.c| 4 ++-- > drivers/nvmem/starfive-otp.c | 2 +- > 6 files changed, 43 insertions(+), 19 deletions(-) > > -- > 2.39.2 > > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 090/112] vsprintf: add %pD for printing EFI device path
On Wed, Jan 03, 2024 at 07:12:50PM +0100, Ahmad Fatoum wrote:
> We already have a few users that will want to print EFI device paths and
> will gain quite a few more with incoming loader support, so let's allow
> printing them directly with printf with the %pD format specifier.
>
> Signed-off-by: Ahmad Fatoum
> ---
> lib/vsprintf.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index ea092c06d3d6..e41a1abee652 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -348,6 +349,15 @@ char *uuid_string(char *buf, const char *end, const u8
> *addr, int field_width,
> return string(buf, end, uuid, field_width, precision, flags);
> }
>
> +static char *device_path_string(char *buf, const char *end, const struct
> efi_device_path *dp,
> + int field_width, int precision, int flags)
> +{
> + if (!dp)
> + return string(buf, end, NULL, field_width, precision, flags);
> +
> + return buf + device_path_to_str_buf(dp, buf, end - buf);
> +}
> +
> static noinline_for_stack
> char *hex_string(char *buf, const char *end, const u8 *addr, int field_width,
>int precision, int flags, const char *fmt)
> @@ -519,6 +529,10 @@ static char *pointer(const char *fmt, char *buf, const
> char *end, const void *pt
> case 'J':
> if (fmt[1] == 'P' && IS_ENABLED(CONFIG_JSMN))
> return jsonpath_string(buf, end, ptr, field_width,
> precision, flags, fmt);
> + case 'D':
> + if (IS_ENABLED(CONFIG_EFI_DEVICEPATH))
> + return device_path_string(buf, end, ptr, field_width,
> precision, flags);
> + break;
Linux uses 'D' to print a filename from a struct file. This might become
useful for barebox as well, so we might better choose a different letter
here.
Otherwise I think it's ok to introduce barebox specific pointer types in
our printf implementation, even when they conflict with ones from the
kernel, but we should update the comment above this function accordingly
and clearly state when a letter is barebox specific.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 065/112] common: add PE/COFF loader
On Wed, Jan 03, 2024 at 07:12:25PM +0100, Ahmad Fatoum wrote:
> EFI loader will need to parse and load PE executables. Add functions to
> facilitate that. The API is inspired by the already existing ELF API.
>
> Signed-off-by: Ahmad Fatoum
> ---
> common/Kconfig | 3 +
> common/Makefile | 1 +
> common/pe.c | 377 +++
> include/asm-generic/pe.h | 56 +
> include/linux/pagemap.h | 1 +
> include/linux/pe.h | 468 +++
> include/pe.h | 316 ++
> 7 files changed, 1222 insertions(+)
> create mode 100644 common/pe.c
> create mode 100644 include/asm-generic/pe.h
> create mode 100644 include/linux/pe.h
> create mode 100644 include/pe.h
>
> +struct pe_image *pe_open(const char *filename)
> +{
> + struct pe_image *pe;
> + size_t size;
> + void *bin;
> +
> + bin = read_file(filename, );
> + if (!bin)
> + return NULL;
The static inline wrapper of this function indicates you should return
an error pointer here.
> +
> + pe = pe_open_buf(bin, size);
> +
> + //free(bin); // FIXME
Isn't this only a matter of adding free(pe->bin) to pe_close() and
freeing it here in case pe_open_buf() fails?
> diff --git a/include/asm-generic/pe.h b/include/asm-generic/pe.h
> new file mode 100644
> index ..a1df7471348e
> --- /dev/null
> +++ b/include/asm-generic/pe.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Portable Executable and Common Object Constants
> + *
> + * Copyright (c) 2018 Heinrich Schuchardt
> + *
> + * based on the "Microsoft Portable Executable and Common Object File Format
> + * Specification", revision 11, 2017-01-23
> + */
> +
> +#ifndef _ASM_PE_H
> +#define _ASM_PE_H
> +
> +/* Characteristics */
> +#define IMAGE_FILE_RELOCS_STRIPPED 0x0001
> +#define IMAGE_FILE_EXECUTABLE_IMAGE 0x0002
> +#define IMAGE_FILE_LINE_NUMS_STRIPPED0x0004
> +#define IMAGE_FILE_LOCAL_SYMS_STRIPPED 0x0008
> +#define IMAGE_FILE_AGGRESSIVE_WS_TRIM0x0010
> +#define IMAGE_FILE_LARGE_ADDRESS_AWARE 0x0020
> +/* Reserved 0x0040 */
> +#define IMAGE_FILE_BYTES_REVERSED_LO 0x0080
> +#define IMAGE_FILE_32BIT_MACHINE 0x0100
> +#define IMAGE_FILE_DEBUG_STRIPPED0x0200
> +#define IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP 0x0400
> +#define IMAGE_FILE_NET_RUN_FROM_SWAP 0x0800
> +#define IMAGE_FILE_SYSTEM0x1000
> +#define IMAGE_FILE_DLL 0x2000
> +#define IMAGE_FILE_UP_SYSTEM_ONLY0x4000
> +#define IMAGE_FILE_BYTES_REVERSED_HI 0x8000
These defines are duplicated in include/linux/pe.h
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 060/112] ARM: pbl: add 64K segment alignment for PE/COFF
On Wed, Jan 03, 2024 at 07:12:20PM +0100, Ahmad Fatoum wrote:
> An EFI stubbed ARM64 kernel can be booted either via EFI or via the
> normal boot protocol. We'll want barebox to be able to behave the same,
> so extend section alignment to enable this.
This description reads as if it would change something, but at this
point this patch only introduces unused defines. They are first used in
086/112.
Does it hurt to move the usage of PBL_SEGMENT_ALIGN and PECOFF_EDATA_PADDING
to this patch? If not, I'd suggest doing so to make the intention of
this patch clearer.
Sascha
>
> Signed-off-by: Ahmad Fatoum
> ---
> arch/arm/include/asm/memory.h | 20
> arch/arm/lib/pbl.lds.S| 18 ++
> 2 files changed, 38 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 23fbbd8438a1..765b089beb59 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -3,6 +3,9 @@
> #ifndef __ASM_ARM_MEMORY_H
> #define __ASM_ARM_MEMORY_H
>
> +#include
> +
> +#ifndef __ASSEMBLY__
> #include
>
> #include
> @@ -13,4 +16,21 @@ static inline int arm_add_mem_device(const char* name,
> resource_size_t start,
> return barebox_add_memory_bank(name, start, size);
> }
>
> +#endif
> +
> +
> +/*
> + * Alignment of barebox PBL segments (e.g. .text, .data).
> + *
> + * 4 B granule: Same flat rwx mapping for everything
> + * 4 KB granule: 16 level 3 entries, with contiguous bit
> + * 16 KB granule: 4 level 3 entries, without contiguous bit
> + * 64 KB granule: 1 level 3 entry
> + */
> +#ifdef CONFIG_EFI_PAYLOAD
> +#define PBL_SEGMENT_ALIGNSZ_64K
> +#else
> +#define PBL_SEGMENT_ALIGN4
> +#endif
> +
> #endif /* __ASM_ARM_MEMORY_H */
> diff --git a/arch/arm/lib/pbl.lds.S b/arch/arm/lib/pbl.lds.S
> index cafb27b2d55e..95929d7558bc 100644
> --- a/arch/arm/lib/pbl.lds.S
> +++ b/arch/arm/lib/pbl.lds.S
> @@ -5,6 +5,24 @@
> #include
> #include
> #include
> +#include
> +
> +/*
> + * The size of the PE/COFF section that covers the barebox image, which
> + * runs from _stext to _edata, must be a round multiple of the PE/COFF
> + * FileAlignment, which we set to its minimum value of 0x200. '_stext'
> + * itself must be 4 KB aligned, because that's what the adrp instructions
> + * expects, so padding out _edata to a 0x200 aligned boundary should be
> + * sufficient.
> + */
> +PECOFF_FILE_ALIGNMENT = 0x200;
> +
> +#ifdef CONFIG_EFI_STUB
> +#define PECOFF_EDATA_PADDING \
> + .pecoff_edata_padding : { BYTE(0); . = ALIGN(PECOFF_FILE_ALIGNMENT); }
> +#else
> +#define PECOFF_EDATA_PADDING
> +#endif
>
> #ifdef CONFIG_PBL_RELOCATABLE
> #define BASE 0x0
> --
> 2.39.2
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
