commit 2d1c861871 upstream
The cardbus code creates PCI devices without ever going through the
necessary fixup bits and pieces that normal PCI devices go through.
There's in fact a commented out call to pcibios_fixup_bus() in there,
it's commented because ... it doesn't work.
I could make pcibios_fixup_bus() do the right thing on powerpc easily
but I felt it cleaner instead to provide a specific hook pci_fixup_cardbus
for which a weak empty implementation is provided by the PCI core.
This fixes cardbus on powerbooks and probably all other PowerPC
platforms which was broken completely for ever on some platforms and
since 2.6.31 on others such as PowerBooks when we made the DMA ops
mandatory (since those are setup by the fixups).
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 0c570cdeb8
(PM / yenta: Fix cardbus suspend/resume regression) caused resume to
fail on systems with two CardBus bridges. While the exact nature
of the failure is not known at the moment, it can be worked around by
splitting the yenta resume into an early part, executed during the
early phase of resume, that will only resume the socket and power it
up if there was a card in it during suspend, and a late part,
executed during "regular" resume, that will carry out all of the
remaining yenta resume operations.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
listed regression from 2.6.31.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Reported-by: Stephen J. Gowdy <gowdy@cern.ch>
Tested-by: Jose Marino <braket@hotmail.com>
The CL-PD6729 chip in some docking station is not initialized properly
under Linux. In that case, do not load the pd6729 driver.
[Dominik Brodowski <linux@dominikbrodowski.net>: spelling fixes, check for NULL not 0]
Signed-off-by: Komuro <komurojun-mbn@nifty.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Fix more possible warnings introduced by my commit
1d80766554 as fixed by the previous patch from
Randy Dunlap. Not tested due to no hardware.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
pccard_read_tuple(), which is only used by the PCMCIA core, should
handle TUPLE_RETURN_COMMON more sensibly: If a specific function (which
may be 0) is requested, set tuple.Attributes = 0 as was done in all
PCMCIA drivers. If, however, BIND_FN_ALL is requested, return the
"common" tuple. As to the callers of pccard_read_tuple():
- All calls to pcmcia_validate_cis() had set the "function" parameter to
BIND_FN_ALL. Therefore, remove the "function" parameter and make the
parameter to pccard_read_tuple explicit.
- Calls to CISTPL_VERS_1 and CISTPL_MANFID now set BIND_FN_ALL. This was
already the case for calls to CISTPL_LONGLINK_MFC.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Fix new pcmcia printk format warnings:
[This has now moved from linux-next to mainline.
Originally sent 2009-SEP-17.]
drivers/pcmcia/i82365.c:1055: warning: format '%#x' expects type 'unsigned int', but argument 6 has type 'phys_addr_t'
drivers/pcmcia/i82365.c:1055: warning: format '%#x' expects type 'unsigned int', but argument 7 has type 'phys_addr_t'
drivers/pcmcia/tcic.c:734: warning: format '%#x' expects type 'unsigned int', but argument 6 has type 'phys_addr_t'
drivers/pcmcia/tcic.c:734: warning: format '%#x' expects type 'unsigned int', but argument 7 has type 'phys_addr_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Since 2.6.29 the PCI PM core have been restoring the standard
configuration registers of PCI devices in the early phase of
resume. In particular, PCI devices without drivers have been handled
this way since commit 355a72d75b
(PCI: Rework default handling of suspend and resume). Unfortunately,
this leads to post-resume problems with CardBus devices which cannot
be accessed in the early phase of resume, because the sockets they
are on have not been woken up yet at that point.
To solve this problem, move the yenta socket resume to the early
phase of resume and, analogously, move the suspend of it to the late
phase of suspend. Additionally, remove some unnecessary PCI code
from the yenta socket's resume routine.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13092, which is a
post-2.6.28 regression.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Florian <fs-kernelbugzilla@spline.de>
Cc: stable@kernel.org
pcmcia_socket_dev_suspend() doesn't use its second argument, so it
may be dropped safely.
This change is necessary for the subsequent yenta suspend/resume fix.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
WARNING: drivers/pcmcia/sa1100_cs.o(.data+0x48): Section mismatch in reference from the variable sa11x0_pcmcia_hw_init to the function .init.text:pcmcia_assabet_init()
The variable sa11x0_pcmcia_hw_init references
the function __init pcmcia_assabet_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: drivers/pcmcia/sa1111_cs.o(.text+0x298): Section mismatch in reference from the function pcmcia_probe() to the function .init.text:pcmcia_neponset_init()
The function pcmcia_probe() references
the function __init pcmcia_neponset_init().
This is often because pcmcia_probe lacks a __init
annotation or the annotation of pcmcia_neponset_init is wrong.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Clean up the /drivers/pcmcia/sa1100_jornada.c file with respect to
formatting. It also changes a build warning into a code comment (since
its a pain to watch every build and havent seen any problems with driver
in 3.5years).
Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Greg KH <greg@kroah.com>
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/gregkh/pcmcia-2.6:
pcmcia: document return value of pcmcia_loop_config
pcmcia: dtl1_cs: fix pcmcia_loop_config logic
pcmcia: drop non-existant includes
pcmcia: disable prefetch/burst for OZ6933
pcmcia: fix incorrect argument order to list_add_tail()
pcmcia: drivers/pcmcia/pcmcia_resource.c: Remove unnecessary semicolons
pcmcia: Use phys_addr_t for physical addresses
pcmcia: drivers/pcmcia: Make static
Hopefully it will be harder to get it wrong now. Also fix an unneeded
initialization while we are here.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit a56bc69a18 fixed a wrong usage of
list_add_tail() within store_new_id() for PCI. Port the fix to PCMCIA,
which adapted this function from PCI.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
