Re: [PATCH] sound: fix uninit-value in i2s_dma_isr

[Suraj Sonawane <surajsonawane0215@gmail.com>]

On 31/10/24 21:47, Mark Brown wrote:
> On Thu, Oct 31, 2024 at 12:17:56PM +0530, Suraj Sonawane wrote:
>> On 30/10/24 22:44, Mark Brown wrote:
> 
>>> This will shut the warning up, but why are these values valid?  Are we
>>> handling the cases where the loops do not execute properly?
> 
>> Thank you for the feedback and your time.
> 
>> The uninitialized warning for val_1 and val_2 arises because, in some cases,
>> the offlevel value is zero, and as a result, the loop does not execute,
>> leaving these variables potentially undefined. The subsequent code
>> calculates prtd->dma_addr_next using val_1 + val_2, so it's necessary to
>> have val_1 and val_2 initialized to a known value, even when the loop does
>> not run.
> 
>> Initializing them to zero ensures prtd->dma_addr_next has a defined value
>> without triggering undefined behavior. However, if a zero initialization
>> could cause unintended behavior in dma_addr_next, I could alternatively
>> handle this case by setting dma_addr_next conditionally when offlevel is
>> non-zero.
> 
> This is describing again what the patch does, which basically just boils
> down to shutting up the warning.
> 
>> Let me know if there’s a preferred approach, or if you'd suggest a different
>> initial value for these variables based on the expected use.
> 
> We need to understand what the change is doing - what do the values
> mean, is the real issue that we're missing some error handling for the
> case that lets us fall through without initialisation?
Thank you for clarifying.

I reviewed the context around val_1 and val_2 in dma_addr_next. These 
values are expected to come from the registers when offlevel is 
non-zero, representing the next DMA address and length information. If 
offlevel is zero, it means there’s no offset data to process, and 
dma_addr_next might not need updating in that case.

A more precise solution would be to conditionally update 
prtd->dma_addr_next only when offlevel is non-zero, as this would 
reflect the intended logic without relying on an arbitrary initialization.

Would it be better to revise the patch to conditionally update 
prtd->dma_addr_next only when offlevel is non-zero?

Let me know if this approach aligns better with the expected behavior.

Thank you again for your time.

Thanks,
Suraj