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

Hi! Is this used somewhere? This adds symbol but noone calls this, and AFAICT it is not used in the rest of the series, either. We can merge it, anyway, I guess, but... explanation would be welcome. B

Hi! Okay, we can't really protect sleeping code with a mutex. But this one is not sleeping. It is mdelay(), not msleep(). And same here. If there's a place which does sleep with the spinlock held, I'd

Hi! Well... I applied this batch. If someone can explain the mutex vs. spinlock thing, then I guess we can do next batch up to 35... OTOH I did not go through those patches in detail, and RFC is good

Hi! Could I get some kind of explanation why this is good idea? As long as code protected by the locks does not sleep, spinlocks are okay... (but they should not need "_irqsave" variants). They are li

Hi! Thanks, applied and pushed out. Our automated testing did not find anything wrong (but I don't think that means much). Best regards, Pavel

Hi! I guess I'd like non-RFC version of patches 1-22 in a series. I believe it makes sense to add 30, 32, 49, 50 to them, as they are simple and fix a bug. Would that work for you? Best regards, Pavel