mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@kernel.org>
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
	 Mikko Perttunen <mperttunen@nvidia.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	 linux-pwm@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] pwm: tegra: Cleanups and .get_state()
Date: Mon, 21 Sep 2026 12:22:44 +0200	[thread overview]
Message-ID: <arEEwg3ErxY5nNVm@orome> (raw)
In-Reply-To: <cover.1789741839.git.u.kleine-koenig@baylibre.com>

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

On Fri, Sep 18, 2026 at 04:33:44PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> v1 of this series can be found at
> https://lore.kernel.org/cover.1784030076.git.ukleinek@kernel.org.
> 
> Changes since then:
> 
>  - Reordered the patches to have dev_err_probe and dev first. Fixes a
>    build failure in the middle of v1. This way patch 2 -- which could be
>    considered a fix -- isn't before the cleanup in patch 1, but doing
>    patch 1 the old way first also feels strange.
> 
>  - add { } around blocks with a single statement if there is also a
>    comment.
> 
>  - fixed too many parenthesis in patch #3 (formerly #6).
> 
>  - dropped other patches as they reorder stuff in unwanted or at least
>    untested ways.
> 
> There was a concern in reply to patch #1 of the v1 series (now #2) from
> Mikko Perttunen. He wrote: 
> 
> > I feel like driver_override falls in the realm of 'root can mess with
> > the system as they feel like but if they don't know what they're doing
> > they get to keep the pieces'. So adding a check in every driver, or
> > in practice having a random mix of drivers with and without the check,
> > doesn't seem necessary to me.
> > 
> > If we actually want to check for this condition, could it be done
> > centrally instead? I.e. don't call probe if there's no match data and
> > the driver's match table implies it requires it.
> 
> It cannot be done reliably in the driver core, and IMHO even root
> shouldn't be able to trigger a NULL pointer exception. So I kept the
> check.

As I mentioned in a comment to the patch, I second Mikko's concern.
Adding validity checks for device data seems like one of those
boilerplate things we should be able to avoid. We never match by name in
the drivers and if driver_override is the only reason why the device
data might end up being NULL, then driver_override should be completely
disabled for this driver because it simply isn't going to work without
the match data (as evidenced by your patch returning an error code in
that case).

I'll take a look at adding a way for the core to let drivers opt-out of
driver_override if it doesn't make sense for them.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      parent reply	other threads:[~2026-09-21 10:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 14:33 Uwe Kleine-König
2026-09-18 14:33 ` [PATCH v2 1/3] pwm: tegra: Make use of dev_err_probe() Uwe Kleine-König
2026-09-21  9:38   ` Thierry Reding
2026-09-21 12:46     ` Uwe Kleine-König
2026-09-21 16:14       ` Thierry Reding
2026-09-18 14:33 ` [PATCH v2 2/3] pwm: tegra: Check for match_data being NULL Uwe Kleine-König
2026-09-21  9:47   ` Thierry Reding
2026-09-21 14:34     ` Uwe Kleine-König
2026-09-21 16:24       ` Thierry Reding
2026-09-21 20:10         ` Uwe Kleine-König
2026-09-18 14:33 ` [PATCH v2 3/3] pwm: tegra: Implement .get_state() Uwe Kleine-König
2026-09-21 10:18   ` Thierry Reding
2026-09-21 14:26     ` Uwe Kleine-König
2026-09-21 10:22 ` Thierry Reding [this message]

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=arEEwg3ErxY5nNVm@orome \
    --to=thierry.reding@kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mperttunen@nvidia.com \
    --cc=p.zabel@pengutronix.de \
    --cc=u.kleine-koenig@baylibre.com \
    /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

all inboxes | Powered by JetHome®