mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* [PATCH] ARM64: let 'end' point after the range in cache functions
@ 2024-04-12 16:28 Enrico Scholz
  2024-04-16 11:55 ` Sascha Hauer
  2024-04-16 12:02 ` Sascha Hauer
  0 siblings, 2 replies; 4+ messages in thread
From: Enrico Scholz @ 2024-04-12 16:28 UTC (permalink / raw)
  To: barebox; +Cc: Enrico Scholz

From: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>

v8_flush_dcache_range() and v8_inv_dcache_range() are implemented
under the assumption that their 'end' parameter points *after* the
range.

Fix callers to use it in this way.

This fixes e.g. spurious corruptions in the last octet when sending
129 bytes over ethernet.

Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
---
 arch/arm/cpu/dma_64.c | 2 +-
 arch/arm/cpu/mmu_64.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/dma_64.c b/arch/arm/cpu/dma_64.c
index 74d7167860c2..b50572f5e601 100644
--- a/arch/arm/cpu/dma_64.c
+++ b/arch/arm/cpu/dma_64.c
@@ -6,7 +6,7 @@ void arch_sync_dma_for_device(void *vaddr, size_t size,
                               enum dma_data_direction dir)
 {
 	unsigned long start = (unsigned long)vaddr;
-	unsigned long end = start + size - 1;
+	unsigned long end = start + size;
 
 	if (dir == DMA_FROM_DEVICE)
 		v8_inv_dcache_range(start, end);
diff --git a/arch/arm/cpu/mmu_64.c b/arch/arm/cpu/mmu_64.c
index 12cd644de0c7..b48e4732b86d 100644
--- a/arch/arm/cpu/mmu_64.c
+++ b/arch/arm/cpu/mmu_64.c
@@ -282,7 +282,7 @@ void mmu_disable(void)
 void dma_inv_range(void *ptr, size_t size)
 {
 	unsigned long start = (unsigned long)ptr;
-	unsigned long end = start + size - 1;
+	unsigned long end = start + size;
 
 	v8_inv_dcache_range(start, end);
 }
@@ -290,7 +290,7 @@ void dma_inv_range(void *ptr, size_t size)
 void dma_flush_range(void *ptr, size_t size)
 {
 	unsigned long start = (unsigned long)ptr;
-	unsigned long end = start + size - 1;
+	unsigned long end = start + size;
 
 	v8_flush_dcache_range(start, end);
 }
-- 
2.44.0




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ARM64: let 'end' point after the range in cache functions
  2024-04-12 16:28 [PATCH] ARM64: let 'end' point after the range in cache functions Enrico Scholz
@ 2024-04-16 11:55 ` Sascha Hauer
  2024-04-16 12:02 ` Sascha Hauer
  1 sibling, 0 replies; 4+ messages in thread
From: Sascha Hauer @ 2024-04-16 11:55 UTC (permalink / raw)
  To: barebox, Enrico Scholz


On Fri, 12 Apr 2024 18:28:35 +0200, Enrico Scholz wrote:
> v8_flush_dcache_range() and v8_inv_dcache_range() are implemented
> under the assumption that their 'end' parameter points *after* the
> range.
> 
> Fix callers to use it in this way.
> 
> This fixes e.g. spurious corruptions in the last octet when sending
> 129 bytes over ethernet.
> 
> [...]

Applied, thanks!

[1/1] ARM64: let 'end' point after the range in cache functions
      https://git.pengutronix.de/cgit/barebox/commit/?id=65ef5d885263 (link may not be stable)

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ARM64: let 'end' point after the range in cache functions
  2024-04-12 16:28 [PATCH] ARM64: let 'end' point after the range in cache functions Enrico Scholz
  2024-04-16 11:55 ` Sascha Hauer
@ 2024-04-16 12:02 ` Sascha Hauer
  2024-04-16 12:10   ` Enrico Scholz
  1 sibling, 1 reply; 4+ messages in thread
From: Sascha Hauer @ 2024-04-16 12:02 UTC (permalink / raw)
  To: Enrico Scholz; +Cc: barebox

Hi Enrico,

On Fri, Apr 12, 2024 at 06:28:35PM +0200, Enrico Scholz wrote:
> From: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
> 
> v8_flush_dcache_range() and v8_inv_dcache_range() are implemented
> under the assumption that their 'end' parameter points *after* the
> range.
> 
> Fix callers to use it in this way.
> 
> This fixes e.g. spurious corruptions in the last octet when sending
> 129 bytes over ethernet.

So 129 bytes are sent from barebox, right? Which network driver driver
is involved on the barebox side here? How did you force sending excatly
129 bytes?

I am asking because I want to look if there are other bugs invlolved
here.

Sascha

> 
> Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
> ---
>  arch/arm/cpu/dma_64.c | 2 +-
>  arch/arm/cpu/mmu_64.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/dma_64.c b/arch/arm/cpu/dma_64.c
> index 74d7167860c2..b50572f5e601 100644
> --- a/arch/arm/cpu/dma_64.c
> +++ b/arch/arm/cpu/dma_64.c
> @@ -6,7 +6,7 @@ void arch_sync_dma_for_device(void *vaddr, size_t size,
>                                enum dma_data_direction dir)
>  {
>  	unsigned long start = (unsigned long)vaddr;
> -	unsigned long end = start + size - 1;
> +	unsigned long end = start + size;
>  
>  	if (dir == DMA_FROM_DEVICE)
>  		v8_inv_dcache_range(start, end);
> diff --git a/arch/arm/cpu/mmu_64.c b/arch/arm/cpu/mmu_64.c
> index 12cd644de0c7..b48e4732b86d 100644
> --- a/arch/arm/cpu/mmu_64.c
> +++ b/arch/arm/cpu/mmu_64.c
> @@ -282,7 +282,7 @@ void mmu_disable(void)
>  void dma_inv_range(void *ptr, size_t size)
>  {
>  	unsigned long start = (unsigned long)ptr;
> -	unsigned long end = start + size - 1;
> +	unsigned long end = start + size;
>  
>  	v8_inv_dcache_range(start, end);
>  }
> @@ -290,7 +290,7 @@ void dma_inv_range(void *ptr, size_t size)
>  void dma_flush_range(void *ptr, size_t size)
>  {
>  	unsigned long start = (unsigned long)ptr;
> -	unsigned long end = start + size - 1;
> +	unsigned long end = start + size;
>  
>  	v8_flush_dcache_range(start, end);
>  }
> -- 
> 2.44.0
> 
> 
> 

-- 
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-5555 |



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ARM64: let 'end' point after the range in cache functions
  2024-04-16 12:02 ` Sascha Hauer
@ 2024-04-16 12:10   ` Enrico Scholz
  0 siblings, 0 replies; 4+ messages in thread
From: Enrico Scholz @ 2024-04-16 12:10 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox

Sascha Hauer <s.hauer@pengutronix.de> writes:

> So 129 bytes are sent from barebox, right? Which network driver driver
> is involved on the barebox side here? How did you force sending excatly
> 129 bytes?

drivers/net/bcmgenet.c;  I made a

diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index 9e0bacb31adf..988324cd22d4 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c
@@ -272,6 +272,10 @@ static int bcmgenet_gmac_eth_send(struct eth_device *edev, void *packet, int len
 	u32 tries = 100;
 	dma_addr_t dma;
 
+	if (length == 129)
+		print_hex_dump(KERN_INFO, "D ", DUMP_PREFIX_OFFSET,
+			       16, 4, packet + 125, 4, 1);
+
 	prod_index = readl(priv->mac_reg + TDMA_PROD_INDEX);
 
 	dma = dma_map_single(priv->dev, packet, length, DMA_TO_DEVICE);


there to verify the input data and checked with tcpdump on the other end
(which differed in around 70% of the cases in the last byte).

Packets with arbitrary length can be constructed easily by custom tftp
filenames.



Enrico



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-04-16 12:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-12 16:28 [PATCH] ARM64: let 'end' point after the range in cache functions Enrico Scholz
2024-04-16 11:55 ` Sascha Hauer
2024-04-16 12:02 ` Sascha Hauer
2024-04-16 12:10   ` Enrico Scholz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox