| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 13 Dec 2020 10:54:26 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Sowjanya Komatineni <skomatineni@...dia.com>
Cc: <thierry.reding@...il.com>, <jonathanh@...dia.com>,
<broonie@...nel.org>, <robh+dt@...nel.org>, <lukas@...ner.de>,
<bbrezillon@...nel.org>, <p.yadav@...com>,
<tudor.ambarus@...rochip.com>, <linux-spi@...r.kernel.org>,
<linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 5/9] spi: spi-mem: Allow masters to transfer dummy
cycles directly by hardware
On Sat, 12 Dec 2020 09:28:50 -0800
Sowjanya Komatineni <skomatineni@...dia.com> wrote:
> On 12/12/20 2:57 AM, Boris Brezillon wrote:
> > On Fri, 11 Dec 2020 13:15:59 -0800
> > Sowjanya Komatineni <skomatineni@...dia.com> wrote:
> >
> >> This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers
> >> that support transfer of dummy cycles by the hardware directly.
> > Hm, not sure this is a good idea. I mean, if we expect regular SPI
> > devices to use this feature, then why not, but if it's just for
> > spi-mem, I'd recommend implementing a driver-specific exec_op() instead
> > of using the default one.
>
> dummy cycles programming is SPI device specific.
>
> Transfer of dummy bytes by SW or HW controller can be depending on
> features supported by controller.
>
> Adding controller driver specific exec_op() Just for skipping dummy
> bytes transfer will have so much of redundant code pretty much what all
> spi_mem_exec_op does.
>
> So in v1, I handled this in controller driver by skipping SW transfer of
> dummy bytes during dummy phase and programming dummy cycles in
> controller register to allow HW to transfer.
>
> Based on v1 feedback discussion, added this flag
> SPI_MASTER_USES_HW_DUMMY_CYCLES which can be used by controllers
> supporting HW dummy bytes transfer and updated spi_mem_exec_op to skip
> SW dummy bytes.
>
> This helps other controllers supporting HW transfer of dummy bytes as
> well just to set the flag and use dummy cycles directly.
Except saying a spi_message has X dummy cycle is not precise enough.
Where are those dummy cycles in the transfer sequence? spi-mem has well
defined sequencing (cmd[+addr][+dummy][+data]) so we know exacly where
dummy cycles are, but trying to retro-fit the dummy-cycle concept in
the generic spi_message is confusing IMHO. If want to avoid code
duplication, I'm pretty sure the driver can be reworked so the
spi_transfer/exec_op() path can share most of the logic (that probably
implies declaring a tegra_qspi_op).
>
> > If we go for those core changes, we should at least add a
> > ctrl->max_dummy_cycles field so the core can fallback to regular writes
> > when the number of dummy cycles in the spi_mem_op exceeds what the
> > controller can do.
> Yes makes sense. Will add this once we decide on keeping this flag to
> identify controllers supporting HW transfer of dummy bytes Vs SW transfer.
> >> For controller with this flag set, spi-mem driver will skip dummy bytes
> >> transfer in the spi message.
> >>
> >> Controller drivers can get the number of dummy cycles from spi_message.
> >>
> >> Signed-off-by: Sowjanya Komatineni <skomatineni@...dia.com>
> >> ---
> >> drivers/spi/spi-mem.c | 18 +++++++++++-------
> >> include/linux/spi/spi.h | 8 ++++++++
> >> 2 files changed, 19 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> >> index f3a3f19..38a523b 100644
> >> --- a/drivers/spi/spi-mem.c
> >> +++ b/drivers/spi/spi-mem.c
> >> @@ -350,13 +350,17 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
> >> }
> >>
> >> if (op->dummy.nbytes) {
> >> - memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes);
> >> - xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1;
> >> - xfers[xferpos].len = op->dummy.nbytes;
> >> - xfers[xferpos].tx_nbits = op->dummy.buswidth;
> >> - spi_message_add_tail(&xfers[xferpos], &msg);
> >> - xferpos++;
> >> - totalxferlen += op->dummy.nbytes;
> >> + if (ctlr->flags & SPI_MASTER_USES_HW_DUMMY_CYCLES) {
> >> + msg.dummy_cycles = (op->dummy.nbytes * 8) / op->dummy.buswidth;
> >> + } else {
> >> + memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes);
> >> + xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1;
> >> + xfers[xferpos].len = op->dummy.nbytes;
> >> + xfers[xferpos].tx_nbits = op->dummy.buswidth;
> >> + spi_message_add_tail(&xfers[xferpos], &msg);
> >> + xferpos++;
> >> + totalxferlen += op->dummy.nbytes;
> >> + }
> >> }
> >>
> >> if (op->data.nbytes) {
> >> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> >> index aa09fdc..2024149 100644
> >> --- a/include/linux/spi/spi.h
> >> +++ b/include/linux/spi/spi.h
> >> @@ -512,6 +512,8 @@ struct spi_controller {
> >>
> >> #define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must select slave */
> >>
> >> +#define SPI_MASTER_USES_HW_DUMMY_CYCLES BIT(6) /* HW dummy bytes transfer */
> >> +
> >> /* flag indicating this is an SPI slave controller */
> >> bool slave;
> >>
> >> @@ -1022,6 +1024,12 @@ struct spi_message {
> >> unsigned actual_length;
> >> int status;
> >>
> >> + /*
> >> + * dummy cycles in the message transfer. This is used by the controller
> >> + * drivers supports transfer of dummy cycles directly by the hardware.
> >> + */
> >> + u8 dummy_cycles;
> >> +
> >> /* for optional use by whatever driver currently owns the
> >> * spi_message ... between calls to spi_async and then later
> >> * complete(), that's the spi_controller controller driver.
Powered by blists - more mailing lists