linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: w.sang@pengutronix.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data
Date: Thu, 30 Sep 2010 12:19:38 +0200	[thread overview]
Message-ID: <20100930101938.GE2655@pengutronix.de> (raw)
In-Reply-To: <4CA45E6D.4070308@pelagicore.com>

On Thu, Sep 30, 2010 at 11:54:53AM +0200, Richard R?jfors wrote:
> On 09/30/2010 10:16 AM, Wolfram Sang wrote:
> >Hi Richard,
> >
> >On Wed, Sep 29, 2010 at 11:24:25PM +0200, Richard R?jfors wrote:
> >>On 09/29/2010 10:07 PM, Wolfram Sang wrote:
> >>>We need to carry some information per host, e.g. the clock. Add a
> >>>structure for it and initialize it in the generic part. Also do not use
> >>>the parent of the platform_device (if it is available), this breaks the
> >>>clock-matching on ARM.
> >>
> >>The reason it's there is for instance a case when the shdci device is exposed
> >>from a MFD device which sits on top of PCI. Then the parent (PCI device)
> >>is the device that is DMA capable. This patch will break such usage.
> >
> >I feared that there is a reason. The problem I see is now, that the parent gets
> >always set (from drivers/base/platform.c):
> 
> Then we obviously need to pass more information in the platform_data to be able
> to chose which device to be used.

Yeah, that was my idea, too.

> >So, sdhci-plftm cannot access the platform_data connected to the original
> >platform_device via host->mmc->parent.
> 
> You're right it wouldn't. But isn't it a bit risky even if you could access it,
> in the long the platform_data coild point to something that is in the __devinit section
> or similar?

The use-case we see now is in the custom init() call, i.e. setting up
GPIO, enabling clocks. That is in the same section. Accessing
platform_data later is in deed always risky and should not be done,
sdhci-pltfm is no special case here.

> What about extend the struct you defined with the pieces needed, and access it via
> sdhci_priv?

At the moment, I don't think this is needed. Will think more about it
(and the other comments) next week, already preparing for a long weekend
\o/

Thanks,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100930/d0f79250/attachment.sig>

  reply	other threads:[~2010-09-30 10:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-29 20:07 [PATCH V3 0/6] SD/MMC-driver for MX35/51 (and improvements to SDHCI) Wolfram Sang
2010-09-29 20:07 ` [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data Wolfram Sang
2010-09-29 21:24   ` Richard Röjfors
2010-09-30  8:16     ` Wolfram Sang
2010-09-30  9:54       ` Richard Röjfors
2010-09-30 10:19         ` Wolfram Sang [this message]
2010-09-30 11:09           ` Anton Vorontsov
2010-09-29 20:08 ` [PATCH 2/6] mmc: sdhci-pltfm: move .h-file into apropriate subdir Wolfram Sang
2010-09-29 20:08 ` [PATCH 3/6] mmc: sdhci: introduce private get_ro Wolfram Sang
2010-09-29 20:08 ` [PATCH 4/6] mmc: sdhci_pltfm: pass more data on custom init-call Wolfram Sang
2010-09-30  8:31   ` Lothar Waßmann
2010-09-30  9:42     ` Anton Vorontsov
2010-10-11 11:07       ` Wolfram Sang
2010-09-29 20:08 ` [PATCH 5/6] mmc: sdhci-of-esdhc: factor out common stuff Wolfram Sang
2010-09-29 20:08 ` [PATCH 6/6] mmc: sdhci-pltfm: add pltfm-driver for imx35/51 Wolfram Sang
2010-09-29 20:14   ` Chris Ball
2010-10-02 15:15 ` [PATCH 1/4] mach-cpuimx35: remove unecessary tsc2007 functions + style cleanup Eric Bénard
2010-10-02 15:15 ` [PATCH 2/4] eukrea_mbimxsd for cpuimx35: add CAN & SDCard support Eric Bénard
2010-10-08 13:43   ` imx-for-2.6.37 broken [Was: [PATCH 2/4] eukrea_mbimxsd for cpuimx35: add CAN & SDCard support] Uwe Kleine-König
2010-10-02 15:15 ` [PATCH 3/4] i.mx25: add esdhc support Eric Bénard
2010-10-02 15:15 ` [PATCH 4/4] eukrea_mbimxsd for cpuimx25: add CAN & SDCard support Eric Bénard
2010-10-02 15:17 ` [PATCH V3 0/6] SD/MMC-driver for MX35/51 (and improvements to SDHCI) Eric Bénard
  -- strict thread matches above, loose matches on Subject: below --
2010-10-11 14:21 [PATCH 0/6] SD/MMC driver for MX25/35/51 Wolfram Sang
2010-10-11 14:21 ` [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data Wolfram Sang
2010-10-15 10:20 [PATCH V5 0/6] SD/MMC driver for MX25/35/51 Wolfram Sang
2010-10-15 10:20 ` [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data Wolfram Sang

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=20100930101938.GE2655@pengutronix.de \
    --to=w.sang@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).