linux-kernel - Re: [RFC 0/6] mailbox: add common framework and port drivers

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: <CAJe_Zhe-n6bYUYcbhfHhZ6Cc-8h5Ag7D69hd4G9AtFPjFkWsug@mail.gmail.com>
Date:	Sat, 15 Feb 2014 09:27:48 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Courtney Cavin <courtney.cavin@...ymobile.com>,
	"Anna, Suman" <s-anna@...com>,
	Rob Herring <rob.herring@...xeda.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mark Langsdorf <mark.langsdorf@...xeda.com>,
	Tony Lindgren <tony@...mide.com>,
	"Omar Ramirez Luna (omar.ramirez@...itl.com)" 
	<omar.ramirez@...itl.com>, Pawel Moll <pawel.moll@....com>,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, rob@...dley.net, linux-doc@...r.kernel.org,
	devicetree@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	Loic Pallardy <loic.pallardy@...com>,
	LeyFoon Tan <lftan.linux@...il.com>,
	Craig McGeachie <slapdau@...oo.com.au>
Subject: Re: [RFC 0/6] mailbox: add common framework and port drivers

On 15 February 2014 09:10, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Sat, Feb 15, 2014 at 09:02:07AM +0530, Jassi Brar wrote:
>> Hi,
>>
>> On 8 February 2014 06:20, Courtney Cavin <courtney.cavin@...ymobile.com> wrote:
>> > There is currently no common framework for mailbox drivers, so this is my
>> > attempt to come up with something suitable.  There seems to be a need for
>> > making this generic, so I have attempted to do just that.  Most of this is
>> > modeled pretty strongly after the pwm core, with some influences from the clock
>> > core.
>> >
>> > Looking at the existing use-cases, and some new ones, it would appear that the
>> > requirements here are rather simple. We need essentially two things for
>> > consumers:
>> >         - put_message
>> >         - callback for receiving messages
>> >
>> > The code currently uses atomic notifiers for callbacks.  The common omap core
>> > deals with fifos and work-queues in order to escape atomic contexts, but from
>> > what I can see, this is unneeded.  I am also of the opinion that the contexts
>> > can be much better managed in the drivers which are working with these
>> > contexts, rather than generically.
>> >
>> > Hopefully this will be suitable for the plethora of other drivers around the
>> > kernel which implement mailboxes, as well.  In any case, I'm rather interested
>> > to see what the rest of the world thinks.
>> >
>> > Keep in mind that while the pl320 & omap code should compile, I don't currently
>> > have a platform on which I can perform proper testing.  I also removed the
>> > context save/restore code from omap2 mailbox support, because I think it should
>> > be able to be done via driver suspend/resume, but haven't done a full
>> > investigation just yet.
>> >
>> > I'm also aware that breaking omap, just to fix it again probably isn't the best
>> > course of action, and I'm open to suggestions.
>> >
>> Did you try to look up the history of mailbox api development?  Google
>> search: 'mailbox common api'
>>
>> I (Linaro/Fujitsu), Suman Anna (TI), LeyFoon Tan (Intel), Craig
>> McGeachie(Broadcom) and Loic Pallardy(ST) already worked a generic
>> Mailbox framework and infact have controller drivers working over
>> them.
>>  For some confidentiality and some lazy and some confusion or whatever
>> reasons the final version of drivers and API wasn't submitted upstream
>> yet.
>
> Then, in all reality, it doesn't exist at all, and so, we will evaluate
> this submission instead.
>
> Just because you all can't send something for merging, doesn't mean you
> get to block someone else who has got their act together, that's not
> fair.
>
Yup probably not much fair. But then also one usually look for any
early development efforts. IIRC only I and Anna started. Others later
joined us looking at archives. Not to vindicate our gang though.

 Now we could either punish us and have this api tread the same
development path where everyone had their requirements (and the
only-waiting-for-approval controller drivers to convert) .... OR we
could see if our/original/old API just works for the purposes of Sony
as well (which it will most probably) and then we could upstream it
with one more 'works-for-me-too'.

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