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:   Mon, 29 Mar 2021 17:38:56 +0200
From:   Matthias Brugger <matthias.bgg@...il.com>
To:     Gene Chen <gene.chen.richtek@...il.com>,
        Lee Jones <lee.jones@...aro.org>
Cc:     sre@...nel.org, Rob Herring <robh+dt@...nel.org>,
        linux-pm@...r.kernel.org, devicetree <devicetree@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Gene Chen <gene_chen@...htek.com>, Wilma.Wu@...iatek.com,
        shufan_lee@...htek.com, ChiYuan Huang <cy_huang@...htek.com>,
        benjamin.chao@...iatek.com
Subject: Re: [PATCH v7 04/11] mfd: mt6360: Combine mt6360 pmic/ldo resources
 into mt6360 regulator resources



On 02/03/2021 08:16, Gene Chen wrote:
> Lee Jones <lee.jones@...aro.org> 於 2021年1月15日 週五 下午3:32寫道:
>>
>> On Fri, 15 Jan 2021, Gene Chen wrote:
>>
>>> Matthias Brugger <matthias.bgg@...il.com> 於 2021年1月12日 週二 下午8:32寫道:
>>>>
>>>>
>>>>
>>>> On 12/11/2020 11:39, Gene Chen wrote:
>>>>> From: Gene Chen <gene_chen@...htek.com>
>>>>>
>>>>> Combine mt6360 pmic/ldo resources into mt6360 regulator resources
>>>>> to simplify the similar resources object.
>>>>>
>>>>> Signed-off-by: Gene Chen <gene_chen@...htek.com>
>>>>> Acked-for-MFD-by: Lee Jones <lee.jones@...aro.org>
>>>>> ---
>>>>>  drivers/mfd/mt6360-core.c | 11 +++--------
>>>>>  1 file changed, 3 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
>>>>> index 692e47b..5119e51 100644
>>>>> --- a/drivers/mfd/mt6360-core.c
>>>>> +++ b/drivers/mfd/mt6360-core.c
>>>>> @@ -265,7 +265,7 @@ static const struct resource mt6360_led_resources[] = {
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"),
>>>>>  };
>>>>>
>>>>> -static const struct resource mt6360_pmic_resources[] = {
>>>>> +static const struct resource mt6360_regulator_resources[] = {
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"),
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"),
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"),
>>>>> @@ -278,9 +278,6 @@ static const struct resource mt6360_pmic_resources[] = {
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"),
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"),
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"),
>>>>> -};
>>>>> -
>>>>> -static const struct resource mt6360_ldo_resources[] = {
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"),
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"),
>>>>>       DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"),
>>>>> @@ -298,10 +295,8 @@ static const struct mfd_cell mt6360_devs[] = {
>>>>>                   NULL, 0, 0, "mediatek,mt6360-chg"),
>>>>>       OF_MFD_CELL("mt6360-led", mt6360_led_resources,
>>>>>                   NULL, 0, 0, "mediatek,mt6360-led"),
>>>>> -     OF_MFD_CELL("mt6360-pmic", mt6360_pmic_resources,
>>>>> -                 NULL, 0, 0, "mediatek,mt6360-pmic"),
>>>>> -     OF_MFD_CELL("mt6360-ldo", mt6360_ldo_resources,
>>>>> -                 NULL, 0, 0, "mediatek,mt6360-ldo"),
>>>>> +     OF_MFD_CELL("mt6360-regulator", mt6360_regulator_resources,
>>>>> +                 NULL, 0, 0, "mediatek,mt6360-regulator"),
>>>>
>>>> As discussed with the MFD maintainer [1], the regulator (and probably all cells)
>>>> shouldn't have a DT binding.
>>>>
>>>> So please send a new version which fixes that.
>>>>
>>>> Regards,
>>>> Matthias
>>>>
>>>> [1] https://lore.kernel.org/linux-mediatek/20210111164118.GE4728@sirena.org.uk/
>>
>> I don't think Mark is correct here.
>>
>> We usually do implement compatible strings for sub-devices and they do
>> tend to have their own device nodes.
>>
>> It's a very long time ago since I coded this up myself, but from
>> memory, you can't have 2 devices share a compatible string.
>>
> 
> Either Mark or Lee suggestion is work.
> Is there a conclusion that we can apply it?
> If MFD is already supported of_compatible, we prefer use of_compatible mapping.
> 

For regulator on PMIC you should add the regulator to the pmic node directly.
Please see the series from Hsin-Hsiung for referece:
https://lore.kernel.org/linux-mediatek/1615829757-3223-6-git-send-email-hsin-hsiung.wang@mediatek.com/T/#u

Regards,
Matthias

>>> Should I use parent's device to find sub-devices of_node if without
>>> compatible name?
>>> I trace the function mfd_add_device,
>>>
>>> if (IS_ENABLED(CONFIG_OF) && parent->of_node && cell->of_compatible) {
>>>     .....
>>>     ret = mfd_match_of_node_to_dev(pdev, np, cell);
>>>     .....
>>> }
>>>
>>> which is binding mfd sub-device with compatible. Does it be removed in
>>> the feature?
>>>
>>>>>       OF_MFD_CELL("mt6360-tcpc", NULL,
>>>>>                   NULL, 0, 0, "mediatek,mt6360-tcpc"),
>>>>>  };
>>>>>
>>
>> --
>> Lee Jones [李琼斯]
>> Senior Technical Lead - Developer Services
>> Linaro.org │ Open source software for Arm SoCs
>> Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ