linux-kernel - Re: [PATCH RFC] x86: Add user configurable GPIO-lib support

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

Hello Michael, Ingo,

Le Tuesday 01 July 2008 13:04:37 Ingo Molnar, vous avez écrit :
> * 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 only reason RDC321x is not yet converted to using gpiolib is the small 
number of actually accessible GPIOs, anyway, I will do the conversion soon.

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

This code is inherited from MIPS/ARM before GPIO lib, where generic assembly 
headers provide prototypes for the usual GPIO functions. Boards override 
those functions with their own copy of these GPIO functions.

>  #ifdef CONFIG_X86_ELAN
>  #  define PIT_TICK_RATE 1189200 /* AMD Elan has different frequency! */
>  #elif defined(CONFIG_X86_RDC321X)
>  #  define PIT_TICK_RATE 1041667 /* Underlying HZ for R8610 */
>  #else
>  #  define PIT_TICK_RATE 1193182 /* Underlying HZ */
>  #endif
>
> ... once that is made dynamic/quirkable we are there.

Yes, I did not have time to investigate this, and am still wondering if we can 
have dynamic tick rate settings in early board setup code.
-- 
Cordialement, Florian Fainelli
------------------------------
--
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/