Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1720937 > unrolled thread

Re: [patch v6 0/3] JTAG driver introduction

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [patch v6 0/3] JTAG driver introduction Linus Walleij <linus.walleij@linaro.org> - 2017-08-28 00:30 +0200

#1720937 — Re: [patch v6 0/3] JTAG driver introduction

On Fri, Aug 25, 2017 at 10:50 AM, Stuart Longland
<stuartl@longlandclan.id.au> wrote:
> [Note: dropping vadimp@maellanox.com as SMTP server complained about the
> DNS server returning NXDOMAIN.  Apologies.]
> On 25/08/17 18:32, Linus Walleij wrote:
>> Gnah!
>> Whoever writes a slot-in replacement making the character device
>> take precendence wins lots of karma.
>
> What would such a replacement look like though?

Something that looks for /dev/gpiochipN and if it exists open the GPIOs
from there and make that take precedence over any /sys/gpio/*
poking.

> Some sort of system whereby you can read/write single-line commands as
> if talking to a GPIO expander over a UART?

I don't really understand the question. All GPIO expanders become
a gpiochip, and have their own character device in /dev.

> Would you access the GPIOs one by one, or would you perhaps map them
> into a bitmap (maybe arbitrarily, up to 64-bits wide) and perform masked
> operations on the bitmap?

The character device supports up to 64bits of simultaneous line
switches, but the in-kernel API can only handle 32bits
in a single register write.

> I'm no fan of the sysfs GPIO interface, but it beats poking around at
> registers behind the kernel's back.

Have a look at libgpiod and tools/gpio/* in the kernel.

Yours,
Linus Walleij

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web