On Mon, Oct 27, 2014 at 05:05:29PM +0200, Pantelis Antoniou wrote: > Hi Mark, > > > On Oct 27, 2014, at 17:01 , Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > On Mon, Oct 27, 2014 at 01:48:02PM +0200, Pantelis Antoniou wrote: > >>> On Oct 24, 2014, at 02:51 , atull@xxxxxxxxxxxxxxxxxxxxx wrote: > > > >>> + - init-val : 0 if driver should disable bridge at startup > >>> + 1 if driver should enable bridge at startup > >>> + driver leaves bridge in current state if property not > >>> + specified. > > > >> Isn’t init-val a boolean property? It’s not named very well. > > > > It's not boolean, it's tristate - turn on, turn off or don't touch. > > > > I see. Even then ‘init-val’ is cryptic. I’d prefer two booleans, > enable-at-startup; disable-at-startup. > > >> Along with the label, is kinda hard to defend as configuration in DT. > > > > Yeah... presumably this decision would fall out of the users? > > Well, it’s the user that should make the decision, but the driver should > pick it up. This works but it’s not very nice. > Hm, convince me why this AXI bus is so special, that I even need an "init-val" property? Other buses don't have that. Why don't I add a property "init-val" to my SPI buses, so I can enable it in the DT and still have it in reset, just because.... The bridges on the SoCFPGA are buses, from the HPS to the FPGA. If I have written firmware to the FPGA and I have subnodes on that bus, I have to get it out of reset and probe everything. Normal procedure, no ?! Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
