lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 16 Jan 2012 11:28:08 -0700 From: Grant Likely <grant.likely@...retlab.ca> To: Stephen Warren <swarren@...dia.com> Cc: Dong Aisheng-B29396 <B29396@...escale.com>, "linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>, "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>, "rob.herring@...xeda.com" <rob.herring@...xeda.com>, "kernel@...gutronix.de" <kernel@...gutronix.de>, "cjb@...top.org" <cjb@...top.org>, "Simon Glass (sjg@...omium.org)" <sjg@...omium.org>, Dong Aisheng <dongas86@...il.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "devicetree-discuss@...ts.ozlabs.org" <devicetree-discuss@...ts.ozlabs.org> Subject: Re: Pinmux bindings proposal On Fri, Jan 13, 2012 at 12:39:42PM -0800, Stephen Warren wrote: > I thought a bit more about pinmux DT bindings. I came up with something > that I like well enough, and is pretty similar to the binding that Dong > posted recently. I think it'll work for both Tegra's and IMX's needs. > Please take a look! > > Note: I've used named constants below just to make this easier to read. > We still don't have a solution to actually use named constants in dtc yet. > > tegra20.dtsi: > > / { > tegra_pmx: pinmux@...00000 { > compatible = "nvidia,tegra20-pinmux"; > reg = <0x70000014 0x10 /* Tri-state registers */ > 0x70000080 0x20 /* Mux registers */ > 0x700000a0 0x14 /* Pull-up/down registers */ > 0x70000868 0xa8>; /* Pad control registers */ > }; > > sdhci@...00200 { > compatible = "nvidia,tegra20-sdhci"; > reg = <0xc8000200 0x200>; > interrupts = <0 15 0x04>; > }; > }; > > tegra-harmony.dts: > > /{ > sdhci@...00200 { > cd-gpios = <&gpio 69 0>; /* gpio PI5 */ > wp-gpios = <&gpio 57 0>; /* gpio PH1 */ > power-gpios = <&gpio 155 0>; /* gpio PT3 */ > > /* > * A list of named configurations that this device needs. > * Format is a list of <"name" &phandle_of_pmx_configuration> > * > * Multiple "name"s are needed e.g. to support active/suspend, > * or whatever device-defined states are appropriate. The > * device defines which names are needed, just like a device > * defines which regulators, clocks, GPIOs, interrupts, ... > * it needs. > * > * This example shows a 1:1 relation between name and phandle. > * We might want a 1:n relation, so that we can blend multiple > * pre-defined sets of data together, e.g. one pre-defined set > * for the pin mux configuration, another for the pin config > * settings, both being put into the single "default" setting > * for this one device. > * > * A pinmux controller can contain this property too, to > * define "hogged" or "system" pin mux configuration. > * > * Note: Mixing strings and integers in a property seems > * unusual. However, I have seen other bindings floating > * around that are starting to do this... > */ > pinmux = > <"default" &pmx_sdhci_active> > <"suspend" &pmx_sdhci_suspend>; > > /* 1:n example: */ > pinmux = > <"default" &pmx_sdhci_mux_a> > <"default" &pmx_sdhci_pincfg_a> > <"suspend" &pmx_sdhci_mux_a> > <"suspend" &pmx_sdhci_pincfg_a_suspend>; Yeah, don't do this. Mixing phandle, string and cell values in a property gets messy and could become troublesome to parse. I've backed away from it in the clk binding. pinumx-* is better, but I'm not thrilled with it and I avoided that pattern too for the latest iteration of the clk binding. I prefer using a "pinmux" + "pinmux-names" pair of properties when dealing with an array of like objects (ie. reg, interrupts, clks, etc), but that might not fit well since each setting has multiple state nodes. > > /* > * Alternative: One property for each required state. But, > * how does pinctrl core know which properties to parse? > * Every property named "pinctrl*" seems a little too far- > * reaching. Perhaps if we used vendor-name "pinmux", that'd > * be OK, i.e. pinmux,default and pinmux,suspend? It isn't actually a vendor name, so don't use a ','. "pinmux-" prefix is fine. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists