linux-kernel - Re: [PATCH RESEND] x86, intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120410175632.5c11c36e@pyramind.ukuu.org.uk>
Date:	Tue, 10 Apr 2012 17:56:32 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] x86, intel_mid: ADC management

> > 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.

Given the responses I got to moving it out of staging were of the "not
yet" and "no" variety it hardly got a request to be worked upon.

> > 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

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.

> 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.

I've been saying this for over a year. It's still a huge blob of code
that isn't needed for pure low level stuff, but that's fixable and
something which can eventually be worked upon.

You are trying to make the tail wag the dog. Staging is basically out of
kernel. The x86 stuff is *in kernel*, this driver is the basis of
cleaning it up. We can sort out making it talk to IIO later. Right now
all you are doing is blocking a pile of much needed code cleanups, and
without them you *won't* have an API for the gpadc on Intel, it'll be
hardcoded in each driver still. That will mean you have *zero* change of
getting IIO support at all.

Whether gpadc then adopts an IIO interface is a question to ask later,
after (if) IIO is ever merged. If the platform ever starts using gpadc
for non internal hardware stuff then I'm pretty sure it'll end up adopting
whatever generic GPADC layer eventually emerges simply because we'll want
to share drivers.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/