Hi! If we are doing this kind of cleanups... I'd move "len" declaration inside the if, too... Not that it matters much. Best regards, Pavel Signed-off-by: Pavel Machek (CIP) <pavel@...> diff --git

Hi! This puts function definition directly into header file; I don't think that will work when multiple files include it. Adding "static inline" is the usual solution for this. Best regards, Pavel

Hi! I went through this and "Add missing rpc-if clock on RZ/G2{E,M,N} SoC" series, and they look okay to me. I can apply them if there are no other comments. Best regards, Pavel

Hi! I applied your recent patches, and pushed the result out: 95fea62f9f4534c3b963acd44f03754d9fe0829a dt-bindings: thermal: rcar-gen3-thermal: Add r8a774e1 support 848657b4ebe54338acc6d8f1d6c37bff0b5

Hi! This and dt-bindings: PCI: rcar: Add missing RZ/G2 SoC's series looks okay to me. I can apply it if there are no other comments. Best regards, Pavel

Hi! Looks good to me. I can apply it to 4.19-cip if there are no other comments. Best regards, Pavel

Hi! Looks good to me. I can apply it to 4.19-cip if there are no other comments. Best regards, Pavel

Hi! Starting some testing would be good; defconfigs would work. We'll need to notify cip-members, but I assume actual replies from members will need some time. They should be, thanks to our upstream-f

Hi! > > 100Cloning linux-stable-rc > > 101fatal: repository '.' does not exist > > 102fatal: repository '.' does not exist > > 103fatal: repository '.' does not exist > > 106 > > Uploading artifacts..

Hi! I have started reviewing all three series "at the same time", always reviewing the oldest patch... because that's what we'll need to do in future. Here are my results so far. What each line means

Hi! It seems -stable-rc tests are now failing completely in "cloning repository" phase: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/934209886 Skipping Git submodules setup 99

Hi! I see why this is good idea for mainline, but do we need it in 4.4? I guess it makes patch backporting easier, but maybe that can wait for such backport? I believe this is wrong. Should be "conver

Hi! In case I don't make it to the meeting: I have reviewed patches targetted for 4.19.163 and .164. I am preparing scripts to make reviews easier once we add 5.10 kernel to the list. Best regards, Pa

Hi! I still see them: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/225881953 2 builds failed, for example: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/

Hi! No problem :-). This looks like USB id's. (1d6b: is Linux foundation, common in USB hubs). So I believe this tells us that someone plugged in device 0424:ec00 -- ID 0424:ec00 Standard Microsystems

Hello, bot. Can you speak english? I'm not sure where you see failure here, plus I find it hard to believe that we have broken anything between v4.4.243-cip51-10-gd7466739b72e9 and v4.4.243-cip51-21-g

Hi! Hello, bot. Which human is your master? Something indeed goes wrong there, but it does not look like kernel failure: 04:25:41.680063 / # mount /dev/disk/by-uuid/1d696e5c-20bb-44a2-9bc5-bed2a2143e3

Hi! Series looks good to me, I can apply it if there are no other comments. Best regards, Pavel

Hi! Just a minor nitpicks; no need to fix them for merge but maybe consideration for mainline? If memory allocations fail here, would it be better to fail the probe? Would it be better to return error

Hi! Aha, MSIOF1 not being on dev board explains things. Applied and pushed out. Thanks and best regards, Pavel