1. 25 Jun, 2018 1 commit
  2. 18 Mar, 2016 1 commit
  3. 28 Dec, 2015 1 commit
  4. 13 Mar, 2015 2 commits
    • Krzysztof Kozlowski's avatar
      power_supply: Change ownership from driver to core · 297d716f
      Krzysztof Kozlowski authored
      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: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      
      [for the nvec part]
      Reviewed-by: Marc Dietrich's avatarMarc Dietrich <marvin24@gmx.de>
      
      [for compal-laptop.c]
      Acked-by: default avatarDarren Hart <dvhart@linux.intel.com>
      
      [for the mfd part]
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      
      [for the hid part]
      Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
      
      [for the acpi part]
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      297d716f
    • Krzysztof Kozlowski's avatar
      power_supply: Move run-time configuration to separate structure · 2dc9215d
      Krzysztof Kozlowski authored
      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: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Acked-by: Pavel Machek's avatarPavel Machek <pavel@ucw.cz>
      
      [for the nvec part]
      Reviewed-by: Marc Dietrich's avatarMarc Dietrich <marvin24@gmx.de>
      
      [for drivers/platform/x86/compal-laptop.c]
      Reviewed-by: default avatarDarren Hart <dvhart@linux.intel.com>
      
      [for drivers/hid/*]
      Reviewed-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      2dc9215d
  5. 30 Oct, 2013 2 commits
  6. 07 Oct, 2013 1 commit
    • David Herrmann's avatar
      HID: wiimote: fix FF deadlock · f50f9aab
      David Herrmann authored
      The input core has an internal spinlock that is acquired during event
      injection via input_event() and friends but also held during FF callbacks.
      That means, there is no way to share a lock between event-injection and FF
      handling. Unfortunately, this is what is required for wiimote state
      tracking and what we do with state.lock and input->lock.
      
      This deadlock can be triggered when using continuous data reporting and FF
      on a wiimote device at the same time. I takes me at least 30m of
      stress-testing to trigger it but users reported considerably shorter
      times (http://bpaste.net/show/132504/) when using some gaming-console
      emulators.
      
      The real problem is that we have two copies of internal state, one in the
      wiimote objects and the other in the input device. As the input-lock is
      not supposed to be accessed from outside of input-core, we have no other
      chance than offloading FF handling into a worker. This actually works
      pretty nice and also allows to implictly merge fast rumble changes into a
      single request.
      
      Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF
      responsiveness. Initial tests were fine so lets fix the race first and if
      it turns out to be too slow we can always handle FF out-of-band and skip
      the queue-worker.
      
      Cc: <stable@vger.kernel.org> # 3.11+
      Reported-by: Thomas Schneider
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      f50f9aab
  7. 07 Sep, 2013 1 commit
  8. 04 Sep, 2013 2 commits
  9. 27 Jun, 2013 1 commit
    • David Herrmann's avatar
      HID: wiimote: support Nintendo Wii U Pro Controller · b8e0fe31
      David Herrmann authored
      The Wii U Pro Controller is a new Nintendo remote device that looks very
      similar to the XBox controller. It has nearly the same features and uses
      the same protocol as the Wii Remote.
      
      We add a new wiimote extension device so the Pro Controller is properly
      detected and supported.
      
      The device reports MP support, which is odd and I couldn't get it working,
      yet. Hence, we disable MP registers for now. Further investigation is
      needed to see what extra capabilities are provided.
      
      There are some other unknown bits in the extension reports that I couldn't
      figure out what they do. You can use hidraw to access these if you're
      interested.
      
      We might want to hook up the "charging" and "USB" bits to the battery
      device so user-space can query whether it is currently charged via USB.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      b8e0fe31
  10. 18 Jun, 2013 1 commit
  11. 03 Jun, 2013 14 commits
    • David Herrmann's avatar
      HID: wiimote: fix classic controller parsing · ee286c2e
      David Herrmann authored
      I finally got a "Classic Controller" and "Classic Controller Pro" in my
      hands and noticed that all analog data was incorrectly parsed. Fix this
      up so we report the data that we pretend we do.
      
      I really doubt that this breaks any backwards compatibility, but if we
      get any reports, we only need to revert this single patch.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      ee286c2e
    • David Herrmann's avatar
      HID: wiimote: add MP quirks · 9f329741
      David Herrmann authored
      Devices which have built-in motion plus ports don't need MP detection
      logic. The new WIIMOD_BUILTIN_MP modules sets the WIIPROTO_FLAG_BUILTIN_MP
      flag which disables polling for MP.
      
      Some other devices erroneously report that they support motion-plus. For
      these devices and all devices without extension ports, we load
      WIIMOD_NO_MP which sets WIIPROTO_FLAG_NO_MP. This effectively disables all
      MP detection logic.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      9f329741
    • David Herrmann's avatar
      HID: wiimote: add "bboard_calib" attribute · 8b1fded7
      David Herrmann authored
      Balance-Boards provide 3 16bit calibration values for each of the 4
      sensors. We provide these now as 192bit value via a new "bboard_calib"
      sysfs attribute.
      We also re-read the calibration data from the device whenever user-space
      attempts to read this file. On normal Nintendo boards, this always
      produces the same results, however, on some 3rd party devices these values
      change until the device is fully initialized. As I have currently no idea
      how long to wait until it's ready (sometimes takes up to 10s?) we provide
      a simple workaround for users by reading this file.
      
      If we, at some point, figure out how it works, we can implement it in the
      kernel and provide offline data via "bboard_calib". This won't break
      user-space then.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      8b1fded7
    • David Herrmann's avatar
      HID: wiimote: add Motion Plus extension module · 34472d37
      David Herrmann authored
      Add parsers for motion plus data so we can hotplug motion plus extensions
      and make use of them. This is mostly the same as the old static motion
      plus parser.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      34472d37
    • David Herrmann's avatar
      HID: wiimote: add Classic Controller extension · 9d6f9ecb
      David Herrmann authored
      Add a new extension module for the classic controller so we get hotplug
      support for this device. It is mostly the same as the old static classic
      controller parser.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      9d6f9ecb
    • David Herrmann's avatar
      HID: wiimote: add Nunchuk support · b6ee67b3
      David Herrmann authored
      This moves the nunchuk parser over to an extension module. This allows to
      make use of hotplugged Nunchuks instead of the old static parser.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      b6ee67b3
    • David Herrmann's avatar
      HID: wiimote: add Balance Board support · f1d4bed4
      David Herrmann authored
      This adds Nintendo Wii Balance Board support to the new HOTPLUG capable
      wiimote core. It is mostly copied from the old extension.
      
      This also adds Balance Board device detection. Whenever we find a device
      that supports the balance-board extension, we assume that it is a real
      balance board and disable unsupported hardward like accelerometer, IR,
      rumble and more.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      f1d4bed4
    • David Herrmann's avatar
      HID: wiimote: add extension hotplug support · 4148b6bf
      David Herrmann authored
      The Wii Remote has several extension ports. The first port (EXT) provides
      hotplug events whenever an extension is plugged. The second port (MP)
      does not provide hotplug events by default. Instead, we have to map MP
      into EXT to get events for it.
      
      This patch introduces hotplug support for extensions. It is fairly
      complicated to get this right because the Wii Remote sends a lot of
      noise-hotplug events while activating extension ports. We need to filter
      the events and only handle the events that are real hotplug events.
      
      Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same
      time, we need to map MP into EXT and enable a passthrough-mode. This will
      then send real EXT events through the mapped MP interleaved with real MP
      events. But once MP is mapped, we no longer have access to the real EXT
      registers so we need to perform setup _before_ mapping MP. Furthermore, we
      no longer can read EXT IDs so we cannot verify if EXT is still the same
      extension that we expect it to be.
      We deal with this by unmapping MP whenever we got into a situation where
      EXT might have changed. We then re-read EXT and MP and remap everything.
      
      The real Wii Console takes a fairly easy approach: It simply reconnects to
      the device on hotplug events that it didn't expect. So if a program wants
      MP events, but MP is disconnected, it fails and reconnects so it can wait
      for MP hotplug events again.
      This simplifies hotplugging a lot because we just react on PLUG events and
      ignore UNPLUG events.
      The more sophisticated Wii applications avoid reconnection (well, they
      still reconnect during many weird events, but at least not during UNPLUG)
      but they start polling the device. This allows them to disable the device,
      poll for the extension ports to settle and then initialize them again.
      Unfortunately, this approach fails whenever an extension is replugged
      while it is initialized. We would loose UNPLUG events and polling the
      device later will give unreliable results because the extension port might
      be in some weird state, even though it's actually unplugged.
      
      Our approach is a real HOTPLUG approch. We keep track of the EXT and
      mapped MP hotplug events whenever they occur. We then re-evaluate the
      device state and initialize any possible new extension or deinitialize any
      gone extension. Only during initialization, we set an extension port
      ACTIVE. However, during an unplug event we mark them as INACTIVE. This
      guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them
      marked as PLUGGED+ACTIVE but only PLUGGED.
      To deal with annoying noise-hotplug events during extension mapping, we
      simply rescan the device before performing any mapping. This allows us to
      ignore all the noise events as long as the device is in the correct state.
      
      Long story short: EXT and MP registers are sparsely known and we need to
      jump through hoops to get reliable HOTPLUG working. But while Nintendo
      needs *FOUR* Bluetooth reconnections for the shortest imaginable
      boot->menu->game->menu->shutdown sequence, we now need *ZERO*.
      
      As always, 3rd party devices tend to break whenever we behave differently
      than the original Wii. So there are also devices which _expect_ a
      disconnect after UNPLUG. Obviously, these devices won't benefit from this
      patch. But all official devices were tested extensively and work great
      during any hotplug sequence. Yay!
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      4148b6bf
    • David Herrmann's avatar
      HID: wiimote: convert IR to module · 3b5f03c4
      David Herrmann authored
      IR is the last piece that still is handled natively. This patch converts
      it into a sub-device module like all other sub-devices. It mainly moves
      code and doesn't change semantics.
      
      We also implicitly sync IR data on ir_to_input3 now so the explicit
      input_sync() calls are no longer needed.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      3b5f03c4
    • David Herrmann's avatar
      HID: wiimote: convert ACCEL to module · 0ea16757
      David Herrmann authored
      Accelerometer data is very similar to KEYS handling. Therefore, convert
      all ACCEL related handling into a sub-device module similar to KEYS.
      
      This doesn't change any semantics but only moves code over to
      wiimote-modules.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      0ea16757
    • David Herrmann's avatar
      HID: wiimote: convert LEDS to modules · 6c5ae018
      David Herrmann authored
      Each of the 4 LEDs may be supported individually by devices. Therefore,
      we need one module for each device. To avoid code-duplication, we simply
      pass the LED ID as "arg" argument to the module loading code.
      
      This just moves the code over to wiimote-module. The semantics stay the
      same as before.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      6c5ae018
    • David Herrmann's avatar
      HID: wiimote: convert BATTERY to module · dcf39231
      David Herrmann authored
      This introduces a new sub-device module for the BATTERY handlers. It
      moves the whole power_supply battery handling over to wiimote-modules.
      
      This doesn't change any semantics or ABI but only converts the battery
      handling into a sub-device module.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      dcf39231
    • David Herrmann's avatar
      HID: wiimote: convert KEYS and RUMBLE to modules · 20cef813
      David Herrmann authored
      This introduces the first sub-device modules by converting the KEYS and
      RUMBLE sub-devices into wiimote modules. Both must be converted at once
      because they depend on the built-in shared input device.
      
      This mostly moves code from wiimote-core to wiimote-modules and doesn't
      change any semantics or ABI.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      20cef813
    • David Herrmann's avatar
      HID: wiimote: add sub-device module infrastructure · 27f06942
      David Herrmann authored
      To avoid loading all sub-device drivers for every Wii Remote, even though
      the required hardware might not be available, we introduce a module layer.
      
      The module layer specifies which sub-devices are available on each
      device-type. After device detection, we only load the modules for the
      detected device. If module loading fails, we unload everything and mark
      the device as WIIMOTE_DEV_UNKNOWN. As long as a device is marked as
      "unknown", no sub-devices will be used and the device is considered
      unsupported.
      
      All the different sub-devices, including KEYS, RUMBLE, BATTERY, LEDS,
      ACCELEROMETER, IR and more will be ported in follow-up patches to the new
      module layer.
      Signed-off-by: David Herrmann's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      27f06942