On 12/18/2017 6:26 AM, Christoph Hellwig wrote:
On Fri, Dec 15, 2017 at 12:18:02PM -0600, Bjorn Helgaas wrote:
I think Christoph volunteered to do some restructuring, but I don't
know his timeframe. If you can, I would probably wait for that
because there's so much overlap here.
I'll have so
Thanks Bjorn for your response. Please see below for my comments.
So, we should consider one of these options.
- set PCI_DEV_FLAGS_NO_FLR_RESET if it is not supported.
- pcie_flr() should return if it is not supported
If we modify pcie_flr() to return error codes, then we need to modify
all ex
Jan,
One quick update on pcie_flr() specific implementation. Please see below.
+static int pcistub_device_reset(struct pci_dev *dev)
+{
+ struct xen_pcibk_dev_data *dev_data;
+ bool slot = false, bus = false;
+ struct pcistub_args arg = {};
+
+ if (!dev)
+ r
Thanks Bjorn and Christophfor your response. Please see below for my
comments.
On 12/13/2017 3:24 PM, Bjorn Helgaas wrote:
[+cc Christoph]
On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote:
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev)
{
u32 cap;
@@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev)
pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &cap);
return cap & PCI_EXP_DEVCAP_FLR;
}
+EXPORT_SYMB
On 12/12/2017 9:01 AM, Jan Beulich wrote:
On 12.12.17 at 15:48, wrote:
Thanks Jan for your review comments. Please see below for my comments.
First of all - can you please do something about your reply style?
HTML mail should be avoided. You'll see that the (plain text) reply
as a result is
Thanks Jan for your review comments. Please see below for my comments.
On 12/8/2017 3:34 AM, Jan Beulich wrote:
On 07.12.17 at 23:21, wrote:
Due to the complexity with the PCI lock we cannot do the reset when a
device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind')
as the
Thanks Bjorn for your review comments. Please see below for my comments.
On 12/8/2017 2:24 PM, Bjorn Helgaas wrote:
On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS
attribute.
Signed-off-by: Govinda Tatti
---
v3: -New
drivers/pci/pci.c | 3 ++-
include/linux/pci.h | 1 +
2 files changed, 3 insertions(+),
to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Boris Ostrovsky
---
v1: - First posting
v2: - struct pcist
This patch contains Xen pciback driver changes to support PCI reset
(flr/slot/bus) based on SysFS 'reset' attribute. The following Xen
libxl patch depends on these kernel patches.
- Xen/libxl: Perform PCI reset using 'reset' SysFS attribute
Govinda Tatti (2):
Drivers/PCI:
Jan,
Do you have any further comments on the current version of this patch?.
Otherwise, I will work on the review comments and publish next version
of this patch later this week. Please let me know. Thanks.
Cheers
GOVINDA
On 12/1/2017 10:16 AM, Govinda Tatti wrote:
On 11/30/2017 8:46 AM
On 11/30/2017 8:46 AM, Jan Beulich wrote:
On 30.11.17 at 15:15, wrote:
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device.
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed irrespective of type of rese
On 11/30/2017 2:29 AM, Jan Beulich wrote:
On 29.11.17 at 20:44, wrote:
So, we will use the following sequence to reset the requested
device/function.
- FLR (as first option)
- BUS/SLOT reset (as fall-back option) if FLR is not supported or any
issue with FLR
It looks to me as if the slot re
On 11/29/2017 12:05 PM, Pasi Kärkkäinen wrote:
On Wed, Nov 29, 2017 at 11:25:09AM -0600, Govinda Tatti wrote:
Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
Thanks Konrad for your response. Please see below for my comments.
Well, that's more a question to Konrad as the maintainer.
Personally I'd prefer just "reset", as "pci" is redundant and "bus"
Can't do 'reset'.
Why?
B/c I forgot that this attribute is not per device, but on the module
sub-di
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed irrespective of type of reset being used.
I don't follow: The scope of other devices/functions possi
Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
tried FLR first, only falling back to the other methods as "emulation",
I could certainly agree with the file name chose
Jan,
Please see below for my comments.
On 11/9/2017 2:49 AM, Jan Beulich wrote:
On 09.11.17 at 00:06, wrote:
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -244,6 +244,91 @@ struct pci_dev *pcistub_get_pci_dev(struct
xen_pcibk_device *pdev,
retur
Jan,
Sorry for the late response. Please see below for my comments.
On 11/9/2017 2:28 AM, Jan Beulich wrote:
On 08.11.17 at 16:44, wrote:
On 11/7/2017 8:40 AM, Jan Beulich wrote:
On 06.11.17 at 18:48, wrote:
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testi
Thanks Pasi for your response. Please see below for my comments.
On 11/8/2017 11:38 AM, Pasi Kärkkäinen wrote:
Hi,
On Wed, Nov 08, 2017 at 09:44:48AM -0600, Govinda Tatti wrote:
Thanks Jan for your review comments. Please see below for my comments.
On 11/7/2017 8:40 AM, Jan Beulich wrote
ces that are in
use by other drivers (other than Xen pciback) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti
Signed-off-by: Konrad Rzeszutek Wilk
Reviewe
Thanks Jan for your review comments. Please see below for my comments.
On 11/7/2017 8:40 AM, Jan Beulich wrote:
On 06.11.17 at 18:48, wrote:
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
On 11/8/2017 9:09 AM, Juergen Gross wrote:
On 08/11/17 16:00, Govinda Tatti wrote:
Thanks Roger for your review comments. Please see below for my comments.
On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
+out:
+ if (!err
Thanks Roger for your review comments. Please see below for my comments.
On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism
ces that are in
use by other drivers (other than Xen pciback) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti
Signed-off-by: Konrad Rzeszutek Wilk
Reviewe
27 matches
Mail list logo
