linux-kernel - Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

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, 8 Jan 2013 10:00:42 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
Cc:	Arnd Bergmann <arnd@...db.de>, Tony Lindgren <tony@...mide.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>, Jon Loeliger <jdl@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	David Gibson <david@...son.dropbear.id.au>,
	Benoit Cousson <b-cousson@...com>,
	Mitch Bradley <wmb@...mworks.com>,
	Alan Tull <atull@...era.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-omap@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Matt Porter <mporter@...com>, Russ Dill <Russ.Dill@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Joel A Fernandes <agnel.joel@...il.com>,
	Rob Clark <robdclark@...il.com>,
	Jason Kridner <jkridner@...gleboard.org>,
	Matt Ranostay <mranostay@...il.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Guennadi Liakhovetski <g.liakhovetski@....de>
Subject: Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

> >>> At the end of the line, some kind of hardware glue is going to be needed.
> >>> 
> >>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>> in the beagleboard), it is a bit premature to think about making it overly
> >>> general, besides the part that are obviously part of the infrastructure 
> >>> (like the DT overlay stuff).
> >>> 
> >>> What I'm getting at, is that we need some user experience about this, before
> >>> going away and creating structure out of possible misconception about the uses. 
> >> 
> >> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >> things for omaps that have eventually become generic frameworks have been
> >> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >> so on.
> >> 
> >> So I suggest a minimal generic API from the start as that will make things
> >> a lot easier in the long run.
> > 
> > I agree. The ux500 platform already has the concept of "user interface boards",
> > which currently is not well integrated into devicetree. I believe Sascha
> > mentioned that Pengutronix had been shipping some other systems with add-on
> > boards and generating device tree binaries from source for each combination.
> > 
> > Ideally, both of the above should be able to use the same DT overlay logic
> > as BeagleBone, and I'm sure there are more of those.
> 
> Hmm, I see. 
> 
> I will need some more information about the interface of the 'user interface boards'.
> I.e. how is the board identified, what is typically present on those boards, etc.

User Interface Boards are mearly removable PCBs which are interchangeable
amongst various hardware platforms. They are connected via numerous
connectors which carry all sorts of different data links; i2c, spi, rs232,
etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
pad, leds, jumpers, switches and a bunch of sensors.

You can find a small example of how we interface to these by viewing
'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
currently include it as a *.dtsi from a platform's dts file.

> Can we get some input by the owner of other similar hardware? I know the FPGA
> people have similar requirements for example. There are other people that are hitting
> problems getting DT to work with their systems, like the V4L people with the order
> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> cleanly solved by the overlay being contained in the V4L device node and applied just before
> the device is probed.
> 
> In the meantime it would be better to wait until we have some ack from the maintainers
> of the core subsystems about what they think.
>  
> Regards
> 
> -- Pantelis
> 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/