On Fri, 25 Jun 2021 04:11:42 +0200, Geoffrey D. Bennett wrote: > > On Thu, Jun 24, 2021 at 07:40:53PM +0200, Takashi Iwai wrote: > > On Thu, 24 Jun 2021 17:47:39 +0200, > > Geoffrey D. Bennett wrote: > > > > > > On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote: > > > [...] > > > > OK, now all patches have been merged. > > > > > > Thanks! > > > > > > I would next like to consider how we can enable this mixer driver by > > > default. I originally added the device_setup=1 gate because there were > > > reports of the driver making the interface hang. These were all traced > > > back to the problem which was resolved with the commit "Fix device > > > hang with ehci-pci". That commit fixed the issue for those who had > > > reported it and since then there have been no more reports that the > > > mixer driver causes any issues. > > > > > > Simply removing the device_setup=1 check would leave users with no way > > > to disable the driver in case that turns out to be necessary for some > > > reason though, so I don't think that's a good idea. > > > > They can blacklist snd-usb-audio, either the module itself (if it's > > the only device), or with enable option of snd-usb-audio module, if > > there are multiple devices bound with the driver. > > But wouldn't that disable audio for the device entirely? I am talking > about only disabling the mixer part of the driver (the code in > mixer_scarlett_gen2.c) which uses the proprietary USB messages. So > that if there is some unseen so-far bug the user can revert to > previous behaviour of audio working but no proprietary controls. Even if you split the mixer part to a module, it'll be always bound with the main snd-usb-audio due to dependency, so you cannot blacklist it. At most, you may add a module option for that, but it's almost equivalent to introduce a new option to snd-usb-audio such as snd_usb_audio.scarlett2_mixer=off A conditional build would make sense for the compilation size, but it's not about the feature to turn on/off functionality on the fly. Takashi