Re: [PATCH v3 14/16] phy: Add notify_speed callback
Hi, On 12/29/2017 11:58 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 29 December 2017 09:54 AM, Manu Gautam wrote: >> Hi, [snip] > > suggest using switch in such case.. and not all PHY drivers do specific > configurations for specific speeds. >> This looks clumsy. >> Where as if bits to used then there is no need for such changes. > really? using bits should only make it more clumsy. Thanks for your feedback. I will update this in next patchset. > -Kishon -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 14/16] phy: Add notify_speed callback
Hi,
On Friday 29 December 2017 09:54 AM, Manu Gautam wrote:
> Hi,
>
>
> On 12/28/2017 4:34 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
> [snip]
>>
I'd prefer adding modes in enum phy_mode according to speed and using
phy_set_mode.
>>> yeah, that also seems good idea. How about something like this:
>>>
>>> --- a/include/linux/phy/phy.h
>>> +++ b/include/linux/phy/phy.h
>>> @@ -23,12 +23,16 @@
>>> struct phy;
>>>
>>> enum phy_mode {
>>> - PHY_MODE_INVALID,
>>> - PHY_MODE_USB_HOST,
>>> - PHY_MODE_USB_DEVICE,
>>> - PHY_MODE_USB_OTG,
>>> - PHY_MODE_SGMII,
>>> - PHY_MODE_10GKR,
>>> + PHY_MODE_INVALID= 0,
>>> + PHY_MODE_USB_HOST = BIT(0),
>>> + PHY_MODE_USB_DEVICE = BIT(1),
>>> + PHY_MODE_USB_OTG, = BIT(2),
>>> + PHY_MODE_SGMII = BIT(3),
>>> + PHY_MODE_10GKR = BIT(4),
>>> + PHY_MODE_USB_LS = BIT(5),
>>> + PHY_MODE_USB_FS = BIT(6),
>>> + PHY_MODE_USB_HS = BIT(7),
>>> + PHY_MODE_USB_SS = BIT(8),
>>> };
>>>
>>>
>>> This way I don't need to duplicate USB speed enums for host/device or otg
>>> modes.
>> no.. let's keep enum. It's lot more cleaner IMO.
>
> In that case all PHY drivers would need to consider these speed enums. E.g.
>
> if (mode == HOST) check in PHY driver would need to be changed to:
> if (mode == HOST || mode == HOST_LS || mode == HOST_FS || mode == HOST_HS ||
> mode == HOST_SS
suggest using switch in such case.. and not all PHY drivers do specific
configurations for specific speeds.
>
> This looks clumsy.
> Where as if bits to used then there is no need for such changes.
really? using bits should only make it more clumsy.
-Kishon
Re: [PATCH v3 14/16] phy: Add notify_speed callback
Hi,
On 12/28/2017 4:34 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
[snip]
>
>>> I'd prefer adding modes in enum phy_mode according to speed and using
>>> phy_set_mode.
>> yeah, that also seems good idea. How about something like this:
>>
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -23,12 +23,16 @@
>> struct phy;
>>
>> enum phy_mode {
>> -PHY_MODE_INVALID,
>> -PHY_MODE_USB_HOST,
>> -PHY_MODE_USB_DEVICE,
>> -PHY_MODE_USB_OTG,
>> -PHY_MODE_SGMII,
>> -PHY_MODE_10GKR,
>> +PHY_MODE_INVALID= 0,
>> +PHY_MODE_USB_HOST = BIT(0),
>> +PHY_MODE_USB_DEVICE = BIT(1),
>> +PHY_MODE_USB_OTG, = BIT(2),
>> +PHY_MODE_SGMII = BIT(3),
>> +PHY_MODE_10GKR = BIT(4),
>> +PHY_MODE_USB_LS = BIT(5),
>> +PHY_MODE_USB_FS = BIT(6),
>> +PHY_MODE_USB_HS = BIT(7),
>> +PHY_MODE_USB_SS = BIT(8),
>> };
>>
>>
>> This way I don't need to duplicate USB speed enums for host/device or otg
>> modes.
> no.. let's keep enum. It's lot more cleaner IMO.
In that case all PHY drivers would need to consider these speed enums. E.g.
if (mode == HOST) check in PHY driver would need to be changed to:
if (mode == HOST || mode == HOST_LS || mode == HOST_FS || mode == HOST_HS ||
mode == HOST_SS
This looks clumsy.
Where as if bits to used then there is no need for such changes.
>
> Thanks
> Kishon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v3 14/16] phy: Add notify_speed callback
Hi,
On Wednesday 20 December 2017 02:11 PM, Manu Gautam wrote:
> Hi
>
>
> On 12/20/2017 12:47 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
> [snip]
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.
>> I'd prefer adding modes in enum phy_mode according to speed and using
>> phy_set_mode.
>
> yeah, that also seems good idea. How about something like this:
>
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -23,12 +23,16 @@
> struct phy;
>
> enum phy_mode {
> - PHY_MODE_INVALID,
> - PHY_MODE_USB_HOST,
> - PHY_MODE_USB_DEVICE,
> - PHY_MODE_USB_OTG,
> - PHY_MODE_SGMII,
> - PHY_MODE_10GKR,
> + PHY_MODE_INVALID= 0,
> + PHY_MODE_USB_HOST = BIT(0),
> + PHY_MODE_USB_DEVICE = BIT(1),
> + PHY_MODE_USB_OTG, = BIT(2),
> + PHY_MODE_SGMII = BIT(3),
> + PHY_MODE_10GKR = BIT(4),
> + PHY_MODE_USB_LS = BIT(5),
> + PHY_MODE_USB_FS = BIT(6),
> + PHY_MODE_USB_HS = BIT(7),
> + PHY_MODE_USB_SS = BIT(8),
> };
>
>
> This way I don't need to duplicate USB speed enums for host/device or otg
> modes.
no.. let's keep enum. It's lot more cleaner IMO.
Thanks
Kishon
Re: [PATCH v3 14/16] phy: Add notify_speed callback
Hi
On 12/20/2017 12:47 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
[snip]
>>> 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.
> I'd prefer adding modes in enum phy_mode according to speed and using
> phy_set_mode.
yeah, that also seems good idea. How about something like this:
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -23,12 +23,16 @@
struct phy;
enum phy_mode {
- PHY_MODE_INVALID,
- PHY_MODE_USB_HOST,
- PHY_MODE_USB_DEVICE,
- PHY_MODE_USB_OTG,
- PHY_MODE_SGMII,
- PHY_MODE_10GKR,
+ PHY_MODE_INVALID= 0,
+ PHY_MODE_USB_HOST = BIT(0),
+ PHY_MODE_USB_DEVICE = BIT(1),
+ PHY_MODE_USB_OTG, = BIT(2),
+ PHY_MODE_SGMII = BIT(3),
+ PHY_MODE_10GKR = BIT(4),
+ PHY_MODE_USB_LS = BIT(5),
+ PHY_MODE_USB_FS = BIT(6),
+ PHY_MODE_USB_HS = BIT(7),
+ PHY_MODE_USB_SS = BIT(8),
};
This way I don't need to duplicate USB speed enums for host/device or otg modes.
> Thanks
> Kishon
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v3 14/16] phy: Add notify_speed callback
Hi, On Wednesday 20 December 2017 11:59 AM, Manu Gautam wrote: > 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. I'd prefer adding modes in enum phy_mode according to speed and using phy_set_mode. Thanks Kishon
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
Re: [PATCH v3 14/16] phy: Add notify_speed callback
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.
Thanks
Kishon
>>>
>>> Signed-off-by: Manu Gautam
>>> ---
>>> 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
>
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
>> ---
>> 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
Re: [PATCH v3 14/16] phy: Add notify_speed callback
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
> ---
> 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?
Thanks
Kishon
[PATCH v3 14/16] phy: Add notify_speed callback
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
---
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);
+
/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a..9efd3cd 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -33,6 +33,14 @@ enum phy_mode {
PHY_MODE_UFS_HS_B,
};
+enum phy_speed {
+ PHY_SPEED_UNKNOWN,
+ PHY_SPEED_USB_LS,
+ PHY_SPEED_USB_FS,
+ PHY_SPEED_USB_HS,
+ PHY_SPEED_USB_SS,
+};
+
/**
* struct phy_ops - set of function pointers for performing phy operations
* @init: operation to be performed for initializing phy
@@ -42,6 +50,8 @@ enum phy_mode {
* @set_mode: set the mode of the phy
* @reset: resetting the phy
* @calibrate: calibrate the phy
+ * @notify_speed: notify phy driver of current speed of PHY
+ * @get_speed: get current operational speed of PHY
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -52,6 +62,8 @@ struct phy_ops {
int (*set_mode)(struct phy *phy, enum phy_mode mode);
int (*reset)(struct phy *phy);
int (*calibrate)(struct phy *phy);
+ int (*notify_speed)(struct phy *phy, enum phy_speed speed);
+ enum phy_speed (*get_speed)(struct phy *phy);
struct module *owner;
};
@@ -146,6 +158,8 @@ static inline void *phy_get_drvdata(struct phy *phy)
int phy_set_mode(struct phy *phy, enum phy_mode mode);
int phy_reset(struct phy *phy);
int phy_calibrate(struct phy *phy);
+int phy_notify_speed(struct phy *phy, enum phy_speed speed);
+enum phy_speed phy_get_speed(struct phy *phy);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy->attrs.bus_width;
@@ -274,6 +288,18 @@ static inline int phy_calibrate(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_notify_speed(struct phy *phy, enum phy_speed speed)
+{
+ if (!phy)
+ return 0;
+ return -EINVAL;
+}
+
+static inline enum phy_speed phy_get_speed(struct phy *phy)
+{
+ return PHY_SPEED_UNKNOWN;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
