Regressions List Tracking
 help / color / mirror / Atom feed
From: Pratham Patel <prathampatel@thefossguy.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Saravana Kannan <saravanak@google.com>,
	Dragan Simic <dsimic@manjaro.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	regressions@lists.linux.dev, stable@vger.kernel.org
Subject: Re: Fixing the devicetree of Rock 5 Model B (and possibly others)
Date: Wed, 03 Apr 2024 15:26:44 +0000	[thread overview]
Message-ID: <D0ALCT8IOMGQ.105ELHD701M4F@thefossguy.com> (raw)

On Wed Apr 3, 2024 at 7:22 PM IST, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Apr 03, 2024 at 01:03:07AM +0000, Pratham Patel wrote:
> > > > > Also, can you give the output of <debugfs>/devices_deferred for the
> > > > > good vs bad case?
> > > >
> > > > I can't provide you with requested output from the bad case, since the
> > > > kernel never moves past this to an initramfs rescue shell, but following
> > > > is the output from v6.8.1 (**with aforementioned patch reverted**).
> > > >
> > > > # cat /sys/kernel/debug/devices_deferred
> > > > fc400000.usb    platform: wait for supplier /phy@fed90000/usb3-port
> > > > 1-0022  typec_fusb302: cannot register tcpm port
> > > > fc000000.usb    platform: wait for supplier /phy@fed80000/usb3-port
> > > >
> > > > It seems that v6.8.2 works _without needing to revert the patch_. I will
> > > > have to look into this sometime this week but it seems like
> > > > a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s)
> > > > seems to be the one that fixed the root issue. I will have to test it
> > > > sometime later this week.
> > >
> > > Ok, once you find the patch that fixes things, let me know too.
> >
> > Will do!
>
> FWIW the v6.8.1 kernel referenced above is definitely patched, since
> upstream's Rock 5B DT does neither describe fusb302, nor the USB
> port it is connected to.
>
> We have a few Rock 5B in Kernel CI and upstream boots perfectly
> fine:
>
> https://lava.collabora.dev/scheduler/device_type/rk3588-rock-5b

Hmm, weird then. I can confirm that v6.8.1 doesn't _always_ boot. It
boots some times but still fails a majority of times. There is a
2 out of 10 chance that v6.8.1 will not boot. If you keep rebooting
enough times, you might get it to boot but the next boot is
likely to be borked. :(

That said, v6.8.2 might still have the same issue, but the probably of a
failed boot might be _lesser_ than v6.8.1 (from what I saw). I will
verify that behaviour sometime tomorrow or day after tomorrow.

>
> So it could be one of your downstream patches, which is introducing
> this problem.

I thought so too. So I built a vanilla kernel from the release tarball
of v6.8.1, using GCC + arm64 defconfig. I also tried using LLVM just in
case but noticed the same result.

 -- Pratham Patel


             reply	other threads:[~2024-04-03 15:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 15:26 Pratham Patel [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-03-23 17:02 Fixing the devicetree of Rock 5 Model B (and possibly others) Pratham Patel
2024-03-23 17:08 ` Pratham Patel
2024-03-23 17:09 ` Dragan Simic
2024-04-01 23:24   ` Saravana Kannan
2024-04-02 23:32     ` Pratham Patel
2024-04-03  0:46       ` Saravana Kannan
2024-04-03  1:03         ` Pratham Patel
2024-04-03 13:52           ` Sebastian Reichel
2024-04-05  8:32           ` Pratham Patel
2024-04-03 13:51       ` Dragan Simic
2024-03-23 17:17 ` Linux regression tracking (Thorsten Leemhuis)
2024-03-23 17:23   ` Pratham Patel

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=D0ALCT8IOMGQ.105ELHD701M4F@thefossguy.com \
    --to=prathampatel@thefossguy.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dsimic@manjaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=regressions@lists.linux.dev \
    --cc=saravanak@google.com \
    --cc=sebastian.reichel@collabora.com \
    --cc=stable@vger.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).