[i2c] [RFC] Lifebook apanel driver

Stephen Hemminger shemminger at osdl.org
Thu Jan 4 21:28:07 CET 2007


On Thu, 4 Jan 2007 15:09:20 -0500
"Dmitry Torokhov" <dmitry.torokhov at gmail.com> wrote:

> On 1/4/07, Jean Delvare <khali at linux-fr.org> wrote:
> > Hi Dmitry,
> >
> > On Thu, 4 Jan 2007 09:15:53 -0500, Dmitry Torokhov wrote:
> > > Hi Jean,
> > >
> > > On 1/4/07, Jean Delvare <khali at linux-fr.org> wrote:
> > > > >
> > > > > +config INPUT_APANEL
> > > > > +       tristate "Fujitsu Lifebook Application Panel buttons"
> > > > > +       depends on X86 && !X86_64
> > > > > +       select I2C
> > > > > +       help
> > > >
> > > > Broken indentation, you should be using tabs not spaces. Also, drivers
> > > > should depend on I2C, not select it. Mixing both tends to be confusing.
> > > >
> > >
> > > I think we should select major subsystems cores (or things needed of
> > > they are "downsteam" in config from the option being considered) and
> > > use depend either for hardware limitations or for features of a
> > > subsystem.
> >
> > I'm not discussing whether doing things differently would be better or
> > not. I'm only asking for consistency. Right now, subsystems (PCI, USB,
> > I2C) are "depended on", not "selected", and it matters to do that
> > consistently, otherwise the use gets easily confused.
> 
> I have bunch of patches (yet to be submitted) that moveinput drivers
> from drivers/usb/input to dtivers/input/... and they are selecting
> USB. If you look at menuconfig structure it dopes not make sense for
> user to have to visit input menu, then go to USB menu, then return
> back to input menu to select additional drivers that were not visible
> before.

From the user's point of view, it makes more sense to see all the input
options and then have the necessary subsystem selected.  Otherwise if
I2C is not enabled, the config option doesn't appear on menuconfig.
But for the difference is minor, and most users will either be knowledgeable
enough to figure that out or be using distribution kernels, so I really
don't care whether 'depend' or 'select' is used.


> >
> > If you think things should be different, feel free to discuss it on
> > LKML, send patches etc. but that's not the point here.
> >
> > > > > +/*
> > > > > +    SMBus client for the Fujitsu Lifebook Application Panel
> > > > > +
> > > > > +    Copyright (C) 2007 Stephen Hemminger <shemminger at osdl.org>
> > > > > +    Copyright (C) 2001-2003 Jochen Eisinger <jochen at penguin-breeder.org>
> > > > > +
> > > > > +    This program is free software; you can redistribute it and/or modify
> > > > > +    it under the terms of the GNU General Public License as published by
> > > > > +    the Free Software Foundation; either version 2 of the License, or
> > > > > +    (at your option) any later version.
> > > >
> > > > Actually not, the kernel is GPLv2 only.
> > >
> > > The kernel as a whole is GPLv2 however individual modules are not
> > > necessary GPLv2. We have mix of BSD, GPLv2 and GPLv2+. It is up to the
> > > author to decide.
> >
> > Ah, I never realized that. So I must stop asking contributors to change
> > that, thanks for letting me know.
> >
> > Now, I get to wonder what it really means in practice when Linus claims
> > loudly that "Linux is GPL v2 only", while 99% of the drivers have their
> > license set to "GPL" and not "GPL v2".
> >
> 
> In my limited understanding (not a lawyer) you can take all the code
> released under GPLv2+, replace the parts that are GPLv2 only and
> release Jeanux under GPLv3 ;)
> It is all becomes a little muddied with patches applied on top that do
> not specify license. It could be argued that since general kernel
> revision is V2 any patches are V2 only. One also argue that if person
> submitting patch wishes that the resulting code can be distributed as
> V2 only he/she should change license notice on the file in question.
> 

Original code had GPL v2 only tag, and at present I have don't want to
touch GPL v3 issues.


-- 
Stephen Hemminger <shemminger at osdl.org>



More information about the i2c mailing list