Re: Kmod driver at iicbus. attach() and config_intrhook(9)

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."
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"