[Buildroot] [PATCH 1/1] package/sunxi-mali-utgard-driver: fix patch fuzz

[Buildroot] [PATCH 1/1] package/sunxi-mali-utgard-driver: fix patch fuzz

[Dario Binacchi]

Commit 8f88a644ed7d6 ("support/scripts/apply-patches.sh: set the maximum
fuzz factor to 0") reduced the fuzz factor.

Due to this change, sunxi-mali-utgard-driver fails to build with output:

    - r6p2:

        Applying 0018-mali-support-building-against-4.20.patch using series:
	patching file src/devicedrv/mali/linux/mali_kernel_linux.c
	Hunk #1 succeeded at 1125 (offset 193 lines).
	patching file src/devicedrv/mali/linux/mali_kernel_linux.h
	Hunk #1 FAILED at 16.
	Hunk #2 succeeded at 33 (offset 5 lines).
	1 out of 2 hunks FAILED -- saving rejects to file src/devicedrv/mali/linux/mali_kernel_linux.h.rej

    -r8p1:

	Applying r6p2/0013-mali-support-building-against-4.15.patch using series:
	patching file src/devicedrv/mali/common/mali_control_timer.c
	patching file src/devicedrv/mali/common/mali_group.c
	Hunk #2 FAILED at 1768.
	1 out of 2 hunks FAILED -- saving rejects to file src/devicedrv/mali/common/mali_group.c.rej
	patching file src/devicedrv/mali/common/mali_osk_types.h
	patching file src/devicedrv/mali/linux/mali_memory_os_alloc.c
	Hunk #1 succeeded at 202 (offset -2 lines).
	patching file src/devicedrv/mali/linux/mali_osk_timers.c

	Applying 0020-mali-support-building-against-4.17.patch using series:
	patching file src/devicedrv/mali/linux/mali_memory.c
	Hunk #1 FAILED at 57.
	1 out of 1 hunk FAILED -- saving rejects to file src/devicedrv/mali/linux/mali_memory.c.rej

This commit fixes the driver patches on the current package version.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
 ...he-patches-to-be-applied-with-fuzz-0.patch | 317 ++++++++++++++++++
 1 file changed, 317 insertions(+)
 create mode 100644 package/sunxi-mali-utgard-driver/0002-Update-the-patches-to-be-applied-with-fuzz-0.patch

diff --git a/package/sunxi-mali-utgard-driver/0002-Update-the-patches-to-be-applied-with-fuzz-0.patch b/package/sunxi-mali-utgard-driver/0002-Update-the-patches-to-be-applied-with-fuzz-0.patch
new file mode 100644
index 000000000000..00e313a57d9a
--- /dev/null
+++ b/package/sunxi-mali-utgard-driver/0002-Update-the-patches-to-be-applied-with-fuzz-0.patch
@@ -0,0 +1,317 @@
+From 6aed6098e4bdfeef87ae7003bfcff03df7b2e13e Mon Sep 17 00:00:00 2001
+From: Dario Binacchi <dario.binacchi@amarulasolutions.com>
+Date: Tue, 9 Jul 2024 18:39:08 +0200
+Subject: [PATCH] Update the patches to be applied with fuzz 0
+
+This driver, used in Buildroot for versions r6p2 and r8p1, fails to apply
+some patches after the commit 8f88a644ed7d6 ("support/scripts/apply-patches.sh:
+set the maximum fuzz factor to 0") has been merged.
+
+This commit fixes those patches so that they can be applied with fuzz
+factor 0, without causing regressions for any of the Mali versions,
+including those not used in Buildroot.
+
+Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
+Upstream: https://github.com/giuliobenetti/sunxi-mali/pull/2
+---
+ ...8-mali-support-building-against-4.20.patch |  87 ++++++++++++
+ patches/r6p2/series                           |   2 +-
+ ...3-mali-support-building-against-4.15.patch | 127 ++++++++++++++++++
+ ...0-mali-support-building-against-4.17.patch |  21 +++
+ patches/r8p1/series                           |   6 +-
+ 5 files changed, 239 insertions(+), 4 deletions(-)
+ create mode 100644 patches/r6p2/0018-mali-support-building-against-4.20.patch
+ create mode 100644 patches/r8p1/0013-mali-support-building-against-4.15.patch
+ create mode 100644 patches/r8p1/0020-mali-support-building-against-4.17.patch
+
+diff --git a/patches/r6p2/0018-mali-support-building-against-4.20.patch b/patches/r6p2/0018-mali-support-building-against-4.20.patch
+new file mode 100644
+index 000000000000..aac891ee1af3
+--- /dev/null
++++ b/patches/r6p2/0018-mali-support-building-against-4.20.patch
+@@ -0,0 +1,87 @@
++From ab90dcd9c5c33d3c26f2553f63dcd1837ce49d79 Mon Sep 17 00:00:00 2001
++From: Roman Stratiienko <roman.stratiienko@globallogic.com>
++Date: Wed, 28 Nov 2018 14:23:57 +0200
++Subject: [PATCH] mali: support building against 4.20
++
++From 4.20 kernel vm_insert_pfn was dropped
++This makes wrapper to preserve compatibility
++
++Also get_monotonic_boottime(...) was removed from 4.20
++Replace it with ktime_get_boot_ns()
++
++Signed-off-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
++---
++ src/devicedrv/mali/linux/mali_kernel_linux.c | 11 +++++++++++
++ src/devicedrv/mali/linux/mali_kernel_linux.h | 10 ++++++++++
++ src/devicedrv/mali/linux/mali_osk_time.c     |  4 ++++
++ 3 files changed, 25 insertions(+)
++
++diff --git a/src/devicedrv/mali/linux/mali_kernel_linux.c b/src/devicedrv/mali/linux/mali_kernel_linux.c
++index 34cb3d7..6ed89a6 100755
++--- a/src/devicedrv/mali/linux/mali_kernel_linux.c
+++++ b/src/devicedrv/mali/linux/mali_kernel_linux.c
++@@ -1125,6 +1125,17 @@
++ 	return err;
++ }
++ 
+++/*
+++ * From 4.20.0 kernel vm_insert_pfn was dropped
+++ * Make wrapper to preserve compatibility
+++ */
+++#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0)
+++int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
+++		  unsigned long pfn)
+++{
+++	return vm_fault_to_errno(vmf_insert_pfn(vma, addr, pfn), 0xffff);
+++}
+++#endif
++ 
++ module_init(mali_module_init);
++ module_exit(mali_module_exit);
++diff --git a/src/devicedrv/mali/linux/mali_kernel_linux.h b/src/devicedrv/mali/linux/mali_kernel_linux.h
++index 8548c9f..f858a5c 100755
++--- a/src/devicedrv/mali/linux/mali_kernel_linux.h
+++++ b/src/devicedrv/mali/linux/mali_kernel_linux.h
++@@ -16,6 +16,7 @@
++ #endif
++ 
++ #include <linux/cdev.h>     /* character device definitions */
+++#include <linux/mm.h>
++ #include <linux/idr.h>
++ #include <linux/rbtree.h>
++ #include "mali_kernel_license.h"
++@@ -33,6 +34,15 @@
++ #define __GFP_REPEAT __GFP_RETRY_MAYFAIL
++ #endif
++ 
+++/*
+++ * From 4.20.0 kernel vm_insert_pfn was dropped
+++ * Make wrapper to preserve compatibility
+++ */
+++#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0)
+++extern int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
+++			 unsigned long pfn);
+++#endif
+++
++ #ifdef __cplusplus
++ }
++ #endif
++diff --git a/src/devicedrv/mali/linux/mali_osk_time.c b/src/devicedrv/mali/linux/mali_osk_time.c
++index 4deaa10..a14cb7d 100755
++--- a/src/devicedrv/mali/linux/mali_osk_time.c
+++++ b/src/devicedrv/mali/linux/mali_osk_time.c
++@@ -53,7 +53,11 @@ u64 _mali_osk_time_get_ns(void)
++ 
++ u64 _mali_osk_boot_time_get_ns(void)
++ {
+++#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0)
+++	return ktime_get_boot_ns();
+++#else
++ 	struct timespec tsval;
++ 	get_monotonic_boottime(&tsval);
++ 	return (u64)timespec_to_ns(&tsval);
+++#endif
++ }
++-- 
++2.17.1
++
+diff --git a/patches/r6p2/series b/patches/r6p2/series
+index 8922fa49e5f6..c1ff18d1b522 100644
+--- a/patches/r6p2/series
++++ b/patches/r6p2/series
+@@ -14,7 +14,7 @@ r6p2/0013-mali-support-building-against-4.15.patch
+ r6p2/0014-mali-Make-devfreq-optional.patch
+ 0015-Enable-parallel-building-passing-variable-to-Makefile.patch
+ r6p2/0016-mali-support-building-against-4.16.patch
+-0018-mali-support-building-against-4.20.patch
++r6p2/0018-mali-support-building-against-4.20.patch
+ 0019-mali-support-building-against-5.0.patch
+ 0020-mali-support-building-against-4.17.patch
+ 0021-mali-support-building-against-5.3.patch
+diff --git a/patches/r8p1/0013-mali-support-building-against-4.15.patch b/patches/r8p1/0013-mali-support-building-against-4.15.patch
+new file mode 100644
+index 000000000000..ff6641a74f37
+--- /dev/null
++++ b/patches/r8p1/0013-mali-support-building-against-4.15.patch
+@@ -0,0 +1,127 @@
++From 5bc1f96c6e9b8927e3020fdfe58b2d99fa42bcb3 Mon Sep 17 00:00:00 2001
++From: John Stultz <john.stultz@linaro.org>
++Date: Thu, 16 Nov 2017 13:42:23 -0800
++Subject: MALI: v4.15-rc build fix
++
++Signed-off-by: John Stultz <john.stultz@linaro.org>
++---
++ src/devicedrv/mali/common/mali_control_timer.c  | 2 +-
++ src/devicedrv/mali/common/mali_group.c          | 8 +++++---
++ src/devicedrv/mali/common/mali_osk_types.h      | 8 +++++++-
++ src/devicedrv/mali/linux/mali_memory_os_alloc.c | 2 +-
++ src/devicedrv/mali/linux/mali_osk_timers.c      | 16 ++++++++++------
++ 5 files changed, 24 insertions(+), 12 deletions(-)
++
++--- a/src/devicedrv/mali/common/mali_control_timer.c
+++++ b/src/devicedrv/mali/common/mali_control_timer.c
++@@ -28,7 +28,7 @@ void mali_control_timer_add(u32 timeout)
++ 	_mali_osk_timer_add(mali_control_timer, _mali_osk_time_mstoticks(timeout));
++ }
++ 
++-static void mali_control_timer_callback(void *arg)
+++static void mali_control_timer_callback(struct timer_list *t)
++ {
++ 	if (mali_utilization_enabled()) {
++ 		struct mali_gpu_utilization_data *util_data = NULL;
++--- a/src/devicedrv/mali/common/mali_group.c
+++++ b/src/devicedrv/mali/common/mali_group.c
++@@ -44,7 +44,7 @@
++ static void mali_group_bottom_half_mmu(void *data);
++ static void mali_group_bottom_half_gp(void *data);
++ static void mali_group_bottom_half_pp(void *data);
++-static void mali_group_timeout(void *data);
+++static void mali_group_timeout(struct timer_list *t);
++ static void mali_group_reset_pp(struct mali_group *group);
++ static void mali_group_reset_mmu(struct mali_group *group);
++ 
++@@ -1761,9 +1761,11 @@
++ 				      0xFFFFFFFF, 0);
++ }
++ 
++-static void mali_group_timeout(void *data)
+++static void mali_group_timeout(struct timer_list *t)
++ {
++-	struct mali_group *group = (struct mali_group *)data;
+++	_mali_osk_timer_t *tim = container_of(t, _mali_osk_timer_t, timer);
+++	struct mali_group *group = container_of(&tim, struct mali_group, timeout_timer);
+++
++ 	MALI_DEBUG_ASSERT_POINTER(group);
++ 
++ 	MALI_DEBUG_PRINT(2, ("Group: timeout handler for %s at %u\n",
++--- a/src/devicedrv/mali/common/mali_osk_types.h
+++++ b/src/devicedrv/mali/common/mali_osk_types.h
++@@ -50,6 +50,7 @@ typedef unsigned long long u64;
++ #include <linux/types.h>
++ #endif
++ 
+++#include <linux/timer.h>
++ /** @brief Mali Boolean type which uses MALI_TRUE and MALI_FALSE
++   */
++ typedef unsigned long mali_bool;
++@@ -395,7 +396,12 @@ typedef struct _mali_osk_notification_t_
++  * by any callers of _mali_osk_timer_del(). Otherwise, a deadlock may occur.
++  *
++  * @param arg Function-specific data */
++-typedef void (*_mali_osk_timer_callback_t)(void *arg);
+++typedef void (*_mali_osk_timer_callback_t)(struct timer_list *t);
+++
+++
+++struct _mali_osk_timer_t_struct {
+++	struct timer_list timer;
+++};
++ 
++ /** @brief Private type for Timer Callback Objects */
++ typedef struct _mali_osk_timer_t_struct _mali_osk_timer_t;
++--- a/src/devicedrv/mali/linux/mali_memory_os_alloc.c
+++++ b/src/devicedrv/mali/linux/mali_memory_os_alloc.c
++@@ -202,7 +202,7 @@
++ 	/* Allocate new pages, if needed. */
++ 	for (i = 0; i < remaining; i++) {
++ 		dma_addr_t dma_addr;
++-		gfp_t flags = __GFP_ZERO | __GFP_REPEAT | __GFP_NOWARN | __GFP_COLD;
+++		gfp_t flags = __GFP_ZERO | __GFP_REPEAT | __GFP_NOWARN;
++ 		int err;
++ 
++ #if defined(CONFIG_ARM) && !defined(CONFIG_ARM_LPAE)
++--- a/src/devicedrv/mali/linux/mali_osk_timers.c
+++++ b/src/devicedrv/mali/linux/mali_osk_timers.c
++@@ -18,16 +18,25 @@
++ #include "mali_osk.h"
++ #include "mali_kernel_common.h"
++ 
++-struct _mali_osk_timer_t_struct {
++-	struct timer_list timer;
++-};
+++#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0)
+++
+++#define TIMER_DATA_TYPE		unsigned long
+++#define TIMER_FUNC_TYPE		void (*)(TIMER_DATA_TYPE)
+++
+++static inline void timer_setup(struct timer_list *timer,
+++			       void (*callback)(struct timer_list *),
+++			       unsigned int flags)
+++{
+++	__setup_timer(timer, (TIMER_FUNC_TYPE)callback,
+++		      (TIMER_DATA_TYPE)timer, flags);
+++}
+++#endif
++ 
++ typedef void (*timer_timeout_function_t)(unsigned long);
++ 
++ _mali_osk_timer_t *_mali_osk_timer_init(void)
++ {
++ 	_mali_osk_timer_t *t = (_mali_osk_timer_t *)kmalloc(sizeof(_mali_osk_timer_t), GFP_KERNEL);
++-	if (NULL != t) init_timer(&t->timer);
++ 	return t;
++ }
++ 
++@@ -65,8 +74,7 @@ mali_bool _mali_osk_timer_pending(_mali_
++ void _mali_osk_timer_setcallback(_mali_osk_timer_t *tim, _mali_osk_timer_callback_t callback, void *data)
++ {
++ 	MALI_DEBUG_ASSERT_POINTER(tim);
++-	tim->timer.data = (unsigned long)data;
++-	tim->timer.function = (timer_timeout_function_t)callback;
+++	timer_setup(&tim->timer, callback, 0);
++ }
++ 
++ void _mali_osk_timer_term(_mali_osk_timer_t *tim)
+diff --git a/patches/r8p1/0020-mali-support-building-against-4.17.patch b/patches/r8p1/0020-mali-support-building-against-4.17.patch
+new file mode 100644
+index 000000000000..3077f080f60d
+--- /dev/null
++++ b/patches/r8p1/0020-mali-support-building-against-4.17.patch
+@@ -0,0 +1,21 @@
++mali: support building against 4.17
++
++4.17 changed the return code of the fault handler from int to vm_fault_t.
++
++The return values don't change though, so we only need to update the prototype.
++
++Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
++
++--- a/src/devicedrv/mali/linux/mali_memory.c
+++++ b/src/devicedrv/mali/linux/mali_memory.c
++@@ -70,7 +70,9 @@
++ 	}
++ }
++ 
++-#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
+++#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 17, 0)
+++static vm_fault_t mali_mem_vma_fault(struct vm_fault *vmf)
+++#elif LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
++ static int mali_mem_vma_fault(struct vm_fault *vmf)
++ #else
++ static int mali_mem_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+diff --git a/patches/r8p1/series b/patches/r8p1/series
+index 564bf88a0ba1..15fdd50e7255 100644
+--- a/patches/r8p1/series
++++ b/patches/r8p1/series
+@@ -4,14 +4,14 @@
+ r6p2/0006-mali-Allow-devfreq-to-run-without-power-models.patch
+ r8p1/0011-mali-support-building-against-4.13.patch
+ 0012-mali-support-building-against-4.14.patch
+-r6p2/0013-mali-support-building-against-4.15.patch
++r8p1/0013-mali-support-building-against-4.15.patch
+ r6p2/0014-mali-Make-devfreq-optional.patch
+ 0015-Enable-parallel-building-passing-variable-to-Makefile.patch
+ r6p2/0016-mali-support-building-against-4.16.patch
+ r8p1/0017-mali-support-building-against-4.9-later.patch
+-0018-mali-support-building-against-4.20.patch
++r6p2/0018-mali-support-building-against-4.20.patch
+ 0019-mali-support-building-against-5.0.patch
+-0020-mali-support-building-against-4.17.patch
++r8p1/0020-mali-support-building-against-4.17.patch
+ 0021-mali-support-building-against-5.3.patch
+ r6p2/0022-mali-support-building-against-5.6.patch
+ 0023-mali-support-building-against-5.7.patch
+-- 
+2.43.0
+
-- 
2.43.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/sunxi-mali-utgard-driver: fix patch fuzz

[Thomas Petazzoni via buildroot]

Hello,

+Arnout in Cc.

On Thu, 11 Jul 2024 09:05:25 +0200
Dario Binacchi <dario.binacchi@amarulasolutions.com> wrote:

> Commit 8f88a644ed7d6 ("support/scripts/apply-patches.sh: set the maximum
> fuzz factor to 0") reduced the fuzz factor.
> 
> Due to this change, sunxi-mali-utgard-driver fails to build with output:
> 
>     - r6p2:
> 
>         Applying 0018-mali-support-building-against-4.20.patch using series:
> 	patching file src/devicedrv/mali/linux/mali_kernel_linux.c
> 	Hunk #1 succeeded at 1125 (offset 193 lines).
> 	patching file src/devicedrv/mali/linux/mali_kernel_linux.h
> 	Hunk #1 FAILED at 16.
> 	Hunk #2 succeeded at 33 (offset 5 lines).
> 	1 out of 2 hunks FAILED -- saving rejects to file src/devicedrv/mali/linux/mali_kernel_linux.h.rej
> 
>     -r8p1:
> 
> 	Applying r6p2/0013-mali-support-building-against-4.15.patch using series:
> 	patching file src/devicedrv/mali/common/mali_control_timer.c
> 	patching file src/devicedrv/mali/common/mali_group.c
> 	Hunk #2 FAILED at 1768.
> 	1 out of 2 hunks FAILED -- saving rejects to file src/devicedrv/mali/common/mali_group.c.rej
> 	patching file src/devicedrv/mali/common/mali_osk_types.h
> 	patching file src/devicedrv/mali/linux/mali_memory_os_alloc.c
> 	Hunk #1 succeeded at 202 (offset -2 lines).
> 	patching file src/devicedrv/mali/linux/mali_osk_timers.c
> 
> 	Applying 0020-mali-support-building-against-4.17.patch using series:
> 	patching file src/devicedrv/mali/linux/mali_memory.c
> 	Hunk #1 FAILED at 57.
> 	1 out of 1 hunk FAILED -- saving rejects to file src/devicedrv/mali/linux/mali_memory.c.rej
> 
> This commit fixes the driver patches on the current package version.
> 
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> ---
>  ...he-patches-to-be-applied-with-fuzz-0.patch | 317 ++++++++++++++++++
>  1 file changed, 317 insertions(+)
>  create mode 100644 package/sunxi-mali-utgard-driver/0002-Update-the-patches-to-be-applied-with-fuzz-0.patch

Thanks for the patch, but I'm not entirely sure that's how we want to
fix this issue. Indeed, apply-patches is used in quite a lot of
packages to apply patches from Debian. Do we want to fix all those
patches, like you did for the sunxi-mali-utgard-driver? I'm not sure.

So in the end, I'm wondering if apply-patches.sh shouldn't take an
argument that specifies whether we accept fuzz or not. We shouldn't
accept fuzz for patches provided by Buildroot itself, but perhaps we
should keep accepting fuzz for patches that are not part of Buildroot.

Arnout, since you accepted the patch changing the apply-patches.sh
behavior, what is your opinion on this?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/sunxi-mali-utgard-driver: fix patch fuzz

[Arnout Vandecappelle via buildroot]

On 11/07/2024 10:52, Thomas Petazzoni wrote:
> Hello,
> 
> +Arnout in Cc.
> 
> On Thu, 11 Jul 2024 09:05:25 +0200
> Dario Binacchi <dario.binacchi@amarulasolutions.com> wrote:
> 
>> Commit 8f88a644ed7d6 ("support/scripts/apply-patches.sh: set the maximum
>> fuzz factor to 0") reduced the fuzz factor.
>>
>> Due to this change, sunxi-mali-utgard-driver fails to build with output:
>>
>>      - r6p2:
>>
>>          Applying 0018-mali-support-building-against-4.20.patch using series:
>> 	patching file src/devicedrv/mali/linux/mali_kernel_linux.c
>> 	Hunk #1 succeeded at 1125 (offset 193 lines).
>> 	patching file src/devicedrv/mali/linux/mali_kernel_linux.h
>> 	Hunk #1 FAILED at 16.
>> 	Hunk #2 succeeded at 33 (offset 5 lines).
>> 	1 out of 2 hunks FAILED -- saving rejects to file src/devicedrv/mali/linux/mali_kernel_linux.h.rej
>>
>>      -r8p1:
>>
>> 	Applying r6p2/0013-mali-support-building-against-4.15.patch using series:
>> 	patching file src/devicedrv/mali/common/mali_control_timer.c
>> 	patching file src/devicedrv/mali/common/mali_group.c
>> 	Hunk #2 FAILED at 1768.
>> 	1 out of 2 hunks FAILED -- saving rejects to file src/devicedrv/mali/common/mali_group.c.rej
>> 	patching file src/devicedrv/mali/common/mali_osk_types.h
>> 	patching file src/devicedrv/mali/linux/mali_memory_os_alloc.c
>> 	Hunk #1 succeeded at 202 (offset -2 lines).
>> 	patching file src/devicedrv/mali/linux/mali_osk_timers.c
>>
>> 	Applying 0020-mali-support-building-against-4.17.patch using series:
>> 	patching file src/devicedrv/mali/linux/mali_memory.c
>> 	Hunk #1 FAILED at 57.
>> 	1 out of 1 hunk FAILED -- saving rejects to file src/devicedrv/mali/linux/mali_memory.c.rej
>>
>> This commit fixes the driver patches on the current package version.
>>
>> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>> ---
>>   ...he-patches-to-be-applied-with-fuzz-0.patch | 317 ++++++++++++++++++
>>   1 file changed, 317 insertions(+)
>>   create mode 100644 package/sunxi-mali-utgard-driver/0002-Update-the-patches-to-be-applied-with-fuzz-0.patch
> 
> Thanks for the patch, but I'm not entirely sure that's how we want to
> fix this issue. Indeed, apply-patches is used in quite a lot of
> packages to apply patches from Debian. Do we want to fix all those
> patches, like you did for the sunxi-mali-utgard-driver? I'm not sure.

  AFAIK, Debian patches should apply without fuzz (unless we do stupid stuff 
like applying our own patches first).

  I think this is the only case where we are downloading patches that have 
incorrect fuzz - or did you encounter any other case, Dario?

  And in this specific case, upstream is Giulio, so I expect that the PR will be 
accepted soon and we can simply bump.

> So in the end, I'm wondering if apply-patches.sh shouldn't take an
> argument that specifies whether we accept fuzz or not. We shouldn't
> accept fuzz for patches provided by Buildroot itself, but perhaps we
> should keep accepting fuzz for patches that are not part of Buildroot.

  I agree, but only if we actually encounter a situation where this is the case. 
Note that the implementation will not be super trivial (will require something 
like FOO_APPLY_PATCHES_FUZZ).


  Regards,
  Arnout

> Arnout, since you accepted the patch changing the apply-patches.sh
> behavior, what is your opinion on this?
> 
> Best regards,
> 
> Thomas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/sunxi-mali-utgard-driver: fix patch fuzz

[Thomas Petazzoni via buildroot]

Hello Arnout,

On Thu, 11 Jul 2024 11:51:11 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

> > Thanks for the patch, but I'm not entirely sure that's how we want to
> > fix this issue. Indeed, apply-patches is used in quite a lot of
> > packages to apply patches from Debian. Do we want to fix all those
> > patches, like you did for the sunxi-mali-utgard-driver? I'm not sure.  
> 
>   AFAIK, Debian patches should apply without fuzz (unless we do stupid stuff 
> like applying our own patches first).

Is this "should" based on actual experimentation/validation, or just
some general assumption?

>   I think this is the only case where we are downloading patches that have 
> incorrect fuzz - or did you encounter any other case, Dario?
> 
>   And in this specific case, upstream is Giulio, so I expect that the PR will be 
> accepted soon and we can simply bump.

Ah, I didn't realize we had an active upstream for this package.
Indeed, it means we will be able to drop our patch.

>   I agree, but only if we actually encounter a situation where this is the case. 
> Note that the implementation will not be super trivial (will require something 
> like FOO_APPLY_PATCHES_FUZZ).

Well, no, I was assuming $(APPLY_PATCHES) that is used in packages
would default to accepting fuzz, and only the $(APPLY_PATCHES) call in
our package infra, which applies our patches, would pass an option to
disable fuzz.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/sunxi-mali-utgard-driver: fix patch fuzz

[Arnout Vandecappelle via buildroot]

On 11/07/2024 12:04, Thomas Petazzoni wrote:
> Hello Arnout,
> 
> On Thu, 11 Jul 2024 11:51:11 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
> 
>>> Thanks for the patch, but I'm not entirely sure that's how we want to
>>> fix this issue. Indeed, apply-patches is used in quite a lot of
>>> packages to apply patches from Debian. Do we want to fix all those
>>> patches, like you did for the sunxi-mali-utgard-driver? I'm not sure.
>>
>>    AFAIK, Debian patches should apply without fuzz (unless we do stupid stuff
>> like applying our own patches first).
> 
> Is this "should" based on actual experimentation/validation, or just
> some general assumption?

  It is based on memory, from 10 years ago when I did something with Debian 
packaging, that patches are applied with fuzz 0. (Or at least, in most cases, 
when the packaging uses one of the standard packaging helpers.)


>>    I think this is the only case where we are downloading patches that have
>> incorrect fuzz - or did you encounter any other case, Dario?
>>
>>    And in this specific case, upstream is Giulio, so I expect that the PR will be
>> accepted soon and we can simply bump.
> 
> Ah, I didn't realize we had an active upstream for this package.
> Indeed, it means we will be able to drop our patch.
> 
>>    I agree, but only if we actually encounter a situation where this is the case.
>> Note that the implementation will not be super trivial (will require something
>> like FOO_APPLY_PATCHES_FUZZ).
> 
> Well, no, I was assuming $(APPLY_PATCHES) that is used in packages
> would default to accepting fuzz, and only the $(APPLY_PATCHES) call in
> our package infra, which applies our patches, would pass an option to
> disable fuzz.

  "Our" patches and Debian patches (i.e. stuff specified in FOO_PATCH) are 
applied in the same APPLY_PATCHES call at the moment I believe. So then it is 
only relevant for the 7 packages that have their own APPLY_PATCHES call, and of 
those sunxi-mali-utgard-driver is the only one that fails.

  Unless you want to make a case for allowing fuzz in custom patches e.g. for 
the kernel. But I don't actually think we want that (same problem as the thing 
that caused to fuzz to begin with).

  Also, apply-patches.sh currently doesn't have a way to specify fuzz.

  Regards,
  Arnout

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/sunxi-mali-utgard-driver: fix patch fuzz

[Dario Binacchi]

Hi All,

On Thu, Jul 11, 2024 at 12:04 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Arnout,
>
> On Thu, 11 Jul 2024 11:51:11 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
>
> > > Thanks for the patch, but I'm not entirely sure that's how we want to
> > > fix this issue. Indeed, apply-patches is used in quite a lot of
> > > packages to apply patches from Debian. Do we want to fix all those
> > > patches, like you did for the sunxi-mali-utgard-driver? I'm not sure.
> >
> >   AFAIK, Debian patches should apply without fuzz (unless we do stupid stuff
> > like applying our own patches first).
>
> Is this "should" based on actual experimentation/validation, or just
> some general assumption?
>
> >   I think this is the only case where we are downloading patches that have
> > incorrect fuzz - or did you encounter any other case, Dario?

There was also the libmad package that was failing, but fortunately it
wasn't necessary
to modify the downloaded patches. The commit
b21184a87733f2f2ccee69cade6875c507e439dc
has fixed the issue by reversing the order of patch application steps:

-LIBMAD_POST_PATCH_HOOKS += LIBMAD_APPLY_DEBIAN_PATCHES
+LIBMAD_PRE_PATCH_HOOKS += LIBMAD_APPLY_DEBIAN_PATCHES

This, along with sunxi-mali-utgard-driver, were the only two packages
with such an issue.

Thanks and regards,
Dario

> >
> >   And in this specific case, upstream is Giulio, so I expect that the PR will be
> > accepted soon and we can simply bump.
>
> Ah, I didn't realize we had an active upstream for this package.
> Indeed, it means we will be able to drop our patch.
>
> >   I agree, but only if we actually encounter a situation where this is the case.
> > Note that the implementation will not be super trivial (will require something
> > like FOO_APPLY_PATCHES_FUZZ).
>
> Well, no, I was assuming $(APPLY_PATCHES) that is used in packages
> would default to accepting fuzz, and only the $(APPLY_PATCHES) call in
> our package infra, which applies our patches, would pass an option to
> disable fuzz.
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com



-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binacchi@amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@amarulasolutions.com

www.amarulasolutions.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH] package/sunxi-mali-utgard-driver: bump to version 2024-07-11

[Giulio Benetti]

This version provide patches that can be applied with fuzz 0 and this is
now required by Buildroot.

Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
 package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash | 2 +-
 package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash b/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash
index be27a85970..5f3e001325 100644
--- a/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash
+++ b/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash
@@ -1,3 +1,3 @@
 # Locally calculated
-sha256  f2e5e671575d9488fd19b821d70e59952b6dbbb5b2036ea5462f811eec819370  sunxi-mali-utgard-driver-c4bc3e229c0e5f30c24c20ff1fb8db0e4a450c0f.tar.gz
+sha256  151a56eb6a47efee19369a1c08b7aec506e48f983683a3cd05c5494cedf0fb69  sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58.tar.gz
 sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  LICENSE
diff --git a/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk b/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk
index b8a12247d3..ba7c50718d 100644
--- a/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk
+++ b/package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-SUNXI_MALI_UTGARD_DRIVER_VERSION = c4bc3e229c0e5f30c24c20ff1fb8db0e4a450c0f
+SUNXI_MALI_UTGARD_DRIVER_VERSION = ad7e98bc1e81c7ac9c897f854c1a429d33e45d58
 SUNXI_MALI_UTGARD_DRIVER_SITE = $(call github,giuliobenetti,sunxi-mali,$(SUNXI_MALI_UTGARD_DRIVER_VERSION))
 SUNXI_MALI_UTGARD_DRIVER_DEPENDENCIES = linux
 SUNXI_MALI_UTGARD_DRIVER_LICENSE = GPL-2.0
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/sunxi-mali-utgard-driver: bump to version 2024-07-11

[Thomas Petazzoni via buildroot]

On Thu, 11 Jul 2024 21:15:39 +0200
Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:

> This version provide patches that can be applied with fuzz 0 and this is
> now required by Buildroot.
> 
> Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> ---
>  package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash | 2 +-
>  package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Thanks for this update. However it seems to not work here:

>>> sunxi-mali-utgard-driver ad7e98bc1e81c7ac9c897f854c1a429d33e45d58 Extracting
gzip -d -c /home/thomas/dl/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58.tar.gz | tar --strip-components=1 -C /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58   -xf -
>>> sunxi-mali-utgard-driver ad7e98bc1e81c7ac9c897f854c1a429d33e45d58 Patching

Applying 0001-build.sh-do-not-apply-patches.patch using patch: 
patching file build.sh
ln -sf /series /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/patches
TAR="tar" PATH=/home/thomas/projets/buildroot/output/host/bin:$PATH support/scripts/apply-patches.sh  /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/ /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/patches

Applying 0001-makefile-Add-install-target-and-build-the-module-by-.patch using patch: 
can't find file to patch at input line 16
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 063c492b89cdbb8739d04b5190105cf2c9e12e6f Mon Sep 17 00:00:00 2001
|From: Maxime Ripard <maxime.ripard@free-electrons.com>
|Date: Tue, 29 Nov 2016 10:11:12 +0100
|Subject: [PATCH 1/4] makefile: Add install target and build the module by
| default
|
|Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|---
| src/devicedrv/mali/Makefile | 7 ++++++-
| 1 file changed, 6 insertions(+), 1 deletion(-)
|
|diff --git a/src/devicedrv/mali/Makefile b/src/devicedrv/mali/Makefile
|index 44c7bb83981a..2fee5e096b51 100755
|--- a/src/devicedrv/mali/Makefile
|+++ b/src/devicedrv/mali/Makefile
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
make: *** [package/pkg-generic.mk:242: /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/.stamp_patched] Error 1

Am I doing something wrong?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/sunxi-mali-utgard-driver: bump to version 2024-07-11

[Giulio Benetti]

Hello Thomas, Dario,

On 12/07/24 09:09, Thomas Petazzoni wrote:
> On Thu, 11 Jul 2024 21:15:39 +0200
> Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:
> 
>> This version provide patches that can be applied with fuzz 0 and this is
>> now required by Buildroot.
>>
>> Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
>> ---
>>   package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash | 2 +-
>>   package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk   | 2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> Thanks for this update. However it seems to not work here:
> 
>>>> sunxi-mali-utgard-driver ad7e98bc1e81c7ac9c897f854c1a429d33e45d58 Extracting
> gzip -d -c /home/thomas/dl/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58.tar.gz | tar --strip-components=1 -C /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58   -xf -
>>>> sunxi-mali-utgard-driver ad7e98bc1e81c7ac9c897f854c1a429d33e45d58 Patching
> 
> Applying 0001-build.sh-do-not-apply-patches.patch using patch:
> patching file build.sh
> ln -sf /series /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/patches
> TAR="tar" PATH=/home/thomas/projets/buildroot/output/host/bin:$PATH support/scripts/apply-patches.sh  /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/ /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/patches
> 
> Applying 0001-makefile-Add-install-target-and-build-the-module-by-.patch using patch:
> can't find file to patch at input line 16
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |From 063c492b89cdbb8739d04b5190105cf2c9e12e6f Mon Sep 17 00:00:00 2001
> |From: Maxime Ripard <maxime.ripard@free-electrons.com>
> |Date: Tue, 29 Nov 2016 10:11:12 +0100
> |Subject: [PATCH 1/4] makefile: Add install target and build the module by
> | default
> |
> |Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> |---
> | src/devicedrv/mali/Makefile | 7 ++++++-
> | 1 file changed, 6 insertions(+), 1 deletion(-)
> |
> |diff --git a/src/devicedrv/mali/Makefile b/src/devicedrv/mali/Makefile
> |index 44c7bb83981a..2fee5e096b51 100755
> |--- a/src/devicedrv/mali/Makefile
> |+++ b/src/devicedrv/mali/Makefile
> --------------------------
> No file to patch.  Skipping patch.
> 1 out of 1 hunk ignored
> make: *** [package/pkg-generic.mk:242: /home/thomas/projets/buildroot/output/build/sunxi-mali-utgard-driver-ad7e98bc1e81c7ac9c897f854c1a429d33e45d58/.stamp_patched] Error 1
> 
> Am I doing something wrong?

This defconfig works at me:
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.6"
BR2_LINUX_KERNEL_DEFCONFIG="sunxi"
BR2_PACKAGE_SUNXI_MALI_UTGARD=y

Which defconfig are you using?

Note that at the moment both sunxi-mali-utgard-driver and mali-driver
fail to build after Linux version 6.6 due to new shrinker_*() API that
is not that easy to solve. I need more time to do that.

-- 
Giulio Benetti
CEO&CTO@Benetti Engineering
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/sunxi-mali-utgard-driver: bump to version 2024-07-11

[Thomas Petazzoni via buildroot]

On Thu, 11 Jul 2024 21:15:39 +0200
Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:

> This version provide patches that can be applied with fuzz 0 and this is
> now required by Buildroot.
> 
> Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> ---
>  package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.hash | 2 +-
>  package/sunxi-mali-utgard-driver/sunxi-mali-utgard-driver.mk   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/sunxi-mali-utgard-driver: bump to version 2024-07-11

[Thomas Petazzoni via buildroot]

On Fri, 12 Jul 2024 12:43:23 +0200
Giulio Benetti <giulio.benetti@benettiengineering.com> wrote:

> This defconfig works at me:
> BR2_arm=y
> BR2_cortex_a7=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.6"
> BR2_LINUX_KERNEL_DEFCONFIG="sunxi"
> BR2_PACKAGE_SUNXI_MALI_UTGARD=y

So, it was my fault. I didn't have BR2_PACKAGE_SUNXI_MALI_UTGARD=y, and
I just did "make sunxi-mali-utgard-driver-patch". But due to
BR2_PACKAGE_SUNXI_MALI_UTGARD not being enabled, SUNXI_MALI_UTGARD_REV
was empty in:

        ln -sf $(SUNXI_MALI_UTGARD_REV)/series $(@D)/patches

So indeed, having a defconfig with the right package enabled is
important in this case.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot