Hi! First, thanks for reaching us over email. Yup, those issues seem to be real. We'd preffer not to take fixes that are not upstream, and this is not too severe bug. (Should the skb be freed in the e

#cip

Hi! New realtime trees 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.19.y-cip-rt https://git.kernel.org/pub

Hi! I started updating -rt to new versions, but it looks like v4.19.206-cip57 is not available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git . Can you recheck you did the git pu

It still fails. https://lava.ciplatform.org/scheduler/job/148674. I'll retry one more time, but this looks like permanent problem. Best regards, Pavel

Hi! Something went wrong on siemens board... I'll try to resubmit the job. https://lava.ciplatform.org/scheduler/job/148648#L266 Best regards, Pavel InfrastructureError: The Infrastructure is not work

Hi! New realtime trees 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/

Hi! Yes, OK with me, thanks. Best regards, Pavel

Hi! New realtime trees 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.19.y-cip-rt https://git.kernel.org/pub

Hi! I don't see any problems with the series, and it passed basic testing, so I can apply it if there are no other comments. Best regards, Pavel

Hi! Series looks ok to me and passes our testing, I can apply it if there are no other comments. Best regards, Pavel

Hi! Series looks good to me. I see that the nodes are stil marked as "disabled"... I guess devboards are not plugged into into PCIe hosts for the testing. Anyway, it would be good to know if the merge

Hi! Thank you. This one is worth backporting, I don't believe we need the other cleanups in -cip. Best regards, Pavel

Hi! Yes, but you'd need to call it in a loop. It will be effective if done inside udelay(), but not like this. Best regards, Pavel

Hi! I believe this should go to pm_put. Best regards, Pavel

Hi! I have merged the patches, but this should be cleaned up IMO... Kind of fun. We test the PHYRDY, not ready, so we wait (now phy becomes ready).. and we time out. What about while (1) { if (rcar_pc

Hi! Thanks, patches look good and CIP testing did not find any problems, so I applied them and pushed out. I'll have some additional comments, but those can be solved post-merge. Best regards, Pavel

Hi! I'm not 100% sure what you are proposing, but let's do that. We should not end with two copies of the identical code in -cip, right? I believe we are ready for rest of the patches. Best regards, P

I mean "fix it upstream first" is good strategy here. This is just cosmetics. You don't even have to backport it.. just fix it upstream. Best regards, Pavel

Hi! Thanks, applied and pushed out. Best regards, Pavel

Hi! Whoa. So... original patch _moved_ shared code to new place. This version creates another copy of shared code, probably subtly different from the other one. Is that good idea? Won't two copies cau