Hi,
On Tue, 2013-09-10 at 10:36 -0500, Josh Cartwright wrote:
> 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).
Thanks, sound reasonable.
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
