Upon resume from standby, ixgbe may trigger the ASSERT_RTNL() in
netif_set_real_num_tx_queues(). The call stack is:
netif_set_real_num_tx_queues
ixgbe_set_num_queues
ixgbe_init_interrupt_scheme
ixgbe_resume
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src()
tries to use __raw_{read,write}l() to read from and write to physical
addresses, but those functions take virtual addresses.
sparse caught this:
arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap1/timer.c:50:13: expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap1/timer.c:50:13: got unsigned int
arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap1/timer.c:52:9: expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap1/timer.c:52:9: got unsigned int
Fix by using omap_{read,writel}(), just like the other users of the
MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term,
removing omap_{read,write}l() is the appropriate thing to do; but
this will take some work to do this cleanly.
Looks like this was caused by 97933d6 (ARM: OMAP1: dmtimer: conversion
to platform devices) that dangerously moved code and changed it in
the same patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: stable@vger.kernel.org
[tony@atomide.com: updated comments to include the breaking commit]
Signed-off-by: Tony Lindgren <tony@atomide.com>
This fixes a scalability problem reported by Andi Kleen and Tim Chen;
they were quite secretive about the precise nature of their workload,
but they later admitted that it only showed up when they were using a
large sparse file, so the amount of data I/O that was needed was close
to zero. I'm not sure how realistic this is and it's only a
regression if you consider changes made since 2.6.39 to be a
"regression" vis-a-vis the policy regarding post-merge window bug
fixes, but Linus agreed it was worth fixing, so I'm including it in
this pull request.
This also fixes the journalled quota mount options, which I
accidentally broke while I was cleaning up the mount option handling.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABCAAGBQJPjbs2AAoJENNvdpvBGATw/4UQAOMsxRlzbMnOAmohIBmesJiB
nTPX41dNw0QCXstMFjvSyRbUJI0NZPGg6ZDhbtoQ/c42/izZOVNd7gh7QQYHRCt2
Oqh6WS159P04ixcAe8NgCm5B5AV/C5Er/vSOUZENBaBo430vvrZasifsyUgQnx+b
PxXlYsfPVzaQVeSxCu/68OeiBRLcLwmKZ6MicOaWt9GCNoCsWzgU+/LNskYuscPI
841yQL6/BE7redU2E9qoEn/xjxx57hJOj2iiIAuqGPmNmRQqq3VtvTqNZHldNBLp
Hz5mB3zSZsPg0uwvp+OxrnpP37NQCCn1L64UFIXxqGF47mcCYw7schAoGBtqwGQS
neGUfkzG4beKk7kojyDawvnrrvVn4iCMaIkR1ZjzjPOk+QBPagckrS2nmuObbYzJ
l4lmHq1v8nOh0clxqJPioNp5/Y13sbpEOY4tAa6sLpzKLKXF330RNuwwrKKHB7zo
ZhCvSwVEjmxacgPCPhFJnR3fxtjoXWR8WvJs7H+gZB/QaC8hjEYw6xvvrkw8mAiS
RNe3cYdYAz6kOJdtJrJaMzp/1CYdHydf+0WvNYCQ/d1poPr7uU5wQY61hdm2gFxh
owsbVAOiEFjZWJHqrRRdcg2irTpINJTS3iRe4g/ltcvYzzRSeOcZNWvkKFspq3i8
EUMHRBxLzPMRa+gU6Unm
=jb3f
-----END PGP SIGNATURE-----
Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 regression fixes from Ted Ts'o:
"This fixes a scalability problem reported by Andi Kleen and Tim Chen;
they were quite secretive about the precise nature of their workload,
but they later admitted that it only showed up when they were using a
large sparse file, so the amount of data I/O that was needed was close
to zero.
I'm not sure how realistic this is and it's only a regression if you
consider changes made since 2.6.39 to be a "regression" vis-a-vis the
policy regarding post-merge window bug fixes, but Linus agreed it was
worth fixing, so I'm including it in this pull request.
This also fixes the journalled quota mount options, which I
accidentally broke while I was cleaning up the mount option handling."
* tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: fix handling of journalled quota options
ext4: address scalability issue by removing extent cache statistics
Pull vfs fixes from Al Viro:
"A bunch of endianness fixes and a couple of nfsd error value fixes.
Speaking of endianness stuff, I'm rather tempted to slap
ccflags-y += -D__CHECK_ENDIAN__
in fs/Makefile, if not making it default for the entire tree; nfsd
regressions I've caught make one hell of a pile and we'd obviously
benefit from having that kind of stuff caught earlier..."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
lockd: fix the endianness bug
ocfs2: ->e_leaf_clusters endianness breakage
ocfs2: ->rl_count endianness breakage
ocfs: ->rl_used breakage on big-endian
ocfs2: ->l_next_free_req breakage on big-endian
btrfs: btrfs_root_readonly() broken on big-endian
ext4: fix endianness breakage in ext4_split_extent_at()
nfsd: fix compose_entry_fh() failure exits
nfsd: fix error value on allocation failure in nfsd4_decode_test_stateid()
nfsd: fix endianness breakage in TEST_STATEID handling
nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails
nfsd: fix b0rken error value for setattr on read-only mount
The current serial UART code, while fidling with ocp idlemode bits,
forget about the smart idle wakeup bit even if it is supported by
UART IP block. This will lead to missing the module wakeup on OMAP's
where the smart idle wakeup is supported.
This was the root cause of the console sluggishness issue, I have been
observing on OMAP4 devices and also can be potential reason for some
other UART wakeup issues.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Paul Walmsley <paul@pwsan.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
Assigning sequence number for frames without taking care
of the fragment field breaks transmission of fragmented frames.
Fix this by assigning the fragment number properly.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The broken check leads to rate control attempting to use HT40 while
the driver is configured for HT20. This leads to interesting hardware
issues.
HT40 can only be used if the channel type is either HT40- or HT40+
and if the channel type of the cell matches the local type.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add Johannes Berg as the primary maintainer for iwlwifi driver
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cooked monitor rx was recently changed to use ieee80211_add_rx_radiotap_header
instead of generating only limited radiotap information.
ieee80211_add_rx_radiotap_header assumes that FCS info is still present if
the hardware supports receiving it, however when cooked monitor rx packets
are processed, FCS info has already been stripped.
Fix this by adding an extra flag indicating FCS presence.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
wrongly added muxing of default pads for all uarts. This causes
breakage on multiple boards using uart pins for alternate functions.
For example, on zoom3 random oopses can be seen with nfsroot as
the smsc911x ethernet FIFO timings on GPMC bus are controlled
by gpmc_wait2 and gpmc_wait3 pins. This means we can't mux these
pads to uart4 functionality as commit 7496ba3 was doing.
Not all boards tend to use all uarts and most of unused uart pins
are muxed for other purpose. This commit breaks the modules which
where trying to use unused uart pins on their boards.
So remove the default pad muxing. Note that this is not a complete
fix, as we now rely on bootloader set muxing for the uart wake-up
events. Further patching is needed to enable wake-up events for
uarts that are already muxed to uart mode.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Acked-by: Russ Dill <russ.dill@gmail.com>
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
[tony@atomide.com: updated comments to describe oops on zoom3]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Use list_for_each_entry_safe and remove the spin_lock acquisition in
m2p_find_override.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Since we are using the m2p_override we do have struct pages
corresponding to the user vma mmap'ed by gntdev.
Removing the VM_PFNMAP flag makes get_user_pages work on that vma.
An example test case would be using a Xen userspace block backend
(QDISK) on a file on NFS using O_DIRECT.
CC: stable@kernel.org
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
_omap3_sram_configure_core_dpll is called when SDRC is reprogrammed,
which is done regardless of CONFIG_PM setting, so we always need it's
setup code too. Without this, we hit a BUG() on OMAP3 when kernel is
built without CONFIG_PM:
Reprogramming SDRC clock to 332000000 Hz
------------[ cut here ]------------
kernel BUG at arch/arm/plat-omap/sram.c:342!
Internal error: Oops - BUG: 0 [#1] ARM
...
[<c001c694>] (omap3_configure_core_dpll+0x68/0x6c) from [<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x1)
[<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x138/0x1b0) from [<c001a478>] (omap2_clk_set_rate+0x14/0x2)
[<c001a478>] (omap2_clk_set_rate+0x14/0x20) from [<c001c9dc>] (clk_set_rate+0x54/0x74)
[<c001c9dc>] (clk_set_rate+0x54/0x74) from [<c022b9c8>] (omap_sdrc_init+0x70/0x90)
[<c022b9c8>] (omap_sdrc_init+0x70/0x90) from [<c022f178>] (omap3pandora_init+0x11c/0x164)
[<c022f178>] (omap3pandora_init+0x11c/0x164) from [<c022849c>] (customize_machine+0x20/0x28)
[<c022849c>] (customize_machine+0x20/0x28) from [<c0225810>] (do_one_initcall+0xa0/0x16c)
[<c0225810>] (do_one_initcall+0xa0/0x16c) from [<c02259e0>] (kernel_init+0x104/0x1ac)
[<c02259e0>] (kernel_init+0x104/0x1ac) from [<c0009cec>] (kernel_thread_exit+0x0/0x8)
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Pull CIFS fixes from Steve French.
* git://git.samba.org/sfrench/cifs-2.6:
Fix number parsing in cifs_parse_mount_options
Cleanup handling of NULL value passed for a mount option
Remove SoC dependency and make it generic for every Atmel ARM AT91. That will
allow to select this driver for newer chips. Keep dependency on AT91 because of
the use of an header file located in include/mach directory.
Modify the comment to reflect this.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Vinod Koul <vinod.koul@linux.intel.com>
Now that we are using irqdomains, we need to convert GPIO pins to Linux
IRQ numbers using the gpio_to_irq() function.
This call is added to request/free_irq calls.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Cc: linux-usb@vger.kernel.org
Add __devinit and __devexit on *_probe() and *_remove() functions
with proper modification of struct platform_driver.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Commit 892a884 (leds: convert led platform drivers to module_platform_driver)
is omitting the section mismatch error: so change annotation of the probe
function to __devinit instead of __init.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Add missing DMI_NONE entry to end of the quirks list so
dmi_check_system() won't read past the end of the list.
Signed-off-by: Martin Nyhus <martin.nyhus@gmx.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
We can't control order here, and getting it inverted is harmless. So
turn this down to dev_info() and leave a note about how to fix it in
case userspace is insufficiently automagic.
Bugzilla: https://bugzilla.redhat.com/794953
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
The CONFIG_FEC2 define was removed from the kernel many versions ago.
But it is still being used to set the multi-function pins when compiling
for a ColdFire 527[45] SoC that has 2 ethernet interfaces. Remove the
last remaining uses of this define, and so fix the setting of the pins
for the 2nd ethernet interface.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The second ColdFire FEC ethernet device should have an id number of 1,
not 0. Otherwise it clashes with the first FEC ethernet device.
On booting a kernel on a 5275 based board you will get messages out of
the kernel like this:
<4>------------[ cut here ]------------
<4>WARNING: at fs/sysfs/dir.c:508 0x0a8b50()
<4>sysfs: cannot create duplicate filename 'fec.0'
And likely you won't be able to completely boot up after this at all.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Jump to the label ini_nomem as done on the failure of the page allocations
above.
The code at ini_nomem is modified to accommodate different return values.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In register_netdevice(), when ndo_init() is successful and later
some error occurred, ndo_uninit() will be called.
So dummy deivce is desirable to implement ndo_uninit() method
to free percpu stats for this case.
And, ndo_uninit() is also called along with dev->destructor() when
device is unregistered, so in order to prevent dev->dstats from
being freed twice, dev->destructor is modified to free_netdev().
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make smsc75xx recalculate the hard_mtu after adjusting the
hard_header_len.
Without this, usbnet adjusts the MTU down to 1492 bytes, and the host is
unable to receive standard 1500-byte frames from the device.
Inspired by same fix on cdc_eem 78fb72f793.
Tested on ARM/Omap3 with EVB-LAN7500-LC.
Signed-off-by: Stephane Fillod <fillods@users.sf.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
A parameter set exists for WRED mode, called wred_set, to hold the same
values for qavg and qidlestart across all VQs. The WRED mode values had
been previously held in the VQ for the default DP. After these values
were moved to wred_set, the VQ for the default DP was no longer created
automatically (so that it could be omitted on purpose, to have packets
in the default DP enqueued directly to the device without using RED).
However, gred_dump() was overlooked during that change; in WRED mode it
still reads qavg/qidlestart from the VQ for the default DP, which might
not even exist. As a result, this command sequence will cause an oops:
tc qdisc add dev $DEV handle $HANDLE parent $PARENT gred setup \
DPs 3 default 2 grio
tc qdisc change dev $DEV handle $HANDLE gred DP 0 prio 8 $RED_OPTIONS
tc qdisc change dev $DEV handle $HANDLE gred DP 1 prio 8 $RED_OPTIONS
This fixes gred_dump() in WRED mode to use the values held in wred_set.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here are some virtio fixes for 3.4:
a test build fix, a patch by Ren fixing naming for systems with a massive
number of virtio blk devices, and balloon fixes for powerpc
by David Gibson.
There was some discussion about Ren's patch for virtio disc naming: some people
wanted to move the legacy name mangling function to the block core. But
there's no concensus on that yet, and we can always deduplicate later.
Added comments in the hope that this will stop people from
copying this legacy naming scheme into future drivers.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJPio1GAAoJECgfDbjSjVRpGDAH/3C/bXm9mriuNauRHwktHgJe
gmh2BfUgnxly6vheuz0Fv61lTe6V8kekHVolbUYwAUgXeWEKK1C59xehrMGRIPDG
1XUiti50U3P+skhIfrbkS5nZ7L+5Hk0ToQ6dd9v0BM2GxDOvgwidlY1bZe+wJEZf
Lvl6w/djBCr1e3k4qfRnpTcdJJ4FnOjGbikLQhSTGfUXeNo6uWS1hljYWnAhzFkd
1xU8h5PP0TDR0nYb80CeB+9Lxw0w4qyNPJIBhNN6ucB/1U6R+55HpEpmrLUkn910
sEFEFsc0cRVWr8FiOTlmzxLHnwTc8AY/Bsp9TMSmnTRu3ZQcoQMTQQCczRj04xI=
=VmpJ
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio fixes from Michael S. Tsirkin:
"Here are some virtio fixes for 3.4: a test build fix, a patch by Ren
fixing naming for systems with a massive number of virtio blk devices,
and balloon fixes for powerpc by David Gibson.
There was some discussion about Ren's patch for virtio disc naming:
some people wanted to move the legacy name mangling function to the
block core. But there's no concensus on that yet, and we can always
deduplicate later. Added comments in the hope that this will stop
people from copying this legacy naming scheme into future drivers."
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio_balloon: fix handling of PAGE_SIZE != 4k
virtio_balloon: Fix endian bug
virtio_blk: helper function to format disk names
tools/virtio: fix up vhost/test module build
Some shortcomings introduced into pci_restore_state() by commit
26f41062f2 ("PCI: check for pci bar restore completion and retry")
have been fixed by recent commit ebfc5b802f ("PCI: Fix regression in
pci_restore_state(), v3"), but that commit treats all PCI devices as
those with Type 0 configuration headers.
That is not entirely correct, because Type 1 and Type 2 headers have
different layouts. In particular, the area occupied by BARs in Type 0
config headers contains the secondary status register in Type 1 ones and
it doesn't make sense to retry the restoration of that register even if
the value read back from it after a write is not the same as the written
one (it very well may be different).
For this reason, make pci_restore_state() only retry the restoration
of BARs for Type 0 config headers. This effectively makes it behave
as before commit 26f41062f2 for all header types except for Type 0.
Tested-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'm dropping off as Documentation/ maintainer.
Rob Landley has agreed to take it over. Thanks, Rob.
I'll still be around reviewing patches and testing.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: Rob Landley <rob@landley.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michel Lespinasse cleaned up the futex calling conventions in commit
37a9d912b2 ("futex: Sanitize cmpxchg_futex_value_locked API").
But the ia64 implementation was subtly broken. Gcc does not know that
register "r8" will be updated by the fault handler if the cmpxchg
instruction takes an exception. So it feels safe in letting the
initialization of r8 slide to after the cmpxchg. Result: we always
return 0 whether the user address faulted or not.
Fix by moving the initialization of r8 into the __asm__ code so gcc
won't move it.
Reported-by: <emeric.maschino@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42757
Tested-by: <emeric.maschino@gmail.com>
Acked-by: Michel Lespinasse <walken@google.com>
Cc: stable@vger.kernel.org # v2.6.39+
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Starting from 7e16838d "i387: support lazy restore of FPU state"
we assume that fpu_owner_task doesn't need restore_fpu_checking()
on the context switch, its FPU state should match what we already
have in the FPU on this CPU.
However, debugger can change the tracee's FPU state, in this case
we should reset fpu.last_cpu to ensure fpu_lazy_restore() can't
return true.
Change init_fpu() to do this, it is called by user_regset->set()
methods.
Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20120416204815.GB24884@redhat.com
Cc: <stable@vger.kernel.org> v3.3
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Commit 26092bf5 broke handling of journalled quota mount options by
trying to parse argument of every mount option as a number. Fix this
by dealing with the quota options before we call match_int().
Thanks to Jan Kara for discovering this regression.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Revert the --strict test for the old preferred block
comment style in drivers/net and net/
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If either call to pcan_usb_pro_send_req() in
drivers/net/can/usb/peak_usb/pcan_usb_pro.c::pcan_usb_pro_init()
fails, we'll leak the memory we allocated to 'usb_if' with kzalloc()
when the 'usb_if' variable goes out of scope without having been
assigned to anything as we 'return err;'.
Fix this by adding appropriate kfree(usb_if) calls to the error paths.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The combination of commit 1b1247dd75
"mfd: Add support for RICOH PMIC RC5T583"
and commit 6ffc327021
"regulator: Add support for RICOH PMIC RC5T583 regulator"
are causing the i386 allmodconfig builds to fail with this:
ERROR: "rc5t583_update" [drivers/regulator/rc5t583-regulator.ko] undefined!
ERROR: "rc5t583_set_bits" [drivers/regulator/rc5t583-regulator.ko] undefined!
ERROR: "rc5t583_clear_bits" [drivers/regulator/rc5t583-regulator.ko] undefined!
ERROR: "rc5t583_read" [drivers/regulator/rc5t583-regulator.ko] undefined!
and this:
ERROR: "rc5t583_ext_power_req_config" [drivers/regulator/rc5t583-regulator.ko] undefined!
For the 1st four, make the simple ops static inline, instead of
polluting the namespace with trivial exports. For the last one,
add an EXPORT_SYMBOL.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The cld.h file contains the definition of the upcall format to talk
with nfsdcld. When I added the file though, I neglected to add it
to the headers-y target, so make headers_install wasn't installing it.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
It's only called from amd.c:srat_detect_node(). The introduced
condition for calling the fixup code is true for all AMD
multi-node processors, e.g. Magny-Cours and Interlagos. There we
have 2 NUMA nodes on one socket. Thus there are cores having
different numa-node-id but with equal phys_proc_id.
There is no point to print error messages in such a situation.
The confusing/misleading error message was introduced with
commit 64be4c1c24 ("x86: Add
x86_init platform override to fix up NUMA core numbering").
Remove the default fixup function (especially the error message)
and replace it by a NULL pointer check, move the
Numascale-specific condition for calling the fixup into the
fixup-function itself and slightly adapt the comment.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: <stable@kernel.org>
Cc: <sp@numascale.com>
Cc: <bp@amd64.org>
Cc: <daniel@numascale-asia.com>
Link: http://lkml.kernel.org/r/20120402160648.GR27684@alberich.amd.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The method used to work out whether we were booted by EFI firmware or
via a boot loader is broken. Because efi_main() is always executed
when booting from a boot loader we will dereference invalid pointers
either on the stack (CONFIG_X86_32) or contained in %rdx
(CONFIG_X86_64) when searching for an EFI System Table signature.
Instead of dereferencing these invalid system table pointers, add a
new entry point that is only used when booting from EFI firmware, when
we know the pointer arguments will be valid. With this change legacy
boot loaders will no longer execute efi_main(), but will instead skip
EFI stub initialisation completely.
[ hpa: Marking this for urgent/stable since it is a regression when
the option is enabled; without the option the patch has no effect ]
Signed-off-by: Matt Fleming <matt.hfleming@intel.com>
Link: http://lkml.kernel.org/r/1334584744.26997.14.camel@mfleming-mobl1.ger.corp.intel.com
Reported-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> v3.3
Upon lastclose(), we switch back to the fbcon configuration. This
requires taking the mode_config lock in order to serialise the change
with output probing elsewhere.
Reported-by: Oleksij Rempel <bug-track@fisher-privat.net>
References: https://bugs.freedesktop.org/show_bug.cgi?id=48652
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bcma should check for a fallback sprom every time it can not find a
sprom on the card itself or a normal external sprom mapped into the
memory of the chip. When otp sprom support was introduced it tried to
read out the sprom from the wireless chip also if no otp sprom was
available. This caused a Data bus error in bcma_sprom_get() when
reading out the sprom for the SoC.
This fixes a regression introduced in commit:
commit 10d8493cd9
Author: Arend van Spriel <arend@broadcom.com>
Date: Tue Mar 6 15:50:48 2012 +0100
bcma: add support for on-chip OTP memory used for SPROM storage
This patch was tested on a Netgear WNDR3400 (Broadcom BCM4718 SoC).
Reported-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Assumption that irq numbers of asic3 gpios start at
IRQ_BOARD_START is certainly wrong - driver may as well
use any other base for its irqs (consider for example
the imaginary case of two ASIC3 chips onboard)
Furthermore, some platforms even don't have IRQ_BOARD_START
defined, so driver will fail to build on them:
-------------------------------------------------------
drivers/mfd/asic3.c: In function 'asic3_gpio_to_irq':
drivers/mfd/asic3.c:530: error: 'IRQ_BOARD_START' undeclared (first use in this function)
drivers/mfd/asic3.c:530: error: (Each undeclared identifier is reported only once
drivers/mfd/asic3.c:530: error: for each function it appears in.)
-------------------------------------------------------
Fix it by using irq_base from driver data.
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
It is observed that the echi ports of 3430 sdp board
are not working due to the random timing of programming
the associated GPIOs of the ULPI PHYs of the EHCI for reset.
If the PHYs are reset at during usbhs core driver, host ports will
not work because EHCI driver is loaded after the resetting PHYs.
The PHYs should be in reset state while initializing the EHCI
controller.
The code which does the GPIO pins associated with the PHYs
are programmed to reset is moved from the USB host core driver
to EHCI driver.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Andi Kleen and Tim Chen have reported that under certain circumstances
the extent cache statistics are causing scalability problems due to
cache line bounces.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Here are the fixes I have queued for v3.4-rc cycle so far.
It includes fixes on many of the gadget drivers and a few
of the UDC controller drivers.
For musb we have a fix for a kernel oops when unloading
omap2430.ko glue layer, proper error checking for pm_runtime_*,
fix for the ULPI transfer block, and a bug fix in musb_cleanup_urb
routine.
For s3c-hsotg we have mostly FIFO-related fixes (proper TX FIFO
allocation, TX FIFO corruption fix in DMA mode) but also a couple
of minor fixes (fixing maximum packet size for ep0 and fix for
big transfers with DMA).
For the dwc3 driver we have a memory leak fix, a very important
fix for USB30CV with SetFeature tests and the hability to handle
ep0 requests bigger than wMaxPacketSize.
On top of that there's a bunch of gadget driver minor fixes adding
proper section annotations, and fixing up the sysfs interface for
doing device-initiated connect/disconnect and so on.
All patches have been pending on the mailing list for quite a while
and look good for your for-linus branch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJPhUWkAAoJEIaOsuA1yqRE8h0P/R5jNluFEzpLA5SLgNFAn4F1
+LkIvB9T/F+UmO5EW4cfQbJ7DgKh92KISIgwSS0+LJEsC05ODWVs1PB1KYj/IgrX
D4GxrAz7DhwGlln2ejiSp/Mx3ATRCrUqhd7S4kt+tsCi7As9rBW4eduUTsp8ip5Z
kxvivYqKfjjJ8MHHRwo3AkkqCZOIc+JW9lhL7itkYMlmpBLPg8NMusJ32O2+0BfD
SK1WOWCladpVjVjoux7QM1y2kZN5XPgwRxLzB/XDK8QbkBukGORPbwiwRnnhHNf5
W/ceKYlCJzj6WdcEUHeDA8b4Sfhu6pbBVjhD3fybMkY0IqcgR3sGDp1eKnXjAbuS
01ALiTKiWlboMhTD4RqnBs17C70kfzRTHfPLZBHi9w04u3jbb5oCmTOgD2gNbb0m
0iHDizMdNVxt25Tcj+mtKNhTYguJ8HoFpQ/bWEHOa/Ra723WPaTd1RFhPLOAgj1K
0V6Rwsi/eb/7CdkCfzOlZe7zixeyLthzG5YbXRMj84XLoD9mBhpMBA21DFpcxizr
1OpZfcgz2LH4WqGZky35Q+BKPma2DA7tLv3VwIRXVkfv9p1ISzIS+Vre/TCHDZWs
oXpsZXHBNyCU+saomJnQ/mRJQ4+uSKsqc+WJPe6D3KpwlMi6DtK3OAAnmullMPjx
ptHgrZzXZuS/10gc1F7g
=Wqlb
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
usb: fixes for v3.4-rc cycle
Here are the fixes I have queued for v3.4-rc cycle so far.
It includes fixes on many of the gadget drivers and a few
of the UDC controller drivers.
For musb we have a fix for a kernel oops when unloading
omap2430.ko glue layer, proper error checking for pm_runtime_*,
fix for the ULPI transfer block, and a bug fix in musb_cleanup_urb
routine.
For s3c-hsotg we have mostly FIFO-related fixes (proper TX FIFO
allocation, TX FIFO corruption fix in DMA mode) but also a couple
of minor fixes (fixing maximum packet size for ep0 and fix for
big transfers with DMA).
For the dwc3 driver we have a memory leak fix, a very important
fix for USB30CV with SetFeature tests and the hability to handle
ep0 requests bigger than wMaxPacketSize.
On top of that there's a bunch of gadget driver minor fixes adding
proper section annotations, and fixing up the sysfs interface for
doing device-initiated connect/disconnect and so on.
All patches have been pending on the mailing list for quite a while
and look good for your for-linus branch.
Complete the separation of the twl6040 from the twl core since
it is a separate chip, not part of the twl6030 PMIC.
Make the needed Kconfig changes for the depending drivers at the
same time to avoid breaking the kernel build (vibra, ASoC components).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonicro.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The ux500 default config enables the db5500 and the db8500.
The incoming cpuidle driver uses the 'prcmu_enable_wakeups'
and the 'prcmu_set_power_state' functions but these ones
are defined but not implemented for the db5500, leading to
an unresolved symbol error at link time. In order to compile,
we have to disable the db5500 support which is not acceptable
for the default config.
I noticed there are also some other functions which are
defined but not implemented.
This patch fix this by removing the functions definitions
and move out of the config section the empty functions which
are normally used when the DB550 config is disabled.
Only the functions which are not implemented are concerned
by this modification.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Forget to unreserve after pinning. This can lead to problems in
soft reset and resume.
v2: rework patch as per Michel's suggestion.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
My rv515 card is very flaky with msi enabled. Every so often it loses a rearm
and never comes back, manually banging the rearm brings it back.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
