All of lore.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: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16 19:33 Problem with restricted I2C algorithms in kernel 2.6.26! D. Kelly
2008-07-26  6:59 ` Andrew Morton [this message]
2008-07-26 14:34   ` [i2c] " Jon Smirl
     [not found] ` <5ab239b10807161233i6c1c4d0we01ea1b8e6ccaa5b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-08-07 11:13   ` Jean Delvare
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:01         ` [i2c] " Trent Piepho
2008-08-07 16:14         ` Jean Delvare
     [not found]           ` <20080807181416.5de4ce6d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-08-07 17:19             ` Jean Delvare
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 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
  -- strict thread matches above, loose matches on Subject: below --
2008-08-07 21:34 mkrufky
     [not found] ` <489B6A66.40605-dJidKbW2IEtAfugRpC6u6w@public.gmane.org>
2008-08-08  0:17   ` Stefan Richter
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.