Message ID | 20201012130845.816462076C@mail.kernel.org (mailing list archive) |
---|---|
State | Accepted |
Commit | f401b2c9931a70317b6ac0d3e6020adc3a404cc0 |
Headers | show |
Series | [GIT,PULL] ASoC updates for v5.10 | expand |
Dne 12. 10. 20 v 15:08 Mark Brown napsal(a): > The following changes since commit 549738f15da0e5a00275977623be199fbbf7df50: > > Linux 5.9-rc8 (2020-10-04 16:04:34 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-v5.10 > > for you to fetch changes up to c890e30b069a2792a5a34e8510a7a437dd6f5b3d: > > Merge remote-tracking branch 'asoc/for-5.10' into asoc-next (2020-10-09 15:42:31 +0100) > > ---------------------------------------------------------------- > ASoC: Updates for v5.10 I miss the SOF cleanups here: https://lore.kernel.org/alsa-devel/20200930152026.3902186-1-kai.vehmanen@linux.intel.com/ Thanks, Jaroslav
On Mon, Oct 12, 2020 at 03:16:18PM +0200, Jaroslav Kysela wrote: > Dne 12. 10. 20 v 15:08 Mark Brown napsal(a): > > ASoC: Updates for v5.10 > I miss the SOF cleanups here: > https://lore.kernel.org/alsa-devel/20200930152026.3902186-1-kai.vehmanen@linux.intel.com/ Yes, looks like they didn't make it. Nothing looks particularly urgent in there.
On Mon, 12 Oct 2020 15:08:28 +0200, Mark Brown wrote: > > The following changes since commit 549738f15da0e5a00275977623be199fbbf7df50: > > Linux 5.9-rc8 (2020-10-04 16:04:34 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-v5.10 > > for you to fetch changes up to c890e30b069a2792a5a34e8510a7a437dd6f5b3d: > > Merge remote-tracking branch 'asoc/for-5.10' into asoc-next (2020-10-09 15:42:31 +0100) > > ---------------------------------------------------------------- > ASoC: Updates for v5.10 > > Not a huge amount going on in the core for ASoC this time but quite a > lot of driver activity, especially for the Intel platforms: > > - Replacement of the DSP driver for some older x86 systems with a new > one which was written with closer reference to the DSP firmware so > should hopefully be more robust and maintainable. > - A big batch of static checker and other fixes for the rest of the x86 > DSP drivers. > - Cleanup of the error unwinding code from Morimoto-san, hopefully > making it more robust. > - Helpers for parsing auxiluary devices from the device tree from > Stephan Gerhold. > - New support for AllWinner A64, Cirrus Logic CS4234, Mediatek MT6359 > Microchip S/PDIF TX and RX controllers, Realtek RT1015P, and Texas > Instruments J721E, TAS2110, TAS2564 and TAS2764 Thanks, pulled now. Takashi
Dne 12. 10. 20 v 15:28 Mark Brown napsal(a): > On Mon, Oct 12, 2020 at 03:16:18PM +0200, Jaroslav Kysela wrote: >> Dne 12. 10. 20 v 15:08 Mark Brown napsal(a): > >>> ASoC: Updates for v5.10 > >> I miss the SOF cleanups here: > >> https://lore.kernel.org/alsa-devel/20200930152026.3902186-1-kai.vehmanen@linux.intel.com/ > > Yes, looks like they didn't make it. Nothing looks particularly urgent > in there. Another week and this is ignored. At least, I cannot find this simple patch set in your for-5.10 tree. I don't care about the cosmetic code fixes, but the last warning suppression can reduce the maintainer / user confusions ("ASoC: SOF: loader: handle all SOF_IPC_EXT types"). Jaroslav
Hi, On Wed, 21 Oct 2020, Jaroslav Kysela wrote: > Another week and this is ignored. At least, I cannot find this simple patch > set in your for-5.10 tree. I don't care about the cosmetic code fixes, but the > last warning suppression can reduce the maintainer / user confusions ("ASoC: > SOF: loader: handle all SOF_IPC_EXT types"). maybe bundling the warning suppression to the same patchset was not the best of ideas. Jaroslav is correct the warnings can unfortunately create real confusion as this is on a code path we run on every rt-resume, and if you happen to have a system with FW that has some custom IPC types, you'll get this warning constantly in dmesg. We did a cleanup of SOF dmesg noise in 5.8, but unfortunately this one slipped through. Br, Kai
On Wed, Oct 21, 2020 at 10:23:18AM +0200, Jaroslav Kysela wrote: > Dne 12. 10. 20 v 15:28 Mark Brown napsal(a): > > Yes, looks like they didn't make it. Nothing looks particularly urgent > > in there. > Another week and this is ignored. At least, I cannot find this simple patch > set in your for-5.10 tree. I don't care about the cosmetic code fixes, but the As you have identified that series looks like minor code cleanups, I am not going to apply minor code cleanups as bug fixes, you should be aware that during the merge window only bug fixes go in and therefore have no expectation that anything else will be applied during that time. Your previous mail was sent after the merge window opened. > last warning suppression can reduce the maintainer / user confusions ("ASoC: > SOF: loader: handle all SOF_IPC_EXT types"). This is the first time you or anyone else has mentioned this as being differentiated from anything else in the series, had someone done so perhaps it might have been reasonable to have an expectation that it might be reasonable to expect that something could happen sooner.
On Wed, Oct 21, 2020 at 12:26:22PM +0300, Kai Vehmanen wrote: > maybe bundling the warning suppression to the same patchset was not the > best of ideas. Jaroslav is correct the warnings can unfortunately create > real confusion as this is on a code path we run on every rt-resume, and if > you happen to have a system with FW that has some custom IPC types, you'll > get this warning constantly in dmesg. No, and especially putting it at the end of the series - presumably it has dependencies on the rest of it? You should always put fixes first in a series.
Hey, On Wed, 21 Oct 2020, Mark Brown wrote: > On Wed, Oct 21, 2020 at 12:26:22PM +0300, Kai Vehmanen wrote: >> maybe bundling the warning suppression to the same patchset was not the >> best of ideas. Jaroslav is correct the warnings can unfortunately create > > No, and especially putting it at the end of the series - presumably it > has dependencies on the rest of it? You should always put fixes first > in a series. I hadn't realized the warning gets triggered so commonly when sending the series out, so it was just a bad call to have this in the same series with coding-style fixes only. The warning patch has no strict dependency to the others. I know series with no hard dependencies are frowned upon, so this a double-fault on my part. I can send the fix patch separately and save the rest of the series for 5.11 window. Br, Kai
On Wed, Oct 21, 2020 at 06:11:07PM +0300, Kai Vehmanen wrote: > I can send the fix patch separately and save the rest of the series for > 5.11 window. I've already got the series queued to try for v5.11, it would require a lot less faffing on my part if you resent that one patch to get it in as a fix though.