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: Thu, 25 Jan 2024 10:20:58 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: William Zhang <william.zhang@...adcom.com>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>, David Regan
 <dregan@...adcom.com>, dregan@...l.com, richard@....at, vigneshr@...com,
 robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 computersforpeace@...il.com, kdasu.kdev@...il.com,
 linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, joel.peshkin@...adcom.com,
 tomer.yacoby@...adcom.com, dan.beygelman@...adcom.com,
 anand.gore@...adcom.com, kursad.oney@...adcom.com, rafal@...ecki.pl,
 bcm-kernel-feedback-list@...adcom.com, andre.przywara@....com,
 baruch@...s.co.il, linux-arm-kernel@...ts.infradead.org,
 dan.carpenter@...aro.org
Subject: Re: [PATCH v3 02/10] ARM: dts: broadcom: bcmbca: Add NAND
 controller node

Hi William,

> >>>> +        nand_controller: nand-controller@...0 {
> >>>> +            #address-cells = <1>;
> >>>> +            #size-cells = <0>;
> >>>> +            compatible = "brcm,nand-bcm63138", >>>> "brcm,brcmnand-v7.1", "brcm,brcmnand";
> >>>> +            reg = <0x1800 0x600>, <0x2000 0x10>;
> >>>> +            reg-names = "nand", "nand-int-base";
> >>>> +            brcm,nand-use-wp = <0>;
> >>>> +            status = "disabled";
> >>>> +
> >>>> +            nandcs: nand@0 {
> >>>> +                compatible = "brcm,nandcs";
> >>>> +                reg = <0>;
> >>>> +                nand-on-flash-bbt;
> >>>> +                brcm,nand-ecc-use-strap;  
> >>>
> >>> Describing the NAND chip in a SoC DTSI does not look relevant to me.
> >>> Even more if you add something like this nand-ecc-use-strap setting
> >>> which is very board dependent.
> >>>  
> >> I am not sure if I understand you comments correctly but are you >> suggesting to put this whole nand controller node into each board dts? >> We have other ip block nodes like SPI, uart in this same soc dtsi file >> too.  For all the bcmbca soc dtsi I am updating here(and its board >> design), we always use the strap to for ecc setting.  So I thought it >> should be okay to put brcm,nand-ecc-use-strap in the default dtsi >> file. For any board that uses the raw nand nand-ecc property, the >> board dts can do so and override the brcm,nand-ecc-use-strap setting.  
> > 
> > I read Miquel's comment as meaning that the nandcs aka the NAND > chip/flash part description should be in the board .dts file, while the > controller itself can remain in the .dtsi file with its status = > "disabled" property.
> > 
> > Are there customer boards, that is non reference boards that might chose > a different chip select number and/or not use the strap settings?  
> In BCMBCA SoC, there is only one cs and customer design also have to use strap for the bootrom to boot up properly.  They can override it with dts in linux but I don't think any customer would do that.
> 
> Maybe the nand-on-flash-bbt could be possible item that customer may have to set it differently if they don't follow our reference software design.
> 
> I will move the nand-on-flash-bbt to the board dts but I would like to keep the other default nandcs settings in SoC.dsti if that is not too out of the conventional rule and Miquel is okay with it.

I think there is a global misunderstanding regarding the use of the
nand-ecc-* properties. These are not the default. The default is the OS
choice and depends on the NAND capabilities. The OS will always try to
match the closest ECC settings offered by the engine, based on the NAND
chip requirements which are discoverable. If you want to maximize your
strength, it is also possible to tell the OS with a dedicated (generic)
property. And only if you want something different, you may use these
properties, but they should be the exception rather than the rule.

Overriding this with a strap is a bad hardware design on commercial
products IMO. I am totally fine with the idea of a strap to choose
the ECC configuration for development boards/evaluation kits, but once
you've decided which setting you want you cannot change it for the
lifetime of your project (or with a lot of difficulties) so I don't see
the point of such a strap. So really, I don't like the idea of defining
by default a variable which asks for an override of the defaults, even
though many of your customers might want to use that.

So, anything that is design dependent (the chip CS, ECC
configuration, etc) should go into the board DTS, and what is SoC
related hardware (like the definition of the NAND controller) should
stay in the DTSI, as properly clarified by Florian.

Thanks,
Miquèl

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ