On Wednesday, May 18, 2011 11:47:44 PM Cyril Hrubis wrote:
> Hi!
> I've applied this patch over 2.6.39-rc3 and did couple of suspends. After
> about ten of them I've got attached trace (instead of the usuall NULL
> pointer dereference in complete()).
>
> And yes, the MMC is still broken after this
On Saturday, May 21, 2011 10:45:02 PM Pavel Herrmann wrote:
> On Saturday, May 21, 2011 10:28:07 PM Pavel Machek wrote:
> > Unfortunately that one does not apply, due to
> >
> > > @@ -213,6 +224,7 @@ static int __devexit max_remove(struct
> > > spi_device *spi)
> >
> > Whitespace damage. (but
On Saturday, May 21, 2011 10:28:07 PM Pavel Machek wrote:
> Unfortunately that one does not apply, due to
>
> > @@ -213,6 +224,7 @@ static int __devexit max_remove(struct spi_device
> > *spi)
>
> Whitespace damage. (but if you just delete this extra newline, its
> fine).
sorry for that one,
Hi!
> > I think you want to hold the mutex at the point you setup the data to be
> > transferred, do the transfer, and then release the mutex once you've read
> > the results of the transfer.
>
> oh no, not again...
> this was the earliest version, not the cleaned-up one (notice the lock in
> se
On Fri, May 20, 2011 at 12:13:20AM +0200, Pavel Herrmann wrote:
> From bd55d6b18fa4fcb884980825b43b43df01767149 Mon Sep 17 00:00:00 2001
> From: Pavel Herrmann
> Date: Mon, 16 May 2011 14:18:18 +0200
> Subject: [PATCH] MAX: Fix Race condition causing NULL pointer exception
>
> spi_sync call u
On Thursday, May 19, 2011 09:31:21 PM Russell King - ARM Linux wrote:
> I'm not sure that this is right. Taking the lock around spi_sync() ensures
> that two concurrent spi_sync()s can't happen in parallel, but with this you
> could end up with another happening as soon as this lock is released -
On Thu, May 19, 2011 at 02:51:40PM +0200, Pavel Herrmann wrote:
> @@ -52,7 +53,14 @@ static int max_read(struct device *dev, int channel)
> MAX_CTRL_PD0 | MAX_CTRL_PD1 |
> MAX_CTRL_SGL | MAX_CTRL_UNI | MAX_CTRL_STR;
>
> + /* spi_sync require
Hi
On Thursday, May 19, 2011 02:35:08 PM Pavel Machek wrote:
> > you're potentially doing with this:
> In some other mail, you said "just add the locking". Pavel H.
> actually produced patch doing so...
yes, that was the original version of the patch. while I agree with Marek on
locks not being
On Thursday, May 19, 2011 02:51:40 PM Pavel Herrmann wrote:
> Hi
>
> On Thursday, May 19, 2011 02:35:08 PM Pavel Machek wrote:
> > > you're potentially doing with this:
> > In some other mail, you said "just add the locking". Pavel H.
> > actually produced patch doing so...
>
> yes, that was the
Hi!
On Wed 2011-05-18 16:29:35, Russell King - ARM Linux wrote:
> On Wed, May 18, 2011 at 05:18:38PM +0200, Pavel Herrmann wrote:
> > spi_sync call uses its spi_message parameter to keep completion information,
> > having this structure static is not thread-safe, potentially causing one
> > thread
On Wed, May 18, 2011 at 07:36:54PM +0200, Marek Vasut wrote:
> > On Wed, May 18, 2011 at 05:18:38PM +0200, Pavel Herrmann wrote:
> > > spi_sync call uses its spi_message parameter to keep completion
> > > information, having this structure static is not thread-safe,
> > > potentially causing one th
Hi!
I've applied this patch over 2.6.39-rc3 and did couple of suspends. After about
ten of them I've got attached trace (instead of the usuall NULL pointer
dereference in complete()).
And yes, the MMC is still broken after this change it seems that there are more
bugs in zaurus SPI drivers.
--
m
> On Wed, May 18, 2011 at 05:18:38PM +0200, Pavel Herrmann wrote:
> > spi_sync call uses its spi_message parameter to keep completion
> > information, having this structure static is not thread-safe,
> > potentially causing one thread having pointers to memory on or above
> > other threads stack. u
On Wed, May 18, 2011 at 05:18:38PM +0200, Pavel Herrmann wrote:
> spi_sync call uses its spi_message parameter to keep completion information,
> having this structure static is not thread-safe, potentially causing one
> thread having pointers to memory on or above other threads stack. use
> per-cal
On Wed, May 18, 2011 at 11:18 PM, Pavel Herrmann
wrote:
> spi_sync call uses its spi_message parameter to keep completion information,
> having this structure static is not thread-safe, potentially causing one
> thread having pointers to memory on or above other threads stack. use
> per-call spi_m
15 matches
Mail list logo
