linux-toradex.git/drivers, branch v3.14.12

sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue

2014-07-09T18:18:29+00:00

commit fd1232b214af43a973443aec6a2808f16ee5bf70 upstream.

This patch fixes I/O errors with the sym53c8xx_2 driver when the disk
returns QUEUE FULL status.

When the controller encounters an error (including QUEUE FULL or BUSY
status), it aborts all not yet submitted requests in the function
sym_dequeue_from_squeue.

This function aborts them with DID_SOFT_ERROR.

If the disk has full tag queue, the request that caused the overflow is
aborted with QUEUE FULL status (and the scsi midlayer properly retries
it until it is accepted by the disk), but the sym53c8xx_2 driver aborts
the following requests with DID_SOFT_ERROR --- for them, the midlayer
does just a few retries and then signals the error up to sd.

The result is that disk returning QUEUE FULL causes request failures.

The error was reproduced on 53c895 with COMPAQ BD03685A24 disk
(rebranded ST336607LC) with command queue 48 or 64 tags.  The disk has
64 tags, but under some access patterns it return QUEUE FULL when there
are less than 64 pending tags.  The SCSI specification allows returning
QUEUE FULL anytime and it is up to the host to retry.

Signed-off-by: Mikulas Patocka 
Cc: Matthew Wilcox 
Cc: James Bottomley 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap

2014-07-09T18:18:29+00:00

commit fbc6c4a13bbfb420eedfdb26a0a859f9c07e8a7b upstream.

Function unifb_mmap calls functions which are defined in linux/mm.h
and asm/pgtable.h

The related error (for unicore32 with unicore32_defconfig):
	CC      drivers/video/fbdev/fb-puv3.o
	drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap':
	drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
				      function 'vm_iomap_memory'
	drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
				      function 'pgprot_noncached'

Signed-off-by: Zhichuang Sun 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Jingoo Han 
Cc: Daniel Vetter 
Cc: Joe Perches 
Cc: Laurent Pinchart 
Cc: linux-fbdev@vger.kernel.org
Acked-by: Xuetao Guan 
Signed-off-by: Tomi Valkeinen 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix display power sw state reporting

2014-07-09T18:18:28+00:00

commit b8c000d9bf23e7c1155ef421f595d1cbc25262da upstream.

Atm, we refcount both power domains and power wells and
intel_display_power_enabled_sw() returns the power domain refcount. What
the callers are really interested in though is the sw state of the
underlying power wells. Due to this we will report incorrectly that a
given power domain is off if its power wells were enabled via another
power domain, for example POWER_DOMAIN_INIT which enables all power
wells.

As a fix return instead the state based on the refcount of all power
wells included in the passed in power domain.

References: https://bugs.freedesktop.org/show_bug.cgi?id=79505
References: https://bugs.freedesktop.org/show_bug.cgi?id=79038
Reported-by: Chris Wilson 
Signed-off-by: Imre Deak 
Reviewed-by: Damien Lespiau 
Signed-off-by: Daniel Vetter 
Acked-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

mmc: rtsx: add R1-no-CRC mmc command type handle

2014-07-09T18:18:28+00:00

commit 5027251eced6e34315a52bd841279df957f627bb upstream.

a27fbf2f067b0cd ("mmc: add ignorance case for CMD13 CRC error") produced
a cmd.flags unhandled in realtek pci host driver.  This will make MMC
card fail to initialize, this patch is used to handle the new cmd.flags
condition and MMC card can be used.

Signed-off-by: Micky Ching 
Signed-off-by: Ulf Hansson 
Signed-off-by: Chris Ball 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: Fix brcmf_chip_ai_coredisable not applying reset bits to BCMA_IOCTL

2014-07-09T18:18:28+00:00

commit ffa216bb5eecfce0f01b0b2a95d5c320dde90005 upstream.

brcmfmac has been broken on my cubietruck with a BCM43362:

brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
        Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d

since commit 53036261033: "brcmfmac: update core reset and disable routines".

The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.

This fixes brcmfmac hanging in firmware loading on my board.

Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede 
Acked-by: Arend van Spriel 
Signed-off-by: John W. Linville 
[arend@broadcom.com: rebase patch on linux-3.14.y branch]
Signed-off-by: Arend van Spriel 
Signed-off-by: Greg Kroah-Hartman

tty: Correct INPCK handling

2014-07-09T18:18:28+00:00

commit 66528f90669691c85c73bea4f0c9f4a5857c4cab upstream.

If INPCK is not set, input parity detection should be disabled. This means
parity errors should not be received from the tty driver, and the data
received should be treated normally.

SUS v3, 11.2.2, General Terminal Interface - Input Modes, states:
  "If INPCK is set, input parity checking shall be enabled. If INPCK is
   not set, input parity checking shall be disabled, allowing output parity
   generation without input parity errors. Note that whether input parity
   checking is enabled or disabled is independent of whether parity detection
   is enabled or disabled (see Control Modes). If parity detection is enabled
   but input parity checking is disabled, the hardware to which the terminal
   is connected shall recognize the parity bit, but the terminal special file
   shall not check whether or not this bit is correctly set."

Ignore parity errors reported by the tty driver when INPCK is not set, and
handle the received data normally.

Fixes: Bugzilla #71681, 'Improvement of n_tty_receive_parity_error from n_tty.c'
Reported-by: Ivan 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

serial: Fix IGNBRK handling

2014-07-09T18:18:28+00:00

commit ef8b9ddcb45fa3b1e11acd72be2398001e807d14 upstream.

If IGNBRK is set without either BRKINT or PARMRK set, some uart
drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the
line discipline, when it should send either nothing or the TTYBREAK flag
set. This happens because the read_status_mask masks out the BI
condition, which uart_insert_char() then interprets as a normal 0x00 byte.

SUS v3 is clear regarding the meaning of IGNBRK; Section 11.2.2, General
Terminal Interface - Input Modes, states:
  "If IGNBRK is set, a break condition detected on input shall be ignored;
   that is, not put on the input queue and therefore not read by any
   process."

Fix read_status_mask to include the BI bit if IGNBRK is set; the
lsr status retains the BI bit if a BREAK is recv'd, which is
subsequently ignored in uart_insert_char() when masked with the
ignore_status_mask.

Affected drivers:
8250 - all
serial_txx9
mfd
amba-pl010
amba-pl011
atmel_serial
bfin_uart
dz
ip22zilog
max310x
mxs-auart
netx-serial
pnx8xxx_uart
pxa
sb1250-duart
sccnxp
serial_ks8695
sirfsoc_uart
st-asc
vr41xx_siu
zs
sunzilog
fsl_lpuart
sunsab
ucc_uart
bcm63xx_uart
sunsu
efm32-uart
pmac_zilog
mpsc
msm_serial
m32r_sio

Unaffected drivers:
omap-serial
rp2
sa1100
imx
icom

Annotated for fixes:
altera_uart
mcf

Drivers without break detection:
21285
xilinx-uartps
altera_jtaguart
apbuart
arc-uart
clps711x
max3100
uartlite
msm_serial_hs
nwpserial
lantiq
vt8500_serial

Unknown:
samsung
mpc52xx_uart
bfin_sport_uart
cpm_uart/core

Fixes: Bugzilla #71651, '8250_core.c incorrectly handles IGNBRK flag'
Reported-by: Ivan 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

clk: qcom: Fix mmcc-8974's PLL configurations

2014-07-09T18:18:28+00:00

commit 437ae6a1b8f2eedebfbf0f6572e19ca5c58a3f71 upstream.

We forgot to add the status bit for the PLLs and we were using
the wrong register and masks for configuration, leading to
unexpected PLL configurations. Fix this.

Fixes: d8b212014e69 (clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC))
Signed-off-by: Stephen Boyd 
Signed-off-by: Mike Turquette 
Signed-off-by: Greg Kroah-Hartman

clk: qcom: Fix clk_rcg2_is_enabled() check

2014-07-09T18:18:28+00:00

commit aa014149ba002155a084ec1e9328e95b70167cbb upstream.

If the bit is set the clock is off so we should be checking for
a clear bit, not a set bit. Invert the logic.

Fixes: bcd61c0f535a (clk: qcom: Add support for root clock generators (RCGs))
Signed-off-by: Stephen Boyd 
Signed-off-by: Mike Turquette 
Signed-off-by: Greg Kroah-Hartman

mlx4_core: Fix incorrect FLAGS1 bitmap test in mlx4_QUERY_FUNC_CAP

2014-07-09T18:18:28+00:00

commit bc82878baa10c2a6a4a6affaf52c152935112142 upstream.

Commit eb17711bc1d6 ("net/mlx4_core: Introduce nic_info new flag in
QUERY_FUNC_CAP") did:

	if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_OFFSET) {

which should be:

	if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_FORCE_VLAN) {

Fix that.

Fixes: eb17711bc1d6 ("net/mlx4_core: Introduce nic_info new flag in QUERY_FUNC_CAP")
Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman