lkml.org 
[lkml]   [2013]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Tue, May 07, 2013 at 09:15:00AM -0400, Eduardo Valentin wrote:
> > But broadly the direction seems that drivers should have minimal
> > dependencies so, eg, the thermal maintainer compiling for x86 should
> > be able to compile test/static analyze your driver..

> Well, I do not see much of this attempt actually. Do you have some link
> / evidene that shows someone who actually cares about compiling drivers
> for targets that they are not used for? On this specific driver, I
> actually have had exactly the opposite advice [1]. I am not convinced
> people actually want to do that.

There was a discussion a bit ago, but I can't find a link.. The
context was subsystem maintainers are being asked to look after more
code with the DT transition moving things out of arch/arm and at least
one complained they couldn't even compile test on x86... But again, I
can't find a link and you are right, there are lots and lots of
'depends ARCH..' style things in kConfig already.

Lets just call it something to think about.

> >> Thats the idea behind this config option. It follows the same design as
> >> CONFIG_ARCH_HAS_CPUFREQ, for instance.
> >
> > That is entirely contained inside arch/arm and doesn't involve
> > drivers.
>
> It actually goes outside arch/arm.

Hm, must have missed that, seemed like all it did was control
including drivers/cpufreq/Kconfig within the ARM kconfigs.. And
unicore32 copied the name, but did the same thing.

Regards,
Jason


\
 
 \ /
  Last update: 2013-05-07 20:41    [W:0.047 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site