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: <87y6c03jxj.fsf@deeprootsystems.com>
Date:	Fri, 20 Aug 2010 17:10:00 -0700
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	"Moffett\, Kyle D" <Kyle.D.Moffett@...ing.com>,
	Patrick Pannuto <ppannuto@...eaurora.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm\@vger.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"magnus.damm\@gmail.com" <magnus.damm@...il.com>,
	"gregkh\@suse.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\@vger.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

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

[...]

>>>
>>> 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.

hmm, a new requirement?, and one that would require some significant
changes to the driver model.

Currently, dev_pm_ops for a bus applies globally to *all* devices on
that bus (or class or type) and changing that would require changing the
platform_bus code to start having per-device (or per-parent-device)
checks. 

> If the override (even when fixed to work at runtime) applies to every
> device on the platform_bus_type, then I'll nack it.  

/me can't help but wonder why the OMAP implementation is getting all the
negative attention while the other identical implementations are already
upstream.

> My concern here is that the SoC or platform support code doesn't get
> to "own" the platform_bus_type.

Well, I'm not proposing that here.  This "feature" already exists in
mainline (albeit using the less-than-optimal weak symbol approach.)  All
I'm proposing is fixing it to make it multi-arch friendly.

If you think this behavior should be changed to non global, that should
be done a separate series since it is not directly related to runtime PM
support for a given platform, IMO.

> Other drivers/code can register their own set of
> platform_devices, which may also need to perform their own dev_pm_ops
> override.  

IMHO, we should deal with such hypothetical, future problems *if* they
arise down the road.

> If the override is global to the platform_bus_type, then the model
> will not scale.

It will not scale any more (or less) than the current functionality of
the driver model which handles this globally.  Again, if scalabilty
becomes a problem down the road, lets fix it then.

Kevin
--
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/