lkml.org 
[lkml]   [2008]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] 2/2 mtd: Add support for the Dreamcast VMU flash
From
Date

On Thu, 2008-03-20 at 14:10 -0700, Andrew Morton wrote:

> If this error is taken, vmu_flash_write() (at least) will not call
> maple_vmu_write_block() and hence mdev->mq->sem never gets up()ed. As far
> as I can tell.
>
> Also, when this function is called from vmu_flash_read_char() I can't see
> where mdev->mq->sem gets up()ed ever. But I didn't look too hard.
>

It's not an issue - the bus will report "a no reply" at the end of the
bus read and that will result in an automatic up.


<snip>
> > +
> > + for (x = 0; x < card->writecnt; x++) {
> > + /* take the lock to protect the contents of sendbuf */
> > + locking = down_interruptible(&mdev->mq->sem);
> > + if (locking) {
> > + error = -EBUSY;
> > + goto fail_nolock;
> > + }
>
> Confused. Where within this loop does the up(&mdev->mq->sem) happen?
>

It's in the bus code.


> > + ((unsigned long *)sendbuf)[1] =
> > + cpu_to_be32(partition << 24 | x << 16 | num);
> > + memcpy(sendbuf + 8, buf + phaselen * x, phaselen);
> > + mdev->mq->sendbuf = sendbuf;
> > + /* wait for the mutex to be available */
> > + maple_add_packet(mdev->mq);
>
> Within here, I guess, via a workqueue or timer function?


It's handled in a workqueue in the main bus code, yes.



\
 
 \ /
  Last update: 2008-03-20 23:37    [W:0.092 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site