From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751333AbdKEWdZ (ORCPT ); Sun, 5 Nov 2017 17:33:25 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:43163 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750724AbdKEWdW (ORCPT ); Sun, 5 Nov 2017 17:33:22 -0500 X-Google-Smtp-Source: ABhQp+TSf/1uYqlv6AP0iIeoI7BScS/HQAPadngMs3fZYkUjF4/B0bFUHjV9UmdqhgLYeKpf8baUOQ== References: <1509724449-26221-2-git-send-email-oleksandrs@mellanox.com> User-agent: mu4e 0.9.18; emacs 25.1.1 From: Chip Bilbrey To: Oleksandr Shamray Cc: gregkh@linuxfoundation.org, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, openbmc@lists.ozlabs.org, joel@jms.id.au, jiri@resnulli.us, tklauser@distanz.ch, linux-serial@vger.kernel.org, mec@shout.net, vadimp@mellanox.com, system-sw-low-level@mellanox.com, robh+dt@kernel.org, openocd-devel-owner@lists.sourceforge.net, linux-api@vger.kernel.org, davem@davemloft.net, mchehab@kernel.org, Jiri Pirko Subject: Re: [v11,1/4] drivers: jtag: Add JTAG core driver In-reply-to: <1509724449-26221-2-git-send-email-oleksandrs@mellanox.com> Date: Sun, 05 Nov 2017 14:32:53 -0800 Message-ID: <8760aoz78q.fsf@bilbrey.org> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Oleksandr Shamray writes: > diff --git a/include/uapi/linux/jtag.h b/include/uapi/linux/jtag.h > new file mode 100644 > index 0000000..0b25a83 > --- /dev/null > +++ b/include/uapi/linux/jtag.h > [...] > +/** > + * enum jtag_xfer_mode: > + * > + * @JTAG_XFER_HW_MODE: hardware mode transfer > + * @JTAG_XFER_SW_MODE: software mode transfer > + */ > +enum jtag_xfer_mode { > + JTAG_XFER_HW_MODE, > + JTAG_XFER_SW_MODE, > +}; Is this essentially selecting between bit-bang mode or not? Is there a generally applicable reason to select SW mode over HW (or vice versa)? This sounds like it's tied to device-specific capability which shouldn't be exposed in a generic user API. > +/** > + * struct jtag_xfer - jtag xfer: > + * > + * @mode: access mode > + * @type: transfer type > + * @direction: xfer direction > + * @length: xfer bits len > + * @tdio : xfer data array > + * @endir: xfer end state > + * > + * Structure represents interface to Aspeed JTAG device for jtag sdr xfer > + * execution. Probably should remove the reference to Aspeed here. > +/* ioctl interface */ > +#define __JTAG_IOCTL_MAGIC 0xb2 > + > +#define JTAG_IOCRUNTEST _IOW(__JTAG_IOCTL_MAGIC, 0,\ > + struct jtag_run_test_idle) > +#define JTAG_SIOCFREQ _IOW(__JTAG_IOCTL_MAGIC, 1, unsigned int) > +#define JTAG_GIOCFREQ _IOR(__JTAG_IOCTL_MAGIC, 2, unsigned int) > +#define JTAG_IOCXFER _IOWR(__JTAG_IOCTL_MAGIC, 3, struct jtag_xfer) > +#define JTAG_GIOCSTATUS _IOWR(__JTAG_IOCTL_MAGIC, 4, enum jtag_endstate) I notice the single-open()-per-device lock was dropped by request in an earlier revision of your patches, but multiple processes trying to drive a single JTAG master could wreak serious havoc if transactions get interleaved. Would something like an added JTAG_LOCKCHAIN/UNLOCKCHAIN ioctl() for exclusive client access be reasonable to prevent this? -Chip