4.16.13-stable review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 169/272 PCI: Restore config space on runtime resume despite being unbound
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
[ Upstream commit 5775b843a619b3c93f946e2b55a208d9f0f48b59 ]
We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child goes to D3cold, its internal state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost.
One example are recent hybrid graphics laptops which cut power to the discrete GPU when the root port above it goes to ACPI power state D3. Users may provoke this by unbinding the GPU driver and allowing runtime PM on the GPU via sysfs: The PM core will then treat the GPU as "suspended", which in turn allows the root port to runtime suspend, causing the power resources listed in its _PR3 object to be powered off. The GPU's BARs will be uninitialized when a driver later probes it.
Another example are hybrid graphics laptops where the GPU itself (rather than the root port) is capable of runtime suspending to D3cold. If the GPU's integrated HDA controller is not bound and the GPU's driver decides to runtime suspend to D3cold, the HDA controller's BARs will be uninitialized when a driver later probes it.
Fix by saving and restoring config space over a runtime suspend cycle even if the device is not bound.
--- drivers/pci/pci-driver.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/pci/pci-driver.c +11 -6
@@ -1225,11 +1225,14 @@ static int pci_pm_runtime_suspend(structint error;/* -* If pci_dev->driver is not set (unbound), the device should -* always remain in D0 regardless of the runtime PM status +* If pci_dev->driver is not set (unbound), we leave the device in D0, +* but it may go to D3cold when the bridge above it runtime suspends. +* Save its config space in case that happens. */ -if (!pci_dev->driver) +if (!pci_dev->driver) { +pci_save_state (pci_dev);return 0 ; + }if (!pm || !pm->runtime_suspend)return -ENOSYS ;
@@ -1277,16 +1280,18 @@ static int pci_pm_runtime_resume(structconst struct dev_pm_ops *pm = dev->driver ? dev->driver->pm :NULL ;/* -* If pci_dev->driver is not set (unbound), the device should -* always remain in D0 regardless of the runtime PM status +* Restoring config space is necessary even if the device is not bound +* to a driver because although we left it in D0, it may have gone to +* D3cold when the bridge above it runtime suspended. */ +pci_restore_standard_config (pci_dev); +if (!pci_dev->driver)return 0 ;if (!pm || !pm->runtime_resume)return -ENOSYS ; -pci_restore_standard_config (pci_dev);pci_fixup_device (pci_fixup_resume_early, pci_dev);pci_enable_wake (pci_dev,PCI_D0 , false);pci_fixup_device (pci_fixup_resume, pci_dev);
Greg Kroah-Hartman
maintainerPATCH 170/272 watchdog: sprd_wdt: Fix error handling in sprd_wdt_enable()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Khoroshilov <[email protected]>
[ Upstream commit 3c578cd4bc52b6e65d65be1abad9a8aa489ec207 ]
If clk_prepare_enable(wdt->rtc_enable) fails,wdt->enable clock is left enabled.
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/watchdog/sprd_wdt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/watchdog/sprd_wdt.c +3 -1
@@ -154,8 +154,10 @@ static int sprd_wdt_enable(struct sprd_wif (ret)return ret; ret =clk_prepare_enable (wdt->rtc_enable); -if (ret) +if (ret) { +clk_disable_unprepare (wdt->enable);return ret; + }sprd_wdt_unlock (wdt->base); val =readl_relaxed (wdt->base +SPRD_WDT_CTRL );
Greg Kroah-Hartman
maintainerPATCH 171/272 watchdog: dw: RMW the control register
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
[ Upstream commit a81abbb412341e9e3b2d42ed7d310cf71fbb84a8 ]
RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length of pulse to issue for system reset. We shouldn't clobber this value, because that might make the system reset ineffective. On RK3399, we're seeing that a value of 000b (meaning 2 cycles) yields an unreliable (partial?) reset, and so we only fully reset after the watchdog fires a second time. If we retain the system default (010b, or 8 clock cycles), then the watchdog reset is much more reliable.
Read-modify-write retains the system value and improves reset reliability.
It seems we were intentionally clobbering the response mode previously, to ensure we performed a system reset (we don't support an interrupt notification), so retain that explicitly.
--- drivers/watchdog/dw_wdt.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
drivers/watchdog/dw_wdt.c +15 -8
@@ -34,6 +34,7 @@#define WDOG_CONTROL_REG_OFFSET 0x00#define WDOG_CONTROL_REG_WDT_EN_MASK 0x01 +#define WDOG_CONTROL_REG_RESP_MODE_MASK 0x02#define WDOG_TIMEOUT_RANGE_REG_OFFSET 0x04#define WDOG_TIMEOUT_RANGE_TOPINIT_SHIFT 4#define WDOG_CURRENT_COUNT_REG_OFFSET 0x08
@@ -121,14 +122,23 @@ static int dw_wdt_set_timeout(struct watreturn 0 ; } +static void dw_wdt_arm_system_reset (struct dw_wdt *dw_wdt) +{ +u32 val =readl (dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); + +/* Disable interrupt mode; always perform system reset. */ + val &= ~WDOG_CONTROL_REG_RESP_MODE_MASK ; +/* Enable watchdog. */ + val |=WDOG_CONTROL_REG_WDT_EN_MASK ; +writel (val, dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); +} +static int dw_wdt_start (struct watchdog_device *wdd) {struct dw_wdt *dw_wdt =to_dw_wdt (wdd);dw_wdt_set_timeout (wdd, wdd->timeout); - -writel (WDOG_CONTROL_REG_WDT_EN_MASK , - dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); +dw_wdt_arm_system_reset (dw_wdt);return 0 ; }
@@ -152,16 +162,13 @@ static int dw_wdt_restart(struct watchdo unsigned long action, void *data) { struct dw_wdt *dw_wdt = to_dw_wdt(wdd); -u32 val;writel (0 , dw_wdt->regs +WDOG_TIMEOUT_RANGE_REG_OFFSET ); - val =readl (dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); -if (val &WDOG_CONTROL_REG_WDT_EN_MASK ) +if (dw_wdt_is_enabled (dw_wdt))writel (WDOG_COUNTER_RESTART_KICK_VALUE , dw_wdt->regs +WDOG_COUNTER_RESTART_REG_OFFSET );else -writel (WDOG_CONTROL_REG_WDT_EN_MASK , - dw_wdt->regs +WDOG_CONTROL_REG_OFFSET ); +dw_wdt_arm_system_reset (dw_wdt);/* wait for reset to assert... */ mdelay (500 );
Greg Kroah-Hartman
maintainerPATCH 172/272 watchdog: aspeed: Fix translation of reset mode to ctrl register
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Milton Miller <[email protected]>
[ Upstream commit d2fc8db691bf3197d43b2afb553311a9bf257bff ]
Assert RESET_SYSTEM bit for any reset and set MODE field from reset type.
The watchdog control register has a RESET_SYSTEM bit that is really closer to activate a reset, and RESET_SYSTEM_MODE field that chooses how much to reset.
Before this patch, a node without these optional property would do a SOC reset, but a node with properties requesting a cpu or SOC reset would do nothing and a node requesting a system reset would do a SOC reset.
--- drivers/watchdog/aspeed_wdt.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/watchdog/aspeed_wdt.c +6 -3
@@ -234,11 +234,14 @@ static int aspeed_wdt_probe(struct platf wdt->ctrl |=WDT_CTRL_RESET_MODE_SOC |WDT_CTRL_RESET_SYSTEM ; }else {if (!strcmp (reset_type,"cpu" )) - wdt->ctrl |=WDT_CTRL_RESET_MODE_ARM_CPU ; + wdt->ctrl |=WDT_CTRL_RESET_MODE_ARM_CPU | +WDT_CTRL_RESET_SYSTEM ;else if (!strcmp (reset_type,"soc" )) - wdt->ctrl |=WDT_CTRL_RESET_MODE_SOC ; + wdt->ctrl |=WDT_CTRL_RESET_MODE_SOC | +WDT_CTRL_RESET_SYSTEM ;else if (!strcmp (reset_type,"system" )) - wdt->ctrl |=WDT_CTRL_RESET_SYSTEM ; + wdt->ctrl |=WDT_CTRL_RESET_MODE_FULL_CHIP | +WDT_CTRL_RESET_SYSTEM ;else if (strcmp (reset_type,"none" ))return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 173/272 ipmi_ssif: Fix kernel panic at msg_done_handler
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamlakant Patel <[email protected]>
[ Upstream commit f002612b9d86613bc6fde0a444e0095225f6053e ]
This happens when BMC doesn't return any data and the code is trying to print the value of data[2].
Getting following crash:
[ 484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002 [ 484.736496] pgd = ffff0000094a2000 [ 484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000 [ 484.748158] Internal error: Oops: 96000005 [#1] SMP [...] [ 485.101451] Call trace: [...] [ 485.188473] [<ffff000000a46e68>] msg_done_handler+0x668/0x700 [ipmi_ssif] [ 485.195249] [<ffff000000a456b8>] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif] [ 485.202038] [<ffff0000080f1430>] kthread+0x108/0x138 [ 485.206994] [<ffff0000080838e0>] ret_from_fork+0x10/0x30 [ 485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3)
Adding a check to validate the data len before printing data[2] to fix this issue.
--- drivers/char/ipmi/ipmi_ssif.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/char/ipmi/ipmi_ssif.c +2 -2
@@ -761,7 +761,7 @@ static void msg_done_handler(struct ssif ssif_info->ssif_state =SSIF_NORMAL ;ipmi_ssif_unlock_cond (ssif_info, flags);pr_warn (PFX "Error getting flags: %d %d, %x\n" , - result, len, data[2 ]); + result, len, (len >=3 ) ? data[2 ] :0 ); }else if (data[0 ] != (IPMI_NETFN_APP_REQUEST |1 ) <<2 || data[1 ] !=IPMI_GET_MSG_FLAGS_CMD ) {/*
@@ -783,7 +783,7 @@ static void msg_done_handler(struct ssifif ((result <0 ) || (len <3 ) || (data[2 ] !=0 )) {/* Error clearing flags */ pr_warn (PFX "Error clearing flags: %d %d, %x\n" , - result, len, data[2 ]); + result, len, (len >=3 ) ? data[2 ] :0 ); }else if (data[0 ] != (IPMI_NETFN_APP_REQUEST |1 ) <<2 || data[1 ] !=IPMI_CLEAR_MSG_FLAGS_CMD ) { pr_warn(PFX "Invalid response clearing flags: %x %x\n",
Greg Kroah-Hartman
maintainerPATCH 174/272 drm/meson: Fix some error handling paths in meson_drv_bind_master()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 2c18107b9d58972588cd45d89b8f58d0f033c110 ]
If one of these functions fail, we whould free 'drm', as alreadry done in the other error handling paths, below and above.
--- drivers/gpu/drm/meson/meson_drv.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)
drivers/gpu/drm/meson/meson_drv.c +16 -8
@@ -189,35 +189,43 @@ static int meson_drv_bind_master(struct res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"vpu" ); regs =devm_ioremap_resource (dev, res); -if (IS_ERR (regs)) -return PTR_ERR (regs); +if (IS_ERR (regs)) { + ret =PTR_ERR (regs); + goto free_drm; + } priv->io_base = regs; res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"hhi" );/* Simply ioremap since it may be a shared register zone */ regs =devm_ioremap (dev, res->start,resource_size (res)); -if (!regs) -return -EADDRNOTAVAIL ; +if (!regs) { + ret = -EADDRNOTAVAIL ; + goto free_drm; + } priv->hhi =devm_regmap_init_mmio (dev, regs, &meson_regmap_config);if (IS_ERR (priv->hhi)) {dev_err (&pdev->dev,"Couldn't create the HHI regmap\n" ); -return PTR_ERR (priv->hhi); + ret =PTR_ERR (priv->hhi); + goto free_drm; } res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"dmc" );/* Simply ioremap since it may be a shared register zone */ regs =devm_ioremap (dev, res->start,resource_size (res)); -if (!regs) -return -EADDRNOTAVAIL ; +if (!regs) { + ret = -EADDRNOTAVAIL ; + goto free_drm; + } priv->dmc =devm_regmap_init_mmio (dev, regs, &meson_regmap_config);if (IS_ERR (priv->dmc)) {dev_err (&pdev->dev,"Couldn't create the DMC regmap\n" ); -return PTR_ERR (priv->dmc); + ret =PTR_ERR (priv->dmc); + goto free_drm; } priv->vsync_irq =platform_get_irq (pdev,0 );
Greg Kroah-Hartman
maintainerPATCH 175/272 drm/meson: Fix an un-handled error path in meson_drv_bind_master()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit e770f6bf18182bc3af6ceec30189b6c323cbc157 ]
'drm_vblank_init()' can fail. So handle this (unlikely) error.
--- drivers/gpu/drm/meson/meson_drv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/meson/meson_drv.c +4 -1
@@ -230,7 +230,10 @@ static int meson_drv_bind_master(struct priv->vsync_irq =platform_get_irq (pdev,0 ); -drm_vblank_init (drm,1 ); + ret =drm_vblank_init (drm,1 ); +if (ret) + goto free_drm; +drm_mode_config_init (drm); drm->mode_config.max_width =3840 ; drm->mode_config.max_height =2160 ;
Greg Kroah-Hartman
maintainerPATCH 177/272 powerpc/powernv/npu: Fix deadlock in mmio_invalidate()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alistair Popple <[email protected]>
[ Upstream commit 2b74e2a9b39df40a2b489af2d24079617c61ee0e ]
When sending TLB invalidates to the NPU we need to send extra flushes due to a hardware issue. The original implementation would lock the all the ATSD MMIO registers sequentially before unlocking and relocking each of them sequentially to do the extra flush.
This introduced a deadlock as it is possible for one thread to hold one ATSD register whilst waiting for another register to be freed while the other thread is holding that register waiting for the one in the first thread to be freed.
For example if there are two threads and two ATSD registers:
Thread A Thread B
----------------------
Acquire 1
Acquire 2
Release 1 Acquire 1
Wait 1 Wait 2
Both threads will be stuck waiting to acquire a register resulting in an RCU stall warning or soft lockup.
This patch solves the deadlock by refactoring the code to ensure registers are not released between flushes and to ensure all registers are either acquired or released together and in order.
--- arch/powerpc/platforms/powernv/npu-dma.c | 227 +++++++++++++++++++------------ 1 file changed, 140 insertions(+), 87 deletions(-)
arch/powerpc/platforms/powernv/npu-dma.c +140 -87
@@ -417,6 +417,11 @@ struct npu_context {void *priv; }; +struct mmio_atsd_reg { +struct npu *npu; +int reg; +}; +/* * Find a free MMIO ATSD register and mark it in use. Return -ENOSPC * if none are available.
@@ -426,7 +431,7 @@ static int get_mmio_atsd_reg(struct npuint i;for (i =0 ; i < npu->mmio_atsd_count; i++) { -if (!test_and_set_bit (i, &npu->mmio_atsd_usage)) +if (!test_and_set_bit_lock (i, &npu->mmio_atsd_usage))return i; }
@@ -435,86 +440,90 @@ static int get_mmio_atsd_reg(struct npustatic void put_mmio_atsd_reg (struct npu *npu,int reg) { -clear_bit (reg, &npu->mmio_atsd_usage); +clear_bit_unlock (reg, &npu->mmio_atsd_usage); }/* MMIO ATSD register offsets */ #define XTS_ATSD_AVA 1#define XTS_ATSD_STAT 2 -static int mmio_launch_invalidate (struct npu *npu,unsigned long launch, -unsigned long va) +static void mmio_launch_invalidate (struct mmio_atsd_reg *mmio_atsd_reg, +unsigned long launch,unsigned long va) { -int mmio_atsd_reg; - -do { - mmio_atsd_reg =get_mmio_atsd_reg (npu); -cpu_relax (); - }while (mmio_atsd_reg <0 ); +struct npu *npu = mmio_atsd_reg->npu; +int reg = mmio_atsd_reg->reg;__raw_writeq (cpu_to_be64 (va), - npu->mmio_atsd_regs[mmio_atsd_reg] +XTS_ATSD_AVA ); + npu->mmio_atsd_regs[reg] +XTS_ATSD_AVA );eieio (); -__raw_writeq (cpu_to_be64 (launch), npu->mmio_atsd_regs[mmio_atsd_reg]); - -return mmio_atsd_reg; +__raw_writeq (cpu_to_be64 (launch), npu->mmio_atsd_regs[reg]); } -static int mmio_invalidate_pid (struct npu *npu,unsigned long pid,bool flush) +static void mmio_invalidate_pid (struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ], +unsigned long pid,bool flush) { +int i;unsigned long launch; -/* IS set to invalidate matching PID */ - launch =PPC_BIT (12 ); +for (i =0 ; i <= max_npu2_index; i++) { +if (mmio_atsd_reg[i].reg <0 ) +continue ; + +/* IS set to invalidate matching PID */ + launch =PPC_BIT (12 ); -/* PRS set to process-scoped */ - launch |=PPC_BIT (13 ); +/* PRS set to process-scoped */ + launch |=PPC_BIT (13 ); -/* AP */ - launch |= (u64 )mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); +/* AP */ + launch |= (u64 ) +mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); -/* PID */ - launch |= pid <<PPC_BITLSHIFT (38 ); +/* PID */ + launch |= pid <<PPC_BITLSHIFT (38 ); -/* No flush */ - launch |= !flush <<PPC_BITLSHIFT (39 ); +/* No flush */ + launch |= !flush <<PPC_BITLSHIFT (39 ); -/* Invalidating the entire process doesn't use a va */ -return mmio_launch_invalidate (npu, launch,0 ); +/* Invalidating the entire process doesn't use a va */ +mmio_launch_invalidate (&mmio_atsd_reg[i], launch,0 ); + } } -static int mmio_invalidate_va (struct npu *npu,unsigned long va, -unsigned long pid,bool flush) +static void mmio_invalidate_va (struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ], +unsigned long va,unsigned long pid,bool flush) { +int i;unsigned long launch; -/* IS set to invalidate target VA */ - launch =0 ; +for (i =0 ; i <= max_npu2_index; i++) { +if (mmio_atsd_reg[i].reg <0 ) +continue ; -/* PRS set to process scoped */ - launch |=PPC_BIT (13 ); +/* IS set to invalidate target VA */ + launch =0 ; -/* AP */ - launch |= (u64 )mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); +/* PRS set to process scoped */ + launch |=PPC_BIT (13 ); -/* PID */ - launch |= pid <<PPC_BITLSHIFT (38 ); +/* AP */ + launch |= (u64 ) +mmu_get_ap (mmu_virtual_psize) <<PPC_BITLSHIFT (17 ); -/* No flush */ - launch |= !flush <<PPC_BITLSHIFT (39 ); +/* PID */ + launch |= pid <<PPC_BITLSHIFT (38 ); -return mmio_launch_invalidate (npu, launch, va); +/* No flush */ + launch |= !flush <<PPC_BITLSHIFT (39 ); + +mmio_launch_invalidate (&mmio_atsd_reg[i], launch, va); + } }#define mn_to_npu_context (x) container_of(x, struct npu_context, mn) -struct mmio_atsd_reg { -struct npu *npu; -int reg; -}; -static void mmio_invalidate_wait ( -struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ],bool flush) +struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ]) {struct npu *npu;int i, reg;
@@ -529,16 +538,67 @@ static void mmio_invalidate_wait( reg = mmio_atsd_reg[i].reg;while (__raw_readq (npu->mmio_atsd_regs[reg] +XTS_ATSD_STAT ))cpu_relax (); + } +} + +/* +* Acquires all the address translation shootdown (ATSD) registers required to +* launch an ATSD on all links this npu_context is active on. +*/ +static void acquire_atsd_reg (struct npu_context *npu_context, +struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ]) +{ +int i, j; +struct npu *npu; +struct pci_dev *npdev; +struct pnv_phb *nphb; + +for (i =0 ; i <= max_npu2_index; i++) { + mmio_atsd_reg[i].reg =-1 ; +for (j =0 ; j <NV_MAX_LINKS ; j++) { +/* +* There are no ordering requirements with respect to +* the setup of struct npu_context, but to ensure +* consistent behaviour we need to ensure npdev[][] is +* only read once. +*/ + npdev =READ_ONCE (npu_context->npdev[i][j]); +if (!npdev) +continue ; + + nphb =pci_bus_to_host (npdev->bus)->private_data; + npu = &nphb->npu; + mmio_atsd_reg[i].npu = npu; + mmio_atsd_reg[i].reg =get_mmio_atsd_reg (npu); +while (mmio_atsd_reg[i].reg <0 ) { + mmio_atsd_reg[i].reg =get_mmio_atsd_reg (npu); +cpu_relax (); + } +break ; + } + } +} -put_mmio_atsd_reg (npu, reg); +/* +* Release previously acquired ATSD registers. To avoid deadlocks the registers +* must be released in the same order they were acquired above in +* acquire_atsd_reg. +*/ +static void release_atsd_reg (struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ]) +{ +int i; +for (i =0 ; i <= max_npu2_index; i++) {/* -* The GPU requires two flush ATSDs to ensure all entries have -* been flushed. We use PID 0 as it will never be used for a -* process on the GPU. +* We can't rely on npu_context->npdev[][] being the same here +* as when acquire_atsd_reg() was called, hence we use the +* values stored in mmio_atsd_reg during the acquire phase +* rather than re-reading npdev[][]. */ -if (flush) -mmio_invalidate_pid (npu,0 , true); +if (mmio_atsd_reg[i].reg <0 ) +continue ; + +put_mmio_atsd_reg (mmio_atsd_reg[i].npu, mmio_atsd_reg[i].reg); } }
@@ -549,10 +609,6 @@ static void mmio_invalidate_wait(static void mmio_invalidate (struct npu_context *npu_context,int va,unsigned long address,bool flush) { -int i, j; -struct npu *npu; -struct pnv_phb *nphb; -struct pci_dev *npdev;struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS ];unsigned long pid = npu_context->mm->context.id;
@@ -568,37 +624,25 @@ static void mmio_invalidate(struct npu_c* Loop over all the NPUs this process is active on and launch * an invalidate. */ -for (i =0 ; i <= max_npu2_index; i++) { - mmio_atsd_reg[i].reg =-1 ; -for (j =0 ; j <NV_MAX_LINKS ; j++) { - npdev = npu_context->npdev[i][j]; -if (!npdev) -continue ; +acquire_atsd_reg (npu_context, mmio_atsd_reg); +if (va) +mmio_invalidate_va (mmio_atsd_reg, address, pid, flush); +else +mmio_invalidate_pid (mmio_atsd_reg, pid, flush); - nphb =pci_bus_to_host (npdev->bus)->private_data; - npu = &nphb->npu; - mmio_atsd_reg[i].npu = npu; - -if (va) - mmio_atsd_reg[i].reg = -mmio_invalidate_va (npu, address, pid, - flush); -else - mmio_atsd_reg[i].reg = -mmio_invalidate_pid (npu, pid, flush); - -/* -* The NPU hardware forwards the shootdown to all GPUs -* so we only have to launch one shootdown per NPU. -*/ -break ; - } +mmio_invalidate_wait (mmio_atsd_reg); +if (flush) { +/* +* The GPU requires two flush ATSDs to ensure all entries have +* been flushed. We use PID 0 as it will never be used for a +* process on the GPU. +*/ +mmio_invalidate_pid (mmio_atsd_reg,0 , true); +mmio_invalidate_wait (mmio_atsd_reg); +mmio_invalidate_pid (mmio_atsd_reg,0 , true); +mmio_invalidate_wait (mmio_atsd_reg); } - -mmio_invalidate_wait (mmio_atsd_reg, flush); -if (flush) -/* Wait for the flush to complete */ -mmio_invalidate_wait (mmio_atsd_reg, false); +release_atsd_reg (mmio_atsd_reg); } static void pnv_npu2_mn_release(struct mmu_notifier *mn,
@@ -741,7 +785,16 @@ struct npu_context *pnv_npu2_init_contexif (WARN_ON (of_property_read_u32 (nvlink_dn,"ibm,npu-link-index" , &nvlink_index)))return ERR_PTR (-ENODEV ); - npu_context->npdev[npu->index][nvlink_index] = npdev; + +/* +* npdev is a pci_dev pointer setup by the PCI code. We assign it to +* npdev[][] to indicate to the mmu notifiers that an invalidation +* should also be sent over this nvlink. The notifiers don't use any +* other fields in npu_context, so we just need to ensure that when they +* deference npu_context->npdev[][] it is either a valid pointer or +* NULL. +*/ +WRITE_ONCE (npu_context->npdev[npu->index][nvlink_index], npdev);if (!nphb->npu.nmmu_flush) {/*
@@ -793,7 +846,7 @@ void pnv_npu2_destroy_context(struct npuif (WARN_ON (of_property_read_u32 (nvlink_dn,"ibm,npu-link-index" , &nvlink_index)))return ; - npu_context->npdev[npu->index][nvlink_index] =NULL ; +WRITE_ONCE (npu_context->npdev[npu->index][nvlink_index],NULL );opal_npu_destroy_context (nphb->opal_id, npu_context->mm->context.id,PCI_DEVID (gpdev->bus->number, gpdev->devfn));kref_put (&npu_context->kref, pnv_npu2_release_context);
Greg Kroah-Hartman
maintainerPATCH 178/272 f2fs: flush cp pack except cp pack 2 page at first
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gao Xiang <[email protected]>
[ Upstream commit 46706d5917f4457a6befe7a39a15c89dbb1ce9ca ]
Previously, we attempt to flush the whole cp pack in a single bio, however, when suddenly powering off at this time, we could get into an extreme scenario that cp pack 1 page and cp pack 2 page are updated and latest, but payload or current summaries are still partially outdated. (see reliable write in the UFS specification)
This patch submits the whole cp pack except cp pack 2 page at first, and then writes the cp pack 2 page with an extra independent bio with pre-io barrier.
--- fs/f2fs/checkpoint.c | 69 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 23 deletions(-)
fs/f2fs/checkpoint.c +46 -23
@@ -1162,6 +1162,39 @@ static void update_ckpt_flags(struct f2fspin_unlock_irqrestore (&sbi->cp_lock, flags); } +static void commit_checkpoint (struct f2fs_sb_info *sbi, +void *src,block_t blk_addr) +{ +struct writeback_control wbc = { + .for_reclaim =0 , + }; + +/* +* pagevec_lookup_tag and lock_page again will take +* some extra time. Therefore, update_meta_pages and +* sync_meta_pages are combined in this function. +*/ +struct page *page =grab_meta_page (sbi, blk_addr); +int err; + +memcpy (page_address (page), src,PAGE_SIZE ); +set_page_dirty (page); + +f2fs_wait_on_page_writeback (page,META , true); +f2fs_bug_on (sbi,PageWriteback (page)); +if (unlikely (!clear_page_dirty_for_io (page))) +f2fs_bug_on (sbi,1 ); + +/* writeout cp pack 2 page */ + err =__f2fs_write_meta_page (page, &wbc,FS_CP_META_IO ); +f2fs_bug_on (sbi, err); + +f2fs_put_page (page,0 ); + +/* submit checkpoint (with barrier if NOBARRIER is not set) */ +f2fs_submit_merged_write (sbi,META_FLUSH ); +} +static int do_checkpoint (struct f2fs_sb_info *sbi,struct cp_control *cpc) {struct f2fs_checkpoint *ckpt =F2FS_CKPT (sbi);
@@ -1264,16 +1297,6 @@ static int do_checkpoint(struct f2fs_sb_ } } -/* need to wait for end_io results */ -wait_on_all_pages_writeback (sbi); -if (unlikely (f2fs_cp_error (sbi))) -return -EIO ; - -/* flush all device cache */ - err =f2fs_flush_device_cache (sbi); -if (err) -return err; -/* write out checkpoint buffer at block 0 */ update_meta_page (sbi, ckpt, start_blk++);
@@ -1301,26 +1324,26 @@ static int do_checkpoint(struct f2fs_sb_ start_blk +=NR_CURSEG_NODE_TYPE ; } -/* writeout checkpoint block */ -update_meta_page (sbi, ckpt, start_blk); +/* update user_block_counts */ + sbi->last_valid_block_count = sbi->total_valid_block_count; +percpu_counter_set (&sbi->alloc_valid_block_count,0 ); -/* wait for previous submitted node/meta pages writeback */ +/* Here, we have one bio having CP pack except cp pack 2 page */ +sync_meta_pages (sbi,META ,LONG_MAX ,FS_CP_META_IO ); + +/* wait for previous submitted meta pages writeback */ wait_on_all_pages_writeback (sbi);if (unlikely (f2fs_cp_error (sbi)))return -EIO ; -filemap_fdatawait_range (NODE_MAPPING (sbi),0 ,LLONG_MAX ); -filemap_fdatawait_range (META_MAPPING (sbi),0 ,LLONG_MAX ); - -/* update user_block_counts */ - sbi->last_valid_block_count = sbi->total_valid_block_count; -percpu_counter_set (&sbi->alloc_valid_block_count,0 ); - -/* Here, we only have one bio having CP pack */ -sync_meta_pages (sbi,META_FLUSH ,LONG_MAX ,FS_CP_META_IO ); +/* flush all device cache */ + err =f2fs_flush_device_cache (sbi); +if (err) +return err; -/* wait for previous submitted meta pages writeback */ +/* barrier and flush checkpoint cp pack 2 page if it can */ +commit_checkpoint (sbi, ckpt, start_blk);wait_on_all_pages_writeback (sbi);release_ino_entry (sbi, false);
Greg Kroah-Hartman
maintainerPATCH 179/272 cxl: Check if PSL data-cache is available before issue flush request
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vaibhav Jain <[email protected]>
[ Upstream commit 94322ed8e857e3b2a33cf75118051af9baaa110f ]
PSL9D doesn't have a data-cache that needs to be flushed before resetting the card. However when cxl tries to flush data-cache on such a card, it times-out as PSL_Control register never indicates flush operation complete due to missing data-cache. This is usually indicated in the kernel logs with this message:
"WARNING: cache flush timed out"
To fix this the patch checks PSL_Debug register CDC-Field(BIT:27) which indicates the absence of a data-cache and sets a flag 'no_data_cache' in 'struct cxl_native' to indicate this. When cxl_data_cache_flush() is called it checks the flag and if set bails out early without requesting a data-cache flush operation to the PSL.
--- drivers/misc/cxl/cxl.h | 4 ++++ drivers/misc/cxl/native.c | 11 ++++++++++- drivers/misc/cxl/pci.c | 19 +++++++++++++------ 3 files changed, 27 insertions(+), 7 deletions(-)
drivers/misc/cxl/cxl.h +4 -0
@@ -369,6 +369,9 @@ static const cxl_p2n_reg_t CXL_PSL_WED_A#define CXL_PSL_TFC_An_AE (1ull << (63-30))/* Restart PSL with address error */ #define CXL_PSL_TFC_An_R (1ull << (63-31))/* Restart PSL transaction */ +/****** CXL_PSL_DEBUG *****************************************************/ +#define CXL_PSL_DEBUG_CDC (1ull << (63-27))/* Coherent Data cache support */ +/****** CXL_XSL9_IERAT_ERAT - CAIA 2 **********************************/ #define CXL_XSL9_IERAT_MLPID (1ull << (63-0))/* Match LPID */ #define CXL_XSL9_IERAT_MPID (1ull << (63-1))/* Match PID */
@@ -669,6 +672,7 @@ struct cxl_native {irq_hw_number_t err_hwirq;unsigned int err_virq;u64 ps_off; +bool no_data_cache;/* set if no data cache on the card */ const struct cxl_service_layer_ops *sl_ops; };
drivers/misc/cxl/native.c +10 -1
@@ -353,8 +353,17 @@ int cxl_data_cache_flush(struct cxl *adau64 reg;unsigned long timeout = jiffies + (HZ *CXL_TIMEOUT ); -pr_devel ("Flushing data cache\n" ); +/* +* Do a datacache flush only if datacache is available. +* In case of PSL9D datacache absent hence flush operation. +* would timeout. +*/ +if (adapter->native->no_data_cache) { +pr_devel ("No PSL data cache. Ignoring cache flush req.\n" ); +return 0 ; + } +pr_devel ("Flushing data cache\n" ); reg =cxl_p1_read (adapter, CXL_PSL_Control); reg |= CXL_PSL_Control_Fr;cxl_p1_write (adapter, CXL_PSL_Control, reg);
drivers/misc/cxl/pci.c +13 -6
@@ -456,6 +456,7 @@ static int init_implementation_adapter_ru64 chipid;u32 phb_index;u64 capp_unit_id; +u64 psl_debug;int rc; rc =cxl_calc_capp_routing (dev, &chipid, &phb_index, &capp_unit_id);
@@ -506,6 +507,16 @@ static int init_implementation_adapter_r }else cxl_p1_write (adapter,CXL_PSL9_DEBUG ,0x4000000000000000ULL ); +/* +* Check if PSL has data-cache. We need to flush adapter datacache +* when as its about to be removed. +*/ + psl_debug =cxl_p1_read (adapter,CXL_PSL9_DEBUG ); +if (psl_debug &CXL_PSL_DEBUG_CDC ) { +dev_dbg (&dev->dev,"No data-cache present\n" ); + adapter->native->no_data_cache = true; + } +return 0 ; }
@@ -1449,10 +1460,8 @@ int cxl_pci_reset(struct cxl *adapter)/* * The adapter is about to be reset, so ignore errors. -* Not supported on P9 DD1 */ -if ((cxl_is_power8 ()) || (!(cxl_is_power9_dd1 ()))) -cxl_data_cache_flush (adapter); +cxl_data_cache_flush (adapter);/* pcie_warm_reset requests a fundamental pci reset which includes a * PERST assert/deassert. PERST triggers a loading of the image
@@ -1936,10 +1945,8 @@ static void cxl_pci_remove_adapter(struc/* * Flush adapter datacache as its about to be removed. -* Not supported on P9 DD1. */ -if ((cxl_is_power8 ()) || (!(cxl_is_power9_dd1 ()))) -cxl_data_cache_flush (adapter); +cxl_data_cache_flush (adapter);cxl_deconfigure_adapter (adapter);
Greg Kroah-Hartman
maintainerPATCH 180/272 f2fs: fix to set KEEP_SIZE bit in f2fs_zero_range
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
[ Upstream commit 17cd07ae95073c298af92c1ba14ac58ce84de33b ]
As Jayashree Mohan reported:
A simple workload to reproduce this would be :
1. create foo
2. Write (8K - 16K) // foo size = 16K now
3. fsync()
4. falloc zero_range , keep_size (4202496 - 4210688) // foo size must be 16K
5. fdatasync()
Crash now
On recovery, we see that the file size is 4210688 and not 16K, which violates the semantics of keep_size flag. We have a test case to reproduce this using CrashMonkey on 4.15 kernel. Try this out by simply running :
./c_harness -f /dev/sda -d /dev/cow_ram0 -t f2fs -e 102400 -P -v tests/generic_468_zero.so
The root cause is that we miss to set KEEP_SIZE bit correctly in zero_range when zeroing block cross EOF with FALLOC_FL_KEEP_SIZE, let's fix this missing case.
--- fs/f2fs/file.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
fs/f2fs/file.c +6 -2
@@ -1348,8 +1348,12 @@ static int f2fs_zero_range(struct inode } out: -if (!(mode &FALLOC_FL_KEEP_SIZE ) &&i_size_read (inode) < new_size) -f2fs_i_size_write (inode, new_size); +if (new_size >i_size_read (inode)) { +if (mode &FALLOC_FL_KEEP_SIZE ) +file_set_keep_isize (inode); +else +f2fs_i_size_write (inode, new_size); + } out_sem:up_write (&F2FS_I (inode)->i_mmap_sem);
Greg Kroah-Hartman
maintainerPATCH 181/272 f2fs: fix to clear CP_TRIMMED_FLAG
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
[ Upstream commit cd36d7a17f9da68be9aa67185ba3ad7969934a19 ]
Once CP_TRIMMED_FLAG is set, after a reboot, we will never issue discard before LBA becomes invalid again, fix it by clearing the flag in checkpoint without CP_TRIMMED reason.
--- fs/f2fs/checkpoint.c | 2 ++ 1 file changed, 2 insertions(+)
fs/f2fs/checkpoint.c +2 -0
@@ -1136,6 +1136,8 @@ static void update_ckpt_flags(struct f2fif (cpc->reason &CP_TRIMMED )__set_ckpt_flags (ckpt,CP_TRIMMED_FLAG ); +else +__clear_ckpt_flags (ckpt,CP_TRIMMED_FLAG );if (cpc->reason &CP_UMOUNT )__set_ckpt_flags (ckpt,CP_UMOUNT_FLAG );
Greg Kroah-Hartman
maintainerPATCH 182/272 f2fs: fix to check extent cache in f2fs_drop_extent_tree
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
[ Upstream commit bf617f7a92edc6bb2909db2bfa4576f50b280ee5 ]
If noextent_cache mount option is on, we will never initialize extent tree in inode, but still we're going to access it in f2fs_drop_extent_tree, result in kernel panic as below:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: _raw_write_lock+0xc/0x30 Call Trace: ? f2fs_drop_extent_tree+0x41/0x70 [f2fs] f2fs_fallocate+0x5a0/0xdd0 [f2fs] ? common_file_perm+0x47/0xc0 ? apparmor_file_permission+0x1a/0x20 vfs_fallocate+0x15b/0x290 SyS_fallocate+0x44/0x70 do_syscall_64+0x6e/0x160 entry_SYSCALL64_slow_path+0x25/0x25
This patch fixes to check extent cache status before using in f2fs_drop_extent_tree.
--- fs/f2fs/extent_cache.c | 3 +++ 1 file changed, 3 insertions(+)
fs/f2fs/extent_cache.c +3 -0
@@ -706,6 +706,9 @@ void f2fs_drop_extent_tree(struct inodestruct f2fs_sb_info *sbi =F2FS_I_SB (inode);struct extent_tree *et =F2FS_I (inode)->extent_tree; +if (!f2fs_may_extent_tree (inode)) +return ; +set_inode_flag (inode,FI_NO_EXTENT );write_lock (&et->lock);
Greg Kroah-Hartman
maintainerPATCH 183/272 perf/core: Fix installing cgroup events on CPU
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: "leilei.lin" <[email protected]>
[ Upstream commit 33801b94741d6c3be9713c10aa627477216c21e2 ]
There's two problems when installing cgroup events on CPUs: firstly list_update_cgroup_event() only tries to set cpuctx->cgrp for the first event, if that mismatches on @cgrp we'll not try again for later additions.
Secondly, when we install a cgroup event into an active context, only issue an event reprogram when the event matches the current cgroup context. This avoids a pointless event reprogramming.
--- kernel/events/core.c | 46 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 35 insertions(+), 11 deletions(-)
kernel/events/core.c +35 -11
@@ -948,27 +948,39 @@ list_update_cgroup_event(struct perf_eveif (!is_cgroup_event (event))return ; -if (add && ctx->nr_cgroups++) -return ; -else if (!add && --ctx->nr_cgroups) -return ;/* * Because cgroup events are always per-cpu events, * this will always be called from the right CPU. */ cpuctx =__get_cpu_context (ctx); - cpuctx_entry = &cpuctx->cgrp_cpuctx_entry; -/* cpuctx->cgrp is NULL unless a cgroup event is active in this CPU .*/ -if (add) { + +/* +* Since setting cpuctx->cgrp is conditional on the current @cgrp +* matching the event's cgroup, we must do this for every new event, +* because if the first would mismatch, the second would not try again +* and we would leave cpuctx->cgrp unset. +*/ +if (add && !cpuctx->cgrp) {struct perf_cgroup *cgrp =perf_cgroup_from_task (current, ctx); -list_add (cpuctx_entry,this_cpu_ptr (&cgrp_cpuctx_list));if (cgroup_is_descendant (cgrp->css.cgroup, event->cgrp->css.cgroup)) cpuctx->cgrp = cgrp; - }else { -list_del (cpuctx_entry); - cpuctx->cgrp =NULL ; } + +if (add && ctx->nr_cgroups++) +return ; +else if (!add && --ctx->nr_cgroups) +return ; + +/* no cgroup running */ +if (!add) + cpuctx->cgrp =NULL ; + + cpuctx_entry = &cpuctx->cgrp_cpuctx_entry; +if (add) +list_add (cpuctx_entry,this_cpu_ptr (&cgrp_cpuctx_list)); +else + list_del(cpuctx_entry); }#else /* !CONFIG_CGROUP_PERF */
@@ -2328,6 +2340,18 @@ static int __perf_install_in_context(voraw_spin_lock (&task_ctx->lock); } +#ifdef CONFIG_CGROUP_PERF +if (is_cgroup_event (event)) { +/* +* If the current cgroup doesn't match the event's +* cgroup, we should not try to schedule it. +*/ +struct perf_cgroup *cgrp =perf_cgroup_from_task (current, ctx); + reprogram =cgroup_is_descendant (cgrp->css.cgroup, + event->cgrp->css.cgroup); + } +#endif +if (reprogram) {ctx_sched_out (ctx, cpuctx,EVENT_TIME );add_event_to_ctx (event, ctx);
Greg Kroah-Hartman
maintainerPATCH 184/272 max17042: propagate of_node to power supply device
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pierre Bourdon <[email protected]>
[ Upstream commit 66ec32fc7cd116dab5c02603ea8ec28ff92da3b5 ]
max17042_get_status uses the core power_supply_am_i_supplied. That function relies on DT properties to figure out the power supply topology, and will error out without DT.
Fixes max17042 battery status being reported as "unknown".
--- drivers/power/supply/max17042_battery.c | 1 + 1 file changed, 1 insertion(+)
drivers/power/supply/max17042_battery.c +1 -0
@@ -1053,6 +1053,7 @@ static int max17042_probe(struct i2c_clii2c_set_clientdata (client, chip); psy_cfg.drv_data = chip; + psy_cfg.of_node = dev->of_node;/* When current is not measured, * CURRENT_NOW and CURRENT_AVG properties should be invisible. */
Greg Kroah-Hartman
maintainerPATCH 185/272 perf/core: Fix perf_output_read_group()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
[ Upstream commit 9e5b127d6f33468143d90c8a45ca12410e4c3fa7 ]
Mark reported his arm64 perf fuzzer runs sometimes splat like:
armv8pmu_read_counter+0x1e8/0x2d8 armpmu_event_update+0x8c/0x188 armpmu_read+0xc/0x18 perf_output_read+0x550/0x11e8 perf_event_read_event+0x1d0/0x248 perf_event_exit_task+0x468/0xbb8 do_exit+0x690/0x1310 do_group_exit+0xd0/0x2b0 get_signal+0x2e8/0x17a8 do_signal+0x144/0x4f8 do_notify_resume+0x148/0x1e8 work_pending+0x8/0x14
which asserts that we only call pmu::read() on ACTIVE events.
The above callchain does:
perf_event_exit_task()
perf_event_exit_task_context()
task_ctx_sched_out() // INACTIVE
perf_event_exit_event()
perf_event_set_state(EXIT) // EXIT
sync_child_event()
perf_event_read_event()
perf_output_read()
perf_output_read_group()
leader->pmu->read()
Which results in doing a pmu::read() on an !ACTIVE event.
I _think_ this is 'new' since we added attr.inherit_stat, which added the perf_event_read_event() to the exit path, without that perf_event_read_output() would only trigger from samples and for @event to trigger a sample, it's leader _must_ be ACTIVE too.
Still, adding this check makes it consistent with the @sub case for the siblings.
--- kernel/events/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/events/core.c +2 -1
@@ -5770,7 +5770,8 @@ static void perf_output_read_group(strucif (read_format &PERF_FORMAT_TOTAL_TIME_RUNNING ) values[n++] = running; -if (leader != event) +if ((leader != event) && + (leader->state ==PERF_EVENT_STATE_ACTIVE )) leader->pmu->read (leader); values[n++] =perf_event_count (leader);
Greg Kroah-Hartman
maintainerPATCH 186/272 drm/panel: simple: Fix the bus format for the Ontat panel
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <[email protected]>
[ Upstream commit 5651e5e094591f479adad5830ac1bc45196a39b3 ]
This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel.
--- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/panel/panel-simple.c +1 -1
@@ -1597,7 +1597,7 @@ static const struct panel_desc ontat_yx7 .width = 154, .height = 83, }, - .bus_format = MEDIA_BUS_FMT_RGB888_1X24, + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, }; static const struct drm_display_mode ortustech_com43h4m85ulc_mode = {
Greg Kroah-Hartman
maintainerPATCH 187/272 hwmon: (pmbus/max8688) Accept negative page register values
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit a46f8cd696624ef757be0311eb28f119c36778e8 ]
A negative page register value means that no page needs to be selected. This is used by status register evaluations and needs to be accepted.
--- drivers/hwmon/pmbus/max8688.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/pmbus/max8688.c +1 -1
@@ -45,7 +45,7 @@ static int max8688_read_word_data(struct {int ret; -if (page) +if (page >0 )return -ENXIO ;switch (reg) {
Greg Kroah-Hartman
maintainerPATCH 188/272 hwmon: (pmbus/adm1275) Accept negative page register values
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit ecb29abd4cb0670c616fb563a078f25d777ce530 ]
A negative page register value means that no page needs to be selected. This is used by status register read operations and needs to be accepted. The failure to do so so results in missed status and limit registers.
--- drivers/hwmon/pmbus/adm1275.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hwmon/pmbus/adm1275.c +2 -2
@@ -154,7 +154,7 @@ static int adm1275_read_word_data(structconst struct adm1275_data *data =to_adm1275_data (info);int ret =0 ; -if (page) +if (page >0 )return -ENXIO ;switch (reg) {
@@ -240,7 +240,7 @@ static int adm1275_write_word_data(strucconst struct adm1275_data *data =to_adm1275_data (info);int ret; -if (page) +if (page >0 )return -ENXIO ;switch (reg) {
Greg Kroah-Hartman
maintainerPATCH 189/272 perf/x86/intel: Properly save/restore the PMU state in the NMI handler
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
[ Upstream commit 82d71ed0277efc45360828af8c4e4d40e1b45352 ]
The PMU is disabled in intel_pmu_handle_irq(), but cpuc->enabled is not updated accordingly.
This is fine in current usage because no-one checks it - but fix it for future code: for example, the drain_pebs() will be modified to fix an auto-reload bug.
Properly save/restore the old PMU state.
--- arch/x86/events/intel/core.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
arch/x86/events/intel/core.c +9 -1
@@ -2201,16 +2201,23 @@ static int intel_pmu_handle_irq(struct pint bit, loops;u64 status;int handled; +int pmu_enabled; cpuc =this_cpu_ptr (&cpu_hw_events);/* +* Save the PMU state. +* It needs to be restored when leaving the handler. +*/ + pmu_enabled = cpuc->enabled; +/* * No known reason to not always do late ACK, * but just in case do it opt-in. */ if (!x86_pmu.late_ack)apic_write (APIC_LVTPC ,APIC_DM_NMI );intel_bts_disable_local (); + cpuc->enabled =0 ;__intel_pmu_disable_all (); handled =intel_pmu_drain_bts_buffer (); handled +=intel_bts_interrupt ();
@@ -2320,7 +2327,8 @@ again: done:/* Only restore PMU state when it's active. See x86_pmu_disable(). */ -if (cpuc->enabled) + cpuc->enabled = pmu_enabled; +if (pmu_enabled)__intel_pmu_enable_all (0 , true);intel_bts_enable_local ();
Greg Kroah-Hartman
maintainerPATCH 190/272 cdrom: do not call check_disk_change() inside cdrom_open()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maurizio Lombardi <[email protected]>
[ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ]
when mounting an ISO filesystem sometimes (very rarely) the system hangs because of a race condition between two tasks.
PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount"
#0 [ffff880078447ae0] __schedule at ffffffff8168d605
#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49 #2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995 #3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod] #5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50 #6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3 #7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs] #8 [ffff880078447da8] mount_bdev at ffffffff81202570
#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
#10 [ffff880078447e28] mount_fs at ffffffff81202d09
#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f #12 [ffff880078447ea8] do_mount at ffffffff81220fee
#13 [ffff880078447f28] sys_mount at ffffffff812218d6
#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246
RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010
RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30
RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010
R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040
R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30
ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002bThis task was trying to mount the cdrom. It allocated and configured a super_block struct and owned the write-lock for the super_block->s_umount rwsem. While exclusively owning the s_umount lock, it called sr_block_ioctl and waited to acquire the global sr_mutex lock.
PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd"
#0 [ffff880078417898] __schedule at ffffffff8168d605
#1 [ffff880078417900] schedule at ffffffff8168dc59
#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605 #3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838 #4 [ffff8800784179d0] down_read at ffffffff8168cde0
#5 [ffff8800784179e8] get_super at ffffffff81201cc7
#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de #7 [ffff880078417a40] flush_disk at ffffffff8123a94b
#8 [ffff880078417a88] check_disk_change at ffffffff8123ab50 #9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod] #11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7 #15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
#16 [ffff880078417d00] do_last at ffffffff8120d53d
#17 [ffff880078417db0] path_openat at ffffffff8120e6b2
#18 [ffff880078417e48] do_filp_open at ffffffff8121082b
#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
#20 [ffff880078417f70] sys_open at ffffffff811fde4e
#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246
RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000
RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70
RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020
R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e
R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010
ORIG_RAX: 0000000000000002 CS: 0033 SS: 002bThis task tried to open the cdrom device, the sr_block_open function acquired the global sr_mutex lock. The call to check_disk_change() then saw an event flag indicating a possible media change and tried to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.
The first task acquires the s_umount lock and then the sr_mutex_lock; the second task acquires the sr_mutex_lock and then the s_umount lock.
This patch fixes the issue by moving check_disk_change() out of cdrom_open() and let the caller take care of it.
--- drivers/block/paride/pcd.c | 2 ++ drivers/cdrom/cdrom.c | 3 --- drivers/cdrom/gdrom.c | 3 +++ drivers/ide/ide-cd.c | 2 ++ drivers/scsi/sr.c | 2 ++ 5 files changed, 9 insertions(+), 3 deletions(-)
drivers/block/paride/pcd.c +2 -0
@@ -230,6 +230,8 @@ static int pcd_block_open(struct block_dstruct pcd_unit *cd = bdev->bd_disk->private_data;int ret; +check_disk_change (bdev); +mutex_lock (&pcd_mutex); ret =cdrom_open (&cd->info, bdev, mode);mutex_unlock (&pcd_mutex);
drivers/cdrom/cdrom.c +0 -3
@@ -1152,9 +1152,6 @@ int cdrom_open(struct cdrom_device_infocd_dbg (CD_OPEN ,"entering cdrom_open\n" ); -/* open is event synchronization point, check events first */ -check_disk_change (bdev); -/* if this was a O_NONBLOCK open and we should honor the flags, * do a quick open without drive/disc integrity checks. */ cdi->use_count++;
drivers/cdrom/gdrom.c +3 -0
@@ -497,6 +497,9 @@ static const struct cdrom_device_ops gdrstatic int gdrom_bdops_open (struct block_device *bdev,fmode_t mode) {int ret; + +check_disk_change (bdev); +mutex_lock (&gdrom_mutex); ret =cdrom_open (gd.cd_info, bdev, mode);mutex_unlock (&gdrom_mutex);
drivers/ide/ide-cd.c +2 -0
@@ -1613,6 +1613,8 @@ static int idecd_open(struct block_devicstruct cdrom_info *info;int rc = -ENXIO ; +check_disk_change (bdev); +mutex_lock (&ide_cd_mutex); info =ide_cd_get (bdev->bd_disk);if (!info)
drivers/scsi/sr.c +2 -0
@@ -525,6 +525,8 @@ static int sr_block_open(struct block_destruct scsi_cd *cd;int ret = -ENXIO ; +check_disk_change (bdev); +mutex_lock (&sr_mutex); cd =scsi_cd_get (bdev->bd_disk);if (cd) {
Greg Kroah-Hartman
maintainerPATCH 191/272 efi/arm*: Only register page tables when they exist
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 6b31a2fa1e8f7bc6c2a474b4a12dad7a145cf83d ]
Currently the arm/arm64 runtime code registers the runtime servies pagetables with ptdump regardless of whether runtime services page tables have been created.
As efi_mm.pgd is NULL in these cases, attempting to dump the efi page tables results in a NULL pointer dereference in the ptdump code:
/sys/kernel/debug# cat efi_page_tables
[ 479.522600] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 479.522715] Mem abort info: [ 479.522764] ESR = 0x96000006 [ 479.522850] Exception class = DABT (current EL), IL = 32 bits [ 479.522899] SET = 0, FnV = 0 [ 479.522937] EA = 0, S1PTW = 0 [ 479.528200] Data abort info: [ 479.528230] ISV = 0, ISS = 0x00000006 [ 479.528317] CM = 0, WnR = 0 [ 479.528317] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000064ab0cb0 [ 479.528449] [0000000000000000] *pgd=00000000fbbe4003, *pud=00000000fb66e003, *pmd=0000000000000000 [ 479.528600] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 479.528664] Modules linked in: [ 479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7 [ 479.528799] Hardware name: FVP Base (DT) [ 479.528899] pstate: 00400009 (nzcv daif +PAN -UAO) [ 479.528941] pc : walk_pgd.isra.1+0x20/0x1d0 [ 479.529011] lr : ptdump_walk_pgd+0x30/0x50 [ 479.529105] sp : ffff00000bf4bc20 [ 479.529185] x29: ffff00000bf4bc20 x28: 0000ffff9d22e000 [ 479.529271] x27: 0000000000020000 x26: ffff80007b4c63c0 [ 479.529358] x25: 00000000014000c0 x24: ffff80007c098900 [ 479.529445] x23: ffff00000bf4beb8 x22: 0000000000000000 [ 479.529532] x21: ffff00000bf4bd70 x20: 0000000000000001 [ 479.529618] x19: ffff00000bf4bcb0 x18: 0000000000000000 [ 479.529760] x17: 000000000041a1c8 x16: ffff0000082139d8 [ 479.529800] x15: 0000ffff9d3c6030 x14: 0000ffff9d2527f4 [ 479.529924] x13: 00000000000003f3 x12: 0000000000000038 [ 479.530000] x11: 0000000000000003 x10: 0101010101010101 [ 479.530099] x9 : 0000000017e94050 x8 : 000000000000003f [ 479.530226] x7 : 0000000000000000 x6 : 0000000000000000 [ 479.530313] x5 : 0000000000000001 x4 : 0000000000000000 [ 479.530416] x3 : ffff000009069fd8 x2 : 0000000000000000 [ 479.530500] x1 : 0000000000000000 x0 : 0000000000000000 [ 479.530599] Process cat (pid: 2457, stack limit = 0x000000005d1b0e6f) [ 479.530660] Call trace: [ 479.530746] walk_pgd.isra.1+0x20/0x1d0 [ 479.530833] ptdump_walk_pgd+0x30/0x50 [ 479.530907] ptdump_show+0x10/0x20 [ 479.530920] seq_read+0xc8/0x470 [ 479.531023] full_proxy_read+0x60/0x90 [ 479.531100] __vfs_read+0x18/0x100 [ 479.531180] vfs_read+0x88/0x160 [ 479.531267] SyS_read+0x48/0xb0 [ 479.531299] el0_svc_naked+0x20/0x24 [ 479.531400] Code: 91400420 f90033a0 a90707a2 f9403fa0 (f9400000) [ 479.531499] ---[ end trace bfe8e28d8acb2b67 ]---
Segmentation fault
Let's avoid this problem by only registering the tables after their successful creation, which is also less confusing when EFI runtime services are not in use.
--- drivers/firmware/efi/arm-runtime.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/firmware/efi/arm-runtime.c +3 -0
@@ -54,6 +54,9 @@ static struct ptdump_info efi_ptdump_infstatic int __init ptdump_init (void ) { +if (!efi_enabled (EFI_RUNTIME_SERVICES )) +return 0 ; +return ptdump_debugfs_register (&efi_ptdump_info,"efi_page_tables" ); }device_initcall (ptdump_init);
Greg Kroah-Hartman
maintainerPATCH 192/272 perf/x86/intel: Fix large period handling on Broadwell CPUs
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
[ Upstream commit f605cfca8c39ffa2b98c06d2b9f30ba64f1e54e3 ]
Large fixed period values could be truncated on Broadwell, for example:
perf record -e cycles -c 10000000000
Here the fixed period is 0x2540BE400, but the period which finally applied is 0x540BE400 - which is wrong.
The reason is that x86_pmu::limit_period() uses an u32 parameter, so the high 32 bits of 'period' get truncated.
This bug was introduced in:
commit 294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds")
It's safe to use u64 instead of u32:
- Although the 'left' is s64, the value of 'left' must be positive when calling limit_period().
- bdw_limit_period() only modifies the lowest 6 bits, it doesn't touch the higher 32 bits.
--- arch/x86/events/intel/core.c | 2 +- arch/x86/events/perf_event.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/x86/events/intel/core.c +1 -1
@@ -3196,7 +3196,7 @@ glp_get_event_constraints(struct cpu_hw_* Therefore the effective (average) period matches the requested period, * despite coarser hardware granularity. */ -static unsigned bdw_limit_period (struct perf_event *event,unsigned left) +static u64 bdw_limit_period (struct perf_event *event,u64 left) {if ((event->hw.config &INTEL_ARCH_EVENT_MASK ) == X86_CONFIG(.event=0xc0, .umask=0x01)) {
arch/x86/events/perf_event.h +1 -1
@@ -557,7 +557,7 @@ struct x86_pmu {struct x86_pmu_quirk *quirks;int perfctr_second_write;bool late_ack; -unsigned (*limit_period)(struct perf_event *event,unsigned l); +u64 (*limit_period)(struct perf_event *event,u64 l);/* * sysfs attrs
Greg Kroah-Hartman
maintainerPATCH 193/272 perf/x86/intel: Fix event update for auto-reload
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
[ Upstream commit d31fc13fdcb20e1c317f9a7dd6273c18fbd58308 ]
There is a bug when reading event->count with large PEBS enabled.
Here is an example:
# ./read_count 0x71f0 0x122c0 0x1000000001c54 0x100000001257d 0x200000000bdc5
In fixed period mode, the auto-reload mechanism could be enabled for PEBS events, but the calculation of event->count does not take the auto-reload values into account.
Anyone who reads event->count will get the wrong result, e.g x86_pmu_read().
This bug was introduced with the auto-reload mechanism enabled since commit:
851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible")
Introduce intel_pmu_save_and_restart_reload() to calculate the event->count only for auto-reload.
Since the counter increments a negative counter value and overflows on the sign switch, giving the interval:
[-period, 0]
the difference between two consequtive reads is:
A) value2 - value1;
when no overflows have happened in between,
B) (0 - value1) + (value2 - (-period));
when one overflow happened in between,
C) (0 - value1) + (n - 1) * (period) + (value2 - (-period)); when @n overflows happened in between.
Here A) is the obvious difference, B) is the extension to the discrete interval, where the first term is to the top of the interval and the second term is from the bottom of the next interval and C) the extension to multiple intervals, where the middle term is the whole intervals covered.
The equation for all cases is:
value2 - value1 + n * period
Previously the event->count is updated right before the sample output. But for case A, there is no PEBS record ready. It needs to be specially handled.
Remove the auto-reload code from x86_perf_event_set_period() since we'll not longer call that function in this case.
Based-on-code-from: Peter Zijlstra (Intel) <[email protected]>
--- arch/x86/events/core.c | 15 ++----- arch/x86/events/intel/ds.c | 92 +++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 94 insertions(+), 13 deletions(-)
arch/x86/events/core.c +6 -9
@@ -1162,16 +1162,13 @@ int x86_perf_event_set_period(struct perper_cpu (pmc_prev_left[idx],smp_processor_id ()) = left; -if (!(hwc->flags &PERF_X86_EVENT_AUTO_RELOAD ) || -local64_read (&hwc->prev_count) != (u64)-left) { -/* -* The hw event starts counting from this event offset, -* mark it to be able to extra future deltas: -*/ -local64_set (&hwc->prev_count, (u64)-left); +/* +* The hw event starts counting from this event offset, +* mark it to be able to extra future deltas: +*/ +local64_set (&hwc->prev_count, (u64)-left); -wrmsrl (hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask); - } +wrmsrl (hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);/* * Due to erratum on certan cpu we need
arch/x86/events/intel/ds.c +88 -4
121 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 194/272 arm64: dts: qcom: Fix SPI5 config on MSM8996
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilia Lin <[email protected]>
[ Upstream commit e723795c702b52cfceb3bb3faa63059eb4658313 ]
Set correct clocks and interrupt values. Fixes the incorrect SPI master configuration. This is mandatory to make the SPI5 interface functional.
--- arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/qcom/msm8996.dtsi +2 -2
@@ -497,8 +497,8 @@ blsp2_spi5: spi@75ba000{ compatible = "qcom,spi-qup-v2.2.1"; reg = <0x075ba000 0x600>; - interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&gcc GCC_BLSP2_QUP5_SPI_APPS_CLK>, + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GCC_BLSP2_QUP6_SPI_APPS_CLK>, <&gcc GCC_BLSP2_AHB_CLK>; clock-names = "core", "iface"; pinctrl-names = "default", "sleep";
Greg Kroah-Hartman
maintainerPATCH 195/272 soc: qcom: wcnss_ctrl: Fix increment in NV upload
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit 90c29ed7627b6b4aeb603ee197650173c8434512 ]
hdr.len includes both the size of the header and the fragment, so using this when stepping through the firmware causes us to skip 16 bytes every chunk of 3072 bytes; causing only the first fragment to actually be valid data.
Instead use fragment size steps through the firmware blob.
--- drivers/soc/qcom/wcnss_ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soc/qcom/wcnss_ctrl.c +1 -1
@@ -249,7 +249,7 @@ static int wcnss_download_nv(struct wcns/* Increment for next fragment */ req->seq++; - data += req->hdr.len; + data +=NV_FRAGMENT_SIZE ; left -=NV_FRAGMENT_SIZE ; }while (left >0 );
Greg Kroah-Hartman
maintainerPATCH 196/272 gfs2: Fix fallocate chunk size
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Gruenbacher <[email protected]>
[ Upstream commit 174d1232ebc84fcde8f5889d1171c9c7e74a10a7 ]
The chunk size of allocations in __gfs2_fallocate is calculated incorrectly. The size can collapse, causing __gfs2_fallocate to allocate one block at a time, which is very inefficient. This needs fixing in two places:
In gfs2_quota_lock_check, always set ap->allowed to UINT_MAX to indicate that there is no quota limit. This fixes callers that rely on ap->allowed to be set even when quotas are off.
In __gfs2_fallocate, reset max_blks to UINT_MAX in each iteration of the loop to make sure that allocation limits from one resource group won't spill over into another resource group.
--- fs/gfs2/file.c | 5 +++-- fs/gfs2/quota.h | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-)
fs/gfs2/file.c +3 -2
@@ -809,7 +809,7 @@ static long __gfs2_fallocate(struct filestruct gfs2_inode *ip =GFS2_I (inode);struct gfs2_alloc_parms ap = { .aflags =0 , };unsigned int data_blocks =0 , ind_blocks =0 , rblocks; -loff_t bytes, max_bytes, max_blks =UINT_MAX ; +loff_t bytes, max_bytes, max_blks;int error;const loff_t pos = offset;const loff_t count = len;
@@ -861,7 +861,8 @@ static long __gfs2_fallocate(struct filereturn error;/* ap.allowed tells us how many blocks quota will allow * us to write. Check if this reduces max_blks */ -if (ap.allowed && ap.allowed < max_blks) + max_blks =UINT_MAX ; +if (ap.allowed) max_blks = ap.allowed; error =gfs2_inplace_reserve (ip, &ap);
fs/gfs2/quota.h +2 -0
@@ -45,6 +45,8 @@ static inline int gfs2_quota_lock_check( {struct gfs2_sbd *sdp =GFS2_SB (&ip->i_inode);int ret; + + ap->allowed =UINT_MAX ;/* Assume we are permitted a whole lot */ if (sdp->sd_args.ar_quota ==GFS2_QUOTA_OFF )return 0 ; ret =gfs2_quota_lock (ip,NO_UID_QUOTA_CHANGE ,NO_GID_QUOTA_CHANGE );
Greg Kroah-Hartman
maintainerPATCH 197/272 x86/devicetree: Initialize device tree before using it
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Gorinov <[email protected]>
[ Upstream commit 628df9dc5ad886b0a9b33c75a7b09710eb859ca1 ]
Commit 08d53aa58cb1 added CRC32 calculation in early_init_dt_verify() and checking in late initcall of_fdt_raw_init(), making early_init_dt_verify() mandatory.
The required call to early_init_dt_verify() was not added to the x86-specific implementation, causing failure to create the sysfs entry in of_fdt_raw_init().
--- arch/x86/kernel/devicetree.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/x86/kernel/devicetree.c +5 -3
@@ -11,6 +11,7 @@#include <linux/of_address.h> #include <linux/of_platform.h> #include <linux/of_irq.h> +#include <linux/libfdt.h> #include <linux/slab.h> #include <linux/pci.h> #include <linux/of_pci.h>
@@ -270,14 +271,15 @@ static void __init x86_flattree_get_conf map_len =max (PAGE_SIZE - (initial_dtb & ~PAGE_MASK ), (u64 )128 ); - initial_boot_params = dt =early_memremap (initial_dtb, map_len); - size =of_get_flat_dt_size (); + dt =early_memremap (initial_dtb, map_len); + size =fdt_totalsize (dt);if (map_len < size) {early_memunmap (dt, map_len); - initial_boot_params = dt =early_memremap (initial_dtb, size); + dt =early_memremap (initial_dtb, size); map_len = size; } +early_init_dt_verify (dt);unflatten_and_copy_device_tree ();early_memunmap (dt, map_len); }
Greg Kroah-Hartman
maintainerPATCH 198/272 x86/devicetree: Fix device IRQ settings in DT
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Gorinov <[email protected]>
[ Upstream commit 0a5169add90e43ab45ab1ba34223b8583fcaf675 ]
IRQ parameters for the SoC devices connected directly to I/O APIC lines (without PCI IRQ routing) may be specified in the Device Tree.
Called from DT IRQ parser, irq_create_fwspec_mapping() calls irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg.
But x86-specific DT IRQ allocation code casts @arg to of_phandle_args structure pointer and crashes trying to read the IRQ parameters. The function was not converted when the mapping descriptor was changed to irq_fwspec in the generic irqdomain code.
--- arch/x86/kernel/devicetree.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
arch/x86/kernel/devicetree.c +8 -5
@@ -195,19 +195,22 @@ static struct of_ioapic_type of_ioapic_tstatic int dt_irqdomain_alloc (struct irq_domain *domain,unsigned int virq,unsigned int nr_irqs,void *arg) { -struct of_phandle_args *irq_data = (void *)arg; +struct irq_fwspec *fwspec = (struct irq_fwspec *)arg;struct of_ioapic_type *it;struct irq_alloc_info tmp; +int type_index; -if (WARN_ON (irq_data->args_count <2 )) +if (WARN_ON (fwspec->param_count <2 ))return -EINVAL ; -if (irq_data->args[1 ] >=ARRAY_SIZE (of_ioapic_type)) + + type_index = fwspec->param[1 ]; +if (type_index >=ARRAY_SIZE (of_ioapic_type))return -EINVAL ; - it = &of_ioapic_type[irq_data->args[1 ]]; + it = &of_ioapic_type[type_index];ioapic_set_alloc_attr (&tmp,NUMA_NO_NODE , it->trigger, it->polarity); tmp.ioapic_id =mpc_ioapic_id (mp_irqdomain_ioapic_idx (domain)); - tmp.ioapic_pin = irq_data->args[0 ]; + tmp.ioapic_pin = fwspec->param[0 ];return mp_irqdomain_alloc (domain, virq, nr_irqs, &tmp); }
Greg Kroah-Hartman
maintainerPATCH 199/272 phy: rockchip-emmc: retry calpad busy trimming
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Lin <[email protected]>
[ Upstream commit a4781c2a74b249cad814ceea7272997bbd20051e ]
It turns out that 5us isn't enough for all cases, so let's retry some more times to wait for caldone.
--- drivers/phy/rockchip/phy-rockchip-emmc.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-)
drivers/phy/rockchip/phy-rockchip-emmc.c +17 -10
@@ -76,6 +76,10 @@#define PHYCTRL_OTAPDLYSEL_MASK 0xf#define PHYCTRL_OTAPDLYSEL_SHIFT 0x7 +#define PHYCTRL_IS_CALDONE (x) \ + ((((x) >> PHYCTRL_CALDONE_SHIFT) & \ + PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE) +struct rockchip_emmc_phy {unsigned int reg_offset;struct regmap *reg_base;
@@ -90,6 +94,7 @@ static int rockchip_emmc_phy_power(strucunsigned int freqsel =PHYCTRL_FREQSEL_200M ;unsigned long rate;unsigned long timeout; +int ret;/* * Keep phyctrl_pdb and phyctrl_endll low to allow
@@ -160,17 +165,19 @@ static int rockchip_emmc_phy_power(struc PHYCTRL_PDB_SHIFT));/* -* According to the user manual, it asks driver to -* wait 5us for calpad busy trimming +* According to the user manual, it asks driver to wait 5us for +* calpad busy trimming. However it is documented that this value is +* PVT(A.K.A process,voltage and temperature) relevant, so some +* failure cases are found which indicates we should be more tolerant +* to calpad busy trimming. */ -udelay (5 ); -regmap_read (rk_phy->reg_base, - rk_phy->reg_offset +GRF_EMMCPHY_STATUS , - &caldone); - caldone = (caldone >>PHYCTRL_CALDONE_SHIFT ) &PHYCTRL_CALDONE_MASK ; -if (caldone !=PHYCTRL_CALDONE_DONE ) { -pr_err ("rockchip_emmc_phy_power: caldone timeout.\n" ); -return -ETIMEDOUT ; + ret =regmap_read_poll_timeout (rk_phy->reg_base, + rk_phy->reg_offset +GRF_EMMCPHY_STATUS , + caldone,PHYCTRL_IS_CALDONE (caldone), +0 ,50 ); +if (ret) { +pr_err ("%s: caldone failed, ret=%d\n" , __func__, ret); +return ret; }/* Set the frequency of the DLL operation */
Greg Kroah-Hartman
maintainerPATCH 200/272 ALSA: vmaster: Propagate slave error
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
[ Upstream commit 2e2c177ca84aff092c3c96714b0f6a12900f3946 ]
In slave_update() of vmaster code ignores the error from the slave get() callback and copies the values. It's not only about the missing error code but also that this may potentially lead to a leak of uninitialized variables when the slave get() don't clear them.
This patch fixes slave_update() not to copy the potentially uninitialized values when an error is returned from the slave get() callback, and to propagate the error value properly.
--- sound/core/vmaster.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
sound/core/vmaster.c +4 -1
@@ -68,10 +68,13 @@ static int slave_update(struct link_slavreturn -ENOMEM ; uctl->id = slave->slave.id; err = slave->slave.get (&slave->slave, uctl); +if (err <0 ) + goto error;for (ch =0 ; ch < slave->info.count; ch++) slave->vals[ch] = uctl->value.integer.value[ch]; + error:kfree (uctl); -return 0 ; +return err <0 ? err :0 ; }/* get the slave ctl info and save the initial values */
Greg Kroah-Hartman
maintainerPATCH 201/272 phy: qcom-qmp: Fix phy pipe clock gating
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Gautam <[email protected]>
[ Upstream commit f8ba22a39e985c93e278709b1d5f20857a26b49b ]
Pipe clock comes out of the phy and is available as long as the phy is turned on. Clock controller fails to gate this clock after the phy is turned off and generates a warning.
/ # [ 33.048561] gcc_usb3_phy_pipe_clk status stuck at 'on'
[ 33.048585] ------------[ cut here ]------------ [ 33.052621] WARNING: CPU: 1 PID: 18 at ../drivers/clk/qcom/clk-branch.c:97 clk_branch_wait+0xf0/0x108 [ 33.057384] Modules linked in: [ 33.066497] CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G W 4.12.0-rc7-00024-gfe926e34c36d-dirty #96 [ 33.069451] Hardware name: Qualcomm Technologies, Inc. DB820c (DT) ... [ 33.278565] [<ffff00000849b27c>] clk_branch_wait+0xf0/0x108 [ 33.286375] [<ffff00000849b2f4>] clk_branch2_disable+0x28/0x34 [ 33.291761] [<ffff0000084868dc>] clk_core_disable+0x5c/0x88 [ 33.297660] [<ffff000008487d68>] clk_core_disable_lock+0x20/0x34 [ 33.303129] [<ffff000008487d98>] clk_disable+0x1c/0x24 [ 33.309384] [<ffff0000083ccd78>] qcom_qmp_phy_poweroff+0x20/0x48 [ 33.314328] [<ffff0000083c53f4>] phy_power_off+0x80/0xdc [ 33.320492] [<ffff00000875c950>] dwc3_core_exit+0x94/0xa0 [ 33.325784] [<ffff00000875c9ac>] dwc3_suspend_common+0x50/0x60 [ 33.331080] [<ffff00000875ca04>] dwc3_runtime_suspend+0x48/0x6c [ 33.336810] [<ffff0000085b82f4>] pm_generic_runtime_suspend+0x28/0x38 [ 33.342627] [<ffff0000085bace0>] __rpm_callback+0x150/0x254 [ 33.349222] [<ffff0000085bae08>] rpm_callback+0x24/0x78 [ 33.354604] [<ffff0000085b9fd8>] rpm_suspend+0xe0/0x4e4 [ 33.359813] [<ffff0000085bb784>] pm_runtime_work+0xdc/0xf0 [ 33.365028] [<ffff0000080d7b30>] process_one_work+0x12c/0x28c [ 33.370576] [<ffff0000080d7ce8>] worker_thread+0x58/0x3b8 [ 33.376393] [<ffff0000080dd4a8>] kthread+0x100/0x12c [ 33.381776] [<ffff0000080836c0>] ret_from_fork+0x10/0x50
Fix this by disabling it as the first thing in phy_exit().
--- drivers/phy/qualcomm/phy-qcom-qmp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/phy/qualcomm/phy-qcom-qmp.c +2 -2
@@ -751,8 +751,6 @@ static int qcom_qmp_phy_poweroff(structstruct qmp_phy *qphy =phy_get_drvdata (phy);struct qcom_qmp *qmp = qphy->qmp; -clk_disable_unprepare (qphy->pipe_clk); -regulator_bulk_disable (qmp->cfg->num_vregs, qmp->vregs);return 0 ;
@@ -936,6 +934,8 @@ static int qcom_qmp_phy_exit(struct phyconst struct qmp_phy_cfg *cfg = qmp->cfg;int i = cfg->num_clks; +clk_disable_unprepare (qphy->pipe_clk); +/* PHY reset */ qphy_setbits (qphy->pcs, cfg->regs[QPHY_SW_RESET ],SW_RESET );
Greg Kroah-Hartman
maintainerPATCH 204/272 tools: hv: fix compiler warnings about major/target_fname
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dexuan Cui <[email protected]>
[ Upstream commit 1330fc35327f3ecdfa1aa645e7321ced7349b2cd ]
This patch fixes the below warnings with new glibc and gcc:
hv_vss_daemon.c:100:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is currently
defined by <sys/types.h> as well, but we plan to remove this soon. To use "major", include <sys/sysmacros.h> directly.
hv_fcopy_daemon.c:42:2: note: 'snprintf' output between 2 and 1040 bytes into a destination of size 260
--- tools/hv/hv_fcopy_daemon.c | 3 ++- tools/hv/hv_vss_daemon.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)
tools/hv/hv_fcopy_daemon.c +2 -1
@@ -23,13 +23,14 @@#include <unistd.h> #include <errno.h> #include <linux/hyperv.h> +#include <linux/limits.h> #include <syslog.h> #include <sys/stat.h> #include <fcntl.h> #include <getopt.h> static int target_fd; -static char target_fname[W_MAX_PATH ]; +static char target_fname[PATH_MAX ];static unsigned long long filesize;static int hv_start_fcopy (struct hv_start_fcopy *smsg)
tools/hv/hv_vss_daemon.c +1 -0
@@ -22,6 +22,7 @@#include <sys/poll.h> #include <sys/ioctl.h> #include <sys/stat.h> +#include <sys/sysmacros.h> #include <fcntl.h> #include <stdio.h> #include <mntent.h>
Greg Kroah-Hartman
maintainerPATCH 205/272 block: null_blk: fix Invalid parameters when loading module
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <[email protected]>
[ Upstream commit 66231ad3e2886ba99fbf440cea44cab547e5163f ]
On ARM64, the default page size has been 64K on some distributions, and we should allow ARM64 people to play null_blk.
This patch fixes the issue by extend page bitmap size for supporting other non-4KB PAGE_SIZE.
--- drivers/block/null_blk.c | 46 +++++++++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 21 deletions(-)
drivers/block/null_blk.c +25 -21
@@ -72,6 +72,7 @@ enum nullb_device_flags { NULLB_DEV_FL_CACHE = 3, }; +#define MAP_SZ ((PAGE_SIZE >> SECTOR_SHIFT) + 2)/* * nullb_page is a page in memory for nullb devices. *
@@ -86,10 +87,10 @@ enum nullb_device_flags {*/ struct nullb_page {struct page *page; -unsigned long bitmap; + DECLARE_BITMAP(bitmap, MAP_SZ); }; -#define NULLB_PAGE_LOCK (sizeof(unsigned long) * 8 - 1) -#define NULLB_PAGE_FREE (sizeof(unsigned long) * 8 - 2) +#define NULLB_PAGE_LOCK (MAP_SZ - 1) +#define NULLB_PAGE_FREE (MAP_SZ - 2)struct nullb_device {struct nullb *nullb;
@@ -728,7 +729,7 @@ static struct nullb_page *null_alloc_pagif (!t_page->page) goto out_freepage; - t_page->bitmap =0 ; +memset (t_page->bitmap,0 ,sizeof (t_page->bitmap));return t_page; out_freepage:kfree (t_page);
@@ -738,13 +739,20 @@ out:static void null_free_page (struct nullb_page *t_page) { -__set_bit (NULLB_PAGE_FREE , &t_page->bitmap); -if (test_bit (NULLB_PAGE_LOCK , &t_page->bitmap)) +__set_bit (NULLB_PAGE_FREE , t_page->bitmap); +if (test_bit (NULLB_PAGE_LOCK , t_page->bitmap))return ;__free_page (t_page->page);kfree (t_page); } +static bool null_page_empty (struct nullb_page *page) +{ +int size =MAP_SZ -2 ; + +return find_first_bit (page->bitmap, size) == size; +} +static void null_free_sector (struct nullb *nullb,sector_t sector,bool is_cache) {
@@ -759,9 +767,9 @@ static void null_free_sector(struct null t_page =radix_tree_lookup (root, idx);if (t_page) { -__clear_bit (sector_bit, &t_page->bitmap); +__clear_bit (sector_bit, t_page->bitmap); -if (!t_page->bitmap) { +if (null_page_empty (t_page)) { ret =radix_tree_delete_item (root, idx, t_page);WARN_ON (ret != t_page);null_free_page (ret);
@@ -832,7 +840,7 @@ static struct nullb_page *__null_lookup_ t_page =radix_tree_lookup (root, idx);WARN_ON (t_page && t_page->page->index != idx); -if (t_page && (for_write ||test_bit (sector_bit, &t_page->bitmap))) +if (t_page && (for_write ||test_bit (sector_bit, t_page->bitmap)))return t_page;return NULL ;
@@ -895,10 +903,10 @@ static int null_flush_cache_page(struct t_page =null_insert_page (nullb, idx <<PAGE_SECTORS_SHIFT , true); -__clear_bit (NULLB_PAGE_LOCK , &c_page->bitmap); -if (test_bit (NULLB_PAGE_FREE , &c_page->bitmap)) { +__clear_bit (NULLB_PAGE_LOCK , c_page->bitmap); +if (test_bit (NULLB_PAGE_FREE , c_page->bitmap)) {null_free_page (c_page); -if (t_page && t_page->bitmap ==0 ) { +if (t_page &&null_page_empty (t_page)) { ret =radix_tree_delete_item (&nullb->dev->data, idx, t_page);null_free_page (t_page);
@@ -914,11 +922,11 @@ static int null_flush_cache_page(structfor (i =0 ; i <PAGE_SECTORS ; i += (nullb->dev->blocksize >>SECTOR_SHIFT )) { -if (test_bit (i, &c_page->bitmap)) { +if (test_bit (i, c_page->bitmap)) { offset = (i <<SECTOR_SHIFT );memcpy (dst + offset, src + offset, nullb->dev->blocksize); -__set_bit (i, &t_page->bitmap); +__set_bit (i, t_page->bitmap); } }
@@ -955,10 +963,10 @@ again:* We found the page which is being flushed to disk by other * threads */ -if (test_bit (NULLB_PAGE_LOCK , &c_pages[i]->bitmap)) +if (test_bit (NULLB_PAGE_LOCK , c_pages[i]->bitmap)) c_pages[i] =NULL ;else -__set_bit (NULLB_PAGE_LOCK , &c_pages[i]->bitmap); +__set_bit (NULLB_PAGE_LOCK , c_pages[i]->bitmap); } one_round =0 ;
@@ -1011,7 +1019,7 @@ static int copy_to_nullb(struct nullb *nkunmap_atomic (dst);kunmap_atomic (src); -__set_bit (sector &SECTOR_MASK , &t_page->bitmap); +__set_bit (sector &SECTOR_MASK , t_page->bitmap);if (is_fua)null_free_sector (nullb, sector, true);
@@ -1802,10 +1810,6 @@ static int __init null_init(void)struct nullb *nullb;struct nullb_device *dev; -/* check for nullb_page.bitmap */ -if (sizeof (unsigned long ) *8 -2 < (PAGE_SIZE >>SECTOR_SHIFT )) -return -EINVAL ; -if (g_bs >PAGE_SIZE ) {pr_warn ("null_blk: invalid block size\n" );pr_warn ("null_blk: defaults block size to %lu\n" ,PAGE_SIZE );
Greg Kroah-Hartman
maintainerPATCH 206/272 dmaengine: pl330: fix a race condition in case of threaded irqs
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qi Hou <[email protected]>
[ Upstream commit a3ca831249ca8c4c226e4ceafee04e280152e59d ]
When booting up with "threadirqs" in command line, all irq handlers of the DMA controller pl330 will be threaded forcedly. These threads will race for the same list, pl330->req_done.
Before the callback, the spinlock was released. And after it, the spinlock was taken. This opened an race window where another threaded irq handler could steal the spinlock and be permitted to delete entries of the list, pl330->req_done.
If the later deleted an entry that was still referred to by the former, there would be a kernel panic when the former was scheduled and tried to get the next sibling of the deleted entry.
The scenario could be depicted as below:
Thread: T1 pl330->req_done Thread: T2
| | |
| -A-B-C-D- |
Locked | |
| | Waiting
Del A | |
| -B-C-D- |
Unlocked | |
| | Locked
Waiting | |
| | Del B
| | |
| -C-D- Unlocked
Waiting | |
|
Locked
| get C via B
\
- Kernel panic
The kernel panic looked like as below:
Unable to handle kernel paging request at virtual address dead000000000108 pgd = ffffff8008c9e000 [dead000000000108] *pgd=000000027fffe003, *pud=000000027fffe003, *pmd=0000000000000000 Internal error: Oops: 96000044 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 85 Comm: irq/59-66330000 Not tainted 4.8.24-WR9.0.0.12_standard #2 Hardware name: Broadcom NS2 SVK (DT) task: ffffffc1f5cc3c00 task.stack: ffffffc1f5ce0000 PC is at pl330_irq_handler+0x27c/0x390 LR is at pl330_irq_handler+0x2a8/0x390 pc : [<ffffff80084cb694>] lr : [<ffffff80084cb6c0>] pstate: 800001c5
sp : ffffffc1f5ce3d00
x29: ffffffc1f5ce3d00 x28: 0000000000000140
x27: ffffffc1f5c530b0 x26: dead000000000100
x25: dead000000000200 x24: 0000000000418958
x23: 0000000000000001 x22: ffffffc1f5ccd668
x21: ffffffc1f5ccd590 x20: ffffffc1f5ccd418
x19: dead000000000060 x18: 0000000000000001
x17: 0000000000000007 x16: 0000000000000001
x15: ffffffffffffffff x14: ffffffffffffffff
x13: ffffffffffffffff x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000840
x9 : ffffffc1f5ce0000 x8 : ffffffc1f5cc3338
x7 : ffffff8008ce2020 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001
x3 : dead000000000200 x2 : dead000000000100
x1 : 0000000000000140 x0 : ffffffc1f5ccd590
Process irq/59-66330000 (pid: 85, stack limit = 0xffffffc1f5ce0020)
Stack: (0xffffffc1f5ce3d00 to 0xffffffc1f5ce4000)
3d00: ffffffc1f5ce3d80 ffffff80080f09d0 ffffffc1f5ca0c00 ffffffc1f6f7c600 3d20: ffffffc1f5ce0000 ffffffc1f6f7c600 ffffffc1f5ca0c00 ffffff80080f0998 3d40: ffffffc1f5ce0000 ffffff80080f0000 0000000000000000 0000000000000000 3d60: ffffff8008ce202c ffffff8008ce2020 ffffffc1f5ccd668 ffffffc1f5c530b0 3d80: ffffffc1f5ce3db0 ffffff80080f0d70 ffffffc1f5ca0c40 0000000000000001 3da0: ffffffc1f5ce0000 ffffff80080f0cfc ffffffc1f5ce3e20 ffffff80080bf4f8 3dc0: ffffffc1f5ca0c80 ffffff8008bf3798 ffffff8008955528 ffffffc1f5ca0c00 3de0: ffffff80080f0c30 0000000000000000 0000000000000000 0000000000000000 3e00: 0000000000000000 0000000000000000 0000000000000000 ffffff80080f0b68 3e20: 0000000000000000 ffffff8008083690 ffffff80080bf420 ffffffc1f5ca0c80 3e40: 0000000000000000 0000000000000000 0000000000000000 ffffff80080cb648 3e60: ffffff8008b1c780 0000000000000000 0000000000000000 ffffffc1f5ca0c00 3e80: ffffffc100000000 ffffff8000000000 ffffffc1f5ce3e90 ffffffc1f5ce3e90 3ea0: 0000000000000000 ffffff8000000000 ffffffc1f5ce3eb0 ffffffc1f5ce3eb0 3ec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 3fc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000 3fe0: 0000000000000000 0000000000000000 0000000275ce3ff0 0000000275ce3ff8
Call trace: Exception stack(0xffffffc1f5ce3b30 to 0xffffffc1f5ce3c60)
3b20: dead000000000060 0000008000000000
3b40: ffffffc1f5ce3d00 ffffff80084cb694 0000000000000008 0000000000000e88 3b60: ffffffc1f5ce3bb0 ffffff80080dac68 ffffffc1f5ce3b90 ffffff8008826fe4 3b80: 00000000000001c0 00000000000001c0 ffffffc1f5ce3bb0 ffffff800848dfcc 3ba0: 0000000000020000 ffffff8008b15ae4 ffffffc1f5ce3c00 ffffff800808f000 3bc0: 0000000000000010 ffffff80088377f0 ffffffc1f5ccd590 0000000000000140 3be0: dead000000000100 dead000000000200 0000000000000001 0000000000000000 3c00: 0000000000000000 ffffff8008ce2020 ffffffc1f5cc3338 ffffffc1f5ce0000 3c20: 0000000000000840 0000000000000001 0000000000000000 ffffffffffffffff 3c40: ffffffffffffffff ffffffffffffffff 0000000000000001 0000000000000007
[<ffffff80084cb694>] pl330_irq_handler+0x27c/0x390 [<ffffff80080f09d0>] irq_forced_thread_fn+0x38/0x88 [<ffffff80080f0d70>] irq_thread+0x140/0x200 [<ffffff80080bf4f8>] kthread+0xd8/0xf0 [<ffffff8008083690>] ret_from_fork+0x10/0x40 Code: f2a00838 f9405763 aa1c03e1 aa1503e0 (f9000443) ---[ end trace f50005726d31199c ]--- Kernel panic - not syncing: Fatal exception in interrupt
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 0-1
Kernel Offset: disabled
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception in interrupt
To fix this, re-start with the list-head after dropping the lock then re-takeing it.
--- drivers/dma/pl330.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/dma/pl330.c +4 -2
@@ -1510,7 +1510,7 @@ static void pl330_dotask(unsigned long d/* Returns 1 if state was updated, 0 otherwise */ static int pl330_update (struct pl330_dmac *pl330) { -struct dma_pl330_desc *descdone, *tmp; +struct dma_pl330_desc *descdone;unsigned long flags;void __iomem *regs;u32 val;
@@ -1588,7 +1588,9 @@ static int pl330_update(struct pl330_dma }/* Now that we are in no hurry, do the callbacks */ -list_for_each_entry_safe (descdone, tmp, &pl330->req_done, rqd) { +while (!list_empty (&pl330->req_done)) { + descdone =list_first_entry (&pl330->req_done, + struct dma_pl330_desc, rqd);list_del (&descdone->rqd);spin_unlock_irqrestore (&pl330->lock, flags);dma_pl330_rqcb (descdone,PL330_ERR_NONE );
Greg Kroah-Hartman
maintainerPATCH 207/272 ARM: dts: keystone-k2e-clocks: Fix missing unit address separator
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suman Anna <[email protected]>
[ Upstream commit 5a3a03905a433216f517babd0a343ae7265e9ca1 ]
Commit 95d8b41c765b ("ARM: dts: keystone-k2e-clocks: Add missing unit name to clock nodes that have regs") fixed the unit names on various clock nodes but missed out adding the unit address separator on the clkhyperlink0 clock node. Fix the same.
--- arch/arm/boot/dts/keystone-k2e-clocks.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/keystone-k2e-clocks.dtsi +1 -1
@@ -42,7 +42,7 @@ clocks { domain-id = <0>; }; - clkhyperlink0: clkhyperlink02350030 { + clkhyperlink0: clkhyperlink0@2350030 { #clock-cells = <0>; compatible = "ti,keystone,psc-clock"; clocks = <&chipclk12>;
Greg Kroah-Hartman
maintainerPATCH 208/272 powerpc/mm/slice: Remove intermediate bitmap copy
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 326691ad4f179e6edc7eb1271e618dd673e4736d upstream.
bitmap_or() and bitmap_andnot() can work properly with dst identical to src1 or src2. There is no need of an intermediate result bitmap that is copied back to dst in a second step.
--- arch/powerpc/mm/slice.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
arch/powerpc/mm/slice.c +4 -8
@@ -388,21 +388,17 @@ static unsigned long slice_find_area(strstatic inline void slice_or_mask (struct slice_mask *dst,struct slice_mask *src) { -DECLARE_BITMAP (result,SLICE_NUM_HIGH ); - dst->low_slices |= src->low_slices; -bitmap_or (result, dst->high_slices, src->high_slices,SLICE_NUM_HIGH ); -bitmap_copy (dst->high_slices, result,SLICE_NUM_HIGH ); +bitmap_or (dst->high_slices, dst->high_slices, src->high_slices, +SLICE_NUM_HIGH ); }static inline void slice_andnot_mask (struct slice_mask *dst,struct slice_mask *src) { -DECLARE_BITMAP (result,SLICE_NUM_HIGH ); - dst->low_slices &= ~src->low_slices; -bitmap_andnot (result, dst->high_slices, src->high_slices,SLICE_NUM_HIGH ); -bitmap_copy (dst->high_slices, result,SLICE_NUM_HIGH ); +bitmap_andnot (dst->high_slices, dst->high_slices, src->high_slices, +SLICE_NUM_HIGH ); }#ifdef CONFIG_PPC_64K_PAGES
Greg Kroah-Hartman
maintainerPATCH 209/272 powerpc/mm/slice: create header files dedicated to slices
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit a3286f05bc5a5bc7fc73a9783ec89de78fcd07f8 upstream.
In preparation for the following patch which will enhance 'slices' for supporting PPC32 in order to fix an issue on hugepages on 8xx, this patch takes out of page*.h all bits related to 'slices' and put them into newly created slice.h header files.
While common parts go into asm/slice.h, subarch specific parts go into respective books3s/64/slice.c and nohash/64/slice.c 'slices'
--- arch/powerpc/include/asm/book3s/64/slice.h | 27 +++++++++++++ arch/powerpc/include/asm/nohash/64/slice.h | 12 +++++ arch/powerpc/include/asm/page.h | 1 arch/powerpc/include/asm/page_64.h | 59 ----------------------------- arch/powerpc/include/asm/slice.h | 40 +++++++++++++++++++ 5 files changed, 80 insertions(+), 59 deletions(-)
arch/powerpc/include/asm/book3s/64/slice.h new file +27 -0
@@ -0,0 +1,27 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_POWERPC_BOOK3S_64_SLICE_H +#define _ASM_POWERPC_BOOK3S_64_SLICE_H + +#ifdef CONFIG_PPC_MM_SLICES + +#define SLICE_LOW_SHIFT 28 +#define SLICE_LOW_TOP (0x100000000ul) +#define SLICE_NUM_LOW (SLICE_LOW_TOP >> SLICE_LOW_SHIFT) +#define GET_LOW_SLICE_INDEX (addr) ((addr) >> SLICE_LOW_SHIFT) + +#define SLICE_HIGH_SHIFT 40 +#define SLICE_NUM_HIGH (H_PGTABLE_RANGE >> SLICE_HIGH_SHIFT) +#define GET_HIGH_SLICE_INDEX (addr) ((addr) >> SLICE_HIGH_SHIFT) + +#else /* CONFIG_PPC_MM_SLICES */ + +#define get_slice_psize (mm, addr) ((mm)->context.user_psize) +#define slice_set_user_psize (mm, psize) \ +do { \ + (mm)->context.user_psize = (psize); \ + (mm)->context.sllp = SLB_VSID_USER | mmu_psize_defs[(psize)].sllp; \ +} while (0) + +#endif /* CONFIG_PPC_MM_SLICES */ + +#endif /* _ASM_POWERPC_BOOK3S_64_SLICE_H */
arch/powerpc/include/asm/nohash/64/slice.h new file +12 -0
@@ -0,0 +1,12 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_POWERPC_NOHASH_64_SLICE_H +#define _ASM_POWERPC_NOHASH_64_SLICE_H + +#ifdef CONFIG_PPC_64K_PAGES +#define get_slice_psize (mm, addr) MMU_PAGE_64K +#else /* CONFIG_PPC_64K_PAGES */ +#define get_slice_psize (mm, addr) MMU_PAGE_4K +#endif /* !CONFIG_PPC_64K_PAGES */ +#define slice_set_user_psize (mm, psize) do { BUG(); } while (0) + +#endif /* _ASM_POWERPC_NOHASH_64_SLICE_H */
arch/powerpc/include/asm/page.h +1 -0
@@ -344,5 +344,6 @@ typedef struct page *pgtable_t;#include <asm-generic/memory_model.h> #endif /* __ASSEMBLY__ */ +#include <asm/slice.h> #endif /* _ASM_POWERPC_PAGE_H */
arch/powerpc/include/asm/page_64.h +0 -59
65 lines not on this page · raw message
arch/powerpc/include/asm/slice.h new file +40 -0
@@ -0,0 +1,40 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_POWERPC_SLICE_H +#define _ASM_POWERPC_SLICE_H + +#ifdef CONFIG_PPC_BOOK3S_64 +#include <asm/book3s/64/slice.h> +#else +#include <asm/nohash/64/slice.h> +#endif + +#ifdef CONFIG_PPC_MM_SLICES + +#ifdef CONFIG_HUGETLB_PAGE +#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA +#endif +#define HAVE_ARCH_UNMAPPED_AREA +#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN + +#ifndef __ASSEMBLY__ + +struct mm_struct ; + +unsigned long slice_get_unmapped_area (unsigned long addr,unsigned long len, +unsigned long flags,unsigned int psize, +int topdown); + +unsigned int get_slice_psize (struct mm_struct *mm,unsigned long addr); + +void slice_set_user_psize (struct mm_struct *mm,unsigned int psize); +void slice_set_range_psize (struct mm_struct *mm,unsigned long start, +unsigned long len,unsigned int psize); +#endif /* __ASSEMBLY__ */ + +#else /* CONFIG_PPC_MM_SLICES */ + +#define slice_set_range_psize (mm, start, len, psize) \ + slice_set_user_psize((mm), (psize)) +#endif /* CONFIG_PPC_MM_SLICES */ + +#endif /* _ASM_POWERPC_SLICE_H */
Greg Kroah-Hartman
maintainerPATCH 210/272 powerpc/mm/slice: Enhance for supporting PPC32
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit db3a528db41caaa6dfd4c64e9f5efb1c81a80467 upstream.
In preparation for the following patch which will fix an issue on the 8xx by re-using the 'slices', this patch enhances the 'slices' implementation to support 32 bits CPUs.
On PPC32, the address space is limited to 4Gbytes, hence only the low slices will be used.
The high slices use bitmaps. As bitmap functions are not prepared to handle bitmaps of size 0, this patch ensures that bitmap functions are called only when SLICE_NUM_HIGH is not nul.
--- arch/powerpc/include/asm/nohash/32/slice.h | 18 ++++++++++++++ arch/powerpc/include/asm/slice.h | 4 ++- arch/powerpc/mm/slice.c | 37 ++++++++++++++++++++++------- 3 files changed, 50 insertions(+), 9 deletions(-)
arch/powerpc/include/asm/nohash/32/slice.h new file +18 -0
@@ -0,0 +1,18 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_POWERPC_NOHASH_32_SLICE_H +#define _ASM_POWERPC_NOHASH_32_SLICE_H + +#ifdef CONFIG_PPC_MM_SLICES + +#define SLICE_LOW_SHIFT 28 +#define SLICE_LOW_TOP (0x100000000ull) +#define SLICE_NUM_LOW (SLICE_LOW_TOP >> SLICE_LOW_SHIFT) +#define GET_LOW_SLICE_INDEX (addr) ((addr) >> SLICE_LOW_SHIFT) + +#define SLICE_HIGH_SHIFT 0 +#define SLICE_NUM_HIGH 0ul +#define GET_HIGH_SLICE_INDEX (addr) (addr & 0) + +#endif /* CONFIG_PPC_MM_SLICES */ + +#endif /* _ASM_POWERPC_NOHASH_32_SLICE_H */
arch/powerpc/include/asm/slice.h +3 -1
@@ -4,8 +4,10 @@#ifdef CONFIG_PPC_BOOK3S_64 #include <asm/book3s/64/slice.h> -#else +#elif defined(CONFIG_PPC64 )#include <asm/nohash/64/slice.h> +#elif defined(CONFIG_PPC_MMU_NOHASH ) +#include <asm/nohash/32/slice.h> #endif #ifdef CONFIG_PPC_MM_SLICES
arch/powerpc/mm/slice.c +29 -8
@@ -73,10 +73,12 @@ static void slice_range_to_mask(unsignedunsigned long end = start + len -1 ; ret->low_slices =0 ; -bitmap_zero (ret->high_slices,SLICE_NUM_HIGH ); +if (SLICE_NUM_HIGH ) +bitmap_zero (ret->high_slices,SLICE_NUM_HIGH );if (start <SLICE_LOW_TOP ) { -unsigned long mend =min (end, (SLICE_LOW_TOP -1 )); +unsigned long mend =min (end, + (unsigned long )(SLICE_LOW_TOP -1 )); ret->low_slices = (1u << (GET_LOW_SLICE_INDEX (mend) +1 )) - (1u <<GET_LOW_SLICE_INDEX (start));
@@ -113,11 +115,13 @@ static int slice_high_has_vma(struct mm_unsigned long start = slice <<SLICE_HIGH_SHIFT ;unsigned long end = start + (1ul <<SLICE_HIGH_SHIFT ); +#ifdef CONFIG_PPC64 /* Hack, so that each addresses is controlled by exactly one * of the high or low area bitmaps, the first high area starts * at 4GB, not 0 */ if (start ==0 ) start =SLICE_LOW_TOP ; +#endif return !slice_area_is_free (mm, start, end - start); }
@@ -128,7 +132,8 @@ static void slice_mask_for_free(struct munsigned long i; ret->low_slices =0 ; -bitmap_zero (ret->high_slices,SLICE_NUM_HIGH ); +if (SLICE_NUM_HIGH ) +bitmap_zero (ret->high_slices,SLICE_NUM_HIGH );for (i =0 ; i <SLICE_NUM_LOW ; i++)if (!slice_low_has_vma (mm, i))
@@ -151,7 +156,8 @@ static void slice_mask_for_size(struct mu64 lpsizes; ret->low_slices =0 ; -bitmap_zero (ret->high_slices,SLICE_NUM_HIGH ); +if (SLICE_NUM_HIGH ) +bitmap_zero (ret->high_slices,SLICE_NUM_HIGH ); lpsizes = mm->context.low_slices_psize;for (i =0 ; i <SLICE_NUM_LOW ; i++)
@@ -180,6 +186,10 @@ static int slice_check_fit(struct mm_str*/ unsigned long slice_count =GET_HIGH_SLICE_INDEX (mm->context.slb_addr_limit); +if (!SLICE_NUM_HIGH ) +return (mask.low_slices & available.low_slices) == + mask.low_slices; +bitmap_and (result, mask.high_slices, available.high_slices, slice_count);
@@ -189,6 +199,7 @@ static int slice_check_fit(struct mm_strstatic void slice_flush_segments (void *parm) { +#ifdef CONFIG_PPC64 struct mm_struct *mm = parm;unsigned long flags;
@@ -200,6 +211,7 @@ static void slice_flush_segments(void *plocal_irq_save (flags);slb_flush_and_rebolt ();local_irq_restore (flags); +#endif }static void slice_convert (struct mm_struct *mm,struct slice_mask mask,int psize)
@@ -389,6 +401,8 @@ static unsigned long slice_find_area(strstatic inline void slice_or_mask (struct slice_mask *dst,struct slice_mask *src) { dst->low_slices |= src->low_slices; +if (!SLICE_NUM_HIGH ) +return ;bitmap_or (dst->high_slices, dst->high_slices, src->high_slices,SLICE_NUM_HIGH ); }
@@ -397,6 +411,8 @@ static inline void slice_andnot_mask(str { dst->low_slices &= ~src->low_slices; +if (!SLICE_NUM_HIGH ) +return ;bitmap_andnot (dst->high_slices, dst->high_slices, src->high_slices,SLICE_NUM_HIGH ); }
@@ -446,14 +462,17 @@ unsigned long slice_get_unmapped_area(un* init different masks */ mask.low_slices =0 ; -bitmap_zero (mask.high_slices,SLICE_NUM_HIGH );/* silence stupid warning */ ; potential_mask.low_slices =0 ; -bitmap_zero (potential_mask.high_slices,SLICE_NUM_HIGH ); compat_mask.low_slices =0 ; -bitmap_zero (compat_mask.high_slices,SLICE_NUM_HIGH ); + +if (SLICE_NUM_HIGH ) { +bitmap_zero (mask.high_slices,SLICE_NUM_HIGH ); +bitmap_zero (potential_mask.high_slices,SLICE_NUM_HIGH ); +bitmap_zero (compat_mask.high_slices,SLICE_NUM_HIGH ); + }/* Sanity checks */ BUG_ON (mm->task_size ==0 );
@@ -591,7 +610,9 @@ unsigned long slice_get_unmapped_area(un convert:slice_andnot_mask (&mask, &good_mask);slice_andnot_mask (&mask, &compat_mask); -if (mask.low_slices || !bitmap_empty (mask.high_slices,SLICE_NUM_HIGH )) { +if (mask.low_slices || + (SLICE_NUM_HIGH && + !bitmap_empty (mask.high_slices,SLICE_NUM_HIGH ))) {slice_convert (mm, mask, psize);if (psize >MMU_PAGE_BASE )on_each_cpu (slice_flush_segments, mm,1 );
Greg Kroah-Hartman
maintainerPATCH 211/272 powerpc/mm/slice: Fix hugepage allocation at hint address on 8xx
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
[ Upstream commit aa0ab02ba992eb956934b21373e0138211486ddd ]
On the 8xx, the page size is set in the PMD entry and applies to all pages of the page table pointed by the said PMD entry.
When an app has some regular pages allocated (e.g. see below) and tries to mmap() a huge page at a hint address covered by the same PMD entry, the kernel accepts the hint allthough the 8xx cannot handle different page sizes in the same PMD entry.
10000000-10001000 r-xp 00000000 00:0f 2597 /root/malloc 10010000-10011000 rwxp 00000000 00:0f 2597 /root/malloc
mmap(0x10080000, 524288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0) = 0x10080000
This results the app remaining forever in do_page_fault()/hugetlb_fault() and when interrupting that app, we get the following warning:
[162980.035629] WARNING: CPU: 0 PID: 2777 at arch/powerpc/mm/hugetlbpage.c:354 hugetlb_free_pgd_range+0xc8/0x1e4 [162980.035699] CPU: 0 PID: 2777 Comm: malloc Tainted: G W 4.14.6 #85 [162980.035744] task: c67e2c00 task.stack: c668e000 [162980.035783] NIP: c000fe18 LR: c00e1eec CTR: c00f90c0 [162980.035830] REGS: c668fc20 TRAP: 0700 Tainted: G W (4.14.6) [162980.035854] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24044224 XER: 20000000 [162980.036003] [162980.036003] GPR00: c00e1eec c668fcd0 c67e2c00 00000010 c6869410 10080000 00000000 77fb4000 [162980.036003] GPR08: ffff0001 0683c001 00000000 ffffff80 44028228 10018a34 00004008 418004fc [162980.036003] GPR16: c668e000 00040100 c668e000 c06c0000 c668fe78 c668e000 c6835ba0 c668fd48 [162980.036003] GPR24: 00000000 73ffffff 74000000 00000001 77fb4000 100fffff 10100000 10100000 [162980.036743] NIP [c000fe18] hugetlb_free_pgd_range+0xc8/0x1e4 [162980.036839] LR [c00e1eec] free_pgtables+0x12c/0x150 [162980.036861] Call Trace: [162980.036939] [c668fcd0] [c00f0774] unlink_anon_vmas+0x1c4/0x214 (unreliable) [162980.037040] [c668fd10] [c00e1eec] free_pgtables+0x12c/0x150 [162980.037118] [c668fd40] [c00eabac] exit_mmap+0xe8/0x1b4 [162980.037210] [c668fda0] [c0019710] mmput.part.9+0x20/0xd8 [162980.037301] [c668fdb0] [c001ecb0] do_exit+0x1f0/0x93c [162980.037386] [c668fe00] [c001f478] do_group_exit+0x40/0xcc [162980.037479] [c668fe10] [c002a76c] get_signal+0x47c/0x614 [162980.037570] [c668fe70] [c0007840] do_signal+0x54/0x244 [162980.037654] [c668ff30] [c0007ae8] do_notify_resume+0x34/0x88 [162980.037744] [c668ff40] [c000dae8] do_user_signal+0x74/0xc4 [162980.037781] Instruction dump: [162980.037821] 7fdff378 81370000 54a3463a 80890020 7d24182e 7c841a14 712a0004 4082ff94 [162980.038014] 2f890000 419e0010 712a0ff0 408200e0 <0fe00000> 54a9000a 7f984840 419d0094 [162980.038216] ---[ end trace c0ceeca8e7a5800a ]--- [162980.038754] BUG: non-zero nr_ptes on freeing mm: 1 [162985.363322] BUG: non-zero nr_ptes on freeing mm: -1
In order to fix this, this patch uses the address space "slices" implemented for BOOK3S/64 and enhanced to support PPC32 by the preceding patch.
This patch modifies the context.id on the 8xx to be in the range [1:16] instead of [0:15] in order to identify context.id == 0 as not initialised contexts as done on BOOK3S
This patch activates CONFIG_PPC_MM_SLICES when CONFIG_HUGETLB_PAGE is selected for the 8xx
Alltough we could in theory have as many slices as PMD entries, the current slices implementation limits the number of low slices to 16. This limitation is not preventing us to fix the initial issue allthough it is suboptimal. It will be cured in a subsequent patch.
--- arch/powerpc/include/asm/mmu-8xx.h | 6 ++++++ arch/powerpc/kernel/setup-common.c | 2 ++ arch/powerpc/mm/8xx_mmu.c | 2 +- arch/powerpc/mm/hugetlbpage.c | 2 ++ arch/powerpc/mm/mmu_context_nohash.c | 18 ++++++++++++++++-- arch/powerpc/platforms/Kconfig.cputype | 1 + 6 files changed, 28 insertions(+), 3 deletions(-)
arch/powerpc/include/asm/mmu-8xx.h +6 -0
@@ -191,6 +191,12 @@ typedef struct {unsigned int id;unsigned int active;unsigned long vdso_base; +#ifdef CONFIG_PPC_MM_SLICES +u16 user_psize;/* page size index */ +u64 low_slices_psize;/* page size encodings */ +unsigned char high_slices_psize[0 ]; +unsigned long slb_addr_limit; +#endif } mm_context_t;#define PHYS_IMMR_BASE (mfspr(SPRN_IMMR) & 0xfff80000)
arch/powerpc/kernel/setup-common.c +2 -0
@@ -919,6 +919,8 @@ void __init setup_arch(char **cmdline_p)#ifdef CONFIG_PPC64 if (!radix_enabled ()) init_mm.context.slb_addr_limit =DEFAULT_MAP_WINDOW_USER64 ; +#elif defined(CONFIG_PPC_8xx) + init_mm.context.slb_addr_limit =DEFAULT_MAP_WINDOW ;#else #error "context.addr_limit not initialized."#endif
arch/powerpc/mm/8xx_mmu.c +1 -1
@@ -192,7 +192,7 @@ void set_context(unsigned long id, pgd_tmtspr (SPRN_M_TW ,__pa (pgd) - offset);/* Update context */ -mtspr (SPRN_M_CASID , id); +mtspr (SPRN_M_CASID , id -1 );/* sync */ mb (); }
arch/powerpc/mm/hugetlbpage.c +2 -0
@@ -553,9 +553,11 @@ unsigned long hugetlb_get_unmapped_area(struct hstate *hstate =hstate_file (file);int mmu_psize =shift_to_mmu_psize (huge_page_shift (hstate)); +#ifdef CONFIG_PPC_RADIX_MMU if (radix_enabled ())return radix__hugetlb_get_unmapped_area (file, addr, len, pgoff, flags); +#endif return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1); }#endif
arch/powerpc/mm/mmu_context_nohash.c +16 -2
@@ -331,6 +331,20 @@ int init_new_context(struct task_struct {pr_hard ("initing context for mm @%p\n" , mm); +#ifdef CONFIG_PPC_MM_SLICES +if (!mm->context.slb_addr_limit) + mm->context.slb_addr_limit =DEFAULT_MAP_WINDOW ; + +/* +* We have MMU_NO_CONTEXT set to be ~0. Hence check +* explicitly against context.id == 0. This ensures that we properly +* initialize context slice details for newly allocated mm's (which will +* have id == 0) and don't alter context slice inherited via fork (which +* will have id != 0). +*/ +if (mm->context.id ==0 ) +slice_set_user_psize (mm, mmu_virtual_psize); +#endif mm->context.id =MMU_NO_CONTEXT ; mm->context.active =0 ;return 0 ;
@@ -428,8 +442,8 @@ void __init mmu_context_init(void)* -- BenH */ if (mmu_has_feature (MMU_FTR_TYPE_8xx)) { - first_context =0 ; - last_context =15 ; + first_context =1 ; + last_context =16 ; no_selective_tlbil = true; }else if (mmu_has_feature (MMU_FTR_TYPE_47x)) { first_context =1 ;
arch/powerpc/platforms/Kconfig.cputype +1 -0
@@ -326,6 +326,7 @@ config PPC_BOOK3E_MMU config PPC_MM_SLICES bool default y if PPC_BOOK3S_64 + default y if PPC_8xx && HUGETLB_PAGE default n config PPC_HAVE_PMU_SUPPORT
Greg Kroah-Hartman
maintainerPATCH 212/272 dmaengine: rcar-dmac: Check the done lists in rcar_dmac_chan_get_residue()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yoshihiro Shimoda <[email protected]>
[ Upstream commit 3e081628d510b2ddbe493371d9c574d9275da17e ]
This patch fixes an issue that a race condition happens between a client driver and the rcar-dmac driver:
- The rcar_dmac_isr_transfer_end() is called.
- The done list appears, and desc.running is the next active list.
- rcar_dmac_chan_get_residue() is called by a client driver before rcar_dmac_isr_channel_thread() is called.
- The rcar_dmac_chan_get_residue() will not find any descriptors.
- And, the following WARNING happens:
WARN(1, "No descriptor for cookie!");
The sh-sci driver with HSCIF (921,600bps) on R-Car H3 can cause this situation.
So, this patch checks the done lists in rcar_dmac_chan_get_residue() and returns zero if the done lists has the argument cookie.
--- drivers/dma/sh/rcar-dmac.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/dma/sh/rcar-dmac.c +9 -0
@@ -1301,8 +1301,17 @@ static unsigned int rcar_dmac_chan_get_r* If the cookie doesn't correspond to the currently running transfer * then the descriptor hasn't been processed yet, and the residue is * equal to the full descriptor size. +* Also, a client driver is possible to call this function before +* rcar_dmac_isr_channel_thread() runs. In this case, the "desc.running" +* will be the next descriptor, and the done list will appear. So, if +* the argument cookie matches the done list's cookie, we can assume +* the residue is zero. */ if (cookie != desc->async_tx.cookie) { +list_for_each_entry (desc, &chan->desc.done, node) { +if (cookie == desc->async_tx.cookie) +return 0 ; + }list_for_each_entry (desc, &chan->desc.pending, node) {if (cookie == desc->async_tx.cookie)return desc->size;
Greg Kroah-Hartman
maintainerPATCH 213/272 enic: enable rq before updating rq descriptors
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Govindarajulu Varadarajan <[email protected]>
[ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ]
rq should be enabled before posting the buffers to rq desc. If not hw sees stale value and casuses DMAR errors.
--- drivers/net/ethernet/cisco/enic/enic_main.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/ethernet/cisco/enic/enic_main.c +7 -3
@@ -1898,6 +1898,8 @@ static int enic_open(struct net_device * }for (i =0 ; i < enic->rq_count; i++) { +/* enable rq before updating rq desc */ +vnic_rq_enable (&enic->rq[i]);vnic_rq_fill (&enic->rq[i], enic_rq_alloc_buf);/* Need at least one buffer on ring to get going */ if (vnic_rq_desc_used (&enic->rq[i]) ==0 ) {
@@ -1909,8 +1911,6 @@ static int enic_open(struct net_device *for (i =0 ; i < enic->wq_count; i++)vnic_wq_enable (&enic->wq[i]); -for (i =0 ; i < enic->rq_count; i++) -vnic_rq_enable (&enic->rq[i]);if (!enic_is_dynamic (enic) && !enic_is_sriov_vf (enic))enic_dev_add_station_addr (enic);
@@ -1936,8 +1936,12 @@ static int enic_open(struct net_device *return 0 ; err_out_free_rq: -for (i =0 ; i < enic->rq_count; i++) +for (i =0 ; i < enic->rq_count; i++) { + err =vnic_rq_disable (&enic->rq[i]); +if (err) +return err;vnic_rq_clean (&enic->rq[i], enic_free_rq_buf); + }enic_dev_notify_unset (enic); err_out_free_intr:enic_unset_affinity_hint (enic);
Greg Kroah-Hartman
maintainerPATCH 214/272 watchdog: asm9260_wdt: fix error handling in asm9260_wdt_probe()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Khoroshilov <[email protected]>
[ Upstream commit 3c829f47e33eb0398a9a14e357a05199a7be0277 ]
If devm_reset_control_get_exclusive() fails, asm9260_wdt_probe() returns immediately. But clks has been already enabled at that point, so it is required to disable them or to move the code around.
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/watchdog/asm9260_wdt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/watchdog/asm9260_wdt.c +4 -4
@@ -292,14 +292,14 @@ static int asm9260_wdt_probe(struct platif (IS_ERR (priv->iobase))return PTR_ERR (priv->iobase); - ret =asm9260_wdt_get_dt_clks (priv); -if (ret) -return ret; - priv->rst =devm_reset_control_get_exclusive (&pdev->dev,"wdt_rst" );if (IS_ERR (priv->rst))return PTR_ERR (priv->rst); + ret =asm9260_wdt_get_dt_clks (priv); +if (ret) +return ret; + wdd = &priv->wdd; wdd->info = &asm9260_wdt_ident; wdd->ops = &asm9260_wdt_ops;
Greg Kroah-Hartman
maintainerPATCH 215/272 hwrng: stm32 - add reset during probe
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
[ Upstream commit 326ed382256475aa4b8b7eae8a2f60689fd25e78 ]
Avoid issue when probing the RNG without
reset if bad status has been detected previously
--- drivers/char/hw_random/stm32-rng.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/char/hw_random/stm32-rng.c +9 -0
@@ -21,6 +21,7 @@#include <linux/of_address.h> #include <linux/of_platform.h> #include <linux/pm_runtime.h> +#include <linux/reset.h> #include <linux/slab.h> #define RNG_CR 0x00
@@ -46,6 +47,7 @@ struct stm32_rng_private {struct hwrng rng;void __iomem *base;struct clk *clk; +struct reset_control *rst; };static int stm32_rng_read (struct hwrng *rng,void *data,size_t max,bool wait)
@@ -140,6 +142,13 @@ static int stm32_rng_probe(struct platfoif (IS_ERR (priv->clk))return PTR_ERR (priv->clk); + priv->rst =devm_reset_control_get (&ofdev->dev,NULL ); +if (!IS_ERR (priv->rst)) { +reset_control_assert (priv->rst); +udelay (2 ); +reset_control_deassert (priv->rst); + } +dev_set_drvdata (dev, priv); priv->rng.name = dev_driver_string(dev),
Greg Kroah-Hartman
maintainerPATCH 216/272 pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit b89405b6102fcc3746f43697b826028caa94c823 ]
When dt_to_map_one_config() is called with a pinctrl_dev passed in, it should only be using this if the node being looked up is a hog. The code was always using the passed pinctrl_dev without checking whether the dt node referred to it.
A pin controller can have pinctrl-n dependencies on other pin controllers in these cases:
- the pin controller hardware is external, for example I2C, so needs other pin controller(s) to be setup to communicate with the hardware device.
- it is a child of a composite MFD so its of_node is shared with the parent MFD and other children of that MFD. Any part of that MFD could have dependencies on other pin controllers.
Because of this, dt_to_map_one_config() can't assume that if it has a pinctrl_dev passed in then the node it looks up must be a hog. It could be a reference to some other pin controller.
--- drivers/pinctrl/devicetree.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/pinctrl/devicetree.c +4 -2
@@ -122,8 +122,10 @@ static int dt_to_map_one_config(struct p/* OK let's just assume this will appear later then */ return -EPROBE_DEFER ; } -if (!pctldev) - pctldev =get_pinctrl_dev_from_of_node (np_pctldev); +/* If we're creating a hog we can use the passed pctldev */ +if (pctldev && (np_pctldev == p->dev->of_node)) +break ; + pctldev =get_pinctrl_dev_from_of_node (np_pctldev);if (pctldev)break ;/* Do not defer probing of hogs (circular loop) */
Greg Kroah-Hartman
maintainerPATCH 217/272 pinctrl: artpec6: dt: add missing pin group uart5nocts
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit 7e065fb9ccce89fe667fdbd9a177eaec59a359fc ]
Add missing pin group uart5nocts (all pins except cts), which has been supported by the artpec6 pinctrl driver since its initial submission.
--- Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt +3 -2
@@ -20,7 +20,8 @@ Required subnode-properties: gpio: cpuclkoutgrp0, udlclkoutgrp0, i2c1grp0, i2c2grp0, i2c3grp0, i2s0grp0, i2s1grp0, i2srefclkgrp0, spi0grp0, spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart1grp0, - uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0 + uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0, + uart5nocts cpuclkout: cpuclkoutgrp0 udlclkout: udlclkoutgrp0 i2c1: i2c1grp0
@@ -37,7 +38,7 @@ Required subnode-properties: uart2: uart2grp0, uart2grp1 uart3: uart3grp0 uart4: uart4grp0 - uart5: uart5grp0 + uart5: uart5grp0, uart5nocts nand: nandgrp0 sdio0: sdio0grp0 sdio1: sdio1grp0
Greg Kroah-Hartman
maintainerPATCH 218/272 vfio-ccw: fence off transport mode
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cornelia Huck <[email protected]>
[ Upstream commit 9851bc77e62499957567e7c39a5beba7d6de6296 ]
vfio-ccw only supports command mode for channel programs, not transport mode. User space is supposed to already take care of that and pass us command-mode ORBs only, but better make sure and return an error to the caller instead of trying to process tcws as ccws.
--- drivers/s390/cio/vfio_ccw_fsm.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/s390/cio/vfio_ccw_fsm.c +5 -0
@@ -129,6 +129,11 @@ static void fsm_io_request(struct vfio_cif (scsw->cmd.fctl &SCSW_FCTL_START_FUNC ) { orb = (union orb *)io_region->orb_area; +/* Don't try to build a cp if transport mode is specified. */ +if (orb->tm.b) { + io_region->ret_code = -EOPNOTSUPP ; + goto err_out; + } io_region->ret_code =cp_init (&private->cp,mdev_dev (mdev), orb);if (io_region->ret_code)
Greg Kroah-Hartman
maintainerPATCH 219/272 dmaengine: qcom: bam_dma: get num-channels and num-ees from dt
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
[ Upstream commit 48d163b1aa6e7f650c0b7a4f9c61c387a6def868 ]
When Linux is master of BAM, it can directly read registers to know number of supported channels, however when its remotely controlled reading these registers would trigger a crash if the BAM is not yet initialized or powered up on the remote side.
This patch allows driver to read num-channels and num-ees from Device Tree for remotely controlled BAM.
--- drivers/dma/qcom/bam_dma.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-)
drivers/dma/qcom/bam_dma.c +22 -5
@@ -393,6 +393,7 @@ struct bam_device {struct device_dma_parameters dma_parms;struct bam_chan *channels;u32 num_channels; +u32 num_ees;/* execution environment ID, from DT */ u32 ee;
@@ -1128,15 +1129,19 @@ static int bam_init(struct bam_device *bu32 val;/* read revision and configuration information */ - val =readl_relaxed (bam_addr (bdev,0 ,BAM_REVISION )) >>NUM_EES_SHIFT ; - val &=NUM_EES_MASK ; +if (!bdev->num_ees) { + val =readl_relaxed (bam_addr (bdev,0 ,BAM_REVISION )); + bdev->num_ees = (val >>NUM_EES_SHIFT ) &NUM_EES_MASK ; + }/* check that configured EE is within range */ -if (bdev->ee >= val) +if (bdev->ee >= bdev->num_ees)return -EINVAL ; - val =readl_relaxed (bam_addr (bdev,0 ,BAM_NUM_PIPES )); - bdev->num_channels = val &BAM_NUM_PIPES_MASK ; +if (!bdev->num_channels) { + val =readl_relaxed (bam_addr (bdev,0 ,BAM_NUM_PIPES )); + bdev->num_channels = val &BAM_NUM_PIPES_MASK ; + }if (bdev->controlled_remotely)return 0 ;
@@ -1232,6 +1237,18 @@ static int bam_dma_probe(struct platform bdev->controlled_remotely =of_property_read_bool (pdev->dev.of_node,"qcom,controlled-remotely" ); +if (bdev->controlled_remotely) { + ret =of_property_read_u32 (pdev->dev.of_node,"num-channels" , + &bdev->num_channels); +if (ret) +dev_err (bdev->dev,"num-channels unspecified in dt\n" ); + + ret =of_property_read_u32 (pdev->dev.of_node,"qcom,num-ees" , + &bdev->num_ees); +if (ret) +dev_err (bdev->dev,"num-ees unspecified in dt\n" ); + } + bdev->bamclk =devm_clk_get (bdev->dev,"bam_clk" );if (IS_ERR (bdev->bamclk))return PTR_ERR (bdev->bamclk);
Greg Kroah-Hartman
maintainerPATCH 220/272 drm: omapdrm: dss: Move initialization code from component bind to probe
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <[email protected]>
[ Upstream commit 215003b4ae1d47035092fef73b6a22aa82037091 ]
There's no reason to delay initialization of most of the driver (such as mapping memory I/O, getting clocks or enabling runtime PM) to the component master bind handler.
This additionally fixes a real PM issue caused enabling runtime PM in the bind handler.
The bind handler performs the following sequence of PM operations:
pm_runtime_enable(dev); pm_runtime_get_sync(dev); ... (access the hardware to read the device revision) ... pm_runtime_put_sync(dev);
If a failure occurs at this point, the error path calls pm_runtime_disable() to balance the pm_runtime_enable() call.
To understand the problem, it should be noted that the bind handler is called when one of the component registers itself, which happens in the component's probe handler. Furthermore, as the components are children of the DSS, the device core calls pm_runtime_get_sync() on the DSS platform device before calling the component's probe handler. This increases the DSS power usage count but doesn't runtime resume the device, as runtime PM is disabled at that point.
The bind handler is thus called with runtime PM disabled, with the device runtime suspended, but with the power usage count larger than 0. The pm_runtime_get_sync() call will thus further increase the power usage count and runtime resume the device. The pm_runtime_put_sync() handler will decrease the power usage count to a non-zero value and will thus not suspend the device. Finally, the pm_runtime_disable() call will disable runtime PM, preventing the pm_runtime_put() call in the device core from runtime suspending the device. The DSS device is thus left powered on.
To fix this, move the initialization code from the bind handler to the probe handler.
--- drivers/gpu/drm/omapdrm/dss/dss.c | 193 ++++++++++++++++++++------------------ 1 file changed, 104 insertions(+), 89 deletions(-)
drivers/gpu/drm/omapdrm/dss/dss.c +104 -89
@@ -1300,88 +1300,18 @@ static const struct soc_device_attributestatic int dss_bind (struct device *dev) { -struct platform_device *pdev =to_platform_device (dev); -struct resource *dss_mem; -u32 rev;int r; - dss_mem =platform_get_resource (dss.pdev,IORESOURCE_MEM ,0 ); - dss.base =devm_ioremap_resource (&pdev->dev, dss_mem); -if (IS_ERR (dss.base)) -return PTR_ERR (dss.base); - - r =dss_get_clocks (); + r =component_bind_all (dev,NULL );if (r)return r; - r =dss_setup_default_clock (); -if (r) - goto err_setup_clocks; - - r =dss_video_pll_probe (pdev); -if (r) - goto err_pll_init; - - r =dss_init_ports (pdev); -if (r) - goto err_init_ports; - -pm_runtime_enable (&pdev->dev); - - r =dss_runtime_get (); -if (r) - goto err_runtime_get; - - dss.dss_clk_rate =clk_get_rate (dss.dss_clk); - -/* Select DPLL */ -REG_FLD_MOD (DSS_CONTROL ,0 ,0 ,0 ); - -dss_select_dispc_clk_source (DSS_CLK_SRC_FCK ); - -#ifdef CONFIG_OMAP2_DSS_VENC -REG_FLD_MOD (DSS_CONTROL ,1 ,4 ,4 );/* venc dac demen */ -REG_FLD_MOD (DSS_CONTROL ,1 ,3 ,3 );/* venc clock 4x enable */ -REG_FLD_MOD (DSS_CONTROL ,0 ,2 ,2 );/* venc clock mode = normal */ -#endif - dss.dsi_clk_source[0 ] =DSS_CLK_SRC_FCK ; - dss.dsi_clk_source[1 ] =DSS_CLK_SRC_FCK ; - dss.dispc_clk_source =DSS_CLK_SRC_FCK ; - dss.lcd_clk_source[0 ] =DSS_CLK_SRC_FCK ; - dss.lcd_clk_source[1 ] =DSS_CLK_SRC_FCK ; - - rev =dss_read_reg (DSS_REVISION ); -pr_info ("OMAP DSS rev %d.%d\n" ,FLD_GET (rev,7 ,4 ),FLD_GET (rev,3 ,0 )); - -dss_runtime_put (); - - r =component_bind_all (&pdev->dev,NULL ); -if (r) - goto err_component; - -dss_debugfs_create_file ("dss" , dss_dump_regs); -pm_set_vt_switch (0 );omapdss_gather_components (dev);omapdss_set_is_initialized (true);return 0 ; - -err_component: -err_runtime_get: -pm_runtime_disable (&pdev->dev); -dss_uninit_ports (pdev); -err_init_ports: -if (dss.video1_pll) -dss_video_pll_uninit (dss.video1_pll); - -if (dss.video2_pll) -dss_video_pll_uninit (dss.video2_pll); -err_pll_init: -err_setup_clocks: -dss_put_clocks (); -return r; }static void dss_unbind (struct device *dev)
@@ -1391,18 +1321,6 @@ static void dss_unbind(struct device *deomapdss_set_is_initialized (false);component_unbind_all (&pdev->dev,NULL ); - -if (dss.video1_pll) -dss_video_pll_uninit (dss.video1_pll); - -if (dss.video2_pll) -dss_video_pll_uninit (dss.video2_pll); - -dss_uninit_ports (pdev); - -pm_runtime_disable (&pdev->dev); - -dss_put_clocks (); }static const struct component_master_ops dss_component_ops = {
@@ -1434,10 +1352,46 @@ static int dss_add_child_component(strucreturn 0 ; } +static int dss_probe_hardware (void ) +{ +u32 rev; +int r; + + r =dss_runtime_get (); +if (r) +return r; + + dss.dss_clk_rate =clk_get_rate (dss.dss_clk); + +/* Select DPLL */ +REG_FLD_MOD (DSS_CONTROL ,0 ,0 ,0 ); + +dss_select_dispc_clk_source (DSS_CLK_SRC_FCK ); + +#ifdef CONFIG_OMAP2_DSS_VENC +REG_FLD_MOD (DSS_CONTROL ,1 ,4 ,4 );/* venc dac demen */ +REG_FLD_MOD (DSS_CONTROL ,1 ,3 ,3 );/* venc clock 4x enable */ +REG_FLD_MOD (DSS_CONTROL ,0 ,2 ,2 );/* venc clock mode = normal */ +#endif + dss.dsi_clk_source[0 ] =DSS_CLK_SRC_FCK ; + dss.dsi_clk_source[1 ] =DSS_CLK_SRC_FCK ; + dss.dispc_clk_source =DSS_CLK_SRC_FCK ; + dss.lcd_clk_source[0 ] =DSS_CLK_SRC_FCK ; + dss.lcd_clk_source[1 ] =DSS_CLK_SRC_FCK ; + + rev =dss_read_reg (DSS_REVISION ); +pr_info ("OMAP DSS rev %d.%d\n" ,FLD_GET (rev,7 ,4 ),FLD_GET (rev,3 ,0 )); + +dss_runtime_put (); + +return 0 ; +} +static int dss_probe (struct platform_device *pdev) {const struct soc_device_attribute *soc;struct component_match *match =NULL ; +struct resource *dss_mem;int r; dss.pdev = pdev;
@@ -1458,20 +1412,69 @@ static int dss_probe(struct platform_develse dss.feat =of_match_device (dss_of_match, &pdev->dev)->data; - r =dss_initialize_debugfs (); +/* Map I/O registers, get and setup clocks. */ + dss_mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); + dss.base =devm_ioremap_resource (&pdev->dev, dss_mem); +if (IS_ERR (dss.base)) +return PTR_ERR (dss.base); + + r =dss_get_clocks ();if (r)return r; -/* add all the child devices as components */ + r =dss_setup_default_clock (); +if (r) + goto err_put_clocks; + +/* Setup the video PLLs and the DPI and SDI ports. */ + r =dss_video_pll_probe (pdev); +if (r) + goto err_put_clocks; + + r =dss_init_ports (pdev); +if (r) + goto err_uninit_plls; + +/* Enable runtime PM and probe the hardware. */ +pm_runtime_enable (&pdev->dev); + + r =dss_probe_hardware (); +if (r) + goto err_pm_runtime_disable; + +/* Initialize debugfs. */ + r =dss_initialize_debugfs (); +if (r) + goto err_pm_runtime_disable; + +dss_debugfs_create_file ("dss" , dss_dump_regs); + +/* Add all the child devices as components. */ device_for_each_child (&pdev->dev, &match, dss_add_child_component); r =component_master_add_with_match (&pdev->dev, &dss_component_ops, match); -if (r) { -dss_uninitialize_debugfs (); -return r; - } +if (r) + goto err_uninit_debugfs;return 0 ; + +err_uninit_debugfs: +dss_uninitialize_debugfs (); + +err_pm_runtime_disable: +pm_runtime_disable (&pdev->dev); +dss_uninit_ports (pdev); + +err_uninit_plls: +if (dss.video1_pll) +dss_video_pll_uninit (dss.video1_pll); +if (dss.video2_pll) +dss_video_pll_uninit (dss.video2_pll); + +err_put_clocks: +dss_put_clocks (); + +return r; }static int dss_remove (struct platform_device *pdev)
@@ -1480,6 +1483,18 @@ static int dss_remove(struct platform_dedss_uninitialize_debugfs (); +pm_runtime_disable (&pdev->dev); + +dss_uninit_ports (pdev); + +if (dss.video1_pll) +dss_video_pll_uninit (dss.video1_pll); + +if (dss.video2_pll) +dss_video_pll_uninit (dss.video2_pll); + +dss_put_clocks (); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 221/272 ARM: dts: dra71-evm: Correct evm_sd regulator max voltage
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ravikumar Kattekola <[email protected]>
[ Upstream commit f4aa1bd5b4fc80f5f4ecd184caad832fd62c25f7 ]
Correct vpo_sd_1v8_3v3 regulator max voltage to 3.3V
--- arch/arm/boot/dts/dra71-evm.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/dra71-evm.dts +2 -2
@@ -24,13 +24,13 @@ regulator-name = "vddshv8"; regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3000000>; + regulator-max-microvolt = <3300000>; regulator-boot-on; vin-supply = <&evm_5v0>; gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>; states = <1800000 0x0 - 3000000 0x1>; + 3300000 0x1>; }; evm_1v8_sw: fixedregulator-evm_1v8 {
Greg Kroah-Hartman
maintainerPATCH 222/272 drm/amdgpu: disable GFX ring and disable PQ wptr in hw_fini
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Monk Liu <[email protected]>
[ Upstream commit 9f0178fb67699992d38601cb923b434f9986dd68 ]
otherwise there will be DMAR reading error comes out from CP since GFX is still alive and CPC's WPTR_POLL is still enabled, which would lead to DMAR read error.
fix:
we can hault CPG after hw_fini, but cannot halt CPC becaues KIQ stil need to be alive to let RLCV invoke, but its WPTR_POLL could be disabled.
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +7 -1
@@ -2954,7 +2954,13 @@ static int gfx_v9_0_hw_fini(void *handlegfx_v9_0_kcq_disable (&adev->gfx.kiq.ring, &adev->gfx.compute_ring[i]);if (amdgpu_sriov_vf (adev)) { -pr_debug ("For SRIOV client, shouldn't do anything.\n" ); +gfx_v9_0_cp_gfx_enable (adev, false); +/* must disable polling for SRIOV when hw finished, otherwise +* CPC engine may still keep fetching WB address which is already +* invalid after sw finished and trigger DMAR reading error in +* hypervisor side. +*/ +WREG32_FIELD15 (GC ,0 ,CP_PQ_WPTR_POLL_CNTL ,EN ,0 );return 0 ; }gfx_v9_0_cp_enable (adev, false);
Greg Kroah-Hartman
maintainerPATCH 224/272 ibmvnic: Allocate statistics buffers during probe
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Falcon <[email protected]>
[ Upstream commit 53cc7721fdf12e649994cfb7d8f562acb0e4510b ]
Currently, buffers holding individual queue statistics are allocated when the device is opened. If an ibmvnic interface is hotplugged or initialized but never opened, an attempt to get statistics with ethtool will result in a kernel panic.
Since the driver allocates a constant number, the maximum supported queues, of buffers, these can be allocated during device probe and freed when the device is hot-unplugged or the module is removed.
--- drivers/net/ethernet/ibm/ibmvnic.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
drivers/net/ethernet/ibm/ibmvnic.c +11 -10
@@ -812,8 +812,6 @@ static void release_resources(struct ibmrelease_tx_pools (adapter);release_rx_pools (adapter); -release_stats_token (adapter); -release_stats_buffers (adapter);release_error_buffers (adapter);if (adapter->napi) {
@@ -953,14 +951,6 @@ static int init_resources(struct ibmvnicif (rc)return rc; - rc =init_stats_buffers (adapter); -if (rc) -return rc; - - rc =init_stats_token (adapter); -if (rc) -return rc; - adapter->vpd =kzalloc (sizeof (*adapter->vpd),GFP_KERNEL );if (!adapter->vpd)return -ENOMEM ;
@@ -4390,6 +4380,14 @@ static int ibmvnic_init(struct ibmvnic_arelease_crq_queue (adapter); } + rc =init_stats_buffers (adapter); +if (rc) +return rc; + + rc =init_stats_token (adapter); +if (rc) +return rc; +return rc; }
@@ -4497,6 +4495,9 @@ static int ibmvnic_remove(struct vio_devrelease_sub_crqs (adapter);release_crq_queue (adapter); +release_stats_token (adapter); +release_stats_buffers (adapter); + adapter->state =VNIC_REMOVED ;mutex_unlock (&adapter->reset_lock);
Greg Kroah-Hartman
maintainerPATCH 225/272 net: stmmac: ensure that the device has released ownership before reading data
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit a6b25da5e7ba212af5826a662e6a035a79bffabd ]
According to Documentation/memory-barriers.txt, we need to use a dma_rmb() after reading the status/own bit, to ensure that all descriptor fields are read after reading the own bit.
This way, we ensure that the DMA engine is done with the DMA descriptor before we read the other descriptor fields, e.g. reading the tx hardware timestamp (if PTP is enabled).
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +5 -0
@@ -1843,6 +1843,11 @@ static void stmmac_tx_clean(struct stmmaif (unlikely (status & tx_dma_own))break ; +/* Make sure descriptor fields are read after reading +* the own bit. +*/ +dma_rmb (); +/* Just consider the last segment and ...*/ if (likely (!(status & tx_not_ls))) {/* ... verify the status error condition */
Greg Kroah-Hartman
maintainerPATCH 226/272 net: stmmac: ensure that the MSS desc is the last desc to set the own bit
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit 15d2ee42a3087089e73ad52fd8c1b37ab496b87c ]
A dma_wmb() is used to guarantee the ordering, with respect to other writes, to cache coherent DMA memory.
There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which ensures that TDES0/1/2 is written before TDES3 (which contains the own bit), for First Desc.
However, in the rare case that MSS changes, there will be a MSS context descriptor in front of the regular DMA descriptors:
<MSS desc> <- DMA Next Descriptor
<First Desc>
<desc n>
<Last Desc>
Thus, for this special case, we need a dma_wmb()
after prepare_tso_tx_desc()/before writing the own bit to the MSS desc, so that we flush the write to TDES3 for First Desc,
in order to ensure that the MSS descriptor is the last descriptor to set the own bit.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +8 -1
@@ -2985,8 +2985,15 @@ static netdev_tx_t stmmac_tso_xmit(struc tcp_hdrlen(skb) / 4, (skb->len - proto_hdr_len));/* If context desc is used to change MSS */ -if (mss_desc) +if (mss_desc) { +/* Make sure that first descriptor has been completely +* written, including its own bit. This is because MSS is +* actually before first descriptor, so we need to make +* sure that MSS's own bit is the last thing written. +*/ +dma_wmb (); priv->hw->desc->set_tx_owner (mss_desc); + }/* The own bit must be the latest setting done when prepare the * descriptor and then barrier is needed to make sure that
Greg Kroah-Hartman
maintainerPATCH 227/272 cpufreq: Reorder cpufreq_online() error code path
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <[email protected]>
[ Upstream commit b24b6478e65f140610ab1ffaadc7bc6bf0be8aad ]
Ideally the de-allocation of resources should happen in the exact opposite order in which they were allocated. It helps maintain the code in long term, even if nothing really breaks with incorrect ordering.
That wasn't followed in cpufreq_online() and it has some inconsistencies. For example, the symlinks were created from within the locked region while they are removed only after putting the locks. Also ->exit() should have been called only after the symlinks are removed and the lock is dropped, as that was the case when ->init() was first called.
--- drivers/cpufreq/cpufreq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/cpufreq/cpufreq.c +3 -3
@@ -1327,14 +1327,14 @@ static int cpufreq_online(unsigned int creturn 0 ; out_exit_policy: +for_each_cpu (j, policy->real_cpus) +remove_cpu_dev_symlink (policy,get_cpu_device (j)); +up_write (&policy->rwsem);if (cpufreq_driver->exit) cpufreq_driver->exit (policy); -for_each_cpu (j, policy->real_cpus) -remove_cpu_dev_symlink (policy,get_cpu_device (j)); - out_free_policy:cpufreq_policy_free (policy);return ret;
Greg Kroah-Hartman
maintainerPATCH 228/272 dpaa_eth: fix SG mapping
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Madalin Bucur <[email protected]>
[ Upstream commit 120d75ecf043044554abbba8507f6d22e4715beb ]
An issue in the code mapping the skb fragments into scatter-gather frames was evidentiated by netperf TCP_SENDFILE tests. The size was set wrong for all fragments but the first, affecting the transmission of any skb with more than one fragment.
--- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +13 -10
@@ -1916,8 +1916,10 @@ static int skb_to_sg_fd(struct dpaa_priv goto csum_failed; } +/* SGT[0] is used by the linear part */ sgt = (struct qm_sg_entry *)(sgt_buf + priv->tx_headroom); -qm_sg_entry_set_len (&sgt[0 ],skb_headlen (skb)); + frag_len =skb_headlen (skb); +qm_sg_entry_set_len (&sgt[0 ], frag_len); sgt[0 ].bpid =FSL_DPAA_BPID_INV ; sgt[0 ].offset =0 ; addr = dma_map_single(dev, skb->data,
@@ -1930,9 +1932,9 @@ static int skb_to_sg_fd(struct dpaa_privqm_sg_entry_set64 (&sgt[0 ], addr);/* populate the rest of SGT entries */ - frag = &skb_shinfo (skb)->frags[0 ]; - frag_len = frag->size; -for (i =1 ; i <= nr_frags; i++, frag++) { +for (i =0 ; i < nr_frags; i++) { + frag = &skb_shinfo (skb)->frags[i]; + frag_len = frag->size;WARN_ON (!skb_frag_page (frag)); addr =skb_frag_dma_map (dev, frag,0 , frag_len, dma_dir);
@@ -1942,15 +1944,16 @@ static int skb_to_sg_fd(struct dpaa_priv goto sg_map_failed; } -qm_sg_entry_set_len (&sgt[i], frag_len); - sgt[i].bpid =FSL_DPAA_BPID_INV ; - sgt[i].offset =0 ; +qm_sg_entry_set_len (&sgt[i +1 ], frag_len); + sgt[i +1 ].bpid =FSL_DPAA_BPID_INV ; + sgt[i +1 ].offset =0 ;/* keep the offset in the address */ -qm_sg_entry_set64 (&sgt[i], addr); - frag_len = frag->size; +qm_sg_entry_set64 (&sgt[i +1 ], addr); } -qm_sg_entry_set_f (&sgt[i -1 ], frag_len); + +/* Set the final bit in the last used entry of the SGT */ +qm_sg_entry_set_f (&sgt[nr_frags], frag_len);qm_fd_set_sg (fd, priv->tx_headroom, skb->len);
Greg Kroah-Hartman
maintainerPATCH 229/272 PCI: Add function 1 DMA alias quirk for Marvell 88SE9220
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Vincent-Cross <[email protected]>
[ Upstream commit 832e4e1f76b8a84991e9db56fdcef1ebce839b8b ]
Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679.
--- drivers/pci/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pci/quirks.c +3 -0
@@ -3903,6 +3903,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c46 */ DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x91a0 , quirk_dma_func1_alias); +/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c127 */ +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x9220 , + quirk_dma_func1_alias);/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c49 */ DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x9230 , quirk_dma_func1_alias);
Greg Kroah-Hartman
maintainerPATCH 231/272 fanotify: Avoid lost events due to ENOMEM for unlimited queues
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
[ Upstream commit 1f5eaa90010ed7cf0ae90a526c48657d02c6086f ]
Fanotify queues of unlimited length do not expect events can be lost. Since these queues are used for system auditing and other security related tasks, loosing events can even have security implications. Currently, since the allocation is small (32-bytes), it cannot fail however when we start accounting events in memcgs, allocation can start failing. So avoid loosing events due to failure to allocate memory by making event allocation use __GFP_NOFAIL.
--- fs/notify/fanotify/fanotify.c | 19 ++++++++++++++----- fs/notify/fanotify/fanotify.h | 3 ++- fs/notify/fanotify/fanotify_user.c | 2 +- 3 files changed, 17 insertions(+), 7 deletions(-)
fs/notify/fanotify/fanotify.c +14 -5
@@ -135,23 +135,32 @@ static bool fanotify_should_send_event(sreturn false; } -struct fanotify_event_info *fanotify_alloc_event (struct inode *inode,u32 mask, +struct fanotify_event_info *fanotify_alloc_event (struct fsnotify_group *group, +struct inode *inode,u32 mask,const struct path *path) {struct fanotify_event_info *event; +gfp_t gfp =GFP_KERNEL ; + +/* +* For queues with unlimited length lost events are not expected and +* can possibly have security implications. Avoid losing events when +* memory is short. +*/ +if (group->max_events ==UINT_MAX ) + gfp |= __GFP_NOFAIL;if (fanotify_is_perm_event (mask)) {struct fanotify_perm_event_info *pevent; - pevent =kmem_cache_alloc (fanotify_perm_event_cachep, -GFP_KERNEL ); + pevent =kmem_cache_alloc (fanotify_perm_event_cachep, gfp);if (!pevent)return NULL ; event = &pevent->fae; pevent->response =0 ; goto init; } - event =kmem_cache_alloc (fanotify_event_cachep,GFP_KERNEL ); + event =kmem_cache_alloc (fanotify_event_cachep, gfp);if (!event)return NULL ; init:__maybe_unused
@@ -206,7 +215,7 @@ static int fanotify_handle_event(structreturn 0 ; } - event =fanotify_alloc_event (inode, mask, data); + event =fanotify_alloc_event (group, inode, mask, data); ret = -ENOMEM ;if (unlikely (!event)) goto finish;
fs/notify/fanotify/fanotify.h +2 -1
@@ -52,5 +52,6 @@ static inline struct fanotify_event_info return container_of(fse, struct fanotify_event_info, fse); } -struct fanotify_event_info *fanotify_alloc_event (struct inode *inode,u32 mask, +struct fanotify_event_info *fanotify_alloc_event (struct fsnotify_group *group, +struct inode *inode,u32 mask,const struct path *path);
fs/notify/fanotify/fanotify_user.c +1 -1
@@ -757,7 +757,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned group->fanotify_data.user = user;atomic_inc (&user->fanotify_listeners); - oevent =fanotify_alloc_event (NULL ,FS_Q_OVERFLOW ,NULL ); + oevent =fanotify_alloc_event (group,NULL ,FS_Q_OVERFLOW ,NULL );if (unlikely (!oevent)) { fd = -ENOMEM ; goto out_destroy_group;
Re: [PATCH 4.16 231/272] fanotify: Avoid lost events due to ENOMEM for unlimited queues
Quoted 2 lines · Greg Kroah-Hartman
4.16-stable review patch. If anyone has any objections, please let me know.
I do not have objections for applying this patch to stable, but AFAIK it is a correctness patch that doesn't fix any bug and it was mainly added as a prerequisite to memcg accounting of event allocations, which is not yet merged and not destined for stable.
Jan? do you agree with my statements above?
Thanks,
Amir.
Quoted 95 lines
------------------
From: Jan Kara <[email protected]>
[ Upstream commit
1f5eaa90010ed7cf0ae90a526c48657d02c6086f]Fanotify queues of unlimited length do not expect events can be lost. Since these queues are used for system auditing and other security related tasks, loosing events can even have security implications. Currently, since the allocation is small (32-bytes), it cannot fail however when we start accounting events in memcgs, allocation can start failing. So avoid loosing events due to failure to allocate memory by making event allocation use
__GFP_NOFAIL.Reviewed-by Amir Goldstein <[email protected]>Signed-off-by Jan Kara <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- fs/notify/fanotify/fanotify.c | 19 ++++++++++++++----- fs/notify/fanotify/fanotify.h | 3 ++- fs/notify/fanotify/fanotify_user.c | 2 +- 3 files changed, 17 insertions(+), 7 deletions(-)fs/notify/fanotify/fanotify.c +14
-5@@ -135,23 +135,32 @@ static bool fanotify_should_send_event(sreturn false; } -struct fanotify_event_info *fanotify_alloc_event (struct inode *inode,u32 mask, +struct fanotify_event_info *fanotify_alloc_event (struct fsnotify_group *group, +struct inode *inode,u32 mask,const struct path *path) {struct fanotify_event_info *event; +gfp_t gfp =GFP_KERNEL ; + +/* +* For queues with unlimited length lost events are not expected and +* can possibly have security implications. Avoid losing events when +* memory is short. +*/ +if (group->max_events ==UINT_MAX ) + gfp |= __GFP_NOFAIL;if (fanotify_is_perm_event (mask)) {struct fanotify_perm_event_info *pevent; - pevent =kmem_cache_alloc (fanotify_perm_event_cachep, -GFP_KERNEL ); + pevent =kmem_cache_alloc (fanotify_perm_event_cachep, gfp);if (!pevent)return NULL ; event = &pevent->fae; pevent->response =0 ; goto init; } - event =kmem_cache_alloc (fanotify_event_cachep,GFP_KERNEL ); + event =kmem_cache_alloc (fanotify_event_cachep, gfp);if (!event)return NULL ; init:__maybe_unused @@ -206,7 +215,7 @@ static int fanotify_handle_event(structreturn 0 ; } - event =fanotify_alloc_event (inode, mask, data); + event =fanotify_alloc_event (group, inode, mask, data); ret = -ENOMEM ;if (unlikely (!event)) goto finish;fs/notify/fanotify/fanotify.h +2
-1@@ -52,5 +52,6 @@ static inline struct fanotify_event_info return container_of(fse, struct fanotify_event_info, fse); } -struct fanotify_event_info *fanotify_alloc_event (struct inode *inode,u32 mask, +struct fanotify_event_info *fanotify_alloc_event (struct fsnotify_group *group, +struct inode *inode,u32 mask,const struct path *path);fs/notify/fanotify/fanotify_user.c +1
-1@@ -757,7 +757,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned group->fanotify_data.user = user;atomic_inc (&user->fanotify_listeners); - oevent =fanotify_alloc_event (NULL ,FS_Q_OVERFLOW ,NULL ); + oevent =fanotify_alloc_event (group,NULL ,FS_Q_OVERFLOW ,NULL );if (unlikely (!oevent)) { fd = -ENOMEM ; goto out_destroy_group;
Re: [PATCH 4.16 231/272] fanotify: Avoid lost events due to ENOMEM for unlimited queues
Quoted 11 lines · Amir Goldstein
Quoted 2 lines · Greg Kroah-Hartman
4.16-stable review patch. If anyone has any objections, please let me know.
I do not have objections for applying this patch to stable, but AFAIK it is a correctness patch that doesn't fix any bug and it was mainly added as a prerequisite to memcg accounting of event allocations, which is not yet merged and not destined for stable.
Jan? do you agree with my statements above?
Yes, you are correct. The problem this patch tries to fix is theoretical in nature at this point. However my feeling is stable tree has got rather benevolent in accepting patches in last months and Greg wishes it stays that way so I'm objecting only to patches I know introduce regressions at this point.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
Greg Kroah-Hartman
maintainerRe: [PATCH 4.16 231/272] fanotify: Avoid lost events due to ENOMEM for unlimited queues
Quoted 11 lines · Jan Kara
Quoted 10 lines · Amir Goldstein
Quoted 2 lines · Greg Kroah-Hartman
4.16-stable review patch. If anyone has any objections, please let me know.
I do not have objections for applying this patch to stable, but AFAIK it is a correctness patch that doesn't fix any bug and it was mainly added as a prerequisite to memcg accounting of event allocations, which is not yet merged and not destined for stable.
Quoted 7 lines
Quoted 1 line
Jan? do you agree with my statements above?
Yes, you are correct. The problem this patch tries to fix is theoretical in nature at this point. However my feeling is stable tree has got rather benevolent in accepting patches in last months and Greg wishes it stays that way so I'm objecting only to patches I know introduce regressions at this point.
I am getting "more benevolent", but the patch should be there for at least some good reason. This one was picked by the "semi-automatic" checker, and at first glance seems like it is a real bugfix. But, as you mention, it was only needed in preparation for a future patch, then this patch is not needed in the stable trees, and I'll go drop it now.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerPATCH 232/272 ixgbe: prevent ptp_rx_hang from running when in FILTER_ALL mode
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
[ Upstream commit 6704a3abf4cf4181a1ee64f5db4969347b88ca1d ]
On hardware which supports timestamping all packets, the timestamps are recorded in the packet buffer, and the driver no longer uses or reads the registers. This makes the logic for checking and clearing Rx timestamp hangs meaningless.
If we run the ixgbe_ptp_rx_hang() function in this case, then the driver will continuously spam the log output with "Clearing Rx timestamp hang". These messages are spurious, and confusing to end users.
The original code in commit a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices", 2015-12-03) did have a flag PTP_RX_TIMESTAMP_IN_REGISTER which was intended to be used to avoid the Rx timestamp hang check, however it did not actually check the flag before calling the function.
Do so now in order to stop the checks and prevent the spurious log messages.
--- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +2 -1
@@ -7711,7 +7711,8 @@ static void ixgbe_service_task(struct woif (test_bit (__IXGBE_PTP_RUNNING, &adapter->state)) {ixgbe_ptp_overflow_check (adapter); -ixgbe_ptp_rx_hang (adapter); +if (adapter->flags &IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ) +ixgbe_ptp_rx_hang (adapter);ixgbe_ptp_tx_hang (adapter); }
Greg Kroah-Hartman
maintainerPATCH 233/272 sh_eth: fix TSU init on SH7734/R8A7740
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
[ Upstream commit a94cf2a614f8bc5b2b33c708626ce695bf71e424 ]
It appears that the single port Ether controllers having TSU (like SH7734/ R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100 currently has -- they also don't have the TSU registers related e.g. to passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port' flag and use it as a new criterion for taking a "short path" in the TSU init sequence in order to avoid writing to the non-existent registers...
--- drivers/net/ethernet/renesas/sh_eth.c | 6 +++++- drivers/net/ethernet/renesas/sh_eth.h | 1 + 2 files changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/renesas/sh_eth.c +5 -1
@@ -763,6 +763,7 @@ static struct sh_eth_cpu_data sh7757_dat .rpadir = 1, .rpadir_value = 2 << 16, .rtrate = 1, + .dual_port = 1, };#define SH_GIGA_ETH_BASE 0xfee00000UL
@@ -841,6 +842,7 @@ static struct sh_eth_cpu_data sh7757_dat .no_trimd = 1, .no_ade = 1, .tsu = 1, + .dual_port = 1, };/* SH7734 */
@@ -911,6 +913,7 @@ static struct sh_eth_cpu_data sh7763_dat .tsu = 1, .irq_flags = IRQF_SHARED, .magic = 1, + .dual_port = 1, };static struct sh_eth_cpu_data sh7619_data = {
@@ -943,6 +946,7 @@ static struct sh_eth_cpu_data sh771x_datEESIPR_RRFIP |EESIPR_RTLFIP |EESIPR_RTSFIP | EESIPR_PREIP | EESIPR_CERFIP, .tsu = 1, + .dual_port = 1, };static void sh_eth_set_default_cpu_data (struct sh_eth_cpu_data *cd)
@@ -2932,7 +2936,7 @@ static int sh_eth_vlan_rx_kill_vid(struc/* SuperH's TSU register init function */ static void sh_eth_tsu_init (struct sh_eth_private *mdp) { -if (sh_eth_is_rz_fast_ether (mdp)) { +if (!mdp->cd->dual_port) {sh_eth_tsu_write (mdp,0 ,TSU_TEN );/* Disable all CAM entry */ sh_eth_tsu_write (mdp,TSU_FWSLC_POSTENU |TSU_FWSLC_POSTENL ,TSU_FWSLC );/* Enable POST registers */
drivers/net/ethernet/renesas/sh_eth.h +1 -0
@@ -509,6 +509,7 @@ struct sh_eth_cpu_data { unsigned rmiimode:1; /* EtherC has RMIIMODE register */ unsigned rtrate:1; /* EtherC has RTRATE register */ unsigned magic:1; /* EtherC has ECMR.MPDE and ECSR.MPD */ + unsigned dual_port:1; /* Dual EtherC/E-DMAC */ };struct sh_eth_private {
Greg Kroah-Hartman
maintainerPATCH 234/272 power: supply: ltc2941-battery-gauge: Fix temperature units
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ladislav Michl <[email protected]>
[ Upstream commit dde5953f05a89eb63a0d666ffe51d447b2ac3e05 ]
Temperature is measured in tenths of degree Celsius.
--- drivers/power/supply/ltc2941-battery-gauge.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/power/supply/ltc2941-battery-gauge.c +4 -4
@@ -317,15 +317,15 @@ static int ltc294x_get_temperature(constif (info->id ==LTC2942_ID ) { reg =LTC2942_REG_TEMPERATURE_MSB ; - value =60000 ;/* Full-scale is 600 Kelvin */ + value =6000 ;/* Full-scale is 600 Kelvin */ }else { reg =LTC2943_REG_TEMPERATURE_MSB ; - value =51000 ;/* Full-scale is 510 Kelvin */ + value =5100 ;/* Full-scale is 510 Kelvin */ } ret =ltc294x_read_regs (info->client, reg, &datar[0 ],2 ); value *= (datar[0 ] <<8 ) | datar[1 ]; -/* Convert to centidegrees */ - *val = value /0xFFFF -27215 ; +/* Convert to tenths of degree Celsius */ + *val = value /0xFFFF -2722 ;return ret; }
Greg Kroah-Hartman
maintainerPATCH 235/272 ARM: dts: bcm283x: Fix probing of bcm2835-i2s
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <[email protected]>
[ Upstream commit 79c81facdc0b43b1cef37b8d5689a8c8b78f8be0 ]
Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework") the bcm2835-i2s requires a clock as DT property. Unfortunately the necessary DT change has never been applied. While we are at it also fix the first PCM register range to cover the PCM_GRAY register.
--- arch/arm/boot/dts/bcm283x.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/bcm283x.dtsi +2 -2
@@ -397,8 +397,8 @@ i2s: i2s@7e203000 { compatible = "brcm,bcm2835-i2s"; - reg = <0x7e203000 0x20>, - <0x7e101098 0x02>; + reg = <0x7e203000 0x24>; + clocks = <&clocks BCM2835_CLOCK_PCM>; dmas = <&dma 2>, <&dma 3>;
Greg Kroah-Hartman
maintainerPATCH 236/272 ARM: dts: bcm283x: Fix pin function of JTAG pins
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henry Zhang <[email protected]>
[ Upstream commit 1a012cb2569f2031b3636232c3ab21c20c92d281 ]
BCM2835 ARM Peripherals doc shows gpio pins 4, 5, 6, 12 and 13 carry altenate function, ALT5 for ARM JTAG
--- arch/arm/boot/dts/bcm283x.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/bcm283x.dtsi +1 -1
@@ -252,7 +252,7 @@ jtag_gpio4: jtag_gpio4 { brcm,pins = <4 5 6 12 13>; - brcm,function = <BCM2835_FSEL_ALT4>; + brcm,function = <BCM2835_FSEL_ALT5>; }; jtag_gpio22: jtag_gpio22 { brcm,pins = <22 23 24 25 26 27>;
Greg Kroah-Hartman
maintainerPATCH 237/272 PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
[ Upstream commit dbdd0f58fd2cdde5cf945c9da67a2d52d32ba550 ]
There is a problem with PCMCIA system resume callbacks with respect to suspend-to-idle in which the ->suspend_noirq() callback may be invoked after the ->resume_noirq() one without resuming the system entirely in some cases. This doesn't work for PCMCIA because of the lack of symmetry between its system suspend and system resume "noirq" callbacks.
The system resume handling in PCMCIA is split between socket_early_resume() and socket_late_resume() which are called in different phases of system resume and both need to run for socket_suspend() (invoked by the system suspend "noirq" callback) to work. Specifically, socket_suspend() returns an error when called after socket_early_resume() without socket_late_resume(), so if the suspend-to-idle core detects a spurious wakeup event and attempts to put the system back to sleep, that is aborted by the error coming from socket_suspend().
Avoid that by using a new socket state flag, SOCKET_IN_RESUME, to indicate that socket_early_resume() has already run for the socket in which case socket_suspend() will do minimum handling and return 0.
This change has been tested on my venerable Toshiba Portege R500 (which is where the problem has been discovered in the first place), but admittedly I have no PCMCIA cards to test along with the socket itself.
--- drivers/pcmcia/cs.c | 10 +++++++--- drivers/pcmcia/cs_internal.h | 1 + 2 files changed, 8 insertions(+), 3 deletions(-)
drivers/pcmcia/cs.c +7 -3
@@ -452,17 +452,20 @@ static int socket_insert(struct pcmcia_sstatic int socket_suspend (struct pcmcia_socket *skt) { -if (skt->state &SOCKET_SUSPEND ) +if ((skt->state &SOCKET_SUSPEND ) && !(skt->state &SOCKET_IN_RESUME ))return -EBUSY ;mutex_lock (&skt->ops_mutex); - skt->suspended_state = skt->state; +/* store state on first suspend, but not after spurious wakeups */ +if (!(skt->state &SOCKET_IN_RESUME )) + skt->suspended_state = skt->state; skt->socket = dead_socket; skt->ops->set_socket (skt, &skt->socket);if (skt->ops->suspend) skt->ops->suspend (skt); skt->state |=SOCKET_SUSPEND ; + skt->state &= ~SOCKET_IN_RESUME ;mutex_unlock (&skt->ops_mutex);return 0 ; }
@@ -475,6 +478,7 @@ static int socket_early_resume(struct pc skt->ops->set_socket (skt, &skt->socket);if (skt->state &SOCKET_PRESENT ) skt->resume_status =socket_setup (skt, resume_delay); + skt->state |=SOCKET_IN_RESUME ;mutex_unlock (&skt->ops_mutex);return 0 ; }
@@ -484,7 +488,7 @@ static int socket_late_resume(struct pcmint ret =0 ;mutex_lock (&skt->ops_mutex); - skt->state &= ~SOCKET_SUSPEND ; + skt->state &= ~(SOCKET_SUSPEND |SOCKET_IN_RESUME );mutex_unlock (&skt->ops_mutex);if (!(skt->state &SOCKET_PRESENT )) {
drivers/pcmcia/cs_internal.h +1 -0
@@ -70,6 +70,7 @@ struct pccard_resource_ops {/* Flags in socket state */ #define SOCKET_PRESENT 0x0008#define SOCKET_INUSE 0x0010 +#define SOCKET_IN_RESUME 0x0040#define SOCKET_SUSPEND 0x0080#define SOCKET_WIN_REQ (i) (0x0100<<(i))#define SOCKET_CARDBUS 0x8000
Greg Kroah-Hartman
maintainerPATCH 238/272 hwrng: bcm2835 - Handle deferred clock properly
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <[email protected]>
[ Upstream commit 7b4c5d30d0bd2b22c09d4d993a76e0973a873891 ]
In case the probe of the clock is deferred, we would assume it is optional. This is wrong, so defer the probe of this driver until the clock is available.
--- drivers/char/hw_random/bcm2835-rng.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/char/hw_random/bcm2835-rng.c +2 -0
@@ -163,6 +163,8 @@ static int bcm2835_rng_probe(struct plat/* Clock is optional on most platforms */ priv->clk =devm_clk_get (dev,NULL ); +if (IS_ERR (priv->clk) &&PTR_ERR (priv->clk) == -EPROBE_DEFER ) +return -EPROBE_DEFER ; priv->rng.name = pdev->name; priv->rng.init = bcm2835_rng_init;
Greg Kroah-Hartman
maintainerPATCH 239/272 audit: return on memory error to avoid null pointer dereference
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Guy Briggs <[email protected]>
[ Upstream commit 23138ead270045f1b3e912e667967b6094244999 ]
If there is a memory allocation error when trying to change an audit kernel feature value, the ignored allocation error will trigger a NULL pointer dereference oops on subsequent use of that pointer. Return instead.
Passes audit-testsuite.
See: https://github.com/linux-audit/audit-kernel/issues/76
--- kernel/audit.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/audit.c +2 -0
@@ -1058,6 +1058,8 @@ static void audit_log_feature_change(intreturn ; ab =audit_log_start (NULL ,GFP_KERNEL ,AUDIT_FEATURE_CHANGE ); +if (!ab) +return ;audit_log_task_info (ab, current); audit_log_format(ab, " feature=%s old=%u new=%u old_lock=%u new_lock=%u res=%d", audit_feature_names[which], !!old_feature, !!new_feature,
Greg Kroah-Hartman
maintainerPATCH 240/272 net: stmmac: call correct function in stmmac_mac_config_rx_queues_routing()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
[ Upstream commit 13138de01400762f706c5e956e70660770d61962 ]
stmmac_mac_config_rx_queues_routing() incorrectly calls rx_queue_prio() instead of rx_queue_routing().
This looks like a copy paste issue, since stmmac_mac_config_rx_queues_prio() already calls rx_queue_prio(), and both stmmac_mac_config_rx_queues_routing() and stmmac_mac_config_rx_queues_prio() are very similar in structure.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +1 -1
@@ -2435,7 +2435,7 @@ static void stmmac_mac_config_rx_queues_continue ; packet = priv->plat->rx_queues_cfg[queue].pkt_route; - priv->hw->mac->rx_queue_prio (priv->hw, packet, queue); + priv->hw->mac->rx_queue_routing (priv->hw, packet, queue); } }
Greg Kroah-Hartman
maintainerPATCH 241/272 rcu: Call touch_nmi_watchdog() while printing stall warnings
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
[ Upstream commit 3caa973b7a260e7a2a69edc94c300ab9c65148c3 ]
When RCU stall warning triggers, it can print out a lot of messages while holding spinlocks. If the console device is slow (e.g. an actual or IPMI serial console), it may end up triggering NMI hard lockup watchdog like the following.
--- kernel/rcu/tree_plugin.h | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
kernel/rcu/tree_plugin.h +13 -1
@@ -560,8 +560,14 @@ static void rcu_print_detail_task_stall_ } t =list_entry (rnp->gp_tasks->prev, struct task_struct, rcu_node_entry); -list_for_each_entry_continue (t, &rnp->blkd_tasks, rcu_node_entry) +list_for_each_entry_continue (t, &rnp->blkd_tasks, rcu_node_entry) { +/* +* We could be printing a lot while holding a spinlock. +* Avoid triggering hard lockup. +*/ +touch_nmi_watchdog ();sched_show_task (t); + }raw_spin_unlock_irqrestore_rcu_node (rnp, flags); }
@@ -1677,6 +1683,12 @@ static void print_cpu_stall_info(structchar *ticks_title;unsigned long ticks_value; +/* +* We could be printing a lot while holding a spinlock. Avoid +* triggering hard lockup. +*/ +touch_nmi_watchdog (); +if (rsp->gpnum == rdp->gpnum) { ticks_title ="ticks this GP" ; ticks_value = rdp->ticks_this_gp;
Greg Kroah-Hartman
maintainerPATCH 242/272 pinctrl: sh-pfc: r8a7796: Fix MOD_SEL register pin assignment for SSI pins group
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takeshi Kihara <[email protected]>
[ Upstream commit b418c4609d5052d174668ad6d13efe023c45c595 ]
This patch fixes MOD_SEL1 bit20 and MOD_SEL2 bit20, bit21 pin assignment for SSI pins group.
This is a correction to the incorrect implementation of MOD_SEL register pin assignment for R8A7796 SoC specification of R-Car Gen3 Hardware User's Manual Rev.0.51E or later.
--- drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 40 +++++++++++++++++------------------ 1 file changed, 20 insertions(+), 20 deletions(-)
drivers/pinctrl/sh-pfc/pfc-r8a7796.c +20 -20
@@ -1,7 +1,7 @@/* * R8A7796 processor support - PFC hardware block. * -* Copyright (C) 2016 Renesas Electronics Corp. +* Copyright (C) 2016-2017 Renesas Electronics Corp. * * This file is based on the drivers/pinctrl/sh-pfc/pfc-r8a7795.c *
@@ -477,7 +477,7 @@ FM(IP16_31_28) IP16_31_28 FM(IP17_31_28)#define MOD_SEL1_26 FM(SEL_TIMER_TMU_0) FM(SEL_TIMER_TMU_1)#define MOD_SEL1_25_24 FM(SEL_SSP1_1_0) FM(SEL_SSP1_1_1) FM(SEL_SSP1_1_2) FM(SEL_SSP1_1_3)#define MOD_SEL1_23_22_21 FM(SEL_SSP1_0_0) FM(SEL_SSP1_0_1) FM(SEL_SSP1_0_2) FM(SEL_SSP1_0_3) FM(SEL_SSP1_0_4) F_(0, 0) F_(0, 0) F_(0, 0) -#define MOD_SEL1_20 FM(SEL_SSI_0) FM(SEL_SSI_1) +#define MOD_SEL1_20 FM(SEL_SSI1_0) FM(SEL_SSI1_1)#define MOD_SEL1_19 FM(SEL_SPEED_PULSE_0) FM(SEL_SPEED_PULSE_1)#define MOD_SEL1_18_17 FM(SEL_SIMCARD_0) FM(SEL_SIMCARD_1) FM(SEL_SIMCARD_2) FM(SEL_SIMCARD_3)#define MOD_SEL1_16 FM(SEL_SDHI2_0) FM(SEL_SDHI2_1)
@@ -1218,7 +1218,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_11_8 ,HSCK0 ),PINMUX_IPSR_MSEL (IP13_11_8 ,MSIOF1_SCK_D ,SEL_MSIOF1_3 ),PINMUX_IPSR_MSEL (IP13_11_8 ,AUDIO_CLKB_A ,SEL_ADG_B_0 ), -PINMUX_IPSR_MSEL (IP13_11_8 ,SSI_SDATA1_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP13_11_8 ,SSI_SDATA1_B ,SEL_SSI1_1 ),PINMUX_IPSR_MSEL (IP13_11_8 ,TS_SCK0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_11_8 ,STP_ISCLK_0_D ,SEL_SSP1_0_3 ), PINMUX_IPSR_MSEL(IP13_11_8, RIF0_CLK_C, SEL_DRIF0_2),
@@ -1226,14 +1226,14 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_15_12 ,HRX0 ),PINMUX_IPSR_MSEL (IP13_15_12 ,MSIOF1_RXD_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_15_12 ,SSI_SDATA2_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP13_15_12 ,SSI_SDATA2_B ,SEL_SSI2_1 ),PINMUX_IPSR_MSEL (IP13_15_12 ,TS_SDEN0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_15_12 ,STP_ISEN_0_D ,SEL_SSP1_0_3 ),PINMUX_IPSR_MSEL (IP13_15_12 ,RIF0_D0_C ,SEL_DRIF0_2 ),PINMUX_IPSR_GPSR (IP13_19_16 ,HTX0 ),PINMUX_IPSR_MSEL (IP13_19_16 ,MSIOF1_TXD_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_19_16 ,SSI_SDATA9_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP13_19_16 ,SSI_SDATA9_B ,SEL_SSI9_1 ),PINMUX_IPSR_MSEL (IP13_19_16 ,TS_SDAT0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_19_16 ,STP_ISD_0_D ,SEL_SSP1_0_3 ), PINMUX_IPSR_MSEL(IP13_19_16, RIF0_D1_C, SEL_DRIF0_2),
@@ -1241,7 +1241,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_23_20 ,HCTS0_N ),PINMUX_IPSR_MSEL (IP13_23_20 ,RX2_B ,SEL_SCIF2_1 ),PINMUX_IPSR_MSEL (IP13_23_20 ,MSIOF1_SYNC_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_23_20 ,SSI_SCK9_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP13_23_20 ,SSI_SCK9_A ,SEL_SSI9_0 ),PINMUX_IPSR_MSEL (IP13_23_20 ,TS_SPSYNC0_D ,SEL_TSIF0_3 ),PINMUX_IPSR_MSEL (IP13_23_20 ,STP_ISSYNC_0_D ,SEL_SSP1_0_3 ), PINMUX_IPSR_MSEL(IP13_23_20, RIF0_SYNC_C, SEL_DRIF0_2),
@@ -1250,7 +1250,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP13_27_24 ,HRTS0_N ),PINMUX_IPSR_MSEL (IP13_27_24 ,TX2_B ,SEL_SCIF2_1 ),PINMUX_IPSR_MSEL (IP13_27_24 ,MSIOF1_SS1_D ,SEL_MSIOF1_3 ), -PINMUX_IPSR_MSEL (IP13_27_24 ,SSI_WS9_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP13_27_24 ,SSI_WS9_A ,SEL_SSI9_0 ),PINMUX_IPSR_MSEL (IP13_27_24 ,STP_IVCXO27_0_D ,SEL_SSP1_0_3 ),PINMUX_IPSR_MSEL (IP13_27_24 ,BPFCLK_A ,SEL_FM_0 ), PINMUX_IPSR_GPSR(IP13_27_24, AUDIO_CLKOUT2_A),
@@ -1265,7 +1265,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP14_3_0 ,RX5_A ,SEL_SCIF5_0 ),PINMUX_IPSR_MSEL (IP14_3_0 ,NFWP_N_A ,SEL_NDF_0 ),PINMUX_IPSR_MSEL (IP14_3_0 ,AUDIO_CLKA_C ,SEL_ADG_A_2 ), -PINMUX_IPSR_MSEL (IP14_3_0 ,SSI_SCK2_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP14_3_0 ,SSI_SCK2_A ,SEL_SSI2_0 ),PINMUX_IPSR_MSEL (IP14_3_0 ,STP_IVCXO27_0_C ,SEL_SSP1_0_2 ),PINMUX_IPSR_GPSR (IP14_3_0 ,AUDIO_CLKOUT3_A ), PINMUX_IPSR_MSEL(IP14_3_0, TCLK1_B, SEL_TIMER_TMU_1),
@@ -1274,7 +1274,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP14_7_4 ,TX5_A ,SEL_SCIF5_0 ),PINMUX_IPSR_MSEL (IP14_7_4 ,MSIOF1_SS2_D ,SEL_MSIOF1_3 ),PINMUX_IPSR_MSEL (IP14_7_4 ,AUDIO_CLKC_A ,SEL_ADG_C_0 ), -PINMUX_IPSR_MSEL (IP14_7_4 ,SSI_WS2_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP14_7_4 ,SSI_WS2_A ,SEL_SSI2_0 ),PINMUX_IPSR_MSEL (IP14_7_4 ,STP_OPWM_0_D ,SEL_SSP1_0_3 ),PINMUX_IPSR_GPSR (IP14_7_4 ,AUDIO_CLKOUT_D ), PINMUX_IPSR_MSEL(IP14_7_4, SPEEDIN_B, SEL_SPEED_PULSE_1),
@@ -1302,10 +1302,10 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP14_31_28 ,MSIOF1_SS2_F ,SEL_MSIOF1_5 ),/* IPSR15 */ -PINMUX_IPSR_MSEL (IP15_3_0 ,SSI_SDATA1_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP15_3_0 ,SSI_SDATA1_A ,SEL_SSI1_0 ), -PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SDATA2_A ,SEL_SSI_0 ), -PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SCK1_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SDATA2_A ,SEL_SSI2_0 ), +PINMUX_IPSR_MSEL (IP15_7_4 ,SSI_SCK1_B ,SEL_SSI1_1 ),PINMUX_IPSR_GPSR (IP15_11_8 ,SSI_SCK349 ), PINMUX_IPSR_MSEL(IP15_11_8, MSIOF1_SS1_A, SEL_MSIOF1_0),
@@ -1391,11 +1391,11 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_MSEL (IP16_27_24 ,RIF1_D1_A ,SEL_DRIF1_0 ),PINMUX_IPSR_MSEL (IP16_27_24 ,RIF3_D1_A ,SEL_DRIF3_0 ), -PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_SDATA9_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_SDATA9_A ,SEL_SSI9_0 ),PINMUX_IPSR_MSEL (IP16_31_28 ,HSCK2_B ,SEL_HSCIF2_1 ),PINMUX_IPSR_MSEL (IP16_31_28 ,MSIOF1_SS1_C ,SEL_MSIOF1_2 ),PINMUX_IPSR_MSEL (IP16_31_28 ,HSCK1_A ,SEL_HSCIF1_0 ), -PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_WS1_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP16_31_28 ,SSI_WS1_B ,SEL_SSI1_1 ),PINMUX_IPSR_GPSR (IP16_31_28 ,SCK1 ),PINMUX_IPSR_MSEL (IP16_31_28 ,STP_IVCXO27_1_A ,SEL_SSP1_1_0 ), PINMUX_IPSR_MSEL(IP16_31_28, SCK5_A, SEL_SCIF5_0),
@@ -1427,7 +1427,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_19_16 ,USB1_PWEN ),PINMUX_IPSR_MSEL (IP17_19_16 ,SIM0_CLK_C ,SEL_SIMCARD_2 ), -PINMUX_IPSR_MSEL (IP17_19_16 ,SSI_SCK1_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP17_19_16 ,SSI_SCK1_A ,SEL_SSI1_0 ),PINMUX_IPSR_MSEL (IP17_19_16 ,TS_SCK0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP17_19_16 ,STP_ISCLK_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP17_19_16, FMCLK_B, SEL_FM_1),
@@ -1437,7 +1437,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_23_20 ,USB1_OVC ),PINMUX_IPSR_MSEL (IP17_23_20 ,MSIOF1_SS2_C ,SEL_MSIOF1_2 ), -PINMUX_IPSR_MSEL (IP17_23_20 ,SSI_WS1_A ,SEL_SSI_0 ), +PINMUX_IPSR_MSEL (IP17_23_20 ,SSI_WS1_A ,SEL_SSI1_0 ),PINMUX_IPSR_MSEL (IP17_23_20 ,TS_SDAT0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP17_23_20 ,STP_ISD_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP17_23_20, FMIN_B, SEL_FM_1),
@@ -1447,7 +1447,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_27_24 ,USB30_PWEN ),PINMUX_IPSR_GPSR (IP17_27_24 ,AUDIO_CLKOUT_B ), -PINMUX_IPSR_MSEL (IP17_27_24 ,SSI_SCK2_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP17_27_24 ,SSI_SCK2_B ,SEL_SSI2_1 ),PINMUX_IPSR_MSEL (IP17_27_24 ,TS_SDEN1_D ,SEL_TSIF1_3 ),PINMUX_IPSR_MSEL (IP17_27_24 ,STP_ISEN_1_D ,SEL_SSP1_1_3 ), PINMUX_IPSR_MSEL(IP17_27_24, STP_OPWM_0_E, SEL_SSP1_0_4),
@@ -1459,7 +1459,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP17_31_28 ,USB30_OVC ),PINMUX_IPSR_GPSR (IP17_31_28 ,AUDIO_CLKOUT1_B ), -PINMUX_IPSR_MSEL (IP17_31_28 ,SSI_WS2_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP17_31_28 ,SSI_WS2_B ,SEL_SSI2_1 ),PINMUX_IPSR_MSEL (IP17_31_28 ,TS_SPSYNC1_D ,SEL_TSIF1_3 ),PINMUX_IPSR_MSEL (IP17_31_28 ,STP_ISSYNC_1_D ,SEL_SSP1_1_3 ), PINMUX_IPSR_MSEL(IP17_31_28, STP_IVCXO27_0_E, SEL_SSP1_0_4),
@@ -1470,7 +1470,7 @@ static const u16 pinmux_data[] = {/* IPSR18 */ PINMUX_IPSR_GPSR (IP18_3_0 ,GP6_30 ),PINMUX_IPSR_GPSR (IP18_3_0 ,AUDIO_CLKOUT2_B ), -PINMUX_IPSR_MSEL (IP18_3_0 ,SSI_SCK9_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP18_3_0 ,SSI_SCK9_B ,SEL_SSI9_1 ),PINMUX_IPSR_MSEL (IP18_3_0 ,TS_SDEN0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP18_3_0 ,STP_ISEN_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP18_3_0, RIF2_D0_B, SEL_DRIF2_1),
@@ -1480,7 +1480,7 @@ static const u16 pinmux_data[] = {PINMUX_IPSR_GPSR (IP18_7_4 ,GP6_31 ),PINMUX_IPSR_GPSR (IP18_7_4 ,AUDIO_CLKOUT3_B ), -PINMUX_IPSR_MSEL (IP18_7_4 ,SSI_WS9_B ,SEL_SSI_1 ), +PINMUX_IPSR_MSEL (IP18_7_4 ,SSI_WS9_B ,SEL_SSI9_1 ),PINMUX_IPSR_MSEL (IP18_7_4 ,TS_SPSYNC0_E ,SEL_TSIF0_4 ),PINMUX_IPSR_MSEL (IP18_7_4 ,STP_ISSYNC_0_E ,SEL_SSP1_0_4 ), PINMUX_IPSR_MSEL(IP18_7_4, RIF2_D1_B, SEL_DRIF2_1),
Greg Kroah-Hartman
maintainerPATCH 243/272 dt-bindings: display: msm/dsi: Fix the PHY regulator supply props
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Archit Taneja <[email protected]>
[ Upstream commit 8c4905fd4939c59e0f7993ba34883e328eef4b59 ]
The PHY regulator supply names vary across different PHY versions. Mention explicitly which PHYs require which supplies.
--- Documentation/devicetree/bindings/display/msm/dsi.txt | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/devicetree/bindings/display/msm/dsi.txt +4 -0
@@ -102,7 +102,11 @@ Required properties: - clocks: Phandles to device clocks. See [1] for details on clock bindings. - clock-names: the following clocks are required: * "iface" + For 28nm HPM/LP, 28nm 8960 PHYs: - vddio-supply: phandle to vdd-io regulator device node + For 20nm PHY: +- vddio-supply: phandle to vdd-io regulator device node +- vcca-supply: phandle to vcca regulator device node Optional properties: - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
Greg Kroah-Hartman
maintainerPATCH 244/272 drm/amd/display: Set vsc pack revision when DPCD revision is >= 1.2
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tao <[email protected]>
[ Upstream commit 3b94a4007dcfd4ac5780cd3d8a2d99979c966073 ]
Brightness couldn't change when booting up in DC mode.
It was because "psr_enabled" flag was not set to true before setting vsc packet revision, causing packet rev setup was skipped. Now instead of checking the psr flag, it checks if the DPCD_REV >= 1.2 and set the vsc packet revision.
--- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/core/dc_resource.c +3 -1
@@ -35,6 +35,7 @@#include "core_types.h" #include "set_mode_types.h" #include "virtual/virtual_stream_encoder.h" +#include "dpcd_defs.h" #include "dce80/dce80_resource.h" #include "dce100/dce100_resource.h"
@@ -2428,7 +2429,8 @@ static void set_vsc_info_packet(unsigned int vscPacketRevision =0 ;unsigned int i; -if (stream->sink->link->psr_enabled) { +/*VSC packet set to 2 when DP revision >= 1.2*/ +if (stream->sink->link->dpcd_caps.dpcd_rev.raw >=DPCD_REV_12 ) { vscPacketRevision =2 ; }
Greg Kroah-Hartman
maintainerPATCH 245/272 dpaa_eth: fix pause capability advertisement logic
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jake Moroni <[email protected]>
[ Upstream commit 3021efb440d02bf5b952b6d151c7ffee9bdd49fe ]
The ADVERTISED_Asym_Pause bit was being improperly set when both rx and tx pause were enabled. When rx and tx are both enabled, only the ADVERTISED_Pause bit is supposed to be set.
--- drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c +1 -1
@@ -211,7 +211,7 @@ static int dpaa_set_pauseparam(struct neif (epause->rx_pause) newadv = ADVERTISED_Pause | ADVERTISED_Asym_Pause;if (epause->tx_pause) - newadv |= ADVERTISED_Asym_Pause; + newadv ^= ADVERTISED_Asym_Pause; oldadv = phydev->advertising & (ADVERTISED_Pause | ADVERTISED_Asym_Pause);
Greg Kroah-Hartman
maintainerPATCH 246/272 MIPS: Octeon: Fix logging messages with spurious periods after newlines
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Perches <[email protected]>
[ Upstream commit db6775ca6e0353d2618ca7d5e210fc36ad43bbd4 ]
Using a period after a newline causes bad output.
Patchwork: https://patchwork.linux-mips.org/patch/17886/
--- arch/mips/cavium-octeon/octeon-irq.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
arch/mips/cavium-octeon/octeon-irq.c +5 -5
@@ -2271,7 +2271,7 @@ static int __init octeon_irq_init_cib(st parent_irq =irq_of_parse_and_map (ciu_node,0 );if (!parent_irq) { -pr_err ("ERROR: Couldn't acquire parent_irq for %s\n." , +pr_err ("ERROR: Couldn't acquire parent_irq for %s\n" , ciu_node->name);return -EINVAL ; }
@@ -2283,7 +2283,7 @@ static int __init octeon_irq_init_cib(st addr =of_get_address (ciu_node,0 ,NULL ,NULL );if (!addr) { -pr_err ("ERROR: Couldn't acquire reg(0) %s\n." , ciu_node->name); +pr_err ("ERROR: Couldn't acquire reg(0) %s\n" , ciu_node->name);return -EINVAL ; } host_data->raw_reg = (u64)phys_to_virt(
@@ -2291,7 +2291,7 @@ static int __init octeon_irq_init_cib(st addr =of_get_address (ciu_node,1 ,NULL ,NULL );if (!addr) { -pr_err ("ERROR: Couldn't acquire reg(1) %s\n." , ciu_node->name); +pr_err ("ERROR: Couldn't acquire reg(1) %s\n" , ciu_node->name);return -EINVAL ; } host_data->en_reg = (u64)phys_to_virt(
@@ -2299,7 +2299,7 @@ static int __init octeon_irq_init_cib(st r =of_property_read_u32 (ciu_node,"cavium,max-bits" , &val);if (r) { -pr_err ("ERROR: Couldn't read cavium,max-bits from %s\n." , +pr_err ("ERROR: Couldn't read cavium,max-bits from %s\n" , ciu_node->name);return r; }
@@ -2309,7 +2309,7 @@ static int __init octeon_irq_init_cib(st &octeon_irq_domain_cib_ops, host_data);if (!cib_domain) { -pr_err ("ERROR: Couldn't irq_domain_add_linear()\n." ); +pr_err ("ERROR: Couldn't irq_domain_add_linear()\n" );return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 249/272 x86/apic: Set up through-local-APIC mode on the boot CPU if noapic specified
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baoquan He <[email protected]>
[ Upstream commit bee3204ec3c49f6f53add9c3962c9012a5c036fa ]
Currently the kdump kernel becomes very slow if 'noapic' is specified. Normal kernel doesn't have this bug.
Kernel parameter 'noapic' is used to disable IO-APIC in system for testing or special purpose. Here the root cause is that in kdump kernel LAPIC is disabled since commit:
522e664644 ("x86/apic: Disable I/O APIC before shutdown of the local APIC")
In this case we need set up through-local-APIC on boot CPU in setup_local_APIC().
In normal kernel the legacy irq mode is enabled by the BIOS. If it is virtual wire mode, the local-APIC has been enabled and set as through-local-APIC.
Though we fixed the regression introduced by commit 522e664644, to further improve robustness set up the through-local-APIC mode explicitly, do not rely on the default boot IRQ mode.
--- arch/x86/kernel/apic/apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/apic/apic.c +1 -1
@@ -1570,7 +1570,7 @@ void setup_local_APIC(void)* TODO: set up through-local-APIC from through-I/O-APIC? --macro */ value =apic_read (APIC_LVT0 ) &APIC_LVT_MASKED ; -if (!cpu && (pic_mode || !value)) { +if (!cpu && (pic_mode || !value || skip_ioapic_setup)) { value =APIC_DM_EXTINT ;apic_printk (APIC_VERBOSE ,"enabled ExtINT on CPU#%d\n" , cpu); }else {
Greg Kroah-Hartman
maintainerPATCH 250/272 perf test: Fix test case inet_pton to accept inlines.
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Richter <[email protected]>
[ Upstream commit 0f19a038afdc592176c9a302f0d08be6a68ad74a ]
Using Fedora 27 and latest Linux kernel the test case trace+probe_libc_inet_pton.sh fails again on s390. This time is the inlining of functions which does not match. After an update of the glibc (from 2.26-16 to 2.26-24) the output is different
The expected output is:
__inet_pton (/usr/lib64/libc-2.26.so)
gaih_inet (inlined)
....The actual output is:
1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.061/0.061/0.061/0.000 ms
0.000 probe_libc:inet_pton:(3ffb2140448))
__inet_pton (inlined)
gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
...Fix this by being less strict on 'inlined' verses library name and accept both
--- tools/perf/tests/shell/trace+probe_libc_inet_pton.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
tools/perf/tests/shell/trace+probe_libc_inet_pton.sh +3 -3
@@ -21,12 +21,12 @@ trace_libc_inet_pton_backtrace() { expected[3]=".*packets transmitted.*" expected[4]="rtt min.*" expected[5]="[0-9]+\.[0-9]+[[:space:]]+probe_libc:inet_pton:\([[:xdigit:]]+\)" - expected[6]=".*inet_pton[[:space:]]\($libc\)$" + expected[6]=".*inet_pton[[:space:]]\($libc|inlined\)$" case "$(uname -m)" in s390x) eventattr='call-graph=dwarf' - expected[7]="gaih_inet[[:space:]]\(inlined\)$" - expected[8]="__GI_getaddrinfo[[:space:]]\(inlined\)$" + expected[7]="gaih_inet.*[[:space:]]\($libc|inlined\)$" + expected[8]="__GI_getaddrinfo[[:space:]]\($libc|inlined\)$" expected[9]="main[[:space:]]\(.*/bin/ping.*\)$" expected[10]="__libc_start_main[[:space:]]\($libc\)$" expected[11]="_start[[:space:]]\(.*/bin/ping.*\)$"
Greg Kroah-Hartman
maintainerPATCH 252/272 perf tests: Use arch__compare_symbol_names to compare symbols
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
[ Upstream commit ab6e9a99345131cd8e54268d1d0dc04a33f7ed11 ]
The symbol search called by machine__find_kernel_symbol_by_name is using internally arch__compare_symbol_names function to compare 2 symbol names, because different archs have different ways of comparing symbols. Mostly for skipping '.' prefixes and similar.
In test 1 when we try to find matching symbols in kallsyms and vmlinux, by address and by symbol name. When either is found we compare the pair symbol names by simple strcmp, which is not good enough for reasons explained in previous paragraph.
On powerpc this can cause lockup, because even thought we found the pair, the compared names are different and don't match simple strcmp. Following code path is executed, that leads to lockup:
- we find the pair in kallsyms by sym->startnext_pair:
- we compare the names and it fails
- we find the pair by sym->name
- the pair addresses match so we call goto next_pair because we assume the names match in this case
--- tools/perf/tests/vmlinux-kallsyms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/tests/vmlinux-kallsyms.c +1 -1
@@ -125,7 +125,7 @@ int test__vmlinux_matches_kallsyms(strucif (pair &&UM (pair->start) == mem_start) { next_pair: -if (strcmp (sym->name, pair->name) ==0 ) { +if (arch__compare_symbol_names (sym->name, pair->name) ==0 ) {/* * kallsyms don't have the symbol end, so we * set that by using the next symbol start - 1,
Greg Kroah-Hartman
maintainerPATCH 253/272 perf report: Fix memory corruption in --branch-history mode --branch-history
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
[ Upstream commit e3ebaa465136ecfedf9c6f4671df02bf625f8125 ]
Jin Yao reported memory corrupton in perf report with branch info used for stack trace:
Quoted 15 lines
Following command lines will cause perf crash.
perf record -j call -g -a <application>
perf report --branch-history*** Error in `perf': double free or corruption (!prev):
0x00000000104aa040*** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f6b37254725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f6b3725cf4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6b37260abc] perf[0x51b914]
perf(hist_entry_iter__add+0x1e5)[0x51f305]
perf[0x43cf01]
perf[0x4fa3bf]
perf[0x4fa923]
Quoted 8 lines
perf[0x4fd396]
perf[0x4f9614] perf(perf_session__process_events+0x89e)[0x4fc38e] perf(cmd_report+0x15d2)[0x43f202]
perf[0x4a059f]
perf(main+0x631)[0x427b71] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6b371fd830] perf(_start+0x29)[0x427d89]
For the cumulative output, we allocate the he_cache array based on the --max-stack option value and populate it with data from 'callchain_cursor'.
The --max-stack option value does not ensure now the limit for number of callchain_cursor nodes, so the cumulative iter code will allocate smaller array than it's actually needed and cause above corruption.
I think the --max-stack limit does not apply here anyway, because we add callchain data as normal hist entries, while the --max-stack control the limit of single entry callchain depth.
Using the callchain_cursor.nr as he_cache array count to fix this. Also removing struct hist_entry_iter::max_stack, because there's no longer any use for it.
We need more fixes to ensure that the branch stack code follows properly the logic of --max-stack, which is not the case at the moment.
--- tools/perf/util/hist.c | 4 +--- tools/perf/util/hist.h | 1 - 2 files changed, 1 insertion(+), 4 deletions(-)
tools/perf/util/hist.c +1 -3
@@ -879,7 +879,7 @@ iter_prepare_cumulative_entry(struct his* cumulated only one time to prevent entries more than 100% * overhead. */ - he_cache =malloc (sizeof (*he_cache) * (iter->max_stack +1 )); + he_cache =malloc (sizeof (*he_cache) * (callchain_cursor.nr +1 ));if (he_cache ==NULL )return -ENOMEM ;
@@ -1045,8 +1045,6 @@ int hist_entry_iter__add(struct hist_entif (err)return err; - iter->max_stack = max_stack_depth; - err = iter->ops->prepare_entry (iter, al);if (err) goto out;
tools/perf/util/hist.h +0 -1
@@ -107,7 +107,6 @@ struct hist_entry_iter {int curr;bool hide_unresolved; -int max_stack;struct perf_evsel *evsel;struct perf_sample *sample;
Greg Kroah-Hartman
maintainerPATCH 254/272 perf tests: Fix dwarf unwind for stripped binaries
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
[ Upstream commit fdf7c49c200d1b9909e2204cec5bd68b48605c71 ]
When we strip the perf binary, dwarf unwind test stop to work. The reason is that strip will remove static function symbols, which we need to check for unwind.
This change will keep this test working in cases where the global symbols are put into dynamic symbol table, which is the case on x86. It still won't work on powerpc.
Making those 5 local functions global, and adding 'test_dwarf_unwind__' to their names.
Committer testing:
Before:
# perf test dwarf 58: DWARF unwind : Ok # strip ~/bin/perf # perf test dwarf 58: DWARF unwind : FAILED! # perf test -v dwarf 58: DWARF unwind : --- start --- test child forked, pid 6590 unwind: thread map already set, dso=/home/acme/bin/perf <SNIP> unwind: access_mem addr 0x7ffce6c48098 val 48563f, offset 1144 unwind: test__dwarf_unwind:ip = 0x4a54e5 (0xa54e5) got: test__dwarf_unwind 0xa54e5, expecting test__dwarf_unwind unwind: '':ip = 0x4a50bb (0xa50bb) failed: got unresolved address 0xa50bb unwind failed test child finished with -1 ---- end ---- DWARF unwind: FAILED! #
After:
# perf test dwarf 58: DWARF unwind : Ok # strip ~/bin/perf # perf test dwarf 58: DWARF unwind : Ok # # perf test -v dwarf 58: DWARF unwind : --- start --- test child forked, pid 7219 unwind: thread map already set, dso=/home/acme/bin/perf <SNIP> unwind: access_mem addr 0x7fff007da2c8 val 48575f, offset 1144 unwind: test__arch_unwind_sample:ip = 0x589044 (0x189044) got: test__arch_unwind_sample 0x189044, expecting test__arch_unwind_sample unwind: test_dwarf_unwind__thread:ip = 0x4a52f7 (0xa52f7) got: test_dwarf_unwind__thread 0xa52f7, expecting test_dwarf_unwind__thread unwind: test_dwarf_unwind__compare:ip = 0x4a5468 (0xa5468) got: test_dwarf_unwind__compare 0xa5468, expecting test_dwarf_unwind__compare unwind: bsearch:ip = 0x7f6608ae94d8 (0x394d8) got: bsearch 0x394d8, expecting bsearch unwind: test_dwarf_unwind__krava_3:ip = 0x4a54d1 (0xa54d1) got: test_dwarf_unwind__krava_3 0xa54d1, expecting test_dwarf_unwind__krava_3 unwind: test_dwarf_unwind__krava_2:ip = 0x4a550b (0xa550b) got: test_dwarf_unwind__krava_2 0xa550b, expecting test_dwarf_unwind__krava_2 unwind: test_dwarf_unwind__krava_1:ip = 0x4a554b (0xa554b) got: test_dwarf_unwind__krava_1 0xa554b, expecting test_dwarf_unwind__krava_1 unwind: test__dwarf_unwind:ip = 0x4a5605 (0xa5605) got: test__dwarf_unwind 0xa5605, expecting test__dwarf_unwind test child finished with 0 ---- end ---- DWARF unwind: Ok #
--- tools/perf/tests/dwarf-unwind.c | 46 ++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 16 deletions(-)
tools/perf/tests/dwarf-unwind.c +30 -16
@@ -37,6 +37,19 @@ static int init_live_machine(struct mach mmap_handler, machine, true, 500); } +/* +* We need to keep these functions global, despite the +* fact that they are used only locally in this object, +* in order to keep them around even if the binary is +* stripped. If they are gone, the unwind check for +* symbol fails. +*/ +int test_dwarf_unwind__thread (struct thread *thread); +int test_dwarf_unwind__compare (void *p1,void *p2); +int test_dwarf_unwind__krava_3 (struct thread *thread); +int test_dwarf_unwind__krava_2 (struct thread *thread); +int test_dwarf_unwind__krava_1 (struct thread *thread); +#define MAX_STACK 8static int unwind_entry (struct unwind_entry *entry,void *arg)
@@ -45,12 +58,12 @@ static int unwind_entry(struct unwind_enchar *symbol = entry->sym ? entry->sym->name :NULL ;static const char *funcs[MAX_STACK ] = {"test__arch_unwind_sample" , -"unwind_thread" , -"compare" , +"test_dwarf_unwind__thread" , +"test_dwarf_unwind__compare" ,"bsearch" , -"krava_3" , -"krava_2" , -"krava_1" , +"test_dwarf_unwind__krava_3" , +"test_dwarf_unwind__krava_2" , +"test_dwarf_unwind__krava_1" ,"test__dwarf_unwind" };/*
@@ -77,7 +90,7 @@ static int unwind_entry(struct unwind_enreturn strcmp ((const char *) symbol, funcs[idx]); } -static noinline int unwind_thread(struct thread *thread) +noinline int test_dwarf_unwind__thread(struct thread *thread) {struct perf_sample sample;unsigned long cnt =0 ;
@@ -108,7 +121,7 @@ static noinline int unwind_thread(structstatic int global_unwind_retval = -INT_MAX ; -static noinline int compare(void *p1, void *p2) +noinline int test_dwarf_unwind__compare(void *p1, void *p2) {/* Any possible value should be 'thread' */ struct thread *thread = *(struct thread **)p1;
@@ -117,17 +130,17 @@ static noinline int compare(void *p1, vo/* Call unwinder twice for both callchain orders. */ callchain_param.order =ORDER_CALLER ; - global_unwind_retval =unwind_thread (thread); + global_unwind_retval =test_dwarf_unwind__thread (thread);if (!global_unwind_retval) { callchain_param.order =ORDER_CALLEE ; - global_unwind_retval =unwind_thread (thread); + global_unwind_retval =test_dwarf_unwind__thread (thread); } }return p1 - p2; } -static noinline int krava_3(struct thread *thread) +noinline int test_dwarf_unwind__krava_3(struct thread *thread) {struct thread *array[2 ] = {thread, thread};void *fp = &bsearch;
@@ -141,18 +154,19 @@ static noinline int krava_3(struct threa size_t, int (*)(void *, void *)); _bsearch = fp; -_bsearch (array, &thread,2 ,sizeof (struct thread **), compare); +_bsearch (array, &thread,2 ,sizeof (struct thread **), + test_dwarf_unwind__compare);return global_unwind_retval; } -static noinline int krava_2(struct thread *thread) +noinline int test_dwarf_unwind__krava_2(struct thread *thread) { -return krava_3 (thread); +return test_dwarf_unwind__krava_3 (thread); } -static noinline int krava_1(struct thread *thread) +noinline int test_dwarf_unwind__krava_1(struct thread *thread) { -return krava_2 (thread); +return test_dwarf_unwind__krava_2 (thread); }int test__dwarf_unwind (struct test *test__maybe_unused ,int subtest__maybe_unused )
@@ -189,7 +203,7 @@ int test__dwarf_unwind(struct test *test goto out; } - err =krava_1 (thread); + err =test_dwarf_unwind__krava_1 (thread);thread__put (thread); out:
Greg Kroah-Hartman
maintainerPATCH 255/272 selftests/net: fixes psock_fanout eBPF test case
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prashant Bhole <[email protected]>
[ Upstream commit ddd0010392d9cbcb95b53d11b7cafc67b373ab56 ]
eBPF test fails due to verifier failure because log_buf is too small. Fixed by increasing log_buf size
--- tools/testing/selftests/net/psock_fanout.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
tools/testing/selftests/net/psock_fanout.c +2 -1
@@ -128,6 +128,8 @@ static void sock_fanout_getopts(int fd,static void sock_fanout_set_ebpf (int fd) { +static char log_buf[65536 ]; + const int len_off = __builtin_offsetof(struct __sk_buff, len);struct bpf_insn prog[] = { {BPF_ALU64 |BPF_MOV |BPF_X ,6 ,1 ,0 ,0 },
@@ -140,7 +142,6 @@ static void sock_fanout_set_ebpf(int fd) { BPF_ALU | BPF_MOV | BPF_K, 0, 0, 0, 0 }, { BPF_JMP | BPF_EXIT, 0, 0, 0, 0 } }; -char log_buf[512 ];union bpf_attr attr;int pfd;
Greg Kroah-Hartman
maintainerPATCH 257/272 netlabel: If PF_INET6, check sk_buff ip header version
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Haines <[email protected]>
[ Upstream commit 213d7f94775322ba44e0bbb55ec6946e9de88cea ]
When resolving a fallback label, check the sk_buff version as it is possible (e.g. SCTP) to have family = PF_INET6 while receiving ip_hdr(skb)->version = 4.
--- net/netlabel/netlabel_unlabeled.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
net/netlabel/netlabel_unlabeled.c +10 -0
@@ -1472,6 +1472,16 @@ int netlbl_unlabel_getattr(const struct iface =rcu_dereference (netlbl_unlhsh_def);if (iface ==NULL || !iface->valid) goto unlabel_getattr_nolabel; + +#if IS_ENABLED (CONFIG_IPV6 ) +/* When resolving a fallback label, check the sk_buff version as +* it is possible (e.g. SCTP) to have family = PF_INET6 while +* receiving ip_hdr(skb)->version = 4. +*/ +if (family ==PF_INET6 &&ip_hdr (skb)->version ==4 ) + family =PF_INET ; +#endif /* IPv6 */ +switch (family) {case PF_INET : {struct iphdr *hdr4;
Greg Kroah-Hartman
maintainerPATCH 258/272 drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
[ Upstream commit 796ceb9269626afaed3b4955c40d2c3d7a8c5d01 ]
According to the latest revisions of the R-Car Gen3 manual, the LVDS mode must be set before the LVDS I/O pins are enabled, not after -- fix the Gen3 LVDS startup sequence accordingly.
--- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c +5 -2
@@ -95,7 +95,7 @@ static void rcar_du_lvdsenc_start_gen3(su32 lvdcr0;u32 pllcr; -/* PLL clock configuration */ +/* Set the PLL clock configuration and LVDS mode. */ if (freq <42000 ) pllcr =LVDPLLCR_PLLDIVCNT_42M ;else if (freq <85000 )
@@ -107,6 +107,9 @@ static void rcar_du_lvdsenc_start_gen3(srcar_lvds_write (lvds,LVDPLLCR , pllcr); + lvdcr0 = lvds->mode <<LVDCR0_LVMD_SHIFT ; +rcar_lvds_write (lvds,LVDCR0 , lvdcr0); +/* Turn all the channels on. */ rcar_lvds_write(lvds, LVDCR1, LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
@@ -117,7 +120,7 @@ static void rcar_du_lvdsenc_start_gen3(s* Turn the PLL on, set it to LVDS normal mode, wait for the startup * delay and turn the output on. */ - lvdcr0 = (lvds->mode <<LVDCR0_LVMD_SHIFT ) |LVDCR0_PLLON ; + lvdcr0 |=LVDCR0_PLLON ;rcar_lvds_write (lvds,LVDCR0 , lvdcr0); lvdcr0 |=LVDCR0_PWD ;
Greg Kroah-Hartman
maintainerPATCH 259/272 drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
[ Upstream commit 8525d04ba8a6a9ecfa4bd619c988ca873a5fc2a4 ]
According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS and the bias circuit must be enabled after the LVDS I/O pins are enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.
While at it, also fix the comment preceding the first LVDCR0 write that still talks about hardcoding the LVDS mode 0.
--- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c +6 -5
@@ -59,11 +59,8 @@ static void rcar_du_lvdsenc_start_gen2(srcar_lvds_write (lvds,LVDPLLCR , pllcr); -/* -* Select the input, hardcode mode 0, enable LVDS operation and turn -* bias circuitry on. -*/ - lvdcr0 = (lvds->mode <<LVDCR0_LVMD_SHIFT ) |LVDCR0_BEN |LVDCR0_LVEN ; +/* Select the input and set the LVDS mode. */ + lvdcr0 = lvds->mode <<LVDCR0_LVMD_SHIFT ;if (rcrtc->index ==2 ) lvdcr0 |=LVDCR0_DUSEL ;rcar_lvds_write (lvds,LVDCR0 , lvdcr0);
@@ -74,6 +71,10 @@ static void rcar_du_lvdsenc_start_gen2(sLVDCR1_CHSTBY_GEN2 (1 ) |LVDCR1_CHSTBY_GEN2 (0 ) | LVDCR1_CLKSTBY_GEN2); +/* Enable LVDS operation and turn bias circuitry on. */ + lvdcr0 |=LVDCR0_BEN |LVDCR0_LVEN ; +rcar_lvds_write (lvds,LVDCR0 , lvdcr0); +/* * Turn the PLL on, wait for the startup delay, and turn the output * on.
Greg Kroah-Hartman
maintainerPATCH 260/272 selftests: Add FIB onlink tests
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ahern <[email protected]>
[ Upstream commit 153e1b84f477f716bc3f81e6cfae1a3d941fc7ec ]
Add test cases verifying FIB onlink commands work as expected in various conditions - IPv4, IPv6, main table, and VRF.
--- tools/testing/selftests/net/fib-onlink-tests.sh | 375 ++++++++++++++++++++++++ 1 file changed, 375 insertions(+) create mode 100644 tools/testing/selftests/net/fib-onlink-tests.sh
tools/testing/selftests/net/fib-onlink-tests.sh new file +375 -0
@@ -0,0 +1,375 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0 + +# IPv4 and IPv6 onlink tests + +PAUSE_ON_FAIL=${PAUSE_ON_FAIL:=no} + +# Network interfaces +# - odd in current namespace; even in peer ns +declare -A NETIFS +# default VRF +NETIFS[p1]=veth1 +NETIFS[p2]=veth2 +NETIFS[p3]=veth3 +NETIFS[p4]=veth4 +# VRF +NETIFS[p5]=veth5 +NETIFS[p6]=veth6 +NETIFS[p7]=veth7 +NETIFS[p8]=veth8 + +# /24 network +declare -A V4ADDRS +V4ADDRS[p1]=169.254.1.1 +V4ADDRS[p2]=169.254.1.2 +V4ADDRS[p3]=169.254.3.1 +V4ADDRS[p4]=169.254.3.2 +V4ADDRS[p5]=169.254.5.1 +V4ADDRS[p6]=169.254.5.2 +V4ADDRS[p7]=169.254.7.1 +V4ADDRS[p8]=169.254.7.2 + +# /64 network +declare -A V6ADDRS +V6ADDRS[p1]=2001:db8:101::1 +V6ADDRS[p2]=2001:db8:101::2 +V6ADDRS[p3]=2001:db8:301::1 +V6ADDRS[p4]=2001:db8:301::2 +V6ADDRS[p5]=2001:db8:501::1 +V6ADDRS[p6]=2001:db8:501::2 +V6ADDRS[p7]=2001:db8:701::1 +V6ADDRS[p8]=2001:db8:701::2 + +# Test networks: +# [1] = default table +# [2] = VRF +# +# /32 host routes +declare -A TEST_NET4 +TEST_NET4[1]=169.254.101 +TEST_NET4[2]=169.254.102 +# /128 host routes +declare -A TEST_NET6 +TEST_NET6[1]=2001:db8:101 +TEST_NET6[2]=2001:db8:102 + +# connected gateway +CONGW[1]=169.254.1.254 +CONGW[2]=169.254.5.254 + +# recursive gateway +RECGW4[1]=169.254.11.254 +RECGW4[2]=169.254.12.254 +RECGW6[1]=2001:db8:11::64 +RECGW6[2]=2001:db8:12::64 + +# for v4 mapped to v6 +declare -A TEST_NET4IN6IN6 +TEST_NET4IN6[1]=10.1.1.254 +TEST_NET4IN6[2]=10.2.1.254 + +# mcast address +MCAST6=ff02::1 + + +PEER_NS=bart +PEER_CMD="ip netns exec ${PEER_NS}" +VRF=lisa +VRF_TABLE=1101 +PBR_TABLE=101 + +################################################################################ +# utilities + +log_test() +{ + local rc=$1 + local expected=$2 + local msg="$3" + + if [ ${rc} -eq ${expected} ]; then + nsuccess=$((nsuccess+1)) + printf "\n TEST: %-50s [ OK ]\n" "${msg}" + else + nfail=$((nfail+1)) + printf "\n TEST: %-50s [FAIL]\n" "${msg}" + if [ "${PAUSE_ON_FAIL}" = "yes" ]; then + echo + echo "hit enter to continue, 'q' to quit" + read a + [ "$a" = "q" ] && exit 1 + fi + fi +} + +log_section() +{ + echo + echo "######################################################################" + echo "TEST SECTION: $*" + echo "######################################################################" +} + +log_subsection() +{ + echo + echo "#########################################" + echo "TEST SUBSECTION: $*" +} + +run_cmd() +{ + echo + echo "COMMAND: $*" + eval $* +} + +get_linklocal() +{ + local dev=$1 + local pfx + local addr + + addr=$(${pfx} ip -6 -br addr show dev ${dev} | \ + awk '{ + for (i = 3; i <= NF; ++i) { + if ($i ~ /^fe80/) + print $i + } + }' + ) + addr=${addr/\/*} + + [ -z "$addr" ] && return 1 + + echo $addr + + return 0 +} + +################################################################################ +# + +setup() +{ + echo + echo "########################################" + echo "Configuring interfaces" + + set -e + + # create namespace + ip netns add ${PEER_NS} + ip -netns ${PEER_NS} li set lo up + + # add vrf table + ip li add ${VRF} type vrf table ${VRF_TABLE} + ip li set ${VRF} up + ip ro add table ${VRF_TABLE} unreachable default + ip -6 ro add table ${VRF_TABLE} unreachable default + + # create test interfaces + ip li add ${NETIFS[p1]} type veth peer name ${NETIFS[p2]} + ip li add ${NETIFS[p3]} type veth peer name ${NETIFS[p4]} + ip li add ${NETIFS[p5]} type veth peer name ${NETIFS[p6]} + ip li add ${NETIFS[p7]} type veth peer name ${NETIFS[p8]} + + # enslave vrf interfaces + for n in 5 7; do + ip li set ${NETIFS[p${n}]} vrf ${VRF} + done + + # add addresses + for n in 1 3 5 7; do + ip li set ${NETIFS[p${n}]} up + ip addr add ${V4ADDRS[p${n}]}/24 dev ${NETIFS[p${n}]} + ip addr add ${V6ADDRS[p${n}]}/64 dev ${NETIFS[p${n}]} + done + + # move peer interfaces to namespace and add addresses + for n in 2 4 6 8; do + ip li set ${NETIFS[p${n}]} netns ${PEER_NS} up + ip -netns ${PEER_NS} addr add ${V4ADDRS[p${n}]}/24 dev ${NETIFS[p${n}]} + ip -netns ${PEER_NS} addr add ${V6ADDRS[p${n}]}/64 dev ${NETIFS[p${n}]} + done + + set +e + + # let DAD complete - assume default of 1 probe + sleep 1 +} + +cleanup() +{ + # make sure we start from a clean slate + ip netns del ${PEER_NS} 2>/dev/null + for n in 1 3 5 7; do + ip link del ${NETIFS[p${n}]} 2>/dev/null + done + ip link del ${VRF} 2>/dev/null + ip ro flush table ${VRF_TABLE} + ip -6 ro flush table ${VRF_TABLE} +} + +################################################################################ +# IPv4 tests +# + +run_ip() +{ + local table="$1" + local prefix="$2" + local gw="$3" + local dev="$4" + local exp_rc="$5" + local desc="$6" + + # dev arg may be empty + [ -n "${dev}" ] && dev="dev ${dev}" + + run_cmd ip ro add table "${table}" "${prefix}"/32 via "${gw}" "${dev}" onlink + log_test $? ${exp_rc} "${desc}" +} + +valid_onlink_ipv4() +{ + # - unicast connected, unicast recursive + # + log_subsection "default VRF - main table" + + run_ip 254 ${TEST_NET4[1]}.1 ${CONGW[1]} ${NETIFS[p1]} 0 "unicast connected" + run_ip 254 ${TEST_NET4[1]}.2 ${RECGW4[1]} ${NETIFS[p1]} 0 "unicast recursive" + + log_subsection "VRF ${VRF}" + + run_ip ${VRF_TABLE} ${TEST_NET4[2]}.1 ${CONGW[2]} ${NETIFS[p5]} 0 "unicast connected" + run_ip ${VRF_TABLE} ${TEST_NET4[2]}.2 ${RECGW4[2]} ${NETIFS[p5]} 0 "unicast recursive" + + log_subsection "VRF device, PBR table" + + run_ip ${PBR_TABLE} ${TEST_NET4[2]}.3 ${CONGW[2]} ${NETIFS[p5]} 0 "unicast connected" + run_ip ${PBR_TABLE} ${TEST_NET4[2]}.4 ${RECGW4[2]} ${NETIFS[p5]} 0 "unicast recursive" +} + +invalid_onlink_ipv4() +{ + run_ip 254 ${TEST_NET4[1]}.11 ${V4ADDRS[p1]} ${NETIFS[p1]} 2 \ + "Invalid gw - local unicast address" + + run_ip ${VRF_TABLE} ${TEST_NET4[2]}.11 ${V4ADDRS[p5]} ${NETIFS[p5]} 2 \ + "Invalid gw - local unicast address, VRF" + + run_ip 254 ${TEST_NET4[1]}.101 ${V4ADDRS[p1]} "" 2 "No nexthop device given" + + run_ip 254 ${TEST_NET4[1]}.102 ${V4ADDRS[p3]} ${NETIFS[p1]} 2 \ + "Gateway resolves to wrong nexthop device" + + run_ip ${VRF_TABLE} ${TEST_NET4[2]}.103 ${V4ADDRS[p7]} ${NETIFS[p5]} 2 \ + "Gateway resolves to wrong nexthop device - VRF" +} + +################################################################################ +# IPv6 tests +# + +run_ip6() +{ + local table="$1" + local prefix="$2" + local gw="$3" + local dev="$4" + local exp_rc="$5" + local desc="$6" + + # dev arg may be empty + [ -n "${dev}" ] && dev="dev ${dev}" + + run_cmd ip -6 ro add table "${table}" "${prefix}"/128 via "${gw}" "${dev}" onlink + log_test $? ${exp_rc} "${desc}" +} + +valid_onlink_ipv6() +{ + # - unicast connected, unicast recursive, v4-mapped + # + log_subsection "default VRF - main table" + + run_ip6 254 ${TEST_NET6[1]}::1 ${V6ADDRS[p1]/::*}::64 ${NETIFS[p1]} 0 "unicast connected" + run_ip6 254 ${TEST_NET6[1]}::2 ${RECGW6[1]} ${NETIFS[p1]} 0 "unicast recursive" + run_ip6 254 ${TEST_NET6[1]}::3 ::ffff:${TEST_NET4IN6[1]} ${NETIFS[p1]} 0 "v4-mapped" + + log_subsection "VRF ${VRF}" + + run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::1 ${V6ADDRS[p5]/::*}::64 ${NETIFS[p5]} 0 "unicast connected" + run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::2 ${RECGW6[2]} ${NETIFS[p5]} 0 "unicast recursive" + run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::3 ::ffff:${TEST_NET4IN6[2]} ${NETIFS[p5]} 0 "v4-mapped" + + log_subsection "VRF device, PBR table" + + run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::4 ${V6ADDRS[p5]/::*}::64 ${NETIFS[p5]} 0 "unicast connected" + run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::5 ${RECGW6[2]} ${NETIFS[p5]} 0 "unicast recursive" + run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::6 ::ffff:${TEST_NET4IN6[2]} ${NETIFS[p5]} 0 "v4-mapped" +} + +invalid_onlink_ipv6() +{ + local lladdr + + lladdr=$(get_linklocal ${NETIFS[p1]}) || return 1 + + run_ip6 254 ${TEST_NET6[1]}::11 ${V6ADDRS[p1]} ${NETIFS[p1]} 2 \ + "Invalid gw - local unicast address" + run_ip6 254 ${TEST_NET6[1]}::12 ${lladdr} ${NETIFS[p1]} 2 \ + "Invalid gw - local linklocal address" + run_ip6 254 ${TEST_NET6[1]}::12 ${MCAST6} ${NETIFS[p1]} 2 \ + "Invalid gw - multicast address" + + lladdr=$(get_linklocal ${NETIFS[p5]}) || return 1 + run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::11 ${V6ADDRS[p5]} ${NETIFS[p5]} 2 \ + "Invalid gw - local unicast address, VRF" + run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::12 ${lladdr} ${NETIFS[p5]} 2 \ + "Invalid gw - local linklocal address, VRF" + run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::12 ${MCAST6} ${NETIFS[p5]} 2 \ + "Invalid gw - multicast address, VRF" + + run_ip6 254 ${TEST_NET6[1]}::101 ${V6ADDRS[p1]} "" 2 \ + "No nexthop device given" + + # default VRF validation is done against LOCAL table + # run_ip6 254 ${TEST_NET6[1]}::102 ${V6ADDRS[p3]/::[0-9]/::64} ${NETIFS[p1]} 2 \ + # "Gateway resolves to wrong nexthop device" + + run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::103 ${V6ADDRS[p7]/::[0-9]/::64} ${NETIFS[p5]} 2 \ + "Gateway resolves to wrong nexthop device - VRF" +} + +run_onlink_tests() +{ + log_section "IPv4 onlink" + log_subsection "Valid onlink commands" + valid_onlink_ipv4 + log_subsection "Invalid onlink commands" + invalid_onlink_ipv4 + + log_section "IPv6 onlink" + log_subsection "Valid onlink commands" + valid_onlink_ipv6 + invalid_onlink_ipv6 +} + +################################################################################ +# main + +nsuccess=0 +nfail=0 + +cleanup +setup +run_onlink_tests +cleanup + +if [ "$TESTS" != "none" ]; then + printf "\nTests passed: %3d\n" ${nsuccess} + printf "Tests failed: %3d\n" ${nfail} +fi
Greg Kroah-Hartman
maintainerPATCH 261/272 ARM: dts: at91: nattis: use the correct compatible for the eeprom
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Rosin <[email protected]>
[ Upstream commit 6b65933008a6bbe5ff79a344b41175826848682d ]
The used part does contain an eeprom compatible with an Atmel 24c02 chip and it is from NXP, but it is not called 24c02. It's actually a se97b chip. Adjust the compatible accordingly.
--- arch/arm/boot/dts/at91-nattis-2-natte-2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/at91-nattis-2-natte-2.dts +1 -1
@@ -146,7 +146,7 @@ }; eeprom@50 { - compatible = "nxp,24c02"; + compatible = "nxp,se97b", "atmel,24c02"; reg = <0x50>; pagesize = <16>; };
Greg Kroah-Hartman
maintainerPATCH 262/272 ARM: dts: at91: tse850: use the correct compatible for the eeprom
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Rosin <[email protected]>
[ Upstream commit 7981190fb5dd710dea08c2613cee3d05e795ca5e ]
The used part does contain an eeprom compatible with an Atmel 24c02 chip and it is from NXP, but it is not called 24c02. It's actually a se97b chip. Adjust the compatible accordingly.
--- arch/arm/boot/dts/at91-tse850-3.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/at91-tse850-3.dts +1 -1
@@ -246,7 +246,7 @@ }; eeprom@50 { - compatible = "nxp,24c02", "atmel,24c02"; + compatible = "nxp,se97b", "atmel,24c02"; reg = <0x50>; pagesize = <16>; };
Greg Kroah-Hartman
maintainerPATCH 263/272 regmap: Correct comparison in regmap_cached
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charles Keepax <[email protected]>
[ Upstream commit 71df179363a5a733a8932e9afb869760d7559383 ]
The cache pointer points to the actual memory used by the cache, as the comparison here is looking for the type of the cache it should check against cache_type.
--- drivers/base/regmap/regmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/regmap/regmap.c +1 -1
@@ -99,7 +99,7 @@ bool regmap_cached(struct regmap *map, uint ret;unsigned int val; -if (map->cache ==REGCACHE_NONE ) +if (map->cache_type ==REGCACHE_NONE )return false;if (!map->cache_ops)
Greg Kroah-Hartman
maintainerPATCH 264/272 soc: amlogic: meson-gx-pwrc-vpu: fix error on shutdown when domain is powered off
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
[ Upstream commit 87f88732d25e6175cb4faa8070658f604660d720 ]
When operating the system headless headless, the domain is never powered on, leaving the clocks disabled. The shutdown function then tries to disable the already disabled clocks, resulting in errors. Therefore call meson_gx_pwrc_vpu_power_off() only if domain is powered on.
This patch fixes the described issue on my system (Odorid-C2).
--- drivers/soc/amlogic/meson-gx-pwrc-vpu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/soc/amlogic/meson-gx-pwrc-vpu.c +5 -1
@@ -224,7 +224,11 @@ static int meson_gx_pwrc_vpu_probe(strucstatic void meson_gx_pwrc_vpu_shutdown (struct platform_device *pdev) { -meson_gx_pwrc_vpu_power_off (&vpu_hdmi_pd.genpd); +bool powered_off; + + powered_off =meson_gx_pwrc_vpu_get_power (&vpu_hdmi_pd); +if (!powered_off) +meson_gx_pwrc_vpu_power_off (&vpu_hdmi_pd.genpd); }static const struct of_device_id meson_gx_pwrc_vpu_match_table[] = {
Greg Kroah-Hartman
maintainerPATCH 265/272 i40e: Add delay after EMP reset for firmware to recover
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filip Sadowski <[email protected]>
[ Upstream commit 1fa51a650e1deb50410677f1bd6c0ce17aa48a49 ]
This patch adds necessary delay for 4.33 firmware to recover after EMP reset. Without this patch driver occasionally reinitializes structures too quickly to communicate with firmware after EMP reset causing AdminQ to timeout.
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/net/ethernet/intel/i40e/i40e_main.c +11 -0
@@ -9215,6 +9215,17 @@ static void i40e_rebuild(struct i40e_pf }i40e_get_oem_version (&pf->hw); +if (test_bit (__I40E_EMP_RESET_INTR_RECEIVED, pf->state) && + ((hw->aq.fw_maj_ver ==4 && hw->aq.fw_min_ver <=33 ) || + hw->aq.fw_maj_ver <4 ) && hw->mac.type ==I40E_MAC_XL710 ) { +/* The following delay is necessary for 4.33 firmware and older +* to recover after EMP reset. 200 ms should suffice but we +* put here 300 ms to be sure that FW is ready to operate +* after reset. +*/ +mdelay (300 ); + } +/* re-verify the eeprom if we just had an EMP reset */ if (test_and_clear_bit (__I40E_EMP_RESET_INTR_RECEIVED, pf->state))i40e_verify_eeprom (pf);
Greg Kroah-Hartman
maintainerPATCH 266/272 ARM: dts: imx7d: cl-som-imx7: fix pinctrl_enet
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aapo Vienamo <[email protected]>
[ Upstream commit 2bada7ac1fdcbf79a9689bd2ff65fa515ca7a31f ]
The missing last digit of the CONFIG values is added. Looks like a typo of some sort when comparing to the downstream dt. This fixes intermittent behavior behaviour of the ethernet controllers.
--- arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 52 ++++++++++++++++---------------- 1 file changed, 26 insertions(+), 26 deletions(-)
arch/arm/boot/dts/imx7d-cl-som-imx7.dts +26 -26
@@ -213,37 +213,37 @@ &iomuxc { pinctrl_enet1: enet1grp { fsl,pins = < - MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x3 - MX7D_PAD_SD2_WP__ENET1_MDC 0x3 - MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x1 - MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x1 - MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x1 - MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2 0x1 - MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3 0x1 - MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x1 - MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x1 - MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x1 - MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x1 - MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 0x1 - MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 0x1 - MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1 + MX7D_PAD_SD2_CD_B__ENET1_MDIO 0x30 + MX7D_PAD_SD2_WP__ENET1_MDC 0x30 + MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC 0x11 + MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x11 + MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x11 + MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2 0x11 + MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3 0x11 + MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x11 + MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x11 + MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x11 + MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x11 + MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2 0x11 + MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3 0x11 + MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x11 >; }; pinctrl_enet2: enet2grp { fsl,pins = < - MX7D_PAD_EPDC_GDSP__ENET2_RGMII_TXC 0x1 - MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0 0x1 - MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1 0x1 - MX7D_PAD_EPDC_GDCLK__ENET2_RGMII_TD2 0x1 - MX7D_PAD_EPDC_GDOE__ENET2_RGMII_TD3 0x1 - MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL 0x1 - MX7D_PAD_EPDC_SDCE1__ENET2_RGMII_RXC 0x1 - MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0 0x1 - MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1 0x1 - MX7D_PAD_EPDC_SDOE__ENET2_RGMII_RD2 0x1 - MX7D_PAD_EPDC_SDSHR__ENET2_RGMII_RD3 0x1 - MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL 0x1 + MX7D_PAD_EPDC_GDSP__ENET2_RGMII_TXC 0x11 + MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0 0x11 + MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1 0x11 + MX7D_PAD_EPDC_GDCLK__ENET2_RGMII_TD2 0x11 + MX7D_PAD_EPDC_GDOE__ENET2_RGMII_TD3 0x11 + MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL 0x11 + MX7D_PAD_EPDC_SDCE1__ENET2_RGMII_RXC 0x11 + MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0 0x11 + MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1 0x11 + MX7D_PAD_EPDC_SDOE__ENET2_RGMII_RD2 0x11 + MX7D_PAD_EPDC_SDSHR__ENET2_RGMII_RD3 0x11 + MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL 0x11 >; };
Greg Kroah-Hartman
maintainerPATCH 267/272 ARM: dts: porter: Fix HDMI output routing
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <[email protected]>
[ Upstream commit d4b78db6ac3e084e2bdc57d5518bd247c727f396 ]
The HDMI encoder is connected to the RGB output of the DU, which is port@0, not port@1. Fix the incorrect DT description.
--- arch/arm/boot/dts/r8a7791-porter.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/r8a7791-porter.dts +1 -1
@@ -425,7 +425,7 @@ "dclkin.0", "dclkin.1"; ports { - port@1 { + port@0 { endpoint { remote-endpoint = <&adv7511_in>; };
Greg Kroah-Hartman
maintainerPATCH 268/272 regulator: of: Add a missing of_node_put() in an error handling path of of_regulator_match()
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 30966861a7a2051457be8c49466887d78cc47e97 ]
If an unlikely failure in 'of_get_regulator_init_data()' occurs, we must release the reference on the current 'child' node before returning.
--- drivers/regulator/of_regulator.c | 1 + 1 file changed, 1 insertion(+)
drivers/regulator/of_regulator.c +1 -0
@@ -321,6 +321,7 @@ int of_regulator_match(struct device *dedev_err (dev,"failed to parse DT for regulator %s\n" , child->name); +of_node_put (child);return -EINVAL ; } match->of_node =of_node_get (child);
Greg Kroah-Hartman
maintainerPATCH 269/272 pinctrl: msm: Use dynamic GPIO numbering
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]
The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices.
--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/qcom/pinctrl-msm.c +1 -1
@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pincreturn -EINVAL ; chip = &pctrl->chip; - chip->base =0 ; + chip->base =-1 ; chip->ngpio = ngpio; chip->label =dev_name (pctrl->dev); chip->parent = pctrl->dev;
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:
Quoted 25 lines
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit
a7aa75a2a7dba32594291a71c3704000a2fd7089]The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices.
Fixes f365be092572 ("pinctrl: Add Qualcomm TLMM driver")Reported-by Timur Tabi <[email protected]>Signed-off-by Bjorn Andersson <[email protected]>Signed-off-by Linus Walleij <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/qcom/pinctrl-msm.c static int msm_gpio_init(struct msm_pinc · line 824
Quoted 8 lines
drivers/pinctrl/qcom/pinctrl-msm.c +1
-1@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pincreturn -EINVAL ; chip = &pctrl->chip; - chip->base =0 ; + chip->base =-1 ; chip->ngpio = ngpio; chip->label =dev_name (pctrl->dev); chip->parent = pctrl->dev;
this patch creates a regression for me. on ipq8064 the systems gpios now start somewhere in the sky
new layout
lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip373 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373 lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip408 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip408 lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip443 -> ../../devices/platform/soc/800000.pinmux/gpio/gpiochip443
before the patch
lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/800000.pinmux/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip442 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442 lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip477 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip477
this broke my userspace gpio handling. i can override this, but still it doesnt look correct since there is a hole at the beginng likelly reserved by unused arm gpios
Quoted 3 lines
Greg Kroah-Hartman
maintainerRe: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Quoted 53 lines · Sebastian Gottschall
Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:
Quoted 25 lines
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit
a7aa75a2a7dba32594291a71c3704000a2fd7089]The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices.
Fixes f365be092572 ("pinctrl: Add Qualcomm TLMM driver")Reported-by Timur Tabi <[email protected]>Signed-off-by Bjorn Andersson <[email protected]>Signed-off-by Linus Walleij <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pinctrl/qcom/pinctrl-msm.c static int msm_gpio_init(struct msm_pinc · line 823
Quoted 7 lines
drivers/pinctrl/qcom/pinctrl-msm.c +1
-1@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pincreturn -EINVAL ; chip = &pctrl->chip; - chip->base =0 ; + chip->base =-1 ; chip->ngpio = ngpio; chip->label =dev_name (pctrl->dev); chip->parent = pctrl->dev;this patch creates a regression for me. on ipq8064 the systems gpios now start somewhere in the sky
new layout
lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1 00:00 gpiochip373 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373 lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1 00:00 gpiochip408 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip408 lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1 00:00 gpiochip443 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip443before the patch
lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1� 1970 gpiochip0 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip0
lrwxrwxrwx��� 1 root���� root������������ 0 May 31 13:13 gpiochip442 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442 lrwxrwxrwx��� 1 root���� root������������ 0 May 31 13:13 gpiochip477 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip477
Quoted 3 lines
this broke my userspace gpio handling. i can override this, but still it doesnt look correct since there is a hole at the beginng likelly reserved by unused arm gpios
So does this mean that 4.17-rc is also broken for you? If so, this needs to be reverted there as well.
Bjorn, any ideas?
thanks,
greg k-h
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Am 31.05.2018 um 13:45 schrieb Greg Kroah-Hartman:
Quoted 56 lines · Sebastian Gottschall
Quoted 52 lines
Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:
Quoted 25 lines
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit
a7aa75a2a7dba32594291a71c3704000a2fd7089]The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices.
Fixes f365be092572 ("pinctrl: Add Qualcomm TLMM driver")Reported-by Timur Tabi <[email protected]>Signed-off-by Bjorn Andersson <[email protected]>Signed-off-by Linus Walleij <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pinctrl/qcom/pinctrl-msm.c static int msm_gpio_init(struct msm_pinc · line 823
Quoted 7 lines
drivers/pinctrl/qcom/pinctrl-msm.c +1
-1@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pincreturn -EINVAL ; chip = &pctrl->chip; - chip->base =0 ; + chip->base =-1 ; chip->ngpio = ngpio; chip->label =dev_name (pctrl->dev); chip->parent = pctrl->dev;this patch creates a regression for me. on ipq8064 the systems gpios now start somewhere in the sky
new layout
lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip373 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373 lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip408 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip408 lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip443 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip443before the patch
lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip442 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442 lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip477 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip477Quoted 3 lines
this broke my userspace gpio handling. i can override this, but still it doesnt look correct since there is a hole at the beginng likelly reserved by unused arm gpios
Quoted 8 lines
So does this mean that 4.17-rc is also broken for you? If so, this needs to be reverted there as well.
Bjorn, any ideas?
thanks,
greg k-h
i checked initially 4.9 with latest patches and 4.14 and reverted this line to get back to the old behaviour but a which view in the current 4.17 tree shows that the same patch has been included in 4.17. it was introduced in the kernel mainline on 12.feb 2018
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7&id=a7aa75a2a7dba32594291a71c3704000a2fd7089
Quoted 1 line
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Quoted 4 lines · Sebastian Gottschall
Quoted 1 line
i checked initially 4.9 with latest patches and 4.14 and reverted this line to get back to the old behaviour but a which view in the current 4.17 tree shows that the same patch has been included in 4.17. it was introduced in the kernel mainline on 12.feb 2018
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7&id=a7aa75a2a7dba32594291a71c3704000a2fd7089
I believe that this patch should not be applied to *any* stable kernel.
It completely breaks legacy GPIO numbering, and it does so intentionally. That may be okay for future kernels, but IMHO it's wrong for older kernels.
Signature · 3 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Quoted 9 lines · Timur Tabi
Quoted 7 lines · Sebastian Gottschall
Quoted 1 line
i checked initially 4.9 with latest patches and 4.14 and reverted this line to get back to the old behaviour but a which view in the current 4.17�tree�shows
that the same patch has been included in 4.17. it was introduced in the kernel�mainline�on�12.feb�2018
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7&id=a7aa75a2a7dba32594291a71c3704000a2fd7089
Quoted 4 lines
I believe that this patch should not be applied to *any* stable kernel.
It completely breaks legacy GPIO numbering, and it does so intentionally. That may be okay for future kernels, but IMHO it's wrong for older kernels.
Why is it somehow ok for "future" kernels? You can't break the api in the future for no reason.
So this needs to be the same everywhere. If it is broken in 4.17-rc, it needs to be reverted.
thanks,
greg k-h
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Am 31.05.2018 um 14:12 schrieb Greg Kroah-Hartman:
Quoted 15 lines · Timur Tabi
Quoted 11 lines · Sebastian Gottschall
Quoted 6 lines
i checked initially 4.9 with latest patches and 4.14 and reverted this line to get back to the old behaviour but a which view in the current 4.17 tree shows
that the same patch has been included in 4.17. it was introduced in the kernel mainline on 12.feb 2018
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7&id=a7aa75a2a7dba32594291a71c3704000a2fd7089I believe that this patch should not be applied to *any* stable kernel.
It completely breaks legacy GPIO numbering, and it does so intentionally. That may be okay for future kernels, but IMHO it's wrong for older kernels.
Why is it somehow ok for "future" kernels? You can't break the api in the future for no reason.
Quoted 6 lines
So this needs to be the same everywhere. If it is broken in 4.17-rc, it needs to be reverted.
thanks,
greg k-h
i agree. i understand the reason why it was introduced, but the reason was a very special case which can be handled in a different way or specific for the affected architecture / device and this patch alone cannot be introduced without further changes to device tree files which may assign those gpio numbers
i2c, leds etc. (a quick review of the current device tree files for qcom already showed me that they are likelly broken because of this change)
Sebastian
Quoted 1 line
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
In reply to Greg Kroah-HartmanQuoted 5 lines · Greg Kroah-Hartman
Why is it somehow ok for "future" kernels? You can't break the api in the future for no reason.
So this needs to be the same everywhere. If it is broken in 4.17-rc, it needs to be reverted.
This was discussed here:
https://www.spinics.net/lists/linux-arm-msm/msg32572.html
The code can't program the value to 0 *and* support multiple TLMM devices at the same time. Prior to 4.18, it is not possible to support multiple TLMMs anyway, so blindly setting the base to -1 in the 4.17 kernel just breaks existing user-space code that uses the legacy GPIO API.
(This patch in 4.18 is what provides support for multiple TLMMs: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/pinctrl/qcom?id=f265e8b91bb50c7a732a171ddaeb0eef143bacd9)
So you can see in the thread that I proposed a compromise:
https://www.spinics.net/lists/linux-arm-msm/msg32596.html
but that was rejected
Signature · 3 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Quoted 16 lines · Timur Tabi
Quoted 5 lines · Greg Kroah-Hartman
Why is it somehow ok for "future" kernels? You can't break the api in the future for no reason.
So this needs to be the same everywhere. If it is broken in 4.17-rc, it needs to be reverted.
This was discussed here:
https://www.spinics.net/lists/linux-arm-msm/msg32572.html
The code can't program the value to 0 *and* support multiple TLMM devices at the same time. Prior to 4.18, it is not possible to support multiple TLMMs anyway, so blindly setting the base to -1 in the 4.17 kernel just breaks existing user-space code that uses the legacy GPIO API.
Quoted 7 lines
(This patch in 4.18 is what provides support for multiple TLMMs: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/pinctrl/qcom?id=f265e8b91bb50c7a732a171ddaeb0eef143bacd9)
So you can see in the thread that I proposed a compromise:
https://www.spinics.net/lists/linux-arm-msm/msg32596.html
but that was rejected
Ugh, ok, you all have fun with this :(
I've reverted it from all of the stable trees, again, sorry for it coming back.
greg k-h
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
In reply to Greg Kroah-HartmanQuoted 54 lines · Greg Kroah-Hartman
Quoted 53 lines · Sebastian Gottschall
Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:
Quoted 25 lines
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit
a7aa75a2a7dba32594291a71c3704000a2fd7089]The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices.
Fixes f365be092572 ("pinctrl: Add Qualcomm TLMM driver")Reported-by Timur Tabi <[email protected]>Signed-off-by Bjorn Andersson <[email protected]>Signed-off-by Linus Walleij <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pinctrl/qcom/pinctrl-msm.c static int msm_gpio_init(struct msm_pinc · line 823
Quoted 7 lines
drivers/pinctrl/qcom/pinctrl-msm.c +1
-1@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pincreturn -EINVAL ; chip = &pctrl->chip; - chip->base =0 ; + chip->base =-1 ; chip->ngpio = ngpio; chip->label =dev_name (pctrl->dev); chip->parent = pctrl->dev;this patch creates a regression for me. on ipq8064 the systems gpios now start somewhere in the sky
new layout
lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1 00:00 gpiochip373 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373 lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1 00:00 gpiochip408 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip408 lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1 00:00 gpiochip443 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip443before the patch
lrwxrwxrwx��� 1 root���� root������������ 0 Jan� 1� 1970 gpiochip0 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip0
lrwxrwxrwx��� 1 root���� root������������ 0 May 31 13:13 gpiochip442 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442 lrwxrwxrwx��� 1 root���� root������������ 0 May 31 13:13 gpiochip477 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip477
Quoted 9 lines
Quoted 3 lines
this broke my userspace gpio handling. i can override this, but still it doesnt look correct since there is a hole at the beginng likelly reserved by unused arm gpios
So does this mean that 4.17-rc is also broken for you? If so, this needs to be reverted there as well.
Bjorn, any ideas?
The Qualcomm TLMM (pinctrl) driver was introduced long after it was decided that the kernel should not rely on global/static gpio numbering.
But due to a mistake on my part the dynamic gpio base for this gpiochip was always 0, which the offending patch corrects.
So writing user space code relying on the gpio numbering for this chip has always been incorrect, just as it is for the other two gpiochips listed above.
The original objection for backporting this patch was a touchscreen driver stopped working on 4.4, but the driver clearly doesn't depend on global or static numbering of gpios. I don't think this was ever root caused.
I guess the pragmatic approach would be to come up with something like Timur's suggested fix that makes the first instance of this driver use base = 0 and then use dynamic numbering for the rest, to maintain support for this incorrect usage of the gpio sysfs interface. (Although that would probably break if Timur's customers move their user space to the new platform as "the first instance" isn't deterministic).
Regards,
Bjorn
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
Am 31.05.2018 um 18:57 schrieb Bjorn Andersson:
Quoted 88 lines · Greg Kroah-Hartman
Quoted 54 lines · Sebastian Gottschall
Quoted 52 lines
Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:
Quoted 25 lines
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit
a7aa75a2a7dba32594291a71c3704000a2fd7089]The base of the TLMM gpiochip should not be statically defined as 0, fix this to not artificially restrict the existence of multiple pinctrl-msm devices.
Fixes f365be092572 ("pinctrl: Add Qualcomm TLMM driver")Reported-by Timur Tabi <[email protected]>Signed-off-by Bjorn Andersson <[email protected]>Signed-off-by Linus Walleij <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pinctrl/qcom/pinctrl-msm.c static int msm_gpio_init(struct msm_pinc · line 823
Quoted 7 lines
drivers/pinctrl/qcom/pinctrl-msm.c +1
-1@@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pincreturn -EINVAL ; chip = &pctrl->chip; - chip->base =0 ; + chip->base =-1 ; chip->ngpio = ngpio; chip->label =dev_name (pctrl->dev); chip->parent = pctrl->dev;this patch creates a regression for me. on ipq8064 the systems gpios now start somewhere in the sky
new layout
lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip373 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373 lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip408 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip408 lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip443 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip443before the patch
lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip442 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442 lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip477 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip477Quoted 8 lines
Quoted 3 lines
this broke my userspace gpio handling. i can override this, but still it doesnt look correct since there is a hole at the beginng likelly reserved by unused arm gpios
So does this mean that 4.17-rc is also broken for you? If so, this needs to be reverted there as well.
Bjorn, any ideas?
The Qualcomm TLMM (pinctrl) driver was introduced long after it was decided that the kernel should not rely on global/static gpio numbering.
But due to a mistake on my part the dynamic gpio base for this gpiochip was always 0, which the offending patch corrects.
So writing user space code relying on the gpio numbering for this chip has always been incorrect, just as it is for the other two gpiochips listed above.
The original objection for backporting this patch was a touchscreen driver stopped working on 4.4, but the driver clearly doesn't depend on global or static numbering of gpios. I don't think this was ever root caused.
I guess the pragmatic approach would be to come up with something like Timur's suggested fix that makes the first instance of this driver use base = 0 and then use dynamic numbering for the rest, to maintain support for this incorrect usage of the gpio sysfs interface. (Although that would probably break if Timur's customers move their user space to the new platform as "the first instance" isn't deterministic).
Quoted 2 lines
Regards,
Bjorn
that would at least guarantee backward compatiblity. i'm fine with that
Sebastian
Quoted 1 line
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
In reply to Bjorn AnderssonQuoted 3 lines · Bjorn Andersson
(Although
that would probably break if Timur's customers move their user space to the new platform as "the first instance" isn't deterministic).
Users of platforms that have multiple TLMMs should be required to use gpiolib instead of sysfs. I've already updated all our internal code to use it, and there is no external code that does GPIO on our server SoCs anyway.
Signature · 3 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
In reply to Sebastian GottschallQuoted 2 lines · Sebastian Gottschall
this patch creates a regression for me. on ipq8064 the systems gpios now start somewhere in the sky
(...)
Quoted 3 lines
this broke my userspace gpio handling. i can override this, but still it doesnt look correct since there is a hole at the beginng likelly reserved by unused arm gpios
Out of curiosity: what is this userspace?
We do not break userspace, so I guess we should put in some hack to keep the base 0 on ipq8064 then, but as pointed out by Bjorn there will be problems when we get multiple gpiochips in later platforms so it is just a stopgap solution.
Have you looked into using the new character device with your userspace, either as shown in the examples:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio
or using libgpiod:
https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
Yours,
Linus Walleij
Greg Kroah-Hartman
maintainerPATCH 271/272 kdb: make "mdr" command repeat
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Randy Dunlap <[email protected]>
[ Upstream commit 1e0ce03bf142454f38a5fc050bf4fd698d2d36d8 ]
The "mdr" command should repeat (continue) when only Enter/Return is pressed, so make it do so.
--- kernel/debug/kdb/kdb_main.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-)
kernel/debug/kdb/kdb_main.c +21 -6
@@ -1566,6 +1566,7 @@ static int kdb_md(int argc, const char *int symbolic =0 ;int valid =0 ;int phys =0 ; +int raw =0 ;kdbgetintenv ("MDCOUNT" , &mdcount);kdbgetintenv ("RADIX" , &radix);
@@ -1575,9 +1576,10 @@ static int kdb_md(int argc, const char * repeat = mdcount *16 / bytesperword;if (strcmp (argv[0 ],"mdr" ) ==0 ) { -if (argc !=2 ) +if (argc ==2 || (argc ==0 && last_addr !=0 )) + valid = raw =1 ; +else return KDB_ARGCOUNT ; - valid =1 ; }else if (isdigit (argv[0 ][2 ])) { bytesperword = (int )(argv[0 ][2 ] -'0' );if (bytesperword ==0 ) {
@@ -1613,7 +1615,10 @@ static int kdb_md(int argc, const char * radix = last_radix; bytesperword = last_bytesperword; repeat = last_repeat; - mdcount = ((repeat * bytesperword) +15 ) /16 ; +if (raw) + mdcount = repeat; +else + mdcount = ((repeat * bytesperword) +15 ) /16 ; }if (argc) {
@@ -1630,7 +1635,10 @@ static int kdb_md(int argc, const char * diag =kdbgetularg (argv[nextarg], &val);if (!diag) { mdcount = (int ) val; - repeat = mdcount *16 / bytesperword; +if (raw) + repeat = mdcount; +else + repeat = mdcount *16 / bytesperword; } }if (argc >= nextarg+1 ) {
@@ -1640,8 +1648,15 @@ static int kdb_md(int argc, const char * } } -if (strcmp (argv[0 ],"mdr" ) ==0 ) -return kdb_mdr (addr, mdcount); +if (strcmp (argv[0 ],"mdr" ) ==0 ) { +int ret; + last_addr = addr; + ret =kdb_mdr (addr, mdcount); + last_addr += mdcount; + last_repeat = mdcount; + last_bytesperword = bytesperword;// to make REPEAT happy +return ret; + }switch (radix) {case 10 :
Greg Kroah-Hartman
maintainerPATCH 272/272 drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepak Rawat <[email protected]>
commit 91ba9f28a3de97761c2b5fd5df5d88421268e507 upstream.
SOU primary plane prepare_fb hook depends upon dmabuf_size to pin up BO (and not call a new vmw_dmabuf_init) when a new fb size is same as current fb. This was changed in a recent commit which is causing page_flip to fail on VM with low display memory and multi-mon failure when cycle monitors from secondary display.
--- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +2 -0
@@ -530,6 +530,8 @@ vmw_sou_primary_plane_prepare_fb(structreturn ret; } + vps->dmabuf_size = size; +/* * TTM already thinks the buffer is pinned, but make sure the * pin_count is upped.
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.y
and the diffstat can be found below.thanks,
Quoted 7 lines
greg k-h
Davidlohr Bueso <[email protected]>
ipc/shm: fixshmat()nil address after round-down when remappingDavidlohr Bueso <[email protected]>
Revert "ipc/shm: Fix shmat mmap nil-page protection"
Regression on 4.16, 4,14, 4.9 and 4.4 and all devices.
Regressions (compared to build v4.16.12)
------------------------------------------------------------------------
On all devices,
ltp-syscalls-tests:
* cve-2017-5669
ltp-cve-tests:
* cve-2017-5669
Test log:
------------
cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page cve-2017-5669.c:74: INFO: Mapped shared memory to (nil) cve-2017-5669.c:78: FAIL: We have mapped a VM address within the first 64Kb cve-2017-5669.c:84: INFO: Touching shared memory to see if anything strange happens
Summary:
passed 0 failed 1 skipped 0
warnings 0
The root cause is,
"Revert "ipc/shm: Fix shmat mmap nil-page protection"", which explicitly rolls back the original change and mentions that the LTP test case needs to be updated accordingly.
This regression initially detected on 4.17.0-rc5-next-20180516 Need more investigation on this issue.
Ref:
LKFT: next: LTS-4.16,4.14 and 4.9: LTP test case cve-2017-5669 failed on all devices
https://bugs.linaro.org/show_bug.cgi?id=3835
https://bugzilla.kernel.org/show_bug.cgi?id=192931
https://patchwork.kernel.org/patch/9552307/
Best regards
Naresh Kamboju
Quoted 19 lines · Naresh Kamboju
On 28 May 2018 at 15:30, Greg Kroah-Hartman <[email protected]> wrote:
On all devices,
ltp-syscalls-tests:
* cve-2017-5669ltp-cve-tests:
* cve-2017-5669Test log:
------------
cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page cve-2017-5669.c:74: INFO: Mapped shared memory to (nil) cve-2017-5669.c:78: FAIL: We have mapped a VM address within the first 64Kb cve-2017-5669.c:84: INFO: Touching shared memory to see if anything strange happens
Summary:passed 0 failed 1 skipped 0
Quoted 7 lines
warnings 0
The root cause is,
"Revert "ipc/shm: Fix shmat mmap nil-page protection"", which explicitly rolls back the original change and mentions that the LTP test case needs to be updated accordingly.
This is expected in that the ltp testcase was made based on wrong assumptions. Furthermore, the reversion is being done because without it we breaks userspace; X11 most noticeably -- that alone indicates that the cve testcase is bogus.
Quoted 3 lines
This regression initially detected on 4.17.0-rc5-next-20180516 Need more investigation on this issue.
The correct way of proceeding is to update the ltp testcase to deal with the remap option only, which I mentioned and they are Cc'ed.
Thanks,
Davidlohr
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
Build results:
total: 143 pass: 143 fail: 0 Qemu test results: total: 141 pass: 141 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
Quoted 6 lines
Build results:
total: 143 pass: 143 fail: 0 Qemu test results: total: 141 pass: 141 fail: 0Details are available at http://kerneltests.org/builders.
Wonderful, everything passed. Thanks for testing all of these and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
NOTE:
The failed LTP test case "cve-2017-5669" is a waiver here.
Summary
------------------------------------------------------------------------
kernel: 4.16.13-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.16.y
git commit: ca67f014e67013cd3d8312e68d2967332dae8654
git describe: v4.16.12-273-gca67f014e670
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.12-273-gca67f014e670
No regressions (compared to build v4.16.12-271-g2cb370dedebb)
Ran 10312 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-fcntl-locktests-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-timers-tests
* ltp-cve-tests
* ltp-filecaps-tests
* ltp-syscalls-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.y
and the diffstat can be found below.thanks,
Quoted 7 lines
Quoted 1 line
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm andx86_64.NOTE:
The failed LTP test case "cve-2017-5669" is a waiver here.
Thanks for figuring that one out :)
Also, thanks for testing all of these and letting me know.
greg k-h
The following bug has been opened for LTP:
https://github.com/linux-test-project/ltp/issues/319
for the CVE-2017-5669's wrong assumptions (based on Davidlohr's work).
I'll change the test to cover both scenarios and expect the right results from them.
Quoted 31 lines · Greg Kroah-Hartman
Quoted 17 lines · Naresh Kamboju
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.y
and the diffstat can be found below.thanks,
Quoted 7 lines
Quoted 1 line
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm andx86_64.NOTE:
The failed LTP test case "cve-2017-5669" is a waiver here.Thanks for figuring that one out :)
Also, thanks for testing all of these and letting me know.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.13 release. There are 272 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed May 30 10:01:02 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.13-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.y
and the diffstat can be found below.
Quoted 4 lines
Quoted 3 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h