linux-kernel - Re: [PATCH 4/5] soundwire: qcom: avoid dependency on CONFIG

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]
Message-ID: <d7ccf640-f493-4f08-a391-7b36bf6966a6@marek.ca>
Date:   Wed, 10 Jun 2020 08:06:17 -0400
From:   Jonathan Marek <jonathan@...ek.ca>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        alsa-devel@...a-project.org
Cc:     Vinod Koul <vkoul@...nel.org>,
        Sanyog Kale <sanyog.r.kale@...el.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 4/5] soundwire: qcom: avoid dependency on CONFIG_SLIMBUS

On 6/10/20 6:36 AM, Srinivas Kandagatla wrote:
> 
> 
> On 09/06/2020 12:33, Jonathan Marek wrote:
>> On 6/9/20 5:52 AM, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 08/06/2020 21:43, Jonathan Marek wrote:
>>>> The driver may be used without slimbus, so don't depend on slimbus.
>>>>
>>>> Signed-off-by: Jonathan Marek <jonathan@...ek.ca>
>>>> ---
>>>>   drivers/soundwire/Kconfig | 1 -
>>>>   drivers/soundwire/qcom.c  | 5 +++++
>>>>   2 files changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
>>>> index fa2b4ab92ed9..d121cf739090 100644
>>>> --- a/drivers/soundwire/Kconfig
>>>> +++ b/drivers/soundwire/Kconfig
>>>> @@ -33,7 +33,6 @@ config SOUNDWIRE_INTEL
>>>>   config SOUNDWIRE_QCOM
>>>>       tristate "Qualcomm SoundWire Master driver"
>>>> -    depends on SLIMBUS
>>>>       depends on SND_SOC
>>>
>>> Why not move this to imply SLIMBUS this will give more flexibility!
>>>
>>>
>>
>> If you mean to change it to "select SLIMBUS", I'd prefer not to, 
>> because this would increase code size unnecessarily in my kernel.
> 
> imply is week select, which means that this driver can be built without 
> SLIMBus selected. So removing reference to slimbus_bus is necessary in 
> this case.
> 

Will change it to "imply", I wasn't aware of this keyword.

> On the other hand, SLIMBus is going to be used sm8250 for BT audio, so 
> this would not be unnecessary. Also mostly these are build as modules, 
> so not sure why kernel size will increase here!
> 

Not everyone uses modules. I am using a config with CONFIG_MODULES=n and 
only relevant drivers enabled.

> Am not 100% sure if SLIMBus will be kept on all SoCs, but keeping 
> depends or imply in place would enforce or spell out some level of 
> dependency on this.
> 
>>
>>>>       help
>>>>         SoundWire Qualcomm Master driver.
>>>> diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
>>>> index 14334442615f..ac81c64768ea 100644
>>>> --- a/drivers/soundwire/qcom.c
>>>> +++ b/drivers/soundwire/qcom.c
>>>> @@ -769,13 +769,18 @@ static int qcom_swrm_probe(struct 
>>>> platform_device *pdev)
>>>>       if (!ctrl)
>>>>           return -ENOMEM;
>>>> +#ifdef CONFIG_SLIMBUS
>>>>       if (dev->parent->bus == &slimbus_bus) {
>>>> +#else
>>>> +    if (false) {
>>>> +#endif
>>>
>>> May be you can do bit more cleanup here, which could endup like:
>>>
>>>
>>> ctrl->regmap = dev_get_regmap(dev->parent, NULL);
>>> if (!ctrl->regmap) {
>>>      res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>      if (res) {
>>>          ctrl->mmio = devm_ioremap_resource(dev, res);
>>>          if (IS_ERR(ctrl->mmio)) {
>>>              dev_err(dev, "No valid mem resource found\n");
>>>              return PTR_ERR(ctrl->mmio);
>>>          }
>>>
>>>          ctrl->reg_read = qcom_swrm_cpu_reg_read;
>>>          ctrl->reg_write = qcom_swrm_cpu_reg_write;
>>>      } else {
>>>          dev_err(dev, "No valid slim resource found\n");
>>>          return -EINVAL;
>>>      }
>>> } else {
>>>      ctrl->reg_read = qcom_swrm_ahb_reg_read;
>>>      ctrl->reg_write = qcom_swrm_ahb_reg_write;
>>> }
>>>
>>>
>>>
>>> thanks,
>>> srini
>>
>> I don't think this is better, it feels more obfuscated, and I think 
>> its possible we may end up with the mmio sdw having a parent with a 
>> regmap. (it is not how I did things up in my upstream stack, but in 
>> downstream the sdw nodes are inside the "macro" codec nodes)
>>
>> I understand the '#ifdef CONFIG_SLIMBUS'/'dev->parent->bus == 
>> &slimbus_bus' is ugly, but at least its clear what's going on. Unless 
>> you have a better suggestion?
> 
> Other suggestion I had in my mind was to use compatible strings to get 
> reg_read, reg_write callbacks + some flags like (if_type) populated. 
> This can help looking up resources correctly.
> 

This is better than the previous suggestion, but is it safe to say that 
specific versions will always be used with MMIO or slimbus? (I guess the 
answer is yes, but I want to confirm)

> Thanks,
> srini
> 
>>
>>>>           ctrl->reg_read = qcom_swrm_ahb_reg_read;
>>>>           ctrl->reg_write = qcom_swrm_ahb_reg_write;
>>>>           ctrl->regmap = dev_get_regmap(dev->parent, NULL);
>>>>           if (!ctrl->regmap)
>>>>               return -EINVAL;
>>>>       } else {
>>>> +
>>>>           res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>           ctrl->reg_read = qcom_swrm_cpu_reg_read;
>>>>