linux-kernel - Re: [PATCH resend 1/2] spi: add driver for ar934x spi controller

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJsYDVKnOv+4NT8V+9fFy_0KE7QSoeTL0jHTdq31Z=88vBzHgQ@mail.gmail.com>
Date:   Thu, 6 Feb 2020 20:30:21 +0800
From:   Chuanhong Guo <gch981213@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-spi@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH resend 1/2] spi: add driver for ar934x spi controller

On Thu, Feb 6, 2020 at 7:31 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Thu, Feb 06, 2020 at 04:44:42PM +0800, Chuanhong Guo wrote:
>
> This looks good, just a couple of comments below:
>
> > --- /dev/null
> > +++ b/drivers/spi/spi-ar934x.c
> > @@ -0,0 +1,230 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * SPI controller driver for Qualcomm Atheros AR934x/QCA95xx SoCs
>
> Please make the entire comment block a C++ one so things look
> more intentional.

Got it. I'll do this in v2.

>
> > +static int ar934x_spi_transfer_one(struct spi_controller *master,
> > +                                struct spi_message *m)
> > +{
> > +     struct ar934x_spi *sp = spi_controller_get_devdata(master);
> > +     struct spi_transfer *t = NULL;
>
> ...
>
> > +
> > +     m->actual_length = 0;
> > +     list_for_each_entry(t, &m->transfers, transfer_list) {
>
> It looks like this could just be a transfer_one() operation
> instead of transfer_one_message() (which is what this is in spite
> of the name)?  There's nothing custom outside this loop that I
> can see.

Chipselect is also handled during transfer. Controller asserts
corresponding chipselect in SHIFT_CTRL register, and if SHIFT_TERM bit
is set, controller will deassert chipselect after current transfer is
done. I need to know whether this is the last transfer and set
SHIFT_TERM accordingly.

Regards,
Chuanhong Guo