1. 28 5月, 2014 3 次提交
  2. 23 5月, 2014 2 次提交
  3. 14 5月, 2014 4 次提交
    • A
      usb: gadget: configfs: OS Extended Properties descriptors support · 7419485f
      Andrzej Pietrasiewicz 提交于
      Add handling of OS Extended Properties descriptors from configfs interface.
      One kind of "OS Descriptors" are "Extended Properties" descriptors, which
      need to be specified per interface or per group of interfaces described
      by an IAD. This patch adds support for creating subdirectories
      in interface.<n> directory located in the function's directory.
      Names of subdirectories created become names of properties.
      Each property contains two attributes: "type" and "data".
      The type can be a numeric value 1..7 while data is a blob interpreted
      depending on the type specified.
      The types are:
      1 - unicode string
      2 - unicode string with environment variables
      3 - binary
      4 - little-endian 32-bit
      5 - big-endian 32-bit
      6 - unicode string with a symbolic link
      7 - multiple unicode strings
      Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7419485f
    • A
      usb: gadget: configfs: OS Extended Compatibility descriptors support · da424314
      Andrzej Pietrasiewicz 提交于
      Add handling of OS Extended Compatibility descriptors from configfs interface.
      Hosts which expect the "OS Descriptors" ask only for configurations @ index 0,
      but linux-based USB devices can provide more than one configuration.
      This patch adds marking one of gadget's configurations the configuration
      to be reported at index 0, regardless of the actual sequence of usb_add_config
      invocations used for adding the configurations. The configuration is selected
      by creating a symbolic link pointing to it from the "os_desc" directory
      located at the top of a gadget's directory hierarchy.
      
      One kind of "OS Descriptors" are "Extended Compatibility Descriptors",
      which need to be specified per interface. This patch adds interface.<n>
      directory in function's configfs directory to represent each interface
      defined by the function. Each interface's directory contains two attributes:
      "compatible_id" and "sub_compatible_id", which represent 8-byte
      strings to be reported to the host as the "Compatible ID" and "Sub Compatible
      ID".
      Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      da424314
    • A
      usb: gadget: configfs: OS String support · 87213d38
      Andrzej Pietrasiewicz 提交于
      Add handling of OS String extension from the configfs interface.
      A directory "os_desc" is added at the top level of a gadget's
      directories hierarchy. In the "os_desc" directory there are
      three attributes: "use", "b_vendor_code" and "qw_sign".
      If "use" contains "0" the OS string is not reported to the host.
      "b_vendor_code" contains a one-byte value which is used
      for custom per-device and per-interface requests.
      "qw_sign" contains an identifier to be reported as the "OS String"
      proper.
      Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      87213d38
    • M
      Documentation: dt: Add new compatible for the A31 USB Phy · fecc2d78
      Maxime Ripard 提交于
      Document the freshly introduced compatible for the USB phy in use in the
      Allwinner A31 SoC.
      Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      fecc2d78
  4. 13 5月, 2014 2 次提交
  5. 08 5月, 2014 1 次提交
  6. 06 5月, 2014 1 次提交
  7. 04 5月, 2014 1 次提交
  8. 01 5月, 2014 3 次提交
  9. 29 4月, 2014 1 次提交
    • L
      clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue · 82a56194
      Lorenzo Pieralisi 提交于
      ARM arch timers are tightly coupled with the CPU logic and lose context
      on platform implementing HW power management when cores are powered
      down at run-time. Marking the arch timers as C3STOP regardless of power
      management capabilities causes issues on platforms with no power management,
      since in that case the arch timers cannot possibly enter states where the
      timer loses context at runtime and therefore can always be used as a high
      resolution clockevent device.
      
      In order to fix the C3STOP issue in a way compliant with how real HW
      works, this patch adds a boolean property to the arch timer bindings
      to define if the arch timer is managed by an always-on power domain.
      
      This power domain is present on all ARM platforms to date, and manages
      HW that must not be turned off, whatever the state of other HW
      components (eg power controller). On platforms with no power management
      capabilities, it is the only power domain present, which encompasses
      and manages power supply for all HW components in the system.
      
      If the timer is powered by the always-on power domain, the always-on
      property must be present in the bindings which means that the timer cannot
      be shutdown at runtime, so it is not a C3STOP clockevent device.
      If the timer binding does not contain the always-on property, the timer is
      assumed to be power-gateable, hence it must be defined as a C3STOP
      clockevent device.
      
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Magnus Damm <damm@opensource.se>
      Cc: Marc Carino <marc.ceeeee@gmail.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      82a56194
  10. 28 4月, 2014 1 次提交
  11. 25 4月, 2014 2 次提交
  12. 24 4月, 2014 1 次提交
  13. 23 4月, 2014 1 次提交
  14. 22 4月, 2014 1 次提交
  15. 19 4月, 2014 1 次提交
    • T
      Documentation/vm/numa_memory_policy.txt: fix wrong document in numa_memory_policy.txt · 8f28ed92
      Tang Chen 提交于
      In document numa_memory_policy.txt, the following examples for flag
      MPOL_F_RELATIVE_NODES are incorrect.
      
      	For example, consider a task that is attached to a cpuset with
      	mems 2-5 that sets an Interleave policy over the same set with
      	MPOL_F_RELATIVE_NODES.  If the cpuset's mems change to 3-7, the
      	interleave now occurs over nodes 3,5-6.  If the cpuset's mems
      	then change to 0,2-3,5, then the interleave occurs over nodes
      	0,3,5.
      
      According to the comment of the patch adding flag MPOL_F_RELATIVE_NODES,
      the nodemasks the user specifies should be considered relative to the
      current task's mems_allowed.
      
       (https://lkml.org/lkml/2008/2/29/428)
      
      And according to numa_memory_policy.txt, if the user's nodemask includes
      nodes that are outside the range of the new set of allowed nodes, then
      the remap wraps around to the beginning of the nodemask and, if not
      already set, sets the node in the mempolicy nodemask.
      
      So in the example, if the user specifies 2-5, for a task whose
      mems_allowed is 3-7, the nodemasks should be remapped the third, fourth,
      fifth, sixth node in mems_allowed.  like the following:
      
      	mems_allowed:       3  4  5  6  7
      
      	relative index:     0  1  2  3  4
      	                    5
      
      So the nodemasks should be remapped to 3,5-7, but not 3,5-6.
      
      And for a task whose mems_allowed is 0,2-3,5, the nodemasks should be
      remapped to 0,2-3,5, but not 0,3,5.
      
      	mems_allowed:       0  2  3  5
      
              relative index:     0  1  2  3
                                  4  5
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f28ed92
  16. 18 4月, 2014 2 次提交
  17. 17 4月, 2014 8 次提交
  18. 15 4月, 2014 5 次提交