Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 12月, 2015 1 次提交
  3. 06 11月, 2015 1 次提交
  5. 30 9月, 2015 1 次提交
  7. 04 8月, 2015 1 次提交
  9. 10 7月, 2015 1 次提交
  11. 28 5月, 2015 3 次提交
  13. 24 3月, 2015 1 次提交
  15. 14 3月, 2015 2 次提交
    • K
      power_supply: Change ownership from driver to core · 297d716f
      由 Krzysztof Kozlowski 提交于 
      Change the ownership of power_supply structure from each driver
implementing the class to the power supply core.

The patch changes power_supply_register() function thus all drivers
implementing power supply class are adjusted.

Each driver provides the implementation of power supply. However it
should not be the owner of power supply class instance because it is
exposed by core to other subsystems with power_supply_get_by_name().
These other subsystems have no knowledge when the driver will unregister
the power supply. This leads to several issues when driver is unbound -
mostly because user of power supply accesses freed memory.

Instead let the core own the instance of struct 'power_supply'.  Other
users of this power supply will still access valid memory because it
will be freed when device reference count reaches 0. Currently this
means "it will leak" but power_supply_put() call in next patches will
solve it.

This solves invalid memory references in following race condition
scenario:

Thread 1: charger manager
Thread 2: power supply driver, used by charger manager

THREAD 1 (charger manager)         THREAD 2 (power supply driver)
==========================         ==============================
psy = power_supply_get_by_name()
                                   Driver unbind, .remove
                                     power_supply_unregister()
                                     Device fully removed
psy->get_property()

The 'get_property' call is executed in invalid context because the driver was
unbound and struct 'power_supply' memory was freed.

This could be observed easily with charger manager driver (here compiled
with max17040 fuel gauge):

$ cat /sys/devices/virtual/power_supply/cm-battery/capacity &
$ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind
[   55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   55.732584] pgd = d98d4000
[   55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000
[   55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
[   55.746210] Modules linked in:
[   55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G        W       3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496
[   55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000
[   55.771647] PC is at 0x0
[   55.774182] LR is at charger_get_property+0x2f4/0x36c
[   55.779201] pc : [<00000000>]    lr : [<c034b0b4>]    psr: 60000013
[   55.779201] sp : daf55e90  ip : 00000003  fp : 00000000
[   55.790657] r10: 00000000  r9 : c06e2878  r8 : d9b26c68
[   55.795865] r7 : dad81610  r6 : daec7410  r5 : daf55ebc  r4 : 00000000
[   55.802367] r3 : 00000000  r2 : daf55ebc  r1 : 0000002a  r0 : d9b26c68
[   55.808879] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   55.815994] Control: 10c5387d  Table: 598d406a  DAC: 00000015
[   55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210)
[   55.827451] Stack: (0xdaf55e90 to 0xdaf56000)
[   55.831795] 5e80:                                     60000013 c01459c4 0000002a c06f8ef8
[   55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4
[   55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80
[   55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001
[   55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000
[   55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000
[   55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124
[   55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550
[   55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364
[   55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c
[   55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000
[   55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000
[   55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c)
[   55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48)
[   55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104)
[   55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28)
[   55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484)
[   55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c)
[   55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100)
[   55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c)
[   55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48)
[   56.000626] Code: bad PC value
[   56.011652] ---[ end trace 7b64343fbdae8ef1 ]---
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

[for the nvec part]
Reviewed-by: NMarc Dietrich <marvin24@gmx.de>

[for compal-laptop.c]
Acked-by: NDarren Hart <dvhart@linux.intel.com>

[for the mfd part]
Acked-by: NLee Jones <lee.jones@linaro.org>

[for the hid part]
Acked-by: NJiri Kosina <jkosina@suse.cz>

[for the acpi part]
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>
      297d716f
    • K
      power_supply: Move run-time configuration to separate structure · 2dc9215d
      由 Krzysztof Kozlowski 提交于 
      Add new structure 'power_supply_config' for holding run-time
initialization data like of_node, supplies and private driver data.

The power_supply_register() function is changed so all power supply
drivers need updating.

When registering the power supply this new 'power_supply_config' should be
used instead of directly initializing 'struct power_supply'. This allows
changing the ownership of power_supply structure from driver to the
power supply core in next patches.

When a driver does not use of_node or supplies then it should use NULL
as config. If driver uses of_node or supplies then it should allocate
config on stack and initialize it with proper values.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NPavel Machek <pavel@ucw.cz>

[for the nvec part]
Reviewed-by: NMarc Dietrich <marvin24@gmx.de>

[for drivers/platform/x86/compal-laptop.c]
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>

[for drivers/hid/*]
Reviewed-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NSebastian Reichel <sre@kernel.org>
      2dc9215d
  17. 05 3月, 2015 1 次提交
    • D
      HID: map telephony usage page · f3dddf24
      由 Dmitry Torokhov 提交于 
      Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc
keys which get interpreted by mousedev and userspace as left/right/middle
button clicks, which is not really helpful.

This change adds mappings for usages that have corresponding input event
definitions, and leaves the rest unmapped. This can be changed when
there are userspace consumers for more telephony usages.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f3dddf24
  19. 07 1月, 2015 3 次提交
    • J
      HID: fixup the conflicting keyboard mappings quirk · 8e7b3410
      由 Jiri Kosina 提交于 
      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.

Cc: <stable@vger.kernel.org>
Fixes: 6ce901eb ("HID: input: fix confusion on conflicting mappings")
Reported-by: NFredrik Hallenberg <megahallon@gmail.com>
Reported-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      8e7b3410
    • R
      HID: apple: fix battery support for the 2009 ANSI wireless keyboard · cbd366be
      由 Ross Skaliotis 提交于 
      Enabled quirks necessary for correct battery capacity reporting. Cleaned up
surrounding style.
Signed-off-by: NRoss Skaliotis <rskaliotis@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      cbd366be
    • D
      HID: input: fix confusion on conflicting mappings · 6ce901eb
      由 David Herrmann 提交于 
      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.

Cc: <stable@vger.kernel.org>
Reported-by: NAdam Goode <adam@spicenitz.org>
Reported-by: NFredrik Hallenberg <megahallon@gmail.com>
Tested-by: NFredrik Hallenberg <megahallon@gmail.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      6ce901eb
  21. 17 12月, 2014 1 次提交
  23. 02 12月, 2014 1 次提交
  25. 29 10月, 2014 1 次提交
  27. 22 10月, 2014 1 次提交
  29. 21 10月, 2014 1 次提交
  31. 26 8月, 2014 1 次提交
  33. 03 6月, 2014 1 次提交
  35. 28 4月, 2014 1 次提交
  37. 25 2月, 2014 2 次提交
  39. 17 2月, 2014 3 次提交
  41. 03 2月, 2014 2 次提交
  43. 21 12月, 2013 1 次提交
  45. 18 10月, 2013 1 次提交
    • N
      HID: Fix unit exponent parsing again · ad0e669b
      由 Nikolai Kondrashov 提交于 
      Revert some changes done in 77463838.

Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.

Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.

Explanations follow.

There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.

The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.

The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.

Taking the representation example of (integer) joules from the
specification:

[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7

the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:

Nibble  Part        Value   Meaning
-----   ----        -----   -------
0       System      1       SI Linear
1       Length      2       Centimeters^2
2       Mass        1       Grams
3       Time        -2      Seconds^-2

To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.

See also the examples of "Unit" values for some common units in the same
chapter.

However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.

As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ad0e669b
  47. 13 9月, 2013 1 次提交
  49. 02 9月, 2013 1 次提交
  51. 31 7月, 2013 1 次提交
    • D
      HID: input: generic hidinput_input_event handler · 50c9d75b
      由 David Herrmann 提交于 
      The hidinput_input_event() callback converts input events written from
userspace into HID reports and sends them to the device. We currently
implement this in every HID transport driver, even though most of them do
the same.

This provides a generic hidinput_input_event() implementation which is
mostly copied from usbhid. It uses a delayed worker to allow multiple LED
events to be collected into a single output event.
We use the custom ->request() transport driver callback to allow drivers
to adjust the outgoing report and handle the request asynchronously. If no
custom ->request() callback is available, we fall back to the generic raw
output report handler (which is synchronous).

Drivers can still provide custom hidinput_input_event() handlers (see
logitech-dj) if the generic implementation doesn't fit their needs.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      50c9d75b
  53. 20 6月, 2013 2 次提交
  55. 29 5月, 2013 1 次提交
    • D
      HID: input: return ENODATA if reading battery attrs fails · d0a934b7
      由 David Herrmann 提交于 
      power_supply core has the bad habit of calling our battery callbacks
from within power_supply_register(). Furthermore, if the callbacks
fail with an unhandled error code, it will skip any uevent that it
might currently process.
So if HID-core registers battery devices, an "add" uevent is generated
and the battery callbacks are called. These will gracefully fail due
to timeouts as they might still hold locks on event processing. One
could argue that this should be fixed in power_supply core, but the
least we can do is to signal ENODATA so power_supply core will just
skip the property and continue with the uevent.

This fixes a bug where "add" and "remove" uevents are skipped for
battery devices. upower is unable to track these devices and currently
needs to ignore them.

This patch also overwrites any other error code. I cannot see any reason
why we should forward protocol- or I/O-errors to the power_supply core.
We handle these errors in hid_ll_driver later, anyway, so just skip
them. power_supply core cannot do anything useful with them, anyway,
and we avoid skipping important uevents and confusing user-space.

Thanks a lot to Daniel Nicoletti for pushing and investigating
on this.

Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: David Woodhouse <dwmw2@infradead.org>
Reported-by: NDaniel Nicoletti <dantti12@gmail.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d0a934b7
  57. 27 3月, 2013 1 次提交
  59. 29 11月, 2012 1 次提交