netdev - Re: [PATCH V4 00/19] net: ks8851: Unify KS8851 SPI and MLL drivers

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]

Date:   Wed, 15 Apr 2020 17:12:36 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     Marek Vasut <marex@...x.de>
Cc:     netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
        Petr Stetiar <ynezz@...e.cz>,
        YueHaibing <yuehaibing@...wei.com>
Subject: Re: [PATCH V4 00/19] net: ks8851: Unify KS8851 SPI and MLL drivers

On Wed, Apr 15, 2020 at 04:51:39PM +0200, Marek Vasut wrote:
> On 4/15/20 4:39 PM, Lukas Wunner wrote:
> I reinstated the indirect access, so things did change. Besides, there
> performance for the parallel option is back where it was with the old
> driver, which is important for me.

Okay, I see.

> > We're using CONFIG_PREEMPT_RT_FULL=y.  I'm sorry for not mentioning this
> > earlier, I didn't assume it would make such a big difference but
> > apparently it does.
> 
> Do you also have the RT patch applied ?

Yes, the branch I linked to also contains the RT patches.

> > This is the branch I've tested today:
> > https://github.com/l1k/linux/commits/revpi-4.19-marek-v4
> 
> You seem to have quite a few more patches in that repository than just
> this series, some of them even touching the RPi SPI driver and it's DMA
> implementation.

Those are just the patches I mainlined, but backported to v4.19.
This branch is based on the Raspberry Pi Foundation's downstream
repository, they still ship v4.19.  Their repo has more performant
drivers for USB, SD/MMC etc. which haven't been mainlined yet.
But the SPI portion is the same as in mainline because I always
submit to mainline and let the patches percolate down to their repo.

> > > I used two different drivers -- the iMX SPI and the STM32 SPI -- I would
> > > say that if both show the same behavior, it's unlikely to be the driver.
> > 
> > Hm, so why did it work with the RasPi but not with the others?
> 
> I didn't have a chance to debug this yet.

I was just curious if those drivers don't work as well as the one
for the RasPi. :-)  That would be funny because the RasPi is generally
considered a toy in the embedded space and the platforms you've
mentioned are taken more seriously I think.

Thanks,

Lukas