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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <06ae1272-9874-4ce7-9e4f-01d521a5f27f@lunn.ch>
Date: Tue, 20 Jan 2026 14:32:30 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Xu Yang <xu.yang_2@....com>
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

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

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

	    Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ