From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 10:20:20 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70AAB8EB; Tue, 18 Jun 2013 10:20:20 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5741DB7; Tue, 18 Jun 2013 10:20:20 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C04DC40002; Tue, 18 Jun 2013 12:20:17 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id B2AC440005; Tue, 18 Jun 2013 12:20:17 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 1A18940002; Tue, 18 Jun 2013 12:20:15 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZQKB6NB8z8hVn; Tue, 18 Jun 2013 12:20:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id u4RXIZ1z-SlV; Tue, 18 Jun 2013 12:20:12 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZQK82PRrz8hVm; Tue, 18 Jun 2013 12:20:12 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3bZQK80YdTz9Ctq; Tue, 18 Jun 2013 12:20:12 +0200 (CEST) Message-ID: <51C0345E.4000309@freebsd.org> Date: Tue, 18 Jun 2013 12:20:14 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: arch@freebsd.org Subject: Bus space routines Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130618-0, 2013-06-18), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:20:20 -0000 This has been discussed before [1], but there seem to still be a lack of consensus, so I'll ask again. Should in*/out* macros or bus_space* functions be used in userland code? The background is that the port devel/libpciaccess uses these routines on FreeBSD. In a first incarnation it used the bus_space* routines, see this patch: http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 This was later changed to use the in*/out* macros directly, with the motivation that the bus_space* functions is a KPI that shouldn't be used in userland. See following for an updated patch: http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 The problem is that the in*/out* macros differ between FreeBSD and Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use bus_space* again. My question is simply, which one is correct, or should libpciaccess be reworked in a completely different way? I hope everything is clear in the above, otherwise poke me and I'll explain further. Regards! -- Niclas [1] http://lists.freebsd.org/pipermail/freebsd-arch/2012-March/012470.html From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 10:56:16 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E78EA2E0; Tue, 18 Jun 2013 10:56:16 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id 98F631F55; Tue, 18 Jun 2013 10:56:16 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so2363659qej.9 for ; Tue, 18 Jun 2013 03:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r+eby7vyGNQFQ27sCOcs9rPTM29YbxNrhVg/3z6PWGg=; b=jnbrwSDac7yEKi00JZZF0rXYIoZcss2bT6JAALcfN0gcLN3aCW/tcrLLRKvrpZPoeU 54JcW174q7GkFc6FX04DpZbDxC99iFTPo506VU0LbINbsXF7pKxuooWs11PxTXghga0E aT+RLCz2qAoFaJLr2MEF51qidl50jAZF/hcJt4nW7efrWKUH4Ds+xPzKD2tGucOtL7Wm 4rKV2HTeJj5f5aWU5qtY255akukXSM3qB60wqIMX+O2EFAfesXm/HFqLznbqyMBBAePA TGimlEJy732Tr8689GQAb8/QE+J/aXCVqwHCpbR1X/isn6OgYP+cIAl3e8S51p99TSKQ dTYg== MIME-Version: 1.0 X-Received: by 10.224.211.8 with SMTP id gm8mr15822474qab.77.1371552975583; Tue, 18 Jun 2013 03:56:15 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.117.3 with HTTP; Tue, 18 Jun 2013 03:56:15 -0700 (PDT) In-Reply-To: <51C0345E.4000309@freebsd.org> References: <51C0345E.4000309@freebsd.org> Date: Tue, 18 Jun 2013 12:56:15 +0200 X-Google-Sender-Auth: WJzJ_SMyGA6o5Mm9ABmeZMnpPHc Message-ID: Subject: Re: Bus space routines From: Robert Millan To: Niclas Zeising , Bruce Evans Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:56:17 -0000 Hi Niclas, Thank you for bringing this up. 2013/6/18 Niclas Zeising > In a first incarnation it used the bus_space* routines, see > this patch: > > http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 Yes, this was my original patch. I wrote it to fix a problem on GNU/kFreeBSD. As always, I took care to do things in a way that would be likely to work on FreeBSD as well (rather than, e.g. using ). > This was later changed to use the in*/out* macros directly, with the > motivation that the bus_space* functions is a KPI that shouldn't be used > in userland. See following for an updated patch: > > http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 Actually, based on previous discussion my understanding was that it's in*/out* which wasn't ment to be used in userland: http://lists.freebsd.org/pipermail/freebsd-arch/2012-March/012470.html I'm adding Bruce Evans to CC, as he participated in that thread. I expect he can provide some insight. > The problem is that the in*/out* macros differ between FreeBSD and > Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use > bus_space* again. Well, there's part of truth in this, but it's not quite the point I was trying to make. Yes, GNU/kFreeBSD is an hybrid system, and as such in some cases it is forced to support two namespaces, because sometimes the semantics from each system just don't get along: >>>> FreeBSD code: outw(port, data); >>>> Glibc code: outw(data, port); We can cope with this problem (mostly) by forcing programs into the namespace they were expecting. But this is IMHO a more general issue, and is not just relevant to GNU/kFreeBSD. The problem is: what happens when someone reuses this code somewhere else? Then we're in for some very ugly trouble. Undefined I/O behaviour is not something I'd like to happen without notice simply because I ported some code from one system to another. I think the BSD world did the right thing by introducing new semantics. Plus they're also more portable (on the hardware sense), have a look, e.g.: static __inline void bus_space_write_1(bus_space_tag_t tag, bus_space_handle_t bsh, bus_size_t offset, u_int8_t value) { if (tag == X86_BUS_SPACE_IO) outb(bsh + offset, value); else *(volatile u_int8_t *)(bsh + offset) = value; } So why not just use those? It seems very natural to me that if you have something which is unambigous and reliable, you use this instead of something else which is prone to nasty errors. -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 10:59:34 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C87573A1; Tue, 18 Jun 2013 10:59:34 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 7930B1F64; Tue, 18 Jun 2013 10:59:34 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j8so2092829qah.10 for ; Tue, 18 Jun 2013 03:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0RQHGj2Lzwr0dPPbQinFWM3NcAQlSwkc1UJUpHeS0yk=; b=1CngH+Iv1R5EDH8bbw1/0LmKP77JubJLbaFme9qcwWZxo98QEo/L7FhtPa5jD9lNMS wx69COlOGLiG8ziM3jCf3TVsLGrq5KLzmMW02KeNEZB7hqbbuO9FmMxQfrZp3Xb7KPMF EHfzuCkSAxVYO/pDog71NB9pwAWZLt26QdJ0WjbSgjfYHfmQp9f9PgrsSTahdDCIT+/j kbAv50j6QcQVwROQCvzIYD3mAinMsubH0E8Sg+iFgp9JqNZU4U1+EWi0z/xnhjT/Ryg/ LDtvnlAUIGWuj3wOGupMBFHPZnWE+xa2TFVmNfs4NGjZeObfTq7IaJLR0zHg+2WnooPe oNqg== MIME-Version: 1.0 X-Received: by 10.229.144.14 with SMTP id x14mr2071439qcu.36.1371553173944; Tue, 18 Jun 2013 03:59:33 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.117.3 with HTTP; Tue, 18 Jun 2013 03:59:33 -0700 (PDT) In-Reply-To: References: <51C0345E.4000309@freebsd.org> Date: Tue, 18 Jun 2013 12:59:33 +0200 X-Google-Sender-Auth: RCkbE2BYAhmYV2bs3AWFXvmpp7M Message-ID: Subject: Re: Bus space routines From: Robert Millan To: Niclas Zeising , Bruce Evans Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:59:34 -0000 2013/6/18 Robert Millan : > static __inline void > bus_space_write_1(bus_space_tag_t tag, bus_space_handle_t bsh, > bus_size_t offset, u_int8_t value) > { > > if (tag == X86_BUS_SPACE_IO) > outb(bsh + offset, value); > else > *(volatile u_int8_t *)(bsh + offset) = value; > } > > So why not just use those? It seems very natural to me that if you > have something which is unambigous and reliable, you use this instead > of something else which is prone to nasty errors. (Yes, I'm aware that GNU systems in general don't have this, and that using bus_space_* would introduce a portability nuissance, but IMHO this is much better than encouraging them to use the non-portable from Glibc right away. At least this forces them to think about what they're doing) -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 11:13:53 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF977727; Tue, 18 Jun 2013 11:13:53 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 57D4B1FED; Tue, 18 Jun 2013 11:13:53 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5IBDpZU044128; Tue, 18 Jun 2013 13:13:51 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5IBDpg5044127; Tue, 18 Jun 2013 13:13:51 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Jun 2013 13:13:51 +0200 From: Marius Strobl To: Niclas Zeising Subject: Re: Bus space routines Message-ID: <20130618111351.GA43938@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C0345E.4000309@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:13:53 -0000 On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising wrote: > This has been discussed before [1], but there seem to still be a lack of > consensus, so I'll ask again. > > Should in*/out* macros or bus_space* functions be used in userland code? > The background is that the port devel/libpciaccess uses these routines > on FreeBSD. In a first incarnation it used the bus_space* routines, see > this patch: > > http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 > > This was later changed to use the in*/out* macros directly, with the > motivation that the bus_space* functions is a KPI that shouldn't be used > in userland. See following for an updated patch: > > http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 > > The problem is that the in*/out* macros differ between FreeBSD and > Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use > bus_space* again. > > My question is simply, which one is correct, or should libpciaccess be > reworked in a completely different way? The latter; in*/out*() are somewhat okay if you want to restrict this to work on x86 without PCI domains only. The above approach to using bus_space(9) is one big hack, though. The right way for employing that API is to allocate the corresponding bus resource of a particular device and then to obtain bus tag and handle via rman_get_bus{tag,handle}(9) - which won't work from userland, however. The shortcut to just stick in {AMD64,I386}_BUS_SPACE_IO instead is totally unportable as generally a bus tag isn't a mere constant and also may depend on which PCI bus and domain a particular device is located on/in. What we really need is a proper interface allowing userland to access PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess to build upon that, i. e. essentially the same as things work on/with Linux and /sys/bus/pci/device. As a side-effect this then also permits to properly sanity check PCI accesses from userland within the kernel. Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 11:27:06 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0B8089F5; Tue, 18 Jun 2013 11:27:06 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id B2B2210FB; Tue, 18 Jun 2013 11:27:05 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2CE0740013; Tue, 18 Jun 2013 13:27:04 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 22FB940005; Tue, 18 Jun 2013 13:27:04 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id EF2B240002; Tue, 18 Jun 2013 13:27:02 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZRpF5SkDz8hVn; Tue, 18 Jun 2013 13:27:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id teyDhAF1zkno; Tue, 18 Jun 2013 13:26:59 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZRpC2LMzz8hVm; Tue, 18 Jun 2013 13:26:59 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3bZRpB4lt0z9Ctq; Tue, 18 Jun 2013 13:26:58 +0200 (CEST) Message-ID: <51C04404.3080509@freebsd.org> Date: Tue, 18 Jun 2013 13:27:00 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Robert Millan Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130618-0, 2013-06-18), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:27:06 -0000 On 2013-06-18 12:56, Robert Millan wrote: > Hi Niclas, > > Thank you for bringing this up. > > 2013/6/18 Niclas Zeising >> In a first incarnation it used the bus_space* routines, see >> this patch: >> >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 > > Yes, this was my original patch. I wrote it to fix a problem on > GNU/kFreeBSD. As always, I took care to do things in a way that would > be likely to work on FreeBSD as well (rather than, e.g. using > ). And for that you have my gratitude, it was very nice to be able to take the patch from debian instead of having to try to make something myself. > >> This was later changed to use the in*/out* macros directly, with the >> motivation that the bus_space* functions is a KPI that shouldn't be used >> in userland. See following for an updated patch: >> >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 > > Actually, based on previous discussion my understanding was that it's > in*/out* which wasn't ment to be used in userland: > > http://lists.freebsd.org/pipermail/freebsd-arch/2012-March/012470.html I have no idea what's the correct or best way, that's why I brought it up again, to get some sort of consensus. :) Regards! -- Niclas From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 11:30:38 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02DB4A78 for ; Tue, 18 Jun 2013 11:30:38 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 752C0111E for ; Tue, 18 Jun 2013 11:30:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AC2A340002 for ; Tue, 18 Jun 2013 13:30:36 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 96F7D40005; Tue, 18 Jun 2013 13:30:36 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D10ED40002; Tue, 18 Jun 2013 13:30:34 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZRtL3flMz8hVn; Tue, 18 Jun 2013 13:30:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id 4pM9c5v6a6HA; Tue, 18 Jun 2013 13:30:32 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZRtH6qbMz8hVm; Tue, 18 Jun 2013 13:30:31 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3bZRtH5v32z9Ctq; Tue, 18 Jun 2013 13:30:31 +0200 (CEST) Message-ID: <51C044DA.8030406@freebsd.org> Date: Tue, 18 Jun 2013 13:30:34 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> In-Reply-To: <20130618111351.GA43938@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130618-0, 2013-06-18), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:30:38 -0000 On 2013-06-18 13:13, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising wrote: >> This has been discussed before [1], but there seem to still be a lack of >> consensus, so I'll ask again. >> >> Should in*/out* macros or bus_space* functions be used in userland code? >> The background is that the port devel/libpciaccess uses these routines >> on FreeBSD. In a first incarnation it used the bus_space* routines, see >> this patch: >> >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 >> >> This was later changed to use the in*/out* macros directly, with the >> motivation that the bus_space* functions is a KPI that shouldn't be used >> in userland. See following for an updated patch: >> >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 >> >> The problem is that the in*/out* macros differ between FreeBSD and >> Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use >> bus_space* again. >> >> My question is simply, which one is correct, or should libpciaccess be >> reworked in a completely different way? > > The latter; in*/out*() are somewhat okay if you want to restrict this > to work on x86 without PCI domains only. The above approach to using > bus_space(9) is one big hack, though. The right way for employing that > API is to allocate the corresponding bus resource of a particular device > and then to obtain bus tag and handle via rman_get_bus{tag,handle}(9) - > which won't work from userland, however. The shortcut to just stick in > {AMD64,I386}_BUS_SPACE_IO instead is totally unportable as generally > a bus tag isn't a mere constant and also may depend on which PCI bus > and domain a particular device is located on/in. > What we really need is a proper interface allowing userland to access > PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess > to build upon that, i. e. essentially the same as things work on/with > Linux and /sys/bus/pci/device. As a side-effect this then also permits > to properly sanity check PCI accesses from userland within the kernel. > > Marius > That is true, however, it won't build itself today, and we need to have this working in the meantime, so what do you suggest we use for now? Also, as a side note, how hard would it be to implement this API, do you think? Is it something a junior hacker (that is, me) can do? Regards! -- Niclas From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 12:40:40 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9EE8D855; Tue, 18 Jun 2013 12:40:40 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6661788; Tue, 18 Jun 2013 12:40:39 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5ICecos053937; Tue, 18 Jun 2013 14:40:38 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5ICecxK053936; Tue, 18 Jun 2013 14:40:38 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Jun 2013 14:40:38 +0200 From: Marius Strobl To: Niclas Zeising Subject: Re: Bus space routines Message-ID: <20130618124038.GV53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C044DA.8030406@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 12:40:40 -0000 On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising wrote: > On 2013-06-18 13:13, Marius Strobl wrote: > > On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising wrote: > >> This has been discussed before [1], but there seem to still be a lack of > >> consensus, so I'll ask again. > >> > >> Should in*/out* macros or bus_space* functions be used in userland code? > >> The background is that the port devel/libpciaccess uses these routines > >> on FreeBSD. In a first incarnation it used the bus_space* routines, see > >> this patch: > >> > >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 > >> > >> This was later changed to use the in*/out* macros directly, with the > >> motivation that the bus_space* functions is a KPI that shouldn't be used > >> in userland. See following for an updated patch: > >> > >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 > >> > >> The problem is that the in*/out* macros differ between FreeBSD and > >> Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use > >> bus_space* again. > >> > >> My question is simply, which one is correct, or should libpciaccess be > >> reworked in a completely different way? > > > > The latter; in*/out*() are somewhat okay if you want to restrict this > > to work on x86 without PCI domains only. The above approach to using > > bus_space(9) is one big hack, though. The right way for employing that > > API is to allocate the corresponding bus resource of a particular device > > and then to obtain bus tag and handle via rman_get_bus{tag,handle}(9) - > > which won't work from userland, however. The shortcut to just stick in > > {AMD64,I386}_BUS_SPACE_IO instead is totally unportable as generally > > a bus tag isn't a mere constant and also may depend on which PCI bus > > and domain a particular device is located on/in. > > What we really need is a proper interface allowing userland to access > > PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess > > to build upon that, i. e. essentially the same as things work on/with > > Linux and /sys/bus/pci/device. As a side-effect this then also permits > > to properly sanity check PCI accesses from userland within the kernel. > > > > That is true, however, it won't build itself today, and we need to have > this working in the meantime, so what do you suggest we use for now? That's hard to say as architecturally neither in*/out*() nor bus_space(9) are the way to proceed. Tentatively, I'd go with abusing the latter as that approach _should_ allow to make things additionally work one another one or two architectures - in particular powerpc - without introducing an #ifdef hell. > Also, as a side note, how hard would it be to implement this API, do you > think? Is it something a junior hacker (that is, me) can do? Well, I'd say that technically this shouldn't be hard to do but mainly a question of having the time to implement and test it. In other words, IMO this would make a rather good GSOC project or generally a great opportunity to get ones feet wet in kernel and API land. Probably, the main issue here is that - from looking at the libpciaccess sources - none of the supported OS currently provides such an interface that is really sound and, thus, may serve as a viable reference. The Linux sysfs method at least should illustrate what is required from a functionality point of view, though. Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 12:50:37 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 869AEC7A for ; Tue, 18 Jun 2013 12:50:37 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 17FD8180B for ; Tue, 18 Jun 2013 12:50:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 91DCD40016 for ; Tue, 18 Jun 2013 14:50:35 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 87CB740015; Tue, 18 Jun 2013 14:50:35 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id E9F6340005; Tue, 18 Jun 2013 14:50:34 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZTff3p1Fz8hVn; Tue, 18 Jun 2013 14:50:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id D72NiPHUyU29; Tue, 18 Jun 2013 14:50:31 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZTfb65F1z8hVm; Tue, 18 Jun 2013 14:50:31 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3bZTfb5X2sz9Ctq; Tue, 18 Jun 2013 14:50:31 +0200 (CEST) Message-ID: <51C05799.30304@freebsd.org> Date: Tue, 18 Jun 2013 14:50:33 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> In-Reply-To: <20130618124038.GV53058@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130618-0, 2013-06-18), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 12:50:37 -0000 On 2013-06-18 14:40, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising wrote: >> On 2013-06-18 13:13, Marius Strobl wrote: >>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising wrote: >>>> This has been discussed before [1], but there seem to still be a lack of >>>> consensus, so I'll ask again. >>>> >>>> Should in*/out* macros or bus_space* functions be used in userland code? >>>> The background is that the port devel/libpciaccess uses these routines >>>> on FreeBSD. In a first incarnation it used the bus_space* routines, see >>>> this patch: >>>> >>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 >>>> >>>> This was later changed to use the in*/out* macros directly, with the >>>> motivation that the bus_space* functions is a KPI that shouldn't be used >>>> in userland. See following for an updated patch: >>>> >>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 >>>> >>>> The problem is that the in*/out* macros differ between FreeBSD and >>>> Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use >>>> bus_space* again. >>>> >>>> My question is simply, which one is correct, or should libpciaccess be >>>> reworked in a completely different way? >>> >>> The latter; in*/out*() are somewhat okay if you want to restrict this >>> to work on x86 without PCI domains only. The above approach to using >>> bus_space(9) is one big hack, though. The right way for employing that >>> API is to allocate the corresponding bus resource of a particular device >>> and then to obtain bus tag and handle via rman_get_bus{tag,handle}(9) - >>> which won't work from userland, however. The shortcut to just stick in >>> {AMD64,I386}_BUS_SPACE_IO instead is totally unportable as generally >>> a bus tag isn't a mere constant and also may depend on which PCI bus >>> and domain a particular device is located on/in. >>> What we really need is a proper interface allowing userland to access >>> PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess >>> to build upon that, i. e. essentially the same as things work on/with >>> Linux and /sys/bus/pci/device. As a side-effect this then also permits >>> to properly sanity check PCI accesses from userland within the kernel. >>> >> >> That is true, however, it won't build itself today, and we need to have >> this working in the meantime, so what do you suggest we use for now? > > That's hard to say as architecturally neither in*/out*() nor bus_space(9) > are the way to proceed. Tentatively, I'd go with abusing the latter as > that approach _should_ allow to make things additionally work one another > one or two architectures - in particular powerpc - without introducing > an #ifdef hell. Ok. I'll see if someone else chimes in on this, otherwise we'll switch back to bus_space(9) for now. > >> Also, as a side note, how hard would it be to implement this API, do you >> think? Is it something a junior hacker (that is, me) can do? > > Well, I'd say that technically this shouldn't be hard to do but mainly > a question of having the time to implement and test it. In other words, > IMO this would make a rather good GSOC project or generally a great > opportunity to get ones feet wet in kernel and API land. Probably, the > main issue here is that - from looking at the libpciaccess sources - > none of the supported OS currently provides such an interface that is > really sound and, thus, may serve as a viable reference. The Linux > sysfs method at least should illustrate what is required from a > functionality point of view, though. I'll have a look at this, as you said, it might be a good way to get my feet wet and see of stuff works. I can always throw it out if I fail, and ask around on mailing lists for guidance and help. Regards! -- Niclas From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 15:22:24 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5BBC4283; Tue, 18 Jun 2013 15:22:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 823C710BE; Tue, 18 Jun 2013 15:22:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA17185; Tue, 18 Jun 2013 18:18:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <51C07A2F.3060504@FreeBSD.org> Date: Tue, 18 Jun 2013 18:18:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> In-Reply-To: <20130618111351.GA43938@alchemy.franken.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:22:24 -0000 on 18/06/2013 14:13 Marius Strobl said the following: > What we really need is a proper interface allowing userland to access > PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess > to build upon that, i. e. essentially the same as things work on/with > Linux and /sys/bus/pci/device. As a side-effect this then also permits > to properly sanity check PCI accesses from userland within the kernel. We have this pciconf utility (in base), which can read PCI config registers (and more). Apparently it uses some ioctl interface of /dev/pci. Is this the interface that you had in mind or does it lack some required capabilities? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 15:25:52 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 353EA4A4 for ; Tue, 18 Jun 2013 15:25:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 0823410E8 for ; Tue, 18 Jun 2013 15:25:51 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id 9so10221598iec.19 for ; Tue, 18 Jun 2013 08:25:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=nkcL2W9l6zOtY5Zsf2Pld7t6HtfW12P12fXuIgSAMNw=; b=kJhscJGjMD0oVKV2ZLqm9UbrD2V2vilN4iko6s3Sa+36AC8E+n+24QJlNrlFttVUBI uvupHUDLAgEF2mHwc0Gqd2OwrmcAXP16XXIsuGCBZ3nYW+KovjBAYOiFqxRlKdLCKnkI nas/y1fytL8/E8ySlO1PTv7WW/2qQ7w72VJHVSvRKdXZTgCnlCPH88u4eAY3NAKWW4sw IdzwNOeFKG58/Unolru+IFvKPB9hNrWOeAYRWCriRpCMOqXHg05gTfGlr8hsIgm2Hzc1 x9kG8RKUY5J007E0+LzjJls+BrATqQjyMWguB1Z7jxX9+HP6s8DWmpHILc/HoWs7ynS0 zflQ== X-Received: by 10.50.111.129 with SMTP id ii1mr7931623igb.47.1371569151677; Tue, 18 Jun 2013 08:25:51 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id wn10sm1492121igb.2.2013.06.18.08.25.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 08:25:49 -0700 (PDT) Sender: Warner Losh Subject: Re: Bus space routines Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51C07A2F.3060504@FreeBSD.org> Date: Tue, 18 Jun 2013 09:25:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C07A2F.3060504@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlw0QS2TngbWH3ltGRx6R8RLa1E4yzLOhM/Q4J6UVEGEEI5sSNAkOa6obp13GDkO8+3zLES Cc: arch@FreeBSD.org, Niclas Zeising , Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:25:52 -0000 On Jun 18, 2013, at 9:18 AM, Andriy Gapon wrote: > on 18/06/2013 14:13 Marius Strobl said the following: >> What we really need is a proper interface allowing userland to access >> PCI I/O and memory registers, f. e. via /dev/pci, and for = libpciaccess >> to build upon that, i. e. essentially the same as things work on/with >> Linux and /sys/bus/pci/device. As a side-effect this then also = permits >> to properly sanity check PCI accesses from userland within the = kernel. >=20 > We have this pciconf utility (in base), which can read PCI config = registers (and > more). Apparently it uses some ioctl interface of /dev/pci. > Is this the interface that you had in mind or does it lack some = required capabilities? It reads config space registers. This thread is about memory and/or I/O = spaces that are mapped via BARs on the device. We have no generic = interface to do that (although adding a memory mapped one for memory = BARs wouldn't be hard). Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 15:45:13 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CC29DBFB; Tue, 18 Jun 2013 15:45:13 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6B65F1248; Tue, 18 Jun 2013 15:45:13 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5IFjCsP071539; Tue, 18 Jun 2013 17:45:12 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5IFjCVS071538; Tue, 18 Jun 2013 17:45:12 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Jun 2013 17:45:11 +0200 From: Marius Strobl To: Andriy Gapon Subject: Re: Bus space routines Message-ID: <20130618154511.GY53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C07A2F.3060504@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C07A2F.3060504@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org, Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:45:13 -0000 On Tue, Jun 18, 2013 at 06:18:07PM +0300, Andriy Gapon wrote: > on 18/06/2013 14:13 Marius Strobl said the following: > > What we really need is a proper interface allowing userland to access > > PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess > > to build upon that, i. e. essentially the same as things work on/with > > Linux and /sys/bus/pci/device. As a side-effect this then also permits > > to properly sanity check PCI accesses from userland within the kernel. > > We have this pciconf utility (in base), which can read PCI config registers (and > more). Apparently it uses some ioctl interface of /dev/pci. > Is this the interface that you had in mind or does it lack some required capabilities? > Currently, that pci(4) userland interface is limited to configuration space only (and libpciaccess indeed already makes use of it for that purpose). What Xorg now additionally requires from such an interface is access to I/O and/or (haven't looked at it in that detail so far) memory registers of PCI devices. Extending /dev/pci to also provide this, thus, certainly is one proper way to go. As a side-note, unfortunately, at least struct pci_conf and pci_match_conf aren't particularly well-thought when it comes to implementing backwards compatibility to previous versions of that interface etc. What we still lack f. e. is support for 32-bit applications using that API on a 64-bit kernel. Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 17:59:10 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4D20594; Tue, 18 Jun 2013 17:59:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 751611A9D; Tue, 18 Jun 2013 17:59:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5IHx0Za094173; Tue, 18 Jun 2013 20:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5IHx0Za094173 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5IHx0CO094172; Tue, 18 Jun 2013 20:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Jun 2013 20:59:00 +0300 From: Konstantin Belousov To: Marius Strobl Subject: Re: Bus space routines Message-ID: <20130618175900.GY91021@kib.kiev.ua> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C07A2F.3060504@FreeBSD.org> <20130618154511.GY53058@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S2CovAv8lqFB/Tem" Content-Disposition: inline In-Reply-To: <20130618154511.GY53058@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@FreeBSD.org, Andriy Gapon , Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:59:10 -0000 --S2CovAv8lqFB/Tem Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2013 at 05:45:11PM +0200, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 06:18:07PM +0300, Andriy Gapon wrote: > > on 18/06/2013 14:13 Marius Strobl said the following: > > > What we really need is a proper interface allowing userland to access > > > PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess > > > to build upon that, i. e. essentially the same as things work on/with > > > Linux and /sys/bus/pci/device. As a side-effect this then also permits > > > to properly sanity check PCI accesses from userland within the kernel. > >=20 > > We have this pciconf utility (in base), which can read PCI config regis= ters (and > > more). Apparently it uses some ioctl interface of /dev/pci. > > Is this the interface that you had in mind or does it lack some require= d capabilities? > >=20 >=20 > Currently, that pci(4) userland interface is limited to configuration > space only (and libpciaccess indeed already makes use of it for that > purpose). What Xorg now additionally requires from such an interface is > access to I/O and/or (haven't looked at it in that detail so far) memory > registers of PCI devices. Extending /dev/pci to also provide this, thus, > certainly is one proper way to go. As a side-note, unfortunately, at > least struct pci_conf and pci_match_conf aren't particularly well-thought > when it comes to implementing backwards compatibility to previous versions > of that interface etc. What we still lack f. e. is support for 32-bit > applications using that API on a 64-bit kernel. Do we ? It seems there are compat32 shims in dev/pci/pci_user.c. I just checked 32bit pciconf(8) on 64bit host. --S2CovAv8lqFB/Tem Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRwJ/jAAoJEJDCuSvBvK1Bgs0P/15DfXbgAlVzxakQwYK4yL9m hbNa2I7MKI5O4uRFxgwv3GKnKM4Pbn3asUsLlSEDXwhfEhMTn8aICwWsrt9m+IWv 8dDAeYLSyLeNGRbywy0caH1IXnRl5nuXeOfzROOCf2J6yQlxpVINrW67/1X1M5cM NkxPv/wwyGX2b2Ln5a3QHQeQ1ZYNdku6DR4BfRGFD498+Dxo7gTjdOpK+/EaWfTo 7xWzmjaDffxIaBv5xx4EPLRZVMrnT0uK7DrSoNNJY168nq0Cdfg+bWnFJ5BXTyXT LtLaEdZAgJqQ3yRlNHkPfgEPrWA++uXrP3H4OrcB4qlR7dBpGN6M1GZcCzJCEEEK Utw9YAv/qL7NE0C3cmfyf1c9r/kmW1uUWenbaIQ4pbW8ZQ0b3re/np7Ozzb/JvmK RG8+mEayNMZL8nICUIpczShSFbLQLkMIJZG+OV6m2VRmWvaKC4azjwq8P1SUJ3PO 9YDUgg8PEQoV7LrMzTEod3F32TuynaE/jLLZ4bN6IKHqxkVKGlgxqR8JgrdVSOT6 BT25QkEC3hilpd3O2W+dVAe6Vzy2PtSPFZi5nBnFf77+frvIvuApgKb4WTnLK2uN Rdv2mPf+g60eD0aT0VVa6A7MaE8cDaF+u9VHYLHekeqTbWtIQNjIR0XoSDSty3h9 Ky5dPYShfLSwtuSiHJgW =MazQ -----END PGP SIGNATURE----- --S2CovAv8lqFB/Tem-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 18:18:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 3DB47D00; Tue, 18 Jun 2013 18:18:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C0A451.4010903@FreeBSD.org> Date: Tue, 18 Jun 2013 14:17:53 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> In-Reply-To: <20130618124038.GV53058@alchemy.franken.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:18:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising wrote: >> On 2013-06-18 13:13, Marius Strobl wrote: >>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising >>> wrote: >>>> This has been discussed before [1], but there seem to still >>>> be a lack of consensus, so I'll ask again. >>>> >>>> Should in*/out* macros or bus_space* functions be used in >>>> userland code? The background is that the port >>>> devel/libpciaccess uses these routines on FreeBSD. In a >>>> first incarnation it used the bus_space* routines, see this >>>> patch: >>>> >>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 >>>> >>>> >>>> This was later changed to use the in*/out* macros directly, with the >>>> motivation that the bus_space* functions is a KPI that >>>> shouldn't be used in userland. See following for an updated >>>> patch: >>>> >>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 >>>> >>>> >>>> The problem is that the in*/out* macros differ between FreeBSD and >>>> Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to >>>> use bus_space* again. >>>> >>>> My question is simply, which one is correct, or should >>>> libpciaccess be reworked in a completely different way? >>> >>> The latter; in*/out*() are somewhat okay if you want to >>> restrict this to work on x86 without PCI domains only. The >>> above approach to using bus_space(9) is one big hack, though. >>> The right way for employing that API is to allocate the >>> corresponding bus resource of a particular device and then to >>> obtain bus tag and handle via rman_get_bus{tag,handle}(9) - >>> which won't work from userland, however. The shortcut to just >>> stick in {AMD64,I386}_BUS_SPACE_IO instead is totally >>> unportable as generally a bus tag isn't a mere constant and >>> also may depend on which PCI bus and domain a particular device >>> is located on/in. What we really need is a proper interface >>> allowing userland to access PCI I/O and memory registers, f. e. >>> via /dev/pci, and for libpciaccess to build upon that, i. e. >>> essentially the same as things work on/with Linux and >>> /sys/bus/pci/device. As a side-effect this then also permits to >>> properly sanity check PCI accesses from userland within the >>> kernel. >>> >> >> That is true, however, it won't build itself today, and we need >> to have this working in the meantime, so what do you suggest we >> use for now? > > That's hard to say as architecturally neither in*/out*() nor > bus_space(9) are the way to proceed. Tentatively, I'd go with > abusing the latter as that approach _should_ allow to make things > additionally work one another one or two architectures - in > particular powerpc - without introducing an #ifdef hell. AFAIK, bus_space(9) can only work for amd64 and i386 in userland by pure luck. It can never work for powerpc if I'm reading the MD headers correctly. Also, I strongly disagree with abusing bus_space because it gives a bad example. Jung-uk Kim >> Also, as a side note, how hard would it be to implement this API, >> do you think? Is it something a junior hacker (that is, me) can >> do? > > Well, I'd say that technically this shouldn't be hard to do but > mainly a question of having the time to implement and test it. In > other words, IMO this would make a rather good GSOC project or > generally a great opportunity to get ones feet wet in kernel and > API land. Probably, the main issue here is that - from looking at > the libpciaccess sources - none of the supported OS currently > provides such an interface that is really sound and, thus, may > serve as a viable reference. The Linux sysfs method at least should > illustrate what is required from a functionality point of view, > though. > > Marius -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwKRRAAoJECXpabHZMqHO5nIIAIjHmaY76EkvsRtWt3UA7H37 b6ObZOQiFyEJYEA2T6ArwML0IqNjMiMbdUgEEDpuctLe7CIh8YmfWOWqWVZg07sD G0g5RqV06UnOV0FS1Agqa1PbAuG6AFsBdvqKaOIOkQhyvz3Doh4FWUzLW7qFXRqZ ok1wcs5I3nqYIHKFtUDZzMAUgOJGbLxio/ROg4/lR8FgImWvOto8Vy/++CzrRn4U pDgiqFjIq39T4bIT0EoizCTpdys64USRp7+glUJXDnGBWPCIeauI3uxSizJcHuK4 4kZlBYilq0WJ5x6Hdw4UWtrA5jgV3DcWiwFPK6ktv1MUF9YLNY4bKKJKDIeg+1M= =2ZDI -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 18:51:09 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id C2E92447; Tue, 18 Jun 2013 18:51:08 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C0AC01.8070007@FreeBSD.org> Date: Tue, 18 Jun 2013 14:50:41 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Robert Millan Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:51:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 06:56:15 -0400, Robert Millan wrote: > I think the BSD world did the right thing by introducing new > semantics. Plus they're also more portable (on the hardware > sense), have a look, e.g.: ... > So why not just use those? It seems very natural to me that if you > have something which is unambigous and reliable, you use this > instead of something else which is prone to nasty errors. bus_space(9!) is KPI and it must not be used on userland. Actually, it only works on X86 by pure luck, e.g., bus_space_tag_t is an integral type, it has very simple instructions to directly access I/O space, etc. Please use GNU libc for Debian until we implement proper API. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwKwAAAoJECXpabHZMqHOs+kH/RGnfuVQK4VkVOuI2HalxV38 /ntERblLlhJjWUdBbNT/ARarSdU9tF1/h9wVGlXEFNWzVUG+Pd3X28VOYrpdNFw6 gQspxQiwO9XDv9iPaZDEjI6wKMS5G6RLzYzpKT0y1xdvtpVcqpJ+VR62nUU9fewW uP78be+1WcqKLuWOIuYsTNGx9isdmrOd2yiA7zinNNjrfAievwxeu+AokAuWWO7q 623v0ePg8e0/lBranAQ3PecK1Mj8JnQa9iySxOiWh7I2HfZbOa6b5eu+suXSPX4L 9ygCzOSaXbp98ASQiKbHUII5/CQyK7JkVhR4upem+H9ZvXFRPHX5ZDXmKYueNE4= =gKtu -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 19:17:18 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D19D5F52 for ; Tue, 18 Jun 2013 19:17:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id A19361E80 for ; Tue, 18 Jun 2013 19:17:18 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id aq17so11108055iec.22 for ; Tue, 18 Jun 2013 12:17:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=XjfINV4cJeL8hKFqMQJOwsqG2VVDzTnB04FuQk0RF3M=; b=DQUDdwFqkKPa0L/Km4Uuqq9szSbJMVbfhr3ex++T4ZfgWjM2Aou9zIhCHkeNFkDJhI GjLXBkX4Z860aH5qBfFsqWHtEeDgTjTFt/qQUoTlQDHk/GYnrHGunHHpAteuirkd49Vv NGdjDZP24UZfS1GzV5+E8usfApJyz1Q+TXC24zciypKiYB0UPMjSxIDlVQz6At/IdHz1 TxxGFS8idd3q0J8I1ZNnfL/bd3+ALh1bV96Y+tvWk+uMlIzR6od9I/BTOT+EBU+afukr 0XX/PxZgz8B3y1cNzTEPY8wGAI3f6IuaZ5ifxNiUPoO9Vb9FYY9VyuE0LuTWey7QXcZ0 zMJQ== X-Received: by 10.50.85.114 with SMTP id g18mr8314574igz.14.1371583038328; Tue, 18 Jun 2013 12:17:18 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id fu2sm2381630igb.3.2013.06.18.12.17.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 12:17:17 -0700 (PDT) Sender: Warner Losh Subject: Re: Bus space routines Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51C0AC01.8070007@FreeBSD.org> Date: Tue, 18 Jun 2013 13:17:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1AF8EDA9-3403-49F2-B16F-B324084908FD@bsdimp.com> References: <51C0345E.4000309@freebsd.org> <51C0AC01.8070007@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmqRzA3Vm4yJjQ87WN+M0K+G5q+7C7sxwdhcTW4EzvPGDY6Bm2BDkPD69zegnGVjq5S5idq Cc: arch@freebsd.org, Niclas Zeising , Robert Millan X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:17:18 -0000 On Jun 18, 2013, at 12:50 PM, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-06-18 06:56:15 -0400, Robert Millan wrote: >> I think the BSD world did the right thing by introducing new=20 >> semantics. Plus they're also more portable (on the hardware >> sense), have a look, e.g.: > ... >> So why not just use those? It seems very natural to me that if you=20 >> have something which is unambigous and reliable, you use this >> instead of something else which is prone to nasty errors. >=20 > bus_space(9!) is KPI and it must not be used on userland. Actually, > it only works on X86 by pure luck, e.g., bus_space_tag_t is an > integral type, it has very simple instructions to directly access I/O > space, etc. There's nothing preventing a bus_space implementation in user space. = It's just that we don't have one yet, except on x86 where it works by = luck. On most architectures other than x86, however, it would likely be tricky = to implement. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 19:36:35 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 731F054D; Tue, 18 Jun 2013 19:36:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C0B6A7.10505@FreeBSD.org> Date: Tue, 18 Jun 2013 15:36:07 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Warner Losh Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <51C0AC01.8070007@FreeBSD.org> <1AF8EDA9-3403-49F2-B16F-B324084908FD@bsdimp.com> In-Reply-To: <1AF8EDA9-3403-49F2-B16F-B324084908FD@bsdimp.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Niclas Zeising , Robert Millan X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:36:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 15:17:13 -0400, Warner Losh wrote: > On Jun 18, 2013, at 12:50 PM, Jung-uk Kim wrote: >> On 2013-06-18 06:56:15 -0400, Robert Millan wrote: >>> I think the BSD world did the right thing by introducing new >>> semantics. Plus they're also more portable (on the hardware >>> sense), have a look, e.g.: >> ... >>> So why not just use those? It seems very natural to me that if >>> you have something which is unambigous and reliable, you use >>> this instead of something else which is prone to nasty errors. >> >> bus_space(9!) is KPI and it must not be used on userland. >> Actually, it only works on X86 by pure luck, e.g., >> bus_space_tag_t is an integral type, it has very simple >> instructions to directly access I/O space, etc. > > There's nothing preventing a bus_space implementation in user > space. It's just that we don't have one yet, except on x86 where it > works by luck. Yeah, that's actually what I meant to say. > On most architectures other than x86, however, it would likely be > tricky to implement. Linux implementation just uses native instructions for x86 and arm via sys/io.h. Other architectures (ab)use sysfs to expose PCI BARs to userland. http://cgit.freedesktop.org/xorg/lib/libpciaccess/tree/src/linux_sysfs.c We can simply use io(4) for non-X86 platforms. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwLanAAoJECXpabHZMqHO6UwIAI096rdiHVsY7C2vOx96MMBY W44gV04FtNqbUDNNZ0v/IwNGoUErd99t/OcVZfgGaSivTdFBZSc9yZUhSxPOXgHV W6ghgLokLedQMbmefXGuAubuXaAG0EARoxsIwipCTHuClrTlJzUtR74oSnirgKmY SK11Co70O95eWYiq4V+U3GrdyWx59WaOkKPWPzEtDb4ssrjyHNCBNFqKPAb4WY4y ginw8Or0TuUSuOK9JsDJQY1uXVdBJhe9XL+eVRfaKe6L7zEKVY3ihW12854XoKUZ pTWxAhAW9X1xIa02yhFBYieW2p1qR58n8EeOi4tSQNV7cxDMSQl7EM3RhDMmErE= =r8Hl -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 20:32:10 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C471A16; Tue, 18 Jun 2013 20:32:10 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 821E0120A; Tue, 18 Jun 2013 20:32:09 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5IKW2FV018765; Tue, 18 Jun 2013 22:32:02 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5IKW2Vt018764; Tue, 18 Jun 2013 22:32:02 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Jun 2013 22:32:02 +0200 From: Marius Strobl To: Konstantin Belousov Subject: Re: Bus space routines Message-ID: <20130618203202.GZ53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C07A2F.3060504@FreeBSD.org> <20130618154511.GY53058@alchemy.franken.de> <20130618175900.GY91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130618175900.GY91021@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org, Andriy Gapon , Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:32:10 -0000 On Tue, Jun 18, 2013 at 08:59:00PM +0300, Konstantin Belousov wrote: > On Tue, Jun 18, 2013 at 05:45:11PM +0200, Marius Strobl wrote: > > On Tue, Jun 18, 2013 at 06:18:07PM +0300, Andriy Gapon wrote: > > > on 18/06/2013 14:13 Marius Strobl said the following: > > > > What we really need is a proper interface allowing userland to access > > > > PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess > > > > to build upon that, i. e. essentially the same as things work on/with > > > > Linux and /sys/bus/pci/device. As a side-effect this then also permits > > > > to properly sanity check PCI accesses from userland within the kernel. > > > > > > We have this pciconf utility (in base), which can read PCI config registers (and > > > more). Apparently it uses some ioctl interface of /dev/pci. > > > Is this the interface that you had in mind or does it lack some required capabilities? > > > > > > > Currently, that pci(4) userland interface is limited to configuration > > space only (and libpciaccess indeed already makes use of it for that > > purpose). What Xorg now additionally requires from such an interface is > > access to I/O and/or (haven't looked at it in that detail so far) memory > > registers of PCI devices. Extending /dev/pci to also provide this, thus, > > certainly is one proper way to go. As a side-note, unfortunately, at > > least struct pci_conf and pci_match_conf aren't particularly well-thought > > when it comes to implementing backwards compatibility to previous versions > > of that interface etc. What we still lack f. e. is support for 32-bit > > applications using that API on a 64-bit kernel. > Do we ? It seems there are compat32 shims in dev/pci/pci_user.c. > Err, you're right, head has grown support for that some time ago and I accidentally used a stable/9 checkout when looking at it today (MFC after 1 week, eh :) Still, IMO the structs for such interfaces should be laid out with compatibility in mind and f. e. not employ u_long as it is the case here so these shims become as simple as possible if necessary at all. Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 20:59:45 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 583FFEF2; Tue, 18 Jun 2013 20:59:45 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id F14DE12BF; Tue, 18 Jun 2013 20:59:44 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5IKxhar018868; Tue, 18 Jun 2013 22:59:43 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5IKxhH8018867; Tue, 18 Jun 2013 22:59:43 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Jun 2013 22:59:43 +0200 From: Marius Strobl To: Jung-uk Kim Subject: Re: Bus space routines Message-ID: <20130618205943.GA53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C0A451.4010903@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:59:45 -0000 On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: > > On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising wrote: > >> On 2013-06-18 13:13, Marius Strobl wrote: > >>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising > >>> wrote: > >>>> This has been discussed before [1], but there seem to still > >>>> be a lack of consensus, so I'll ask again. > >>>> > >>>> Should in*/out* macros or bus_space* functions be used in > >>>> userland code? The background is that the port > >>>> devel/libpciaccess uses these routines on FreeBSD. In a > >>>> first incarnation it used the bus_space* routines, see this > >>>> patch: > >>>> > >>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 > >>>> > >>>> > >>>> > This was later changed to use the in*/out* macros directly, with the > >>>> motivation that the bus_space* functions is a KPI that > >>>> shouldn't be used in userland. See following for an updated > >>>> patch: > >>>> > >>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 > >>>> > >>>> > >>>> > The problem is that the in*/out* macros differ between FreeBSD and > >>>> Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to > >>>> use bus_space* again. > >>>> > >>>> My question is simply, which one is correct, or should > >>>> libpciaccess be reworked in a completely different way? > >>> > >>> The latter; in*/out*() are somewhat okay if you want to > >>> restrict this to work on x86 without PCI domains only. The > >>> above approach to using bus_space(9) is one big hack, though. > >>> The right way for employing that API is to allocate the > >>> corresponding bus resource of a particular device and then to > >>> obtain bus tag and handle via rman_get_bus{tag,handle}(9) - > >>> which won't work from userland, however. The shortcut to just > >>> stick in {AMD64,I386}_BUS_SPACE_IO instead is totally > >>> unportable as generally a bus tag isn't a mere constant and > >>> also may depend on which PCI bus and domain a particular device > >>> is located on/in. What we really need is a proper interface > >>> allowing userland to access PCI I/O and memory registers, f. e. > >>> via /dev/pci, and for libpciaccess to build upon that, i. e. > >>> essentially the same as things work on/with Linux and > >>> /sys/bus/pci/device. As a side-effect this then also permits to > >>> properly sanity check PCI accesses from userland within the > >>> kernel. > >>> > >> > >> That is true, however, it won't build itself today, and we need > >> to have this working in the meantime, so what do you suggest we > >> use for now? > > > > That's hard to say as architecturally neither in*/out*() nor > > bus_space(9) are the way to proceed. Tentatively, I'd go with > > abusing the latter as that approach _should_ allow to make things > > additionally work one another one or two architectures - in > > particular powerpc - without introducing an #ifdef hell. > > AFAIK, bus_space(9) can only work for amd64 and i386 in userland by > pure luck. It can never work for powerpc if I'm reading the MD > headers correctly. Actually, I think that by cloning bs_le_tag in userland as far as necessary, i. e. leaving out things like mapping/unmapping and allocation/deallocation etc., and using that as bus tag, bus_space(9) has a fairly good chance of working in userland for powerpc in this case. Obviously, that's harder to do than faking the bus tag for x86, though. > > Also, I strongly disagree with abusing bus_space because it gives a > bad example. Well, I strongly believe that both in*/out*() and bus_space(9) give very bad examples for userland code :) Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 21:07:17 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 75EE72E6; Tue, 18 Jun 2013 21:07:16 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C0CBE8.5030904@FreeBSD.org> Date: Tue, 18 Jun 2013 17:06:48 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> In-Reply-To: <20130618205943.GA53058@alchemy.franken.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:07:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 16:59:43 -0400, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: >>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising >>> wrote: >>>> On 2013-06-18 13:13, Marius Strobl wrote: >>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising >>>>> wrote: >>>>>> This has been discussed before [1], but there seem to >>>>>> still be a lack of consensus, so I'll ask again. >>>>>> >>>>>> Should in*/out* macros or bus_space* functions be used >>>>>> in userland code? The background is that the port >>>>>> devel/libpciaccess uses these routines on FreeBSD. In a >>>>>> first incarnation it used the bus_space* routines, see >>>>>> this patch: >>>>>> >>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 >>>>>> >>>>>> >>>>>> >> >>>>>> This was later changed to use the in*/out* macros directly, with the >>>>>> motivation that the bus_space* functions is a KPI that >>>>>> shouldn't be used in userland. See following for an >>>>>> updated patch: >>>>>> >>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 >>>>>> >>>>>> >>>>>> >> >>>>>> The problem is that the in*/out* macros differ between FreeBSD and >>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to switch back >>>>>> to use bus_space* again. >>>>>> >>>>>> My question is simply, which one is correct, or should >>>>>> libpciaccess be reworked in a completely different way? >>>>> >>>>> The latter; in*/out*() are somewhat okay if you want to >>>>> restrict this to work on x86 without PCI domains only. The >>>>> above approach to using bus_space(9) is one big hack, >>>>> though. The right way for employing that API is to allocate >>>>> the corresponding bus resource of a particular device and >>>>> then to obtain bus tag and handle via >>>>> rman_get_bus{tag,handle}(9) - which won't work from >>>>> userland, however. The shortcut to just stick in >>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally unportable as >>>>> generally a bus tag isn't a mere constant and also may >>>>> depend on which PCI bus and domain a particular device is >>>>> located on/in. What we really need is a proper interface >>>>> allowing userland to access PCI I/O and memory registers, >>>>> f. e. via /dev/pci, and for libpciaccess to build upon >>>>> that, i. e. essentially the same as things work on/with >>>>> Linux and /sys/bus/pci/device. As a side-effect this then >>>>> also permits to properly sanity check PCI accesses from >>>>> userland within the kernel. >>>>> >>>> >>>> That is true, however, it won't build itself today, and we >>>> need to have this working in the meantime, so what do you >>>> suggest we use for now? >>> >>> That's hard to say as architecturally neither in*/out*() nor >>> bus_space(9) are the way to proceed. Tentatively, I'd go with >>> abusing the latter as that approach _should_ allow to make >>> things additionally work one another one or two architectures - >>> in particular powerpc - without introducing an #ifdef hell. >> >> AFAIK, bus_space(9) can only work for amd64 and i386 in userland >> by pure luck. It can never work for powerpc if I'm reading the >> MD headers correctly. > > Actually, I think that by cloning bs_le_tag in userland as far as > necessary, i. e. leaving out things like mapping/unmapping and > allocation/deallocation etc., and using that as bus tag, > bus_space(9) has a fairly good chance of working in userland for > powerpc in this case. Obviously, that's harder to do than faking > the bus tag for x86, though. Please don't forget the point of this thread, i.e., finding simple MI interface. ;-) >> Also, I strongly disagree with abusing bus_space because it gives >> a bad example. > > Well, I strongly believe that both in*/out*() and bus_space(9) > give very bad examples for userland code :) If you insist, we can simply use io(4). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwMvoAAoJECXpabHZMqHOPyYIAL0KU/nKFtrSGSQvRAHN+oK1 3LqZL6sLTXwQgxc3DXKwoB9X/qBSvBSpxuJ0A2kiV0Kj2GBj67jepJFEXvg0jLSg Cscd6amKuH3JUwfd/Nz2BwEnGUk1WxZuJg68nKhLd2ahJA6aeIPDf3kGabw1lfEa Ef72lSA35eHjzpzEMPYFHO5gXy0y7IEWuqpeU4Ah+8AKKxC2TqKcvTysaadbwSFQ HctLchUih+cyDnmSq+Km8bjOy3Lv0IM6pGGwSRr1BuQ2LYug7zdIcBBviqKYZBJZ f5+i81ibU0K2TSfBTRwJhIi587nasyU7xIBjIADSx5mthi61bspAYIOFUp9HzfE= =ArO1 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 21:15:06 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id F341B6D3; Tue, 18 Jun 2013 21:15:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C0CDBE.40501@FreeBSD.org> Date: Tue, 18 Jun 2013 17:14:38 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> <51C0CBE8.5030904@FreeBSD.org> In-Reply-To: <51C0CBE8.5030904@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Robert Millan , Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:15:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 - -0400, Marius Strobl wrote: >> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: >>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising >>>> wrote: >>>>> On 2013-06-18 13:13, Marius Strobl wrote: >>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising >>>>>> wrote: >>>>>>> This has been discussed before [1], but there seem to >>>>>>> still be a lack of consensus, so I'll ask again. >>>>>>> >>>>>>> Should in*/out* macros or bus_space* functions be used >>>>>>> in userland code? The background is that the port >>>>>>> devel/libpciaccess uses these routines on FreeBSD. In >>>>>>> a first incarnation it used the bus_space* routines, >>>>>>> see this patch: >>>>>>> >>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> > >>>>>>> This was later changed to use the in*/out* macros directly, with the >>>>>>> motivation that the bus_space* functions is a KPI that >>>>>>> shouldn't be used in userland. See following for an >>>>>>> updated patch: >>>>>>> >>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> > >>>>>>> The problem is that the in*/out* macros differ between FreeBSD and >>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to switch >>>>>>> back to use bus_space* again. >>>>>>> >>>>>>> My question is simply, which one is correct, or should >>>>>>> libpciaccess be reworked in a completely different >>>>>>> way? >>>>>> >>>>>> The latter; in*/out*() are somewhat okay if you want to >>>>>> restrict this to work on x86 without PCI domains only. >>>>>> The above approach to using bus_space(9) is one big >>>>>> hack, though. The right way for employing that API is to >>>>>> allocate the corresponding bus resource of a particular >>>>>> device and then to obtain bus tag and handle via >>>>>> rman_get_bus{tag,handle}(9) - which won't work from >>>>>> userland, however. The shortcut to just stick in >>>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally unportable >>>>>> as generally a bus tag isn't a mere constant and also >>>>>> may depend on which PCI bus and domain a particular >>>>>> device is located on/in. What we really need is a proper >>>>>> interface allowing userland to access PCI I/O and memory >>>>>> registers, f. e. via /dev/pci, and for libpciaccess to >>>>>> build upon that, i. e. essentially the same as things >>>>>> work on/with Linux and /sys/bus/pci/device. As a >>>>>> side-effect this then also permits to properly sanity >>>>>> check PCI accesses from userland within the kernel. >>>>>> >>>>> >>>>> That is true, however, it won't build itself today, and we >>>>> need to have this working in the meantime, so what do you >>>>> suggest we use for now? >>>> >>>> That's hard to say as architecturally neither in*/out*() nor >>>> bus_space(9) are the way to proceed. Tentatively, I'd go >>>> with abusing the latter as that approach _should_ allow to >>>> make things additionally work one another one or two >>>> architectures - in particular powerpc - without introducing >>>> an #ifdef hell. >>> >>> AFAIK, bus_space(9) can only work for amd64 and i386 in >>> userland by pure luck. It can never work for powerpc if I'm >>> reading the MD headers correctly. > >> Actually, I think that by cloning bs_le_tag in userland as far as >> necessary, i. e. leaving out things like mapping/unmapping and >> allocation/deallocation etc., and using that as bus tag, >> bus_space(9) has a fairly good chance of working in userland for >> powerpc in this case. Obviously, that's harder to do than faking >> the bus tag for x86, though. > > Please don't forget the point of this thread, i.e., finding simple > MI interface. ;-) > >>> Also, I strongly disagree with abusing bus_space because it >>> gives a bad example. > >> Well, I strongly believe that both in*/out*() and bus_space(9) >> give very bad examples for userland code :) > > If you insist, we can simply use io(4). I went ahead and implemented it: http://people.freebsd.org/~jkim/libpciaccess.diff This should work with powerpc and other platforms with working io(4). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwM2+AAoJECXpabHZMqHOE48H/R1+E2H9Kww/b9STnLKih9po eD5HrRB+iQCe3qjzh328ulyvraBiCIyIf0irUMJ7H0e6k/bPQaepAcE6DURrnG1x IrB+Nntx5o+NOeq96kEaIQhD48beZfKcHao81y0+YEzYK9taE+JAOFTmGVACZFXd 2/ZqCB3wyD9gSN1WbUZQ+BNGWn4geUNDvkXgOiyov70AidaL5lkrXNuQSCAp9Mwl X1uclYYDLl9nPXtx9m/l8bxLNryL6p7ONzDRASpHhjoRiVNiYttOSnIDzJwC8mWn 3BEaqJraNjdzhpme1vV78e82/g88CWZN2NHicXqnHnAopU+Pc4RRev301Mf8zjU= =ORB9 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 21:49:59 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAF80F0D; Tue, 18 Jun 2013 21:49:59 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6973016F3; Tue, 18 Jun 2013 21:49:59 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5ILnvMU033843; Tue, 18 Jun 2013 23:49:58 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5ILnvfP033842; Tue, 18 Jun 2013 23:49:57 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Jun 2013 23:49:57 +0200 From: Marius Strobl To: Jung-uk Kim Subject: Re: Bus space routines Message-ID: <20130618214957.GB53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> <51C0CBE8.5030904@FreeBSD.org> <51C0CDBE.40501@FreeBSD.org> <51C0CFE7.6010906@niksun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C0CFE7.6010906@niksun.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "arch@freebsd.org" , Robert Millan , Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:49:59 -0000 On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim wrote: > On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: > > On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: > > 2013? 6? 18? 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 > > -0400, Marius Strobl wrote: > >>> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>>> > >>>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: > >>>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising > >>>>> wrote: > >>>>>> On 2013-06-18 13:13, Marius Strobl wrote: > >>>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising > >>>>>>> wrote: > >>>>>>>> This has been discussed before [1], but there seem to > >>>>>>>> still be a lack of consensus, so I'll ask again. > >>>>>>>> > >>>>>>>> Should in*/out* macros or bus_space* functions be used > >>>>>>>> in userland code? The background is that the port > >>>>>>>> devel/libpciaccess uses these routines on FreeBSD. In > >>>>>>>> a first incarnation it used the bus_space* routines, > >>>>>>>> see this patch: > >>>>>>>> > >>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>> > >>>>>>>> > > > >>>>>>>> > > This was later changed to use the in*/out* macros directly, with the > >>>>>>>> motivation that the bus_space* functions is a KPI that > >>>>>>>> shouldn't be used in userland. See following for an > >>>>>>>> updated patch: > >>>>>>>> > >>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>> > >>>>>>>> > > > >>>>>>>> > > The problem is that the in*/out* macros differ between FreeBSD and > >>>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to switch > >>>>>>>> back to use bus_space* again. > >>>>>>>> > >>>>>>>> My question is simply, which one is correct, or should > >>>>>>>> libpciaccess be reworked in a completely different > >>>>>>>> way? > >>>>>>> > >>>>>>> The latter; in*/out*() are somewhat okay if you want to > >>>>>>> restrict this to work on x86 without PCI domains only. > >>>>>>> The above approach to using bus_space(9) is one big > >>>>>>> hack, though. The right way for employing that API is to > >>>>>>> allocate the corresponding bus resource of a particular > >>>>>>> device and then to obtain bus tag and handle via > >>>>>>> rman_get_bus{tag,handle}(9) - which won't work from > >>>>>>> userland, however. The shortcut to just stick in > >>>>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally unportable > >>>>>>> as generally a bus tag isn't a mere constant and also > >>>>>>> may depend on which PCI bus and domain a particular > >>>>>>> device is located on/in. What we really need is a proper > >>>>>>> interface allowing userland to access PCI I/O and memory > >>>>>>> registers, f. e. via /dev/pci, and for libpciaccess to > >>>>>>> build upon that, i. e. essentially the same as things > >>>>>>> work on/with Linux and /sys/bus/pci/device. As a > >>>>>>> side-effect this then also permits to properly sanity > >>>>>>> check PCI accesses from userland within the kernel. > >>>>>>> > >>>>>> > >>>>>> That is true, however, it won't build itself today, and we > >>>>>> need to have this working in the meantime, so what do you > >>>>>> suggest we use for now? > >>>>> > >>>>> That's hard to say as architecturally neither in*/out*() nor > >>>>> bus_space(9) are the way to proceed. Tentatively, I'd go > >>>>> with abusing the latter as that approach _should_ allow to > >>>>> make things additionally work one another one or two > >>>>> architectures - in particular powerpc - without introducing > >>>>> an #ifdef hell. > >>>> > >>>> AFAIK, bus_space(9) can only work for amd64 and i386 in > >>>> userland by pure luck. It can never work for powerpc if I'm > >>>> reading the MD headers correctly. > > > >>> Actually, I think that by cloning bs_le_tag in userland as far as > >>> necessary, i. e. leaving out things like mapping/unmapping and > >>> allocation/deallocation etc., and using that as bus tag, > >>> bus_space(9) has a fairly good chance of working in userland for > >>> powerpc in this case. Obviously, that's harder to do than faking > >>> the bus tag for x86, though. > > > >> Please don't forget the point of this thread, i.e., finding simple > >> MI interface. ;-) > > > >>>> Also, I strongly disagree with abusing bus_space because it > >>>> gives a bad example. > > > >>> Well, I strongly believe that both in*/out*() and bus_space(9) > >>> give very bad examples for userland code :) > > > >> If you insist, we can simply use io(4). > > > > I went ahead and implemented it: > > > > http://people.freebsd.org/~jkim/libpciaccess.diff > > > > This should work with powerpc and other platforms with working io(4). > > I just realized powerpc does not have /dev/io, sorry. Anyway, my > point was there is userland API already and we don't have to reinvent > the wheel. > Essentially, the issue with io(4) is the same as with in*/out*(); you can't implement it in a sane way on architectures such as powerpc that have busses of different endianesses, apart from some other complications. IMO, we'll run in circles forever without a new userland interface or without extending an existing one to be able to deal with all these MD requirements (as such, thinking in the direction of the MI bus_space(9) at least in theory is the right thing but the problem is that it's an _K_PI in the first place). Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 22:03:55 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 72C6A2A1; Tue, 18 Jun 2013 22:03:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C0D92D.70608@FreeBSD.org> Date: Tue, 18 Jun 2013 18:03:25 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> <51C0CBE8.5030904@FreeBSD.org> <51C0CDBE.40501@FreeBSD.org> <51C0CFE7.6010906@niksun.com> <20130618214957.GB53058@alchemy.franken.de> In-Reply-To: <20130618214957.GB53058@alchemy.franken.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , Robert Millan , Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:03:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 17:49:57 -0400, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim wrote: >> On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: >>> On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? >>> 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 -0400, Marius >>> Strobl wrote: >>>>> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim >>>>> wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: >>>>>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas >>>>>>> Zeising wrote: >>>>>>>> On 2013-06-18 13:13, Marius Strobl wrote: >>>>>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas >>>>>>>>> Zeising wrote: >>>>>>>>>> This has been discussed before [1], but there >>>>>>>>>> seem to still be a lack of consensus, so I'll ask >>>>>>>>>> again. >>>>>>>>>> >>>>>>>>>> Should in*/out* macros or bus_space* functions be >>>>>>>>>> used in userland code? The background is that the >>>>>>>>>> port devel/libpciaccess uses these routines on >>>>>>>>>> FreeBSD. In a first incarnation it used the >>>>>>>>>> bus_space* routines, see this patch: >>>>>>>>>> >>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> This was later changed to use the in*/out* macros directly, with the >>>>>>>>>> motivation that the bus_space* functions is a KPI >>>>>>>>>> that shouldn't be used in userland. See >>>>>>>>>> following for an updated patch: >>>>>>>>>> >>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> The problem is that the in*/out* macros differ between FreeBSD and >>>>>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to >>>>>>>>>> switch back to use bus_space* again. >>>>>>>>>> >>>>>>>>>> My question is simply, which one is correct, or >>>>>>>>>> should libpciaccess be reworked in a completely >>>>>>>>>> different way? >>>>>>>>> >>>>>>>>> The latter; in*/out*() are somewhat okay if you >>>>>>>>> want to restrict this to work on x86 without PCI >>>>>>>>> domains only. The above approach to using >>>>>>>>> bus_space(9) is one big hack, though. The right way >>>>>>>>> for employing that API is to allocate the >>>>>>>>> corresponding bus resource of a particular device >>>>>>>>> and then to obtain bus tag and handle via >>>>>>>>> rman_get_bus{tag,handle}(9) - which won't work from >>>>>>>>> userland, however. The shortcut to just stick in >>>>>>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally >>>>>>>>> unportable as generally a bus tag isn't a mere >>>>>>>>> constant and also may depend on which PCI bus and >>>>>>>>> domain a particular device is located on/in. What >>>>>>>>> we really need is a proper interface allowing >>>>>>>>> userland to access PCI I/O and memory registers, f. >>>>>>>>> e. via /dev/pci, and for libpciaccess to build upon >>>>>>>>> that, i. e. essentially the same as things work >>>>>>>>> on/with Linux and /sys/bus/pci/device. As a >>>>>>>>> side-effect this then also permits to properly >>>>>>>>> sanity check PCI accesses from userland within the >>>>>>>>> kernel. >>>>>>>>> >>>>>>>> >>>>>>>> That is true, however, it won't build itself today, >>>>>>>> and we need to have this working in the meantime, so >>>>>>>> what do you suggest we use for now? >>>>>>> >>>>>>> That's hard to say as architecturally neither >>>>>>> in*/out*() nor bus_space(9) are the way to proceed. >>>>>>> Tentatively, I'd go with abusing the latter as that >>>>>>> approach _should_ allow to make things additionally >>>>>>> work one another one or two architectures - in >>>>>>> particular powerpc - without introducing an #ifdef >>>>>>> hell. >>>>>> >>>>>> AFAIK, bus_space(9) can only work for amd64 and i386 in >>>>>> userland by pure luck. It can never work for powerpc if >>>>>> I'm reading the MD headers correctly. >>> >>>>> Actually, I think that by cloning bs_le_tag in userland as >>>>> far as necessary, i. e. leaving out things like >>>>> mapping/unmapping and allocation/deallocation etc., and >>>>> using that as bus tag, bus_space(9) has a fairly good >>>>> chance of working in userland for powerpc in this case. >>>>> Obviously, that's harder to do than faking the bus tag for >>>>> x86, though. >>> >>>> Please don't forget the point of this thread, i.e., finding >>>> simple MI interface. ;-) >>> >>>>>> Also, I strongly disagree with abusing bus_space because >>>>>> it gives a bad example. >>> >>>>> Well, I strongly believe that both in*/out*() and >>>>> bus_space(9) give very bad examples for userland code :) >>> >>>> If you insist, we can simply use io(4). >>> >>> I went ahead and implemented it: >>> >>> http://people.freebsd.org/~jkim/libpciaccess.diff >>> >>> This should work with powerpc and other platforms with working >>> io(4). >> >> I just realized powerpc does not have /dev/io, sorry. Anyway, >> my point was there is userland API already and we don't have to >> reinvent the wheel. >> > > Essentially, the issue with io(4) is the same as with in*/out*(); > you can't implement it in a sane way on architectures such as > powerpc that have busses of different endianesses, apart from some > other complications. Why can't we implement it to always get/set in host byte order regardless of underlying bus? Can't the MD portion of the driver figure it out magically? > IMO, we'll run in circles forever without a new userland interface > or without extending an existing one to be able to deal with all > these MD requirements (as such, thinking in the direction of the > MI bus_space(9) at least in theory is the right thing but the > problem is that it's an _K_PI in the first place). I am also a big fan of simple API but io(4) isn't too bad, IMHO. :-) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwNksAAoJECXpabHZMqHO5dYH/363uqlIUYMhNF2+o/IkNTd/ 1E3uoRqtBuZc9Nl56aBu2X7qCRe7ndlxIzXwqUbOw/MD+ZuGFMxAemVD8HU485l1 17TAIhrLbvZShu7OqjfNYZDY6hi9LJs+7Y0NKFMj/0qQxFZZvrS1/0BrwxmMzQ3E Jr6LigLaWi5LEekoVEX1Qg7TrXb7fuRXLC3G7SJWtQMi20h/QHpo69wG9+WSugCT VCPe2t+UrJ07tHa+XFS/SAmPNZHoukIzzkFXzclskqnPXsA6M8eyTG/2SxSoevtS nob7z4WxlN0Eqkb7EIr04tO+/bu2aKDdg4yCV9SRJ7+9tMruPHFt1TDhuBy1IAg= =rv89 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 22:19:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01B7CAAD for ; Tue, 18 Jun 2013 22:19:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id C4B9817FE for ; Tue, 18 Jun 2013 22:19:20 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id ar20so10963320iec.7 for ; Tue, 18 Jun 2013 15:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+JXlQWe66vGa/74RAT/HI4T0elazTOkg6rFdlULp9Og=; b=KFI+PA06/ySMCp+4jw8vCamEdAqAsdOIM0QiSpLXkN9DcrT4I8crlGYyYsGgnVg6cl ahNh6hBtlGCulNXC+aIoxg0SD/QL6iSjFt2d3EQcUA+NaRMaJC0NAisnMLolh1f8rjnE JO140FJLlcFuNGd5tG09qgEJz7xSTGll1u892nw8lv3uFSeTPEgvzu+anWf81NnTnwdY dmMT5UUUW5joFts2BYuksyKgW0ZOB9hmsU6+Ew6E8iMuwWj3vnRF2/FqA6Mvo5pY1Igf 8EAuTbAUDAyOTZv2IP9X4PJB75FosBH6BIouXrkzCZ9ol/H8AJ6qY+3ROUPTNSffZlUG UA8w== X-Received: by 10.50.7.1 with SMTP id f1mr2242894iga.48.1371593960430; Tue, 18 Jun 2013 15:19:20 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id wn10sm3097262igb.2.2013.06.18.15.19.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:19:19 -0700 (PDT) Sender: Warner Losh Subject: Re: Bus space routines Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51C0D92D.70608@FreeBSD.org> Date: Tue, 18 Jun 2013 16:19:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> <51C0CBE8.5030904@FreeBSD.org> <51C0CDBE.40501@FreeBSD.org> <51C0CFE7.6010906@niksun.com> <20130618214957.GB53058@alchemy.franken.de> <51C0D92D.70608@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnNlCXh5wYakmXHeMz7uaDDT+DtjTMq/WdYy9z9HvDCo+aCiNWd1MvNuwj0OGXFvviDdPHs Cc: "arch@freebsd.org" , Robert Millan , Niclas Zeising , Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:19:21 -0000 On Jun 18, 2013, at 4:03 PM, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-06-18 17:49:57 -0400, Marius Strobl wrote: >> On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim wrote: >>> On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: >>>> On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? >>>> 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 -0400, Marius >>>> Strobl wrote: >>>>>> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim >>>>>> wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>>=20 >>>>>>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: >>>>>>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas >>>>>>>> Zeising wrote: >>>>>>>>> On 2013-06-18 13:13, Marius Strobl wrote: >>>>>>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas >>>>>>>>>> Zeising wrote: >>>>>>>>>>> This has been discussed before [1], but there >>>>>>>>>>> seem to still be a lack of consensus, so I'll ask >>>>>>>>>>> again. >>>>>>>>>>>=20 >>>>>>>>>>> Should in*/out* macros or bus_space* functions be >>>>>>>>>>> used in userland code? The background is that the >>>>>>>>>>> port devel/libpciaccess uses these routines on >>>>>>>>>>> FreeBSD. In a first incarnation it used the >>>>>>>>>>> bus_space* routines, see this patch: >>>>>>>>>>>=20 >>>>>>>>>>> = http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/file= s/patch-src-freebsd_pci.c?rev=3D591 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 > This was later changed to use the in*/out* macros directly, with the >>>>>>>>>>> motivation that the bus_space* functions is a KPI >>>>>>>>>>> that shouldn't be used in userland. See >>>>>>>>>>> following for an updated patch: >>>>>>>>>>>=20 >>>>>>>>>>> = http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/file= s/patch-src-freebsd_pci.c?rev=3D815 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 > The problem is that the in*/out* macros differ between FreeBSD and >>>>>>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to >>>>>>>>>>> switch back to use bus_space* again. >>>>>>>>>>>=20 >>>>>>>>>>> My question is simply, which one is correct, or >>>>>>>>>>> should libpciaccess be reworked in a completely >>>>>>>>>>> different way? >>>>>>>>>>=20 >>>>>>>>>> The latter; in*/out*() are somewhat okay if you >>>>>>>>>> want to restrict this to work on x86 without PCI >>>>>>>>>> domains only. The above approach to using >>>>>>>>>> bus_space(9) is one big hack, though. The right way >>>>>>>>>> for employing that API is to allocate the >>>>>>>>>> corresponding bus resource of a particular device >>>>>>>>>> and then to obtain bus tag and handle via=20 >>>>>>>>>> rman_get_bus{tag,handle}(9) - which won't work from >>>>>>>>>> userland, however. The shortcut to just stick in=20 >>>>>>>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally >>>>>>>>>> unportable as generally a bus tag isn't a mere >>>>>>>>>> constant and also may depend on which PCI bus and >>>>>>>>>> domain a particular device is located on/in. What >>>>>>>>>> we really need is a proper interface allowing >>>>>>>>>> userland to access PCI I/O and memory registers, f. >>>>>>>>>> e. via /dev/pci, and for libpciaccess to build upon >>>>>>>>>> that, i. e. essentially the same as things work >>>>>>>>>> on/with Linux and /sys/bus/pci/device. As a=20 >>>>>>>>>> side-effect this then also permits to properly >>>>>>>>>> sanity check PCI accesses from userland within the >>>>>>>>>> kernel. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> That is true, however, it won't build itself today, >>>>>>>>> and we need to have this working in the meantime, so >>>>>>>>> what do you suggest we use for now? >>>>>>>>=20 >>>>>>>> That's hard to say as architecturally neither >>>>>>>> in*/out*() nor bus_space(9) are the way to proceed. >>>>>>>> Tentatively, I'd go with abusing the latter as that >>>>>>>> approach _should_ allow to make things additionally >>>>>>>> work one another one or two architectures - in >>>>>>>> particular powerpc - without introducing an #ifdef >>>>>>>> hell. >>>>>>>=20 >>>>>>> AFAIK, bus_space(9) can only work for amd64 and i386 in=20 >>>>>>> userland by pure luck. It can never work for powerpc if >>>>>>> I'm reading the MD headers correctly. >>>>=20 >>>>>> Actually, I think that by cloning bs_le_tag in userland as >>>>>> far as necessary, i. e. leaving out things like >>>>>> mapping/unmapping and allocation/deallocation etc., and >>>>>> using that as bus tag, bus_space(9) has a fairly good >>>>>> chance of working in userland for powerpc in this case. >>>>>> Obviously, that's harder to do than faking the bus tag for >>>>>> x86, though. >>>>=20 >>>>> Please don't forget the point of this thread, i.e., finding >>>>> simple MI interface. ;-) >>>>=20 >>>>>>> Also, I strongly disagree with abusing bus_space because >>>>>>> it gives a bad example. >>>>=20 >>>>>> Well, I strongly believe that both in*/out*() and >>>>>> bus_space(9) give very bad examples for userland code :) >>>>=20 >>>>> If you insist, we can simply use io(4). >>>>=20 >>>> I went ahead and implemented it: >>>>=20 >>>> http://people.freebsd.org/~jkim/libpciaccess.diff >>>>=20 >>>> This should work with powerpc and other platforms with working >>>> io(4). >>>=20 >>> I just realized powerpc does not have /dev/io, sorry. Anyway, >>> my point was there is userland API already and we don't have to >>> reinvent the wheel. >>>=20 >>=20 >> Essentially, the issue with io(4) is the same as with in*/out*();=20 >> you can't implement it in a sane way on architectures such as >> powerpc that have busses of different endianesses, apart from some >> other complications. >=20 > Why can't we implement it to always get/set in host byte order > regardless of underlying bus? Can't the MD portion of the driver > figure it out magically? Not typically. Since all the world is intel, all the world is little = endian... Plus, the PCI bus is defined to be little endian, not host = endian. Not all drivers cope well with this. Warner >> IMO, we'll run in circles forever without a new userland interface >> or without extending an existing one to be able to deal with all >> these MD requirements (as such, thinking in the direction of the >> MI bus_space(9) at least in theory is the right thing but the >> problem is that it's an _K_PI in the first place). >=20 > I am also a big fan of simple API but io(4) isn't too bad, IMHO. :-) >=20 > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (FreeBSD) >=20 > iQEcBAEBAgAGBQJRwNksAAoJECXpabHZMqHO5dYH/363uqlIUYMhNF2+o/IkNTd/ > 1E3uoRqtBuZc9Nl56aBu2X7qCRe7ndlxIzXwqUbOw/MD+ZuGFMxAemVD8HU485l1 > 17TAIhrLbvZShu7OqjfNYZDY6hi9LJs+7Y0NKFMj/0qQxFZZvrS1/0BrwxmMzQ3E > Jr6LigLaWi5LEekoVEX1Qg7TrXb7fuRXLC3G7SJWtQMi20h/QHpo69wG9+WSugCT > VCPe2t+UrJ07tHa+XFS/SAmPNZHoukIzzkFXzclskqnPXsA6M8eyTG/2SxSoevtS > nob7z4WxlN0Eqkb7EIr04tO+/bu2aKDdg4yCV9SRJ7+9tMruPHFt1TDhuBy1IAg=3D > =3Drv89 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 22:45:04 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD284535; Tue, 18 Jun 2013 22:45:04 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6975018F2; Tue, 18 Jun 2013 22:45:04 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5IMj2sG035771; Wed, 19 Jun 2013 00:45:02 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5IMj1ZZ035770; Wed, 19 Jun 2013 00:45:01 +0200 (CEST) (envelope-from marius) Date: Wed, 19 Jun 2013 00:45:01 +0200 From: Marius Strobl To: Warner Losh Subject: Re: Bus space routines Message-ID: <20130618224501.GC53058@alchemy.franken.de> References: <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> <51C0CBE8.5030904@FreeBSD.org> <51C0CDBE.40501@FreeBSD.org> <51C0CFE7.6010906@niksun.com> <20130618214957.GB53058@alchemy.franken.de> <51C0D92D.70608@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "arch@freebsd.org" , Niclas Zeising , Jung-uk Kim , Robert Millan X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:45:04 -0000 On Tue, Jun 18, 2013 at 04:19:16PM -0600, Warner Losh wrote: > > On Jun 18, 2013, at 4:03 PM, Jung-uk Kim wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2013-06-18 17:49:57 -0400, Marius Strobl wrote: > >> On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim wrote: > >>> On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: > >>>> On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? > >>>> 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 -0400, Marius > >>>> Strobl wrote: > >>>>>> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim > >>>>>> wrote: > >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>>>>>> > >>>>>>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: > >>>>>>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas > >>>>>>>> Zeising wrote: > >>>>>>>>> On 2013-06-18 13:13, Marius Strobl wrote: > >>>>>>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas > >>>>>>>>>> Zeising wrote: > >>>>>>>>>>> This has been discussed before [1], but there > >>>>>>>>>>> seem to still be a lack of consensus, so I'll ask > >>>>>>>>>>> again. > >>>>>>>>>>> > >>>>>>>>>>> Should in*/out* macros or bus_space* functions be > >>>>>>>>>>> used in userland code? The background is that the > >>>>>>>>>>> port devel/libpciaccess uses these routines on > >>>>>>>>>>> FreeBSD. In a first incarnation it used the > >>>>>>>>>>> bus_space* routines, see this patch: > >>>>>>>>>>> > >>>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> > >>>>>>>>>>> > >>>> > >>>>>>>>>>> > >>>> > >>>>>>>>>>> > > This was later changed to use the in*/out* macros directly, with the > >>>>>>>>>>> motivation that the bus_space* functions is a KPI > >>>>>>>>>>> that shouldn't be used in userland. See > >>>>>>>>>>> following for an updated patch: > >>>>>>>>>>> > >>>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> > >>>>>>>>>>> > >>>> > >>>>>>>>>>> > >>>> > >>>>>>>>>>> > > The problem is that the in*/out* macros differ between FreeBSD and > >>>>>>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to > >>>>>>>>>>> switch back to use bus_space* again. > >>>>>>>>>>> > >>>>>>>>>>> My question is simply, which one is correct, or > >>>>>>>>>>> should libpciaccess be reworked in a completely > >>>>>>>>>>> different way? > >>>>>>>>>> > >>>>>>>>>> The latter; in*/out*() are somewhat okay if you > >>>>>>>>>> want to restrict this to work on x86 without PCI > >>>>>>>>>> domains only. The above approach to using > >>>>>>>>>> bus_space(9) is one big hack, though. The right way > >>>>>>>>>> for employing that API is to allocate the > >>>>>>>>>> corresponding bus resource of a particular device > >>>>>>>>>> and then to obtain bus tag and handle via > >>>>>>>>>> rman_get_bus{tag,handle}(9) - which won't work from > >>>>>>>>>> userland, however. The shortcut to just stick in > >>>>>>>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally > >>>>>>>>>> unportable as generally a bus tag isn't a mere > >>>>>>>>>> constant and also may depend on which PCI bus and > >>>>>>>>>> domain a particular device is located on/in. What > >>>>>>>>>> we really need is a proper interface allowing > >>>>>>>>>> userland to access PCI I/O and memory registers, f. > >>>>>>>>>> e. via /dev/pci, and for libpciaccess to build upon > >>>>>>>>>> that, i. e. essentially the same as things work > >>>>>>>>>> on/with Linux and /sys/bus/pci/device. As a > >>>>>>>>>> side-effect this then also permits to properly > >>>>>>>>>> sanity check PCI accesses from userland within the > >>>>>>>>>> kernel. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> That is true, however, it won't build itself today, > >>>>>>>>> and we need to have this working in the meantime, so > >>>>>>>>> what do you suggest we use for now? > >>>>>>>> > >>>>>>>> That's hard to say as architecturally neither > >>>>>>>> in*/out*() nor bus_space(9) are the way to proceed. > >>>>>>>> Tentatively, I'd go with abusing the latter as that > >>>>>>>> approach _should_ allow to make things additionally > >>>>>>>> work one another one or two architectures - in > >>>>>>>> particular powerpc - without introducing an #ifdef > >>>>>>>> hell. > >>>>>>> > >>>>>>> AFAIK, bus_space(9) can only work for amd64 and i386 in > >>>>>>> userland by pure luck. It can never work for powerpc if > >>>>>>> I'm reading the MD headers correctly. > >>>> > >>>>>> Actually, I think that by cloning bs_le_tag in userland as > >>>>>> far as necessary, i. e. leaving out things like > >>>>>> mapping/unmapping and allocation/deallocation etc., and > >>>>>> using that as bus tag, bus_space(9) has a fairly good > >>>>>> chance of working in userland for powerpc in this case. > >>>>>> Obviously, that's harder to do than faking the bus tag for > >>>>>> x86, though. > >>>> > >>>>> Please don't forget the point of this thread, i.e., finding > >>>>> simple MI interface. ;-) > >>>> > >>>>>>> Also, I strongly disagree with abusing bus_space because > >>>>>>> it gives a bad example. > >>>> > >>>>>> Well, I strongly believe that both in*/out*() and > >>>>>> bus_space(9) give very bad examples for userland code :) > >>>> > >>>>> If you insist, we can simply use io(4). > >>>> > >>>> I went ahead and implemented it: > >>>> > >>>> http://people.freebsd.org/~jkim/libpciaccess.diff > >>>> > >>>> This should work with powerpc and other platforms with working > >>>> io(4). > >>> > >>> I just realized powerpc does not have /dev/io, sorry. Anyway, > >>> my point was there is userland API already and we don't have to > >>> reinvent the wheel. > >>> > >> > >> Essentially, the issue with io(4) is the same as with in*/out*(); > >> you can't implement it in a sane way on architectures such as > >> powerpc that have busses of different endianesses, apart from some > >> other complications. > > > > Why can't we implement it to always get/set in host byte order > > regardless of underlying bus? Can't the MD portion of the driver > > figure it out magically? > > Not typically. Since all the world is intel, all the world is little endian... Plus, the PCI bus is defined to be little endian, not host endian. Not all drivers cope well with this. > These are good arguments but IMO the real hard part would be to derive the endianess and whether it's an I/O or memory mapped register etc. solely from the port address supplied via io(4)/in*/ out*(). We currently don't have any global infrastructure in the kernel to query for that information; quite the contrary, with newbus and bus_space(9) such information generally is local to a specific bus instance. Generally, there also isn't something like the fixed ISA range on x86, i. e. for example on one sparc64 machine address 0x1000 might refer to a memory mapped register on a big-endian SBus while on another one it could translate to a I/O BAR on a little- endian PCI bus. Consequently, from a kernel perspective it's way simpler if an userland interface would allow to specify "read from offset A of BAR B on PCI device C living on BUS D in domain E". Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 23:24:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E292747C; Tue, 18 Jun 2013 23:24:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 712861A5C; Tue, 18 Jun 2013 23:24:21 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5INAKKb035880; Wed, 19 Jun 2013 01:10:20 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5INAK6P035879; Wed, 19 Jun 2013 01:10:20 +0200 (CEST) (envelope-from marius) Date: Wed, 19 Jun 2013 01:10:20 +0200 From: Marius Strobl To: Warner Losh Subject: Re: Bus space routines Message-ID: <20130618231020.GA35814@alchemy.franken.de> References: <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> <51C0CBE8.5030904@FreeBSD.org> <51C0CDBE.40501@FreeBSD.org> <51C0CFE7.6010906@niksun.com> <20130618214957.GB53058@alchemy.franken.de> <51C0D92D.70608@FreeBSD.org> <20130618224501.GC53058@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130618224501.GC53058@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "arch@freebsd.org" , Niclas Zeising , Jung-uk Kim , Robert Millan X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:24:22 -0000 On Wed, Jun 19, 2013 at 12:45:01AM +0200, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 04:19:16PM -0600, Warner Losh wrote: > > > > On Jun 18, 2013, at 4:03 PM, Jung-uk Kim wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 2013-06-18 17:49:57 -0400, Marius Strobl wrote: > > >> On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim wrote: > > >>> On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: > > >>>> On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? > > >>>> 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 -0400, Marius > > >>>> Strobl wrote: > > >>>>>> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim > > >>>>>> wrote: > > >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > >>>>>>> > > >>>>>>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: > > >>>>>>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas > > >>>>>>>> Zeising wrote: > > >>>>>>>>> On 2013-06-18 13:13, Marius Strobl wrote: > > >>>>>>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas > > >>>>>>>>>> Zeising wrote: > > >>>>>>>>>>> This has been discussed before [1], but there > > >>>>>>>>>>> seem to still be a lack of consensus, so I'll ask > > >>>>>>>>>>> again. > > >>>>>>>>>>> > > >>>>>>>>>>> Should in*/out* macros or bus_space* functions be > > >>>>>>>>>>> used in userland code? The background is that the > > >>>>>>>>>>> port devel/libpciaccess uses these routines on > > >>>>>>>>>>> FreeBSD. In a first incarnation it used the > > >>>>>>>>>>> bus_space* routines, see this patch: > > >>>>>>>>>>> > > >>>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > > This was later changed to use the in*/out* macros directly, with the > > >>>>>>>>>>> motivation that the bus_space* functions is a KPI > > >>>>>>>>>>> that shouldn't be used in userland. See > > >>>>>>>>>>> following for an updated patch: > > >>>>>>>>>>> > > >>>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > > The problem is that the in*/out* macros differ between FreeBSD and > > >>>>>>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to > > >>>>>>>>>>> switch back to use bus_space* again. > > >>>>>>>>>>> > > >>>>>>>>>>> My question is simply, which one is correct, or > > >>>>>>>>>>> should libpciaccess be reworked in a completely > > >>>>>>>>>>> different way? > > >>>>>>>>>> > > >>>>>>>>>> The latter; in*/out*() are somewhat okay if you > > >>>>>>>>>> want to restrict this to work on x86 without PCI > > >>>>>>>>>> domains only. The above approach to using > > >>>>>>>>>> bus_space(9) is one big hack, though. The right way > > >>>>>>>>>> for employing that API is to allocate the > > >>>>>>>>>> corresponding bus resource of a particular device > > >>>>>>>>>> and then to obtain bus tag and handle via > > >>>>>>>>>> rman_get_bus{tag,handle}(9) - which won't work from > > >>>>>>>>>> userland, however. The shortcut to just stick in > > >>>>>>>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally > > >>>>>>>>>> unportable as generally a bus tag isn't a mere > > >>>>>>>>>> constant and also may depend on which PCI bus and > > >>>>>>>>>> domain a particular device is located on/in. What > > >>>>>>>>>> we really need is a proper interface allowing > > >>>>>>>>>> userland to access PCI I/O and memory registers, f. > > >>>>>>>>>> e. via /dev/pci, and for libpciaccess to build upon > > >>>>>>>>>> that, i. e. essentially the same as things work > > >>>>>>>>>> on/with Linux and /sys/bus/pci/device. As a > > >>>>>>>>>> side-effect this then also permits to properly > > >>>>>>>>>> sanity check PCI accesses from userland within the > > >>>>>>>>>> kernel. > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> That is true, however, it won't build itself today, > > >>>>>>>>> and we need to have this working in the meantime, so > > >>>>>>>>> what do you suggest we use for now? > > >>>>>>>> > > >>>>>>>> That's hard to say as architecturally neither > > >>>>>>>> in*/out*() nor bus_space(9) are the way to proceed. > > >>>>>>>> Tentatively, I'd go with abusing the latter as that > > >>>>>>>> approach _should_ allow to make things additionally > > >>>>>>>> work one another one or two architectures - in > > >>>>>>>> particular powerpc - without introducing an #ifdef > > >>>>>>>> hell. > > >>>>>>> > > >>>>>>> AFAIK, bus_space(9) can only work for amd64 and i386 in > > >>>>>>> userland by pure luck. It can never work for powerpc if > > >>>>>>> I'm reading the MD headers correctly. > > >>>> > > >>>>>> Actually, I think that by cloning bs_le_tag in userland as > > >>>>>> far as necessary, i. e. leaving out things like > > >>>>>> mapping/unmapping and allocation/deallocation etc., and > > >>>>>> using that as bus tag, bus_space(9) has a fairly good > > >>>>>> chance of working in userland for powerpc in this case. > > >>>>>> Obviously, that's harder to do than faking the bus tag for > > >>>>>> x86, though. > > >>>> > > >>>>> Please don't forget the point of this thread, i.e., finding > > >>>>> simple MI interface. ;-) > > >>>> > > >>>>>>> Also, I strongly disagree with abusing bus_space because > > >>>>>>> it gives a bad example. > > >>>> > > >>>>>> Well, I strongly believe that both in*/out*() and > > >>>>>> bus_space(9) give very bad examples for userland code :) > > >>>> > > >>>>> If you insist, we can simply use io(4). > > >>>> > > >>>> I went ahead and implemented it: > > >>>> > > >>>> http://people.freebsd.org/~jkim/libpciaccess.diff > > >>>> > > >>>> This should work with powerpc and other platforms with working > > >>>> io(4). > > >>> > > >>> I just realized powerpc does not have /dev/io, sorry. Anyway, > > >>> my point was there is userland API already and we don't have to > > >>> reinvent the wheel. > > >>> > > >> > > >> Essentially, the issue with io(4) is the same as with in*/out*(); > > >> you can't implement it in a sane way on architectures such as > > >> powerpc that have busses of different endianesses, apart from some > > >> other complications. > > > > > > Why can't we implement it to always get/set in host byte order > > > regardless of underlying bus? Can't the MD portion of the driver > > > figure it out magically? > > > > Not typically. Since all the world is intel, all the world is little endian... Plus, the PCI bus is defined to be little endian, not host endian. Not all drivers cope well with this. > > > > These are good arguments but IMO the real hard part would be to > derive the endianess and whether it's an I/O or memory mapped > register etc. solely from the port address supplied via io(4)/in*/ > out*(). We currently don't have any global infrastructure in the > kernel to query for that information; quite the contrary, with newbus > and bus_space(9) such information generally is local to a specific > bus instance. Well, actually that was a bit misworded; we certainly may query all bus resources in the kernel but across all architectures and busses, the addresses recorded there are not necessarily global bus addresses one can supply to the instruction performing the actual access, i. e. the addresses there may be relative to the bus a specific device lives on. Marius From owner-freebsd-arch@FreeBSD.ORG Wed Jun 19 17:25:57 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4754ACA8 for ; Wed, 19 Jun 2013 17:25:57 +0000 (UTC) (envelope-from bounces+612829-ba58-arch=freebsd.org@sendgrid.info) Received: from o1.bn.sendgrid.net (o1.bn.sendgrid.net [75.126.253.211]) by mx1.freebsd.org (Postfix) with SMTP id 023961202 for ; Wed, 19 Jun 2013 17:25:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to :subject:mime-version:content-type; s=smtpapi; bh=N/x/krRBirSBoa LcMS7U2AGlfAc=; b=UW3Qozgr2k2qo6ttuuMtXn1FJOpOLBB2SM6kSpIxP+Ggp0 vIwfpjsXGJFDNzdqtnFwctjOr0NHC5xXqWK006VgKznldzLXrDbAFlGx8/LUmjOx lryc3EK1Tcx0TLM/Lxb4VNvZAukDKZlJ8v5GGf2sB0NxGUsztxbwC9+wDbhE0= Received: by 10.42.80.20 with SMTP id filter-003.23991.51C1E7032 Wed, 19 Jun 2013 17:14:43 +0000 (UTC) Received: from (ool-18e496ee.dyn.optonline.net [24.228.150.238]) by mi21 (SG) with ESMTP id 13f5d6e6495.5f8b.127e325 for ; Wed, 19 Jun 2013 12:14:43 -0500 (CST) From: TheUrbanShopper To: Date: Wed, 19 Jun 2013 13:14:41 -0400 Subject: In this Issue: Black Cowboy Quilts, 2013 Products of the Year, Allergies Unique to Urban Areas, Big Salad Recipes X-Mailer: TOL Mailer MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_0_.__.__TOL__Mailer__Part_Boundary_ Message-ID: <1371662083.5190923996090873@filter-003> X-SG-EID: PYCKI43QWrQUfl7nqliIpR4qzPlu41Kt+60rv5InnxECdViy7TmgeFm9onWeIt04Sx/Ys4ESNNBS4Fx/oPnVbEey3u7bCfZ/VB1u9fwyhmcNC5xZgn/nUqgxHmGie9MR X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:25:57 -0000 This is a multi-part message in MIME format. --_0_.__.__TOL__Mailer__Part_Boundary_ Content-Type: multipart/related; boundary=_1_.__.__TOL__Mailer__Part_Boundary_ --_1_.__.__TOL__Mailer__Part_Boundary_ Content-Type: text/plain Content-Transfer-Encoding: 7Bit Untitled Document
Having trouble reading this email? Click Here to go direct to TheUrbanShopper.com.
To ensure delivery, please add us@theurbanshopper.com to your Safe Sender List or Address Book.
You have received this update as a subscriber to TheUrbanShopper.com. Ensure inbox delivery by adding us@theurbanshopper.com to your SAFE SENDER or email CONTACTS list. If you'd like to unsubscribe . For more information, please read our Privacy Policy . ©2013 All Rights Reserved
--_1_.__.__TOL__Mailer__Part_Boundary_-- --_0_.__.__TOL__Mailer__Part_Boundary_-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 19 17:58:45 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80D8DA2F; Wed, 19 Jun 2013 17:58:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 42307146E; Wed, 19 Jun 2013 17:58:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F4196B97C; Wed, 19 Jun 2013 13:58:41 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Bus space routines Date: Wed, 19 Jun 2013 10:56:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51C044DA.8030406@freebsd.org> <20130618224501.GC53058@alchemy.franken.de> In-Reply-To: <20130618224501.GC53058@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306191056.41700.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Jun 2013 13:58:42 -0400 (EDT) Cc: Marius Strobl , Niclas Zeising , "arch@freebsd.org" , Robert Millan , Jung-uk Kim X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:58:45 -0000 On Tuesday, June 18, 2013 6:45:01 pm Marius Strobl wrote: > On Tue, Jun 18, 2013 at 04:19:16PM -0600, Warner Losh wrote: > > > > On Jun 18, 2013, at 4:03 PM, Jung-uk Kim wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 2013-06-18 17:49:57 -0400, Marius Strobl wrote: > > >> On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim wrote: > > >>> On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: > > >>>> On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? > > >>>> 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 -0400, Marius > > >>>> Strobl wrote: > > >>>>>> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim > > >>>>>> wrote: > > >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > >>>>>>> > > >>>>>>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: > > >>>>>>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas > > >>>>>>>> Zeising wrote: > > >>>>>>>>> On 2013-06-18 13:13, Marius Strobl wrote: > > >>>>>>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas > > >>>>>>>>>> Zeising wrote: > > >>>>>>>>>>> This has been discussed before [1], but there > > >>>>>>>>>>> seem to still be a lack of consensus, so I'll ask > > >>>>>>>>>>> again. > > >>>>>>>>>>> > > >>>>>>>>>>> Should in*/out* macros or bus_space* functions be > > >>>>>>>>>>> used in userland code? The background is that the > > >>>>>>>>>>> port devel/libpciaccess uses these routines on > > >>>>>>>>>>> FreeBSD. In a first incarnation it used the > > >>>>>>>>>>> bus_space* routines, see this patch: > > >>>>>>>>>>> > > >>>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch- src-freebsd_pci.c?rev=591 > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > > This was later changed to use the in*/out* macros directly, with the > > >>>>>>>>>>> motivation that the bus_space* functions is a KPI > > >>>>>>>>>>> that shouldn't be used in userland. See > > >>>>>>>>>>> following for an updated patch: > > >>>>>>>>>>> > > >>>>>>>>>>> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch- src-freebsd_pci.c?rev=815 > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > >>>> > > >>>>>>>>>>> > > > The problem is that the in*/out* macros differ between FreeBSD and > > >>>>>>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want to > > >>>>>>>>>>> switch back to use bus_space* again. > > >>>>>>>>>>> > > >>>>>>>>>>> My question is simply, which one is correct, or > > >>>>>>>>>>> should libpciaccess be reworked in a completely > > >>>>>>>>>>> different way? > > >>>>>>>>>> > > >>>>>>>>>> The latter; in*/out*() are somewhat okay if you > > >>>>>>>>>> want to restrict this to work on x86 without PCI > > >>>>>>>>>> domains only. The above approach to using > > >>>>>>>>>> bus_space(9) is one big hack, though. The right way > > >>>>>>>>>> for employing that API is to allocate the > > >>>>>>>>>> corresponding bus resource of a particular device > > >>>>>>>>>> and then to obtain bus tag and handle via > > >>>>>>>>>> rman_get_bus{tag,handle}(9) - which won't work from > > >>>>>>>>>> userland, however. The shortcut to just stick in > > >>>>>>>>>> {AMD64,I386}_BUS_SPACE_IO instead is totally > > >>>>>>>>>> unportable as generally a bus tag isn't a mere > > >>>>>>>>>> constant and also may depend on which PCI bus and > > >>>>>>>>>> domain a particular device is located on/in. What > > >>>>>>>>>> we really need is a proper interface allowing > > >>>>>>>>>> userland to access PCI I/O and memory registers, f. > > >>>>>>>>>> e. via /dev/pci, and for libpciaccess to build upon > > >>>>>>>>>> that, i. e. essentially the same as things work > > >>>>>>>>>> on/with Linux and /sys/bus/pci/device. As a > > >>>>>>>>>> side-effect this then also permits to properly > > >>>>>>>>>> sanity check PCI accesses from userland within the > > >>>>>>>>>> kernel. > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> That is true, however, it won't build itself today, > > >>>>>>>>> and we need to have this working in the meantime, so > > >>>>>>>>> what do you suggest we use for now? > > >>>>>>>> > > >>>>>>>> That's hard to say as architecturally neither > > >>>>>>>> in*/out*() nor bus_space(9) are the way to proceed. > > >>>>>>>> Tentatively, I'd go with abusing the latter as that > > >>>>>>>> approach _should_ allow to make things additionally > > >>>>>>>> work one another one or two architectures - in > > >>>>>>>> particular powerpc - without introducing an #ifdef > > >>>>>>>> hell. > > >>>>>>> > > >>>>>>> AFAIK, bus_space(9) can only work for amd64 and i386 in > > >>>>>>> userland by pure luck. It can never work for powerpc if > > >>>>>>> I'm reading the MD headers correctly. > > >>>> > > >>>>>> Actually, I think that by cloning bs_le_tag in userland as > > >>>>>> far as necessary, i. e. leaving out things like > > >>>>>> mapping/unmapping and allocation/deallocation etc., and > > >>>>>> using that as bus tag, bus_space(9) has a fairly good > > >>>>>> chance of working in userland for powerpc in this case. > > >>>>>> Obviously, that's harder to do than faking the bus tag for > > >>>>>> x86, though. > > >>>> > > >>>>> Please don't forget the point of this thread, i.e., finding > > >>>>> simple MI interface. ;-) > > >>>> > > >>>>>>> Also, I strongly disagree with abusing bus_space because > > >>>>>>> it gives a bad example. > > >>>> > > >>>>>> Well, I strongly believe that both in*/out*() and > > >>>>>> bus_space(9) give very bad examples for userland code :) > > >>>> > > >>>>> If you insist, we can simply use io(4). > > >>>> > > >>>> I went ahead and implemented it: > > >>>> > > >>>> http://people.freebsd.org/~jkim/libpciaccess.diff > > >>>> > > >>>> This should work with powerpc and other platforms with working > > >>>> io(4). > > >>> > > >>> I just realized powerpc does not have /dev/io, sorry. Anyway, > > >>> my point was there is userland API already and we don't have to > > >>> reinvent the wheel. > > >>> > > >> > > >> Essentially, the issue with io(4) is the same as with in*/out*(); > > >> you can't implement it in a sane way on architectures such as > > >> powerpc that have busses of different endianesses, apart from some > > >> other complications. > > > > > > Why can't we implement it to always get/set in host byte order > > > regardless of underlying bus? Can't the MD portion of the driver > > > figure it out magically? > > > > Not typically. Since all the world is intel, all the world is little endian... Plus, the PCI bus is defined to be little endian, not host endian. Not all drivers cope well with this. > > > > These are good arguments but IMO the real hard part would be to > derive the endianess and whether it's an I/O or memory mapped > register etc. solely from the port address supplied via io(4)/in*/ > out*(). We currently don't have any global infrastructure in the > kernel to query for that information; quite the contrary, with newbus > and bus_space(9) such information generally is local to a specific > bus instance. Generally, there also isn't something like the fixed > ISA range on x86, i. e. for example on one sparc64 machine address > 0x1000 might refer to a memory mapped register on a big-endian SBus > while on another one it could translate to a I/O BAR on a little- > endian PCI bus. Consequently, from a kernel perspective it's way > simpler if an userland interface would allow to specify "read from > offset A of BAR B on PCI device C living on BUS D in domain E". Yes, something like the config access, but having the address be 'offset X in bar Y'. This would be MI and would use bus_space in the kernel. If you wanted a way to mmap BARs you could implement that (mostly) trivially as well. What operations does libpciaccess want to do with BARs: read_[1248] and write_[1248]? Does it want to do anything else (mmap BARs, etc.)? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jun 19 22:17:39 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 6C52ED94; Wed, 19 Jun 2013 22:17:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C22DE5.2040306@FreeBSD.org> Date: Wed, 19 Jun 2013 18:17:09 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: Bus space routines References: <51C044DA.8030406@freebsd.org> <20130618224501.GC53058@alchemy.franken.de> <201306191056.41700.jhb@freebsd.org> In-Reply-To: <201306191056.41700.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, Robert Millan , Niclas Zeising , "arch@freebsd.org" , Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 22:17:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-19 10:56:41 -0400, John Baldwin wrote: > On Tuesday, June 18, 2013 6:45:01 pm Marius Strobl wrote: >> On Tue, Jun 18, 2013 at 04:19:16PM -0600, Warner Losh wrote: >>> >>> On Jun 18, 2013, at 4:03 PM, Jung-uk Kim wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 2013-06-18 17:49:57 -0400, Marius Strobl wrote: >>>>> On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim >>>>> wrote: >>>>>> On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: >>>>>>> On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? >>>>>>> 6? 18? 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 >>>>>>> -0400, Marius Strobl wrote: >>>>>>>>> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk >>>>>>>>> Kim wrote: >>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>>>>> >>>>>>>>>> On 2013-06-18 08:40:38 -0400, Marius Strobl >>>>>>>>>> wrote: >>>>>>>>>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, >>>>>>>>>>> Niclas Zeising wrote: >>>>>>>>>>>> On 2013-06-18 13:13, Marius Strobl wrote: >>>>>>>>>>>>> On Tue, Jun 18, 2013 at 12:20:14PM +0200, >>>>>>>>>>>>> Niclas Zeising wrote: >>>>>>>>>>>>>> This has been discussed before [1], but >>>>>>>>>>>>>> there seem to still be a lack of >>>>>>>>>>>>>> consensus, so I'll ask again. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should in*/out* macros or bus_space* >>>>>>>>>>>>>> functions be used in userland code? The >>>>>>>>>>>>>> background is that the port >>>>>>>>>>>>>> devel/libpciaccess uses these routines >>>>>>>>>>>>>> on FreeBSD. In a first incarnation it >>>>>>>>>>>>>> used the bus_space* routines, see this >>>>>>>>>>>>>> patch: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch- > > src-freebsd_pci.c?rev=591 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>> This was later changed to use the in*/out* macros directly, >>>> with the >>>>>>>>>>>>>> motivation that the bus_space* functions >>>>>>>>>>>>>> is a KPI that shouldn't be used in >>>>>>>>>>>>>> userland. See following for an updated >>>>>>>>>>>>>> patch: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch- > > src-freebsd_pci.c?rev=815 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>> The problem is that the in*/out* macros differ between >>>> FreeBSD and >>>>>>>>>>>>>> Debian/kFreeBSD, and Debian/kFreeBSD want >>>>>>>>>>>>>> to switch back to use bus_space* again. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My question is simply, which one is >>>>>>>>>>>>>> correct, or should libpciaccess be >>>>>>>>>>>>>> reworked in a completely different way? >>>>>>>>>>>>> >>>>>>>>>>>>> The latter; in*/out*() are somewhat okay if >>>>>>>>>>>>> you want to restrict this to work on x86 >>>>>>>>>>>>> without PCI domains only. The above >>>>>>>>>>>>> approach to using bus_space(9) is one big >>>>>>>>>>>>> hack, though. The right way for employing >>>>>>>>>>>>> that API is to allocate the corresponding >>>>>>>>>>>>> bus resource of a particular device and >>>>>>>>>>>>> then to obtain bus tag and handle via >>>>>>>>>>>>> rman_get_bus{tag,handle}(9) - which won't >>>>>>>>>>>>> work from userland, however. The shortcut >>>>>>>>>>>>> to just stick in {AMD64,I386}_BUS_SPACE_IO >>>>>>>>>>>>> instead is totally unportable as generally >>>>>>>>>>>>> a bus tag isn't a mere constant and also >>>>>>>>>>>>> may depend on which PCI bus and domain a >>>>>>>>>>>>> particular device is located on/in. What we >>>>>>>>>>>>> really need is a proper interface allowing >>>>>>>>>>>>> userland to access PCI I/O and memory >>>>>>>>>>>>> registers, f. e. via /dev/pci, and for >>>>>>>>>>>>> libpciaccess to build upon that, i. e. >>>>>>>>>>>>> essentially the same as things work on/with >>>>>>>>>>>>> Linux and /sys/bus/pci/device. As a >>>>>>>>>>>>> side-effect this then also permits to >>>>>>>>>>>>> properly sanity check PCI accesses from >>>>>>>>>>>>> userland within the kernel. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That is true, however, it won't build itself >>>>>>>>>>>> today, and we need to have this working in >>>>>>>>>>>> the meantime, so what do you suggest we use >>>>>>>>>>>> for now? >>>>>>>>>>> >>>>>>>>>>> That's hard to say as architecturally neither >>>>>>>>>>> in*/out*() nor bus_space(9) are the way to >>>>>>>>>>> proceed. Tentatively, I'd go with abusing the >>>>>>>>>>> latter as that approach _should_ allow to make >>>>>>>>>>> things additionally work one another one or two >>>>>>>>>>> architectures - in particular powerpc - without >>>>>>>>>>> introducing an #ifdef hell. >>>>>>>>>> >>>>>>>>>> AFAIK, bus_space(9) can only work for amd64 and >>>>>>>>>> i386 in userland by pure luck. It can never work >>>>>>>>>> for powerpc if I'm reading the MD headers >>>>>>>>>> correctly. >>>>>>> >>>>>>>>> Actually, I think that by cloning bs_le_tag in >>>>>>>>> userland as far as necessary, i. e. leaving out >>>>>>>>> things like mapping/unmapping and >>>>>>>>> allocation/deallocation etc., and using that as bus >>>>>>>>> tag, bus_space(9) has a fairly good chance of >>>>>>>>> working in userland for powerpc in this case. >>>>>>>>> Obviously, that's harder to do than faking the bus >>>>>>>>> tag for x86, though. >>>>>>> >>>>>>>> Please don't forget the point of this thread, i.e., >>>>>>>> finding simple MI interface. ;-) >>>>>>> >>>>>>>>>> Also, I strongly disagree with abusing bus_space >>>>>>>>>> because it gives a bad example. >>>>>>> >>>>>>>>> Well, I strongly believe that both in*/out*() and >>>>>>>>> bus_space(9) give very bad examples for userland >>>>>>>>> code :) >>>>>>> >>>>>>>> If you insist, we can simply use io(4). >>>>>>> >>>>>>> I went ahead and implemented it: >>>>>>> >>>>>>> http://people.freebsd.org/~jkim/libpciaccess.diff >>>>>>> >>>>>>> This should work with powerpc and other platforms with >>>>>>> working io(4). >>>>>> >>>>>> I just realized powerpc does not have /dev/io, sorry. >>>>>> Anyway, my point was there is userland API already and we >>>>>> don't have to reinvent the wheel. >>>>>> >>>>> >>>>> Essentially, the issue with io(4) is the same as with >>>>> in*/out*(); you can't implement it in a sane way on >>>>> architectures such as powerpc that have busses of different >>>>> endianesses, apart from some other complications. >>>> >>>> Why can't we implement it to always get/set in host byte >>>> order regardless of underlying bus? Can't the MD portion of >>>> the driver figure it out magically? >>> >>> Not typically. Since all the world is intel, all the world is >>> little > endian... Plus, the PCI bus is defined to be little endian, not > host endian. Not all drivers cope well with this. >>> >> >> These are good arguments but IMO the real hard part would be to >> derive the endianess and whether it's an I/O or memory mapped >> register etc. solely from the port address supplied via >> io(4)/in*/ out*(). We currently don't have any global >> infrastructure in the kernel to query for that information; quite >> the contrary, with newbus and bus_space(9) such information >> generally is local to a specific bus instance. Generally, there >> also isn't something like the fixed ISA range on x86, i. e. for >> example on one sparc64 machine address 0x1000 might refer to a >> memory mapped register on a big-endian SBus while on another one >> it could translate to a I/O BAR on a little- endian PCI bus. >> Consequently, from a kernel perspective it's way simpler if an >> userland interface would allow to specify "read from offset A of >> BAR B on PCI device C living on BUS D in domain E". > > Yes, something like the config access, but having the address be > 'offset X in bar Y'. This would be MI and would use bus_space in > the kernel. If you wanted a way to mmap BARs you could implement > that (mostly) trivially as well. > > What operations does libpciaccess want to do with BARs: > read_[1248] and write_[1248]? Yes. > Does it want to do anything else (mmap BARs, etc.)? Not ATM. http://cgit.freedesktop.org/xorg/lib/libpciaccess/commit/src/common_io.c?id=5e8d4c1 for (bar = 0; bar < 6; bar++) { struct pci_mem_region *region = &(dev->regions[bar]); if (!region->is_IO) continue; ... Please note we do not support I/O via PCI BARs yet on *any* platform. In fact, we only support ISA I/O ports, i.e., just enough to support VGA/VESA for x86, and possibly ia64. AFAICT, the API is available but X.org does not need it ATM. In other words, there is no hurry at all. In fact, I don't think they will ever use the API because they already moved these things to kernel-side anyway. ;-) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwi3lAAoJECXpabHZMqHO2wYIAJURutCs8gKsuxrfycAR4vDL T8hFcA5sR4WFJBuyMLsKxagcF0A6+HJtyTW8V7yC1dqt9lqMWLUAPHrAFv9Fdcsg Ztbe3N8FGIbKva6VrtfdYWHjE4kv3Qb5OblVsW1s/kXm4Cetei5dQ4HXA1Q340LT 7OAlFxLaWMfLjkSj939BlBeXJ2vApnEEkYEFJiEGxDMm6laFeB/B1vNfSQbF2ncd x8VYf5qwal1kBLs8w5mdAG7Eo9RAatWNa5/Cycr4qdALKpqRZXb/pTob07pBAaPH 1GZC4x1KFDwM/m3T81T+ntgQ2lJNyPuZZaO29s5mcppugdFUBF6yX1ISAWQ/ovQ= =8LTg -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 21 21:05:37 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D462A51; Fri, 21 Jun 2013 21:05:37 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id EF37F1619; Fri, 21 Jun 2013 21:05:36 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id n20so926218qaj.6 for ; Fri, 21 Jun 2013 14:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Dy2AOAZd2LMYahtP5nNxAYOAR7q5dBXdpzajrrPc9z8=; b=r1Zh4Q3IZR4l4G2e98tzkd5aDMr908tbGZXO6HE79dtLls6oh0vBHxC11prVrD1HXN jOfDeW09V1R/kAJ3jwbi5Sh4zuY4fI32vuSkV9y1aTMNhxPDvnCYx66uRixztstrB94m A8Wun2gO/rtnGuTnyfRrBF11pTUa+u8//XR8/NwkWnBfCuS49XL9IIijEqz2D1vQRla8 BcR4EXoXxR3uCaexc9/Je+YHKuAWzZ3wMnaKCChrPgAkCe6UDcx9JbFGvJ56sGjfV/6f G+W+YuP1FYgV8WJ0ybKhhRoB/vy/ljXrzTYKnxL6ZJ+U7TT9aVFU0QHUR/sEreTHwIs5 pkOg== X-Received: by 10.49.60.169 with SMTP id i9mr7266669qer.93.1371848736307; Fri, 21 Jun 2013 14:05:36 -0700 (PDT) Received: from [10.1.10.62] ([187.120.137.162]) by mx.google.com with ESMTPSA id s8sm8649681qat.4.2013.06.21.14.05.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 14:05:35 -0700 (PDT) Subject: Re: FDT Support for GPIO (gpiobus and friends) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/mixed; boundary=Apple-Mail-11-552019434 From: Luiz Otavio O Souza In-Reply-To: <20121205.060056.592894859995638978.hrs@allbsd.org> Date: Fri, 21 Jun 2013 18:05:26 -0300 Message-Id: References: <20121205.060056.592894859995638978.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1085) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:05:37 -0000 --Apple-Mail-11-552019434 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 4, 2012, at 7:00 PM, Hiroki Sato wrote: > Luiz Otavio O Souza wrote > in : >=20 > lo> Hi, > lo> > lo> I've been playing with GPIO on RPi and found the missing support = of > lo> FDT on gpiobus very annoying. > lo> > lo> The following patch (gpio-fdt.diff) adds FDT support to GPIO = (gpiobus, > lo> gpioc, gpioled). > lo> > lo> The bcm2835_gpio.c.fdt.diff will add (a better) support of FDT on = RPi > lo> GPIO controller and the bcm2835.dts.diff has my changes on the RPi = dts > lo> for adding support of gpioled on 'ok' led (pin 16). > lo> > lo> Comments ? >=20 > I like this idea, but it should be consistent with standard device > tree bindings. For example, >=20 > + gpiobus { > + compatible =3D "gpiobus"; > + > + /* Ok led */ > + led { > + compatible =3D "gpioled"; > + label =3D "ok"; > + pins =3D <16>; > + }; > + }; >=20 > should be something like the following: >=20 > led { > compatible =3D "gpio-leds"; > ok { > gpios =3D <&foo 16 1>; > label =3D "ok"; > }; > }; >=20 > A node using GPIOs must have gpios property for the gpio-controller > node and pin number. >=20 > -- Hiroki Sorry for the long delay. And yes, i should have read the bindings-gpio.txt document first :) Is the attached patch better ? It implements the gpios property decoding = for gpioled (and could be used as a template for others gpio consumers) = and now it works (almost) out of box with the standard rpi dts file. The only change on the rpi dts file was to add the flags field and mark = the pin led as an output (even if this is unused by the current code - a = gpioled pin is always an output). This was necessary to match the format = documented on bindings-gpio.txt. Luiz --Apple-Mail-11-552019434 Content-Disposition: attachment; filename=bcm2835-rpi-b.diff Content-Type: application/octet-stream; name="bcm2835-rpi-b.diff" Content-Transfer-Encoding: 7bit Index: boot/fdt/dts/bcm2835-rpi-b.dts =================================================================== --- boot/fdt/dts/bcm2835-rpi-b.dts (revision 251700) +++ boot/fdt/dts/bcm2835-rpi-b.dts (working copy) @@ -518,7 +518,7 @@ ok { label = "ok"; - gpios = <&gpio 16 1>; + gpios = <&gpio 16 2 0>; /* Don't change this - it configures * how the led driver determines if --Apple-Mail-11-552019434 Content-Disposition: attachment; filename=gpioled-fdt.diff Content-Type: application/octet-stream; name="gpioled-fdt.diff" Content-Transfer-Encoding: 7bit Index: dev/gpio/gpiobus.c =================================================================== --- dev/gpio/gpiobus.c (revision 251700) +++ dev/gpio/gpiobus.c (working copy) @@ -27,6 +27,8 @@ #include __FBSDID("$FreeBSD$"); +#include "opt_platform.h" + #include #include #include @@ -41,6 +43,12 @@ #include #include +#ifdef FDT +#include +#include +#include +#endif + #include #include #include "gpio_if.h" @@ -83,6 +91,130 @@ #define GPIOBUS_ASSERT_UNLOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_NOTOWNED); +#ifdef FDT +static int +gpiobus_fdt_parse_pins(device_t dev) +{ + struct gpiobus_ivar *devi; + struct gpiobus_softc *sc; + int i, len; + pcell_t *gpios; + phandle_t gpio, node; + + /* Retrieve the FDT node and check for gpios property. */ + node = ofw_bus_get_node(dev); + if ((len = OF_getproplen(node, "gpios")) < 0) + return (EINVAL); + + /* Retrieve the gpios property. */ + gpios = malloc(len, M_DEVBUF, M_NOWAIT | M_ZERO); + if (gpios == NULL) + return (ENOMEM); + if (OF_getprop(node, "gpios", gpios, len) < 0) { + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* + * The OF_getprop() is returning 4 pcells. + * The first one is the GPIO controller phandler. + * The last three are GPIO pin, GPIO pin direction and GPIO pin flags. + */ + if ((len / sizeof(pcell_t)) % 4) { + free(gpios, M_DEVBUF); + return (EINVAL); + } + devi = GPIOBUS_IVAR(dev); + devi->npins = len / (sizeof(pcell_t) * 4); + devi->pins = malloc(sizeof(uint32_t) * devi->npins, M_DEVBUF, + M_NOWAIT | M_ZERO); + if (devi->pins == NULL) { + free(gpios, M_DEVBUF); + return (ENOMEM); + } + + for (i = 0; i < devi->npins; i++) { + + /* Verify if we're attaching to the correct gpio controller. */ + gpio = OF_instance_to_package(fdt32_to_cpu(gpios[i * 4 + 0])); + if (!OF_hasprop(gpio, "gpio-controller") || + gpio != ofw_bus_get_node(device_get_parent( + device_get_parent(dev)))) { + free(devi->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* Attach the child device to gpiobus. */ + sc = device_get_softc(device_get_parent(dev)); + + devi->pins[i] = fdt32_to_cpu(gpios[i * 4 + 1]); + /* (void)gpios[i * 4 + 2] - GPIO pin direction */ + /* (void)gpios[i * 4 + 3] - GPIO pin flags */ + + if (devi->pins[i] > sc->sc_npins) { + device_printf(dev, "invalid pin %d, max: %d\n", + devi->pins[i], sc->sc_npins - 1); + free(devi->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* + * Mark pin as mapped and give warning if it's already mapped. + */ + if (sc->sc_pins_mapped[devi->pins[i]]) { + device_printf(dev, + "warning: pin %d is already mapped\n", + devi->pins[i]); + free(devi->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + sc->sc_pins_mapped[devi->pins[i]] = 1; + } + + free(gpios, M_DEVBUF); + return (0); +} + +int +gpiobus_fdt_add_child(device_t bus, phandle_t childnode) +{ + struct gpiobus_ivar *devi; + device_t child; + + devi = malloc(sizeof(*devi), M_DEVBUF, M_NOWAIT | M_ZERO); + if (devi == NULL) + return (-1); + + if (ofw_bus_gen_setup_devinfo(&devi->ofw, childnode) != 0) { + device_printf(bus, "could not set up devinfo\n"); + free(devi, M_DEVBUF); + return (-1); + } + + /* Add newbus device for the child. */ + child = device_add_child(bus, NULL, -1); + if (child == NULL) { + device_printf(bus, "could not add child: %s\n", + devi->ofw.obd_name); + /* XXX should unmap */ + ofw_bus_gen_destroy_devinfo(&devi->ofw); + free(devi, M_DEVBUF); + return (-1); + } + device_set_ivars(child, devi); + if (gpiobus_fdt_parse_pins(child) != 0) { + device_delete_child(bus, child); + ofw_bus_gen_destroy_devinfo(&devi->ofw); + free(devi, M_DEVBUF); + return (-1); + } + return (0); +} +#endif + static void gpiobus_print_pins(struct gpiobus_ivar *devi) { @@ -151,6 +283,7 @@ if (i >= sc->sc_npins) { device_printf(child, "invalid pin %d, max: %d\n", i, sc->sc_npins - 1); + free(devi->pins, M_DEVBUF); return (EINVAL); } @@ -161,6 +294,7 @@ if (sc->sc_pins_mapped[i]) { device_printf(child, "warning: pin %d is already mapped\n", i); + free(devi->pins, M_DEVBUF); return (EINVAL); } sc->sc_pins_mapped[i] = 1; @@ -207,6 +341,7 @@ /* * Get parent's pins and mark them as unmapped */ + bus_generic_probe(dev); bus_enumerate_hinted_children(dev); return (bus_generic_attach(dev)); } @@ -445,6 +580,17 @@ return GPIO_PIN_TOGGLE(sc->sc_dev, devi->pins[pin]); } +#ifdef FDT +static const struct ofw_bus_devinfo * +gpiobus_get_devinfo(device_t bus, device_t child) +{ + struct gpiobus_ivar *devi; + + devi = device_get_ivars(child); + return (&devi->ofw); +} +#endif + static device_method_t gpiobus_methods[] = { /* Device interface */ DEVMETHOD(device_probe, gpiobus_probe), @@ -473,6 +619,16 @@ DEVMETHOD(gpiobus_pin_set, gpiobus_pin_set), DEVMETHOD(gpiobus_pin_toggle, gpiobus_pin_toggle), +#ifdef FDT + /* OFW bus interface */ + DEVMETHOD(ofw_bus_get_devinfo, gpiobus_get_devinfo), + DEVMETHOD(ofw_bus_get_compat, ofw_bus_gen_get_compat), + DEVMETHOD(ofw_bus_get_model, ofw_bus_gen_get_model), + DEVMETHOD(ofw_bus_get_name, ofw_bus_gen_get_name), + DEVMETHOD(ofw_bus_get_node, ofw_bus_gen_get_node), + DEVMETHOD(ofw_bus_get_type, ofw_bus_gen_get_type), +#endif + DEVMETHOD_END }; Index: dev/gpio/gpiobusvar.h =================================================================== --- dev/gpio/gpiobusvar.h (revision 251700) +++ dev/gpio/gpiobusvar.h (working copy) @@ -30,10 +30,16 @@ #ifndef __GPIOBUS_H__ #define __GPIOBUS_H__ +#include "opt_platform.h" + #include #include #include +#ifdef FDT +#include +#endif + #define GPIOBUS_IVAR(d) (struct gpiobus_ivar *) device_get_ivars(d) #define GPIOBUS_SOFTC(d) (struct gpiobus_softc *) device_get_softc(d) @@ -50,8 +56,15 @@ struct gpiobus_ivar { +#ifdef FDT + struct ofw_bus_devinfo ofw; /* FDT device info */ +#endif uint32_t npins; /* pins total */ uint32_t *pins; /* pins map */ }; +#ifdef FDT +int gpiobus_fdt_add_child(device_t, phandle_t); +#endif + #endif /* __GPIOBUS_H__ */ Index: dev/gpio/gpioled.c =================================================================== --- dev/gpio/gpioled.c (revision 251700) +++ dev/gpio/gpioled.c (working copy) @@ -27,6 +27,8 @@ #include __FBSDID("$FreeBSD$"); +#include "opt_platform.h" + #include #include #include @@ -43,11 +45,20 @@ #include #include "gpiobus_if.h" +#ifdef FDT +#include +#include +#include +#include +#endif + /* * Only one pin for led */ #define GPIOLED_PIN 0 +#define GPIOLED_MAXBUF 32 + #define GPIOLED_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) #define GPIOLED_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) #define GPIOLED_LOCK_INIT(_sc) \ @@ -68,6 +79,35 @@ static int gpioled_attach(device_t); static int gpioled_detach(device_t); +#ifdef FDT +static void +gpioled_identify(driver_t *driver, device_t bus) +{ + phandle_t child, leds, root; + + root = OF_finddevice("/"); + if (root == 0) + return; + leds = fdt_find_compatible(root, "gpio-leds", 1); + if (leds == 0) + return; + for (child = OF_child(leds); child != 0; child = OF_peer(child)) { + + /* Check and process 'status' property. */ + if (!(fdt_is_enabled(child))) + continue; + + /* Property gpios must exist. */ + if (!OF_hasprop(child, "gpios")) + continue; + + /* Add the gpiobus child. */ + if (gpiobus_fdt_add_child(bus, child) != 0) + continue; + } +} +#endif + static void gpioled_control(void *priv, int onoff) { @@ -93,15 +133,27 @@ gpioled_attach(device_t dev) { struct gpioled_softc *sc; - const char *name; + char *name; +#ifdef FDT + phandle_t node; +#endif sc = device_get_softc(dev); sc->sc_dev = dev; sc->sc_busdev = device_get_parent(dev); GPIOLED_LOCK_INIT(sc); +#ifdef FDT + name = malloc(GPIOLED_MAXBUF + 1, M_DEVBUF, M_NOWAIT | M_ZERO); + if (name == NULL) + return (ENOMEM); + node = ofw_bus_get_node(dev); + if (OF_getprop(node, "label", name, GPIOLED_MAXBUF) == -1) + OF_getprop(node, "name", name, GPIOLED_MAXBUF); +#else if (resource_string_value(device_get_name(dev), device_get_unit(dev), "name", &name)) name = NULL; +#endif GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, GPIOLED_PIN, GPIO_PIN_OUTPUT); @@ -109,6 +161,9 @@ sc->sc_leddev = led_create(gpioled_control, sc, name ? name : device_get_nameunit(dev)); +#ifdef FDT + free(name, M_DEVBUF); +#endif return (0); } @@ -130,6 +185,9 @@ static device_method_t gpioled_methods[] = { /* Device interface */ +#ifdef FDT + DEVMETHOD(device_identify, gpioled_identify), +#endif DEVMETHOD(device_probe, gpioled_probe), DEVMETHOD(device_attach, gpioled_attach), DEVMETHOD(device_detach, gpioled_detach), --Apple-Mail-11-552019434--