linux-kernel - Re: [PATCH 1/4] of: Add device tree bindings for Evatronix

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]

Date:	Fri, 10 Jun 2016 19:14:38 +0200
From:	Ricard Wanderlof <ricard.wanderlof@...s.com>
To:	Boris Brezillon <boris.brezillon@...e-electrons.com>
CC:	Brian Norris <computersforpeace@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Benoit Cousson <bcousson@...libre.com>,
	Tony Lindgren <tony@...mide.com>, <devicetree@...r.kernel.org>,
	Linux mtd <linux-mtd@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] of: Add device tree bindings for Evatronix


On Fri, 10 Jun 2016, Boris Brezillon wrote:

> > Basically, in the general case, the controller can handle a matrix of 
> > nand flash chips. There can be a number of banks, each of which can 
> > have a number of individual CS lines. For the (in this case academic) 
> > case of 3 banks and 4 chip selects per bank, there would be a total of 
> > 3 x 4 = 12 CS lines.
> > 
> > For the IP configuration the driver was written for, there are only 2 
> > CS lines, and we can configure if they are to be viewed by the 
> > controller as 2 CS lines within the same single bank, or 2 separate 
> > banks with one CS each. This is what the DT property is intended to 
> > express. It basically translates directly into a register write in the 
> > IP.
> 
> Okay, got it. I guess we should just expose the chip select in a linear
> way (3 banks of 4 CS means the controller should support up to 12
> chips), unless you really have a way to change the CS pins routing
> internally.

When I go through the driver I will also revisit this and give it some 
more thought if there's a set of bindings which would make sense both for 
the case we have now and for a general configuration of the IP.

> > Yes, that makes sense of course, but what if someone would want to 
> > override the automatic settings, for whatever reason, using an 
> > optional DT property? I can think of several reasons either way, 
> > that's why I'm asking.
>
> You mean reducing the timings because the board design prevents using
> the highest supported mode for example? That would actually be a valid
> use case, and I guess we could make a generic property for that
> (without the vendor prefix).

Yes, either that, or if the automatic selection fails for some reason, say 
in a given case we know that the chips we are using support mode 2 timing, 
but one of them gets misidentified as mode 0. Sure, that is a bug and 
should be fixed of course, but I can imagine commercial situations where 
it may not be feasable to update the kernel, but where a new DT would be 
ok.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30