Kmod driver at iicbus. attach() and config_intrhook(9)
John-Mark Gurney
jmg at funkthat.com
Mon Aug 24 20:18:44 UTC 2020
Ian Lepore wrote this message on Thu, Aug 20, 2020 at 18:40 -0600:
> On Thu, 2020-08-20 at 16:53 -0700, John-Mark Gurney wrote:
> > > Hmm, yeah, it looks like more has been done along these lines than I
> > > remembered. In fact, the work may be done.
> > >
> > > Some i2c controllers have to work properly before interrupts are
> > > available, to control things like PMIC chips that are required very
> > > early in device configuration. Typically they have some sort of
> >
> > Ahh, yeah, forgot about PMICs...
> >
> > > polling mechanism that's used early, and revert to using interrupts
> > > once they're available. The allwinner and rockchip drivers work that
> > > way.
> >
> > So, sounds like any controller that is found to not be doing this, needs
> > to be fixed to use the above function, and then the remaining ones that
> > either poll, or use the hybrid approach can keep using
> > bus_generic_attach...
> >
> > Back to original question, no, that additional logic should not be
> > needed, and any controller that requires it needs to be fixed
> > instead...
>
> Yeah, it was always my plan that after all controller drivers were
> updated, the intrhook stuff could be removed from slave drivers that
> still have it.
>
> I'd like to see the controllers that can do xfers without interrupts
> have a comment that says so. Something like
>
> /* no need for bus_delayed_attach(), we xfer without interrupts */
>
> Then you can grep -l for add_child.*iicbus and grep for
> bus_delayed_attach and compare the two file lists to find drivers that
> may not be doing the right thing. Using that technique now shows that
> we may still have a dozen or so controller drivers to fix (or at least
> examine for correctness).
Just realized we should probably document this somewhere... iicbus(4)
isn't the best place, but it's a place that exists...
It's also woefully out of data, listing only a few device drivers,
and 4 interfaces...
Anyone want to submit a patch for this?
> BTW, all of this tends to apply to SPI controller and slave drivers
> too, but the problem is likely smaller there because we have fewer SPI
> controller drivers.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-arm
mailing list