All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: "Richard Röjfors" <richard.rojfors@pelagicore.com>,
	linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	"Zhu Richard-R65037" <r65037@freescale.com>,
	"zhangfei gao" <zhangfei.gao@gmail.com>,
	"Philip Rakity" <prakity@marvell.com>,
	"Richard Röjfors" <richard.rojfors.ext@mocean-labs.com>
Subject: Re: [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data
Date: Thu, 30 Sep 2010 15:09:22 +0400	[thread overview]
Message-ID: <20100930110922.GA8464@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20100930101938.GE2655@pengutronix.de>

On Thu, Sep 30, 2010 at 12:19:38PM +0200, Wolfram Sang wrote:
[...]
> > 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.

I don't think that it's always risky, it's more driver-specific.

Many drivers access it from everywhere, see drivers/mmc/host/mmc_spi.c
for example. In general, if the driver needs most of the platform data
in the run-time, it makes no sense to duplicate or copy the pdata into
the private struct field by field.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

WARNING: multiple messages have this Message-ID (diff)
From: cbouatmailru@gmail.com (Anton Vorontsov)
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 15:09:22 +0400	[thread overview]
Message-ID: <20100930110922.GA8464@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20100930101938.GE2655@pengutronix.de>

On Thu, Sep 30, 2010 at 12:19:38PM +0200, Wolfram Sang wrote:
[...]
> > 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.

I don't think that it's always risky, it's more driver-specific.

Many drivers access it from everywhere, see drivers/mmc/host/mmc_spi.c
for example. In general, if the driver needs most of the platform data
in the run-time, it makes no sense to duplicate or copy the pdata into
the private struct field by field.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

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

Thread overview: 47+ 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 [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   ` 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
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-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
2010-10-15 10:20   ` Wolfram Sang
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-11 14:21   ` Wolfram Sang
2010-09-28 12:36 [PATCH 0/6] Add driver for mx35/51-esdhc-controller (and update sdhci for that) Wolfram Sang
2010-09-28 12:36 ` [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data Wolfram Sang
2010-09-28 12:57   ` Anton Vorontsov
2010-09-28 13:54   ` zhangfei gao
     [not found]   ` <48641052-49AF-4A24-9C8C-42E59791D6A7@marvell.com>
2010-09-28 14:49     ` 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=20100930110922.GA8464@oksana.dev.rtsoft.ru \
    --to=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=richard.rojfors.ext@mocean-labs.com \
    --cc=richard.rojfors@pelagicore.com \
    --cc=w.sang@pengutronix.de \
    --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.