linux-kernel - Generic HSI client DT bindings

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>] [day] [month] [year] [list]

Date:	Mon, 10 Mar 2014 00:41:44 +0100
From:	Sebastian Reichel <sre@...g0.de>
To:	Sebastian Reichel <sre@...g0.de>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc:	Carlos Chinea <cch.devel@...il.com>,
	Shubhrajyoti Datta <omaplinuxkernel@...il.com>,
	Dmitry Tarnyagin <dmitry.tarnyagin@...kless.no>,
	Pawel Szyszuk <pawel.szyszuk@...ricsson.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>
Subject: Generic HSI client DT bindings

Hi,

I'm currently working on Device Tree support for the HSI subsystem
to get the Nokia N900 modem working in the mainline kernel. I guess
the key question for the binding has been asked by Mark:

Mark Rutland <mark.rutland@....com> wrote [0]:
> Does HSI have an addressing scheme, or does each port
> have a single device?

It's easy to answer the question in an abstract way: A HSI link
connects two processors with each other providing multiple logical
channels. The problem is, that only the physical layer is specified
AFAIK (I do not have access to HSI specification, so I do not know
for sure). Thus the exact usage of the channels is vendor specific.

For the Nokia N900 modem the following one of the following bindings
seem senseful to me:

========= Variant A =========
hsi-port {
	/* some nodes describing the port */

	n900_modem: client-device {
		compatible = "nokia,n900-modem";
		reg = <0>, <1>, <2>, <3>;
		reg-names = "mcsaab-control",
			    "speech-control",
			    "mcsaab-data",
			    "speech-data";
		hsi-mode = "stream";
		hsi-speed-kbps = <55000>;
		hsi-flow = "synchronized";
		hsi-arb-mode = "round-robin";
	};
};
#############################

========= Variant B =========
hsi-port {
	/* some nodes describing the port */

	cmt_mcsaab: client-device@0 {
		compatible = "nokia,mcsaab-protocol";
		reg = <0>, <2>;
		reg-names = "mcsaab-control",
			    "mcsaab-data";
		hsi-mode = "stream";
		hsi-channels = <4>;
		hsi-speed-kbps = <55000>;
		hsi-flow = "synchronized";
		hsi-arb-mode = "round-robin";
	};

	cmt_speech: client-device@1 {
		compatible = "nokia,cmt-speech";
		reg = <1>, <4>;
		reg-names = "speech-control",
			    "speech-data";
		hsi-mode = "stream";
		hsi-channels = <4>;
		hsi-speed-kbps = <55000>;
		hsi-flow = "synchronized";
		hsi-arb-mode = "round-robin";
	};
};
#############################

Both bindings are simplified and do not map all of the hardware's
capabilities: Some settings can be configured differently for RX and
TX. It should be easy to extend the support for e.g. hsi-mode-rx
and hsi-mode-tx once this is needed. For devices configuring them
the same having just one node seems better to me (I assume almost
all devices want them to be the same).

As far as I can see only ST-Erricson has also HSI clients prepared
for the mainline kernel. It would be nice to get some feedback from
you. If you know more HSI users, which are not yet Cc'd please feel
free to point them here.

[0] http://article.gmane.org/gmane.linux.kernel/1654456

-- Sebastian

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