Pull CIFS fixes from Steve French.
* git://git.samba.org/sfrench/cifs-2.6:
Use correct conversion specifiers in cifs_show_options
CIFS: Show backupuid/gid in /proc/mounts
cifs: fix offset handling in cifs_iovec_write
- In the low-level assembler code we would jump to check events
even if none were present. This incorrect behavior had been there
since 2.6.27 days!
- When using the fast-path for ACK-ing interrupts we were using the
Linux IRQ numbers instead of the Xen ones (and they can differ) and
missing interrupts in process.
- Fix bootup crashes when ACPI hotplug CPUs were present and they
would expand past the set number of CPUs we were allocated.
- Deal with broken BIOSes when uploading C-states to the hypervisor.
- Disable the cpuid check for MWAIT_LEAF if the ACPI PAD driver is
loaded. If the ACPI PAD driver is used it will crash, so lets not
export the functionality so the ACPI PAD driver won't load.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJPmwl0AAoJEFjIrFwIi8fJdMoIAKliOTtWwaBTH8VzrVK3f2+x
Hdp7KQuFB6SM74Be2TMYvev7v2q4u35eLCf/huj+vr7MVjOKqjKKrVLLuZKU1sKz
a9ohLy0el6BDgL6Bkywm9AhReCXGz0sRi2g2nVV1HhUHjaJiMC7Rbd/ac+8FtYTF
d/paaMWxGshtJwjHPn6XZhTJ54Rguwbp4cW+R/6IVDAfI3BH0nBWNgj53lwKpvmh
7c7rzwLJRokW0hVoqGvpeT6pIeRqDOMBBQP5BhGe8YCl3qASJBzWPmzQHAqL/h5Z
ieDmkQCyKZXew+jyV3Xq+V0ZuQekUCfz/sapRh+F32ZB2jxCcaeRLzPNLVzAs5o=
=m4wA
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
Pull Xen fixes from Konrad Rzeszutek Wilk:
"Some of these had been in existence since the 2.6.27 days, some since
3.0 - and some due to new features added in v3.4.
The one that is most interesting is David's one - in the low-level
assembler code we had be checking events needlessly. With his patch
now we do it when the appropriate flag is set - with the added benefit
that we can process events faster. Stefano's is fixing a mistake
where the Linux IRQ numbers were ACK-ed instead of the Xen IRQ,
resulting in missing interrupts. The other ones are bootup related
that can show up on various hardware."
- In the low-level assembler code we would jump to check events even if
none were present. This incorrect behavior had been there since
2.6.27 days!
- When using the fast-path for ACK-ing interrupts we were using the
Linux IRQ numbers instead of the Xen ones (and they can differ) and
missing interrupts in process.
- Fix bootup crashes when ACPI hotplug CPUs were present and they would
expand past the set number of CPUs we were allocated.
- Deal with broken BIOSes when uploading C-states to the hypervisor.
- Disable the cpuid check for MWAIT_LEAF if the ACPI PAD driver is
loaded. If the ACPI PAD driver is used it will crash, so lets not
export the functionality so the ACPI PAD driver won't load.
* tag 'stable/for-linus-3.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen: correctly check for pending events when restoring irq flags
xen/acpi: Workaround broken BIOSes exporting non-existing C-states.
xen/smp: Fix crash when booting with ACPI hotplug CPUs.
xen: use the pirq number to check the pirq_eoi_map
xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPmubjAAoJEEFnBt12D9kBPZ4P/2wrFqNy2+Fxatstmb1GKwqW
Yx0acIZkJK/gfZetFDSiTzM8bcxp/oz2lfqHE7xFq96s36wSZyO9B9Ry+YiD9x4g
wzN/Gb7UufnuSEEJo19E13sJxMXJ/4dVFHKtJnxSL3k9lC6nO/YkEn7C2OXE9gXy
d3a8H2jyGK9CPPHzQVxDP+9vYj8RpZcXz1M49H8dZ7UZblPfHlvPNzsclKbuTiFK
8zg16sX01BjvbawwMuAuJH/SGytKpM7WtlzDni/OplqX3CDjIoNZ8BEqDgXDVcS8
dwhmhPEf89v5ctWhaDHlskwAkL8oFjwFAHMZ7pjiIZ1aTxPPEKtyegVqPKoQwQmK
XCbjb9SqFNRXI2nIkbeX1xGHQS1wngRcfWJ13qLDEDi3d3aGLUJDYTtMHPrjvNnI
kzqbNC6fFuKZNOaDYMb1nqV3oWa8VLlDhXgEn5K8ZzBInZ/12LsqybRqImwLQnN0
flRCcOWApbHmJB64IAI1NzbG5Y6FxG53lwW+bwkw83W1fWw1WaUNNvJ8HBfDoN3G
QflSqY8TtRE5vGvTburRbDIF3YBeGsaPDTksIg2t82PZ1SabUfIhpWRbhzS6YvMH
NiKlgk88Q3VHLUF4TOxDThXZEJpL4VcJWOV0/Y4eSDNNhOtBKfGMoo9EBCfLwevM
q6EyapSjiDz0pu9jUN/P
=V4y2
-----END PGP SIGNATURE-----
Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6
Pull misc SPI device driver bug fixes from Grant Likely.
* tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
spi/spi-bfin5xx: Fix flush of last bit after each spi transfer
spi/spi-bfin5xx: fix reversed if condition in interrupt mode
spi/spi_bfin_sport: drop bits_per_word from client data
spi/bfin_spi: drop bits_per_word from client data
spi/spi-bfin-sport: move word length setup to transfer handler
spi/bfin5xx: rename config macro name for bfin5xx spi controller driver
spi/pl022: Allow request for higher frequency than maximum possible
spi/bcm63xx: set master driver mode_bits.
spi/bcm63xx: don't use the stopping state
spi/bcm63xx: convert to the pump message infrastructure
spi/spi-ep93xx.c: use dma_transfer_direction instead of dma_data_direction
spi: fix spi.h kernel-doc warning
spi/pl022: Fix calculate_effective_freq()
spi/pl022: Fix range checking for bits per word
Pull drm fixes from Dave Airlie:
"For your Friday pull request stack, nothing astounding or shattering
this week some exynos, some intel, some radeon fixes. One intel fix
for a regression somwehere back in 2.6.35 land."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon/kms: use frac fb div on APUs
drm/radeon: add a missing entry to encoder_names
drm/i915: handle input/output sdvo timings separately in mode_set
drm/i915: fix integer overflow in i915_gem_do_execbuffer()
drm/i915: fix integer overflow in i915_gem_execbuffer2()
drm/exynos: added missed vm area region mapping type.
drm/exynos: fixed exynos_drm_gem_map_pages bug.
drm/exynos: fixed duplicatd memory allocation bug.
drm/i915: fixup load-detect on enabled, but not active pipe
Pull x86 fixes from Ingo Molnar.
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/apic: Use x2apic physical mode based on FADT setting
x86/mrst: Quiet sparse noise about plain integer as NULL pointer
x86, intel_cacheinfo: Fix error return code in amd_set_l3_disable_slot()
Pull perf fixes from Ingo Molnar.
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix perf_event_for_each() to use sibling
perf symbols: Read plt symbols from proper symtab_type binary
tracing: Fix stacktrace of latency tracers (irqsoff and friends)
perf tools: Add 'G' and 'H' modifiers to event parsing
tracing: Fix regression with tracing_on
perf tools: Drop CROSS_COMPILE from flex and bison calls
perf report: Fix crash showing warning related to kernel maps
tracing: Fix build breakage without CONFIG_PERF_EVENTS (again)
Pull build fixes for less mainstream architectures from Paul Gortmaker:
"These are fixes for frv(1), blackfin(2), powerpc(1) and xtensa(4).
Fortunately the touches are nearly all specific to files just used by
the arch in question. The two touches to shared/common files
[kernel/irq/debug.h and drivers/pci/Makefile] are trivial to assess as
no risk to anyone.
Half of them relate to xtensa directly. It was only when I fixed the
last xtensa issue that I realized that the arch has been broken for a
significant time, and isn't a specific v3.4 regression. So if you
wanted, we could leave xtensa lying bleeding in the street for a
couple more weeks and queue those for 3.5. But given they are no risk
to anyone outside of xtensa, I figured to just leave them in.
If you are OK with taking the xtensa fixes, then please pull to get:
- one last implicit include uncovered by system.h that is in a file
specific to just one powerpc defconfig. (I'd sync'd with BenH).
- fix an oversight in the PCI makefile where shared code wasn't being
compiled for ARCH=frv
- fix a missing include for GPIO in blackfin framebuffer.
- audit and tag endif in blackfin ezkit board file, in order to find
and fix the misplaced endif masking a block of code.
- fix irq/debug.h choice of temporary macro names to be more internal
so they don't conflict with names used by xtensa.
- fix a reference to an undeclared local var in xtensa's signal.c
- fix an implicit bug.h usage in xtensa's asm/io.h uncovered by my
removing bug.h from kernel.h
- fix xtensa to properly indicate it is using asm-generic/hardirq.h
in order to resolve the link error - undefined ack_bad_irq
The xtensa still fails final link as my latest binutils does something
evil when ld forward-relocates unlikely() blocks, but in theory people
who have older/valid toolchains could now use the thing."
* 'for-v3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
xtensa: fix build fail on undefined ack_bad_irq
blackfin: fix ifdef fustercluck in mach-bf538/boards/ezkit.c
blackfin: fix compile error in bfin-lq035q1-fb.c
pci: frv architecture needs generic setup-bus infrastructure
irq: hide debug macros so they don't collide with others.
xtensa: fix build error in xtensa/include/asm/io.h
xtensa: fix build failure in xtensa/kernel/signal.c
powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig]
Pull security key doc update from Jeff Layton:
"Ordinarily, I send my patches through others' trees, but David
suggested I just send this one to you directly since it's just a
Documentation/ update"
* 'docs-3.4' of git://git.samba.org/jlayton/linux:
keys: update the documentation with info about "logon" keys
In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
called even if no events were pending. This resulted in (depending on
workload) about a 100 times as many xen_version hypercalls as
necessary.
Fix this by correcting the sense of the conditional jump.
This seems to give a significant performance benefit for some
workloads.
There is some subtle tricksy "..since the check here is trying to
check both pending and masked in a single cmpw, but I think this is
correct. It will call check_events now only when the combined
mask+pending word is 0x0001 (aka unmasked, pending)." (Ian)
CC: stable@kernel.org
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This patch ensures that the last bit of a transfer gets correctly
flushed out of the register.
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This condition is used to determine 8 bits or 16 and 32 bits transfer.
Obviously it is reversed.
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Since the member was dropped from the common Blackfin header, we need
to stop using it in the SPORT driver too.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
No other SPI controller has this field, and SPI clients should be setting
this up in their own drivers. So drop it from the Blackfin controller to
keep people from using it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Each transfer may have its own bits per word.
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This controller is only for blackfin 5xx soc, so rename it to BFIN5XX
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Currently, if we request for frequency greater than maximum possible, spi driver
returns error.
For example, if the spi block src frequency is 333/4 MHz, i.e. 83.33.. MHz,
maximum frequency programmable would be src/2. Which would come around 41.6...
It is difficult to pass frequency in these figures. We normally try to program
in round figures, like 42 MHz and it should get programmed to <=
requested_frequency, i.e. 41.6...
For this to happen, we must not return error even if requested freq is higher
than max possible. But should program it to max possible.
Reported-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
We were not properly advertising the MODE bits supported by this driver, fix
that.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
We do not need to use a flag to indicate if the master driver is stopping
it is sufficient to perform spi master unregistering in the platform
driver's remove function.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This patch converts the bcm63xx SPI driver to use the SPI infrastructure
pump message queue. Since we were previously sleeping in the SPI
driver's transfer() function (which is not allowed) this is now fixed as well.
To complete that conversion a certain number of changes have been made:
- the transfer len is split into multiple hardware transfers in case its
size is bigger than the hardware FIFO size
- the FIFO refill is no longer done in the interrupt context, which was a
bad idea leading to quick interrupt handler re-entrancy
Tested-by: Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
A new enum indicating the dma channel direction was introduced by:
commit 49920bc669
dmaengine: add new enum dma_transfer_direction
The following commit changed spi-ep93xx to use the new enum:
commit a485df4b44
spi, serial: move to dma_transfer_direction
In doing so a sparse warning was introduced:
warning: mixing different enum types
int enum dma_data_direction versus
int enum dma_transfer_direction
This is produced because the 'dir' passed in ep93xx_spi_dma_prepare
is an enum dma_data_direction and is being used to set the
dma_slave_config 'direction' which is now an enum dma_transfer_direction.
Fix this by converting spi-ep93xx to use the new enum type in all
places.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Fix kernel-doc warning in spi.h (copy/paste):
Warning(include/linux/spi/spi.h:365): No description found for parameter 'unprepare_transfer_hardware'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
calculate_effective_freq() was still not optimized and there were cases when it
returned without error and with values of cpsr and scr as zero.
Also, the variable named found is not used well.
This patch targets to optimize and correct this routine. Tested for SPEAr.
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Tested-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
An entry for INTERNAL_VCE encoder was missing. Add it.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From Daniel Vetter
- VGA load-detect fix. This bug seems to be as old as the load-detect code
(2.6.30), but needs stupid userspace (upowerd trying to detect
connectors on dpms-off outputs) to actually kill the machine. And
obviously a machine without VGA-hotplug, otherwise we don't do load
detect.
- 2 interger overflow fixes for unpriviledged ioctls from Xi Wang.
- Fix SDVO regression for low-res (pixelclock < 100MHz) digital outputs,
introduce in 2.6.36.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: handle input/output sdvo timings separately in mode_set
drm/i915: fix integer overflow in i915_gem_do_execbuffer()
drm/i915: fix integer overflow in i915_gem_execbuffer2()
drm/i915: fixup load-detect on enabled, but not active pipe
From Inki Dae:
this patch set fixes gem allocation and mapping issue between user space and
physical memory region.
* 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-2.6-samsung:
drm/exynos: added missed vm area region mapping type.
drm/exynos: fixed exynos_drm_gem_map_pages bug.
drm/exynos: fixed duplicatd memory allocation bug.
We did a similar check for the P-states but did not do it for
the C-states. What we want to do is ignore cases where the DSDT
has definition for sixteen CPUs, but the machine only has eight
CPUs and we get:
xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14
Reported-by: Tobias Geiger <tobias.geiger@vido.info>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
When we boot on a machine that can hotplug CPUs and we
are using 'dom0_max_vcpus=X' on the Xen hypervisor line
to clip the amount of CPUs available to the initial domain,
we get this:
(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
.. snip..
DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
.. snip.
SMP: Allowing 64 CPUs, 32 hotplug CPUs
installing Xen timer for CPU 7
cpu 7 spinlock event irq 361
NMI watchdog: disabled (cpu7): hardware events not enabled
Brought up 8 CPUs
.. snip..
[acpi processor finds the CPUs are not initialized and starts calling
arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
CPU 8 got hotplugged
CPU 9 got hotplugged
CPU 10 got hotplugged
.. snip..
initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
calling erst_init+0x0/0x2bb @ 1
[and the scheduler sticks newly started tasks on the new CPUs, but
said CPUs cannot be initialized b/c the hypervisor has limited the
amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
The spinlock tries to kick the other CPU, but the structure for that
is not initialized and we crash.]
BUG: unable to handle kernel paging request at fffffffffffffed8
IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
PGD 180d067 PUD 180e067 PMD 0
Oops: 0002 [#1] SMP
CPU 7
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffff81035289>] [<ffffffff81035289>] xen_spin_lock+0x29/0x60
RSP: e02b:ffff8801fb9b3a70 EFLAGS: 00010282
With this patch, we cap the amount of vCPUS that the initial domain
can run, to exactly what dom0_max_vcpus=X has specified.
In the future, if there is a hypercall that will allow a running
domain to expand past its initial set of vCPUS, this patch should
be re-evaluated.
CC: stable@kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
With the introduction of static keys, anything using tracepoints blows up
in the following manner:
include/trace/events/oom.h:8:13: error: initializer element is not constant
include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update')
include/trace/events/oom.h:8:13: error: initializer element is not constant
include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update.key')
This is a result of the STATIC_KEY_INIT_xxx defs wrapping ATOMIC_INIT()
which on sh includes an atomic_t typecast. Given that we don't really
need the typecast for anything anymore, the simplest solution is simply
to kill off the cast.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Pull arch/tile fixes from Chris Metcalf:
"One change fixes a platform-independent bug about environment var
handling in the boot command line. The other is a trivial
tile-specific bug fix to avoid a link-time warning."
* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
arch/tile: fix a couple of functions that should be __init
init: fix bug where environment vars can't be passed via boot args
- fix memory leak in mlx4
- fix two problems with new MAD response generation code
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABCAAGBQJPmYfMAAoJEENa44ZhAt0h06IP/jPJeH855wC2RgWXY2Fd+b6w
K/DQVE2MaX2f8EHuAB5MKoC0zzchKNu0GTMbrZMizbocDBmIU6ibF3MKx2rycSBC
FI906X7FFAeSyaywrI+k+ZGxVQYAck1QFDr44WiyJ400r8BGbx9ZECKvIyEwjaUa
RpRn4Pui4IjMV7GFqiziUsa9uo4xKYagjNfeInAZXelzIN76Coeae28dAIE2rPT/
BTcrtQ2JMG6H4AVGTImTP+Kqk1Cm7apBeHS4+SGWWTdw1WH4IcMqPmxHBUUtKTWt
UnlgpHquuC913VpkbkGeog32iAndhHgAkfs67Rs0IFwck127Il/DiPK/zir2zkZ2
YVilzYIxrSUYqPZYfKFcrKsnjfM+HJxBEPCfDjxfG0TjrVS8tnc75Uq1NvIt6e42
lcIclLDyZtdsMLmJlsTsT5cF7HlThSjpZDSgmMi2eeOI0RKoqRyyGGwiAIq7Ud2a
oRa+bheh4pBD2lvzd62uEkgMkTaToAz3I/vlbOTSwxYg2skoHUpwNPCsmstsQ7RU
BHi7Nl5DLNT5lNBTIouWvbilpXs8eXwgcNrQcWSYaPeY2aDsGAAdi9Q4BadENao9
dmxOtqjryctX7U7LGDRmNDIfiyPY5AodDUJjFux1JwqbdSCGf1Lz7uvDWu7gqL9V
TCJFAK54okexpoyV6Vgv
=iRrT
-----END PGP SIGNATURE-----
Merge tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
Pull infiniband fixes from Roland Dreier:
"A few fixes for regressions introduced in 3.4-rc1:
- fix memory leak in mlx4
- fix two problems with new MAD response generation code"
* tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/mlx4: Fix memory leaks in ib_link_query_port()
IB/mad: Don't send response for failed MADs
IB/mad: Set 'D' bit in response for unhandled MADs
Commit e520c41085
"xtensa: convert to asm-generic/hardirq.h"
converted over to using the asm-generic parts, but it also
added the sentinel
#define ack_bad_irq ack_bad_irq
which tells asm-generic to _not_ use the common ack_bad_irq.
Since e520c41 deleted the duplicated code from the arch specific
file, we _do_ want the asm-generic one in scope. So delete
the trigger define above which hides it. In doing so we'll
realize that we've got to delete the almost-duplicate prototype
as well to avoid "static declaration ... follows non-static".
Cc: Christoph Hellwig <hch@lst.de>
Cc: Chris Zankel <chris@zankel.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
A workaround for an ASUS laptop and a few ASoC changes;
most of the commits are tagged for stable, too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAABAgAGBQJPmUKpAAoJEGwxgFQ9KSmk3eIP/iGu1az70dixqEjfOifTcJcv
V3VS5HIko0n3+iAkBQr+lo7RLnMQsqy5DQzv6h8FVzuyYgYVvT2eKLPEUh1p+LNw
tZaosfrrnvGhthF5uDVKUeDe69wujfW68gLJJdp+dnUU28RG/cCuUu4+ae2nCBE+
Glus4Zn5wC06P2Uuv67AHYiraCahiuwbrrXAYa0X8glEE7Vpg5t09d3l/KHBIbFH
g46UF5D7LYoMHEThgeyYgq8lEK2THUJlLl887dZTjSqS9ps52cOyRlQmljRvvDXw
BNdOSSu0YqRBX0ja7kIkadCVfZpQEyqfW6ISETozchPYogO9SHXz0plEB/OXWB+q
dUwJGRdoWeJtW/jyd4RHIJlxYektY1ygUsrCeKdIM3lO3M8RnwMosUcy0rW9yKsA
C8BIJz6KdEsiOHpTvvadln5MoarvoPIQXdw8yahJnisd5Kbrx1bQX8PPLhOatRpF
U125ywvif5miV66+0ocnTB2eNJTy4zyokpR6JAQ1z9I+IZOF4mwH+OgLEGlTm28k
Dn/UCxYhEGvLH0vrtU/WiPXE42Jw1ZeRRn56ErWPWOpRBzaJjK4hRu9zFK3cL9xh
bBfP4hsMq2X8lW5nIFz5FLeocnIaMe0CCyNH9X+EoH+BS9HVx274a63t0te8fKtV
E457r7iBnssONY4WIG2l
=KjOE
-----END PGP SIGNATURE-----
Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A workaround for an ASUS laptop and a few ASoC changes; most of the
commits are tagged for stable, too."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: wm8994: Improve sequencing of AIF channel enables
ALSA: HDA: Add external mic quirk for Asus Zenbook UX31E
ASoC: fsi: update for dmaengine prep_slave_sg fallout.
ASoC: core: Fix card RTD count for deferred probe.
ASoC: cs42l73: don't use negative array index
ASoC: dapm: Ensure power gets managed for line widgets
Pull a watchdog fix from Wim Van Sebroeck:
"It will fix the size when reading or writing to WD Timer port 0x72 in
the hpwdt driver."
* git://www.linux-watchdog.org/linux-watchdog:
hpwdt: Only BYTE reads/writes to WD Timer port 0x72
Pull timer fixes from Thomas Gleixner.
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tick: Fix the spurious broadcast timer ticks after resume
tick: Ensure that the broadcast device is initialized
tick: Fix oneshot broadcast setup really
Merge fixes from Andrew Morton:
"13 fixes. The acerhdf patches aren't (really) fixes. But they've
been stuck in my tree for up to two years, sent to Matthew multiple
times and the developers are unhappy."
* emailed from Andrew Morton <akpm@linux-foundation.org>: (13 patches)
mm: fix NULL ptr dereference in move_pages
mm: fix NULL ptr dereference in migrate_pages
revert "proc: clear_refs: do not clear reserved pages"
drivers/rtc/rtc-ds1307.c: fix BUG shown with lock debugging enabled
arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file
hugetlbfs: lockdep annotate root inode properly
acerhdf: lowered default temp fanon/fanoff values
acerhdf: add support for new hardware
acerhdf: add support for Aspire 1410 BIOS v1.3314
fs/buffer.c: remove BUG() in possible but rare condition
mm: fix up the vmscan stat in vmstat
epoll: clear the tfile_check_list on -ELOOP
mm/hugetlb: fix warning in alloc_huge_page/dequeue_huge_page_vma
In pirq_check_eoi_map use the pirq number rather than the Linux irq
number to check whether an eoi is needed in the pirq_eoi_map.
The reason is that the irq number is not always identical to the
pirq number so if we wrongly use the irq number to check the
pirq_eoi_map we are going to check for the wrong pirq to EOI.
As a consequence some interrupts might not be EOI'ed by the
guest correctly.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Tobias Geiger <tobias.geiger@vido.info>
[v1: Added some extra wording to git commit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
There are exactly four users of __monitor and __mwait:
- cstate.c (which allows acpi_processor_ffh_cstate_enter to be called
when the cpuidle API drivers are used. However patch
"cpuidle: replace xen access to x86 pm_idle and default_idle"
provides a mechanism to disable the cpuidle and use safe_halt.
- smpboot (which allows mwait_play_dead to be called). However
safe_halt is always used so we skip that.
- intel_idle (same deal as above).
- acpi_pad.c. This the one that we do not want to run as we
will hit the below crash.
Why do we want to expose MWAIT_LEAF in the first place?
We want it for the xen-acpi-processor driver - which uploads
C-states to the hypervisor. If MWAIT_LEAF is set, the cstate.c
sets the proper address in the C-states so that the hypervisor
can benefit from using the MWAIT functionality. And that is
the sole reason for using it.
Without this patch, if a module performs mwait or monitor we
get this:
invalid opcode: 0000 [#1] SMP
CPU 2
.. snip..
Pid: 5036, comm: insmod Tainted: G O 3.4.0-rc2upstream-dirty #2 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffffa000a017>] [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
RSP: e02b:ffff8801c298bf18 EFLAGS: 00010282
RAX: ffff8801c298a010 RBX: ffffffffa03b2000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801c29800d8 RDI: ffff8801ff097200
RBP: ffff8801c298bf18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa000a000 R14: 0000005148db7294 R15: 0000000000000003
FS: 00007fbb364f2700(0000) GS:ffff8801ff08c000(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000179f038 CR3: 00000001c9469000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process insmod (pid: 5036, threadinfo ffff8801c298a000, task ffff8801c29cd7e0)
Stack:
ffff8801c298bf48 ffffffff81002124 ffffffffa03b2000 00000000000081fd
000000000178f010 000000000178f030 ffff8801c298bf78 ffffffff810c41e6
00007fff3fb30db9 00007fff3fb30db9 00000000000081fd 0000000000010000
Call Trace:
[<ffffffff81002124>] do_one_initcall+0x124/0x170
[<ffffffff810c41e6>] sys_init_module+0xc6/0x220
[<ffffffff815b15b9>] system_call_fastpath+0x16/0x1b
Code: <0f> 01 c8 31 c0 0f 01 c9 c9 c3 00 00 00 00 00 00 00 00 00 00 00 00
RIP [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
RSP <ffff8801c298bf18>
---[ end trace 16582fc8a3d1e29a ]---
Kernel panic - not syncing: Fatal exception
With this module (which is what acpi_pad.c would hit):
MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("mwait_check_and_back");
MODULE_LICENSE("GPL");
MODULE_VERSION();
static int __init mwait_check_init(void)
{
__monitor((void *)¤t_thread_info()->flags, 0, 0);
__mwait(0, 0);
return 0;
}
static void __exit mwait_check_exit(void)
{
}
module_init(mwait_check_init);
module_exit(mwait_check_exit);
Reported-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This file has lots and lots of ifdef, around structure decls
and structure usages. The failure issue was that we would
build the BF538-EZKIT_defconfig and get:
arch/blackfin/mach-bf538/boards/ezkit.c:924:3: error: 'bfin_lq035q1_device'
undeclared here (not in a function)
even though the same ifdef _appeared_ to enable both the struct
declaration and the code that used it. Yet cpp was telling us we
didn't have the struct, but we still had the usage of it.
However, _appeared_ is the operative word. After marking all the
anonymous #endif with their parent #ifdef config options, it was
_then_ clear that there was a misplaced #endif that was hiding
the struct declaration.
The real guts of the patch boils down to this:
-#endif
+#endif /* CONFIG_MTD_M25P80 */
+#endif /* CONFIG_SPI_BFIN5XX */
[...]
-#endif /* spi master and devices */
but since I had to tag the #endif with their respective #ifdef
options to find this misplaced SPI endif, it would be silly to
then go and delete them all. So they stay.
Cc: Sonic Zhang <sonic.zhang@analog.com>
Cc: Bob Liu <lliubbo@gmail.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
This file has an implicit dependency on GPIO stuff, showing
up as the following build failure:
drivers/video/bfin-lq035q1-fb.c:369:6: error: 'GPIOF_OUT_INIT_LOW' undeclared
Other more global bfin build issues prevent an automated bisect, but
it really doesn't matter - simply add in the appropriate header.
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Otherwise we get this link failure for frv's defconfig:
LD .tmp_vmlinux1
drivers/built-in.o: In function `pci_assign_resource':
(.text+0xbf0c): undefined reference to `pci_cardbus_resource_alignment'
drivers/built-in.o: In function `pci_setup':
pci.c:(.init.text+0x174): undefined reference to `pci_realloc_get_opt'
pci.c:(.init.text+0x1a0): undefined reference to `pci_realloc_get_opt'
make[1]: *** [.tmp_vmlinux1] Error 1
Cc: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the situation by adding an explicit output_dtd to the sdvo
mode_set function and streamline the code-flow by moving the input and
output mode setting in the sdvo encode together.
Furthermore testing showed that the sdvo input timing needs the
unadjusted dotclock, the sdvo chip will automatically compute the
required pixel multiplier to get a dotclock above 100 MHz.
Fix this up when converting a drm mode to an sdvo dtd.
This regression was introduced in
commit c74696b9c8
Author: Pavel Roskin <proski@gnu.org>
Date: Thu Sep 2 14:46:34 2010 -0400
i915: revert some checks added by commit 32aad86f
particularly the following hunk:
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 093e914..62d22ae 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder,
/* We have tried to get input timing in mode_fixup, and filled into
adjusted_mode */
- if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
- intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+ intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+ if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
- } else
- intel_sdvo_get_dtd_from_mode(&input_dtd, mode);
/* If it's a TV, we already set the output timing in mode_fixup.
* Otherwise, the output timing is equal to the input timing.
Due to questions raised in review, below a more elaborate analysis of
the bug at hand:
Sdvo seems to have two timings, one is the output timing which will be
sent over whatever is connected on the other side of the sdvo chip (panel,
hdmi screen, tv), the other is the input timing which will be generated by
the gmch pipe. It looks like sdvo is expected to scale between the two.
To make things slightly more complicated, we have a bunch of special
cases:
- For lvds panel we always use a fixed output timing, namely
intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
- Sdvo has an interface to generate a preferred input timing for a given
output timing. This is the confusing thing that I've tried to clear up
with the follow-on patches.
- A special requirement is that the input pixel clock needs to be between
100MHz and 200MHz (likely to keep it within the electromechanical design
range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
doubled/quadrupled.
The thing this patch tries to fix is that the pipe needs to be
explicitly instructed to double/quadruple the pixels and needs the
correspondingly higher pixel clock, whereas the sdvo adaptor seems to
do that itself and needs the unadjusted pixel clock. For the sdvo
encode side we already set the pixel mutliplier with a different
command (0x21).
This patch tries to fix this mess by:
- Keeping the output mode timing in the unadjusted plain mode, safe
for the lvds case.
- Storing the input timing in the adjusted_mode with the adjusted
pixel clock. This way we don't need to frob around with the core
crtc mode set code.
- Fixing up the pixelclock when constructing the sdvo dtd timing
struct. This is why the first hunk of the patch is an integral part
of the series.
- Dropping the is_tv special case because input_dtd is equivalent to
adjusted_mode after these changes. Follow-up patches clear this up
further (by simply ripping out intel_sdvo->input_dtd because it's
not needed).
v2: Extend commit message with an in-depth bug analysis.
Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch is to correct the use of the iLO port 0x72 usage.
The port 0x72 is a byte size write/read and hpwdt is currently
writing a WORD.
Signed-off by: Thomas Mingarelli <thomas.mingarelli@hp.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
