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:	Mon, 17 Dec 2012 14:36:03 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Laxman Dewangan <ldewangan@...dia.com>, grant.likely@...retlab.ca,
	rob.herring@...xeda.com
CC:	alan@...ux.intel.com, gregkh@...uxfoundation.org, jslaby@...e.cz,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	linux-tegra@...r.kernel.org
Subject: Re: [PATCH] serial: tegra: add serial driver

On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
> Nvidia's Tegra has multiple uart controller which supports:
> - APB dma based controller fifo read/write.
> - End Of Data interrupt in incoming data to know whether end
>   of frame achieve or not.
> - Hw controlled RTS and CTS flow control to reduce SW overhead.

> diff --git a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt

> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver.
> +
> +Required properties:
> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart".

One question that isn't addressed here is:

Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying
compatible = "nvidia,tegra20-uart". However, the 8250.c driver doesn't
support the DMA features of this driver. This driver is an alternate
driver for the same HW that allows DMA to be used with it, etc.

Since DT is supposed to describe the HW, modifying the DT to change the
compatible value in order to select a different driver in Linux doesn't
seem correct, or is it? Is there any kind of precedent for how to select
different drivers for the same HW at run-time? I'd wondered about using
the sysfs bind/unbind "methods" from user-space as the driver selection
mechanism...
--
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