[00/20] ALSA: Drop superfluous PCM preallocation error checks
mbox series

Message ID 20190205194221.25924-1-tiwai@suse.de
Headers show
Series
  • ALSA: Drop superfluous PCM preallocation error checks
Related show

Message

Takashi Iwai Feb. 5, 2019, 7:42 p.m. UTC
Hi,

this is yet another patchset for trivial cleanups.
At this time, it's about the superfluous error check from
snd_pcm_lib_preallocate_pages() and co.  They always succeed and never
return a failure although many codes do the error check.  The patches
simply remove the error checks and finally change the function to be
void function.

The patches are applied on top of my previous NULL device fix patches,
so not applicable to ASoC tree, I guess.  As all these are trivial,
applying through my tree altogether would be simpler.

So, Mark, please give your ACK if the changes to ASoC drivers are OK.


thanks,

Takashi

===

Takashi Iwai (20):
  ALSA: atmel: Drop superfluous PCM preallocation error checks
  ALSA: parisc: Drop superfluous PCM preallocation error checks
  ALSA: pci: Drop superfluous PCM preallocation error checks
  ALSA: ppc: Drop superfluous PCM preallocation error checks
  ALSA: sh: Drop superfluous PCM preallocation error checks
  ALSA: sparc: Drop superfluous PCM preallocation error checks
  ALSA: spi: Drop superfluous PCM preallocation error checks
  ALSA: usb: Drop superfluous PCM preallocation error checks
  ASoC: amd: Drop superfluous PCM preallocation error checks
  ASoC: dwc: Drop superfluous PCM preallocation error checks
  ASoC: intel: Drop superfluous PCM preallocation error checks
  ASoC: mediatek: Drop superfluous PCM preallocation error checks
  ASoC: meson: Drop superfluous PCM preallocation error checks
  ASoC: sh: Drop superfluous PCM preallocation error checks
  ASoC: stm: Drop superfluous PCM preallocation error checks
  ASoC: txx9: Drop superfluous PCM preallocation error checks
  ASoC: uniphier: Drop superfluous PCM preallocation error checks
  ASoC: xtensa: Drop superfluous PCM preallocation error checks
  ASoC: dmaengine: Drop superfluous PCM preallocation error checks
  ALSA: pcm: Define snd_pcm_lib_preallocate_*() as returning void

 include/sound/pcm.h                                |  8 ++---
 sound/atmel/ac97c.c                                |  4 +--
 sound/core/pcm_memory.c                            | 29 +++++-----------
 sound/parisc/harmony.c                             | 10 ++----
 sound/pci/ad1889.c                                 |  7 +---
 sound/pci/aw2/aw2-alsa.c                           | 40 +++++++---------------
 sound/pci/bt87x.c                                  | 10 +++---
 sound/pci/ca0106/ca0106_main.c                     | 16 ++++-----
 sound/pci/echoaudio/echoaudio.c                    | 16 ++++-----
 sound/pci/emu10k1/emupcm.c                         | 22 ++++++++----
 sound/pci/emu10k1/p16v.c                           | 17 ++++-----
 sound/pci/lx6464es/lx6464es.c                      |  8 ++---
 sound/pci/rme9652/hdspm.c                          | 20 +++--------
 sound/pci/via82xx_modem.c                          |  8 ++---
 sound/ppc/snd_ps3.c                                |  6 +---
 sound/sh/aica.c                                    | 14 ++++----
 sound/soc/amd/acp-pcm-dma.c                        | 26 ++++++--------
 sound/soc/amd/raven/acp3x-pcm-dma.c                |  9 +++--
 sound/soc/dwc/dwc-pcm.c                            |  3 +-
 sound/soc/intel/atom/sst-mfld-platform-pcm.c       |  9 ++---
 sound/soc/intel/baytrail/sst-baytrail-pcm.c        | 15 +++-----
 sound/soc/intel/haswell/sst-haswell-pcm.c          | 10 ++----
 sound/soc/intel/skylake/skl-pcm.c                  |  9 ++---
 .../soc/mediatek/common/mtk-afe-platform-driver.c  |  6 ++--
 sound/soc/meson/axg-fifo.c                         |  7 ++--
 sound/soc/sh/fsi.c                                 |  3 +-
 sound/soc/sh/rcar/core.c                           |  5 +--
 sound/soc/sh/siu_pcm.c                             | 13 +------
 sound/soc/soc-generic-dmaengine-pcm.c              |  5 +--
 sound/soc/stm/stm32_adfsdm.c                       |  5 +--
 sound/soc/txx9/txx9aclc.c                          |  4 ++-
 sound/soc/uniphier/aio-dma.c                       |  3 +-
 sound/soc/xtensa/xtfpga-i2s.c                      |  6 ++--
 sound/sparc/dbri.c                                 |  9 ++---
 sound/spi/at73c213.c                               |  2 +-
 sound/usb/usx2y/usbusx2yaudio.c                    | 21 ++++++------
 sound/usb/usx2y/usx2yhwdeppcm.c                    | 19 +++++-----
 37 files changed, 157 insertions(+), 267 deletions(-)

Comments

Jaroslav Kysela Feb. 6, 2019, 9:07 a.m. UTC | #1
Dne 5.2.2019 v 20:42 Takashi Iwai napsal(a):
> Hi,
> 
> this is yet another patchset for trivial cleanups.
> At this time, it's about the superfluous error check from
> snd_pcm_lib_preallocate_pages() and co.  They always succeed and never
> return a failure although many codes do the error check.  The patches
> simply remove the error checks and finally change the function to be
> void function.
> 
> The patches are applied on top of my previous NULL device fix patches,
> so not applicable to ASoC tree, I guess.  As all these are trivial,
> applying through my tree altogether would be simpler.
> 
> So, Mark, please give your ACK if the changes to ASoC drivers are OK.

With all respects, do we really need to split those elementary changes
to single patches inside the sound tree? I would really prefer to have
this inside one patch or maybe few patches (core/pci/asoc/others). Just
my two cents.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>

					Jaroslav
Takashi Iwai Feb. 6, 2019, 9:27 a.m. UTC | #2
On Wed, 06 Feb 2019 10:07:21 +0100,
Jaroslav Kysela wrote:
> 
> Dne 5.2.2019 v 20:42 Takashi Iwai napsal(a):
> > Hi,
> > 
> > this is yet another patchset for trivial cleanups.
> > At this time, it's about the superfluous error check from
> > snd_pcm_lib_preallocate_pages() and co.  They always succeed and never
> > return a failure although many codes do the error check.  The patches
> > simply remove the error checks and finally change the function to be
> > void function.
> > 
> > The patches are applied on top of my previous NULL device fix patches,
> > so not applicable to ASoC tree, I guess.  As all these are trivial,
> > applying through my tree altogether would be simpler.
> > 
> > So, Mark, please give your ACK if the changes to ASoC drivers are OK.
> 
> With all respects, do we really need to split those elementary changes
> to single patches inside the sound tree? I would really prefer to have
> this inside one patch or maybe few patches (core/pci/asoc/others). Just
> my two cents.
> 
> Reviewed-by: Jaroslav Kysela <perex@perex.cz>

There are both good and bad sides by this kind of fine splits.
A good side is that each reviewer can give ack for particular changes,
and it's easier to backport to older kernels.  A bad side is that it
results in more commits, and the relation between all relevant changes
isn't clear from each single commit.

I split at this time, especially about ASoC, since ASoC codes are
managed by more people than other parts in the sound tree.  But, yeah,
this could be a single patch, too.


thanks,

Takashi
Mark Brown Feb. 6, 2019, 2:50 p.m. UTC | #3
On Wed, Feb 06, 2019 at 10:07:21AM +0100, Jaroslav Kysela wrote:
> Dne 5.2.2019 v 20:42 Takashi Iwai napsal(a):

> > So, Mark, please give your ACK if the changes to ASoC drivers are OK.

Acked-by: Mark Brown <broonie@kernel.org>

> With all respects, do we really need to split those elementary changes
> to single patches inside the sound tree? I would really prefer to have
> this inside one patch or maybe few patches (core/pci/asoc/others). Just
> my two cents.

FWIW it does mean that life is easier for people doing backports when
things are split up as there's less chance that some file that wasn't
added in the kernel version you were interested in was touched by the
patch.
Jaroslav Kysela Feb. 6, 2019, 3:35 p.m. UTC | #4
Dne 6.2.2019 v 15:50 Mark Brown napsal(a):

>> With all respects, do we really need to split those elementary changes
>> to single patches inside the sound tree? I would really prefer to have
>> this inside one patch or maybe few patches (core/pci/asoc/others). Just
>> my two cents.
> 
> FWIW it does mean that life is easier for people doing backports when
> things are split up as there's less chance that some file that wasn't
> added in the kernel version you were interested in was touched by the
> patch.

It's only minor thing for the backports. The proper import procedure
covers this. I don't like to have separate patches for
single-line/single-file changes and this change set belongs to this.

				Jaroslav