linux-kernel - Re: [PATCH] [RESEND] media: tea5764: reconcile Kconfig symbol and macro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1319994738.14409.37.camel@x61.thuisdomein>
Date:	Sun, 30 Oct 2011 18:12:18 +0100
From:	Paul Bolle <pebolle@...cali.nl>
To:	Randy Dunlap <rdunlap@...otime.net>
Cc:	Mauro Carvalho Chehab <mchehab@...radead.org>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RESEND] media: tea5764: reconcile Kconfig symbol and
 macro

On Sun, 2011-10-30 at 09:43 -0700, Randy Dunlap wrote:
> On 10/30/11 05:08, Paul Bolle wrote:
> > The Kconfig symbol RADIO_TEA5764_XTAL is unused. The code does use a
> > RADIO_TEA5764_XTAL macro, but does that rather peculiar. But there seems
> > to be a way to keep both. (The easiest way out would be to rip out both
> > the Kconfig symbol and the macro.)
> > 
> > Note there's also a module parameter 'use_xtal' to influence all this.
> 
> It's curious that the module parameter is only available when the driver
> is builtin (=y) but not built as a loadable module (=m):

As far as I can see the module parameter is available in both cases but
defaults to different values when builtin and when loadable. 

> config RADIO_TEA5764_XTAL
> 	bool "TEA5764 crystal reference"
> 	depends on RADIO_TEA5764=y
> 	default y

0) I've noticed similar dependencies (while doing some other Kconfig
related clean up) with a number of other config entries in that same
Kconfig file:
    $ git grep -n "depends on.*=y" drivers/media/radio/
    drivers/media/radio/Kconfig:60: depends on RADIO_RTRACK=y
    drivers/media/radio/Kconfig:83: depends on RADIO_RTRACK2=y
    drivers/media/radio/Kconfig:106:        depends on RADIO_AZTECH=y
    drivers/media/radio/Kconfig:135:        depends on RADIO_GEMTEK=y
    drivers/media/radio/Kconfig:147:        depends on RADIO_GEMTEK=y
    drivers/media/radio/Kconfig:239:        depends on RADIO_TERRATEC=y
    drivers/media/radio/Kconfig:257:        depends on RADIO_TRUST=y
    drivers/media/radio/Kconfig:280:        depends on RADIO_TYPHOON=y
    drivers/media/radio/Kconfig:287:        depends on RADIO_TYPHOON=y
    drivers/media/radio/Kconfig:314:        depends on RADIO_ZOLTRIX=y
    drivers/media/radio/Kconfig:385:        depends on RADIO_TEA5764=y 

1) It seems the logic behind those config symbols is mostly like this:
- if the driver for a radio is builtin: default some setting for that
  radio to a sane value, but allow overriding of that setting on the
  kernel commandline (through a module parameter)
- if the driver for a radio is a module: default that same setting to
  something invalid and _force_ the use of module parameters to get a
  sane value

This logic isn't implemented flawless but it does look to me that this
is intentional.

2) I'm not sure why things are done that way. Why can't builtin drivers
and loadable drivers default to identical values? But perhaps I'm just
misunderstanding the code.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/