headers
Frank Pan | 1 Jun 2010 07:05
Picon
Gravatar

Add a helper function in PCI IOV to get VF device

Greetings,

The motivation is make VF device visible to PF driver. PF driver
may need this to access VF's PCI configuration.
Another use case is in sysfs symbolic linking. Some of VF's sysfs
entries are created by PF driver. For example, /sys/class/net/ethx/vfx
in Intel 82576 NIC driver. Makeing a symbolic link from VF's pci device
to this path also must be done in PF's driver.

Currently, there is no hint about VF's bus/devfn in PF's pci_dev.
The offset and stride entries(which are used to calculate bus/devfn
of VF devices) in VF's PCI configuration is also invisible in PF's
driver. So IMO this helper function is needed.

Any reply is appreciated, THX.

(ps: gmail will do line wrap/tab replace, use attachment instead to patch)

--
Frank Pan

Computer Science and Technology
Tsinghua University

Signed-off-by: Frank Pan <frankpzh <at> gmail.com>
---
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ce6a366..f15aa2a 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
(Continue reading)

Permalink | Reply | 15 comments |
headers
John W. Linville | 1 Jun 2010 15:34
Favicon

Re: [Regression] [2.6.35-rc1] ssb_is_sprom_available

On Mon, May 31, 2010 at 02:53:00PM -0600, Matthew Wilcox wrote:
> On Mon, May 31, 2010 at 09:55:20PM +0200, Maciej Rutecki wrote:
> > Last known good: 2.6.34
> > Failing kernel: 2.6.35-rc1
> > 
> > subsystem: PCI, USB(?)
> > 
> > Kernel dies during booting on message "ssb_is_sprom_available", see picture:
> > http://www.unixy.pl/maciek/download/kernel/2.6.35-rc1/gumis/DSC_0011.JPG
> 
> Um, looks like it's something to do with the Sonics Silicon Backplane,
> not PCI, nor USB.

Fix is on its way...

commit da1fdb02d9200ff28b6f3a380d21930335fe5429
Author: Christoph Fritz <chf.fritz <at> googlemail.com>
Date:   Fri May 28 10:45:59 2010 +0200

    ssb: fix NULL ptr deref when pcihost_wrapper is used

    Ethernet driver b44 does register ssb by it's pcihost_wrapper
    and doesn't set ssb_chipcommon. A check on this value
    introduced with commit d53cdbb94a52a920d5420ed64d986c3523a56743
    and ea2db495f92ad2cf3301623e60cb95b4062bc484 triggers:

    BUG: unable to handle kernel NULL pointer dereference at 00000010
    IP: [<c1266c36>] ssb_is_sprom_available+0x16/0x30

    Signed-off-by: Christoph Fritz <chf.fritz <at> googlemail.com>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Stern | 1 Jun 2010 16:59
Picon
Favicon

Re: Runtime PM for PCI-based USB host controllers

On Wed, 26 May 2010, Matthew Garrett wrote:

> On Wed, May 26, 2010 at 12:56:33PM -0400, Alan Stern wrote:
> 
> > I don't know how that works.  However an easy approach would be to make
> > opening the device file (or however the userspace driver gets a
> > reference to the device) cause the core to do a pm_runtime_get_sync(),
> > with a corresponding pm_runtime_put_sync() when the file is closed.
> 
> No, X is far worse than you think. It's handled by mmap()ping /dev/mem.

Can we rely on the forbid/allow mechanism?  If userspace never allows 
runtime suspend for devices like the video controller then there's no 
problem.  Conversely, if a PCI device really doesn't have a driver and 
isn't used for anything, then by default it should go into a lower 
power state if userspace allows this.

I admit this is a slightly brittle solution, in that it depends on 
userspace not doing the wrong thing.  But the default (runtime PM 
forbidden) is always safe.

Alan Stern
Permalink | Reply | 14 comments |
headers
Matthew Garrett | 1 Jun 2010 17:06
Favicon

Re: Runtime PM for PCI-based USB host controllers

On Tue, Jun 01, 2010 at 10:59:17AM -0400, Alan Stern wrote:

> Can we rely on the forbid/allow mechanism?  If userspace never allows 
> runtime suspend for devices like the video controller then there's no 
> problem.  Conversely, if a PCI device really doesn't have a driver and 
> isn't used for anything, then by default it should go into a lower 
> power state if userspace allows this.

I think that's safe, yes. Other fringe concerns include things like 
smbus controllers - we typically won't allow a driver to bind to them 
because they're used by ACPI, so putting the in D3 is also an error. So 
I think Rafael's right in that we should default to forbid unless a 
driver knows that it's safe, and let userspace override us.

--

-- 
Matthew Garrett | mjg59 <at> srcf.ucam.org
Permalink | Reply | 12 comments |
headers
Stephen Hemminger | 1 Jun 2010 18:00
Favicon

[PATCH] pci: sparse warning (trivial)

Assigning zero where NULL should be used.

Signed-off-by: Stephen Hemminger <shemminger <at> vyatta.com>

--- a/drivers/pci/bus.c	2010-06-01 08:51:28.361314729 -0700
+++ b/drivers/pci/bus.c	2010-06-01 08:51:36.769714125 -0700
 <at>  <at>  -56,7 +56,7  <at>  <at>  void pci_bus_remove_resources(struct pci
 	int i;

 	for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++)
-		bus->resource[i] = 0;
+		bus->resource[i] = NULL;

 	list_for_each_entry_safe(bus_res, tmp, &bus->resources, list) {
 		list_del(&bus_res->list);
Permalink | Reply | 1 comment |
headers
Alan Stern | 1 Jun 2010 19:25
Picon
Favicon

Re: Runtime PM for PCI-based USB host controllers

On Tue, 1 Jun 2010, Matthew Garrett wrote:

> On Tue, Jun 01, 2010 at 10:59:17AM -0400, Alan Stern wrote:
> 
> > Can we rely on the forbid/allow mechanism?  If userspace never allows 
> > runtime suspend for devices like the video controller then there's no 
> > problem.  Conversely, if a PCI device really doesn't have a driver and 
> > isn't used for anything, then by default it should go into a lower 
> > power state if userspace allows this.
> 
> I think that's safe, yes. Other fringe concerns include things like 
> smbus controllers - we typically won't allow a driver to bind to them 
> because they're used by ACPI, so putting the in D3 is also an error. So 
> I think Rafael's right in that we should default to forbid unless a 
> driver knows that it's safe, and let userspace override us.

Therefore the default state for unbound PCI devices should be
runtime-PM-enabled.  Devices will be put in a low-power state if
userspace allows.  Also, the PCI core should make sure that devices are
active when drivers' probe and release methods are called.

If a driver doesn't want to use runtime PM then not doing anything at 
all should leave the device with a positive usage count.  If it does 
want to use runtime PM then a pm_runtime_put_sync() during probe and 
pm_runtime_get_sync() during release will take care of everything.

Something like the patch below, awkward though it is.  Does this look 
reasonable?

Alan Stern
(Continue reading)

Permalink | Reply | 10 comments |
headers
klink | 1 Jun 2010 19:12
Favicon

howto map pci device registers to user space

All:

I'm trying again to get mmapping working from user space to a cards 
device registers.
The platform is X86, linux 2.6.18 .

Under linux 2.4, the following code snippet was able to map 1 page of 
PLX register
and 1 page of card registers:
-----
bus_adr = pCrd->pPciDevInfo->resource[ bar_nmbr ].start;
bus_adr &= PCI_BASE_ADDRESS_MEM_MASK;
page_adr = bus_adr &  (PAGE_MASK);
offset   = bus_adr & ~(PAGE_MASK);
vma->vm_flags |= VM_IO | VM_RESERVED ;

prot = pgprot_noncached(__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | 
_PAGE_GLOBAL) );
vma->vm_page_prot = prot ;

rtv = remap_page_range(vma->vm_start, page_adr, length, vma->vm_page_prot);

vma->vm_start += offset;
-----

Under linux 2.6.18, documentation indicates remap_pfn_range() is the 
routine to use.
Indeed, this works for kmallocd() pages.  However for device registers 
it is unclear
as to which pfn ( presumably the pfn for the bus adrs ... like the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg KH | 1 Jun 2010 20:39
Gravatar

Re: Add a helper function in PCI IOV to get VF device

On Tue, Jun 01, 2010 at 01:05:25PM +0800, Frank Pan wrote:
> Greetings,
> 
> The motivation is make VF device visible to PF driver. PF driver
> may need this to access VF's PCI configuration.

What is "VF" and "PF" here?

> Another use case is in sysfs symbolic linking. Some of VF's sysfs
> entries are created by PF driver. For example, /sys/class/net/ethx/vfx
> in Intel 82576 NIC driver. Makeing a symbolic link from VF's pci device
> to this path also must be done in PF's driver.

No, the network core should create that symlink, not the driver, right?

thanks,

greg k-h
Permalink | Reply | 11 comments |
headers
Yinghai Lu | 1 Jun 2010 20:49
Picon
Favicon

[RFC PATCH] pciehp: only wait command complete for real command

Found one system with PCIe Modules keep saying "Command not completed in 1000 msec"
when pciehp initialized, and hot-add and hot-remove.

According to our HW engineer Jason Timpe, Command Completed bit is set iff those
real commands are issued. Because those command that are with VPP are going through
i2c to vpp.

So try to check that before we decide to wait those command completion.

Signed-off-by: Yinghai Lu <yinghai <at> kernel.org>

---
 drivers/pci/hotplug/pciehp_hpc.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Index: linux-2.6/drivers/pci/hotplug/pciehp_hpc.c
===================================================================
--- linux-2.6.orig/drivers/pci/hotplug/pciehp_hpc.c
+++ linux-2.6/drivers/pci/hotplug/pciehp_hpc.c
 <at>  <at>  -176,6 +176,7  <at>  <at>  static int pcie_write_cmd(struct control
 	int retval = 0;
 	u16 slot_status;
 	u16 slot_ctrl;
+	u16 wait_mask;

 	mutex_lock(&ctrl->ctrl_lock);

 <at>  <at>  -215,9 +216,14  <at>  <at>  static int pcie_write_cmd(struct control
 		goto out;
 	}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Williams, Mitch A | 1 Jun 2010 20:57
Picon
Favicon

RE: Add a helper function in PCI IOV to get VF device

>-----Original Message-----
>From: Greg KH [mailto:greg <at> kroah.com]
>Sent: Tuesday, June 01, 2010 11:39 AM

>
>On Tue, Jun 01, 2010 at 01:05:25PM +0800, Frank Pan wrote:
>> Greetings,
>>
>> The motivation is make VF device visible to PF driver. PF driver
>> may need this to access VF's PCI configuration.
>
>What is "VF" and "PF" here?
>
>> Another use case is in sysfs symbolic linking. Some of VF's sysfs
>> entries are created by PF driver. For example, /sys/class/net/ethx/vfx
>> in Intel 82576 NIC driver. Makeing a symbolic link from VF's pci device
>> to this path also must be done in PF's driver.
>
>No, the network core should create that symlink, not the driver, right?
>
>thanks,
>
>greg k-h

Furthermore, the links are already there in sysfs, created by the PCI subsystem. 

/sys/class/net/ethX/device links to the PCI device entry for the PF device, which itself has symlinks to
each of the VF devices.

This patch just isn't necessary.
(Continue reading)

Permalink | Reply | 9 comments |

Gmane