00:05 <abhinav__> bamse Hi, looks like all changes in https://patchwork.freedesktop.org/series/101966/ have now been acked . Can you please help us to test this on your sc8180x setup and provide your Tested-by as we spoke earlier? Also, please include https://patchwork.freedesktop.org/series/103017/ in your tree as well for a potential deadlock .... Thanks a lot in

00:05 <abhinav__> advance

00:29 <calebccff> why does the sdm845 sound driver hardcode some codec specific calls... https://github.com/torvalds/linux/blob/master/sound/soc/qcom/sdm845.c#L187

00:30 <calebccff> some Chromebook stuff that got upstreamed I guess? https://lore.kernel.org/all/20181128090037.257359-1-cychiang@chromium.org/

00:30 <calebccff> for the Cheza prototype perhaps

00:30 <calebccff> this doesn't seem right at all https://lore.kernel.org/all/20181128090037.257359-5-cychiang@chromium.org/

08:08 <Mis012[m]> >add board specific ...

08:08 <Mis012[m]> >hardcode

08:08 <Mis012[m]> how did that get merged again?

15:40 <DavidHeidelberg[m]> Mis012: guess because no-one objected ;) you could review these patches too

16:03 <bamse> more importantly, if we know better today, it's worth trying to fix it

16:33 <Mis012[m]> bamse: hm, so I just confirmed it... if I go UEFI->u-boot->Linux with maxcpus=8, it boots fine

16:33 <Mis012[m]> with maxcpus=1, it reboots unless I comment out those four clocks

16:33 <Mis012[m]> in rpmcc

16:34 <Mis012[m]> weird that konradybcio doesn't seem to have the same behavior on a different msm8998 though...

16:34 <Mis012[m]> I mean, I didn't test straight UEFI->Linux yet

16:35 <Mis012[m]> but it would seem that all I need in order to sidestep this weird bug is to figure out by what magic UEFI makes booting up the BIG cluster work