From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj5Se-00012t-Oh for qemu-devel@nongnu.org; Mon, 05 Oct 2015 09:05:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zj5SY-0002QT-WA for qemu-devel@nongnu.org; Mon, 05 Oct 2015 09:05:48 -0400 Received: from foss.arm.com ([217.140.101.70]:46907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj5SY-0002P3-RL for qemu-devel@nongnu.org; Mon, 05 Oct 2015 09:05:42 -0400 Date: Mon, 5 Oct 2015 14:05:17 +0100 From: Mark Rutland Message-ID: <20151005130516.GM19064@leverpostej> References: <1443914889-9619-1-git-send-email-somlo@cmu.edu> <20151005100035.GA19064@leverpostej> <20151005124042.GF1977@HEDWIG.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151005124042.GF1977@HEDWIG.INI.CMU.EDU> Subject: Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: peter.maydell@linaro.org, paul@pwsan.com, matt.fleming@intel.com, catalin.marinas@arm.com, jordan.l.justen@intel.com, kernelnewbies@kernelnewbies.org, gregkh@linuxfoundation.org, zajec5@gmail.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, leif.lindholm@linaro.org, qemu-devel@nongnu.org, ard.biesheuvel@linaro.org, galak@codeaurora.org, mst@redhat.com, hanjun.guo@linaro.org, agross@codeaurora.org, pbonzini@redhat.com, linux-api@vger.kernel.org, lersek@redhat.com, kraxel@redhat.com > > I'm not sure I follow what the difficulty with supporting DT in addition > > to ACPI is? It looks like all you need is a compatible string and a reg > > entry. > > Bearing in mind that I have almost no experience with arm: > > I started out by probing all possible port-io and mmio locations where > fw_cfg registers might have been found, from a "classic" module_init > method. > > Arm has DT, which as far as I understand will answer the following two > questions: 1. Do I have fw_cfg ? 2. If yes, what address range does it use ? > So that I could continue using a classic module_init, but won't need > to probe for the device. > > PC (my primary architecture, the one I actually care about) does not > have DT. If I want to share the same code, I can't probe, so if I try > DT and don't find fw_cfg there (or somehow DT is no-op-ed out because > I'm on a PC guest), I could somehow look it up in ACPI the same way > (i.e., use ACPI as sort of a stand-in for DT). I'd imagine that it's simple to have something in your probe path like: if (pdev->dev.of_node) parse_dt(pdev); else parse_acpi(pdev); > But all ACPI-enabled drivers I could find use dedicated macros (i.e. > no more classic module_init() and module_exit(), but rather > module_acpi_driver() with .add and .remove methods on an acpi_driver > object, etc.) Not sure how I'd glue DT back into something like that. You don't have to use those macros, and can simply use the classic module_{init,exit} functions, calling the requisite acpi driver registration functions at module {init,exit} time. > In addition, Michael's comment earlier in the thread suggests that > even my current acpi version isn't sufficiently "orthodox" w.r.t. > ACPI, and I should be providing the hardware access routine as > an ACPI/AML routine, to avoid race conditions with the rest of ACPI, > and for encapsulation. I.e. it's even rude to use the fw_cfg node's > ACPI _CRS method (the part where I'd be treating it like a DT stand-in > only to query fw_cfg's hardware specifics). As Peter stated, this sounds very much like it rules out sharing the interface with FW generally (and is certainly scary). > So far, all the information I've been able to pull together points > away from a dual DT + ACPI all-in-one solution for fw_cfg. If you know > of an example where that's done in an acceptable way, please let > me know so I can use it for inspiration... I'm not immediately aware, but I would imagine you could search for files that had both an of_match_table and a acpi_bus_register_driver call. Thanks, Mark.