From: "Danilo Krummrich" <dakr@kernel.org>
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: "Thierry Reding" <thierry.reding@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-pwm@vger.kernel.org, linux-tegra@vger.kernel.org,
"Thierry Reding" <treding@nvidia.com>,
"Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
Subject: Re: [PATCH 1/2] driver: core: Allow drivers to opt out of driver_override
Date: Tue, 22 Sep 2026 14:49:56 +0200 [thread overview]
Message-ID: <DLLUW8UZUU4G.3FX7WHWGVM1T4@kernel.org> (raw)
In-Reply-To: <2026092227-marbling-untying-c1df@gregkh>
On Tue Sep 22, 2026 at 2:13 PM CEST, Greg Kroah-Hartman wrote:
> On Tue, Sep 22, 2026 at 01:38:28PM +0200, Thierry Reding wrote:
>> From: Thierry Reding <treding@nvidia.com>
> What's wrong with just not allowing bind/unbind at all? Why would you
> want that, but NOT the driver_override file?
pwm-tegra is a platform driver, but for drivers on hot-pluggable buses we still
want bind/unbind for testing, even if we opt-out from driver_override.
Besides that, I think that even for buses that do not have hotplug, there are
cases where it can be useful to be able test whether a driver survives
bind/unbind (i.e. follows the device driver lifecycle rules). E.g. because the
same IP will later receive an implementation on a hot-pluggable bus that shares
driver code, or just to validate driver design in general.
next prev parent reply other threads:[~2026-09-22 12:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 11:38 [PATCH 0/2] driver: core: Allow drivers to opt out of driver_override Thierry Reding
2026-09-22 11:38 ` [PATCH 1/2] " Thierry Reding
2026-09-22 12:13 ` Greg Kroah-Hartman
2026-09-22 12:49 ` Danilo Krummrich [this message]
2026-09-22 13:17 ` Uwe Kleine-König
2026-09-22 14:09 ` Thierry Reding
2026-09-25 17:21 ` Uwe Kleine-König
2026-09-22 11:38 ` [PATCH 2/2] pwm: tegra: Opt " Thierry Reding
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=DLLUW8UZUU4G.3FX7WHWGVM1T4@kernel.org \
--to=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=thierry.reding@kernel.org \
--cc=treding@nvidia.com \
--cc=u.kleine-koenig@baylibre.com \
--cc=ukleinek@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.