public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	Mark Brown <broonie@kernel.org>,
	Gui-Dong Han <hanguidong02@gmail.com>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org,
	linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
	Qiu-ji Chen <chenqiuji666@gmail.com>,
	Aishwarya.TCV@arm.com,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v5] driver core: enforce device_lock for driver_match_device()
Date: Wed, 21 Jan 2026 20:00:54 +0000	[thread overview]
Message-ID: <e32b0819-2c29-4c83-83d5-e28dc4b2b01f@nvidia.com> (raw)
In-Reply-To: <ef37ed64-24ad-4b82-bc6c-d3bc72aaf232@samsung.com>


On 20/01/2026 15:23, Marek Szyprowski wrote:
> On 20.01.2026 14:22, Mark Brown wrote:
>> On Wed, Jan 14, 2026 at 12:28:43AM +0800, Gui-Dong Han wrote:
>>> Currently, driver_match_device() is called from three sites. One site
>>> (__device_attach_driver) holds device_lock(dev), but the other two
>>> (bind_store and __driver_attach) do not. This inconsistency means that
>>> bus match() callbacks are not guaranteed to be called with the lock
>>> held.
>> I'm seeing boot hangs on Arm Juno in next/pending-fixes which bisect to
>> this commit.  The boot grinds to a halt near the end of boot:
>>
>> [    2.570549] ledtrig-cpu: registered to indicate activity on CPUs
>> [    2.618301] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
>> [    2.623547] msm_serial: driver initialized
>> [    2.624058] SuperH (H)SCI(F) driver initialized
>> [    2.624312] STM32 USART driver initialized
>>
>> with no further output, full log:
>>
>>      https://lava.sirena.org.uk/scheduler/job/2387335#L862
>>
>> We are also seeing similar looking boot hangs on some Qualcomm platforms
>> in Arm's test lab which aren't verified to be the same thing but are
>> hanging at a similar point in boot.
> 
> I've observed the same issue on Qualcomm RB5 board and bisecting lead me
> also to this patch. My kernel log also doesn't reveal much information:
> 
> ...
> 
> [    3.671227] vreg_bob: Setting 3008000-4000000uV
> [    3.676929] vreg_l1c_1p8: Setting 1800000-1800000uV
> [    3.682826] vreg_l2c_1p2: Setting 1200000-1200000uV
> [    3.688547] vreg_l3c_0p8: Setting 800000-800000uV
> [    3.694080] vreg_l4c_1p7: Setting 1704000-2928000uV
> [    3.699908] vreg_l5c_1p8: Setting 1800000-2928000uV
> [    3.705763] vreg_l6c_2p96: Setting 1800000-2960000uV
> [    3.711684] vreg_l7c_cam_vcm0_2p85: Setting 2856000-3104000uV
> [    3.718408] vreg_l8c_1p8: Setting 1800000-1800000uV
> [    3.724287] vreg_l9c_2p96: Setting 2704000-2960000uV
> [    3.730218] vreg_l10c_3p0: Setting 3000000-3000000uV
> [    3.736226] vreg_l11c_3p3: Setting 3296000-3296000uV
> [    3.743413] vreg_s8c_1p3: Setting 1352000-1352000uV
> [    3.771370] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    3.792020] msm_serial: driver initialized
> [    3.797633] SuperH (H)SCI(F) driver initialized
> [    3.802881] STM32 USART driver initialized
> 
> [hang/freeze]

I am seeing a similar issue on one of our Tegra boards and bisect also 
points to this commit.

It is odd because it only appears to impact the Tegra194 Jetson Xavier 
NX board (tegra194-p3509-0000+p3668-0000.dts).

It appears to boot enough so the test can SSH into the device, but the 
kernel log does not show the us getting to the console prompt. It also 
appears that a lot of drivers are not bound as expected. I would need to 
check if those are all modules or not.

Jon

-- 
nvpublic


       reply	other threads:[~2026-01-21 20:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260113162843.12712-1-hanguidong02@gmail.com>
     [not found] ` <7ae38e31-ef31-43ad-9106-7c76ea0e8596@sirena.org.uk>
     [not found]   ` <CGME20260120152328eucas1p1024a7488ae10b8b7f2fcb74baee24c75@eucas1p1.samsung.com>
     [not found]     ` <ef37ed64-24ad-4b82-bc6c-d3bc72aaf232@samsung.com>
2026-01-21 20:00       ` Jon Hunter [this message]
2026-01-21 21:42         ` [PATCH v5] driver core: enforce device_lock for driver_match_device() Danilo Krummrich
2026-01-22 17:28           ` Jon Hunter
2026-01-22 17:55             ` Gui-Dong Han
2026-01-22 18:12               ` Danilo Krummrich
2026-01-22 18:58                 ` Jon Hunter
2026-01-22 19:35                   ` Danilo Krummrich
2026-01-23 13:57                     ` Jon Hunter
2026-01-23 14:09                       ` Danilo Krummrich
2026-01-23 14:29                         ` Jon Hunter
2026-01-23 16:54                           ` Danilo Krummrich
2026-01-23 18:53                             ` Gui-Dong Han
2026-01-23 19:07                               ` Danilo Krummrich
2026-01-27 14:58                                 ` Jon Hunter
2026-01-27 15:18                                   ` Danilo Krummrich
2026-01-27 14:53                     ` Jon Hunter
2026-01-27 15:05                       ` Gui-Dong Han

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=e32b0819-2c29-4c83-83d5-e28dc4b2b01f@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=Aishwarya.TCV@arm.com \
    --cc=baijiaju1990@gmail.com \
    --cc=broonie@kernel.org \
    --cc=chenqiuji666@gmail.com \
    --cc=dakr@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hanguidong02@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=rafael@kernel.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