Skip to content

L
linux
Switch branch/tag
  1. 09 Apr, 2015 31 commits
  3. 16 Mar, 2015 9 commits
    • Jiri Slaby's avatar
      Linux 3.12.39 · 0b8aecf1
      Jiri Slaby authored
      0b8aecf1
    • Sergei Shtylyov's avatar
      clk-gate: fix bit # check in clk_register_gate() · 13538bca
      Sergei Shtylyov authored 
      commit 2e9dcdae upstream.

In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit #
should be no higher than 15, however the corresponding check is obviously off-
by-one.

Fixes: 04577994 ("clk: gate: add CLK_GATE_HIWORD_MASK")
Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: default avatarMichael Turquette <mturquette@linaro.org>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      13538bca
    • Sergey Ryazanov's avatar
      ath5k: fix spontaneus AR5312 freezes · cb3f9ca3
      Sergey Ryazanov authored 
      commit 8bfae4f9 upstream.

Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.

The easiest way to reproduce this issue: create a station interface,
start continous scan with wpa_supplicant and load CPU by something. Or
just create multiple station interfaces and put them all in continous
scan.

This patch partially reverts the commit 1846ac3d ("ath5k: Use
usleep_range where possible"), which replaces initial udelay()
by usleep_range().

I do not know actual source of this issue, but all looks like that HW
freeze is caused by transaction on internal SoC bus, while wireless
block is in reset state.

Also I should note that I do not know how many chips are affected, but I
did not see this issue with chips, other than AR5312.

CC: Jiri Slaby <jirislaby@gmail.com>
CC: Nick Kossifidis <mickflemm@gmail.com>
CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Fixes: 1846ac3d ("ath5k: Use usleep_range where possible")
Reported-by: default avatarChristophe Prevotaux <c.prevotaux@rural-networks.com>
Tested-by: default avatarChristophe Prevotaux <c.prevotaux@rural-networks.com>
Tested-by: default avatarEric Bree <ebree@nltinc.com>
Signed-off-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      cb3f9ca3
    • Trond Myklebust's avatar
      NFSv4: Don't call put_rpccred() under the rcu_read_lock() · 168d2e5e
      Trond Myklebust authored 
      commit 7c0af9ff upstream.

put_rpccred() can sleep.

Fixes: 8f649c37 ("NFSv4: Fix the locking in nfs_inode_reclaim_delegation()")
Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      168d2e5e
    • Chris Wilson's avatar
      ACPI / video: Load the module even if ACPI is disabled · fec983fe
      Chris Wilson authored 
      commit 6e17cb12 upstream.

i915.ko depends upon the acpi/video.ko module and so refuses to load if
ACPI is disabled at runtime if for example the BIOS is broken beyond
repair. acpi/video provides an optional service for i915.ko and so we
should just allow the modules to load, but do no nothing in order to let
the machines boot correctly.
Reported-by: default avatarBill Augur <bill-auger@programmer.net>
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Acked-by: default avatarAaron Lu <aaron.lu@intel.com>
[ rjw: Fixed up the new comment in acpi_video_init() ]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      fec983fe
    • Alex Deucher's avatar
      drm/radeon: fix 1 RB harvest config setup for TN/RL · 8245bceb
      Alex Deucher authored 
      commit dbfb00c3 upstream.

The logic was reversed from what the hw actually exposed.
Fixes graphics corruption in certain harvest configurations.
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8245bceb
    • Alex Deucher's avatar
      drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh · 84f9532f
      Alex Deucher authored 
      commit 3d2d98ee upstream.

Just in case it hasn't been calculated for the mode.
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      84f9532f
    • Jiri Kosina's avatar
      HID: fixup the conflicting keyboard mappings quirk · 36530280
      Jiri Kosina authored 
      commit 8e7b3410 upstream.

The ignore check that got added in 6ce901eb ("HID: input: fix confusion
on conflicting mappings") needs to properly check for VARIABLE reports
as well (ARRAY reports should be ignored), otherwise legitimate keyboards
might break.

Fixes: 6ce901eb ("HID: input: fix confusion on conflicting mappings")
Reported-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
Reported-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      36530280
    • David Herrmann's avatar
      HID: input: fix confusion on conflicting mappings · 955c3838
      David Herrmann authored 
      commit 6ce901eb upstream.

On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
neighbours look like this:

           +---+ +---+ +-------+
           | 1 | | 2 | |   5   |
           +---+ +---+ +-------+
             +---+ +-----------+
             | 3 | |     4     |
             +---+ +-----------+

On a PC-102/105 keyboard (European layout) it looks like this:

           +---+ +---+ +-------+
           | 1 | | 2 | |       |
           +---+ +---+ +-+  4  |
             +---+ +---+ |     |
             | 3 | | 5 | |     |
             +---+ +---+ +-----+

(Note that the number of keys is the same, but key '5' is moved down and
 the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)

The keys 1-4 report the same scan-code in HID in both layouts, even though
the keysym they produce is usually different depending on the XKB-keymap
used by user-space.
However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
and 0x32 for the lower layout, as defined by the HID spec. This is highly
confusing as the linux-input API uses a single keycode for both.

So far, this was never a problem as there never has been a keyboard with
both of those keys present at the same time. It would have to look
something like this:

           +---+ +---+ +-------+
           | 1 | | 2 | |  x31  |
           +---+ +---+ +-------+
             +---+ +---+ +-----+
             | 3 | |x32| |  4  |
             +---+ +---+ +-----+

HID can represent such a keyboard, but the linux-input API cannot.
Furthermore, any user-space mapping would be confused by this and,
luckily, no-one ever produced such hardware.

Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
is present on a hardware, this works just fine.

Lets introduce hardware-vendors into this:
------------------------------------------

Unfortunately, it seems way to expensive to produce a different device for
American and European layouts. Therefore, hardware-vendors put both keys,
(0x31 and 0x32) on the same keyboard, but only one of them is hooked up
to the physical button, the other one is 'dead'.
This means, they can use the same hardware, with a different button-layout
and automatically produce the correct HID events for American *and*
European layouts. This is unproblematic for normal keyboards, as the
'dead' key will never report any KEY-DOWN events. But RollOver keyboards
send the whole matrix on each key-event, allowing n-key roll-over mode.
This means, we get a 0x31 and 0x32 event on each key-press. One of them
will always be 0, the other reports the real state. As we map both to the
same keycode, we will get spurious key-events, even though the real
key-state never changed.

The easiest way would be to blacklist 'dead' keys and never handle those.
We could simply read the 'country' tag of USB devices and blacklist either
key according to the layout. But... hardware vendors... want the same
device for all countries and thus many of them set 'country' to 0 for all
devices. Meh..

So we have to deal with this properly. As we cannot know which of the keys
is 'dead', we either need a heuristic and track those keys, or we simply
make use of our value-tracking for HID fields. We simply ignore HID events
for absolute data if the data didn't change. As HID tracks events on the
HID level, we haven't done the keycode translation, yet. Therefore, the
'dead' key is tracked independently of the real key, therefore, any events
on it will be ignored.

This patch simply discards any HID events for absolute data if it didn't
change compared to the last report. We need to ignore relative and
buffered-byte reports for obvious reasons. But those cannot be affected by
this bug, so we're fine.

Preferably, we'd do this filtering on the HID-core level. But this might
break a lot of custom drivers, if they do not follow the HID specs.
Therefore, we do this late in hid-input just before we inject it into the
input layer (which does the exact same filtering, but on the keycode
level).

If this turns out to break some devices, we might have to limit filtering
to EV_KEY events. But lets try to do the Right Thing first, and properly
filter any absolute data that didn't change.

This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
hardware. We might wanna wait with backporting for a while, before we know
it doesn't break anything else, though.
Reported-by: default avatarAdam Goode <adam@spicenitz.org>
Reported-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
Tested-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      955c3838
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7