ASoC: fsl_asrc: constify snd_soc_dai_ops structure

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 <[email protected]>

---
 sound/soc/fsl/fsl_asrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/soc/fsl/fsl_asrc.c +1 -1

index 8cfffa7..806d399 100644
@@ -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,

Signature · 6 lines

2.5.0

_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

Quoted 32 lines · Gustavo A. R. Silva

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 <[email protected]>

---
 sound/soc/fsl/fsl_asrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/soc/fsl/fsl_asrc.c +1 -1

index 8cfffa7..806d399 100644
@@ -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
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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.

Quoted 7 lines

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.

Quoted 2 lines

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 <[email protected]>:

Quoted 10 lines · Takashi Iwai

Quoted 8 lines

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.

Quoted 5 lines

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. :)

Quoted 20 lines

Hi Mark,

Quoting Mark Brown <[email protected]>:

Quoted 15 lines · Takashi Iwai

Quoted 8 lines

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).

Quoted 1 line

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 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.

Quoted 5 lines · Joe Perches

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.

Quoted 7 lines · Mark Brown

Quoted 5 lines · Joe Perches

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.

Quoted 4 lines

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.

Quoted 7 lines · Joe Perches

Quoted 6 lines · Mark Brown

Quoted 5 lines · Joe Perches

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.

Quoted 5 lines

Quoted 4 lines

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.

From 29a22ebfa4c44bf96b3d00d90b5e3b8128d8a162 Mon Sep 17 00:00:00 2001