If acpi_query_osc() returns other than AE_OK, __pci_osc_support_set()
stops scanning ACPI objects to evaluate _OSC. This prevents subsequent
_OSCs from being evaluated if some of root bridge doesn't have _OSC, for
example. So acpi_query_osc() should return always AE_OK to evaluate all
_OSC.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
In current pci_osc_control_set() implementation, once the _OSC control
field is queried, it is never queried again. But the query result can
change depending on the _OSC support field. For example, if PCI Express
Native Hot Plug control depends on ASPM support on a certain platform, a
PCI Express Native Hot Plug Control query would fail before the ASPM
driver was loaded, but it would succeed if the ASPM driver was loaded
first. Therefore, pci_osc_control_set() should query the _OSC control
field every time.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Current pci_osc_control_set() evaluates _OSC without query for control
bits, unless __pci_osc_support_set() is called beforehand. But as
strongly recommended in PCI firmware specification, it should query
control bits first.
This patch changes pci_osc_control_set() to query control bits first
even if __pci_osc_support_set() is not called beforehand.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Fix possible race condition on _OSC evaluation.
Current _OSC evaluation code has possible race condition because it
maniputes osc_data linked list or its contents without any lock
mechanism.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Since the ehca device driver does not support dynamic memory add and
remove operations, the driver must explicitly reject such requests in
order to prevent unpredictable behaviors related to existing memory
regions that cover all of memory being used by InfiniBand protocols in
the kernel.
The solution (for now at least) is to add a memory notifier to the
ehca device driver and if a request for dynamic memory add or remove
comes in, ehca will always reject it. The user can add or remove
memory by hot-removing the ehca adapter, performing the memory
operation, and then hot-adding the ehca adapter back.
Signed-off-by: Stefan Roscher <stefan.roscher@de.ibm.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Because ehca adapters can differ in the maximum number of QPs and CQs
we have to save the maximum number of these ressources per adapter and
not globally per ehca driver. This fix introduces 2 new members to the
shca structure to store the maximum value for QPs and CQs per adapter.
The module parameters are now used as initial values for those
variables. If a user selects an invalid number of CQs or QPs we don't
print an error any longer, instead we will inform the user with a
warning and set the values to the respective maximum supported by the
HW.
Signed-off-by: Stefan Roscher <stefan.roscher@de.ibm.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Child devices were created without any offload features set, fix this by
moving the code that computes the features into generic function which is
now called through non-child and child device creation.
Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com>
-- v1 has a bug where the 'result' flag in ipoib_vlan_add may be used uninitialized
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Add a get_rx_csum method. Remove the driver's own get_tso method, as
the ethtool kernel code uses the default one if nothing is provided.
Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The Mellanox ConnectX can operate as an InfiniBand adapter, as an
Ethernet NIC, or as a Fibre Channel (FC) HBA. The kernel has a
low-level driver, mlx4_core, which handles multiplexing access to the
device, and there is also already an InfiniBad driver, mlx4_ib.
This patch adds a new driver, mlx4_en, which implements a standard
Ethernet NIC driver.
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Multi-protocol adapters support different port types. Each consumer
of mlx4_core queries for supported port types; in particular mlx4_ib
can no longer assume that all physical ports belong to it. Port type
is configured through a sysfs interface. When the type of a port is
changed, all mlx4 interfaces are unregistered, and then registered
again with the new port types.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
panasonic-laptop uses many acpi_*() functions so it should
depend on ACPI; otherwise there are approximately 70
warnings/errors generated.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Harald Welte <laforge@gnumonks.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Based on analysis and a patch from Matthew Garrett <mjg59@srcf.ucam.org>.
Instruct the ThinkPad ACPI firmware to remove delays on the processing of
backlight brightness changes. This method is present on ThinkPad
Vista-compatible BIOSes with standard ACPI backlight level control.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Yves-Alexis Perez <corsac@debian.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Pascal Terjan <pterjan@mandriva.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Trivial fix makes the error message match the code before it (ibm->driver
vs ibm->acpi-driver) better.
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Attempt to preserve fan state across sleep and hibernation if the fan
control mode is enabled.
For safety reasons, only the PWM OFF (fan at 100%) or maximum
closed-loop level (level 7) are preserved. If the fan state was set
to anything else, it will not be restored.
Also, should the fan be at PWM OFF mode at resume, it will be left at
that state (but this is extremely unlikely, no ThinkPad firmware was
ever reported to do this).
For reference, the known states used for fan control upon resume by
the firmware are either "auto" or "level 7" depending on whether the
laptop wakes due to normal conditions or a thermal emergency.
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=11331
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Richard Hartmann <richih.mailinglist@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Badness at /home/proski/src/linux-2.6/net/mac80211/rx.c:2200
NIP: c02bc850 LR: c02ab268 CTR: 00000000
REGS: ef01fcc0 TRAP: 0700 Tainted: G W (2.6.27-wl)
MSR: 00029032 <EE,ME,IR,DR> CR: 22004084 XER: 20000000
TASK = c1a58800[1778] 'p54pci' THREAD: ef01e000
[...]
NIP [c02bc850] __ieee80211_rx+0x17c/0x638
LR [c02ab268] ieee80211_tasklet_handler+0x104/0x120
Call Trace:
[ef01fd70] [c1a0c020] 0xc1a0c020 (unreliable)
[ef01fdb0] [c02ab268] ieee80211_tasklet_handler+0x104/0x120
[...]
the problem was that some older cards are mis-identified and didn't support
5GHz rates, while they have the right MAC & Synth chip.
This patch changes the way how p54 decides if it should enable 11a channels
or not.
Reported-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
orinoco_dl_firmware and symbol_dl_mage allocate large local
variables (1K); at least orinoco fails with panic or hung
kernel if 4K stacks is enabled.
Allocate large buffers dynamically at run time.
Tested-By: Andrey Borzenkov <arvidjaar@mail.ru> for Agere case
Signed-off-by: Andrey Borzenkov < arvidjaar@mail.ru>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on a patch by Elias Oltmanns, we call ath5k_init in resume even
if we didn't previously open the device. Besides starting up the
device unnecessarily, this also causes an oops on rmmod because
mac80211 will not invoke ath5k_stop and softirqs are left running after
the module has been unloaded. Add a new state bit, ATH_STAT_STARTED,
to indicate that we have been started up.
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Elias Oltmanns <eo@nebensachen.de>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Code in `pci_link.c' is calling the internal routine `acpi_ut_evaluate_object'
which is dangerous given that it is passing a NULL pointer when it should
be passing a pointer to a real object. The patch corrects the issue by
having the code call the external routine `acpi_evaluate_object', which
correctly handles a NULL pointer.
Signed-off-by: Don Dugger <donald.d.dugger@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
According to ACPI spec when the status of some device is not present
but functional, the device is valid and the children of this device
should be enumerated. It means that the device should be added to
linux acpi device tree. But the device driver for this device should not
be loaded.
The detailed info can be found in the section 6.3.7 of ACPI 3.0b spec.
_STA may return bit 0 clear (not present) with bit 3 set (device is
functional). This case is used to indicate a valid device for which no
device driver should be loaded (for example, a bridge device.).
Children of this device may be present and valid. OS should continue
enumeration below a device whose _STA returns this bit combination
http://bugzilla.kernel.org/show_bug.cgi?id=3358
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add the DMI check to disable power check in the course of device power
transistion.
http://bugzilla.kernel.org/show_bug.cgi?id=11000
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Maybe the incorrect power state is returned on the bogus bios, which
is different with the real power state. For example: the bios returns D0
state and the real power state is D3. OS expects to set the device to D0
state. In such case if OS uses the power state returned by the BIOS and
checks the device power state very strictly in power transition, the device
can't be transited to the correct power state.
So the boot option of "acpi.power_nocheck=1" is added to avoid checking
the device power in the course of device power transition.
http://bugzilla.kernel.org/show_bug.cgi?id=8049http://bugzilla.kernel.org/show_bug.cgi?id=11000
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Attach the ACPI device to the ACPI handle as early as possible so that OS
can get the corresponding ACPI device by the acpi handle in the course
of getting the power/wakeup/performance flags.
http://bugzilla.kernel.org/show_bug.cgi?id=8049http://bugzilla.kernel.org/show_bug.cgi?id=11000
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Get the device power state in the course of scanning device if the device
power flag is power_managable. i.e. The device has the _PSx/_PRx object.
At the same time before the drivers/acpi/power module is loaded, there is no
relation between acpi_power_resource and acpi device. So the first parameter
of acpi_power_get_state is changed to acpi_handle.
http://bugzilla.kernel.org/show_bug.cgi?id=8049http://bugzilla.kernel.org/show_bug.cgi?id=11000
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The AE_BAD_ADDRESS exception code is now unused in ACPICA.
For linux, it's only used at wmi.c and acer-wmi.c.
I checked both wmi.c and acer-wmi.c, the AE_BAD_ADDRESS exception code
has no special meaning. The parent functions just call AE_SUCCESS() or
AE_FAILURE() to check the return status.
So it's safe to replace AE_BAD_ADDRESS with AE_ERROR.
Signed-off-by Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Initially CONFIG_PM_SLEEP was defined as
CONFIG_SUSPEND || CONFIG_HIBERNATION and some ACPI code, most
importantly the code in drivers/acpi/main.c, was written with this
assumption. Currently, however, CONFIG_PM_SLEEP is also set when
CONFIG_XEN_SAVE_RESTORE is set.
This causes some compilation warnings to appear in
drivers/acpi/main.c if both CONFIG_SUSPEND and CONFIG_HIBERNATION
are unset and CONFIG_PM_SLEEP is set (this was impossible before).
To fix this problem, redefine CONFIG_ACPI_SLEEP do depend directly
on CONFIG_SUSPEND || CONFIG_HIBERNATION, as originally intended, and
use it instead of CONFIG_PM_SLEEP in drivers/acpi/main.c, wherever
appropriate.
Additionally, move the acpi_target_sleep_state definition from under
the #ifdef to prevent compilation from failing in some cases.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Add support for managing MAC and VLAN filters for each port.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Oren Duer <oren@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
A typo caused these values to be swapped leading to incorrect memory
type attributes.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
From: David Brownell <dbrownell@users.sourceforge.net>
The "5298/1: Drop desc_handle_irq()" patch went overboard
and deleted an essential line of code, causing all AT91
GPIO interrupts to oops (in irq). Trimmed example:
Unable to handle kernel NULL pointer dereference at virtual address 000000c4
...
PC is at gpio_irq_handler+0x78/0xd0
LR is at gpio_irq_handler+0x38/0xd0
...
Backtrace:
[<c0029884>] (gpio_irq_handler+0x0/0xd0) from [<c0020054>] (__exception_text_start+0x54/0x7c)
[<c0020000>] (__exception_text_start+0x0/0x7c) from [<c00209ec>] (__irq_svc+0x2c/0x60)
Exception stack(0xc1c1de00 to 0xc1c1de48)
[<c01f4ca8>] (_spin_unlock_irq+0x0/0x3c) from [<c01389f8>] (at91ether_open+0x220/0x318)
[<c01387d8>] (at91ether_open+0x0/0x318) from [<c018caa4>] (dev_open+0xa8/0x10c)
[<c018c9fc>] (dev_open+0x0/0x10c) from [<c018b874>] (dev_change_flags+0x98/0x164)
[<c018b7dc>] (dev_change_flags+0x0/0x164) from [<c0019f8c>] (ip_auto_config+0x164/0xe28)
[<c0019e28>] (ip_auto_config+0x0/0xe28) from [<c0020318>] (__exception_text_end+0x60/0x180)
[<c00202b8>] (__exception_text_end+0x0/0x180) from [<c0008738>] (kernel_init+0x70/0xd8)
[<c00086c8>] (kernel_init+0x0/0xd8) from [<c00398e0>] (do_exit+0x0/0x6ac)
This patch restores the missing line'o'code.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Andrew Victor <linux@maxim.org.za>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If present the info->archdata is copied into the dev->archdata.
Some (OpenFirmware) platforms need it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The chips directory under drivers/i2c is deprecated. Spread the word!
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Use the newly introduced pci_ioremap_bar() function in drivers/i2c.
pci_ioremap_bar() just takes a pci device and a bar number, with the goal
of making it really hard to get wrong, while also having a central place
to stick sanity checks.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The legacy i2c device driver binding model is superseded by the
standard model, so it's time to deprecate it and schedule it for
removal.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Fix most checkpatch.pl errors and warnings. This includes replacing
spaces with tabs in many places, adding and removing spaces, and
folding long lines.
Also complete a couple prototypes to make it clearer what the
parameters represent.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
* Strip trailing white space.
* Remove out-of-date or irrelevant parts.
* Insist on the fact that command is deprecated.
* Fix spelling mistakes and typos.
* Reformat code examples and function prototypes to comply with the
kernel coding style.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
We have no users and no implementers for these transfer types so it
makes little sense to define functionality bits for them.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The legacy i2c binding model is deprecated and will be removed soon,
so we no longer need to document it.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
i2c_get_clientdata doesn't change the i2c_client it is passed as a
parameter, so it can be constified. Same for i2c_get_adapdata.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The document describing how to port i2c chip drivers from Linux 2.4 to
Linux 2.6 is outdated. As I suspect that most drivers that had to be
ported have already been by now, I do not want to spend time updating
it. Let's just delete it instead.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Make clear what the class field of i2c_adapter is good for.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Fix typo in debugging log message.
deteted --> detected
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Some I2C bus implementations need to synchronize with external
entities, such as system firmware, which might also be programming the
same I2C bus.
In order to facilitate this add ->xfer_begin() and ->xfer_end() hooks
which are invoked around pcf_xfer().
[JD: Make these hooks optional.]
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
