linux-kernel - Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

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:	Wed, 25 May 2016 13:50:58 -0700
From:	Kevin Hilman <khilman@...libre.com>
To:	Andy Gross <andy.gross@...aro.org>
Cc:	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	devicetree <devicetree@...r.kernel.org>,
	jilai wang <jilaiw@...eaurora.org>
Subject: Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

Andy Gross <andy.gross@...aro.org> writes:

> On Mon, May 23, 2016 at 04:02:06PM -0500, Andy Gross wrote:
>> On 23 May 2016 at 14:26, Kevin Hilman <khilman@...nel.org> wrote:
>> > Hi Andy,
>> >
>> > On Thu, May 12, 2016 at 8:46 PM, Andy Gross <andy.gross@...aro.org> wrote:
>> >> This patch converts the Qualcomm SCM driver to use the streaming DMA APIs
>> >> for communication buffers.
>> >>
>> >> Signed-off-by: Andy Gross <andy.gross@...aro.org>
>> >
>> > This patch has landed in linux-next in the form of commit a551c3dbd689
>> > (firmware: qcom: scm: Convert to streaming DMA APIS), and kernelci.org
>> > found some boot breakage in next-20160523 on apq8064[1] which was
>> > bisected down to this commit.
>> >
>> > I reverted this commit on top of next-20160523 and it no longer
>> > builds, so I didn't validate if things boot again with this patch
>> > reverted.
>> 
>> Ouch I missed this failure.  I'll investigate and get it fixed.
>
> So the root cause was the fact that the DFAB clock required by the SCM is an RPM
> clock.  That support isn't present yet in the kernel, so SCM probe fails.
>
> The core clock is really only accessed so that we can bump the clock on it up to
> the max for performance.  As such, I'll make it optional in the platform code.
>
> This does bring up the issue of probe defer causing issues with the spm driver,
> as it calls set_warm_boot_addr.  That may have to be addressed, but is probably
> a problem best fixed in the spm.

Nice, thanks for the explanation.

Is there a patch somewhere you'd like me to test? or were you able to
dust off an 8064 platform for testing?

Kevin