From: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Manivannan Sadhasivam <mani@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-usb@vger.kernel.org,
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Subject: Re: [PATCH v8 2/5] include: linux: phy: Add phy attribute "type" and associated helpers
Date: Fri, 9 Oct 2026 22:29:56 +0530 [thread overview]
Message-ID: <3a3cf540-816f-41a3-b31d-2902e7f4cf01@oss.qualcomm.com> (raw)
In-Reply-To: <asNji2_GUda8x245@parshuram>
On 10/5/2026 2:14 PM, Vinod Koul wrote:
> On 13-09-26, 20:10, Krishna Kurapati wrote:
>> In cases like USB High-speed phys which can be either USB2 or EUSB2, it is
>> required to know the type of phy (rather than the operating mode) because
>> DP and DM interrupt lines need to be configured differently for each of
>> them.
>
> Does the controller care? In preceding patch you defined the EUSB2 in dt
> type, so this describes the hardware. So phy knows it is usb or eusb...
>>
Controller is agnostic of whether the phy is usb2 or eusb2. Phy does now
its type, but it needs to communicate the same to controller.
>> Add support to cache the PHY_TYPE and add the following helpers:
>>
>> - phy_set_type() for the phy drivers (like m31_eusb2 or snps-eusb2) to
>> declare what type of PHY they are (in this case PHY_TYPE_EUSB2).
>>
>> - phy_get_type() for the consumers (like USB controllers) to query the
>> type of phy connected to them.
>
> I am not convinced that this is the way to go... Driver already knows
> the type and should use it...
> we alreayd have mode, i am inclined to not say yes to adding type here
>
"Mode" attribute describes the current operating scenario of the phy
(device mode, host mode, high speed, super speed etc.,). But it doesn't
describe the type of hardware and hence a new attribute.
Regards,
Krishna,
>>
>> Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>> ---
>> include/linux/phy/phy.h | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index ea47975e288a..038c2b58bbe1 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -21,6 +21,8 @@
>> #include <linux/phy/phy-lvds.h>
>> #include <linux/phy/phy-mipi-dphy.h>
>>
>> +#include <dt-bindings/phy/phy.h>
>> +
>> struct phy;
>>
>> enum phy_mode {
>> @@ -152,11 +154,13 @@ struct phy_ops {
>> * @bus_width: Data path width implemented by PHY
>> * @max_link_rate: Maximum link rate supported by PHY (units to be decided by producer and consumer)
>> * @mode: PHY mode
>> + * @type: PHY type
>> */
>> struct phy_attrs {
>> u32 bus_width;
>> u32 max_link_rate;
>> enum phy_mode mode;
>> + int type;
>> };
>>
>> /**
>> @@ -262,6 +266,20 @@ static inline enum phy_mode phy_get_mode(struct phy *phy)
>> {
>> return phy->attrs.mode;
>> }
>> +
>> +static inline int phy_get_type(struct phy *phy)
>> +{
>> + if (phy)
>> + return phy->attrs.type;
>> +
>> + return PHY_NONE;
>> +}
>> +
>> +static inline void phy_set_type(struct phy *phy, int type)
>> +{
>> + phy->attrs.type = type;
>> +}
>> +
>> int phy_reset(struct phy *phy);
>> int phy_calibrate(struct phy *phy);
>> int phy_notify_connect(struct phy *phy, int port);
>> @@ -393,6 +411,15 @@ static inline enum phy_mode phy_get_mode(struct phy *phy)
>> return PHY_MODE_INVALID;
>> }
>>
>> +static inline int phy_get_type(struct phy *phy)
>> +{
>> + return PHY_NONE;
>> +}
>> +
>> +static inline void phy_set_type(struct phy *phy, int type)
>> +{
>> +}
>> +
>> static inline int phy_reset(struct phy *phy)
>> {
>> if (!phy)
>>
>> --
>> 2.34.1
>
next prev parent reply other threads:[~2026-10-09 17:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 14:40 [PATCH v8 0/5] Modify interrupt handling for eUSB2 Phy targets Krishna Kurapati
2026-09-13 14:40 ` [PATCH v8 1/5] dt-bindings: phy: Add PHY_TYPE_EUSB2 definition Krishna Kurapati
2026-09-13 14:40 ` [PATCH v8 2/5] include: linux: phy: Add phy attribute "type" and associated helpers Krishna Kurapati
2026-10-05 8:44 ` Vinod Koul
2026-10-09 16:59 ` Krishna Kurapati [this message]
2026-09-13 14:40 ` [PATCH v8 3/5] phy: snps-eusb2: Set phy type to EUSB2 Krishna Kurapati
2026-09-13 14:40 ` [PATCH v8 4/5] phy: qcom: m31-eusb2: " Krishna Kurapati
2026-09-13 14:40 ` [PATCH v8 5/5] usb: dwc3: qcom: Modify interrupt handling for eUSB2 Phy targets Krishna Kurapati
2026-10-04 9:34 ` [PATCH v8 0/5] " Joonhoe Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a3cf540-816f-41a3-b31d-2902e7f4cf01@oss.qualcomm.com \
--to=krishna.kurapati@oss.qualcomm.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=neil.armstrong@linaro.org \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox