From: Jan Kiszka <jan.kiszka@siemens.com>
To: Kim Phillips <kim.phillips@linaro.org>, scottwood@freescale.com
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
kvm@vger.kernel.org, R65777@freescale.com, B07421@freescale.com,
B08248@freescale.com, christoffer.dall@linaro.org,
alex.williamson@redhat.com, a.motakis@virtualopensystems.com,
agraf@suse.de, B16395@freescale.com
Subject: Re: [REPOST][PATCH 1/2] driver core: Add new device_driver flag to allow binding via sysfs only
Date: Mon, 09 Dec 2013 20:12:45 +0100 [thread overview]
Message-ID: <52A6162D.7090008@siemens.com> (raw)
In-Reply-To: <20131209125802.0e2b86a3daa9d9ad5a7d43bf@linaro.org>
On 2013-12-09 19:58, Kim Phillips wrote:
> On Thu, 5 Dec 2013 16:38:15 -0600
> Scott Wood <scottwood@freescale.com> wrote:
>
>> On Thu, 2013-12-05 at 17:45 +0000, Kim Phillips wrote:
>>> On Tue, 03 Dec 2013 16:34:33 +0100
>>> Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>
>>>> On 2013-12-03 13:34, Kim Phillips wrote:
>>>>> VFIO supports pass-through of devices to user space - for sake
>>>>> of illustration, say a PCI e1000 device:
>>>>>
>>>>> - the e1000 is first unbound from the PCI e1000 driver via sysfs
>>>>> - the vfio-pci driver is told via new_id that it now handles e1000 devices
>>>>> - the e1000 is explicitly bound to vfio-pci through sysfs
>>>>>
>>>>> However, now we have two drivers in the system that both handle e1000
>>>>> devices. A hotplug event could then occur and it is ambiguous as to which
>>>>> driver will claim the device. The desired semantics is that vfio-pci is
>>>>> only bound to devices by explicit request in sysfs. This patch makes this
>>>>> possible by introducing a sysfs_bind_only flag in struct device_driver.
>>>>>
>>>>> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
>>>>> Signed-off-by: Kim Phillips <kim.phillips@linaro.org>
>>>>> ---
>>>>> rebased onto 3.13-rc2, and reposted from first submission which
>>>>> recieved no comments:
>>>>>
>>>>> https://lkml.org/lkml/2013/10/11/53
>>>>>
>>>>> drivers/base/dd.c | 5 ++++-
>>>>> include/linux/device.h | 2 ++
>>>>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>>>>> index 0605176..b83b16d 100644
>>>>> --- a/drivers/base/dd.c
>>>>> +++ b/drivers/base/dd.c
>>>>> @@ -389,7 +389,7 @@ static int __device_attach(struct device_driver *drv, void *data)
>>>>> {
>>>>> struct device *dev = data;
>>>>>
>>>>> - if (!driver_match_device(drv, dev))
>>>>> + if (drv->sysfs_bind_only || !driver_match_device(drv, dev))
>>>>> return 0;
>>>>>
>>>>> return driver_probe_device(drv, dev);
>>>>> @@ -476,6 +476,9 @@ static int __driver_attach(struct device *dev, void *data)
>>>>> */
>>>>> int driver_attach(struct device_driver *drv)
>>>>> {
>>>>> + if (drv->sysfs_bind_only)
>>>>> + return 0;
>>>>> +
>>>>> return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(driver_attach);
>>>>> diff --git a/include/linux/device.h b/include/linux/device.h
>>>>> index 952b010..ed441d1 100644
>>>>> --- a/include/linux/device.h
>>>>> +++ b/include/linux/device.h
>>>>> @@ -200,6 +200,7 @@ extern struct klist *bus_get_device_klist(struct bus_type *bus);
>>>>> * @owner: The module owner.
>>>>> * @mod_name: Used for built-in modules.
>>>>> * @suppress_bind_attrs: Disables bind/unbind via sysfs.
>>>>> + * @sysfs_bind_only: Only allow bind/unbind via sysfs.
>>>>> * @of_match_table: The open firmware table.
>>>>> * @acpi_match_table: The ACPI match table.
>>>>> * @probe: Called to query the existence of a specific device,
>>>>> @@ -233,6 +234,7 @@ struct device_driver {
>>>>> const char *mod_name; /* used for built-in modules */
>>>>>
>>>>> bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
>>>>> + bool sysfs_bind_only; /* only allow bind/unbind via sysfs */
>>>>>
>>>>> const struct of_device_id *of_match_table;
>>>>> const struct acpi_device_id *acpi_match_table;
>>>>
>>>> I think I only discussed this with Stuart in person at the KVM Forum:
>>>> Why not deriving the property "sysfs bind only" from the fact that a
>>>> device does wild-card binding? Are there use cases that benefit from
>>>> decoupling both features?
>>>
>>> you mean merge the two new flags sysfs_bind_only and platform driver's
>>> match_any_dev into one new single driver flag, right? good question.
>>
>> 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.
I didn't follow if Greg expressed his opinion on this or a similar
scenario before. If he prefers separate knobs for a certain reason, he
likely wins.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2013-12-09 19:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 12:34 [REPOST][PATCH 1/2] driver core: Add new device_driver flag to allow binding via sysfs only Kim Phillips
2013-12-03 15:34 ` Jan Kiszka
2013-12-05 17:45 ` Kim Phillips
2013-12-05 22:38 ` Scott Wood
2013-12-09 18:58 ` Kim Phillips
2013-12-09 19:12 ` Jan Kiszka [this message]
2013-12-09 21:33 ` Scott Wood
2013-12-19 1:04 ` Greg Kroah-Hartman
2013-12-19 1:07 ` Greg Kroah-Hartman
2013-12-19 20:22 ` Scott Wood
2013-12-19 20:34 ` Greg Kroah-Hartman
2013-12-19 21:06 ` Stuart Yoder
2013-12-19 21:43 ` Greg Kroah-Hartman
2013-12-19 22:15 ` Scott Wood
2013-12-19 22:32 ` Greg Kroah-Hartman
2013-12-19 23:08 ` Stuart Yoder
2013-12-20 0:00 ` Greg Kroah-Hartman
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=52A6162D.7090008@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=B07421@freescale.com \
--cc=B08248@freescale.com \
--cc=B16395@freescale.com \
--cc=R65777@freescale.com \
--cc=a.motakis@virtualopensystems.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=kim.phillips@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scottwood@freescale.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.