Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751516AbdH0WZU (ORCPT ); Sun, 27 Aug 2017 18:25:20 -0400 Received: from mail-oi0-f49.google.com ([209.85.218.49]:33543 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751436AbdH0WZQ (ORCPT ); Sun, 27 Aug 2017 18:25:16 -0400 MIME-Version: 1.0 In-Reply-To: <593cd0d3-8e06-0992-c155-1322014c0477@longlandclan.id.au> References: <1503418256-5215-1-git-send-email-oleksandrs@mellanox.com> <593cd0d3-8e06-0992-c155-1322014c0477@longlandclan.id.au> From: Linus Walleij Date: Mon, 28 Aug 2017 00:25:14 +0200 Message-ID: Subject: Re: [patch v6 0/3] JTAG driver introduction To: Stuart Longland Cc: Rick Altherr , Oleksandr Shamray , "devicetree@vger.kernel.org" , =?UTF-8?B?SmnFmcOtIFDDrXJrbw==?= , Arnd Bergmann , system-sw-low-level@mellanox.com, Greg KH , OpenBMC Maillist , "linux-kernel@vger.kernel.org" , openocd-devel-owner@lists.sourceforge.net, mec@shout.net, Rob Herring , "linux-serial@vger.kernel.org" , Tobias Klauser , "linux-api@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1317 Lines: 36 On Fri, Aug 25, 2017 at 10:50 AM, Stuart Longland 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