linux-kernel - Re: [PATCHv1 1/6] HSI: add Device Tree support for HSI clients

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]

Message-ID: <20140224150930.GI28555@e106331-lin.cambridge.arm.com>
Date:	Mon, 24 Feb 2014 15:09:31 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Sebastian Reichel <sre@...ian.org>
Cc:	Sebastian Reichel <sre@...g0.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Shubhrajyoti Datta <omaplinuxkernel@...il.com>,
	Carlos Chinea <cch.devel@...il.com>,
	Tony Lindgren <tony@...mide.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Landley <rob@...dley.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	Pali Rohár <pali.rohar@...il.com>,
	Ивайло Димитров 
	<freemangordon@....bg>,
	Joni Lapilainen <joni.lapilainen@...il.com>,
	Aaro Koskinen <aaro.koskinen@....fi>
Subject: Re: [PATCHv1 1/6] HSI: add Device Tree support for HSI clients

On Sun, Feb 23, 2014 at 11:49:56PM +0000, Sebastian Reichel wrote:
> Add new method hsi_add_clients_from_dt, which can be used
> to initialize HSI clients from a device tree node.
> 
> The patch also documents the DT binding for trivial HSI
> clients.
> 
> Signed-off-by: Sebastian Reichel <sre@...ian.org>
> ---
>  .../devicetree/bindings/hsi/trivial-devices.txt    | 36 +++++++++++
>  drivers/hsi/hsi.c                                  | 70 +++++++++++++++++++++-
>  include/dt-bindings/hsi/hsi.h                      | 17 ++++++
>  include/linux/hsi/hsi.h                            |  2 +
>  4 files changed, 124 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/hsi/trivial-devices.txt
>  create mode 100644 include/dt-bindings/hsi/hsi.h

It would be nice if we had a general HSI binding document that explains
what HSI is and how HSI bus devices and clients are expected too look.

Does HSI have an addressing scheme, or does each port have a single
device?

> 
> diff --git a/Documentation/devicetree/bindings/hsi/trivial-devices.txt b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
> new file mode 100644
> index 0000000..1ace14a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
> @@ -0,0 +1,36 @@
> +This is a list of trivial hsi client devices that have simple
> +device tree bindings, consisting only of a compatible field
> +and the optional hsi configuration.
> +
> +If a device needs more specific bindings, such as properties to
> +describe some aspect of it, there needs to be a specific binding
> +document for it just like any other devices.

Might this make more sense as a hsi-clients binding doc? I assume these
properties could be applied to non-trivial devices?

> +
> +Optional HSI configuration properties:
> +
> +- hsi,mode		Bit transmission mode (STREAM or FRAME)
> +			The first value is used for RX and the second one for
> +			TX configuration. If only one value is provided it will
> +			be used for RX and TX.
> +			The assignments may be found in header file
> +			<dt-bindings/hsi/hsi.h>.

Why not have hsi,rx-mode and hsi,tx-mode? I'll certainly get confused as
to which cell is tx and which is rx with the current binding.

Having separate tx-* and rx-* versions of the remaining properties would
be good too.

I note that the defines are called HSI_MODE_STREAM and HSI_MODE_FRAME,
not STREAM and FRAME as the binding document implies. Please refer to
exact names.

It may make more sense to use a string here and for the other
properties. They're easier for humans to read, and they survive
decompilation (so you get _much_ better error messages).

> +- hsi,channels		Number of channels to use [1..16]
> +			The first value is used for RX and the second one for
> +			TX configuration. If only one value is provided it will
> +			be used for RX and TX.
> +- hsi,speed		Max bit transmission speed (Kbit/s)
> +			The first value is used for RX and the second one for
> +			TX configuration. If only one value is provided it will
> +			be used for RX and TX.
> +- hsi,flow		RX flow type (SYNCHRONIZED or PIPELINE)
> +			The assignments may be found in header file
> +			<dt-bindings/hsi/hsi.h>.
> +- hsi,arb_mode		Arbitration mode for TX frame (Round robin, priority)
> +			The assignments may be found in header file
> +			<dt-bindings/hsi/hsi.h>.

s/_/-/ in property names please.

> +
> +This is the list of trivial client devices:
> +
> +Compatible		Description
> +==========		=============
> +hsi-char		HSI character device

What exactly is a HSI character device?

This seems more like a Linux abstraction than a real class of device.

Cheers,
Mark.
--
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/