linux-kernel - Re: [PATCH v13 2/3] fpga: microchip-spi: add Microchip MPF FPGA manager

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: <20220530120701.sedwn3qeohlnj52e@x260>
Date:   Mon, 30 May 2022 15:07:01 +0300
From:   Ivan Bornyakov <i.bornyakov@...rotek.ru>
To:     Conor.Dooley@...rochip.com
Cc:     mdf@...nel.org, hao.wu@...el.com, yilun.xu@...el.com,
        trix@...hat.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, linux-fpga@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        system@...rotek.ru
Subject: Re: [PATCH v13 2/3] fpga: microchip-spi: add Microchip MPF FPGA
 manager

On Mon, May 30, 2022 at 11:22:26AM +0000, Conor.Dooley@...rochip.com wrote:
> On 26/05/2022 19:13, Ivan Bornyakov wrote:
> > +static int mpf_read_status(struct spi_device *spi)
> > +{
> > +       u8 status = 0, status_command = MPF_SPI_READ_STATUS;
> > +       /*
> > +        * Two identical SPI transfers are used for status reading.
> > +        * The reason is that the first one can be inadequate.
> > +        * We ignore it completely and use the second one.
> > +        */
> > +       struct spi_transfer xfers[] = {
> > +               [0 ... 1] = {
> > +                       .tx_buf = &status_command,
> > +                       .rx_buf = &status,
> > +                       .len = 1,
> > +                       .cs_change = 1,
> > +               }
> > +       };
> 
> Hmm, I don't think that this is correct, or at least it is not
> correct from the polarfire /soc/ perspective. I was told that
> there was nothing different other than the envm between the
> programming for both devices - but this is another situation
> where I start to question that.
> 
> When I run this code, ISC enable /never/ passes - failing due
> to timing out. I see something like this picture here:
> https://i.imgur.com/EKhd1S3.png
> You can see the 0x0B ISC enable coming through & then a status
> check after it.
> 
> With the current code, the value of the "status" variable will
> be 0x0, given you are overwriting the first MISO value with the
> second. According to the hw guys, the spi hw status *should*
> only be returned on MISO in the first byte after SS goes low.
> 
> If this is not the case for a non -soc part, which, as I said
> before, I don't have a board with the SPI programmer exposed
> for & I have been told is not the case then my comments can
> just be ignored entirely & I'll have some head scratching to
> do...
> 
> Thanks,
> Conor.
> 

If I understood correctly, SS doesn't alter between two status reading
transactions despite .cs_change = 1. May be adding some .cs_change_delay
to spi_transfer struct can help with that?

> > +       int ret = spi_sync_transfer(spi, xfers, 2);
> > +
> > +       if ((status & MPF_STATUS_SPI_VIOLATION) ||
> > +           (status & MPF_STATUS_SPI_ERROR))
> > +               ret = -EIO;
> > +
> > +       return ret ? : status;
> > +}