linux-kernel - Re: [RFC PATCHv2 2/7] OMAP SSI: Introducing OMAP SSI driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1274858833.8099.14.camel@localhost>
Date:	Wed, 26 May 2010 10:27:13 +0300
From:	Carlos Chinea <carlos.chinea@...ia.com>
To:	ext Sebastien Jan <s-jan@...com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [RFC PATCHv2 2/7] OMAP SSI: Introducing OMAP SSI driver

On Tue, 2010-05-18 at 16:05 +0200, ext Sebastien Jan wrote:
> On Tuesday 18 May 2010 11:07:20 Carlos Chinea wrote:
> [cut]
> > > > +       val |= __raw_readl(omap_ssi->sys +
> > > > SSI_MPU_ENABLE_REG(port->num, 0)); +       __raw_writel(val,
> > > > omap_ssi->sys +
> > > >  SSI_MPU_ENABLE_REG(port->num, 0)); +
> > > > +       msg->status = HSI_STATUS_COMPLETED;
> > > > +       msg->actual_len = sg_dma_len(msg->sgt.sgl);
> > > > +       spin_unlock(&omap_ssi->lock);
> > > > +}
> > >
> > > Don't you need to check the queue related to this transfer at this point,
> > > to start the potentially next queued transfer on the same channel?
> > > (calling ssi_start_transfer(), like in ssi_pio_complete()?)
> > 
> > No this is done in ssi_pio_complete(). Notice that we do not call the
> > complete callback at any point here. We just arm the pio interrupt for
> > that channel and transfer direction. AFAIK, this is the SW logic
> > expected by the OMAP SSI HW.
> 
> Ok, though I would not expect the interrupt to fire in an Rx scenario as the 
> fifo would have already been emptied by the DMA for this transfer (unless you 
> rely on the next transfer initiated by the peer to make the Rx interrupt fire 
> on this channel?)?

No I do not rely on the next RX transfer. I rely on the fact that the
GDD(DMA) controller does not reset the RX status bit for that channel
when RX transfer is finished.

Br,
-- 
Carlos Chinea <carlos.chinea@...ia.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/