Re: [PATCH v3 3/4] iio: chemical: add support for winsen MHZ19B CO2 sensor

[Andy Shevchenko <andy.shevchenko@gmail.com>]

On Thu, Apr 17, 2025 at 11:03:12PM +0900, gyeyoung wrote:
> On Tue, Apr 15, 2025 at 2:21 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:

...

> > > > > +       /*
> > > > > +        * serdev receive buffer.
> > > > > +        * When data is received from the MH-Z19B,
> > > > > +        * the 'mhz19b_receive_buf' callback function is called and fills this buffer.
> > > > > +        */
> > > > > +       char buf[9];
> > > >
> > > > Should it be DMA-safe?
> > >
> > > I'm not sure if I understood your point correctly,
> > > This code isn't DMA-safe. I'm currently understanding why DMA-safe is necessary.
> > > (but actually other drivers implementing 'serdev ops' use non-DMA-safe buffers.)
> > > I will verify this part and then send the next patch.
> >
> > Because some of the UART drivers may enable DMA by default if it's
> > available and your code won't work on them, right? But double check if
> > serdev makes it DMA-safe before use.
> 
> It seems that the serdev buf doesn't need to be DMA-safe. I looked
> into the PL011 driver as an example,
> which uses DMA, and found that the data received via DMA is firstly
> stored in the buffer within the 'uart_amba_port' structure, and then
> copied into the 'tty_bufhead' within the tty_port. Later, in serdev's
> receive_buf(), it simply copies from the tty_bufhead to into serdev
> buf. So I think there's no need to consider DMA-safe in the serdev buf
> itself.

But who will give those guarantees (note, the code is most likely may be run on
different UART controllers (PL011 is just one of many), have you checked all
supported drivers for DMA?

> would this make sense? If so, I think there is no need to change the
> code related to the buffer.

The bare minimum is to make sure this buffer occupies the cacheline.
Read about DMA safety for the cache coherency.

-- 
With Best Regards,
Andy Shevchenko