[PATCH v4 01/16] dt-bindings: mtd: gpmc-onenand: Update properties description

[Ladislav Michl]

On Wed, Nov 15, 2017 at 02:43:39PM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Sat, Nov 11, 2017 at 10:16:56PM +0100, Ladislav Michl wrote:
> > Compatible property is required for OMAP2+ mtd driver. Also
> > add R/B pin gpio description and delete unused dma-channel
> > property.
> > 
> > Signed-off-by: Ladislav Michl <ladis at linux-mips.org>
> > ---
> >  Changes:
> >  -v4: new patch
> > 
> >  Documentation/devicetree/bindings/mtd/gpmc-onenand.txt | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> > index b6e8bfd024f4..9d7b1409deab 100644
> > --- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> > @@ -9,13 +9,14 @@ Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> >  
> >  Required properties:
> >  
> > + - compatible:		"ti,omap2-onenand"
> 
> I suggest to also add more specific compatible values (i.e.
> "ti,omap3-onenand") in case it is needed later. They don't
> hurt much and may prevent ugly hacks in the future.

We tried hard to avoid anything omap3 specific (it was present in earlier
versions of this patchset). And NAND driver is also okay with "ti,omap3-nand"
(I know it is a poor argument). So far all OMAP2/3 differences seems to come
from both devices unavailable to the person who did the code change.

While I agree it is in general good idea, I have personal problem with that
as there are devices in field with "ti,omap2-onenand" compatible and OMAP3530.

See this function:
http://git.denx.de/?p=u-boot.git;a=blob;f=board/isee/igep00x0/igep00x0.c;h=5c7f2567118a1e17bdb6f76f29a7161628776bf7;hb=HEAD#l158
Board comes either with NAND or OneNAND, bootloader detects that and
enables proper node. Updating bootloader is potentially dangerous, so I'd
like to avoid that.

However, if you insist on idea above, I'm okay with keeping some of tree
patches for a while...

> >   - reg:			The CS line the peripheral is connected to
> > - - gpmc,device-width	Width of the ONENAND device connected to the GPMC
> > + - gpmc,device-width:	Width of the ONENAND device connected to the GPMC
> >  			in bytes. Must be 1 or 2.
> >  
> >  Optional properties:
> >  
> > - - dma-channel:		DMA Channel index
> > + - rb-gpios:		GPIO specifier for the ready/busy# pin.
> >  
> >  For inline partition table parsing (optional):
> >  
> > @@ -35,6 +36,7 @@ Example for an OMAP3430 board:
> >  		#size-cells = <1>;
> >  
> >  		onenand at 0 {
> > +			compatible = "ti,omap2-onenand";
> >  			reg = <0 0 0>; /* CS0, offset 0 */
> >  			gpmc,device-width = <2>;
> >  
> 
> -- Sebastian