| Message ID | 20240711070525.1406612-1-dario.binacchi@amarulasolutions.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
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
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 To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
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
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 To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
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
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 +
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