|
[PATCH 4.19.y-cip 4/6] arm64: dts: renesas: r8a774e1: Add USB2.0 phy and host (EHCI/OHCI) device nodes
Hi! Yes, OK with me, thanks. Best regards, Pavel
Hi! Yes, OK with me, thanks. Best regards, Pavel
|
By
Pavel Machek
· #5927
·
|
|
[ANNOUNCE] v4.19.160-cip39-rt17
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! 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
|
By
Pavel Machek
· #5888
·
|
|
[PATCH 4.4.y-cip 0/8] Renesas RZ/G1H add PCIe, SATA and VSP support
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! 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
|
By
Pavel Machek
· #5764
·
|
|
[PATCH 4.19.y-cip 0/6] Renesas RZ/G2H add USB{2,3} support
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 ok to me and passes our testing, I can apply it if there are no other comments. Best regards, Pavel
|
By
Pavel Machek
· #5750
·
|
|
[PATCH 4.19.y-cip 0/5] Add PCIe EP nodes to RZ/G2{EMN}
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! 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
|
By
Pavel Machek
· #5684
·
|
|
[PATCH 4.19.y-cip 4/6] PCI: rcar: Add endpoint mode support
Hi! Thank you. This one is worth backporting, I don't believe we need the other cleanups in -cip. Best regards, Pavel
Hi! Thank you. This one is worth backporting, I don't believe we need the other cleanups in -cip. Best regards, Pavel
|
By
Pavel Machek
· #5672
·
|
|
[PATCH 4.19.y-cip 1/6] PCI: rcar: Move shareable code to a common file
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! 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
|
By
Pavel Machek
· #5671
·
|
|
[PATCH 4.19.y-cip 4/6] PCI: rcar: Add endpoint mode support
Hi! I believe this should go to pm_put. Best regards, Pavel
Hi! I believe this should go to pm_put. Best regards, Pavel
|
By
Pavel Machek
· #5667
·
|
|
[PATCH 4.19.y-cip 1/6] PCI: rcar: Move shareable code to a common file
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! 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
|
By
Pavel Machek
· #5666
·
|
|
[PATCH 4.19.y-cip 0/6] Add PCIe EP driver to Renesas R-Car Gen3 and RZ/G2x
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! 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
|
By
Pavel Machek
· #5665
·
|
|
[RFC PATCH 4.19.y-cip 38/50] PCI: rcar: Move shareable code to a common file
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
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
|
By
Pavel Machek
· #5657
·
|
|
[RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support
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
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
|
By
Pavel Machek
· #5656
·
|
|
[PATCH 4.19.y-cip 00/13] Enhancements to PCIe EPF
Hi! Thanks, applied and pushed out. Best regards, Pavel
Hi! Thanks, applied and pushed out. Best regards, Pavel
|
By
Pavel Machek
· #5654
·
|
|
[RFC PATCH 4.19.y-cip 38/50] PCI: rcar: Move shareable code to a common file
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! 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
|
By
Pavel Machek
· #5635
·
|
|
[RFC PATCH 4.19.y-cip 28/50] PCI: endpoint: Add notification for core init completion
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! 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
|
By
Pavel Machek
· #5634
·
|
|
[RFC PATCH 4.19.y-cip 24/50] PCI: endpoint: Replace spinlock with mutex
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! 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
|
By
Pavel Machek
· #5633
·
|
|
If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x
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! 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
|
By
Pavel Machek
· #5626
·
|
|
[RFC PATCH 4.19.y-cip 24/50] PCI: endpoint: Replace spinlock with mutex
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! 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
|
By
Pavel Machek
· #5625
·
|
|
[PATCH 4.19.y-cip 00/26] Fixes and extension to PCIe EPF
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! Thanks, applied and pushed out. Our automated testing did not find anything wrong (but I don't think that means much). Best regards, Pavel
|
By
Pavel Machek
· #5624
·
|
|
If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x
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
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
|
By
Pavel Machek
· #5594
·
|