linux-toradex.git/drivers, branch v2.6.16.53

ide: clear bmdma status in ide_intr() for ICHx controllers (revised #4)

2007-07-22T16:05:44+00:00

patch 1/2 (revised):
- Fix drive->waiting_for_dma to work with CDB-intr devices.
- Do the dma status clearing in ide_intr() and add a new
  hwif->ide_dma_clear_irq for Intel ICHx controllers.

Revised per Alan, Sergei and Bart's advice.

Patch against 2.6.20-rc6. Tested ok on my ICH4 and pdc20275 adapters.
Please review/apply, thanks.

Signed-off-by: Albert Lee 
Signed-off-by: Adrian Bunk

8139too.c: fix netpoll deadlock

2007-07-22T16:03:53+00:00

fix deadlock in the 8139too driver: poll handlers should never forcibly
enable local interrupts, because they might be used by netpoll/printk
from IRQ context.

  =================================
  [ INFO: inconsistent lock state ]
  2.6.19 #11
  ---------------------------------
  inconsistent {softirq-on-W} -> {in-softirq-W} usage.
  swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
   (&npinfo->poll_lock){-+..}, at: [] net_rx_action+0x64/0x1de
  {softirq-on-W} state was registered at:
    [] mark_lock+0x5b/0x39c
    [] mark_held_locks+0x4b/0x68
    [] trace_hardirqs_on+0x115/0x139
    [] rtl8139_poll+0x3d7/0x3f4
    [] netpoll_poll+0x82/0x32f
    [] netpoll_send_skb+0xc9/0x12f
    [] netpoll_send_udp+0x253/0x25b
    [] write_msg+0x40/0x65
    [] __call_console_drivers+0x45/0x51
    [] _call_console_drivers+0x5d/0x61
    [] release_console_sem+0x11f/0x1d8
    [] register_console+0x1ac/0x1b3
    [] init_netconsole+0x55/0x67
    [] init+0x9a/0x24e
    [] kernel_thread_helper+0x7/0x10
    [] 0xffffffff
  irq event stamp: 819992
  hardirqs last  enabled at (819992): [] net_rx_action+0x39/0x1de
  hardirqs last disabled at (819991): [] net_rx_action+0x141/0x1de
  softirqs last  enabled at (817552): [] __do_softirq+0xa3/0xa8
  softirqs last disabled at (819987): [] do_softirq+0x5b/0xc9

  other info that might help us debug this:
  no locks held by swapper/1.

  stack backtrace:
   [] dump_trace+0x63/0x1e8
   [] show_trace_log_lvl+0x19/0x2e
   [] show_trace+0x12/0x14
   [] dump_stack+0x14/0x16
   [] print_usage_bug+0x23c/0x246
   [] mark_lock+0x108/0x39c
   [] __lock_acquire+0x361/0x9ed
   [] lock_acquire+0x56/0x72
   [] _spin_lock+0x35/0x42
   [] net_rx_action+0x64/0x1de
   [] __do_softirq+0x52/0xa8
   [] do_softirq+0x5b/0xc9
   [] irq_exit+0x3c/0x48
   [] do_IRQ+0xa4/0xbd
   [] common_interrupt+0x2e/0x34
   [] vprintk+0x2c0/0x309
   [] printk+0x1b/0x1d
   [] init+0x80/0x24e
   [] kernel_thread_helper+0x7/0x10
   =======================

Signed-off-by: Ingo Molnar 
Signed-off-by: Adrian Bunk

ieee1394: forgotten dereference...

2007-07-22T16:01:20+00:00

Going through the string and waiting for _pointer_ to become '\0'
is not what the authors meant...

Signed-off-by: Al Viro 
Acked-by: Ben Collins 
Signed-off-by: Adrian Bunk

[SPARC]: Linux always started with 9600 8N1

2007-07-22T15:44:18+00:00

The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in
my case). This was because mode_prop remained "ttyX-mode" (expected:
"ttya-mode") due to the constness of string literals when used with
"char *". Since there is no "ttyX-mode" property in the PROM, Linux
always used the default 9600.

[ Investigation of the suncore.s assembler reveals that gcc optimizied
  away the stores, yet did not emit a warning, which is a pretty
  anti-social thing to do and is the only reason this bug lived for
  so long -DaveM ]

Signed-off-by: Jan Engelhardt 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[NETPOLL]: Remove CONFIG_NETPOLL_RX

2007-05-22T22:43:37+00:00

Get rid of the CONFIG_NETPOLL_RX option completely since all the
dependencies have been removed long ago...

Signed-off-by: Sergei Shtylyov 
Acked-by: Jeff Garzik 
Acked-by: Matt Mackall 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

hwmon/w83627ehf: Don't redefine REGION_OFFSET

2007-05-03T23:35:12+00:00

On ia64, kernel headers define REGION_OFFSET so we can't use that.
Reported by Andrew Morton.

Signed-off-by: Jean Delvare 
Signed-off-by: Adrian Bunk

Char: icom, mark init as devinit

2007-04-25T23:35:22+00:00

Two functions are called from __devinit context, but they are marked as
__init. Fix this.

Signed-off-by: Jiri Slaby 
Signed-off-by: Adrian Bunk

tty_io: fix race in master pty close/slave pty close path

2007-04-20T22:18:01+00:00

This patch fixes a possible race that leads to double freeing an idr index.
 When the master begin to close, release_dev() is called and then
pty_close() is called:

        if (tty->driver->close)
                tty->driver->close(tty, filp);

This is done without helding any locks other than BKL.  Inside pty_close(),
being a master close, the devpts entry will be removed:

#ifdef CONFIG_UNIX98_PTYS
                if (tty->driver == ptm_driver)
                        devpts_pty_kill(tty->index);
#endif

But devpts_pty_kill() will call get_node() that may sleep while waiting for
&devpts_root->d_inode->i_sem.  When this happens and the slave is being
opened, tty_open() just found the driver and index:

        driver = get_tty_driver(device, &index);
        if (!driver) {
                mutex_unlock(&tty_mutex);
                return -ENODEV;
        }

This part of the code is already protected under tty_mute.  The problem is
that the slave close already got an index.  Then init_dev() is called and
blocks waiting for the same &devpts_root->d_inode->i_sem.

When the master close resumes, it removes the devpts entry, and the
relation between idr index and the tty is gone.  The master then sleeps
waiting for the tty_mutex on release_dev().

Slave open resumes and found no tty for that index.  As result, a NULL tty
is returned and init_dev() doesn't flow to fast_track:

        /* check whether we're reopening an existing tty */
        if (driver->flags & TTY_DRIVER_DEVPTS_MEM) {
                tty = devpts_get_tty(idx);
                if (tty && driver->subtype == PTY_TYPE_MASTER)
                        tty = tty->link;
        } else {
                tty = driver->ttys[idx];
        }
        if (tty) goto fast_track;

The result of this, is that a new tty will be created and init_dev() returns
sucessfull. After returning, tty_mutex is dropped and master close may resume.

Master close finds it's the only use and both sides are closing, then releases
the tty and the index. At this point, the idr index is free, but slave still
has it.

Slave open then calls pty_open() and finds that tty->link->count is 0,
because there's no master and returns error.  Then tty_open() calls
release_dev() which executes without any warning, as it was a case of last
slave close when the master is already closed (master->count == 0,
slave->count == 1).  The tty is then released with the already released idr
index.

This normally would only issue a warning on idr_remove() but in case of a
customer's critical application, it's never too simple:

thread1: opens master, gets index X
thread1: begin closing master
thread2: begin opening slave with index X
thread1: finishes closing master, index X released
thread3: opens master, gets index X, just released
thread2: fails opening slave, releases index X         <----
thread4: opens master, gets index X, init_dev() then find an already in use
         and healthy tty and fails

If no more indexes are released, ptmx_open() will keep failing, as the
first free index available is X, and it will make init_dev() fail because
you're trying to "reopen a master" which isn't valid.

The patch notices when this race happens and make init_dev() fail
imediately.  The init_dev() function is called with tty_mutex held, so it's
safe to continue with tty till the end of function because release_dev()
won't make any further changes without grabbing the tty_mutex.

Without the patch, on some machines it's possible get easily idr warnings
like this one:

idr_remove called for id=15 which is not allocated.
 [] idr_remove+0x139/0x170
 [] release_mem+0x182/0x230
 [] release_dev+0x4b7/0x700
 [] tty_ldisc_enable+0x27/0x30
 [] init_dev+0x254/0x580
 [] check_tty_count+0x14/0xb0
 [] tty_open+0x1c5/0x340
 [] tty_open+0x0/0x340
 [] chrdev_open+0xaf/0x180
 [] open_namei+0x8c/0x760
 [] chrdev_open+0x0/0x180
 [] __dentry_open+0xc9/0x210
 [] do_filp_open+0x5c/0x70
 [] get_unused_fd+0x61/0xd0
 [] do_sys_open+0x53/0x100
 [] sys_open+0x27/0x30
 [] syscall_call+0x7/0xb

using this test application available on:
 http://www.ruivo.org/~aris/pty_sodomizer.c

Signed-off-by: Aristeu Sergio Rozanski Filho 
Signed-off-by: Adrian Bunk

hwmon/w83627ehf: Fix the fan5 clock divider write

2007-04-19T23:43:12+00:00

Users have been complaining about the w83627ehf driver flooding their logs
with debug messages like:

w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128

or:

w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8

The reason is that we failed to actually write the LSB of the encoded clock
divider value for that fan, causing the next read to report the same old value
again and again.

Additionally, the fan number was improperly reported, making the bug harder to
find.

Signed-off-by: Jean Delvare 
Signed-off-by: Adrian Bunk

[SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something.

2007-04-19T23:31:17+00:00

We only map DMA when cmd->request_bufflen is non-zero for non-sg
buffers, we thus should make the same check when unmapping.

Based upon a report from Pasi Pirhonen.

Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk