From owner-freebsd-arm@freebsd.org Wed Aug 19 07:24:19 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 2F19F3B46E7 for ; Wed, 19 Aug 2020 07:24:19 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWfRQ37xFz4KRx; Wed, 19 Aug 2020 07:24:18 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1k8ISA-000FcC-3V; Wed, 19 Aug 2020 00:24:10 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 07J7O9Jn060027; Wed, 19 Aug 2020 00:24:09 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Wed, 19 Aug 2020 00:24:09 -0700 From: Oleksandr Tymoshenko To: Andriy Gapon Cc: Alexander Mishin , freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) Message-ID: <20200819072409.GA59949@bluezbox.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4BWfRQ37xFz4KRx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-0.43 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; FREEFALL_USER(0.00)[gonzo]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.130]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] 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 07:24:19 -0000 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