[PATCH] kernel: replace downstream get_mtd_device_by_node() implementation

2022-08-17 Thread Rafał Miłecki
From: Rafał Miłecki 

Use upstream of_get_mtd_device_by_node() which should behave pretty much
the same. Implementation differences:

get_mtd_device_by_node()  of_get_mtd_device_by_node()
  
np->dev.of_node   mtd_get_of_node(np)
-EPROBE_DEFER -ENODEV

Cc: Bernhard Frauendienst 
Cc: Bernhard Frauendienst 
Signed-off-by: Rafał Miłecki 
---
 ...-mtd-core-add-get_mtd_device_by_node.patch | 75 ---
 ...cat-add-dt-driver-for-concat-devices.patch |  2 +-
 ...-mtd-core-add-get_mtd_device_by_node.patch | 75 ---
 ...cat-add-dt-driver-for-concat-devices.patch |  2 +-
 4 files changed, 2 insertions(+), 152 deletions(-)
 delete mode 100644 
target/linux/generic/pending-5.10/495-mtd-core-add-get_mtd_device_by_node.patch
 delete mode 100644 
target/linux/generic/pending-5.15/495-mtd-core-add-get_mtd_device_by_node.patch

diff --git 
a/target/linux/generic/pending-5.10/495-mtd-core-add-get_mtd_device_by_node.patch
 
b/target/linux/generic/pending-5.10/495-mtd-core-add-get_mtd_device_by_node.patch
deleted file mode 100644
index 66017e1648..00
--- 
a/target/linux/generic/pending-5.10/495-mtd-core-add-get_mtd_device_by_node.patch
+++ /dev/null
@@ -1,75 +0,0 @@
-From 1bd1b740f208d1cf4071932cc51860d37266c402 Mon Sep 17 00:00:00 2001
-From: Bernhard Frauendienst 
-Date: Sat, 1 Sep 2018 00:30:11 +0200
-Subject: [PATCH 495/497] mtd: core: add get_mtd_device_by_node
-
-Add function to retrieve a mtd device by its OF node. Since drivers can
-assign arbitrary names to mtd devices in the absence of a label
-property, there is no other reliable way to retrieve a mtd device for a
-given OF node.
-
-Signed-off-by: Bernhard Frauendienst 
-Reviewed-by: Miquel Raynal 

- drivers/mtd/mtdcore.c   | 38 ++
- include/linux/mtd/mtd.h |  2 ++
- 2 files changed, 40 insertions(+)
-
 a/drivers/mtd/mtdcore.c
-+++ b/drivers/mtd/mtdcore.c
-@@ -1145,6 +1145,44 @@ out_unlock:
- }
- EXPORT_SYMBOL_GPL(get_mtd_device_nm);
- 
-+/**
-+ *get_mtd_device_by_node - obtain a validated handle for an MTD device
-+ *by of_node
-+ *@of_node: OF node of MTD device to open
-+ *
-+ *This function returns MTD device description structure in case of
-+ *success and an error code in case of failure.
-+ */
-+struct mtd_info *get_mtd_device_by_node(const struct device_node *of_node)
-+{
-+  int err = -ENODEV;
-+  struct mtd_info *mtd = NULL, *other;
-+
-+  mutex_lock(_table_mutex);
-+
-+  mtd_for_each_device(other) {
-+  if (of_node == other->dev.of_node) {
-+  mtd = other;
-+  break;
-+  }
-+  }
-+
-+  if (!mtd)
-+  goto out_unlock;
-+
-+  err = __get_mtd_device(mtd);
-+  if (err)
-+  goto out_unlock;
-+
-+  mutex_unlock(_table_mutex);
-+  return mtd;
-+
-+out_unlock:
-+  mutex_unlock(_table_mutex);
-+  return ERR_PTR(err);
-+}
-+EXPORT_SYMBOL_GPL(get_mtd_device_by_node);
-+
- void put_mtd_device(struct mtd_info *mtd)
- {
-   mutex_lock(_table_mutex);
 a/include/linux/mtd/mtd.h
-+++ b/include/linux/mtd/mtd.h
-@@ -697,6 +697,8 @@ extern int __get_mtd_device(struct mtd_i
- extern void __put_mtd_device(struct mtd_info *mtd);
- extern struct mtd_info *of_get_mtd_device_by_node(struct device_node *np);
- extern struct mtd_info *get_mtd_device_nm(const char *name);
-+extern struct mtd_info *get_mtd_device_by_node(
-+  const struct device_node *of_node);
- extern void put_mtd_device(struct mtd_info *mtd);
- 
- static inline uint64_t mtdpart_get_offset(const struct mtd_info *mtd)
diff --git 
a/target/linux/generic/pending-5.10/497-mtd-mtdconcat-add-dt-driver-for-concat-devices.patch
 
b/target/linux/generic/pending-5.10/497-mtd-mtdconcat-add-dt-driver-for-concat-devices.patch
index 058cab09e5..9b938a43f8 100644
--- 
a/target/linux/generic/pending-5.10/497-mtd-mtdconcat-add-dt-driver-for-concat-devices.patch
+++ 
b/target/linux/generic/pending-5.10/497-mtd-mtdconcat-add-dt-driver-for-concat-devices.patch
@@ -165,7 +165,7 @@ Signed-off-by: Bernhard Frauendienst 

 +  platform_set_drvdata(pdev, info);
 +
 +  of_for_each_phandle(, err, node, "devices", NULL, 0) {
-+  mtd = get_mtd_device_by_node(it.node);
++  mtd = of_get_mtd_device_by_node(it.node);
 +  if (IS_ERR(mtd)) {
 +  of_node_put(it.node);
 +  err = -EPROBE_DEFER;
diff --git 
a/target/linux/generic/pending-5.15/495-mtd-core-add-get_mtd_device_by_node.patch
 
b/target/linux/generic/pending-5.15/495-mtd-core-add-get_mtd_device_by_node.patch
deleted file mode 100644
index 3e14a1dd31..00
--- 
a/target/linux/generic/pending-5.15/495-mtd-core-add-get_mtd_device_by_node.patch
+++ /dev/null
@@ -1,75 +0,0 @@
-From 1bd1b740f208d1cf4071932cc51860d37266c402 Mon Sep 17 00:00:00 2001
-From: Bernhard Frauendienst 
-Date: Sat, 1 Sep 2018 00:30:11 

Re: [PATCH 6/7] tools: add 7z host package

2022-08-17 Thread Luiz Angelo Daros de Luca
> On Sun, Jul 31, 2022 at 03:36:32PM +0200, Sander Vanheule wrote:
> > On Sat, 2022-07-23 at 22:53 +0200, Jan Hoffmann wrote:
> > > Add the 7zr command line tool, which is a version of the 7z application
> > > that only supports 7z archives.
> > >
> > > 7z is one of the two compression formats supported in H3C firmware
> > > images (the alternative would be ARJ).
> > >
> > > (Alternatively, the 7zr command line tool could also be built from a
> > > current version of the public-domain LZMA SDK. That would require
> > > repackaging the source package, as it is only provided in 7z format.)
> > >
> > > Signed-off-by: Jan Hoffmann 
> >
> > This caused builds to fail on systems with GCC 12 (Arch, Fedora 36).
>
> Strange, I'm on archlinux with gcc 12.1.0 and it worked for me.
> Maybe it only fails in silent mode when warnings are treated as errors?
>
> Anyway, thanks for taking care of that!

It seems the issue is back. Tested with OpenSUSE Tumbleweed 20220813,
gcc (SUSE Linux) 12.1.1 20220721 [revision
4f15d2234608e82159d030dadb17af678cfad626],
even with 7z 22.01 version:

cc x86_64 -O2 -c -Wall -Werror -Wextra  -DNDEBUG -D_REENTRANT
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -f
PIC  -o _o/7zStream.o ../../../../C/7zStream.c
cc: warning: x86_64: linker input file unused because linking not done
cc: error: x86_64: linker input file not found: No such file or directory
make[3]: *** [../../7zip_gcc.mak:1070: _o/7zStream.o] Error 1

Regards,

Luiz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] build: revert 54070a1 (all kernels are >= 5.10)

2022-08-17 Thread Sebastian Kemper
Commit 54070a1 was added to allow building proper SDKs with kernels <
5.10. Now that all targets use at least kernel 5.10 it can be reverted.

Signed-off-by: Sebastian Kemper 
---
 include/kernel-defaults.mk | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 2e21392016..6687a58d1a 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -153,17 +153,12 @@ define Kernel/CopyImage
}
 endef

-# Always add "modules" so a proper Module.symvers file is written that
-# also contains symbols from the kernel modules. Without these symbols
-# external packages that depend on exported symbols from kernel modules
-# will fail to build.
 define Kernel/CompileImage/Default
rm -f $(TARGET_DIR)/init
-   +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if 
$(KERNELNAME),$(KERNELNAME),all) modules
+   +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if 
$(KERNELNAME),$(KERNELNAME),all)
$(call Kernel/CopyImage)
 endef

-# Here as well, always add "modules", see comment above.
 ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
 define Kernel/CompileImage/Initramfs
$(call Kernel/Configure/Initramfs)
@@ -185,7 +180,7 @@ endif
 # ?$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZ4),)
$(if 
$(CONFIG_TARGET_INITRAMFS_COMPRESSION_ZSTD),$(STAGING_DIR_HOST)/bin/zstd -T0 -f 
-o $(KERNEL_BUILD_DIR)/initrd.cpio.zstd $(KERNEL_BUILD_DIR)/initrd.cpio)
 endif
-   +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if 
$(KERNELNAME),$(KERNELNAME),all) modules
+   +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if 
$(KERNELNAME),$(KERNELNAME),all)
$(call Kernel/CopyImage,-initramfs)
 endef
 else
--
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] tplink-safeloader: add optional extra header for support-list

2022-08-17 Thread Nick French
Some TP-Link OEM firmwares add an extra len 0x18 header immediately
after the normal 0x8 byte parition header to support encrypted
partitions.

This extra header only applies to a subset of partitions.
For our purposes it only applies to the support-list partition.

The first 0x8 bytes are a flag to indicate if the contents are
encrypted or not, and the following 0x10 bytes form part of the
encryption key (used if flag is non-zero). Therefore an un-encrypted
parititon will have a zero-filled extra 0x18 bytes of header.

Add support to write this extra header for support-list partitions.

Note: currently only seen in the TP-Link Deco S4R v2, whose support
for factory images is only theoretical since all known OEM firmwares
require vendor-signed firmware updates, but that should not stop us
from generting valid factory images.

Signed-off-by: Nick French 
---
 src/tplink-safeloader.c | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index 7f9081d..babdea6 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -87,6 +87,7 @@ struct device_info {
const char *id;
const char *vendor;
const char *support_list;
+   uint32_t support_list_extra_header_len;
enum partition_trail_value part_trail;
struct {
enum soft_ver_type type;
@@ -1595,6 +1596,7 @@ static struct device_info boards[] = {

"{product_name:S4,product_ver:2.0.0,special_id:4A50}\n"

"{product_name:S4,product_ver:2.0.0,special_id:4155}\n"

"{product_name:S4,product_ver:2.0.0,special_id:4B52}\n",
+   .support_list_extra_header_len = 0x18,
.part_trail = 0x00,
.soft_ver = SOFT_VER_DEFAULT,
 
@@ -3029,11 +3031,11 @@ static inline bool meta_partition_should_pad(enum 
partition_trail_value pv)
  * If the `data` pointer is NULL, then the required space is only allocated,
  * otherwise `data_len` bytes will be copied from `data` into the partition
  * entry. */
-static struct image_partition_entry init_meta_partition_entry(
+static struct image_partition_entry 
init_meta_partition_entry_with_extra_header(
const char *name, const void *data, uint32_t data_len,
-   enum partition_trail_value pad_value)
+   enum partition_trail_value pad_value, uint32_t extra_header_len)
 {
-   uint32_t total_len = sizeof(struct meta_header) + data_len;
+   uint32_t total_len = sizeof(struct meta_header) + extra_header_len + 
data_len;
if (meta_partition_should_pad(pad_value))
total_len += 1;
 
@@ -3049,8 +3051,10 @@ static struct image_partition_entry 
init_meta_partition_entry(
header->length = htonl(data_len);
header->zero = 0;
 
-   if (data)
-   memcpy(entry.data+sizeof(*header), data, data_len);
+   if (data) {
+   memset(entry.data+sizeof(*header),0,extra_header_len);
+   memcpy(entry.data+sizeof(*header)+extra_header_len, data, 
data_len);
+   }
 
if (meta_partition_should_pad(pad_value))
entry.data[total_len - 1] = (uint8_t) pad_value;
@@ -3058,6 +3062,14 @@ static struct image_partition_entry 
init_meta_partition_entry(
return entry;
 }
 
+static struct image_partition_entry init_meta_partition_entry(
+const char *name, const void *data, uint32_t data_len,
+enum partition_trail_value pad_value)
+{
+   static const uint32_t NO_EXTRA_HEADER = 0;
+   return init_meta_partition_entry_with_extra_header(name, data, 
data_len, pad_value, NO_EXTRA_HEADER);
+}
+
 /** Allocates a new image partition */
 static struct image_partition_entry alloc_image_partition(const char *name, 
size_t len) {
struct image_partition_entry entry = {name, len, malloc(len)};
@@ -3191,8 +3203,9 @@ static struct image_partition_entry make_support_list(
const struct device_info *info)
 {
uint32_t len = strlen(info->support_list);
-   return init_meta_partition_entry(info->partition_names.support_list, 
info->support_list,
-   len, info->part_trail);
+
+   return 
init_meta_partition_entry_with_extra_header(info->partition_names.support_list, 
info->support_list,
+   len, info->part_trail, info->support_list_extra_header_len);
 }
 
 /** Partition with extra-para data */
-- 
2.37.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: Setting Linux Capabilities

2022-08-17 Thread Daniel Golle
On Wed, Aug 17, 2022 at 09:15:12AM +, Ravi Paluri (QUIC) wrote:
> > OpenWrt has procd-ujail, to set capabilities with it:
> > https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L80
> > https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/ntpd.capabilities
> 
> Thanks Etienne for the pointers and letting us know that jailing needs to be 
> enabled for capabilities to work.

You can also use procd/ujail to just drop/set capabilities WITHOUT
having to use the chroot-jail and other functionality at the same time.

> 
> Thanks,
> Ravi
> 
> -Original Message-
> From: Etienne Champetier  
> Sent: Tuesday, August 16, 2022 5:34 PM
> To: Ravi Paluri (QUIC) 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: Setting Linux Capabilities
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary of 
> any links or attachments, and do not enable macros.
> 
> Hi Ravi,
> 
> Le mar. 16 août 2022 à 07:52, Ravi Paluri (QUIC)  a 
> écrit :
> >
> > Hi Team,
> > We would like to set below capabilities for our process.
> > * CAP_NET_ADMIN
> > * CAP_NET_RAW
> >
> > Do we need to use APIs mentioned in 
> > https://linux.die.net/man/3/cap_set_flag and 
> > https://linux.die.net/man/3/cap_set_proc to get this functionality?
> >
> > On Systemd, I see that this can be achieved by writing below lines in a 
> > service file.
> > CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW 
> > AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW
> >
> > So, would like to know if there is any thing similar that can be done in 
> > procd init scripts?
> 
> OpenWrt has procd-ujail, to set capabilities with it:
> https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L80
> https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/ntpd.capabilities
> 
> Best
> Etienne
> 
> > Thanks,
> > Ravi
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: Setting Linux Capabilities

2022-08-17 Thread Ravi Paluri (QUIC)
> OpenWrt has procd-ujail, to set capabilities with it:
> https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L80
> https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/ntpd.capabilities

Thanks Etienne for the pointers and letting us know that jailing needs to be 
enabled for capabilities to work.

Thanks,
Ravi

-Original Message-
From: Etienne Champetier  
Sent: Tuesday, August 16, 2022 5:34 PM
To: Ravi Paluri (QUIC) 
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: Setting Linux Capabilities

WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.

Hi Ravi,

Le mar. 16 août 2022 à 07:52, Ravi Paluri (QUIC)  a 
écrit :
>
> Hi Team,
> We would like to set below capabilities for our process.
> * CAP_NET_ADMIN
> * CAP_NET_RAW
>
> Do we need to use APIs mentioned in https://linux.die.net/man/3/cap_set_flag 
> and https://linux.die.net/man/3/cap_set_proc to get this functionality?
>
> On Systemd, I see that this can be achieved by writing below lines in a 
> service file.
> CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW 
> AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW
>
> So, would like to know if there is any thing similar that can be done in 
> procd init scripts?

OpenWrt has procd-ujail, to set capabilities with it:
https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L80
https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/ntpd.capabilities

Best
Etienne

> Thanks,
> Ravi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: [EXT] Re: [PATCH] imx: add imx8mplus platform support

2022-08-17 Thread Andy Tang
Hi Piotr,

Thanks for your valuable suggestions.

I will address most of your concern.
Some responses are inline.

> -Original Message-
> From: Piotr Dymacz 
> Sent: 2022年8月16日 19:16
> To: Andy Tang 
> Cc: openwrt-devel@lists.openwrt.org; Rafał Miłecki ;
> Petr Štetiar 
> Subject: [EXT] Re: [PATCH] imx: add imx8mplus platform support
> 
> Caution: EXT Email
> 
> Hi Andy,
> 
> Sorry for late reply. Please, see my comments inline below.
> 
> Rafał, Petr, it would be great if you could give your thoughts regarding my
> concerns about the 'firmware-imx' package.
> > > +++ b/package/firmware/imx/Makefile
> > @@ -0,0 +1,47 @@
> > +# SPDX-License-Identifier: GPL-2.0-only # # Copyright 2022 NXP #
> > +
> > +include $(TOPDIR)/rules.mk
> > +
> > +PKG_NAME:=firmware-imx
> > +PKG_VERSION:=8.15
> > +PKG_RELEASE:=1
> > +
> > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).bin
> >
> +PKG_SOURCE_URL:=https://eur01.safelinks.protection.outlook.com/?url=h
> >
> +ttps%3A%2F%2Fwww.nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2F&
> amp;data=05
> >
> +%7C01%7Candy.tang%40nxp.com%7C3b32776df9fc458bdc3308da7f78c352
> %7C686e
> >
> +a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637962453910142398%7C
> Unknown%7
> >
> +CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJX
> >
> +VCI6Mn0%3D%7C3000%7C%7C%7Csdata=XYCuUHEbBXHxYglYSPaox
> nQVEGD0ivXF
> > +Ci0MaZllnKk%3Dreserved=0
> > +PKG_HASH:=ef91390da6c8a6a48c8121a5dd667de8
> 
> OK, so a 'firmware-imx-8.15.bin' file, hosted somewhere on NXP servers
> which seems to be a self-extracting package with bunch of proprietary binary
> blobs and almost 700 lines license. And it asks for EULA acceptance when
> extracting:
> 
> "Welcome to NXP firmware-imx-8.15.bin
> 
> You need to read and accept the EULA before you can continue.
> 
> LA_OPT_NXP_Software_License v34 February 2022 [...] "
> I don't think we can accept this (Rafał, Petr, any opinions?). Looking at 
> other
> open source projects, e.g. Barebox requires users to manually obtain and
> extract the firmware [1]. U-Boot documentation for this board mentions only
> the DDR training and ATF firmware [2].
> 
> Are all the blobs really required by this platform? Is there any other, more
> open source friendly way to get these binary blobs?
Since the license issue, these blobs have been released together.
This is the only format to release these binaries even though not all of them 
are used on a specific platform.

If this is not acceptable, what's your suggestion for it? Let the user do this 
manually?

> > +endef
> > +TARGET_DEVICES += imx8mplus
> > diff --git a/target/linux/imx/image/mkits-multiple-config.sh
> > b/target/linux/imx/image/mkits-multiple-config.sh
> > new file mode 100755
> > index 00..0d83f9e34d
> > --- /dev/null
> > +++ b/target/linux/imx/image/mkits-multiple-config.sh
> 
> [snip]
> 
> Maybe instead of introducing another copy of the same script (see the
> 'layerscape' target) you could reuse existing one and make some generic
> image commands out of it?
Could you please instruct me how I can reuse the script that belongs to other 
targets like this?

BR,
Andy

> 
> > diff --git a/target/linux/imx/imx8/config-5.15
> > b/target/linux/imx/imx8/config-5.15
> > new file mode 100644
> > index 00..2b6ab299a0
> > --- /dev/null
> > +++ b/target/linux/imx/imx8/config-5.15
> > @@ -0,0 +1,2661 @@
> 
> [snip]
> 
> > diff --git a/target/linux/imx/imx8/target.mk
> > b/target/linux/imx/imx8/target.mk new file mode 100644 index
> > 00..f990298d80
> > --- /dev/null
> > +++ b/target/linux/imx/imx8/target.mk
> > @@ -0,0 +1,11 @@
> > +# SPDX-License-Identifier: GPL-2.0-only # # Copyright 2022 NXP
> > +
> > +ARCH:=aarch64
> > +BOARDNAME:=NXP i.MX8 boards
> > +KERNELNAME:=Image
> > +
> > +define Target/Description
> > + Build firmware images for NXP imx8 boards.
> > +endef
> > diff --git
> > a/target/linux/imx/patches-5.15/0001-fix-the-compiling-error.patch
> > b/target/linux/imx/patches-5.15/0001-fix-the-compiling-error.patch
> > new file mode 100644
> > index 00..bd2cd68be8
> > --- /dev/null
> > +++ b/target/linux/imx/patches-5.15/0001-fix-the-compiling-error.patch
> > @@ -0,0 +1,39 @@
> > +From b671acdd69098b12ff7f567b1b6211ab4f38bf20 Mon Sep 17 00:00:00
> > +2001
> > +From: Yuantian Tang 
> > +Date: Tue, 28 Jun 2022 14:26:12 +0800
> > +Subject: [PATCH] fix the compiling error
> 
> Please, be more specific.
> 
> > +
> > +Signed-off-by: Andy Tang 
> > +---
> > + arch/arm64/kvm/hyp/nvhe/gen-hyprel.c | 1 +
> > + scripts/Makefile | 2 +-
> > + 2 files changed, 2 insertions(+), 1 deletion(-)
> > +
> > +diff --git a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> > +b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> > +index 6bc88a756cb7..99506facd30e 100644
> > +--- a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> >  b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> > +@@ -36,6 +36,7 @@
> > + #include 
> > + #include 
> > + #include 
> > ++#include 
> > +
> > + #include 
> > +
> > +diff --git a/scripts/Makefile