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>] [day] [month] [year] [list]
Message-ID: <314e596f4f7b7e7f8742c47dfeeb7d93@mail.infomaniak.com>
Date:   Mon, 20 Nov 2023 17:45:29 +0100
From:   linux@...ler.io
To:     Stefan Moring <stefan.moring@...hnolution.nl>
Cc:     Francesco Dolcini <francesco@...cini.it>,
        Linux regressions mailing list <regressions@...ts.linux.dev>,
        Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org,
        linux-spi@...r.kernel.org
Subject: Re: spi: imx: Increase imx51 ecspi burst length fails on imx6dl and
 imx8mm

Hi Stefan

I added my printing 
@@ -655,12 +658,25 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 
        /* Clear BL field and set the right value */
        ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
+       dev_info(spi_imx->dev, "%s: count=%d, bits_per_word=%d\n",
+            __FUNCTION__, spi_imx->count, spi_imx->bits_per_word);
+
        if (spi_imx->target_mode && is_imx53_ecspi(spi_imx))
                ctrl |= (spi_imx->target_burst * 8 - 1)
                        << MX51_ECSPI_CTRL_BL_OFFSET;

and run the test with the burst enabled 
/var/volatile/tmp# spidev_test --device /dev/spidev1.0 --speed 20000000 --bpw 8 -i 127bytes-spi-test-data.bin -o 127bytes-spi-test-result.bin
[  802.729824] spi_imx 30830000.spi: mx51_ecspi_prepare_transfer: count=127, bits_per_word=8
-> transmitted 504 Bytes on the line

then I run it with burst disabled
spidev_test --device /dev/spidev1.0 --speed 20000000 --bpw 8 -i 127bytes-spi-test-data.bin -o 127bytes-spi-test-result.bin
[  316.683807] spi_imx 30830000.spi: mx51_ecspi_prepare_transfer: count=0, bits_per_word=8
-> transmitted 127 Bytes on the line

The count is different 
- for burst-enabled  127
- for burst-disable 0

concerning the sdma-firmware I checked on 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma
but the latest I found was 4.5

Regards
Stefan


Am 2023-11-20T16:30:15.000+01:00 hat Stefan Moring <stefan.moring@...hnolution.nl> geschrieben:
>  Hi Stefan,
> 
> I have been trying to reproduce your error on my iMX8M, scoping the SPI
> lines, but everything works as expected. I don't have the exact same board,
> but I don't think that should be a problem. One difference I noticed is
> that my imx-sdma firmware is version 4.6.
> 
> Can you verify the values used for the transfer,  spi_imx->count and
> spi_imx->bits_per_word inside the mx51_ecpsi_prepare_transfer() method?
> Those are the only two things that changed in the commits. Maybe compare
> them to the working version?
> 
> Kind regards,
> 
> Stefan Moring
> 
> Op ma 20 nov 2023 om 11:18 schreef Francesco Dolcini <francesco@...cini.it>:
> 
> 
> >    On Mon, Nov 20, 2023 at 10:33:38AM +0100, linux@...ler.io wrote:
> > 
> > >     I run the test and it worked fine. The transmitted data matches with
> > >   the recived data, no diff.
> >   ok, thanks for confirming. At least we are on the same page.
> > 
> > 
> > >     BUT!!! on the MDIO it is completly different !!!
> > >   When I request to send 4kB Data I measure on the line 16384Byte.
> > >  
> > >   The data is again   3Dummy Bytes followed by the databyte.
> > >   So the error symetic on send and recive
> >  
> >  ok, that's annoying. I wonder if the loopback test could be improved to
> >  spot such kind of issues, maybe we could verify if the execution time
> >  is reasonable given the SPI clock frequency and the payload size ...
> > 
> >  Francesco
> > 
> 
> 
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ