Re: [PATCH] ASoC: core: init delayed_work for codec-codec links

2013-08-01 Thread Mark Brown
On Thu, Aug 01, 2013 at 04:50:56PM +0100, Richard Fitzgerald wrote: > Yeah, I think the problem is more one of bad naming. I should define that > function as the delayed work for codec-2-codec links, it just happens > that we don't currently have to do anything for them. The only thing > the pcm c

Re: [PATCH] ASoC: core: init delayed_work for codec-codec links

2013-08-01 Thread Richard Fitzgerald
On Thu, Aug 01, 2013 at 04:23:56PM +0100, Mark Brown wrote: > On Thu, Aug 01, 2013 at 04:13:52PM +0100, Richard Fitzgerald wrote: > > On Wed, Jul 31, 2013 at 02:25:22PM +0100, Mark Brown wrote: > > > > Why is this better than pointing at the normal work that you'd expect to > > > be used there? >

Re: [PATCH] ASoC: core: init delayed_work for codec-codec links

2013-08-01 Thread Mark Brown
On Thu, Aug 01, 2013 at 04:13:52PM +0100, Richard Fitzgerald wrote: > On Wed, Jul 31, 2013 at 02:25:22PM +0100, Mark Brown wrote: > > Why is this better than pointing at the normal work that you'd expect to > > be used there? > By 'normal work' do you mean the close_delayed_work() used for > stan

Re: [PATCH] ASoC: core: init delayed_work for codec-codec links

2013-08-01 Thread Richard Fitzgerald
On Wed, Jul 31, 2013 at 02:25:22PM +0100, Mark Brown wrote: > On Wed, Jul 31, 2013 at 02:16:44PM +0100, Richard Fitzgerald wrote: > > > Pointing it to a dummy work callback is cleaner than taking > > special cases in the code to bypass the flush_delayed_work_sync(). > > Why is this better than po

Re: [PATCH] ASoC: core: init delayed_work for codec-codec links

2013-07-31 Thread Mark Brown
On Wed, Jul 31, 2013 at 02:16:44PM +0100, Richard Fitzgerald wrote: > Pointing it to a dummy work callback is cleaner than taking > special cases in the code to bypass the flush_delayed_work_sync(). Why is this better than pointing at the normal work that you'd expect to be used there? signatur