[PATCH 0/2] ALSA: usb-audio: scarlett2: Read all configuration at init time

[Geoffrey D. Bennett]

On Mon, Jun 07, 2021 at 09:23:34AM +0200, Takashi Iwai wrote:
> On Sun, 06 Jun 2021 16:16:44 +0200,
> Geoffrey D. Bennett wrote:
> > 
> > These two patches add support for reading the mixer volumes and mux
> > configuration from the hardware when the driver is initialising.
> > 
> > Previously the ALSA volume controls were initialised to zero and the
> > mux configuration set to a fixed default instead of being initialised
> > to match the hardware state.
> > 
> > The ALSA controls for the Scarlett Gen 2 interfaces should now always
> > be in sync with the hardware. Thanks to Vladimir Sadovnikov for
> > figuring out how to do this.
> > 
> > Takashi, if these pass your review, I believe that they are
> > appropriate for:
> > #Cc: stable at vger.kernel.org
> 
> Well, in general, having a proper fixed value for the initial mixer
> value is the right thing, which is a part of the driver's role.
> Though, in snd-usb-audio, we don't set up the initial values just
> because of laziness; since the topology in USB audio is variable per
> device and often hard to parse correctly, it's difficult to determine
> the suitable initial values, hence we leave untouched.  So, in that
> sense, setting the zero isn't wrong, rather safer, per se.
> 
> However, Scarlett 2 seems to want to be different; it has already some
> initialization code to read the existing configs.  So this change
> sounds more or less acceptable.  But it's questionable whether it's
> really for stable as a "fix".

For the Scarlett devices, the sensible (but not all good)
initialisation options are:

1. Don't load configuration from hardware so the ALSA controls show
default values not in sync with hardware. This is a bad user
experience.

2. Reset hardware configuration to hard-coded defaults so ALSA
controls will be in sync with hardware. This is a really bad user
experience as it is common for the device to be configured using the
proprietary vendor-supplied software and then connected to Linux with
the expectation that the configuration is kept.

3. Load configuration from hardware so ALSA controls are in sync with
hardware. This is a good user experience.

Before these two patches, it was option (1) for the mix/mux controls
and option (3) for the remainder of the controls. I would call this
definitely not sensible behaviour.

I got many queries as to the apparently strange workings of the driver
due to this; certainly many users besides myself considered the
original behaviour a bug so it does fit the rule "It must fix a real
bug that bothers people" from
Documentation/process/stable-kernel-rules.rst

You might consider that it does not meet the "It must be obviously
correct and tested" rule though, and I could agree with that. Perhaps
leave it out from stable for now and revisit later after we get more
test results? Is there a particular amount of time or number of test
success reports that you would consider sufficient?

> In anyway, please fix the bug ktest bot spotted, the missing endian
> conversions and resubmit.

Thanks, I have resubmitted.

Regards,
Geoffrey.