On Tue, Sep 10, 2013 at 06:10:56PM +0300, Ivan T. Ivanov wrote:
> On Tue, 2013-09-10 at 08:46 -0500, Josh Cartwright wrote:
> > Hey Ivan-
> >
> > Some nits below.
> >
> > On Thu, Aug 29, 2013 at 04:27:53PM +0300, Ivan T. Ivanov wrote:
[..]
> > > +static int qup_i2c_probe(struct platform_device *pdev)
> > > +{
> > [..]
> > > +
> > > + ret = devm_request_irq(qup->dev, qup->irq, qup_i2c_interrupt,
> > > + IRQF_TRIGGER_HIGH, "i2c_qup", qup);
> > > + if (ret) {
> > > + dev_err(qup->dev, "Request %d IRQ failed\n", qup->irq);
> > > + return ret;
> > > + }
> > > +
> > > + disable_irq(qup->irq);
> >
> > How is this not racy, in the case where a pending interrupt is left from
> > the bootloader (which seems to be possible based on the comments below)?
>
> Yes it looks weird. Interrupt handler will check and exit if there
> is no message for transfer. I am looking for better way to handle this.
Below in probe() it looks like a controller reset is issued. I'm
wondering if the best way to fix this is to move that up so it happens
sooner (so we can assume here that the controller is in a
non-interrupting state).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
