The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that
currently writes (optionally) and reads back up to 5 "ports" consisting
of 8 channels each. It reads up to 32 1-bit channels but can only read
and write a whole port at once - it needs to handle up to 5 ports as the
first channel it reads might not be aligned on a port boundary. It
breaks out of the loop early if the next port it handles is beyond the
final port on the card. It also breaks out early on the 5th port in the
loop if the first channel was aligned. Unfortunately, it doesn't check
that the current port it is dealing with belongs to the comedi subdevice
the `insn_bits` handler is acting on. That's a bug.
Redo the `for` loop to terminate after the final port belonging to the
subdevice, changing the loop variable in the process to simplify things
a bit. The `for` loop could now try and handle more than 5 ports if the
subdevice has more than 40 channels, but the test `if (bitshift >= 32)`
ensures it will break out early after 4 or 5 ports (depending on whether
the first channel is aligned on a port boundary). (`bitshift` will be
between -7 and 7 inclusive on the first iteration, increasing by 8 for
each subsequent operation.)
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: <stable@vger.kernel.org> # 3.10.y 3.11.y 3.12.y
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch bumps the default number of tags allocated per session by
iscsi-target via transport_alloc_session_tags() -> percpu_ida_init()
by another (tag_num / 2).
This is done to take into account the tags waiting to be acknowledged
and released in iscsit_ack_from_expstatsn(), but who's number are not
directly limited by the CmdSN Window queue_depth being enforced by
the target.
Using a larger value here is also useful to prevent percpu_ida_alloc()
from having to steal tags from other CPUs when no tags are available
on the local CPU, while waiting for unacknowledged tags to be released.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch converts iscsit_ack_from_expstatsn() to populate a local
ack_list of commands, and call iscsit_free_cmd() directly from RX
thread context, instead of using iscsit_add_cmd_to_immediate_queue()
to queue the acknowledged commands to be released from TX thread
context.
It is helpful to release the acknowledge commands as quickly as
possible, along with the associated percpu_ida tags, in order to
prevent percpu_ida_alloc() from having to steal tags from other
CPUs while waiting for iscsit_free_cmd() to happen from TX thread
context.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch changes transport_generic_free_cmd() to only wait_for_tasks
when shutdown=true is passed to iscsit_free_cmd().
With the advent of >= v3.10 iscsi-target code using se_cmd->cmd_kref,
the extra wait_for_tasks with shutdown=false is unnecessary, and may
end up causing an extra context switch when releasing WRITEs.
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Power Well in use forces constantly PSR to exit.
On recent Kernel I noticed that PSR Performance Counter was always 0
indicating that PSR was never really achieved.
By masking LPSP, PSR can work normally and save power on Haswell.
Two bugs had been raised with PSR flag enabled:
- "Screen flickers when booted by enabling PSR in the kernel (i915.enable_psr=1) , the system is booting to a gray screen."
- "When booting the DUT with PSR feature enabled in the kernel (i915.enable_psr=1) , the system is booting to a gray screen."
Both bugs has been fixed by this patch.
v2: proper comment for -fixes
Tested-by: Selvaraj, Elavarasan <elavarasanx.selvaraj@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull ARC fix from Vineet Gupta:
"Chrisitian found/fixed issue with SA_SIGINFO based signal handler
corrupting the user space registers post after signal handling"
* 'for-curr' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: Fix signal frame management for SA_SIGINFO
Pull powerpc fixes from Ben Herrenschmidt:
"Here are a few powerpc fixes, all aimed at -stable, found in part
thanks to the ramping up of a major distro testing and in part thanks
to the LE guys hitting all sort interesting corner cases.
The most scary are probably the register clobber issues in
csum_partial_copy_generic(), especially since Anton even had a test
case for that thing, which didn't manage to hit the bugs :-)
Another highlight is that memory hotplug should work again with these
fixes.
Oh and the vio modalias one is worse than the cset implies as it
upsets distro installers, so I've been told at least, which is why I'm
shooting it to stable"
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/tm: Switch out userspace PPR and DSCR sooner
powerpc/tm: Turn interrupts hard off in tm_reclaim()
powerpc/perf: Fix handling of FAB events
powerpc/vio: Fix modalias_show return values
powerpc/iommu: Use GFP_KERNEL instead of GFP_ATOMIC in iommu_init_table()
powerpc/sysfs: Disable writing to PURR in guest mode
powerpc: Restore registers on error exit from csum_partial_copy_generic()
powerpc: Fix parameter clobber in csum_partial_copy_generic()
powerpc: Fix memory hotplug with sparse vmemmap
3e00a09d2f
(spi/hspi: Convert to core runtime PM)
enabled master->auto_runtime_pm.
Then, pm_runtime_enable() is required *before*
spi_register_master() calling.
This patch fixed it up.
Kernel will hang up with "spi_master spi0: Failed to power device: -13"
message without this patch.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This patch addresses a bug for backends such as IBLOCK that perform
asynchronous completion via transport_complete_cmd(), that will call
target_complete_failure_work() -> transport_generic_request_failure(),
upon exception status and invoke cmd->transport_complete_callback()
-> compare_and_write_callback() incorrectly during the failure case.
It adds a check for a non zero se_cmd->scsi_status within the first
invocation of compare_and_write_callback(), and will jump to out plus
up se_device->caw_sem before exiting the callback.
Reported-by: Thomas Glanzmann <thomas@glanzmann.de>
Tested-by: Thomas Glanzmann <thomas@glanzmann.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch addresses a bug when compare_and_write_callback() invoked from
target_complete_ok_work() hits an failure from __target_execute_cmd() ->
cmd->execute_cmd(), that ends up calling transport_generic_request_failure()
-> compare_and_write_post(), thus causing SCF_COMPARE_AND_WRITE_POST to
incorrectly be set.
The result of this bug is that target_complete_ok_work() no longer hits
the if (!rc && !(cmd->se_cmd_flags & SCF_COMPARE_AND_WRITE_POST) check
that forces an immediate return, and instead double completes the se_cmd
in question, triggering an OOPs in the process.
This patch changes compare_and_write_post() to only set this bit when a
failure has not already occured to ensure the immediate return from within
target_complete_ok_work(), and thus allow transport_generic_request_failure()
to handle the sending of the CHECK_CONDITION exception status.
Reported-by: Thomas Glanzmann <thomas@glanzmann.de>
Tested-by: Thomas Glanzmann <thomas@glanzmann.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch resets se_cmd->data_length for COMPARE_AND_WRITE emulation
within sbc_compare_and_write() to NoLB * block_size in order to address
a bug with FILEIO backends where a I/O failure will occur when data_length
does not match the I/O size being actually dispatched for the individual
per block READs + WRITEs.
This is done late enough in sbc_compare_and_write() after the memory
allocations have occured in transport_generic_new_cmd() to not cause
any unwanted side-effects.
Reported-by: Thomas Glanzmann <thomas@glanzmann.de>
Tested-by: Thomas Glanzmann <thomas@glanzmann.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The SRP specification requires:
"Response data shall be provided in any SRP_RSP response that is sent in
response to an SRP_TSK_MGMT request (see 6.7). The information in the
RSP_CODE field (see table 24) shall indicate the completion status of
the task management function."
So fix this to avoid the SRP initiator interprets task management functions
that succeeded as failed.
Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
Cc: stable@vger.kernel.org # 3.3+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Otherwise using any atomic memory operation will lock up the GPU due
to a Haswell hardware bug.
v2: Use the _MASKED_BIT_ENABLE macro. Drop drm parameter definition.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: <stable@vger.kernel.org>
[danvet: Fix checkpatch fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we do a treclaim or trecheckpoint we end up running with userspace
PPR and DSCR values. Currently we don't do anything special to avoid
running with user values which could cause a severe performance
degradation.
This patch moves the PPR and DSCR save and restore around treclaim and
trecheckpoint so that we run with user values for a much shorter period.
More care is taken with the PPR as it's impact is greater than the DSCR.
This is similar to user exceptions, where we run HTM_MEDIUM early to
ensure that we don't run with a userspace PPR values in the kernel.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We can't take IRQs in tm_reclaim as we might have a bogus r13 and r1.
This turns IRQs hard off in this function.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Commit 4df4899 "Add power8 EBB support" included a bug in the handling
of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields.
These values are pulled out of the event code using EVENT_THR_CTL_SHIFT,
however we were then or'ing that value directly into MMCR1.
This meant we were failing to set the FAB fields correctly, and also
potentially corrupting the value for PMC4SEL. Leading to no counts for
the FAB events and incorrect counts for PMC4.
The fix is simply to shift left the FAB value correctly before or'ing it
with MMCR1.
Reported-by: Sooraj Ravindran Nair <soonair3@in.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
modalias_show() should return an empty string on error, not -ENODEV.
This causes the following false and annoying error:
> find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null
cat: /sys/devices/vio/4000/modalias: No such device
cat: /sys/devices/vio/4001/modalias: No such device
cat: /sys/devices/vio/4002/modalias: No such device
cat: /sys/devices/vio/4004/modalias: No such device
cat: /sys/devices/vio/modalias: No such device
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():
page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
Before the panic() we got a page allocation failure for an order-2
allocation. There appears to be memory free, but perhaps not in the
ATOMIC context. I looked through all the call-sites of
iommu_init_table() and didn't see any obvious reason to need an ATOMIC
allocation. Most call-sites in fact have an explicit GFP_KERNEL
allocation shortly before the call to iommu_init_table(), indicating we
are not in an atomic context. There is some indirection for some paths,
but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
With this change under the same conditions, we have not been able to
reproduce the panic.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
arch/powerpc/kernel/sysfs.c exports PURR with write permission.
This may be valid for kernel in phyp mode. But writing to
the file in guest mode causes crash due to a priviledge violation
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
The csum_partial_copy_generic() function saves the PowerPC non-volatile
r14, r15, and r16 registers for the main checksum-and-copy loop.
Unfortunately, it fails to restore them upon error exit from this loop,
which results in silent corruption of these registers in the presumably
rare event of an access exception within that loop.
This commit therefore restores these register on error exit from the loop.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The csum_partial_copy_generic() uses register r7 to adjust the remaining
bytes to process. Unfortunately, r7 also holds a parameter, namely the
address of the flag to set in case of access exceptions while reading
the source buffer. Lacking a quantum implementation of PowerPC, this
commit instead uses register r9 to do the adjusting, leaving r7's
pointer uncorrupted.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Previous commit 46723bfa540... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
when sparse vmemmap is not defined.
This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
register_page_bootmem_info_node. Without this we get a BUG_ON for memory
hot remove in put_page_bootmem().
This also adds a stub for register_page_bootmem_memmap to allow ppc to build
with sparse vmemmap defined. Leaving this as a stub is fine since the same
vmemmap addresses are also handled in vmemmap_populate and as such are
properly mapped.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.9+]
gfn_to_memslot() can return NULL or invalid slot. We need to check slot
validity before accessing it.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
IORESOURCE_BUSY is used to mark temporary driver mem-resources
instead of global regions. This suppresses warnings if regions
overlap with a region marked as BUSY.
This was always the case for VESA/VGA/EFI framebuffer regions so
do the same for simplefb regions. The reason we do this is to
allow device handover to real GPU drivers like
i915/radeon/nouveau which get the same regions via PCI BARs.
Maybe at some point we will be able to unregister platform
devices properly during the handover. In this case the simplefb
region would get removed before the new region is created.
However, this is currently not the case and would require rather
huge changes in remove_conflicting_framebuffers(). Add the BUSY
marker now and try to eventually rewrite the handover for a next release.
Also see kernel/resource.c for more information:
/*
* if a resource is "BUSY", it's not a hardware resource
* but a driver mapping of such a resource; we don't want
* to warn for those; some drivers legitimately map only
* partial hardware resources. (example: vesafb)
*/
This suppresses warnings like:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390()
Info: mapping multiple BARs. Your kernel is fine.
Call Trace:
dump_stack+0x54/0x8d
warn_slowpath_common+0x7d/0xa0
warn_slowpath_fmt+0x4c/0x50
iomem_map_sanity_check+0xac/0xe0
__ioremap_caller+0x2e3/0x390
ioremap_wc+0x32/0x40
i915_driver_load+0x670/0xf50 [i915]
...
Reported-by: Tom Gundersen <teg@jklm.no>
Tested-by: Tom Gundersen <teg@jklm.no>
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1380724864-1757-1-git-send-email-dh.herrmann@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We have a fairly large batch of fixes this time around, mostly just due to
various platforms all having a fix or two more than usual.
Worth pointing out are:
- A fix for EDMA on Davinci/OMAP where channel allocation broke with
the DT conversion. Due to some miscommunication we didn't
understand the impact of the breakage, so we were pushing back on it
for 3.12, but it sounds like it's actually breaking quite a few people
out there.
- A bunch of fixes for Marvell platforms, some straggling fixes for
merge window fallout and some fixes for a couple of the platforms
(Netgear RN102 in particular).
- A fix for a race between multi-cluster power management and cpu hotplug
on Versatile Express.
And a bunch of other smaller fixes that all add up.
We'll be switching over into stricter regressions-only mode from here
on out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSTO8aAAoJEIwa5zzehBx3t/4P/jVzo0/Yvs0GtlD9tyC5uHgc
aDvz7cjP+/w8Is2amSBr+QR/bslT7gYjyBB9cBZluH/v1juohl16jRZMxHOmoV80
f3OfdJ7gXbKRRgrZNw9sBGWEfKrqb/Zr86CMOm51RpLizhHGXv+88DR/Rc63GgTl
P+NBbhyL9DiL3ox7OLM7UlMafovTR0HegeypMkWghBGaIwsgjheNz1xL0/oi+6tW
i74ehXBqoxpuHXm7UzdVD0VcQ+/GCXFo+yC0BrnGoNZG77Etq9CjpNRV3YFVZhCt
qD9RIznRDX2bA1Mcn74bFB9H+eL4c866p/gAH8tgbwdym9KtTcqNgYTR2nL5aAHa
OfD23lsaiy7yftPQX4bnD53bzeXJCJ+246SECK06fphS6PihYPK6iubxVL4yA5e/
iwzqCPQ3+f9NmC4+tLoydA2xzSHtgeCQc+smYVQlyyDMtEUaCzj58GDKebUpm62X
uMIQ8wrDRSJXURZl708UUixEvzQ6OLVgp1B3ASbedbh542qTQIpC2W8FIkYOUb6u
S7uErba0u/UC+bxBlAYNWnBM1npT//bZgCC8LRAJ+S3HIv8OGhHStsCZfGQxbeND
NxgPbHJPgSQu6RzaHcYSweuO38cfl6zkNcor8gf6ts3UOYnJuD+l8PLfqN13Erjm
NUL6gyQIF4uekR4GOTdI
=DLem
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"We have a fairly large batch of fixes this time around, mostly just
due to various platforms all having a fix or two more than usual.
Worth pointing out are:
- A fix for EDMA on Davinci/OMAP where channel allocation broke with
the DT conversion. Due to some miscommunication we didn't
understand the impact of the breakage, so we were pushing back on
it for 3.12, but it sounds like it's actually breaking quite a few
people out there.
- A bunch of fixes for Marvell platforms, some straggling fixes for
merge window fallout and some fixes for a couple of the platforms
(Netgear RN102 in particular).
- A fix for a race between multi-cluster power management and cpu
hotplug on Versatile Express.
And a bunch of other smaller fixes that all add up.
We'll be switching over into stricter regressions-only mode from here
on out"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
ARM: multi_v7_defconfig: add SDHCI for i.MX
bus: mvebu-mbus: Fix optional pcie-mem/io-aperture properties
ARM: mvebu: add missing DT Mbus ranges and relocate PCIe DT nodes for RN102
ARM: at91: sam9g45: shutdown ddr1 too when rebooting
MAINTAINERS: ARM: SIRF: use kernel.org mail box
MAINTAINERS: ARM: SIRF: add missed drivers into maintain list
ARM: edma: Fix clearing of unused list for DT DMA resources
ARM: vexpress: tc2: fix hotplug/idle/kexec race on cluster power down
ARM: dts: sirf: fix interrupt and dma prop of VIP for prima2 and atlas6
ARM: dts: sirf: fix the ranges of peri-iobrg of prima2
ARM: dts: makefile: build atlas6-evb.dtb for ARCH_ATLAS6
ARM: dts: sirf: fix fifosize, clks, dma channels for UART
ARM: mvebu: Add DT entry for ReadyNAS 102 to use gpio-poweroff driver
ARM: mvebu: fix ReadyNAS 102 Power button GPIO to make it active high
ARM: mach-integrator: Add stub for pci_v3_early_init() for !CONFIG_PCI
ARM: shmobile: Remove #gpio-ranges-cells DT property
gpio: rcar: Remove #gpio-range-cells DT property usage
ARM: shmobile: armadillo: fixup ether pinctrl naming
ARM: shmobile: Lager: add Micrel KSZ8041 PHY fixup
ARM: shmobile: update SDHI DT compatibility string to the <unit>-<soc> format
...
Previously, when a signal was registered with SA_SIGINFO, parameters 2
and 3 of the signal handler were written to registers r1 and r2 before
the register set was saved. This led to corruption of these two
registers after returning from the signal handler (the wrong values were
restored).
With this patch, registers are now saved before any parameters are
passed, thus maintaining the processor state from before signal entry.
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Pull sparc fixes from David Miller:
"Couple of small bug fixes:
1) strlcpy in ldom_reboot() is still not quite right, use sprintf
instead from Kees Cook.
2) Generic hugetlb interface pte checks should use the widest return
type, otherwise high bits can get chopped off.
3) Fix build with PCI MSI enabled on 32-bit sparc"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc: fix MSI build failure on Sparc32
sparc: remove deprecated IRQF_DISABLED
mm: Fix generic hugetlb pte check return type.
sparc: fix ldom_reboot buffer overflow harder
- mvebu
- fix ReadyNAS 102 power button (needs to be active high)
- fix ReadyNAS 102 automated rebooting (prevent hang) by add gpio-poweroff
node
- fix booting ReadyNAS 102 by adding MBus ranges and PCIe DT nodes
- mvebu-mbus: prevent PCIe driver from continuing with corrupted resource
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAABAgAGBQJSTERhAAoJEAi3KVZQDZAeFaQH/jmhAZwvSrB7MeTTY7J9eAcl
n4cFHImBiSb6IdDaocKB+yOmEgq/X2LS/DjK71sa0+CQsTq9B5nHxMHioogdUrG7
S8ofIjqu90CBOZ1I5IMSPmA3uOc1B2+wYi9uLxmajMTzYVDDBEZh9LuMy/GjwzU2
/g09RedQ3XkWDVv3pdPdEiC6KZ/gg7gejxOLv0nv9ydxr0DB8/VwmBHWFC0ghawB
3EchoagJ3M+mAbUaxtY6cauV2nnAJOO5mV6ZHl2tIOj4/Mhn8Le/C1t+Zcdf+U82
iAvqWmiRc3Vk96g8xXZWwZoPL7vhidLcE7dpOIZ2ymq5+g3esTaailqRxRqS9+c=
=uNPR
-----END PGP SIGNATURE-----
Merge tag 'fixes-3.12-2' of git://git.infradead.org/linux-mvebu into fixes
From Jason Cooper:
mvebu fixes for v3.12 (round 2)
- mvebu
- fix ReadyNAS 102 power button (needs to be active high)
- fix ReadyNAS 102 automated rebooting (prevent hang) by add gpio-poweroff
node
- fix booting ReadyNAS 102 by adding MBus ranges and PCIe DT nodes
- mvebu-mbus: prevent PCIe driver from continuing with corrupted resource
* tag 'fixes-3.12-2' of git://git.infradead.org/linux-mvebu:
bus: mvebu-mbus: Fix optional pcie-mem/io-aperture properties
ARM: mvebu: add missing DT Mbus ranges and relocate PCIe DT nodes for RN102
ARM: mvebu: Add DT entry for ReadyNAS 102 to use gpio-poweroff driver
ARM: mvebu: fix ReadyNAS 102 Power button GPIO to make it active high
Signed-off-by: Olof Johansson <olof@lixom.net>
Turn on SDHCI for i.MX support so machines can boot with local rootfs
on SD. Tested on a Wandboard Quad.
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Commit ebd97be635 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option')
removes the ARCH_SUPPORTS_MSI Kconfig option that allowed
architectures to indicate whether they support PCI MSI or not. Now,
PCI MSI support can be compiled in on any architecture thanks to the
use of weak functions thanks to 4287d824f2 ('PCI: use weak functions
for MSI arch-specific functions').
So, architecture specific code is now responsible to ensure that its
PCI MSI code builds in all cases, or be appropriately conditionally
compiled.
On Sparc, the MSI support is only provided for Sparc64, so the
ARCH_SUPPORTS_MSI kconfig option was only selected for SPARC64, and
not for the Sparc architecture as a whole. Therefore, removing
ARCH_SUPPORTS_MSI broke Sparc32 configurations with CONFIG_PCI_MSI=y,
because the Sparc-specific MSI code is not designed to be built on
Sparc32.
To solve this, this commit ensures that the Sparc MSI code is only
built on Sparc64. This is done thanks to a new Kconfig Makefile helper
option SPARC64_PCI_MSI, modeled after the existing SPARC64_PCI. The
SPARC64_PCI_MSI option is an hidden option that is true when both
Sparc64 PCI support is enabled and MSI is enabled. The
arch/sparc/kernel/pci_msi.c file is now only built when
SPARC64_PCI_MSI is true.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch proposes to remove the IRQF_DISABLED flag from sparc architecture
code. It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The include/asm-generic/hugetlb.h stubs that just vector huge_pte_*()
calls to the pte_*() implementations won't work in certain situations.
x86 and sparc, for example, return "unsigned long" from the bit
checks, and just go "return pte_val(pte) & PTE_BIT_FOO;"
But since huge_pte_*() returns 'int', if any high bits on 64-bit are
relevant, they get chopped off.
The net effect is that we can loop forever trying to COW a huge page,
because the huge_pte_write() check signals false all the time.
Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: David Rientjes <rientjes@google.com>
The length argument to strlcpy was still wrong. It could overflow the end of
full_boot_str by 5 bytes. Instead of strcat and strlcpy, just use snprint.
Reported-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Install targets (install, zinstall, uinstall) on arm have a dependency
to vmlinux. This may cause parts of the kernel to be rebuilt during
installation. We must avoid this since this may run as root. Install
targets "ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE." as Linus
emphasized this in:
http://lkml.org/lkml/2013/7/10/600
So on arm and maybe other archs we need the same as for x86:
1648e4f8 x86, kbuild: make "make install" not depend on vmlinux
This patch fixes this for arm. Dependencies are removed and instead a
check to install.sh is added for the files that are needed.
This issue was uncovered by this build error where the -j option is
used in conjunction with install targets:
$ make <makeflags>
$ make <makeflags> zinstall
...
DEPMOD
Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease>
(INSTALL_MOD_PATH and INSTALL_PATH variables set, so no root perms
required in this case.)
The problem is that zinstall on arm due to its dependency to vmlinux
does a prepare/prepare3 and finally does a forced rewrite of
kernel.release even if it exists already.
Rebuilding kernel.release removes it first and then recreates it. This
might race with another parallel make job running depmod.
So this patch should fix this one too.
Also quoting $(KERNELRELEASE) arg for install.sh as this messes
argument order in case it is empty (which is the case if the kernel
was not built yet).
Signed-off-by: Robert Richter <robert.richter@linaro.org>
Signed-off-by: Robert Richter <rric@kernel.org>
Acked-by: Michal Marek <mmarek@suse.cz>.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This config item already exists generically in lib/Kconfig.debug.
Remove the duplicate config in arm64.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
All small, mostly driver-specific fixes: a few ASoC driver fixes
(trivial stable fixes, sgtl5000 fixes), one DPCM fix, an old AC97 ID,
and a fix for HD-audio Conexant GPIO.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)
iQIcBAABAgAGBQJSS/NwAAoJEGwxgFQ9KSmk3Q4P/RwWxFa8kaXouJitWfwC6eMt
T+5nHdp3/fjQLhjjkKy7SIXKpIWk/H+qRgsWHhLybvBVK7vCQszf8FiJJOiasaTm
mdEqgo5dWrIaaQueO9//MPy7iPRzQHUSbEoEsfRfZGcc56ITZCfO0ank/3WBfG/0
X/G0ohW0vgULrh/LNcwIbDT00aPX0aBP+8OWfvMHGOmfW5WR9GdfZ0OXqGQtzqdy
XVfeBMAlwmmGkD7ERquJ3oE40fN/rPiFlQSqT/gSHnW9Q6yoxE45IGheXdRSzfSb
7rsGdns8xhjRLgxUEq0v96A5C669prG8gCMgOeIF0mJxiG55jyG6wSakuYUFczbF
Fgh6+EZjjooVBxTF5k82ZCFOlkJBaYPWVnq+GTH8qKqavhaqgafIr2a0l6G5uzSH
Zy8/h66O0GXKSAAxjTRf9NSPMiAerE/X3cCqSARLXMD+a2qGOOoJQJANTZ66mw05
ePtu6KzP0D0RbEVccHRW9hJZ4vJY8r7EIWzfTpd705R0A83bAJzyunVZP/a3r9yW
69OIB15510hGrFb3UozLiJSLNHKpB5g9xFsCBYXdiYMRbo0N3i0J882HNxbc15Ar
SHyi3WQ/cd1EgSKtECZ80FCdc5vDzaXYrNqrDIX9+cQxxBce0M86/r8lH/XMFoeL
jXIszWlJK+NFKzrEL9Qy
=7zvu
-----END PGP SIGNATURE-----
Merge tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"All small, mostly driver-specific fixes: a few ASoC driver fixes
(trivial stable fixes, sgtl5000 fixes), one DPCM fix, an old AC97 ID,
and a fix for HD-audio Conexant GPIO"
* tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix GPIO for Acer Aspire 3830TG
ALSA: ac97: Add ID for TI TLV320AIC27 codec
ASoC: imx-sgtl5000: Fix uninitialized pointer use in error path
ASoC: imx-sgtl5000: do not use devres on a foreign device
ASoC: blackfin: Add missing break statement to bf6xx
ASoC: 88pm860x: array overflow in snd_soc_put_volsw_2r_st()
ASoC: ab8500-codec: info leak in anc_status_control_put()
ASoC: max98095: a couple array underflows
ASoC: core: Only add platform DAI widgets once.
- Various build warning fixes.
- Correct the S5P pin count.
- Handle BIAS_DEFAULT properly in the Palmas driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSS9t4AAoJEEEQszewGV1ztdsP/12dV/JktKcqTRRijr2cYSQc
+pfQ2rMBlogjTfJSOOqAeaPKA/qDLlG/WbVZW6bH87CMojsZHSbOxboqcPiqshmk
9x+8BEcHxqjJkFcR2tPgVj/6S1ObFHD6fQ0Lv2m4MicfHpe6cUOIGevihfBV2mtR
3n0u+uxPhZhvBYrVbaPT6kwCcLKmsWwAT7KKMXVCD7I5Wx3PsrfvEW08lw8hv/n5
5f9IntvYga3SaLigLnHEeXVr9rXZqi4wl1FwAt3OXcT30wMIMaDxMKi990FCfech
K5PdW+wkN6TO5cFS/PwCqWHMXpASfeLCU0Iy9S1RU4XZUGL782QUyCspj+hWuaRh
uG9BSweF4iWRMzrHnNWIRIuNMMOArIr3XkB1xZ14dwBjZzeqBIXumiIV1XyWMcFe
48Tvu3czCXYoMqhNtIPIsWgQafONG7f0sFoGjMqoQJ8uNy2ipTq3aKaoH620r//a
AtCGfs/LdG/6Z/W5YKTjKzyyKoFWHhkoPzB+TVHrA4WZR5xunLol8EVWLdMUTkB+
8Ujxw7jpy2xQye59lg9bgaG5yroteot7O09vN6TEzMj9b9/0SrzpJaE/JsqpUlCB
r8veQuQboHqX/e3Uui4lME6SdA0UgFzBUEhX39raL6MKDuqsgX2uQOKdNS/KMNgB
iUUMr8mtN/jhI7FEdYn8
=k2j2
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v3.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- Various build warning fixes.
- Correct the S5P pin count.
- Handle BIAS_DEFAULT properly in the Palmas driver.
* tag 'pinctrl-v3.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: palmas: do not abort pin configuration for BIAS_DEFAULT
pinctrl: Correct number of pins for s5pv210
pinctrl: remove an unnecessary cast
pinctrl: fix pinconf_dbg_config_write return type
pinctrl: tegra114: Remove MODULE_ALIAS
* pm-fixes:
intel_pstate: fix no_turbo
cpufreq: cpufreq-cpu0: NULL is a valid regulator, part 2
cpufreq: SPEAr: Fix incorrect variable type
PM / hibernate: Fix user space driven resume regression
The frame check in i_usX2Y_urb_complete() and
i_usX2Y_usbpcm_urb_complete() is bogus and produces false positives as
described in this LAU thread:
http://linuxaudio.org/mailarchive/lau/2013/5/20/200177
This patch removes the check code entirely.
Cc: fzu@wemgehoertderstaat.de
Reported-by: Dr Nicholas J Bailey <nicholas.bailey@glasgow.ac.uk>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Mack <zonque@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added id, bindings and comments for Holtek USB ID 04d9:a081 SHARKOON
DarkGlider Gaming mouse to use the same corrections of the report
descriptor as Holtek 04d9:a04a. As the mouse exceed HID_MAX_USAGES
at the same offsets in the reported descriptor.
Tested on the hardware.
Signed-off-by: Anders F. U. Kiær <ablacksheep@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Even though device exist bit is set the underlying
HW device should be closed when the last reader
of the device is closed i.e. open count drops to zero.
Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
Reported-by: mika.westerberg@linux.intel.com
Tested-by: mika.westerberg@linux.intel.com
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
On my MacBook Air lfb_size is 4M, which makes the bitshit
overflow (to 256GB - larger than 32 bits), meaning we fall
back to efifb unnecessarily.
Cast to u64 to avoid the overflow.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Link: http://lkml.kernel.org/r/1380644320-1026-1-git-send-email-teg@jklm.no
Signed-off-by: Ingo Molnar <mingo@kernel.org>
