Re: [PATCH 6/9] reset: google: Add CPM reset driver

[Philipp Zabel]

On Mo, 2026-11-02 at 17:03 -0800, Brian Norris wrote:
> Hi Philipp,
> 
> On Wed, Oct 28, 2026 at 03:03:24PM +0100, Philipp Zabel wrote:
> > On Mo, 2026-10-26 at 14:43 -0700, Brian Norris wrote:
[...]
> > > +DEFINE_DEBUGFS_ATTRIBUTE(goog_cpm_rst_assert_debugfs_fops, NULL,
> > > +			 goog_cpm_rst_debugfs_assert_set, "%llu\n");
> > > +
> > > +DEFINE_DEBUGFS_ATTRIBUTE(goog_cpm_rst_deassert_debugfs_fops, NULL,
> > > +			 goog_cpm_rst_debugfs_deassert_set, "%llu\n");
> > > +
> > > +static void goog_cpm_rst_add_debugfs(struct goog_cpm_rst_debugfs_entry *entry,
> > > +				     struct dentry *debugfs_root,
> > > +				     const char *name)
> > > +{
> > > +	struct dentry *d = debugfs_create_dir(name, debugfs_root);
> > > +
> > > +	debugfs_create_file("assert", 0220, d, entry,
> > > +			    &goog_cpm_rst_assert_debugfs_fops);
> > > +	debugfs_create_file("deassert", 0220, d, entry,
> > > +			    &goog_cpm_rst_deassert_debugfs_fops);
> > > +}
> > 
> > Please drop the debugfs functionality or explain what it is needed for.
> 
> Ack. I think I'll probably go with "drop", but some notes:
> 
> There's no real way to test and validate a "reset" driver without a
> consumer. There is no direct (even for debug) interface into the reset
> API, unlike in some other subsystems (e.g., GPIO). I believe the main
> purpose here on Pixel drivers has been hardware+driver testing, so one
> can test reset functionality before hooking it up to real client
> drivers, and without adding fake drivers or extra debug code (a la
> "printf debugging").
> 
> (One might observe these results either via /dev/mem-like access to
> registers, or even through external debug peripherals/consoles that can
> monitor the status of the underlying component that is being reset.)
> 
> This all would generally be in an early hardware bringup scenario, so
> admittedly it probably doesn't have as much of a use case in the
> upstream kernel  -- it's a long shot for this kind of hardware/product
> development to *actually* work directly on an upstream kernel, with
> upstream drivers.
> 
> ...but if I were imagining a better way to do this without bypassing
> reference counting: perhaps it could be useful to a have a
> debug-oriented "reset client" driver, that could bind to arbitrary reset
> devices, if they're not already owned, and expose a sysfs or debugfs
> interface like this? That could fill similar use cases for this sort of
> hardware testing/validation area.
> 
> But anyway, I understand such a proposal should definitely come
> separately from this driver submission.

Thank you for explaining anyway. With that use case in mind, I think
"drop" is the right choice for now. This functionality can be
implemented in the core and use reset controls like any other consumer
driver.

regards
Philipp