linux-kernel - Re: [PATCH] ALSA: cs5535audio: only build OLPC support if MGEODE

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 14 Nov 2008 10:34:49 -0700
From:	Jordan Crouse <jordan@...micpenguin.net>
To:	Pavel Machek <pavel@...e.cz>
CC:	Andres Salomon <dilinger@...ued.net>, Takashi Iwai <tiwai@...e.de>,
	Ingo Molnar <mingo@...e.hu>, Jeremy Katz <katzj@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jordan Crouse <jordan.crouse@....com>,
	linux-kernel@...r.kernel.org, dsaxena@...top.org
Subject: Re: [PATCH] ALSA: cs5535audio: only build OLPC support if	MGEODE_LX
 is defined

Pavel Machek wrote:
> HI!
> 
>>>> i've zapped this patch meanwhile:
>>>>
>>>>  1355c96: x86/olpc: make CONFIG_OLPC dependent on CONFIG_MGEODE_LX
>>>>
>>>> because it cripples the ability to run distribution kernels on the 
>>>> OLPC.
>>> OK, I reverted also all relevant changes for cs5535audio driver now.
>>> The patches are saved in topic/cs5535audio branch, though.
>>>
>>> Let's fix OLPC-geode coupling first.
>> Hm, I'd really rather prefer this to be upstream.  The patch I sent adds
>> no regressions, allows the driver to happily coexist with existing
>> stuff, and *does* add support if you configure OLPC with MGEODE_LX
>> (generic kernels don't get the additional benefits, but those configured
>> specifically for OLPC do).
> 
> Yes, but the patch is also not a good way of going forward, so it
> should not be in mainline.

For the moment, this is a reasonable intermediate solution.  I think the 
way forward will involve a great deal more work.

The driver does need to be able to twiddle the GPIO pins, and the GPIO 
pins are unique to the CS5536.  In the past, the CS5536 has been only 
associated with the Geode, and 99.99% of the kernel users in the world 
don't need Geode, so it make sense to omit specific code of this nature.
As you might expect, I'm not in the "you should be able to run an 
arbitrary kernel on the XO" crowd.

That said, its clear that people are interested in doing so - so a 
change needs to be made.  The immediate option is to turn on Geode 
support for all x86 kernels, but thats a few extra K in the kernel 
binary that nobody needs.  So we'll have to go modular.

I talked to Andres about this yesterday.  The immediately obvious 
solution would be to port the Geode GPIO support into the existing GPIO 
subsystem.  That is attractive, but it omits some of the other Geode 
goodness that might be of interest to a "standard kernel" not configured 
for MGEODE_LX (such as the Geode watchdog timer).  So, I think we should 
move most of the Geode code into a support module and remove MGEODE_LX 
checks in most places.  The distributions can build the module and put 
it in the file system, and serious Geode users such as OLPC can build it 
in to the kernel binary.

Also, while we are at it, we should be more specific and rename the 
hooks from geode_ to cs5536_, since there will soon be a system in the 
wild with a MIPS processor and a CS5536.

But needless to say, this will be a goodly amount of work and churn that 
will need some heavy testing in the OLPC kernel.  In the meantime, 
Andres' fix will make the upstream kernel happier.

Jordan

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