Hi! I am not sure if I'll be able to make it to the meeting. My work last week: reviews of patches for 4.19.131 and 4.19.132. I took a look at "PM / OPP v2 & cpufreq backports part 2" and will have so

Hi! Newest 4.19-rt kernel is currently v4.19.127-rt54. That's not good match for us, as -cip kernels are v4.19.128-cip28 and v4.19.130-cip29. I could do kernel based on v4.19.127-rt54 and v4.19.124-ci

Hi! Not sure if I'll be able to make it today. From last meeting, I have been reviewing patches for 4.19.129 and 4.19.130. Best regards, Pavel

Hi! I noticed that android drivers in staging are enabled by moxa_eds: CONFIG_ION=y CONFIG_ION_SYSTEM_HEAP=y CONFIG_ION_CARVEOUT_HEAP=y CONFIG_ION_CHUNK_HEAP=y CONFIG_ION_CMA_HEAP=y I normally don't r

Hi! Thanks! I have applied the series, will run some basic tests and push the results if they work okay. Best regards, Pavel

Hi! Aha, ok, having more boards like this certainly explains the benefits. Thanks for an explanation. I have applied patches, I'll run some basic tests and push the results. Best regards, Pavel

Hi! ... OPP subsystem is shared with other boards, so I believe we should be careful here. 01fb4d3c39d3 introduces a bug and fd8d8e63467c fixes it. I believe it would be better to merge them together.

Hi! There's nothing obviously wrong with the patches (and they won't break anything but am335x-moxa platform, so they are low risk). On the other hand, I don't see any obvious benefit. Whether we use

Hi! I get quite a lot of complains here, if I try to apply patch automatically using git-am. Applying: ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 .git/rebase-apply/patch:17: trailing whit

Hi! It is possible to drop the patch and force push before new commits are added on top. It is also possible to queue a revert at any later time. OTOH if the patch is not wrong, just needs another pat

Hi! So this is relatively simple, as it only affects Moxa code. And I see nothing wrong there. I'll apply it if there are no other comments. Best regards, Pavel

Hi! Thanks, applied, I'll run tests on it and push the result. Best regards, Pavel

Hi! This is fixed in the next patch. But I wonder if we should merge them into one for -cip... Unlike mainline, we already know about the bug. No need to prepare trap for people doing bisect. Best reg

Hi! This is not right. If in !dev_opp->prop_name, it will pass uninitialized buffer to of_find_property. Best regards, Pavel

Hi! That's really quite "interesting" design. I wondered if devicetree people are okay with that. But, interestingly, their review tag is missing...? As this is mainline, I don't think we need to do a

Hi! I don't see anything wrong, either. SIMPLE_PANEL is not enabled in 4.4.y-cip/arm/renesas_shmobile_defconfig , and it seems to be driver relevant to this panel. Best regards, Pavel

Hi! I did a bit of research on CVE-2020-10742. Unfortunately, RedHat is a bad player here, and bug reports are partly hidden from public. https://bugzilla.redhat.com/show_bug.cgi?id=1824270 https://bu

Hi! I don't see anything wrong with the patch. OTOH I'd expect to see this in a series with the code actually using these defines. Is there a reason to merge it on its own? Best regards, Pavel

Hi! Yes, IIRC. Ok, good to know. So... there are few reasons why it is important to know what is in use or not: 1) If we see patch in stable, how much effort should be spent reviewing it? 2) If we see

Hi! v4.4.225-cip45-rt29 should be available at kernel.org. Trees are available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-cip-rt https://git.kernel.org/pub