lkml.org 
[lkml]   [2017]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] firmware: arm_scpi: Add hardware dependencies
From
Date


On 25/01/17 14:14, Jean Delvare wrote:
> On Wed, 25 Jan 2017 13:56:23 +0000, Sudeep Holla wrote:
>> On 25/01/17 13:50, Jean Delvare wrote:
>>> On Wed, 25 Jan 2017 13:38:47 +0000, Sudeep Holla wrote:
>>>> On 25/01/17 13:32, Jean Delvare wrote:
>>>>> With a name like that, I assume that the ARM SCPI protocol is only
>>>>> useful on the ARM architectures.
>>>>>
>>>>> Signed-off-by: Jean Delvare <jdelvare@suse.de>
>>>>> Fixes: 8f1498c03d15 ("firmware: arm_scpi: make it depend on MAILBOX instead of")
>>>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>>>> Cc: Jon Medhurst (Tixy) <tixy@linaro.org>
>>>>> ---
>>>>> Please correct me if I'm wrong.
>>>>
>>>> I won't say you are wrong but the reason why it's named arm_scpi is
>>>> because the protocol was developed by ARM. It doesnn't mean only
>>>> ARM/ARM64 needs to use it, it can be used on any architecture for
>>>> inter-processor communication using any communication technique
>>>> (currently mailbox is the only supported in the driver)
>>>
>>> OK, thanks for the clarification. In practice, what other architectures
>>> are using it?
>>
>> None, hence I didn't say you are wrong ;). I am fine having the check if
>> it breaks for any other architecture with COMPILE_TEST.
>
> Not sure what you mean here... The purpose of COMPILE_TEST is to allow
> limiting the scope of a driver withing hurting the build test coverage.
>

No I agree with adding COMPILE_TEST just not ARM || ARM64

>> Also you have mentioned it fixes 8f1498c03d15, have you seen any
>> regression with that commit ? If so, details in the commit would be
>> good.
>
> Before 8f1498c03d15, the dependency on ARM_MHU made the driver only
> visible on ARM kernels. Since 8f1498c03d15, the driver is proposed to
> all, which I think isn't correct.

I disagree here. It depends on mailbox as we use mailbox API. And it is
now used on AmLogic Meson series of SoC. So it *is correct*.

> In that sense my proposed patch is
> fixing a (user-friendliness) regression. But nothing serious.
>

Can you elaborate ? What's that *user-friendliness regression* ?
build/boot/... ? I just need more details.

--
Regards,
Sudeep

\
 
 \ /
  Last update: 2017-01-25 15:24    [W:0.059 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site