Hello,
On Wed, Jul 12, 2017 at 03:31:02PM +0200, Arnd Bergmann wrote:
> > We also have about a bazillion
> >
> > warning: ‘*’ in boolean context, suggest ‘&&’ instead
> >
> > warnings in drivers/ata/libata-core.c, all due to a single macro that
> > uses a pattern that gcc-7.1.1 doesn't like. T
*' in boolean context, suggest
> '&&' instead [-Wint-in-bool-context]
>
> This slightly rearranges the macro to simplify the code and avoid
> the warning at the same time.
>
> Signed-off-by: Arnd Bergmann
If the whole series will be routed together,
Acked-by: T
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Mauro, can you please pick this one up? It prolly should be tagged
for -stable too.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.ker
en the driver is disconnected.
>
> The unused label err_unreg has also been dropped.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord..
On Sat, Jul 16, 2016 at 02:43:20PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "_irq_audio_queues" runs the audio upstream handler.
> It has a single work item(&dev->_audio_work_entry) and hence doesn't
> require ordering. Also, it is not being used on a memory reclaim path.
> Hence, the sin
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
This needs to be marked for stable.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
nless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
ntee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in pvr2_hdw_destroy to ensure that there are no
> pending tasks while disconnecting the driver.
>
> Signed-off-by: Bh
ath.
>
> Work item has been flushed in s5p_mfc_remove() to ensure
> that there are no pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "
ath.
>
> Work item has been flushed in s5p_mfc_remove() to ensure
> that there are no pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "
the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in hdpvr_device_release() to ensure
> that there are no pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shridhar
the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been sync cancelled in tc358743_remove() to ensure
> that there are no pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
tly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Tejun Heo
On Sat, Jul 02, 2016 at 04:19:28PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in updating parameters for
> transfers. It has a single work item(&sd->work) and hence
> doesn't require ordering. Also, it is not being used on a memory
> reclaim path. Hence, the single
the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been sync cancelled in adv76xx_remove() to ensure
> that there are no pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
>
> Work item has been sync cancelled in adv7842_remove() to ensure
> that there are no pending tasks while disconnecting the driver.
>
> Signed-off-by: Bhaktipriya Shrid
B_MUSB_OMAP2PLUS has a cyclic
> >dependency, so it is left as "select".
> >
> >Signed-off-by: Arun Ramamurthy
>
> Need your ACK for this patch.
For ATA part,
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "
On Mon, May 05, 2014 at 03:30:34PM -0400, Devin Heitmueller wrote:
> On Mon, May 5, 2014 at 3:26 PM, Tejun Heo wrote:
> > As such, please consider the patches nacked and try to find someone
> > who can shepherd the code. Mauro, can you help out here?
>
> We actually discu
Hello, Shuah.
On Mon, May 05, 2014 at 01:16:46PM -0600, Shuah Khan wrote:
> You are right that there is a need for an owner field to indicate who
> has the token. Since the path is very long, I didn't want to use just
> the mutex and keep it tied up for long periods of time. That is the
> reason w
actually owns the
lock.
> + if (tkn_ptr->in_use)
> + rc = -EBUSY;
> + else
> + tkn_ptr->in_use = true;
Wat? Why would you have in_use protected by trylock? What's the
reasonsing behind that? What would you need "try"lock there? Ok
On Thu, Apr 17, 2014 at 04:10:34PM -0400, Tejun Heo wrote:
> On Thu, Apr 17, 2014 at 02:01:32PM -0600, Shuah Khan wrote:
> > Operating on the lock should be atomic, which is what devres_update()
> > is doing. It can be simplified as follows by holding devres_lock
> &g
On Thu, Apr 17, 2014 at 02:01:32PM -0600, Shuah Khan wrote:
> Operating on the lock should be atomic, which is what devres_update()
> is doing. It can be simplified as follows by holding devres_lock
> in devm_token_lock().
>
> spin_lock_irqsave(&dev->devres_lock, flags);
> if (tkn_ptr->status == T
&tkn, __devm_token_unlock);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(devm_token_unlock);
Why is devres_update() even necessary? You can just embed lock in the
data part and operate on it, no?
This is among the most poorly written code that
Hey,
On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote:
> Another would be if subsystem maintainers are happy that I carry them,
> I can add the acks, and then later on towards the end of the cycle,
> provide a branch subsystem maintainers could pull.
>
> Or... if you can t
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_c
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King
Acked-by: Tejun Heo
The patch is pretty widely spread. I don't mind how it gets routed
but what's the plan?
Thanks.
--
tejun
--
To unsubscribe from this list: send the lin
On Wed, Oct 24, 2012 at 8:14 AM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit 43829731d (workqueue: deprecate flush[_delayed]_work_sync()),
> flush_work() should be used instead of flush_work_sync().
>
> Signed-off-by: Fabio Estevam
Acked-by: Tejun Heo
Thanks
>
> drivers/media/platform/coda.c:1543: warning: '__cancel_delayed_work' is
> deprecated (declared at include/linux/workqueue.h:437)
>
> Signed-off-by: Fabio Estevam
Acked-by: Tejun Heo
Thanks!
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe
On Fri, Sep 14, 2012 at 03:50:40PM -0700, Colin Cross wrote:
> This patch set fixes a reproducible crash I'm seeing on a 3.4.10
> kernel. flush_kthread_worker (which is different from
> flush_kthread_work) is initializing a kthread_work and a completion on
> the stack, then queuing it and calling
Hello,
On Sun, Jul 22, 2012 at 04:46:54PM -0400, Andy Walls wrote:
> Hmmm, I didn't know about the constraint about 'known to be alive' in
> the other email I just sent.
>
> That might make calling flush_kthread_work() hard for a user to use, if
> the user lets the work get freed by another threa
>From 9a2e03d8ed518a61154f18d83d6466628e519f94 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Thu, 19 Jul 2012 13:52:53 -0700
Make the following two non-functional changes.
* Separate out insert_kthread_work() from queue_kthread_work().
* Relocate struct kthread_flush_work
Hello,
On Sat, Jul 21, 2012 at 02:20:06PM -0400, Andy Walls wrote:
> > + worker->current_work = work;
> > spin_unlock_irq(&worker->lock);
> >
> > if (work) {
> > __set_current_state(TASK_RUNNING);
> > work->func(work);
>
> If the call to 'work->func(work);' fre
Hello,
On Sat, Jul 21, 2012 at 01:13:27PM -0400, Andy Walls wrote:
> > +/* insert @work before @pos in @worker */
>
> Hi Tejun,
>
> Would a comment that the caller should be holding worker->lock be useful
> here? Anyway, comment or not:
>
> Acked-by: Andy Walls
Will add lockdep_assert_held()
>From 06f9a06f4aeecdb9d07014713ab41b548ae219b5 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Thu, 19 Jul 2012 13:52:53 -0700
kthread_worker provides minimalistic workqueue-like interface for
users which need a dedicated worker thread (e.g. for realtime
priority). It has basic queue, flush_w
>From c9bba34243a86fb3ac82d1bdd0ce4bf796b79559 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Thu, 19 Jul 2012 13:52:53 -0700
Make the following two non-functional changes.
* Separate out insert_kthread_work() from queue_kthread_work().
* Relocate struct kthread_flush_work
Hello,
kthread_worker was introduced together with concurrency managed
workqueue to serve workqueue users which need a special dedicated
worker - e.g. RT scheduling. This is minimal queue / flush / flush
all iterface on top of kthread and each provided interface matches the
workqueue counterpart
flush_scheduled_work() is deprecated and scheduled to be removed.
technisat-usb2 already sync-cancels the only work item it uses and
there's no reason for it to call flush_scheduled_work(). Don't use
it.
Signed-off-by: Tejun Heo
Cc: Mauro Carvalho Chehab
Cc: Patrick Boettcher
--
ut_ir_stop() sync flush all three work items before
returning.
Signed-off-by: Tejun Heo
Reported-by: Andy Walls
Reviewed-by: Andy Walls
Cc: Dmitry Torokhov
Cc: Mauro Carvalho Chehab
---
drivers/media/video/cx23885/cx23885-input.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/m
Hello,
On Mon, Feb 14, 2011 at 07:54:36PM -0500, Andy Walls wrote:
> > 1. Just flush the work items explicitly using flush_work_sync().
>
> That will do for now.
>
> > 2. Create a dedicated workqueue to serve as flushing domain.
>
> I have gotten reports of the IR Rx FIFO overflows for the CX23
Hello,
On Sun, Feb 13, 2011 at 08:33:55PM -0800, Dmitry Torokhov wrote:
> > The cx23885 driver does in fact schedule work for IR input handling:
> >
> > Here's where it is scheduled for CX23888 chips:
> >
> > http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-ir.c
wl1273_device->work is unused. Remove it along with the spurious
flush_scheduled_work() call in wl1273_fm_module_exit().
Signed-off-by: Tejun Heo
Cc: Matti Aaltonen
Cc: Mauro Carvalho Chehab
---
drivers/media/radio/radio-wl1273.c |5 -
1 file changed, 5 deletions(-)
Index: w
Hello,
On Mon, Jan 03, 2011 at 07:54:56PM -0500, Andy Walls wrote:
> 2. To prevent work items being handled by keventd/n from being delayed
> too long, as the deferred work in question can involve a bit of sleeping
> due to contention, the workload of the CX23418's MPEG encoding engine,
> and the
WQ_MEM_RECLAIM.
Signed-off-by: Tejun Heo
Cc: Andy Walls
Cc: linux-media@vger.kernel.org
---
Only compile tested. Please feel free to take it into the subsystem
tree or simply ack - I'll route it through the wq tree.
Thanks.
drivers/media/video/cx18/cx18-driver.c | 24 ++-
On 07/05/2010 07:11 PM, Andy Walls wrote:
> Assuming the new kthread_worker implementation is OK, this change for
> ivtv looks good.
>
> Reviewed-by: Andy Walls
> Acked-by: Andy Walls
May I route this patch through wq branch? As it's not clear how this
whole patchset will end up, I think it wo
Upcoming workqueue updates will no longer guarantee fixed workqueue to
worker kthread association, so giving RT priority to the irq worker
won't work. Use kthread_worker which guarantees specific kthread
association instead. This also makes setting the priority cleaner.
Signed-off-by: Teju
Hello,
11/17/2009 09:05 PM, Andy Walls wrote:
>> Implementing strict ordering
>> shouldn't be too difficult but I can't help but feeling that such
>> assumption is abuse of implementation detail.
>
> Hmmm, does not the "queue" in workqueue mean "FIFO"?
I don't think it necessarily means strict
Hello, Linus.
11/18/2009 12:05 AM, Linus Torvalds wrote:
>> Do you think that usage is wide-spread? Implementing strict ordering
>> shouldn't be too difficult but I can't help but feeling that such
>> assumption is abuse of implementation detail.
>
> I think it would be good if it were more than
Hello,
11/17/2009 09:47 AM, Andy Walls wrote:
> An important property of the single threaded workqueue, upon which the
> cx18 driver relies, is that work objects will be processed strictly in
> the order in which they were queued. The cx18 driver has a pool of
> "work orders" and multiple active
52 matches
Mail list logo
