The pci channel state is currently uninitialized, thus there are two ways
of indicating that "everything's OK": 0 and 1. This is a bit of a burden.
If a devce driver wants to check if the pci channel is in a working or a
disconnected state, the driver writer must perform checks similar to
if((pdev->error_state != 0) &&
(pdev->error_state != pci_channel_io_normal)) {
whatever();
}
which is rather akward. The first check is needed because stuct pci_dev is
inited to all-zeros. The scond is needed because the error recovery will
set the state to pci_channel_io_normal (which is not zero).
This patch fixes this awkwardness.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch fixes several problems:
- pmac_backlight_key() is called under interrupt context, and therefore
can't use mutexes or semaphores, so defer the backlight level for
later, as it's not critical (original code by Aristeu S. Rozanski F.
<aris@valeta.org>).
- Add exports for functions that might be called from modules
- Fix Kconfig depdencies on PMAC_BACKLIGHT.
- Fix locking issues on calls from inside the driver (reported by
Aristeu S. Rozanski F., too)
- Fix wrong calculation of backlight values in some of the drivers
- Replace pmac_backlight_key_up/down by inline functions
[akpm@osdl.org: fix function prototypes]
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Aristeu S. Rozanski F. <aris@valeta.org>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The SMU driver tries to map an interrupt from the device-tree before the
interrupt controllers in the machine have been enumerated. This doesn't work
properly and cause machines like the Quad g5 to fail booting later on when
some drivers waits endlessly for an SMU request to complete. This is the
second problem preventing boot on the Quad g5. This fixes it and also makes
the SMU driver a bit more resilient to not having an interrupt.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch slightly reworks the new irq code to fix a small design error. I
removed the passing of the trigger to the map() calls entirely, it was not a
good idea to have one call do two different things. It also fixes a couple of
corner cases.
Mapping a linux virtual irq to a physical irq now does only that. Setting the
trigger is a different action which has a different call.
The main changes are:
- I no longer call host->ops->map() for an already mapped irq, I just return
the virtual number that was already mapped. It was called before to give an
opportunity to change the trigger, but that was causing issues as that could
happen while the interrupt was in use by a device, and because of the
trigger change, map would potentially muck around with things in a racy way.
That was causing much burden on a given's controller implementation of
map() to get it right. This is much simpler now. map() is only called on
the initial mapping of an irq, meaning that you know that this irq is _not_
being used. You can initialize the hardware if you want (though you don't
have to).
- Controllers that can handle different type of triggers (level/edge/etc...)
now implement the standard irq_chip->set_type() call as defined by the
generic code. That means that you can use the standard set_irq_type() to
configure an irq line manually if you wish or (though I don't like that
interface), pass explicit trigger flags to request_irq() as defined by the
generic kernel interfaces. Also, using those interfaces guarantees that
your controller set_type callback is called with the descriptor lock held,
thus providing locking against activity on the same interrupt (including
mask/unmask/etc...) automatically. A result is that, for example, MPIC's
own map() implementation calls irq_set_type(NONE) to configure the hardware
to the default triggers.
- To allow the above, the irq_map array entry for the new mapped interrupt
is now set before map() callback is called for the controller.
- The irq_create_of_mapping() (also used by irq_of_parse_and_map()) function
for mapping interrupts from the device-tree now also call the separate
set_irq_type(), and only does so if there is a change in the trigger type.
- While I was at it, I changed pci_read_irq_line() (which is the helper I
would expect most archs to use in their pcibios_fixup() to get the PCI
interrupt routing from the device tree) to also handle a fallback when the
DT mapping fails consisting of reading the PCI_INTERRUPT_PIN to know wether
the device has an interrupt at all, and the the PCI_INTERRUPT_LINE to get an
interrupt number from the device. That number is then mapped using the
default controller, and the trigger is set to level low. That default
behaviour works for several platforms that don't have a proper interrupt
tree like Pegasos. If it doesn't work for your platform, then either
provide a proper interrupt tree from the firmware so that fallback isn't
needed, or don't call pci_read_irq_line()
- Add back a bit that got dropped by my main rework patch for properly
clearing pending IPIs on pSeries when using a kexec
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Daniel Ritz <daniel.ritz-ml@swissonline.ch> says:
The acpi driver suspend/resume patches that went in recently caused a regression
on my box (toshiba tecra 8000 laptop): after resume from swsusp the fan turns on
keeping blowing cold air out of my notebook. before the patches, the fan was off
and would only make noise when required. it's the same thing described in
bugzilla.kernel.org #5000. the acpi suspend/resume patches or at least parts of
them originate in this bug. now the last patch in the report (attach id 8438)
actually fixes the problem - for me and the reporter. this is a trimmed down
version of that patch.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Len Brown <len.brown@intel.com>
Cc: Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk>
Cc: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
During early MD setup (superblock reading), we don't have a personality yet.
But the error-handling code tries to dereference mddev->pers. Fix.
Acked-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is generally useful, but particularly helps see if it is the same sector
that always needs correcting, or different ones.
[akpm@osdl.org: fix printk warnings]
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ioctl requires CAP_SYS_ADMIN, so sysfs should too. Note that we don't
require CAP_SYS_ADMIN for reading attributes even though the ioctl does.
There is no reason to limit the read access, and much of the information is
already available via /proc/mdstat
Cc: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some places we use number (0660) someplaces names (S_IRUGO). Change all
numbers to be names, and change 0655 to be what it should be.
Also make some formatting more consistent.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Though it rarely matters, we should be using 's' rather than r1_bio->sector
here.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The comment gives more details, but I didn't quite have the sequencing write,
so there was room for races to leave bits unset in the on-disk bitmap for
short periods of time.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When a device is unplugged, requests are moved from one or two (depending on
whether a bitmap is in use) queues to the main request queue.
So whenever requests are put on either of those queues, we should make sure
the raid5 array is 'plugged'. However we don't. We currently plug the raid5
queue just before putting requests on queues, so there is room for a race. If
something unplugs the queue at just the wrong time, requests will be left on
the queue and nothing will want to unplug them. Normally something else will
plug and unplug the queue fairly soon, but there is a risk that nothing will.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We introduced 'io_sectors' recently so we could count the sectors that causes
io during resync separate from sectors which didn't cause IO - there can be a
difference if a bitmap is being used to accelerate resync.
However when a speed is reported, we find the number of sectors processed
recently by subtracting an oldish io_sectors count from a current
'curr_resync' count. This is wrong because curr_resync counts all sectors,
not just io sectors.
So, add a field to mddev to store the curren io_sectors separately from
curr_resync, and use that in the calculations.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When an array is started we start one or two threads (two if there is a
reshape or recovery that needs to be completed).
We currently start these *before* the array is completely set up and in
particular before queue->queuedata is set. If the thread actually starts
very quickly on another CPU, we can end up dereferencing queue->queuedata
and oops.
This patch also makes sure we don't try to start a recovery if a reshape is
being restarted.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This has to be done in ->load_super, not ->validate_super
Without this, hot-adding devices to an array doesn't always
work right - though there is a work around in mdadm-2.5.2 to
make this less of an issue.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I have reports of a problem with raid5 which turns out to be because the raid5
device gets stuck in a 'plugged' state. This shouldn't be able to happen as
3msec after it gets plugged it should get unplugged. However it happens
none-the-less. This patch fixes the problem and is a reasonable thing to do,
though it might hurt performance slightly in some cases.
Until I can find the real problem, we should probably have this workaround in
place.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
screen_info.h doesn't have anything to do with the tty layer and shouldn't be
included by tty.h. This patches removes the include and modifies all users to
directly include screen_info.h. struct screen_info is mainly used to
communicate with the console drivers in drivers/video/console. Note that this
patch touches every arch and I have no way of testing it. If there is a
mistake the worst thing that will happen is a compile error.
[akpm@osdl.org: fix arm build]
[akpm@osdl.org: fix alpha build]
Signed-off-by: Jon Smirl <jonsmir@gmail.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
allows all of the framebuffer and VT console drivers to remove their
dependency on tty.h.
[akpm@osdl.org: fix alpha build]
Signed-off-by: Jon Smirl <jonsmir@gmail.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix the warnings about the section mismatches for __init* in the HiSax
driver.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Use release_firmware() to free requested resources.
According to Documentation/firmware_class/README the request_firmware()
call should be followed by a release_firmware(). Some drivers do not
however free the firmware previously allocated with request_firmware().
This patch tries to fix this by making sure that release_firmware() is used
as expected.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The code really means to mask off the high bits, not assign 0xff.
Signed-off-by: Jens Axboe <axboe@suse.de>
Cc: Marcus Meissner <meissner@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It's useful to be able to turn off CONFIG_HOTPLUG for compile-coverage testing
and for section-checking coverage. But a few things go and select
CONFIG_HOTPLUG, making it a royal PITA to turn the thing off.
It's only turnable offable if CONFIG_EMBEDDED anyway. So let's make those
things depend on HOTPLUG, not select it.
Cc: Greg KH <greg@kroah.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
We will reimplement halt-clearing later, when we have periodic
housekeeping routines in place. This will do as a temporary fix, the
EPIPE case has not yet been seen.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
An assert statement near the start of handle_irq_noise in the softmac
version of bcm43xx_main.c is there to protect against out of bound
addressing using variable bcm->noisecalc.nr_samples. The arrays in
question have a dimension of 8, thus the value must be < 8.
Signed-Off-By: Larry.Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Replace acpi_in_resume with a more general hack
to check irqs_disabled() on any kmalloc() from ACPI.
While setting (system_state != SYSTEM_RUNNING) on resume
seemed more general, Andrew Morton preferred this approach.
http://bugzilla.kernel.org/show_bug.cgi?id=3469
Make acpi_os_allocate() into an inline function to
allow /proc/slab_allocators to work.
Delete some memset() that could fault on allocation failure.
Signed-off-by: Len Brown <len.brown@intel.com>
cm_sbs_sem is being downed (via acpi_ac_init->acpi_lock_ac_dir) before it is
initialised, with grave results.
- Make it a mutex
- Initialise it
- Make it static
- Clean other stuff up.
Thanks to Paul Drynoff <pauldrynoff@gmail.com> for reporting and testing.
Cc: Rich Townsend <rhdt@bartol.udel.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
No need for video to be always in
No need for ACPI dock driver to be always in
No need for smart battery driver to be always in
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
HOTPLUG_PCI_ACPI depends on ACPI_DOCK
ACPI_IBM_DOCK depends on ACPI_DOCK=n
ACPI_DOCK is EXPERIMENTAL, though that doesn't seem to mean much
Signed-off-by: Len Brown <len.brown@intel.com>
Fix http://bugzilla.kernel.org/show_bug.cgi?id=6716
Doing a sysrq over a serial line into an SMP machine presently deadlocks.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The following patch gets rid of CONFIG_TSI108_BRIDGE. I add UPIO_TSI to
handle IIR and IER register in serial_in and serial_out.
(1) the reason to rewrite serial_in:
TSI108 rev Z1 version ERRATA. Reading the UART's Interrupt
Identification Register (IIR) clears the Transmit Holding Register
Empty (THRE) and Transmit buffer Empty (TEMP) interrupts even if they
are not enabled in the Interrupt Enable Register (IER). This leads to
loss of the interrupts. Interrupts are not cleared when reading UART
registers as 32-bit word.
(2) the reason to rewrite serial_out:
Check for UART_IER_UUE bit in the autoconfig routine. This section
of autoconfig is excluded for Tsi108/109 because bits 7 and 6 are
reserved for internal use. They are R/W bits. In addition to
incorrect identification, changing these bits (from 00) will make
Tsi108/109 UART non-functional.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The patch below fixes serial console hangs as seen on IP22
machines. Typically, while booting, the machine hangs for ~1 minute
displaying "INIT: ", then the same thing happens again when init
enters in the designated runlevel and finally the getty process on
ttyS0 hangs indefinitely (though strace'ing it helps).
strace (-e raw=ioctl, otherwise the ioctl() translation is utterly
bogus) reveals that getty hangs on ioctl() 0x540f which happens to be
TCSETSW (I saw it hang on another console ioctl() but couldn't
reproduce that one).
A diff between ip22zilog and sunzilog revealed the following
differences:
1. the channel A flag being set on up.port.flags instead of up.flags
2. the channel A flag being set on what is marked as being channel B
3. sunzilog has a call to uart_update_timeout(port, termios->c_cflag, baud);
at the end of sunzilog_set_termios(), which ip22zilog lacks (on
purpose ?)
The patch below addresses point 1 and fixes the serial console hangs
just fine. However point 2 should be investigated by someone familiar
with the IP22 Zilog; it's probably OK as is but even if it is, a
comment in ip22zilog.c is badly needed.
Point 3 is left as an exercise for whoever feels like digging into
ip22zilog :)
These are the main obvious differences between ip22zilog and
sunzilog. Newer versions of sunzilog (Linus's git tree as of today)
are more close to ip22zilog as the sbus_{write,read}b have been
changed into simple {write,read}b, which shrinks the diff by a fair
amount. Resyncing both drivers should be doable in a few hours time
now for someone familiar with the IP22 Zilog hardware.
Signed-off-by: Julien BLACHE <jb@jblache.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the following compilation error in the dz serial driver that got
introduced with the "kernel console should send CRLF not LFCR" change.
CC drivers/serial/dz.o
drivers/serial/dz.c: In function 'dz_console_putchar':
drivers/serial/dz.c:679: error: 'uport' undeclared (first use in this function)
drivers/serial/dz.c:679: error: (Each undeclared identifier is reported only once
drivers/serial/dz.c:679: error: for each function it appears in.)
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Linux mutexes and the debug code that that reference
acpi_os_get_thread_id() are happy with 0.
But the AML mutexes in exmutex.c expect a unique non-zero
number for each thread - as they track this thread_id
to permit the mutex re-entrancy defined by the ACPI spec.
http://bugzilla.kernel.org/show_bug.cgi?id=6687
Signed-off-by: Len Brown <len.brown@intel.com>
Added the ACPI_PACKED_POINTERS_NOT_SUPPORTED macro to
support C compilers that do not allow the initialization
of address pointers within packed structures - even though
the hardware itself may support misaligned transfers. Some
of the debug data structures are packed by default to
minimize size.
Added an error message for the case where
acpi_os_get_thread_id() returns zero. A non-zero value is
required by the core ACPICA code to ensure the proper
operation of AML mutexes and recursive control methods.
The DSDT is now the only ACPI table that determines whether
the AML interpreter is in 32-bit or 64-bit mode. Not really
a functional change, but the hooks for per-table 32/64
switching have been removed from the code. A clarification
to the ACPI specification is forthcoming in ACPI 3.0B.
Fixed a possible leak of an Owner ID in the error
path of tbinstal.c acpi_tb_init_table_descriptor() and
migrated all table OwnerID deletion to a single place in
acpi_tb_uninstall_table() to correct possible leaks when using
the acpi_tb_delete_tables_by_type() interface (with assistance
from Lance Ortiz.)
Fixed a problem with Serialized control methods where the
semaphore associated with the method could be over-signaled
after multiple method invocations.
Fixed two issues with the locking of the internal
namespace data structure. Both the Unload() operator and
acpi_unload_table() interface now lock the namespace during
the namespace deletion associated with the table unload
(with assistance from Linn Crosetto.)
Fixed problem reports (Valery Podrezov) integrated: -
Eliminate unnecessary memory allocation for CreateXxxxField
http://bugzilla.kernel.org/show_bug.cgi?id=5426
Fixed problem reports (Fiodor Suietov) integrated: -
Incomplete cleanup branches in AcpiTbGetTableRsdt (BZ 369)
- On Address Space handler deletion, needless deactivation
call (BZ 374) - AcpiRemoveAddressSpaceHandler: validate
Device handle parameter (BZ 375) - Possible memory leak,
Notify sub-objects of Processor, Power, ThermalZone (BZ
376) - AcpiRemoveAddressSpaceHandler: validate Handler
parameter (BZ 378) - Minimum Length of RSDT should be
validated (BZ 379) - AcpiRemoveNotifyHandler: return
AE_NOT_EXIST if Processor Obj has no Handler (BZ (380)
- AcpiUnloadTable: return AE_NOT_EXIST if no table of
specified type loaded (BZ 381)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Currently struct scsi_cmnd has various fields that are used to backup
original data after the corresponding fields have been overridden for
EH commands. This means drivers can easily get at it and misuse it.
Due to the old_ naming this doesn't happen for most of them, but two
that have different names have been used wrong a lot (see previous
patch). Another downside is that they unessecarily bloat the scsi_cmnd
size.
This patch moves them onstack in scsi_send_eh_cmnd to fix those two
issues aswell as allowing future EH fixes like moving the EH command
submissions to use SG lists like everything else.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
