linux-kernel - RE: [PATCH] SPI: Add driver for Cadence SPI controller

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aa8486d2-8571-4b31-8980-78806a80e600@CH1EHSMHS031.ehs.local>
Date:	Tue, 18 Mar 2014 14:45:09 +0000
From:	Harini Katakam <harini.katakam@...inx.com>
To:	Mark Brown <broonie@...nel.org>
CC:	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"rob@...dley.net" <rob@...dley.net>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
	Michal Simek <michals@...inx.com>
Subject: RE: [PATCH] SPI: Add driver for Cadence SPI controller

HI Mark,

> -----Original Message-----
> From: Mark Brown [mailto:broonie@...nel.org]
> Sent: Tuesday, March 18, 2014 6:04 PM
> To: Harini Katakam
> Cc: robh+dt@...nel.org; pawel.moll@....com; mark.rutland@....com;
> ijc+devicetree@...lion.org.uk; galak@...eaurora.org; rob@...dley.net;
> grant.likely@...aro.org; devicetree@...r.kernel.org; linux-
> doc@...r.kernel.org; linux-kernel@...r.kernel.org; linux-
> spi@...r.kernel.org; Michal Simek
> Subject: Re: [PATCH] SPI: Add driver for Cadence SPI controller
> 
> On Tue, Mar 18, 2014 at 12:13:45PM +0000, Harini Katakam wrote:
> 
> 
> > > > In this case both possible interrupt conditions are handled.
> 
> > > Are you sure that's the case, and even if you are that's still not
> > > handling the case where the device isn't flagging an interrupt at all.
> 
> > The IXR_ALL mask is only used to disable all the interrupts in the
> beginning.
> > These two are the only interrupts enabled.
> > And RXNEMPTY status is just polled. That interrupt is not enabled either
> 
> This is all going to be fragile in the face of bugs or changes in the
> code though and like I keep saying it doesn't handle interrupt sharing.

OK. I dint consider interrupt sharing. 
Do you think the following implementation would be better?

status = IRQ_NONE;
if (intr_status & CDNS_SPI_IXR_MODF_MASK) {
	/* Handle this interrupt here */
	status = IRQ_HANDLED;
} else if (intr_status & CDNS_SPI_IXR_TXOW_MASK) {
	/* Handle this interrupt here */
	status = IRQ_HANDLED;
}

return status;

Regards,
Harini


--
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/