All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <w.sang@pengutronix.de>
To: Anton Vorontsov <cbouatmailru@gmail.com>
Cc: "Lothar Waßmann" <LW@KARO-electronics.de>,
	linux-mmc@vger.kernel.org,
	"Zhu Richard-R65037" <r65037@freescale.com>,
	"zhangfei gao" <zhangfei.gao@gmail.com>,
	"Philip Rakity" <prakity@marvell.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/6] mmc: sdhci_pltfm: pass more data on custom init-call
Date: Mon, 11 Oct 2010 13:07:58 +0200	[thread overview]
Message-ID: <20101011110758.GE6028@pengutronix.de> (raw)
In-Reply-To: <20100930094202.GA581@oksana.dev.rtsoft.ru>

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

On Thu, Sep 30, 2010 at 01:42:02PM +0400, Anton Vorontsov wrote:
> On Thu, Sep 30, 2010 at 10:31:58AM +0200, Lothar Waßmann wrote:
> > > The custom init call may need more data to perform its job, so we pass
> > > it a pointer to pdata, too. Also, always use the platform_id specific
> > > data even if platform_data is present. Doing that, platform_data can
> > > additionally be parsed by init() for board-specific information (via
> > > sdhci->mmc->parent).
> > > 
> > Why not a pointer to the platform_device itself? Then the callback
> > function would have even more information (e.g. platform_device ID)
> > and could easily get at the platform_data too.
> 
> dev->platform_data may not be there. There are two ways to pass
> the "platform data" to the sdhci-pltfm driver:
> 
> a) via dev->platform_data
> b) via platform_device_id->driver_data

or c) both :)

which is the reason for the current implementation.
platform_device_id->driver_data may still need additional information
from the board (e.g. a write protect pin from board pcm043) while the
larger part of the driver_data-extensions are still generic (e.g. to
imx-esdhc).

> 
> Technically, we can do something like this in the probe():
> 
> if (!pdev->dev.platform_data)
> 	pdev->dev.platform_data = platform_device_id->driver_data;
> 
> pdata->init(dev);
> 
> Note, in this case we must also NULLify platform_data it at remove(),
> as platform_device_release() will try to free statically allocated
> memory.
> 
> Thanks,
> 
> -- 
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
> --
> 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

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: w.sang@pengutronix.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/6] mmc: sdhci_pltfm: pass more data on custom init-call
Date: Mon, 11 Oct 2010 13:07:58 +0200	[thread overview]
Message-ID: <20101011110758.GE6028@pengutronix.de> (raw)
In-Reply-To: <20100930094202.GA581@oksana.dev.rtsoft.ru>

On Thu, Sep 30, 2010 at 01:42:02PM +0400, Anton Vorontsov wrote:
> On Thu, Sep 30, 2010 at 10:31:58AM +0200, Lothar Wa?mann wrote:
> > > The custom init call may need more data to perform its job, so we pass
> > > it a pointer to pdata, too. Also, always use the platform_id specific
> > > data even if platform_data is present. Doing that, platform_data can
> > > additionally be parsed by init() for board-specific information (via
> > > sdhci->mmc->parent).
> > > 
> > Why not a pointer to the platform_device itself? Then the callback
> > function would have even more information (e.g. platform_device ID)
> > and could easily get at the platform_data too.
> 
> dev->platform_data may not be there. There are two ways to pass
> the "platform data" to the sdhci-pltfm driver:
> 
> a) via dev->platform_data
> b) via platform_device_id->driver_data

or c) both :)

which is the reason for the current implementation.
platform_device_id->driver_data may still need additional information
from the board (e.g. a write protect pin from board pcm043) while the
larger part of the driver_data-extensions are still generic (e.g. to
imx-esdhc).

> 
> Technically, we can do something like this in the probe():
> 
> if (!pdev->dev.platform_data)
> 	pdev->dev.platform_data = platform_device_id->driver_data;
> 
> pdata->init(dev);
> 
> Note, in this case we must also NULLify platform_data it at remove(),
> as platform_device_release() will try to free statically allocated
> memory.
> 
> Thanks,
> 
> -- 
> Anton Vorontsov
> email: cbouatmailru at gmail.com
> irc://irc.freenode.net/bd2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
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/20101011/f3816841/attachment.sig>

  reply	other threads:[~2010-10-11 11:08 UTC|newest]

Thread overview: 43+ 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 ` Wolfram Sang
2010-09-29 20:07 ` [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data Wolfram Sang
2010-09-29 20:07   ` Wolfram Sang
2010-09-29 21:24   ` Richard Röjfors
2010-09-29 21:24     ` Richard Röjfors
2010-09-30  8:16     ` Wolfram Sang
2010-09-30  8:16       ` Wolfram Sang
2010-09-30  9:54       ` Richard Röjfors
2010-09-30  9:54         ` Richard Röjfors
2010-09-30 10:19         ` Wolfram Sang
2010-09-30 10:19           ` Wolfram Sang
2010-09-30 11:09           ` Anton Vorontsov
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   ` Wolfram Sang
2010-09-29 20:08 ` [PATCH 3/6] mmc: sdhci: introduce private get_ro Wolfram Sang
2010-09-29 20:08   ` Wolfram Sang
2010-09-29 20:08 ` [PATCH 4/6] mmc: sdhci_pltfm: pass more data on custom init-call Wolfram Sang
2010-09-29 20:08   ` Wolfram Sang
2010-09-30  8:31   ` Lothar Waßmann
2010-09-30  8:31     ` Lothar Waßmann
2010-09-30  9:42     ` Anton Vorontsov
2010-09-30  9:42       ` Anton Vorontsov
2010-10-11 11:07       ` Wolfram Sang [this message]
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   ` 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:08   ` Wolfram Sang
2010-09-29 20:14   ` Chris Ball
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
2010-10-02 15:17   ` 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 4/6] mmc: sdhci_pltfm: pass more data on custom init-call Wolfram Sang
2010-10-11 14:21   ` Wolfram Sang
2010-10-15 10:20 [PATCH V5 0/6] SD/MMC driver for MX25/35/51 Wolfram Sang
2010-10-15 10:21 ` [PATCH 4/6] mmc: sdhci_pltfm: pass more data on custom init-call Wolfram Sang
2010-10-15 10:21   ` 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=20101011110758.GE6028@pengutronix.de \
    --to=w.sang@pengutronix.de \
    --cc=LW@KARO-electronics.de \
    --cc=cbouatmailru@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=prakity@marvell.com \
    --cc=r65037@freescale.com \
    --cc=zhangfei.gao@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.