lkml.org 
[lkml]   [2012]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RESEND] x86, intel_mid: ADC management
    On 4/11/2012 11:24 AM, Alan Cox wrote:
    >>> Non-staging code cannot depend upon staging code. That is the rule GregKH
    >>> laid down. The Intel drivers involved are established non staging drivers
    >>> and the gpadc layer is basically cleaning up the fact they all do this
    >>> themselves in private right now without any central co-ordination or
    >>> abstraction.
    >> So, that's a bit different and not at all obvious from your e-mail - the
    >> diffstat shows only the code you're adding, not the code you've factored
    >> out of the existing mainline drivers. The diffstat you posted was:
    >>
    >> | arch/x86/include/asm/intel_mid_gpadc.h | 13 +
    >> | arch/x86/platform/mrst/Makefile | 1
    >> | arch/x86/platform/mrst/intel_mid_gpadc.c | 645 ++++++++++++++++++++++++++++++
    >> | arch/x86/platform/mrst/mrst.c | 6
    >> | 4 files changed, 665 insertions(+), 0 deletions(-)
    >>
    >> which is a pure addition of code and I'm not seeing anything in the
    >> changelog about this either.
    > True.. the code factoring out stuff is supposed to follow once this is
    > sorted.
    >
    >> We do have to be careful about this sort of "this is a little bit of low
    >> level code" thing - it (along with "our hardware is unique") comes up
    >> rather a lot and it's often missing a good chunk of the picture.
    > Yes. But it also helps - there is no user space API here so the only bit
    > of IIO that needs importing is small, and if the API in kernel changes
    > nothing userspace will break.
    If only it separated that well. There are numerous bits of iio that
    need to hack into
    the core structures still. I wish there weren't but they are there.
    >
    > I don't btw think that layer should depend upon IIO though - IIO should
    > depend upon that layer. There's no need to drag all the rest of IIO in
    > for this, just as it can depend upon the gpio layer etc.
    I have no problem with additional abstractions below. What I want to
    avoid is having
    two equivalent interfaces.
    >
    > If that code gets pulled out of IIO dumped into drivers/adc and has a bit
    > of a different API to the gpadc code then no problem, gpadc can follow it
    > happily enough. IIO can use it from staging and IIO can migrate whenever.
    Just to restate this. It doesn't go in drivers/adc. That would cover a
    tiny corner of the scope
    of IIO and make the ripped out bit effectively useless for the rest. We
    ended up with IIO because
    we couldn't come up with a term that meant input / output devices that
    are analog (in some sense)
    but not hwmon or human input related. Other name suggestions welcome!

    I'm not against this in principle but don't have the time and it will
    have to be carefully handled
    to not end up with something so limited that it is useless for IIO's
    current drivers.
    Now days there is actually relatively little bloat in the IIO core.

    In the short term I'll look at making the sysfs interfaces a build time
    option for a driver or two.

    As ever it comes down to man hours.
    >
    > It does make sense to think hard about userspace APIs for IIO but for
    > kernel APIs its really being too conservative - we break kernel APIs
    > every release. They are not set into stone.
    No problem with that. The recent core changes have all been about
    adding enough
    support for the cases Mark raised (which are pretty much the same as here).
    >
    > Alan



    \
     
     \ /
      Last update: 2012-04-11 13:41    [W:0.026 / U:30.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site