netdev - Re: randconfig build error with next-20141001, in drivers/i2c/algos/i2c-algo-bit.c

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: <5432D3E6.9020805@hartkopp.net>
Date:	Mon, 06 Oct 2014 19:39:50 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Randy Dunlap <rdunlap@...radead.org>,
	Jim Davis <jim.epost@...il.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>
CC:	linux-next <linux-next@...r.kernel.org>,
	Stephane Grosjean <s.grosjean@...k-system.com>,
	linux-i2c@...r.kernel.org,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	linux-can@...r.kernel.org
Subject: Re: randconfig build error with next-20141001, in drivers/i2c/algos/i2c-algo-bit.c



On 10/06/2014 06:52 PM, Randy Dunlap wrote:
> On 10/06/14 01:06, Oliver Hartkopp wrote:
>> Hello all,
>>
>> just to get it right:
>>
>> So far it looks like this in linux/drivers/net/can/sja1000/Kconfig
>>
>> config CAN_PEAK_PCIEC
>>         bool "PEAK PCAN-ExpressCard Cards"
>>         depends on CAN_PEAK_PCI
>>         select I2C
>>         select I2C_ALGOBIT
>>
>> If one would change the
>>
>>         select I2C
>>
>> into
>>
>>         depends on I2C
>>
>> IMHO the CAN_PEAK_PCIEC hardware would *only* be visible and selectable when
>> I2C was selected before (from anyone else?).
> 
> That is correct.
> 
>> So what it wrong on the current Kconfig entry?
>> Is 'select' deprecated?
> 
> No, it's not deprecated.  It's just dangerous.  and driver configs should not
> enable entire subsystems via 'select'.
> 
>> Or did randconfig generate a configuration that would not be possible by
>> properly generating the config file with 'make menuconfig' ??
> 
> randconfig generated a config for another driver which causes a build error,
> not for a CAN driver.  The CAN driver does not have a build error AFAIK.
> Its Kconfig is just doing something with a very big & ugly stick.

But when it is not done like this, we might have an invisible config option in
the corner case that I2C is not enabled by anyone else.

So what would you propose then?

AFAICS there is 'just' a style problem as 'configs should not enable entire
subsystems'. But it finally is a correct and valid Kconfig, right?

When I2C is already enabled - fine. If (unlikely) I2C is not enabled, we need
to pull the ugly stick. So what is dangerous on this? Was there any misuse of
select statements before?

Best regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html