summaryrefslogtreecommitdiff
path: root/drivers/base
AgeCommit message (Collapse)AuthorFilesLines
2014-11-21fence: dma-buf cross-device synchronization (v18)Maarten Lankhorst1-0/+9
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 <maarten.lankhorst@canonical.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> #use smp_mb__before_atomic() Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Chanho Park <chanho61.park@samsung.com> Conflicts: drivers/base/Kconfig Change-Id: Ie62c8c33a0cb7ca3df596f47ef328c33c4468139
2014-11-21dma-buf: move to drivers/dma-bufMaarten Lankhorst3-754/+0
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21dma-buf: update debugfs outputSumit Semwal1-13/+12
Russell King observed 'wierd' looking output from debugfs, and also suggested better ways of getting device names (use KBUILD_MODNAME, dev_name()) This patch addresses these issues to make the debugfs output correct and better looking. While at it, replace seq_printf with seq_puts to remove the checkpatch.pl warnings. Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2014-11-21reservation: cross-device reservation support, v4Maarten Lankhorst2-1/+40
This adds support for a generic reservations framework that can be hooked up to ttm and dma-buf and allows easy sharing of reservations across devices. The idea is that a dma-buf and ttm object both will get a pointer to a struct reservation_object, which has to be reserved before anything is done with the contents of the dma-buf. Changes since v1: - Fix locking issue in ticket_reserve, which could cause mutex_unlock to be called too many times. Changes since v2: - All fence related calls and members have been taken out for now, what's left is the bare minimum to be useful for ttm locking conversion. Changes since v3: - Removed helper functions too. The documentation has an example implementation for locking. With the move to ww_mutex there is no need to have much logic any more. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-21Revert "dmabuf-sync: add buffer synchronization framework"Chanho Park4-686/+0
This reverts commit 7a9958fedb90ef4000b6461d77a5c6dfd795c1c1.
2014-11-21Revert "dmabuf-sync: add cache operation feature"Chanho Park1-75/+0
This reverts commit 22a2b813ad54d967edf9d8117662fea25093f7d0.
2014-11-21Revert "dma-buf: add lock callback for fcntl system call."Chanho Park1-33/+0
This reverts commit 30d585606b85e454113b79478b6b6bb1991dd210.
2014-11-21Revert "dmabuf-sync: fix sync lock to multiple read"Chanho Park1-13/+30
This reverts commit 5c6a3a47e9a5b4286e4219bd70e9917b8ffee414.
2014-11-21Revert "dmabuf-sync: remove unnecessary the use of mutex lock."Chanho Park1-3/+6
This reverts commit c75e1e7a03b157842638e55b27f28c41a9a3dc2b.
2014-11-21Revert "dmabuf-sync: add private backend callbacks"Chanho Park1-7/+1
This reverts commit 5d2749a0ac3be2a3ed43a24a88d821e26097bf1e.
2014-11-21Revert "dmabuf-sync: add select system call support."Chanho Park2-66/+0
This reverts commit 4439a419906d4fe3d7e5093292bd2f4f4fbfc8c2.
2014-11-21Revert "dma-buf: return POLLIN | POLLOUT instead of POLLERR"Chanho Park1-2/+2
This reverts commit 494805a828f760a3b36629875cc123cc1e396aa8.
2014-11-21Revert "dmabuf-sync: update it to patch v8"Chanho Park1-389/+113
This reverts commit cf7e07ce2d9843105d2ed8f9d30ee66c06d83bb0.
2014-11-18clk: Support for clock parents and rates assigned from device treeSylwester Nawrocki1-0/+5
This patch adds helper functions to configure clock parents and rates as specified through 'assigned-clock-parents', 'assigned-clock-rates' DT properties for a clock provider or clock consumer device. The helpers are now being called by the bus code for the platform, I2C and SPI busses, before the driver probing and also in the clock core after registration of a clock provider. Change-Id: I96d98c9c9d576fcbf0dfc90d1cc75feb9fdf97cb Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> [s.nawrocki@samsung.com: backported to v3.10] Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-11-18upstream: dma-buf: avoid using IS_ERR_OR_NULLColin Cross1-7/+11
dma_buf_map_attachment and dma_buf_vmap can return NULL or ERR_PTR on a error. This encourages a common buggy pattern in callers: sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); if (IS_ERR_OR_NULL(sgt)) return PTR_ERR(sgt); This causes the caller to return 0 on an error. IS_ERR_OR_NULL is almost always a sign of poorly-defined error handling. This patch converts dma_buf_map_attachment to always return ERR_PTR, and fixes the callers that incorrectly handled NULL. There are a few more callers that were not checking for NULL at all, which would have dereferenced a NULL pointer later. There are also a few more callers that correctly handled NULL and ERR_PTR differently, I left those alone but they could also be modified to delete the NULL check. This patch also converts dma_buf_vmap to always return NULL. All the callers to dma_buf_vmap only check for NULL, and would have dereferenced an ERR_PTR and panic'd if one was ever returned. This is not consistent with the rest of the dma buf APIs, but matches the expectations of all of the callers. Signed-off-by: Colin Cross <ccross@android.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-18upstream: Finally eradicate CONFIG_HOTPLUGStephen Rothwell1-2/+0
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 <linux@arm.linux.org.uk> Cc: Doug Thompson <dougthompson@xmission.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-18drivers: power: hide some excessive debugsMarek Szyprowski1-3/+3
Hide following excessive debug messages, which are really not helpful for anything: device xyz: start latency exceeded, new value XXX ns device xyz: state restore latency exceeded, new value YYY ns Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Change-Id: Idab765ebd307ac40af1a556c0b08e26938a1c9cf
2014-11-18dmabuf-sync: update it to patch v8Inki Dae1-113/+389
- Consider the write-and-then-read ordering. The ordering issue means that a task don't take a lock to the dmabuf so this task would be stalled even though this task requested a lock to the dmabuf between other task unlocked and tries to lock the dmabuf again. For this, it addes a wait event mechanism using only generic APIs, wait_event_timeout and wake_up functions. The below is how to handle the ordering issue using this mechanism: 1. Check if there is a sync object added prior to current task's one. 2. If exists, it unlocks the dmabuf so that other task can take a lock to the dmabuf first. 3. Wait for the wake up event from other task: current task will be waked up when other task unlocks the dmabuf. 4. Take a lock to the dmabuf again. - Update Document - Code cleanups. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-18dma-buf: return POLLIN | POLLOUT instead of POLLERRInki Dae1-2/+2
It's not error if a dmabuf wasn't locked when select is called but rather that means there is no anyone accessing the dmabuf so return POLLIN | POLLOUT. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-18dmabuf-sync: add select system call support.Inki Dae2-0/+66
This patch implements select system call for DMA BUF module and adds related codes to dmabuf sync framework. The purpose of this feature is to wait for the completion of DMA or CPU access to a dmabuf without that caller locks the dmabuf again after the completion. This feature is useful when caller wants to be aware of the completion of DMA access to a shared dmabuf, and the caller doesn't use interfaces for the DMA device driver. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-18dmabuf-sync: add private backend callbacksInki Dae1-1/+7
This ops has just a free callback to release resource for each device driver. free callback will be called when device driver's sync object is freed. So device drivers should implement this callback so that their own contexts can be cleaned up regarding sync object. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-18dmabuf-sync: remove unnecessary the use of mutex lock.Inki Dae1-6/+3
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-18dmabuf-sync: fix sync lock to multiple readInki Dae1-30/+13
This patch fixes the issue that a sync object is unlocked when shared_cnt is bigger than 1 and sobj->access_type is write. the below number means shared_cnt and three sync objects share one buffer, r r r w when write locked 1 2 3 3 <- blocked when read unlocked 2 when read unlocked 1 when read unlocked 1 <- waked up Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-18dma-buf: add lock callback for fcntl system call.Inki Dae1-0/+33
This patch adds lock callback to dma buf file operations, and this callback will be called by fcntl system call. With this patch, fcntl system call can be used for buffer synchronization between CPU and CPU, and CPU and DMA in user mode. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2014-11-18dmabuf-sync: add cache operation featureInki Dae1-0/+75
With this patch, all cache operations will be done in kernel side instead of user side. P.S. basically, not only user shouldn't need to request cache operation to kernel but also kernel should't need such things. However, we would have performance overhead by unnecessary cache operations if we conform with mainline style: cache sync just before memory ownership moves from CPU to DMA, and just after memory ownership moves from DMA to CPU. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-18dmabuf-sync: add buffer synchronization frameworkInki Dae4-0/+686
This patch adds a buffer synchronization framework based on DMA BUF[1] and and based on ww-mutexes[2] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and user application. This framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v5: - Rmove a dependence on reservation_object: the reservation_object is used to hook up to ttm and dma-buf for easy sharing of reservations across devices. However, the dmabuf sync can be used for all dma devices; v4l2 and drm based drivers, so doesn't need the reservation_object anymore. With regared to this, it adds 'void *sync' to dma_buf structure. - All patches are rebased on mainline, Linux v3.10. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); ... And the below can be used as access types: DMA_BUF_ACCESS_R - CPU will access a buffer for read. DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use interfaces for device driver: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: "drm/exynos: add dmabuf sync support for g2d driver" and "drm/exynos: add dmabuf sync support for kms framework" from https://git.kernel.org/cgit/linux/kernel/git/daeinki/ drm-exynos.git/log/?h=dmabuf-sync And this framework includes fcntl system call[3] as interfaces exported to user. As you know, user sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. The below is how to use interfaces for user application: struct flock filelock; 1. Lock a dma buf: filelock.l_type = F_WRLCK or F_RDLCK; /* lock entire region to the dma buf. */ filelock.lwhence = SEEK_CUR; filelock.l_start = 0; filelock.l_len = 0; fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock); ... CPU access to the dma buf 2. Unlock a dma buf: filelock.l_type = F_UNLCK; fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock); close(dmabuf fd) call would also unlock the dma buf. And for more detail, please refer to [3] References: [1] http://lwn.net/Articles/470339/ [2] https://patchwork.kernel.org/patch/2625361/ [3] http://linux.die.net/man/2/fcntl Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2014-11-18drivers: dma-contiguous: clean source code and prepare for device treeMarek Szyprowski1-75/+44
This patch cleans the initialization of dma contiguous framework. The all-in-one dma_declare_contiguous() function is now separated into dma_contiguous_reserve_area() which only steals the the memory from memblock allocator and dma_contiguous_add_device() function, which assigns given device to the specified reserved memory area. This improves the flexibility in defining contiguous memory areas and assigning device to them, because now it is possible to assign more than one device to the given contiguous memory area. Such split in initialization procedure is also required for upcoming device tree support. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Michal Nazarewicz <mina86@mina86.com> Acked-by: Tomasz Figa <t.figa@samsung.com>
2014-11-18drivers: base: add notifier for failed driver bindMarek Szyprowski1-3/+7
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2014-11-14sysfs: driver core: Fix glue dir race condition by gdp_mutexYijing Wang1-1/+3
commit e4a60d139060975eb956717e4f63ae348d4d8cc5 upstream. There is a race condition when removing glue directory. It can be reproduced in following test: path 1: Add first child device device_add() get_device_parent() /*find parent from glue_dirs.list*/ list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) if (k->parent == parent_kobj) { kobj = kobject_get(k); break; } .... class_dir_create_and_add() path2: Remove last child device under glue dir device_del() cleanup_device_parent() cleanup_glue_dir() kobject_put(glue_dir); If path2 has been called cleanup_glue_dir(), but not call kobject_put(glue_dir), the glue dir is still in parent's kset list. Meanwhile, path1 find the glue dir from the glue_dirs.list. Path2 may release glue dir before path1 call kobject_get(). So kernel will report the warning and bug_on. This is a "classic" problem we have of a kref in a list that can be found while the last instance could be removed at the same time. This patch reuse gdp_mutex to fix this race condition. The following calltrace is captured in kernel 3.4, but the latest kernel still has this bug. ----------------------------------------------------- <4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40() <4>[ 3965.441474] Hardware name: Romley <4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)... ... <4>[ 3965.441605] Call Trace: <4>[ 3965.441611] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0 <4>[ 3965.441615] [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20 <4>[ 3965.441618] [<ffffffff81215963>] kobject_get+0x33/0x40 <4>[ 3965.441624] [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0 <4>[ 3965.441627] [<ffffffff812d22d4>] device_add+0xd4/0x6d0 <4>[ 3965.441631] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40 .... <2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65! <4>[ 3965.441915] invalid opcode: 0000 [#1] SMP ... <4>[ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10 <4>[ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20 <4>[ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120 <4>[ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490 .... ------------------------------------------------------- Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-30firmware_class: make sure fw requests contain a nameKees Cook1-0/+3
commit 471b095dfe0d693a8d624cbc716d1ee4d74eb437 upstream. An empty firmware request name will trigger warnings when building device names. Make sure this is caught earlier and rejected. The warning was visible via the test_firmware.ko module interface: echo -ne "\x00" > /sys/devices/virtual/misc/test_firmware/trigger_request Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-30regmap: fix NULL pointer dereference in _regmap_write/readPankaj Dubey1-2/+2
commit 5336be8416a71b5568d2cf54a2f2066abe9f2a53 upstream. If LOG_DEVICE is defined and map->dev is NULL it will lead to NULL pointer dereference. This patch fixes this issue by adding check for dev->NULL in all such places in regmap.c Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-30regmap: debugfs: fix possbile NULL pointer dereferenceXiubo Li1-2/+6
commit 2c98e0c1cc6b8e86f1978286c3d4e0769ee9d733 upstream. If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer dereference. So before dev_name(), we need to have check of the map->dev pionter. We also should make sure that the 'name' pointer shouldn't be NULL for debugfs_create_dir(). So here using one default "dummy" debugfs name when the 'name' pointer and 'map->dev' are both NULL. Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-05regmap: Fix handling of volatile registers for format_write() chipsMark Brown1-1/+1
commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream. A previous over-zealous factorisation of code means that we only treat registers as volatile if they are readable. For most devices this is fine since normally most registers can be read and volatility implies readability but for format_write() devices where there is no readback from the hardware and we use volatility to mean simply uncacheability this means that we end up treating all registers as cacheble. A bigger refactoring of the code to clarify this is in order but as a fix make a minimal change and only check readability when checking volatility if there is no format_write() operation defined for the device. Signed-off-by: Mark Brown <broonie@linaro.org> Tested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07drivercore: deferral race condition fixGrant Likely1-0/+17
commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream. When the kernel is built with CONFIG_PREEMPT it is possible to reach a state when all modules loaded but some driver still stuck in the deferred list and there is a need for external event to kick the deferred queue to probe these drivers. The issue has been observed on embedded systems with CONFIG_PREEMPT enabled, audio support built as modules and using nfsroot for root filesystem. The following log fragment shows such sequence when all audio modules were loaded but the sound card is not present since the machine driver has failed to probe due to missing dependency during it's probe. The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm machine driver: ... [ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER [ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER [ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card [ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component [ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE [ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered [ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517) [ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list [ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2 [ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517) [ 13.346755] davinci_mcasp_driver_init: LEAVE [ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral [ 13.592527] platform sound.3: really_probe: probe_count = 0 In the log the machine driver enters it's probe at 12.719969 (this point it has been removed from the deferred lists). McASP driver already executing it's probing (since 12.615118). The machine driver tries to construct the sound card (12.950839) but did not found one of the components so it fails. After this McASP driver registers all the ASoC components (the machine driver still in it's probe function after it failed to construct the card) and the deferred work is prepared at 13.099026 (note that this time the machine driver is not in the lists so it is not going to be handled when the work is executing). Lastly the machine driver exit from it's probe and the core places it to the deferred list but there will be no other driver going to load and the deferred queue is not going to be kicked again - till we have external event like connecting USB stick, etc. The proposed solution is to try the deferred queue once more when the last driver is asking for deferring and we had drivers loaded while this last driver was probing. This way we can avoid drivers stuck in the deferred queue. Signed-off-by: Grant Likely <grant.likely@linaro.org> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07topology: Fix compilation warning when not in SMPVincent Stehlé1-2/+1
commit 53974e06603977f348ed978d75c426b0532daa67 upstream. The topology_##name() macro does not use its argument when CONFIG_SMP is not set, as it ultimately calls the cpu_data() macro. So we avoid maintaining a possibly unused `cpu' variable, to avoid the following compilation warning: drivers/base/topology.c: In function ‘show_physical_package_id’: drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ [-Wunused-variable] define_id_show_func(physical_package_id); drivers/base/topology.c: In function ‘show_core_id’: drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ [-Wunused-variable] define_id_show_func(core_id); This can be seen with e.g. x86 defconfig and CONFIG_SMP not set. Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-04PM / runtime: Use pm_runtime_put_sync() in __device_release_driver()Rafael J. Wysocki1-1/+1
commit baab52ded242c35a2290e1fa82e0cc147d0d8c1a upstream. Commit fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) modified __device_release_driver() to call pm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before detaching the driver from the device. However, that was a mistake, because pm_runtime_put(dev) causes rpm_idle() to be queued up and the driver may be gone already when that function is executed. That breaks the assumptions the drivers have the right to make about the core's behavior on the basis of the existing documentation and actually causes problems to happen, so revert that part of commit fa180eb448fa and restore the previous behavior of __device_release_driver(). Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Fixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Kevin Hilman <khilman@linaro.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-05driver core : Fix use after free of dev->parent in device_shutdownBenson Leung1-7/+7
commit f123db8e9d6c84c863cb3c44d17e61995dc984fb upstream. The put_device(dev) at the bottom of the loop of device_shutdown may result in the dev being cleaned up. In device_create_release, the dev is kfreed. However, device_shutdown attempts to use the dev pointer again after put_device by referring to dev->parent. Copy the parent pointer instead to avoid this condition. This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11. See bug report : https://code.google.com/p/chromium/issues/detail?id=297842 This can easily be reproduced when shutting down with hidraw devices that report battery condition. Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse. For example, with the magic mouse : The dev in question is "hidraw0" dev->parent is "magicmouse" In the course of the shutdown for this device, the input event cleanup calls a put on hidraw0, decrementing its reference count. When we finally get to put_device(dev) in device_shutdown, kobject_cleanup is called and device_create_release does kfree(dev). dev->parent is no longer valid, and we may crash in put_device(dev->parent). This change should be applied on any kernel with this change : d1c6c030fcec6f860d9bb6c632a3ebe62e28440b Signed-off-by: Benson Leung <bleung@chromium.org> Reviewed-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-07regmap: rbtree: Fix overlapping rbnodes.David Jander1-1/+1
commit 4e67fb5f5e336250db944921e3c68057d6203034 upstream. Avoid overlapping register regions by making the initial blklen of a new node 1. If a register write occurs to a yet uncached register, that is lower than but near an existing node's base_reg, a new node is created and it's blklen is set to an arbitrary value (sizeof(*rbnode)). That may cause this node to overlap with another node. Those nodes should be merged, but this merge doesn't happen yet, so this patch at least makes the initial blklen small enough to avoid hitting the wrong node, which may otherwise lead to severe breakage. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Zhouping Liu <zliu@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-07drivers/base/memory.c: fix show_mem_removable() to handle missing sectionsRuss Anderson1-0/+2
commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 upstream. "cat /sys/devices/system/memory/memory*/removable" crashed the system. The problem is that show_mem_removable() is passing a bad pfn to is_mem_section_removable(), which causes if (!node_online(page_to_nid(page))) to blow up. Why is it passing in a bad pfn? The reason is that show_mem_removable() will loop sections_per_block times. sections_per_block is 16, but mem->section_count is 8, indicating holes in this memory block. Checking that the memory section is present before checking to see if the memory section is removable fixes the problem. harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable 0 1 1 1 1 1 1 1 1 1 1 1 1 1 BUG: unable to handle kernel paging request at ffffea00c3200000 IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90 PGD 83ffd4067 PUD 37bdfce067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod CPU: 4 PID: 5991 Comm: cat Tainted: G O 3.11.0-rc5-rja-uv+ #10 Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013 task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000 RIP: 0010:[<ffffffff81117ed1>] [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90 RSP: 0018:ffff880820023df8 EFLAGS: 00010287 RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004 RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000 RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000 R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001 FS: 00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0 Call Trace: show_mem_removable+0x41/0x70 dev_attr_show+0x2a/0x60 sysfs_read_file+0xf7/0x1c0 vfs_read+0xc8/0x130 SyS_read+0x5d/0xa0 system_call_fastpath+0x16/0x1b Signed-off-by: Russ Anderson <rja@sgi.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Yinghai Lu <yinghai@kernel.org> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14regmap: cache: Make sure to sync the last register in a blockLars-Peter Clausen1-1/+2
commit 2d49b5987561e480bdbd8692b27fc5f49a1e2f0b upstream. regcache_sync_block_raw_flush() expects the address of the register after last register that needs to be synced as its parameter. But the last call to regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address of the last register in the block. This effectively always skips over the last register in a block, even if it needs to be synced. In order to fix it increase the address by one register. The issue was introduced in commit 75a5f89 ("regmap: cache: Write consecutive registers in a single block write"). Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04regmap: cache: bail in regmap_async_complete() for bus-less mapsDaniel Mack1-1/+1
commit f2e055e7c9c6084bfbaa68701e52562acf96419e upstream. Commit f8bd822cb ("regmap: cache: Factor out block sync") made regcache_rbtree_sync() call regmap_async_complete(), which in turn does not check for map->bus before dereferencing it. This causes a NULL pointer dereference on bus-less maps. Signed-off-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18firmware loader: fix use-after-free by double abortMing Lei1-9/+18
fw_priv->buf is accessed in both request_firmware_load() and writing to sysfs file of 'loading' context, but not protected by 'fw_lock' entirely. The patch makes sure that access on 'fw_priv->buf' is protected by the lock. So fixes the double abort problem reported by nirinA raseliarison: http://lkml.org/lkml/2013/6/14/188 Reported-and-tested-by: nirinA raseliarison <nirina.raseliarison@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: stable <stable@vger.kernel.org> # 3.9 Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-03Merge remote-tracking branch 'regmap/fix/debugfs' into regmap-linusMark Brown1-1/+4
2013-06-03Merge remote-tracking branch 'regmap/fix/cache' into regmap-linusMark Brown2-14/+12
2013-06-01regmap: rbtree: Fixed node range check on syncMaarten ter Huurne1-2/+0
A node starting before the minimum register is no reason to reject it, since its end could be in range. The check for the end already exists two lines lower, so we can just remove the incorrect check. Signed-off-by: Maarten ter Huurne <maarten@treewalker.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-05-23Merge tag 'driver-core-3.10-rc2' of ↵Linus Torvalds2-2/+5
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg Kroah-Hartman: "Here are 3 tiny driver core fixes for 3.10-rc2. A needed symbol export, a change to make it easier to track down offending sysfs files with incorrect attributes, and a klist bugfix. All have been in linux-next for a while" * tag 'driver-core-3.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: klist: del waiter from klist_remove_waiters before wakeup waitting process driver core: print sysfs attribute name when warning about bogus permissions driver core: export subsys_virtual_register
2013-05-23regmap: regcache: Fixup locking for custom lock callbacksLars-Peter Clausen2-12/+12
The parameter passed to the regmap lock/unlock callbacks needs to be map->lock_arg, regcache passes just map. This works fine in the case that no custom locking callbacks are used since in this case map->lock_arg equals map, but will break when custom locking callbacks are used. The issue was introduced in commit 0d4529c5("regmap: make lock/unlock functions customizable") and is fixed by this patch. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-21driver core: print sysfs attribute name when warning about bogus permissionsdyoung@redhat.com1-2/+4
Make it obvious to see what attribute is using bogus permissions. Signed-off-by: Dave Young <dyoung@redhat.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-21driver core: export subsys_virtual_registerGreg Kroah-Hartman1-0/+1
Modules want to call this function, so it needs to be exported. Reported-by: Daniel Mack <zonque@gmail.com> Cc: Kay Sievers <kay@vrfy.org> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-12regmap: debugfs: Check return value of regmap_write()Dimitris Papastamos1-1/+4
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>