From owner-freebsd-arm@freebsd.org Mon Aug 24 20:18:44 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 72C073CC5AD for ; Mon, 24 Aug 2020 20:18:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bb3Nc2DJmz4CvX; Mon, 24 Aug 2020 20:18:39 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 07OKIWDX081021 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Aug 2020 13:18:32 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 07OKIVmt081019; Mon, 24 Aug 2020 13:18:31 -0700 (PDT) (envelope-from jmg) Date: Mon, 24 Aug 2020 13:18:31 -0700 From: John-Mark Gurney To: Ian Lepore Cc: Alexander Mishin , freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) Message-ID: <20200824201830.GF4213@funkthat.com> Mail-Followup-To: Ian Lepore , Alexander Mishin , freebsd-arm@freebsd.org References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> <20200820223918.GC4213@funkthat.com> <20200820235301.GE4213@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 24 Aug 2020 13:18:32 -0700 (PDT) X-Rspamd-Queue-Id: 4Bb3Nc2DJmz4CvX X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [2.42 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.89)[0.890]; NEURAL_SPAM_SHORT(0.33)[0.330]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] 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: Mon, 24 Aug 2020 20:18:44 -0000 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."