Re: [linux-yocto][v5.15/standard/preempt-rt/base][PATCH] OF: DT-Overlay configfs interface (v8)

2023-05-30 Thread quanyang.wang via lists.yoctoproject.org

Hi Bruce,

I wrote the wrong branch information. It should be:

v6.1/standard/preempt-rt/base

v6.1/standard/base

And this patch will conflict with another patch ("Revert "OF: DT-Overlay 
configfs interface (v8)" I just sent which is


https://lists.yoctoproject.org/g/linux-yocto/topic/v6_1_standard_preempt_rt_sdkv6_1_xlnx_soc_patch/99215104?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,99215104,previd%3D1685429439939095335,nextid%3D1684520876284512837&previd=1685429439939095335&nextid=1684520876284512837

So the patch in the above URL should be applied first and then this patch.

Sorry for the inconvenience.

Thanks,

Quanyang

On 5/30/23 14:43, quanyang.wang via lists.yoctoproject.org wrote:

From: Pantelis Antoniou 

commit 999eb1a8fdc4512412c7bc519c895bc2a6fabbe0 from
https://github.com/Xilinx/linux-xlnx.git

Add a runtime interface to using configfs for generic device tree overlay
usage. With it its possible to use device tree overlays without having
to use a per-platform overlay manager.

Please see Documentation/devicetree/configfs-overlays.txt for more info.

Changes since v7:
- Xilinx alignment
- of: configfs: Fix error handling from of_overlay_create()
- of: configfs: lock while resolving and applying
- of: configfs: Fix memory leak in create overlay
- of: configfs: Fix compilation warning
- of: configfs: Use of_overlay_fdt_apply API call

Changes since v6:
- Default groups properties API changed.

Changes since v5:
- New style configfs.

Changes since v4:
- Loading fix for multiple overlays as found out by
   Geert Uytterhoeven 

Changes since v3:
- Fixed compilation on SPARC & Xtensa

Changes since v2:
- Removed ifdef CONFIG_OF_OVERLAY (since for now it's required)
- Created a documentation entry
- Slight rewording in Kconfig

Changes since v1:
- of_resolve() -> of_resolve_phandles().

Signed-off-by: Pantelis Antoniou 
Signed-off-by: Nava kishore Manne 
Signed-off-by: Radhey Shyam Pandey 
State: not-upstreamable
Signed-off-by: Liwei Song 
[Liwei: remove overlay_lock to fix "unused-variable" warning.]
Signed-off-by: Bruce Ashfield 
---
Hi Bruce,
Would you please help merge this patch to the branches:
v5.15/standard/preempt-rt/base
v5.15/standard/base
Thanks,
Quanyang
---
  .../devicetree/configfs-overlays.txt  |  31 ++
  drivers/of/Kconfig|  11 +
  drivers/of/Makefile   |   1 +
  drivers/of/configfs.c | 292 ++
  4 files changed, 335 insertions(+)
  create mode 100644 Documentation/devicetree/configfs-overlays.txt
  create mode 100644 drivers/of/configfs.c

diff --git a/Documentation/devicetree/configfs-overlays.txt 
b/Documentation/devicetree/configfs-overlays.txt
new file mode 100644
index 0..5fa43e0643072
--- /dev/null
+++ b/Documentation/devicetree/configfs-overlays.txt
@@ -0,0 +1,31 @@
+Howto use the configfs overlay interface.
+
+A device-tree configfs entry is created in /config/device-tree/overlays
+and and it is manipulated using standard file system I/O.
+Note that this is a debug level interface, for use by developers and
+not necessarily something accessed by normal users due to the
+security implications of having direct access to the kernel's device tree.
+
+* To create an overlay you mkdir the directory:
+
+   # mkdir /config/device-tree/overlays/foo
+
+* Either you echo the overlay firmware file to the path property file.
+
+   # echo foo.dtbo >/config/device-tree/overlays/foo/path
+
+* Or you cat the contents of the overlay to the dtbo file
+
+   # cat foo.dtbo >/config/device-tree/overlays/foo/dtbo
+
+The overlay file will be applied, and devices will be created/destroyed
+as required.
+
+To remove it simply rmdir the directory.
+
+   # rmdir /config/device-tree/overlays/foo
+
+The rationalle of the dual interface (firmware & direct copy) is that each is
+better suited to different use patterns. The firmware interface is what's
+intended to be used by hardware managers in the kernel, while the copy 
interface
+make sense for developers (since it avoids problems with namespaces).
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 80b5fd44ab1c7..da62bc6766952 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -94,4 +94,15 @@ config OF_DMA_DEFAULT_COHERENT
# arches should select this if DMA is coherent by default for OF devices
bool
  
+config OF_CONFIGFS

+   bool "Device Tree Overlay ConfigFS interface"
+   select CONFIGFS_FS
+   depends on OF_OVERLAY
+   help
+ Select this option to enable simple user-space driven DT overlay
+ interface to support device tree manipulated at runtime.
+ Say Y here to include this support.
+
+ If unsure, say N.
+
  endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e0360a44306e2..90c92ced24e62 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,6 +1,7 @@
  # SPDX-License-Identifier: GPL-2.0
 

Re: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 1/1] nxp-imx8: Enable Vivante GPU driver

2023-05-30 Thread Xiaolei Wang via lists.yoctoproject.org
Hi bruce

I found that this patch does not seem to be merged into the yocto-kernel-cache 
yocto-6.1 branch, can you help me merge it again

thanks
xiaolei

From: Bruce Ashfield 
Sent: Tuesday, May 9, 2023 6:12 AM
To: Wang, Xiaolei 
Cc: linux-yocto@lists.yoctoproject.org 
Subject: Re: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 1/1] nxp-imx8: 
Enable Vivante GPU driver

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

merged

FYI: Something mangled your author name in the patch.

I fixed it before pushing, but it is worth checking to see if something changed 
in your infrastructure.

Bruce

In message: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 1/1] nxp-imx8: 
Enable Vivante GPU driver
on 08/05/2023 Xiaolei Wang wrote:

> Enable Vivante GPU driver for nxp-imx8 bsp.
>
> Signed-off-by: Xiaolei Wang 
> ---
>  bsp/nxp-imx8/nxp-imx8.cfg | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg
> index d90837d3..a278850f 100644
> --- a/bsp/nxp-imx8/nxp-imx8.cfg
> +++ b/bsp/nxp-imx8/nxp-imx8.cfg
> @@ -262,6 +262,11 @@ CONFIG_DRM_GEM_SHMEM_HELPER=y
>  CONFIG_DRM_SCHED=m
>  CONFIG_DRM_ITE_IT6263=y
>
> +#
> +# MXC Vivante GPU support
> +#
> +CONFIG_MXC_GPU_VIV=y
> +
>  #
>  # I2C encoder or helper chips
>  #
> --
> 2.25.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12663): 
https://lists.yoctoproject.org/g/linux-yocto/message/12663
Mute This Topic: https://lists.yoctoproject.org/mt/98757130/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] yaffs_vfs warning

2023-05-30 Thread Bruce Ashfield
On Mon, May 29, 2023 at 11:41 PM He Zhe  wrote:
>
> Sorry for messy encoding...
>
>
> We met the following warning when build linux-yocto v6.1, introduced by 
> latter diff. It perhaps miscalculates the buf length.

Are you only seeing it with gcc-13 ?

That fix follows the same pattern as many other parts of the kernel,
and checking the 6.1 branch, those other subsystems still have similar
sprintf() changes in place:

i.e.:

switch (cmd) {
case BLKTRACESETUP:
snprintf(b, sizeof(b), "%pg", bdev);

So I don't see a miscalculation of the buffer length in the snippet
you have below.

The callers of yaffs_devname declare "buf" to be a char array, just as
the other kernel references I mentioned do. The different being that
yaffs_devname is an inline function, where the other reference changes
are not.

What happens if you take the code from the inline function and
implement it in the calling function, does the warning go away ?

Bruce

>
> fs/yaffs2/yaffs_vfs.c:122:29: warning: argument to 'sizeof' in 'snprintf' 
> call is the same expression as the destination; did you mean to provide an 
> explicit length? [-Wsizeof-pointer-memaccess]
>
> --- a/fs/yaffs2/yaffs_vfs.c
> +++ b/fs/yaffs2/yaffs_vfs.c
> @@ -117,7 +117,11 @@
>  #define Page_Uptodate(page) test_bit(PG_uptodate, &(page)->flags)
>
>  /* FIXME: use sb->s_id instead ? */
> -#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, buf)
> +//#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, buf)
> +static inline char* yaffs_devname(struct super_block *sb, char *buf) {
> +   snprintf(buf, sizeof(buf), "%pg", sb->s_bdev);
> +   return buf;
> +}
>
>  #else
>
>
>
> Thanks,
> Zhe
>
> On 5/30/23 11:34, He Zhe via lists.yoctoproject.org wrote:
> > |Hi Bruce, We met the following warning when build linux-yocto v6.1, 
> > introduced by latter diff. It perhaps miscalculates the buf length. 
> > fs/yaffs2/yaffs_vfs.c:122:29: warning: argument to 'sizeof' in 'snprintf' 
> > call is the same expression as the destination; did you mean to provide an 
> > explicit length? [-Wsizeof-pointer-memaccess] --- a/fs/yaffs2/yaffs_vfs.c 
> > +++ b/fs/yaffs2/yaffs_vfs.c @@ -117,7 +117,11 @@  #define 
> > Page_Uptodate(page) test_bit(PG_uptodate, &(page)->flags)/* FIXME: use 
> > sb->s_id instead ? */ -#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, 
> > buf) +//#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, buf) +static 
> > inline char* yaffs_devname(struct super_block *sb, char *buf) { +   
> > snprintf(buf, sizeof(buf), "%pg", sb->s_bdev); +   return buf; +}
> > #else   Thanks, Zhe |
> >
> >
> > 
> >
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12664): 
https://lists.yoctoproject.org/g/linux-yocto/message/12664
Mute This Topic: https://lists.yoctoproject.org/mt/99213494/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy
 [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 1/1] nxp-imx8: Enable Vivante GPU driver

2023-05-30 Thread Bruce Ashfield
In message: Re: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 1/1] 
nxp-imx8: Enable Vivante GPU driver
on 30/05/2023 Wang, Xiaolei wrote:

> Hi bruce
> 
> I found that this patch does not seem to be merged into the yocto-kernel-cache
> yocto-6.1 branch, can you help me merge it again

It looks like I merged one patch, and replied to the emai of another.

this should be merged now.

Bruce

> 
> thanks
> xiaolei
> ━━━
> From: Bruce Ashfield 
> Sent: Tuesday, May 9, 2023 6:12 AM
> To: Wang, Xiaolei 
> Cc: linux-yocto@lists.yoctoproject.org 
> Subject: Re: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 1/1] nxp-imx8:
> Enable Vivante GPU driver
>  
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and 
> know
> the content is safe.
> 
> merged
> 
> FYI: Something mangled your author name in the patch.
> 
> I fixed it before pushing, but it is worth checking to see if something 
> changed
> in your infrastructure.
> 
> Bruce
> 
> In message: [linux-yocto][yocto-kernel-cache yocto-6.1][PATCH 1/1] nxp-imx8:
> Enable Vivante GPU driver
> on 08/05/2023 Xiaolei Wang wrote:
> 
> > Enable Vivante GPU driver for nxp-imx8 bsp.
> >
> > Signed-off-by: Xiaolei Wang 
> > ---
> >  bsp/nxp-imx8/nxp-imx8.cfg | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg
> > index d90837d3..a278850f 100644
> > --- a/bsp/nxp-imx8/nxp-imx8.cfg
> > +++ b/bsp/nxp-imx8/nxp-imx8.cfg
> > @@ -262,6 +262,11 @@ CONFIG_DRM_GEM_SHMEM_HELPER=y
> >  CONFIG_DRM_SCHED=m
> >  CONFIG_DRM_ITE_IT6263=y
> >
> > +#
> > +# MXC Vivante GPU support
> > +#
> > +CONFIG_MXC_GPU_VIV=y
> > +
> >  #
> >  # I2C encoder or helper chips
> >  #
> > --
> > 2.25.1
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12665): 
https://lists.yoctoproject.org/g/linux-yocto/message/12665
Mute This Topic: https://lists.yoctoproject.org/mt/98757130/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy
 [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto][linux-yocto v6.1/standard/ti-sdk-5.10/ti-j7xxx & v6.1/standard/preempt-rt/ti-sdk-5.10/ti-j7xxx][PATCH] net: ethernet: ti: am65-cpsw: drop unused variable 'dev'

2023-05-30 Thread Bruce Ashfield
merged.

Bruce

In message: [linux-yocto][linux-yocto v6.1/standard/ti-sdk-5.10/ti-j7xxx & 
v6.1/standard/preempt-rt/ti-sdk-5.10/ti-j7xxx][PATCH]  net: ethernet: ti: 
am65-cpsw: drop unused variable 'dev'
on 30/05/2023 Xulin Sun wrote:

> Drop unused variable 'dev', to fix below warning:
> drivers/net/ethernet/ti/am65-cpsw-nuss.c:1767:24: warning: unused variable 
> 'dev' [-Wunused-variable]
> 1767 | struct device *dev = common->dev;
> 
> Signed-off-by: Xulin Sun 
> ---
>  drivers/net/ethernet/ti/am65-cpsw-nuss.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c 
> b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index cc4470514d79..2abc4a84964e 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -1764,7 +1764,6 @@ static void am65_cpsw_nuss_slave_disable_unused(struct 
> am65_cpsw_port *port)
>  
>  static void am65_cpsw_nuss_free_tx_chns(struct am65_cpsw_common *common)
>  {
> - struct device *dev = common->dev;
>   int i;
>  
>   for (i = 0; i < common->tx_ch_num; i++) {
> -- 
> 2.40.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12666): 
https://lists.yoctoproject.org/g/linux-yocto/message/12666
Mute This Topic: https://lists.yoctoproject.org/mt/99215052/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy
 [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] Trial merge of v5.15.114 v6.1.31 for linux-yocto

2023-05-30 Thread Kevin Hao
Hi Bruce,

This is a trial merge of the stable kernel v5.15.114 v6.1.31 for the following 
branches in the linux-yocto.
  d547e7f5bc0a  v5.15/standard/sdkv5.10/axxia
  59a34b26f323  v5.15/standard/preempt-rt/sdkv5.10/axxia
  9fd769562dae  v5.15/standard/base
  6af1dfdecdf3  v5.15/standard/preempt-rt/base
  dcd5eafbfe83  v5.15/standard/cn-sdkv5.4/octeon
  9a9c3c876923  v5.15/standard/preempt-rt/cn-sdkv5.4/octeon
  2d735a4173c8  v5.15/standard/cn-sdkv5.15/octeon
  9d0f475b5800  v5.15/standard/preempt-rt/cn-sdkv5.15/octeon
  2f11ec7e600a  v5.15/standard/ti-sdk-5.10/ti-j72xx
  7c1279b896b7  v5.15/standard/preempt-rt/ti-sdk-5.10/ti-j72xx
  7b0a923885de  v5.15/standard/nxp-sdk-5.15/nxp-soc 
 #Have textual conflicts
  96bac0c6e644  v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc  
 #Have textual conflicts
  6fbe57dbd48b  v5.15/standard/bcm-2xxx-rpi
  13904374823f  v5.15/standard/preempt-rt/bcm-2xxx-rpi
  3fae05dc70d5  v5.15/standard/nxp-sdk-5.15/nxp-s32g
  5fec5bd47a75  v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g
  67d5ebb0aea3  v5.15/standard/intel-sdk-5.15/intel-socfpga
  c5204957cee3  v5.15/standard/preempt-rt/intel-sdk-5.15/intel-socfpga
  12d56638dcd9  v5.15/standard/x86
  ed06ff93a699  v5.15/standard/preempt-rt/x86
  e1bb3e6d56ac  v5.15/standard/sdkv5.15/xlnx-soc
 #Have textual conflicts
  71df8f645502  v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc 
 #Have textual conflicts
  3a87532fe22d  v6.1/standard/base
  6f8ae7bf93be  v6.1/standard/preempt-rt/base
  62b4711e14f6  v6.1/standard/ti-sdk-5.10/ti-j7xxx
  0de1fa8ce944  v6.1/standard/preempt-rt/ti-sdk-5.10/ti-j7xxx
  b55eebaff7ba  v6.1/standard/nxp-sdk-6.1/nxp-soc   
 #Have textual conflicts
  a1328b32578d  v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc
 #Have textual conflicts
  fb623b6f0077  v6.1/standard/bcm-2xxx-rpi
  7e5a05433afc  v6.1/standard/preempt-rt/bcm-2xxx-rpi
  027c65b58322  v6.1/standard/nxp-sdk-5.15/nxp-s32g
  91878a08890f  v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g
  3a87532fe22d  v6.1/standard/x86
  752cafeaa8e5  v6.1/standard/preempt-rt/x86
  30e338889d7c  v6.1/standard/sdkv6.1/xlnx-soc  
 #Have textual conflicts
  638a62e0f723  v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc   
 #Have textual conflicts

This is a relatively small stable release and only has several trivial merge 
conflicts.
All the branches have passed my build test. I have pushed all these branches to:
https://github.com/haokexin/linux

You can use this as a reference for the linux-yocto stable kernel bump.

Thanks,
Kevin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12667): 
https://lists.yoctoproject.org/g/linux-yocto/message/12667
Mute This Topic: https://lists.yoctoproject.org/mt/99231926/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto][v5.15/standard/preempt-rt/base][PATCH] OF: DT-Overlay configfs interface (v8)

2023-05-30 Thread Bruce Ashfield
In message: Re: [linux-yocto][v5.15/standard/preempt-rt/base][PATCH] OF: 
DT-Overlay configfs interface (v8)
on 30/05/2023 Quanyang Wang wrote:

> Hi Bruce,
> 
> I wrote the wrong branch information. It should be:
> 
> v6.1/standard/preempt-rt/base
> 
> v6.1/standard/base
> 
> And this patch will conflict with another patch ("Revert "OF: DT-Overlay
> configfs interface (v8)" I just sent which is
> 
> https://lists.yoctoproject.org/g/linux-yocto/topic/v6_1_standard_preempt_rt_sdkv6_1_xlnx_soc_patch/99215104?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,99215104,previd%3D1685429439939095335,nextid%3D1684520876284512837&previd=1685429439939095335&nextid=1684520876284512837
> 
> So the patch in the above URL should be applied first and then this patch.
> 
> Sorry for the inconvenience.

No problem!

I have it sorted out and the functionality should now be on all BSP branches.

The rpi branches carry a similar change, but I reverted the rpi version, 
otherwise
the conflicts are a mess.

Bruce

> 
> Thanks,
> 
> Quanyang
> 
> On 5/30/23 14:43, quanyang.wang via lists.yoctoproject.org wrote:
> > From: Pantelis Antoniou 
> > 
> > commit 999eb1a8fdc4512412c7bc519c895bc2a6fabbe0 from
> > https://github.com/Xilinx/linux-xlnx.git
> > 
> > Add a runtime interface to using configfs for generic device tree overlay
> > usage. With it its possible to use device tree overlays without having
> > to use a per-platform overlay manager.
> > 
> > Please see Documentation/devicetree/configfs-overlays.txt for more info.
> > 
> > Changes since v7:
> > - Xilinx alignment
> > - of: configfs: Fix error handling from of_overlay_create()
> > - of: configfs: lock while resolving and applying
> > - of: configfs: Fix memory leak in create overlay
> > - of: configfs: Fix compilation warning
> > - of: configfs: Use of_overlay_fdt_apply API call
> > 
> > Changes since v6:
> > - Default groups properties API changed.
> > 
> > Changes since v5:
> > - New style configfs.
> > 
> > Changes since v4:
> > - Loading fix for multiple overlays as found out by
> >Geert Uytterhoeven 
> > 
> > Changes since v3:
> > - Fixed compilation on SPARC & Xtensa
> > 
> > Changes since v2:
> > - Removed ifdef CONFIG_OF_OVERLAY (since for now it's required)
> > - Created a documentation entry
> > - Slight rewording in Kconfig
> > 
> > Changes since v1:
> > - of_resolve() -> of_resolve_phandles().
> > 
> > Signed-off-by: Pantelis Antoniou 
> > Signed-off-by: Nava kishore Manne 
> > Signed-off-by: Radhey Shyam Pandey 
> > State: not-upstreamable
> > Signed-off-by: Liwei Song 
> > [Liwei: remove overlay_lock to fix "unused-variable" warning.]
> > Signed-off-by: Bruce Ashfield 
> > ---
> > Hi Bruce,
> > Would you please help merge this patch to the branches:
> > v5.15/standard/preempt-rt/base
> > v5.15/standard/base
> > Thanks,
> > Quanyang
> > ---
> >   .../devicetree/configfs-overlays.txt  |  31 ++
> >   drivers/of/Kconfig|  11 +
> >   drivers/of/Makefile   |   1 +
> >   drivers/of/configfs.c | 292 ++
> >   4 files changed, 335 insertions(+)
> >   create mode 100644 Documentation/devicetree/configfs-overlays.txt
> >   create mode 100644 drivers/of/configfs.c
> > 
> > diff --git a/Documentation/devicetree/configfs-overlays.txt 
> > b/Documentation/devicetree/configfs-overlays.txt
> > new file mode 100644
> > index 0..5fa43e0643072
> > --- /dev/null
> > +++ b/Documentation/devicetree/configfs-overlays.txt
> > @@ -0,0 +1,31 @@
> > +Howto use the configfs overlay interface.
> > +
> > +A device-tree configfs entry is created in /config/device-tree/overlays
> > +and and it is manipulated using standard file system I/O.
> > +Note that this is a debug level interface, for use by developers and
> > +not necessarily something accessed by normal users due to the
> > +security implications of having direct access to the kernel's device tree.
> > +
> > +* To create an overlay you mkdir the directory:
> > +
> > +   # mkdir /config/device-tree/overlays/foo
> > +
> > +* Either you echo the overlay firmware file to the path property file.
> > +
> > +   # echo foo.dtbo >/config/device-tree/overlays/foo/path
> > +
> > +* Or you cat the contents of the overlay to the dtbo file
> > +
> > +   # cat foo.dtbo >/config/device-tree/overlays/foo/dtbo
> > +
> > +The overlay file will be applied, and devices will be created/destroyed
> > +as required.
> > +
> > +To remove it simply rmdir the directory.
> > +
> > +   # rmdir /config/device-tree/overlays/foo
> > +
> > +The rationalle of the dual interface (firmware & direct copy) is that each 
> > is
> > +better suited to different use patterns. The firmware interface is what's
> > +intended to be used by hardware managers in the kernel, while the copy 
> > interface
> > +make sense for developers (since it avoids problems with namespaces).
> > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > index 80b5fd44ab1c7..da62bc

Re: [linux-yocto] yaffs_vfs warning

2023-05-30 Thread He Zhe via lists.yoctoproject.org


On 5/30/23 21:35, Bruce Ashfield wrote:
> On Mon, May 29, 2023 at 11:41 PM He Zhe  wrote:
>> Sorry for messy encoding...
>>
>>
>> We met the following warning when build linux-yocto v6.1, introduced by 
>> latter diff. It perhaps miscalculates the buf length.
> Are you only seeing it with gcc-13 ?
>
> That fix follows the same pattern as many other parts of the kernel,
> and checking the 6.1 branch, those other subsystems still have similar
> sprintf() changes in place:
>
> i.e.:
>
> switch (cmd) {
> case BLKTRACESETUP:
> snprintf(b, sizeof(b), "%pg", bdev);

The problem is when array is passed as function parameter it'll be treated as a
simple pointer and thus sizeof will return the length of a pointer. This is the
warning is about.

But this doesn't apply to the above case since it passes array directly to
sizeof.

>
> So I don't see a miscalculation of the buffer length in the snippet
> you have below.
>
> The callers of yaffs_devname declare "buf" to be a char array, just as
> the other kernel references I mentioned do. The different being that
> yaffs_devname is an inline function, where the other reference changes
> are not.
>
> What happens if you take the code from the inline function and
> implement it in the calling function, does the warning go away ?

I did a quick test piggybacking print_unknown_bootoptions in init/main.c

static inline char* test_decay(char *buf) {
    printk("sizeof(buf) is %lu", sizeof(buf));
    snprintf(buf, sizeof(buf), "test_decay");
    return buf;
}

static void __init print_unknown_bootoptions(void)
{
    char *unknown_options;
    char *end;
    const char *const *p;
    size_t len;
    char buf[16];   
 

    test_decay(buf);
...

During build we got:
build/tmp-glibc/work-shared/qemux86-64/kernel-source/init/main.c:895:29: 
warning: argument to 'sizeof' in 'snprintf' call is the same expression as the 
destination; did you mean to provide an explicit length? 
[-Wsizeof-pointer-memaccess]
  895 | snprintf(buf, sizeof(buf), "test_decay");
  |

During boot we got:
...
[    0.00] sizeof(buf) is 8
...


I'll send a patch later.

Zhe

>
> Bruce
>
>> fs/yaffs2/yaffs_vfs.c:122:29: warning: argument to 'sizeof' in 'snprintf' 
>> call is the same expression as the destination; did you mean to provide an 
>> explicit length? [-Wsizeof-pointer-memaccess]
>>
>> --- a/fs/yaffs2/yaffs_vfs.c
>> +++ b/fs/yaffs2/yaffs_vfs.c
>> @@ -117,7 +117,11 @@
>>  #define Page_Uptodate(page) test_bit(PG_uptodate, &(page)->flags)
>>
>>  /* FIXME: use sb->s_id instead ? */
>> -#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, buf)
>> +//#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, buf)
>> +static inline char* yaffs_devname(struct super_block *sb, char *buf) {
>> +   snprintf(buf, sizeof(buf), "%pg", sb->s_bdev);
>> +   return buf;
>> +}
>>
>>  #else
>>
>>
>>
>> Thanks,
>> Zhe
>>
>> On 5/30/23 11:34, He Zhe via lists.yoctoproject.org wrote:
>>> |Hi Bruce, We met the following warning when build linux-yocto v6.1, 
>>> introduced by latter diff. It perhaps miscalculates the buf length. 
>>> fs/yaffs2/yaffs_vfs.c:122:29: warning: argument to 'sizeof' in 'snprintf' 
>>> call is the same expression as the destination; did you mean to provide an 
>>> explicit length? [-Wsizeof-pointer-memaccess] --- a/fs/yaffs2/yaffs_vfs.c 
>>> +++ b/fs/yaffs2/yaffs_vfs.c @@ -117,7 +117,11 @@  #define 
>>> Page_Uptodate(page) test_bit(PG_uptodate, &(page)->flags)/* FIXME: use 
>>> sb->s_id instead ? */ -#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, 
>>> buf) +//#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, buf) +static 
>>> inline char* yaffs_devname(struct super_block *sb, char *buf) { +   
>>> snprintf(buf, sizeof(buf), "%pg", sb->s_bdev); +   return buf; +}
>>> #else   Thanks, Zhe |
>>>
>>>
>>>
>>>
>
>
> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12669): 
https://lists.yoctoproject.org/g/linux-yocto/message/12669
Mute This Topic: https://lists.yoctoproject.org/mt/99213494/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto][linux-yocto v6.1/standard/base][PATCH] yaffs2: Fix miscalculation of devname buffer length

2023-05-30 Thread He Zhe via lists.yoctoproject.org
The following build warning helps us find a real mishandling of array length.

fs/yaffs2/yaffs_vfs.c:122:29: warning: argument to 'sizeof' in 'snprintf' call
is the same expression as the destination; did you mean to provide an explicit
length? [-Wsizeof-pointer-memaccess]

If an array is passed as a function parameter it'll be treated as a simple
pointer and thus sizeof will return the length of a pointer rather than the
length of the array.

Add and pass the buffer length to make it work correctly.

Signed-off-by: He Zhe 
---
 fs/yaffs2/yaffs_vfs.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
index 140f7aa7a1a1..e9e29a41a680 100644
--- a/fs/yaffs2/yaffs_vfs.c
+++ b/fs/yaffs2/yaffs_vfs.c
@@ -118,8 +118,8 @@
 
 /* FIXME: use sb->s_id instead ? */
 //#define yaffs_devname(sb, buf) bdevname(sb->s_bdev, buf)
-static inline char* yaffs_devname(struct super_block *sb, char *buf) {
-   snprintf(buf, sizeof(buf), "%pg", sb->s_bdev);
+static inline char* yaffs_devname(struct super_block *sb, char *buf, unsigned 
long len) {
+   snprintf(buf, len, "%pg", sb->s_bdev);
return buf;
 }
 
@@ -2944,12 +2944,12 @@ static struct super_block 
*yaffs_internal_read_super(int yaffs_version,
 
if (!sb->s_dev)
printk(KERN_INFO "yaffs: sb->s_dev is NULL\n");
-   else if (!yaffs_devname(sb, devname_buf))
+   else if (!yaffs_devname(sb, devname_buf, sizeof(devname_buf)))
printk(KERN_INFO "yaffs: devname is NULL\n");
else
printk(KERN_INFO "yaffs: dev is %d name is \"%s\" %s\n",
   sb->s_dev,
-  yaffs_devname(sb, devname_buf), read_only ? "ro" : "rw");
+  yaffs_devname(sb, devname_buf, sizeof(devname_buf)), 
read_only ? "ro" : "rw");
 
if (!data_str)
data_str = "";
@@ -2974,7 +2974,7 @@ static struct super_block *yaffs_internal_read_super(int 
yaffs_version,
yaffs_trace(YAFFS_TRACE_ALWAYS,
"yaffs: Attempting MTD mount of %u.%u,\"%s\"",
MAJOR(sb->s_dev), MINOR(sb->s_dev),
-   yaffs_devname(sb, devname_buf));
+   yaffs_devname(sb, devname_buf, sizeof(devname_buf)));
 
 
mtd = yaffs_get_mtd_device(sb->s_dev);
-- 
2.35.5


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12670): 
https://lists.yoctoproject.org/g/linux-yocto/message/12670
Mute This Topic: https://lists.yoctoproject.org/mt/99236577/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-