| Message ID | 20230116125506.27989-1-peter.ujfalusi@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: SOF: sof-audio: Fixes for widget prepare and unprepare | expand |
On Mon, Jan 16, 2023 at 02:55:03PM +0200, Peter Ujfalusi wrote:
> Mark: can these be picked for 6.2?
Well, patch 2 doesn't apply so not right now...
Applying: ASoC: SOF: sof-audio: Unprepare when swidget->use_count > 0
Using index info to reconstruct a base tree...
M sound/soc/sof/sof-audio.c
Falling back to patching base and 3-way merge...
Auto-merging sound/soc/sof/sof-audio.c
Applying: ASoC: SOF: sof-audio: skip prepare/unprepare if swidget is NULL
Using index info to reconstruct a base tree...
M sound/soc/sof/sof-audio.c
Falling back to patching base and 3-way merge...
Auto-merging sound/soc/sof/sof-audio.c
CONFLICT (content): Merge conflict in sound/soc/sof/sof-audio.c
On 17/01/2023 15:16, Mark Brown wrote: > On Mon, Jan 16, 2023 at 02:55:03PM +0200, Peter Ujfalusi wrote: > >> Mark: can these be picked for 6.2? > > Well, patch 2 doesn't apply so not right now... oh. Let me see what is missing. > > Applying: ASoC: SOF: sof-audio: Unprepare when swidget->use_count > 0 > Using index info to reconstruct a base tree... > M sound/soc/sof/sof-audio.c > Falling back to patching base and 3-way merge... > Auto-merging sound/soc/sof/sof-audio.c > Applying: ASoC: SOF: sof-audio: skip prepare/unprepare if swidget is NULL > Using index info to reconstruct a base tree... > M sound/soc/sof/sof-audio.c > Falling back to patching base and 3-way merge... > Auto-merging sound/soc/sof/sof-audio.c > CONFLICT (content): Merge conflict in sound/soc/sof/sof-audio.c >
On 17/01/2023 15:48, Péter Ujfalusi wrote: > > > On 17/01/2023 15:16, Mark Brown wrote: >> On Mon, Jan 16, 2023 at 02:55:03PM +0200, Peter Ujfalusi wrote: >> >>> Mark: can these be picked for 6.2? >> >> Well, patch 2 doesn't apply so not right now... > > oh. > Let me see what is missing. It is the topology ops optionality stuff. It is in itself a trivial (for my eyes) conflict, but it is a conflict never the less. This is not going to backport cleanly to stable either. What would be the preferred way to handle this (for next, for 6.2 and for 6.1.x)? >> >> Applying: ASoC: SOF: sof-audio: Unprepare when swidget->use_count > 0 >> Using index info to reconstruct a base tree... >> M sound/soc/sof/sof-audio.c >> Falling back to patching base and 3-way merge... >> Auto-merging sound/soc/sof/sof-audio.c >> Applying: ASoC: SOF: sof-audio: skip prepare/unprepare if swidget is NULL >> Using index info to reconstruct a base tree... >> M sound/soc/sof/sof-audio.c >> Falling back to patching base and 3-way merge... >> Auto-merging sound/soc/sof/sof-audio.c >> CONFLICT (content): Merge conflict in sound/soc/sof/sof-audio.c >> >
On Tue, Jan 17, 2023 at 04:05:18PM +0200, Péter Ujfalusi wrote: > It is the topology ops optionality stuff. It is in itself a trivial (for > my eyes) conflict, but it is a conflict never the less. > This is not going to backport cleanly to stable either. > What would be the preferred way to handle this (for next, for 6.2 and > for 6.1.x)? Can you send me a version that applies against for-6.2, if it doesn't backport to stable you can send an explicit backport patch once that becomes an issue. I'm much happier resolving a merge between 6.2 and 6.3 than on initial application.
On 17/01/2023 16:18, Mark Brown wrote: > On Tue, Jan 17, 2023 at 04:05:18PM +0200, Péter Ujfalusi wrote: > >> It is the topology ops optionality stuff. It is in itself a trivial (for >> my eyes) conflict, but it is a conflict never the less. > >> This is not going to backport cleanly to stable either. > >> What would be the preferred way to handle this (for next, for 6.2 and >> for 6.1.x)? > > Can you send me a version that applies against for-6.2, if it > doesn't backport to stable you can send an explicit backport > patch once that becomes an issue. I'm much happier resolving a > merge between 6.2 and 6.3 than on initial application. Sure, just to be sure: v3 which is against 6.2-rc, right? I can assist you in case of a conflict.
On Tue, Jan 17, 2023 at 04:30:47PM +0200, Péter Ujfalusi wrote:
> Sure, just to be sure: v3 which is against 6.2-rc, right?
Yes.
On Mon, 16 Jan 2023 14:55:03 +0200, Peter Ujfalusi wrote: > Changes since v1: > - patches got re-ordered to make them (hopefully) apply on stable when picked > - Added stable tag for 6.1 for the patches > - Added Fixes tag for the swidget NULL check on unprepare > > This series contains one fix (first patch) followed by a nice to have safety > belts in case we get a widget from topology which is not handled by SOF and will > not have corresponding swidget associated with. > > [...] Applied to broonie/sound.git for-next Thanks! [1/3] ASoC: SOF: sof-audio: Unprepare when swidget->use_count > 0 (no commit info) [2/3] ASoC: SOF: sof-audio: skip prepare/unprepare if swidget is NULL commit: 0ad84b11f2f8dd19d62d0b2ffd95ece897e6c3dc [3/3] ASoC: SOF: sof-audio: keep prepare/unprepare widgets in sink path (no commit info) All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark