All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Brown <broonie@kernel.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	rafael@kernel.org, lgirdwood@gmail.com, perex@perex.cz,
	tiwai@suse.com, linux-kernel@vger.kernel.org,
	alsa-devel@alsa-project.org, srivasam@codeaurora.org,
	rohitkr@codeaurora.org
Subject: Re: [PATCH v2 1/2] regmap: add support to regmap_field_bulk_alloc/free apis
Date: Wed, 30 Sep 2020 14:11:00 +0200	[thread overview]
Message-ID: <20200930121100.GA1616135@kroah.com> (raw)
In-Reply-To: <20200930120849.GG4974@sirena.org.uk>

On Wed, Sep 30, 2020 at 01:08:49PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2020 at 01:59:15PM +0200, Greg KH wrote:
> > On Fri, Sep 25, 2020 at 05:48:55PM +0100, Srinivas Kandagatla wrote:
> 
> > > +int devm_regmap_field_bulk_alloc(struct device *dev, struct regmap *regmap,
> > > +				 struct regmap_field **field,
> > > +				 struct reg_field *reg_field, int num_fields);
> > > +void devm_regmap_field_bulk_free(struct device *dev,
> > > +				 struct regmap_field *field);
> > > +
> > 
> > You only have a patch that uses these last two functions, so why add all
> > 4?  We don't add infrastructure to the kernel without users.
> 
> We have managed versions of the other regmap allocation functions, it
> makes sense for consistency to have managed versions of these too.  I
> think there's a meaningful difference between a simple and expected
> wrapper like these and infrastructure which hasn't been proved out by
> users.

Ok, do you think these are really needed?

A review would be nice :)

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, srivasam@codeaurora.org,
	lgirdwood@gmail.com, rafael@kernel.org,
	linux-kernel@vger.kernel.org, tiwai@suse.com,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	rohitkr@codeaurora.org
Subject: Re: [PATCH v2 1/2] regmap: add support to regmap_field_bulk_alloc/free apis
Date: Wed, 30 Sep 2020 14:11:00 +0200	[thread overview]
Message-ID: <20200930121100.GA1616135@kroah.com> (raw)
In-Reply-To: <20200930120849.GG4974@sirena.org.uk>

On Wed, Sep 30, 2020 at 01:08:49PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2020 at 01:59:15PM +0200, Greg KH wrote:
> > On Fri, Sep 25, 2020 at 05:48:55PM +0100, Srinivas Kandagatla wrote:
> 
> > > +int devm_regmap_field_bulk_alloc(struct device *dev, struct regmap *regmap,
> > > +				 struct regmap_field **field,
> > > +				 struct reg_field *reg_field, int num_fields);
> > > +void devm_regmap_field_bulk_free(struct device *dev,
> > > +				 struct regmap_field *field);
> > > +
> > 
> > You only have a patch that uses these last two functions, so why add all
> > 4?  We don't add infrastructure to the kernel without users.
> 
> We have managed versions of the other regmap allocation functions, it
> makes sense for consistency to have managed versions of these too.  I
> think there's a meaningful difference between a simple and expected
> wrapper like these and infrastructure which hasn't been proved out by
> users.

Ok, do you think these are really needed?

A review would be nice :)

thanks,

greg k-h

  reply	other threads:[~2020-09-30 12:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 16:48 [PATCH v2 0/2] regmap: add support to regmap_field_bulk_alloc/free Srinivas Kandagatla
2020-09-25 16:48 ` Srinivas Kandagatla
2020-09-25 16:48 ` [PATCH v2 1/2] regmap: add support to regmap_field_bulk_alloc/free apis Srinivas Kandagatla
2020-09-25 16:48   ` Srinivas Kandagatla
2020-09-30 11:59   ` Greg KH
2020-09-30 11:59     ` Greg KH
2020-09-30 12:08     ` Mark Brown
2020-09-30 12:08       ` Mark Brown
2020-09-30 12:11       ` Greg KH [this message]
2020-09-30 12:11         ` Greg KH
2020-09-30 12:15         ` Mark Brown
2020-09-30 12:15           ` Mark Brown
2020-09-30 12:27           ` Greg KH
2020-09-30 12:27             ` Greg KH
2020-09-25 16:48 ` [PATCH v2 2/2] ASoC: lpass-platform: use devm_regmap_field_bulk_alloc Srinivas Kandagatla
2020-09-25 16:48   ` Srinivas Kandagatla
2020-09-28 19:34 ` [PATCH v2 0/2] regmap: add support to regmap_field_bulk_alloc/free Mark Brown
2020-09-28 19:34   ` Mark Brown

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=20200930121100.GA1616135@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=rafael@kernel.org \
    --cc=rohitkr@codeaurora.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=srivasam@codeaurora.org \
    --cc=tiwai@suse.com \
    /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.