[PATCH v3 06/13] mmc: tmio-mmc: define device-tree bindings

Arnd Bergmann arnd at arndb.de
Thu Feb 7 19:27:29 EST 2013


On Thursday 07 February 2013, Simon Horman wrote:
> > Please write the binding in a way that does not refer to a specific
> > implementation in Linux: The binding should describe the hardware
> > independent of details in the driver. In particular, I think you
> > should not refer to the TMIO_MMC_BLKSZ_2BYTES etc macros but describe
> > in text what the flags are about.
> > 
> > Regarding the toshiba,mmc-wrprotect-disable property, would it be
> > enough to just check the presence of the wp-gpios property?
> > 
> > TMIO_MMC_BLKSZ_2BYTES seems to be set unconditionally in
> > sh_mobile_sdhi_probe and nowhere else, so I'd assume we don't
> > actually need to provide this here, but can keep that knowledge
> > implicit based on whether we're talking to sh_mobile_sdhi
> > or another tmio_mmc variant.
> > 
> > For the other last one, is that actually board specific, or just
> > a feature of a given chip? If we can tell by the SoC, then I'd
> > suggest using separate "compatible" properties instead, and
> > put a bitmask of features into the .data field of the of match
> > table. For all I can tell, SH7372 does not set it, while SH73A0,
> > R8A7740 and R8A7779 always do.
> 
> My understanding is that TMIO_MMC_HAS_IDLE_WAIT can be set based
> on the SoC in use.

Ok, thanks for the confirmation. Just to be clear: Either way (compatible
or separate property) works fine and can be used here. I tend to prefer
basing these things on the "compatible" string in order to keep
specific knowledge of the device internals out of the device tree
binding though.

	Arnd


More information about the devicetree-discuss mailing list