1. 07 6月, 2017 1 次提交
  2. 27 5月, 2017 2 次提交
  3. 20 4月, 2017 1 次提交
  4. 14 4月, 2017 3 次提交
  5. 13 4月, 2017 2 次提交
  6. 11 4月, 2017 1 次提交
    • Y
      usb: gadget: udc: renesas_usb3: add support for usb role swap · cc995c9e
      Yoshihiro Shimoda 提交于
      This patch adds support for usb role swap via sysfs "role".
      
      For example:
       1) Connect a usb cable using 2 Salvator-X boards.
        - For A-Device, the cable is connected to CN11 (USB3.0 ch0).
        - For B-Device, the cable is connected to CN9 (USB2.0 ch0).
       2) On A-Device, you input the following command:
        # echo peripheral > /sys/devices/platform/soc/ee020000.usb/role
       3) On B-Device, you input the following command:
        # echo host > /sys/devices/platform/soc/ee080200.usb-phy/role
      
      Then, the A-Device acts as a peripheral and the B-Device acts as
      a host. Please note that A-Device must input the following command
      if you want the board to act as a host again.
       # echo host > /sys/devices/platform/soc/ee020000.usb/role
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      cc995c9e
  7. 09 4月, 2017 3 次提交
  8. 26 3月, 2017 1 次提交
  9. 23 3月, 2017 1 次提交
  10. 09 3月, 2017 1 次提交
  11. 08 3月, 2017 1 次提交
    • J
      livepatch: change to a per-task consistency model · d83a7cb3
      Josh Poimboeuf 提交于
      Change livepatch to use a basic per-task consistency model.  This is the
      foundation which will eventually enable us to patch those ~10% of
      security patches which change function or data semantics.  This is the
      biggest remaining piece needed to make livepatch more generally useful.
      
      This code stems from the design proposal made by Vojtech [1] in November
      2014.  It's a hybrid of kGraft and kpatch: it uses kGraft's per-task
      consistency and syscall barrier switching combined with kpatch's stack
      trace switching.  There are also a number of fallback options which make
      it quite flexible.
      
      Patches are applied on a per-task basis, when the task is deemed safe to
      switch over.  When a patch is enabled, livepatch enters into a
      transition state where tasks are converging to the patched state.
      Usually this transition state can complete in a few seconds.  The same
      sequence occurs when a patch is disabled, except the tasks converge from
      the patched state to the unpatched state.
      
      An interrupt handler inherits the patched state of the task it
      interrupts.  The same is true for forked tasks: the child inherits the
      patched state of the parent.
      
      Livepatch uses several complementary approaches to determine when it's
      safe to patch tasks:
      
      1. The first and most effective approach is stack checking of sleeping
         tasks.  If no affected functions are on the stack of a given task,
         the task is patched.  In most cases this will patch most or all of
         the tasks on the first try.  Otherwise it'll keep trying
         periodically.  This option is only available if the architecture has
         reliable stacks (HAVE_RELIABLE_STACKTRACE).
      
      2. The second approach, if needed, is kernel exit switching.  A
         task is switched when it returns to user space from a system call, a
         user space IRQ, or a signal.  It's useful in the following cases:
      
         a) Patching I/O-bound user tasks which are sleeping on an affected
            function.  In this case you have to send SIGSTOP and SIGCONT to
            force it to exit the kernel and be patched.
         b) Patching CPU-bound user tasks.  If the task is highly CPU-bound
            then it will get patched the next time it gets interrupted by an
            IRQ.
         c) In the future it could be useful for applying patches for
            architectures which don't yet have HAVE_RELIABLE_STACKTRACE.  In
            this case you would have to signal most of the tasks on the
            system.  However this isn't supported yet because there's
            currently no way to patch kthreads without
            HAVE_RELIABLE_STACKTRACE.
      
      3. For idle "swapper" tasks, since they don't ever exit the kernel, they
         instead have a klp_update_patch_state() call in the idle loop which
         allows them to be patched before the CPU enters the idle state.
      
         (Note there's not yet such an approach for kthreads.)
      
      All the above approaches may be skipped by setting the 'immediate' flag
      in the 'klp_patch' struct, which will disable per-task consistency and
      patch all tasks immediately.  This can be useful if the patch doesn't
      change any function or data semantics.  Note that, even with this flag
      set, it's possible that some tasks may still be running with an old
      version of the function, until that function returns.
      
      There's also an 'immediate' flag in the 'klp_func' struct which allows
      you to specify that certain functions in the patch can be applied
      without per-task consistency.  This might be useful if you want to patch
      a common function like schedule(), and the function change doesn't need
      consistency but the rest of the patch does.
      
      For architectures which don't have HAVE_RELIABLE_STACKTRACE, the user
      must set patch->immediate which causes all tasks to be patched
      immediately.  This option should be used with care, only when the patch
      doesn't change any function or data semantics.
      
      In the future, architectures which don't have HAVE_RELIABLE_STACKTRACE
      may be allowed to use per-task consistency if we can come up with
      another way to patch kthreads.
      
      The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
      is in transition.  Only a single patch (the topmost patch on the stack)
      can be in transition at a given time.  A patch can remain in transition
      indefinitely, if any of the tasks are stuck in the initial patch state.
      
      A transition can be reversed and effectively canceled by writing the
      opposite value to the /sys/kernel/livepatch/<patch>/enabled file while
      the transition is in progress.  Then all the tasks will attempt to
      converge back to the original patch state.
      
      [1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.czSigned-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NMiroslav Benes <mbenes@suse.cz>
      Acked-by: Ingo Molnar <mingo@kernel.org>        # for the scheduler changes
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d83a7cb3
  12. 05 3月, 2017 1 次提交
  13. 25 2月, 2017 1 次提交
    • H
      leds: class: Add new optional brightness_hw_changed attribute · b8c5099b
      Hans de Goede 提交于
      Some LEDs may have their brightness level changed autonomously
      (outside of kernel control) by hardware / firmware. This commit
      adds support for an optional brightness_hw_changed attribute to
      signal such changes to userspace (if a driver can detect them):
      
      What:		/sys/class/leds/<led>/brightness_hw_changed
      Date:		January 2017
      KernelVersion:	4.11
      Description:
      		Last hardware set brightness level for this LED. Some LEDs
      		may be changed autonomously by hardware/firmware. Only LEDs
      		where this happens and the driver can detect this, will
      		have this file.
      
      		This file supports poll() to detect when the hardware
      		changes the brightness.
      
      		Reading this file will return the last brightness level set
      		by the hardware, this may be different from the current
      		brightness.
      
      Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
      their flags field and call led_classdev_notify_brightness_hw_changed()
      with the hardware set brightness when they detect a hardware / firmware
      triggered brightness change.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
      b8c5099b
  14. 23 2月, 2017 1 次提交
  15. 15 2月, 2017 1 次提交
  16. 11 2月, 2017 3 次提交
  17. 01 2月, 2017 1 次提交
  18. 31 1月, 2017 1 次提交
  19. 30 1月, 2017 2 次提交
    • S
      [media] rc: change wakeup_protocols to list all protocol variants · 0751d33c
      Sean Young 提交于
      For IR wakeup, a driver has to program the hardware to wakeup at a
      specific IR sequence, so it makes no sense to allow multiple wakeup
      protocols to be selected. In the same manner the sysfs interface only
      allows one scancode to be provided.
      
      In addition, we need to know the specific variant of the protocol.
      
      In short, these changes are made to the wakeup_protocols sysfs entry:
       - list all the protocol variants rather than the protocol groups,
         e.g. "nec nec-x nec-32" rather than just "nec".
       - only allow one protocol variant to be selected rather than multiple
       - wakeup_filter can only be set once a protocol has been selected in
         wakeup_protocols.
      
      This is an API change, however the only user of this API is the img-ir,
      but the wakeup code was never merged to mainline, so it was never used.
      Signed-off-by: NSean Young <sean@mess.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Sifan Naeem <sifan.naeem@imgtec.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      0751d33c
    • H
      leds: class: Add new optional brightness_hw_changed attribute · 0cb8eb30
      Hans de Goede 提交于
      Some LEDs may have their brightness level changed autonomously
      (outside of kernel control) by hardware / firmware. This commit
      adds support for an optional brightness_hw_changed attribute to
      signal such changes to userspace (if a driver can detect them):
      
      What:		/sys/class/leds/<led>/brightness_hw_changed
      Date:		January 2017
      KernelVersion:	4.11
      Description:
      		Last hardware set brightness level for this LED. Some LEDs
      		may be changed autonomously by hardware/firmware. Only LEDs
      		where this happens and the driver can detect this, will
      		have this file.
      
      		This file supports poll() to detect when the hardware
      		changes the brightness.
      
      		Reading this file will return the last brightness level set
      		by the hardware, this may be different from the current
      		brightness.
      
      Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
      their flags field and call led_classdev_notify_brightness_hw_changed()
      with the hardware set brightness when they detect a hardware / firmware
      triggered brightness change.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
      0cb8eb30
  20. 29 1月, 2017 2 次提交
  21. 26 1月, 2017 1 次提交
    • B
      iio: Add STM32 timer trigger driver · 93fbe91b
      Benjamin Gaignard 提交于
      Timers IPs can be used to generate triggers for other IPs like
      DAC or ADC.
      Each trigger may result of timer internals signals like counter enable,
      reset or edge, this configuration could be done through "master_mode"
      device attribute.
      
      Since triggers could be used by DAC or ADC their names are defined
      in include/ nux/iio/timer/stm32-timer-trigger.h and is_stm32_iio_timer_trigger
      function could be used to check if the trigger is valid or not.
      
      "trgo" trigger have a "sampling_frequency" attribute which allow to configure
      timer sampling frequency.
      
      version 8:
      - change kernel version from 4.10 to 4.11 in ABI documentation
      
      version 7:
      - remove all iio_device related code
      - move driver into trigger directory
      
      version 5:
      - simplify tables of triggers
      - only create an IIO device when needed
      
      version 4:
      - get triggers configuration from "reg" in DT
      - add tables of triggers
      - sampling frequency is enable/disable when writing in trigger
        sampling_frequency attribute
      - no more use of interruptions
      
      version 3:
      - change compatible to "st,stm32-timer-trigger"
      - fix attributes access right
      - use string instead of int for master_mode and slave_mode
      - document device attributes in sysfs-bus-iio-timer-stm32
      
      version 2:
      - keep only one compatible
      - use st,input-triggers-names and st,output-triggers-names
        to know which triggers are accepted and/or create by the device
      Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@st.com>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      93fbe91b
  22. 23 1月, 2017 1 次提交
  23. 19 1月, 2017 1 次提交
  24. 14 1月, 2017 2 次提交
  25. 05 1月, 2017 1 次提交
  26. 02 1月, 2017 1 次提交
  27. 31 12月, 2016 1 次提交
  28. 09 12月, 2016 1 次提交
  29. 06 12月, 2016 1 次提交