Fix an 'oops' when a tmpfs mount point is mounted with the mpol=default
mempolicy.
Upon remounting a tmpfs mount point with 'mpol=default' option, the mount
code crashed with a null pointer dereference. The initial problem report
was on 2.6.27, but the problem exists in mainline 2.6.34-rc as well. On
examining the code, we see that mpol_new returns NULL if default mempolicy
was requested. This 'NULL' mempolicy is accessed to store the node mask
resulting in oops.
The following patch fixes it.
Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Acked-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use IS_ERR() instead of comparing to NULL.
[akpm@linux-foundation.org: preserve the error code]
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ksm.c's write_protect_page implements a lockless means of verifying a page
does not have any users of the page which are not accounted for via other
kernel tracking means. It does this by removing the writable pte with TLB
flushes, checking the page_count against the total known users, and then
using set_pte_at_notify to make it a read-only entry.
An unneeded mmu_notifier callout is made in the case where the known users
does not match the page_count. In that event, we are inserting the
identical pte and there is no need for the set_pte_at_notify, but rather
the simpler set_pte_at suffices.
Signed-off-by: Robin Holt <holt@sgi.com>
Acked-by: Izik Eidus <ieidus@redhat.com>
Acked-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Chris Wright <chrisw@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch renames PCI/PCI-DMA-mapping.txt to DMA-API-HOWTO.txt.
The commit 51e7364ef2 "Documentation: rename
PCI-DMA-mapping.txt to DMA-API-HOWTO.txt" was supposed to do this but it
didn't.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
include/linux/kfifo.h first defines and then undefines __kfifo_initializer
which is used by INIT_KFIFO (which is also a macro, so building a module
which uses INIT_KFIFO will fail).
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Stefani Seibold <stefani@seibold.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix an incorrect comment in the do_mmap_shared_file(). If a mapping is
requested MAP_SHARED, then a private copy cannot be made and still provide
correct semantics.
Signed-off-by: David Howells <dhowells@redhat.com>
Reported-by: Dave Hudson <uclinux@blueteddy.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Keeps MAINTAINERS a bit more consistent.
done via sed -r -i -e 's/^([A-Z]):[ \t]+/\1:\t/g' MAINTAINERS
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
According to the header in max730x it is licensed GPLv2.
Add a MODULE_LICENSE to avoid getting the kernel tainted.
[w.sang@pengutronix.de: add MODULE_AUTHOR and MODULE_DESCRIPTION also]
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 22dd5b0cba (fix perlcritic warnings)
broke the ability to handle STDIN because the three argument version of
open() cannot handle standard IO-streams (which is mentioned in
PerlBestPractices, too).
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We see only one section mismatch now after thousands of randconfigs, and a
bug has been filed about that one.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cpu_relax() is documented in volatile-considered-harmful.txt to be a
memory barrier. However, everyone with the exception of Blackfin and
possibly ia64 defines cpu_relax() to be a compiler barrier.
Make the documentation reflect the general concensus.
Linus sayeth:
: I don't think it was ever the intention that it would be seen as anything
: but a compiler barrier, although it is obviously implied that it might
: well perform some per-architecture actions that have "memory barrier-like"
: semantics.
:
: After all, the whole and only point of the "cpu_relax()" thing is to tell
: the CPU that we're busy-looping on some event.
:
: And that "event" might be (and often is) about reading the same memory
: location over and over until it changes to what we want it to be. So it's
: quite possible that on various architectures the "cpu_relax()" could be
: about making sure that such a tight loop on loads doesn't starve cache
: transactions, for example - and as such look a bit like a memory barrier
: from a CPU standpoint.
:
: But it's not meant to have any kind of architectural memory ordering
: semantics as far as the kernel is concerned - those must come from other
: sources.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: <linux-arch@vger.kernel.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/binfmt_aout.c: In function `aout_core_dump':
fs/binfmt_aout.c:125: warning: passing argument 2 of `dump_write' makes pointer from integer without a cast
include/linux/coredump.h:12: note: expected `const void *' but argument is of type `long unsigned int'
fs/binfmt_aout.c:132: warning: passing argument 2 of `dump_write' makes pointer from integer without a cast
include/linux/coredump.h:12: note: expected `const void *' but argument is of type `long unsigned int'
due to dump_write() expecting a user void *. Fold casts into the
START_DATA/START_STACK macros and shut up the warnings.
Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
Cc: Daisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
scripts/kernel-doc erroneously says:
Warning(include/linux/skbuff.h:410): Excess struct/union/enum/typedef member 'cb' description in 'sk_buff'
on this line in struct sk_buff:
char cb[48] __aligned(8);
due to treating the last field as the struct member name, so teach
kernel-doc to ignore __aligned(x) in structs.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This was introduced by v2.6.34-rc1~38:
4c014e8 (rtc/mc13783: protect rtc {,un}registration by mc13783 lock)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There was a potential null deref introduced in c62b1a3b31 ("memcg: use
generic percpu instead of private implementation").
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
commit e6a1105b ("cgroups: subsystem module loading interface") and commit
c50cc752 ("sched, cgroups: Fix module export") result in duplicate
including of module.h
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit 02491447 ("memcg: move charges of anonymous swap"), I tried to
disable move charge feature in no mmu case by enclosing all the related
functions with "#ifdef CONFIG_MMU", but the commit places these ifdefs in
wrong place. (it seems that it's mangled while handling some fixes...)
This patch fixes it up.
Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The driver match strategy was:
- Match vendor/model/specifier/version of the unit directory.
- If that was a miss, match vendor from the root directory and
model/specifier/version of the unit directory.
This was inconsistent with how the modalias string was constructed
until recently (take vendor/model from root directory and specifier/
version from unit directory). It was also inconsistent with how it is
done since the parent commit:
- Use vendor/model/specifier/version of the unit directory if possible,
- fall back to one or more of vendor/model/specifier/version from the
root directory depending on which ones are not present at the unit
directory.
Fix this inconsistency by sharing the ROM scanner function between
modalias printer function and driver match function.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The modalias string of devices that represent units on a FireWire node
did not show Module_ID entries within unit directories. This was
because firewire-core searched only the root directory of the
configuration ROM for a Model_ID entry.
We now search first the root directory, then the unit directory. IOW
honor a unit directory's Model_ID if present, otherwise fall back to the
root directory's model ID (if present).
Furthermore, apply the same change to Vendor_ID. This had the same
issue but it was less apparent because most devices provide Vendor_ID
only in the root directory.
And finally, also use this strategy for the remaining two IDs in the
modalias, Specifier_ID and Version. It does not actually make sense to
look for them elsewhere than in the unit directory because they are
mandatory there. However, a uniform search order simplifies the
implementation and has no adverse affect in practice.
Side notes:
- The older counterpart of this, nodemgr.c of ieee1394, looked for
Vendor_ID first in the root directory, then in the unit directory,
and for Model_ID only in the unit directory.
- There is a single mainline driver which requires Vendor_ID and
Model_ID --- the firedtv driver. This one worked because FireDTVs
provide Vendor_ID in the root directory and Model_ID identically in
root directory and unit directory.
- Apart from firedtv, there are currently no drivers known to me
(including userspace drivers) that look at the Vendor_ID or Model_ID
of the modalias.
Reported-by: Maciej Żenczykowski <zenczykowski@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The original code saved the error value but just returned 0 in the end.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jamal Hadi Salim <hadi@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
AMD says in section 2.5.4 (GFX MSI Enable) of #43291 (AMD 780G Family
Register Programming Requirements):
The SBIOS must enable internal graphics MSI capability in GCCFG by
setting the following: NBCFG.NB_CNTL.STRAP_MSI_ENABLE='1'
Quite a few BIOS writers misinterpret this sentence and think that
enabling MSI is an optional feature. However, clearing that bit just
prevents delivery of MSI messages but does not remove the MSI PCI
capabilities registers, and so leaves these devices unusable for any
driver that attempts to use MSI.
Setting that bit is not possible after the BIOS has locked down the
configuration registers, so we have to manually disable MSI for the
affected devices.
This fixes the codec communication errors in the HDA driver when
accessing the HDMI audio device, and allows us to get rid of the
overcautious quirk in radeon_irq_kms.c.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Alex Deucher <alexdeucher@gamil.com>
Cc: <stable@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Apply the CX700 quirk only when an external VT6212L is present (which
is the case for the errant hardware the quirk was written for), don't
touch the settings otherwise -- Hauppage PVR-500 tuners need PCI Bus
Parking in order to work and when that's turned on everything seems
to behave fine.
I guess the underlying problem is a combination of an external VT6212L
and the CX700 rather than the CX700's PCI being broken completely for
all cases...
Reported-by: Jeroen Roos <jeroen@roosnl.com>
Signed-off-by: Tim Yamin <plasm@roo.me.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
If we can tell that a device isn't working correctly, we should tell
the user to make debugging easier. Otherwise, it can take a lot of
work to determine whether the problem is in the driver, PCMCIA, PCI,
hardware, etc., as in http://bugzilla.kernel.org/show_bug.cgi?id=12006
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
No functional change; just print resources in the conventional style.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
No functional change; this just tweaks the changes from 349e1823a405
so the new printks for disabled PCI-to-PCI bridge windows match the
ones for the enabled windows.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
No functional change; just add names for the primary/secondary/subordinate
bus numbers read from config space rather than repeatedly masking/shifting.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With request_resource_conflict(), we can learn what the actual conflict is,
so print that info for debugging purposes.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Commit 08677214e3 ("x86: Make 64 bit use early_res instead
of bootmem before slab") introduced early_res replacement for
bootmem, but left code in __free_pages_memory() which dumps all
the ranges that are beeing freed, without any additional
information, causing some noise in dmesg during bootup.
Just remove printing of the ranges, that doesn't provide
anything useful anyway.
While at it, remove other commented-out KERN_DEBUG messages in
the NO_BOOTMEM code as well.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Found-OK-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <alpine.LNX.2.00.1003220931360.18642@pobox.suse.cz>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The dma map fields in the skb_shared_info structure no longer has any users
and can be dropped since it is making the skb_shared_info unecessarily larger.
Running slabtop show that we were using 4K slabs for the skb->head on x86_64 w/
an allocation size of 1522. It turns out that the dma_head and dma_maps array
made skb_shared large enough that we had crossed over the 2k boundary with
standard frames and as such we were using 4k blocks of memory for all skbs.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Updates real_num_tx_queues in case underlying real device
has changed real_num_tx_queues.
-v2
As per Eric Dumazet<eric.dumazet@gmail.com> comment:-
-- adds BUG_ON to catch case of real_num_tx_queues exceeding num_tx_queues.
-- created this self contained patch to just update real_num_tx_queues.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is required to correctly select vlan tx queue for a driver
supporting multi tx queue with ndo_select_queue implemented since
currently selected vlan tx queue is unaligned to selected queue by
real net_devce ndo_select_queue.
Unaligned vlan tx queue selection causes thrash with higher vlan
tx lock contention for least fcoe traffic and wrong socket tx
queue_mapping for ixgbe having ndo_select_queue implemented.
-v2
As per Eric Dumazet<eric.dumazet@gmail.com> comments, mirrored
vlan net_device_ops to have them with and without vlan_dev_select_queue
and then select according to real dev ndo_select_queue present or not
for a vlan net_device. This is to completely skip vlan_dev_select_queue
calling for real net_device not supporting ndo_select_queue.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
*) add a new HID for IBM SMBus CMI devices
*) add methods for IBM SMBus CMI devices
*) hook different HID with different control methods set
*) minor tweaks as suggested by Jean Delvare
Slightly modified by Darrick to use #define'd IBM SMBUS HID from Darrick's ACPI
scan quirk patch.
Signed-off-by: Crane Cai <crane.cai@amd.com>
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
On some old IBM workstations and desktop computers, the BIOS presents in the
DSDT an SMBus object that is missing the HID identifier that the i2c-scmi
driver looks for. Modify the ACPI device scan code to insert the missing HID
if it finds an IBM system with such an object.
Affected machines: IntelliStation Z20/Z30. Note that the i2c-i801 driver no
longer works on these machines because of ACPI resource conflicts.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Both functions should not be marked as __init, since they be called
from modules after the init section is freed.
Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Kosina <jkosina@suse.cz>
LKML-Reference: <1269431961-5731-1-git-send-email-henne@nachtwindheim.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
can_request_irq() accesses and dereferences irq_desc->action w/o
holding irq_desc->lock. So action can be freed on another CPU before
it's dereferenced. Unlikely, but ...
Protect it with desc->lock.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Fix two bugs with the kernel image compression:
1) reset the bss section of the compressed vmlinux
2) clear the high half of the registers for 64 bit early enough
for the decompression step
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This patch now allows the use of the proc interface to either activate
or deactivate call home on panic.
e.g. echo 1 > /proc/sys/kernel/callhome
strict_strtoul() requires _either_'\n\0' _or_ '\0' termination.
This was missing and therefore the interface did not recognise valid input.
Signed-off-by: Hans-Joachim Picht <hans@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Avoid 64 bit division to fix this compile error on 32 bit:
drivers/s390/char/sclp_cmd.c:711: undefined reference to `__udivdi3'
Also move the whole arch_get_memory_phys_device function to the
memory hotplug related functions.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Check tsb validity before the tcw_get_tsb function is called.
Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
All TCWs need to be aligned on a 64 byte boundary or the I/O will be
rejected. For recovery requests we create fresh TCWs, so we need to
do the proper alignment here as well.
Signed-off-by: Stefan Weinhuber <wein@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
commit 024914477e "memcg: move charges of anonymous
swap" revealed that the 1 byte and 2 byte cmpxchg is currently broken:
arch/s390/include/asm/system.h: Assembler messages:
arch/s390/include/asm/system.h:241: Error: junk at end of line: `(%r5)'
make[1]: *** [mm/page_cgroup.o] Error 1
make[1]: *** Waiting for unfinished jobs....
It turned out that commit 987bcdacb1 ([S390] use
inline assembly contraints available with gcc 3.3.3) broke the inline assembly.
The or operands are now in constraint 3 and 4 instead of 2 and 3.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The intermediate lowcore for CONFIG_SMP is allocated using a call to
__alloc_bootmem() with a goal of 0. That however doesn't guarantee that
the allocated piece of memory is below 2GB.
Instead we should call __alloc_bootmem_low().
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
To save the registers for all CPUs a sigp "store status" is done that
stores the registers to address absolute zero. To access storage at
absolute zero, normally the address of the prefix register of the
accessing CPU has to be used. This does not work when large pages are
active (currently only under LPAR). In order to fix that problem,
instead of memcpy memcpy_real is used, which switches to real mode
where prefixing works.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Instead of requiring PCMCIA socket drivers to call various functions
during their (bus) resume and suspend functions, register an own
dev_pm_ops for this class. This fixes several suspend/resume bugs
seen on db1xxx-ss, and probably on some other socket drivers, too.
With regard to the asymmetry with only _noirq suspend, but split up
resume, please see bug 14334 and commit 9905d1b411 .
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
The new-style dev_pm_ops provide callbacks for both IRQs enabled
and disabled. However, the _noirq variants were only called for
buses registered with a device, not for classes and types.
In order to properly use dev_pm_ops in class pcmcia_socket_class,
support _noirq actions also on classes and types.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Commit aa584ca4 broke what 6cf5be51 had already fixed: there may
be four multifunction devices, but just two pseudo-multifunction
devices per PCMCIA card.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
