[PATCH v2] x86/cpu/AMD: Fix CPB bit for more processors

CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on some newer F17h procssors but their revision guide has not been released. For example,Tesed on AMD "Ryzen 7 2700U with Radeon Vega Mobile Gfx" and "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", their CPUID Fn_0001_EAX is 0x00810f10 and should have

[PATCH v2] x86/cpu/AMD: Fix CPB bit for more processors

CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on some newer F17h procssors but their revision guide has not been released. For example,Tesed on AMD "Ryzen 7 2700U with Radeon Vega Mobile Gfx" and "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", their CPUID Fn_0001_EAX is 0x00810f10 and should have

Re: [PATCH] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()

On Mon, 2018-11-19 at 15:43 -0800, Dave Hansen wrote: > On 11/19/18 3:19 PM, Dan Williams wrote: > > Andy wondered why a path that can sleep was using __flush_tlb_all() > > [1] > > and Dave confirmed the expectation for TLB flush is for modifying / > > invalidating existing pte entries, but not

Re: [PATCH] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()

On Mon, 2018-11-19 at 15:43 -0800, Dave Hansen wrote: > On 11/19/18 3:19 PM, Dan Williams wrote: > > Andy wondered why a path that can sleep was using __flush_tlb_all() > > [1] > > and Dave confirmed the expectation for TLB flush is for modifying / > > invalidating existing pte entries, but not

Re: [PATCH 01/16] dt-bindings: Add RDA Micro vendor prefix

On Mon, Nov 19, 2018 at 10:59:58PM +0530, Manivannan Sadhasivam wrote: > On Mon, Nov 19, 2018 at 06:22:02PM +0100, Andreas Färber wrote: > > Am 19.11.18 um 18:09 schrieb Manivannan Sadhasivam: > > > From: Andreas Färber > > > > > > RDA Microelectronics is a Chinese SoC manufacturer. > > > > > >

Re: [PATCH 01/16] dt-bindings: Add RDA Micro vendor prefix

On Mon, Nov 19, 2018 at 10:59:58PM +0530, Manivannan Sadhasivam wrote: > On Mon, Nov 19, 2018 at 06:22:02PM +0100, Andreas Färber wrote: > > Am 19.11.18 um 18:09 schrieb Manivannan Sadhasivam: > > > From: Andreas Färber > > > > > > RDA Microelectronics is a Chinese SoC manufacturer. > > > > > >

Re: [PATCH 3/6] zram: introduce ZRAM_IDLE flag

Hello, On (11/16/18 16:20), Minchan Kim wrote: [..] > +static ssize_t idle_store(struct device *dev, > + struct device_attribute *attr, const char *buf, size_t len) > +{ > + struct zram *zram = dev_to_zram(dev); > + unsigned long nr_pages = zram->disksize >> PAGE_SHIFT; > +

Re: [PATCH 3/6] zram: introduce ZRAM_IDLE flag

Hello, On (11/16/18 16:20), Minchan Kim wrote: [..] > +static ssize_t idle_store(struct device *dev, > + struct device_attribute *attr, const char *buf, size_t len) > +{ > + struct zram *zram = dev_to_zram(dev); > + unsigned long nr_pages = zram->disksize >> PAGE_SHIFT; > +

Investment Lening!

Heb je een lening nodig voor welk doel dan ook?? wij verlenen lening at 3% belangen tarief jaarlijks Ik kan u helpen met het financieren van leningen voor elk doel (zolang er geen sprake is van enige vorm van illegaliteit), van € 5.000 (vijfduizend euro) tot slechts € 20 miljoen euro. Alle

Re: [PATCH v1 04/11] soc: mediatek: add new flow for mtcmos power.

On Tue, 2018-11-13 at 11:31 -0800, Nicolas Boichat wrote: > (not a complete review...) > > On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote: > > > > From: Owen Chen > > > > Both MT8183 & MT6765 add more bus protect node than previous project, > > therefore we add two more register for setup bus

Investment Lening!

Heb je een lening nodig voor welk doel dan ook?? wij verlenen lening at 3% belangen tarief jaarlijks Ik kan u helpen met het financieren van leningen voor elk doel (zolang er geen sprake is van enige vorm van illegaliteit), van € 5.000 (vijfduizend euro) tot slechts € 20 miljoen euro. Alle

Re: [PATCH v1 04/11] soc: mediatek: add new flow for mtcmos power.

On Tue, 2018-11-13 at 11:31 -0800, Nicolas Boichat wrote: > (not a complete review...) > > On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote: > > > > From: Owen Chen > > > > Both MT8183 & MT6765 add more bus protect node than previous project, > > therefore we add two more register for setup bus

Re: [PATCH 00/12] perf top: Rework processing code

Hi Jirka, On Mon, Nov 19, 2018 at 01:20:04PM +0100, Jiri Olsa wrote: > hi, > David reported issues with perf top loosing side band events > so we moved mmap reading and hists processing into separated > threads. > > This patchset also adds dropping sample logic when the processing > falls behind

Re: [PATCH 00/12] perf top: Rework processing code

Hi Jirka, On Mon, Nov 19, 2018 at 01:20:04PM +0100, Jiri Olsa wrote: > hi, > David reported issues with perf top loosing side band events > so we moved mmap reading and hists processing into separated > threads. > > This patchset also adds dropping sample logic when the processing > falls behind

Re: [PATCH] mm: use this_cpu_cmpxchg_double in put_cpu_partial

Hi Wengang, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.20-rc3 next-20181119] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH] mm: use this_cpu_cmpxchg_double in put_cpu_partial

Hi Wengang, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.20-rc3 next-20181119] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH] mm: use this_cpu_cmpxchg_double in put_cpu_partial

On 2018/11/17 9:33, Wengang Wang wrote: > The this_cpu_cmpxchg makes the do-while loop pass as long as the > s->cpu_slab->partial as the same value. It doesn't care what happened to > that slab. Interrupt is not disabled, and new alloc/free can happen in the > interrupt handlers. Theoretically,

Re: [PATCH] mm: use this_cpu_cmpxchg_double in put_cpu_partial

On 2018/11/17 9:33, Wengang Wang wrote: > The this_cpu_cmpxchg makes the do-while loop pass as long as the > s->cpu_slab->partial as the same value. It doesn't care what happened to > that slab. Interrupt is not disabled, and new alloc/free can happen in the > interrupt handlers. Theoretically,

Re: [PATCH] ACPI / battery: Fix reporting "Not charging" when capacity is 100%

On Sun, Nov 11, 2018 at 4:22 AM Pavel Machek wrote: > > On Sun 2018-11-11 12:57:12, Hans de Goede wrote: > > Hi, > > > > On 11/7/18 5:53 AM, Daniel Drake wrote: > > >On Mon, Nov 5, 2018 at 1:19 AM Pavel Machek wrote: > > >>Plus, I don't think "100% charge" is right test for "battery full". At >

Re: [PATCH] ACPI / battery: Fix reporting "Not charging" when capacity is 100%

On Sun, Nov 11, 2018 at 4:22 AM Pavel Machek wrote: > > On Sun 2018-11-11 12:57:12, Hans de Goede wrote: > > Hi, > > > > On 11/7/18 5:53 AM, Daniel Drake wrote: > > >On Mon, Nov 5, 2018 at 1:19 AM Pavel Machek wrote: > > >>Plus, I don't think "100% charge" is right test for "battery full". At >

Re: [PATCH] timers: Make the lower-level timer function first call than higher-level

Hi John, Thanks for your review. John Stultz 于2018年11月20日周二 上午2:16写道： > > On Mon, Nov 19, 2018 at 6:10 AM, Muchun Song wrote: > > The elements of the heads array are a linked list of timer events that > > expire at the current time. And it can contain up to LVL_DEPTH levels > > and the lower

Re: [PATCH] timers: Make the lower-level timer function first call than higher-level

Hi John, Thanks for your review. John Stultz 于2018年11月20日周二 上午2:16写道： > > On Mon, Nov 19, 2018 at 6:10 AM, Muchun Song wrote: > > The elements of the heads array are a linked list of timer events that > > expire at the current time. And it can contain up to LVL_DEPTH levels > > and the lower

Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()

Hi, On Mon, Nov 19, 2018 at 4:58 PM Dmitry Osipenko wrote: > > On 20.11.2018 3:26, Douglas Anderson wrote: > > In regulator_force_disable() there was a strange loop that looked like: > > > > while (rdev->open_count--) > > regulator_disable(rdev->supply); > > > > I'm not totally sure what

Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()

Hi, On Mon, Nov 19, 2018 at 4:58 PM Dmitry Osipenko wrote: > > On 20.11.2018 3:26, Douglas Anderson wrote: > > In regulator_force_disable() there was a strange loop that looked like: > > > > while (rdev->open_count--) > > regulator_disable(rdev->supply); > > > > I'm not totally sure what

Re: [PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk

On Mon, Nov 19, 2018 at 1:41 AM Heiko Stübner wrote: > > Am Freitag, 16. November 2018, 19:23:59 CET schrieb Doug Anderson: > > Hi, > > > > On Fri, Nov 16, 2018 at 9:39 AM dbasehore . wrote: > > > On Fri, Nov 16, 2018 at 8:01 AM Doug Anderson > wrote: > > > > Hi, > > > > > > > > On Thu, Nov 15,

Re: [PATCH] arm64: dts: rockchip: rk3399: Add xin32k clk

On Mon, Nov 19, 2018 at 1:41 AM Heiko Stübner wrote: > > Am Freitag, 16. November 2018, 19:23:59 CET schrieb Doug Anderson: > > Hi, > > > > On Fri, Nov 16, 2018 at 9:39 AM dbasehore . wrote: > > > On Fri, Nov 16, 2018 at 8:01 AM Doug Anderson > wrote: > > > > Hi, > > > > > > > > On Thu, Nov 15,

Re: [PATCH 05/12] perf top: Moving lost events warning to helpline

On Mon, Nov 19, 2018 at 01:20:09PM +0100, Jiri Olsa wrote: > We can't display the UI box saying that we are slow in reader > thread. That will make perf top even slower and user even more > angry ;-) > > Moving the UI box message out of the reader thread into UI thread > and changing it into

Re: [PATCH 05/12] perf top: Moving lost events warning to helpline

On Mon, Nov 19, 2018 at 01:20:09PM +0100, Jiri Olsa wrote: > We can't display the UI box saying that we are slow in reader > thread. That will make perf top even slower and user even more > angry ;-) > > Moving the UI box message out of the reader thread into UI thread > and changing it into

Re: Memory hotplug softlock issue

On 11/19/18 at 09:59pm, Michal Hocko wrote: > On Mon 19-11-18 12:34:09, Hugh Dickins wrote: > > I'm glad that I delayed, what I had then (migration_waitqueue instead > > of using page_waitqueue) was not wrong, but what I've been using the > > last couple of months is rather better (and can be put

Re: Memory hotplug softlock issue

On 11/19/18 at 09:59pm, Michal Hocko wrote: > On Mon 19-11-18 12:34:09, Hugh Dickins wrote: > > I'm glad that I delayed, what I had then (migration_waitqueue instead > > of using page_waitqueue) was not wrong, but what I've been using the > > last couple of months is rather better (and can be put

RE: [PATCH] driver: input: fix UBSAN warning in input_defuzz_abs_event

Best Regards, liujian > -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: Tuesday, November 13, 2018 3:49 AM > To: liujian (CE) > Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] driver: input: fix UBSAN warning

RE: [PATCH] driver: input: fix UBSAN warning in input_defuzz_abs_event

Best Regards, liujian > -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: Tuesday, November 13, 2018 3:49 AM > To: liujian (CE) > Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] driver: input: fix UBSAN warning

[PATCH] KVM: LAPIC: Fix pv ipis use-before-initialization

Reported by syzkaller: BUG: unable to handle kernel NULL pointer dereference at 0014 PGD 80040410c067 P4D 80040410c067 PUD 40410d067 PMD 0 Oops: [#1] PREEMPT SMP PTI CPU: 3 PID: 2567 Comm: poc Tainted: G OE 4.19.0-rc5 #16 RIP:

[PATCH] KVM: LAPIC: Fix pv ipis use-before-initialization

Reported by syzkaller: BUG: unable to handle kernel NULL pointer dereference at 0014 PGD 80040410c067 P4D 80040410c067 PUD 40410d067 PMD 0 Oops: [#1] PREEMPT SMP PTI CPU: 3 PID: 2567 Comm: poc Tainted: G OE 4.19.0-rc5 #16 RIP:

RE: [PATCH V2] ARM: dts: imx7d-sdb: add rev-a board support

Hi, Shawn Best Regards! Anson Huang > -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: 2018年11月19日 21:46 > To: Anson Huang > Cc: robh...@kernel.org; mark.rutl...@arm.com; s.ha...@pengutronix.de; > ker...@pengutronix.de; Fabio Estevam ; >

RE: [PATCH V2] ARM: dts: imx7d-sdb: add rev-a board support

Hi, Shawn Best Regards! Anson Huang > -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: 2018年11月19日 21:46 > To: Anson Huang > Cc: robh...@kernel.org; mark.rutl...@arm.com; s.ha...@pengutronix.de; > ker...@pengutronix.de; Fabio Estevam ; >

[PATCH V3] ARM: dts: imx7d-sdb: add rev-a board support

Current imx7d-sdb.dts has some incorrect settings about Rev-A and Rev-B boards, some of the settings are based on Rev-A board but some are based on Rev-B board, clean up it by adding i.MX7D SDB Rev-A board support, make default imx7d-sdb.dts for Rev-B board as usual, and introduce

[PATCH V3] ARM: dts: imx7d-sdb: add rev-a board support

Current imx7d-sdb.dts has some incorrect settings about Rev-A and Rev-B boards, some of the settings are based on Rev-A board but some are based on Rev-B board, clean up it by adding i.MX7D SDB Rev-A board support, make default imx7d-sdb.dts for Rev-B board as usual, and introduce

Re: [PATCH 2/2] PCI: imx6: limit DBI register length

On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote: > > > +static const struct imx6_pcie_drvdata imx6q_pcie_drvdata = { > + .variant = IMX6Q, > + .dbi_length = 0x15c, > +}; > + > +static const struct imx6_pcie_drvdata imx6sx_pcie_drvdata = { > + .variant = IMX6SX, > +}; > + >

Re: [PATCH 2/2] PCI: imx6: limit DBI register length

On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote: > > > +static const struct imx6_pcie_drvdata imx6q_pcie_drvdata = { > + .variant = IMX6Q, > + .dbi_length = 0x15c, > +}; > + > +static const struct imx6_pcie_drvdata imx6sx_pcie_drvdata = { > + .variant = IMX6SX, > +}; > + >

Re: [PATCH v3 1/3] compiler_types.h: make __builtin_types_compatible_p() noop for Sparse

On Mon, Nov 19, 2018 at 9:35 PM Luc Van Oostenryck wrote: > > On Mon, Nov 19, 2018 at 07:31:41PM +0900, Masahiro Yamada wrote: > > When I tried to delete BUILD_BUG_ON stubs for sparse, the kbuild test > > robot reported lots of Sparse warnings from container_of(), which > > seem false positive. >

Re: [PATCH v3 1/3] compiler_types.h: make __builtin_types_compatible_p() noop for Sparse

On Mon, Nov 19, 2018 at 9:35 PM Luc Van Oostenryck wrote: > > On Mon, Nov 19, 2018 at 07:31:41PM +0900, Masahiro Yamada wrote: > > When I tried to delete BUILD_BUG_ON stubs for sparse, the kbuild test > > robot reported lots of Sparse warnings from container_of(), which > > seem false positive. >

Re: [PATCH v3 3/3] build_bug.h: remove most of dummy BUILD_BUG_ON stubs for sparse

On Tue, Nov 20, 2018 at 3:02 AM Nick Desaulniers wrote: > > On Mon, Nov 19, 2018 at 4:37 AM Luc Van Oostenryck > wrote: > > > > On Mon, Nov 19, 2018 at 07:31:43PM +0900, Masahiro Yamada wrote: > > > The introduction of these dummy BUILD_BUG_ON stubs dates back to > > > commit 903c0c7cdc21

Re: [PATCH v3 3/3] build_bug.h: remove most of dummy BUILD_BUG_ON stubs for sparse

On Tue, Nov 20, 2018 at 3:02 AM Nick Desaulniers wrote: > > On Mon, Nov 19, 2018 at 4:37 AM Luc Van Oostenryck > wrote: > > > > On Mon, Nov 19, 2018 at 07:31:43PM +0900, Masahiro Yamada wrote: > > > The introduction of these dummy BUILD_BUG_ON stubs dates back to > > > commit 903c0c7cdc21

Re: [PATCH v2] mm: fix swap offset when replacing shmem page

On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote: > On Sun, 18 Nov 2018, Yu Zhao wrote: > > > We used to have a single swap address space with swp_entry_t.val > > as its radix tree index. This is not the case anymore. Now Each > > swp_type() has its own address space and should use

Re: [PATCH v2] mm: fix swap offset when replacing shmem page

On Mon, Nov 19, 2018 at 02:11:27PM -0800, Hugh Dickins wrote: > On Sun, 18 Nov 2018, Yu Zhao wrote: > > > We used to have a single swap address space with swp_entry_t.val > > as its radix tree index. This is not the case anymore. Now Each > > swp_type() has its own address space and should use

Re: [PATCH 00/12] perf top: Rework processing code

From: Jiri Olsa Date: Mon, 19 Nov 2018 13:20:04 +0100 > David reported issues with perf top loosing side band events > so we moved mmap reading and hists processing into separated > threads. > > This patchset also adds dropping sample logic when the processing > falls behind the reader thread.

Re: [PATCH 00/12] perf top: Rework processing code

From: Jiri Olsa Date: Mon, 19 Nov 2018 13:20:04 +0100 > David reported issues with perf top loosing side band events > so we moved mmap reading and hists processing into separated > threads. > > This patchset also adds dropping sample logic when the processing > falls behind the reader thread.

[PATCH v3 3/5] phy: ocelot-serdes: convert to use eth phy mode and submode

Convert ocelot-serdes PHY driver to use recently introduced PHY_MODE_ETHERNET and phy_set_mode_ext(). Cc: Quentin Schulz Signed-off-by: Grygorii Strashko --- drivers/net/ethernet/mscc/ocelot.c | 9 ++--- drivers/phy/mscc/phy-ocelot-serdes.c | 22 -- 2 files changed,

[PATCH v3 4/5] phy: mvebu-cp110-comphy: convert to use eth phy mode and submode

Convert mvebu-cp110-comphy PHY driver to use recently introduced PHY_MODE_ETHERNET and phy_set_mode_ext(). Cc: Russell King - ARM Linux Cc: Maxime Chevallier Cc: Antoine Tenart Signed-off-by: Grygorii Strashko --- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-

[PATCH v3 1/5] phy: core: rework phy_set_mode to accept phy mode and submode

Currently the attempt to add support for Ethernet interface mode PHY (MII/GMII/RGMII) will lead to the necessity of extending enum phy_mode and duplicate there values from phy_interface_t enum (or introduce more PHY callbacks) [1]. Both approaches are ineffective and would lead to fast bloating of

[PATCH v3 3/5] phy: ocelot-serdes: convert to use eth phy mode and submode

Convert ocelot-serdes PHY driver to use recently introduced PHY_MODE_ETHERNET and phy_set_mode_ext(). Cc: Quentin Schulz Signed-off-by: Grygorii Strashko --- drivers/net/ethernet/mscc/ocelot.c | 9 ++--- drivers/phy/mscc/phy-ocelot-serdes.c | 22 -- 2 files changed,

[PATCH v3 4/5] phy: mvebu-cp110-comphy: convert to use eth phy mode and submode

Convert mvebu-cp110-comphy PHY driver to use recently introduced PHY_MODE_ETHERNET and phy_set_mode_ext(). Cc: Russell King - ARM Linux Cc: Maxime Chevallier Cc: Antoine Tenart Signed-off-by: Grygorii Strashko --- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-

[PATCH v3 1/5] phy: core: rework phy_set_mode to accept phy mode and submode

Currently the attempt to add support for Ethernet interface mode PHY (MII/GMII/RGMII) will lead to the necessity of extending enum phy_mode and duplicate there values from phy_interface_t enum (or introduce more PHY callbacks) [1]. Both approaches are ineffective and would lead to fast bloating of

Re: [PATCH 2/3] PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D

On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote: > PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family, > so none of the code in current implementation of imx6_pcie_reset_phy() > is applicable. Tested on IMX7d, still appears to work. Note that your patches will collide

Re: [PATCH 2/3] PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D

On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote: > PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family, > so none of the code in current implementation of imx6_pcie_reset_phy() > is applicable. Tested on IMX7d, still appears to work. Note that your patches will collide

[PATCH v1] regulator: core: Export regulator_lock and regulator_unlock

This fixes compiling regulator drivers that use these function when these drivers are built as kernel modules. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH v1] regulator: core: Export regulator_lock and regulator_unlock

This fixes compiling regulator drivers that use these function when these drivers are built as kernel modules. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 2 ++ 1 file changed, 2 insertions(+) diff

Re: [PATCH 2/2] ASoC: max98927: Add reset-gpio support

Hi Philipp, On Thu, Oct 18, 2018 at 1:02 AM Philipp Zabel wrote: > > Hi Maxime, > > On Fri, 2018-10-12 at 15:46 +0200, Maxime Ripard wrote: > > On Fri, Oct 12, 2018 at 12:05:16PM +0200, Philipp Zabel wrote: > [...] > > > What I would like better would be to let the consumers keep their reset- >

Re: [PATCH 2/2] ASoC: max98927: Add reset-gpio support

Hi Philipp, On Thu, Oct 18, 2018 at 1:02 AM Philipp Zabel wrote: > > Hi Maxime, > > On Fri, 2018-10-12 at 15:46 +0200, Maxime Ripard wrote: > > On Fri, Oct 12, 2018 at 12:05:16PM +0200, Philipp Zabel wrote: > [...] > > > What I would like better would be to let the consumers keep their reset- >

Re: [RFC PATCH] Documentation: DT: arm: add support for sockets defining package boundaries

On 11/12/18 3:37 PM, Rob Herring wrote: On Wed, Nov 07, 2018 at 05:13:44PM +, Sudeep Holla wrote: The current ARM DT topology description provides the operating system with a topological view of the system that is based on leaf nodes representing either cores or threads (in an SMT system)

Re: [RFC PATCH] Documentation: DT: arm: add support for sockets defining package boundaries

On 11/12/18 3:37 PM, Rob Herring wrote: On Wed, Nov 07, 2018 at 05:13:44PM +, Sudeep Holla wrote: The current ARM DT topology description provides the operating system with a topological view of the system that is based on leaf nodes representing either cores or threads (in an SMT system)

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

> I'm not taking that stuff without proper documentation. Ok can you just revert Jiri's code then instead? This is after all mainly an emergency fixup patch for that disaster, which got fast tracked without any of these considerations which now suddenly appear. Requiring new documentation for

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

> I'm not taking that stuff without proper documentation. Ok can you just revert Jiri's code then instead? This is after all mainly an emergency fixup patch for that disaster, which got fast tracked without any of these considerations which now suddenly appear. Requiring new documentation for

Re: [PATCH 4.14 000/124] 4.14.82-stable review

stable-rc/linux-4.14.y boot: 77 boots: 0 failed, 59 passed with 18 offline (v4.14.81-125-g43bb46eb6e2e) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.81-125-g43bb46eb6e2e/ Full Build Summary:

Re: [PATCH 4.14 000/124] 4.14.82-stable review

stable-rc/linux-4.14.y boot: 77 boots: 0 failed, 59 passed with 18 offline (v4.14.81-125-g43bb46eb6e2e) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.81-125-g43bb46eb6e2e/ Full Build Summary:

Re: [PATCH 4/8] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS

Hi Nicolas, On Sat, Nov 17, 2018 at 2:50 AM Nicolas Pitre wrote: > > > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > > > > index 7f3ca6e..e5ba9b1 100644 > > > > --- a/scripts/Makefile.build > > > > +++ b/scripts/Makefile.build > > > > @@ -254,9 +254,18 @@ objtool_dep =

Re: [PATCH 4/8] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS

Hi Nicolas, On Sat, Nov 17, 2018 at 2:50 AM Nicolas Pitre wrote: > > > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > > > > index 7f3ca6e..e5ba9b1 100644 > > > > --- a/scripts/Makefile.build > > > > +++ b/scripts/Makefile.build > > > > @@ -254,9 +254,18 @@ objtool_dep =

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

On 11/19/2018 04:30 PM, Thomas Gleixner wrote: > > What has spectre_v2=on to do with spectre_v2_app2app=on? > > Exactly nothing. You can have 'on' for both. The only side effect of > spectre_v2=on is that it also forces spectre_v2_app2app to 'on' > irrespective of what eventually was added for

Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

On 11/19/2018 04:30 PM, Thomas Gleixner wrote: > > What has spectre_v2=on to do with spectre_v2_app2app=on? > > Exactly nothing. You can have 'on' for both. The only side effect of > spectre_v2=on is that it also forces spectre_v2_app2app to 'on' > irrespective of what eventually was added for

Re: [PATCH RFC] hist lookups

On Mon, Nov 19, 2018 at 10:12:57AM +0100, Jiri Olsa wrote: > On Mon, Nov 19, 2018 at 02:26:03PM +0900, Namhyung Kim wrote: > > Hi Jirka > > > > Sorry for late! > > > > On Tue, Nov 06, 2018 at 12:54:36PM +0100, Jiri Olsa wrote: > > > On Mon, Nov 05, 2018 at 08:53:42PM -0800, David Miller wrote: >

Re: [PATCH RFC] hist lookups

On Mon, Nov 19, 2018 at 10:12:57AM +0100, Jiri Olsa wrote: > On Mon, Nov 19, 2018 at 02:26:03PM +0900, Namhyung Kim wrote: > > Hi Jirka > > > > Sorry for late! > > > > On Tue, Nov 06, 2018 at 12:54:36PM +0100, Jiri Olsa wrote: > > > On Mon, Nov 05, 2018 at 08:53:42PM -0800, David Miller wrote: >

[PATCH v2 0/9] kbuild: clean-up modversion, TRIM_UNUSED_KSYMS, if_changed_rule, etc.

As a Kbuild maintainer, I always struggle to keep the core makefiles clean because people tend to squeeze more and more clutter code into the kbuild core in order to do what they want to do. The biggest step forward in this series is to re-implement the build trick of CONFIG_TRIM_UNUSED_KSYMS in

[PATCH v2 0/9] kbuild: clean-up modversion, TRIM_UNUSED_KSYMS, if_changed_rule, etc.

As a Kbuild maintainer, I always struggle to keep the core makefiles clean because people tend to squeeze more and more clutter code into the kbuild core in order to do what they want to do. The biggest step forward in this series is to re-implement the build trick of CONFIG_TRIM_UNUSED_KSYMS in

[PATCH v2 2/9] kbuild: remove redundant 'set -e' from filechk_* defines

The filechk macro in scripts/Kbuild.include already sets 'set -e'. Signed-off-by: Masahiro Yamada --- Changes in v2: None arch/um/Makefile | 2 +- scripts/Makefile.lib | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/um/Makefile b/arch/um/Makefile index

[PATCH v2 2/9] kbuild: remove redundant 'set -e' from filechk_* defines

The filechk macro in scripts/Kbuild.include already sets 'set -e'. Signed-off-by: Masahiro Yamada --- Changes in v2: None arch/um/Makefile | 2 +- scripts/Makefile.lib | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/um/Makefile b/arch/um/Makefile index

[PATCH v2 7/9] kbuild: remove trailing semicolon from cmd_* passed to if_changed_rule

With the change of rule_cc_o_c / rule_as_o_S in the last commit, each command is executed in a separate subshell. Rip off unneeded semicolons. Signed-off-by: Masahiro Yamada --- Changes in v2: - Clean up cmd_and_fixdep as well scripts/Kbuild.include | 2 +- scripts/Makefile.build | 16

[PATCH v2 7/9] kbuild: remove trailing semicolon from cmd_* passed to if_changed_rule

With the change of rule_cc_o_c / rule_as_o_S in the last commit, each command is executed in a separate subshell. Rip off unneeded semicolons. Signed-off-by: Masahiro Yamada --- Changes in v2: - Clean up cmd_and_fixdep as well scripts/Kbuild.include | 2 +- scripts/Makefile.build | 16

[PATCH v2 5/9] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS

My main motivation of this commit is to clean up scripts/Kbuild.include and scripts/Makefile.build. Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick; possibly exported symbols are detected by letting $(CPP) replace EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is

[PATCH v2 3/9] kbuild: remove redundant 'set -e' from sub_cmd_record_mcount

This is executed inside the if_changed_rule, which already sets 'set -e'. Signed-off-by: Masahiro Yamada --- Changes in v2: None scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index c909588..032ca24

[PATCH v2 6/9] kbuild: change if_changed_rule for multi-line recipe

The 'define' ... 'endef' directive can describe a recipe that consists of multiple lines. For example, all: @echo hello @echo world ... can be written as: define greeting @echo hello @echo world endif all: $(greeting)

[PATCH v2 5/9] kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS

My main motivation of this commit is to clean up scripts/Kbuild.include and scripts/Makefile.build. Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick; possibly exported symbols are detected by letting $(CPP) replace EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is

[PATCH v2 3/9] kbuild: remove redundant 'set -e' from sub_cmd_record_mcount

This is executed inside the if_changed_rule, which already sets 'set -e'. Signed-off-by: Masahiro Yamada --- Changes in v2: None scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index c909588..032ca24

[PATCH v2 6/9] kbuild: change if_changed_rule for multi-line recipe

The 'define' ... 'endef' directive can describe a recipe that consists of multiple lines. For example, all: @echo hello @echo world ... can be written as: define greeting @echo hello @echo world endif all: $(greeting)

[PATCH v2 4/9] kbuild: refactor modversions build rules

Let $(CC) compile objects into normal files *.o instead of .tmp_*.o whether CONFIG_MODVERSIONS is enabled or not. With this, the input file for objtool is always *.o so objtool_o can go away. I guess the reason of using .tmp_*.o for intermediate objects was to avoid leaving incomplete *.o file (,

Re: [PATCH 2/2] PCI: imx6: limit DBI register length

On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote: > Define the length of the DBI registers. This makes sure that > the kernel does not access registers beyond that point, avoiding > the following abort on a i.MX 6Quad: > # cat >

[PATCH v2 1/9] kbuild: let fixdep directly write to .*.cmd files

Currently, fixdep writes dependencies to .*.tmp, which is renamed to .*.cmd after everything succeeds. This is a very safe way to avoid corrupted .*.cmd files. The if_changed_dep has carried this safety mechanism since it was added in 2002. If fixdep fails for some reasons or a user terminates

[PATCH v2 4/9] kbuild: refactor modversions build rules

Let $(CC) compile objects into normal files *.o instead of .tmp_*.o whether CONFIG_MODVERSIONS is enabled or not. With this, the input file for objtool is always *.o so objtool_o can go away. I guess the reason of using .tmp_*.o for intermediate objects was to avoid leaving incomplete *.o file (,

Re: [PATCH 2/2] PCI: imx6: limit DBI register length

On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote: > Define the length of the DBI registers. This makes sure that > the kernel does not access registers beyond that point, avoiding > the following abort on a i.MX 6Quad: > # cat >

[PATCH v2 1/9] kbuild: let fixdep directly write to .*.cmd files

Currently, fixdep writes dependencies to .*.tmp, which is renamed to .*.cmd after everything succeeds. This is a very safe way to avoid corrupted .*.cmd files. The if_changed_dep has carried this safety mechanism since it was added in 2002. If fixdep fails for some reasons or a user terminates

[PATCH v2 9/9] kbuild: remove redundant 'set -e' from cmd_* defines

These three cmd_* are invoked in the $(call cmd,*) form. Now that 'set -e' moved to the 'cmd' macro, they do not need to explicitly give 'set -e'. Signed-off-by: Masahiro Yamada --- Changes in v2: None scripts/Makefile.build | 2 -- scripts/package/Makefile | 1 - 2 files changed, 3

[PATCH v2 9/9] kbuild: remove redundant 'set -e' from cmd_* defines

These three cmd_* are invoked in the $(call cmd,*) form. Now that 'set -e' moved to the 'cmd' macro, they do not need to explicitly give 'set -e'. Signed-off-by: Masahiro Yamada --- Changes in v2: None scripts/Makefile.build | 2 -- scripts/package/Makefile | 1 - 2 files changed, 3

[PATCH v2 8/9] kbuild: refactor if_changed and if_changed_dep

'@set -e; $(echo-cmd) $(cmd_$(1)' can be replaced with '$(cmd)'. Signed-off-by: Masahiro Yamada --- Changes in v2: None scripts/Kbuild.include | 9 +++-- scripts/Makefile.build | 4 ++-- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/scripts/Kbuild.include

[PATCH v2 8/9] kbuild: refactor if_changed and if_changed_dep

'@set -e; $(echo-cmd) $(cmd_$(1)' can be replaced with '$(cmd)'. Signed-off-by: Masahiro Yamada --- Changes in v2: None scripts/Kbuild.include | 9 +++-- scripts/Makefile.build | 4 ++-- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/scripts/Kbuild.include

Re: [RFC PATCH v2 03/14] m68k: mac: Clean up unused timer definitions

Geert, Please consider cherry-picking this patch. It isn't particularly relevant to the API conversion so I'd better not to include it in v3, when I submit v3. -- On Mon, 19 Nov 2018, Finn Thain wrote: > Signed-off-by: Finn Thain > --- > arch/m68k/include/asm/macints.h | 3 --- > 1 file

Re: [RFC PATCH v2 03/14] m68k: mac: Clean up unused timer definitions

Geert, Please consider cherry-picking this patch. It isn't particularly relevant to the API conversion so I'd better not to include it in v3, when I submit v3. -- On Mon, 19 Nov 2018, Finn Thain wrote: > Signed-off-by: Finn Thain > --- > arch/m68k/include/asm/macints.h | 3 --- > 1 file

Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()

On 20.11.2018 3:26, Douglas Anderson wrote: > In regulator_force_disable() there was a strange loop that looked like: > > while (rdev->open_count--) > regulator_disable(rdev->supply); > > I'm not totally sure what the goal was for this loop, but it seems > wrong to me. If anything I think

Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()

On 20.11.2018 3:26, Douglas Anderson wrote: > In regulator_force_disable() there was a strange loop that looked like: > > while (rdev->open_count--) > regulator_disable(rdev->supply); > > I'm not totally sure what the goal was for this loop, but it seems > wrong to me. If anything I think

Re: linux-next: build failure after merge of the regulator tree

e4aa7 ("regulator: core: Use ww_mutex for regulators locking") > > I have used the regulator tree from next-20181119 for today. > My bad, forgot to export these functions. That's the same issue that was reporter by the build robot earlier. Will send the fix, sorry for the inconvenience.

Re: linux-next: build failure after merge of the regulator tree

e4aa7 ("regulator: core: Use ww_mutex for regulators locking") > > I have used the regulator tree from next-20181119 for today. > My bad, forgot to export these functions. That's the same issue that was reporter by the build robot earlier. Will send the fix, sorry for the inconvenience.

<    1   2   3   4   5   6   7   8   9   10   >