linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Roy Luo <royluo@google.com>
Cc: "Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Peter Griffin" <peter.griffin@linaro.org>,
	"André Draszik" <andre.draszik@linaro.org>,
	"Tudor Ambarus" <tudor.ambarus@linaro.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Badhri Jagan Sridharan" <badhri@google.com>,
	"Doug Anderson" <dianders@google.com>,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	"Joy Chakraborty" <joychakr@google.com>,
	"Naveen Kumar" <mnkumar@google.com>
Subject: Re: [PATCH v9 2/2] phy: Add Google Tensor SoC USB PHY driver
Date: Wed, 24 Dec 2025 11:00:46 +0530	[thread overview]
Message-ID: <aUt6hobN9DPUGbpz@vaman> (raw)
In-Reply-To: <CA+zupgxP+_2iRYABhPM1OOJtRdkrcOvrsKH=Sxk45XwsiamzTw@mail.gmail.com>

On 23-12-25, 09:53, Roy Luo wrote:
> On Tue, Dec 23, 2025 at 6:04 AM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > On 22-12-25, 21:31, Roy Luo wrote:

> > > +struct google_usb_phy {
> > > +     struct device *dev;
> > > +     struct regmap *usb_cfg_regmap;
> > > +     unsigned int usb2_cfg_offset;
> > > +     void __iomem *usbdp_top_base;
> > > +     struct google_usb_phy_instance insts[GOOGLE_USB_PHY_NUM];
> >
> > so you have an array for one phy?
> 
> While the current patch only supports usb2, I used an array
> to simplify future support for usb3 and DP. I understand this
> might seem like over-engineering for now, and we could
> certainly wait to implement the array until the second phy
> support is added. I’m happy to move away from array if
> you’d prefer a simpler approach for this iteration.

Rather than do array, allocate mem as probe based on how many phys will
be there and use that. That would be a better approach than static
allocation here

> > > +static int google_usb2_phy_exit(struct phy *_phy)
> > > +{
> > > +     struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
> > > +     struct google_usb_phy *gphy = to_google_usb_phy(inst);
> > > +     u32 reg;
> > > +
> > > +     dev_dbg(gphy->dev, "exiting usb2 phy\n");
> > > +
> > > +     guard(mutex)(&gphy->phy_mutex);
> > > +
> > > +     regmap_read(gphy->usb_cfg_regmap, gphy->usb2_cfg_offset + USBCS_USB2PHY_CFG21_OFFSET, &reg);
> > > +     reg &= ~USBCS_USB2PHY_CFG21_PHY_ENABLE;
> > > +     regmap_write(gphy->usb_cfg_regmap, gphy->usb2_cfg_offset + USBCS_USB2PHY_CFG21_OFFSET, reg);
> > > +
> > > +     reset_control_bulk_assert(inst->num_rsts, inst->rsts);
> > > +     clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
> > > +
> > > +     return 0;
> > > +}
> > > +
> > > +static const struct phy_ops google_usb2_phy_ops = {
> > > +     .init           = google_usb2_phy_init,
> > > +     .exit           = google_usb2_phy_exit,
> > > +};
> >
> > Only two ops? I would expect more... No power_on/off or set_mode?
> >
> > --
> > ~Vinod
> 
> No, configuring usb2 phy is pretty straightforward. The hardware
> does not distinguish between "initialized" and "powered on" states,
> it also does not distinguish phy mode.

ok

-- 
~Vinod


  reply	other threads:[~2025-12-24  5:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-22 21:31 [PATCH v9 0/2] Add Google Tensor SoC USB PHY support Roy Luo
2025-12-22 21:31 ` [PATCH v9 1/2] dt-bindings: phy: google: Add Google Tensor G5 USB PHY Roy Luo
2025-12-22 21:31 ` [PATCH v9 2/2] phy: Add Google Tensor SoC USB PHY driver Roy Luo
2025-12-23 14:04   ` Vinod Koul
2025-12-23 17:53     ` Roy Luo
2025-12-24  5:30       ` Vinod Koul [this message]
2025-12-25  0:33         ` Roy Luo

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=aUt6hobN9DPUGbpz@vaman \
    --to=vkoul@kernel.org \
    --cc=andre.draszik@linaro.org \
    --cc=badhri@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@google.com \
    --cc=joychakr@google.com \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mnkumar@google.com \
    --cc=neil.armstrong@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=peter.griffin@linaro.org \
    --cc=robh@kernel.org \
    --cc=royluo@google.com \
    --cc=tudor.ambarus@linaro.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;
as well as URLs for NNTP newsgroup(s).