03:10 <bamse> aka_[m]: did i screw something up? or you just mean that i sent a lot of thank-you emails today?

06:09 <aka_[m]> bamse: I'm just surprised you applied rprocs series I sent 2h before pull without any reviews on it

06:09 <aka_[m]> *dt rprocs

10:57 <krzk> pull? There was no pull from bamse yet.

11:00 <krzk> aka_[m]: btw, your patches had incorrect subject prefix. Stick to the subsystem style.

11:02 <aka_[m]> i know

11:03 <aka_[m]> noticed bit late

11:03 <aka_[m]> arm64: boot: dts :qcom: msm8953: should be

11:03 <aka_[m]> * arm64: boot: dts: qcom: msm8953: should be

11:04 <aka_[m]> s/boot/dts/, s/dts ://

11:05 <aka_[m]> <krzk> "pull? There was no pull from..." <- https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-next

11:06 <krzk> aka_[m]: you pointed to his repo, but there is no pull.

11:06 <krzk> You can check on soc mailing list - no pull...

11:07 <aka_[m]> any idea if i should resend with changed title?

11:07 <aka_[m]> i made this same mistake in series previous

11:07 <aka_[m]> i need to add some info to my template file >_>

11:08 <aka_[m]> so i won't make same mistake once again

11:09 <krzk> no need to resend, was already applied

11:10 <aka_[m]> sadly Konrad haven't pointed this before i sent it out and rather told me to send away and await responds there

11:10 <aka_[m]> nothing i can change

11:10 <aka_[m]> sorry.

11:10 <aka_[m]> i hope i will learn from this mistake

19:26 <aka_[m]> Marijn: are you aware of such things happening on 6.3?... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/URABMxMgSNsjGJlCyBCaqHIK>)

19:26 <aka_[m]> on 8976

20:07 <aka_[m]> lumag: there is probably something wrong with that preemption patch i sent

20:07 <aka_[m]> testing 6.3 now with it applied yet it still hangcheck

20:08 <lumag> aka_[m], probably there is something more to add for that platform.

20:08 <aka_[m]> it shouldnt mention ring2

20:08 <aka_[m]> or should it?

20:09 <aka_[m]> no idea what went broke

20:11 <lumag> aka_[m], you patch is not a part of 6.3 cycle. It will be merged into 6.4 and then backported to 6.3.x stable series

20:11 <lumag> so, nothing is wrong

20:11 <aka_[m]> i added it by cherry picking

20:11 <aka_[m]> maybe modules somehow didnt update

20:12 <lumag> At least I don't have issues with outdated modules

20:13 <lumag> so, could you please recheck everything is up to date?

20:13 <lumag> Because your patch fixes nr_rings to 1, so there should be just ring0

20:23 <aka_[m]> > * <@_oftc_lumag:matrix.org> prefers monolithic kernels

20:23 <aka_[m]> me too, but there is always issue with firmware loading if you build monolithic and it starts loading before rootfs is mounted

20:34 <aka_[m]> still somehow doesnt work

20:34 <aka_[m]> now im tired

20:34 <aka_[m]> it was working fine on newer i think

20:43 <aka_[m]> lumag: clean flash ends in error no longer showing

20:43 <aka_[m]> tho plasma is dead

20:43 <aka_[m]> after unlocking

20:46 <aka_[m]> it still does show...

20:50 <aka_[m]> lumag: the only chance is that adreno_gpu does not yet contain revision number data so it goes into fail

20:50 <aka_[m]> need to check tomorrow

20:51 <aka_[m]> need to print revn to check what is inside it before i check it

20:51 <aka_[m]> maybe we have to hardcode shit in adreno_gpu_init instead

20:53 <aka_[m]> i might need to check on pdev data instead of adreno_gpu

20:55 <aka_[m]> lumag: it would be better for now to skip this patch, i will test tomorrow whats exactly wrong with it

21:21 <aka_[m]> indeed it was checking before it was initalized

21:44 <lumag> aka_[m], then we'll wait for the fix ;-)

21:44 <aka_[m]> lumag: it so happens i had Tooniis disabler before

21:45 <aka_[m]> and i havent noticed it

21:45 <aka_[m]> somewhere else in code

21:45 <aka_[m]> thats so shame compiler didnt say about using on uninitialized variable

22:19 <aka_[m]> The only way if I want to override it there is to idk, fetch revn from platform_data and then compare it vs 510 bit I don't think I can compare uint32_t with number just like that :/