Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()

[Heiko Stübner]

Am Sonntag, 2. Juni 2024, 17:57:12 CEST schrieb Andy Shevchenko:
> Make two APIs look similar. Hence convert match_string() to be
> a 2-argument macro. In order to avoid unneeded churn, convert
> all users as well. There is no functional change intended.
> 
> Signed-off-by: Andy Shevchenko 
> ---
> 
> Compile tested with `make allyesconfig` and `make allmodconfig`
> on x86_64, arm, aarch64, powerpc64 (8 builds total).
> 
> I guess the best is to apply it to Linus' tree directly.
> And now it seems a good timing as there are no new users
> of this API either in v6.10-rcX, or in Linux Next.
> 
> But if you think differently, tell me.
> 

For the Rockchip clock part

>  drivers/clk/rockchip/clk.c|  4 +--

[...]

> diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
> index 73d2cbdc716b..30414d081f46 100644
> --- a/drivers/clk/rockchip/clk.c
> +++ b/drivers/clk/rockchip/clk.c
> @@ -266,8 +266,8 @@ static struct clk *rockchip_clk_register_frac_branch(
>   struct clk *mux_clk;
>   int ret;
>  
> - frac->mux_frac_idx = match_string(child->parent_names,
> -   child->num_parents, name);
> + frac->mux_frac_idx = __match_string(child->parent_names,
> + child->num_parents, name);
>   frac->mux_ops = _mux_ops;
>   frac->clk_nb.notifier_call = rockchip_clk_frac_notifier_cb;
>  

Acked-by: Heiko Stuebner 

Re: [PATCH 3/5] arm64: dts: remove label = "cpu" from DSA dt-binding

[Heiko Stübner]

Am Mittwoch, 30. November 2022, 15:10:38 CET schrieb Arınç ÜNAL:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
> 
> Signed-off-by: Arınç ÜNAL 
> ---

> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts 
> b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> index c282f6e79960..b71162d65d2e 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> @@ -552,7 +552,6 @@ port@4 {
>  
>   port@5 {
>   reg = <5>;
> - label = "cpu";
>   ethernet = <>;
>   phy-mode = "rgmii";
>  
> 

Rockchip-part:
Acked-by: Heiko Stuebner 

Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support

[Heiko Stübner]

Am Mittwoch, 25. Mai 2022, 18:08:22 CEST schrieb Guo Ren:
> Thx Heiko & Guenter,
> 
> On Wed, May 25, 2022 at 7:10 PM Heiko Stübner  wrote:
> >
> > Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner:
> > > Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck:
> > > > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote:
> > > > [ ... ]
> > > >
> > > > > > The problem is come from "__dls3's vdso decode part in musl's
> > > > > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong.
> > > > > >
> > > > > > I think the root cause is from musl's implementation with the wrong
> > > > > > elf parser. I would fix that soon.
> > > > > Not elf parser, it's "aux vector just past environ[]". I think I could
> > > > > solve this, but anyone who could help dig in is welcome.
> > > > >
> > > >
> > > > I am not sure I understand what you are saying here. Point is that my
> > > > root file system, generated with musl a year or so ago, crashes with
> > > > your patch set applied. That is a regression, even if there is a bug
> > > > in musl.
> Thx for the report, it's a valuable regression for riscv-compat.
> 
> > >
> > > Also as I said in the other part of the thread, the rootfs seems innocent,
> > > as my completely-standard Debian riscv64 rootfs is also affected.
> > >
> > > The merged version seems to be v12 [0] - not sure how we this discussion
> > > ended up in v9, but I just tested this revision in two variants:
> > >
> > > - v5.17 + this v9 -> works nicely
> >
> > I take that back ... now going back to that build I somehow also run into
> > that issue here ... will investigate more.
> Yeah, it's my fault. I've fixed up it, please have a try:
> 
> https://lore.kernel.org/linux-riscv/20220525160404.2930984-1-guo...@kernel.org/T/#u

very cool that you found the issue.
I've tested your patch and it seems to fix the issue for me.

Thanks for figuring out the cause
Heiko


> > > - v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot
> > >   The only rebase-conflict was with the introduction of restartable
> > >   sequences and removal of the tracehook include, but turning CONFIG_RSEQ
> > >   off doesn't seem to affect the breakage.
> > >
> > > So it looks like something changed between 5.17 and 5.18 that causes the 
> > > issue.
> > >
> > >
> > > Heiko
> > >
> > >
> > > [0] 
> > > https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/
> > >
> >
> >
> >
> >
> 
> 
> 

Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support

[Heiko Stübner]

Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner:
> Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck:
> > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote:
> > [ ... ]
> > 
> > > > The problem is come from "__dls3's vdso decode part in musl's
> > > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong.
> > > >
> > > > I think the root cause is from musl's implementation with the wrong
> > > > elf parser. I would fix that soon.
> > > Not elf parser, it's "aux vector just past environ[]". I think I could
> > > solve this, but anyone who could help dig in is welcome.
> > > 
> > 
> > I am not sure I understand what you are saying here. Point is that my
> > root file system, generated with musl a year or so ago, crashes with
> > your patch set applied. That is a regression, even if there is a bug
> > in musl.
> 
> Also as I said in the other part of the thread, the rootfs seems innocent,
> as my completely-standard Debian riscv64 rootfs is also affected.
> 
> The merged version seems to be v12 [0] - not sure how we this discussion
> ended up in v9, but I just tested this revision in two variants:
> 
> - v5.17 + this v9 -> works nicely

I take that back ... now going back to that build I somehow also run into
that issue here ... will investigate more.


> - v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot
>   The only rebase-conflict was with the introduction of restartable
>   sequences and removal of the tracehook include, but turning CONFIG_RSEQ
>   off doesn't seem to affect the breakage.
> 
> So it looks like something changed between 5.17 and 5.18 that causes the 
> issue.
> 
> 
> Heiko
> 
> 
> [0] https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/
> 

Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support

[Heiko Stübner]

Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck:
> On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote:
> [ ... ]
> 
> > > The problem is come from "__dls3's vdso decode part in musl's
> > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong.
> > >
> > > I think the root cause is from musl's implementation with the wrong
> > > elf parser. I would fix that soon.
> > Not elf parser, it's "aux vector just past environ[]". I think I could
> > solve this, but anyone who could help dig in is welcome.
> > 
> 
> I am not sure I understand what you are saying here. Point is that my
> root file system, generated with musl a year or so ago, crashes with
> your patch set applied. That is a regression, even if there is a bug
> in musl.

Also as I said in the other part of the thread, the rootfs seems innocent,
as my completely-standard Debian riscv64 rootfs is also affected.

The merged version seems to be v12 [0] - not sure how we this discussion
ended up in v9, but I just tested this revision in two variants:

- v5.17 + this v9 -> works nicely
- v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot
  The only rebase-conflict was with the introduction of restartable
  sequences and removal of the tracehook include, but turning CONFIG_RSEQ
  off doesn't seem to affect the breakage.

So it looks like something changed between 5.17 and 5.18 that causes the issue.


Heiko


[0] https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/

Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support

[Heiko Stübner]

Am Dienstag, 24. Mai 2022, 01:00:39 CEST schrieb Guenter Roeck:
> On Tue, May 24, 2022 at 12:40:06AM +0200, Heiko Stübner wrote:
> > Hi Guenter,
> > 
> > Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck:
> > > On 5/23/22 08:18, Guo Ren wrote:
> > > > I tested Palmer's branch, it's okay:
> > > > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
> > > > bogus mmu-type on a no MMU kernel
> > > > 
> > > > I also tested linux-next, it's okay:
> > > > 
> > > > rv64_rootfs:
> > > > # uname -a
> > > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > > > 2022 riscv64 GNU/Linux
> > > > #
> > > 
> > > That is is ok with one setup doesn't mean it is ok with
> > > all setups. It is not ok with my root file system (from
> > > https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64),
> > > with qemu v6.2.
> > 
> > That is very true that it shouldn't fail on any existing (qemu-)platform,
> > but as I remember also testing Guo's series on both riscv32 and riscv64
> > qemu platforms in the past, I guess it would be really helpful to get more
> > information about the failing platform you're experiencing so that we can
> > find the source of the issue.
> > 
> > As it looks like you both tested the same kernel source, I guess the only
> > differences could be in the qemu-version, kernel config and rootfs.
> > Is your rootfs something you can share or that can be rebuilt easily?
> > 
> I provided a link to my root file system above. The link points to two
> root file systems, for initrd (cpio archive) and for ext2.
> I also mentioned above that I used qemu v6.2. And below I said
> 
> > My root file system uses musl.
> 
> I attached the buildroot configuration below. The buildroot version,
> if I remember correctly, was 2021.02.
> 
> Kernel configuration is basically defconfig. However, I do see one
> detail that is possibly special in my configuration.
> 
> # The latest kernel assumes SBI version 0.3, but that doesn't match qemu
> # at least up to version 6.2 and results in hangup/crashes during reboot
> # with sifive_u emulations.
> enable_config "${defconfig}" CONFIG_RISCV_SBI_V01
> 
> Hope that helps,

Actually it doesn't seem rootfs-specific at all.

Merged was this v9, but the version I last tested was one of the earlier
ones, so it looks like something really broke meanwhile.

I tested both linux-next-20220524 and palmer's for-next on a very recent
qemu - master from april if I remember correctly together with a
Debian-based rootfs mounted as nfsroot inside qemu.

With CONFIG_COMPAT=y (aka using defconfig directly) I get:
[   12.957612] VFS: Mounted root (nfs filesystem) on device 0:15.
[   12.967260] devtmpfs: mounted
[   13.101186] Freeing unused kernel image (initmem) memory: 2168K
[   13.110914] Run /sbin/init as init process
[   13.343810] Unable to handle kernel paging request at virtual address 
ff60007265776f78
[   13.347271] Oops [#1]
[   13.347749] Modules linked in:
[   13.348689] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-next-20220524 #1
[   13.349864] Hardware name: riscv-virtio,qemu (DT)
[   13.350706] epc : special_mapping_fault+0x4c/0x8e
[   13.351639]  ra : __do_fault+0x28/0x11c
[   13.352311] epc : 801210e6 ra : 8011712a sp : 
ff200060bd10
[   13.353276]  gp : 810df030 tp : ff60012a8000 t0 : 
80008acc
[   13.354063]  t1 : 80c001d8 t2 : 80c00258 s0 : 
ff200060bd20
[   13.354886]  s1 : ff200060bd68 a0 : ff60013165f0 a1 : 
ff6001ec2450
[   13.355675]  a2 : ff200060bd68 a3 :  a4 : 
ff603f0337c8
[   13.356822]  a5 : ff60007265776f70 a6 : ff6001ec2450 a7 : 
0007
[   13.357689]  s2 : ff6001ec2450 s3 : ff6001ec2450 s4 : 
ff200060bd68
[   13.358487]  s5 : ff6001ec2450 s6 : 0254 s7 : 
000c
[   13.359305]  s8 : 000f s9 : 000d s10: 
ff6001e4c080
[   13.360102]  s11: 000d t3 : 00ffbbeab000 t4 : 
6dff
[   13.361557]  t5 : 6e35 t6 : 000a
[   13.362229] status: 00020120 badaddr: ff60007265776f78 cause: 
000d
[   13.363504] [] __do_fault+0x28/0x11c
[   13.364464] [] __handle_mm_fault+0x71c/0x9ea
[   13.365577] [] handle_mm_fault+0x82/0x136
[   13.366275] [] do_page_fault+0x120/0x31c
[   13.366906] [] ret_from_exception+0x0/0xc
[   13.368763] ---[ end trace  ]---
[   13.368763] ---[ end trace  ]---
[   13.369598] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[   13.369933] SMP: sto

Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support

[Heiko Stübner]

Hi Guenter,

Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck:
> On 5/23/22 08:18, Guo Ren wrote:
> > I tested Palmer's branch, it's okay:
> > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
> > bogus mmu-type on a no MMU kernel
> > 
> > I also tested linux-next, it's okay:
> > 
> > rv64_rootfs:
> > # uname -a
> > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > 2022 riscv64 GNU/Linux
> > #
> 
> That is is ok with one setup doesn't mean it is ok with
> all setups. It is not ok with my root file system (from
> https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64),
> with qemu v6.2.

That is very true that it shouldn't fail on any existing (qemu-)platform,
but as I remember also testing Guo's series on both riscv32 and riscv64
qemu platforms in the past, I guess it would be really helpful to get more
information about the failing platform you're experiencing so that we can
find the source of the issue.

As it looks like you both tested the same kernel source, I guess the only
differences could be in the qemu-version, kernel config and rootfs.
Is your rootfs something you can share or that can be rebuilt easily?


Heiko

> > #
> > #
> > # ls /lib
> > ld-uClibc-1.0.39.so  libatomic.so.1   libgcc_s.so
> > ld-uClibc.so.0   libatomic.so.1.2.0   libgcc_s.so.1
> > ld-uClibc.so.1   libc.so.0libuClibc-1.0.39.so
> > libatomic.so libc.so.1modules
> > 
> 
> My root file system uses musl.
> 
> Guenter
> 
> > rv32_rootfs:
> > buildroot login: root
> > # uname -a
> > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > 2022 riscv64 GNU/Linux
> > # ls /lib
> > ld-linux-riscv32-ilp32d.so.1  libm.so.6
> > libanl.so.1   libnss_dns.so.2
> > libatomic.so  libnss_files.so.2
> > libatomic.so.1libpthread.so.0
> > libatomic.so.1.2.0libresolv.so.2
> > libc.so.6 librt.so.1
> > libcrypt.so.1 libthread_db.so.1
> > libdl.so.2libutil.so.1
> > libgcc_s.so   modules
> > libgcc_s.so.1
> > 
> > Here is my qemu version:
> > commit 19f13a92cef8405052e0f73d5289f9e15474dad3 (HEAD ->
> > riscv-to-apply.next, alistair/riscv-to-apply.next)
> > Author: Tsukasa OI 
> > Date:   Sun May 15 11:56:11 2022 +0900
> > 
> >  target/riscv: Move/refactor ISA extension checks
> > 
> >  We should separate "check" and "configure" steps as possible.
> >  This commit separates both steps except vector/Zfinx-related checks.
> > 
> >  Signed-off-by: Tsukasa OI 
> >  Reviewed-by: Alistair Francis 
> >  Message-Id:
> > 
> >  Signed-off-by: Alistair Francis 
> > 
> > On Mon, May 23, 2022 at 1:45 PM Guenter Roeck  wrote:
> >>
> >> On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote:
> >>> From: Guo Ren 
> >>>
> >>> Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on
> >>> 64bit S-mode) support.
> >>>   - Setup kconfig & dummy functions for compiling.
> >>>   - Implement compat_start_thread by the way.
> >>>
> >>> Signed-off-by: Guo Ren 
> >>> Signed-off-by: Guo Ren 
> >>> Reviewed-by: Arnd Bergmann 
> >>> Tested-by: Heiko Stuebner 
> >>> Cc: Palmer Dabbelt 
> >>
> >> With this patch in linux-next, all my riscv64 emulations crash.
> >>
> >> [   11.600082] Run /sbin/init as init process
> >> [   11.628561] init[1]: unhandled signal 11 code 0x1 at 0x 
> >> in libc.so[ff8ad39000+a4000]
> >> [   11.629398] CPU: 0 PID: 1 Comm: init Not tainted 
> >> 5.18.0-rc7-next-20220520 #1
> >> [   11.629462] Hardware name: riscv-virtio,qemu (DT)
> >> [   11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : 
> >> 00ffc58199f0
> >> [   11.629586]  gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : 
> >> 
> >> [   11.629598]  t1 : 00ffc5819fd0 t2 :  s0 : 
> >> 00ff8ade0cc0
> >> [   11.629610]  s1 : 00ff8ade0cc0 a0 :  a1 : 
> >> 00ffc5819a00
> >> [   11.629622]  a2 : 0001 a3 : 001e a4 : 
> >> 00ffc5819b00
> >> [   11.629634]  a5 : 00ffc5819b00 a6 :  a7 : 
> >> 
> >> [   11.629645]  s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : 
> >> 00ff8ade0728
> >> [   11.629656]  s5 : 00ff8ade0a90 s6 :  s7 : 
> >> 00ffc5819e40
> >> [   11.629667]  s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: 
> >> 
> >> [   11.629678]  s11:  t3 : 0002 t4 : 
> >> 0001
> >> [   11.629688]  t5 : 0002 t6 : 
> >> [   11.629699] status: 4020 badaddr:  cause: 
> >> 000d
> >> [   11.633421] Kernel panic - not syncing: Attempted to kill init! 
> >> exitcode=0x000b
> >> [   11.633664] CPU: 0 PID: 1 Comm: init Not tainted 
> >> 5.18.0-rc7-next-20220520 #1
> >> [   11.633784] Hardware name: 

Re: [PATCH V7 00/20] riscv: compat: Add COMPAT mode support for rv64

[Heiko Stübner]

Hi,

Am Sonntag, 27. Februar 2022, 17:28:11 CET schrieb guo...@kernel.org:
> From: Guo Ren 
> 
> Currently, most 64-bit architectures (x86, parisc, powerpc, arm64,
> s390, mips, sparc) have supported COMPAT mode. But they all have
> history issues and can't use standard linux unistd.h. RISC-V would
> be first standard __SYSCALL_COMPAT user of include/uapi/asm-generic
> /unistd.h.
> 
> The patchset are based on v5.17-rc5, you can compare rv64-compat
> v.s. rv32-native in qemu with following steps:

I've followed your great test-instructions :-) .

Starting a riscv32 userspace with a riscv64-kernel _without_ that series
fails as expected. It wants to find the binfmt module to emulate the
unavailable architecture.

Same userspace and this series applied to the kernel tree makes that
riscv32 userspace boot nicely on the riscv64 kernel.

So the series:
Tested-by: Heiko Stuebner 



>  - Prepare rv32 rootfs & fw_jump.bin by buildroot.org
>$ git clone git://git.busybox.net/buildroot
>$ cd buildroot
>$ make qemu_riscv32_virt_defconfig O=qemu_riscv32_virt_defconfig
>$ make -C qemu_riscv32_virt_defconfig
>$ make qemu_riscv64_virt_defconfig O=qemu_riscv64_virt_defconfig
>$ make -C qemu_riscv64_virt_defconfig
>(Got fw_jump.bin & rootfs.ext2 in qemu_riscvXX_virt_defconfig/images)
> 
>  - Prepare Linux rv32 & rv64 Image
>$ git clone g...@github.com:c-sky/csky-linux.git -b riscv_compat_v6 linux
>$ cd linux
>$ echo "CONFIG_STRICT_KERNEL_RWX=n" >> arch/riscv/configs/defconfig
>$ echo "CONFIG_STRICT_MODULE_RWX=n" >> arch/riscv/configs/defconfig
>$ make ARCH=riscv CROSS_COMPILE=riscv32-buildroot-linux-gnu- 
> O=../build-rv32/ rv32_defconfig
>$ make ARCH=riscv CROSS_COMPILE=riscv32-buildroot-linux-gnu- 
> O=../build-rv32/ Image
>$ make ARCH=riscv CROSS_COMPILE=riscv64-buildroot-linux-gnu- 
> O=../build-rv64/ defconfig
>$ make ARCH=riscv CROSS_COMPILE=riscv64-buildroot-linux-gnu- 
> O=../build-rv64/ Image
> 
>  - Prepare Qemu: (rv32 compat was made by LIU Zhiwei )
>$ git clone g...@github.com:alistair23/qemu.git -b 
> riscv-to-apply.for-upstream linux
>$ cd qemu
>$ ./configure --target-list="riscv64-softmmu riscv32-softmmu"
>$ make
> 
> Now let's compare rv64-compat with rv32-native memory footprint with almost 
> the same
> defconfig, rootfs, opensbi in one qemu.
> 
>  - Run rv64 with rv32 rootfs in compat mode:
>$ ./build/qemu-system-riscv64 -cpu rv64 -M virt -m 64m -nographic -bios 
> qemu_riscv64_virt_defconfig/images/fw_jump.bin -kernel build-rv64/Image 
> -drive file qemu_riscv32_virt_defconfig/images/rootfs.ext2,format=raw,id=hd0 
> -device virtio-blk-device,drive=hd0 -append "rootwait root=/dev/vda ro 
> console=ttyS0 earlycon=sbi" -netdev user,id=net0 -device 
> virtio-net-device,netdev=net0
> 
> QEMU emulator version 6.2.50 (v6.2.0-29-g196d7182c8)
> OpenSBI v0.9
> [0.00] Linux version 5.16.0-rc6-00017-g750f87086bdd-dirty 
> (guoren@guoren-Z87-HD3) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld 
> (GNU Binutils) 2.37) #96 SMP Tue Dec 28 21:01:55 CST 2021
> [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
> [0.00] Machine model: riscv-virtio,qemu
> [0.00] earlycon: sbi0 at I/O port 0x0 (options '')
> [0.00] printk: bootconsole [sbi0] enabled
> [0.00] efi: UEFI not found.
> [0.00] Zone ranges:
> [0.00]   DMA32[mem 0x8020-0x83ff]
> [0.00]   Normal   empty
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x8020-0x83ff]
> [0.00] Initmem setup node 0 [mem 
> 0x8020-0x83ff]
> [0.00] SBI specification v0.2 detected
> [0.00] SBI implementation ID=0x1 Version=0x9
> [0.00] SBI TIME extension detected
> [0.00] SBI IPI extension detected
> [0.00] SBI RFENCE extension detected
> [0.00] SBI v0.2 HSM extension detected
> [0.00] riscv: ISA extensions acdfhimsu
> [0.00] riscv: ELF capabilities acdfim
> [0.00] percpu: Embedded 17 pages/cpu s30696 r8192 d30744 u69632
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 15655
> [0.00] Kernel command line: rootwait root=/dev/vda ro console=ttyS0 
> earlycon=sbi
> [0.00] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes, 
> linear)
> [0.00] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes, 
> linear)
> [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
> [0.00] Virtual kernel memory layout:
> [0.00]   fixmap : 0xffcefee0 - 0xffceff00   (2048 
> kB)
> [0.00]   pci io : 0xffceff00 - 0xffcf   (  16 
> MB)
> [0.00]  vmemmap : 0xffcf - 0xffcf   (4095 
> MB)
> [0.00]  vmalloc : 0xffd0 - 

Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name

[Heiko Stübner]

Am Dienstag, 28. August 2018, 03:52:44 CEST schrieb Rob Herring:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.

>  drivers/soc/rockchip/pm_domains.c | 44 +++

For the Rockchip-part
Acked-by: Heiko Stuebner 

Re: [PATCH] i2c: don't print error when adding adapter fails

[Heiko Stübner]

Am Dienstag, 9. August 2016, 13:36:17 schrieb Wolfram Sang:
> The core will do this for us now.
> 
> Signed-off-by: Wolfram Sang 
> ---

[...]

> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 2bc8b01153d619..3b87afe82f6394 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1303,10 +1303,8 @@ static int rk3x_i2c_probe(struct platform_device
> *pdev) rk3x_i2c_adapt_div(i2c, clk_rate);
> 
>   ret = i2c_add_adapter(>adap);
> - if (ret < 0) {
> - dev_err(>dev, "Could not register adapter\n");
> + if (ret < 0)
>   goto err_clk_notifier;
> - }
> 
>   dev_info(>dev, "Initialized RK3xxx I2C bus at %p\n", i2c->regs);

for Rockchip
Acked-by: Heiko Stuebner 

Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call

[Heiko Stübner]

Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
 The DMA API requires drivers to call the appropriate dma_set_mask()
 functions before doing any DMA mapping.  Add this required call to
 the AMBA PL08x driver.
^--- copy and paste error - should of course be PL330


 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
  drivers/dma/pl330.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index a562d24..df8b10f 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -2903,6 +2903,10 @@ pl330_probe(struct amba_device *adev, const struct
 amba_id *id)
 
   pdat = dev_get_platdata(adev-dev);
 
 + ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
 + if (ret)
 + return ret;
 +
   /* Allocate a new DMAC and its Channels */
   pdmac = devm_kzalloc(adev-dev, sizeof(*pdmac), GFP_KERNEL);
   if (!pdmac) {

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev