From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-kernel@vger.kernel.org, paul@pwsan.com,
khilman@deeprootsystems.com, gregkh@suse.de,
stern@rowland.harvard.edu, linux-pm@lists.linux-foundation.org
Subject: Re: [PATCH] Driver Core: Add platform device arch data V2
Date: Fri, 5 Jun 2009 21:54:15 +0200 [thread overview]
Message-ID: <200906052154.16563.rjw@sisk.pl> (raw)
In-Reply-To: <aec7e5c30906042007t26915c05rd8ef375b8d4a353c@mail.gmail.com>
On Friday 05 June 2009, Magnus Damm wrote:
> On Wed, Jun 3, 2009 at 6:01 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > On Tuesday 02 June 2009, Magnus Damm wrote:
> >> If you guys dislike adding arch specific data to struct platform
> >> device then for SuperH we can just (mis)use the arch specific data in
> >> struct device instead. I'm afraid that solution wastes memory since
> >> the data will only be used for platform devices anyway. So I prefer
> >> adding arch specific data to struct platform_device instead of struct
> >> device if possible.
> >
> > BTW, what is the difference really? You can always put
> > dev.platform_data = NULL for devices that don't have any platform data,
> > can't you?
>
> So the convention is that dev.platform_data points to driver-specific
> data. It may or may not be required by the driver. The format of this
> data is driver specific and should be the same across architectures.
>
> What I'm trying to add with struct pdev_archdata is a place for
> architecture specific data. This data is needed by architecture
> specific code (for example runtime PM), and since it's architecture
> specific it should _never_ be touched by device driver code. Exactly
> like struct dev_archdata but for platform devices.
>
> Like I said, we _could_ use struct device for this purpose, but it
> sounds like suboptimal software design to me. Using struct device
> means that we put data where it doesn't belong. I'd like to add
> _platform_ _device_ _specific_ data, not data that should be present
> in all struct devices in the system but only used in some cases.
OK, that explains the idea. Perhaps it's woth putting into the changelog?
Best,
Rafael
prev parent reply other threads:[~2009-06-05 19:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-01 10:16 [PATCH] Driver Core: Add platform device arch data V2 Magnus Damm
2009-06-01 18:47 ` Rafael J. Wysocki
2009-06-01 19:33 ` Rafael J. Wysocki
2009-06-02 4:33 ` Magnus Damm
2009-06-02 15:30 ` Kevin Hilman
2009-06-03 8:56 ` Rafael J. Wysocki
2009-06-03 8:45 ` Rafael J. Wysocki
2009-06-05 2:52 ` Magnus Damm
2009-06-03 9:01 ` Rafael J. Wysocki
2009-06-05 3:07 ` Magnus Damm
2009-06-05 19:54 ` Rafael J. Wysocki [this message]
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=200906052154.16563.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=gregkh@suse.de \
--cc=khilman@deeprootsystems.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=magnus.damm@gmail.com \
--cc=paul@pwsan.com \
--cc=stern@rowland.harvard.edu \
/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