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-next>] [day] [month] [year] [list]
Message-ID: <5421B4B0.1020306@dev.rtsoft.ru>
Date:	Tue, 23 Sep 2014 21:58:08 +0400
From:	Nikita Yushchenko <nyushchenko@....rtsoft.ru>
To:	devicetree@...r.kernel.org
CC:	linux-kernel@...r.kernel.org,
	Gennady Kuznetsov <kuznetsovg@....rtsoft.ru>,
	Aleksey Makarov <amakarov@....rtsoft.ru>
Subject: Device tree vs hardware configurations

Hi

I'm currently forward-porting a BSP for imx6-based custom board from 
pre-devicetree kernel to modern kernel.

In old BSP there was a board setup file, that registered all board's 
devices. For new BSP, I need to replace that with device tree based 
solution.

However, old BSP used conditional code to register devices differently 
based on GPIO inputs and on kernel command line. This approach was used to

- handle board's jumper that switches SPI CS lines: current jumper 
setting is available over gpio, depending on that old BSP registered 
chips differently,

- handle different i2c connections on different board revisions: board 
has 5 i2c busses with quite a few devices connected, these busses are 
routed to different hardware busses on different board revisions, board 
revision could be read over gpios.

- handle different possible display connections (lvds vs lcd, 6bit vs 
8bit hw interface) based on kernel command line options

- handle different possible camera connections by registered camera 
differently based on kernel command line option

... and more,


Device tree describes hardware unconditionally. I already have to 
provide 2 dts files for imx6q and imx6dl based setups (both just include 
a common dtsi) ...  But providing separate dts file for every possible 
hardware configuration will result into 2^n device trees, which is 
inconvenient visible regression against old BSP that "just worked" on 
all hardware configurations.


Is there a sane way to handle hardware configurations like above in 
device tree based kernel?


Nikita Yushchenko
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ