Jean Delvare [Mon, 14 Jul 2008 20:38:36 +0000 (22:38 +0200)]
i2c: Call client_unregister for new-style devices too
We call adapter->client_register for both legacy and new-style i2c
devices, however we only call adapter->client_unregister for legacy
drivers. This doesn't make much sense. Usually, drivers will undo
in client_unregister what they did in client_register, so we should
call neither or both for every given i2c device.
In order to ease the transition from legacy to new-style devices, it
seems preferable to actually call both.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: David Brownell <david-b@pacbell.net>
Sean MacLennan [Mon, 14 Jul 2008 20:38:36 +0000 (22:38 +0200)]
i2c-ibm_iic: Register child nodes
This patch completes the conversion of the IBM IIC driver to an
of-platform driver.
It removes the index from the IBM IIC driver and makes it an unnumbered
driver. It then calls of_register_i2c_devices to properly register all
the child nodes in the DTS.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Manuel Lauss [Mon, 14 Jul 2008 20:38:34 +0000 (22:38 +0200)]
i2c-au1550: Fix PM support
Fix driver power management:
- suspend the PSC while driver is idle.
- move PSC init/deinit to separate functions, as PSC must be
initialized/shutdown on resume/suspend.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Mon, 14 Jul 2008 20:38:33 +0000 (22:38 +0200)]
i2c: Check for ACPI resource conflicts
Check for ACPI resource conflicts in i2c bus drivers. I've included
all recent SMBus master drivers for PC hardware.
I've voluntarily left out:
* Drivers that don't run on PCs: they can't conflict with ACPI.
* Bit-banged bus device drivers: it's very unlikely that ACPI would
deal with such buses.
Manuel Lauss [Mon, 14 Jul 2008 20:38:33 +0000 (22:38 +0200)]
i2c-ocores: basic PM support
Basic PM support: reinit the core on resume, disable it on suspend.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net> Acked-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Jean Delvare <khali@linux-fr.org>
The standard rtc-m41t80.c driver cannot be used with the SWARM as it is,
because the board does not provide setup information for the I2C core.
As a result the bus and the address to probe for the M41T80 chip is not
known.
Here is a set of changes that fix the problem:
1. swarm-i2c.c -- SWARM I2C board setup, currently for the M41T80 chip on
the bus #1 only (there is a MAX6654 temperature sensor on the bus #0
which may be added in the future if we have a driver for that chip).
2. The i2c-sibyte.c BCM1250A SMBus controller driver now registers its
buses as numbered so that board setup is correctly applied.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Mon, 14 Jul 2008 20:38:33 +0000 (22:38 +0200)]
i2c-i801: Fix handling of error conditions
Move the check of pre-transaction and post-transaction conditions to
separate functions, and adjust them a bit. Having dedicated functions
for that ensures that errors are handled in a consistent way.
Bit HOST_BUSY of the status register is read-only, so writing to it is
certainly not going to clear it. If this bit is set then we simply
don't want to start the transaction, as it means that somebody else
(ACPI, SMM?) is already using the controller.
Improve lost-arbitration handling of PCF8584. This is necessary for
support of a currently out-of-kernel driver for Sun Microsystems E250
environmental management; perhaps others.
Signed-off-by: Eric Brower <ebrower@gmail.com> Acked-by: Dan Smolik <marvin@mydatex.cz> Signed-off-by: Jean Delvare <khali@linux-fr.org>
David Brownell [Mon, 14 Jul 2008 20:38:31 +0000 (22:38 +0200)]
i2c: Deprecate the legacy gpio drivers
The legacy pcf8574 and pcf8575 drivers should be avoided
on systems using the new gpiolib code, and generally deprecated
in the same way the legacy pca9539 driver is deprecated.
Also, correct the pca9539 deprecation to match the current name
of the preferred driver: pca953x, supporting several more chips.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Stefan Roese [Mon, 14 Jul 2008 20:38:30 +0000 (22:38 +0200)]
i2c-ibm_iic: Enable driver for all PPC4xx variants in arch/powerpc
Enable the IBM I2C driver for all PPC4xx variants by adding
"ibm,iic" to the compatible list. This way all currently available
arch/powerpc 4xx ports can make use of this driver without any changes.
Additionally all "other" compatible entries are removed since they are
not needed anymore.
Currently all 4xx PPC's have the same compatible I2C macro. If at some
time an incompatibility is detected we can take care of this with an
additional property.
Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Stefan Roese [Mon, 14 Jul 2008 20:38:30 +0000 (22:38 +0200)]
i2c-ibm_iic: Remove deprecated OCP style part
The deprecated OCP style driver part is used by the "old" arch/ppc
platform. This platform is scheduled for removal in June/July this year.
This patch now removes the OCP driver part from the IBM I2C driver.
Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Mon, 14 Jul 2008 20:38:29 +0000 (22:38 +0200)]
i2c/eeprom: Fall back to SMBus read word transactions
When I2C block reads are not supported by the underlying adapter, use
SMBus read word transactions instead of consecutive byte reads.
Reasons for this change are:
* The consecutive byte read approach is not safe on multi-master buses.
* While consecutive byte reads have less overhead if you only count the
bytes on the bus, it takes more than twice as many transactions as
with SMBus read word transactions, and each transaction has a cost:
taking and releasing the adapter mutex, and for polling drivers,
waiting for the transaction to complete.
This change yields a significant performance boost at HZ=250 with
EEPROMs on an Intel 82801 bus (basically twice as fast.)
SMBus read word transactions are widely supported so I don't expect
compatibility issues.
Jean Delvare [Mon, 14 Jul 2008 20:38:29 +0000 (22:38 +0200)]
i2c: Let bus drivers add SPD to their class
Let general purpose I2C/SMBus bus drivers add SPD to their class. Once
this is done, we will be able to tell the eeprom driver to only probe
for SPD EEPROMs and similar on these buses.
Note that I took a conservative approach here, adding I2C_CLASS_SPD to
many drivers that have no idea whether they can host SPD EEPROMs or not.
This is to make sure that the eeprom driver doesn't stop probing buses
where SPD EEPROMs or equivalent live.
So, bus driver maintainers and users should feel free to remove the SPD
class from drivers those buses never have SPD EEPROMs or they don't
want the eeprom driver to bind to them. Likewise, feel free to add the
SPD class to any bus driver I might have missed.
Jean Delvare [Mon, 14 Jul 2008 20:38:28 +0000 (22:38 +0200)]
i2c: Let framebuffer drivers set their I2C bus class to DDC
Let framebuffer drivers set their I2C bus class to DDC. Once this is
done, we will be able to tell the eeprom driver to only probe for
EDID EEPROMs on these buses.
Jochen Friedrich [Mon, 14 Jul 2008 20:38:27 +0000 (22:38 +0200)]
i2c: Add support for I2C bus on Freescale CPM1/CPM2 controllers
This driver uses the port of 2.4 code from Vitaly Bordug
<vitb@kernel.crashing.org> and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Felix Domke
(tmbinc@gmx.net) and Gillem (htoa@gmx.net) converted to an
of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and
CPM2 (MPC8272).
Signed-off-by: Jochen Friedrich <jochen@scram.de> Tested-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Mon, 14 Jul 2008 20:38:25 +0000 (22:38 +0200)]
i2c: Consistently reject unsupported transactions
Many PC SMBus host controller drivers don't properly handle the case
where they are requested to achieve a transaction they do not support.
Update them so that the consistently print a warning message and
return a single error value in this case.
Jean Delvare [Mon, 14 Jul 2008 20:38:25 +0000 (22:38 +0200)]
i2c-piix4: Various cleanups and minor fixes
The i2c-piix4 driver was used recently as a model to write a new SMBus
host controller driver and this made me realize that the code of this
old driver wasn't exactly good. So, here are many cleanups and minor
fixes to this driver, so that these minor mistakes aren't duplicated
again:
* Delete unused structure.
* Delete needless forward function declaration.
* Properly announce the SMBus host controller as we find it.
* Spell it SMBus not SMB.
* Return -EBUSY instead of -ENODEV when the I/O region is already in
use.
* Drop useless masks on the 7-bit address and the R/W bit.
* Reject block transaction requests with an invalid block length.
* Check and report block transaction replies with an invalid block
length.
* Delete a useless comment.
David Brownell [Mon, 14 Jul 2008 20:38:25 +0000 (22:38 +0200)]
i2c: Bus drivers return -Errno not -1
Tighten error paths used by various i2c adapters (mostly x86) so
they return real fault/errno codes instead of a "-1" (which is
most often interpreted as "-EPERM"). Build tested, with eyeball
review.
One minor initial goal is to have adapters consistently return
the code "-ENXIO" when addressing a device doesn't get an ACK
response, at least in the probe paths where they are already
good at stifling related logspam.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
David Brownell [Mon, 14 Jul 2008 20:38:24 +0000 (22:38 +0200)]
i2c: i2c_use_client() defends against NULL
Defend the i2c refcount calls against NULL pointers, as is important
(and conventional) for such calls. Note that none of the current
callers of i2c_use_client() use its return value.
[JD: I hate this but apparently all the other subsystems do it so...]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
David Brownell [Mon, 14 Jul 2008 20:38:24 +0000 (22:38 +0200)]
i2c: Kerneldoc for most I/O calls
Provide kerneldoc for most of the I2C and SMBus I/O calls. Add a
comment summarizing some fault reporting issues which affect the
ability to provide clean fault reports through I2C master transfer
calls. (Making it hard to precisely specify their return values...)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Mon, 14 Jul 2008 20:38:23 +0000 (22:38 +0200)]
i2c: Group bus drivers by type
The list of I2C/SMBus bus drivers is growing and it is sometimes
difficult for the users to figure out what drivers they should enable.
By grouping the drivers by type, I hope to make the selection easier.
David Brownell [Mon, 14 Jul 2008 20:38:23 +0000 (22:38 +0200)]
i2c-core: Return -Errno, not -1
More updates to the I2C stack's fault reporting: make the core stop
returning "-1" (usually "-EPERM") for all faults. Instead, pass lower
level fault code up the stack, or return some appropriate errno.
This patch happens to touch almost exclusively SMBus calls.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
David Brownell [Mon, 14 Jul 2008 20:38:22 +0000 (22:38 +0200)]
i2c: Document standard fault codes
Create Documentation/i2c/fault-codes to help standardize
fault/error code usage in the I2C stack. It turns out that
returning -1 (-EPERM) for everything was not at all helpful.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Mon, 14 Jul 2008 20:38:21 +0000 (22:38 +0200)]
i2c-nforce2: Add support for multiplexing on the Tyan S4985
Just like the Tyan S4882, the S4985 uses a multiplexer to give access
to all 16 memory module SPD EEPROMs. This specific i2c-nforce2-s4985
driver adds support for this. It is heavily based on the older
i2c-amd756-s4882 driver.
As more mainboards will use multiplexer chips, we will have to find a
way to support them without having to write a new specfic driver for
each. The recent changes to the i2c subsystem should help us, and the
new gpio subsystem might help, too.
Interrupts are enabled at the point where the DAVINCI_I2C_IVR_REG is read,
so unless an interrupt happened just at that moment, no interrupt would be
pending. Even though documentation implies you should do this, I see no
reason. If slave support is added, this read would cause a hard to
reproduce bug.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by: Kevin Hilman <khilman@mvista.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Commit f18f982ab ("sched: CPU hotplug events must not destroy scheduler
domains created by the cpusets") introduced a hotplug-related problem as
described below:
/*
* Force a reinitialization of the sched domains hierarchy. The domains
* and groups cannot be updated in place without racing with the balancing
* code, so we temporarily attach all running cpus to the NULL domain
* which will prevent rebalancing while the sched domains are recalculated.
*/
The sched-domains should be rebuilt when a CPU_DOWN ops. has been
completed, effectively either upon CPU_DEAD{_FROZEN} (upon success) or
CPU_DOWN_FAILED{_FROZEN} (upon failure -- restore the things to their
initial state). That's what update_sched_domains() also does but only
for !CPUSETS case.
With f18f982ab, sched-domains' reinitialization is delegated to
CPUSETS code:
Being called for CPU_UP_PREPARE and if its callback is called after
update_sched_domains()), it just negates all the work done by
update_sched_domains() -- i.e. a soon-to-be-offline cpu is included in
the sched-domains and that makes it visible for the load-balancer
while the CPU_DOWN ops. is in progress.
__migrate_live_tasks() moves the tasks off a 'dead' cpu (it's already
"offline" when this function is called).
try_to_wake_up() is called for one of these tasks from another CPU ->
the load-balancer (wake_idle()) picks up a "dead" CPU and places the
task on it. Then e.g. BUG_ON(rq->nr_running) detects this a bit later
-> oops.
Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com> Tested-by: Vegard Nossum <vegard.nossum@gmail.com> Cc: Paul Menage <menage@google.com> Cc: Max Krasnyansky <maxk@qualcomm.com> Cc: Paul Jackson <pj@sgi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: miaox@cn.fujitsu.com Cc: rostedt@goodmis.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] bsg: fix oops on remove
[SCSI] fusion: default MSI to disabled for SPI and FC controllers
[SCSI] ipr: Fix HDIO_GET_IDENTITY oops for SATA devices
[SCSI] mptspi: fix oops in mptspi_dv_renegotiate_work()
[SCSI] erase invalid data returned by device
Jeff Layton [Sat, 12 Jul 2008 20:48:00 +0000 (13:48 -0700)]
cifs: fix wksidarr declaration to be big-endian friendly
The current definition of wksidarr works fine on little endian arches
(since cpu_to_le32 is a no-op there), but on big-endian arches, it fails
to compile with this error:
error: braced-group within expression allowed only inside a function
The problem is that this static declaration has cpu_to_le32 embedded
within it, and that expands into a function macro. We need to use
__constant_cpu_to_le32() instead.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Cc: Steven French <sfrench@us.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jeff Layton [Sat, 12 Jul 2008 20:47:59 +0000 (13:47 -0700)]
cifs: fix inode leak in cifs_get_inode_info_unix
Try this:
mount a share with unix extensions
create a file on it
umount the share
You'll get the following message in the ring buffer:
VFS: Busy inodes after unmount of cifs. Self-destruct in 5 seconds. Have a
nice day...
...the problem is that cifs_get_inode_info_unix is creating and hashing
a new inode even when it's going to return error anyway. The first
lookup when creating a file returns an error so we end up leaking this
inode before we do the actual create. This appears to be a regression
caused by commit 0e4bbde94fdc33f5b3d793166b21bf768ca3e098.
The following patch seems to fix it for me, and fixes a minor
formatting nit as well.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: Steven French <sfrench@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Robert Richter [Sat, 12 Jul 2008 20:47:57 +0000 (13:47 -0700)]
OProfile kernel maintainership changes
Cc: Philippe Elie <phil.el@wanadoo.fr> Cc: John Levon <levon@movementarian.org> Cc: Maynard Johnson <maynardj@us.ibm.com> Cc: Richard Purdie <rpurdie@openedhand.com> Cc: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com> Cc: Jason Yeh <jason.yeh@amd.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Andres Salomon [Sat, 12 Jul 2008 20:47:54 +0000 (13:47 -0700)]
ov7670: clean up ov7670_read semantics
Cortland Setlow pointed out a bug in ov7670.c where the result from
ov7670_read() was just being checked for !0, rather than <0. This made me
realize that ov7670_read's semantics were rather confusing; it both fills
in 'value' with the result, and returns it. This is goes against general
kernel convention; so rather than fixing callers, let's fix the function.
This makes ov7670_read return <0 in the case of an error, and 0 upon
success. Thus, code like:
res = ov7670_read(...);
if (!res)
goto error;
..will work properly.
Signed-off-by: Cortland Setlow <csetlow@tower-research.com> Signed-off-by: Andres Salomon <dilinger@debian.org> Acked-by: Jonathan Corbet <corbet@lwn.net> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird
mysterious crash in sysfs. After taking an in-depth look I realized that
CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of
the serial8250_ports array.
Ouch!!!
Don't let this happen to someone else.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Acked-by: Alan Cox <alan@redhat.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch is a bugfix for how defio handles multiple processes manipulating
the same framebuffer.
Thanks to Bernard Blackham for identifying this bug.
It occurs when two applications mmap the same framebuffer and concurrently
write to the same page. Normally, this doesn't occur since only a single
process mmaps the framebuffer. The symptom of the bug is that the mapping
applications will hang. The cause is that defio incorrectly tries to add the
same page twice to the pagelist. The solution I have is to walk the pagelist
and check for a duplicate before adding. Since I needed to walk the pagelist,
I now also keep the pagelist in sorted order.
Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Bernard Blackham <bernard@largestprime.net> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Darren Jenkins [Sat, 12 Jul 2008 20:47:50 +0000 (13:47 -0700)]
drivers/isdn/i4l/isdn_common.c fix small resource leak
Coverity CID: 1356 RESOURCE_LEAK
I found a very old patch for this that was Acked but did not get applied
https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.html
There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when
copy_from_user() returns an un-copied data length (length != 0). The below
patch should be a minimally invasive fix.
Signed-off-by: Darren Jenkins <darrenrjenkins@gmailcom> Acked-by: Karsten Keil <kkeil@suse.de> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
James Bottomley [Mon, 7 Jul 2008 20:50:01 +0000 (15:50 -0500)]
[SCSI] bsg: fix oops on remove
If you do a modremove of any sas driver, you run into an oops on
shutdown when the host is removed (coming from the host bsg device).
The root cause seems to be that there's a use after free of the
bsg_class_device: In bsg_kref_release_function, this is used (to do a
put_device(bcg->parent) after bcg->release has been called. In sas (and
possibly many other things) bcd->release frees the queue which contains
the bsg_class_device, so we get a put_device on unreferenced memory.
Fix this by taking a copy of the pointer to the parent before releasing
bsg.
Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
James Bottomley [Fri, 11 Jul 2008 03:10:55 +0000 (22:10 -0500)]
[SCSI] fusion: default MSI to disabled for SPI and FC controllers
There's a fault on the FC controllers that makes them not respond
correctly to MSI. The SPI controllers are fine, but are likely to be
onboard on older motherboards which don't handle MSI correctly, so
default both these cases to disabled. Enable by setting the module
parameter mpt_msi_enable=1.
For the SAS case, enable MSI by default, but it can be disabled by
setting the module parameter mpt_msi_enable=0.
Cc: "Prakash, Sathya" <sathya.prakash@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Mark Rustad [Thu, 10 Jul 2008 19:27:11 +0000 (14:27 -0500)]
[PATCH] IPMI: return correct value from ipmi_write
This patch corrects the handling of write operations to the IPMI watchdog
to work as intended by returning the number of characters actually
processed. Without this patch, an "echo V >/dev/watchdog" enables the
watchdog if IPMI is providing the watchdog function.
Signed-off-by: Mark Rustad <MRustad@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Brian King [Fri, 11 Jul 2008 18:37:50 +0000 (13:37 -0500)]
[SCSI] ipr: Fix HDIO_GET_IDENTITY oops for SATA devices
Currently, ipr does not support HDIO_GET_IDENTITY to SATA devices.
An oops occurs if userspace attempts to send the command. Since hald
issues the command, ensure we fail the ioctl in ipr. This is a
temporary solution to the oops. Once the ipr libata EH conversion
is upstream, ipr will fully support HDIO_GET_IDENTITY.
Tested-by: Milton Miller <miltonm@bga.com> Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
libata-acpi: don't call sleeping function from invalid context
Added Targa Visionary 1000 IDE adapter to pata_sis.c
libata-acpi: filter out DIPM enable
Dave Chinner [Fri, 11 Jul 2008 07:43:55 +0000 (17:43 +1000)]
Fix reference counting race on log buffers
When we release the iclog, we do an atomic_dec_and_lock to determine if
we are the last reference and need to trigger update of log headers and
writeout. However, in xlog_state_get_iclog_space() we also need to
check if we have the last reference count there. If we do, we release
the log buffer, otherwise we decrement the reference count.
But the compare and decrement in xlog_state_get_iclog_space() is not
atomic, so both places can see a reference count of 2 and neither will
release the iclog. That leads to a filesystem hang.
Close the race by replacing the atomic_read() and atomic_dec() pair with
atomic_add_unless() to ensure that they are executed atomically.
Signed-off-by: Dave Chinner <david@fromorbit.com> Reviewed-by: Tim Shimmin <tes@sgi.com> Tested-by: Eric Sandeen <sandeen@sandeen.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some BIOSen enable DIPM via _GTF which causes command timeouts under
certain configuration. This didn't occur on 2.6.25 because 2.6.25
defaulted to SRST, so _GTF wasn't executed during boot probe, so ahci
host reset disabled DIPM and as _GTF wasn't executed after SRST, DIPM
wasn't enabled. On 2.6.26, hardreset is used during probe and after
probe _GTF is executed enabling DIPM and thus the failures.
This patch could theoretically disable DIPM on machines which used to
have it enabled on 2.6.25 but AFAIK ahci is currently the only driver
which uses SATA ACPI hierarchy (_SDD) and as the host reset would have
always disabled DIPM, this shouldn't happen.
Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Paul Gortmaker [Fri, 11 Jul 2008 00:30:48 +0000 (17:30 -0700)]
rtc: fix reported IRQ rate for when HPET is enabled
The IRQ rate reported back by the RTC is incorrect when HPET is enabled.
Newer hardware that has HPET to emulate the legacy RTC device gets this value
wrong since after it sets the rate, it returns before setting the variable
used to report the IRQ rate back to users of the device -- so the set rate and
the reported rate get out of sync.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Brownell <david-b@pacbell.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (27 commits)
tun: Persistent devices can get stuck in xoff state
xfrm: Add a XFRM_STATE_AF_UNSPEC flag to xfrm_usersa_info
ipv6: missed namespace context in ipv6_rthdr_rcv
netlabel: netlink_unicast calls kfree_skb on error path by itself
ipv4: fib_trie: Fix lookup error return
tcp: correct kcalloc usage
ip: sysctl documentation cleanup
Documentation: clarify tcp_{r,w}mem sysctl docs
netfilter: nf_nat_snmp_basic: fix a range check in NAT for SNMP
netfilter: nf_conntrack_tcp: fix endless loop
libertas: fix memory alignment problems on the blackfin
zd1211rw: stop beacons on remove_interface
rt2x00: Disable synchronization during initialization
rc80211_pid: Fix fast_start parameter handling
sctp: Add documentation for sctp sysctl variable
ipv6: fix race between ipv6_del_addr and DAD timer
irda: Fix netlink error path return value
irda: New device ID for nsc-ircc
irda: via-ircc proper dma freeing
sctp: Mark the tsn as received after all allocations finish
...
Max Krasnyansky [Thu, 10 Jul 2008 23:59:11 +0000 (16:59 -0700)]
tun: Persistent devices can get stuck in xoff state
The scenario goes like this. App stops reading from tun/tap.
TX queue gets full and driver does netif_stop_queue().
App closes fd and TX queue gets flushed as part of the cleanup.
Next time the app opens tun/tap and starts reading from it but
the xoff state is not cleared. We're stuck.
Normally xoff state is cleared when netdev is brought up. But
in the case of persistent devices this happens only during
initial setup.
The fix is trivial. If device is already up when an app opens
it we clear xoff state and that gets things moving again.
Signed-off-by: Max Krasnyansky <maxk@qualcomm.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
xfrm: Add a XFRM_STATE_AF_UNSPEC flag to xfrm_usersa_info
Add a XFRM_STATE_AF_UNSPEC flag to handle the AF_UNSPEC behavior for
the selector family. Userspace applications can set this flag to leave
the selector family of the xfrm_state unspecified. This can be used
to to handle inter family tunnels if the selector is not set from
userspace.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Hutchings [Thu, 10 Jul 2008 23:52:52 +0000 (16:52 -0700)]
ipv4: fib_trie: Fix lookup error return
In commit a07f5f508a4d9728c8e57d7f66294bf5b254ff7f "[IPV4] fib_trie: style
cleanup", the changes to check_leaf() and fn_trie_lookup() were wrong - where
fn_trie_lookup() would previously return a negative error value from
check_leaf(), it now returns 0.
Now fn_trie_lookup() doesn't appear to care about plen, so we can revert
check_leaf() to returning the error value.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Tested-by: William Boughton <bill@boughton.de> Acked-by: Stephen Heminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Take out the confusing language in tcp_frto, and organize the
undocumented values.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: David S. Miller <davem@davemloft.net>
"The register %ecx looks innocent but is very important here. The disassembly:
mov %edx,%ecx
shr $0x2,%ecx
rep stos %eax,%es:(%edi) <-- the fault
So %ecx has been loaded from %edx... which is 0x6b6b6b6b/POISON_FREE.
(0x6b6b6b6b >> 2 == 0x1adadada.)
%ecx is the counter for the memset, from here:
memset(object, 0, c->objsize);
i.e. %ecx was loaded from c->objsize, so "c" must have been freed.
Where did "c" come from? Uh-oh...
c = get_cpu_slab(s, smp_processor_id());
This looks like it has very much to do with CPU hotplug/unplug. Is
there a race between SLUB/hotplug since the CPU slab is used after it
has been freed?"
Good analysis.
Yeah, it's possible that a caller of kmem_cache_alloc() -> slab_alloc()
can be migrated on another CPU right after local_irq_restore() and
before memset(). The inital cpu can become offline in the mean time (or
a migration is a consequence of the CPU going offline) so its
'kmem_cache_cpu' structure gets freed ( slab_cpuup_callback).
At some point of time the caller continues on another CPU having an
obsolete pointer...
Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
exec'ing an ELF without a PT_GNU_STACK program header should default to an
executable stack; but this got broken by the unlimited argv feature because
stack vma is now created before the right personality has been established:
so breaking old binaries using nested function trampolines.
Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
vm_flags used to be set, before the mprotect_fixup. Checking through
our existing VM_flags, none would have changed since insert_vm_struct:
so this seems safer than finding a way through the personality labyrinth.
projects / linux-2.6-omap-h63xx.git / log