On Tue, Dec 3, 2024 at 6:16 PM Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxx> wrote: > On Tue, Dec 03, 2024 at 03:10:30PM +0200, Andy Shevchenko wrote: > > On Tue, Dec 3, 2024 at 1:01 PM Uwe Kleine-König > > <u.kleine-koenig@xxxxxxxxxxxx> wrote: > > > > > > It can happen if a previous conversion was aborted the ADC pulls down > > > the ̅R̅D̅Y line but the event wasn't handled before. In that case enabling > > > > Interesting use of Unicode, but I suggest to avoid it when it can be > > avoided, i.e. > > using the notation of #RDY_N might be appropriate as that is how > > usually the HW people refer to the active low signals. > > Usage of ̅R̅D̅Y has the advantage to match the reference manual and data > sheet. So I tend to keep it. Not sure it's strictly the same. The above has two dashes on top (actually misaligned a bit) of two letters out of three, this is quite confusing (as to me to an electrical engineer) and I hardly believe it's the same in the datasheet (however nowadays everything is possible with (ab)use of Unicode). > > > the irq might immediately fire (depending on the irq controller's > > > > controller > > That matches the way I spelled it. Do you mean s/'s//? Yes. > > > capabilities) and even with a rdy-gpio isn't identified as an unrelated > > > one. > > > > > > To cure that problem check for a pending event before the measurement is > > > started and clear it if needed. ... > > > + data = kzalloc(data_read_len + 1, GFP_KERNEL); > > > > Yes, I know that's not needed right now, but would make code robust > > against changes. I'm talking about using __free() here. > > Given that I expect this commit to be backported to stable and > > $ git show stable/linux-4.19.y:include/linux/cleanup.h > fatal: path 'include/linux/cleanup.h' exists on disk, but not in 'stable/linux-4.19.y' > > I'd not do that *now* and in this commit. But in general I agree. Good! -- With Best Regards, Andy Shevchenko
