From: chip@bilbrey•org (Chip Bilbrey)
To: linux-arm-kernel@lists•infradead.org
Subject: [v11,1/4] drivers: jtag: Add JTAG core driver
Date: Sun, 05 Nov 2017 14:32:53 -0800 [thread overview]
Message-ID: <8760aoz78q.fsf@bilbrey.org> (raw)
In-Reply-To: <1509724449-26221-2-git-send-email-oleksandrs@mellanox.com>
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
next prev parent reply other threads:[~2017-11-05 22:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-03 15:54 [patch v11 0/4] JTAG driver introduction Oleksandr Shamray
2017-11-03 15:54 ` [patch v11 1/4] drivers: jtag: Add JTAG core driver Oleksandr Shamray
2017-11-04 11:36 ` Greg KH
2017-11-05 22:32 ` Chip Bilbrey [this message]
2017-11-06 14:28 ` [v11,1/4] " Oleksandr Shamray
2017-11-14 10:34 ` Oleksandr Shamray
2017-11-14 11:10 ` gregkh at linuxfoundation.org
2017-11-14 11:19 ` Russell King - ARM Linux
2017-11-14 11:31 ` gregkh at linuxfoundation.org
2017-11-03 15:54 ` [patch v11 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver Oleksandr Shamray
2017-11-03 15:54 ` [patch v11 3/4] Documentation: jtag: Add bindings for " Oleksandr Shamray
2017-11-03 15:54 ` [patch v11 4/4] Documentation: jtag: Add ABI documentation Oleksandr Shamray
2017-11-07 10:36 ` Tobias Klauser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8760aoz78q.fsf@bilbrey.org \
--to=chip@bilbrey$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox