The destination of goto error also does a kfree(g_iommus), so it is not
correct to do one here.
This was found using Coccinelle (http://www.emn.fr/x-info/coccinelle/).
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Fixup a typo in dbg_ctrl(); it was fetching SLOTSTATUS twice.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Fix the following problems of shpchp driver about getting hotplug
control from firmware.
- The shpchp driver must not control the hotplug controller if it
fails to get control from the firmware. But current shpchp
controls the hotplug controller regardless the result, because it
doesn't check the return value of get_hp_hw_control_from_firmware().
- Current shpchp driver doesn't support _OSC.
The pciehp driver already have the code for evaluating _OSC and OSHP
and shpchp and pciehp can share it. So this patch move that code from
pciehp to acpi_pcihp.c.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Since we need to wait for command completion for muximum 1sec, waiting
command should not be interrupted by a signal.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Current pciehp evaluates _OSC/OSHP method after some controller
initialization is done. So if evaluating _OSC/OSHP is failed, we need
to cleanup already initialized data structures or hardware. This
clearly is not robust way. With this patch, _OSC/OSHP evaluation is
done first.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Remove the redundant initialization of pci_dev member of struct
controller in pciehp_probe(). It is initialized in pcie_init().
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Allows us to dump PCI space before any kernel changes have been made.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Implement new suspend and hibernation callbacks for the platform bus
type.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg KH <greg@kroah.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Implement new suspend and hibernation callbacks for the PCI bus type.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Contention for scarce PCI memory resources has been growing
due to an increasing number of PCI slots in large multi-node
systems. The kernel currently attempts by default to
allocate memory for all PCI expansion ROMs so there has
also been an increasing number of PCI memory allocation
failures seen on these systems. This occurs because the
BIOS either (1) provides insufficient PCI memory resource
for all the expansion ROMs or (2) provides adequate PCI
memory resource for expansion ROMs but provides the
space in kernel unexpected BIOS assigned P2P non-prefetch
windows.
The resulting PCI memory allocation failures may be benign
when related to memory requests for expansion ROMs themselves
but in some cases they can occur when attempting to allocate
space for more critical BARs. This can happen when a successful
expansion ROM allocation request consumes memory resource
that was intended for a non-ROM BAR. We have seen this
happen during PCI hotplug of an adapter that contains a
P2P bridge where successful memory allocation for an
expansion ROM BAR on device behind the bridge consumed
memory that was intended for a non-ROM BAR on the P2P bridge.
In all cases the allocation failure messages can be very
confusing for users.
This patch provides a new 'pci=norom' kernel boot parameter
that can be used to disable the default PCI expansion ROM memory
resource allocation. This provides a way to avoid the above
described issues on systems that do not contain PCI devices
for which drivers or user-level applications depend on the
default PCI expansion ROM memory resource allocation behavior.
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The position of MSI capability is already cached in the msi_desc when
we enter the msi_set_mask_bits(). Use it instead.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch removes CVS keywords that weren't updated for a long time
from comments.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The 'retval' variable in __pci_osc_support_set() is no longer
used. Remove this unused variable.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Current pci-acpi implementation checks osc_data->support_stat to see
if control bits had been already queried. It is not good from the
viewpoint of easy understanding. So this patch adds new 'is_queried'
flag to indicate query had been done.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Current pci-acpi implementation uses array in osc_data directly to
evaluate _OSC. It needs to save the old data and restore it if _OSC
evaluation fails. To make it more robust, we should use local array to
evaluate _OSC.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Remove the duplicated code in acpi_query_osc() and acpi_run_osc().
It simplifies the code very much.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
If a device supports #PME and can generate PME events from D0, we may see
superfluous events before a driver is loaded (drivers should only enable PME as
needed), preventing suspend from working if the corresponding GPE was enabled.
Likewise, if the ACPI device has the _PRW object, the _PSW/_DSW object will be
called in order to disable the wakeup functionality. But when it is allowed to
wake up the sleeping state, OSPM will enable it again.
So we should disable PME in the course of scanning PCI devices and enable it
again only when PME events are actually required to be generated from the
requested PCI state (for example, D3_hot or D3_cold). It is also safe to
disable PME again when the PME is disabled for the PCI devices.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Some quirks should be called with interrupt disabled, we can't directly
call them in .resume_early. Also the patch introduces
pci_fixup_resume_early and pci_fixup_suspend, which matches current
device core callbacks (.suspend/.resume_early).
TBD: Somebody knows why we need quirk resume should double check if a
quirk should be called in resume or resume_early. I changed some per my
understanding, but can't make sure I fixed all.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch adds prototypes for pcibios_disable_device() and
pcibios_set_pcie_reset_state() in include/linux/pci.h
While I was at it, I also removed the unneeded "extern" from the
prototype of pcibios_add_platform_entries().
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch makes the needlessly global {pciehp,shpchp}_slot_with_bus
static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/core: Remove IB_DEVICE_SEND_W_INV capability flag
IB/umem: Avoid sign problems when demoting npages to integer
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6:
Blackfin serial driver: fix up tty core set_ldisc API change breakage bug
Blackfin arch: protect only the SPI bus controller with CONFIG_SPI_BFIN
Blackfin arch: fixup warnings with the new cplb saved values
Blackfin Serial Driver: Clean up BF54x macro in blackfin UART driver.
Commit 54d29ad33e (Power Supply: fix race
in device_create) introduced a race in power_supply_uevent. Previously it
checked that power_supply is available by checking for dev->driver_data.
But now dev->driver_data is set before power_supply->dev is initialised.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Format string bug. Not exploitable, as this is only writable by root,
but worth fixing all the same.
Spotted-by: Ilja van Sprundel <ilja@netric.org>
Signed-off-by: Dave Jones <davej@redhat.com>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
[POWERPC] ehea: Remove dependency on MEMORY_HOTPLUG
[POWERPC] Make walk_memory_resource available with MEMORY_HOTPLUG=n
[POWERPC] Use dev_set_name in pci_64.c
[POWERPC] Fix incorrect enabling of VMX when building signal or user context
[POWERPC] boot/Makefile CONFIG_ variable fixes
* git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.26:
sh: Add -mno-fdpic to default flags.
sh: add resource of USB host for SH7723
usb: r8a66597-hcd: Add support for SH7723 USB host
sh: Fix compile error SH7763 setup code
sh: Add SH7723 SCIF support
Minor source code cleanup of page flags in mm/page_alloc.c.
Move the definition of the groups of bits to page-flags.h.
The purpose of this clean up is that the next patch will
conditionally add a page flag to the groups. Doing that
in a header file is cleaner than adding #ifdefs to the
C code.
Signed-off-by: Russ Anderson <rja@sgi.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 30f2f0eb4b ("block: do_mounts -
accept root=<non-existant partition>") extended blk_lookup_devt() to be
able to look up partitions that had not yet been registered, but in the
process made the assumption that the '&block_class.devices' list only
contains disk devices and that you can do 'dev_to_disk(dev)' on them.
That isn't actually true. The block_class device list also contains the
partitions we've discovered so far, and you can't just do a
'dev_to_disk()' on those.
So make sure to only work on devices that block/genhd.c has registered
itself, something we can test by checking the 'dev->type' member. This
makes the loop in blk_lookup_devt() match the other such loops in this
file.
[ We may want to do an alternate version that knows to handle _either_
whole-disk devices or partitions, but for now this is the minimal fix
for a series of crashes reported by Mariusz Kozlowski in
http://lkml.org/lkml/2008/5/25/25
and Ingo in
http://lkml.org/lkml/2008/6/9/39 ]
Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Reported-by: Ingo Molnar <mingo@elte.hu>
Cc: Neil Brown <neilb@suse.de>
Cc: Joao Luis Meloni Assirati <assirati@nonada.if.usp.br>
Acked-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In 2.6.26, we added some support for send with invalidate work
requests, including a device capability flag to indicate whether a
device supports such requests. However, the support was incomplete:
the completion structure was not extended with a field for the key
contained in incoming send with invalidate requests.
Full support for memory management extensions (send with invalidate,
local invalidate, fast register through a send queue, etc) is planned
for 2.6.27. Since send with invalidate is not very useful by itself,
just remove the IB_DEVICE_SEND_W_INV bit before the 2.6.26 final
release; we will add an IB_DEVICE_MEM_MGT_EXTENSIONS bit in 2.6.27,
which makes things simpler for applications, since they will not have
quite as confusing an array of fine-grained bits to check.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
I think that hda_verb array must have "terminator (empty array)".
But alc262_sony_unsol[] does not have it.
And it causes gcc-4.3's buggy behavior
with snd_hda_sequence_write().
Signed-off-by: Akio Idehara <zbe64533@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Presently the --fdpic specifier and the --isa matching clash when
building with FDPIC toolchains. As we have no interest in building the
kernel with --fdpic in the first place, always try to add in -mno-fdpic
to the default flags.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
R8A66597 is similar to SH7723 USB 2.0 Host/Function module.
In addition, the USB of SH7366 is compatible with SH7723.
It can support SH7723 USB host by changing Kconfig.
Signed-off-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
SH7763's setup code use old DECLARE_INTC_DESC.
There was a compile error because of this.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Now that walk_memory_resource() is available regardless of
MEMORY_HOTPLUG's setting, this dependency is not needed.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Jeff Garzik <jeff@garzik.org>
Acked-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The ehea driver was recently changed[1] to use walk_memory_resource() to
detect the system's memory layout. However, walk_memory_resource() is
available only when memory hotplug is enabled. So CONFIG_EHEA was
made to depend on MEMORY_HOTPLUG [2], but it is inappropriate for a
network driver to have such a dependency.
Make the declaration of walk_memory_resource() and its powerpc
implementation (ehea is powerpc-specific) unconditionally available.
[1] 48cfb14f8b
"ehea: Add DLPAR memory remove support"
[2] fb7b6ca2b6
"ehea: Add dependency to Kconfig"
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
During the next merge window, pci_name()'s return value will become
const, so use the new dev_set_name() instead to avoid the warning (from
linux-next):
arch/powerpc/kernel/pci_64.c: In function 'of_create_pci_dev':
arch/powerpc/kernel/pci_64.c:193: warning: passing argument 1 of 'sprintf' discards qualifiers from pointer target type
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When building a signal or a ucontext, we can incorrectly set the MSR_VEC
bit of the kernel pt_regs->msr before returning to userspace if the task
-ever- used VMX.
This can lead to funny result if that stack used it in the past, then
"lost" it (ie. it wasn't enabled after a context switch for example)
and then called get_context. It can end up with VMX enabled and the
registers containing values from some other task.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This corrects the names of two CONFIG_ variables.
Note that the CONFIG_MPC86XADS fix uncovers another bug
(with mpc866_ads_defconfig) that will require fixing:
<-- snip -->
...
arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/mpc866ads.dtb -b 0 /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts
DTC: dts->dtb on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts"
WRAP arch/powerpc/boot/cuImage.mpc866ads
powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such file or directory
make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1
<-- snip -->
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Julia Lawall