linux-kernel - Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver

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:	Thu, 19 Jun 2014 22:17:40 -0700
From:	Bjorn Andersson <bjorn@...o.se>
To:	Kevin Hilman <khilman@...aro.org>
Cc:	Kumar Gala <galak@...eaurora.org>,
	Lee Jones <lee.jones@...aro.org>,
	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Josh Cartwright <joshc@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Paul Walmsley <paul@...an.com>,
	Jaswinder Singh <jaswinder.singh@...aro.org>
Subject: Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver

On Wed, Jun 18, 2014 at 9:44 AM, Kevin Hilman <khilman@...aro.org> wrote:
[...]
> Thinking more about what this RPM driver actually does, and since you
> mentioned patterns across SoCs, it seems to me the RPM driver bascially
> just doing the IPC.
>

Yes, technically this is IPC. But it's all exposed in memory as if it
was hardware, so there's no messages or packets to be interpreted by
the other side.

> So, rather than MFD or drivers/soc, it seems to me that it should be
> implmented as a controller in the new common mailbox framwork[1] being
> worked on by Jassi Brar (added to Cc.)
>
> IIUC, RPM is actually only doing one-way IPC (it only exposes a write()
> interface to clients) so it seems like a rather simple implementation of
> a mailbox controller.
>

What I think you miss here is the detail of that what the regulator
writes is not what is passed over the IPC, but rather is just an
interface to abstract away how things are spread our in the register
space.

So the only place where we do have a "mailbox" here is the actual
function call between the regulator and the rpm drivers; not between
the rpm driver and the rpm.

> I believe Bjorn is already on the list of folks Cc'd on the common
> mailbox framework, so it would be good to hear from him why RPM wouldn't
> fit under that framework.
>

In a separate group of Qualcomm platforms the communication with the
RPM is done by passing messages over a shared memory channel; as this
requires a completely different implementation of the rpm driver, I
have started to look at Jassi's patch series.

Unfortunately at this point it does not look like the proposed mailbox
framework would reduce the complexity of the implementation nor
provide any additional benefits when it comes to being able to
exchange the underlaying communication methods.

But I will continue to follow the development of the mailbox framework.

Regards,
Bjorn
--
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/