From owner-freebsd-arm@freebsd.org Wed Aug 19 15:40:05 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D76373C1A67 for ; Wed, 19 Aug 2020 15:40:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWsRT3Kmvz40wB for ; Wed, 19 Aug 2020 15:40:05 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1597851597; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=CLJX1u/Ezh86x2aAzFH5Ey3SiBbeQSgvfX4I9jywmpd/NyRdzg7xBS7X/ucgSW9XXfD7+dIk10aLQ onAX/FQtZwSDqqXG89bed47jPw/iT2CthRmCe3HgbSEtsO0YQLdyMFrfgG2Mlf9V/iYhGX60+SiJ0c m8koSis+yJJPehui/MoxNLZvkSRMuk5naz1QzD4ogqz0HxJ28sBRApagyxgPK9Tlnc2QRu4tgfe0Qm X6UL4iGGTRv+mhYYQW3e0Zsojnyz4hCws2dR6rttGDFe9JOMGikj44rQWVSrcdcqjeL5UyVkUwSa56 HK64WfpcXfJrnkHrREdTMH9PCwfwlZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=0iZkNmjs55mse4Hv35Hf2xZSfPMx1O27I6+HIifkdx8=; b=vaEeA8xMyChD6zORSmiK7vyN7oF4QQoecx9JfzxFXSGdTKi7wnOqQhi391xZ/QT4N+Ng0GALv+G8C v2GaIeSOwXe/gqyN7SnVT7h5S4iAKtcLdGGqHtRvwgvygsO1kv2xRi3vrYQFlZdrEHU8+3TJ13AHQ7 hwQJ98XT56ftHeco0eHbEKioVOIxe3Hq28/B8SxxjOgbRdOqz0UHGBJjiRbPxxHJR3Ec9sEUqUtKDY TqLe0Gl/aXEThiVPcU3imXsr8eCWz5t9qN7JwTK+gOF0n0E2i7szWd7Wdpg2G27ZL3wI9mKy/5zAiY m3FKehMULWGosJdiWnvjOCMMwXS8B3w== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=0iZkNmjs55mse4Hv35Hf2xZSfPMx1O27I6+HIifkdx8=; b=rNKaZKC2zbDwUqOEfMUGkspSutON7S+F+aPnmB0/CWpbTEqq4XhOMgMxRuTeND4mvRqbO55fuka/N fcx2k+n/VMtbZLHX9YC1sXeFfS1u7QsVaIkgKuIm01DbHXVP7Z9pg979yGiypxZPRnDFYzjvq46JDJ rhnCAAijyc4/6nZseHirA9+kRSNzUrOwUcxWjy7kaIC1GKWoRQuo1uKvYVPYt7IGdk+oppYAAO1JkX TI7A/jfGtr6CkGbIVdUDNoWsA77ssf0pg4HHFECclO8/WvOoLRe/dKgypGQ/UFeTsNLT4rZrVLK7U9 bOGBcM31QhBC2VI2DzLR8plPP9iW2OA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3aa43223-e232-11ea-a2bb-9f0c275c2f69 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 3aa43223-e232-11ea-a2bb-9f0c275c2f69; Wed, 19 Aug 2020 15:39:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 07JFdstp089262; Wed, 19 Aug 2020 09:39:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) From: Ian Lepore To: Oleksandr Tymoshenko , Andriy Gapon Cc: freebsd-arm@freebsd.org Date: Wed, 19 Aug 2020 09:39:54 -0600 In-Reply-To: <20200819072409.GA59949@bluezbox.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BWsRT3Kmvz40wB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 15:40:05 -0000 On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: > 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. > A note about all this: It should never be necessary for an i2c slave device driver to do this. The reason it's needed is because many i2c controller drivers attach the iicbus from their attach() routine even though they can't actually do i2c IO until interrupts are available. It is these controller drivers that should have the intrhook logic to not call bus_generic_attach() until interrupts are available if they can't do IO until interrupts are available. It has long been my goal to fix all our i2c controller drivers to behave correctly, so that i2c slave device drivers don't all need the intrhook logic. But somehow I never get around to it. -- Ian