Skip to content

L
linux
Switch branch/tag
  1. 30 Mar, 2016 2 commits
    • Dan Carpenter's avatar
      EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr() · f727a148
      Dan Carpenter authored 
      commit 6f3508f6 upstream.

dct_sel_base_off is declared as a u64 but we're only using the lower 32
bits because of a shift wrapping bug. This can possibly truncate the
upper 16 bits of DctSelBaseOffset[47:26], causing us to misdecode the CS
row.

Fixes: c8e518d5 ('amd64_edac: Sanitize f10_get_base_addr_offset')
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Cc: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20160120095451.GB19898@mwandaSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f727a148
    • Ville Syrjälä's avatar
      drm/i915: Workaround CHV pipe C cursor fail · 7973b9e5
      Ville Syrjälä authored 
      commit b29ec92c upstream.

Turns out CHV pipe C was glued on somewhat poorly, and there's something
wrong with the cursor. If the cursor straddles the left screen edge,
and is then moved away from the edge or disabled, the pipe will often
underrun. If enough underruns are triggered quickly enough the pipe
will fall over and die (it just scans out a solid color and reports
a constant underrun). We need to turn the disp2d power well off and
on again to recover the pipe.

None of that is very nice for the user, so let's just refuse to place
the cursor in the compromised position. The ddx appears to fall back
to swcursor when the ioctl returns an error, so theoretically there's
no loss of functionality for the user (discounting swcursor bugs).
I suppose most cursors images actually have the hotspot not exactly
at 0,0 so under typical conditions the fallback will in fact kick in
as soon as the cursor touches the left edge of the screen.

Any atomic compositor should anyway be prepared to fall back to
GPU composition when things don't work out, so there should be no
problem with those.

Other things that I tried to solve this include flipping all
display related clock gating knobs I could find, increasing the
minimum gtt alignment all the way up to 512k. I also tried to see
if there are more specific screen coordinates that hit the bug, but
the findings were somewhat inconclusive. Sometimes the failures
happen almost across the whole left edge, sometimes more at the very
top and around the bottom half. I wasn't able to find any real pattern
to these variations, so it seems our only choice is to just refuse
to straddle the left screen edge at all.

Cc: Jason Plum <max@warheads.net>
Testcase: igt/kms_chv_cursor_fail
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450459479-16286-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
[ kamal: backport to 4.2-stable: context ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7973b9e5
  3. 29 Mar, 2016 8 commits
  5. 28 Mar, 2016 3 commits
    • Geert Uytterhoeven's avatar
      gpio: rcar: Add Runtime PM handling for interrupts · 93267aeb
      Geert Uytterhoeven authored 
      commit b26a719b upstream.

The R-Car GPIO driver handles Runtime PM for requested GPIOs only.

When using a GPIO purely as an interrupt source, no Runtime PM handling
is done, and the GPIO module's clock may not be enabled.

To fix this:
  - Add .irq_request_resources() and .irq_release_resources() callbacks
    to handle Runtime PM when an interrupt is requested,
  - Add irq_bus_lock() and sync_unlock() callbacks to handle Runtime PM
    when e.g. disabling/enabling an interrupt, or configuring the
    interrupt type.

Fixes: d5c3d846 "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      93267aeb
    • Linus Walleij's avatar
      gpio: add a data pointer to gpio_chip · 70ee401b
      Linus Walleij authored 
      commit b08ea35a upstream.

This adds a void * pointer to gpio_chip so that driver can
assign and retrieve some states. This is done to get rid of
container_of() calls for gpio_chips embedded inside state
containers, so we can remove the need to have the gpio_chip
or later (planned) struct gpio_device be dynamically allocated
at registration time, so that its struct device can be properly
reference counted and not bound to its parent device (e.g.
a platform_device) but instead live on after unregistration
if it is opened by e.g. a char device or sysfs.

The data is added with the new function gpiochip_add_data()
and for compatibility we add static inline wrapper function
gpiochip_add() that will call gpiochip_add_data() with
NULL as argument. The latter will be removed once we have
exorcised gpiochip_add() from the kernel.

gpiochip_get_data() is added as a static inline accessor
for drivers to quickly get their data out.
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
[ kamal: 4.2-stable prereq ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      70ee401b
    • Bamvor Jian Zhang's avatar
      gpiolib: do not allow to insert an empty gpiochip · 31d98a9a
      Bamvor Jian Zhang authored 
      commit 5ed41cc4 upstream.

We need to check if number of gpio is positive if there is no
such check in devicetree or acpi or whatever called before
gpiochip_add.

I suppose that devicetree and acpi do not allow insert gpiochip
with zero number but I do not know if it is enough to ignore
this check in gpiochip_add.
Signed-off-by: default avatarBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
[ kamal: 4.2-stable prereq ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      31d98a9a
  7. 25 Mar, 2016 4 commits
  9. 21 Mar, 2016 1 commit
  11. 15 Mar, 2016 22 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7