From owner-freebsd-arch@FreeBSD.ORG Mon Dec 9 17:22:11 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B0F9552; Mon, 9 Dec 2013 17:22:11 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52B111E2D; Mon, 9 Dec 2013 17:22:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D7B0B94B; Mon, 9 Dec 2013 12:22:10 -0500 (EST) From: John Baldwin To: clutton Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Mon, 9 Dec 2013 12:19:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1383419596.3253.42.camel@eva02.mbsd> <201311121354.03923.jhb@freebsd.org> <1386409167.1888.18.camel@eva02.mbsd> In-Reply-To: <1386409167.1888.18.camel@eva02.mbsd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312091219.58325.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Dec 2013 12:22:10 -0500 (EST) Cc: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:22:11 -0000 On Saturday, December 07, 2013 4:39:27 am clutton wrote: > On Tue, 2013-11-12 at 13:54 -0500, John Baldwin wrote: >=20 > Guys, it still doesn't work. Two days ago, when I changed my AP setup, > in rc.conf and then run =C2=ABsudo service netif restart=C2=BB I'd observ= ed two > copies of the wpa_supplicant. >=20 > System is CURRENT b9061d4, I can't see the pgrep patch on it... No, I had to revert it because it broke other things. I'm still not sure w= hat=20 solution I prefer yet. =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Dec 12 19:20:07 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67424964; Thu, 12 Dec 2013 19:20:07 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08BAF1F86; Thu, 12 Dec 2013 19:20:06 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id f64so709874yha.31 for ; Thu, 12 Dec 2013 11:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6fJ1YTjc5rwP2ZAZvf2eIZ9TyVFvnfmHriAeXDhnHkU=; b=rKE8dBvUbvjRlKfOjtCVqgQ0UUMvpB9RJN6uumIgfXSd6cE5r9DbkPUAUMbEtRFWyO B8VBGb7krw+xTW48JykdAHKZ+fvT5MBiJ4Ovp+B/Rx3U0MjNVkL8e8z/BMiYX6fpOgYn srE3FD1wlmylWliqeeSUVPDzsQcpyfaq42Nn1OQw7ooq7799NkzWGFE01sjC6VyDLiUe dEqMi6rHf+Jqz5l/LAayoOKwwsz4E7T6kBsnJnHXSdCwMWnKS3lFAqOQglt17hHr8moH gWfavt5iHFlPU9E/zQajW7LI6QlEcYP/BMsSSSZo9gveZt4QungnrZ0jHE1AznP0gYzF L3tg== X-Received: by 10.236.139.198 with SMTP id c46mr7518847yhj.78.1386876005676; Thu, 12 Dec 2013 11:20:05 -0800 (PST) Received: from [192.168.1.7] ([187.120.137.162]) by mx.google.com with ESMTPSA id r64sm35607308yhc.23.2013.12.12.11.20.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 11:20:04 -0800 (PST) Content-Type: multipart/mixed; boundary="Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: FDT Support for GPIO (gpiobus and friends) From: Luiz Otavio O Souza In-Reply-To: <7DBC8BB4-8CEF-48E0-BB6B-40C00F71284A@gmail.com> Date: Thu, 12 Dec 2013 17:19:52 -0200 Message-Id: <598EB94E-817C-47E9-BBA5-F6E6D5A1B2BA@gmail.com> References: <20121205.060056.592894859995638978.hrs@allbsd.org> <7DBC8BB4-8CEF-48E0-BB6B-40C00F71284A@gmail.com> To: freebsd-arch@FreeBSD.org X-Mailer: Apple Mail (2.1822) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 19:20:07 -0000 --Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 26, 2013, at 4:44 PM, Luiz Otavio O Souza = wrote: > Right, so after playing a little bit with IIC and SPI on FDT i have = now a patch, which i believe, is more clean and complete to support an = OFW GPIO bus in the same way as it has been done with IIC and SPI. >=20 > The first patch (001-ofw-gpiobus.diff) implements the OFW GPIO bus and = all the changes to make possible to the available gpio devices (gpioled = and gpioiic) attach to it. >=20 > The second patch (002-iicbb-ofw-iicbus.diff) implements the changes to = make the OFW IIC bus attach to a gpioiic bit-banging (iicbb(4)) kind of = driver. >=20 > The third patch (006-ofw-gpio-man.diff) has the manual changes for = gpioiic and gpioled. >=20 > I would appreciate if you people could take a look and give me some = feedback. Okay, so here are the updated patches (updated to apply clean after the = last changes). I=92ve added one missing patch (000-gpio-node.diff) which gives access = to FDT node of the gpio controller to GPIO OFW bus. For now, this last patch is only for RPi and BBB. Both are tested and = known to work with gpioled(4) and gpioiic(4). There is an additional patch (000-bbb-gpioled.diff) which shows what is = needed to setup gpioled on BBB. In the next days, i=92ll check the changes for regressions with some non = FDT boards and if everything is okay and nobody objects, i=92ll ask for = permission to commit it. Comments ? Luiz --Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725 Content-Disposition: attachment; filename=001-ofw-gpiobus.diff Content-Type: application/octet-stream; name="001-ofw-gpiobus.diff" Content-Transfer-Encoding: 7bit Index: sys/conf/files =================================================================== --- sys/conf/files (revision 259130) +++ sys/conf/files (working copy) @@ -1436,6 +1436,7 @@ dev/gpio/gpioled.c optional gpioled dev/gpio/gpio_if.m optional gpio dev/gpio/gpiobus_if.m optional gpio +dev/gpio/ofw_gpiobus.c optional fdt gpio dev/hatm/if_hatm.c optional hatm pci dev/hatm/if_hatm_intr.c optional hatm pci dev/hatm/if_hatm_ioctl.c optional hatm pci Index: sys/dev/gpio/gpiobus.c =================================================================== --- sys/dev/gpio/gpiobus.c (revision 259130) +++ sys/dev/gpio/gpiobus.c (working copy) @@ -46,7 +46,6 @@ #include "gpio_if.h" #include "gpiobus_if.h" -static void gpiobus_print_pins(struct gpiobus_ivar *); static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int); static int gpiobus_probe(device_t); static int gpiobus_attach(device_t); @@ -73,17 +72,7 @@ static int gpiobus_pin_get(device_t, device_t, uint32_t, unsigned int*); static int gpiobus_pin_toggle(device_t, device_t, uint32_t); -#define GPIOBUS_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) -#define GPIOBUS_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) -#define GPIOBUS_LOCK_INIT(_sc) \ - mtx_init(&_sc->sc_mtx, device_get_nameunit(_sc->sc_dev), \ - "gpiobus", MTX_DEF) -#define GPIOBUS_LOCK_DESTROY(_sc) mtx_destroy(&_sc->sc_mtx); -#define GPIOBUS_ASSERT_LOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_OWNED); -#define GPIOBUS_ASSERT_UNLOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_NOTOWNED); - - -static void +void gpiobus_print_pins(struct gpiobus_ivar *devi) { int range_start, range_stop, need_coma; Index: sys/dev/gpio/gpiobusvar.h =================================================================== --- sys/dev/gpio/gpiobusvar.h (revision 259130) +++ sys/dev/gpio/gpiobusvar.h (working copy) @@ -30,13 +30,26 @@ #ifndef __GPIOBUS_H__ #define __GPIOBUS_H__ +#include "opt_platform.h" + #include #include #include -#define GPIOBUS_IVAR(d) (struct gpiobus_ivar *) device_get_ivars(d) -#define GPIOBUS_SOFTC(d) (struct gpiobus_softc *) device_get_softc(d) +#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) +#define GPIOBUS_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) +#define GPIOBUS_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) +#define GPIOBUS_LOCK_INIT(_sc) mtx_init(&_sc->sc_mtx, \ + device_get_nameunit(_sc->sc_dev), "gpiobus", MTX_DEF) +#define GPIOBUS_LOCK_DESTROY(_sc) mtx_destroy(&_sc->sc_mtx) +#define GPIOBUS_ASSERT_LOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_OWNED) +#define GPIOBUS_ASSERT_UNLOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_NOTOWNED) + struct gpiobus_softc { struct mtx sc_mtx; /* bus mutex */ @@ -54,4 +67,11 @@ uint32_t *pins; /* pins map */ }; +void gpiobus_print_pins(struct gpiobus_ivar *); +#ifdef FDT +device_t ofw_gpiobus_add_fdt_child(device_t, phandle_t); +#endif + +extern driver_t gpiobus_driver; + #endif /* __GPIOBUS_H__ */ Index: sys/dev/gpio/gpioiic.c =================================================================== --- sys/dev/gpio/gpioiic.c (revision 259130) +++ sys/dev/gpio/gpioiic.c (working copy) @@ -28,6 +28,8 @@ #include __FBSDID("$FreeBSD$"); +#include "opt_platform.h" + #include #include #include @@ -38,6 +40,12 @@ #include #include "gpiobus_if.h" +#ifdef FDT +#include +#include +#include +#endif + #include #include @@ -71,6 +79,10 @@ gpioiic_probe(device_t dev) { +#ifdef FDT + if (!ofw_bus_is_compatible(dev, "gpioiic")) + return (ENXIO); +#endif device_set_desc(dev, "GPIO I2C bit-banging driver"); return (0); @@ -81,6 +93,10 @@ { struct gpioiic_softc *sc = device_get_softc(dev); device_t bitbang; +#ifdef FDT + phandle_t node; + pcell_t pin; +#endif sc->sc_dev = dev; sc->sc_busdev = device_get_parent(dev); @@ -91,6 +107,15 @@ device_get_unit(dev), "sda", &sc->sda_pin)) sc->sda_pin = SDA_PIN_DEFAULT; +#ifdef FDT + if ((node = ofw_bus_get_node(dev)) == -1) + return (ENXIO); + if (OF_getencprop(node, "scl", &pin, sizeof(pin)) > 0) + sc->scl_pin = (int)pin; + if (OF_getencprop(node, "sda", &pin, sizeof(pin)) > 0) + sc->sda_pin = (int)pin; +#endif + /* add generic bit-banging code */ bitbang = device_add_child(dev, "iicbb", -1); device_probe_and_attach(bitbang); @@ -209,6 +234,16 @@ return (IIC_ENOADDR); } +#ifdef FDT +static phandle_t +gpioiic_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the iicbb, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} +#endif + static devclass_t gpioiic_devclass; static device_method_t gpioiic_methods[] = { @@ -225,6 +260,11 @@ DEVMETHOD(iicbb_getscl, gpioiic_getscl), DEVMETHOD(iicbb_reset, gpioiic_reset), +#ifdef FDT + /* OFW bus interface */ + DEVMETHOD(ofw_bus_get_node, gpioiic_get_node), +#endif + { 0, 0 } }; Index: sys/dev/gpio/gpioled.c =================================================================== --- sys/dev/gpio/gpioled.c (revision 259130) +++ sys/dev/gpio/gpioled.c (working copy) @@ -27,6 +27,8 @@ #include __FBSDID("$FreeBSD$"); +#include "opt_platform.h" + #include #include #include @@ -39,6 +41,12 @@ #include #include +#ifdef FDT +#include +#include +#include +#endif + #include #include #include "gpiobus_if.h" @@ -84,10 +92,65 @@ GPIOLED_UNLOCK(sc); } +#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; + + /* Traverse the 'gpio-leds' node and add its children. */ + for (child = OF_child(leds); child != 0; child = OF_peer(child)) + if (ofw_gpiobus_add_fdt_child(bus, child) == NULL) + continue; +} +#endif + static int gpioled_probe(device_t dev) { +#ifdef FDT + int match; + phandle_t node; + char *compat; + + /* + * We can match against our own node compatible string and also against + * our parent node compatible string. The first is normally used to + * describe leds on a gpiobus and the later when there is a common node + * compatible with 'gpio-leds' which is used to concentrate all the + * leds nodes on the dts. + */ + match = 0; + if (ofw_bus_is_compatible(dev, "gpioled")) + match = 1; + + if (match == 0) { + if ((node = ofw_bus_get_node(dev)) == -1) + return (ENXIO); + if ((node = OF_parent(node)) == -1) + return (ENXIO); + if (OF_getprop_alloc(node, "compatible", 1, + (void **)&compat) == -1) + return (ENXIO); + + if (strcasecmp(compat, "gpio-leds") == 0) + match = 1; + + free(compat, M_OFWPROP); + } + + if (match == 0) + return (ENXIO); +#endif device_set_desc(dev, "GPIO led"); + return (0); } @@ -95,18 +158,35 @@ gpioled_attach(device_t dev) { struct gpioled_softc *sc; +#ifdef FDT + phandle_t node; + char *name; +#else const char *name; +#endif sc = device_get_softc(dev); sc->sc_dev = dev; sc->sc_busdev = device_get_parent(dev); GPIOLED_LOCK_INIT(sc); +#ifdef FDT + name = NULL; + if ((node = ofw_bus_get_node(dev)) == -1) + return (ENXIO); + if (OF_getprop_alloc(node, "label", 1, (void **)&name) == -1) + OF_getprop_alloc(node, "name", 1, (void **)&name); +#else if (resource_string_value(device_get_name(dev), device_get_unit(dev), "name", &name)) name = NULL; +#endif sc->sc_leddev = led_create(gpioled_control, sc, name ? name : device_get_nameunit(dev)); +#ifdef FDT + if (name != NULL) + free(name, M_OFWPROP); +#endif return (0); } @@ -129,6 +209,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), --- /dev/null 2013-12-12 17:00:00.000000000 -0200 +++ sys/dev/gpio/ofw_gpiobus.c 2013-11-25 10:15:00.322070491 -0200 @@ -0,0 +1,342 @@ +/*- + * Copyright (c) 2009, Nathan Whitehorn + * Copyright (c) 2013, Luiz Otavio O Souza + * Copyright (c) 2013 The FreeBSD Foundation + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice unmodified, this list of conditions, and the following + * disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +#include "gpio_if.h" +#include "gpiobus_if.h" + +struct ofw_gpiobus_devinfo { + struct gpiobus_ivar opd_dinfo; + struct ofw_bus_devinfo opd_obdinfo; +}; + +static int ofw_gpiobus_parse_gpios(struct gpiobus_softc *, + struct gpiobus_ivar *, phandle_t); +static struct ofw_gpiobus_devinfo *ofw_gpiobus_setup_devinfo(device_t, + phandle_t); +static void ofw_gpiobus_destroy_devinfo(struct ofw_gpiobus_devinfo *); + +device_t +ofw_gpiobus_add_fdt_child(device_t bus, phandle_t child) +{ + struct ofw_gpiobus_devinfo *dinfo; + device_t childdev; + + /* + * Set up the GPIO child and OFW bus layer devinfo and add it to bus. + */ + dinfo = ofw_gpiobus_setup_devinfo(bus, child); + if (dinfo == NULL) + return (NULL); + childdev = device_add_child(bus, NULL, -1); + if (childdev == NULL) { + device_printf(bus, "could not add child: %s\n", + dinfo->opd_obdinfo.obd_name); + ofw_gpiobus_destroy_devinfo(dinfo); + return (NULL); + } + device_set_ivars(childdev, dinfo); + + return (childdev); +} + +static int +ofw_gpiobus_parse_gpios(struct gpiobus_softc *sc, struct gpiobus_ivar *dinfo, + phandle_t child) +{ + int i, len; + pcell_t *gpios; + phandle_t gpio; + + /* Check and process 'status' property. */ + if (!(fdt_is_enabled(child))) + return (ENXIO); + + /* Retrieve the gpios property. */ + if ((len = OF_getproplen(child, "gpios")) < 0) + return (EINVAL); + gpios = malloc(len, M_DEVBUF, M_NOWAIT | M_ZERO); + if (gpios == NULL) + return (ENOMEM); + if (OF_getencprop(child, "gpios", gpios, len) < 0) { + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* + * Each 'gpios' entry must contain 4 pcells. + * The first one is the GPIO controller phandler. + * Then the last three are the GPIO pin, the GPIO pin direction and + * the GPIO pin flags. + */ + if ((len / sizeof(pcell_t)) % 4) { + free(gpios, M_DEVBUF); + return (EINVAL); + } + dinfo->npins = len / (sizeof(pcell_t) * 4); + dinfo->pins = malloc(sizeof(uint32_t) * dinfo->npins, M_DEVBUF, + M_NOWAIT | M_ZERO); + if (dinfo->pins == NULL) { + free(gpios, M_DEVBUF); + return (ENOMEM); + } + + for (i = 0; i < dinfo->npins; i++) { + + /* Verify if we're attaching to the correct gpio controller. */ + gpio = OF_xref_phandle(gpios[i * 4 + 0]); + if (!OF_hasprop(gpio, "gpio-controller") || + gpio != ofw_bus_get_node(sc->sc_dev)) { + free(dinfo->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* Get the GPIO pin number. */ + dinfo->pins[i] = gpios[i * 4 + 1]; + /* gpios[i * 4 + 2] - GPIO pin direction */ + /* gpios[i * 4 + 3] - GPIO pin flags */ + + if (dinfo->pins[i] > sc->sc_npins) { + device_printf(sc->sc_busdev, + "invalid pin %d, max: %d\n", + dinfo->pins[i], sc->sc_npins - 1); + free(dinfo->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[dinfo->pins[i]]) { + device_printf(sc->sc_busdev, + "warning: pin %d is already mapped\n", + dinfo->pins[i]); + free(dinfo->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + sc->sc_pins_mapped[dinfo->pins[i]] = 1; + } + + free(gpios, M_DEVBUF); + + return (0); +} + +static struct ofw_gpiobus_devinfo * +ofw_gpiobus_setup_devinfo(device_t dev, phandle_t node) +{ + struct gpiobus_softc *sc; + struct ofw_gpiobus_devinfo *dinfo; + + sc = device_get_softc(dev); + dinfo = malloc(sizeof(*dinfo), M_DEVBUF, M_NOWAIT | M_ZERO); + if (dinfo == NULL) + return (NULL); + if (ofw_bus_gen_setup_devinfo(&dinfo->opd_obdinfo, node) != 0) { + free(dinfo, M_DEVBUF); + return (NULL); + } + + /* Parse the gpios property for the child. */ + if (ofw_gpiobus_parse_gpios(sc, &dinfo->opd_dinfo, node) != 0) { + ofw_bus_gen_destroy_devinfo(&dinfo->opd_obdinfo); + free(dinfo, M_DEVBUF); + return (NULL); + } + + return (dinfo); +} + +static void +ofw_gpiobus_destroy_devinfo(struct ofw_gpiobus_devinfo *dinfo) +{ + + ofw_bus_gen_destroy_devinfo(&dinfo->opd_obdinfo); + free(dinfo, M_DEVBUF); +} + +static int +ofw_gpiobus_probe(device_t dev) +{ + + if (ofw_bus_get_node(dev) == -1) + return (ENXIO); + device_set_desc(dev, "OFW GPIO bus"); + + return (0); +} + +static int +ofw_gpiobus_attach(device_t dev) +{ + struct gpiobus_softc *sc; + phandle_t child; + + sc = GPIOBUS_SOFTC(dev); + sc->sc_busdev = dev; + sc->sc_dev = device_get_parent(dev); + + /* Read the pin max. value */ + if (GPIO_PIN_MAX(sc->sc_dev, &sc->sc_npins) != 0) + return (ENXIO); + + KASSERT(sc->sc_npins != 0, ("GPIO device with no pins")); + + /* + * Increase to get number of pins. + */ + sc->sc_npins++; + + sc->sc_pins_mapped = malloc(sizeof(int) * sc->sc_npins, M_DEVBUF, + M_NOWAIT | M_ZERO); + + if (!sc->sc_pins_mapped) + return (ENOMEM); + + /* Init the bus lock. */ + GPIOBUS_LOCK_INIT(sc); + + bus_generic_probe(dev); + bus_enumerate_hinted_children(dev); + + /* + * Attach the children represented in the device tree. + */ + for (child = OF_child(ofw_bus_get_node(dev)); child != 0; + child = OF_peer(child)) + if (ofw_gpiobus_add_fdt_child(dev, child) == NULL) + continue; + + return (bus_generic_attach(dev)); +} + +static device_t +ofw_gpiobus_add_child(device_t dev, u_int order, const char *name, int unit) +{ + device_t child; + struct ofw_gpiobus_devinfo *devi; + + child = device_add_child_ordered(dev, order, name, unit); + if (child == NULL) + return (child); + devi = malloc(sizeof(struct ofw_gpiobus_devinfo), M_DEVBUF, + M_NOWAIT | M_ZERO); + if (devi == NULL) { + device_delete_child(dev, child); + return (0); + } + + /* + * NULL all the OFW-related parts of the ivars for non-OFW + * children. + */ + devi->opd_obdinfo.obd_node = -1; + devi->opd_obdinfo.obd_name = NULL; + devi->opd_obdinfo.obd_compat = NULL; + devi->opd_obdinfo.obd_type = NULL; + devi->opd_obdinfo.obd_model = NULL; + + device_set_ivars(child, devi); + + return (child); +} + +static int +ofw_gpiobus_print_child(device_t dev, device_t child) +{ + struct ofw_gpiobus_devinfo *devi; + int retval = 0; + + devi = device_get_ivars(child); + retval += bus_print_child_header(dev, child); + retval += printf(" at pin(s) "); + gpiobus_print_pins(&devi->opd_dinfo); + retval += bus_print_child_footer(dev, child); + + return (retval); +} + +static const struct ofw_bus_devinfo * +ofw_gpiobus_get_devinfo(device_t bus, device_t dev) +{ + struct ofw_gpiobus_devinfo *dinfo; + + dinfo = device_get_ivars(dev); + + return (&dinfo->opd_obdinfo); +} + +static device_method_t ofw_gpiobus_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, ofw_gpiobus_probe), + DEVMETHOD(device_attach, ofw_gpiobus_attach), + + /* Bus interface */ + DEVMETHOD(bus_child_pnpinfo_str, ofw_bus_gen_child_pnpinfo_str), + DEVMETHOD(bus_print_child, ofw_gpiobus_print_child), + DEVMETHOD(bus_add_child, ofw_gpiobus_add_child), + + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_devinfo, ofw_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), + + DEVMETHOD_END +}; + +static devclass_t ofwgpiobus_devclass; + +DEFINE_CLASS_1(gpiobus, ofw_gpiobus_driver, ofw_gpiobus_methods, + sizeof(struct gpiobus_softc), gpiobus_driver); +DRIVER_MODULE(ofw_gpiobus, gpio, ofw_gpiobus_driver, ofwgpiobus_devclass, 0, 0); +MODULE_VERSION(ofw_gpiobus, 1); +MODULE_DEPEND(ofw_gpiobus, gpiobus, 1, 1, 1); --Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725 Content-Disposition: attachment; filename=002-iicbb-ofw-iicbus.diff Content-Type: application/octet-stream; name="002-iicbb-ofw-iicbus.diff" Content-Transfer-Encoding: 7bit Index: sys/dev/iicbus/iicbb.c =================================================================== --- sys/dev/iicbus/iicbb.c (revision 258138) +++ sys/dev/iicbus/iicbb.c (working copy) @@ -43,6 +43,8 @@ * */ +#include "opt_platform.h" + #include #include #include @@ -50,6 +52,11 @@ #include #include +#ifdef FDT +#include +#include +#include +#endif #include #include @@ -77,6 +84,9 @@ static int iicbb_read(device_t, char *, int, int *, int, int); static int iicbb_reset(device_t, u_char, u_char, u_char *); static int iicbb_transfer(device_t dev, struct iic_msg *msgs, uint32_t nmsgs); +#ifdef FDT +static phandle_t iicbb_get_node(device_t, device_t); +#endif static device_method_t iicbb_methods[] = { /* device interface */ @@ -98,6 +108,11 @@ DEVMETHOD(iicbus_reset, iicbb_reset), DEVMETHOD(iicbus_transfer, iicbb_transfer), +#ifdef FDT + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_node, iicbb_get_node), +#endif + { 0, 0 } }; @@ -154,6 +169,16 @@ return (0); } +#ifdef FDT +static phandle_t +iicbb_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the I2C bus, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} +#endif + static void iicbb_child_detached( device_t dev, device_t child ) { Index: sys/dev/ofw/ofw_iicbus.c =================================================================== --- sys/dev/ofw/ofw_iicbus.c (revision 258138) +++ sys/dev/ofw/ofw_iicbus.c (working copy) @@ -80,6 +80,7 @@ DEFINE_CLASS_1(iicbus, ofw_iicbus_driver, ofw_iicbus_methods, sizeof(struct iicbus_softc), iicbus_driver); +DRIVER_MODULE(ofw_iicbus, iicbb, ofw_iicbus_driver, ofwiicbus_devclass, 0, 0); DRIVER_MODULE(ofw_iicbus, iichb, ofw_iicbus_driver, ofwiicbus_devclass, 0, 0); MODULE_VERSION(ofw_iicbus, 1); MODULE_DEPEND(ofw_iicbus, iicbus, 1, 1, 1); --Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725 Content-Disposition: attachment; filename=006-ofw-gpio-man.diff Content-Type: application/octet-stream; name="006-ofw-gpio-man.diff" Content-Transfer-Encoding: 7bit Index: share/man/man4/gpioiic.4 =================================================================== --- share/man/man4/gpioiic.4 (revision 258550) +++ share/man/man4/gpioiic.4 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 5, 2013 +.Dd November 26, 2013 .Dt GPIOIIC 4 .Os .Sh NAME @@ -73,12 +73,75 @@ .Va hint.gpioiic.%d.pins should be used as the SCLOCK source. +Optional, defaults to 0. .It Va hint.gpioiic.%d.sda Indicates which bit in the .Va hint.gpioiic.%d.pins should be used as the SDATA source. +Optional, defaults to 1. .El +.Pp +On a +.Xr FDT 4 +based system, like +.Li ARM , the dts part for a +.Nm gpioiic +device usually looks like: +.Bd -literal +gpio: gpio { + + gpio-controller; + ... + + gpioiic0 { + compatible = "gpioiic"; + /* + * Attach to GPIO pins 21 and 22. Set them + * initially as inputs. + */ + gpios = <&gpio 21 1 0 + &gpio 22 1 0>; + scl = <0>; /* GPIO pin 21 */ + sda = <1>; /* GPIO pin 22 */ + + /* This is an example of a gpioiic child. */ + gpioiic-child0 { + compatible = "lm75"; + i2c-address = <0x9e>; + }; + }; +}; +.Ed +.Pp +Where: +.Bl -tag -width ".Va compatible" +.It Va compatible +Should always be set to "gpioiic". +.It Va gpios +The +.Va gpios +property indicates which GPIO pins should be used for SCLOCK and SDATA +on the GPIO IIC bit-banging bus. +For more details about the +.Va gpios +property, please consult +.Pa /usr/src/sys/boot/fdt/dts/bindings-gpio.txt . +.It Va scl +The +.Va scl +option indicates which bit in the +.Va gpios +should be used as the SCLOCK source. +Optional, defaults to 0. +.It Va sda +The +.Va sda +option indicates which bit in the +.Va gpios +should be used as the SDATA source. +Optional, defaults to 1. +.El .Sh SEE ALSO .Xr gpio 4 , .Xr gpioled 4 , Index: share/man/man4/gpioled.4 =================================================================== --- share/man/man4/gpioled.4 (revision 258550) +++ share/man/man4/gpioled.4 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 5, 2013 +.Dd November 26, 2013 .Dt GPIOLED 4 .Os .Sh NAME @@ -68,6 +68,73 @@ Please note that this mask should only ever have one bit set (any others bits - i.e., pins - will be ignored). .El +.Pp +On a +.Xr FDT 4 +based system, like +.Li ARM , the dts part for a +.Nm gpioled +device usually looks like: +.Bd -literal +gpio: gpio { + + gpio-controller; + ... + + led0 { + compatible = "gpioled"; + gpios = <&gpio 16 2 0>; /* GPIO pin 16. */ + name = "ok"; + }; + + led1 { + compatible = "gpioled"; + gpios = <&gpio 17 2 0>; /* GPIO pin 17. */ + name = "user-led1"; + }; +}; +.Ed +.Pp +And optionally, you can choose combine all the leds under a single +.Dq gpio-leds +compatible node: +.Bd -literal +simplebus0 { + + ... + + leds { + compatible = "gpio-leds"; + + led0 { + gpios = <&gpio 16 2 0>; + name = "ok" + }; + + led1 { + gpios = <&gpio 17 2 0>; + name = "user-led1" + }; + }; +}; +.Ed +.Pp +Both methods are equally supported and it is possible to have the leds +defined with any sort of mix between the methods. +The only restriction is that a GPIO pin cannot be mapped by two different +(gpio)leds. +.Pp +For more details about the +.Va gpios +property, please consult +.Pa /usr/src/sys/boot/fdt/dts/bindings-gpio.txt . +.Pp +The property +.Va name +is the arbitrary name of device in +.Pa /dev/led/ +to create for +.Xr led 4 . .Sh SEE ALSO .Xr gpio 4 , .Xr led 4 , --Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725 Content-Disposition: attachment; filename=000-gpio-node.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="000-gpio-node.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/ti/ti_gpio.c =================================================================== --- sys/arm/ti/ti_gpio.c (revision 258855) +++ sys/arm/ti/ti_gpio.c (working copy) @@ -788,6 +788,14 @@ return(0); } +static phandle_t +ti_gpio_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the GPIO bus, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} + static device_method_t ti_gpio_methods[] = { DEVMETHOD(device_probe, ti_gpio_probe), DEVMETHOD(device_attach, ti_gpio_attach), @@ -802,6 +810,10 @@ DEVMETHOD(gpio_pin_get, ti_gpio_pin_get), DEVMETHOD(gpio_pin_set, ti_gpio_pin_set), DEVMETHOD(gpio_pin_toggle, ti_gpio_pin_toggle), + + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_node, ti_gpio_get_node), + {0, 0}, }; Index: sys/arm/broadcom/bcm2835/bcm2835_gpio.c =================================================================== --- sys/arm/broadcom/bcm2835/bcm2835_gpio.c (revision 258855) +++ sys/arm/broadcom/bcm2835/bcm2835_gpio.c (working copy) @@ -762,6 +762,14 @@ return (EBUSY); } +static phandle_t +bcm_gpio_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the GPIO bus, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} + static device_method_t bcm_gpio_methods[] = { /* Device interface */ DEVMETHOD(device_probe, bcm_gpio_probe), @@ -778,6 +786,9 @@ DEVMETHOD(gpio_pin_set, bcm_gpio_pin_set), DEVMETHOD(gpio_pin_toggle, bcm_gpio_pin_toggle), + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_node, bcm_gpio_get_node), + DEVMETHOD_END }; --Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725 Content-Disposition: attachment; filename=000-bbb-gpioled.diff Content-Type: application/octet-stream; name="000-bbb-gpioled.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/conf/BEAGLEBONE =================================================================== --- sys/arm/conf/BEAGLEBONE (revision 258798) +++ sys/arm/conf/BEAGLEBONE (working copy) @@ -101,6 +101,7 @@ # GPIO device gpio +device gpioled # USB support device usb Index: sys/boot/fdt/dts/beaglebone-black.dts =================================================================== --- sys/boot/fdt/dts/beaglebone-black.dts (revision 258798) +++ sys/boot/fdt/dts/beaglebone-black.dts (working copy) @@ -147,6 +147,30 @@ } }; + leds { + compatible = "gpio-leds"; + + led1 { + gpios = <&GPIO 53 2 0>; + name = "led1"; + }; + + led2 { + gpios = <&GPIO 54 2 0>; + name = "led2"; + }; + + led3 { + gpios = <&GPIO 55 2 0>; + name = "led3"; + }; + + led4 { + gpios = <&GPIO 56 2 0>; + name = "led4"; + }; + }; + chosen { stdin = "uart0"; stdout = "uart0"; --Apple-Mail=_8AC709E8-28F7-4B23-B62B-026FF9B7E725-- From owner-freebsd-arch@FreeBSD.ORG Thu Dec 12 20:41: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDDF1337; Thu, 12 Dec 2013 20:41:37 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F19C1660; Thu, 12 Dec 2013 20:41:37 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id w5so109360qac.14 for ; Thu, 12 Dec 2013 12:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Wbu08uSJUAyCMZVWkFPJcDcXkI1aZemhBs9NsXbawg8=; b=Zb6vBdVrpVzyVAGsCtyY7Bnc/Q1ZrTPmvKJ+GsMz/mhZNzkyCMOVqQ81PEBIUNtn77 qIo+Nn2qN1AGmv8iK6osWHdETmsbJz3S+48O11ncR61IlGEy4Gp9on19jJeKYGdPz/PS d+Bg+6/BL9gjaQxdQZGID/xW2fVFHzDi/zpLbMLDYRrPkP8YYA4zx/nrW/yf/8P+2li9 mFPFDx86/cgL2uHJ/Z5KhRQymyleNDKf4uDFVxrGiwIQv0fVsWOTRueevSqj82uemZxm 96C067XOqWVrFuGGrtScSuWXJUicR/ijnFxgTUIqJyB4ZgS2pprfn0UeRKi0FQnfgIF3 19dw== MIME-Version: 1.0 X-Received: by 10.224.50.195 with SMTP id a3mr15839247qag.25.1386880896643; Thu, 12 Dec 2013 12:41:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 12 Dec 2013 12:41:36 -0800 (PST) Date: Thu, 12 Dec 2013 12:41:36 -0800 X-Google-Sender-Auth: lf4nKGruO1FcFSSzD-JNDf_ar48 Message-ID: Subject: review request: sendfile kqueue notification From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 20:41:37 -0000 Hi, I'd like to start committing this to FreeBSD-HEAD: http://people.freebsd.org/~adrian/netflix/20131211-sendfile-kqueue-11.diff It implements kqueue notifications for sendfile so users can get an asynchronous notification that the underlying mbufs have been freed. This allows userland users of sendfile to know that the underlying memory / file object can be recycled or overwritten. Right now the only way to do this is to set SF_SYNC and this causes sendfile() to sleep until the transaction is complete and the mbufs have been freed. I've been testing this out locally in my lab environment and it's running flawlessly at 30gbit/sec of TCP across 32,768 active transmitting sockets. I'd like to start merging this into -HEAD in small pieces to make it easier to MFC to -10. Thanks! -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Dec 12 20:45:17 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30847838; Thu, 12 Dec 2013 20:45:17 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2DA11726; Thu, 12 Dec 2013 20:45:16 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id ii20so117460qab.2 for ; Thu, 12 Dec 2013 12:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=kgcFDTHekBRsotEm60Yqps8P7YBX9zCvKs7S5b22c3I=; b=lEqcFvMsdEQAkd76NflEkZi4kSY0hlgxbAZUpuskHHeQY4o336z9EGBBZESHoa6k+u YBGuo0ZnXuZ7jcCF0y9h2+Uxi93Hs0+JnCLAYuwjhz4gdNnDennp7xgIKIspamli2UrQ bOiPGbPMBjDqLa9Q4xowCsLvz5i6sAAczSFDNN4BnKRagFmLbAqx/dBAxqwTICQRTHSg RV1Q/l9TB2qVWuNI0omfYLvs5oZ1eW7vla/G4eh3pp2sRct0zRDS30miyEy1bnwkHMkU hmN1X3txtTpvc2kZN0oCq05qStpj7T6FTyZQIKIIXiY4NopeWKjEs3TUm9wWOvcl8822 MmNQ== MIME-Version: 1.0 X-Received: by 10.224.80.129 with SMTP id t1mr9628851qak.95.1386881115845; Thu, 12 Dec 2013 12:45:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 12 Dec 2013 12:45:15 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Dec 2013 12:45:15 -0800 X-Google-Sender-Auth: 5SlNet_u6767tqGcwJtWUpsLyAQ Message-ID: Subject: Re: review request: sendfile kqueue notification From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 20:45:17 -0000 And yes, I know this breaks the 32 bit compat sendfile call. I'm thinking of how to fix this without just duplicating all of that code. Thanks, -a On 12 December 2013 12:41, Adrian Chadd wrote: > Hi, > > I'd like to start committing this to FreeBSD-HEAD: > > http://people.freebsd.org/~adrian/netflix/20131211-sendfile-kqueue-11.diff > > It implements kqueue notifications for sendfile so users can get an > asynchronous notification that the underlying mbufs have been freed. > This allows userland users of sendfile to know that the underlying > memory / file object can be recycled or overwritten. Right now the > only way to do this is to set SF_SYNC and this causes sendfile() to > sleep until the transaction is complete and the mbufs have been freed. > > I've been testing this out locally in my lab environment and it's > running flawlessly at 30gbit/sec of TCP across 32,768 active > transmitting sockets. > > I'd like to start merging this into -HEAD in small pieces to make it > easier to MFC to -10. > > Thanks! > > > > -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Dec 12 22:37:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E27ACA8; Thu, 12 Dec 2013 22:37:22 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 831C31065; Thu, 12 Dec 2013 22:37:22 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id E3F3026BCA; Thu, 12 Dec 2013 14:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1386887830; bh=WP1P5VWD5CFJ5QgfvHT68FTtWetCexgTwv1EX1j6bq8=; h=Date:From:Reply-To:To:Subject; b=wJsPcF1BvNYdkpcBBYf9Tn8HRdOnUWz+cWaNBhDrU1i0gbC4TeZwhRJ1vyAQgDli3 rUesY4vHm2FaHaDOu0OsUlueJaEpYeG+tvQrVvKDci1ktnryvgZ6YgLJ6UH67m8aMr lfltokERyApqGDwgOeOmsvue1LybNxpdMc+oHauQ= Message-ID: <52AA3A95.9010904@delphij.net> Date: Thu, 12 Dec 2013 14:37:09 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: "freebsd-arch@FreeBSD.org Arch" , re Subject: Removal of a pre-existing library interface X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 22:37:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Recently, OpenBSD have moved from RC4 to ChaCha20 for their arc4random(3) family of functions and they have later removed a few interfaces for good reasons. On FreeBSD, we aim to maintain ABI stability so we can not simply remove the interface; we can not remove it from -HEAD because they are established by previous -STABLE branches, or we would have to bump major number of shared libraries. After thinking about some other alternatives, I have created two dummy (well, they also log the event) compatibility shims for these two interfaces that gets removed from OpenBSD. Is this a reasonable approach of handling changes like this? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSqjqVAAoJEJW2GBstM+nsCT0P/12NSDuM4ID2tZI/LztkzGiS RKInS+EX1fyofBx1xxrSVdBgulwcA+SQUrKO20iYcuZt+BeNWjc7zQ4GjSDLfvqF NmFXBTd6nIz+bJWXkxOcE7gTrujWm7bJO6RJnYIDkCIrwUdxMe/x4DaC0GW2+5h7 dg3lByP8JAFwUxC4gABUZbka8lpW+qNNPq8BE0tAkPubN0lpLWtI8+00kTYqlcP4 PmbYLq7fepO4XJS11ibFgFcV+hHLbP88BIzb6eyc4ukf86P+RmZGfZywAJasL+oo 0gs4+l33HpUz9hjYWZFcYityY4Gvqc87iqJmnLDqaSq+ToRyIY9SXMYro6VtGJDg H7TQfu3jKriOEFq870W+jhHeU/+p5n264aEXEBEVvfNHTdcYHtBfZy1/p1e1+Jzh 266xXxh4Rd0EFxnuU5W3tRK0MLZkvGTwzPHPfhlqR1uwnZgsCHzmeB0OuTtTaAgb qoiZbEcioukpy1g3kfBOD+QPJqCB3eQiS5g688kiWUi8rXJj6ZW+JW4QxSTnLLVQ TsrugizeNvctGJi5l3KbZG9c7/v9vQSp8hp6woXf2P38Ru5fOihhWSU0Up6t0MqD +NWS3njmL3hVaC2vGxjg61WOuqw3VbkiH3dy5X04mU1aTu8UUF3pkSAO9wLHhfhH fJm3qtcn06PnAgZKVSaD =dXxi -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Fri Dec 13 05:26:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53C71BC9 for ; Fri, 13 Dec 2013 05:26:24 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1BC77119C for ; Fri, 13 Dec 2013 05:26:24 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id rp16so1885218pbb.32 for ; Thu, 12 Dec 2013 21:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=elOdP2fiHlWfGtilYKYH2qiFewCLllms4LwwBbZGDaU=; b=rqK1OL/kXABtDGThS/rfYvKmsi27NeG4OF1odd9ZLzuNslzNs7r3uXUp7YTQp3djBy 2/+WCREW2vXzXBP+1NgJomK3hkS/y9ySHwsK2SHSJFZ7TP25+t8ScYPhsA7pVNmGDymj erDRR9hhjwvC1HXw1omngPj7PXdhJ3K0CIbxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=elOdP2fiHlWfGtilYKYH2qiFewCLllms4LwwBbZGDaU=; b=QQsOvvGPgPGBCRCf1LtIv8bQUpSb7Veri+AgRl5CUmumiaRQwI/10Wxq7vrmpGe1Wt RJEiGqMRrZIGIBm/6cVVLkGPZSA/hidGPU1akRShTgSoGQ8CI6W9DCCBDHipvVHNrnu6 2j63Df7xAhDrJ2uqlOFHV1XAcM1Q7jgfxaYa83EueWrVUwGpsnEnDoadJdjg2/vJ9Rnm UdB9KUcrXm5rci/Ts8BJfBuJBKS9LxccEb3FixjUyIIKiuKBmT5Ce3yfFt0pMe1C1YAh WFOGmXA1iwR1d81Y2ZXFAwHV83dTwaDmMvaDrHL3lwWSI2IEbINki/72AebDKIrjdYdi 8/yA== X-Gm-Message-State: ALoCoQl4nD2zBMSIerGFaVekVkWbcvS9hLpeVvM3VT2Vpn3gDt6zhWsRM0/SNIfl/Jgr01JrB/1V X-Received: by 10.68.244.168 with SMTP id xh8mr919529pbc.3.1386912383795; Thu, 12 Dec 2013 21:26:23 -0800 (PST) Received: from hackintosh.wemm.org (c-71-198-8-135.hsd1.ca.comcast.net. [71.198.8.135]) by mx.google.com with ESMTPSA id ik1sm1669240pbc.9.2013.12.12.21.26.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 21:26:22 -0800 (PST) Message-ID: <52AA9A7E.8030500@wemm.org> Date: Thu, 12 Dec 2013 21:26:22 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Removal of a pre-existing library interface References: <52AA3A95.9010904@delphij.net> In-Reply-To: <52AA3A95.9010904@delphij.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aV4TNWpD6EQf4vKHqotjFT96nJOBuIiHr" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 05:26:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aV4TNWpD6EQf4vKHqotjFT96nJOBuIiHr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/12/13, 2:37 PM, Xin Li wrote: > Hi, >=20 > Recently, OpenBSD have moved from RC4 to ChaCha20 for their > arc4random(3) family of functions and they have later removed a few > interfaces for good reasons. >=20 > On FreeBSD, we aim to maintain ABI stability so we can not simply > remove the interface; we can not remove it from -HEAD because they are > established by previous -STABLE branches, or we would have to bump > major number of shared libraries. After thinking about some other > alternatives, I have created two dummy (well, they also log the event) > compatibility shims for these two interfaces that gets removed from > OpenBSD. >=20 > Is this a reasonable approach of handling changes like this? If you wish to avoid a major bump and the symbols are versioned (as they = are in libc), the one option is this: rename function from arcfour_foo to arcfour_foo_compat and _sym_compat(arcfour_foo, arcfour_foo_compat, FBSD_1.3); That then provides a versioned symbol to satisfy runtime dependencies but= will not allow new references. We did this with the iconv stuff for early 10.x binaries that we didn't w= ant to break but make sure there were no new unintended references. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --aV4TNWpD6EQf4vKHqotjFT96nJOBuIiHr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKqmoIACgkQFRKuUnJ3cX/70gCgiVUvLYfJMhhn2TWY9pWIrY0d AYIAoJnzGhy1Dtj28HGhO0LZwipEi+yP =mz8X -----END PGP SIGNATURE----- --aV4TNWpD6EQf4vKHqotjFT96nJOBuIiHr-- From owner-freebsd-arch@FreeBSD.ORG Fri Dec 13 05:32:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01185EFB for ; Fri, 13 Dec 2013 05:32:40 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D46951282 for ; Fri, 13 Dec 2013 05:32:39 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 5503326488; Thu, 12 Dec 2013 21:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1386912759; bh=AJsQj0VWHbft8ArP30SVHvQZeogSi4PKm9OHPcnjDfM=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=tImHu5Q/uZIkVxvkfKvGejOcEtWOxrhw+fsT0lGqH+5qOwRTt9NRnVpf7a+ssLDfl XGkrFWNtRLlaD/jhbxJfnH1datUUJ3qu/bvpeTVNGqqrSGSt00BQ0wy9kymINy1Th8 jsbGM5vWykytwScN87ZvaB0XLZdckgW4bKmSlx4k= Message-ID: <52AA9BF5.2080406@delphij.net> Date: Thu, 12 Dec 2013 21:32:37 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Peter Wemm , freebsd-arch@freebsd.org Subject: Re: Removal of a pre-existing library interface References: <52AA3A95.9010904@delphij.net> <52AA9A7E.8030500@wemm.org> In-Reply-To: <52AA9A7E.8030500@wemm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 05:32:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/12/13, 9:26 PM, Peter Wemm wrote: > On 12/12/13, 2:37 PM, Xin Li wrote: >> Hi, >> >> Recently, OpenBSD have moved from RC4 to ChaCha20 for their >> arc4random(3) family of functions and they have later removed a >> few interfaces for good reasons. >> >> On FreeBSD, we aim to maintain ABI stability so we can not >> simply remove the interface; we can not remove it from -HEAD >> because they are established by previous -STABLE branches, or we >> would have to bump major number of shared libraries. After >> thinking about some other alternatives, I have created two dummy >> (well, they also log the event) compatibility shims for these two >> interfaces that gets removed from OpenBSD. >> >> Is this a reasonable approach of handling changes like this? > > If you wish to avoid a major bump and the symbols are versioned (as > they are in libc), the one option is this: > > rename function from arcfour_foo to arcfour_foo_compat and > _sym_compat(arcfour_foo, arcfour_foo_compat, FBSD_1.3); > > That then provides a versioned symbol to satisfy runtime > dependencies but will not allow new references. > > We did this with the iconv stuff for early 10.x binaries that we > didn't want to break but make sure there were no new unintended > references. Yes I know this. Forgot to add the link in previous email. https://github.com/delphij/freebsd/blob/featurefork/chacha20/lib/libc/gen/arc4random-compat.c What I'm not clear is whether it's Okay to call syslog() in the context. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSqpv1AAoJEJW2GBstM+nslRgP+gMfXWVCKM1o+RxWNxcVVNOi NWiYcXiFuIwpY0fmtlmoEClG7Re1ZyPPkXQIec5pKMZHrl+KFnqLRdcrxOrgIMa6 1M2YtDRGno+NhkoOvD3ZhqhI1UEL5olpnpqq36Zcc+oe8Vk3H2hk8WNFbhuLpMef 5uidrCG7tGY6w7U2fBHNK0Fl0+GaTpRMB4AvJ+MzqIj65doY0rWbtBjAybWcdid/ kOQN7XTlueNnu54IMeeA0a8kO7oZq2YLeL9/gdocOYbRACnyoLBcoc2R18A+ldNU CKsKS7BioXlpUG3K3UDCg6qSqmIm4RkSX5RlFfTLPJy7s7O4w8ppgL4L56BqbJAw y8IbjQXqZhUH7kqCcWBwGXYyoK1+93SeoPuq3MAmzLhmIGnbTrUuuC/vZCQJXv0c L0UEkZ5X5yXZqW3D5BOBru1Frp1nBXn7m02Cwl5T1BI5G+kcHonlxu3g0Vmj1CHB paE2gBbXr8S0mmOBviT9Jx61Ph1tXmV9yysxqrCqMJDq1E1BFyNX+9W7sDZi43H7 6NmS17g+MfGbneyGhdRzxcaqgK+qQpa1EpTVQik+pSWnvckm1vwcOs/t6TRWOMaO o/CLfO1plyJ8gggqO0kbfzVpTNEYC5QiHG0VtO5GIay2vgMT7ZYVUfnSLo0ZMklj AFUqOvnhixhmTUXEXSFQ =9nu1 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Sat Dec 14 19:29:09 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5259E380 for ; Sat, 14 Dec 2013 19:29:09 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 076C817FE for ; Sat, 14 Dec 2013 19:29:08 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id i13so475630qae.17 for ; Sat, 14 Dec 2013 11:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UEXxUrgi4P0ayz80s+VfjJfNHHMgetunm6H3ctioAsk=; b=Su6vE8db8qOyE1tBnJ+Cz50zcPVP8+hRqaDVNXGPFSMgPHUBgNnQbp2Q/RExTjPHM5 T/Y8DNRfitrilnLo/OgRsimAFEbODeZFsh9wgSe3peEMv4GVKZC1SzYuSZnNCBlQgvYF dBGCKGP9Fbg6gObq/j5uocLl21zHDXEunD7Ns= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=UEXxUrgi4P0ayz80s+VfjJfNHHMgetunm6H3ctioAsk=; b=OlSi3lI8GpaSV/lcrQXngy0t5q1MfElRr3dPmD3ghT41KlTeLZHl0/+VQoCwurp4dU O6HRAFxvsdlqT+jQ0VgeBeZ1d7KbzsLGDQbCEmVW7BdDIBJ38IUvSgm4qlG/q30enmHW SiGi+b/EhEpmWY/AcEVJY1viMAlWwjVRa9g2xPI8tHKc6tbAiz9C0bRnZXBFTo4G4dMQ QrzZWfwiadd/xJ92yDfJECYPLpFWGUkvrLjHViEqAe+5N/xcgJnKa+tbGkmJDCqEb+Tl g2C85L+0/GmW0ZkvlSFmG7+tQKLFbYcqb4WbfEHYCYzVlcZC0ckjuC+PthoxSvaB59uy yNmQ== X-Gm-Message-State: ALoCoQnMm+PZYixW7W5j49yUJOPLFK1mZh22VYvccZNq901bsmpcGrIdWFbtzW9ajx2xVimehH5z X-Received: by 10.49.25.109 with SMTP id b13mr17518244qeg.3.1387049348116; Sat, 14 Dec 2013 11:29:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.86.42 with HTTP; Sat, 14 Dec 2013 11:28:36 -0800 (PST) In-Reply-To: References: <523457A1.3090606@debian.org> From: Eitan Adler Date: Sat, 14 Dec 2013 14:28:36 -0500 Message-ID: Subject: Re: IPSEC To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Robert Millan , "debian-bsd@lists.debian.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 19:29:09 -0000 Hi arch@, The question below has been unanswered since Sat, Sep 14, 2013. Are there any known concerns with enabling IPSEC? Is there any reason to not do so in GENERIC? On Sun, Dec 8, 2013 at 2:02 PM, Olivier Cochard-Labb=C3=A9 wrote: > On Sun, Dec 8, 2013 at 12:16 AM, Eitan Adler wrote= : >> Hi all, >> >> I understand this is an old thread but I do not see an answer here. >> Can anyone answer the question below? >> >> On Sat, Sep 14, 2013 at 8:33 AM, Robert Millan wrote: >>> >>> Hi! >>> >>> Is there any particular reason (performance, stability concerns...) >>> IPSEC support is not enabled in GENERIC? >>> >>> In Debian GNU/kFreeBSD we're considering enabling it in our default >>> builds, due to increased user demand and as it is already enabled for >>> our Linux-based flavours. >>> >>> However we're concerned about diverging from FreeBSD as there might be >>> unforeseen consequences. Is there any specific concern on your side? >>> >>> If not, perhaps it could be considered for HEAD after 10.0 release? >> >> > > Here are my own bench result regarding forwarding speed (paquet-per-secon= d) > with a kernel compiled without-ipsec and with ipsec (ipsec is not enabled > during the tests, just present on the kernel) of FreeBSD 10.0-PRERELEASE: > > ministat -s without-ipsec ipsec > x without-ipsec > + ipsec > +------------------------------------------------------------------------= --------+ > |x + x + +x x x + > +| > | |__________________A_____M____________| > | > | |_______________M_________A__________________________| > | > +------------------------------------------------------------------------= --------+ > N Min Max Median Avg Stdd= ev > x 5 1646075 1764528 1725461 1713080 44560.0= 59 > + 5 1685034 1833206 1724461 1748666.8 62356.2= 18 > No difference proven at 95.0% confidence > > I didn't see negative impact of enabling ipsec (it's even a little bit > better with it). > > Regards, > > Olivier --=20 Eitan Adler