mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Hans Verkuil <hans@jjverkuil.nl>
Subject: Re: [GIT PULL for v7.4] media updates
Date: Mon, 26 Oct 2026 21:13:19 +0200	[thread overview]
Message-ID: <20261026191319.GA1996520@killaraus.ideasonboard.com> (raw)
In-Reply-To: <at-a-2wTtf7bJQwU@kekkonen.localdomain>

On Mon, Oct 26, 2026 at 08:24:59PM +0200, Sakari Ailus wrote:
> Hi Linus, Mauro,
> 
> On Mon, Oct 26, 2026 at 07:34:12AM -1000, Linus Torvalds wrote:
> > On Sat, 24 Oct 2026 at 06:51, Mauro Carvalho Chehab wrote:
> > > Sakari Ailus (60):
> > >       media: Don't hide I²C or SPI drivers by default
> > 
> > This needs to be fixed some way.
> > 
> > The kernel config is asking about ridiculous things that no sane user
> > can know the answer to. And that change has made it worse.
> > 
> > Asking a user for random media drivers by chip ID is *NOT* ok. It
> > needs to be hidden some way. If the old way didn't work, some new way
> > needs to happen.
> > 
> > Guys, the kernel config phase is already *the* most annoying thing for
> > people trying to build their own kernel. Don't make it worse by asking
> > questions that make no sense to a normal user.
> 
> The patch in question puts camera sensors and related chips in line with
> how the rest of the drivers are selected elsewhere.
> 
> The reason why I wrote the patch was that Arch Linux kernel missed enabling
> these drivers, which given how the MEDIA_HIDE_ANCILLARY_SUBDRV option
> worked before the patch was to be expected at some point (rather it's a
> small miracle no-one had complained about this earlier). Raw camera sensors
> are quite common in laptops these days and the only way to enable compiling
> them before my patch was to enable CONFIG_EXPERT first.
> 
> I guess we could have an option to compile pretty much all media drivers as
> modules (it may be hard to draw a line) and then require CONFIG_EXPERT to
> allow choosing amongst them. I'm not sure I like that idea much though.

As far as I understand, the goal of the patch was to stop hiding the
"Miscellaneous helper chips" section by default, and let users select
VIDEO_INTEL_CVS. While the commit message states that it applies to all
camera and lens VCM drivers, that doesn't seem to be the case, those are
not covered by MEDIA_HIDE_ANCILLARY_SUBDRV today as far as I can tell.

One simple option could be to drop MEDIA_HIDE_ANCILLARY_SUBDRV only for
the section that covers the CVS. It's not ideal, but it could be a quick
fix until we find a better option.

Junjie also proposed automatically selecting VIDEO_INTEL_CVS in
VIDEO_INTEL_IPU6 and VIDEO_INTEL_IPU7. You didn't like that because CVS
is an I2C device separate from the IPU6 and IPU7, but is it found in any
platform other than in conjunction with an IPU6 or IPU7 ?

> I wonder what others think.
> 
> Also cc Hans and Laurent.

-- 
Regards,

Laurent Pinchart

      parent reply	other threads:[~2026-10-26 19:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24 16:50 Mauro Carvalho Chehab
2026-10-25  5:51 ` pr-tracker-bot
2026-10-26 17:34 ` Linus Torvalds
2026-10-26 18:24   ` Sakari Ailus
2026-10-26 18:53     ` Linus Torvalds
2026-10-26 23:56       ` Mauro Carvalho Chehab
2026-10-27  0:04         ` Mauro Carvalho Chehab
2026-10-27  7:37         ` Laurent Pinchart
2026-10-27  8:01           ` Mauro Carvalho Chehab
2026-10-27 10:09       ` [PATCH 1/1] Revert "media: Don't hide I²C or SPI drivers by default" Sakari Ailus
2026-10-27 10:19         ` Laurent Pinchart
2026-10-27 11:03           ` Sakari Ailus
2026-10-26 19:13     ` Laurent Pinchart [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=20261026191319.GA1996520@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hans@jjverkuil.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®