| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Make the mmc bus uevent callback look like all other subsystems.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
| |
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that the sdio_bus must be registered before any SDIO
drivers are registered against it otherwise the kernel sulks. Because
the sdio_bus registration happens through module_init (equivalent to
device_initcall), then any SDIO
drivers linked before the SDIO core code in the kernel will be initialized
first.
Upcoming SDIO function drivers are likely to be located outside the
drivers/mmc directory as it is common practice to group drivers according
to their function rather than the bus they use. SDIO drivers are therefore
likely to appear at random location in the kernel link.
To make sure the sdio_bus is always initialized before any SDIO drivers,
let's move the MMC init to the subsys_initcall level.
Signed-off-by: Nicolas Pitre <npitre@mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
| |
Add a more clean separation between global, common CIS information
and the function specific one as we need the common information in
places where no specific function is specified.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
|
| |
This way those tuples that the core cares about are consumed by the core
code, and tuples that only function drivers might make sense of are
available to drivers.
Signed-off-by: Nicolas Pitre <npitre@mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
| |
Signed-off-by: Nicolas Pitre <npitre@mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
| |
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
| |
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
| |
Like many other buses, the devices (functions) on the SDIO bus
must be enabled before they can be used. Add functions that allow
drivers to do so.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
| |
Add command wrappers that simplify register access from SDIO
function drivers.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
| |
Add basic driver handling to the SDIO device model.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
| |
Add the sdio bus type and basic device handling.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
| |
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
| |
Really basic init sequence for SDIO cards.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
| |
This kind of transfer is not supported, so don't advertise it and make it
fail early.
Signed-off-by: Marc Pignat <marc.pignat@hevs.ch>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
| |
Some printk:s were missing an explicit level.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
| |
The MMC_DATA_MULTI flag never had a proper definition of what it
means, so remove it and let the drivers check the block count in
the request.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
| |
Remove the BYTEBLOCK capability and let the broken hosts fail the
requests with -EINVAL instead.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
| |
The write parameter in mmc_set_data_timeout() is redundant as the
data structure contains information about the direction of the
transfer.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
| |
Make sure we do not try to parse a structure we do not
understand.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
| |
Now that we use "normal" error codes, improve the reporting and response
to error codes in the core.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
| |
Convert the MMC layer to use standard error codes and not its own,
incompatible values.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a desparate attempt to fix the suspend/resume problem on Andrews
VAIO I added a workaround which enforced the broadcast of the oneshot
timer on resume. This was actually resolving the problem on the VAIO
but was just a stupid workaround, which was not tackling the root
cause: the assignement of lower idle C-States in the ACPI processor_idle
code. The cpuidle patches, which utilize the dynamic tick feature and
go faster into deeper C-states exposed the problem again. The correct
solution is the previous patch, which prevents lower C-states across
the suspend/resume.
Remove the enforcement code, including the conditional broadcast timer
arming, which helped to pamper over the real problem for quite a time.
The oneshot broadcast flag for the cpu, which runs the resume code can
never be set at the time when this code is executed. It only gets set,
when the CPU is entering a lower idle C-State.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
device_suspend() calls ACPI suspend functions, which seems to have undesired
side effects on lower idle C-states. It took me some time to realize that
especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
show this effect. I'm quite sure that other bug reports against suspend/resume
about turning the system into a brick have the same root cause.
After fishing in the dark for quite some time, I realized that removing the ACPI
processor module before suspend (this removes the lower C-state functionality)
made the problem disappear. Interestingly enough the propability of having a
bricked box is influenced by various factors (interrupts, size of the ram image,
...). Even adding a bunch of printks in the wrong places made the problem go
away. The previous periodic tick implementation simply pampered over the
problem, which explains why the dyntick / clockevents changes made this more
prominent.
We avoid complex functionality during the boot process and we have to do the
same during suspend/resume. It is a similar scenario and equaly fragile.
Add suspend / resume functions to the ACPI processor code and disable the lower
idle C-states across suspend/resume. Fall back to the default idle
implementation (halt) instead.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: suspend: consolidate handling of Sx states addendum
ACPI: suspend: consolidate handling of Sx states.
ACPI: video: remove dmesg spam
ACPI: video: _DOS=0 by default to prevent hotkey hang
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Make the S0 state be always reported as supported
Signed-off: Frans Pop <elendil@planet.nl>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Recent changes to sleep initialization in ACPI dropped reporting of supported Sx
states above S3. Fix that and also move S5 init into same file as other Sx.
The only functional change is adding printk() for S4 and S5 cases.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
|
| |\ \
| | |/
| |/| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
i am actually heavily using the ACPI video extension for my Thinkpad X61
Tablet. I have bound the input events triggered by the brightness
up/down keys to a simple
echo <value> > /sys/class/backlight/acpi_video1/brightness
but everytime the event is triggered and acpi_video_device_lcd_set_level()
is called i got a notificication in my kernel log like:
set_level status: 0
set_level status: 0
set_level status: 0
set_level status: 0
...
Signed-off-by: Maik Broemme <mbroemme@plusserver.de>
Signed-off-by: Len Brown <len.brown@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the past, the Linux/ACPI video driver invoked _DOS
(Display Output Switch) with the parameter 1
to tell the BIOS to switch the video output display for us.
But this conflicts with Linux native graphics drivers,
and can cause all sorts of issues, including hanging the system.
http://bugzilla.kernel.org/show_bug.cgi?id=6001
Here we change the Linux default to evaluate _DOS=0,
which tells the BIOS to simply send us a hotkey event
and not touch the graphics hardware.
The acpi video driver sends the display switch hotkey
event up through the intput layer, and X can interpret
that and use its native graphics driver to switch the display.
For the case where Linux has no native graphics driver running,
or the graphics driver doesn't know how to switch video and
the BIOS (safely) does, the previous behaviour can be restored with:
# echo 1 > /proc/acpi/video/*/DOS
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
* 'for-linus' of git://oss.sgi.com:8090/xfs/xfs-2.6:
[XFS] fix valid but harmless sparse warning
[XFS] fix filestreams on 32-bit boxes
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The new xlog_recover_do_reg_buffer checks call be16_to_cpu on di_gen which
is a 32bit value so sparse rightly complains. Fortunately the warning is
harmless because we don't care for the value, but only whether it's
non-NULL. Due to that fact we can simply kill the endian swaps on this and
the previous di_mode check entirely.
SGI-PV: 969656
SGI-Modid: xfs-linux-melb:xfs-kern:29709a
Signed-off-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
xfs_filestream_mount() sets up an mru cache with:
err = xfs_mru_cache_create(&mp->m_filestream, lifetime, grp_count,
(xfs_mru_cache_free_func_t)xfs_fstrm_free_func);
but that cast is causing problems...
typedef void (*xfs_mru_cache_free_func_t)(unsigned long, void*);
but:
void xfs_fstrm_free_func( xfs_ino_t ino, fstrm_item_t *item)
so on a 32-bit box, it's casting (32, 32) args into (64, 32) and I assume
it's getting garbage for *item, which subsequently causes an explosion.
With this change the filestreams xfsqa tests don't oops on my 32-bit box.
SGI-PV: 967795
SGI-Modid: xfs-linux-melb:xfs-kern:29510a
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
What guest drivers?
Cc: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] 4569/1: ep93xx_gpio_irq_type(): fix spurious enumeration offset for FGPIO handling
[ARM] 4568/1: fix l2x0 cache invalidate handling of unaligned addresses
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
FGPIO handling
The EP93XX_GPIO_LINE_F() macro is supposed to be called with a line
number between 0 and 7, but the current code causes it to get called
with an spuriously offset number range {16..23}.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The l2x0_inv_range() function doesn't handle unaligned addresses
correctly. It's necessary to clean the cache lines that are at the
start and end of the invalidate range, if the addresses are not aligned,
to prevent corruption of other data sharing the same cache line.
Signed-off-by: Rui Sousa <rui.p.m.sousa@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 34feb2c83beb3bdf13535a36770f7e50b47ef299.
Suresh Siddha points out that this one breaks the fundamental
requirement that you cannot free page table pages before the TLB caches
are flushed. The quicklists do not give the same kinds of guarantees
that the mmu_gather structure does, at least not in NUMA configurations.
Requested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
[MIPS] BCM1480: include <linux/init.h>.
[MIPS] BCM1480: Export zbbus_mhz.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | | |
Symbol is required by the ZBus profiler.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2:
ocfs2: Pack vote message and response structures
ocfs2: Don't double set write parameters
ocfs2: Fix pos/len passed to ocfs2_write_cluster
ocfs2: Allow smaller allocations during large writes
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The ocfs2_vote_msg and ocfs2_response_msg structs needed to be
packed to ensure similar sizeofs in 32-bit and 64-bit arches. Without this,
we had inadvertantly broken 32/64 bit cross mounts.
Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The target page offsets were being incorrectly set a second time in
ocfs2_prepare_page_for_write(), which was causing problems on a 16k page
size kernel. Additionally, ocfs2_write_failure() was incorrectly using those
parameters instead of the parameters for the individual page being cleaned
up.
Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This was broken for file systems whose cluster size is greater than page
size. Pos needs to be incremented as we loop through the descriptors, and
len needs to be capped to the size of a single cluster.
Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The ocfs2 write code loops through a page much like the block code, except
that ocfs2 allocation units can be any size, including larger than page
size. Typically it's equal to or larger than page size - most kernels run 4k
pages, the minimum ocfs2 allocation (cluster) size.
Some changes introduced during 2.6.23 changed the way writes to pages are
handled, and inadvertantly broke support for > 4k page size. Instead of just
writing one cluster at a time, we now handle the whole page in one pass.
This means that multiple (small) seperate allocations might happen in the
same pass. The allocation code howver typically optimizes by getting the
maximum which was reserved. This triggered a BUG_ON in the extend code where
it'd ask for a single bit (for one part of a > 4k page) and get back more
than it asked for.
Fix this by providing a variant of the high level allocation function which
allows the caller to specify a maximum. The traditional function remains and
just calls the new one with a maximum determined from the initial
reservation.
Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Strictly it's only needed for eax.
It actually does a little more than strictly needed -- the other registers
are already zero extended.
Also remove the now unnecessary and non functional compat task check
in ptrace.
This is CVE-2007-4573
Found by Wojciech Purczynski
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
[libata] ahci: add ATI SB800 PCI IDs
libata-sff: Fix documentation
libata: Update the blacklist with a few more devices
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
ATI/AMD SB800 shares some device IDs with SB700,
and SB800 adds two more device IDs:0x4394,0x4395.
Signed-off-by: henry su <henry.su.ati@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
|