linux-kernel - Re: [PATCHv3 0/7] gpio: extend basic_mmio

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]

Message-ID: <BANLkTik-qMKqbsdwsgA=0waiMH2f63FBzg@mail.gmail.com>
Date:	Tue, 3 May 2011 15:36:12 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Jamie Iles <jamie@...ieiles.com>
Cc:	linux-kernel@...r.kernel.org, linux@....linux.org.uk,
	tglx@...utronix.de, cbouatmailru@...il.com, arnd@...db.de,
	nico@...xnic.net
Subject: Re: [PATCHv3 0/7] gpio: extend basic_mmio_gpio for different controllers

On Tue, May 3, 2011 at 3:13 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> Oops, forgot to cc tglx...
>
> On Tue, May 3, 2011 at 3:09 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
>> While on the topic of a generic mmio gpio driver, I've been thinking a
>> lot about things that Alan, Anton, and others have been doing, and I
>> took a good look at the irq_chip_generic work[1] that tglx (cc'd) put
>> together.
>>
>> There are two things that stood out.  Alan pointed out (IIRC) that a
>> generic gpio driver should not require each bank to be encapsulated in
>> a separate struct platform_device, and after mulling over it a while I
>> agree.  It was also pointed out by Anton that often GPIO controllers
>> are embedded into other devices register addresses intertwined with
>> other gpio banks, or even other functions.
>>
>> In parallel, tglx posted the irq_chip_generic patch[1] which has to
>> deal with pretty much the same set of issues.  I took a close look at
>> how he handled it for interrupt controllers, and I think it is
>> entirely appropriate to use the same pattern for creating a
>> gpio_mmio_generic library.
>>
>> [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/113697
>>
>> So, the direction I would like to go is to split the basic_mmio_gpio
>> drivers into two parts;
>>  - a platform_driver, and
>>  - a gpio_mmio_generic library.
>>
>> The platform driver would be responsible for parsing pdata and/or
>> device tree node data, but would call into the gpio_mmio_generic
>> library for actually registering the gpio banks.
>>
>> I envision the gpio_mmio_generic library would look something like
>> this:
>>
>> First, a structure for storing the register offsets froma  base
>> address:
>>
>> struct gpio_mmio_regs {
>> };

Gah, I'm doing real well this afternoon.  Ignore the above structure.
I intended to delete it from the email.

>>
>> Next, a structure for each generic mmio gpio instance:
>>
>> struct gpio_mmio_generic {
>>        spinlock_t      lock;
>>
>>        /* initialized by user */
>>        unsigned long   reg_data;
>>        unsigned long   reg_set;
>>        unsigned long   reg_clr;
>>        unsigned long   reg_dir;

And these are intended to be register offsets from the base address;
however, since the caller is responsible for ioremapping anyway, this
could just as easily be direct pointers to the registers.

>>
>>        void __iomem    *reg_base;
>>
>>        /* Runtime register value caches; may be initialized by user */
>>        u32             data_cache;
>>        u32             dir_cache;
>>
>>        /* Embedded gpio_chip.  Helpers functions set up accessors, but user
>>         * can override before calling gpio_mmio_generic_add() */
>>        struct gpio_chip chip;
>> };
>>
>> And then some helpers for initializing/adding/removing the embedded gpio_chip:
>>
>> void gpio_mmio_generic_setup(struct gpio_mmio_generic *gmg, int register_width);
>> int gpio_mmio_generic_add(struct gpio_mmio_generic *gmg);
>> void gpio_mmio_generic_remove(struct gpio_mmio_generic *gmg);
>>
>> gpio_mmio_generic_setup() sets up the common callback ops in the
>> embedded gpio_chip, but the decisions it makes could be overridden by
>> the user before calling gpio_mmio_generic_add().
>>
>> I've not had time to prototype this yet, but I wanted to get it
>> written down and out onto the list for feedback since I probably won't
>> have any chance to get to it until after UDS.  Bonus points to anyone
>> who wants to take the initiative to hack it together before I get to
>> it.  Extra bonus points to anyone who also converts some of the other
>> gpio controllers to use it.  :-D
>
> And triple bonus points to anyone who thinks this is stupid and comes
> up with a better approach.  :-)
>
> g.
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/