All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Marcus Lorentzon <marcus.lorentzon@linaro.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: Multiple parents in device driver model and Common Display Framework (CDF)
Date: Wed, 13 Feb 2013 00:17:52 +0000	[thread overview]
Message-ID: <201302130017.52311.arnd@arndb.de> (raw)
In-Reply-To: <20130212222955.GA25968@kroah.com>

On Tuesday 12 February 2013, Greg KH wrote:
> On Tue, Feb 12, 2013 at 11:20:04PM +0100, Marcus Lorentzon wrote:
> > Den 12 feb 2013 23:02 skrev "Greg KH" <gregkh@linuxfoundation.org>:
> > >
> > > On Tue, Feb 12, 2013 at 04:04:53PM +0100, Marcus Lorentzon wrote:
> > > > 3) Daniel V hinted that multiple parents (or multiple busses) is
> > > > something that has been discussed as a limitation of device driver
> > > > model before. And that maybe now was the time to fix that or at
> > > > least sort out how to handle it.
> > >
> > > No, it's the other way around, we have discussed ways about having
> > > multiple drivers control a single device at the same time.  The
> > > "multiple parents" issue has come up a number of times with the power
> > > management people, but they solved this by keeping a separate tree of
> > > how to properly control and walk things to handle power domains and the
> > > like.
> > >
> > Thanks,
> > does this mean there are no other devices in the kernel that sit on multiple
> > busses that can be use as inspiration?
> 
> Lots of devices do this, but they all have an individual 'struct device'
> for the part that sits on each bus, with a single driver controlling
> both of them

A typical example of this is an ethernet device where the MAC and PHY
are on different buses. While we have some drivers that just bind to
both devices, another solution is to have separate device drivers
for each portion, and an interface to communicate between them.

It depends a bit on what the two bus interfaces are used for.

	Arnd

      reply	other threads:[~2013-02-13  0:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 15:04 Multiple parents in device driver model and Common Display Framework (CDF) Marcus Lorentzon
2013-02-12 15:53 ` Tomi Valkeinen
2013-02-12 17:06   ` Marcus Lorentzon
2013-02-12 18:08     ` Tomi Valkeinen
2013-02-12 22:02 ` Greg KH
2013-02-12 22:20   ` Marcus Lorentzon
2013-02-12 22:29     ` Greg KH
2013-02-13  0:17       ` Arnd Bergmann [this message]

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=201302130017.52311.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=marcus.lorentzon@linaro.org \
    --cc=tomi.valkeinen@ti.com \
    /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.