linux.kernel - 26 new messages in 15 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* serial: samsung: Move uart_register_driver call to device probe - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/8b321f7043371d52?hl=en
* linux-next: build failure after merge of the tip tree - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/5d213db28c0ba532?hl=en
* lockdep: (Was: check && lockdep_no_validate) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/07e5799772466cd4?hl=en
* MAINTAINERS tree branches [xen tip as an example] - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e080ae587afdec2e?hl=en
* ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/0bc8f0bfd15b8d30?hl=en
* input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path - 4
messages, 3 authors
http://groups.google.com/group/linux.kernel/t/d9e917b55c72248e?hl=en
* Quirk Intel PCH root ports for ACS-like features - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fb4c38bf865c1643?hl=en
* xen-netback: Timeout packets in RX path - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fa3947f0129612f2?hl=en
* hyperv: Add support for physically discontinuous receive buffer - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/1484eaf6bfef9ffe?hl=en
* Drivers: hv: Implement the file copy service - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/e6745e5c9e6c7e65?hl=en
* Terrible performance of sequential O_DIRECT 4k writes in SAN environment. ~3
times slower then Solars 10 with the same HBA/Storage. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c2d4038a5c79058e?hl=en
* tracing: New features and fixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/00a304c4cb1d6344?hl=en
* Poor network performance x86_64.. also with 3.13 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/7e633b15855dce3f?hl=en
* nvme: Cleanup nvme_dev_start() and fix IRQ leak - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7ded004c0804c466?hl=en
* x86/kaslr for v3.14 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/04a24a4d3c0cf627?hl=en

==============================================================================
TOPIC: serial: samsung: Move uart_register_driver call to device probe
http://groups.google.com/group/linux.kernel/t/8b321f7043371d52?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 1:50 pm
From: Alan Cox


> I had earlier submitted a patch [1] to remove the hard coded
> major/minor number for Samsung UART driver, but that was rejected
> because of userspace breakage. Without this patch, Samsung UART driver
> can't bind to the hard-coded device node. Changing the default
> major/minor will also not help to fix the objections raised in [1].
>
> Would you please suggest a way forward?
>
> [1] https://lkml.org/lkml/2013/12/27/2

The dynamic major/minor is the right patch. If the userspace breaks then
the userspace was broken, but I see no evidence in the discussion that
the userspace broke.

204,64 belongs to Altix so neither of the clashing drivers should use it.
We had a table to stop messes like this, and we have dynamic numbering
to stop the table being needed for the future

50 = /dev/ttyIOC0 Altix serial card
...
81 = /dev/ttyIOC31 Altix serial card


Thats what the list says. Samsung should have followed the rules, they
didn't so they get to pick up the pieces. The Amba driver wants moving as
well. It's easy. If you want something to be ABI then make sure you get
it upstream first, if not you get to own all the pain down the line.

Hacking up the core code to paper over this crap is not on. We've been
insisting firmly and robustly for years that people don't keep borrowing
names and numbers they are not allocated, and use dynamic values whenever
possible.

If the hardware isn't present then the driver shouldn't even register
with the tty layer in the first place so it doesn't make any resource
differeneces either for properly written code.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: linux-next: build failure after merge of the tip tree
http://groups.google.com/group/linux.kernel/t/5d213db28c0ba532?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 20 2014 1:50 pm
From: Len Brown


> As a side note, at minimum the semantic and compatibility difference
> needs to be _very_ clearly present in the naming. Something like
> mwait_old_() or mwait_core2_(). That way such dependencies and
> assumptions don't get lost in code restructuring, etc.

Agreed.
We started with mwait_idle() -- which was erroneously removed
and is now being restored under it original name.

The "new" function is mwait_idle_with_hints() -- which uses
the additional hints that were not available w/ the original MWAIT instruction.
Where "new" is Core Duo and later -- all the processor that can use
MWAIT for C-states deeper than C1.

Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Mon, Jan 20 2014 2:00 pm
From: Peter Zijlstra


On Mon, Jan 20, 2014 at 04:39:45PM -0500, Len Brown wrote:
> > As a side note, at minimum the semantic and compatibility difference
> > needs to be _very_ clearly present in the naming. Something like
> > mwait_old_() or mwait_core2_(). That way such dependencies and
> > assumptions don't get lost in code restructuring, etc.
>
> Agreed.
> We started with mwait_idle() -- which was erroneously removed
> and is now being restored under it original name.
>
> The "new" function is mwait_idle_with_hints() -- which uses
> the additional hints that were not available w/ the original MWAIT instruction.
> Where "new" is Core Duo and later -- all the processor that can use
> MWAIT for C-states deeper than C1.

I'm still waiting for someone to explain what's wrong with:

static inline void mwait_idle(void)
{
local_irq_enable();
mwait_idle_with_hints(0, 0);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: lockdep: (Was: check && lockdep_no_validate)
http://groups.google.com/group/linux.kernel/t/07e5799772466cd4?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 1:50 pm
From: Alan Stern


On Mon, 20 Jan 2014, Oleg Nesterov wrote:

> > > At first glance, can't __ATTR_IGNORE_LOCKDEP() use no_validate too ?
> > > (ignoring the fact checkpatch.pl won't be happy). This can simplify
> > > the code, it seems.
> >
> > Well, the macro itself doesn't specify the lockdep class. That happens
> > implicitly in sysfs_get_active(), in the call to rwsem_acquire_read().
> > However, it ought to be possible to change the code so that when
> > ignore_lockdep(sd) returns nonzero, we end up using no_validate.
>
> sysfs_dirent_init_lockdep() can check ->ignore_lockdep and do
> lockdep_set_novalidate_class(). This way sysfs_ignore_lockdep() can
> go away.
>
> I guess we could even change __ATTR_IGNORE_LOCKDEP() to initialize
> ->key = __lockdep_no_validate__ and kill ->ignore_lockdep.

It's clear that you have a more thorough understanding of how sysfs and
lockdep work than I do. :-)

This suggestion sounds quite reasonable.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: MAINTAINERS tree branches [xen tip as an example]
http://groups.google.com/group/linux.kernel/t/e080ae587afdec2e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 1:50 pm
From: "Luis R. Rodriguez"


On Mon, Jan 20, 2014 at 11:02 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 20/01/14 18:33, Luis R. Rodriguez wrote:
>> Is the delta of what is queued for the next release typically small?
>> Otherwise someone doing development based on linux.git alone should
>> have conflicts with anything on the queue, no?
>
> We've not had any issues so far.

Will give that a shot.

>>> To see what's queued for the next release, the next merge window,
>>> and other work in progress:
>>>
>>> The Xen subsystem maintainers' tip.git tree.
>>
>> That's the thing, you can't clone the tip.git tree today well, there
>> are undefined references and git gives up, asking for the linux-next
>> branch however did work.
>
> I think it did work, you just needed to checkout a branch manually.

Indeed, I just didn't expect random developer to know how to fix this,
and if other git trees will exist in the same form I figured its best
to extend MAINTAINERS to specify the preference for a branch. In this
case, since the branch is not recommended for development, I suppose
the recommendation no longer applies for this tree.

> But it looks like Konrad has pushed a master branch recently, as well.

That gives me a warm fuzzy, thanks.

Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER
http://groups.google.com/group/linux.kernel/t/0bc8f0bfd15b8d30?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 2:00 pm
From: Ian Campbell


On Thu, 2014-01-16 at 13:49 -0500, Jason Cooper wrote:
> > @Ian: Thanks for hunting this down, please keep bothering us with
> > bug reports :)
>
> Yes, please!

No worries there -- it seem Debian has quite a few people who use
kirkwood based systems and will report bugs when they find them...

Thanks (again?) for the quick fix.

Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
http://groups.google.com/group/linux.kernel/t/d9e917b55c72248e?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Jan 20 2014 2:00 pm
From: Dmitry Torokhov


Hi Benjamin,

On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires wrote:
> Evemu [1] uses uinput to replay devices traces it has recorded. However,
> the way evemu uses uinput is slightly different from how uinput is
> supposed to be used.
> Evemu relies on libevdev, which creates the device node through uinput.
> It then injects events through the input device node directly (and it
> completely skips the uinput node).
>
> Currently, libevdev relies on an heuristic to guess which input node was
> created. The problem is that is heuristic is subjected to races between
> different uinput devices or even with physical devices. Having a way
> to retrieve the sysfs path allows us to find the event node without
> having to rely on this heuristic.

I have been thinking about it and I think that providing tight coupling
between uinput and resulting event device is wrong thing to do. We do
allow sending input events through uinput interface and I think evemu
should be using it, instead of going halfway through uinput and halfway
though evdev. Replaying though uinput would actually be more correct as
it would involve the same code paths throgugh input core as with using
real devices (see input_event() vs. input_inject_event() that is used by
input handlers).

Thanks.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 4 ==
Date: Mon, Jan 20 2014 2:20 pm
From: Peter Hutterer


On Mon, Jan 20, 2014 at 01:53:13PM -0800, Dmitry Torokhov wrote:
> Hi Benjamin,
>
> On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires wrote:
> > Evemu [1] uses uinput to replay devices traces it has recorded. However,
> > the way evemu uses uinput is slightly different from how uinput is
> > supposed to be used.
> > Evemu relies on libevdev, which creates the device node through uinput.
> > It then injects events through the input device node directly (and it
> > completely skips the uinput node).
> >
> > Currently, libevdev relies on an heuristic to guess which input node was
> > created. The problem is that is heuristic is subjected to races between
> > different uinput devices or even with physical devices. Having a way
> > to retrieve the sysfs path allows us to find the event node without
> > having to rely on this heuristic.
>
> I have been thinking about it and I think that providing tight coupling
> between uinput and resulting event device is wrong thing to do. We do
> allow sending input events through uinput interface and I think evemu
> should be using it, instead of going halfway through uinput and halfway
> though evdev. Replaying though uinput would actually be more correct as
> it would involve the same code paths throgugh input core as with using
> real devices (see input_event() vs. input_inject_event() that is used by
> input handlers).

this isn't just about evemu. I've got a fair number of tests that create a
uinput device and then pass the device node to the next level. for example,
you may want to create a synaptics touchpad through uinput and then test the
xorg driver against it. I can't pass the uinput fd to the xorg driver, it
only takes a device node. in fact, virtually all the interactions I have
with uinput is of that form - create a device, hook something up to the
device and then do stuff. it's not the writing side that I need this ioctl
for, it's making sure whatever is _reading_ from it is hooked up to the
right device.

Cheers,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 3 of 4 ==
Date: Mon, Jan 20 2014 2:20 pm
From: Benjamin Tissoires


On Mon, Jan 20, 2014 at 4:53 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Benjamin,
>
> On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires wrote:
>> Evemu [1] uses uinput to replay devices traces it has recorded. However,
>> the way evemu uses uinput is slightly different from how uinput is
>> supposed to be used.
>> Evemu relies on libevdev, which creates the device node through uinput.
>> It then injects events through the input device node directly (and it
>> completely skips the uinput node).
>>
>> Currently, libevdev relies on an heuristic to guess which input node was
>> created. The problem is that is heuristic is subjected to races between
>> different uinput devices or even with physical devices. Having a way
>> to retrieve the sysfs path allows us to find the event node without
>> having to rely on this heuristic.
>
> I have been thinking about it and I think that providing tight coupling
> between uinput and resulting event device is wrong thing to do. We do
> allow sending input events through uinput interface and I think evemu
> should be using it, instead of going halfway through uinput and halfway
> though evdev. Replaying though uinput would actually be more correct as
> it would involve the same code paths throgugh input core as with using
> real devices (see input_event() vs. input_inject_event() that is used by
> input handlers).
>

Yes, I am perfectly aware of the fact that evemu is not using uinput
in the way it is intended to be.
I agree that it should be using the uinput node to inject events but
this means that only the process which has created the virtual device
can access it. It seems weird, I know, but the typical use of evemu is
the following:
- in a first terminal: $> sudo evemu-device mydevice.desc
- In a second: $> sudo evemu-play /dev/input/event12 < mydevice.events

It looks weird here, but it allows to inject different events
recording for the same virtual device node. Using the uinput node to
inject events will force us to change the user "interface" and rely on
pipes to get the same separation of describe/inject.
Note that I am modifying evemu-play to be able to also create the
virtual device, so I am not entirely convinced about this argument
(but we have users).

The other use case I should have mentioned in the commit message is
that we extensively rely on evemu for the xorg-integration-tests (and
the upcoming wayland test suite if I am not wrong).
The tests are fully automatized, and we need to know which input node
has just been created to record the correct one and test against it.


Ok, I am stopping here because Peter already answered about this in his mail :)

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 4 of 4 ==
Date: Mon, Jan 20 2014 3:00 pm
From: Peter Hutterer


On Mon, Jan 20, 2014 at 05:17:08PM -0500, Benjamin Tissoires wrote:
> On Mon, Jan 20, 2014 at 4:53 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > Hi Benjamin,
> >
> > On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires wrote:
> >> Evemu [1] uses uinput to replay devices traces it has recorded. However,
> >> the way evemu uses uinput is slightly different from how uinput is
> >> supposed to be used.
> >> Evemu relies on libevdev, which creates the device node through uinput.
> >> It then injects events through the input device node directly (and it
> >> completely skips the uinput node).
> >>
> >> Currently, libevdev relies on an heuristic to guess which input node was
> >> created. The problem is that is heuristic is subjected to races between
> >> different uinput devices or even with physical devices. Having a way
> >> to retrieve the sysfs path allows us to find the event node without
> >> having to rely on this heuristic.
> >
> > I have been thinking about it and I think that providing tight coupling
> > between uinput and resulting event device is wrong thing to do. We do
> > allow sending input events through uinput interface and I think evemu
> > should be using it, instead of going halfway through uinput and halfway
> > though evdev. Replaying though uinput would actually be more correct as
> > it would involve the same code paths throgugh input core as with using
> > real devices (see input_event() vs. input_inject_event() that is used by
> > input handlers).
> >
>
> Yes, I am perfectly aware of the fact that evemu is not using uinput
> in the way it is intended to be.
> I agree that it should be using the uinput node to inject events but
> this means that only the process which has created the virtual device
> can access it. It seems weird, I know, but the typical use of evemu is
> the following:
> - in a first terminal: $> sudo evemu-device mydevice.desc
> - In a second: $> sudo evemu-play /dev/input/event12 < mydevice.events
>
> It looks weird here, but it allows to inject different events
> recording for the same virtual device node.

it also allows replaying an event through the device it was recorded on.
it's not always necessary or desirable to create a uinput device, sometimes
replaying it through the actual device is better to reproduce a certain bug.

Cheers,
Peter



> Using the uinput node to
> inject events will force us to change the user "interface" and rely on
> pipes to get the same separation of describe/inject.
> Note that I am modifying evemu-play to be able to also create the
> virtual device, so I am not entirely convinced about this argument
> (but we have users).
>
> The other use case I should have mentioned in the commit message is
> that we extensively rely on evemu for the xorg-integration-tests (and
> the upcoming wayland test suite if I am not wrong).
> The tests are fully automatized, and we need to know which input node
> has just been created to record the correct one and test against it.
>
>
> Ok, I am stopping here because Peter already answered about this in his mail :)
>
> Cheers,
> Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Quirk Intel PCH root ports for ACS-like features
http://groups.google.com/group/linux.kernel/t/fb4c38bf865c1643?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 20 2014 2:10 pm
From: Alex Williamson


As described in 2/2 many Intel root ports lack PCIe ACS capabilities
which results in excessively large IOMMU groups. Many of these root
ports do provide isolation capabilities, we just need to use device
specific mechanisms to enable and verify. Long term, I hope we can
round out this list (particularly to include X79 root ports) and
more importantly, encourage proper PCIe ACS support in future
products. I'm really hoping we can get this in during the 3.14 cycle.
Thanks,

Alex

---

Alex Williamson (2):
pci: Add device specific PCI ACS enable
pci/quirks: Enable quirks for PCIe ACS on Intel PCH root ports


drivers/pci/pci.c | 26 +++++-
drivers/pci/quirks.c | 201 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 2
3 files changed, 223 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 3 ==
Date: Mon, Jan 20 2014 2:10 pm
From: Alex Williamson


Some devices support PCI ACS-like features, but don't report it using
the standard PCIe capabilities. We already provide hooks for device
specific testing of ACS, but not for device specific enabling of ACS.
This provides that setup hook.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
drivers/pci/pci.c | 26 ++++++++++++++++++++------
drivers/pci/quirks.c | 25 +++++++++++++++++++++++++
include/linux/pci.h | 2 ++
3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 07369f3..a57ff7f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2357,21 +2357,18 @@ void pci_request_acs(void)
}

/**
- * pci_enable_acs - enable ACS if hardware support it
+ * pci_std_enable_acs - enable ACS on devices using standard ACS capabilites
* @dev: the PCI device
*/
-void pci_enable_acs(struct pci_dev *dev)
+static int pci_std_enable_acs(struct pci_dev *dev)
{
int pos;
u16 cap;
u16 ctrl;

- if (!pci_acs_enable)
- return;
-
pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS);
if (!pos)
- return;
+ return -ENODEV;

pci_read_config_word(dev, pos + PCI_ACS_CAP, &cap);
pci_read_config_word(dev, pos + PCI_ACS_CTRL, &ctrl);
@@ -2389,6 +2386,23 @@ void pci_enable_acs(struct pci_dev *dev)
ctrl |= (cap & PCI_ACS_UF);

pci_write_config_word(dev, pos + PCI_ACS_CTRL, ctrl);
+
+ return 0;
+}
+
+/**
+ * pci_enable_acs - enable ACS if hardware support it
+ * @dev: the PCI device
+ */
+void pci_enable_acs(struct pci_dev *dev)
+{
+ if (!pci_acs_enable)
+ return;
+
+ if (!pci_std_enable_acs(dev))
+ return;
+
+ pci_dev_specific_enable_acs(dev);
}

static bool pci_acs_flags_enabled(struct pci_dev *pdev, u16 acs_flags)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 3a02717..4be1cd5 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3461,3 +3461,28 @@ int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags)

return -ENOTTY;
}
+
+static const struct pci_dev_enable_acs {
+ u16 vendor;
+ u16 device;
+ int (*enable_acs)(struct pci_dev *dev);
+} pci_dev_enable_acs[] = {
+ { 0 }
+};
+
+void pci_dev_specific_enable_acs(struct pci_dev *dev)
+{
+ const struct pci_dev_enable_acs *i;
+ int ret;
+
+ for (i = pci_dev_enable_acs; i->enable_acs; i++) {
+ if ((i->vendor == dev->vendor ||
+ i->vendor == (u16)PCI_ANY_ID) &&
+ (i->device == dev->device ||
+ i->device == (u16)PCI_ANY_ID)) {
+ ret = i->enable_acs(dev);
+ if (ret >= 0)
+ return;
+ }
+ }
+}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a13d682..7905fd8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1633,6 +1633,7 @@ enum pci_fixup_pass {
void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
struct pci_dev *pci_get_dma_source(struct pci_dev *dev);
int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
+void pci_dev_specific_enable_acs(struct pci_dev *dev);
#else
static inline void pci_fixup_device(enum pci_fixup_pass pass,
struct pci_dev *dev) {}
@@ -1645,6 +1646,7 @@ static inline int pci_dev_specific_acs_enabled(struct pci_dev *dev,
{
return -ENOTTY;
}
+static inline void pci_dev_specific_enable_acs(struct pci_dev *dev) {}