linux-kernel - Re: GPIO: Performance sensitive applications, gpiochip-level locking

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: <CACRpkdY4HBmNUMAE6LzGEjR05x+XunxeQrazRk9JLAiHjOcz3A@mail.gmail.com>
Date:	Fri, 11 Oct 2013 16:02:20 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Darren Hart <dvhart@...ux.intel.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: GPIO: Performance sensitive applications, gpiochip-level locking

On Mon, Sep 30, 2013 at 7:29 PM, Darren Hart <dvhart@...ux.intel.com> wrote:

> I'm currently working with a graphics driver that makes use of 2 GPIO
> pins for EDID communication (clock and data). In order to coexist
> peacefully with the driver for the GPIO chip, it must use gpiolib to
> request the lines, set direction, and set values. This results in a
> spinlock/unlock for every operation with this particular gpio driver.

Do you mean that this particular GPIO driver (which one?)
has a problem with this, or do you mean that there is something
in the gpiolib architecture that prevents you from augmenting
the GPIO driver to do what you want?

I can't see that we're taking any locks in the GPIOlib core.

> It would be preferable to lock the resources once, perform the EDID
> communication, then unlock the resources. The resources in this case are
> the value and direction registers off the PCI GPIO base address register
> which is shared with the other lines provided by the GPIO chip.
>
> Is there a best practice for dealing with this kind of configuration?

No.

> If not, would it make sense to add optional gpiochip-level lock/unlock
> and lockless direction and value operations to the gpiochip function
> block?

How do you imagine the API?

I can imagine something like:

gpio_bitbang_array(struct gpio_desc *desc, int value *, unsigned int values)
{
   /* Fall all the way through to the driver */
}

Or even:

struct bitbang_entry {
    unsigned int val;
    unsigned int delay_after;
}

gpio_bitbang_array(struct gpio_desc *desc,
                            struct bitbang_entry **,
                            int entries);

In either case (for the rough sketches) the gpiolib core has to fall back to
iterating over the array and just using set_value() if the accelerated ops
are not supported by the driver.

Possibly things can be learned from other parts of the kernel here.

Yours,
Linus Walleij
--
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/