linux-kernel - Re: [PATCH 0/3] 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:	Thu, 1 Nov 2012 13:04:18 +0200
From:	Felipe Balbi <balbi@...com>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
CC:	"Cousson, Benoit" <b-cousson@...com>, <balbi@...com>,
	Tony Lindgren <tony@...mide.com>,
	<linux-kernel@...r.kernel.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, Russ Dill <Russ.Dill@...com>,
	<linux-omap@...r.kernel.org>, Kevin Hilman <khilman@...com>,
	Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

Hi,

On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
> >>>                 lcd@0 {
> >>>                         compatible = "adafruit,tft-lcd-1.8-red", "sitronix,st7735";
> >>>                         spi-max-frequency = <8000000>;
> >>>                         reg = <0>;
> >>>                         spi-cpol;
> >>>                         spi-cpha;
> >>>                         pinctrl-names = "default";
> >>>                         pinctrl-0 = <&lcd_pins>;
> >>>                         st7735-rst = <&gpio4 19 0>;
> >>>                         st7735-dc = <&gpio4 21 0>;
> >>>                 };
> >>> 
> >>>         };
> >>> };
> >>> 
> > 
> > I guess there is no easy solution for that, but it looks to me that
> > what you have to do is to make the DT creation dynamic in your case.
> > Assuming you do not want to do that in the bootloader, you must do
> > that pretty early during the boot process to end up with a full
> > description of your DT tree before creating the devices.
> > 
> 
> Do it pretty early in the boot processes ended up with the am335xevm board file in the PSP tree.
> 
> The whole set of possible cape designs cannot be controlled, nor do we want to.
> We want to empower users to come up with their own designs without having to do any kernel/boot loader
> hacking.

that's impossible since you will have to provide the capebus driver
anyway.

> > Each cape will have their own DTS and based on some board id you
> > will fix the DT dynamically.
> > 
> > My point is that the issue you are facing is a real limitation of
> > DT, so you should fix the DT core and not workaround it by creating
> > artificial bindings / drivers.
> > 
> 
> You still haven't described any mechanism to deal with all the use
> cases I described.
> 
> DT can't and will not deal with the complexity that we're facing right
> now.

and DT-itself shouldn't. I agree with Benoit that this should be built
at bootloader level, perhaps. Whatever you're doing in capebus, you
could do at kernel space, build your DT bindings in runtime, and pass
that DT blob to kernel.

One question though, what do you mean by "some capes are full blown
devices with their own drivers" ? Do you mean you have capes running
some other (RT)OS and communicating with linux somehow ? How does it
communicate to the bone ?

cheers

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)