From owner-freebsd-arch@FreeBSD.ORG Mon Jun 24 12:36:16 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 0DDEB30B; Mon, 24 Jun 2013 12:36:16 +0000 (UTC) (envelope-from luiz.souza@ad.com.br) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by mx1.freebsd.org (Postfix) with ESMTP id CDD4B1476; Mon, 24 Jun 2013 12:36:14 +0000 (UTC) Received: from mail10-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 12:21:06 +0000 Received: from mail10-co1 (localhost [127.0.0.1]) by mail10-co1-R.bigfish.com (Postfix) with ESMTP id 8029B68023C; Mon, 24 Jun 2013 12:21:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:207.46.4.203; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD8002HT001.lamprd80.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zz98dI9371Ic85fhde40hzz1f42h1ee6h1de0h1d18h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h34h1155h) Received-SPF: pass (mail10-co1: domain of ad.com.br designates 207.46.4.203 as permitted sender) client-ip=207.46.4.203; envelope-from=luiz.souza@ad.com.br; helo=SN2PRD8002HT001.lamprd80.prod.outlook.com ; .outlook.com ; Received: from mail10-co1 (localhost.localdomain [127.0.0.1]) by mail10-co1 (MessageSwitch) id 1372076465232506_5473; Mon, 24 Jun 2013 12:21:05 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.249]) by mail10-co1.bigfish.com (Postfix) with ESMTP id 2B88C4A0048; Mon, 24 Jun 2013 12:21:05 +0000 (UTC) Received: from SN2PRD8002HT001.lamprd80.prod.outlook.com (207.46.4.203) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 12:21:03 +0000 Received: from adnote108.ad.adseguros.com.br (201.72.203.67) by pod51028.outlook.com (10.27.50.185) with Microsoft SMTP Server (TLS) id 14.15.129.14; Mon, 24 Jun 2013 12:20:57 +0000 Subject: Re: FDT Support for GPIO (gpiobus and friends) MIME-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/mixed; boundary="Apple-Mail-14-779745624" From: Luiz Otavio O Souza In-Reply-To: Date: Mon, 24 Jun 2013 09:20:53 -0300 Message-ID: <04AEF097-025D-4B3F-A345-98878AE4A822@ad.com.br> References: <20121205.060056.592894859995638978.hrs@allbsd.org> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1085) X-Originating-IP: [201.72.203.67] X-OriginatorOrg: ad.com.br 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: Mon, 24 Jun 2013 12:36:16 -0000 --Apple-Mail-14-779745624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Jun 21, 2013, at 6:05 PM, Luiz Otavio O Souza wrote: +int +gpiobus_fdt_add_child(device_t bus, phandle_t childnode) +{ [...] + /* Add newbus device for the child. */ + child =3D device_add_child(bus, NULL, -1); This is obviously wrong.. it should only probe the specified type of = drivers... The attached patch fix this problem. Now i can have things like: Index: bcm2835-rpi-b.dts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bcm2835-rpi-b.dts (revision 251700) +++ bcm2835-rpi-b.dts (working copy) @@ -518,7 +518,7 @@ =20 ok { label =3D "ok"; - gpios =3D <&gpio 16 1>; + gpios =3D <&gpio 16 2 0>; =20 /* Don't change this - it configures * how the led driver determines if @@ -529,8 +529,24 @@ /* This is the real default state. */ linux,default-trigger =3D "default-on"; }; + + blue { + label =3D "blue"; + gpios =3D <&sr1 3 2 0>; + }; }; =20 + shift-registers { + compatible =3D "gpio-shiftregister"; + + sr1: sr1 { + gpios =3D <&gpio 17 2 0 + &gpio 21 2 0 + &gpio 22 2 0>; + gpio-controller; + }; + }; + power: regulator { compatible =3D "broadcom,bcm2835-power-mgr", = "broadcom,bcm2708-power-mgr", "simple-bus"; #address-cells =3D <1>; And everything attaches correctly: gpio0: mem 0x20200000-0x202000af irq = 57,59,58,60 on simplebus0 gpio0: read-only pins: 46,47,48,49,50,51,52,53. gpio0: reserved pins: 48,49,50,51,52,53. gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 16 on gpiobus0 gpioshiftreg0: at pin(s) 17,21-22 on = gpiobus0 gpioc1: on gpioshiftreg0 gpiobus1: on gpioshiftreg0 gpioled1: at pin(s) 3 on gpiobus1 Regards, Luiz --Apple-Mail-14-779745624 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(driver_t *driver, 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, driver->name, -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(driver_t *, 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(driver, 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-14-779745624-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 24 14:52:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9C715F7 for ; Mon, 24 Jun 2013 14:52:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id AA2131C09 for ; Mon, 24 Jun 2013 14:52:22 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so25249875ieb.10 for ; Mon, 24 Jun 2013 07:52:22 -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=y0/Xs9Aqu4X96QrhSxSUEOr6TSLY8vV81etXPjpDclM=; b=kA9TXQDKUucP9Nt66Mx4xl6ksE3WA+y40eMm0QxZzbPU+Xz1puaRQIOcvkop33cOZ3 G1rgzzp6GQoYO9N/7xgIAPY6P4oNaXFhGsZocqUSQjOsH3docpQbxOAdTnIWCPQgSo4d TX/HXYZOaWmgeQznaGBjWg7H5tkomrWNKhgXmvdxAXYLt5XJE0A7v6ymcD9mdum3jegO UCWQmw23393lIkd1Pc/Mn4ERb+ob/jxRGvsRSm2JtSp4WSzUIuJv7H+2+j4/cKmHIDAv yWmGJOoIPL4qewqM6CGFCe24/4MKb04BU2i7K7ULEtni0F5DkMZ+uy0TXtO+34SqgAxj gidg== X-Received: by 10.50.112.5 with SMTP id im5mr5905752igb.23.1372085542331; Mon, 24 Jun 2013 07:52:22 -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 kj5sm396200igb.7.2013.06.24.07.52.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 07:52:21 -0700 (PDT) Sender: Warner Losh Subject: Re: FDT Support for GPIO (gpiobus and friends) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <04AEF097-025D-4B3F-A345-98878AE4A822@ad.com.br> Date: Mon, 24 Jun 2013 08:52:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1142ABEB-7FDA-4CFE-9D12-F8FD2D4C85D6@bsdimp.com> References: <20121205.060056.592894859995638978.hrs@allbsd.org> <04AEF097-025D-4B3F-A345-98878AE4A822@ad.com.br> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkz1Z8t8yMUNNno4PiXLFmkW4/AzORIhA3Kkp9rCWq/3MLb38DUgruiPS2750QnMiPb4UHv Cc: freebsd-arch@FreeBSD.org, Luiz Otavio O Souza 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: Mon, 24 Jun 2013 14:52:23 -0000 I'm loving this patch, mostly. But I don't see where the ivar gets freed... Perhaps this is because we = dont' support detaching GPIOs? Warner On Jun 24, 2013, at 6:20 AM, Luiz Otavio O Souza wrote: > On Jun 21, 2013, at 6:05 PM, Luiz Otavio O Souza wrote: >=20 > +int > +gpiobus_fdt_add_child(device_t bus, phandle_t childnode) > +{ > [...] > + /* Add newbus device for the child. */ > + child =3D device_add_child(bus, NULL, -1); >=20 >=20 > This is obviously wrong.. it should only probe the specified type of = drivers... >=20 > The attached patch fix this problem. Now i can have things like: >=20 > Index: bcm2835-rpi-b.dts > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- bcm2835-rpi-b.dts (revision 251700) > +++ bcm2835-rpi-b.dts (working copy) > @@ -518,7 +518,7 @@ >=20 > ok { > label =3D "ok"; > - gpios =3D <&gpio 16 1>; > + gpios =3D <&gpio 16 2 0>; >=20 > /* Don't change this - it configures > * how the led driver determines if > @@ -529,8 +529,24 @@ > /* This is the real default state. */ > linux,default-trigger =3D "default-on"; > }; > + > + blue { > + label =3D "blue"; > + gpios =3D <&sr1 3 2 0>; > + }; > }; >=20 > + shift-registers { > + compatible =3D "gpio-shiftregister"; > + > + sr1: sr1 { > + gpios =3D <&gpio 17 2 0 > + &gpio 21 2 0 > + &gpio 22 2 0>; > + gpio-controller; > + }; > + }; > + > power: regulator { > compatible =3D "broadcom,bcm2835-power-mgr", = "broadcom,bcm2708-power-mgr", "simple-bus"; > #address-cells =3D <1>; >=20 >=20 > And everything attaches correctly: >=20 > gpio0: mem 0x20200000-0x202000af irq = 57,59,58,60 on simplebus0 > gpio0: read-only pins: 46,47,48,49,50,51,52,53. > gpio0: reserved pins: 48,49,50,51,52,53. > gpioc0: on gpio0 > gpiobus0: on gpio0 > gpioled0: at pin(s) 16 on gpiobus0 > gpioshiftreg0: at pin(s) 17,21-22 on = gpiobus0 > gpioc1: on gpioshiftreg0 > gpiobus1: on gpioshiftreg0 > gpioled1: at pin(s) 3 on gpiobus1 >=20 >=20 > Regards, > Luiz >=20 >=20 > _______________________________________________ > 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 Wed Jun 26 11:53:46 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78470D42 for ; Wed, 26 Jun 2013 11:53:46 +0000 (UTC) (envelope-from user@atena.prefo.pl) Received: from atena.prefo.pl (atena.prefo.pl [188.165.80.169]) by mx1.freebsd.org (Postfix) with ESMTP id 495A21069 for ; Wed, 26 Jun 2013 11:53:46 +0000 (UTC) Received: by atena.prefo.pl (Postfix, from userid 10025) id AA3C21C2259A; Wed, 26 Jun 2013 13:44:27 +0200 (CEST) To: freebsd-arch@freebsd.org Subject: =?utf-8?B?Kw==?= X-PHP-Originating-Script: 10025:actives.php From: =?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAICjRgdC70YPQttCx0LAg0YDQsNGB0YHRi9C70L7QuiDQv9C40YHQtdC8?= Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Date: Wed, 26 Jun 2013 13:44:27 +0200 (CEST) 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, 26 Jun 2013 11:53:46 -0000 Добрый день Меня зовут Александр. Я профессионально занимаюсь электронными рассылками. Предлагаю прорекламировать Ваше рекламное объявление по любой нужной базе данных. Если Вам интересно - будет сформирована базу возможных потенциальных клиентов. Если это возможно - сообщите пожалуйста Ваш Ваш телефон или skype, я объясню о данном виде рекламы более детально. С уважением, Александр. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 26 22:53:33 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 75AC4D55 for ; Wed, 26 Jun 2013 22:53:33 +0000 (UTC) (envelope-from bounces+612829-ba58-arch=freebsd.org@sendgrid.info) Received: from o3.bn.sendgrid.net (o3.bn.sendgrid.net [198.21.6.101]) by mx1.freebsd.org (Postfix) with SMTP id 4ABFF120D for ; Wed, 26 Jun 2013 22:53:32 +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=oMJUCX28ek9POs GbGRPhsZsrMls=; b=wl+KJgs1pKAw+BsUDv3pGkNyhlfsMlYee9CSOKMLscIiqJ NYN4yIXSxhL0CP3t34qux9XjNOUJtcndhshmjMMgxQHRvwm2cyKFQBHjvsCFsbpF w/nb52YmwlIiGrvzdnHQQZawJG5E4kaLzlWt6hw764FAGHoPVmaecJBzg74AY= Received: by 10.37.85.82 with SMTP id mf97.16720.51CB70E67 Wed, 26 Jun 2013 22:53:26 +0000 (UTC) Received: from (ool-18e496ee.dyn.optonline.net [24.228.150.238]) by mi23 (SG) with ESMTP id 13f82b1047e.51e8.7f9f3f for ; Wed, 26 Jun 2013 17:53:26 -0500 (CST) From: TheUrbanShopper To: Date: Wed, 26 Jun 2013 18:53:29 -0400 Subject: In this Issue: Life Coaches, 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: <1372287206.6760818037934475@mf97> X-SG-EID: PYCKI43QWrQUfl7nqliIpR4qzPlu41Kt+60rv5InnxHUmHsHDB3IoI4JeeJE8pbavuihO/b9vAI9kXYbPi5IEH+jtXjcpRtDm8G11arCSzSF87UVSd5i+gIBD2ODUX3U 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, 26 Jun 2013 22:53:33 -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 Fri Jun 28 18:46: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 0CAA2A82; Fri, 28 Jun 2013 18:46:21 +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 DCA971ECF; Fri, 28 Jun 2013 18:46:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A67DB91A; Fri, 28 Jun 2013 14:46:19 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT Date: Fri, 28 Jun 2013 14:46:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua> In-Reply-To: <20130522084145.GJ3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201306281446.01797.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Jun 2013 14:46:19 -0400 (EDT) Cc: arch@freebsd.org, "Robert N. M. Watson" , Jilles Tjoelker 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, 28 Jun 2013 18:46:21 -0000 On Wednesday, May 22, 2013 4:41:45 am Konstantin Belousov wrote: > On Tue, May 21, 2013 at 03:24:50PM -0400, Robert N. M. Watson wrote: > > > > On 21 May 2013, at 12:22, John Baldwin wrote: > > > > >> If it is ioctl-like, it is possible to redirect ioctl() on a process > > >> descriptor to procctl and use cap_ioctls_limit() infrastructure. I'm not > > >> sure Capsicum people actually like that, though. > > >> > > >> In either case, it is possible to have a P_PROCDESC to affect a process > > >> by process descriptor. Capsicum may then need more CAP_*. > > > > > > I talked to Robert about this in person at BSDCan and he indeed does not > > > prefer general purpose multiplexers for system calls. In particular it does > > > make auditing and access control for such things a lot harder to do. My > > > impression from my discussion with him is that he would actually prefer much > > > more narrowly focused system calls (so pprotect() in this case rather than a > > > generic procctl()). > > > > Yes -- based on experience with Capsicum, audit, but also things > like ktrace, LD_PRELOAD, etc, I have a strong preference for not using > ioctl for first-class (global) functions. We shouldn't go crazy on > new system calls, but key new abstraction functions in the kernel do > reasonably deserve new APIs. Matching pprotect() and pdprotect() APIs > sound plausible to me (without skimming back through the thread too > much). > > I agree with statement that an ioctl()-like interface for the syscall > is too wide, and I stated this already. On the other hand, I believe > that e.g. ptrace(2) is fine as is, and splitting it into 20-30 syscalls > each performing single ptrace operation would be a mistake. The same, > IMO, holds for the procctl() syscall, which is better not split into > pprotect(), then some improved version of pprotect() etc. I would prefer > to not have proliferation of the FreeBSD-specific process-controlling > syscalls, which could be cumulated in the single entry and single man > page. Ok, there isn't really a clear consensus here, but I need a system call to let me toggle this flag on existing processes. One reason I don't like the procctl() approach is I am uneasy about forcing a certain behavior for how commands treat pgid (first-fail vs best-effort). I guess it can always change in the future so that isn't completely unsolvable. I guess I am fine just making it use hardcoded sizes instead of full-blown ioctl encoding. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Jun 29 15:08: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 32B1F7F0; Sat, 29 Jun 2013 15:08: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 8193C1981; Sat, 29 Jun 2013 15:08:09 +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 r5TF84wF045022; Sat, 29 Jun 2013 18:08:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5TF84wF045022 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5TF84WL045021; Sat, 29 Jun 2013 18:08:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 29 Jun 2013 18:08:04 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130629150804.GC91021@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua> <201306281446.01797.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VNNQie1NYARlNv6L" Content-Disposition: inline In-Reply-To: <201306281446.01797.jhb@freebsd.org> 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, "Robert N. M. Watson" , Jilles Tjoelker 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: Sat, 29 Jun 2013 15:08:10 -0000 --VNNQie1NYARlNv6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 02:46:01PM -0400, John Baldwin wrote: > On Wednesday, May 22, 2013 4:41:45 am Konstantin Belousov wrote: > > On Tue, May 21, 2013 at 03:24:50PM -0400, Robert N. M. Watson wrote: > > >=20 > > > On 21 May 2013, at 12:22, John Baldwin wrote: > > >=20 > > > >> If it is ioctl-like, it is possible to redirect ioctl() on a proce= ss > > > >> descriptor to procctl and use cap_ioctls_limit() infrastructure. I= 'm not > > > >> sure Capsicum people actually like that, though. > > > >>=20 > > > >> In either case, it is possible to have a P_PROCDESC to affect a pr= ocess > > > >> by process descriptor. Capsicum may then need more CAP_*. > > > >=20 > > > > I talked to Robert about this in person at BSDCan and he indeed doe= s not=20 > > > > prefer general purpose multiplexers for system calls. In particula= r it does=20 > > > > make auditing and access control for such things a lot harder to do= =2E My=20 > > > > impression from my discussion with him is that he would actually pr= efer much=20 > > > > more narrowly focused system calls (so pprotect() in this case rath= er than a=20 > > > > generic procctl()). > > >=20 > > > Yes -- based on experience with Capsicum, audit, but also things > > like ktrace, LD_PRELOAD, etc, I have a strong preference for not using > > ioctl for first-class (global) functions. We shouldn't go crazy on > > new system calls, but key new abstraction functions in the kernel do > > reasonably deserve new APIs. Matching pprotect() and pdprotect() APIs > > sound plausible to me (without skimming back through the thread too > > much). > >=20 > > I agree with statement that an ioctl()-like interface for the syscall > > is too wide, and I stated this already. On the other hand, I believe > > that e.g. ptrace(2) is fine as is, and splitting it into 20-30 syscalls > > each performing single ptrace operation would be a mistake. The same, > > IMO, holds for the procctl() syscall, which is better not split into > > pprotect(), then some improved version of pprotect() etc. I would prefer > > to not have proliferation of the FreeBSD-specific process-controlling > > syscalls, which could be cumulated in the single entry and single man > > page. >=20 > Ok, there isn't really a clear consensus here, but I need a system call t= o let > me toggle this flag on existing processes. >=20 > One reason I don't like the procctl() approach is I am uneasy about forci= ng > a certain behavior for how commands treat pgid (first-fail vs best-effort= ). > I guess it can always change in the future so that isn't completely unsol= vable. >=20 > I guess I am fine just making it use hardcoded sizes instead of full-blown > ioctl encoding. I definitely like the ptrace-style syscall (i.e. hardcoded argument structu= res sizes) most. But I repeat myself. Also, I think that best efforts is fair, while first fail causes unpredicta= ble behaviour. My 0.02UAH, sorry for causing this discussion at all. --VNNQie1NYARlNv6L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzvhUAAoJEJDCuSvBvK1BPVIQAJ7moQaM3Kf//hJswXKNeyxM 1bXFIYQnhn6dEPN9jtDdUe0jdjd6Q42wXpwAHR5y0eQKzoVFLoLrmkHzM/wR4dUz PWvlRnBiJdrIX8W5to2jtiHSxfpMKJamJ2u8VT5FPsMCuDXoyRz6Wz/2Egc4F3nx ljCaroMJSJTF5QALGcTKFwsJ4/j/o02KXWVB8R4kuTvy5BDNC680RFdHw4DScTGH XYWRLdGI+p6ZPd3fRgXP+gf9bHOoXO236opwYBSwI28vXpSgJbrh1nmdKlO+9DH5 zUtGrW9VMpLQ1ub4sRpKHmEiIug17Q2q8TyxPAbJGBeE3tQKTvl37cpQvf5o3R/2 XqW0z/wyxzTjv4Dw0EDFr8j58KMCEVnJaG4D+Oo4Adg0V3kyinUoi4OOLuPE8cQa ImLfqLnANy1Z8iDU7e2yW4fT/hUpcFSD3GHPv2kjguJnyp2JkUTCyRN9JgjBEh5g JEsClyr6toW4rLugVQDae/x8UnzFmKVUJ0mB/ubYhMtVFO+1zcVLfPBFQTzP5mMW 1lACxk+mKqkBI98DakrIVx1zHytY1OPkXdlNWdvcchWpQlmOaganmkixMBVUXQVk B57aXE53MgPbptFlHpDuALlNYtZCXAIlvu1si1mxQcUI7jrQV3jaVrl9aJ3lWNJI duPVfcN75WXKv89hdD8i =VTcG -----END PGP SIGNATURE----- --VNNQie1NYARlNv6L--