All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "Moffett, Kyle D" <Kyle.D.Moffett@boeing.com>,
	Patrick Pannuto <ppannuto@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"magnus.damm@gmail.com" <magnus.damm@gmail.com>,
	"gregkh@suse.de" <gregkh@suse.de>,
	Paul Mundt <lethal@linux-sh.org>,
	Magnus Damm <damm@opensource.se>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Eric Miao <eric.y.miao@gmail.com>, Dmitry Torokhov <dtor@mail.ru>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Kyle D Moffett <kyle@moffetthome.net>
Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
Date: Thu, 19 Aug 2010 12:20:14 -0700	[thread overview]
Message-ID: <87hbiql89d.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTi=Pm8BL+Ksq1o7MYpV7mMH10bEPu1=Am9EgT-Kk@mail.gmail.com> (Grant Likely's message of "Mon, 16 Aug 2010 00:43:01 -0600")

Grant Likely <grant.likely@secretlab.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

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "Moffett\, Kyle D" <Kyle.D.Moffett@boeing.com>,
	Patrick Pannuto <ppannuto@codeaurora.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm\@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"magnus.damm\@gmail.com" <magnus.damm@gmail.com>,
	"gregkh\@suse.de" <gregkh@suse.de>,
	Paul Mundt <lethal@linux-sh.org>,
	Magnus Damm <damm@opensource.se>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Eric Miao <eric.y.miao@gmail.com>, Dmitry Torokhov <dtor@mail.ru>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	Kyle D Moffett <kyle@moffetthome.net>
Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
Date: Thu, 19 Aug 2010 12:20:14 -0700	[thread overview]
Message-ID: <87hbiql89d.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTi=Pm8BL+Ksq1o7MYpV7mMH10bEPu1=Am9EgT-Kk@mail.gmail.com> (Grant Likely's message of "Mon, 16 Aug 2010 00:43:01 -0600")

Grant Likely <grant.likely@secretlab.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

  reply	other threads:[~2010-08-19 19:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-10 23:49 [PATCHv2 0/2] platform: Facilitate the creation of pseudo-platform buses Patrick Pannuto
2010-08-10 23:49 ` [PATCH 1/2] platform: Use drv->driver.bus instead of assuming platform_bus_type Patrick Pannuto
2010-08-10 23:49 ` [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses Patrick Pannuto
2010-08-13  1:13   ` Patrick Pannuto
2010-08-14 21:04     ` Greg KH
2010-08-13 22:05   ` Grant Likely
2010-08-16 18:47     ` Patrick Pannuto
2010-08-16 20:25       ` Grant Likely
2010-08-16 23:58       ` Michał Mirosław
2010-08-16  1:38   ` Moffett, Kyle D
2010-08-16  6:43     ` Grant Likely
2010-08-19 19:20       ` Kevin Hilman [this message]
2010-08-19 19:20         ` Kevin Hilman
2010-08-19 22:22         ` Grant Likely
2010-08-20 18:51           ` Kevin Hilman
2010-08-20 18:51             ` Kevin Hilman
2010-08-20 20:08             ` Grant Likely
2010-08-21  0:10               ` Kevin Hilman
2010-08-21  0:10                 ` Kevin Hilman
2010-08-21  7:10                 ` Grant Likely
2010-08-23 14:53                   ` Kevin Hilman
2010-08-23 14:53                     ` Kevin Hilman

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=87hbiql89d.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=Kyle.D.Moffett@boeing.com \
    --cc=damm@opensource.se \
    --cc=dtor@mail.ru \
    --cc=eric.y.miao@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@suse.de \
    --cc=kyle@moffetthome.net \
    --cc=lethal@linux-sh.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=ppannuto@codeaurora.org \
    --cc=rjw@sisk.pl \
    /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.