[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1386624837.10013.49.camel@snotra.buserror.net>
Date: Mon, 9 Dec 2013 15:33:57 -0600
From: Scott Wood <scottwood@...escale.com>
To: Jan Kiszka <jan.kiszka@...mens.com>
CC: Kim Phillips <kim.phillips@...aro.org>,
<linux-kernel@...r.kernel.org>, <gregkh@...uxfoundation.org>,
<kvm@...r.kernel.org>, <R65777@...escale.com>,
<B07421@...escale.com>, <B08248@...escale.com>,
<christoffer.dall@...aro.org>, <alex.williamson@...hat.com>,
<a.motakis@...tualopensystems.com>, <agraf@...e.de>,
<B16395@...escale.com>
Subject: Re: [REPOST][PATCH 1/2] driver core: Add new device_driver flag to
allow binding via sysfs only
On Mon, 2013-12-09 at 20:12 +0100, Jan Kiszka wrote:
> On 2013-12-09 19:58, Kim Phillips wrote:
> > On Thu, 5 Dec 2013 16:38:15 -0600
> > Scott Wood <scottwood@...escale.com> wrote:
> >
> >> What would combining them solve, other than making it more likely that
> >> Greg complains about the wildcard because it would no longer be handled
> >> at the bus level where all the other matching goes on?
> >>
> >> They are logically separate things. That doesn't change just because we
> >> currently plan to use them together.
> >
> > Jan? Given the above, what would be the advantage of merging
> > sysfs_bind_only and (PCI drivers' PCI_ANY_ID and platform drivers'
> > match_any_dev)?
>
> That you cannot configure (likely) meaningless or even harmful (bind-any
> + auto-bind) configurations.
If you want to put in a check that warns on bind-any plus auto-bind,
fine -- but that doesn't mean they should share a mechanism. It's valid
to have no-auto-bind without a wildcard match. And FWIW, PCI already
has wildcard matches without any no-auto-bind mechanism (it's presumably
not intended to specify PCI_ANY_ID for all fields, but it is allowed
AFAICT).
-Scott
--
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/
Powered by blists - more mailing lists