linux-kernel - Re: [PATCH v6 4/6] mfd: tps65219: Add driver for TI TPS65219 PMIC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1231f3e6-61a7-ca3c-2fbb-679b583e0df1@ti.com>
Date:   Thu, 10 Nov 2022 11:44:45 -0600
From:   Andrew Davis <afd@...com>
To:     Kevin Hilman <khilman@...libre.com>,
        jerome Neanne <jneanne@...libre.com>,
        Nishanth Menon <nm@...com>
CC:     Lee Jones <lee@...nel.org>, <lgirdwood@...il.com>,
        <broonie@...nel.org>, <robh+dt@...nel.org>, <kristo@...nel.org>,
        <dmitry.torokhov@...il.com>, <krzysztof.kozlowski+dt@...aro.org>,
        <catalin.marinas@....com>, <will@...nel.org>, <tony@...mide.com>,
        <vigneshr@...com>, <bjorn.andersson@...aro.org>,
        <shawnguo@...nel.org>, <geert+renesas@...der.be>,
        <dmitry.baryshkov@...aro.org>, <marcel.ziswiler@...adex.com>,
        <vkoul@...nel.org>, <biju.das.jz@...renesas.com>, <arnd@...db.de>,
        <jeff@...undy.com>, <narmstrong@...libre.com>, <msp@...libre.com>,
        <j-keerthy@...com>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-input@...r.kernel.org>, <linux-omap@...r.kernel.org>
Subject: Re: [PATCH v6 4/6] mfd: tps65219: Add driver for TI TPS65219 PMIC

On 11/10/22 11:00 AM, Kevin Hilman wrote:
> jerome Neanne <jneanne@...libre.com> writes:
> 
>> On 09/11/2022 22:59, Andrew Davis wrote:
>>> On 11/7/22 3:14 PM, Kevin Hilman wrote:
>>>> Nishanth Menon <nm@...com> writes:
>>>>
>>>>> On 13:58-20221104, jerome Neanne wrote:
>>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Can you try an compile with W=1 please.
>>>>>> This raise one warning on mfd:
>>>>>> drivers/mfd/tps65219.c:28:12: warning: ‘tps65219_soft_shutdown’
>>>>>> defined but
>>>>>> not used [-Wunused-function]
>>>>>>      28 | static int tps65219_soft_shutdown(struct tps65219 *tps)
>>>>>>         |            ^~~~~~~~~~~~~~~~~~~~~~
>>>>>> soft_shutdown has been validated and is used in TI baseline even if not
>>>>>> hooked in upstream version further to this review:
>>>>>> https://lore.kernel.org/lkml/20220825150224.826258-5-msp@baylibre.com/
>>>>>>
>>>>>> It was a TI requirement to implement it...
>>>>>> Let me know if you want me to remove this function or if we can keep
>>>>>> it like
>>>>>> this.
>>>>>
>>>>> There are platforms without psci, correct? I think the comment was to
>>>>> drop the force override with system-power-controller property,
>>>>>
>>>>> if (!pm_power_off) {
>>>>>      tps65219_i2c_client = client;
>>>>>      pm_power_off = &tps65219_pm_power_off;
>>>>> }
>>>>>
>>>>> Could still be valid for such platforms, no? I do see that the
>>>>> capability that the PMIC has - which is software shutdown is a valid
>>>>> feature that we support in many different PMIC drivers. Is'nt the job of
>>>>> the driver to introduce the functionality in a manner that is
>>>>> appropriate to the OS framework?
>>>>
>>>> Yeah, I think Nishanth is right here.
>>>>
>>>> We should probably keep the `if (!pm_power_off)` part so the PMIC will
>>>> be used if PSCI is not, but it also allows an easy way to test/use the
>>>> PMIC
>>>> shutdown functionality downstream if needed.
>>>>
>>>
>>> Then should be using the sys-off handler API[0] so it doesn't block PSCI
>>> which is also switching over[1].
>>>
>>> Andrew
>>>
>>> [0] https://lwn.net/Articles/894511/
>>> [1] https://www.spinics.net/lists/arm-kernel/msg1024127.html
>> Can we go for upstream with v7 without tps65219_soft_shutdown. Then if
>> everyone agrees with Andrew proposal, I'll submit a separate patch which
>> adds implementation of tps65219_soft_shutdown support through sys-off
>> handler.
>>
>> So that we are not blocking upstream in case further
>> discussions/alignment are required.
> 
> Seems OK to me.  Nishanth?  Andrew?
> 
> But I think you'll need to at least submit a v8 without the unused
> code/dead code that Lee pointed out.
> 

If you need the v8 anyway, then add support through sys-off in
that spin, should only be a couple lines of change.

Andrew