public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "D. Kelly" <user.kernel@gmail.com>
Cc: "mailing list: linux-kernel" <linux-kernel@vger.kernel.org>,
	Jean Delvare <khali@linux-fr.org>,
	i2c@lm-sensors.org
Subject: Re: Problem with restricted I2C algorithms in kernel 2.6.26!
Date: Fri, 25 Jul 2008 23:59:36 -0700	[thread overview]
Message-ID: <20080725235936.aeae8bc2.akpm@linux-foundation.org> (raw)
In-Reply-To: <5ab239b10807161233i6c1c4d0we01ea1b8e6ccaa5b@mail.gmail.com>

(cc's added)

On Wed, 16 Jul 2008 12:33:57 -0700 "D. Kelly" <user.kernel@gmail.com> wrote:

> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3845de25c5f83cd52729570f7b501679d37ca8de
> 
> The patch at the preceeding url disables the users ability to select
> I2C algorithms.  Specifically the reason stated was:
> 
> "The algorithm drivers are
> helper drivers that are selected automatically
> as needed. There's no point in listing them in the config menu, it can
> only confuse users and waste their time."
> 
> The algorithm drivers will not be 'selected automatically as needed'
> if the user is compiling something outside of the kernel that requires
> them!  Just one example, there are drivers found in the V4L dvb driver
> tree that require i2c bit-banging be enabled.  The drivers are now
> broken because the user is not allowed to enable bit-banging himself.
> The only way around this is to revert the patch manually or enable
> something else in the kernel, that he doesn't need, just to get
> bit-banging.
> 
> It's a very bad idea to assume that nothing built outside of the
> kernel may need i2c algorithms.  Furthermore, the whole point of being
> able to customize your kernel is so you can select only the things
> which you need.  It makes no good sense to intentionally
> disable/restrict the users ability to do so.  Additionally, assuming
> the ability to select i2c algorithms will only confuse the user and
> waste their time is ridiculous.  The user should be allowed to decide
> for himself what he needs regarding this!
> 
> One of the biggest reasons people choose to compile things from
> cvs/svn/mercurial/etc. is because it gives them access to newer bug
> fixes and support for things not yet present in the kernel source.  A
> perfect example, the multiproto dvb driver tree.  Users wanting
> support for dvb-s2 devices have to compile drivers outside of the
> kernel because it's simply not available in the kernel and won't be
> for some time.
> 
> I've contacted one of the i2c subsystem maintainers, Jean Delvare, but
> unfortunately he doesn't seem to care about this problem and his
> advice in dealing with it is to "Just get these drivers merged in the
> kernel. Ah ah ah!"...
> 
> Clearly the more sane and reasonable solution is to not cripple the
> menu options in the first place, especially when it creates no benefit
> and only serves to limit/restrict the users ability to select what he
> needs.  I'm asking that the patch be reverted and anyone in agreement
> to please voice their opinion here in public.
> 
> Best regards,
> -Derek

       reply	other threads:[~2008-07-26  6:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5ab239b10807161233i6c1c4d0we01ea1b8e6ccaa5b@mail.gmail.com>
2008-07-26  6:59 ` Andrew Morton [this message]
2008-07-26 14:34   ` [i2c] Problem with restricted I2C algorithms in kernel 2.6.26! Jon Smirl
     [not found] ` <5ab239b10807161233i6c1c4d0we01ea1b8e6ccaa5b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-08-07 11:13   ` Jean Delvare
     [not found]     ` <20080807131357.59399ddf-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-08-07 16:01       ` Trent Piepho
2008-08-07 16:14         ` Jean Delvare
     [not found]           ` <20080807181416.5de4ce6d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-08-07 17:19             ` Jean Delvare
     [not found]               ` <20080807191943.72d1802d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-08-07 17:29                 ` Randy Dunlap
2008-08-07 23:41           ` Trent Piepho
2008-08-08  9:37             ` Jean Delvare
2008-08-08 17:52               ` Trent Piepho
2008-08-10 11:07                 ` Adrian Bunk
2008-08-07 18:39     ` Sam Ravnborg
2008-08-07 18:49       ` Jean Delvare
2008-08-07 19:03         ` Michael Krufky
2008-08-07 21:06           ` Jean Delvare
2008-08-07 21:34 mkrufky
     [not found] ` <489B6A66.40605-dJidKbW2IEtAfugRpC6u6w@public.gmane.org>
2008-08-08  0:17   ` Stefan Richter
2008-08-08  9:28 ` Jean Delvare

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=20080725235936.aeae8bc2.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=i2c@lm-sensors.org \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=user.kernel@gmail.com \
    /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