On 9/15/20 2:56 PM, Andy Shevchenko wrote:
> On Tue, Sep 15, 2020 at 04:46:25PM +0300, Andy Shevchenko wrote:
>> On Tue, Sep 15, 2020 at 01:46:12PM +0100, Vladimir Murzin wrote:
>>> On 9/15/20 1:35 PM, Andy Shevchenko wrote:
>>>> On Fri, Sep 11, 2020 at 09:34:04AM +0100, Vladimir Murzin wrote:
>>>>> On 9/7/20 5:52 PM, Vladimir Murzin wrote:
>>
>> ...
>>
>>>>> An update on this?
>>>>
>>>> Sorry for delay. I have tested your patch and it works for my case. Though I
>>>> would amend it a bit (commit message is still a due).
>>>
>>>
>>> That's good, but what about behaviour prior d53513d5dc28? Did you (or somebody
>>> else) have a chance to confirm that it won't run with plain defaults?
>
> Yes, I may confirm this. I have taken dmatest just before that commit as of
> % git checkout 3f3c75541ffe -- drivers/dma/dmatest.c
> and it simple returns 0 and nothing happens.
Thanks a lot for confirmation!
>
> So, please provide a commit message to your fix, I'll incorporate it and send as a part of the series.
>
dmaengine: dmatest: Fix regression in run command with mis-configured channel
Andy reported that commit 6b41030fdc79 ("dmaengine: dmatest:
Restore default for channel") broke his scripts for the case
where "busy" channel is used for configuration with expectation
that run command would do nothing (and return 0). Instead,
behavior was (unintentionally) changed to treat such case as
under-configuration and progress with defaults, i.e. run command
would start a test with default setting for channel (which would
use all channels).
Restore original behavior with tracking status of channel setter
so we can distinguish between mis-configured and under-configured
cases in run command and act accordingly.
Fixes: 6b41030fdc79086db5d673c5ed7169f3ee8c13b9 ("dmaengine: dmatest: Restore default for channel")
Reported-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Tested-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Signed-off-by: Signed-off-by: Vladimir Murzin <vladimir.murzin@xxxxxxx>
Cheers
Vladimir
