Commit graph

548439 commits

Author SHA1 Message Date
Linus Torvalds
83dc311ce0 dmaengine fixes for 4.3-rc4
This contains fixes spread throughout the drivers
    Also fixes one more instance of privatecnt in dmaengine
    bunch of pxa_dma fixes for reuse of descriptor issue, residue and
    no-requestor
    odd fixes in xgene, idma, sun4i and zxdma
    at_xdmac fixes for cleaning descriptor and block addr mode
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJWDsttAAoJEHwUBw8lI4NHBDcP/0NjV4T7KAcx+IYDodDw4fti
 p+UixavHfVUHJ63tG/y9YiJKR7OjqJbuY3T3dgazJN/Xfyi7QKt3IcnXNhpU6Gk0
 VlbvTQtZXzUEa13pLH02QwAMxf8wn+1c5r2jSuCKCwVdjfKujfwmfJC2Yqxk66YQ
 2dFGclMfkQeiKPfo5WZZa95fk9ZhAVzduMdU1mn5Zk1rV2wYGIXm/k6nvY8pUle/
 6PkTjFYCv9fZ5eGP1pwpoJ5GMxXbCQL8Z0/KQGKNEoEjA2+LgsjIxN2nGYXVvMDa
 Z/T8bTfcZdi8kgLmxZSJalWRWQyMmWmp2Sv9tQ5ujnJ/vlnDD1WA0uah+MGIv1sj
 HK5FVRwzIfNtFsSpI6on0ndi2xf5c2tA4ZC8St8jyZyw3DxYNeiGgL6/uIn60saf
 5v5D6R+YQ7uxX3jfWe6vzoZMBNqaKpcLmZmSwiwo6SQgP7umYAQocNmFCWLAkHlN
 UPvgVW2Q4Doqj11GEJ3FO4HXd4Sauo+ARvlYNs0hyeIEwnHJsc0IMYHd4tmnzwt0
 EiM7uDMeJVkQrJxXm3xsv8rqheLXS6rGebu3JLL1riEe9nxC1sGuz08L4+sJFMgn
 agyRGMYnslFaVwWMkgA4rdh0FPJwFRRFjxggtskwhIi9sSRTBF9uKS98JvrU/AeW
 J4C8XmuLMGyATzrBXdUM
 =wcjo
 -----END PGP SIGNATURE-----

Merge tag 'dmaengine-fix-4.3-rc4' of git://git.infradead.org/users/vkoul/slave-dma

Pull dmaengine fixes from Vinod Koul:
 "This contains fixes spread throughout the drivers, and also fixes one
  more instance of privatecnt in dmaengine.

  Driver fixes summary:
   - bunch of pxa_dma fixes for reuse of descriptor issue, residue and
     no-requestor
   - odd fixes in xgene, idma, sun4i and zxdma
   - at_xdmac fixes for cleaning descriptor and block addr mode"

* tag 'dmaengine-fix-4.3-rc4' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine: pxa_dma: fix residue corner case
  dmaengine: pxa_dma: fix the no-requestor case
  dmaengine: zxdma: Fix off-by-one for testing valid pchan request
  dmaengine: at_xdmac: clean used descriptor
  dmaengine: at_xdmac: change block increment addressing mode
  dmaengine: dw: properly read DWC_PARAMS register
  dmaengine: xgene-dma: Fix overwritting DMA tx ring
  dmaengine: fix balance of privatecnt
  dmaengine: sun4i: fix unsafe list iteration
  dmaengine: idma64: improve residue estimation
  dmaengine: xgene-dma: fix handling xgene_dma_get_ring_size result
  dmaengine: pxa_dma: fix initial list move
2015-10-02 14:46:15 -04:00
Linus Torvalds
27728bf04b Merge branch 'for-linus' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
 "Another week, another round of fixes.

  These have been brewing for a bit and in various iterations, but I
  feel pretty comfortable about the quality of them.  They fix real
  issues.  The pull request is mostly blk-mq related, and the only one
  not fixing a real bug, is the tag iterator abstraction from Christoph.
  But it's pretty trivial, and we'll need it for another fix soon.

  Apart from the blk-mq fixes, there's an NVMe affinity fix from Keith,
  and a single fix for xen-blkback from Roger fixing failure to free
  requests on disconnect"

* 'for-linus' of git://git.kernel.dk/linux-block:
  blk-mq: factor out a helper to iterate all tags for a request_queue
  blk-mq: fix racy updates of rq->errors
  blk-mq: fix deadlock when reading cpu_list
  blk-mq: avoid inserting requests before establishing new mapping
  blk-mq: fix q->mq_usage_counter access race
  blk-mq: Fix use after of free q->mq_map
  blk-mq: fix sysfs registration/unregistration race
  blk-mq: avoid setting hctx->tags->cpumask before allocation
  NVMe: Set affinity after allocating request queues
  xen/blkback: free requests on disconnection
2015-10-02 14:40:57 -04:00
Stephen Boyd
9f30a04d76 Merge branch 'for-4.3-rc/ti-clk-fixes' of https://github.com/t-kristo/linux-pm into clk-fixes
Pull fixes from Tero Kristo:

"A few TI clock driver fixes to pull against 4.3-rc"

* 'for-4.3-rc/ti-clk-fixes' of https://github.com/t-kristo/linux-pm: (3 commits)
  clk: ti: dflt: fix enable_reg validity check
  clk: ti: fix dual-registration of uart4_ick
  clk: ti: clk-7xx: Remove hardwired ABE clock configuration
2015-10-02 11:22:23 -07:00
Dmitry Torokhov
62d7846144 Revert "Input: synaptics - fix handling of disabling gesture mode"
This reverts commit e51e38494a: we
actually do want the device to work in extended W mode, as this is the
mode that allows us receiving multiple contact information.

Cc: stable@vger.kernel.org
2015-10-02 10:31:32 -07:00
Matt Bennett
66803dd919 MIPS: Octeon: Fix kernel panic on startup from memory corruption
During development it was found that a number of builds would panic
during the kernel init process, more specifically in 'delayed_fput()'.
The panic showed the kernel trying to access a memory address of
'0xb7fdc00' while traversing the 'delayed_fput_list' structure.
Comparing this memory address to the value of the pointer used on
builds that did not panic confirmed that the pointer on crashing
builds must have been corrupted at some stage earlier in the init
process.

By traversing the list earlier and earlier in the code it was found
that 'plat_mem_setup()' was responsible for corrupting the list.
Specifically the line:

    memory = cvmx_bootmem_phy_alloc(mem_alloc_size,
			__pa_symbol(&__init_end), -1,
			0x100000,
			CVMX_BOOTMEM_FLAG_NO_LOCKING);

Which would eventually call:

    cvmx_bootmem_phy_set_size(new_ent_addr,
		cvmx_bootmem_phy_get_size
		(ent_addr) -
		(desired_min_addr -
			ent_addr));

Where 'new_ent_addr'=0x4800000 (the address of 'delayed_fput_list')
and the second argument (size)=0xb7fdc00 (the address causing the
kernel panic). The job of this part of 'plat_mem_setup()' is to
allocate chunks of memory for the kernel to use. At the start of
each chunk of memory the size of the chunk is written, hence the
value 0xb7fdc00 is written onto memory at 0x4800000, therefore the
kernel panics when it goes back to access 'delayed_fput_list' later
on in the initialisation process.

On builds that were not crashing it was found that the compiler had
placed 'delayed_fput_list' at 0x4800008, meaning it wasn't corrupted
(but something else in memory was overwritten).

As can be seen in the first function call above the code begins to
allocate chunks of memory beginning from the symbol '__init_end'.
The MIPS linker script (vmlinux.lds.S) however defines the .bss
section to begin after '__init_end'. Therefore memory within the
.bss section is allocated to the kernel to use (System.map shows
'delayed_fput_list' and other kernel structures to be in .bss).

To stop the kernel panic (and the .bss section being corrupted)
memory should begin being allocated from the symbol '_end'.

Signed-off-by: Matt Bennett <matt.bennett@alliedtelesis.co.nz>
Acked-by: David Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: aleksey.makarov@auriga.com
Patchwork: https://patchwork.linux-mips.org/patch/11251/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-10-02 19:19:55 +02:00
Paul Burton
085c2f25d3 MIPS: Fix R2300 FP context switch handling
Commit 1a3d59579b ("MIPS: Tidy up FPU context switching") removed FP
context saving from the asm-written resume function in favour of reusing
existing code to perform the same task. However it only removed the FP
context saving code from the r4k_switch.S implementation of resume.
Remove it from the r2300_switch.S implementation too in order to prevent
attempting to save the FP context twice, which would likely lead to an
exception from the second save because the FPU had already been disabled
by the first save.

This patch has only been build tested, using rbtx49xx_defconfig.

Fixes: 1a3d59579b ("MIPS: Tidy up FPU context switching")
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: linux-kernel@vger.kernel.org
Cc: Manuel Lauss <manuel.lauss@gmail.com>
Patchwork: https://patchwork.linux-mips.org/patch/11167/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-10-02 19:16:46 +02:00
Paul Burton
0fa24340f7 MIPS: Fix octeon FP context switch handling
Commit 1a3d59579b ("MIPS: Tidy up FPU context switching") removed FP
context saving from the asm-written resume function in favour of reusing
existing code to perform the same task. However it only removed the FP
context saving code from the r4k_switch.S implementation of resume.
Octeon uses its own implementation in octeon_switch.S, so remove FP
context saving there too in order to prevent attempting to save context
twice. That formerly led to an exception from the second save as follows
because the FPU had already been disabled by the first save:

    do_cpu invoked from kernel context![#1]:
    CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.3.0-rc2-dirty #2
    task: 800000041f84a008 ti: 800000041f864000 task.ti: 800000041f864000
    $ 0   : 0000000000000000 0000000010008ce1 0000000000100000 ffffffffbfffffff
    $ 4   : 800000041f84a008 800000041f84ac08 800000041f84c000 0000000000000004
    $ 8   : 0000000000000001 0000000000000000 0000000000000000 0000000000000001
    $12   : 0000000010008ce3 0000000000119c60 0000000000000036 800000041f864000
    $16   : 800000041f84ac08 800000000792ce80 800000041f84a008 ffffffff81758b00
    $20   : 0000000000000000 ffffffff8175ae50 0000000000000000 ffffffff8176c740
    $24   : 0000000000000006 ffffffff81170300
    $28   : 800000041f864000 800000041f867d90 0000000000000000 ffffffff815f3fa0
    Hi    : 0000000000fa8257
    Lo    : ffffffffe15cfc00
    epc   : ffffffff8112821c resume+0x9c/0x200
    ra    : ffffffff815f3fa0 __schedule+0x3f0/0x7d8
    Status: 10008ce2        KX SX UX KERNEL EXL
    Cause : 1080002c (ExcCode 0b)
    PrId  : 000d0601 (Cavium Octeon+)
    Modules linked in:
    Process kthreadd (pid: 2, threadinfo=800000041f864000, task=800000041f84a008, tls=0000000000000000)
    Stack : ffffffff81604218 ffffffff815f7e08 800000041f84a008 ffffffff811681b0
              800000041f84a008 ffffffff817e9878 0000000000000000 ffffffff81770000
              ffffffff81768340 ffffffff81161398 0000000000000001 0000000000000000
              0000000000000000 ffffffff815f4424 0000000000000000 ffffffff81161d68
              ffffffff81161be8 0000000000000000 0000000000000000 0000000000000000
              0000000000000000 0000000000000000 0000000000000000 ffffffff8111e16c
              0000000000000000 0000000000000000 0000000000000000 0000000000000000
              0000000000000000 0000000000000000 0000000000000000 0000000000000000
              0000000000000000 0000000000000000 0000000000000000 0000000000000000
              0000000000000000 0000000000000000 0000000000000000 0000000000000000
              ...
    Call Trace:
    [<ffffffff8112821c>] resume+0x9c/0x200
    [<ffffffff815f3fa0>] __schedule+0x3f0/0x7d8
    [<ffffffff815f4424>] schedule+0x34/0x98
    [<ffffffff81161d68>] kthreadd+0x180/0x198
    [<ffffffff8111e16c>] ret_from_kernel_thread+0x14/0x1c

Tested using cavium_octeon_defconfig on an EdgeRouter Lite.

Fixes: 1a3d59579b ("MIPS: Tidy up FPU context switching")
Reported-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Aleksey Makarov <aleksey.makarov@auriga.com>
Cc: linux-kernel@vger.kernel.org
Cc: Chandrakala Chavva <cchavva@caviumnetworks.com>
Cc: David Daney <david.daney@cavium.com>
Cc: Leonid Rosenboim <lrosenboim@caviumnetworks.com>
Patchwork: https://patchwork.linux-mips.org/patch/11166/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-10-02 19:16:06 +02:00
yitian
924eb47512 ASoC: dwc: fix dma stop transferring issue
Designware I2S uses tx empty and rx available signals as the DMA
handshaking signals. during music playing, if XRUN occurs,
i2s_stop() function will be executed and both tx and rx irq are
masked, when music continues to be played, i2s_start() is executed
but both tx and rx irq are not unmasked which cause I2S stop
sending DMA handshaking signal to DMA controller, and it finally
causes music playing will be stopped once XRUN occurs for the first
time.

[On list discussion suggests this may be partly a race condition on slow
systems -- broonie]

Signed-off-by: Yitian Bu <yitian.bu@tangramtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-02 18:05:51 +01:00
Mikulas Patocka
042745ee53 dm raid: fix round up of default region size
Commit 3a0f9aaee0 ("dm raid: round region_size to power of two")
intended to make sure that the default region size is a power of two.
However, the logic in that commit is incorrect and sets the variable
region_size to 0 or 1, depending on whether min_region_size is a power
of two.

Fix this logic, using roundup_pow_of_two(), so that region_size is
properly rounded up to the next power of two.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Fixes: 3a0f9aaee0 ("dm raid: round region_size to power of two")
Cc: stable@vger.kernel.org # v3.8+
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2015-10-02 12:02:31 -04:00
Rafael J. Wysocki
d61e87ac53 Pull request for Rafael from devfreq targetting next RC (4.3-rcX)
There are two bugfixes included.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJWDebUAAoJEBOhurvWBoCKHmQQAIt/YVivAdp7NiAfNjPsJhVl
 YegzRA2JmG2XAqJa1nEltMzawMKHfyinV3mwrbDA3Uk1SDh5L483ucPKSROysdTz
 /8dWIWPPgO+Y0kt7HBAoj+Q/+pOcrNoBeb1+muYCxFOse43O4RXKqdZb7BlEPiKf
 eDIrsq7HtAIA6FFlcVD4HyMSS3WkxBWpZMIu/DcKsLPc1cZrhvNYDd4rXWLSEDF7
 u74ztOlDNz0n9nwM1tP/M8cG08jlXAyjlz6zfGP+j8AzjRd6HUJAAgiF4eg63CfH
 JF3r1DQCGTjmcmk0qiT8WGl1BpxM8ez8D7qgMPIV6jkHgk4KBPsg1w/0btJhUGIW
 i4SIMbrXJAkq0USLiw6rQUAsKCpiYT5ZMxamQ5UUDYegcRF678xb0tkwQMFbPxVi
 StoyAeC7m+H9WEnZoANZtzXKWURtHa9tiFUuJVr5/V8FDFrQWfwVKs9lzUihiEyz
 6P+IDeBRCv59qzjK0gMqIOq5PwllS2Mwhb+cyw7b13NN6esq3bnx+BNkIgTcbH4J
 Gj60Jr3KCx4ttSa8i7UWeHOxhAy/btjlLjUYo4uR0I9ylYxGPzFkyCTgmXUOr8E8
 LM3RIs9bPTkcknEyuBEmgpe7oAvkKKWilS1GlWjbTb+KHxmaqQD2KCbFwXqm/Pmj
 EDyzaIK6cMPhM6SRD8Jp
 =tYMc
 -----END PGP SIGNATURE-----

Merge tag 'pull_req_4.3_rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq into pm-devfreq

Pull devfreq fixes for v4.3-rc5 from MyungJoo Ham.

* tag 'pull_req_4.3_rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq:
  PM / devfreq: fix double kfree
  PM / devfreq: Fix governor_store()
2015-10-02 15:23:42 +02:00
Sunil Kamath
022e4e52a7 drm/i915/bxt: Modify BXT BLC according to VBT changes
Latest VBT mentions which set of registers will be used for BLC,
as controller number field. Making use of this field in BXT
BLC implementation. Also, the registers are used in case control
pin indicates display DDI. Adding a check for this.
According to Bspec, BLC_PWM_*_2 uses the display utility pin for output.
To use backlight 2, enable the utility pin with mode = PWM
   v2: Jani's review comments
   addressed
       - Add a prefix _ to BXT BLC registers definitions.
       - Add "bxt only" comment for u8 controller
       - Remove control_pin check for DDI controller
       - Check for valid controller values
       - Set pipe bits in UTIL_PIN_CTL
       - Enable/Disable UTIL_PIN_CTL in enable/disable_backlight()
       - If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity
   Satheesh's review comment addressed
       - If UTIL PIN is already enabled, BIOS would have programmed it. No
       need to disable and enable again.
   v3: Jani's review comments
       - add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK
       - Disable UTIL_PIN if controller 1 is used
       - Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before enabling
       UTIL_PIN
       - check valid controller value in intel_bios.c
       - add backlight.util_pin_active_low
       - disable util pin before enabling
   v4: Change for BXT-PO branch:
   Stubbed unwanted definition which was existing before
   because of DC6 patch.
   UTIL_PIN_MODE_PWM     (0x1b << 24)

v2: Fixed Jani's review comment.

v3: Split the backight PWM frequency programming into separate patch,
    in cases BIOS doesn't initializes it.

v4: Starting afresh and not modifying existing state for backlight, as
    per Jani's recommendation.

v5: Fixed Jani's review comment wrt util pin enable

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:59:25 +02:00
Shashank Sharma
ce0c982152 drm/i915/bxt: get DSI pixelclock
BXT's DSI PLL is different from that of VLV. So this patch
adds a new function to get the current DSI pixel clock based
on the PLL divider ratio and lane count.

This function is required for intel_dsi_get_config() function.

v2: Fixed Jani's review comments.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:45:51 +02:00
Shashank Sharma
baeac68a82 drm/i915/bxt: get_hw_state for BXT
Pick appropriate port control register (BXT or VLV), based on device.
Get the current hw state wrt Mipi port.

v2: Rebased on latest drm nightly branch.

v3: Removed the GET_DSI_PORT_CTRL Macro for consistency with earlier
    implementations as per Jani's suggestion.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:45:25 +02:00
Shashank Sharma
b389a45c6b drm/i915/bxt: DSI disable and post-disable
This patch contains changes to support DSI disble sequence in BXT.
The changes are:
1. BXT specific changes in clear_device_ready function.
2. BXT specific changes in DSI disable and post-disable functions.
3. Add a new function to reset BXT Dphy clock and dividers
   (bxt_dsi_reset_clocks).
4. Moved some part of the vlv clock reset code, in a new function
   (vlv_dsi_reset_clocks) maintaining the exact same sequence.
5. Wrapper function to call corresponding reset clock function.

v2: Fixed Jani's review comments.

v3: Removed the GET_DSI_PORT_CTRL Macro for consistency with earlier
    implementations as per Jani's suggestion.

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:44:59 +02:00
Shashank Sharma
11b8e4f58e drm/i915/bxt: Program Tx Rx and Dphy clocks
BXT DSI clocks are different than previous platforms. So adding a
new function to program following clocks and dividers:
1. Program variable divider to generate input to Tx clock divider
   (Output value must be < 39.5Mhz)
2. Select divide by 2 option to get < 20Mhz for Tx clock
3. Program 8by3 divider to generate Rx clock

v2: Fixed Jani's review comments. Adjusted the Macro definition as
    per convention. Simplified the logic for bit definitions for
    MIPI PORT A and PORT C in same registers.

v3: Refactored the macros for TX, RX Escape and DPHY clocks as per
    Jani's suggestion.

v4: Addressed Jani's review comments.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:44:41 +02:00
Shashank Sharma
37ab0810c9 drm/i915/bxt: DSI enable for BXT
This patch contains following changes:
1. MIPI device ready changes to support dsi_pre_enable. Changes
   are specific to BXT device ready sequence. Added check for
   ULPS mode(No effects on VLV).
2. Changes in dsi_enable to pick BXT port control register.
3. Changes in dsi_pre_enable to restrict DPIO programming for VLV

v2: Fixed Jani's review comments. Removed the changes in VLV/CHV
    code. Fixed the macros to get proper port offsets.

v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:38:52 +02:00
Shashank Sharma
7d4aefd0a9 drm/i915/bxt: DSI encoder support in CRTC modeset
SKL and BXT qualifies the HAS_DDI() check, and hence haswell
modeset functions are re-used for modeset sequence. But DDI
interface doesn't include support for DSI.
This patch adds:
1. cases for DSI encoder, in those modeset functions and allows
   a CRTC modeset
2. Adds call to pre_pll enabled from CRTC modeset function. Nothing
   needs to be done as such in CRTC for DSI encoder, as PLL, clock
   and and transcoder programming will be taken care in encoder's
   pre_enable and pre_pll_enable function.

v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI
    encoder like DSI for platforms having HAS_DDI as true.

v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid
    encoder.

v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion.
    Fixed the sequence for pre_pll_enable.

v5: Protected DDI code paths in case of DSI encoder calls.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:27:55 +02:00
Imre Deak
13d70b8135 drm/i915: rename INSTDONE1 to GEN4_INSTDONE1
This register was added on GEN4, by the name INSTDONE_1 whereas the GEN6
specification calls it INSTDONE_2. Keep the original name with a
platform prefix to make it clearer which INSTDONE register instance this
is. Also add a comment about the SNB alternative name.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 14:25:19 +02:00
Linus Torvalds
36f8dafe52 MMC core:
- Allow users of mmc_of_parse() to succeed when CONFIG_GPIOLIB is unset
  - Prevent infinite loop of re-tuning for CRC-errors for CMD19 and CMD21
 
 MMC host:
  - pxamci: Fix issues with card detect
  - sunxi: Fix clk-delay settings
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJWDkvnAAoJEP4mhCVzWIwpfg4P/A2KXUrFNw4e0FbFGY49pgvs
 aqIYWy0g9DFWnki/yl1R/W9NmrpXeRFKRoilC1BGUGqWvWnjBRNObl66ZQ2gWOkb
 Xg7lZvhINs1ovqOAm6mCp8xr1sSShucoQ4TjKF2nV99BmuV0r5iHtCPFkpU7gAx7
 9J+07Ksss/FoBiM6g+2ImVUKCp0HBe13lnXIL9GFv3QVXFNDzVyEoSqaP0GorjCj
 CD53BlNd8dE7IVme02q/xPuXJ7VuRrp8+tCORForfxvvLc2cy4eoIT43efQp10Fd
 FPnkWkDg+kmZaGg2clkN9igJja7WZzgMS1r7bZpgx9xc37BXfyv/D3zdWawM/zqJ
 FhKFGSreAY9mGQNR0kdHNfq4Gk4UV0c2T5BUYgk+OR6bqpXWitRkGYddLmk6q2mD
 YnNJ6qV9U9y1PlMajrkHNfkYRFitFQYmQfKY/VxqJrVZYSS4jt4k6BBEcfS0YQpu
 aRRLnx+G4uqYri1l7DyVfaq9GtO5EWyllgy1m8QNgrFJeV09oQXBcWQxjP3HQxqh
 NIVXVuSNG/5Imj1HX40i1Pa/NRvgd4HRE/QviM3Ukby9Nr2atXFdYWjn5jtMyqk9
 KFwI6+dqSKKaxzVB30Mb3booEy6IdueWNc2Sg2pFj1Q5U3O2AofZwjoOHozvDoY1
 lf+NQifwnJFloCCXMXLY
 =bo65
 -----END PGP SIGNATURE-----

Merge tag 'mmc-v4.3-rc3' of git://git.linaro.org/people/ulf.hansson/mmc

Pull MMC fixes from Ulf Hansson:
 "Here are some mmc fixes intended for v4.3 rc4:

  MMC core:
   - Allow users of mmc_of_parse() to succeed when CONFIG_GPIOLIB is
     unset
   - Prevent infinite loop of re-tuning for CRC-errors for CMD19 and
     CMD21

   MMC host:
   - pxamci: Fix issues with card detect
   - sunxi: Fix clk-delay settings"

* tag 'mmc-v4.3-rc3' of git://git.linaro.org/people/ulf.hansson/mmc:
  mmc: core: fix dead loop of mmc_retune
  mmc: pxamci: fix card detect with slot-gpio API
  mmc: sunxi: Fix clk-delay settings
  mmc: core: Don't return an error for CD/WP GPIOs when GPIOLIB is unset
2015-10-02 08:03:04 -04:00
Linus Torvalds
8c25ab8b5a Merge git://git.infradead.org/intel-iommu
Pull IOVA fixes from David Woodhouse:
 "The main fix here is the first one, fixing the over-allocation of
   size-aligned requests.  The other patches simply make the existing
  IOVA code available to users other than the Intel VT-d driver, with no
  functional change.

  I concede the latter really *should* have been submitted during the
  merge window, but since it's basically risk-free and people are
  waiting to build on top of it and it's my fault I didn't get it in, I
  (and they) would be grateful if you'd take it"

* git://git.infradead.org/intel-iommu:
  iommu: Make the iova library a module
  iommu: iova: Export symbols
  iommu: iova: Move iova cache management to the iova library
  iommu/iova: Avoid over-allocating when size-aligned
2015-10-02 07:59:29 -04:00
Yitian Bu
4873867e5f ASoC: dwc: correct irq clear method
from Designware I2S datasheet, tx/rx XRUN irq is cleared by
reading register TOR/ROR, rather than by writing into them.

Signed-off-by: Yitian Bu <yitian.bu@tangramtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2015-10-02 11:44:04 +01:00
Li Bin
ee556d00cf arm64: ftrace: fix function_graph tracer panic
When function graph tracer is enabled, the following operation
will trigger panic:

mount -t debugfs nodev /sys/kernel
echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
echo function_graph > /sys/kernel/tracing/current_tracer
ls /proc/

------------[ cut here ]------------
[  198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316
[  198.506126] pgd = ffffffc008f79000
[  198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000
[  198.517726] Internal error: Oops: 94000005 [#1] SMP
[  198.518798] Modules linked in:
[  198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G
[  198.521800] Hardware name: linux,dummy-virt (DT)
[  198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000
[  198.524306] PC is at next_tgid+0x30/0x100
[  198.525205] LR is at return_to_handler+0x0/0x20
[  198.526090] pc : [<ffffffc0002a1070>] lr : [<ffffffc0000907c0>] pstate: 60000145
[  198.527392] sp : ffffffc0f9ab3d40
[  198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000
[  198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8
[  198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00
[  198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002
[  198.533202] x21: ffffffc000d85050 x20: 0000000000000002
[  198.534446] x19: 0000000000000002 x18: 0000000000000000
[  198.535719] x17: 000000000049fa08 x16: ffffffc000242efc
[  198.537030] x15: 0000007fa472b54c x14: ffffffffff000000
[  198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001
[  198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70
[  198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40
[  198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015
[  198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0
[  198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306
[  198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050
[  198.547432]
[  198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020)
[  198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000)
[  198.582568] Call trace:
[  198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100
[  198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[  198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[  198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[  198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[  198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
[  198.591092] ---[ end trace 6a346f8f20949ac8 ]---

This is because when using function graph tracer, if the traced
function return value is in multi regs ([x0-x7]), return_to_handler
may corrupt them. So in return_to_handler, the parameter regs should
be protected properly.

Cc: <stable@vger.kernel.org> # 3.18+
Signed-off-by: Li Bin <huawei.libin@huawei.com>
Acked-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2015-10-02 11:12:56 +01:00
Lukas Wunner
8f12a3118f vga_switcheroo: Add missing locking
The following functions iterate over the client list, invoke client
callbacks or invoke handler callbacks without locking anything at all:

- Introduced by c8e9cf7bb2 ("vga_switcheroo: Add a helper function to
  get the client state"):
  vga_switcheroo_get_client_state()

- Introduced by 0d69704ae3 ("gpu/vga_switcheroo: add driver control
  power feature. (v3)"):
  vga_switcheroo_set_dynamic_switch()
  vga_switcheroo_runtime_suspend()
  vga_switcheroo_runtime_resume()
  vga_switcheroo_runtime_resume_hdmi_audio()

Refactor vga_switcheroo_runtime_resume_hdmi_audio() a bit to be able to
release vgasr_mutex immediately after iterating over the client list.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 10:21:13 +02:00
Ralf Baechle
0c5d187828 MIPS: BPF: Fix load delay slots.
The entire bpf_jit_asm.S is written in noreorder mode because "we know
better" according to a comment.  This also prevented the assembler from
throwing in the required NOPs for MIPS I processors which have no
load-use interlock, thus the load's consumer might end up using the
old value of the register from prior to the load.

Fixed by putting the assembler in reorder mode for just the affected
load instructions.  This is not enough for gas to actually try to be
clever by looking at the next instruction and inserting a nop only
when needed but as the comment said "we know better", so getting gas
to unconditionally emit a NOP is just right in this case and prevents
adding further ifdefery.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-10-02 09:48:57 +02:00
Ben Hutchings
f4b4aae182 x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds
On x32, gcc predefines __x86_64__ but long is only 32-bit.  Use
__ILP32__ to distinguish x32.

Fixes this compiler error in perf:

	tools/include/asm-generic/bitops/__ffs.h: In function '__ffs':
	tools/include/asm-generic/bitops/__ffs.h:19:8: error: right shift count >= width of type [-Werror=shift-count-overflow]
	  word >>= 32;
	       ^

This isn't sufficient to build perf for x32, though.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443660043.2730.15.camel@decadent.org.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-02 09:43:21 +02:00
Imre Deak
bd93a50e4d drm/i915: rename INSTDONE to GEN2_INSTDONE
We have a bunch of INSTDONE registers for different platforms and
purposes and it's not immediately clear which instance they are just by
looking at the register name. This one was added on GEN2, where it was
the only INSTDONE register, so mark it as such.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 09:41:09 +02:00
Imre Deak
f1d5434853 drm/i915: remove duplicate names for the render ring INSTDONE register
We use 3 different names to refer to the same render ring INSTDONE
register. This can be confusing when comparing two parts of the code
accessing the register via different names. Although the GEN4 version's
layout is different, we treat it the same way as the GEN7+ version, in
that we simply read it out during error capture. So remove the
duplicates and leave a comment about the GEN4 difference.

Note that there is also a GEN2 version of this register, but that's on a
different address so not handled in this patch.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02 09:41:02 +02:00
NeilBrown
da6fb7a9e5 md/bitmap: don't pass -1 to bitmap_storage_alloc.
Passing -1 to bitmap_storage_alloc() causes page->index to be set to
-1, which is quite problematic.

So only pass ->cluster_slot if mddev_is_clustered().

Fixes: b97e92574c ("Use separate bitmaps for each nodes in the cluster")
Cc: stable@vger.kernel.org (v4.1+)
Signed-off-by: NeilBrown <neilb@suse.com>
2015-10-02 17:24:13 +10:00
Jes Sorensen
e8ff8bf09f md/raid1: Avoid raid1 resync getting stuck
close_sync() needs to set conf->next_resync to a large, but safe value
below MaxSector and use it to determine whether or not to set
start_next_window in wait_barrier()

Solution suggested by Neil Brown.

Reported-by: Nate Dailey <nate.dailey@stratus.com>
Tested-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.com>
2015-10-02 17:23:44 +10:00
Julia Lawall
644df1a85f md: drop null test before destroy functions
Remove unneeded NULL test.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@ expression x; @@
-if (x != NULL)
  \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NeilBrown <neilb@suse.com>
2015-10-02 17:23:44 +10:00
Shaohua Li
d4929add83 md: clear CHANGE_PENDING in readonly array
If faulty disks of an array are more than allowed degraded number, the
array enters error handling. It will be marked as read-only with
MD_CHANGE_PENDING/RECOVERY_NEEDED set. But currently recovery doesn't
clear CHANGE_PENDING bit for read-only array.  If MD_CHANGE_PENDING is
set for a raid5 array, all returned IO will be hold on a list till the
bit is clear. But recovery nevery clears this bit, the IO is always in
pending state and nevery finish. This has bad effects like upper layer
can't get an IO error and the array can't be stopped.

Fixes: c3cce6cda1 ("md/raid5: ensure device failure recorded before write request returns.")
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.com>
2015-10-02 17:23:44 +10:00
NeilBrown
66eefe5de1 md/raid0: apply base queue limits *before* disk_stack_limits
Calling e.g. blk_queue_max_hw_sectors() after calls to
disk_stack_limits() discards the settings determined by
disk_stack_limits().
So we need to make those calls first.

Fixes: 199dc6ed51 ("md/raid0: update queue parameter in a safer location.")
Cc: stable@vger.kernel.org (v2.6.35+ - please apply with 199dc6ed51).
Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.com>
2015-10-02 17:23:44 +10:00
NeilBrown
36707bb2e7 md/raid5: don't index beyond end of array in need_this_block().
When need_this_block probably shouldn't be called when there
are more than 2 failed devices, we really don't want it to try
indexing beyond the end of the failed_num[] of fdev[] arrays.

So limit the loops to at most 2 iterations.

Reported-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2015-10-02 17:23:43 +10:00
Shaohua Li
ebda780bce raid5: update analysis state for failed stripe
handle_failed_stripe() makes the stripe fail, eg, all IO will return
with a failure, but it doesn't update stripe_head_state. Later
handle_stripe() has special handling for raid6 for handle_stripe_fill().
That check before handle_stripe_fill() doesn't skip the failed stripe
and we get a kernel crash in need_this_block.  This patch clear the
analysis state to make sure no functions wrongly called after
handle_failed_stripe()

Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.com>
2015-10-02 17:23:43 +10:00
NeilBrown
88724bfa68 md: wait for pending superblock updates before switching to read-only
If a superblock update is pending, wait for it to complete before
letting md_set_readonly() switch to readonly.
Otherwise we might lose important information about a device having
failed.

For external arrays, waiting for superblock updates can wait on
user-space, so in that case, just return an error.

Reported-and-tested-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.com>
2015-10-02 17:23:43 +10:00
Stephen Smalley
ab76f7b4ab x86/mm: Set NX on gap between __ex_table and rodata
Unused space between the end of __ex_table and the start of
rodata can be left W+x in the kernel page tables.  Extend the
setting of the NX bit to cover this gap by starting from
text_end rather than rodata_start.

  Before:
  ---[ High Kernel Mapping ]---
  0xffffffff80000000-0xffffffff81000000          16M                               pmd
  0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
  0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
  0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB x  pte
  0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
  0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
  0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
  0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
  0xffffffff82200000-0xffffffffa0000000         478M                               pmd

  After:
  ---[ High Kernel Mapping ]---
  0xffffffff80000000-0xffffffff81000000          16M                               pmd
  0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
  0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
  0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB NX pte
  0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
  0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
  0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
  0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
  0xffffffff82200000-0xffffffffa0000000         478M                               pmd

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443704662-3138-1-git-send-email-sds@tycho.nsa.gov
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-02 09:21:06 +02:00
Lee, Chun-Yi
e3c41e37b0 x86/kexec: Fix kexec crash in syscall kexec_file_load()
The original bug is a page fault crash that sometimes happens
on big machines when preparing ELF headers:

    BUG: unable to handle kernel paging request at ffffc90613fc9000
    IP: [<ffffffff8103d645>] prepare_elf64_ram_headers_callback+0x165/0x260

The bug is caused by us under-counting the number of memory ranges
and subsequently not allocating enough ELF header space for them.
The bug is typically masked on smaller systems, because the ELF header
allocation is rounded up to the next page.

This patch modifies the code in fill_up_crash_elf_data() by using
walk_system_ram_res() instead of walk_system_ram_range() to correctly
count the max number of crash memory ranges. That's because the
walk_system_ram_range() filters out small memory regions that
reside in the same page, but walk_system_ram_res() does not.

Here's how I found the bug:

After tracing prepare_elf64_headers() and prepare_elf64_ram_headers_callback(),
the code uses walk_system_ram_res() to fill-in crash memory regions information
to the program header, so it counts those small memory regions that
reside in a page area.

But, when the kernel was using walk_system_ram_range() in
fill_up_crash_elf_data() to count the number of crash memory regions,
it filters out small regions.

I printed those small memory regions, for example:

  kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0

Based on the code in walk_system_ram_range(), this memory region
will be filtered out:

  pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
  end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
  end_pfn - pfn = 0x77593 - 0x77593 = 0  <=== if (end_pfn > pfn) is FALSE

So, the max_nr_ranges that's counted by the kernel doesn't include
small memory regions - causing us to under-allocate the required space.
That causes the page fault crash that happens in a later code path
when preparing ELF headers.

This bug is not easy to reproduce on small machines that have few
CPUs, because the allocated page aligned ELF buffer has more free
space to cover those small memory regions' PT_LOAD headers.

Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: kexec@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-jlee@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-02 09:13:06 +02:00
Suman Anna
7aba4f5201 clk: ti: dflt: fix enable_reg validity check
The default clock enabling functions for TI clocks -
omap2_dflt_clk_enable() and omap2_dflt_clk_disable() perform a
NULL check for the enable_reg field of the clk_hw_omap structure.
This enable_reg field however is merely a combination of the index
of the master IP module, and the offset from the master IP module's
base address. A value of 0 is perfectly valid, and the current error
checking will fail in these cases. The issue was found when trying
to enable the iva2_ck clock on OMAP3 platforms.

So, switch the check to use IS_ERR. This correction is similar to the
logic used in commit c807dbedb5 ("clk: ti: fix ti_clk_get_reg_addr
error handling").

Fixes: 9f37e90efa ("clk: ti: dflt: move support for default gate clock..")
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
2015-10-02 09:24:28 +03:00
Ben Dooks
19e79687de clk: ti: fix dual-registration of uart4_ick
On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power management to /dev/ttyO3 to fail
when trying to wake the device up.

This solves the following oops:

[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c

Fixes: aafd900cab ("CLK: TI: add omap3 clock init file")
Cc: stable@vger.kernel.org
Cc: mturquette@baylibre.com
Cc: sboyd@codeaurora.org
Cc: linux-clk@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-kernel@lists.codethink.co.uk
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
2015-10-02 09:24:28 +03:00
Peter Ujfalusi
4b3061b391 clk: ti: clk-7xx: Remove hardwired ABE clock configuration
The ABE related clocks should be configured via DT and not have it wired
inside of the kernel.

Fixes: a74c52def9 ("clk: ti: clk-7xx: Correct ABE DPLL configuration")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
2015-10-02 09:24:28 +03:00
Dave Airlie
d4070ff713 Merge tag 'drm-intel-next-2015-09-11' of git://anongit.freedesktop.org/drm-intel into drm-next
- initialize backlight from VBT as fallback (Jani)
- hpd A support from Ville
- various atomic polish all over (mostly from Maarten)
- first parts of virtualize gpu guest support on bdw from
  Zhiyuan Lv
- GuC fixes from Alex
- polish for the chv clocks code (Ville)
- various things all over, as usual

* tag 'drm-intel-next-2015-09-11' of git://anongit.freedesktop.org/drm-intel: (145 commits)
  drm/i915: Update DRIVER_DATE to 20150911
  drm/i915: Remove one very outdated comment
  drm/i915: Use crtc->state for duplication.
  drm/i915: Do not handle a null plane state.
  drm/i915: Remove legacy plane updates for cursor and sprite planes.
  drm/i915: Use atomic state when changing cursor visibility.
  drm/i915: Use the atomic state in intel_update_primary_planes.
  drm/i915: Use the plane state in intel_crtc_info.
  drm/i915: Use atomic plane state in the primary plane update.
  drm/i915: add attached connector to hdmi container
  drm/i915: don't hard code vlv backlight frequency if unset
  drm/i915: initialize backlight max from VBT
  drm/i915: use pch backlight override on hsw too
  drm/i915/bxt: Clean up bxt_init_clock_gating
  drm/i915: Fix cmdparser STORE/LOAD command descriptors
  drm/i915: Dump pfit state as hex
  drm/i915: access the PP_ON_DELAYS/PP_OFF_DELAYS regs only pre GEN5
  drm/i915: access the PP_CONTROL reg only pre GEN5
  drm/i915: Refactor common ringbuffer allocation code
  drm/i915: use the yesno helper for logging
  ...
2015-10-02 15:41:17 +10:00
Dave Airlie
ccf03d6995 drm/dp/mst: add some defines for logical/physical ports
This just removes the magic number.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:34:42 +10:00
Dave Airlie
274d835248 drm/dp/mst: drop cancel work sync in the mstb destroy path (v2)
Since 9eb1e57f56
drm/dp/mst: make sure mst_primary mstb is valid in work function

we validate the mstb structs in the work function, and doing
that takes a reference. So we should never get here with the
work function running using the mstb device, only if the work
function hasn't run yet or is running for another mstb.

So we don't need to sync the work here, this was causing
lockdep spew as below.

[  +0.000160] =============================================
[  +0.000001] [ INFO: possible recursive locking detected ]
[  +0.000002] 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 Tainted: G        W      ------------
[  +0.000001] ---------------------------------------------
[  +0.000001] kworker/4:2/1262 is trying to acquire lock:
[  +0.000001]  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b29a5>] flush_work+0x5/0x2e0
[  +0.000007]
but task is already holding lock:
[  +0.000001]  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[  +0.000004]
other info that might help us debug this:
[  +0.000001]  Possible unsafe locking scenario:

[  +0.000002]        CPU0
[  +0.000000]        ----
[  +0.000001]   lock((&mgr->work));
[  +0.000002]   lock((&mgr->work));
[  +0.000001]
 *** DEADLOCK ***

[  +0.000001]  May be due to missing lock nesting notation

[  +0.000002] 2 locks held by kworker/4:2/1262:
[  +0.000001]  #0:  (events_long){.+.+.+}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[  +0.000004]  #1:  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[  +0.000003]
stack backtrace:
[  +0.000003] CPU: 4 PID: 1262 Comm: kworker/4:2 Tainted: G        W      ------------   3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1
[  +0.000001] Hardware name: LENOVO 20EGS0R600/20EGS0R600, BIOS GNET71WW (2.19 ) 02/05/2015
[  +0.000008] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
[  +0.000001]  ffffffff82c26c90 00000000a527b914 ffff88046399bae8 ffffffff816fe04d
[  +0.000004]  ffff88046399bb58 ffffffff8110f47f ffff880461438000 0001009b840fc003
[  +0.000002]  ffff880461438a98 0000000000000000 0000000804dc26e1 ffffffff824a2c00
[  +0.000003] Call Trace:
[  +0.000004]  [<ffffffff816fe04d>] dump_stack+0x19/0x1b
[  +0.000004]  [<ffffffff8110f47f>] __lock_acquire+0x115f/0x1250
[  +0.000002]  [<ffffffff8110fd49>] lock_acquire+0x99/0x1e0
[  +0.000002]  [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
[  +0.000002]  [<ffffffff810b29ee>] flush_work+0x4e/0x2e0
[  +0.000002]  [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
[  +0.000004]  [<ffffffff81025905>] ? native_sched_clock+0x35/0x80
[  +0.000002]  [<ffffffff81025959>] ? sched_clock+0x9/0x10
[  +0.000002]  [<ffffffff810da1f5>] ? local_clock+0x25/0x30
[  +0.000002]  [<ffffffff8110dca9>] ? mark_held_locks+0xb9/0x140
[  +0.000003]  [<ffffffff810b4ed5>] ? __cancel_work_timer+0x95/0x160
[  +0.000002]  [<ffffffff810b4ee8>] __cancel_work_timer+0xa8/0x160
[  +0.000002]  [<ffffffff810b4fb0>] cancel_work_sync+0x10/0x20
[  +0.000007]  [<ffffffffa0160d17>] drm_dp_destroy_mst_branch_device+0x27/0x120 [drm_kms_helper]
[  +0.000006]  [<ffffffffa0163968>] drm_dp_mst_link_probe_work+0x78/0xa0 [drm_kms_helper]
[  +0.000002]  [<ffffffff810b5850>] process_one_work+0x220/0x710
[  +0.000002]  [<ffffffff810b57e4>] ? process_one_work+0x1b4/0x710
[  +0.000005]  [<ffffffff810b5e5b>] worker_thread+0x11b/0x3a0
[  +0.000003]  [<ffffffff810b5d40>] ? process_one_work+0x710/0x710
[  +0.000002]  [<ffffffff810beced>] kthread+0xed/0x100
[  +0.000003]  [<ffffffff810bec00>] ? insert_kthread_work+0x80/0x80
[  +0.000003]  [<ffffffff817121d8>] ret_from_fork+0x58/0x90

v2: add flush_work.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:34:42 +10:00
Dave Airlie
d9515c5ec1 drm/dp/mst: split connector registration into two parts (v2)
In order to cache the EDID properly for tiled displays, we
need to retrieve it before we register the connector with
userspace, otherwise userspace can call get resources
and try and get the edid before we've even cached it.

This fixes some problems when hotplugging mst monitors,
with X/mutter running. As mutter seems to get 0 modes
for one of the monitors in the tile.

v2: fix warning in radeon
handle tile setting in cached path rather than
get edid path.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:34:41 +10:00
Dave Airlie
68d8c9fc91 drm/dp/mst: update the link_address_sent before sending the link address (v3)
Update the state before sending the msg to close it.

v2: reset value if return indicates we haven't send the msg.
v3: just clean the code up.
Pointed out by Adam J Richter on

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91481

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:34:41 +10:00
Dave Airlie
df4839fdc9 drm/dp/mst: fixup handling hotplug on port removal.
output ports should always have a connector, unless
in the rare case connector allocation fails in the
driver.

In this case we only need to teardown the pdt,
and free the struct, and there is no need to
send a hotplug msg.

In the case were we add the port to the destroy
list we need to send a hotplug if we destroy
any connectors, so userspace knows to reprobe
stuff.

this patch also handles port->connector allocation
failing which should be a rare event, but makes
the code consistent.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:34:40 +10:00
Dave Airlie
1c960876be drm/dp/mst: don't pass port into the path builder function
This is unnecessary and it makes it easier to see what is needed
from port.

also add blank line to make things nicer.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:34:40 +10:00
Alex Deucher
0c6dadbe79 drm/radeon: drop radeon_fb_helper_set_par
It was just a wrapper around drm_fb_helper_set_par that
called cursor_set2 in addition.  Now that the core handles
this, drop this radeon specific version.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:31:00 +10:00
Alex Deucher
03f9abb28c drm: handle cursor_set2 in restore_fbdev_mode
If a driver uses the cursor_set2 crtc callback rather than
cursor_set, use that.  This fixes the fbdev helper for drivers
that use cursor_set2.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-02 15:30:41 +10:00
Steve French
646200a041 [SMB3] Do not fall back to SMBWriteX in set_file_size error cases
The error paths in set_file_size for cifs and smb3 are incorrect.

In the unlikely event that a server did not support set file info
of the file size, the code incorrectly falls back to trying SMBWriteX
(note that only the original core SMB Write, used for example by DOS,
can set the file size this way - this actually  does not work for the more
recent SMBWriteX).  The idea was since the old DOS SMB Write could set
the file size if you write zero bytes at that offset then use that if
server rejects the normal set file info call.

Fortunately the SMBWriteX will never be sent on the wire (except when
file size is zero) since the length and offset fields were reversed
in the two places in this function that call SMBWriteX causing
the fall back path to return an error. It is also important to never call
an SMB request from an SMB2/sMB3 session (which theoretically would
be possible, and can cause a brief session drop, although the client
recovers) so this should be fixed.  In practice this path does not happen
with modern servers but the error fall back to SMBWriteX is clearly wrong.

Removing the calls to SMBWriteX in the error paths in cifs_set_file_size

Pointed out by PaX/grsecurity team

Signed-off-by: Steve French <steve.french@primarydata.com>
Reported-by: PaX Team <pageexec@freemail.hu>
CC: Emese Revfy <re.emese@gmail.com>
CC: Brad Spengler <spender@grsecurity.net>
CC: Stable <stable@vger.kernel.org>
2015-10-01 22:48:37 -05:00