From owner-svn-src-all@freebsd.org Tue Jul 19 11:22:31 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 177C6B9EC5B; Tue, 19 Jul 2016 11:22:31 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CAE381AD3; Tue, 19 Jul 2016 11:22:30 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 276383ACE3; Tue, 19 Jul 2016 13:13:34 +0200 (CEST) Subject: Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys To: Nathan Whitehorn , Svatopluk Kraus , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201606051620.u55GKD5S066398@repo.freebsd.org> From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <578E0B5D.3070105@FreeBSD.org> Date: Tue, 19 Jul 2016 13:13:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Tue, 19 Jul 2016 13:13:34 +0200 (CEST) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:22:31 -0000 Dne 19.07.2016 v 2:11 Nathan Whitehorn napsal(a): Hi Nathan, I’m afraid that skra is on vacation, for next 2 weeks (at minimum), so please don’t expect quick response. > Could you please describe what this change is in more detail? Short description is appended. > > It breaks a lot of encapsulations we have worked very hard to maintain, > moves ARM code into MI parts of the kernel, and the OFW parts violate > IEEE 1275 (the Open Firmware standard). In particular, there is no > guarantee that the interrupts for a newbus (or OF) device are encoded in > a property called "interrupts" (or, indeed, in any property at all) on > that node and there are many, many device trees where that is not the > case (e.g. ones with interrupt maps, as well as Apple hardware). By > putting that knowledge into the OF root bus device, which we have tried > to keep it out of, this enforces a standard that doesn't actually exist. Imho, this patch doesn’t change anything in this area. Only handling of “interrupts” property is changed, all other cases are unchanged (I hope). Also, INTRNG code is currently shared by ARM, ARM64 and MIPS. > > I'm hesitant to ask for reversion on something that landed 6 weeks ago > without me noticing, but this needs a lot more architectural work before > any parts of the kernel should use it. > -Nathan I think that it’s too late. This patch series consist of r301451 (https://reviews.freebsd.org/D6632), r301453, r301539 and 301543. And new GPIO interrupts are currently used (by in tree drivers or in development trees). The root of problem is that standard way of delivering interrupt resource to consumer driver doesn’t works in OFW world. So we have some fact: - the format of interrupt property is dependent of interrupt controller and only interrupt controller can parse it. - the interrupt property can have more data than just interrupt number. - single interrupt controller must be able to handle multiple format of interrupt description. In pre-patchset era, simplebus enumerates children and attempts to set memory and interrupts to resource list for them. But the interrupt controllers are not yet populated so nobody can parse interrupt property. Moreover, in all cases (parsed or not), we cannot store complete interrupt description into resource list. The patch simply postpones reading of interrupt property to bus_alloc_resource() (called by consumer driver) time. Due to this, we can: - parse interrupt property. The interrupt driver must exist at this time. - bus_alloc_resource() returns resource, so we can attach parsed interrupt data to it. By this, the resource itself can be used for delivering configuration data to subsequent call to bus_setup_intr() (or to all related bus_() calls). The patched code still accepts delivering of interrupts in resource list. Michal