linux-kernel - Re: [PATCH v2] firmware: qcom_scm: Fix to allow COMPILE

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]

Message-ID: <0e0833ff-c440-c314-4ef7-c294ee68cd56@linaro.org>
Date:   Tue, 20 Jun 2017 11:43:43 +0300
From:   Stanimir Varbanov <stanimir.varbanov@...aro.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Olof Johansson <olof@...om.net>,
        Andy Gross <andy.gross@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: [PATCH v2] firmware: qcom_scm: Fix to allow COMPILE_TEST-ing

Hi Bjorn,

On 06/20/2017 12:00 AM, Bjorn Andersson wrote:
> On Mon 19 Jun 05:19 PDT 2017, Stanimir Varbanov wrote:
> 
>> Hi Olof,
>>
>> On 06/19/2017 02:25 PM, Stanimir Varbanov wrote:
>>> Hi Olof,
>>>
>>> On 06/19/2017 08:35 AM, Olof Johansson wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jun 8, 2017 at 8:23 AM, Stanimir Varbanov
> [..]
>>>>
>>>> It probably makes more sense to stub the driver->scm interface than
>>>> the internal scm interface if what you're looking for is driver
>>>> compile_test coverage.
>>>
>>> Actually, this is the state of qcom_scm if we don't apply the this
>>> patch, and it didn't help. Thinking more on that it looks like that
>>> adding COMPILE_TEST in 'config QCOM_SCM' is controversial.
>>>
>>> Arnd, Andy any ideas how to proceed. If this patch is not get merged
>>> (and I/we cannot find better solution) the video driver for qualcomm
>>> platforms will be rejected for 4.13.
>>>
>>
>> Currently the dependences are:
>>
>> VIDEO_QCOM_VENUS selects QCOM_MDT_LOADER
>> QCOM_MDT_LOADER selects QCOM_SCM
>>
>> And I came to this,
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 9fca977ef18d..b8657c561eae 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -12,7 +12,7 @@ config QCOM_GSBI
>>
>>  config QCOM_MDT_LOADER
>>         tristate
>> -       select QCOM_SCM
>> +       depends on QCOM_SCM || COMPILE_TEST
> 
> The problem with this is that QCOM_SCM is not user selectable and you
> can't select MDT_LOADER if you make it depend on QCOM_SCM - as this
> might not be enabled by the user (if you make it user selectable).
> 
> 
> The problem that I see changing this is that there's no point in making
> QCOM_SCM and QCOM_MDT_LOADER user selectable - they don't serve a
> purpose on their own.
> 
> 
> PS. Don't you depend on scm functionality directly from the venus driver
> as well?

Yes, qcom video codec driver depends directly on QCOM_SCM. But I'm
relying on the fact that QCOM_MDT_LOADER depends on QCOM_SCM, and
probably QCOM_MDT_LOADER will need to depends on QCOM_SCM forever.

-- 
regards,
Stan