All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.