From: Wolfram Sang <wsa@the-dreams.de>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
linux-mmc@vger.kernel.org,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Simon Horman <horms@verge.net.au>
Subject: Re: [PATCH 2/2] mmc: host: sh_mobile_sdhi: don't populate unneeded functions
Date: Fri, 2 Sep 2016 07:23:01 +0200 [thread overview]
Message-ID: <20160902052258.GA1601@katana> (raw)
In-Reply-To: <CANqRtoTJWN52roRwJHh1cZrb2Jqf5OD-ffjKgiW4Y5jqCeVzhg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]
Magnus,
> To my eye it looks like this patch might be adding a fix for a bug
> introduced by another patch. R-Car Gen2 and later are quite recent
> SoCs but I believe support for other mobile chips and earlier R-Car
> SoCs also also covered by the SDHI driver. Also there are theTMIO
> chips that share some software and are related but a bit different. So
> in my opinion we need to thread lightly to avoid breakage.
I'm very much with you. This is the very much reason I introduced
TMIO_MMC_MIN_RCAR2 in 3d376fb2ea907f ("mmc: tmio/sdhi: introduce flag
for RCar 2+ specific features") in the first place to be able to
"protect" old hardware from new features. It was not done before! This
is also the reason why we have commits like a21553c9e0c236 ("mmc:
tmio/sdhi: distinguish between SCLKDIVEN and ILL_FUNC") documenting a
difference between some old TMIO variant and our current SDHI. I spent
quite some time finding old TMIO information somewhere for that.
> My concern is what happened before this patch was applied. It looks
> like the callbacks were installed for all hardware types which makes
> me wonder because UHS/SDR support is only available for quite recent
> hardware.
I didn't protect these callbacks before because I assumed they are only
called when SDR support is enabled via devicetree or platform data.
Which is not the case for all the old platforms. I sadly missed that
card_busy() is used when polling an SDIO card in case "broken-cd" is
used. That was a detail I overlooked, sorry. Given my work outlined
above I don't think one can deduce that I don't care about regressing
old hardware, though.
> The ->card_busy() callback is not yet in mainline or -next. It was
> introduced in:
> 0157290 mmc: host: sh_mobile_sdhi: move card_busy from tmio to sdhi
Not quite, it was introduced with 452e5eef6d311e ("mmc: tmio: Add UHS-I
mode support"). The commit you mentioned moved it from tmio*.c to
sdhi*.c
> If this patch is fixing a recent commit then perhaps some patches
> should be squashed together to prevent bisection breakage or if a
> patch is already part of mainline then a "Fixes:" tag might be
> suitable.
It can be argued that this tag could be added:
Fixes: 452e5eef6d311e ("mmc: tmio: Add UHS-I mode support")
I don't know how well it applies, though, because the code has been
modified a lot recently. But we can try.
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-09-02 5:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-24 9:34 [PATCH 0/2] mmc: sh_mobile_sdhi: use SDR & card_busy only on Gen2+ Wolfram Sang
2016-08-24 9:34 ` [PATCH 1/2] mmc: host: sh_mobile_sdhi: move card_busy from tmio to sdhi Wolfram Sang
2016-08-24 9:34 ` [PATCH 2/2] mmc: host: sh_mobile_sdhi: don't populate unneeded functions Wolfram Sang
2016-09-02 2:26 ` Magnus Damm
2016-09-02 5:23 ` Wolfram Sang [this message]
2016-09-02 9:48 ` Ulf Hansson
2016-09-05 8:18 ` Wolfram Sang
2016-09-09 9:45 ` Ulf Hansson
2016-08-25 8:20 ` [PATCH 0/2] mmc: sh_mobile_sdhi: use SDR & card_busy only on Gen2+ Geert Uytterhoeven
2016-08-25 10:02 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160902052258.GA1601@katana \
--to=wsa@the-dreams.de \
--cc=geert@linux-m68k.org \
--cc=horms@verge.net.au \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).