Jean Delvare [Wed, 24 Aug 2011 01:19:41 +0000 (11:19 +1000)]
hwmon: (ibmaem) Avoid repeated memory allocations
Preallocate a buffer for the response to sensor reads, and reuse it
for each read instead of allocating a new one each time. This should
be faster and should also avoid memory fragmentation.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Darrick J. Wong <djwong@us.ibm.com> Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Jean Delvare [Wed, 24 Aug 2011 01:19:38 +0000 (11:19 +1000)]
hwmon: (ibmaem) Fix error paths
I am under the impression that error paths in functions
aem_init_aem1_inst() and aem_init_aem2_inst() are incorrect. In
several cases, the function returns 0 on error, which I suspect is
not intended. Fix this by properly tracking error codes.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Darrick J. Wong <djwong@us.ibm.com> Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Dean Nelson [Wed, 24 Aug 2011 01:19:37 +0000 (11:19 +1000)]
hwmon: Avoid building drivers for powerpc that read/write ISA addresses
A modprobe of hwmon drivers that read/write ISA addresses on a powerpc results
in a kernel Oops. These reads/writes are being done via the inb()/in_8() and
outb()/out_8() macros.
Prevent these drivers from being built for powerpc.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
drivers/i2c/busses/i2c-elektor.c: In function ‘pcf_isa_init’:
drivers/i2c/busses/i2c-elektor.c:153: error: implicit declaration of function ‘ioport_map’
drivers/i2c/busses/i2c-elektor.c:153: warning: assignment makes pointer from integer without a cast
drivers/i2c/busses/i2c-elektor.c: In function ‘elektor_probe’:
drivers/i2c/busses/i2c-elektor.c:287: error: implicit declaration of function ‘ioport_unmap’
Since commit 82ed223c264def2b15ee4bec2e8c3048092ceb5f ("iomap: make IOPORT/PCI
mapping functions conditional"), ioport_map() is only available on platforms
that set HAS_IOPORT.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Jean Delvare <khali@linuxfr.org>
Seth Jennings [Wed, 10 Aug 2011 17:56:49 +0000 (12:56 -0500)]
staging: zcache: fix crash on high memory swap
zcache_put_page() was modified to pass page_address(page) instead of the
actual page structure. In combination with the function signature changes
to tmem_put() and zcache_pampd_create(), zcache_pampd_create() tries to
(re)derive the page structure from the virtual address. However, if the
original page is a high memory page (or any unmapped page), this
virt_to_page() fails because the page_address() in zcache_put_page()
returned NULL.
This patch changes zcache_put_page() and zcache_get_page() to pass
the page structure instead of the page's virtual address, which
may or may not exist.
Émeric Maschino [Tue, 23 Aug 2011 19:48:23 +0000 (21:48 +0200)]
[IA64] agp/hp-agp: Allow binding user memory to the AGP GART
dmesg reports:
[ 29.365973] [TTM] AGP Bind memory failed.
[ 29.366015] radeon 0000:80:00.0: object_init failed for (4096, 0x00000002)
[ 29.366052] radeon 0000:80:00.0: (-22) create WB bo failed
[ 29.366087] radeon 0000:80:00.0: Disabling GPU acceleration
[ 29.366124] [drm] radeon: cp finalized
[ 29.366168] [drm] radeon: cp finalized
[ 29.366210] [TTM] Finalizing pool allocator.
[ 29.366924] [TTM] Zone kernel: Used memory at exit: 0 kiB.
[ 29.366961] [TTM] Zone dma32: Used memory at exit: 0 kiB.
[ 29.366996] [drm] radeon: ttm finalized
[ 29.367030] [drm] Forcing AGP to PCI mode
This patch allows binding user memory to the AGP GART on zx1-based
systems. dmesg thus no more complains about AGP bind memory failure,
disabled GPU acceleration or AGP mode forced to PCI.
Original work from Francisco Jerez in agp/amd-k7
(https://lkml.org/lkml/2010/10/15/469).
Tested-by: Émeric Maschino <emeric.maschino@gmail.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
staging: brcm80211: fix compile error on non-x86 archs since 3.0 kernel
Since the arrival of kernel version 3.0 in the staging tree it
turns out compile error occurs for sparc64, powerpc, and arm
platforms. This patch fixes that issue.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Henry Ptasinski <henryp@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luciano Coelho [Tue, 23 Aug 2011 08:42:25 +0000 (11:42 +0300)]
wl12xx: add max_sched_scan_ssids value to the hw description
After commit 5a865ba, we require a separate value to indicate the
number of supported SSIDs in scheduled scans. This patch adds a
proper value to the wl12xx driver.
This fixes a regression in 3.1-rc3 where scheduled scans were not
working properly with the wl12xx driver.
Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ido Yariv [Mon, 22 Aug 2011 20:19:49 +0000 (23:19 +0300)]
wl12xx: Fix validation of pm_runtime_get_sync return value
wl1271_sdio_power_on checks if the return value of pm_runtime_get_sync
is non-zero, and if so bails out.
However, pm_runtime_get_sync can return a positive number which does not
suggest an error has occurred. This is problematic for two reasons:
1. The function will needlessly bail out without decrementing back the
runtime PM reference counter.
2. wl1271_power_on only checks if wl1271_power_on return value is
negative. This means that wl1271_power_on will continue even if
wl1271_sdio_power_on bailed out. As a result, sdio transactions will
be initiated without properly enabling the sdio function and claiming
the host. This could even lead to a kernel panic.
Fix this by only checking that the return value of pm_runtime_get_sync
is non-negative.
Signed-off-by: Ido Yariv <ido@wizery.com> Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ido Yariv [Mon, 22 Aug 2011 20:19:48 +0000 (23:19 +0300)]
wl12xx: Remove obsolete testmode NVS push command
The testmode NVS push command is no longer in use. In addition, it has
several implementation issues that prevent it from working correctly:
1. wl1271_tm_cmd_configure relies on wl->chip.id being set. However,
since the device was not necessarily booted by the time the function
is called, wl->chip.id will be initialized to 0.
2. The NVS file is fetched by calling request_firmware() before it is
possible to push an NVS file.
3. The maximum allowed size of nl binary payloads is not sufficient for
pushing NVS files.
4. Pushing 128x NVS files will always fail due to a bug in the
validation code.
5. In case the pushed NVS file is found invalid, the mutex will be kept
locked and the nvs member will become a dangling pointer.
Since this feature is not being used, remove it completely instead of
fixing it.
Signed-off-by: Ido Yariv <ido@wizery.com> Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Linus Torvalds [Tue, 23 Aug 2011 18:41:44 +0000 (11:41 -0700)]
Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
xfs: fix tracing builds inside the source tree
xfs: remove subdirectories
xfs: don't expect xfs headers to be in subdirectories
Grant Likely [Tue, 23 Aug 2011 18:15:33 +0000 (12:15 -0600)]
mmc: sdhci-tegra: Add Device Tree probing support
Add hooks to read gpio configuration out of the device tree node.
[grant.likely: Rewrite of original patch from John Bonesio] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
[swarren: Fixed tegra_sdhci_get_ro() to retrieve pdata correctly]
[swarren: Reworked to avoid #ifdef CONFIG_OF]
[swarren: Reworked binding based on fsl-imx-esdhc.txt]
[swarren: Documented binding] Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Chris Ball <cjb@laptop.org>
Nick Pelly [Fri, 15 Jul 2011 20:53:08 +0000 (13:53 -0700)]
omap-serial: Allow IXON and IXOFF to be disabled.
Fixes logic bug that software flow control cannot be disabled, because
serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits
are cleared.
Linus Torvalds [Tue, 23 Aug 2011 17:46:21 +0000 (10:46 -0700)]
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon: Extended DDC Probing for Toshiba L300D Radeon Mobility X1100 HDMI-A Connector
drm/ttm: ensure ttm for new node is bound before calling move_notify()
drm/ttm: unbind ttm before destroying node in accel move cleanup
drm/ttm: fix ttm_bo_add_ttm(user) failure path
drm/radeon: Make vramlimit parameter actually work.
drm/radeon: Explicitly print GTT/VRAM offsets on test failure.
drm/radeon: Take IH ring into account for test size calculation.
drm/radeon/alpha: Add Alpha support to Radeon DRM code
It turns out that this breaks several drivers, one example being OMAP
boards which use the on-board OMAP UARTs and the omap-serial driver that
will not boot to userspace after the commit.
Paul Walmsley reports that enabling CONFIG_DEBUG_SHIRQ reveals 'IRQ
handler type mismatch' errors:
IRQ handler type mismatch for IRQ 74
current handler: serial idle
...
and the reason is that setting IRQF_ONESHOT will now result in those
interrupt handlers having different IRQF flags, and thus being
unsharable. So the commit log in the reverted commit:
"Since it is required for those users and
there is no difference for others it makes sense to add this flag
unconditionally."
is simply not true: there may not be any difference from a "actions at
irq time", but there is a *big* difference wrt this flag testing irq
management (see __setup_irq() in kernel/irq/manage.c).
One solution may be to stop verifying IRQF_ONESHOT in __setup_irq(), but
right now the safe course of action is to revert the change. Let's
revisit this in a later merge window.
Reported-by: Paul Walmsley <paul@pwsan.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Requested-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jiri Slaby [Wed, 17 Aug 2011 11:48:15 +0000 (13:48 +0200)]
TTY: serial, document ignoring of uart->ops->startup error
When a user has SYS_ADMIN capabilities and uart->ops->startup returns
an error in uart_startup, we silently drop the error. We then return 0
and behave as if it didn't fail. (Not quite, since we set TTY_IO_ERROR
bit and leave ASYNC_INITIALIZED bit cleared.)
This all is to allow setserial to work with improperly configured or
unconfigured ports. User can thus set port properties and reconfigure
properly.
This patch only documents this behavior.
Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Russel King <linux@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Slaby [Wed, 10 Aug 2011 12:59:28 +0000 (14:59 +0200)]
TTY: pty, fix pty counting
tty_operations->remove is normally called like:
queue_release_one_tty
->tty_shutdown
->tty_driver_remove_tty
->tty_operations->remove
However tty_shutdown() is called from queue_release_one_tty() only if
tty_operations->shutdown is NULL. But for pty, it is not.
pty_unix98_shutdown() is used there as ->shutdown.
So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never
called. This results in invalid pty_count. I.e. what can be seen in
/proc/sys/kernel/pty/nr.
I see this was already reported at:
https://lkml.org/lkml/2009/11/5/370
But it was not fixed since then.
This patch is kind of a hackish way. The problem lies in ->install. We
allocate there another tty (so-called tty->link). So ->install is
called once, but ->remove twice, for both tty and tty->link. The fix
here is to count both tty and tty->link and divide the count by 2 for
user.
And to have ->remove called, let's make tty_driver_remove_tty() global
and call that from pty_unix98_shutdown() (tty_operations->shutdown).
While at it, let's document that when ->shutdown is defined,
tty_shutdown() is not called.
Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Al Cooper [Mon, 25 Jul 2011 20:19:52 +0000 (16:19 -0400)]
8250: Fix race condition in serial8250_backup_timeout().
This is to fix an issue where output will suddenly become very slow.
The problem occurs on 8250 UARTS with the hardware bug UART_BUG_THRE.
BACKGROUND
For normal UARTs (without UART_BUG_THRE): When the serial core layer
gets new transmit data and the transmitter is idle, it buffers the
data and calls the 8250s' serial8250_start_tx() routine which will
simply enable the TX interrupt in the IER register and return. This
should immediately fire a THRE interrupt and begin transmitting the
data.
For buggy UARTs (with UART_BUG_THRE): merely enabling the TX interrupt
in IER does not necessarily generate a new THRE interrupt.
Therefore, a background timer periodically checks to see if there is
pending data, and starts transmission if that is the case.
The bug happens on SMP systems when the system has nothing to transmit,
the transmit interrupt is disabled and the following sequence occurs:
- CPU0: The background timer routine serial8250_backup_timeout()
starts and saves the state of the interrupt enable register (IER)
and then disables all interrupts in IER. NOTE: The transmit interrupt
(TI) bit is saved as disabled.
- CPU1: The serial core gets data to transmit, grabs the port lock and
calls serial8250_start_tx() which enables the TI in IER.
- CPU0: serial8250_backup_timeout() waits for the port lock.
- CPU1: finishes (with TI enabled) and releases the port lock.
- CPU0: serial8250_backup_timeout() calls the interrupt routine which
will transmit the next fifo's worth of data and then restores the
IER from the previously saved value (TI disabled).
At this point, as long as the serial core has more transmit data
buffered, it will not call serial8250_start_tx() again and the
background timer routine will slowly transmit the data.
The fix is to have serial8250_start_tx() get the port lock before
it saves the IER state and release it after restoring IER. This will
prevent serial8250_start_tx() from running in parallel.
Signed-off-by: Al Cooper <alcooperx@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Smith [Tue, 12 Jul 2011 04:53:13 +0000 (22:53 -0600)]
8250_pci: add support for Rosewill RC-305 4x serial port card
This patch adds support for the Rosewill RC-305 four-port PCI serial
card, and probably any other four-port serial cards based on the
Moschip MCS9865 chip, assuming that the EEPROM on the card was
programmed in accordance with Table 6 of the MCS9865 EEPROM
Application Note version 0.3 dated 16-May-2008, available from the
Moschip web site (registration required).
This patch is based on an earlier patch [1] for the SYBA 6x serial
port card by Ira W. Snyder.
projects / karo-tx-linux.git / log