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: <20140215041119.GA29012@kroah.com>
Date:	Fri, 14 Feb 2014 20:11:19 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Jassi Brar <jaswinder.singh@...aro.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 Sat, Feb 15, 2014 at 09:27:48AM +0530, Jassi Brar wrote:
> 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'.

What is stopping you submitting your patches right now?
--
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/