[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180207192854.fnzanswn52zm6es3@ninjato>
Date: Wed, 7 Feb 2018 20:28:54 +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,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>, linux-kernel@...r.kernel.org,
linux-sh@...r.kernel.org
Subject: Re: [PATCH v3 08/16] sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT
instead of TMIO own flag
On Thu, Jan 18, 2018 at 01:28:08AM +0900, Masahiro Yamada wrote:
> TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
>
> The flag is propagated as follows:
> 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, so gpio_ro
> is obviously unused by legacy boards like this. 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