All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] x86, intel_mid: ADC management
Date: Tue, 10 Apr 2012 16:19:43 +0100	[thread overview]
Message-ID: <20120410151943.GM7499@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120410151529.5bcc5ce6@pyramind.ukuu.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Tue, Apr 10, 2012 at 03:15:29PM +0100, Alan Cox wrote:
> > Could you be more specific about what this early boot time stuff is?
> > Looking at the changelogs in there it all looks like the standard
> > battery monitoring and power supply stuff that these ADCs get used for -
> > just based on the changelogs there doesn't appear to be anything
> > remarkable here.

> It depends on the actual device but things the like battery management
> are a key one.

Right, like I say that all sounds totally standard and unremarkable.

> > We can't just keep on going round adding new custom interfaces every
> > time someone supports a new SoC - it means we end up having to sit and

> We can't go around blocking entire platforms because of the IIO blob. I
> raised this point with the whole previous *generation* of Intel SoC
> devices about IIO and nothing has been done about it.

Including by Intel, of course.

> Get IIO out of staing and we can look at it, until then IIO is staging
> code, it's not part of the kernel, it may never be part of the kernel,
> and it should never block actual kernel code.

That's not where the rest of the embedded community has been coming from
on this stuff and from a deployment point of view staging isn't really
that big a blocker to users.  We've had a lot of experience with trying
to follow that approach and the results haven't been great thus far.

Frankly at this point I don't understand why we can't just lift IIO out
of staging as-is, perhaps with the userspace ABI nobbled or moved into
debugfs for the time being if that's still a concern.  Alternatively
there is the option of you proposing some other generic framework.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-04-10 15:19 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-10 13:20 [PATCH RESEND] x86, intel_mid: ADC management Alan Cox
2012-04-10 13:12 ` Mark Brown
2012-04-10 13:25   ` Alan Cox
2012-04-10 13:33     ` Mark Brown
2012-04-10 13:42       ` Alan Cox
2012-04-10 14:07         ` Mark Brown
2012-04-10 14:15           ` Alan Cox
2012-04-10 15:19             ` Mark Brown [this message]
2012-04-10 16:56               ` Alan Cox
2012-04-10 17:58                 ` Mark Brown
2012-04-10 19:39                   ` Jonathan Cameron
2012-04-10 22:37                     ` Mark Brown
2012-04-11  6:19                       ` Jonathan Cameron
2012-04-11  6:19                         ` Jonathan Cameron
2012-04-11  7:44                         ` Jonathan Cameron
2012-04-11 15:38                         ` Greg Kroah-Hartman
2012-04-11 16:30                           ` Jonathan Cameron
2012-04-11 23:46                             ` Greg Kroah-Hartman
2012-04-12  6:25                               ` Jonathan Cameron
2012-04-11 10:24                   ` Alan Cox
2012-04-11 10:38                     ` Mark Brown
2012-04-11 10:48                       ` Jonathan Cameron
2012-04-11 11:13                         ` Alan Cox
2012-04-11 11:19                           ` Jonathan Cameron
2012-04-11 12:30                             ` Alan Cox
2012-04-11 12:55                               ` Jonathan Cameron
2012-04-12 17:53                               ` Mark Brown
2012-04-12 18:04                             ` Mark Brown
2012-04-11 11:38                     ` Jonathan Cameron

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=20120410151943.GM7499@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.