1. 28 8月, 2017 1 次提交
  2. 23 5月, 2017 1 次提交
  3. 12 4月, 2017 1 次提交
  4. 07 2月, 2017 1 次提交
  5. 14 12月, 2016 1 次提交
    • I
      s390/zcrypt: add multi domain support · e28d2af4
      Ingo Tuchscherer 提交于
      Currently the ap infrastructure only supports one domain at a time.
      This feature extends the generic cryptographic device driver to
      support multiple cryptographic domains simultaneously.
      
      There are now card and queue devices on the AP bus with independent
      card and queue drivers. The new /sys layout is as follows:
      
      /sys/bus/ap
          devices
              <xx>.<yyyy> -> ../../../devices/ap/card<xx>/<xx>.<yyyy>
              ...
              card<xx> -> ../../../devices/ap/card<xx>
              ...
          drivers
              <drv>card
                  card<xx> -> ../../../../devices/ap/card<xx>
              <drv>queue
                  <xx>.<yyyy> -> ../../../../devices/ap/card<xx>/<xx>.<yyyy>
                  ...
      
      /sys/devices/ap
          card<xx>
              <xx>.<yyyy>
                  driver -> ../../../../bus/ap/drivers/<zzz>queue
                  ...
              driver -> ../../../bus/ap/drivers/<drv>card
              ...
      
      The two digit <xx> field is the card number, the four digit <yyyy>
      field is the queue number and <drv> is the name of the device driver,
      e.g. "cex4".
      
      For compatability /sys/bus/ap/card<xx> for the old layout has to exist,
      including the attributes that used to reside there.
      
      With additional contributions from Harald Freudenberger and
      Martin Schwidefsky.
      Signed-off-by: NIngo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e28d2af4
  6. 27 6月, 2016 1 次提交
  7. 15 12月, 2015 1 次提交
  8. 20 10月, 2015 1 次提交
  9. 21 9月, 2015 2 次提交
  10. 07 8月, 2015 1 次提交
  11. 07 7月, 2015 1 次提交
    • S
      ACPI / scan: Add support for ACPI _CLS device matching · 26095a01
      Suthikulpanit, Suravee 提交于
      Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
      acpi_match_table to match devices. However, for generic drivers, we do not
      want to list _HID for all supported devices. Also, certain classes of devices
      do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
      which specifies PCI-defined class code (i.e. base-class, subclass and
      programming interface). This patch adds support for matching ACPI devices using
      the _CLS method.
      
      To support loadable module, current design uses _HID or _CID to match device's
      modalias. With the new way of matching with _CLS this would requires modification
      to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
      class-code to the existing ACPI modalias as following.
      
          acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
      E.g:
          # cat /sys/devices/platform/AMDI0600:00/modalias
          acpi:AMDI0600:010601:
      
      where bb is th base-class code, ss is te sub-class code, and pp is the
      programming interface code
      
      Since there would not be _HID/_CID in the ACPI matching table of the driver,
      this patch adds a field to acpi_device_id to specify the matching _CLS.
      
          static const struct acpi_device_id ahci_acpi_match[] = {
              { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
              {},
          };
      
      In this case, the corresponded entry in modules.alias file would be:
      
          alias acpi*:010601:* ahci_platform
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      26095a01
  12. 31 5月, 2015 1 次提交
  13. 25 5月, 2015 1 次提交
  14. 14 5月, 2015 1 次提交
    • H
      usb: add bus type for USB ULPI · 289fcff4
      Heikki Krogerus 提交于
      UTMI+ Low Pin Interface (ULPI) is a commonly used PHY
      interface for USB 2.0. The ULPI specification describes a
      standard set of registers which the vendors can extend for
      their specific needs. ULPI PHYs provide often functions
      such as charger detection and ADP sensing and probing.
      
      There are two major issues that the bus type is meant to
      tackle:
      
      Firstly, ULPI registers are accessed from the controller.
      The bus provides convenient method for the controller
      drivers to share that access with the actual PHY drivers.
      
      Secondly, there are already platforms that assume ULPI PHYs
      are runtime detected, such as many Intel Baytrail based
      platforms. They do not provide any kind of hardware
      description for the ULPI PHYs like separate ACPI device
      object that could be used to enumerate a device from.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: NDavid Cohen <david.a.cohen@linux.intel.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      289fcff4
  15. 31 3月, 2015 1 次提交
    • J
      MIPS: Add CDMM bus support · 8286ae03
      James Hogan 提交于
      Add MIPS Common Device Memory Map (CDMM) support in the form of a bus in
      the standard Linux device model. Each device attached via CDMM is
      discoverable via an 8-bit type identifier and may contain a number of
      blocks of memory mapped registers in the CDMM region. IRQs are expected
      to be handled separately.
      
      Due to the per-cpu (per-VPE for MT cores) nature of the CDMM devices,
      all the driver callbacks take place from workqueues which are run on the
      right CPU for the device in question, so that the driver doesn't need to
      be as concerned about which CPU it is running on. Callbacks also exist
      for when CPUs are taken offline, so that any per-CPU resources used by
      the driver can be disabled so they don't get forcefully migrated. CDMM
      devices are created as children of the CPU device they are attached to.
      
      Any existing CDMM configuration by the bootloader will be inherited,
      however platforms wishing to enable CDMM should implement the weak
      mips_cdmm_phys_base() function (see asm/cdmm.h) so that the bus driver
      knows where it should put the CDMM region in the physical address space
      if the bootloader hasn't already enabled it.
      
      A mips_cdmm_early_probe() function is also provided to allow early boot
      or particularly low level code to set up the CDMM region and probe for a
      specific device type, for example early console or KGDB IO drivers for
      the EJTAG Fast Debug Channel (FDC) CDMM device.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/9599/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8286ae03
  16. 07 3月, 2015 1 次提交
  17. 12 2月, 2015 2 次提交
  18. 04 2月, 2015 1 次提交
  19. 27 1月, 2015 1 次提交
  20. 29 10月, 2014 1 次提交
  21. 10 4月, 2014 1 次提交
    • B
      x86: LLVMLinux: Fix "incomplete type const struct x86cpu_device_id" · c4586256
      Behan Webster 提交于
      Similar to the fix in 40413dcb
      
      MODULE_DEVICE_TABLE(x86cpu, ...) expects the struct to be called struct
      x86cpu_device_id, and not struct x86_cpu_id which is what is used in the rest
      of the kernel code.  Although gcc seems to ignore this error, clang fails
      without this define to fix the name.
      
      Code from drivers/thermal/x86_pkg_temp_thermal.c
      static const struct x86_cpu_id __initconst pkg_temp_thermal_ids[] = { ... };
      MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids);
      
      Error from clang:
      drivers/thermal/x86_pkg_temp_thermal.c:577:1: error: variable has
            incomplete type 'const struct x86cpu_device_id'
      MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids);
      ^
      include/linux/module.h:145:3: note: expanded from macro
            'MODULE_DEVICE_TABLE'
        MODULE_GENERIC_TABLE(type##_device, name)
        ^
      include/linux/module.h:87:32: note: expanded from macro
            'MODULE_GENERIC_TABLE'
      extern const struct gtype##_id __mod_##gtype##_table            \
                                     ^
      <scratch space>:143:1: note: expanded from here
      __mod_x86cpu_device_table
      ^
      drivers/thermal/x86_pkg_temp_thermal.c:577:1: note: forward declaration of
            'struct x86cpu_device_id'
      include/linux/module.h:145:3: note: expanded from macro
            'MODULE_DEVICE_TABLE'
        MODULE_GENERIC_TABLE(type##_device, name)
        ^
      include/linux/module.h:87:21: note: expanded from macro
            'MODULE_GENERIC_TABLE'
      extern const struct gtype##_id __mod_##gtype##_table            \
                          ^
      <scratch space>:141:1: note: expanded from here
      x86cpu_device_id
      ^
      1 error generated.
      Signed-off-by: NBehan Webster <behanw@converseincode.com>
      Signed-off-by: NJan-Simon Möller <dl9pf@gmx.de>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4586256
  22. 01 3月, 2014 1 次提交
  23. 19 2月, 2014 1 次提交
    • A
      cpu: add generic support for CPU feature based module autoloading · 67bad2fd
      Ard Biesheuvel 提交于
      This patch adds support for advertising optional CPU features over udev
      using the modalias, and for declaring compatibility with/dependency upon
      such a feature in a module.
      
      The mapping between feature numbers and actual features should be provided
      by the architecture in a file called <asm/cpufeature.h> which exports the
      following functions/macros:
      - cpu_feature(FEAT), a preprocessor macro that maps token FEAT to a
        numeric index;
      - bool cpu_have_feature(n), returning whether this CPU has support for
        feature #n;
      - MAX_CPU_FEATURES, an upper bound for 'n' in the previous function.
      
      The feature can then be enabled by setting CONFIG_GENERIC_CPU_AUTOPROBE
      for the architecture.
      
      For instance, a module that registers its module init function using
      
        module_cpu_feature_match(FEAT_X, module_init_function)
      
      will be probed automatically when the CPU's support for the 'FEAT_X'
      feature is advertised over udev, and will only allow the module to be
      loaded by hand if the 'FEAT_X' feature is supported.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67bad2fd
  24. 16 2月, 2014 1 次提交
  25. 08 9月, 2013 1 次提交
  26. 04 9月, 2013 1 次提交
  27. 19 7月, 2013 1 次提交
    • A
      ssb: fix alignment of struct bcma_device_id · b01a60be
      Arnd Bergmann 提交于
      The ARM OABI and EABI disagree on the alignment of structures
      with small members, so module init tools may interpret the
      ssb device table incorrectly, as shown  by this warning when
      building the b43 device driver in an OABI kernel:
      
      FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
      not a modulo of the size of section __mod_ssb_device_table=88.
      
      Forcing the default (EABI) alignment on the structure makes this
      problem go away. Since the ssb_device_id may have the same problem,
      better fix both structures.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Michael Buesch <mb@bu3sch.de>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b01a60be
  28. 04 7月, 2013 2 次提交
  29. 29 3月, 2013 1 次提交
  30. 25 1月, 2013 1 次提交
  31. 11 9月, 2012 1 次提交
  32. 07 9月, 2012 1 次提交
  33. 05 9月, 2012 1 次提交
  34. 19 6月, 2012 1 次提交
  35. 14 6月, 2012 1 次提交
    • B
      USB: allow match on bInterfaceNumber · 81df2d59
      Bjørn Mork 提交于
      Some composite USB devices provide multiple interfaces
      with different functions, all using "vendor-specific"
      for class/subclass/protocol.  Another OS use interface
      numbers to match the driver and interface. It seems
      these devices are designed with that in mind - using
      static interface numbers for the different functions.
      
      This adds support for matching against the
      bInterfaceNumber, allowing such devices to be supported
      without having to resort to testing against interface
      number whitelists and/or blacklists in the probe.
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81df2d59
  36. 01 5月, 2012 2 次提交