From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Li Chen <me@linux.beauty>
Cc: "rafael j. wysocki" <rafael@kernel.org>,
li chen <lchen@ambarella.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] debugfs: allow to use regmap for print regs
Date: Wed, 11 Jan 2023 11:48:38 +0100 [thread overview]
Message-ID: <Y76UBsukAz+yQ9bW@kroah.com> (raw)
In-Reply-To: <1859ff0ddb8.d9ed321d977156.553326609923116766@linux.beauty>
On Wed, Jan 11, 2023 at 04:27:20PM +0800, Li Chen wrote:
> Hi Greg,
> ---- On Wed, 11 Jan 2023 15:42:44 +0800 Greg Kroah-Hartman wrote ---
> > On Wed, Jan 11, 2023 at 03:21:29PM +0800, Li Chen wrote:
> > > From: Li Chen lchen@ambarella.com>
> > >
> > > Currently, debugfs_regset32 only contains void __iomem *base,
> > > and it is not friendly to regmap user.
> > >
> > > Let's add regmap to debugfs_regset32, and add debugfs_print_regmap_reg32
> > > to allow debugfs_regset32_show handle regmap.
> > >
> > > Signed-off-by: Li Chen lchen@ambarella.com>
> >
> > Do you have an actual in-kernel user for this new function? We can't
> > accept new apis without users for obvious reasaons.
>
> Actually, both the old debugfs_print_regs32 and the new debugfs_regmap_print_regs32
> have only one user: debugfs_regset32_show located inside debugfs/file.c.
Yes, but that function is used by lots of drivers in the kernel today,
which is fine.
> The difference is currently all users(device drivers) only use debugfs_regset32->base,
> and none of them use debugfs_regset32->regmap, which is provided by this patch.
>
> I'm not sure whether it violates the kernel's "no user, no new function" ruler or not.
Yes, you would have to have a user for this functionality for us to be
able to take the change.
> I use this regmap locally on our SoC driver, but it is still not ready to upstream, really sorry for it,
> and it is not a good idea to change existing non-regmap users to regmap haha.
>
> If you think it does matter, please tell me and I will upload v3 with our SoC driver in the future.
Please add it to your SoC driver patch series instead and I will be glad
to review it at that point in time. But for now, this shouldn't be
needed.
thanks,
greg k-h
next prev parent reply other threads:[~2023-01-11 10:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 7:21 [PATCH v2] debugfs: allow to use regmap for print regs Li Chen
2023-01-11 7:42 ` Greg Kroah-Hartman
2023-01-11 8:27 ` Li Chen
2023-01-11 10:48 ` Greg Kroah-Hartman [this message]
2023-01-23 7:49 ` Li Chen
2023-01-11 14:59 ` kernel test robot
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=Y76UBsukAz+yQ9bW@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=lchen@ambarella.com \
--cc=linux-kernel@vger.kernel.org \
--cc=me@linux.beauty \
--cc=rafael@kernel.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