On Thu, 10 Aug 2023 00:57:22 +0200, Takashi Sakamoto wrote:
On Wed, Aug 09, 2023 at 04:39:55PM +0200, Takashi Iwai wrote:
On Wed, 09 Aug 2023 16:18:54 +0200, Takashi Sakamoto wrote:
Hi,
On Wed, Aug 09, 2023 at 04:03:00PM +0200, Takashi Iwai wrote:
On Wed, 09 Aug 2023 02:26:31 +0200, Takashi Sakamoto wrote:
This patch is for kernel prepatch v6.5.
Why it must be included in 6.5? This sounds more like a new implementation, rather than an urgent but fix that is needed for rc.
Thanks for your notice to the patch. Indeed, it is neither urgent nor bug fix. It is a kind of 'adding support for new device with slight change', like adding new entries in mod device table. The overall change and new lines are quite typical in ALSA dice driver, like TC Electronic devices in 'sound/firewire/dice/dice-tcelectronic.c'. Things are prepared and not brand-new.
Precisely, current ALSA dice driver supports the Weiss models already, while the functionality is limited that the part of sampling transfer frequencies are available as the initial author said (e.g. when 44.1/48.0 kHz are available, 88.2/96.0 kHz are not, vise versa). The patch extends the functionality by hard-coding stream formats following to the design of ALSA dice driver.
Of cource, I don't mind postponing the patch to v6.6 kernel, but in my point of view, it is worth to v6.5 since users got benefits from the code which is not so novel.
OK, then I'd rather put it to 6.6. If it were for rc2, I could take it. But it's already in a second half turn, and I'd rather like to limit the changes for later rcs.
It sounds reasonable. So should I post the patch on your for-next branch?
No need for that, the patch itself is applicable cleanly. I just need to drop the commit log line indicating 6.5-rc.
thanks,
Takashi