From: "Geoffrey D. Bennett" <g@b4.vu>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH V4] ALSA: usb-audio: Scarlett Gen 2 mixer interface
Date: Wed, 10 Jul 2019 23:36:47 +0930 [thread overview]
Message-ID: <20190710140647.GA29152@b4.vu> (raw)
In-Reply-To: <s5h1ryzi108.wl-tiwai@suse.de>
On Tue, Jul 09, 2019 at 07:14:15PM +0200, Takashi Iwai wrote:
> On Tue, 09 Jul 2019 18:24:30 +0200,
> Geoffrey D. Bennett wrote:
[...]
> > > > +static int scarlett_gen2_mixer_enable;
> > > > +module_param(scarlett_gen2_mixer_enable, int, 0444);
> > > > +MODULE_PARM_DESC(scarlett_gen2_mixer_enable,
> > > > + "Focusrite Scarlett Gen 2 Mixer Driver Enable");
> > >
> > > Do we need this? If disabling the quirk is really required, it should
> > > be implemented rather in a generic option, instead.
> >
> > Actually it would be best to have it disabled by default as I have had
> > two reports from people who tried this mixer driver and it broke audio
> > for them.
>
> Hm, and these have the same USB device ID?
Yes, same device ID. I couldn't see any significant difference between
mine and theirs usbmon trace and lsusb -v output.
[...]
> I guess you can use chip->setup value for the quirk-specific
> configuration as a start. It's a bit hackish but the parameter is
> already there for long time, hence you don't need to add any extra
> stuff for that.
Got it. Have implemented and will resend soon.
In your other email you wrote:
> Canceling the pending work is the right thing for suspend, but we need
> reconsidering the side effect. For example, the device might be
> removed while the machine is in sleep. And the purpose of the
> scheduled work is to sync the config to NVRAM. That is, it should
> have been done before going to suspend. Then we don't have to resume
> the task at resume, too.
>
> That said, the best would be:
> - cancel the pending work, check the return value
> - re-execute the work immediately (delay=0) if the work was canceled
> in the above, and do flush -- or just call the function directly
I agree and have implemented that as well.
Thanks,
Geoffrey.
prev parent reply other threads:[~2019-07-10 14:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-09 13:26 [PATCH V4] ALSA: usb-audio: Scarlett Gen 2 mixer interface Geoffrey D. Bennett
2019-07-09 13:57 ` Takashi Iwai
2019-07-09 16:24 ` Geoffrey D. Bennett
2019-07-09 17:14 ` Takashi Iwai
2019-07-10 14:06 ` Geoffrey D. Bennett [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190710140647.GA29152@b4.vu \
--to=g@b4.vu \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox