[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180207192815.vdamhm66jheysz2b@ninjato>
Date: Wed, 7 Feb 2018 20:28:15 +0100
From: Wolfram Sang <wsa@...-dreams.de>
To: Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: linux-mmc@...r.kernel.org,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Ulf Magnusson <ulfalizer@...il.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Simon Horman <horms+renesas@...ge.net.au>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH v3 07/16] mmc: renesas_sdhi: use
MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
On Thu, Jan 18, 2018 at 01:28:07AM +0900, Masahiro Yamada wrote:
> TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
>
> The flag is propagated as follows:
> renesas_sdhi_of_data::capabilities2
> -> tmio_mmc_data::capabilities2
> -> mmc_host::caps2
>
> Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
> (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
> returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
> logic and GPIO detection).
>
> The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the
> possibility, if any, would be DT specifies "wp-gpios" property, and
> gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse().
> However, it does not make sense to specify "wp-gpios" property and
> TMIO_MMC_WRPROTECT_DISABLE at the same time.
>
> I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/,
> and I did not see any Renesas boards with "wp-gpios". So, this
> conversion should be safe.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
Reviewed-by: Wolfram Sang <wsa+renesas@...g-engineering.com>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists