linux-stable.git/drivers, branch v4.7.5

Add braces to avoid "ambiguous ‘else’" compiler warnings

2016-09-24T08:09:41+00:00

commit 194dc870a5890e855ecffb30f3b80ba7c88f96d6 upstream.

Some of our "for_each_xyz()" macro constructs make gcc unhappy about
lack of braces around if-statements inside or outside the loop, because
the loop construct itself has a "if-then-else" statement inside of it.

The resulting warnings look something like this:

  drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’:
  drivers/gpu/drm/i915/i915_debugfs.c:2103:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
     if (ctx != dev_priv->kernel_context)
        ^

even if the code itself is fine.

Since the warning is fairly easy to avoid by adding a braces around the
if-statement near the for_each_xyz() construct, do so, rather than
disabling the otherwise potentially useful warning.

(The if-then-else statements used in the "for_each_xyz()" constructs are
designed to be inherently safe even with no braces, but in this case
it's quite understandable that gcc isn't really able to tell that).

This finally leaves the standard "allmodconfig" build with just a
handful of remaining warnings, so new and valid warnings hopefully will
stand out.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: avoid warning about missing braces

2016-09-24T08:09:41+00:00

commit 2cce76c3fab410520610a7d2f52faebc3cfcf843 upstream.

gcc-6 warns about code in il3945_hw_txq_ctx_free() being
somewhat ambiguous:

drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]

This adds a set of curly braces to avoid the warning.

Signed-off-by: Arnd Bergmann 
Acked-by: Stanislaw Gruszka 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

irqchip/atmel-aic: Fix potential deadlock in ->xlate()

2016-09-24T08:09:38+00:00

commit 5eb0d6eb3fac3daa60d9190eed9fa41cf809c756 upstream.

aic5_irq_domain_xlate() and aic_irq_domain_xlate() take the generic chip
lock without disabling interrupts, which can lead to a deadlock if an
interrupt occurs while the lock is held in one of these functions.

Replace irq_gc_{lock,unlock}() calls by
irq_gc_{lock_irqsave,unlock_irqrestore}() ones to prevent this bug from
happening.

Fixes: b1479ebb7720 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers")
Signed-off-by: Boris Brezillon 
Acked-by: Marc Zyngier 
Cc: Jason Cooper 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Link: http://lkml.kernel.org/r/1473775109-4192-2-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-st: Handle interconnect clock

2016-09-24T08:09:38+00:00

commit 3ae50f4512ce831e8b63eb54ad969417ff30ada7 upstream.

Some ST platforms contain interconnect (ICN) clocks which must be handed
correctly in order to obtain full functionality of a given IP.  In this
case, if the ICN clocks are not handled properly by the ST SDHCI driver
MMC will break and the following output can be observed:

    [   13.916949] mmc0: Timeout waiting for hardware interrupt.
    [   13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
    [   13.928175] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
    [   13.933999] sdhci: Blk size: 0x00007040 | Blk cnt:  0x00000001
    [   13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
    [   13.945650] sdhci: Present:  0x1fff0206 | Host ctl: 0x00000011
    [   13.951475] sdhci: Power:    0x0000000f | Blk gap:  0x00000080
    [   13.957300] sdhci: Wake-up:  0x00000000 | Clock:    0x00003f07
    [   13.963126] sdhci: Timeout:  0x00000004 | Int stat: 0x00000000
    [   13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
    [   13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
    [   13.980602] sdhci: Caps:     0x21ed3281 | Caps_1:   0x00000000
    [   13.986428] sdhci: Cmd:      0x0000063a | Max curr: 0x00000000
    [   13.992252] sdhci: Host ctl2: 0x00000000
    [   13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
    [   14.001990] sdhci: ===========================================
    [   14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.

A decent point was raised about minimising the use of a local variable that
we 'could' do without.  I've chosen consistency over the possibility of
reducing the local variable count by 1.  Thinking that it's more important
for the code to be grouped and authoured in a similar manner/style for
greater maintainability/readability.

Tested-by: Peter Griffin 
Signed-off-by: Lee Jones 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

drm: Only use compat ioctl for addfb2 on X86/IA64

2016-09-24T08:09:37+00:00

commit 47a66e45d7a7613322549c2475ea9d809baaf514 upstream.

Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an
unaligned 64 bit field (modifier). This get packed differently between
32 bit and 64 bit modes on architectures that can handle unaligned 64
bit access (X86 and IA64).  Other architectures pack the structs the
same and don't need the compat wrapper. Use the same condition for
drm_mode_fb_cmd2 as we use for drm_update_draw.

Note that only the modifier will be packed differently between compat
and non-compat versions.

Reviewed-by: Rob Clark 
Signed-off-by: Kristian H. Kristensen 
[seanpaul added not at bottom of commit msg re: modifier]
Signed-off-by: Sean Paul 
Link: http://patchwork.freedesktop.org/patch/msgid/1473801645-116011-1-git-send-email-hoegsberg@chromium.org
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Ignore OpRegion panel type except on select machines

2016-09-24T08:09:37+00:00

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639 upstream.

Turns out
commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
details") has regressed quite a few machines. So it looks like we
can't use the panel type from OpRegion on all systems, and yet we
absolutely must use it on some specific systems.

Despite trying, I was unable to find any automagic way to determine
if the OpRegion panel type is respectable or not. The only glimmer
of hope I had was bit 8 in the SCIC response, but that turned out to
not work either (it was always 0 on both types of systems).

So, to fix the regressions without breaking the machine we know to need
the OpRegion panel type, let's just add a quirk for this. Only specific
machines known to require the OpRegion panel type will therefore use
it. Everyone else will fall bck to the VBT panel type.

The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
subsystem ID on this machine is just a generic 8086:2a42, so of no use.
Instead we'll go with a DMI match.

I suspect we can now also revert
commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
but let's leave that to a separate patch.

v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
    gets populated too late

Cc: Rob Kramer 
Cc: Martin van Es 
Cc: Andrea Arcangeli 
Cc: Dave Airlie 
Cc: Marco Krüger 
Cc: Sean Greenslade 
Cc: Trudy Tective 
Cc: Robin Müller 
Cc: Alexander Kobel 
Cc: Alexey Shumitsky 
Cc: Emil Andersen Lauridsen 
Cc: oceans112@gmail.com
Cc: James Hogan 
Cc: James Bottomley 
References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363
Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details")
Tested-by: Marco Krüger 
Tested-by: Alexey Shumitsky 
Tested-by: Sean Greenslade 
Tested-by: Emil Andersen Lauridsen 
Tested-by: Robin Müller 
Tested-by: oceans112@gmail.com
Tested-by: Rob Kramer 
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com
References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.com
Acked-by: Jani Nikula 
(cherry picked from commit c8ebfad7a063fe665417fa0eeb0da7cfe987d8ed)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm: atmel-hlcdc: Fix vertical scaling

2016-09-24T08:09:37+00:00

commit d31ed3f05763644840c654a384eaefa94c097ba2 upstream.

The code is applying the same scaling for the X and Y components,
thus making the scaling feature only functional when both components
have the same scaling factor.

Do the s/_w/_h/ replacement where appropriate to fix vertical scaling.

Signed-off-by: Jan Leupold 
Fixes: 1a396789f65a2 ("drm: add Atmel HLCDC Display Controller support")
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

efi/libstub: Use efi_exit_boot_services() in FDT

2016-09-24T08:09:37+00:00

commit ed9cc156c42ff0c0bf9b1d09df48a12bf0873473 upstream.

The FDT code directly calls ExitBootServices.  This is inadvisable as the
UEFI spec details a complex set of errors, race conditions, and API
interactions that the caller of ExitBootServices must get correct.  The
FDT code does not handle EFI_INVALID_PARAMETER as required by the spec,
which causes intermittent boot failures on the Qualcomm Technologies
QDF2432.  Call the efi_exit_boot_services() helper intead, which handles
the EFI_INVALID_PARAMETER scenario properly.

Signed-off-by: Jeffrey Hugo 
Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Leif Lindholm 
Cc: Ingo Molnar 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efi/libstub: Introduce ExitBootServices helper

2016-09-24T08:09:37+00:00

commit fc07716ba803483be91bc4b2344f9c84985e6f07 upstream.

The spec allows ExitBootServices to fail with EFI_INVALID_PARAMETER if a
race condition has occurred where the EFI has updated the memory map after
the stub grabbed a reference to the map.  The spec defines a retry
proceedure with specific requirements to handle this scenario.

This scenario was previously observed on x86 - commit d3768d885c6c ("x86,
efi: retry ExitBootServices() on failure") but the current fix is not spec
compliant and the scenario is now observed on the Qualcomm Technologies
QDF2432 via the FDT stub which does not handle the error and thus causes
boot failures.  The user will notice the boot failure as the kernel is not
executed and the system may drop back to a UEFI shell, but will be
unresponsive to input and the system will require a power cycle to recover.

Add a helper to the stub library that correctly adheres to the spec in the
case of EFI_INVALID_PARAMETER from ExitBootServices and can be universally
used across all stub implementations.

Signed-off-by: Jeffrey Hugo 
Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Leif Lindholm 
Cc: Ingo Molnar 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efi/libstub: Allocate headspace in efi_get_memory_map()

2016-09-24T08:09:36+00:00

commit dadb57abc37499f565b23933dbf49b435c3ba8af upstream.

efi_get_memory_map() allocates a buffer to store the memory map that it
retrieves.  This buffer may need to be reused by the client after
ExitBootServices() is called, at which point allocations are not longer
permitted.  To support this usecase, provide the allocated buffer size back
to the client, and allocate some additional headroom to account for any
reasonable growth in the map that is likely to happen between the call to
efi_get_memory_map() and the client reusing the buffer.

Signed-off-by: Jeffrey Hugo 
Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Leif Lindholm 
Cc: Ingo Molnar 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman