From: Zumeng Chen <zumeng.chen@...> commit 248aefdcc3a7e0cfbd014946b4dead63e750e71b upstream. call of_node_put to release the refcount of np. Signed-off-by: Zumeng Chen

From: Viresh Kumar <viresh.kumar@...> V2 bindings have better support for clock-latency and voltage-tolerance and doesn't need special care. To use callbacks,

Hi everyone, This is the final part of MOXA's PM / OPP / ti-cpufreq backport series. Part 2, which consisted of OPP / cpufreq-dt cleanups, is abandoned in favor of directly backporting the ti-cpufreq

From: Dave Gerlach <d-gerlach@...> commit e13cf046cd70894393a1085ca39da7ef751353fb upstream. Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families= , have different OPPs

From: Dave Gerlach <d-gerlach@...> commit 0764c604c8128f17fd740ff8b1701d0a1301eb7e upstream. Rename _of_get_opp_desc_node to dev_pm_opp_of_get_opp_desc_node and add i= t to include/linux/pm_opp.h

From: Dave Gerlach <d-gerlach@...> commit 953a0f18337406ab041252ce5a62db5d173bee5f upstream. Add the device tree bindings document for the TI CPUFreq/OPP driver on AM33xx, AM43xx, DRA7xx, and

Add test target for Cybertrust supported ZYNQMP zcu102 board. boot and smc test are executed automatically, but LTP is set to be executed manually because this board is not official

Hi! v4.19.142-cip33-rt14 should be available at kernel.org. Trees are available

Hi Pavel,

gpiochip_get_data() expects the controller probe to call gpiochip_add_data() before using it, where as the rcar-gpio driver probe has gpiochip_add() call thus resulting in NULL pointer access. Avoid

From: Rob Herring <robh@...> commit 173ee3962959a1985a109f81539a403b5cd07ae7 upstream. Commit f42b0e18f2e5 ("of: add node name compare helper functions") failed to add the module exports to

Hi Pavel/ Nobuhiro,

Hi! Aha, so I'd expect Fixes: eeaa48eee492d ("drm: rcar-du: Support panels connected directly to the DPAD outputs") in this patch. And yes, this means that failure is real and this patch should go

Hi! Quick git log shows that "serial: mctrl_gpio: Avoid probe failures" is not mentioned in 4.4 commit history. That very probably means that this patch is not safe for 4.4 (situation similar to

Hi! No, sorry, I don't think this is correct. In 4.4, we still have static inline struct gpio_desc *__must_check devm_gpiod_get_index_optional(struct device *dev, const char *con_id,

Hi! What is the impact of the bug? DMA running during reboot, but not doing any harm? Anyway, this looks okay to me. Best regards, Pavel -- DENX Software Engineering GmbH, Managing

Hi! Ok, so this fixes serial_mctrl_gpio on some ACPI systems. It should be a NOP on Renesas hardware, right? Do you need this one in 4.4? Was it tested on problematic ACPI system? Best

Hi Pavel, Thank you for the review.

Hi! Okay, so this is a cleanup that makes sense for mainline. Does it fix set_multiple? ... seems so. Fixing set_multiple is possible with this oneliner, right? The patch is okay and now I

Hi Pavel, Thank you for the review.