linux-kernel - Re: [PATCH] mtd: aspeed-smc: improve probe resilience

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] [day] [month] [year] [list]

Message-ID: <20220208190636.h6dubktkmuosvdxo@ti.com>
Date:   Wed, 9 Feb 2022 00:36:36 +0530
From:   Pratyush Yadav <p.yadav@...com>
To:     Cédric Le Goater <clg@...d.org>
CC:     Patrick Williams <patrick@...cx.xyz>,
        Vignesh Raghavendra <vigneshr@...com>,
        <linux-aspeed@...ts.ozlabs.org>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Richard Weinberger <richard@....at>,
        Potin Lai <potin.lai@...ntatw.com>,
        <linux-kernel@...r.kernel.org>, Michael Walle <michael@...le.cc>,
        <linux-mtd@...ts.infradead.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] mtd: aspeed-smc: improve probe resilience

On 07/02/22 06:13PM, Cédric Le Goater wrote:
> Hello,
> 
> On 1/24/22 21:37, Pratyush Yadav wrote:
> > On 24/01/22 07:34PM, Cédric Le Goater wrote:
> > > > > spimem needs an extension I think. Sorry I have not been able to
> > > > > push that forward. Lack of time and other tasks to address on the
> > > > > host side of the machine. This is really a software problem, we
> > > > > have the HW procedures ready. If a spimem expert could get involved
> > > > > to make a few proposals, I would be happy to help and do some testing.
> > > > > QEMU models are good enough for the software part. We can do the
> > > > > training validation on real HW when ready.
> > > > 
> > > > What information about the flash do you need for this training?
> > > 
> > > Last time I looked, we lacked some post_init handler to setup a slave:
> > > configure the registers defining the AHB windows for each flash
> > > slave and perform the read timing calibration. calibration should
> > > only be done once.
> > > 
> > > See how the aspeed_spi_flash_init() routine doing the calibration
> > > is hooked up under aspeed_spi_claim_bus() in the u-boot driver :
> > 
> > My patch series should provide a hook for doing the calibration _after_
> > the flash is initialized.
> 
> You can also use the .dirmap_create handler. The flash device has
> been scanned when called and the size is available in the spi-mem
> dirmap descriptor.

I feel uncomfortable doing that since the API does not actually make 
this guarantee. Who knows if a future change will violate that 
assumption. That is why I added a new API call to explicitly mark the 
flash as ready. I suppose you can get the op from the .dirmap_create 
handler, but I guess we can debate that over the patches.

> 
> I reworked the current Aspeed driver with this approach and it
> seems sufficient for read calibration.
> 
> Thanks,
> 
> C.
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.