Re: [patch v6 0/3] JTAG driver introduction
From: Linus Walleij <hidden>
Date: 2017-08-27 22:25:20
Also in:
linux-api, linux-arm-kernel, linux-serial, lkml, openbmc
From: Linus Walleij <hidden>
Date: 2017-08-27 22:25:20
Also in:
linux-api, linux-arm-kernel, linux-serial, lkml, openbmc
On Fri, Aug 25, 2017 at 10:50 AM, Stuart Longland [off-list ref] wrote:
[Note: dropping vadimp-45czdsxZ+A5DPfheJLI6IQ@public.gmane.org as SMTP server complained about the DNS server returning NXDOMAIN. Apologies.] On 25/08/17 18:32, Linus Walleij wrote:quoted
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html