[lkml]   [2008]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [i2c] Problem with restricted I2C algorithms in kernel 2.6.26!
On 7/26/08, Andrew Morton <> wrote:
> (cc's added)
> On Wed, 16 Jul 2008 12:33:57 -0700 "D. Kelly" <> wrote:
> >;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."

I support Jean's decision on this. Very few people know how to
correctly enable those algorithms and most people get them wrong. Now
they are set automatically.

What about merging a placeholder driver for dvb-s2 that selects the
needed i2c algorithm? Then merge a real driver as soon as possible.

My out of tree drivers are written as a patch against the kernel. The
patch contains a select for the algorithm in my Kconfig additions.
When the drivers work, I'll submit them.

> >
> > 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
> _______________________________________________
> i2c mailing list

Jon Smirl

 \ /
  Last update: 2008-07-26 16:37    [W:0.163 / U:12.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site