mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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: Tue, 27 Oct 2026 13:37:27 +0530	[thread overview]
Message-ID: <033c8432-4a03-4f38-b0a3-28f5d551b0ef@oss.qualcomm.com> (raw)
In-Reply-To: <3a3cf540-816f-41a3-b31d-2902e7f4cf01@oss.qualcomm.com>



On 10/9/2026 10:29 PM, Krishna Kurapati wrote:
> 
> 
> 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.
> 

Vinod, can you please let know if you are fine with this approach. If 
yes, I will send v9 rebased on top of phy-next.

Regards,
Krishna,


> 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
>>
> 


  reply	other threads:[~2026-10-27  8:07 UTC|newest]

Thread overview: 10+ 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
2026-10-27  8:07       ` 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=033c8432-4a03-4f38-b0a3-28f5d551b0ef@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

all inboxes | Powered by JetHome®