[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rrmva3t4tesocitdrz5yfb35wer4htr5lkymzoyhjx4ajy7tt6@fbhlvrqzswd5>
Date: Fri, 16 Jan 2026 19:30:58 +0800
From: Xu Yang <xu.yang_2@....com>
To: Vinod Koul <vkoul@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, neil.armstrong@...aro.org,
shawnguo@...nel.org, kernel@...gutronix.de, festevam@...il.com, jun.li@....com,
Frank.Li@....com, linux-phy@...ts.infradead.org, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control
register
On Wed, Jan 14, 2026 at 03:09:54PM +0530, Vinod Koul wrote:
> On 08-01-26, 19:24, Andrew Lunn wrote:
> > On Thu, Jan 08, 2026 at 04:36:41PM +0800, Xu Yang wrote:
> > > The CR port is a simple 16-bit data/address parallel port that is
> > > provided for on-chip access to the control registers inside the
> > > USB 3.0 femtoPHY[1]. While access to these registers is not required
> > > for normal PHY operation, this interface enables you to access
> > > some of the PHY’s diagnostic features during normal operation or
> > > to override some basic PHY control signals.
> > >
> > > 3 debugfs files are created to read and write control registers,
> > > all use hexadecimal format:
> > > ctrl_reg_base: the register offset to write, or the start offset
> > > to read.
> > > ctrl_reg_count: how many continuous registers to be read.
> > > ctrl_reg_value: read to show the continuous registers value from
> > > the offset in ctrl_reg_base, to ctrl_reg_base
> > > + ctrl_reg_count - 1, one line for one register.
> > > when write, override the register at ctrl_reg_base,
> > > one time can only change one 16bits register.
> > >
> > > Link[1]: https://www.synopsys.com/dw/doc.php/phy/usb3.0/femto/phy/x652_usb3_ss14lpp_18_ns/4.07a/dwc_usb3.0_femtophy_ss14lpp_08V18V_x1_databook.pdf
> >
> > Please don't ignore my comments to V2. Think about the code split
> > between the generic IP licensed from Synopsys and the vendor specific
> > code used for integration into the SoC. You want to avoid making a
> > mess you later need to cleanup because somebody else licensed the same
> > IP core from Synopsys, and need to put their own vendor specific
> > integration code around the generic code.
>
> Agree with Andrew here, please do mix, splitting would be better
OK, will try.
Thanks,
Xu Yang
>
> >
> > Andrew
>
> --
> ~Vinod
Powered by blists - more mailing lists