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: <87hbiql89d.fsf@deeprootsystems.com>
Date:	Thu, 19 Aug 2010 12:20:14 -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:

> I'm not convinced (yet) that this is the right approach, and I'd like
> to see a few sample drivers converted to the new approach.  Creating
> new bus_types that "inherit" from the platform_bus is actually not a
> bad idea, and it is an elegant way to change the behaviour (for
> example, how power management is implemented) for devices connected in
> a different way.
>
> A problem with the approach that Kevin pointed out is that drivers
> that need to work on both the platform_bus_type and the new
> soc_bus_type must explicitly register themselves on both bus types.

And potentially more than 2 if a driver exists for a hardware block on
different SoCs.  Magnus raised this issue for drivers used across SH and
ARM/SH-Mobile, and the same issue exists between TI OMAP and TI DaVinci
SoCs.

> There is no mechanism to allow drivers from one bus type to also be
> made available to another bus type. Certainly it would be possible to
> invent a mechanism, but the more I think about it, them more I think
> it will be a bad idea.  The runtime-PM use-case that kicked this
> discussion off makes the assumption that a driver will behave
> identically when attached to either the platform_bus_type or the
> soc_bus_type.  However, I think that in the general case that
> assumption will prove to be false.  I strongly suspect that the new
> bus type will turn out to be not as similar to the platform_bus_type
> as originally assumed and that there will still be bus-type-specific
> impact on device drivers

What makes you suspect that?  Maybe Patrick has other use-cases in mind,
but from a PM perspective, I have not seen any impact.

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.

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.

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/