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: <HK0PR06MB27865D494F91D29B61A5B15BB2ED0@HK0PR06MB2786.apcprd06.prod.outlook.com>
Date:   Fri, 6 Nov 2020 09:01:42 +0000
From:   Chin-Ting Kuo <chin-ting_kuo@...eedtech.com>
To:     Mark Brown <broonie@...nel.org>,
        Boris Brezillon <boris.brezillon@...labora.com>
CC:     Cédric Le Goater <clg@...d.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "joel@....id.au" <joel@....id.au>,
        "andrew@...id.au" <andrew@...id.au>,
        "bbrezillon@...nel.org" <bbrezillon@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        BMC-SW <BMC-SW@...eedtech.com>
Subject: RE: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller driver

Hi Mark,

> -----Original Message-----
> From: Mark Brown <broonie@...nel.org>
> Sent: Friday, November 6, 2020 12:43 AM
> To: Boris Brezillon <boris.brezillon@...labora.com>
> Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller
> driver
> 
> On Thu, Nov 05, 2020 at 04:11:32PM +0100, Boris Brezillon wrote:
> > Cédric Le Goater <clg@...d.org> wrote:
> 
> > > Thanks for this driver. It's much cleaner than the previous and we
> > > should try adding support for the AST2500 SoC also. I guess we can
> > > keep the old driver for the AST2400 which has a different register layout.
> > >
> > > On the patchset, I think we should split this patch in three :
> > >
> > >  - basic support
> > >  - AHB window calculation depending on the flash size
> > >  - read training support
> 
> > I didn't look closely at the implementation, but if the read training
> > tries to read a section of the NOR, I'd recommend exposing that
> > feature through spi-mem and letting the SPI-NOR framework trigger the
> > training instead of doing that at dirmap creation time (remember that
> > spi-mem is also used for SPI NANDs which use the dirmap API too, and
> > this training is unlikely to work there).
> 
> > The SPI-NOR framework could pass a read op template and a reference
> > pattern such that all the spi-mem driver has to do is execute the
> > template op and compare the output to the reference buffer.
> 
> That seems like a good idea.

Yes, this idea will be implemented on the next patch version.

> 
> > > We should avoid magic values when setting registers. This is
> > > confusing and defines are much better.
> 
> It does depend a bit on documentation though, it's not a hard requirement.

I will update it on the next patch version.



Thanks.

Best Wishes,
Chin-Ting

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ