linux-kernel - Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTine=VLLm4+ReKeMKBdbV1JsunNagwKxGMDhEe8e@mail.gmail.com>
Date:	Fri, 20 Aug 2010 14:08:49 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	"Moffett, Kyle D" <Kyle.D.Moffett@...ing.com>,
	Patrick Pannuto <ppannuto@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"magnus.damm@...il.com" <magnus.damm@...il.com>,
	"gregkh@...e.de" <gregkh@...e.de>,
	Paul Mundt <lethal@...ux-sh.org>,
	Magnus Damm <damm@...nsource.se>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Eric Miao <eric.y.miao@...il.com>,
	Dmitry Torokhov <dtor@...l.ru>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Kyle D Moffett <kyle@...fetthome.net>
Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses

On Fri, Aug 20, 2010 at 12:51 PM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
> Grant Likely <grant.likely@...retlab.ca> writes:
>
> [...]
>
>>> One of the primary goals of this (at least for me and it seems Magnus also)
>>> is to keep drivers ignorant of their bus type, and any bus-type-specific
>>> code should be done in the bus_type implementation.
>>
>> Heh; which just screams to me that bus_type is the wrong level to be
>> abstracting the behaviour
>
> Heh, now I feel like we're going around in circles.  Remember, I never
> wanted to create add a new bus_type.  Someone else [ahem] suggested
> doing the abstraction at the bus_type level.  ;)

Hey!  I didn't suggest it either!  I believe that was Greg at ELC.  I
just... um... kind of took it and ran with it.  :-)

>> (but I also understand your need for the
>> "omap_device" wrapper around platform_device which also requires some
>> method to sort out when a platform_device really is an omap_device
>> without an unsafe dereference).
>
> Yes, I'm working on the devres approach to that now, as is Magnus for
> the sh-mobile version (proposed for .36-rc1[1])
>
>>> Both for SH and OMAP, we've been using the (admiteddly broken)
>>> weak-symbol-override approach to getting a custom bus-type based on the
>>> platform_bus.  We've been using that in OMAP for a while now and have
>>> not seen any need to for the drivers to know if they are on the vanilla
>>> platform_bus or the customized one.
>>>
>>> I'm very curious to hear what type of impact you expect to the drivers.
>>
>> My fears on this point may very well be unfounded.  This isn't the
>> hill I'm going to die on either.  Show me an implementation of driver
>> sharing that is clean and prove me wrong!  :-)
>
> IMHO, simply overriding the few dev_pm_ops methods was the cleanest and
> simplest.
>
> Since we seem to be in agreement now that the a new bus may not the
> right abstraction for this (since we want it to be completely
> transparent to the drivers), I'll go back to the original design.  No new
> bus types, keep the platform_bus as is, but simply override the few
> dev_pm_ops methods I care about.  This is what is done on SH,
> SH-Mobile[1] and my original version for OMAP that started this
> conversation.
>
> Yes, the weak-symbol method of overriding is not scalable, but that's a
> separate issue from whether or not to create a new bus.  I have a
> proposed fix for the weak which I'll post shortly.

Okay.

One constraint remains though:  If you can override the dev_pm_ops on
a per-device or per-device-parent basis, then you've got my support.
If the override (even when fixed to work at runtime) applies to every
device on the platform_bus_type, then I'll nack it.  My concern here
is that the SoC or platform support code doesn't get to "own" the
platform_bus_type.  Other drivers/code can register their own set of
platform_devices, which may also need to perform their own dev_pm_ops
override.  If the override is global to the platform_bus_type, then
the model will not scale.

Cheers,
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/