* [RFC PATCH] mmc: tmio: use ioread* for repeated access to a register
From: Wolfram Sang @ 2017-12-18 0:00 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Masahiro Yamada, Simon Horman, Wolfram Sang
Not all archs define reads* and writes*. Switch to ioread*_rep and
friends which is defined everywhere, so we can enable COMPILE_TEST after
that.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
So, I pushed this to buildbot on top of Yamada-san's patch series and there
were no complaints, even with COMPILE_TEST enabled. I also did some tests on
HW and checksuming huge files on SD cards still works.
However, I am not sure about this mixture of read* and ioread* functions. Shall
we convert maybe all of those?
drivers/mmc/host/tmio_mmc.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 76094345cbacf3..03519c4ca0aa1a 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -233,7 +233,7 @@ static inline u16 sd_ctrl_read16(struct tmio_mmc_host *host, int addr)
static inline void sd_ctrl_read16_rep(struct tmio_mmc_host *host, int addr,
u16 *buf, int count)
{
- readsw(host->ctl + (addr << host->bus_shift), buf, count);
+ ioread16_rep(host->ctl + (addr << host->bus_shift), buf, count);
}
static inline u32 sd_ctrl_read16_and_16_as_32(struct tmio_mmc_host *host,
@@ -246,7 +246,7 @@ static inline u32 sd_ctrl_read16_and_16_as_32(struct tmio_mmc_host *host,
static inline void sd_ctrl_read32_rep(struct tmio_mmc_host *host, int addr,
u32 *buf, int count)
{
- readsl(host->ctl + (addr << host->bus_shift), buf, count);
+ ioread32_rep(host->ctl + (addr << host->bus_shift), buf, count);
}
static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr,
@@ -263,7 +263,7 @@ static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr,
static inline void sd_ctrl_write16_rep(struct tmio_mmc_host *host, int addr,
u16 *buf, int count)
{
- writesw(host->ctl + (addr << host->bus_shift), buf, count);
+ iowrite16_rep(host->ctl + (addr << host->bus_shift), buf, count);
}
static inline void sd_ctrl_write32_as_16_and_16(struct tmio_mmc_host *host,
@@ -276,7 +276,7 @@ static inline void sd_ctrl_write32_as_16_and_16(struct tmio_mmc_host *host,
static inline void sd_ctrl_write32_rep(struct tmio_mmc_host *host, int addr,
const u32 *buf, int count)
{
- writesl(host->ctl + (addr << host->bus_shift), buf, count);
+ iowrite32_rep(host->ctl + (addr << host->bus_shift), buf, count);
}
#endif
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2] mmc: block: fix logical error to avoid memory leak
From: Linus Walleij @ 2017-12-16 19:07 UTC (permalink / raw)
To: Liu, Changcheng; +Cc: Adrian Hunter, Ulf Hansson, linux-mmc, Andrew Morton
In-Reply-To: <20171216151545.GA138678@sofia>
On Sat, Dec 16, 2017 at 4:15 PM, Liu, Changcheng
<changcheng.liu@intel.com> wrote:
> If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then
> ext_csd must be freed, but in one case it was not. Fix that.
>
> Signed-off-by: Liu Changcheng <changcheng.liu@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 10/12] dt-bindings: sdhci-omap: Add K2G specific binding
From: Rob Herring @ 2017-12-16 16:49 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Ulf Hansson, Tony Lindgren, Adrian Hunter, Mark Rutland,
Russell King, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nsekhar-l0cyMroinI0
In-Reply-To: <20171214130941.26666-11-kishon-l0cyMroinI0@public.gmane.org>
On Thu, Dec 14, 2017 at 06:39:39PM +0530, Kishon Vijay Abraham I wrote:
> Add binding for the TI's sdhci-omap controller present in K2G.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/sdhci-omap.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mmc: block: fix logical error to avoid memory leak
From: Liu, Changcheng @ 2017-12-16 15:15 UTC (permalink / raw)
To: Adrian Hunter, ulf.hansson, linus.walleij; +Cc: linux-mmc, akpm, changcheng.liu
In-Reply-To: <f9294d5a-bd24-8b95-3666-fa75d681bec1@intel.com>
If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then
ext_csd must be freed, but in one case it was not. Fix that.
Signed-off-by: Liu Changcheng <changcheng.liu@intel.com>
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index ccfa98a..b737a95 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2623,6 +2623,7 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp)
if (n != EXT_CSD_STR_LEN) {
err = -EINVAL;
+ kfree(ext_csd);
goto out_free;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3] mmc: sdhci: wait 5ms after set 1.8V signal enable
From: Zhoujie Wu @ 2017-12-15 19:28 UTC (permalink / raw)
To: ulf.hansson, adrian.hunter, linux-mmc
Cc: nadavh, xigu, xswang, dingwei, kostap, hannah, hongd, dougj, ygao,
liuw, gregory.clement, thomas.petazzoni, Zhoujie Wu
According to SD spec 3.00 3.6.1 signal voltage switch
procedure step 6~8,
(6) Set 1.8V Signal Enable in the Host Control 2 register.
(7) Wait 5ms. 1.8V voltage regulator shall be stable within this period.
(8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12).
Host should wait 5ms after set 1.8V signal enable bit in
Host Control 2 register and check if 1.8V is stable or not.
But current code checks if this bit is cleared by controller
right after set it. On some platforms found the bit is not
cleared right away and host reports "1.8V regulator output
did not became stable" and 5ms delay can help.
Follow the spec and add 5ms delay to make sure the 1.8V Signal Enable
bit is cleared.
Signed-off-by: Zhoujie Wu <zjwu@marvell.com>
---
drivers/mmc/host/sdhci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e9290a3..fe5f208 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1933,6 +1933,9 @@ int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
if (host->ops->voltage_switch)
host->ops->voltage_switch(host);
+ /* Wait for 5ms */
+ usleep_range(5000, 5500);
+
/* 1.8V regulator output should be stable within 5 ms */
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
if (ctrl & SDHCI_CTRL_VDD_180)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups
From: Wolfram Sang @ 2017-12-15 19:08 UTC (permalink / raw)
To: Ulf Hansson
Cc: Masahiro Yamada, linux-mmc@vger.kernel.org, Wolfram Sang,
Simon Horman, Yoshihiro Shimoda, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <CAPDyKFpUE1s8+OXuyyRszFnpt5CN4G8d2vhwRhs-PkaL_VU7oQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 199 bytes --]
> > Other thoughts?
>
> Nope.
I have :) Another solution seems to be to switch to ioread16_rep and
friends. Those are defined on sparc64. Compiles locally here, now sent
it to buildbot.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [EXT] Re: [PATCH v2] mmc: sdhci: wait 5ms after set 1.8V signal enable
From: Zhoujie Wu @ 2017-12-15 18:53 UTC (permalink / raw)
To: Ulf Hansson
Cc: Adrian Hunter, linux-mmc@vger.kernel.org, Nadav Haklai, Victor Gu,
xswang, Wilson Ding, Kostya Porotchkin, Hanna Hawa, hongd,
Doug Jones, Ryan Gao, Wei(SOCP) Liu, Gregory Clement,
Thomas Petazzoni
In-Reply-To: <CAPDyKFqhsdC43RL1KWK6TtXRcbSkDAk-3iiwoCUB+jewkNuPtA@mail.gmail.com>
On 12/14/2017 11:05 PM, Ulf Hansson wrote:
> On 14 December 2017 at 20:04, Zhoujie Wu <zjwu@marvell.com> wrote:
>> Hi Ulf,
>>
>> On 12/14/2017 12:41 AM, Ulf Hansson wrote:
>>> External Email
>>>
>>> ----------------------------------------------------------------------
>>> On 14 December 2017 at 00:48, Zhoujie Wu <zjwu@marvell.com> wrote:
>>>> According to SD spec 3.00 3.6.1 signal voltage switch
>>>> procedure, host should wait 5ms after set 1.8V signal
>>>> enable bit in Host Control 2 register and check if 1.8V
>>>> is stable or not.
>>>>
>>> The core already deals with this. See mmc_set_uhs_voltage() and
>>> mmc_host_set_uhs_voltage().
>>>
>>> We even have a retry mechanism in place.
>> I checked these functions, they just make sure when do signal voltage
>> switch, gate the clock to SD card 5ms and wait 1ms before check data lines.
>> This patch is following below spec requirement when switching signal voltage
>> to 1.8V, wait 5ms after set 1.8V signal Enable bit in Host control 2
>> register.
> Right, so this is an SDHCI controller requirement. Could you perhaps
> clarify that in the changlog, then I am happy.
Sure, I will give more details in comment to avoid confusing:)
>> Current code will set 1.8V Signal Enable bit and check if this bit is
>> cleared by host right after that, the bit is not cleared and host report
>> "1.8V regulator output did not became stable".
>>
>> You can find the steps at SD spec 3.0 3.6.1.
>> (6) Set 1.8V Signal Enable in the Host Control 2 register.
>> (7) Wait 5ms. 1.8V voltage regulator shall be stable within this period.
>> (8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12).
>>>
>>>> On some cards, found without the delay would see "1.8V
>>>> regulator output did not became stable" err log.
>>> Seems like you need to fix the regulator instead.
>>>
>>> BTW, is this a regression? No?
>> It is not regulator related, the regulator already output 1.8V and add delay
>> after regulator set voltage didn't help.
>> The only solution is to add 5ms after set 1.8V signal enable bit .
>> Not a regression issue, we recently found it when enabling uhs on some
>> platforms since they didn't enable it previously.
> I see, thanks for clarifying.
>
> Kind regards
> Uffe
^ permalink raw reply
* Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups
From: Wolfram Sang @ 2017-12-15 16:30 UTC (permalink / raw)
To: Ulf Hansson
Cc: Masahiro Yamada, linux-mmc@vger.kernel.org, Wolfram Sang,
Simon Horman, Yoshihiro Shimoda, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <CAPDyKFopKm2psU19vGQfGL6WizXQA0vvzQubqsypvytbpRtyAA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
> > Ulf, this patch then in deed should ideally be applied before 1-8 here.
>
> Okay, once you post it to linux-mmc I will pick it up, and put it in front.
Bad news, that patch didn't help. The problem is that sparc64 doesn't
include 'asm-generic/io.h' and also has no own 'readsw'. No surprise
that just adding this include will cause lots of redefines which are way
too much to handle as a side-task.
So, the best option I see here is to drop COMPILE_TEST for now, report
this to the sparc64 maintainers (I assume they know already), and see if
they can fix it.
Other thoughts?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups
From: Ulf Hansson @ 2017-12-15 16:34 UTC (permalink / raw)
To: Wolfram Sang
Cc: Masahiro Yamada, linux-mmc@vger.kernel.org, Wolfram Sang,
Simon Horman, Yoshihiro Shimoda, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <20171215163055.vxxiswgsvfybf4hi@katana>
On 15 December 2017 at 17:30, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > Ulf, this patch then in deed should ideally be applied before 1-8 here.
>>
>> Okay, once you post it to linux-mmc I will pick it up, and put it in front.
>
> Bad news, that patch didn't help. The problem is that sparc64 doesn't
> include 'asm-generic/io.h' and also has no own 'readsw'. No surprise
> that just adding this include will cause lots of redefines which are way
> too much to handle as a side-task.
>
> So, the best option I see here is to drop COMPILE_TEST for now, report
> this to the sparc64 maintainers (I assume they know already), and see if
> they can fix it.
Okay!
If some of you send a patch on top, I can fold it into the offending commit.
>
> Other thoughts?
Nope.
Kind regards
Uffe
^ permalink raw reply
* [GIT PULL] MMC fixes for v.4.15-rc4
From: Ulf Hansson @ 2017-12-15 16:32 UTC (permalink / raw)
To: Linus, linux-mmc, linux-kernel; +Cc: Jaehoon Chung, Adrian Hunter, Ulf Hansson
Hi Linus,
Here's a PR with a couple of MMC fixes intended for v4.15-rc4. Details about the
highlights are as usual found in the signed tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:
Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.15-rc2
for you to fetch changes up to 91516a2a4734614d62ee3ed921f8f88acc67c000:
mmc: core: apply NO_CMD23 quirk to some specific cards (2017-12-11 13:43:27 +0100)
----------------------------------------------------------------
MMC core:
- Fix use of uninitialized drv_typ variable
- Apply NO_CMD23 quirk to some specific SD cards to make them work
----------------------------------------------------------------
Christoph Fritz (1):
mmc: core: apply NO_CMD23 quirk to some specific cards
Wolfram Sang (1):
mmc: core: properly init drv_type
drivers/mmc/core/card.h | 2 ++
drivers/mmc/core/mmc.c | 2 +-
drivers/mmc/core/quirks.h | 8 ++++++++
3 files changed, 11 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 04/14] ARM: dts: dra76x: Create a common file with MMC/SD IOdelay data
From: Tony Lindgren @ 2017-12-15 16:32 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: bcousson, Santosh Shilimkar, Rob Herring, Mark Rutland,
Russell King, linux-mmc, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, nsekhar
In-Reply-To: <be4d8cfd-bdd3-aedf-9d9c-156de39d2621@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [171215 06:12]:
> Hi Tony,
>
> On Thursday 14 December 2017 08:45 PM, Tony Lindgren wrote:
> > * Kishon Vijay Abraham I <kishon@ti.com> [171214 13:44]:
> >> +&dra7_pmx_core {
> >> + mmc1_pins_default: mmc1_pins_default {
> >> + pinctrl-single,pins = <
> >> + DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
> >> + DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
> >> + DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
> >> + DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
> >> + DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
> >> + DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
> >> + >;
> >> + };
> >> +
> >> + mmc1_pins_sdr12: mmc1_pins_sdr12 {
> >> + pinctrl-single,pins = <
> >> + DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
> >> + DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
> >> + DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
> >> + DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
> >> + DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
> >> + DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
> >> + >;
> >> + };
> >
> > Can't you just do:
> >
> > pinctrl-0 = <&mmc1_pins_default>;
> > pinctrl-1 = <&mmc1_pins_default>;
> > pinctrl-2 = <&mmc1_pins_hs>;
> > pinctrl-names = "default", "sdr12", "sdr25";
>
> just wanted to make sure every mode has it's own pinctrl group so that it's
> easy to review. Initially we were thinking something like
> mmc1_pins_default_sdr12_sdr25.
OK that naming works fine for me.
> But if you'd prefer we just use mmc1_pins_default for all modes that uses
> default pinmux configuration, I can change it that way too.
No up to you with the naming thanks.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] mm/block: logical error fix to avoid memory leak
From: Adrian Hunter @ 2017-12-15 14:34 UTC (permalink / raw)
To: Liu, Changcheng, Ulf Hansson, Linus Walleij; +Cc: linux-mmc, akpm
In-Reply-To: <20171214050305.GA135779@sofia>
On 14/12/17 07:03, Liu, Changcheng wrote:
> function: mmc_ext_csd_open
> {
> +-- 33 lines: struct mmc_card *card = inode->i_private;--
> if (n != EXT_CSD_STR_LEN) {
> err = -EINVAL;
> goto out_free; //==>should free ext_csd firstly.
> }
> +-- 2 lines: filp->private_data = buf;------------------
> kfree(ext_csd);
> return 0;
>
> out_free:
> kfree(buf);
> return err;
> }
>
> Signed-off-by: Liu Changcheng <changcheng.liu@intel.com>
Well I don't really follow the commit message, but the patch is OK.
How about this:
mmc: block: fix logical error to avoid memory leak
If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then
ext_csd must be freed, but in one case it was not. Fix that.
Otherwise:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index ccfa98a..b737a95 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -2623,6 +2623,7 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp)
>
> if (n != EXT_CSD_STR_LEN) {
> err = -EINVAL;
> + kfree(ext_csd);
> goto out_free;
> }
>
>
^ permalink raw reply
* Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups
From: Ulf Hansson @ 2017-12-15 13:34 UTC (permalink / raw)
To: Wolfram Sang
Cc: Masahiro Yamada, linux-mmc@vger.kernel.org, Wolfram Sang,
Simon Horman, Yoshihiro Shimoda, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <20171215111225.ekrau5e27xknb3jf@ninjato>
On 15 December 2017 at 12:12, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> After 2, COMPILE_TEST will work correctly.
>>
>> Then, Wolfram mentioned we would need to include <linux/io.h> from tmio_mmc.h
>>
>> https://patchwork.kernel.org/patch/10074333/
>>
>>
>> I was waiting for a patch from him.
>
> Yes, I am sorry. I am currently swamped with I2C work, not so much time
> for SDHI. However, I did this patch now and pushed the branch out to see
> if buildbot is happy.
Great!
>
> Ulf, this patch then in deed should ideally be applied before 1-8 here.
Okay, once you post it to linux-mmc I will pick it up, and put it in front.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups
From: Wolfram Sang @ 2017-12-15 11:12 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ulf Hansson, linux-mmc@vger.kernel.org, Wolfram Sang,
Simon Horman, Yoshihiro Shimoda, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <CAK7LNASQfsnQY6henk5RvAysQUh3=cPXV1GPNeWeXgBxZvadAw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
> After 2, COMPILE_TEST will work correctly.
>
> Then, Wolfram mentioned we would need to include <linux/io.h> from tmio_mmc.h
>
> https://patchwork.kernel.org/patch/10074333/
>
>
> I was waiting for a patch from him.
Yes, I am sorry. I am currently swamped with I2C work, not so much time
for SDHI. However, I did this patch now and pushed the branch out to see
if buildbot is happy.
Ulf, this patch then in deed should ideally be applied before 1-8 here.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups
From: Masahiro Yamada @ 2017-12-15 10:08 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc@vger.kernel.org, Wolfram Sang, Simon Horman,
Yoshihiro Shimoda, Linux-Renesas, linux-kernel@vger.kernel.org
In-Reply-To: <CAPDyKFqE7Pg8fJFyOtihdRnma+dFQd3+YPWGn6pXbpzhpERK9Q@mail.gmail.com>
2017-12-15 18:18 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
> On 24 November 2017 at 17:24, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>>
>> I am working on this IP for Socionext SoCs.
>>
>> I was hit by several issues, and noticed various
>> clean-up candidates.
>>
>> - Fix and clean-up Kconfig
>> - Fix various card detection problems
>> - Move Renesas private data out of TMIO core
>> - Allow to perform platform-specific settings before MMC host starts
>> - Fix weird IRQ handling
>>
>> I am getting more and more patches for TMIO.
>> I put all in a single series to clarify the patch order.
>>
>> 1, 2, 4, 5, 6, 7 were already acked or reviewed by Wolfram Sang.
>>
>>
>> Masahiro Yamada (22):
>> mmc: renesas_sdhi: consolidate DMAC CONFIG options
>> mmc: renesas_sdhi: remove wrong depends on to enable compile test
>> mmc: renesas_sdhi: remove eprobe jump label
>> mmc: tmio: set tmio_mmc_host to driver data
>> mmc: tmio: use devm_ioremap_resource() instead of devm_ioremap()
>> mmc: tmio: move mmc_host_ops to struct tmio_mmc_host from static data
>> mmc: tmio, renesas_sdhi: set mmc_host_ops hooks directly
>> mmc: tmio: move mmc_gpio_request_cd() before mmc_add_host()
>> mmc: tmio: use mmc_can_gpio_cd() instead of checking
>> TMIO_MMC_USE_GPIO_CD
>> mmc: tmio: support IP-builtin card detection logic
>> mmc: renesas_sdhi: remove always false condition
>> mmc: tmio,renesas_sdhi: move struct tmio_mmc_dma to renesas_sdhi.h
>> mmc: tmio,renesas_sdhi: move Renesas-specific DMA data to
>> renesas_sdhi.h
>> mmc: tmio,renesas_sdhi: move ssc_tappos to renesas_sdhi.h
>> mmc: tmio: change bus_shift to unsigned int
>> mmc: tmio: fix never-detected card insertion bug
>> mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place
>> mmc: tmio: remove useless TMIO_MASK_CMD handling in
>> tmio_mmc_host_probe()
>> mmc: tmio: ioremap memory resource in tmio_mmc_host_alloc()
>> mmc: tmio: move clk_enable/disable out of tmio_mmc_host_probe()
>> mmc: tmio: move {tmio_}mmc_of_parse() to tmio_mmc_host_alloc()
>> mmc: tmio: remove dma_ops from tmio_mmc_host_probe() argument
>>
>> drivers/mmc/host/Kconfig | 5 +-
>> drivers/mmc/host/Makefile | 8 +-
>> drivers/mmc/host/renesas_sdhi.h | 22 ++++
>> drivers/mmc/host/renesas_sdhi_core.c | 49 ++++-----
>> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 14 ++-
>> drivers/mmc/host/renesas_sdhi_sys_dmac.c | 35 +++---
>> drivers/mmc/host/tmio_mmc.c | 23 ++--
>> drivers/mmc/host/tmio_mmc.h | 23 +---
>> drivers/mmc/host/tmio_mmc_core.c | 149 +++++++++++++-------------
>> 9 files changed, 170 insertions(+), 158 deletions(-)
>>
>> --
>> 2.7.4
>>
>
> To get this moving, I have applied patch 1->8 for next, thanks!
>
> Kind regards
> Uffe
After 2, COMPILE_TEST will work correctly.
Then, Wolfram mentioned we would need to include <linux/io.h> from tmio_mmc.h
https://patchwork.kernel.org/patch/10074333/
I was waiting for a patch from him.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] mmc: core: Send SLEEP_NOTIFICATION for eMMC 5.x device
From: Ulf Hansson @ 2017-12-15 9:24 UTC (permalink / raw)
To: Gwendal Grignou
Cc: linux-mmc@vger.kernel.org, Avi Shchislowski, Chris Ball,
Alex Lemberg, Thierry Escande
In-Reply-To: <CAPDyKFrSmX_MbErW71tjwQui6LExQUfHjWL6UVNuJekvgrCc7Q@mail.gmail.com>
On 29 November 2017 at 15:14, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> [...]
>
>>> static int mmc_poweroff_notify(struct mmc_card *card, unsigned int notify_type)
>>> {
>>> - unsigned int timeout = card->ext_csd.generic_cmd6_time;
>>> + unsigned int timeout;
>>> + bool use_busy_signal = true;
>>> int err;
>>>
>>> - /* Use EXT_CSD_POWER_OFF_SHORT as default notification type. */
>>> - if (notify_type == EXT_CSD_POWER_OFF_LONG)
>>> + switch (notify_type) {
>>> + case EXT_CSD_POWER_OFF_LONG:
>>> timeout = card->ext_csd.power_off_longtime;
>>> + break;
>>> + case EXT_CSD_SLEEP_NOTIFICATION:
>>> + timeout = card->ext_csd.sleep_notification_time;
>>> + use_busy_signal = false;
>>
>> This is wrong.
>>
>> If you set use_busy_signal to false, it means that we don't care about
>> waiting for the card to stop signaling busy on DAT0 after setting
>> EXT_CSD_SLEEP_NOTIFICATION. This then becomes a violation of the eMMC
>> spec, because we must not issue a CMD5 before the card have stopped
>> signaling busy.
>>
>> I realize that for those devices that don't support
>> MMC_CAP_WAIT_WHILE_BUSY or have the ->card_busy() callback
>> implemented, the consequence may be that mmc_poll_for_busy() may call
>> mmc_delay() with a very big timeout. This could be a big problem, I
>> guess.
>
> Well, it may also be a big problem even if the host supports
> ->card_busy() and/or MMC_CAP_WAIT_WHILE_BUSY (but maybe not as big),
> simply because we can't be waiting here for several seconds to allow
> the card to deal with background operations.
>
> I guess we need to try and see what happens. Perhaps you can share
> some data about the timeouts you get?
>
>>
>>> + break;
>>> + default:
>>> + /* Use EXT_CSD_POWER_OFF_SHORT as default notification type. */
>>> + timeout = card->ext_csd.generic_cmd6_time;
>>> + }
>>>
>>> err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>>> EXT_CSD_POWER_OFF_NOTIFICATION,
>>> - notify_type, timeout, 0, true, false, false);
>>> + notify_type, timeout, 0, use_busy_signal, false, false);
>>> if (err)
>>> pr_err("%s: Power Off Notification timed out, %u\n",
>>> mmc_hostname(card->host), timeout);
>
> [...]
>
> Kind regards
> Uffe
Gwendal, any news on this?
As changes for the SLEEP_NOTIFICATION keeps being posted, clearly
there is a need for us to deal with it in some way. I have been
thinking of a fall-back solution, if we can't get it it work, but
anyway I am eager to find a solution so we finally can sort this out.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] mmc: renesas_sdhi: Add MODULE_LICENSE
From: Ulf Hansson @ 2017-12-15 9:18 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Wolfram Sang, linux-mmc@vger.kernel.org, Linux-Renesas, # 4.0+,
Masaharu Hayakawa
In-Reply-To: <1513132380-7421-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On 13 December 2017 at 03:33, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> From: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
>
> The following error occurs when loading renesas_sdhi_core.c module,
> so add MODULE_LICENSE("GPL v2").
>
> renesas_sdhi_core: module license 'unspecified' taints kernel.
>
> Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
> Fixes: 9d08428afb72 ("mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main module file")
> Cc: <stable@vger.kernel.org> # v4.13+
> [Shimoda: Added Fixes tag and Cc to the stable ML]
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Thanks, applied for fixes!
Kind regards
Uffe
> ---
> drivers/mmc/host/renesas_sdhi_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
> index fcf7235..157e1d9 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -24,6 +24,7 @@
> #include <linux/kernel.h>
> #include <linux/clk.h>
> #include <linux/slab.h>
> +#include <linux/module.h>
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/mmc/host.h>
> @@ -667,3 +668,5 @@ int renesas_sdhi_remove(struct platform_device *pdev)
> return 0;
> }
> EXPORT_SYMBOL_GPL(renesas_sdhi_remove);
> +
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] mmc: avoid removing non-removable hosts during suspend
From: Ulf Hansson @ 2017-12-15 9:18 UTC (permalink / raw)
To: Daniel Drake; +Cc: linux-mmc@vger.kernel.org, linux, matthew.leeds
In-Reply-To: <20171212104902.11793-1-drake@endlessm.com>
On 12 December 2017 at 11:49, Daniel Drake <drake@endlessm.com> wrote:
> The Weibu F3C MiniPC has an onboard AP6255 module, presenting
> two SDIO functions on a single MMC host (Bluetooth/btsdio and
> WiFi/brcmfmac), and the mmc layer correctly detects this as
> non-removable.
>
> After suspend/resume, the wifi and bluetooth interfaces disappear
> and do not get probed again.
>
> The conditions here are:
>
> 1. During suspend, we reach mmc_pm_notify()
>
> 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
> suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
> -ENOSYS because btsdio_driver does not have a suspend method.
>
> 3. mmc_pm_notify() proceeds to remove the card
>
> 4. Upon resume, mmc_rescan() does nothing with this host, because of
> the rescan_entered check which aims to only scan a non-removable
> device a single time (i.e. during boot).
>
> Fix the loss of functionality by detecting that we are unable to
> suspend a non-removable host, so avoid the forced removal in that
> case. The comment above this function already indicates that this
> code was only intended for removable devices.
>
> Signed-off-by: Daniel Drake <drake@endlessm.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/core/core.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> Replaces previous approach:
> [PATCH] mmc: allow rescan of non-removable hosts on resume
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 26431267a3e2..6f815a264285 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2763,6 +2763,14 @@ static int mmc_pm_notify(struct notifier_block *notify_block,
> if (!err)
> break;
>
> + if (!mmc_card_is_removable(host)) {
> + dev_warn(mmc_dev(host),
> + "pre_suspend failed for non-removable host: "
> + "%d\n", err);
> + /* Avoid removing non-removable hosts */
> + break;
> + }
> +
> /* Calling bus_ops->remove() with a claimed host can deadlock */
> host->bus_ops->remove(host);
> mmc_claim_host(host);
> --
> 2.14.1
>
^ permalink raw reply
* Re: [PATCH 12/45] drivers: mmc: remove duplicate includes
From: Ulf Hansson @ 2017-12-15 9:18 UTC (permalink / raw)
To: Pravin Shedge
Cc: linux-mmc@vger.kernel.org, Heiner Kallweit,
linux-kernel@vger.kernel.org
In-Reply-To: <1512579423-5405-1-git-send-email-pravin.shedge4linux@gmail.com>
On 6 December 2017 at 17:57, Pravin Shedge
<pravin.shedge4linux@gmail.com> wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
Thanks, applied for next with an updated prefix of the commit msg header!
Kind regards
Uffe
> ---
> drivers/mmc/host/android-goldfish.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mmc/host/android-goldfish.c b/drivers/mmc/host/android-goldfish.c
> index 63fe509..63d2758 100644
> --- a/drivers/mmc/host/android-goldfish.c
> +++ b/drivers/mmc/host/android-goldfish.c
> @@ -42,13 +42,11 @@
> #include <linux/spinlock.h>
> #include <linux/timer.h>
> #include <linux/clk.h>
> -#include <linux/scatterlist.h>
>
> #include <asm/io.h>
> #include <asm/irq.h>
>
> #include <asm/types.h>
> -#include <asm/io.h>
> #include <linux/uaccess.h>
>
> #define DRIVER_NAME "goldfish_mmc"
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups
From: Ulf Hansson @ 2017-12-15 9:18 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc@vger.kernel.org, Wolfram Sang, Simon Horman,
Yoshihiro Shimoda, Linux-Renesas, linux-kernel@vger.kernel.org
In-Reply-To: <1511540697-27387-1-git-send-email-yamada.masahiro@socionext.com>
On 24 November 2017 at 17:24, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> I am working on this IP for Socionext SoCs.
>
> I was hit by several issues, and noticed various
> clean-up candidates.
>
> - Fix and clean-up Kconfig
> - Fix various card detection problems
> - Move Renesas private data out of TMIO core
> - Allow to perform platform-specific settings before MMC host starts
> - Fix weird IRQ handling
>
> I am getting more and more patches for TMIO.
> I put all in a single series to clarify the patch order.
>
> 1, 2, 4, 5, 6, 7 were already acked or reviewed by Wolfram Sang.
>
>
> Masahiro Yamada (22):
> mmc: renesas_sdhi: consolidate DMAC CONFIG options
> mmc: renesas_sdhi: remove wrong depends on to enable compile test
> mmc: renesas_sdhi: remove eprobe jump label
> mmc: tmio: set tmio_mmc_host to driver data
> mmc: tmio: use devm_ioremap_resource() instead of devm_ioremap()
> mmc: tmio: move mmc_host_ops to struct tmio_mmc_host from static data
> mmc: tmio, renesas_sdhi: set mmc_host_ops hooks directly
> mmc: tmio: move mmc_gpio_request_cd() before mmc_add_host()
> mmc: tmio: use mmc_can_gpio_cd() instead of checking
> TMIO_MMC_USE_GPIO_CD
> mmc: tmio: support IP-builtin card detection logic
> mmc: renesas_sdhi: remove always false condition
> mmc: tmio,renesas_sdhi: move struct tmio_mmc_dma to renesas_sdhi.h
> mmc: tmio,renesas_sdhi: move Renesas-specific DMA data to
> renesas_sdhi.h
> mmc: tmio,renesas_sdhi: move ssc_tappos to renesas_sdhi.h
> mmc: tmio: change bus_shift to unsigned int
> mmc: tmio: fix never-detected card insertion bug
> mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place
> mmc: tmio: remove useless TMIO_MASK_CMD handling in
> tmio_mmc_host_probe()
> mmc: tmio: ioremap memory resource in tmio_mmc_host_alloc()
> mmc: tmio: move clk_enable/disable out of tmio_mmc_host_probe()
> mmc: tmio: move {tmio_}mmc_of_parse() to tmio_mmc_host_alloc()
> mmc: tmio: remove dma_ops from tmio_mmc_host_probe() argument
>
> drivers/mmc/host/Kconfig | 5 +-
> drivers/mmc/host/Makefile | 8 +-
> drivers/mmc/host/renesas_sdhi.h | 22 ++++
> drivers/mmc/host/renesas_sdhi_core.c | 49 ++++-----
> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 14 ++-
> drivers/mmc/host/renesas_sdhi_sys_dmac.c | 35 +++---
> drivers/mmc/host/tmio_mmc.c | 23 ++--
> drivers/mmc/host/tmio_mmc.h | 23 +---
> drivers/mmc/host/tmio_mmc_core.c | 149 +++++++++++++-------------
> 9 files changed, 170 insertions(+), 158 deletions(-)
>
> --
> 2.7.4
>
To get this moving, I have applied patch 1->8 for next, thanks!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 6/6 v3] mmc: sunxi-mmc: Handle return value of platform_get_irq
From: Ulf Hansson @ 2017-12-15 9:18 UTC (permalink / raw)
To: Arvind Yadav
Cc: Ben Dooks, Adrian Hunter, Viresh Kumar, Maxime Ripard,
Chen-Yu Tsai, Russell King, Carlo Caione, Kevin Hilman,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
open list:ARM/Amlogic Meson...
In-Reply-To: <6ad5c6077b96353a77ea30d1b64651c77d5622f6.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> platform_get_irq() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/sunxi-mmc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index cc98355d..c926ac8 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1255,6 +1255,11 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
> goto error_assert_reset;
>
> host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + ret = -EINVAL;
> + goto error_assert_reset;
> + }
> +
> return devm_request_threaded_irq(&pdev->dev, host->irq, sunxi_mmc_irq,
> sunxi_mmc_handle_manual_stop, 0, "sunxi-mmc", host);
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 4/6 v3] mmc: sdhci-spear: Handle return value of platform_get_irq
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: Arvind Yadav
Cc: Ben Dooks, Adrian Hunter, Viresh Kumar, Maxime Ripard,
Chen-Yu Tsai, Russell King, Carlo Caione, Kevin Hilman,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
open list:ARM/Amlogic Meson...
In-Reply-To: <23382b551ade00543aadc588aa74b0648958b907.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> platform_get_irq() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/sdhci-spear.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
> index 8c0f884..e04485e 100644
> --- a/drivers/mmc/host/sdhci-spear.c
> +++ b/drivers/mmc/host/sdhci-spear.c
> @@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
> host->hw_name = "sdhci";
> host->ops = &sdhci_pltfm_ops;
> host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + ret = -EINVAL;
> + goto err_host;
> + }
> host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
>
> sdhci = sdhci_priv(host);
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 3/6 v3] mmc: sdhci-acpi: Handle return value of platform_get_irq
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: Arvind Yadav
Cc: Ben Dooks, Adrian Hunter, Viresh Kumar, Maxime Ripard,
Chen-Yu Tsai, Russell King, Carlo Caione, Kevin Hilman,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
open list:ARM/Amlogic Meson...
In-Reply-To: <ecd11732b6a29aee23a1be94616755e575b0d438.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> platform_get_irq() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/sdhci-acpi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
> index b988997..0d9965b 100644
> --- a/drivers/mmc/host/sdhci-acpi.c
> +++ b/drivers/mmc/host/sdhci-acpi.c
> @@ -566,6 +566,10 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
> host->hw_name = "ACPI";
> host->ops = &sdhci_acpi_ops_dflt;
> host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + err = -EINVAL;
> + goto err_free;
> + }
>
> host->ioaddr = devm_ioremap_nocache(dev, iomem->start,
> resource_size(iomem));
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 2/6 v3] mmc: s3cmci: Fix platform_get_irq's error checking
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: Arvind Yadav
Cc: Ben Dooks, Adrian Hunter, Viresh Kumar, Maxime Ripard,
Chen-Yu Tsai, Russell King, Carlo Caione, Kevin Hilman,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
open list:ARM/Amlogic Meson...
In-Reply-To: <870b1a28108a8c0f3885bd345f3d27dda67621d5.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/s3cmci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index f7f157a..36daee1 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -1658,7 +1658,7 @@ static int s3cmci_probe(struct platform_device *pdev)
> }
>
> host->irq = platform_get_irq(pdev, 0);
> - if (host->irq == 0) {
> + if (host->irq <= 0) {
> dev_err(&pdev->dev, "failed to get interrupt resource.\n");
> ret = -EINVAL;
> goto probe_iounmap;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 1/6 v3] mmc: meson-gx-mmc: Fix platform_get_irq's error checking
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: Arvind Yadav
Cc: Ben Dooks, Adrian Hunter, Viresh Kumar, Maxime Ripard,
Chen-Yu Tsai, Russell King, Carlo Caione, Kevin Hilman,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
open list:ARM/Amlogic Meson...
In-Reply-To: <c1c27676e9f141ace1254b40807bf2dc03f072c6.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of irq.
>
> drivers/mmc/host/meson-gx-mmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index e0862d3..32a6a22 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -1208,7 +1208,7 @@ static int meson_mmc_probe(struct platform_device *pdev)
> }
>
> irq = platform_get_irq(pdev, 0);
> - if (!irq) {
> + if (irq <= 0) {
> dev_err(&pdev->dev, "failed to get interrupt resource.\n");
> ret = -EINVAL;
> goto free_host;
> --
> 2.7.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox