Hi Miquel, On Wed, Mar 17, 2021 at 03:51:21PM +0100, Miquel Raynal wrote: > Hi Manivannan, > > Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx> wrote on Wed, > 17 Mar 2021 17:55:10 +0530: > > > On a typical end product, a vendor may choose to secure some regions in > > the NAND memory which are supposed to stay intact between FW upgrades. > > The access to those regions will be blocked by a secure element like > > Trustzone. So the normal world software like Linux kernel should not > > touch these regions (including reading). > > > > So this series adds a property for declaring such secure regions in DT > > so that the driver can skip touching them. While at it, the Qcom NANDc > > DT binding is also converted to YAML format. > > > > Thanks, > > Mani > > > > Changes in v5: > > > > * Switched to "uint64-matrix" as suggested by Rob > > * Moved the whole logic from qcom driver to nand core as suggested by Boris > > I'm really thinking about a nand-wide property now. Do you think it > makes sense to move the helper to the NAND core (instead of the raw > NAND core)? I'm fine only using it in the raw NAND core though. > The reason why I didn't move the helper and checks to NAND core is I haven't seen any secure implementations in other NAND interfaces except rawnand. This change can be done in future if we start seeing implementations. > Also, can I request a global s/sec/secure/ update? I find the "sec" > abbreviation unclear and I think we have more than enough cryptic > names :-) > Sure. Thanks, Mani > Thanks, > Miquèl
