| Message ID | 20170713072351.GA1485@embeddedgus (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 29a22ebfa4c44bf96b3d00d90b5e3b8128d8a162 |
| Headers | show |
Gustavo, please stop posting in this style. It's really annoying to see spontaneously popping-up almost same patch for more than two hours long. If you have a series of the same fix patches, send them as a patch set in a shot with a thread. git-send-email does it right. I don't mind a couple of patches posted separately, but this is over the limit. thanks, Takashi On Thu, 13 Jul 2017 09:23:51 +0200, Gustavo A. R. Silva wrote: > > This structure is only stored in the ops field of a snd_soc_dai_driver > structure. That field is declared const, so snd_soc_dai_ops structures > that have this property can be declared as const also. > > Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> > --- > sound/soc/fsl/fsl_asrc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c > index 8cfffa7..806d399 100644 > --- a/sound/soc/fsl/fsl_asrc.c > +++ b/sound/soc/fsl/fsl_asrc.c > @@ -542,7 +542,7 @@ static int fsl_asrc_dai_trigger(struct snd_pcm_substream *substream, int cmd, > return 0; > } > > -static struct snd_soc_dai_ops fsl_asrc_dai_ops = { > +static const struct snd_soc_dai_ops fsl_asrc_dai_ops = { > .hw_params = fsl_asrc_dai_hw_params, > .hw_free = fsl_asrc_dai_hw_free, > .trigger = fsl_asrc_dai_trigger, > -- > 2.5.0 > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
Hi Takashi, Quoting Takashi Iwai <tiwai@suse.de>: > Gustavo, > > please stop posting in this style. It's really annoying to see > spontaneously popping-up almost same patch for more than two hours > long. > > If you have a series of the same fix patches, send them as a patch > set in a shot with a thread. git-send-email does it right. > I will do that. Thanks for the suggestion. -- Gustavo A. R. Silva > I don't mind a couple of patches posted separately, but this is over > the limit. > > > thanks, > > Takashi > > On Thu, 13 Jul 2017 09:23:51 +0200, > Gustavo A. R. Silva wrote: >> >> This structure is only stored in the ops field of a snd_soc_dai_driver >> structure. That field is declared const, so snd_soc_dai_ops structures >> that have this property can be declared as const also. >> >> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> >> --- >> sound/soc/fsl/fsl_asrc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c >> index 8cfffa7..806d399 100644 >> --- a/sound/soc/fsl/fsl_asrc.c >> +++ b/sound/soc/fsl/fsl_asrc.c >> @@ -542,7 +542,7 @@ static int fsl_asrc_dai_trigger(struct >> snd_pcm_substream *substream, int cmd, >> return 0; >> } >> >> -static struct snd_soc_dai_ops fsl_asrc_dai_ops = { >> +static const struct snd_soc_dai_ops fsl_asrc_dai_ops = { >> .hw_params = fsl_asrc_dai_hw_params, >> .hw_free = fsl_asrc_dai_hw_free, >> .trigger = fsl_asrc_dai_trigger, >> -- >> 2.5.0 >> >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>
On Thu, Jul 13, 2017 at 09:32:41AM +0200, Takashi Iwai wrote: > please stop posting in this style. It's really annoying to see > spontaneously popping-up almost same patch for more than two hours > long. > If you have a series of the same fix patches, send them as a patch > set in a shot with a thread. git-send-email does it right. > I don't mind a couple of patches posted separately, but this is over > the limit. Or at least just collect them up and send them all at one time even if not as a single thread (you don't want to CC everyone affected by a single patch in the set on everything, that's harder to avoid when sending a series via git, but it can be confusing to get one item in a large patch series without context).
Hi Mark, Quoting Mark Brown <broonie@kernel.org>: > On Thu, Jul 13, 2017 at 09:32:41AM +0200, Takashi Iwai wrote: > >> please stop posting in this style. It's really annoying to see >> spontaneously popping-up almost same patch for more than two hours >> long. > >> If you have a series of the same fix patches, send them as a patch >> set in a shot with a thread. git-send-email does it right. > >> I don't mind a couple of patches posted separately, but this is over >> the limit. > > Or at least just collect them up and send them all at one time even if > not as a single thread (you don't want to CC everyone affected by a > single patch in the set on everything, that's harder to avoid when > sending a series via git, but it can be confusing to get one item in a > large patch series without context). I like this idea better. I will do so next time. :) Thank you -- Gustavo A. R. Silva
On Thu, 2017-07-13 at 10:18 -0500, Gustavo A. R. Silva wrote: > Hi Mark, > > Quoting Mark Brown <broonie@kernel.org>: > > > On Thu, Jul 13, 2017 at 09:32:41AM +0200, Takashi Iwai wrote: > > > > > please stop posting in this style. It's really annoying to see > > > spontaneously popping-up almost same patch for more than two hours > > > long. > > > If you have a series of the same fix patches, send them as a patch > > > set in a shot with a thread. git-send-email does it right. > > > I don't mind a couple of patches posted separately, but this is over > > > the limit. > > > > Or at least just collect them up and send them all at one time even if > > not as a single thread (you don't want to CC everyone affected by a > > single patch in the set on everything, that's harder to avoid when > > sending a series via git, but it can be confusing to get one item in a > > large patch series without context). > > I like this idea better. I will do so next time. :) I don't it's better. It's not that confusing if the 0/n patch cover letter is cc'd to all the appropriate mailing lists and all the [1..n]/n patches are sent with in-reply-to of the cover letter and send to the maintainers and appropriate mailing lists.
Hi Joe, Quoting Joe Perches <joe@perches.com>: > On Thu, 2017-07-13 at 10:18 -0500, Gustavo A. R. Silva wrote: >> Hi Mark, >> >> Quoting Mark Brown <broonie@kernel.org>: >> >> > On Thu, Jul 13, 2017 at 09:32:41AM +0200, Takashi Iwai wrote: >> > >> > > please stop posting in this style. It's really annoying to see >> > > spontaneously popping-up almost same patch for more than two hours >> > > long. >> > > If you have a series of the same fix patches, send them as a patch >> > > set in a shot with a thread. git-send-email does it right. >> > > I don't mind a couple of patches posted separately, but this is over >> > > the limit. >> > >> > Or at least just collect them up and send them all at one time even if >> > not as a single thread (you don't want to CC everyone affected by a >> > single patch in the set on everything, that's harder to avoid when >> > sending a series via git, but it can be confusing to get one item in a >> > large patch series without context). >> >> I like this idea better. I will do so next time. :) > > I don't it's better. > > It's not that confusing if the 0/n patch cover letter is cc'd > to all the appropriate mailing lists and all the [1..n]/n > patches are sent with in-reply-to of the cover letter and > send to the maintainers and appropriate mailing lists. I ended up following your suggestions: https://lkml.org/lkml/2017/7/13/739 (Notice that these are new patches. Not related to the ones I previously sent) Much appreciated Thanks! -- Gustavo A. R. Silva
On Fri, 2017-07-14 at 12:02 +0100, Mark Brown wrote: > On Thu, Jul 13, 2017 at 11:18:11AM -0700, Joe Perches wrote: > > > I don't it's better. > > It's not that confusing if the 0/n patch cover letter is cc'd > > to all the appropriate mailing lists and all the [1..n]/n > > patches are sent with in-reply-to of the cover letter and > > send to the maintainers and appropriate mailing lists. > > With large serieses like Gustavo is sending the CC list can easily hit > the points where mailing lists start blocking it, and the individual > pathces really do need to go to the relevant people so they have sight > of them. I agree and that's what I wrote.
Hi Mark, Joe, On 07/14/2017 06:25 AM, Mark Brown wrote: > On Fri, Jul 14, 2017 at 04:08:21AM -0700, Joe Perches wrote: >> On Fri, 2017-07-14 at 12:02 +0100, Mark Brown wrote: >>> On Thu, Jul 13, 2017 at 11:18:11AM -0700, Joe Perches wrote: >>>> I don't it's better. >>>> It's not that confusing if the 0/n patch cover letter is cc'd >>>> to all the appropriate mailing lists and all the [1..n]/n >>>> patches are sent with in-reply-to of the cover letter and >>>> send to the maintainers and appropriate mailing lists. >>> With large serieses like Gustavo is sending the CC list can easily hit >>> the points where mailing lists start blocking it, and the individual >>> pathces really do need to go to the relevant people so they have sight >>> of them. >> I agree and that's what I wrote. > The set of people who should have sight of the patches is wider than > just the maintainers. I'm running get_maintainer.pl in the following way in order to get all the supporters, maintainers and lists: $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback <file> Thank you
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 8cfffa7..806d399 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -542,7 +542,7 @@ static int fsl_asrc_dai_trigger(struct snd_pcm_substream *substream, int cmd, return 0; } -static struct snd_soc_dai_ops fsl_asrc_dai_ops = { +static const struct snd_soc_dai_ops fsl_asrc_dai_ops = { .hw_params = fsl_asrc_dai_hw_params, .hw_free = fsl_asrc_dai_hw_free, .trigger = fsl_asrc_dai_trigger,
This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> --- sound/soc/fsl/fsl_asrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)