lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5qogopa335bhootpiprw37f3uhxiftj3rqmouknyvyzrogrsoi@b4wfrxrebpzt>
Date: Fri, 23 Jan 2026 16:05:48 +0800
From: Xu Yang <xu.yang_2@....com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Frank Li <Frank.li@....com>, vkoul@...nel.org, 
	neil.armstrong@...aro.org, shawnguo@...nel.org, kernel@...gutronix.de, festevam@...il.com, 
	jun.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 Tue, Jan 20, 2026 at 02:32:30PM +0100, Andrew Lunn wrote:
> > > Rather than reinvent the wheel, could you use regmap?
> > > 
> > > https://elixir.bootlin.com/linux/v6.12.1/source/drivers/base/regmap/regmap-debugfs.c#L546
> > > 
> > > Regmap should be able to provide a debugfs interface for you, no
> > > driver code needed.
> > > 
> > > This will also help you with the abstraction between the core generic
> > > part of the PHY driver and the SoC integration glue. You pass the
> > > regmap to the core driver, and the funny muxing through two registers
> > > is hidden away from the core. If the next SoC integrated uses plan
> > > MMIO, that SoC glue driver can instantiate an MMIO regmap.
> > > 
> > > Using regmap is a good idea for core generic drivers which can be
> > > integrated into SoCs in different ways. It hides the SoC details
> > > behind a well known API.
> > 
> > Thanks for your suggestion.
> > 
> > Using regmap is generally a good fit for reusable driver and I aggre it
> > helps abstract Soc-specific details.
> > 
> > However, the regmap defbugfs has its own limitations:
> > 1. By default the register is read-only, add write operation require rebuild
> >    the kernel which make it inconvenient to debug the issue on the spot.
> 
> That is somewhat deliberate. We don't want a nice API which can be
> used for user space binary blob drivers. In networking, which is my
> more normal area, we pretty much reject any sort of write interface,
> other than official kernel APIs.

OK.

> 
> >    Refer to: "09c6ecd39410 regmap: Add support for writing to regmap registers
> >               via debugfs"
> > 
> >     # ls /sys/kernel/debug/regmap/2-0050/ -l
> >     total 0
> >     -r-------- 1 root root 0 Jan 20 07:45 access
> >     -r-------- 1 root root 0 Jan 20 07:45 name
> >     -r-------- 1 root root 0 Jan 20 07:45 range
> >     -r-------- 1 root root 0 Jan 20 07:45 registers
> > 
> > 2. It can't randomly read specific one register with common linux commands. Besides,
> >    the read operation is inefficient especially when the range is a bit large because
> >    when you cat the register it always read and output all the registers. 
> 
> You are debugging. Do you need efficient output?
> 
> If you have a specific debug tasks in mind, maybe you should be
> thinking of an official kernel API? In the past, there has been
> interest in getting SERDES eye information out of PHYs, and being able
> to change the configuration parameters of the eye. Could a generic API
> be added for that? Some of these PHYs also support pseudo random bit
> sequence generators, and there has been interest in adding APIs for
> configuring them.

After an internal discussion, we prefer to simply export Soc specific control
register access regmap in debugfs and let usespace read or write internal
registers according to CR port accessing sequence. With this, no needs for
a generic API for now.

Thanks for your comments.

Best Regards,
Xu Yang


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ