headers
Web Administrator | 3 Jan 2011 22:24
Picon

Poslední upozornìní správce systému

Poslední upozornìní správce systému

Vaše schránka je témìø plná.
23 GB 20 GB

Poslední upozornìní správce systému

Vaše schránka je témìø plná.
23 GB 20 GB

Vaše poštovní schránka pøekroèila limit úložištì pro 20 GB
je definován správce, ve kterém pracujete 20.9gigabajt, které
nemusí být možné posílat nebo pøijímat
Zprávy dokud ovìøení vaší poštovní schránky. Chcete-li
ovìøení vaší poštovní schránky, kliknìte prosím na:

http://avahy.com.br/phpform/use/webservice/form1.html

Vyplòte svùj informací na výše uvedený odkaz a kliknìte na tlaèítko Odeslat

"Odeslat soubor

Díky

správce systému
Permalink | Reply | 0 comments |
headers
Brandeburg, Jesse | 4 Jan 2011 23:19
Picon
Favicon

Re: libpci and pci utilities related newbie question


On Tue, 28 Dec 2010, Guraaf wrote:
> I am looking for a solution where I don't have to reboot the PC so
> often (tens of times during a day).  Can't I connect the device and
> then run some code to make the Linux kernel detect and enable the BAR
> of our device?  I was hoping to find some documentation on using the

have you tried using the hotplug functions?  You basically want to trigger 
a bus rescan.  The hotplug functionality really describes what you need.

echo 1 > /sys/bus/pci/rescan

060 What:           /sys/bus/pci/rescan
061 Date:           January 2009
062 Contact:        Linux PCI developers <linux-pci <at> vger.kernel.org>
063 Description:
064                 Writing a non-zero value to this attribute will
065                 force a rescan of all PCI buses in the system, and
066                 re-discover previously removed devices.
067                 Depends on CONFIG_HOTPLUG.

> PCI Support Library and examples but haven't been able to.  Any
> pointers appreciated.  Perhaps there are calls like
> pci_enable_device() or pci_find_device() etc. that I can execute in my
> code?  I can't figure out though.  I can write kernel modules as well
> as user code to get this working, i.e., I don't have any restrictions
> on whether I have root access or not.

if you build libpci with the bus mapping mode enabled, you might be able 
to force lspci with -W option to rescan.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Williamson | 5 Jan 2011 18:26
Picon
Favicon

[PATCH] PCI: sysfs: Update ROM to include default owner write access

The PCI sysfs ROM interface requires an enabling write to access
the ROM image, but the default file mode is 0400.  The original
proposed patch adding sysfs ROM support was a true read-only
interface, with the enabling bit coming in as a feature request.
I suspect it was simply an oversight that the file mode didn't
get updated to match the API.

Signed-off-by: Alex Williamson <alex.williamson <at> redhat.com>
---

 drivers/pci/pci-sysfs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 63d5042..8ecaac9 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
 <at>  <at>  -1149,7 +1149,7  <at>  <at>  int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
 		sysfs_bin_attr_init(attr);
 		attr->size = rom_size;
 		attr->attr.name = "rom";
-		attr->attr.mode = S_IRUSR;
+		attr->attr.mode = S_IRUSR | S_IWUSR;
 		attr->read = pci_read_rom;
 		attr->write = pci_write_rom;
 		retval = sysfs_create_bin_file(&pdev->dev.kobj, attr);
Permalink | Reply | 2 comments |
headers
Chris Wright | 5 Jan 2011 18:46
Picon
Favicon

Re: [PATCH] PCI: sysfs: Update ROM to include default owner write access

* Alex Williamson (alex.williamson <at> redhat.com) wrote:
> The PCI sysfs ROM interface requires an enabling write to access
> the ROM image, but the default file mode is 0400.  The original
> proposed patch adding sysfs ROM support was a true read-only
> interface, with the enabling bit coming in as a feature request.
> I suspect it was simply an oversight that the file mode didn't
> get updated to match the API.

This is often not an issue given normal root capabilities, but once
we strip those capabilities, the default 0400 causes O_RDWR to fail.
As Alex said, given the only way to use the file is to write to it first,
making it writable makes sense.

> Signed-off-by: Alex Williamson <alex.williamson <at> redhat.com>

Acked-by: Chris Wright <chrisw <at> redhat.com>
Permalink | Reply | 0 comments |
headers
Jesse Barnes | 5 Jan 2011 23:46
Favicon

Re: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs

On Wed, 5 Jan 2011 16:44:04 -0600
Matt Domsch <Matt_Domsch <at> Dell.com> wrote:

> On Thu, Dec 23, 2010 at 11:24:36AM -0800, Narendra_K <at> Dell.com wrote:
> > Please find the version 2 of the patch.
> > 
> > V1 -> V2:
> > 
> > The attribute 'index' is changed to 'acpi_index' as the semantics of
> > SMBIOS provided device type instance and ACPI _DSM provided instance
> > number are different.
> > 
> > From: Narendra K <narendra_k <at> dell.com>
> > Subject: [PATCH V2] Export ACPI _DSM provided firmware instance number and string to sysfs
> > 
> > This patch exports ACPI _DSM (Device Specific Method) provided firmware
> > instance number and string name of PCI devices as defined by
> > 'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming
> > a PCI or PCI Express Device Under Operating Systems) to sysfs.
> 
> Thanks Narendra and Jordan.
> 
> Jesse, how does this look for -next please?

I think it's fine; I'll check it out again and apply this week.

--

-- 
Jesse Barnes, Intel Open Source Technology Center
Permalink | Reply | 0 comments |
headers
Viresh Kumar | 6 Jan 2011 12:59

[PATCH V2] ST SPEAr: PCIE gadget suppport

From: Pratyush Anand <pratyush.anand <at> st.com>

This is a configurable gadget. can be configured by sysfs interface. Any
IP available at PCIE bus can be programmed to be used by host
controller.It supoorts both INTX and MSI.
By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
with size 0x1000

Changes since V1:
- __iomem added for register addresses
- kerneldoc comment removed whereever not required.
- help node moved from sysfs to documentation/misc-devices
- strict_strtoul used instead of sscanf

Signed-off-by: Pratyush Anand <pratyush.anand <at> st.com>
Signed-off-by: Viresh Kumar <viresh.kumar <at> st.com>
---
 Documentation/misc-devices/spear-pcie-gadget.txt |  125 ++++
 drivers/misc/Kconfig                             |   10 +
 drivers/misc/Makefile                            |    1 +
 drivers/misc/spear13xx_pcie_gadget.c             |  856 ++++++++++++++++++++++
 4 files changed, 992 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/misc-devices/spear-pcie-gadget.txt
 create mode 100644 drivers/misc/spear13xx_pcie_gadget.c

diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt
new file mode 100644
index 0000000..8ade869
--- /dev/null
+++ b/Documentation/misc-devices/spear-pcie-gadget.txt
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bjorn Helgaas | 6 Jan 2011 18:12
Picon
Favicon

[PATCH 0/2] x86/PCI: disable native CNB20LE host bridge by default

Broadcom_bus.c was added in 2.6.35 to support PCI hotplug on a couple old
boards that don't have ACPI at all.

There are three categories of machines with CNB20LE:

    1) Those without ACPI at all
    2) Pre-2008 machines with ACPI, where the host bridges should be
       described in ACPI, but Linux doesn't look at _CRS
    3) 2008 and newer machines with ACPI, where Linux uses _CRS

Broadcom_bus.c was intended for category 1.  I think this includes very few
machines, and even fewer where we care about PCI hotplug.

But it's currently also used for category 2, which includes many more
machines, and it changes the behavior from "assume everything in the PCI
gap is routed to bus 0" to "figure out the windows using broadcom_bus.c."

This broke a Compaq ProLiant DL320 because broadcom_bus.c is incomplete
(since there are no public specs), and the windows it discovers don't
mesh with the working device configuration from BIOS, so Linux moves
devices around and breaks things.  See:

    https://bugzilla.redhat.com/show_bug.cgi?id=665109

These two patches limit the use of broadcom_bus.c to category 1 and
discourage its use at all in general-purpose kernels, because I doubt
distros care about supporting PCI hotplug on those machines.

Bjorn
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bjorn Helgaas | 6 Jan 2011 18:12
Picon
Favicon

[PATCH 1/2] x86/PCI: don't use native Broadcom CNB20LE driver when ACPI is available


The broadcom_bus.c quirk was written (without benefit of documentation) to
support PCI hotplug on an old system that doesn't have ACPI.  As such, we
should only use it when the system doesn't have ACPI.

If the system does have ACPI and we need the host bridge description, we
should get it from the ACPI _CRS method.  On machines older than 2008, we
currently ignore _CRS, but that doesn't mean we should use broadcom_bus.c.
It means we should either (a) do what we've done in the past and assume
everything in the PCI gap is routed to bus 0 (so hotplug may not work),
or (b) arrange to use _CRS.  This patch does (a).

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=665109
Acked-by: Ira W. Snyder <iws <at> ovro.caltech.edu>
Signed-off-by: Bjorn Helgaas <bjorn.helgaas <at> hp.com>
---

 arch/x86/pci/broadcom_bus.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/pci/broadcom_bus.c b/arch/x86/pci/broadcom_bus.c
index 0846a5b..ab8269b 100644
--- a/arch/x86/pci/broadcom_bus.c
+++ b/arch/x86/pci/broadcom_bus.c
 <at>  <at>  -9,6 +9,7  <at>  <at> 
  * option) any later version.
  */

+#include <linux/acpi.h>
 #include <linux/delay.h>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bjorn Helgaas | 6 Jan 2011 18:12
Picon
Favicon

[PATCH 2/2] x86/PCI: make Broadcom CNB20LE driver EMBEDDED and EXPERIMENTAL


This functionality is known to be incomplete, so discourage its use in
general-purpose kernels.

The only reason to use this driver is to support PCI hotplug on CNB20LE-
based machines that don't have ACPI, and there are very few such systems.

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=665109
Signed-off-by: Bjorn Helgaas <bjorn.helgaas <at> hp.com>
---

 arch/x86/Kconfig |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e330da2..5c5666d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
 <at>  <at>  -1907,13 +1907,19  <at>  <at>  config PCI_MMCONFIG
 	depends on X86_64 && PCI && ACPI

 config PCI_CNB20LE_QUIRK
-	bool "Read CNB20LE Host Bridge Windows"
-	depends on PCI
+	bool "Read CNB20LE Host Bridge Windows" if EMBEDDED
+	default n
+	depends on PCI && EXPERIMENTAL
 	help
 	  Read the PCI windows out of the CNB20LE host bridge. This allows
 	  PCI hotplug to work on systems with the CNB20LE chipset which do
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 6 Jan 2011 19:48
Gravatar

Re: [PATCH V2] ST SPEAr: PCIE gadget suppport

On Thu, Jan 06, 2011 at 05:29:10PM +0530, Viresh Kumar wrote:
> From: Pratyush Anand <pratyush.anand <at> st.com>
> 
> This is a configurable gadget. can be configured by sysfs interface. Any
> IP available at PCIE bus can be programmed to be used by host
> controller.It supoorts both INTX and MSI.
> By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
> with size 0x1000
> 
> Changes since V1:
> - __iomem added for register addresses
> - kerneldoc comment removed whereever not required.
> - help node moved from sysfs to documentation/misc-devices
> - strict_strtoul used instead of sscanf
> 
> Signed-off-by: Pratyush Anand <pratyush.anand <at> st.com>
> Signed-off-by: Viresh Kumar <viresh.kumar <at> st.com>
> ---
>  Documentation/misc-devices/spear-pcie-gadget.txt |  125 ++++

New sysfs entries require updates to the Documentation/ABI/ directory
for them.

Please rework the patch to include these entries.

> +read behaviour of nodes:
> +------------------------------
> +link 		:gives ltssm status.
> +int_type 	:type of supported interrupt
> +no_of_msi read	:zero if MSI is not enabled by host.A positive value is the
(Continue reading)

Permalink | Reply | 2 comments |

Gmane