Message ID | 1406298233-27876-3-git-send-email-pawel.moll@arm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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?
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
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
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
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.
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
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);
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(-)