All of lore.kernel.org
 help / color / mirror / Atom feed
From: khilman@deeprootsystems.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata
Date: Thu, 05 Aug 2010 08:19:19 -0700	[thread overview]
Message-ID: <87mxt11408.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTinv2ZpLaRYEN+FVwuX1QTK_+568K8BckVp_tx=K@mail.gmail.com> (Grant Likely's message of "Wed, 4 Aug 2010 16:54:59 -0600")

Grant Likely <grant.likely@secretlab.ca> writes:

> On Tue, Aug 3, 2010 at 10:16 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Magnus Damm <magnus.damm@gmail.com> writes:
>>
>>> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>>>><khilman@deeprootsystems.com> wrote:
>>>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>>>> Mikael Pettersson wrote:
>>>>>>>>> Eric Miao writes:
>>>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>>>> ?> > and allowing each subarch to customize it as needed.
>>>
>>>>>Do you remember what happened with this patch?
>>>>
>>>> I don't have all the details in front of me because I'm on my phone,
>>>> but I advised against pdev_archdata because it is
>>>> multiplatform-unfriendly.
>>>
>>> Ok, I did not expect that. =) But after thinking a bit it does make
>>> sense. I wonder what my options are. I'm not so fond of the idea to
>>> wrap the platform devices - that's not more multi-platform friendly,
>>> is it?
>>
>> [sorry for the lag, been on vacation]
>>
>> Wrapping is more multi-platform friendly because only platform-specific
>> code accesses the wrapped code. ?It's also logically consistent as
>> a struct device is contained by a platform_device which is then
>> contained by an omap_device (in our case.) ? Only OMAP-specific code
>> ever knows about or touches that layer.
>
> (I just noticed this; will also reply on the other thread so it is
> recorded in the public record) But it is also really dangerous;
> particularly in the case of dynamically allocated platform_devices.
> When handed a random platform_device pointer, you have absolutely *no*
> idea whether or not it is valid to dereference a pointer at a lower
> address from the platform_device pointer.  It is very likely that
> there will be other code in the system that will register
> platform_devices without the omap_device wrapper.
>
>>> How about using devres and platform bus notifiers?
>>
>> That seems fine too, and probably better if the amount of data/code you need
>> is small. ?In the OMAP case, it's rather complicated so it's cleaner
>> IMHO to keep it in a separate omap_device layer and struct.
>
> but it is safe
>

/me is beaten into submission.  ;)

OK, it would not be too much work to move the OMAP implementation to
devres + notifiers either.  I can give it a spin.

Kevin

  parent reply	other threads:[~2010-08-05 15:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-23  1:50 [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata Kevin Hilman
2009-09-23  1:50 ` Kevin Hilman
2009-09-23  3:54 ` Ben Dooks
2009-09-23  3:54 ` Ben Dooks
2009-09-23 23:26   ` Kevin Hilman
2009-09-23 23:26   ` Kevin Hilman
2009-09-23  4:53 ` Eric Miao
2009-09-23  4:53 ` Eric Miao
2009-09-23 10:23   ` Mikael Pettersson
2009-09-23 23:28     ` Kevin Hilman
2009-09-23 23:28       ` Kevin Hilman
2009-09-23 23:30       ` Eric Miao
2009-09-23 23:36         ` Kevin Hilman
2009-09-23 23:36         ` Kevin Hilman
2009-10-26 23:13         ` Kevin Hilman
2009-10-26 23:13         ` Kevin Hilman
2010-07-22  8:06           ` [linux-pm] " Magnus Damm
2010-07-24 20:24             ` Grant Likely
2010-07-24 20:24             ` [linux-pm] " Grant Likely
2010-07-26  1:51               ` Magnus Damm
2010-07-26  1:51               ` [linux-pm] " Magnus Damm
2010-08-03 16:16                 ` Kevin Hilman
2010-08-03 16:16                 ` [linux-pm] " Kevin Hilman
2010-08-04  3:56                   ` Magnus Damm
2010-08-04 23:10                     ` Grant Likely
2010-08-05  3:07                       ` Magnus Damm
2010-08-05 15:12                         ` Kevin Hilman
2010-08-05 15:12                         ` Kevin Hilman
2010-08-05  3:07                       ` Magnus Damm
2010-08-04 23:10                     ` Grant Likely
2010-08-04  3:56                   ` Magnus Damm
2010-08-04 22:54                   ` [linux-pm] " Grant Likely
2010-08-05 15:19                     ` Kevin Hilman
2010-08-05 15:19                     ` Kevin Hilman [this message]
2010-08-04 22:54                   ` Grant Likely
2010-08-04 22:41                 ` [linux-pm] " Grant Likely
2010-08-05  2:53                   ` Magnus Damm
2010-08-05  2:53                   ` [linux-pm] " Magnus Damm
2010-08-04 22:41                 ` Grant Likely
2010-07-22  8:06           ` Magnus Damm
2009-09-23 23:30       ` Eric Miao
2009-09-23 10:23   ` Mikael Pettersson

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=87mxt11408.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --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 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.