diff mbox

[3/5] mmc: sdhci-pltfm: Do not use parent as the host's device

Message ID 1406298233-27876-3-git-send-email-pawel.moll@arm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Pawel Moll July 25, 2014, 2:23 p.m. UTC
The code selecting a device for the sdhci host has been
continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
"mmc: sdhci-pltfm: Add structure for host-specific data" and
a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
device does not pass parent to sdhci_alloc_host") while there
does not seem to be any reason to use platform device's parent
in the first place.

The comment saying "Some PCI-based MFD need the parent here"
seem to refer to Timberdale FPGA driver (the only MFD driver
registering SDHCI cell, drivers/mfd/timberdale.c) but again,
the only situation when parent device matter is runtime PM,
which is not implemented for Timberdale.

Cc: Chris Ball <chris@printf.net>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---

This patch is a part of effort to remove references to platform_bus
and make it static.

Chris, Anton, Ulf - could you please advise if the assumptions
above are correct or if I'm completely wrong? Do you know what
where the real reasons to use parent originally? The PCI comment
seems like a red herring to me...

 drivers/mmc/host/sdhci-pltfm.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

Comments

Pawel Moll Aug. 8, 2014, 4:36 p.m. UTC | #1
On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
> The code selecting a device for the sdhci host has been
> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
> "mmc: sdhci-pltfm: Add structure for host-specific data" and
> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
> device does not pass parent to sdhci_alloc_host") while there
> does not seem to be any reason to use platform device's parent
> in the first place.
> 
> The comment saying "Some PCI-based MFD need the parent here"
> seem to refer to Timberdale FPGA driver (the only MFD driver
> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
> the only situation when parent device matter is runtime PM,
> which is not implemented for Timberdale.
> 
> Cc: Chris Ball <chris@printf.net>
> Cc: Anton Vorontsov <anton@enomsg.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: linux-mmc@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> 
> This patch is a part of effort to remove references to platform_bus
> and make it static.
> 
> Chris, Anton, Ulf - could you please advise if the assumptions
> above are correct or if I'm completely wrong? Do you know what
> where the real reasons to use parent originally? The PCI comment
> seems like a red herring to me...

Can I take the silence as a suggestion that the change looks ok-ish for
you?

Pawe?

--
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
Ulf Hansson Aug. 11, 2014, 9:07 a.m. UTC | #2
On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
> On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
>> The code selecting a device for the sdhci host has been
>> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
>> "mmc: sdhci-pltfm: Add structure for host-specific data" and
>> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
>> device does not pass parent to sdhci_alloc_host") while there
>> does not seem to be any reason to use platform device's parent
>> in the first place.
>>
>> The comment saying "Some PCI-based MFD need the parent here"
>> seem to refer to Timberdale FPGA driver (the only MFD driver
>> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
>> the only situation when parent device matter is runtime PM,
>> which is not implemented for Timberdale.
>>
>> Cc: Chris Ball <chris@printf.net>
>> Cc: Anton Vorontsov <anton@enomsg.org>
>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> Cc: linux-mmc@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>> ---
>>
>> This patch is a part of effort to remove references to platform_bus
>> and make it static.
>>
>> Chris, Anton, Ulf - could you please advise if the assumptions
>> above are correct or if I'm completely wrong? Do you know what
>> where the real reasons to use parent originally? The PCI comment
>> seems like a red herring to me...
>
> Can I take the silence as a suggestion that the change looks ok-ish for
> you?

Sorry for the delay. I suppose this make sense, but I really don't
know for sure.

I guess we need some testing in linux-next, to get some confidence.

Kind regards
Uffe

>
> Pawe?
>
> --
> 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
--
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
Pawel Moll Aug. 11, 2014, 9:15 a.m. UTC | #3
On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
> On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
> > On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
> >> The code selecting a device for the sdhci host has been
> >> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
> >> "mmc: sdhci-pltfm: Add structure for host-specific data" and
> >> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
> >> device does not pass parent to sdhci_alloc_host") while there
> >> does not seem to be any reason to use platform device's parent
> >> in the first place.
> >>
> >> The comment saying "Some PCI-based MFD need the parent here"
> >> seem to refer to Timberdale FPGA driver (the only MFD driver
> >> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
> >> the only situation when parent device matter is runtime PM,
> >> which is not implemented for Timberdale.
> >>
> >> Cc: Chris Ball <chris@printf.net>
> >> Cc: Anton Vorontsov <anton@enomsg.org>
> >> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> >> Cc: linux-mmc@vger.kernel.org
> >> Cc: linuxppc-dev@lists.ozlabs.org
> >> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> >> ---
> >>
> >> This patch is a part of effort to remove references to platform_bus
> >> and make it static.
> >>
> >> Chris, Anton, Ulf - could you please advise if the assumptions
> >> above are correct or if I'm completely wrong? Do you know what
> >> where the real reasons to use parent originally? The PCI comment
> >> seems like a red herring to me...
> >
> > Can I take the silence as a suggestion that the change looks ok-ish for
> > you?
> 
> Sorry for the delay. I suppose this make sense, but I really don't
> know for sure.
> 
> I guess we need some testing in linux-next, to get some confidence.

Would you take it into -next then? Unless I'm completely wrong there
should be no impact on any in-tree driver...

Cheers!

Pawel

--
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
Ulf Hansson Aug. 11, 2014, 9:32 a.m. UTC | #4
On 11 August 2014 11:15, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
>> On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
>> > On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
>> >> The code selecting a device for the sdhci host has been
>> >> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
>> >> "mmc: sdhci-pltfm: Add structure for host-specific data" and
>> >> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
>> >> device does not pass parent to sdhci_alloc_host") while there
>> >> does not seem to be any reason to use platform device's parent
>> >> in the first place.
>> >>
>> >> The comment saying "Some PCI-based MFD need the parent here"
>> >> seem to refer to Timberdale FPGA driver (the only MFD driver
>> >> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
>> >> the only situation when parent device matter is runtime PM,
>> >> which is not implemented for Timberdale.
>> >>
>> >> Cc: Chris Ball <chris@printf.net>
>> >> Cc: Anton Vorontsov <anton@enomsg.org>
>> >> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> >> Cc: linux-mmc@vger.kernel.org
>> >> Cc: linuxppc-dev@lists.ozlabs.org
>> >> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>> >> ---
>> >>
>> >> This patch is a part of effort to remove references to platform_bus
>> >> and make it static.
>> >>
>> >> Chris, Anton, Ulf - could you please advise if the assumptions
>> >> above are correct or if I'm completely wrong? Do you know what
>> >> where the real reasons to use parent originally? The PCI comment
>> >> seems like a red herring to me...
>> >
>> > Can I take the silence as a suggestion that the change looks ok-ish for
>> > you?
>>
>> Sorry for the delay. I suppose this make sense, but I really don't
>> know for sure.
>>
>> I guess we need some testing in linux-next, to get some confidence.
>
> Would you take it into -next then? Unless I'm completely wrong there
> should be no impact on any in-tree driver...

I will take it; though I think it's best to queue it for 3.18 to get
some more testing.

Kind regards
Uffe
--
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
Russell King - ARM Linux Aug. 11, 2014, 10:02 a.m. UTC | #5
On Mon, Aug 11, 2014 at 10:15:50AM +0100, Pawel Moll wrote:
> On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
> > Sorry for the delay. I suppose this make sense, but I really don't
> > know for sure.
> > 
> > I guess we need some testing in linux-next, to get some confidence.
> 
> Would you take it into -next then? Unless I'm completely wrong there
> should be no impact on any in-tree driver...

But not until 3.17-rc1 has been released.  linux-next should not receive
new material other than bug fixes while a merge window is open.
Ulf Hansson Aug. 12, 2014, 8:58 a.m. UTC | #6
On 11 August 2014 11:32, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 11 August 2014 11:15, Pawel Moll <pawel.moll@arm.com> wrote:
>> On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
>>> On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
>>> > On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
>>> >> The code selecting a device for the sdhci host has been
>>> >> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
>>> >> "mmc: sdhci-pltfm: Add structure for host-specific data" and
>>> >> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
>>> >> device does not pass parent to sdhci_alloc_host") while there
>>> >> does not seem to be any reason to use platform device's parent
>>> >> in the first place.
>>> >>
>>> >> The comment saying "Some PCI-based MFD need the parent here"
>>> >> seem to refer to Timberdale FPGA driver (the only MFD driver
>>> >> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
>>> >> the only situation when parent device matter is runtime PM,
>>> >> which is not implemented for Timberdale.
>>> >>
>>> >> Cc: Chris Ball <chris@printf.net>
>>> >> Cc: Anton Vorontsov <anton@enomsg.org>
>>> >> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>> >> Cc: linux-mmc@vger.kernel.org
>>> >> Cc: linuxppc-dev@lists.ozlabs.org
>>> >> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>>> >> ---
>>> >>
>>> >> This patch is a part of effort to remove references to platform_bus
>>> >> and make it static.
>>> >>
>>> >> Chris, Anton, Ulf - could you please advise if the assumptions
>>> >> above are correct or if I'm completely wrong? Do you know what
>>> >> where the real reasons to use parent originally? The PCI comment
>>> >> seems like a red herring to me...
>>> >
>>> > Can I take the silence as a suggestion that the change looks ok-ish for
>>> > you?
>>>
>>> Sorry for the delay. I suppose this make sense, but I really don't
>>> know for sure.
>>>
>>> I guess we need some testing in linux-next, to get some confidence.
>>
>> Would you take it into -next then? Unless I'm completely wrong there
>> should be no impact on any in-tree driver...
>
> I will take it; though I think it's best to queue it for 3.18 to get
> some more testing.

This patch causes a compiler warning, could you please fix it.

Kind regards
Uffe
--
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
diff mbox

Patch

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 7e834fb..4996112 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -136,13 +136,8 @@  struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
 	if (resource_size(iomem) < 0x100)
 		dev_err(&pdev->dev, "Invalid iomem size!\n");
 
-	/* Some PCI-based MFD need the parent here */
-	if (pdev->dev.parent != &platform_bus && !np)
-		host = sdhci_alloc_host(pdev->dev.parent,
-			sizeof(struct sdhci_pltfm_host) + priv_size);
-	else
-		host = sdhci_alloc_host(&pdev->dev,
-			sizeof(struct sdhci_pltfm_host) + priv_size);
+	host = sdhci_alloc_host(&pdev->dev,
+		sizeof(struct sdhci_pltfm_host) + priv_size);
 
 	if (IS_ERR(host)) {
 		ret = PTR_ERR(host);