linux-kernel - Re: [PATCH 2/2] ARM: tegra: initial add of Colibri T30

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 13 May 2014 13:49:12 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	stefan@...er.ch, thierry.reding@...il.com
CC:	linux@....linux.org.uk, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-tegra@...r.kernel.org, marcel@...wiler.com
Subject: Re: [PATCH 2/2] ARM: tegra: initial add of Colibri T30

On 05/13/2014 11:27 AM, stefan@...er.ch wrote:
> This patch adds the device tree to support Toradex Colibri T30, a
> computer on module which can be used on different carrier boards.
> 
> The module consists of a Tegra 30 SoC, two PMIC, DDR3L RAM, eMMC,
> a LM95245 temperature sensor and an AX88772B USB Ethernet
> Controller. Furthermore, there is a STMPE811 and SGTL5000 audio
> codec which are not yet supported. Anything that is not self
> contained on the module is disabled by default.
> 
> The device tree for the Evaluation Board includes the modules
> device tree and enables the supported pheripherials of the carrier
> board (the Evaluation Board supports almost all of them).

> diff --git a/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts b/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts

> +#include "tegra30-colibri.dtsi"
> +
> +/ {
> +	model = "Toradex Colibri T30 on Colibri Evaluation Board";
> +	compatible = "toradex,colibri_t30-eval-v3", "nvidia,tegra30";

That should include all the compatible values "inherited" from the
Colibri T30 module .dtsi file too.

> +	aliases {
> +		rtc0 = "/i2c@...0c000/rtc@68";
> +		rtc1 = "/i2c@...0d000/tps65911@2d";
> +		rtc2 = "/rtc@...0e000";
> +	};

Wow, no shortage of RTCs!

> +	/* SPI1: Colibri SSP */
> +	spi@...0d400 {
> +		status = "okay";
> +		spi-max-frequency = <25000000>;
> +		can0: can@0 {
> +			compatible = "microchip,mcp2515";
> +			reg = <0>;
> +			clocks = <&clk16m>;
> +			interrupt-parent = <&gpio>;
> +			interrupts = <TEGRA_GPIO(S, 0) GPIO_ACTIVE_LOW>;
> +			spi-max-frequency = <10000000>;

So this chip doesn't get confused by a faster clock frequency when its
chip-select line isn't asserted? I would have expected spi-max-frequency
for the bus to be the minimum value that any device on the bus would
tolerate.

> +	/* EHCI instance 0: USB1_DP/N -> USBC_P/N */
> +	usb@...00000 {
> +		status = "okay";
> +		dr_mode = "otg";

The dr_mode property is only for the PHY node.

> +	panel: panel {
> +		compatible = "edt,et057090dhu", "simple-panel";

The panel-simple driver doesn't seem to know about that EDT panel. How
will it work out the display timings?

> diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi b/arch/arm/boot/dts/tegra30-colibri.dtsi

> +/ {
> +	model = "Toradex Colibri T30";
> +	compatible = "toradex,colibri_t30-v11b",
> +		     "toradex,colibri_t30-v11c",
> +		     "toradex,colibri_t30-v11d",
> +		     "toradex,colibri_t30", "nvidia,tegra30";

Do we really need all those compatible values? If those board revisions
are all SW-compatible, then you may as well write just:

	compatible = "toradex,colibri_t30", "nvidia,tegra30";

> +	aliases {
> +		serial0 = &uarta;
> +		serial1 = &uartd;
> +		serial2 = &uartb;
> +	};

tegra20.dtsi already sets the alias names for the serial ports. Previous
discussions settled on giving each on-chip UART a static name, rather
than renaming them per board.

> +	pmc@...0e400 {
> +		status = "okay";

The PMC node isn't disabled in tegra20.dtsi, so you don't need the
status property here.
--
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/