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:   Tue, 12 Dec 2017 20:54:42 +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/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.
>>
>> Signed-off-by: Manu Gautam <mgautam@...eaurora.org>
>> ---
>>  drivers/phy/phy-core.c  | 30 ++++++++++++++++++++++++++++++
>>  include/linux/phy/phy.h | 26 ++++++++++++++++++++++++++
>>  2 files changed, 56 insertions(+)
>>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index b4964b0..03df2be 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -387,6 +387,36 @@ int phy_calibrate(struct phy *phy)
>>  }
>>  EXPORT_SYMBOL_GPL(phy_calibrate);
>>  
>> +int phy_notify_speed(struct phy *phy, enum phy_speed speed)
>> +{
>> +	int ret;
>> +
>> +	if (!phy || !phy->ops->notify_speed)
>> +		return 0;
>> +
>> +	mutex_lock(&phy->mutex);
>> +	ret = phy->ops->notify_speed(phy, speed);
>> +	mutex_unlock(&phy->mutex);
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(phy_notify_speed);
>> +
>> +enum phy_speed phy_get_speed(struct phy *phy)
>> +{
>> +	enum phy_speed ret;
>> +
>> +	if (!phy || !phy->ops->get_speed)
>> +		return PHY_SPEED_UNKNOWN;
>> +
>> +	mutex_lock(&phy->mutex);
>> +	ret = phy->ops->get_speed(phy);
>> +	mutex_unlock(&phy->mutex);
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(phy_get_speed);
> So this is equivalent to set_speed (why notify?) and get_speed. set_speed will
> most likely be invoked by USB driver? who will invoke get_speed?

I picked notify_speed as set_speed sounds like driver is going to set/program
speed related configuration in PHY. Where as the purpose of this function
is to notify phy_driver of the connection speed of established link.
USB glue drivers for Qualcomm platforms need to know USB PHYs' speed to
set correct polarity of wakeup interrupt from hardware in low power state.
 

> Thanks
> Kishon

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