linux-kernel - Marvell NFC timings on CN9130

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

Date:   Tue, 16 May 2023 04:46:38 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
CC:     "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Marvell NFC timings on CN9130

Hi Miquel, Thomas,

A hardware colleague reported a concern to me about a new design we have 
using the Marvell CN9130 SoC (which I think was called Armada-8K before 
they rebranded).

Basically their concern is that the tWC timing they observe is faster 
(~18ns) than the documented minimum in the hardware datasheet for the 
CN9130 (25ns). Aside from not meeting the datasheet spec we've not 
observed any other issue (yet).

I notice in the marvell_nand.c driver that marvell_nfc_init() sets the 
NAND Clock Frequency Select bit (0xF2440700:0) to 1 which runs according 
to the datasheet the NAND flash at 400MHz . But the calculations in 
marvell_nfc_setup_interface() use the value from 
clk_get_rate(nfc->core_clk) which is still 250MHz so I'm wondering if 
maybe the fact that the NAND flash is being run faster is having an 
impact on timings that are calculated around the core_clk frequency.

Do you think that the timings calculations should take the NAND Clock 
Frequency Select setting into account?

Thanks,
Chris