On Tuesday 12 of July 2011 09:36:06 Jean Delvare wrote:
> On Mon, 11 Jul 2011 23:50:38 +0200, Pavel Herrmann wrote:
> > spi_sync call uses its spi_message parameter to keep completion
> > information, using a drvdata structure is not thread-safe, potentially
> > causing one thread having pointers t
On Tue, Jul 12, 2011 at 10:04:55AM +0200, Pavel Herrmann wrote:
> On Tuesday 12 of July 2011 09:36:06 Jean Delvare wrote:
> > Honestly, I have no idea what "causing one thread having pointers to
> > memory on or above other threads stack" means (nor why this would be
> > bad.)
> the long-winded s
On Tue, 12 Jul 2011 10:04:55 +0200, Pavel Herrmann wrote:
> On Tuesday 12 of July 2011 09:36:06 Jean Delvare wrote:
> > On Mon, 11 Jul 2011 23:50:38 +0200, Pavel Herrmann wrote:
> > > spi_sync call uses its spi_message parameter to keep completion
> > > information, using a drvdata structure is not
We can allocate the tx and rx buffers as part of our data structure.
Doing so is faster and spares memory.
Signed-off-by: Jean Delvare
---
Can anyone with a MAX device try and report please?
drivers/hwmon/max.c | 27 ++-
1 file changed, 6 insertions(+), 21 dele
On Mon, 11 Jul 2011 23:50:38 +0200, Pavel Herrmann wrote:
> spi_sync call uses its spi_message parameter to keep completion information,
> using a drvdata structure is not thread-safe, potentially causing one thread
> having pointers to memory on or above other threads stack. use mutex to
> prevent
Jean Delvare wrote:
> Can anyone with a MAX device try and report please?
MAX on spitz seems to work properly.
Tested-by: Stanislav Brabec
--
Stanislav Brabec
http://www.penguin.cz/~utx
___
Zaurus-devel mailing list
Zaurus-devel@lists.linu
