linux-kernel - Re: [PATCHv3 00/14] drivers: mailbox: framework creation

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, 29 Apr 2013 22:19:08 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Suman Anna <s-anna@...com>
Cc:	Loic PALLARDY <loic.pallardy@...com>,
	Jassi Brar <jassisinghbrar@...il.com>,
	"Ohad Ben-Cohen (ohad@...ery.com)" <ohad@...ery.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"Andy Green (andy.green@...aro.org)" <andy.green@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Tony Lindgren <tony@...mide.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Omar Ramirez Luna (omar.ramirez@...itl.com)" 
	<omar.ramirez@...itl.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCHv3 00/14] drivers: mailbox: framework creation

Hi

On 29 April 2013 21:30, Suman Anna <s-anna@...com> wrote:
> Hi Jassi,
>
> On 04/26/2013 11:51 PM, Jassi Brar wrote:

>>> OK, I didn't think of a no RTR interrupt-based controller. I would thing
>>> that such a controller is very rudimentary. I wonder if there are any
>>> controllers like this out there.
>>>
>> One of my controllers is like that :)
>
> I hope it does have a status register atleast, and not the "neither
> report nor sense RTR" type.
>
Actually the status is not set by the h/w, but the remote's firmware
implementation makes sure it sets a marker in the status register
after accepting data. So with some other firmware, we might not even
have the status read facility and the client will have to solely run
the TX ticker.

>> If the controller h/w absolutely can not tell the remote(sender) of a
>> received packet (as seems to be your case), its driver shouldn't even
>> try to demux the received messages. The client driver must know which
>> remotes could send it a message and how to discern them on the
>> platform. Some 'server' RX client is needed here.
>
> No demuxing, deliver the message to the different clients. It is a
> protocol agreement between the clients on what the message means. Think
> of this scenario akin to shared interrupts.
>
Please re-read. That's what I said - No demuxing by the controller driver :)

>
> The notify mechanism was the top-half on the interrupt handling. The
> faith part is coming from the fact that you expect all the clients to do
> the equivalent of the bottom-half (which would mean some duplication in
> the different clients), the OMAP scenario is such that all the different
> link interrupts (both rx & tx) are mapped onto a single physical
> interrupt. I think this may not be applicable to your usecase, wherein
> you probably expect a response back before proceeding.
>
Simply put - the RX by notifier method will fail should a client is
speed critical.
The api might provide it optionally, but direct handover should be the
default option.

Btw, I did put up an almost tested version of an API implementing most
of the features we agree upon
http://www.spinics.net/lists/kernel/msg1523873.html
http://www.spinics.net/lists/kernel/msg1523874.html

cheers.
--
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/