Re: [PATCH v4] serial: spi: add spi-uart driver for Maxim 3110

[David Brownell <david-b@pacbell.net>]

On Friday 26 February 2010, Masakazu Mokuno wrote:
> > +static int max3110_read_multi(struct uart_max3110 *max, u8 *buf)
> > +{
> > +     u16 obuf[M3110_RX_FIFO_DEPTH], ibuf[M3110_RX_FIFO_DEPTH];
> 
> Doing I/O on stack is guaranteed safe for spi functions?

Good catch ...  no it's not safe.

No DMA-enabled programming interface allows it, including SPI.

The Documentation/PCI/PCI-DMA-mapping.txt file has a section with
the oddly punctuated title "What memory is DMA'able?".  That's
generic to all uses of DMA.  When it was moved to the PCI area,
that information became harder to find ... but no less true for
non-PCI contexts (sigh).  One relevant paragraph being:

  This rule also means that you may use neither kernel image addresses
  (items in data/text/bss segments), nor module image addresses, nor
  stack addresses for DMA.  These could all be mapped somewhere entirely
  different than the rest of physical memory.  Even if those classes of
  memory could physically work with DMA, you'd need to ensure the I/O
  buffers were cacheline-aligned.  Without that, you'd see cacheline
  sharing problems (data corruption) on CPUs with DMA-incoherent caches.
  (The CPU could write to one word, DMA would write to a different one
  in the same cache line, and one of them could be overwritten.)

Those cacheline sharing problems are particularly bad for the stack,
since the data corruption often includes return addresses.

In short, passing a stack-based I/O buffer could work on some machines,
but cause perplexing data corruption issues on others.  So don't try
to do it any driver that claims to be portable.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html