Hi, On Wed, Nov 15, 2017 at 04:12:06PM +0100, Ladislav Michl wrote: > 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@xxxxxxxxxxxxxx> > > > --- > > > 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... The best practice for DT bindings is to have a specific compatible and a generic fallback. Something like compatible = "ti,omap3-onenand", "ti,omap2-onenand"; You can just ignore the "ti,omap3-onenand" in the driver for now. Just add it to the bindings and the DTS files. Then it is there in case it is needed at some point. -- Sebastian > > > - 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@0 { > > > + compatible = "ti,omap2-onenand"; > > > reg = <0 0 0>; /* CS0, offset 0 */ > > > gpmc,device-width = <2>; > > > > > > > -- Sebastian > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
