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

Alexander Mishin <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
Thanks for your answers, especially for "...controllers use interrupts 
to get notified about...".
It helped to understand.

Yes, I need it as I check on attach() if the device connected.
Everything was fine while I was loading the driver into an already 
running system,
but as soon as I loaded the driver at boot time, I saw that its sysctl 
variables was
only half filled (no result nor calculated values).
config_intrhook_oneshot() solved this issue.

Thanks once more

Oleksandr Tymoshenko писал 2020-08-19 11:24:
> Andriy Gapon ([email protected]) wrote:
>> On 18/08/2020 22:05, Alexander Mishin wrote:
>> > Hi
>> > ....
>> > But I see that some other devices (from /usr/src/sys/dev) uses CONFIG_INTRHOOK(9)
>> > on attach() for initialize themselfs.
>> > I wonder if I need this too?...
>> 
>> This is usually needed when a driver needs to talk to its device while
>> attaching.  E.g., to set some initial configuration or to confirm 
>> device's
>> identity, etc.
> 
> To extend Andriy's explanation a bit: all these operations may perform
> I2C transfers and most I2C controllers use interrupts to get notified
> about tranfer status change (finished, error, etc...). There is no
> guarantee that when driver's attach method is called interrupts are
> globally enabled. What would happen in this case is: I2C controller
> is going to initiate I2C operation and wait for an interrupt that's
> never going to be delivered. CONFIG_INTRHOOK is a solution for this
> problem, if your attach method requires interrupts - just split it
> in two parts and postpone running interrupt-dependent part until after
> interrupts are globally enabled.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.