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]
Date:	Tue, 1 Jul 2008 13:13:40 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	linux-kernel <linux-kernel@...r.kernel.org>,
	florian.fainelli@...ecomint.eu,
	the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH RFC] x86: Add user configurable GPIO-lib support

On Tuesday 01 July 2008 13:04:37 Ingo Molnar wrote:
> 
> * Michael Buesch <mb@...sch.de> wrote:
> 
> > So this adds user-configurable GPIO support through gpiolib on 
> > subarchitectures that do not implement a GPIO implementation, yet. 
> > Currently that's everything except X86_RDC321X.
> > 
> > The advantage of this is to make it possible to use generic PCI (or 
> > other bus) GPIO extention cards in standard PCs through the standard 
> > GPIO API.
> > 
> > If another subarch implements its own GPIO, it needs to add itself as 
> > an inverted dependency to GPIO_USERSELECTION to make sure the user 
> > does not enable two GPIO API implementations.
> > 
> > About the asm-x86/gpio.h:
> > I'm not sure what this <gpio.h> include currently is.
> > Can somebody explain that to me? Where is this supposed
> > to include a gpio.h file from?
> > 
> > What's your opinion on this?
> 
> ( i've Cc:-ed Florian on this who's maintaining the RDC R-321X bits. )
> 
> The longer-term goal is that we'd like to remove the explicit RDC 
> sub-arch and just support such systems out of box on x86.

nice :)

> ... and thus perhaps your GPIO_USERSELECTION patch should move into 
> drivers/ and be generally accessible, not special to x86?

Yes I'd really like to move it there, too. But currently that
clashes with architectures like MIPS, some PPC flavours and probably
others that implement their own GPIO API.
We should have an ARCH_IMPLEMENT_GPIO or whatever, but currently we
don't seem to have that.

So well. If it's desired to put the user selection into drivers/gpio
(which I'd really prefer), I can try to make a patch that adds
ARCH_IMPLEMENT_GPIO to every arch that implements their own GPIO API
and make GPIO_USERSELECTION depend on !ARCH_IMPLEMENT_GPIO.

-- 
Greetings Michael.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ