Given that Intel's security notice did not state which patches fixed which issues, nor which commits caused them, I tried to guess which patch fixed which issue, based solely on their descriptions. Th

<daniel.sangorrin@...> wrote: Not at all. I'm merely stating that the descriptions match a known source. ChenYu

<masashi.kudo@...> wrote: I might not make it. Here's this week's update: Five new CVEs: - CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+ - This is

<daniel.sangorrin@...> wrote: Looks like all the new descriptions were copied from MITRE. Reviewed-by: Chen-Yu Tsai (Moxa) <wens@...>

Jumped the gun. This patch is no longer needed if you use join() to combine the lines.

<daniel.sangorrin@...> wrote: Reviewed-by: Chen-Yu Tsai (Moxa) <wens@...> Though these occurrences seem to be very rare.

<daniel.sangorrin@...> wrote: I believe it would be better to include the "CVE => " string in the full text passed to textwrap. That would make all lines properly wrapped at the given width.

Hi, It's the Mid-Autumn Festival, and we have a long weekend here. So I will not be attending today's meeting. 3 new CVEs this week. Please check the merge request In cip-kernel-sec for details. ChenY

Hi, <daniel.sangorrin@...> wrote: Thanks for submitting these. I'll take a look at them next week, after the long weekend here. ChenYu

From: Zumeng Chen <zumeng.chen@...> commit 05829d9431df1bf6de98679fbcfbad282c1c55a4 upstream. memory leakage was found by kmemleak. opp_data needs to be freed when failure, including fail_put_no

From: Dave Gerlach <d-gerlach@...> commit 69c8ab148006a2ec7ac1a1f08945e95febc1c132 upstream. AM335x, AM437x, DRA7xx, and AM57xx platforms all now depend on ti-cpufreq driver to enable proper OPPs f

From: Dave Gerlach <d-gerlach@...> commit 051bd84bb45bc994b7d762467f60b3bd0c7aa6bc upstream. Some TI platforms, specifically those in the am33xx, am43xx, dra7xx, and am57xx families of SoCs can mak

From: Christophe Jaillet <christophe.jaillet@...> commit 9a6e91d08e7707baa2f824257342ca7efcb199bc upstream. If 'dev_pm_opp_set_supported_hw()' fails, 'opp_data->opp_node' refcount will be decre

From: Suman Anna <s-anna@...> commit e5d295b06d69a1924665a16a4987be475addd00f upstream. Commit 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when failure") has fixed a memory leak in the failu

From: Dave Gerlach <d-gerlach@...> commit 72ac40fcb164a3d8fbd1ff13647abe67df26ced5 upstream. After the ti-cpufreq driver has been added, we can now drop the operating-points table present in am33xx

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

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, like dev_pm_opp_get_max_{transitio

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 availab

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 t