From: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Subject: Re: [PATCH v3 13/14] reset: convert reset core to using firmware nodes
Date: Wed, 11 Mar 2026 17:06:52 +0100 [thread overview]
Message-ID: <abGTCWDGNx_EPJjH@tom-desktop> (raw)
In-Reply-To: <CAMRc=Mfi7qJ2VvaUy-OQmV6hz_GjFstsHkt2iYyrTUPDgyKGCA@mail.gmail.com>
Hi Bartosz,
On Wed, Mar 11, 2026 at 08:54:52AM -0700, Bartosz Golaszewski wrote:
> On Wed, 11 Mar 2026 16:47:57 +0100, Tommaso Merciai
> <tommaso.merciai.xr@bp.renesas.com> said:
> > Hi Bartosz,
> > Thanks for your patch.
> >
> > On Fri, Mar 06, 2026 at 06:22:57PM +0100, Bartosz Golaszewski wrote:
> >> With everything else now in place, we can convert the remaining parts of
> >> the reset subsystem to becoming fwnode-agnostic - meaning it will work
> >> with all kinds of firmware nodes, not only devicetree.
> >>
> >> To that end: extend struct reset_controller_dev with fields taking
> >> information relevant for using firmware nodes (which mirrors what we
> >> already do for OF-nodes) and limit using of_ APIs only to where it's
> >> absolutely necessary (mostly around the of_xlate callback).
> >>
> >> For backward compatibility of existing drivers we still support OF-nodes
> >> but firmware nodes become the preferred method.
> >>
> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >
> > Just to share I'm seeing the following on RZ/G3E (next-20260310):
> >
> > [ 16.806538] ------------[ cut here ]------------
> > [ 16.806546] WARNING: drivers/reset/core.c:1195 at __fwnode_reset_control_get+0x474/0x568, CPU#3: kworker/u16:0/11
> > [ 16.806566] Modules linked in: reset_rzv2h_usb2phy(+) rcar_canfd(+) rtc_isl1208 can_dev ecdh_generic ecc rfkill renesas_rpc_if fuse drm backlight ipv6
> > [ 16.806603] CPU: 3 UID: 0 PID: 11 Comm: kworker/u16:0 Not tainted 7.0.0-rc3-next-20260310-00016-g866b1999e3fc #17 PREEMPT
> > [ 16.806610] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT)
> > [ 16.806615] Workqueue: events_unbound deferred_probe_work_func
> > [ 16.806627] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [ 16.806632] pc : __fwnode_reset_control_get+0x474/0x568
> > [ 16.806638] lr : __fwnode_reset_control_get+0x164/0x568
> > [ 16.806644] sp : ffff800083263930
> > [ 16.806646] x29: ffff800083263a30 x28: ffff0000ff8370a8 x27: ffff800081d8d590
> > [ 16.806655] x26: ffff800081e3a6c8 x25: ffff800082fec430 x24: ffff800082fec450
> > [ 16.806663] x23: 0000000000000000 x22: 0000000000000003 x21: ffff0000ff835940
> > [ 16.806671] x20: 0000000000000000 x19: ffff0000c0294e98 x18: 00000000ffffffff
> > [ 16.806679] x17: 6e6f637478652f79 x16: 68702d6273752e30 x15: 303230303835312f
> > [ 16.806687] x14: ffff8000831a6200 x13: 00363038343d4d55 x12: 0000000000000000
> > [ 16.806695] x11: 7478653d4d455453 x10: ffff8000827b0ab7 x9 : 0000000000000028
> > [ 16.806703] x8 : 0101010101010101 x7 : 00000000736c6c65 x6 : 000000000080a3f0
> > [ 16.806711] x5 : ffff800083263864 x4 : ffffffffff604034 x3 : 0000000000000000
> > [ 16.806719] x2 : ffff0000c0128fc0 x1 : 0000000000000000 x0 : 0000000000000001
> > [ 16.806727] Call trace:
> > [ 16.806731] __fwnode_reset_control_get+0x474/0x568 (P)
> > [ 16.806738] fwnode_reset_control_array_get+0x84/0x134
> > [ 16.806745] devm_reset_control_array_get+0x54/0xb4
> > [ 16.806751] rcar_gen3_phy_usb2_probe+0x108/0x5b8
> > [ 16.806762] platform_probe+0x5c/0x98
> > [ 16.806770] really_probe+0xbc/0x29c
> > [ 16.806776] __driver_probe_device+0x78/0x12c
> > [ 16.806782] driver_probe_device+0x3c/0x15c
> > [ 16.806789] __device_attach_driver+0xb8/0x134
> > [ 16.806795] bus_for_each_drv+0x88/0xe8
> > [ 16.806802] __device_attach+0xa0/0x190
> > [ 16.806808] device_initial_probe+0x50/0x54
> > [ 16.806814] bus_probe_device+0x38/0xa4
> > [ 16.806820] deferred_probe_work_func+0x88/0xc0
> > [ 16.806826] process_one_work+0x154/0x294
> > [ 16.806835] worker_thread+0x180/0x300
> > [ 16.806840] kthread+0x118/0x124
> > [ 16.806847] ret_from_fork+0x10/0x20
> > [ 16.806856] ---[ end trace 0000000000000000 ]---
> > [ 16.806867] phy_rcar_gen3_usb2 15800200.usb-phy: probe with driver phy_rcar_gen3_usb2 failed with error -22
> >
> > Hope this help.
> >
> > Thanks & Regards,
> > Tommaso
> >
>
> Does [1] fix it?
Yes, thanks for sharing.
I will provide my Tested-by tag.
Kind Regards,
Tommaso
>
> Bart
>
> [1] https://lore.kernel.org/all/20260310151515.34681-1-bartosz.golaszewski@oss.qualcomm.com/
>
next prev parent reply other threads:[~2026-03-11 16:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 17:22 [PATCH v3 00/14] reset: major reset core refactoring Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 01/14] reset: gpio: remove unneeded OF-node put Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 02/14] reset: gpio: add a devlink between reset-gpio and its consumer Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 03/14] reset: gpio: simplify fallback device matching Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 04/14] reset: gpio: remove unneeded auxiliary_set_drvdata() Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 05/14] reset: warn on reset-gpio release Bartosz Golaszewski
2026-03-09 9:21 ` Philipp Zabel
2026-03-06 17:22 ` [PATCH v3 06/14] reset: fold ida_alloc() into reset_create_gpio_aux_device() Bartosz Golaszewski
2026-03-09 7:47 ` Philipp Zabel
2026-03-06 17:22 ` [PATCH v3 07/14] reset: use lock guards in reset core Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 08/14] reset: handle removing supplier before consumers Bartosz Golaszewski
2026-03-09 7:47 ` Philipp Zabel
2026-03-06 17:22 ` [PATCH v3 09/14] reset: protect struct reset_controller_dev with its own mutex Bartosz Golaszewski
2026-03-09 8:01 ` Philipp Zabel
2026-03-06 17:22 ` [PATCH v3 10/14] reset: protect struct reset_control " Bartosz Golaszewski
2026-03-09 8:01 ` Philipp Zabel
2026-03-06 17:22 ` [PATCH v3 11/14] reset: convert of_reset_control_get_count() to using firmware nodes Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 12/14] reset: convert the core API " Bartosz Golaszewski
2026-03-06 17:22 ` [PATCH v3 13/14] reset: convert reset core " Bartosz Golaszewski
2026-03-09 8:01 ` Philipp Zabel
2026-03-10 14:16 ` Mark Brown
2026-03-10 14:48 ` Philipp Zabel
2026-03-10 14:53 ` Bartosz Golaszewski
2026-03-10 15:00 ` Geert Uytterhoeven
2026-03-11 15:47 ` Tommaso Merciai
2026-03-11 15:54 ` Bartosz Golaszewski
2026-03-11 16:06 ` Tommaso Merciai [this message]
2026-03-06 17:22 ` [PATCH v3 14/14] reset: gpio: make the driver fwnode-agnostic Bartosz Golaszewski
2026-03-09 9:25 ` [PATCH v3 00/14] reset: major reset core refactoring Philipp Zabel
2026-03-09 9:34 ` Bartosz Golaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abGTCWDGNx_EPJjH@tom-desktop \
--to=tommaso.merciai.xr@bp.renesas.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=corbet@lwn.net \
--cc=krzk@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox