27 Nov, 2011

1 commit

  • Move the "Device Drivers/Microsoft Hyper-V guest support"
    menu entry up such that it appears immediately below virtio
    (KVM and lguest guest driver support) instead of after a
    hypervisor driver menu entry.

    Signed-off-by: Bart Van Assche
    Cc: Greg Kroah-Hartman
    Cc: James Bottomley
    Cc: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Bart Van Assche
     

26 Oct, 2011

1 commit

  • * 'staging-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (1519 commits)
    staging: et131x: Remove redundant check and return statement
    staging: et131x: Mainly whitespace changes to appease checkpatch
    staging: et131x: Remove last of the forward declarations
    staging: et131x: Remove even more forward declarations
    staging: et131x: Remove yet more forward declarations
    staging: et131x: Remove more forward declarations
    staging: et131x: Remove forward declaration of et131x_adapter_setup
    staging: et131x: Remove some forward declarations
    staging: et131x: Remove unused rx_ring.recv_packet_pool
    staging: et131x: Remove call to find pci pm capability
    staging: et131x: Remove redundant et131x_reset_recv() call
    staging: et131x: Remove unused rx_ring.recv_buffer_pool
    Staging: bcm: Fix three initialization errors in InterfaceDld.c
    Staging: bcm: Fix coding style issues in InterfaceDld.c
    staging:iio:dac: Add AD5360 driver
    staging:iio:trigger:bfin-timer: Fix compile error
    Staging: vt6655: add some range checks before memcpy()
    Staging: vt6655: whitespace fixes to iotcl.c
    Staging: vt6656: add some range checks before memcpy()
    Staging: vt6656: whitespace cleanups in ioctl.c
    ...

    Fix up conflicts in:
    - drivers/{Kconfig,Makefile}, drivers/staging/{Kconfig,Makefile}:
    vg driver movement
    - drivers/staging/brcm80211/brcmfmac/{dhd_linux.c,mac80211_if.c}:
    driver removal vs now stale changes
    - drivers/staging/rtl8192e/r8192E_core.c:
    driver removal vs now stale changes
    - drivers/staging/et131x/et131*:
    driver consolidation into one file, tried to do fixups

    Linus Torvalds
     

25 Oct, 2011

1 commit

  • * 'pm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits)
    PM / Clocks: Remove redundant NULL checks before kfree()
    PM / Documentation: Update docs about suspend and CPU hotplug
    ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist.
    ARM: mach-shmobile: sh7372 A4R support (v4)
    ARM: mach-shmobile: sh7372 A3SP support (v4)
    PM / Sleep: Mark devices involved in wakeup signaling during suspend
    PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
    PM / Hibernate: Do not initialize static and extern variables to 0
    PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too
    PM / Hibernate: Add resumedelay kernel param in addition to resumewait
    MAINTAINERS: Update linux-pm list address
    PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs
    PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs
    PM / Hibernate: Add resumewait param to support MMC-like devices as resume file
    PM / Hibernate: Fix typo in a kerneldoc comment
    PM / Hibernate: Freeze kernel threads after preallocating memory
    PM: Update the policy on default wakeup settings
    PM / VT: Cleanup #if defined uglyness and fix compile error
    PM / Suspend: Off by one in pm_suspend()
    PM / Hibernate: Include storage keys in hibernation image on s390
    ...

    Linus Torvalds
     

13 Oct, 2011

1 commit

  • This creates a subsystem for handling of pin control devices.
    These are devices that control different aspects of package
    pins.

    Currently it handles pinmuxing, i.e. assigning electronic
    functions to groups of pins on primarily PGA and BGA type of
    chip packages which are common in embedded systems.

    The plan is to also handle other I/O pin control aspects
    such as biasing, driving, input properties such as
    schmitt-triggering, load capacitance etc within this
    subsystem, to remove a lot of ARM arch code as well as
    feature-creepy GPIO drivers which are implementing the same
    thing over and over again.

    This is being done to depopulate the arch/arm/* directory
    of such custom drivers and try to abstract the infrastructure
    they all need. See the Documentation/pinctrl.txt file that is
    part of this patch for more details.

    ChangeLog v1->v2:

    - Various minor fixes from Joe's and Stephens review comments
    - Added a pinmux_config() that can invoke custom configuration
    with arbitrary data passed in or out to/from the pinmux driver

    ChangeLog v2->v3:

    - Renamed subsystem folder to "pinctrl" since we will likely
    want to keep other pin control such as biasing in this
    subsystem too, so let us keep to something generic even though
    we're mainly doing pinmux now.
    - As a consequence, register pins as an abstract entity separate
    from the pinmux. The muxing functions will claim pins out of the
    pin pool and make sure they do not collide. Pins can now be
    named by the pinctrl core.
    - Converted the pin lookup from a static array into a radix tree,
    I agreed with Grant Likely to try to avoid any static allocation
    (which is crap for device tree stuff) so I just rewrote this
    to be dynamic, just like irq number descriptors. The
    platform-wide definition of number of pins goes away - this is
    now just the sum total of the pins registered to the subsystem.
    - Make sure mappings with only a function name and no device
    works properly.

    ChangeLog v3->v4:

    - Define a number space per controller instead of globally,
    Stephen and Grant requested the same thing so now maps need to
    define target controller, and the radix tree of pin descriptors
    is a property on each pin controller device.
    - Add a compulsory pinctrl device entry to the pinctrl mapping
    table. This must match the pinctrl device, like "pinctrl.0"
    - Split the file core.c in two: core.c and pinmux.c where the
    latter carry all pinmux stuff, the core is for generic pin
    control, and use local headers to access functionality between
    files. It is now possible to implement a "blank" pin controller
    without pinmux capabilities. This split will make new additions
    like pindrive.c, pinbias.c etc possible for combined drivers
    and chunks of functionality which is a GoodThing(TM).
    - Rewrite the interaction with the GPIO subsystem - the pin
    controller descriptor now handles this by defining an offset
    into the GPIO numberspace for its handled pin range. This is
    used to look up the apropriate pin controller for a GPIO pin.
    Then that specific GPIO range is matched 1-1 for the target
    controller instance.
    - Fixed a number of review comments from Joe Perches.
    - Broke out a header file pinctrl.h for the core pin handling
    stuff that will be reused by other stuff than pinmux.
    - Fixed some erroneous EXPORT() stuff.
    - Remove mispatched U300 Kconfig and Makefile entries
    - Fixed a number of review comments from Stephen Warren, not all
    of them - still WIP. But I think the new mapping that will
    specify which function goes to which pin mux controller address
    50% of your concerns (else beat me up).

    ChangeLog v4->v5:

    - Defined a "position" for each function, so the pin controller now
    tracks a function in a certain position, and the pinmux maps define
    what position you want the function in. (Feedback from Stephen
    Warren and Sascha Hauer).
    - Since we now need to request a combined function+position from
    the machine mapping table that connect mux settings to drivers,
    it was extended with a position field and a name field. The
    name field is now used if you e.g. need to switch between two
    mux map settings at runtime.
    - Switched from a class device to using struct bus_type for this
    subsystem. Verified sysfs functionality: seems to work fine.
    (Feedback from Arnd Bergmann and Greg Kroah-Hartman)
    - Define a per pincontroller list of GPIO ranges from the GPIO
    pin space that can be handled by the pin controller. These can
    be added one by one at runtime. (Feedback from Barry Song)
    - Expanded documentation of regulator_[get|enable|disable|put]
    semantics.
    - Fixed a number of review comments from Barry Song. (Thanks!)

    ChangeLog v5->v6:

    - Create an abstract pin group concept that can sort pins into
    named and enumerated groups no matter what the use of these
    groups may be, one possible usecase is a group of pins being
    muxed in or so. The intention is however to also use these
    groups for other pin control activities.
    - Make it compulsory for pinmux functions to associate with
    at least one group, so the abstract pin group concept is used
    to define the groups of pins affected by a pinmux function.
    The pinmux driver interface has been altered so as to enforce
    a function to list applicable groups per function.
    - Provide an optional .group entry in the pinmux machine map
    so the map can select beteween different available groups
    to be used with a certain function.
    - Consequent changes all over the place so that e.g. debugfs
    present reasonable information about the world.
    - Drop the per-pin mux (*config) function in the pinmux_ops
    struct - I was afraid that this would start to be used for
    things totally unrelated to muxing, we can introduce that to
    the generic struct pinctrl_ops if needed. I want to keep
    muxing orthogonal to other pin control subjects and not mix
    these things up.

    ChangeLog v6->v7:

    - Make it possible to have several map entries matching the
    same device, pin controller and function, but using
    a different group, and alter the semantics so that
    pinmux_get() will pick all matching map entries, and
    store the associated groups in a list. The list will
    then be iterated over at pinmux_enable()/pinmux_disable()
    and corresponding driver functions called for each
    defined group. Notice that you're only allowed to map
    multiple *groups* to the same
    { device, pin controller, function } triplet, attempts
    to map the same device to multiple pin controllers will
    for example fail. This is hopefully the crucial feature
    requested by Stephen Warren.
    - Add a pinmux hogging field to the pinmux mapping entries,
    and enable the pinmux core to hog pinmux map entries.
    This currently only works for pinmuxes without assigned
    devices as it looks now, but with device trees we can
    look up the corresponding struct device * entries when
    we register the pinmux driver, and have it hog each
    pinmux map in turn, for a simple approach to
    non-dynamic pin muxing. This addresses an issue from
    Grant Likely that the machine should take care of as
    much of the pinmux setup as possible, not the devices.
    By supplying a list of hogs, it can now instruct the
    core to take care of any static mappings.
    - Switch pinmux group retrieveal function to grab an
    array of strings representing the groups rather than an
    array of unsigned and rewrite accordingly.
    - Alter debugfs to show the grouplist handled by each
    pinmux. Also add a list of hogs.
    - Dynamically allocate a struct pinmux at pinmux_get() and
    free it at pinmux_put(), then add these to the global
    list of pinmuxes active as we go along.
    - Go over the list of pinmux maps at pinmux_get() time
    and repeatedly apply matches.
    - Retrieve applicable groups per function from the driver
    as a string array rather than a unsigned array, then
    lookup the enumerators.
    - Make the device to pinmux map a singleton - only allow the
    mapping table to be registered once and even tag the
    registration function with __init so it surely won't be
    abused.
    - Create a separate debugfs file to view the pinmux map at
    runtime.
    - Introduce a spin lock to the pin descriptor struct, lock it
    when modifying pin status entries. Reported by Stijn Devriendt.
    - Fix up the documentation after review from Stephen Warren.
    - Let the GPIO ranges give names as const char * instead of some
    fixed-length string.
    - add a function to unregister GPIO ranges to mirror the
    registration function.
    - Privatized the struct pinctrl_device and removed it from the
    API, the drivers do not need to know
    the members of this struct. It is now in the local header
    "core.h".
    - Rename the concept of "anonymous" mux maps to "system" muxes
    and add convenience macros and documentation.

    ChangeLog v7->v8:

    - Delete the leftover pinmux_config() function from the
    header.
    - Fix a race condition found by Stijn Devriendt in pin_request()

    ChangeLog v8->v9:

    - Drop the bus_type and the sysfs attributes and all, we're not on
    the clear about how this should be used for e.g. userspace
    interfaces so let us save this for the future.
    - Use the right name in MAINTAINERS, PIN CONTROL rather than
    PINMUX
    - Don't kfree() the device state holder, let the .remove() callback
    handle this.
    - Fix up numerous kerneldoc headers to have one line for the function
    description and more verbose documentation below the parameters

    ChangeLog v9->v10:
    - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
    from Steven Rothwell
    - fix pinctrl_register error handling, folded in a patch from
    Axel Lin
    - Various fixes to documentation text so that it's consistent.
    - Removed pointless comment from drivers/Kconfig
    - Removed dependency on SYSFS since we removed the bus in
    v9.
    - Renamed hopelessly abbreviated pctldev_* functions to the
    more verbose pinctrl_dev_*
    - Drop mutex properly when looking up GPIO ranges
    - Return NULL instead of ERR_PTR() errors on registration of
    pin controllers, using cast pointers is fragile. We can
    live without the detailed error codes for sure.

    Cc: Stijn Devriendt
    Cc: Joe Perches
    Cc: Russell King
    Acked-by: Grant Likely
    Acked-by: Stephen Warren
    Tested-by: Barry Song
    Signed-off-by: Linus Walleij

    Linus Walleij
     

11 Oct, 2011

1 commit

  • After many years wandering the desert, it is finally time for the
    Microsoft HyperV code to move out of the staging directory. Or at least
    the core hyperv bus code, and the utility driver, the rest still have
    some review to get through by the various subsystem maintainers.

    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: K. Y. Srinivasan

    Greg Kroah-Hartman
     

02 Oct, 2011

1 commit

  • With OPPs, a device may have multiple operable frequency and voltage
    sets. However, there can be multiple possible operable sets and a system
    will need to choose one from them. In order to reduce the power
    consumption (by reducing frequency and voltage) without affecting the
    performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
    scheme may be used.

    This patch introduces the DVFS capability to non-CPU devices with OPPs.
    DVFS is a techique whereby the frequency and supplied voltage of a
    device is adjusted on-the-fly. DVFS usually sets the frequency as low
    as possible with given conditions (such as QoS assurance) and adjusts
    voltage according to the chosen frequency in order to reduce power
    consumption and heat dissipation.

    The generic DVFS for devices, devfreq, may appear quite similar with
    /drivers/cpufreq. However, cpufreq does not allow to have multiple
    devices registered and is not suitable to have multiple heterogenous
    devices with different (but simple) governors.

    Normally, DVFS mechanism controls frequency based on the demand for
    the device, and then, chooses voltage based on the chosen frequency.
    devfreq also controls the frequency based on the governor's frequency
    recommendation and let OPP pick up the pair of frequency and voltage
    based on the recommended frequency. Then, the chosen OPP is passed to
    device driver's "target" callback.

    When PM QoS is going to be used with the devfreq device, the device
    driver should enable OPPs that are appropriate with the current PM QoS
    requests. In order to do so, the device driver may call opp_enable and
    opp_disable at the notifier callback of PM QoS so that PM QoS's
    update_target() call enables the appropriate OPPs. Note that at least
    one of OPPs should be enabled at any time; be careful when there is a
    transition.

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Kyungmin Park
    Reviewed-by: Mike Turquette
    Acked-by: Kevin Hilman
    Signed-off-by: Rafael J. Wysocki

    MyungJoo Ham
     

26 Jul, 2011

1 commit

  • * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (99 commits)
    drivers/virt: add missing linux/interrupt.h to fsl_hypervisor.c
    powerpc/85xx: fix mpic configuration in CAMP mode
    powerpc: Copy back TIF flags on return from softirq stack
    powerpc/64: Make server perfmon only built on ppc64 server devices
    powerpc/pseries: Fix hvc_vio.c build due to recent changes
    powerpc: Exporting boot_cpuid_phys
    powerpc: Add CFAR to oops output
    hvc_console: Add kdb support
    powerpc/pseries: Fix hvterm_raw_get_chars to accept < 16 chars, fixing xmon
    powerpc/irq: Quieten irq mapping printks
    powerpc: Enable lockup and hung task detectors in pseries and ppc64 defeconfigs
    powerpc: Add mpt2sas driver to pseries and ppc64 defconfig
    powerpc: Disable IRQs off tracer in ppc64 defconfig
    powerpc: Sync pseries and ppc64 defconfigs
    powerpc/pseries/hvconsole: Fix dropped console output
    hvc_console: Improve tty/console put_chars handling
    powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
    powerpc/mm: Fix output of total_ram.
    powerpc/cpufreq: Add cpufreq driver for Momentum Maple boards
    powerpc: Correct annotations of pmu registration functions
    ...

    Fix up trivial Kconfig/Makefile conflicts in arch/powerpc, drivers, and
    drivers/cpufreq

    Linus Torvalds
     

23 Jul, 2011

2 commits

  • virtio has been so far used only in the context of virtualization,
    and the virtio Kconfig was sourced directly by the relevant arch
    Kconfigs when VIRTUALIZATION was selected.

    Now that we start using virtio for inter-processor communications,
    we need to source the virtio Kconfig outside of the virtualization
    scope too.

    Moreover, some architectures might use virtio for both virtualization
    and inter-processor communications, so directly sourcing virtio
    might yield unexpected results due to conflicting selections.

    The simple solution offered by this patch is to always source virtio's
    Kconfig in drivers/Kconfig, and remove it from the appropriate arch
    Kconfigs. Additionally, a virtio menu entry has been added so virtio
    drivers don't show up in the general drivers menu.

    This way anyone can use virtio, though it's arguably less accessible
    (and neat!) for virtualization users now.

    Note: some architectures (mips and sh) seem to have a VIRTUALIZATION
    menu merely for sourcing virtio's Kconfig, so that menu is removed too.

    Signed-off-by: Ohad Ben-Cohen
    Signed-off-by: Rusty Russell

    Ohad Ben-Cohen
     
  • …/git/tip/linux-2.6-tip

    * 'core-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    iommu/core: Fix build with INTR_REMAP=y && CONFIG_DMAR=n
    iommu/amd: Don't use MSI address range for DMA addresses
    iommu/amd: Move missing parts to drivers/iommu
    iommu: Move iommu Kconfig entries to submenu
    x86/ia64: intel-iommu: move to drivers/iommu/
    x86: amd_iommu: move to drivers/iommu/
    msm: iommu: move to drivers/iommu/
    drivers: iommu: move to a dedicated folder
    x86/amd-iommu: Store device alias as dev_data pointer
    x86/amd-iommu: Search for existind dev_data before allocting a new one
    x86/amd-iommu: Allow dev_data->alias to be NULL
    x86/amd-iommu: Use only dev_data in low-level domain attach/detach functions
    x86/amd-iommu: Use only dev_data for dte and iotlb flushing routines
    x86/amd-iommu: Store ATS state in dev_data
    x86/amd-iommu: Store devid in dev_data
    x86/amd-iommu: Introduce global dev_data_list
    x86/amd-iommu: Remove redundant device_flush_dte() calls
    iommu-api: Add missing header file

    Fix up trivial conflicts (independent additions close to each other) in
    drivers/Makefile and include/linux/pci.h

    Linus Torvalds
     

08 Jul, 2011

2 commits


06 Jul, 2011

1 commit

  • The NFC subsystem core is responsible for providing the device driver
    interface. It is also responsible for providing an interface to the control
    operations and data exchange.

    Signed-off-by: Lauro Ramos Venancio
    Signed-off-by: Aloisio Almeida Jr
    Signed-off-by: Samuel Ortiz
    Signed-off-by: John W. Linville

    Lauro Ramos Venancio
     

14 Jun, 2011

1 commit

  • Create a dedicated folder for iommu drivers, and move the base
    iommu implementation over there.

    Grouping the various iommu drivers in a single location will help
    finding similar problems shared by different platforms, so they
    could be solved once, in the iommu framework, instead of solved
    differently (or duplicated) in each driver.

    Signed-off-by: Ohad Ben-Cohen
    Signed-off-by: Joerg Roedel

    Ohad Ben-Cohen
     

24 May, 2011

1 commit

  • This patch adds an infrastructure for hardware clocks that implement
    IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
    registration method to particular hardware clock drivers. Each clock is
    presented as a standard POSIX clock.

    The ancillary clock features are exposed in two different ways, via
    the sysfs and by a character device.

    Signed-off-by: Richard Cochran
    Acked-by: Arnd Bergmann
    Acked-by: David S. Miller
    Signed-off-by: John Stultz

    Richard Cochran
     

21 May, 2011

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1446 commits)
    macvlan: fix panic if lowerdev in a bond
    tg3: Add braces around 5906 workaround.
    tg3: Fix NETIF_F_LOOPBACK error
    macvlan: remove one synchronize_rcu() call
    networking: NET_CLS_ROUTE4 depends on INET
    irda: Fix error propagation in ircomm_lmp_connect_response()
    irda: Kill set but unused variable 'bytes' in irlan_check_command_param()
    irda: Kill set but unused variable 'clen' in ircomm_connect_indication()
    rxrpc: Fix set but unused variable 'usage' in rxrpc_get_transport()
    be2net: Kill set but unused variable 'req' in lancer_fw_download()
    irda: Kill set but unused vars 'saddr' and 'daddr' in irlan_provider_connect_indication()
    atl1c: atl1c_resume() is only used when CONFIG_PM_SLEEP is defined.
    rxrpc: Fix set but unused variable 'usage' in rxrpc_get_peer().
    rxrpc: Kill set but unused variable 'local' in rxrpc_UDP_error_handler()
    rxrpc: Kill set but unused variable 'sp' in rxrpc_process_connection()
    rxrpc: Kill set but unused variable 'sp' in rxrpc_rotate_tx_window()
    pkt_sched: Kill set but unused variable 'protocol' in tc_classify()
    isdn: capi: Use pr_debug() instead of ifdefs.
    tg3: Update version to 3.119
    tg3: Apply rx_discards fix to 5719/5720
    ...

    Fix up trivial conflicts in arch/x86/Kconfig and net/mac80211/agg-tx.c
    as per Davem.

    Linus Torvalds
     

14 May, 2011

1 commit


11 May, 2011

1 commit

  • Broadcom has released cards based on a new AMBA-based bus type. From a
    programming point of view, this new bus type differs from AMBA and does
    not use AMBA common registers. It also differs enough from SSB. We
    decided that a new bus driver is needed to keep the code clean.

    In its current form, the driver detects devices present on the bus and
    registers them in the system. It allows registering BCMA drivers for
    specified bus devices and provides them basic operations. The bus driver
    itself includes two important bus managing drivers: ChipCommon core
    driver and PCI(c) core driver. They are early used to allow correct
    initialization.

    Currently code is limited to supporting buses on PCI(e) devices, however
    the driver is designed to be used also on other hosts. The host
    abstraction layer is implemented and already used for PCI(e).

    Support for PCI(e) hosts is working and seems to be stable (access to
    80211 core was tested successfully on a few devices). We can still
    optimize it by using some fixed windows, but this can be done later
    without affecting any external code. Windows are just ranges in MMIO
    used for accessing cores on the bus.

    Cc: Greg KH
    Cc: Michael Büsch
    Cc: Larry Finger
    Cc: George Kashperko
    Cc: Arend van Spriel
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: Russell King
    Cc: Arnd Bergmann
    Cc: Andy Botting
    Cc: linuxdriverproject
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Rafał Miłecki
    Signed-off-by: John W. Linville

    Rafał Miłecki
     

18 Feb, 2011

1 commit

  • Add a platform-independent hwspinlock framework.

    Hardware spinlock devices are needed, e.g., in order to access data
    that is shared between remote processors, that otherwise have no
    alternative mechanism to accomplish synchronization and mutual exclusion
    operations.

    Signed-off-by: Ohad Ben-Cohen
    Cc: Hari Kanigeri
    Cc: Benoit Cousson
    Cc: Kevin Hilman
    Cc: Grant Likely
    Cc: Paul Walmsley
    Cc: Russell King
    Acked-by: Arnd Bergmann
    Signed-off-by: Tony Lindgren

    Ohad Ben-Cohen
     

15 Jan, 2011

1 commit

  • LIO target is a full featured in-kernel target framework with the
    following feature set:

    High-performance, non-blocking, multithreaded architecture with SIMD
    support.

    Advanced SCSI feature set:

    * Persistent Reservations (PRs)
    * Asymmetric Logical Unit Assignment (ALUA)
    * Protocol and intra-nexus multiplexing, load-balancing and failover (MC/S)
    * Full Error Recovery (ERL=0,1,2)
    * Active/active task migration and session continuation (ERL=2)
    * Thin LUN provisioning (UNMAP and WRITE_SAMExx)

    Multiprotocol target plugins

    Storage media independence:

    * Virtualization of all storage media; transparent mapping of IO to LUNs
    * No hard limits on number of LUNs per Target; maximum LUN size ~750 TB
    * Backstores: SATA, SAS, SCSI, BluRay, DVD, FLASH, USB, ramdisk, etc.

    Standards compliance:

    * Full compliance with IETF (RFC 3720)
    * Full implementation of SPC-4 PRs and ALUA

    Significant code cleanups done by Christoph Hellwig.

    [jejb: fix up for new block bdev exclusive interface. Minor fixes from
    Randy Dunlap and Dan Carpenter.]
    Signed-off-by: Nicholas A. Bellinger
    Signed-off-by: James Bottomley

    Nicholas Bellinger
     

14 Jan, 2011

1 commit

  • Creates a new "Near Field Communication" subsystem in drivers/nfc.
    http://en.wikipedia.org/wiki/Near_Field_Communication is useful ;)

    This is a driver for the pn544 NFC device. The driver transfers
    ETSI messages between the device and the user space.

    Signed-off-by: Matti J. Aaltonen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matti J. Aaltonen
     

26 Nov, 2010

1 commit


07 Mar, 2010

1 commit

  • Move the CS5535 MFGPT hrtimer kconfig option to be with the other MFGPT
    options. This makes it easier to find and also removes it from the main
    "Device Drivers" menu, where it should not have been.

    Signed-off-by: Randy Dunlap
    Acked-by: Andres Salomon
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

30 Dec, 2009

1 commit

  • Update the Kconfig help texts of both stacks to encourage a general move
    from the older to the newer drivers. However, do not label ieee1394 as
    "Obsolete" yet, as the newer drivers have not been deployed as default
    stack in the majority of Linux distributions yet, and those who start
    doing so now may still want to install the old drivers as fallback for
    unforeseen issues.

    Since Linux 2.6.32, FireWire audio devices can be driven by the newer
    firewire driver stack too, hence remove an outdated comment about audio
    devices. Also remove comments about library versions since the 2nd
    generation of libraw1394 and libdc1394 is now in common use; details on
    library versions can be read at the wiki link from the help texts.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

16 Dec, 2009

1 commit

  • This is based on the old code in arch/x86/kernel/mfgpt_32.c, but is
    modular and not Geode-specific. There's no reason why the clock event
    device needs to be registered so early at boot; the clockevent code is
    perfectly capable of dynamic switching.

    [akpm@linux-foundation.org: add linux/irq.h include]
    Signed-off-by: Andres Salomon
    Cc: Jordan Crouse
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: john stultz
    Cc: Chris Ball
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andres Salomon
     

09 Nov, 2009

1 commit


19 Jun, 2009

1 commit

  • This patch adds the kernel side of the PPS support currently named
    "LinuxPPS".

    PPS means "pulse per second" and a PPS source is just a device which
    provides a high precision signal each second so that an application can
    use it to adjust system clock time.

    Common use is the combination of the NTPD as userland program with a GPS
    receiver as PPS source to obtain a wallclock-time with sub-millisecond
    synchronisation to UTC.

    To obtain this goal the userland programs shoud use the PPS API
    specification (RFC 2783 - Pulse-Per-Second API for UNIX-like Operating
    Systems, Version 1.0) which in part is implemented by this patch. It
    provides a set of chars devices, one per PPS source, which can be used to
    get the time signal. The RFC's functions can be implemented by accessing
    to these char devices.

    Signed-off-by: Rodolfo Giometti
    Cc: David Woodhouse
    Cc: Greg KH
    Cc: Randy Dunlap
    Cc: Kay Sievers
    Acked-by: Alan Cox
    Cc: Michael Kerrisk
    Cc: Christoph Hellwig
    Cc: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rodolfo Giometti
     

17 Jun, 2009

1 commit

  • Add support for the TI VLYNQ high-speed, serial and packetized bus.

    This bus allows external devices to be connected to the System-on-Chip and
    appear in the main system memory just like any memory mapped peripheral.
    It is widely used in TI's networking and multimedia SoC, including the AR7
    SoC.

    Signed-off-by: Eugene Konev
    Signed-off-by: Florian Fainelli
    Cc: Ralf Baechle
    Cc: Alan Cox
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Florian Fainelli
     

19 Dec, 2008

1 commit

  • Move x86 platform specific drivers from drivers/misc/
    to a new home under drivers/platform/x86/.

    The community has been maintaining x86 vendor-specific
    platform specific drivers under /drivers/misc/ for a few years.
    The oldest ones started life under drivers/acpi.
    They moved out of drivers/acpi/ because they don't actually
    implement the ACPI specification, but either simply
    use ACPI, or implement vendor-specific ACPI extensions.

    In the future we anticipate...
    drivers/misc/ will go away.
    other architectures will create drivers/platform/

    Signed-off-by: Len Brown

    Len Brown
     

29 Oct, 2008

1 commit

  • When the regulator API was merged it was added to the separate Kconfig
    which ARM uses for drivers but not the generic one in drivers/. Since
    there is nothing ARM-specific about the API add it there too.

    Signed-off-by: Mark Brown
    Signed-off-by: Liam Girdwood

    Mark Brown
     

20 Oct, 2008

1 commit


11 Oct, 2008

1 commit


17 Sep, 2008

1 commit


30 Apr, 2008

1 commit

  • This adds a minimalistic braille screen reader support. This is meant to
    be used by blind people e.g. on boot failures or when / cannot be mounted
    etc and thus the userland screen readers can not work.

    [akpm@linux-foundation.org: fix exports]
    Signed-off-by: Samuel Thibault
    Cc: Jiri Kosina
    Cc: Dmitry Torokhov
    Acked-by: Alan Cox
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Samuel Thibault
     

25 Apr, 2008

1 commit

  • The balloon driver allows memory to be dynamically added or removed from the domain,
    in order to allow host memory to be balanced between multiple domains.

    This patch introduces the Xen balloon driver, though it currently only
    allows a domain to be shrunk from its initial size (and re-grown back to
    that size). A later patch will add the ability to grow a domain beyond
    its initial size.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Jeremy Fitzhardinge
     

10 Feb, 2008

1 commit

  • Sony MemoryStick cards are used in many products manufactured by Sony.
    They are available both as storage and as IO expansion cards. Currently,
    only MemoryStick Pro storage cards are supported via TI FlashMedia
    MemoryStick interface.

    [mboton@gmail.com: biuld fix]
    [akpm@linux-foundation.org: build fix]
    Signed-off-by: Alex Dubov
    Signed-off-by: Miguel Boton
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alex Dubov
     

07 Feb, 2008

1 commit


06 Feb, 2008

1 commit

  • Add an empty drivers/gpio directory for gpiolib infrastructure and GPIO
    expanders. It will be populated by later patches.

    This won't be the only place to hold such gpio_chip code. Many external chips
    add a few GPIOs as secondary functionality (such as MFD drivers) and platform
    code frequently needs to closely integrate GPIO and IRQ support.

    This is placed *early* in the build/link sequence since it's common for other
    drivers to depend on GPIOs to do their work, so they must be initialized early
    in the device_initcall() sequence.

    Signed-off-by: David Brownell
    Acked-by: Jean Delvare
    Cc: Eric Miao
    Cc: Sam Ravnborg
    Cc: Haavard Skinnemoen
    Cc: Philipp Zabel
    Cc: Russell King
    Cc: Ben Gardner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

04 Feb, 2008

1 commit


02 Feb, 2008

1 commit


31 Jan, 2008

1 commit