Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Aug 2020 00:24:09 -0700
From:      Oleksandr Tymoshenko <gonzo@bluezbox.com>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        Alexander Mishin <mishin@mh.net.ru>, freebsd-arm@freebsd.org
Subject:   Re: Kmod driver at iicbus. attach() and config_intrhook(9)
Message-ID:  <20200819072409.GA59949@bluezbox.com>
In-Reply-To: <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org>
References:  <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon (avg@FreeBSD.org) wrote:
> On 18/08/2020 22:05, Alexander Mishin wrote:
> > Hi
> > 
> > I write a kmod driver for bh1750 light sensor with iic (almost wrote).
> > As usual, probe(), attach() and detach(). On attach() it runs TIMEOUT_TASK_INIT
> > for periodically write opecode, read result and place it to sysctl dev.bh1750.N
> > variables. It is all.
> > 
> > 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? ...or maybe... when I might need it?
> 
> 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.

-- 
gonzo



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200819072409.GA59949>