Thread (12 messages) flat view 12 messages, 5 authors, 2013-02-14

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

From: Arnd Bergmann <arnd@arndb.de>
Date: 2013-02-07 08:27:29
Also in: linux-mmc, linux-sh

On Thursday 07 February 2013, Simon Horman wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help