linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Nov 2012 10:35:32 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Rob Herring <robherring2@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Scott Wood <scottwood@...escale.com>,
	Russ Dill <Russ.Dill@...com>, Felipe Balbi <balbi@...com>,
	Benoit Cousson <b-cousson@...com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, linux-omap@...r.kernel.org,
	Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving
 omap_devices to mach-omap2)

* Grant Likely <grant.likely@...retlab.ca> [121106 03:16]:
> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
> <panto@...oniou-consulting.com> wrote:
> >
> > Another can of worms is the pinctrl nodes.
> 
> Yes... new pinctrl data would need to trigger adding new data to
> pinctrl. I don't know if the pinctrl api supports that.

The actual pins stay the same, just their configuration
changes. AFAIK all that is already supported using the
pinctrl framework.

For example, considering hotplugging capes on the beaglebone:

1. You need to map all the sensible modes for the pins exposed
   to the capes in the board specific .dts file. This will
   add roughly 4 x nr_capbus_pins named modes in the .dts file
   so not too bad.

2. Claim all the capebus pins during the capbus driver probe
   and set them to some safe mode.

3. Try to detect the connected cape(s) over i2c.

4. Use pinctr_select_state to set the desired modes for
   the pins used by the cape(s).

5. Enable capebus regulators and clocks etc.

6. Load the driver modules for whatever omap internal
   devices the cape supports.

You could also claim the pin for the omap internal
devices instead of claiming them in the capebus, but then
things can get messy with binding and unbinding the
drivers. So just claiming all the pins in the capebus
probably keeps things simpler.

Regards,

Tony
--
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/