linux-kernel - Re: [PATCH 4/4] mtd: nand: omap2: Add support for NAND Controller on AM64 SoC

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:   Sun, 28 Nov 2021 22:36:33 -0600
From:   Nishanth Menon <nm@...com>
To:     Roger Quadros <rogerq@...nel.org>
CC:     Miquel Raynal <miquel.raynal@...tlin.com>, <richard@....at>,
        <vigneshr@...com>, <kishon@...com>, <tony@...mide.com>,
        <linux-mtd@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH 4/4] mtd: nand: omap2: Add support for NAND Controller on
 AM64 SoC

On 13:10-20211126, Roger Quadros wrote:
[...]

> >>>> +	/* Some SoC's have 32-bit at least, read limitation */
> >>>> +	if (soc_device_match(k3_soc_devices)) {
> >>>> +		dev_info(&pdev->dev, "force 32-bit\n");
> >>>> +		info->force_32bit = true;
> >>>> +	}
> >>>> +  
> >>>
> >>> As suggested above, just adding a capability structure tied to the
> >>> compatible string and retrieved with of_device_get_match_data() should
> >>> be enough and replace this manual tree research.  
> >>
> >> The trouble comes when TI updates the silicon revision to "SR2.0" and that has the issue fixed
> >> but still uses the same compatible. So compatible string by itself is not sufficient to identify
> >> the troubled devices. soc_device_match() was the easiest way to address this.
> > 
> > This is precisely what compatibles are for, I believe we should declare
> > the necessary additional compatibles and fix the device trees that are
> > wrong.
> 
> AFAIK TI SoCs don't have different compatibles for different revisions of the same SoC.
> My understanding is that the SoC is the same so compatible shouldn't change. Just that there were some
> hardware fixes and some quirks may not be needed anymore.
> 
> Nishanth,
> 
> Could you please chime in on why SoC revisions can't use different compatibles?
> 

The permutations of boards (with add-on cards) and SRs become
un-manageable esp when Silicon Revisions(SRs) dont actually get into
production. Instead, what we do suggest are one of two things:
a) The dts in k.org always reflect the latest SR for the chip that is
   going into production. Older SR revisions are supported as overlays on top
   of the dtb.
b) Where possible, use the chip-id framework[1] to dynamically detect
   the variations. This might be easier with newer K3 generation SoCs.


In this instance, an overlay corresponding to older SoC might be
feasible.



[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D