On Wed, Sep 05, 2018 at 08:48:23AM +0800, Phil Reid wrote:
> On 5/09/2018 12:39 AM, Andy Shevchenko wrote:
> > On Tue, Sep 4, 2018 at 3:34 PM Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote:
> > >
> > >
> > > > LGTM.
> > > > Though I would expect that call back optional, so, it means that I2C
> > > > core, perhaps, may put some generic one as a stub.
> > >
> > > Right, stupid me. After some many variations, I missed to add one
> > > condition to this version. It should have been something like the
> > > following:
> > >
> > > > > - ret = adap->algo->master_xfer(adap, msgs, num);
> > > > > + if (in_atomic() || irqs_disabled())
> > >
> > > if (adap->algo->master_xfer_irqless && (in_atomic() || irqs_disabled()))
> >
> > I think something like
> >
> > if (in_atomic() || irqs_disabled()) {
> > if (adap->algo->master_xfer_irqless)
> > ret = adap->algo->master_xfer_irqless(adap, msgs, num);
> > else
> > ret = -ENOTSUPP;
> > }
> >
> At the moment I have an i2c gpio that is set to power off the system.
> A design flaw for sure but somehow it is working and so far no problems.
> Would this break that, vs falling back to the existing behaviour of
> calling master_xfer as proposed.
Ack. This is exactly the reason why I wrote:
"Note that we fall back to the generic master_xfer callback if this new
irqless one is not present. This is intentional to preserve the previous
behaviour and avoid regressions. Because there are drivers not using
interrupts or because it might have worked "accidently" before."
Maybe I should mention i2c-gpio as a no-interrupt user explicitly there.
Attachment:
signature.asc
Description: PGP signature
