From: Arnd Bergmann <arnd@arndb.de>
To: John Williams <john.williams@petalogix.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Wolfram Sang <w.sang@pengutronix.de>,
Michal Simek <monstr@monstr.eu>,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org, hjk@hansjkoch.de
Subject: Re: [PATCH v3] uio/pdrv_genirq: Add OF support
Date: Tue, 19 Apr 2011 15:02:37 +0200 [thread overview]
Message-ID: <201104191502.37396.arnd@arndb.de> (raw)
In-Reply-To: <BANLkTin0krYi+MqngSQ5n-752vDa_a8ZtA@mail.gmail.com>
On Tuesday 19 April 2011, John Williams wrote:
> OK, so let's talk about this interface. As I see it, it must be able
> to handle bind per-instance, not per compatibility.
Yes.
> For example, we make systems with multiple, identical timers. One
> will be used as the system timer, the others need to be (optionally)
> bound to generic UIO.
>
> Therefore, it's not OK to just do
>
> echo "vendor,device" >> /sys/class/something/generic-uio/compatlist
>
> or whatever, as this would bind all instances matching vendor,device.
>
> So, the question I have is, how to handle bind per-instance?
>
> I can accept that the generic-uio idea is permanently blocked, but
> please can we have some concrete suggestions on an approach that would
> be acceptable?
I think nobody has had a good idea so far, unfortunately. It would
be nice if you could research how libusb, vfio and qemu pci passthrough
work. Hopefully one of these uses a method that we can do here, too.
> > In the mean time, explicitly modifying the match table is an okay
> > compromise.
>
> My mind is still boggling that in this day and age it could possibly
> be preferred to modify code, instead of a data structure. However,
> clearly this is a lost cause!
It's preferred to do a local modification to a single kernel build over
introducing an interface that we have to maintain compatibility with
when we already know we don't want it.
Arnd
next prev parent reply other threads:[~2011-04-19 13:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 8:50 [PATCH v3] uio/pdrv_genirq: Add OF support Michal Simek
2011-04-18 8:50 ` Michal Simek
2011-04-18 10:35 ` Paul Mundt
2011-04-18 11:10 ` Michal Simek
2011-04-18 11:10 ` Michal Simek
2011-04-18 16:06 ` Wolfram Sang
2011-04-18 16:06 ` Wolfram Sang
2011-04-19 1:58 ` John Williams
2011-04-19 1:58 ` John Williams
2011-04-19 6:11 ` Grant Likely
2011-04-19 7:32 ` Arnd Bergmann
[not found] ` <201104190932.31777.arnd-r2nGTMty4D4@public.gmane.org>
2011-04-19 8:42 ` Michal Simek
2011-04-19 12:37 ` John Williams
2011-04-19 13:02 ` Arnd Bergmann [this message]
2011-04-19 14:49 ` Grant Likely
2011-04-19 15:07 ` Arnd Bergmann
2011-04-19 15:45 ` Grant Likely
2011-04-19 15:45 ` Grant Likely
2011-04-21 12:08 ` Wolfram Sang
2011-04-21 12:08 ` Wolfram Sang
2011-04-21 23:46 ` John Williams
2011-04-21 23:46 ` John Williams
2011-04-22 6:07 ` Wolfram Sang
2011-04-19 8:16 ` Michal Simek
2011-04-19 8:16 ` Michal Simek
2011-04-19 6:08 ` Grant Likely
2011-04-19 8:15 ` Michal Simek
2011-04-19 22:00 ` Hans J. Koch
2011-04-19 23:09 ` Scott Wood
2011-04-19 23:09 ` Scott Wood
2011-04-27 11:05 ` Michal Simek
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=201104191502.37396.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=hjk@hansjkoch.de \
--cc=john.williams@petalogix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=monstr@monstr.eu \
--cc=w.sang@pengutronix.de \
/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.