[PATCH v2] ALSA: rme9652: use explicitly signed char

[Takashi Iwai]

On Tue, 25 Oct 2022 15:14:54 +0200,
Jason A. Donenfeld wrote:
> 
> On Tue, Oct 25, 2022 at 3:14 PM Takashi Iwai <tiwai at suse.de> wrote:
> >
> > On Tue, 25 Oct 2022 15:11:39 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Tue, 25 Oct 2022 14:54:54 +0200,
> > > Jason A. Donenfeld wrote:
> > > >
> > > > On Tue, Oct 25, 2022 at 2:48 PM Takashi Iwai <tiwai at suse.de> wrote:
> > > > >
> > > > > On Tue, 25 Oct 2022 14:08:29 +0200,
> > > > > Jason A. Donenfeld wrote:
> > > > > >
> > > > > > On Tue, Oct 25, 2022 at 08:21:55AM +0200, Takashi Iwai wrote:
> > > > > > > On Tue, 25 Oct 2022 02:03:13 +0200,
> > > > > > > Jason A. Donenfeld wrote:
> > > > > > > >
> > > > > > > > With char becoming unsigned by default, and with `char` alone being
> > > > > > > > ambiguous and based on architecture, signed chars need to be marked
> > > > > > > > explicitly as such. This fixes warnings like:
> > > > > > > >
> > > > > > > > sound/pci/rme9652/hdsp.c:3953 hdsp_channel_buffer_location() warn: 'hdsp->channel_map[channel]' is unsigned
> > > > > > > > sound/pci/rme9652/hdsp.c:4153 snd_hdsp_channel_info() warn: impossible condition '(hdsp->channel_map[channel] < 0) => (0-255 < 0)'
> > > > > > > > sound/pci/rme9652/rme9652.c:1833 rme9652_channel_buffer_location() warn: 'rme9652->channel_map[channel]' is unsigned
> > > > > > > >
> > > > > > > > Cc: Jaroslav Kysela <perex at perex.cz>
> > > > > > > > Cc: Takashi Iwai <tiwai at suse.com>
> > > > > > > > Cc: alsa-devel at alsa-project.org
> > > > > > > > Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
> > > > > > >
> > > > > > > Applied now.  Thanks!
> > > > > >
> > > > > > Thanks. For this and the other patch, applied for 6.1 or 6.2?
> > > > >
> > > > > I applied for 6.2.  Was it an action that has to be fixed for 6.1?
> > > > > If so, I still can shuffle.
> > > >
> > > > Well, this is code that's broken currently on ARM platforms, for
> > > > example, where char is already unsigned. So it's arguably a fix for
> > > > 6.1.
> > >
> > > Fair enough, I'll apply for 6.1, then.
> >
> > ... and in that case, it deserves for Cc-to-stable, IMO, as it's a fix
> > to be done for older kernels, too.  Then it'd be clearly a 6.1
> > material.
> 
> Fine by me if you want to add that (for this and the other patch).

OK, done.


Takashi