On 9/10/2018 5:52 AM, Pasi Kärkkäinen wrote:
Hi,
On Sun, Sep 09, 2018 at 10:33:02PM -0400, Sinan Kaya wrote:
On 9/9/2018 2:59 PM, Pasi Kärkkäinen wrote:
I noticed pcie_has_flr() has been recently exported in upstream Linux:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
Hi,
On Sun, Sep 09, 2018 at 10:33:02PM -0400, Sinan Kaya wrote:
> On 9/9/2018 2:59 PM, Pasi Kärkkäinen wrote:
> >I noticed pcie_has_flr() has been recently exported in upstream Linux:
> >https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d2917f7747805a1f4188672f308d82a8
On 9/9/2018 2:59 PM, Pasi Kärkkäinen wrote:
I noticed pcie_has_flr() has been recently exported in upstream Linux:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d2917f7747805a1f4188672f308d82a8ba01700
Are there more changes / cleanups planned to these interfaces,
On Mon, Dec 18, 2017 at 04:26:30AM -0800, 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
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
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 some time over the holidays. If you need it more
On 16/12/17 05:18, Bjorn Helgaas wrote:
> [+cc Russell, Sinan, Herbert, Srikanth, Derek, Satanand, Felix, Raghu]
>
> On Fri, Dec 15, 2017 at 09:48:02AM -0600, Govinda Tatti wrote:
>> On 12/13/2017 3:24 PM, Bjorn Helgaas wrote:
>>> On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote:
>
>
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
[+cc Russell, Sinan, Herbert, Srikanth, Derek, Satanand, Felix, Raghu]
On Fri, Dec 15, 2017 at 09:48:02AM -0600, Govinda Tatti wrote:
> On 12/13/2017 3:24 PM, Bjorn Helgaas wrote:
> >On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote:
> >>-static bool pcie_has_flr(struct pci_dev *d
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)
On Thu, Dec 14, 2017 at 04:52:06AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 13, 2017 at 03:24:21PM -0600, Bjorn Helgaas wrote:
> > Prior to a60a2b73ba69, we had
> >
> > int pcie_flr(struct pci_dev *dev, int probe);
> >
> > like all the other reset methods. AFAICT, the addition of
> > pcie
On Wed, Dec 13, 2017 at 03:24:21PM -0600, Bjorn Helgaas wrote:
> Prior to a60a2b73ba69, we had
>
> int pcie_flr(struct pci_dev *dev, int probe);
>
> like all the other reset methods. AFAICT, the addition of
> pcie_has_flr() was to optimize the path slightly because when drivers
> call pcie_flr
[+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)
> {
> u32 cap;
> @@ -3882,6 +3882,7 @@ static 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 Fri, Dec 08, 2017 at 02:24:24PM -0600, Bjorn Helgaas wrote:
> I'd rather change pcie_flr() so you could *always* call it, and it
> would return 0, -ENOTTY, or whatever, based on whether FLR is
> supported. Is that feasible?
>
> I don't like the "Can I do this? Ok, do this" style of interfaces.
On Mon, Dec 11, 2017 at 06:29:29PM -0600, Govinda Tatti wrote:
>
> 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
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 ba
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 based on 'reset' SysFS
> attribute.
>
> Signed-off-by: Govinda Tatti
> ---
> v3: -New
>
> drivers/pci/pci.c | 3 +
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(+), 1 deletion(-)
d
19 matches
Mail list logo
