23 Feb, 2017

1 commit


27 Oct, 2016

1 commit

  • The current state of driver removal is not great.
    CONFIG_DEBUG_TEST_DRIVER_REMOVE finds lots of errors. The help text
    currently undersells exactly how many errors this option will find. Add
    a bit more description to indicate this option shouldn't be turned on
    unless you actually want to debug driver removal. The text can be
    changed later when more drivers are fixed up.

    Signed-off-by: Laura Abbott
    Signed-off-by: Greg Kroah-Hartman

    Laura Abbott
     

31 Aug, 2016

1 commit

  • In recent discussions on ksummit-discuss[1], it was suggested to do a
    sequence of probe, remove, probe for testing driver remove paths. This
    adds a kconfig option for said test.

    [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

    Suggested-by: Arnd Bergmann
    Cc: Greg Kroah-Hartman
    Signed-off-by: Rob Herring
    Signed-off-by: Greg Kroah-Hartman

    Rob Herring
     

11 Dec, 2014

1 commit

  • This makes CMA memory area size zero for x86 in default configuration
    (doesn't change on the other architectures). If default CMA size is
    zero, DMA_CMA is disabled. It can be enabled by passing cma= to the
    kernel.

    This makes less impact on x86. Because there is no mainline driver that
    requires it for x86, and Peter Hurley reported the performance
    regression, as this is trying to drive _all_ dma mapping allocations
    through a _very_ small window.

    Signed-off-by: Akinobu Mita
    Reported-by: Peter Hurley
    Cc: Peter Hurley
    Cc: Chuck Ebbert
    Cc: Jean Delvare
    Acked-by: Marek Szyprowski
    Cc: Konrad Rzeszutek Wilk
    Cc: David Woodhouse
    Cc: Don Dutile
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: Andi Kleen
    Cc: Yinghai Lu
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

08 Nov, 2014

2 commits

  • The ENABLE_DEV_COREDUMP option is misleading as it implies that
    it gets the framework enabled, this isn't true it just allows it
    to get enabled if a driver needs it.

    Rename it to ALLOW_DEV_COREDUMP to better capture its semantics.

    Signed-off-by: Johannes Berg
    Reviewed-by: Josh Triplett
    Acked-by: Aristeu Rozanski
    Signed-off-by: Greg Kroah-Hartman

    Johannes Berg
     
  • It's desirable for allnconfig and tinyconfig targets to result in the
    least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to
    switch off DEV_COREDUMP regardless if any drivers select
    WANT_DEV_COREDUMP.

    This patch renames the option to ENABLE_DEV_COREDUMP and setting it to
    'n' (as in allnconfig or tinyconfig) will effectively disable device
    coredump.

    Cc: Josh Triplett
    Reviewed-by: Josh Triplett
    Signed-off-by: Aristeu Rozanski
    Reviewed-by: Johannes Berg
    Acked-by: Johannes Berg
    Signed-off-by: Greg Kroah-Hartman

    Aristeu Rozanski
     

10 Oct, 2014

1 commit

  • It isn't obvious that CMA can be disabled on the kernel's command line, so
    document it.

    Signed-off-by: Jean Delvare
    Cc: Joonsoo Kim
    Cc: Greg Kroah-Hartman
    Cc: Akinobu Mita
    Cc: Chuck Ebbert
    Cc: Marek Szyprowski
    Cc: Konrad Rzeszutek Wilk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     

24 Sep, 2014

1 commit

  • Many devices run firmware and/or complex hardware, and most of that
    can have bugs. When it misbehaves, however, it is often much harder
    to debug than software running on the host.

    Introduce a "device coredump" mechanism to allow dumping internal
    device/firmware state through a generalized mechanism. As devices
    are different and information needed can vary accordingly, this
    doesn't prescribe a file format - it just provides mechanism to
    get data to be able to capture it in a generalized way (e.g. in
    distributions.)

    The dumped data will be readable in sysfs in the virtual device's
    data file under /sys/class/devcoredump/devcd*/. Writing to it will
    free the data and remove the device, as does a 5-minute timeout.

    Note that generalized capturing of such data may result in privacy
    issues, so users generally need to be involved. In order to allow
    certain users/system integrators/... to disable the feature at all,
    introduce a Kconfig option to override the drivers that would like
    to have the feature.

    For now, this provides two ways of dumping data:
    1) with a vmalloc'ed area, that is then given to the subsystem
    and freed after retrieval or timeout
    2) with a generalized reader/free function method

    We could/should add more options, e.g. a list of pages, since the
    vmalloc area is very limited on some architectures.

    Signed-off-by: Johannes Berg
    Signed-off-by: Greg Kroah-Hartman

    Johannes Berg
     

07 Aug, 2014

1 commit

  • Currently, there are two users on CMA functionality, one is the DMA
    subsystem and the other is the KVM on powerpc. They have their own code
    to manage CMA reserved area even if they looks really similar. From my
    guess, it is caused by some needs on bitmap management. KVM side wants
    to maintain bitmap not for 1 page, but for more size. Eventually it use
    bitmap where one bit represents 64 pages.

    When I implement CMA related patches, I should change those two places
    to apply my change and it seem to be painful to me. I want to change
    this situation and reduce future code management overhead through this
    patch.

    This change could also help developer who want to use CMA in their new
    feature development, since they can use CMA easily without copying &
    pasting this reserved area management code.

    In previous patches, we have prepared some features to generalize CMA
    reserved area management and now it's time to do it. This patch moves
    core functions to mm/cma.c and change DMA APIs to use these functions.

    There is no functional change in DMA APIs.

    Signed-off-by: Joonsoo Kim
    Acked-by: Michal Nazarewicz
    Acked-by: Zhang Yanfei
    Acked-by: Minchan Kim
    Reviewed-by: Aneesh Kumar K.V
    Cc: Alexander Graf
    Cc: Aneesh Kumar K.V
    Cc: Gleb Natapov
    Acked-by: Marek Szyprowski
    Tested-by: Marek Szyprowski
    Cc: Paolo Bonzini
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joonsoo Kim
     

09 Jul, 2014

2 commits

  • [The patch was originally proposed by Tom Gundersen, and rewritten
    afterwards by me; most of changelogs below borrowed from Tom's
    original patch -- tiwai]

    Currently (at least) the dell-rbu driver selects FW_LOADER_USER_HELPER,
    which means that distros can't really stop loading firmware through
    udev without breaking other users (though some have).

    Ideally we would remove/disable the udev firmware helper in both the
    kernel and in udev, but if we were to disable it in udev and not the
    kernel, the result would be (seemingly) hung kernels as no one would
    be around to cancel firmware requests.

    This patch allows udev firmware loading to be disabled while still
    allowing non-udev firmware loading, as done by the dell-rbu driver, to
    continue working. This is achieved by only using the fallback
    mechanism when the uevent is suppressed.

    The patch renames the user-selectable Kconfig from FW_LOADER_USER_HELPER
    to FW_LOADER_USER_HELPER_FALLBACK, and the former is reverse-selected
    by the latter or the drivers that need userhelper like dell-rbu.

    Also, the "default y" is removed together with this change, since it's
    been deprecated in udev upstream, thus rather better to disable it
    nowadays.

    Tested with
    FW_LOADER_USER_HELPER=n
    LATTICE_ECP3_CONFIG=y
    DELL_RBU=y
    and udev without the firmware loading support, but I don't have the
    hardware to test the lattice/dell drivers, so additional testing would
    be appreciated.

    Reviewed-by: Tom Gundersen
    Cc: Ming Lei
    Cc: Abhay Salunke
    Cc: Stefan Roese
    Cc: Arnd Bergmann
    Cc: Kay Sievers
    Tested-by: Balaji Singh
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • A fence can be attached to a buffer which is being filled or consumed
    by hw, to allow userspace to pass the buffer without waiting to another
    device. For example, userspace can call page_flip ioctl to display the
    next frame of graphics after kicking the GPU but while the GPU is still
    rendering. The display device sharing the buffer with the GPU would
    attach a callback to get notified when the GPU's rendering-complete IRQ
    fires, to update the scan-out address of the display, without having to
    wake up userspace.

    A driver must allocate a fence context for each execution ring that can
    run in parallel. The function for this takes an argument with how many
    contexts to allocate:
    + fence_context_alloc()

    A fence is transient, one-shot deal. It is allocated and attached
    to one or more dma-buf's. When the one that attached it is done, with
    the pending operation, it can signal the fence:
    + fence_signal()

    To have a rough approximation whether a fence is fired, call:
    + fence_is_signaled()

    The dma-buf-mgr handles tracking, and waiting on, the fences associated
    with a dma-buf.

    The one pending on the fence can add an async callback:
    + fence_add_callback()

    The callback can optionally be cancelled with:
    + fence_remove_callback()

    To wait synchronously, optionally with a timeout:
    + fence_wait()
    + fence_wait_timeout()

    When emitting a fence, call:
    + trace_fence_emit()

    To annotate that a fence is blocking on another fence, call:
    + trace_fence_annotate_wait_on(fence, on_fence)

    A default software-only implementation is provided, which can be used
    by drivers attaching a fence to a buffer when they have no other means
    for hw sync. But a memory backed fence is also envisioned, because it
    is common that GPU's can write to, or poll on some memory location for
    synchronization. For example:

    fence = custom_get_fence(...);
    if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
    dma_buf *fence_buf = seqno_fence->sync_buf;
    get_dma_buf(fence_buf);

    ... tell the hw the memory location to wait ...
    custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
    } else {
    /* fall-back to sw sync * /
    fence_add_callback(fence, my_cb);
    }

    On SoC platforms, if some other hw mechanism is provided for synchronizing
    between IP blocks, it could be supported as an alternate implementation
    with it's own fence ops in a similar way.

    enable_signaling callback is used to provide sw signaling in case a cpu
    waiter is requested or no compatible hardware signaling could be used.

    The intention is to provide a userspace interface (presumably via eventfd)
    later, to be used in conjunction with dma-buf's mmap support for sw access
    to buffers (or for userspace apps that would prefer to do their own
    synchronization).

    v1: Original
    v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
    that dma-fence didn't need to care about the sw->hw signaling path
    (it can be handled same as sw->sw case), and therefore the fence->ops
    can be simplified and more handled in the core. So remove the signal,
    add_callback, cancel_callback, and wait ops, and replace with a simple
    enable_signaling() op which can be used to inform a fence supporting
    hw->hw signaling that one or more devices which do not support hw
    signaling are waiting (and therefore it should enable an irq or do
    whatever is necessary in order that the CPU is notified when the
    fence is passed).
    v3: Fix locking fail in attach_fence() and get_fence()
    v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
    we decided that we need to be able to attach one fence to N dma-buf's,
    so using the list_head in dma-fence struct would be problematic.
    v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
    v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
    about checking if fence fired or not. This is broken by design.
    waitqueue_active during destruction is now fatal, since the signaller
    should be holding a reference in enable_signalling until it signalled
    the fence. Pass the original dma_fence_cb along, and call __remove_wait
    in the dma_fence_callback handler, so that no cleanup needs to be
    performed.
    v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
    fence wasn't signaled yet, for example for hardware fences that may
    choose to signal blindly.
    v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
    header and fixed include mess. dma-fence.h now includes dma-buf.h
    All members are now initialized, so kmalloc can be used for
    allocating a dma-fence. More documentation added.
    v9: Change compiler bitfields to flags, change return type of
    enable_signaling to bool. Rework dma_fence_wait. Added
    dma_fence_is_signaled and dma_fence_wait_timeout.
    s/dma// and change exports to non GPL. Added fence_is_signaled and
    fence_enable_sw_signaling calls, add ability to override default
    wait operation.
    v10: remove event_queue, use a custom list, export try_to_wake_up from
    scheduler. Remove fence lock and use a global spinlock instead,
    this should hopefully remove all the locking headaches I was having
    on trying to implement this. enable_signaling is called with this
    lock held.
    v11:
    Use atomic ops for flags, lifting the need for some spin_lock_irqsaves.
    However I kept the guarantee that after fence_signal returns, it is
    guaranteed that enable_signaling has either been called to completion,
    or will not be called any more.

    Add contexts and seqno to base fence implementation. This allows you
    to wait for less fences, by testing for seqno + signaled, and then only
    wait on the later fence.

    Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
    An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
    spam, and another runtime option can turn it off at runtime.
    v12:
    Add CONFIG_FENCE_TRACE. Add missing documentation for the fence->context
    and fence->seqno members.
    v13:
    Fixup CONFIG_FENCE_TRACE kconfig description.
    Move fence_context_alloc to fence.
    Simplify fence_later.
    Kill priv member to fence_cb.
    v14:
    Remove priv argument from fence_add_callback, oops!
    v15:
    Remove priv from documentation.
    Explicitly include linux/atomic.h.
    v16:
    Add trace events.
    Import changes required by android syncpoints.
    v17:
    Use wake_up_state instead of try_to_wake_up. (Colin Cross)
    Fix up commit description for seqno_fence. (Rob Clark)
    v18:
    Rename release_fence to fence_release.
    Move to drivers/dma-buf/.
    Rename __fence_is_signaled and __fence_signal to *_locked.
    Rename __fence_init to fence_init.
    Make fence_default_wait return a signed long, and fix wait ops too.

    Signed-off-by: Maarten Lankhorst
    Signed-off-by: Thierry Reding #use smp_mb__before_atomic()
    Acked-by: Sumit Semwal
    Acked-by: Daniel Vetter
    Reviewed-by: Rob Clark
    Signed-off-by: Greg Kroah-Hartman

    Maarten Lankhorst
     

05 Jun, 2014

1 commit

  • Some systems require a larger maximum PAGE_SIZE order for CMA allocations.
    To accommodate such systems, increase the upper-bound of the
    CMA_ALIGNMENT range to 12 (which ends up being 16MB on systems with 4K
    pages).

    Signed-off-by: Marc Carino
    Cc: Marek Szyprowski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marc Carino
     

26 Apr, 2014

1 commit


19 Feb, 2014

2 commits

  • The x86 CPU feature modalias handling existed before it was reimplemented
    generically. This patch aligns the x86 handling so that it
    (a) reuses some more code that is now generic;
    (b) uses the generic format for the modalias module metadata entry, i.e., it
    now uses 'cpu:type:x86,venVVVVfamFFFFmodMMMM:feature:,XXXX,YYYY' instead of
    the 'x86cpu:vendor:VVVV:family:FFFF:model:MMMM:feature:,XXXX,YYYY' that was
    used before.

    Signed-off-by: Ard Biesheuvel
    Acked-by: H. Peter Anvin
    Signed-off-by: Greg Kroah-Hartman

    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 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: Ard Biesheuvel
    Signed-off-by: Greg Kroah-Hartman

    Ard Biesheuvel
     

19 Dec, 2013

1 commit


08 Jul, 2013

1 commit


02 Jul, 2013

1 commit

  • We want to use CMA for allocating hash page table and real mode area for
    PPC64. Hence move DMA contiguous related changes into a seperate config
    so that ppc64 can enable CMA without requiring DMA contiguous.

    Acked-by: Michal Nazarewicz
    Acked-by: Paul Mackerras
    Signed-off-by: Aneesh Kumar K.V
    [removed defconfig changes]
    Signed-off-by: Marek Szyprowski

    Aneesh Kumar K.V
     

04 Jun, 2013

1 commit

  • Ever since commit 45f035ab9b8f ("CONFIG_HOTPLUG should be always on"),
    it has been basically impossible to build a kernel with CONFIG_HOTPLUG
    turned off. Remove all the remaining references to it.

    Cc: Russell King
    Cc: Doug Thompson
    Cc: Bjorn Helgaas
    Cc: Steven Whitehouse
    Cc: Arnd Bergmann
    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Cc: Andrew Morton
    Signed-off-by: Stephen Rothwell
    Acked-by: Mauro Carvalho Chehab
    Acked-by: Hans Verkuil
    Signed-off-by: Greg Kroah-Hartman

    Stephen Rothwell
     

04 Feb, 2013

1 commit

  • This patch adds a new kconfig, CONFIG_FW_LOADER_USER_HELPER, and
    guards the user-helper codes in firmware_class.c with ifdefs.

    Yeah, yeah, there are lots of ifdefs in this patch. The further
    clean-up with code shuffling follows in the next.

    Acked-by: Ming Lei
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     

29 Oct, 2012

1 commit


26 Oct, 2012

1 commit

  • This config item has not carried much meaning for a while now and is
    almost always enabled by default. As agreed during the Linux kernel
    summit, remove it.

    CC: Greg Kroah-Hartman
    Signed-off-by: Kees Cook
    Signed-off-by: Greg Kroah-Hartman

    Kees Cook
     

23 Oct, 2012

1 commit


01 Aug, 2012

1 commit

  • mm/page_alloc.c has some memory isolation functions but they are used only
    when we enable CONFIG_{CMA|MEMORY_HOTPLUG|MEMORY_FAILURE}. So let's make
    it configurable by new CONFIG_MEMORY_ISOLATION so that it can reduce
    binary size and we can check it simple by CONFIG_MEMORY_ISOLATION, not if
    defined CONFIG_{CMA|MEMORY_HOTPLUG|MEMORY_FAILURE}.

    Signed-off-by: Minchan Kim
    Cc: Andi Kleen
    Cc: Marek Szyprowski
    Acked-by: KAMEZAWA Hiroyuki
    Cc: KOSAKI Motohiro
    Cc: Mel Gorman
    Cc: Michal Hocko
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Minchan Kim
     

21 May, 2012

1 commit

  • The Contiguous Memory Allocator is a set of helper functions for DMA
    mapping framework that improves allocations of contiguous memory chunks.

    CMA grabs memory on system boot, marks it with MIGRATE_CMA migrate type
    and gives back to the system. Kernel is allowed to allocate only movable
    pages within CMA's managed memory so that it can be used for example for
    page cache when DMA mapping do not use it. On
    dma_alloc_from_contiguous() request such pages are migrated out of CMA
    area to free required contiguous block and fulfill the request. This
    allows to allocate large contiguous chunks of memory at any time
    assuming that there is enough free memory available in the system.

    This code is heavily based on earlier works by Michal Nazarewicz.

    Signed-off-by: Marek Szyprowski
    Signed-off-by: Kyungmin Park
    Signed-off-by: Michal Nazarewicz
    Acked-by: Arnd Bergmann
    Tested-by: Rob Clark
    Tested-by: Ohad Ben-Cohen
    Tested-by: Benjamin Gaignard
    Tested-by: Robert Nelson
    Tested-by: Barry Song

    Marek Szyprowski
     

11 Feb, 2012

1 commit

  • Traditionally, any System-on-Chip based platform creates a flat list
    of platform_devices directly under /sys/devices/platform.

    In order to give these some better structure, this introduces a new
    bus type for soc_devices that are registered with the new
    soc_device_register() function. All devices that are on the same
    chip should then be registered as child devices of the soc device.

    The soc bus also exports a few standardised device attributes which
    allow user space to query the specific type of soc.

    Signed-off-by: Lee Jones
    Signed-off-by: Greg Kroah-Hartman

    Lee Jones
     

13 Jan, 2012

1 commit


12 Jan, 2012

1 commit

  • frv, h8300, m68k, microblaze, openrisc, score, um and xtensa currently
    do not register a CPU device. Add the config option GENERIC_CPU_DEVICES
    which causes a generic CPU device to be registered for each present CPU,
    and make all these architectures select it.

    Richard Weinberger covered UML and suggested using
    per_cpu.

    Signed-off-by: Ben Hutchings
    Signed-off-by: Linus Torvalds

    Ben Hutchings
     

06 Jan, 2012

2 commits

  • Mark dma-buf buffer sharing API as EXPERIMENTAL for first release.
    We will remove this in later versions, once it gets smoothed out
    and has more users.

    Signed-off-by: Sumit Semwal
    Signed-off-by: Sumit Semwal
    Signed-off-by: Dave Airlie

    Sumit Semwal
     
  • This is the first step in defining a dma buffer sharing mechanism.

    A new buffer object dma_buf is added, with operations and API to allow easy
    sharing of this buffer object across devices.

    The framework allows:
    - creation of a buffer object, its association with a file pointer, and
    associated allocator-defined operations on that buffer. This operation is
    called the 'export' operation.
    - different devices to 'attach' themselves to this exported buffer object, to
    facilitate backing storage negotiation, using dma_buf_attach() API.
    - the exported buffer object to be shared with the other entity by asking for
    its 'file-descriptor (fd)', and sharing the fd across.
    - a received fd to get the buffer object back, where it can be accessed using
    the associated exporter-defined operations.
    - the exporter and user to share the scatterlist associated with this buffer
    object using map_dma_buf and unmap_dma_buf operations.

    Atleast one 'attach()' call is required to be made prior to calling the
    map_dma_buf() operation.

    Couple of building blocks in map_dma_buf() are added to ease introduction
    of sync'ing across exporter and users, and late allocation by the exporter.

    For this first version, this framework will work with certain conditions:
    - *ONLY* exporter will be allowed to mmap to userspace (outside of this
    framework - mmap is not a buffer object operation),
    - currently, *ONLY* users that do not need CPU access to the buffer are
    allowed.

    More details are there in the documentation patch.

    This is based on design suggestions from many people at the mini-summits[1],
    most notably from Arnd Bergmann , Rob Clark and
    Daniel Vetter .

    The implementation is inspired from proof-of-concept patch-set from
    Tomasz Stanislawski , who demonstrated buffer sharing
    between two v4l2 devices. [2]

    [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
    [2]: http://lwn.net/Articles/454389

    Signed-off-by: Sumit Semwal
    Signed-off-by: Sumit Semwal
    Reviewed-by: Daniel Vetter
    Reviewed-by: Dave Airlie
    Reviewed-and-Tested-by: Rob Clark
    Signed-off-by: Dave Airlie

    Sumit Semwal
     

26 Jul, 2011

1 commit

  • …/gregkh/driver-core-2.6

    * 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6:
    updated Documentation/ja_JP/SubmittingPatches
    debugfs: add documentation for debugfs_create_x64
    uio: uio_pdrv_genirq: Add OF support
    firmware: gsmi: remove sysfs entries when unload the module
    Documentation/zh_CN: Fix messy code file email-clients.txt
    driver core: add more help description for "path to uevent helper"
    driver-core: modify FIRMWARE_IN_KERNEL help message
    driver-core: Kconfig grammar corrections in firmware configuration
    DOCUMENTATION: Replace create_device() with device_create().
    DOCUMENTATION: Update overview.txt in Doc/driver-model.
    pti: pti_tty_install documentation mispelling.

    Linus Torvalds
     

23 Jul, 2011

1 commit

  • There are many places in the tree where we implement register access for
    devices on non-memory mapped buses, especially I2C and SPI. Since hardware
    designers seem to have settled on a relatively consistent set of register
    interfaces this can be effectively factored out into shared code. There
    are a standard set of formats for marshalling data for exchange with the
    device, with the actual I/O mechanisms generally being simple byte
    streams.

    We create an abstraction for marshaling data into formats which can be
    sent on the control interfaces, and create a standard method for
    plugging in actual transport underneath that.

    This is mostly a refactoring and renaming of the bottom level of the
    existing code for sharing register I/O which we have in ASoC. A
    subsequent patch in this series converts ASoC to use this. The main
    difference in interface is that reads return values by writing to a
    location provided by a pointer rather than in the return value, ensuring
    we can use the full range of the type for register data. We also use
    unsigned types rather than ints for the same reason.

    As some of the devices can have very large register maps the existing
    ASoC code also contains infrastructure for managing register caches.
    This cache work will be moved over in a future stage to allow for
    separate review, the current patch only deals with the physical I/O.

    Signed-off-by: Mark Brown
    Acked-by: Liam Girdwood
    Acked-by: Greg Kroah-Hartman
    Acked-by: Wolfram Sang
    Acked-by: Grant Likely

    Mark Brown
     

02 Jul, 2011

3 commits


12 May, 2011

1 commit

  • Since suspend, resume and shutdown operations in struct sysdev_class
    and struct sysdev_driver are not used any more, remove them. Also
    drop sysdev_suspend(), sysdev_resume() and sysdev_shutdown() used
    for executing those operations and modify all of their users
    accordingly. This reduces kernel code size quite a bit and reduces
    its complexity.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

24 Mar, 2011

1 commit

  • Introduce Kconfig option allowing architectures where sysdev
    operations used during system suspend, resume and shutdown have been
    completely replaced with struct sycore_ops operations to avoid
    building sysdev code that will never be used.

    Make callbacks in struct sys_device and struct sysdev_driver depend
    on ARCH_NO_SYSDEV_OPS to allows us to verify if all of the references
    have been actually removed from the code the given architecture
    depends on.

    Make x86 select ARCH_NO_SYSDEV_OPS.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

21 Jan, 2011

1 commit

  • The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
    is used to configure any non-standard kernel with a much larger scope than
    only small devices.

    This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
    references to the option throughout the kernel. A new CONFIG_EMBEDDED
    option is added that automatically selects CONFIG_EXPERT when enabled and
    can be used in the future to isolate options that should only be
    considered for embedded systems (RISC architectures, SLOB, etc).

    Calling the option "EXPERT" more accurately represents its intention: only
    expert users who understand the impact of the configuration changes they
    are making should enable it.

    Reviewed-by: Ingo Molnar
    Acked-by: David Woodhouse
    Signed-off-by: David Rientjes
    Cc: Greg KH
    Cc: "David S. Miller"
    Cc: Jens Axboe
    Cc: Arnd Bergmann
    Cc: Robin Holt
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     

23 Oct, 2010

1 commit

  • Fix kconfig dependency warning for FW_LOADER.

    Lots of drivers select FW_LOADER without bothering to depend on
    HOTPLUG and/or without selecting HOTPLUG. A kernel builds fine
    when FW_LOADER is enabled, whether HOTPLUG is enabled or not, and
    a kernel config file (make oldconfig) is not changed by this patch.
    (Yes, drivers/base/firmware_class.c uses interfaces from linux/kobject.h,
    which does have some CONFIG_HOTPLUG dependencies, but this patch does
    not change that.)

    warning: (MICROCODE || MICROCODE_INTEL && MICROCODE || MICROCODE_AMD && MICROCODE || PCMCIA_LOAD_CIS && PCCARD && PCMCIA && EXPERIMENTAL || USB_IRDA && NET && IRDA && USB || BT_HCIBCM203X && NET && BT && USB || BT_HCIBFUSB && NET && BT && USB || BT_HCIBT3C && NET && BT && PCMCIA || BT_MRVL_SDIO && NET
    ...
    !STAGING_EXCLUDE_BUILD && USB && (X86 || ARM) && WLAN || DRM_NOUVEAU && STAGING && !STAGING_EXCLUDE_BUILD && DRM && PCI || TI_ST && STAGING && !STAGING_EXCLUDE_BUILD && RFKILL || DELL_RBU && X86) selects FW_LOADER which has unmet direct dependencies (HOTPLUG)
    (5200 byte line reduced a lot)

    Signed-off-by: Randy Dunlap
    Signed-off-by: Greg Kroah-Hartman

    Randy Dunlap
     

22 May, 2010

1 commit