linux-kernel - Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock 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] [day] [month] [year] [list]

Date:   Tue, 6 Dec 2016 16:47:55 +0200
From:   Georgi Djakov <georgi.djakov@...aro.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>
Cc:     mturquette@...libre.com, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>
Subject: Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

On 12/05/2016 11:26 PM, Bjorn Andersson wrote:
> On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote:
>
>> On 11/11, Georgi Djakov wrote:
>>> On 11/03/2016 08:28 PM, Bjorn Andersson wrote:
> [..]
>>>> I'm in favour of us inventing a kicker API and it's found outside out
>>>> use cases as well (e.g. virtio/rpmsg).
>>>>
>>
>> I'd rather we did this kicker API as well. That way we don't need
>> to make a syscon and a simple-mfd to get software to work
>> properly. Don't other silicon vendors need a kicker API as well?
>> How are they kicking remote processors in other places? GPIOs?
>>
>
> In remoteproc I have two of these:
> 1) da8xx_remoteproc ioremaps a register and writes a bit in it (looks
>    similar to the downstream Qualcomm way)
>
> 2) omap_remoteproc acquires a mbox channel, in which it writes a
>    virtqueue id to kick the remote.
>
> So one of the two cases could have used such mechanism.
>

I also see the potential users of such API mostly in the 
remoteproc/rpmgs subsystems.

> We could write up a Qualcomm specific "kicker" and probe the mailing
> list regarding the interest in making that generic (i.e. changing the
> names in the API and DT binding).

Yes, i am planing to do this.

>
> The sucky part is that I believe we have most of our kickers in place
> already so rpm, smd, smp2p, smsm etc would all need to support both
> mechanisms.

Agree.. we have to keep compatibility with existing dtbs.

Thanks,
Georgi