Boris, On 27/10/15 10:12, Boris Brezillon wrote: > Hi Roger, > > On Tue, 27 Oct 2015 10:03:02 +0200 > Roger Quadros <rogerq@xxxxxx> wrote: > >> On 26/10/15 22:49, Brian Norris wrote: >>> >>> Others have been looking at using GPIOs for the ready/busy pin too. At a >>> minimum, we need an updated DT binding doc for this, since I see you're >>> adding this via device tree in a later patch (I don't see any DT binding >>> patch for this; but I could just be overlooking it). It'd also be great >>> if this support was moved to nand_dt_init() so other platforms can >>> benefit, but I won't require that. >>> >>> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio' >>> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't >>> really care, but the name should be going into a doc, so we can choose >>> the same one everywhere. >>> >>> EDIT: looks like the discussion was partly here [1] and it seems we're >>> landing on "rb-gpios" in the latest version [2]. Can we stick with that? >> >> Why should it be "rb-gpios" and not "rb-gpio"? >> I don't think there are multiple gpios for r/b# function. > > Because it's supposed to be a generic binding, and some NAND chips > embed several dies, thus exposing several CS and RB pins, hence the > rb-gpios name. > Also, as described here [1], the convention is to name your property > <name>-gpios even if you only need one gpio. Makes sense now. Thanks for the explanation. I'll update this patch to use rb-gpios and update the binding doc as well. -- cheers, -roger -- 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
