linux-kernel - Re: [PATCH v3 14/16] phy: Add notify

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:   Wed, 20 Dec 2017 11:59:26 +0530
From:   Manu Gautam <mgautam@...eaurora.org>
To:     Kishon Vijay Abraham I <kishon@...com>
Cc:     linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        "open list:GENERIC PHY FRAMEWORK" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 14/16] phy: Add notify_speed callback

Hi,

On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote:
>> Hi,
>>
>>
>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
>>>> QCOM USB PHYs can monitor resume/remote-wakeup event in
>>>> suspended state. However PHY driver must know current
>>>> operational speed of PHY in order to set correct polarity of
>>>> wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
>>>> signals depending on speed is LS or FS/HS to detect resume.
>>>> Similarly QMP USB3 PHY in SS mode should monitor RX
>>>> terminations attach/detach and LFPS events depending on
>>>> SSPHY is active or not.
> Why not use a notification mechanism instead of adding new APIs in phy-core.
> This will only bloat phy-core with APIs for a particular platform.

Do you mean notifier_chains ?
When we have multiple instances of USB PHYs then notifier chains are not
of much help. For any platform glue or PHY driver it will be very difficult to
figure out if notification received for speed was for same phy/bus or a
different one.
Using PHY callbacks looked more elegant to me. Additionally PHY drivers
can also use this info decide power management policy e.g. if speed is
INVALID then it means PHY is not in a session and it can enter deepest
low power state.
Additionally if you prefer set_speed name over notify_speed then I am
ok with that as well so that it sounds more generic.

>
> Thanks
> Kishon
>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project