linux-kernel - Re: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager

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:	Wed, 10 Feb 2016 14:13:40 -0600
From:	Suman Anna <s-anna@...com>
To:	"Menon, Nishanth" <nm@...com>,
	Jassi Brar <jassisinghbrar@...il.com>
CC:	Devicetree List <devicetree@...r.kernel.org>,
	"Cooper Jr., Franklin" <fcooper@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Santosh Shilimkar <ssantosh@...nel.org>,
	Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager

Hi Nishanth,

On 02/09/2016 12:10 PM, Menon, Nishanth wrote:
> On 09:43-20160209, Nishanth Menon wrote:
>> On Tue, Feb 9, 2016 at 8:54 AM, Jassi Brar <jassisinghbrar@...il.com> wrote:
> [..]
>> Let me prototype this as part of of_xlate and see if I can pull the
>> qinst data back out.. obviously one negative will be that I will
>> register *all* valid channels as part of probe.. at least based on
>> initial code i wrote today morning..
> 
> OK - I believe I have it working now. How does the following look? If
> this looks fine to you, then I will post a v2 including the driver
> update.
> Changes here:
> 	- dropped the generic message-manager compatible
> 	- dropped child nodes
> 	- moved the valid queue information to driver (no longer in dts)
> 	- rx interrupts per SoC are explicitly named list in binding(and
> 	  dts)
> 
> Texas Instruments' Message Manager Driver
> ========================================
> 
> The Texas Instruments' Message Manager is a mailbox controller that has
> configurable queues selectable at SoC(System on Chip) integration. The Message
> manager is broken up into queues in different address regions that are called
> "proxies" - each instance is unidirectional and is instantiated at SoC
> integration level to indicate receive or transmit path.
> 
> Message Manager Device Node:
> ===========================
> Required properties:
> --------------------
> - compatible:		Shall be: "ti,k2g-message-manager"
> - reg-names 		queue_proxy_region - Map the queue proxy region.
> 			queue_state_debug_region - Map the queue state debug
> 			region.
> - reg:			Contains the register map per reg-names.
> - #mbox-cells		Shall be 2. Contains the queue ID and proxy ID in that
> 		        order referring to the transfer path.
> - interrupt-names:	Contains interrupt names matching the rx transfer path
> 			for a given SoC. Receive interrupts shall be of the
> 			format: "rx_<QID>_<PID>".
> 			For ti,k2g-message-manager, this shall contain:
> 				"rx_005_002", "rx_057_002"

Are these the only two that will ever be supported for
ti,k2g-message-manager or there can be more in the future? You did
mention about 11 possible valid qid_pid values for the ARM, and the
driver match data is
registering all of those mboxes.

> - interrupts:		Contains the interrupt information corresponding to
> 			interrupt-names property.
> 
> Example(K2G):
> ------------
> 
> 	msgmgr: msgmgr@...00000 {
> 		compatible = "ti,k2g-message-manager";
> 		#mbox-cells = <2>;
> 		reg-names = "queue_proxy_region", "queue_state_debug_region";
> 		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
> 		interrupt-names = "rx_005_002",
> 				  "rx_057_002";
> 		interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
> 			     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
> 	};
> 
> 	pmmc: pmmc {
> 		[...]
> 		mbox-names = "rx", "tx";
> 		# RX queue ID is 5, proxy ID is 2
> 		# TX queue ID is 0, proxy ID is 0
> 		mboxes= <&msgmgr 5 2>,
> 			<&msgmgr 0 0>;
> 		[...]
> 	};

Yeah, this will also work. I am fine with this approach - my only
concern was that the probe doesn't have to go parsing all the nodes to
be able to register the mailbox channels with the mailbox core. Since
you are registering them using match data, that is not a concern anymore.

Anyway, will let Rob give the final ACK.

regards
Suman