Hi! You are returning IRQ_HANDLED even when you do no handling. That probably will not do harm as long as interrupts are not shared. Is that guaranteed to be true? This leaks ndev; it should free_cand

Hi! I'd preffer you to submit them. Thank you, Pavel

Hi! And these are various minor nits I noticed while reviewing the code. Best regards, Pavel diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetre

Hi! Heh. Array could be avoided altogether; you could check for power of two and then count bits. That would give even shorter code, but I'm not sure about readability. I'd also not mind using usual c

Hi! Should we check for overflows here, too? Best regards, Pavel

Hi! These are likely milliamps and millivolts, right? Elsewhere in device trees microvolts and microamps are used, so that is not too consistent. Is the unit mentioned somewhere / should it be? Best r

Thank you, applied. Best regards, Pavel

Hi! Series looks okay to me. All I could find are whitespaces/comments/documentation issues. I'll proceed with testing; I can apply it if it passes and there are no other comments. Best regards, Pavel

Hi! Thank you. We should do what our users are likely to do... they want stable kernel, and will not update toolchain in middle of product maintainance. [Updating toolchain when starting new product w

Hi! Thank you. I checked the series and only found some details (some of them were fixed later in the series). I believe we can apply it. Reviewed-by: Pavel Machek <pavel@...> Pavel

Hi! So the clocks can have different properties (frequency?), but can only be enabled/disabled together? So we can't handle them as one clock? Best regards, Pavel

Hi! I just want to double check: Are the last two interrupts supposed to be same? Best regards, Pavel

Hi! Some comments below. ... I believe this wanted to return clk? But I'd recommend just directly returning the ERR_PTR(). ... Is " " missing? ... ... Should this be devm_kfree? (And is devm_kfree(NUL

Hi! Looks good to me too. I have series ready due to testing, so I'll push it. Best regards, Pavel

Hi! This one is actually quite interesting. Untrusted users should not normally have shell access on embedded systems, but it highlights topic of coredumps. Default config of coredumping is unsuitable

Hi! I have reviewed patches and they look okay to me. I'll proceed with testing. Do we have suitable board in the test lab / is there plan to add one? Best regards, Pavel

Hi! I don't see anything obviously wrong. Thanks and best regards, Pavel

Hi! Hmm. Fun. 1e98ffea5a8935ec040ab72299e349cb44b8defd may have a clue: This leads to kernel pointer leaks if a match/target is set and then read back to userspace. So that sounds like KASLR workaroun

Hi! There is first release of 5.10-cip-rt kernel available at kernel.org. Trees are available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-5.10.y-cip-rt https://gi

Hi! -cip-rt branch is available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-5.10.y-cip-rt and it passes basic testing we do on gitlab. More testing would be welco