It seems that hrtimer_run_queues() is calling hrtimer_get_softirq_time() more
often than it needs to. This can cause frequent contention on systems with
large numbers of processors/cores.
With this patch, hrtimer_run_queues only calls hrtimer_get_softirq_time() if
there is a pending timer in one of the hrtimer bases, and only once.
This also combines hrtimer_run_queues() and the inline run_hrtimer_queue()
into one function.
[ tglx@linutronix.de: coding style ]
Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
braodcast -> broadcast
Signed-off-by: Glauber Costa <gcosta@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Most of time_after like macros usages just compare jiffies and another number,
so here add some time_is_* macros for convenience.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Jesse foolishly volunteered to handle PCI patches. Update MAINTAINERS to
reflect this.
Woho! Time to kick back and relax...
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following patch is an update to use an array instead of a list of
IOVA's in the implementation of defered iotlb flushes. It takes
inspiration from sba_iommu.c
I like this implementation better as it encapsulates the batch process
within intel-iommu.c, and no longer touches iova.h (which is shared)
Performance data: Netperf 32byte UDP streaming
2.6.25-rc3-mm1:
IOMMU-strict : 58Mps @ 62% cpu
NO-IOMMU : 71Mbs @ 41% cpu
List-based IOMMU-default-batched-IOTLB flush: 66Mbps @ 57% cpu
with this patch:
IOMMU-strict : 73Mps @ 75% cpu
NO-IOMMU : 74Mbs @ 42% cpu
Array-based IOMMU-default-batched-IOTLB flush: 72Mbps @ 62% cpu
Signed-off-by: <mgross@linux.intel.com>
Cc: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
WARNING: drivers/pci/built-in.o(.text+0x28ee9): Section mismatch in reference from the function pci_bus_assign_resources() to the function .devinit.text:pci_setup_bridge()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
WARNING: drivers/pci/built-in.o(.text+0x28e1f): Section mismatch in reference from the function pci_bus_size_bridges() to the function .devinit.text:pci_bus_size_cardbus()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
WARNING: drivers/pci/built-in.o(.text+0x150f): Section mismatch in reference from the function pci_scan_single_device() to the function .devinit.text:pci_scan_device()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
WARNING: drivers/pci/built-in.o(.text+0xc4c): Section mismatch in reference from the function pci_add_new_bus() to the function .devinit.text:pci_alloc_child_bus()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The 'power' attribute of the fakephp driver originally only let one turn a
slot off. If one tried to turn a slot on (echo 1 > .../power), it would
return ENODEV, as fakephp did not support this function.
An old (pre-git) patch changed this:
2004/11/11 16:33:31-08:00 jdittmer
[PATCH] fakephp: add pci bus rescan ability
http://article.gmane.org/gmane.linux.kernel/251183
Now writing "1" to the power attribute has the effect of triggering a bus
rescan, but it still returns ENODEV, probably an oversight in the above
patch.
Using the BusyBox echo will not produce an error message, but will
trigger *two* bus rescans (and return an exit code of 1):
~ # strace echo -n 1 > /sys/bus/pci/slots/0000:00:00.0/power
...
write(1, "1", 1) = -1 ENODEV (No such device)
write(1, "1", 1) = -1 ENODEV (No such device)
exit(1) = ?
Using cp gives a write error, even though the write did happen and a rescan
was triggered:
~ # echo -n 1 > tmp ; cp tmp /sys/bus/pci/slots/0000:00:00.0/power
cp: Write Error: No such device
It seems much better to return success instead of failure. The actual
status of the bus rescan is hard to return. It happens asynchronously in a
work thread, so the sysfs store functions returns before any status is
ready (the whole point of the work queue). And even if it didn't do this,
the rescan doesn't have any clear status to return.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
CC: Jan Dittmer <jdittmer@ppp0.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In drivers/pci/hotplug/ibmphp_core.c::ibmphp_init_devno() we allocate
space dynamically for a PCI irq routing table by calling
pcibios_get_irq_routing_table(), but we never free the allocated space.
This patch frees the allocated space at the function exit points.
Spotted by the Coverity checker. Compile tested only.
Please consider applying.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:
On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.
Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There's no reason for checking pdev->bus for being NULL here (and we'd
anyway Oops 3 lines below if it was).
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This follows up 53a9bf4267. Some newer
CX700 BIOSes from our vendor have PCI Bus Parking disabled but PCI
Master read caching enabled. This creates problems such as system
freezing when both the network controller and the USB controller are
active and one of them is pretty busy (e.g. heavy network traffic).
This patch separates the checks and both the bus parking and the read
caching are disabled independently if either is enabled by the BIOS.
Signed-off-by: Tim Yamin <tim.yamin@zonbu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vital Product Data (VPD) may be exposed by PCI devices in several
ways. It is generally unsafe to read this information through the
existing interfaces to user-land because of stateful interfaces.
This adds:
- abstract operations for VPD access (struct pci_vpd_ops)
- VPD state information in struct pci_dev (struct pci_vpd)
- an implementation of the VPD access method specified in PCI 2.2
(in access.c)
- a 'vpd' binary file in sysfs directories for PCI devices with VPD
operations defined
It adds a probe for PCI 2.2 VPD in pci_scan_device() and release of
VPD state in pci_release_dev().
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is for batching up the flushing of the IOTLB for the DMAR
implementation found in the Intel VT-d hardware. It works by building a list
of to be flushed IOTLB entries and a bitmap list of which DMAR engine they are
from.
After either a high water mark (250 accessible via debugfs) or 10ms the list
of iova's will be reclaimed and the DMAR engines associated are IOTLB-flushed.
This approach recovers 15 to 20% of the performance lost when using the IOMMU
for my netperf udp stream benchmark with small packets. It can be disabled
with a kernel boot parameter "intel_iommu=strict".
Its use does weaken the IOMMU protections a bit.
Signed-off-by: Mark Gross <mgross@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
print_fn_descriptor_symbol() prints the address if we don't have a symbol,
so no need to print both.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following patch merges two functions into one allowing for a 3%
reduction in overhead in locating, allocating and inserting pages for
use in IOMMU operations.
Its a bit of a eye-crosser so I welcome any RB-tree / MM experts to take
a look. It works by re-using some of the information gathered in the
search for the pages to use in setting up the IOTLB's in the insertion
of the iova structure into the RB tree.
Signed-off-by: <mgross@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not DEVICE_COUNT_RESOURCE (12), resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent", not IORESOURCE_UNSET
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the generic pci_enable_resources() instead of the arch-specific code.
The generic version is functionally equivalent, but uses dev_printk.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- does not check for a NULL dev pointer
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- skips resources unless requested in "mask"
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Each architecture has its own pcibios_enable_resources() implementation.
These differ in many minor ways that have nothing to do with actual
architectural differences. Follow-on patches will make most arches
use this generic version instead.
This version is based on powerpc, which seemed most up-to-date. The only
functional difference from the x86 version is that this uses "!r->parent"
to check for resource collisions instead of "!r->start && r->end".
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
PCI Express ASPM defines a protocol for PCI Express components in the D0
state to reduce Link power by placing their Links into a low power state
and instructing the other end of the Link to do likewise. This
capability allows hardware-autonomous, dynamic Link power reduction
beyond what is achievable by software-only controlled power management.
However, The device should be configured by software appropriately.
Enabling ASPM will save power, but will introduce device latency.
This patch adds ASPM support in Linux. It introduces a global policy for
ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
it. The interface can be used as a boot option too. Currently we have
below setting:
-default, BIOS default setting
-powersave, highest power saving mode, enable all available ASPM
state and clock power management
-performance, highest performance, disable ASPM and clock power
management
By default, the 'default' policy is used currently.
In my test, power difference between powersave mode and performance mode
is about 1.3w in a system with 3 PCIE links.
Note: some devices might not work well with aspm, either because chipset
issue or device issue. The patch provide API (pci_disable_link_state),
driver can disable ASPM for specific device.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The "pci=routeirq" option was added in 2004, and I don't get any valid
reports anymore. The option is still mentioned in kernel-parameters.txt.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The PCI bus names included in /proc/iomem and /proc/ioports are
of the form 'PCI Bus #XX' where XX is the bus number. This patch
changes the naming to 'PCI Bus XXXX:YY' where XXXX is the domain
number and YY is the bus number. For example, PCI bus 14 in
domain 0 will show as 'PCI Bus 0000:14' instead of 'PCI Bus #14'.
This change makes the naming consistent with other architectures
such as ia64 where multiple PCI domain support has been around
longer.
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
#if 0 the no longer used pci_cleanup_aer_correct_error_status().
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] pcie AER: don't check _OSC when acpi is disabled
when acpi=off or pci=noacpi, get warning
AER service couldn't init device 0000:00:0a.0:pcie01 - no _OSC support
AER service couldn't init device 0000:00:0e.0:pcie01 - no _OSC support
AER service couldn't init device 0000:00:0f.0:pcie01 - no _OSC support
AER service couldn't init device 0000:80:0b.0:pcie01 - no _OSC support
AER service couldn't init device 0000:80:0e.0:pcie01 - no _OSC support
AER service couldn't init device 0000:80:0f.0:pcie01 - no _OSC support
so don't check _OSC in aer_osc_setup
Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch finally removes the global list of PCI devices. We are
relying entirely on the list held in the driver core now, and do not
need a separate "shadow" list as no one uses it.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove the parisc usage of the global_list, as it's not needed anymore.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This function was obviously never being used since early 2.5 days as any
device that it would try to remove would never really be removed from
the system due to the PCI device list being held in the driver core, not
the general list of PCI devices.
As we have not had a single report of a problem here in 4 years, I think
it's safe to remove now.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This lets us check if the device is really added to the driver core or
not, which is what we need when walking some of the bus lists. The flag
is there in anticipation of getting rid of the other PCI device list,
which is what we used to check in this situation.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We currently keep 2 lists of PCI devices in the system, one in the
driver core, and one all on its own. This second list is sorted at boot
time, in "BIOS" order, to try to remain compatible with older kernels
(2.2 and earlier days). There was also a "nosort" option to turn this
sorting off, to remain compatible with even older kernel versions, but
that just ends up being what we have been doing from 2.5 days...
Unfortunately, the second list of devices is not really ever used to
determine the probing order of PCI devices or drivers[1]. That is done
using the driver core list instead. This change happened back in the
early 2.5 days.
Relying on BIOS ording for the binding of drivers to specific device
names is problematic for many reasons, and userspace tools like udev
exist to properly name devices in a persistant manner if that is needed,
no reliance on the BIOS is needed.
Matt Domsch and others at Dell noticed this back in 2006, and added a
boot option to sort the PCI device lists (both of them) in a
breadth-first manner to help remain compatible with the 2.4 order, if
needed for any reason. This option is not going away, as some systems
rely on them.
This patch removes the sorting of the internal PCI device list in "BIOS"
mode, as it's not needed at all anymore, and hasn't for many years.
I've also removed the PCI flags for this from some other arches that for
some reason defined them, but never used them.
This should not change the ordering of any drivers or device probing.
[1] The old-style pci_get_device and pci_find_device() still used this
sorting order, but there are very few drivers that use these functions,
as they are deprecated for use in this manner. If for some reason, a
driver rely on the order and uses these functions, the breadth-first
boot option will resolve any problem.
Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This was marked incorrectly for some reason. Allow the ibmphp driver to
be built even if PCI_LEGACY is not enabled.
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This removes the depandancy of the cpcihp driver from the PCI_LEGACY
config option by removing its usage of the pci_find_bus() function.
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Scott Murray <scottm@somanetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This cleans up the search.c file, now using the pci list of devices that
are created for the driver core, instead of relying on our separate list
of devices. It's better to use the functions already created for this
kind of thing, instead of rolling our own all the time.
This work is done in anticipation of getting rid of that second list of
pci devices all together.
And it ends up saving code, always a nice benefit.
This also removes one compiler warning for when CONFIG_PCI_LEGACY is
enabled as we no longer internally use the deprecated functions anymore.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This removes the pci_get_device_reverse function as there should not be
any need to walk pci devices backwards anymore. All users of this call
are now gone from the tree, so it is safe to remove it.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This isn't needed, we can just walk the devices in bus order with no
problems at all, as we really want to remove pci_get_device_reverse from
the kernel tree.
Acked-by: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
No one is using this function anymore for quite some time, so remove it.
Everyone calls pci_dev_present() instead anyway...
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
An unused function that bloated the kernel only when CONFIG_EMBEDDED was
enabled...
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Create Documentation/PCI/ and move PCI-related files to it.
Fix a few instances of trailing whitespace.
Update references to the new file locations.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Minor cleanups to the OMAP RNG:
- Comment update re RNG status:
* yes, it works on 16xx; "rngtest" is quite happy
* it's fast enough that polling vs IRQ is a non-issue
- Get rid of BUG_ON
- Help GCC not be stupid about inlining (object code shrink)
- Remove "sparse" warning
- Cope with new hotplug rule requiring "platform:" modalias
And make the file header match kernel conventions.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Ciphers, block modes, name it, are grouped together and sorted.
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
> Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> > This patch cleanups the crypto code, replaces the init() and fini()
> > with the <algorithm name>_init/_fini
>
> This part ist OK.
>
> > or init/fini_<algorithm name> (if the
> > <algorithm name>_init/_fini exist)
>
> Having init_foo and foo_init won't be a good thing, will it? I'd start
> confusing them.
>
> What about foo_modinit instead?
Thanks for the suggestion, the init() is replaced with
<algorithm name>_mod_init ()
and fini () is replaced with <algorithm name>_mod_fini.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The Padlock AES setkey routine is the same as exported by the generic
implementation. So we could use it.
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Cc: Michal Ludvig <michal@logix.cz>
Tested-by: Stefan Hellermann <stefan@the2masters.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The key expansion routine could be get little more generic, become
a kernel doc entry and then get exported.
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Tested-by: Stefan Hellermann <stefan@the2masters.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
