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

[Suraj Sonawane]

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