From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Oleksandr Shamray <oleksandrs@mellanox.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"linux-arm Mailing List" <linux-arm-kernel@lists.infradead.org>,
devicetree <devicetree@vger.kernel.org>,
openbmc@lists.ozlabs.org, "Joel Stanley" <joel@jms.id.au>,
"Jiří Pírko" <jiri@resnulli.us>,
"Tobias Klauser" <tklauser@distanz.ch>,
"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
"Vadim Pasternak" <vadimp@mellanox.com>,
system-sw-low-level@mellanox.com,
"Rob Herring" <robh+dt@kernel.org>,
openocd-devel-owner@lists.sourceforge.net,
linux-api@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Jiri Pirko" <jiri@mellanox.com>
Subject: Re: [patch v21 1/4] drivers: jtag: Add JTAG core driver
Date: Wed, 16 May 2018 00:21:35 +0300 [thread overview]
Message-ID: <CAHp75VctG5RBtLF3nT5e_j7_e9O12u=5gerJ6OMxWbABM9ft2w@mail.gmail.com> (raw)
In-Reply-To: <1526394095-5069-2-git-send-email-oleksandrs@mellanox.com>
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Initial patch for JTAG driver
> JTAG class driver provide infrastructure to support hardware/software
> JTAG platform drivers. It provide user layer API interface for flashing
> and debugging external devices which equipped with JTAG interface
> using standard transactions.
>
> Driver exposes set of IOCTL to user space for:
> - XFER:
> - SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
> - SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
> - RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
> number of clocks).
> - SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency.
>
> Driver core provides set of internal APIs for allocation and
> registration:
> - jtag_register;
> - jtag_unregister;
> - jtag_alloc;
> - jtag_free;
>
> Platform driver on registration with jtag-core creates the next
> entry in dev folder:
> /dev/jtagX
> 0xB0 all RATIO devices in development:
> <mailto:vgo@ratio.de>
> 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
> +0xB2 00-0f linux/jtag.h JTAG driver
> + <mailto:oleksandrs@mellanox.com>
Consider to preserve style (upper vs. lower).
> + This provides basic core functionality support for JTAG class devices.
> + Hardware that is equipped with a JTAG microcontroller can be
> + supported by using this driver's interfaces.
> + This driver exposes a set of IOCTLs to the user space for
> + the following commands:
> + SDR: (Scan Data Register) Performs an IEEE 1149.1 Data Register scan
> + SIR: (Scan Instruction Register) Performs an IEEE 1149.1 Instruction
> + Register scan.
> + RUNTEST: Forces the IEEE 1149.1 bus to a run state for a specified
> + number of clocks or a specified time period.
Something feels wrong with formatting here.
> +#define MAX_JTAG_NAME_LEN (sizeof("jtag") + 5)
Interesting definition. Why not to set to 10 explicitly? And why 10?
(16 sounds better)
> +struct jtag {
> + struct miscdevice miscdev;
> + struct device *dev;
Doesn't miscdev parent contain exactly this one?
> + const struct jtag_ops *ops;
> + int id;
> + bool opened;
> + struct mutex open_lock;
> + unsigned long priv[0];
> +};
> + err = copy_to_user(u64_to_user_ptr(xfer.tdio),
> + (void *)(xfer_data), data_size);
Redundant parens in one case. Check the rest similar places.
> +static int jtag_open(struct inode *inode, struct file *file)
> +{
> + struct jtag *jtag = container_of(file->private_data, struct jtag,
> + miscdev);
I would don't care about length and put it on one line.
> + if (jtag->opened) {
> + jtag->opened = true;
> + jtag->opened = false;
Can it be opened non exclusively several times? If so, this needs to
be a ref counter instead.
> + if (!ops->idle || !ops->mode_set || !ops->status_get || !ops->xfer)
> + return NULL;
Are all of them mandatory?
> +int jtag_register(struct jtag *jtag)
Perhaps devm_ variant.
> +#define jtag_u64_to_ptr(arg) ((void *)(uintptr_t)arg)
Where is this used or supposed to be used?
> +#define JTAG_MAX_XFER_DATA_LEN 65535
Is this limitation from some spec?
Otherwise why not to allow 64K?
> +/**
> + * struct jtag_ops - callbacks for jtag control functions:
> + *
> + * @freq_get: get frequency function. Filled by device driver
> + * @freq_set: set frequency function. Filled by device driver
> + * @status_get: set status function. Filled by device driver
> + * @idle: set JTAG to idle state function. Filled by device driver
> + * @xfer: send JTAG xfer function. Filled by device driver
> + */
Perhaps you need to describe which of them are _really_ mandatory and
which are optional.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2018-05-15 21:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 14:21 [patch v21 0/4] JTAG driver introduction Oleksandr Shamray
2018-05-15 14:21 ` [patch v21 1/4] drivers: jtag: Add JTAG core driver Oleksandr Shamray
2018-05-15 21:21 ` Andy Shevchenko [this message]
2018-05-22 15:00 ` Oleksandr Shamray
2018-05-15 14:21 ` [patch v21 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver Oleksandr Shamray
2018-05-15 21:00 ` Andy Shevchenko
2018-05-22 15:00 ` Oleksandr Shamray
2018-05-22 20:21 ` Andy Shevchenko
2018-05-15 14:21 ` [patch v21 3/4] Documentation: jtag: Add bindings for " Oleksandr Shamray
2018-05-15 14:21 ` [patch v21 4/4] Documentation: jtag: Add ABI documentation Oleksandr Shamray
2018-05-16 18:16 ` Randy Dunlap
2018-05-22 13:08 [patch v21 1/4] drivers: jtag: Add JTAG core driver Oleksandr Shamray
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='CAHp75VctG5RBtLF3nT5e_j7_e9O12u=5gerJ6OMxWbABM9ft2w@mail.gmail.com' \
--to=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jiri@mellanox.com \
--cc=jiri@resnulli.us \
--cc=joel@jms.id.au \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=oleksandrs@mellanox.com \
--cc=openbmc@lists.ozlabs.org \
--cc=openocd-devel-owner@lists.sourceforge.net \
--cc=robh+dt@kernel.org \
--cc=system-sw-low-level@mellanox.com \
--cc=tklauser@distanz.ch \
--cc=vadimp@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).