All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Anand Moon <linux.amoon@gmail.com>
Cc: Grimmauld <grimmauld@grimmauld.de>,
	mani@kernel.org, "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] PCI: dw-rockchip: Enable async probe by default
Date: Tue, 3 Feb 2026 12:01:41 +0100	[thread overview]
Message-ID: <aYHVlS1nbCMMyF04@ryzen> (raw)
In-Reply-To: <CANAwSgSR7AYCvMXSo5UskTF3LJToOnPV9JE4XBAUzrCbWGKD_w@mail.gmail.com>

On Mon, Feb 02, 2026 at 11:35:48PM +0530, Anand Moon wrote:
> On Mon, 2 Feb 2026 at 15:25, Niklas Cassel <cassel@kernel.org> wrote:
> >
> > On Sat, Jan 31, 2026 at 03:08:42PM +0530, Anand Moon wrote:
> > > >
> > > I’ve attempted to reproduce the warning but was unable to trigger it locally.
> > >
> > > I have tested with the built-in module
> > > CONFIG_R8169=y
> > > CONFIG_R8169_LEDS=y
> > >
> > > As well as the module
> > > CONFIG_R8169=m
> > > CONFIG_R8169_LEDS=y
> > >
> >
> > I'm running with:
> > CONFIG_R8169=y
> > CONFIG_PHYLIB=y
> > CONFIG_REALTEK_PHY=y
> > CONFIG_REALTEK_PHY_HWMON=y
> >
> I feel CONFIG_R8169 should not be built into the kernel image.
> Since the driver is registered via module_pci_driver(rtl8169_pci_driver),
> it is intended to be loaded as a module. In addition, this driver
> requires external firmware
> during initialization, which could make a built‑in configuration problematic.
> Keeping it modular ensures proper firmware loading and avoids
> early‑boot failures.

For what it is worth, I strongly disagree that you should not be allowed
to build something as built-in just because the driver is registered using
module_pci_driver().

In order to use NFS root, and to avoid the hassle of using an initramfs,
having the driver as built-in is a logical option.
Anyway, this is currently working fine with my setup today, and is
unrelated to the phylib splat that I have reported in this thread.

I know that the R8169 driver tries to load a firmware blob, I used to have
an initramfs just to be able to load this firmware blob, but I found out
that the driver probes and works perfectly fine even without the loading
any firmware, therefore I no longer use an initramfs.
Again, this is working perfectly fine today, and the R8169 loading or not
loading any firmware is unrealated to the phylib splat.

(Just for clarity, I don't think that the phylib splat should stop this
patch from being accepted.)


Kind regards,
Niklas


WARNING: multiple messages have this Message-ID (diff)
From: Niklas Cassel <cassel@kernel.org>
To: Anand Moon <linux.amoon@gmail.com>
Cc: Grimmauld <grimmauld@grimmauld.de>,
	mani@kernel.org, "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] PCI: dw-rockchip: Enable async probe by default
Date: Tue, 3 Feb 2026 12:01:41 +0100	[thread overview]
Message-ID: <aYHVlS1nbCMMyF04@ryzen> (raw)
In-Reply-To: <CANAwSgSR7AYCvMXSo5UskTF3LJToOnPV9JE4XBAUzrCbWGKD_w@mail.gmail.com>

On Mon, Feb 02, 2026 at 11:35:48PM +0530, Anand Moon wrote:
> On Mon, 2 Feb 2026 at 15:25, Niklas Cassel <cassel@kernel.org> wrote:
> >
> > On Sat, Jan 31, 2026 at 03:08:42PM +0530, Anand Moon wrote:
> > > >
> > > I’ve attempted to reproduce the warning but was unable to trigger it locally.
> > >
> > > I have tested with the built-in module
> > > CONFIG_R8169=y
> > > CONFIG_R8169_LEDS=y
> > >
> > > As well as the module
> > > CONFIG_R8169=m
> > > CONFIG_R8169_LEDS=y
> > >
> >
> > I'm running with:
> > CONFIG_R8169=y
> > CONFIG_PHYLIB=y
> > CONFIG_REALTEK_PHY=y
> > CONFIG_REALTEK_PHY_HWMON=y
> >
> I feel CONFIG_R8169 should not be built into the kernel image.
> Since the driver is registered via module_pci_driver(rtl8169_pci_driver),
> it is intended to be loaded as a module. In addition, this driver
> requires external firmware
> during initialization, which could make a built‑in configuration problematic.
> Keeping it modular ensures proper firmware loading and avoids
> early‑boot failures.

For what it is worth, I strongly disagree that you should not be allowed
to build something as built-in just because the driver is registered using
module_pci_driver().

In order to use NFS root, and to avoid the hassle of using an initramfs,
having the driver as built-in is a logical option.
Anyway, this is currently working fine with my setup today, and is
unrelated to the phylib splat that I have reported in this thread.

I know that the R8169 driver tries to load a firmware blob, I used to have
an initramfs just to be able to load this firmware blob, but I found out
that the driver probes and works perfectly fine even without the loading
any firmware, therefore I no longer use an initramfs.
Again, this is working perfectly fine today, and the R8169 loading or not
loading any firmware is unrealated to the phylib splat.

(Just for clarity, I don't think that the phylib splat should stop this
patch from being accepted.)


Kind regards,
Niklas

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2026-02-03 11:01 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-09  7:36 [PATCH v2] PCI: dw-rockchip: Enable async probe by default Anand Moon
2024-08-09  7:36 ` Anand Moon
2025-01-03 11:31 ` Niklas Cassel
2025-01-03 11:31   ` Niklas Cassel
2025-01-03 13:54   ` Anand Moon
2025-01-03 13:54     ` Anand Moon
2025-01-03 14:25     ` Niklas Cassel
2025-01-03 14:25       ` Niklas Cassel
2025-01-03 14:40       ` Anand Moon
2025-01-03 14:40         ` Anand Moon
2025-01-03 14:45         ` Niklas Cassel
2025-01-03 14:45           ` Niklas Cassel
2025-01-03 15:06           ` Anand Moon
2025-01-03 15:06             ` Anand Moon
2025-01-03 15:10             ` Niklas Cassel
2025-01-03 15:10               ` Niklas Cassel
2025-01-03 15:29               ` Anand Moon
2025-01-03 15:29                 ` Anand Moon
2025-01-03 15:45                 ` Niklas Cassel
2025-01-03 15:45                   ` Niklas Cassel
2025-01-05 16:35                 ` Manivannan Sadhasivam
2025-01-05 16:35                   ` Manivannan Sadhasivam
2025-01-05 17:46       ` Anand Moon
2025-01-05 17:46         ` Anand Moon
2025-01-03 16:04     ` Andrew Lunn
2025-01-03 16:04       ` Andrew Lunn
2025-01-05 17:46       ` Anand Moon
2025-01-05 17:46         ` Anand Moon
2025-01-05 17:57         ` Andrew Lunn
2025-01-05 17:57           ` Andrew Lunn
2025-01-06  7:58           ` Anand Moon
2025-01-06  7:58             ` Anand Moon
2025-01-06 12:02             ` Niklas Cassel
2025-01-06 12:02               ` Niklas Cassel
2025-01-06 13:44               ` Andrew Lunn
2025-01-06 13:44                 ` Andrew Lunn
2025-01-07 11:13                 ` Anand Moon
2025-01-07 11:13                   ` Anand Moon
2025-01-07 13:13                   ` Andrew Lunn
2025-01-07 13:13                     ` Andrew Lunn
2025-01-07 14:57                     ` Anand Moon
2025-01-07 14:57                       ` Anand Moon
2025-01-15 17:49                     ` Manivannan Sadhasivam
2025-01-15 17:49                       ` Manivannan Sadhasivam
2026-01-29 14:06 ` Grimmauld
2026-01-29 14:06   ` Grimmauld
2026-01-30 10:25   ` Niklas Cassel
2026-01-30 10:25     ` Niklas Cassel
2026-01-31  9:38     ` Anand Moon
2026-01-31  9:38       ` Anand Moon
2026-02-02  9:54       ` Niklas Cassel
2026-02-02  9:54         ` Niklas Cassel
2026-02-02 18:05         ` Anand Moon
2026-02-02 18:05           ` Anand Moon
2026-02-03 11:01           ` Niklas Cassel [this message]
2026-02-03 11:01             ` Niklas Cassel
2026-02-02 10:02     ` Niklas Cassel
2026-02-02 10:02       ` Niklas Cassel
2026-02-02 18:07       ` Anand Moon
2026-02-02 18:07         ` Anand Moon

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=aYHVlS1nbCMMyF04@ryzen \
    --to=cassel@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=grimmauld@grimmauld.de \
    --cc=heiko@sntech.de \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux.amoon@gmail.com \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.