* [PATCH 4/5] parisc: configs: drop unused BACKLIGHT_GENERIC option
From: Andrey Zhizhikin @ 2020-11-30 15:21 UTC (permalink / raw)
To: linux, nicolas.ferre, alexandre.belloni, ludovic.desroches, tony,
mripard, wens, jernej.skrabec, thierry.reding, jonathanh,
catalin.marinas, will, tsbogend, James.Bottomley, deller, mpe,
benh, paulus, lee.jones, sam, emil.l.velikov, daniel.thompson,
krzk, linux-arm-kernel, linux-kernel, linux-omap, linux-tegra,
linux-mips, linux-parisc, linuxppc-dev
In-Reply-To: <20201130152137.24909-1-andrey.zhizhikin@leica-geosystems.com>
Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
unused") removed geenric_bl driver from the tree, together with
corresponding config option.
Remove BACKLIGHT_GENERIC config item from generic-64bit_defconfig.
Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is unused")
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
---
arch/parisc/configs/generic-64bit_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/parisc/configs/generic-64bit_defconfig b/arch/parisc/configs/generic-64bit_defconfig
index 7e2d7026285e..8f81fcbf04c4 100644
--- a/arch/parisc/configs/generic-64bit_defconfig
+++ b/arch/parisc/configs/generic-64bit_defconfig
@@ -191,7 +191,6 @@ CONFIG_DRM=y
CONFIG_DRM_RADEON=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_HIDRAW=y
CONFIG_HID_PID=y
--
2.17.1
^ permalink raw reply related
* [PATCH 1/5] ARM: configs: drop unused BACKLIGHT_GENERIC option
From: Andrey Zhizhikin @ 2020-11-30 15:21 UTC (permalink / raw)
To: linux, nicolas.ferre, alexandre.belloni, ludovic.desroches, tony,
mripard, wens, jernej.skrabec, thierry.reding, jonathanh,
catalin.marinas, will, tsbogend, James.Bottomley, deller, mpe,
benh, paulus, lee.jones, sam, emil.l.velikov, daniel.thompson,
krzk, linux-arm-kernel, linux-kernel, linux-omap, linux-tegra,
linux-mips, linux-parisc, linuxppc-dev
In-Reply-To: <20201130152137.24909-1-andrey.zhizhikin@leica-geosystems.com>
Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
unused") removed geenric_bl driver from the tree, together with
corresponding config option.
Remove BACKLIGHT_GENERIC config item from all ARM configurations.
Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is unused")
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
---
arch/arm/configs/at91_dt_defconfig | 1 -
arch/arm/configs/cm_x300_defconfig | 1 -
arch/arm/configs/colibri_pxa300_defconfig | 1 -
arch/arm/configs/jornada720_defconfig | 1 -
arch/arm/configs/magician_defconfig | 1 -
arch/arm/configs/mini2440_defconfig | 1 -
arch/arm/configs/omap2plus_defconfig | 1 -
arch/arm/configs/pxa3xx_defconfig | 1 -
arch/arm/configs/qcom_defconfig | 1 -
arch/arm/configs/sama5_defconfig | 1 -
arch/arm/configs/sunxi_defconfig | 1 -
arch/arm/configs/tegra_defconfig | 1 -
arch/arm/configs/u8500_defconfig | 1 -
13 files changed, 13 deletions(-)
diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig
index 4a0ba2ae1a25..6e52c9c965e6 100644
--- a/arch/arm/configs/at91_dt_defconfig
+++ b/arch/arm/configs/at91_dt_defconfig
@@ -132,7 +132,6 @@ CONFIG_DRM_ATMEL_HLCDC=y
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_FB_ATMEL=y
CONFIG_BACKLIGHT_ATMEL_LCDC=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
diff --git a/arch/arm/configs/cm_x300_defconfig b/arch/arm/configs/cm_x300_defconfig
index 2f7acde2d921..502a9d870ca4 100644
--- a/arch/arm/configs/cm_x300_defconfig
+++ b/arch/arm/configs/cm_x300_defconfig
@@ -87,7 +87,6 @@ CONFIG_FB=y
CONFIG_FB_PXA=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_TDO24M=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_DA903X=m
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
diff --git a/arch/arm/configs/colibri_pxa300_defconfig b/arch/arm/configs/colibri_pxa300_defconfig
index 0dae3b185284..26e5a67f8e2d 100644
--- a/arch/arm/configs/colibri_pxa300_defconfig
+++ b/arch/arm/configs/colibri_pxa300_defconfig
@@ -34,7 +34,6 @@ CONFIG_FB=y
CONFIG_FB_PXA=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_VGA_CONSOLE is not set
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
diff --git a/arch/arm/configs/jornada720_defconfig b/arch/arm/configs/jornada720_defconfig
index 9f079be2b84b..069f60ffdcd8 100644
--- a/arch/arm/configs/jornada720_defconfig
+++ b/arch/arm/configs/jornada720_defconfig
@@ -48,7 +48,6 @@ CONFIG_FB=y
CONFIG_FB_S1D13XXX=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_VGA_CONSOLE is not set
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
diff --git a/arch/arm/configs/magician_defconfig b/arch/arm/configs/magician_defconfig
index d2e684f6565a..b4670d42f378 100644
--- a/arch/arm/configs/magician_defconfig
+++ b/arch/arm/configs/magician_defconfig
@@ -95,7 +95,6 @@ CONFIG_FB_PXA_OVERLAY=y
CONFIG_FB_W100=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
# CONFIG_VGA_CONSOLE is not set
CONFIG_FRAMEBUFFER_CONSOLE=y
diff --git a/arch/arm/configs/mini2440_defconfig b/arch/arm/configs/mini2440_defconfig
index 301f29a1fcc3..898490aaa39e 100644
--- a/arch/arm/configs/mini2440_defconfig
+++ b/arch/arm/configs/mini2440_defconfig
@@ -158,7 +158,6 @@ CONFIG_FB_S3C2410=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index de3b7813a1ce..7eae097a75d2 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -388,7 +388,6 @@ CONFIG_FB_TILEBLITTING=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-CONFIG_BACKLIGHT_GENERIC=m
CONFIG_BACKLIGHT_PWM=m
CONFIG_BACKLIGHT_PANDORA=m
CONFIG_BACKLIGHT_GPIO=m
diff --git a/arch/arm/configs/pxa3xx_defconfig b/arch/arm/configs/pxa3xx_defconfig
index 06bbc7a59b60..f0c34017f2aa 100644
--- a/arch/arm/configs/pxa3xx_defconfig
+++ b/arch/arm/configs/pxa3xx_defconfig
@@ -74,7 +74,6 @@ CONFIG_FB_PXA=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_TDO24M=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_DA903X=y
# CONFIG_VGA_CONSOLE is not set
CONFIG_FRAMEBUFFER_CONSOLE=y
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index c882167e1496..d6733e745b80 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -159,7 +159,6 @@ CONFIG_FB=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_LM3630A=y
CONFIG_BACKLIGHT_LP855X=y
CONFIG_SOUND=y
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index 037d3a718a60..0a167891eb05 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -161,7 +161,6 @@ CONFIG_DRM_ATMEL_HLCDC=y
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_SOUND=y
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 244126172fd6..af6e80d1a0f2 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -111,7 +111,6 @@ CONFIG_DRM_SIMPLE_BRIDGE=y
CONFIG_DRM_LIMA=y
CONFIG_FB_SIMPLE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
CONFIG_SOUND=y
CONFIG_SND=y
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index fff5fae0db30..74739a52a8ad 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -205,7 +205,6 @@ CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_LVDS_CODEC=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 28dd7cf56048..24aacc255021 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -92,7 +92,6 @@ CONFIG_DRM_PANEL_SONY_ACX424AKP=y
CONFIG_DRM_LIMA=y
CONFIG_DRM_MCDE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
-CONFIG_BACKLIGHT_GENERIC=m
CONFIG_BACKLIGHT_GPIO=y
CONFIG_LOGO=y
CONFIG_SOUND=y
--
2.17.1
^ permalink raw reply related
* [PATCH 5/5] powerpc/configs: drop unused BACKLIGHT_GENERIC option
From: Andrey Zhizhikin @ 2020-11-30 15:21 UTC (permalink / raw)
To: linux, nicolas.ferre, alexandre.belloni, ludovic.desroches, tony,
mripard, wens, jernej.skrabec, thierry.reding, jonathanh,
catalin.marinas, will, tsbogend, James.Bottomley, deller, mpe,
benh, paulus, lee.jones, sam, emil.l.velikov, daniel.thompson,
krzk, linux-arm-kernel, linux-kernel, linux-omap, linux-tegra,
linux-mips, linux-parisc, linuxppc-dev
In-Reply-To: <20201130152137.24909-1-andrey.zhizhikin@leica-geosystems.com>
Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
unused") removed geenric_bl driver from the tree, together with
corresponding config option.
Remove BACKLIGHT_GENERIC config item from generic-64bit_defconfig.
Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is unused")
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
---
arch/powerpc/configs/powernv_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
index cf30fc24413b..60a30fffeda0 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -208,7 +208,6 @@ CONFIG_FB_MATROX_G=y
CONFIG_FB_RADEON=m
CONFIG_FB_IBM_GXT4500=m
CONFIG_LCD_PLATFORM=m
-CONFIG_BACKLIGHT_GENERIC=m
# CONFIG_VGA_CONSOLE is not set
CONFIG_LOGO=y
CONFIG_HID_A4TECH=m
--
2.17.1
^ permalink raw reply related
* RE: [PATCH 1/5] ARM: configs: drop unused BACKLIGHT_GENERIC option
From: ZHIZHIKIN Andrey @ 2020-11-30 19:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: alexandre.belloni@bootlin.com, tony@atomide.com,
linux-kernel@vger.kernel.org,
James.Bottomley@HansenPartnership.com, thierry.reding@gmail.com,
paulus@samba.org, sam@ravnborg.org, daniel.thompson@linaro.org,
linux-omap@vger.kernel.org, Arnd Bergmann, deller@gmx.de,
linux@armlinux.org.uk, jonathanh@nvidia.com,
ludovic.desroches@microchip.com, catalin.marinas@arm.com,
linux-mips@vger.kernel.org, will@kernel.org, mripard@kernel.org,
linux-tegra@vger.kernel.org, lee.jones@linaro.org, wens@csie.org,
linux-arm-kernel@lists.infradead.org, jernej.skrabec@siol.net,
tsbogend@alpha.franken.de, linux-parisc@vger.kernel.org,
emil.l.velikov@gmail.com, nicolas.ferre@microchip.com,
Olof Johansson, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20201130185227.GA29434@kozik-lap>
Hello Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Monday, November 30, 2020 7:52 PM
> To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> Cc: linux@armlinux.org.uk; nicolas.ferre@microchip.com;
> alexandre.belloni@bootlin.com; ludovic.desroches@microchip.com;
> tony@atomide.com; mripard@kernel.org; wens@csie.org;
> jernej.skrabec@siol.net; thierry.reding@gmail.com; jonathanh@nvidia.com;
> catalin.marinas@arm.com; will@kernel.org; tsbogend@alpha.franken.de;
> James.Bottomley@HansenPartnership.com; deller@gmx.de;
> mpe@ellerman.id.au; benh@kernel.crashing.org; paulus@samba.org;
> lee.jones@linaro.org; sam@ravnborg.org; emil.l.velikov@gmail.com;
> daniel.thompson@linaro.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> tegra@vger.kernel.org; linux-mips@vger.kernel.org; linux-
> parisc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Arnd Bergmann
> <arnd@arndb.de>; Olof Johansson <olof@lixom.net>
> Subject: Re: [PATCH 1/5] ARM: configs: drop unused BACKLIGHT_GENERIC
> option
>
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
>
>
> On Mon, Nov 30, 2020 at 03:21:33PM +0000, Andrey Zhizhikin wrote:
> > Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it
> > is
> > unused") removed geenric_bl driver from the tree, together with
> > corresponding config option.
> >
> > Remove BACKLIGHT_GENERIC config item from all ARM configurations.
> >
> > Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it
> > is unused")
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Andrey Zhizhikin
> > <andrey.zhizhikin@leica-geosystems.com>
> > ---
> > arch/arm/configs/at91_dt_defconfig | 1 -
> > arch/arm/configs/cm_x300_defconfig | 1 -
> > arch/arm/configs/colibri_pxa300_defconfig | 1 -
> > arch/arm/configs/jornada720_defconfig | 1 -
> > arch/arm/configs/magician_defconfig | 1 -
> > arch/arm/configs/mini2440_defconfig | 1 -
> > arch/arm/configs/omap2plus_defconfig | 1 -
> > arch/arm/configs/pxa3xx_defconfig | 1 -
> > arch/arm/configs/qcom_defconfig | 1 -
> > arch/arm/configs/sama5_defconfig | 1 -
> > arch/arm/configs/sunxi_defconfig | 1 -
> > arch/arm/configs/tegra_defconfig | 1 -
> > arch/arm/configs/u8500_defconfig | 1 -
> > 13 files changed, 13 deletions(-)
>
> You need to send it to arm-soc maintainers, otherwise no one might feel
> responsible enough to pick it up.
Good point, thanks a lot!
I was not aware of the fact that there is a separate ML that should receive patches targeted ARM SOCs. Can you (or anyone else) please share it, so I can re-send it there as well?
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> +CC Arnd and Olof,
>
> Dear Arnd and Olof,
>
> Maybe it is worth to add arm-soc entry to the MAINTAINERS file?
> Otherwise how one could get your email address? Not mentioning the
> secret-soc address. :)
"scripts/get_maintainer.pl --no-git-fallback --no-multiline --no-rolestats --no-n --separator , " across entire series gave only the list of addresses that I've included in the series itself. If I would be given a arm-soc mailing list as output of the script - I would've included it as well.
>
> Best regards,
> Krzysztof
Regards,
Andrey
^ permalink raw reply
* RE: [PATCH 0/5] drop unused BACKLIGHT_GENERIC option
From: ZHIZHIKIN Andrey @ 2020-11-30 19:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: alexandre.belloni@bootlin.com, tony@atomide.com,
linux-kernel@vger.kernel.org,
James.Bottomley@hansenpartnership.com, thierry.reding@gmail.com,
paulus@samba.org, lee.jones@linaro.org,
daniel.thompson@linaro.org, linux-omap@vger.kernel.org,
Arnd Bergmann, deller@gmx.de, linux@armlinux.org.uk,
krzk@kernel.org, jonathanh@nvidia.com,
ludovic.desroches@microchip.com, catalin.marinas@arm.com,
linux-mips@vger.kernel.org, will@kernel.org, mripard@kernel.org,
linux-tegra@vger.kernel.org, wens@csie.org,
linux-arm-kernel@lists.infradead.org, jernej.skrabec@siol.net,
tsbogend@alpha.franken.de, linux-parisc@vger.kernel.org,
emil.l.velikov@gmail.com, nicolas.ferre@microchip.com,
Olof Johansson, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20201130191133.GA1565464@ravnborg.org>
Hello Sam,
> -----Original Message-----
> From: Sam Ravnborg <sam@ravnborg.org>
> Sent: Monday, November 30, 2020 8:12 PM
> To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> Cc: linux@armlinux.org.uk; nicolas.ferre@microchip.com;
> alexandre.belloni@bootlin.com; ludovic.desroches@microchip.com;
> tony@atomide.com; mripard@kernel.org; wens@csie.org;
> jernej.skrabec@siol.net; thierry.reding@gmail.com; jonathanh@nvidia.com;
> catalin.marinas@arm.com; will@kernel.org; tsbogend@alpha.franken.de;
> James.Bottomley@hansenpartnership.com; deller@gmx.de;
> mpe@ellerman.id.au; benh@kernel.crashing.org; paulus@samba.org;
> lee.jones@linaro.org; emil.l.velikov@gmail.com;
> daniel.thompson@linaro.org; krzk@kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> omap@vger.kernel.org; linux-tegra@vger.kernel.org; linux-
> mips@vger.kernel.org; linux-parisc@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Arnd Bergmann <arnd@arndb.de>; Olof Johansson
> <olof@lixom.net>
> Subject: Re: [PATCH 0/5] drop unused BACKLIGHT_GENERIC option
>
>
> On Mon, Nov 30, 2020 at 03:21:32PM +0000, Andrey Zhizhikin wrote:
> > Since the removal of generic_bl driver from the source tree in commit
> > 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> > unused") BACKLIGHT_GENERIC config option became obsolete as well and
> > therefore subject to clean-up from all configuration files.
> >
> > This series introduces patches to address this removal, separated by
> > architectures in the kernel tree.
> >
> > Andrey Zhizhikin (5):
> > ARM: configs: drop unused BACKLIGHT_GENERIC option
> > arm64: defconfig: drop unused BACKLIGHT_GENERIC option
> > MIPS: configs: drop unused BACKLIGHT_GENERIC option
> > parisc: configs: drop unused BACKLIGHT_GENERIC option
> > powerpc/configs: drop unused BACKLIGHT_GENERIC option
>
> For defconfigs I expect arch maintainers to do a make xxxdefconfig / make
> savedefconfig / cp defconfig ... run now and then - this will remove all such
> symbols.
This series stretches across several archs, so I would expect that it could've been addressed for some of them but would take more time than submitting this "point fix" now, targeting one obsolete config option.
I've personally hit it for arm64 on the first place, and looking further into the option itself I realized that it is missing from the kernel tree completely and decided to fix all archs affected at once.
>
> If the patches goes in like they are submitted then:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> >
> > arch/arm/configs/at91_dt_defconfig | 1 -
> > arch/arm/configs/cm_x300_defconfig | 1 -
> > arch/arm/configs/colibri_pxa300_defconfig | 1 -
> > arch/arm/configs/jornada720_defconfig | 1 -
> > arch/arm/configs/magician_defconfig | 1 -
> > arch/arm/configs/mini2440_defconfig | 1 -
> > arch/arm/configs/omap2plus_defconfig | 1 -
> > arch/arm/configs/pxa3xx_defconfig | 1 -
> > arch/arm/configs/qcom_defconfig | 1 -
> > arch/arm/configs/sama5_defconfig | 1 -
> > arch/arm/configs/sunxi_defconfig | 1 -
> > arch/arm/configs/tegra_defconfig | 1 -
> > arch/arm/configs/u8500_defconfig | 1 -
> > arch/arm64/configs/defconfig | 1 -
> > arch/mips/configs/gcw0_defconfig | 1 -
> > arch/mips/configs/gpr_defconfig | 1 -
> > arch/mips/configs/lemote2f_defconfig | 1 -
> > arch/mips/configs/loongson3_defconfig | 1 -
> > arch/mips/configs/mtx1_defconfig | 1 -
> > arch/mips/configs/rs90_defconfig | 1 -
> > arch/parisc/configs/generic-64bit_defconfig | 1 -
> > arch/powerpc/configs/powernv_defconfig | 1 -
> > 22 files changed, 22 deletions(-)
> >
> >
> > base-commit: b65054597872ce3aefbc6a666385eabdf9e288da
> > prerequisite-patch-id: bfd382cf1dc021d20204f10ea9403319c1c32b12
> > prerequisite-patch-id: 5397c0c8648bb3e0b830207ea867138c11c6e644
> > prerequisite-patch-id: a3c284dff5fe6d02828918a886db6a8ed3197e20
> > --
> > 2.17.1
Regards,
Andrey
^ permalink raw reply
* Re: [PATCH 0/5] drop unused BACKLIGHT_GENERIC option
From: Sam Ravnborg @ 2020-11-30 21:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: alexandre.belloni, tony, linux-kernel, James.Bottomley,
thierry.reding, paulus, lee.jones, daniel.thompson, linux-omap,
Arnd Bergmann, deller, linux, jonathanh, ludovic.desroches,
catalin.marinas, linux-mips, will, mripard, Andrey Zhizhikin,
linux-tegra, wens, linux-arm-kernel, jernej.skrabec, tsbogend,
linux-parisc, emil.l.velikov, nicolas.ferre, Olof Johansson,
linuxppc-dev
In-Reply-To: <20201130202501.GA32878@kozik-lap>
Hi Krzysztof,
On Mon, Nov 30, 2020 at 10:25:01PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Nov 30, 2020 at 08:11:33PM +0100, Sam Ravnborg wrote:
> > On Mon, Nov 30, 2020 at 03:21:32PM +0000, Andrey Zhizhikin wrote:
> > > Since the removal of generic_bl driver from the source tree in commit
> > > 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> > > unused") BACKLIGHT_GENERIC config option became obsolete as well and
> > > therefore subject to clean-up from all configuration files.
> > >
> > > This series introduces patches to address this removal, separated by
> > > architectures in the kernel tree.
> > >
> > > Andrey Zhizhikin (5):
> > > ARM: configs: drop unused BACKLIGHT_GENERIC option
> > > arm64: defconfig: drop unused BACKLIGHT_GENERIC option
> > > MIPS: configs: drop unused BACKLIGHT_GENERIC option
> > > parisc: configs: drop unused BACKLIGHT_GENERIC option
> > > powerpc/configs: drop unused BACKLIGHT_GENERIC option
> >
> > For defconfigs I expect arch maintainers to do a make xxxdefconfig / make
> > savedefconfig / cp defconfig ... run now and then - this will remove
> > all such symbols.
>
> savedefconfig can be tricky because of risk of loosing options:
> 1. it will remove options which became the default or became selected,
> 2. later when the default is changed or selecting option is removed, the
> first option from #1 will not be brought back.
>
> This was already for example with DEBUG_FS and the conclusion that time
> was - do not run savedefconfig automatically.
>
> Therefore if some symbol(s) can be safely removed, patch is welcomed.
Thanks for letting me know, I have missed that discussion and
was obviously not aware.
I already acked'ed the patches and hope the soc people will pick them
up.
Sam
^ permalink raw reply
* Re: [PATCH kernel v4 2/8] genirq/irqdomain: Clean legacy IRQ allocation
From: Thomas Gleixner @ 2020-11-30 21:41 UTC (permalink / raw)
To: Alexey Kardashevskiy, linux-kernel
Cc: Alexey Kardashevskiy, Marc Zyngier, x86, linux-gpio,
Oliver O'Halloran, Cédric Le Goater, Frederic Barrat,
Michal Suchánek, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201124061720.86766-3-aik@ozlabs.ru>
Alexey,
On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
> There are 10 users of __irq_domain_alloc_irqs() and only one - IOAPIC -
> passes realloc==true. There is no obvious reason for handling this
> specific case in the generic code.
There is also no obvious reason for _NOT_ handling it at the core code.
> This splits out __irq_domain_alloc_irqs_data() to make it clear what
> IOAPIC does and makes __irq_domain_alloc_irqs() cleaner.
That's your interpretation of cleaner.
You need to expose __irq_domain_alloc_irqs_data() for that which is a
core only functionality, so it's not cleaner. It's exposing internals
which are not to be exposed.
The right thing to do is to get rid of the legacy allocation of x86
during early_irq_init() which is possible with the recent restructuring
of the interrupt initialization code in x86. That's a cleanup which will
actually remove code and not expose internals just because.
> This should cause no behavioral change.
Should not cause is a pretty weak statement.
You're missing a nasty detail here. Contrary to the normal irqdomain
rules virq 0 _IS_ valid on x86 for historical reasons and that's not
trivial to change.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v8 11/12] mm/vmalloc: Hugepage vmalloc mappings
From: Edgecombe, Rick P @ 2020-11-30 21:42 UTC (permalink / raw)
To: npiggin@gmail.com, linux-mm@kvack.org, akpm@linux-foundation.org
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
hch@infradead.org, lizefan@huawei.com,
Jonathan.Cameron@Huawei.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <e9d3a50e1b18f9ea1cdfdc221bef75db19273417.camel@intel.com>
On Mon, 2020-11-30 at 12:21 -0800, Rick Edgecombe wrote:
> another option could be to use the changes here:
> https://lore.kernel.org/lkml/20201125092208.12544-4-rppt@kernel.org/
> to reset the direct map for a large page range at a time for large
> vmalloc pages.
Oops, sorry. This wouldn't be so simple because hibernate currently
expects NP direct map pages to be 4k.
^ permalink raw reply
* Re: [PATCH v2] clk: renesas: r9a06g032: Drop __packed for portability
From: Stephen Rothwell @ 2020-11-30 21:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Boyd, Michael Turquette, linux-kernel, Gareth Williams,
linux-renesas-soc, Paul Mackerras, linuxppc-dev, linux-clk
In-Reply-To: <20201130085743.1656317-1-geert+renesas@glider.be>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
Hi Geert,
On Mon, 30 Nov 2020 09:57:43 +0100 Geert Uytterhoeven <geert+renesas@glider.be> wrote:
>
> The R9A06G032 clock driver uses an array of packed structures to reduce
> kernel size. However, this array contains pointers, which are no longer
> aligned naturally, and cannot be relocated on PPC64. Hence when
> compile-testing this driver on PPC64 with CONFIG_RELOCATABLE=y (e.g.
> PowerPC allyesconfig), the following warnings are produced:
>
> WARNING: 136 bad relocations
> c000000000616be3 R_PPC64_UADDR64 .rodata+0x00000000000cf338
> c000000000616bfe R_PPC64_UADDR64 .rodata+0x00000000000cf370
> ...
>
> Fix this by dropping the __packed attribute from the r9a06g032_clkdesc
> definition, trading a small size increase for portability.
>
> This increases the 156-entry clock table by 1 byte per entry, but due to
> the compiler generating more efficient code for unpacked accesses, the
> net size increase is only 76 bytes (gcc 9.3.0 on arm32).
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - Fix authorship.
> ---
> drivers/clk/renesas/r9a06g032-clocks.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks.
I have added that to my fixes tree until it gets picked up elsewhere.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH kernel v4 5/8] genirq: Add free_irq hook for IRQ descriptor and use for mapping disposal
From: Thomas Gleixner @ 2020-11-30 22:18 UTC (permalink / raw)
To: Alexey Kardashevskiy, linux-kernel
Cc: Alexey Kardashevskiy, Marc Zyngier, x86, linux-gpio,
Oliver O'Halloran, Cédric Le Goater, Frederic Barrat,
Michal Suchánek, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201124061720.86766-6-aik@ozlabs.ru>
Alexey,
On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
> We want to make the irq_desc.kobj's release hook free associated resources
> but we do not want to pollute the irqdesc code with domains.
Can you please describe your changelog in factual ways without 'we and I
and want'? See Documentation/process/
> This adds a free_irq hook which is called when the last reference to
> the descriptor is dropped.
>
> The first user is mapped irqs. This potentially can break the existing
> users; however they seem to do the right thing and call dispose once
> per mapping.
Q: How is this supposed to work with CONFIG_SPARSE_IRQ=n?
A: Not at all.
Also 'seem to do the right thing' is from the same quality as 'should
not break stuff'. Either you have done a proper analysis or you did
not. Aside of that how is anyone supposed to decode the subtle wreckage
which is this going to cause if 'seem to do the right thing' turns out
to be wrong?
> -void irq_domain_disassociate(struct irq_domain *domain, unsigned int irq)
> +static void irq_domain_disassociate(struct irq_domain *domain, unsigned int irq)
> {
> struct irq_data *irq_data = irq_get_irq_data(irq);
> irq_hw_number_t hwirq;
> @@ -582,6 +582,13 @@ void irq_domain_associate_many(struct irq_domain *domain, unsigned int irq_base,
> }
> EXPORT_SYMBOL_GPL(irq_domain_associate_many);
>
> +static void irq_mapped_free_desc(struct irq_desc *desc)
That function name is really misleading and badly chosen. The function
is not about freeing the irq descriptor as the name suggests. It's
called from that code in order to clean up the mapping.
> +{
> + unsigned int virq = desc->irq_data.irq;
> +
> + irq_domain_disassociate(desc->irq_data.domain, virq);
> +}
> +
> /**
> * irq_create_direct_mapping() - Allocate an irq for direct mapping
> * @domain: domain to allocate the irq for or NULL for default domain
> @@ -638,6 +645,7 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
> {
> struct device_node *of_node;
> int virq;
> + struct irq_desc *desc;
This code uses reverse fir tree ordering of variables
struct device_node *of_node;
struct irq_desc *desc;
int virq;
Why? Because it's simpler to read than the vertical camel case above.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH kernel v4 5/8] genirq: Add free_irq hook for IRQ descriptor and use for mapping disposal
From: Thomas Gleixner @ 2020-11-30 22:33 UTC (permalink / raw)
To: Alexey Kardashevskiy, linux-kernel
Cc: Alexey Kardashevskiy, Marc Zyngier, x86, linux-gpio,
Oliver O'Halloran, Cédric Le Goater, Frederic Barrat,
Michal Suchánek, linuxppc-dev, linux-arm-kernel
In-Reply-To: <877dq2ij45.fsf@nanos.tec.linutronix.de>
On Mon, Nov 30 2020 at 23:18, Thomas Gleixner wrote:
> On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
>> We want to make the irq_desc.kobj's release hook free associated resources
>> but we do not want to pollute the irqdesc code with domains.
>
> Can you please describe your changelog in factual ways without 'we and I
> and want'? See Documentation/process/
And while we are at process. MAINTAINERS clearly says:
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
IRQ SUBSYSTEM
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
So why are these patches not applying against that git branch?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH kernel v4 6/8] genirq/irqdomain: Move hierarchical IRQ cleanup to kobject_release
From: Thomas Gleixner @ 2020-11-30 23:13 UTC (permalink / raw)
To: Alexey Kardashevskiy, linux-kernel
Cc: Alexey Kardashevskiy, Marc Zyngier, x86, linux-gpio,
Oliver O'Halloran, Cédric Le Goater, Frederic Barrat,
Michal Suchánek, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201124061720.86766-7-aik@ozlabs.ru>
Alexey,
On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
> This moves hierarchical domain's irqs cleanup into the kobject release
> hook to make irq_domain_free_irqs() as simple as kobject_put.
Truly simple: Simply broken in multiple ways.
CONFIG_SPARSE_IRQ=n is now completely buggered. It does not even compile
anymore. Running core code changes through a larger set of cross
compilers is neither rocket science nor optional.
For CONFIG_SPARSE_IRQ=y, see below.
> @@ -1675,14 +1679,11 @@ void irq_domain_free_irqs(unsigned int virq, unsigned int nr_irqs)
> "NULL pointer, cannot free irq\n"))
> return;
>
> - mutex_lock(&irq_domain_mutex);
> - for (i = 0; i < nr_irqs; i++)
> - irq_domain_remove_irq(virq + i);
> - irq_domain_free_irqs_hierarchy(data->domain, virq, nr_irqs);
> - mutex_unlock(&irq_domain_mutex);
> + for (i = 0; i < nr_irqs; i++) {
> + struct irq_desc *desc = irq_to_desc(virq + i);
>
> - irq_domain_free_irq_data(virq, nr_irqs);
> - irq_free_descs(virq, nr_irqs);
> + kobject_put(&desc->kobj);
So up to this point both irq_dispose_mapping() _and_
irq_domain_free_irqs() invoked irq_free_descs().
Let's look at the call chains:
irq_domain_free_irqs()
irq_free_descs()
mutex_lock(&sparse_irq_lock);
for (i...)
free_desc(from + i)
irq_remove_debugfs_entry();
unregister_irq_proc();
irq_sysfs_del();
delete_irq_desc();
call_rcu();
bitmap_clear(allocated_irqs, ...);
mutex_unlock(&sparse_irq_lock);
with your modifications it does:
irq_domain_free_irqs()
for (i...)
kobject_put(&desc->kobj)
irq_kobj_release()
if (desc->free_irq)
desc->free_irq(desc);
irq_remove_debugfs_entry();
unregister_irq_proc();
delete_irq_desc();
call_rcu();
Can you spot the wreckage? It's not even subtle, it's more than obvious.
1) None of the operations in irq_kobj_release() is protected by
sparse_irq_lock anymore. There was a comment in free_desc() which
explained what is protected. You removed parts of that comment
and just left the sysfs portion of it above delete_irq_desc()
which is completely bogus because you removed the irq_sysfs_del()
call.
2) Nothing removes the freed interrupts from the allocation
bitmap. Run this often enough and you exhausted the interrupt
space.
And no, you cannot just go and invoke irq_free_descs() instead of
kobject_put(), simply because you'd create lock order inversion vs. the
free_irq() callback.
So no, it's not that simple and I'm not at all interested in another
respin of this with some more duct tape applied.
It can be done, but that needs way more thought, a proper design which
preserves the existing semantics completely and wants to be a fine
grained series where each patch does exactly ONE small thing which is
reviewable and testable on _ALL_ users of this code, i.e. _ALL_
architectures and irq chip implementations.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 5/5] powerpc/configs: drop unused BACKLIGHT_GENERIC option
From: Michael Ellerman @ 2020-12-01 0:46 UTC (permalink / raw)
To: Andrey Zhizhikin, linux, nicolas.ferre, alexandre.belloni,
ludovic.desroches, tony, mripard, wens, jernej.skrabec,
thierry.reding, jonathanh, catalin.marinas, will, tsbogend,
James.Bottomley, deller, benh, paulus, lee.jones, sam,
emil.l.velikov, daniel.thompson, krzk, linux-arm-kernel,
linux-kernel, linux-omap, linux-tegra, linux-mips, linux-parisc,
linuxppc-dev
In-Reply-To: <20201130152137.24909-6-andrey.zhizhikin@leica-geosystems.com>
Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com> writes:
> Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused") removed geenric_bl driver from the tree, together with
> corresponding config option.
>
> Remove BACKLIGHT_GENERIC config item from generic-64bit_defconfig.
^
powernv_defconfig
> Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is unused")
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
> ---
> arch/powerpc/configs/powernv_defconfig | 1 -
> 1 file changed, 1 deletion(-)
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
> diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
> index cf30fc24413b..60a30fffeda0 100644
> --- a/arch/powerpc/configs/powernv_defconfig
> +++ b/arch/powerpc/configs/powernv_defconfig
> @@ -208,7 +208,6 @@ CONFIG_FB_MATROX_G=y
> CONFIG_FB_RADEON=m
> CONFIG_FB_IBM_GXT4500=m
> CONFIG_LCD_PLATFORM=m
> -CONFIG_BACKLIGHT_GENERIC=m
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_LOGO=y
> CONFIG_HID_A4TECH=m
> --
> 2.17.1
^ permalink raw reply
* [PATCH v2] powerpc: Allow relative pointers in bug table entries
From: Jordan Niethe @ 2020-12-01 0:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe
This enables GENERIC_BUG_RELATIVE_POINTERS on Power so that 32-bit
offsets are stored in the bug entries rather than 64-bit pointers.
While this doesn't save space for 32-bit machines, use it anyway so
there is only one code path.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
v2: Remove non-relative pointers code
---
arch/powerpc/Kconfig | 4 ++++
arch/powerpc/include/asm/bug.h | 8 ++++----
arch/powerpc/xmon/xmon.c | 4 ++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e9f13fe08492..294108e0e5c6 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -311,6 +311,10 @@ config GENERIC_BUG
default y
depends on BUG
+config GENERIC_BUG_RELATIVE_POINTERS
+ def_bool y
+ depends on GENERIC_BUG
+
config SYS_SUPPORTS_APM_EMULATION
default y if PMAC_APM_EMU
bool
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 338f36cd9934..ba0500872cce 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -12,7 +12,7 @@
#ifdef CONFIG_DEBUG_BUGVERBOSE
.macro EMIT_BUG_ENTRY addr,file,line,flags
.section __bug_table,"aw"
-5001: PPC_LONG \addr, 5002f
+5001: .4byte \addr - 5001b, 5002f - 5001b
.short \line, \flags
.org 5001b+BUG_ENTRY_SIZE
.previous
@@ -23,7 +23,7 @@
#else
.macro EMIT_BUG_ENTRY addr,file,line,flags
.section __bug_table,"aw"
-5001: PPC_LONG \addr
+5001: .4byte \addr - 5001b
.short \flags
.org 5001b+BUG_ENTRY_SIZE
.previous
@@ -36,14 +36,14 @@
#ifdef CONFIG_DEBUG_BUGVERBOSE
#define _EMIT_BUG_ENTRY \
".section __bug_table,\"aw\"\n" \
- "2:\t" PPC_LONG "1b, %0\n" \
+ "2:\t.4byte 1b - 2b, %0 - 2b\n" \
"\t.short %1, %2\n" \
".org 2b+%3\n" \
".previous\n"
#else
#define _EMIT_BUG_ENTRY \
".section __bug_table,\"aw\"\n" \
- "2:\t" PPC_LONG "1b\n" \
+ "2:\t.4byte 1b - 2b\n" \
"\t.short %2\n" \
".org 2b+%3\n" \
".previous\n"
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 55c43a6c9111..9704c81aff7d 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1745,9 +1745,9 @@ static void print_bug_trap(struct pt_regs *regs)
#ifdef CONFIG_DEBUG_BUGVERBOSE
printf("kernel BUG at %s:%u!\n",
- bug->file, bug->line);
+ (char *)bug + bug->file_disp, bug->line);
#else
- printf("kernel BUG at %px!\n", (void *)bug->bug_addr);
+ printf("kernel BUG at %px!\n", (void *)bug + bug->bug_addr_disp);
#endif
#endif /* CONFIG_BUG */
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net v2 0/2] ibmvnic: Bug fixes for queue descriptor processing
From: Jakub Kicinski @ 2020-12-01 1:12 UTC (permalink / raw)
To: Thomas Falcon
Cc: cforno12, ljp, ricklind, dnbanerg, drt, netdev, brking, sukadev,
linuxppc-dev
In-Reply-To: <1606763244-28111-1-git-send-email-tlfalcon@linux.ibm.com>
On Mon, 30 Nov 2020 13:07:22 -0600 Thomas Falcon wrote:
> This series resolves a few issues in the ibmvnic driver's
> RX buffer and TX completion processing. The first patch
> includes memory barriers to synchronize queue descriptor
> reads. The second patch fixes a memory leak that could
> occur if the device returns a TX completion with an error
> code in the descriptor, in which case the respective socket
> buffer and other relevant data structures may not be freed
> or updated properly.
>
> v2: Provide more detailed comments explaining specifically what
> reads are being ordered, suggested by Michael Ellerman
The commit hashes on fixes tags need to be at least 12 characters long,
please fix and repost.
^ permalink raw reply
* Re: [RFC PATCH 01/14] ftrace: Fix updating FTRACE_FL_TRAMP
From: Steven Rostedt @ 2020-12-01 2:23 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <56c113aa9c3e10c19144a36d9684c7882bf09af5.1606412433.git.naveen.n.rao@linux.vnet.ibm.com>
On Thu, 26 Nov 2020 23:38:38 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> On powerpc, kprobe-direct.tc triggered FTRACE_WARN_ON() in
> ftrace_get_addr_new() followed by the below message:
> Bad trampoline accounting at: 000000004222522f (wake_up_process+0xc/0x20) (f0000001)
>
> The set of steps leading to this involved:
> - modprobe ftrace-direct-too
> - enable_probe
> - modprobe ftrace-direct
> - rmmod ftrace-direct <-- trigger
>
> The problem turned out to be that we were not updating flags in the
> ftrace record properly. From the above message about the trampoline
> accounting being bad, it can be seen that the ftrace record still has
> FTRACE_FL_TRAMP set though ftrace-direct module is going away. This
> happens because we are checking if any ftrace_ops has the
> FTRACE_FL_TRAMP flag set _before_ updating the filter hash.
>
> The fix for this is to look for any _other_ ftrace_ops that also needs
> FTRACE_FL_TRAMP.
I'm applying this now and sending this for -rc and stable.
The code worked on x86 because x86 has a way to make all users use
trampolines, so this was never an issue (everything has a trampoline).
I modified the kernel so that x86 would not create its own trampoline
(see the weak function arch_ftrace_update_trampoline(), and I was able
to reproduce the bug.
I'm adding:
Cc: stable@vger.kernel.org
Fixes: a124692b698b0 ("ftrace: Enable trampoline when rec count returns back to one")
Thanks!
-- Steve
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> kernel/trace/ftrace.c | 22 +++++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 8185f7240095f4..9c1bba8cc51b03 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1629,6 +1629,8 @@ static bool test_rec_ops_needs_regs(struct dyn_ftrace *rec)
> static struct ftrace_ops *
> ftrace_find_tramp_ops_any(struct dyn_ftrace *rec);
> static struct ftrace_ops *
> +ftrace_find_tramp_ops_any_other(struct dyn_ftrace *rec, struct ftrace_ops *op_exclude);
> +static struct ftrace_ops *
> ftrace_find_tramp_ops_next(struct dyn_ftrace *rec, struct ftrace_ops *ops);
>
> static bool __ftrace_hash_rec_update(struct ftrace_ops *ops,
> @@ -1778,7 +1780,7 @@ static bool __ftrace_hash_rec_update(struct ftrace_ops *ops,
> * to it.
> */
> if (ftrace_rec_count(rec) == 1 &&
> - ftrace_find_tramp_ops_any(rec))
> + ftrace_find_tramp_ops_any_other(rec, ops))
> rec->flags |= FTRACE_FL_TRAMP;
> else
> rec->flags &= ~FTRACE_FL_TRAMP;
> @@ -2244,6 +2246,24 @@ ftrace_find_tramp_ops_any(struct dyn_ftrace *rec)
> return NULL;
> }
>
> +static struct ftrace_ops *
> +ftrace_find_tramp_ops_any_other(struct dyn_ftrace *rec, struct ftrace_ops *op_exclude)
> +{
> + struct ftrace_ops *op;
> + unsigned long ip = rec->ip;
> +
> + do_for_each_ftrace_op(op, ftrace_ops_list) {
> +
> + if (op == op_exclude || !op->trampoline)
> + continue;
> +
> + if (hash_contains_ip(ip, op->func_hash))
> + return op;
> + } while_for_each_ftrace_op(op);
> +
> + return NULL;
> +}
> +
> static struct ftrace_ops *
> ftrace_find_tramp_ops_next(struct dyn_ftrace *rec,
> struct ftrace_ops *op)
^ permalink raw reply
* Re: [RFC PATCH 02/14] ftrace: Fix DYNAMIC_FTRACE_WITH_DIRECT_CALLS dependency
From: Steven Rostedt @ 2020-12-01 2:36 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fc4b257ea8689a36f086d2389a9ed989496ca63a.1606412433.git.naveen.n.rao@linux.vnet.ibm.com>
On Thu, 26 Nov 2020 23:38:39 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> DYNAMIC_FTRACE_WITH_DIRECT_CALLS should depend on
> DYNAMIC_FTRACE_WITH_REGS since we need ftrace_regs_caller().
>
> Fixes: 763e34e74bb7d5c ("ftrace: Add register_ftrace_direct()")
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
I'm pulling this in for stable as well.
-- Steve
> ---
> kernel/trace/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index a4020c0b4508c9..e1bf5228fb692a 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -202,7 +202,7 @@ config DYNAMIC_FTRACE_WITH_REGS
>
> config DYNAMIC_FTRACE_WITH_DIRECT_CALLS
> def_bool y
> - depends on DYNAMIC_FTRACE
> + depends on DYNAMIC_FTRACE_WITH_REGS
> depends on HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
>
> config FUNCTION_PROFILER
^ permalink raw reply
* Re: [RFC PATCH 03/14] ftrace: Fix cleanup in error path of register_ftrace_direct()
From: Steven Rostedt @ 2020-12-01 2:36 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <5a10d77b845633fbd13f1c3c71e7f9777bbbe601.1606412433.git.naveen.n.rao@linux.vnet.ibm.com>
On Thu, 26 Nov 2020 23:38:40 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> We need to remove hash entry if register_ftrace_function() fails.
> Consolidate the cleanup to be done after register_ftrace_function() at
> the end.
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> kernel/trace/ftrace.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 9c1bba8cc51b03..3844a4a1346a9c 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -5136,8 +5136,6 @@ int register_ftrace_direct(unsigned long ip, unsigned long addr)
> __add_hash_entry(direct_functions, entry);
>
> ret = ftrace_set_filter_ip(&direct_ops, ip, 0, 0);
> - if (ret)
> - remove_hash_entry(direct_functions, entry);
>
> if (!ret && !(direct_ops.flags & FTRACE_OPS_FL_ENABLED)) {
> ret = register_ftrace_function(&direct_ops);
> @@ -5146,6 +5144,7 @@ int register_ftrace_direct(unsigned long ip, unsigned long addr)
> }
>
> if (ret) {
> + remove_hash_entry(direct_functions, entry);
> kfree(entry);
> if (!direct->count) {
> list_del_rcu(&direct->next);
^ permalink raw reply
* Re: [PATCH v7 00/22] Kernel userspace access/execution prevention with hash translation
From: Aneesh Kumar K.V @ 2020-12-01 3:41 UTC (permalink / raw)
To: linuxppc-dev, mpe
In-Reply-To: <20201127044424.40686-1-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> This patch series implements KUAP and KUEP with hash translation mode using
> memory keys. The kernel now uses memory protection key 3 to control access
> to the kernel. Kernel page table entries are now configured with key 3.
> Access to locations configured with any other key value is denied when in
> kernel mode (MSR_PR=0). This includes userspace which is by default configured
> with key 0.
>
> null-syscall benchmark results:
>
> With smap/smep disabled:
> Without patch:
> 845.29 ns 2451.44 cycles
> With patch series:
> 858.38 ns 2489.30 cycles
>
> With smap/smep enabled:
> Without patch:
> NA
> With patch series:
> 1021.51 ns 2962.44 cycles
>
> Changes from v6:
> * Address review comments
> * Rename MMU FTR defines
>
> Changes from v5:
> * Rework the patch based on suggestion from Michael to avoid the
> usage of CONFIG_PPC_PKEY on BOOKE platforms.
>
> Changes from v4:
> * Repost with other pkey related changes split out as a separate series.
> * Improve null-syscall benchmark by optimizing SPRN save and restore.
>
> Changes from v3:
> * Fix build error reported by kernel test robot <lkp@intel.com>
>
> Changes from v2:
> * Rebase to the latest kernel.
> * Fixed a bug with disabling KUEP/KUAP on kernel command line
> * Added a patch to make kup key dynamic.
>
> Changes from V1:
> * Rebased on latest kernel
I disabled kernel debug config options based on request from Nick
Piggin. null_syscall benchmark numbers after that.
Full series/all patches applied
radix:
277.51 ns 1054.59 cycles
hash
348.24 ns 1323.32 cycles
hash nosmap nosmep
280.39 ns 1065.47 cycles
Patch 22 dropped (no optimization)
hash
341.87 ns 1326.64 cycles
hash nosmap nosmep
312.74 ns 1188.42 cycles
Without patches:
radix:
281.31 ns 1068.98 cycles
hash (same as below)
286.37 ns 1088.21 cycles
hash nosmap nosmep
286.44 ns 1088.46 cycles
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 78c312324391ee996944e1196123b0060888e189
From: kernel test robot @ 2020-12-01 4:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 78c312324391ee996944e1196123b0060888e189 Automatic merge of 'master' into merge (2020-11-30 12:10)
elapsed time: 723m
configs tested: 141
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm defconfig
arm allmodconfig
arm sama5_defconfig
sh espt_defconfig
sh edosk7705_defconfig
arm jornada720_defconfig
arm cm_x300_defconfig
mips ip27_defconfig
mips pic32mzda_defconfig
arm imx_v6_v7_defconfig
arm mvebu_v5_defconfig
s390 zfcpdump_defconfig
mips gcw0_defconfig
arm pxa255-idp_defconfig
arm multi_v7_defconfig
s390 debug_defconfig
powerpc ep88xc_defconfig
arm aspeed_g5_defconfig
arm mmp2_defconfig
sh secureedge5410_defconfig
arm lpc32xx_defconfig
arm clps711x_defconfig
arm corgi_defconfig
powerpc mpc834x_itxgp_defconfig
sh r7785rp_defconfig
powerpc sam440ep_defconfig
mips workpad_defconfig
arm gemini_defconfig
mips cu1000-neo_defconfig
ia64 generic_defconfig
powerpc kilauea_defconfig
powerpc adder875_defconfig
sh j2_defconfig
powerpc katmai_defconfig
arc tb10x_defconfig
m68k m5475evb_defconfig
powerpc asp8347_defconfig
arm palmz72_defconfig
h8300 defconfig
m68k stmark2_defconfig
m68k multi_defconfig
powerpc fsp2_defconfig
mips capcella_defconfig
powerpc ppc44x_defconfig
arm imote2_defconfig
h8300 h8s-sim_defconfig
powerpc bluestone_defconfig
powerpc lite5200b_defconfig
powerpc canyonlands_defconfig
m68k m5272c3_defconfig
powerpc ebony_defconfig
mips malta_kvm_defconfig
arm netwinder_defconfig
powerpc tqm8555_defconfig
mips nlm_xlp_defconfig
arm pxa_defconfig
powerpc xes_mpc85xx_defconfig
xtensa iss_defconfig
powerpc mpc7448_hpc2_defconfig
arm multi_v4t_defconfig
mips cu1830-neo_defconfig
arm colibri_pxa270_defconfig
powerpc stx_gp3_defconfig
arm simpad_defconfig
arm zx_defconfig
arm realview_defconfig
powerpc ppc6xx_defconfig
powerpc kmeter1_defconfig
mips maltasmvp_defconfig
m68k defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allyesconfig
m68k allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201130
i386 randconfig-a002-20201130
i386 randconfig-a003-20201130
i386 randconfig-a005-20201130
i386 randconfig-a006-20201130
i386 randconfig-a001-20201130
x86_64 randconfig-a014-20201130
x86_64 randconfig-a015-20201130
x86_64 randconfig-a016-20201130
x86_64 randconfig-a011-20201130
x86_64 randconfig-a012-20201130
x86_64 randconfig-a013-20201130
i386 randconfig-a013-20201130
i386 randconfig-a012-20201130
i386 randconfig-a011-20201130
i386 randconfig-a016-20201130
i386 randconfig-a015-20201130
i386 randconfig-a014-20201130
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20201130
x86_64 randconfig-a006-20201130
x86_64 randconfig-a005-20201130
x86_64 randconfig-a004-20201130
x86_64 randconfig-a001-20201130
x86_64 randconfig-a003-20201130
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 61fb396f48fcf49892b6801f2e98f40a413da1dc
From: kernel test robot @ 2020-12-01 4:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 61fb396f48fcf49892b6801f2e98f40a413da1dc powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
elapsed time: 723m
configs tested: 169
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm defconfig
arm allmodconfig
arm sama5_defconfig
sh espt_defconfig
sh edosk7705_defconfig
arm jornada720_defconfig
mips malta_kvm_defconfig
mips db1xxx_defconfig
powerpc mpc8560_ads_defconfig
arm milbeaut_m10v_defconfig
arm neponset_defconfig
sh ecovec24_defconfig
arm cm_x300_defconfig
mips ip27_defconfig
mips pic32mzda_defconfig
arm imx_v6_v7_defconfig
arm mvebu_v5_defconfig
powerpc maple_defconfig
xtensa xip_kc705_defconfig
sh apsh4a3a_defconfig
c6x dsk6455_defconfig
powerpc ppc64e_defconfig
openrisc simple_smp_defconfig
s390 zfcpdump_defconfig
mips gcw0_defconfig
arm pxa255-idp_defconfig
arm multi_v7_defconfig
s390 debug_defconfig
powerpc ep88xc_defconfig
arm aspeed_g5_defconfig
arm mmp2_defconfig
sh secureedge5410_defconfig
arm lpc32xx_defconfig
powerpc mpc5200_defconfig
mips tb0287_defconfig
arm mvebu_v7_defconfig
powerpc canyonlands_defconfig
mips gpr_defconfig
arc nsimosci_defconfig
arm clps711x_defconfig
arm corgi_defconfig
powerpc mpc834x_itxgp_defconfig
sh r7785rp_defconfig
powerpc sam440ep_defconfig
mips workpad_defconfig
arm gemini_defconfig
mips cu1000-neo_defconfig
ia64 generic_defconfig
powerpc kilauea_defconfig
powerpc adder875_defconfig
sh j2_defconfig
powerpc katmai_defconfig
arc tb10x_defconfig
sh polaris_defconfig
arm rpc_defconfig
x86_64 alldefconfig
arm h5000_defconfig
powerpc cell_defconfig
arm trizeps4_defconfig
mips fuloong2e_defconfig
m68k apollo_defconfig
arm spitz_defconfig
arm vf610m4_defconfig
arm lpd270_defconfig
nios2 10m50_defconfig
um x86_64_defconfig
powerpc skiroot_defconfig
powerpc mpc836x_mds_defconfig
powerpc fsp2_defconfig
mips capcella_defconfig
powerpc ppc44x_defconfig
arm imote2_defconfig
xtensa allyesconfig
h8300 h8s-sim_defconfig
powerpc bluestone_defconfig
powerpc lite5200b_defconfig
m68k m5272c3_defconfig
powerpc ebony_defconfig
arm netwinder_defconfig
powerpc tqm8555_defconfig
mips nlm_xlp_defconfig
powerpc motionpro_defconfig
mips allyesconfig
riscv defconfig
sh hp6xx_defconfig
sh lboxre2_defconfig
arm pxa_defconfig
powerpc xes_mpc85xx_defconfig
xtensa iss_defconfig
powerpc mpc7448_hpc2_defconfig
arm multi_v4t_defconfig
mips cu1830-neo_defconfig
arm colibri_pxa270_defconfig
powerpc stx_gp3_defconfig
arm simpad_defconfig
arm zx_defconfig
arm realview_defconfig
powerpc ppc6xx_defconfig
powerpc kmeter1_defconfig
mips maltasmvp_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201130
i386 randconfig-a002-20201130
i386 randconfig-a003-20201130
i386 randconfig-a005-20201130
i386 randconfig-a006-20201130
i386 randconfig-a001-20201130
x86_64 randconfig-a014-20201130
x86_64 randconfig-a015-20201130
x86_64 randconfig-a016-20201130
x86_64 randconfig-a011-20201130
x86_64 randconfig-a012-20201130
x86_64 randconfig-a013-20201130
i386 randconfig-a013-20201130
i386 randconfig-a012-20201130
i386 randconfig-a011-20201130
i386 randconfig-a016-20201130
i386 randconfig-a015-20201130
i386 randconfig-a014-20201130
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20201130
x86_64 randconfig-a006-20201130
x86_64 randconfig-a005-20201130
x86_64 randconfig-a004-20201130
x86_64 randconfig-a001-20201130
x86_64 randconfig-a003-20201130
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: CONFIG_PPC_VAS depends on 64k pages...?
From: Sukadev Bhattiprolu @ 2020-12-01 5:52 UTC (permalink / raw)
To: Christophe Leroy; +Cc: daniel, haren, linuxppc-dev, Will Springer, abali
In-Reply-To: <2b234a7e-e9f6-d02b-a20f-74c0cc1df8d3@csgroup.eu>
Christophe Leroy [christophe.leroy@csgroup.eu] wrote:
> Hi,
>
> Le 19/11/2020 à 11:58, Will Springer a écrit :
> > I learned about the POWER9 gzip accelerator a few months ago when the
> > support hit upstream Linux 5.8. However, for some reason the Kconfig
> > dictates that VAS depends on a 64k page size, which is problematic as I
> > run Void Linux, which uses a 4k-page kernel.
> >
> > Some early poking by others indicated there wasn't an obvious page size
> > dependency in the code, and suggested I try modifying the config to switch
> > it on. I did so, but was stopped by a minor complaint of an "unexpected DT
> > configuration" by the VAS code. I wasn't equipped to figure out exactly what
> > this meant, even after finding the offending condition, so after writing a
> > very drawn-out forum post asking for help, I dropped the subject.
> >
> > Fast forward to today, when I was reminded of the whole thing again, and
> > decided to debug a bit further. Apparently the VAS platform device
> > (derived from the DT node) has 5 resources on my 4k kernel, instead of 4
> > (which evidently works for others who have had success on 64k kernels). I
> > have no idea what this means in practice (I don't know how to introspect
> > it), but after making a tiny patch[1], everything came up smoothly and I
> > was doing blazing-fast gzip (de)compression in no time.
> >
> > Everything seems to work fine on 4k pages. So, what's up? Are there
> > pitfalls lurking around that I've yet to stumble over? More reasonably,
> > I'm curious as to why the feature supposedly depends on 64k pages, or if
> > there's anything else I should be concerned about.
Will,
The reason I put in that config check is because we were only able to
test 64K pages at that point.
It is interesting that it is working for you. Following code in skiboot
https://github.com/open-power/skiboot/blob/master/hw/vas.c should restrict
it to 64K pages. IIRC there is also a corresponding change in some NX
registers that should also be configured to allow 4K pages.
static int init_north_ctl(struct proc_chip *chip)
{
uint64_t val = 0ULL;
val = SETFIELD(VAS_64K_MODE_MASK, val, true);
val = SETFIELD(VAS_ACCEPT_PASTE_MASK, val, true);
val = SETFIELD(VAS_ENABLE_WC_MMIO_BAR, val, true);
val = SETFIELD(VAS_ENABLE_UWC_MMIO_BAR, val, true);
val = SETFIELD(VAS_ENABLE_RMA_MMIO_BAR, val, true);
return vas_scom_write(chip, VAS_MISC_N_CTL, val);
}
I am copying Bulent Albali and Haren Myneni who have been working with
VAS/NX for their thoughts/experience.
> >
>
> Maybe ask Sukadev who did the implementation and is maintaining it ?
>
> > I do have to say I'm quite satisfied with the results of the NX
> > accelerator, though. Being able to shuffle data to a RaptorCS box over gigE
> > and get compressed data back faster than most software gzip could ever
> > hope to achieve is no small feat, let alone the instantaneous results locally.
> > :)
> >
> > Cheers,
> > Will Springer [she/her]
> >
> > [1]: https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch
> >
>
>
> Christophe
^ permalink raw reply
* Re: [PATCH v2] powerpc: Allow relative pointers in bug table entries
From: Christophe Leroy @ 2020-12-01 6:25 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20201201005203.15210-1-jniethe5@gmail.com>
Le 01/12/2020 à 01:52, Jordan Niethe a écrit :
> This enables GENERIC_BUG_RELATIVE_POINTERS on Power so that 32-bit
> offsets are stored in the bug entries rather than 64-bit pointers.
> While this doesn't save space for 32-bit machines, use it anyway so
> there is only one code path.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> # on PPC32
> ---
> v2: Remove non-relative pointers code
> ---
> arch/powerpc/Kconfig | 4 ++++
> arch/powerpc/include/asm/bug.h | 8 ++++----
> arch/powerpc/xmon/xmon.c | 4 ++--
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index e9f13fe08492..294108e0e5c6 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -311,6 +311,10 @@ config GENERIC_BUG
> default y
> depends on BUG
>
> +config GENERIC_BUG_RELATIVE_POINTERS
> + def_bool y
> + depends on GENERIC_BUG
> +
> config SYS_SUPPORTS_APM_EMULATION
> default y if PMAC_APM_EMU
> bool
> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
> index 338f36cd9934..ba0500872cce 100644
> --- a/arch/powerpc/include/asm/bug.h
> +++ b/arch/powerpc/include/asm/bug.h
> @@ -12,7 +12,7 @@
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> .macro EMIT_BUG_ENTRY addr,file,line,flags
> .section __bug_table,"aw"
> -5001: PPC_LONG \addr, 5002f
> +5001: .4byte \addr - 5001b, 5002f - 5001b
> .short \line, \flags
> .org 5001b+BUG_ENTRY_SIZE
> .previous
> @@ -23,7 +23,7 @@
> #else
> .macro EMIT_BUG_ENTRY addr,file,line,flags
> .section __bug_table,"aw"
> -5001: PPC_LONG \addr
> +5001: .4byte \addr - 5001b
> .short \flags
> .org 5001b+BUG_ENTRY_SIZE
> .previous
> @@ -36,14 +36,14 @@
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> #define _EMIT_BUG_ENTRY \
> ".section __bug_table,\"aw\"\n" \
> - "2:\t" PPC_LONG "1b, %0\n" \
> + "2:\t.4byte 1b - 2b, %0 - 2b\n" \
> "\t.short %1, %2\n" \
> ".org 2b+%3\n" \
> ".previous\n"
> #else
> #define _EMIT_BUG_ENTRY \
> ".section __bug_table,\"aw\"\n" \
> - "2:\t" PPC_LONG "1b\n" \
> + "2:\t.4byte 1b - 2b\n" \
> "\t.short %2\n" \
> ".org 2b+%3\n" \
> ".previous\n"
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 55c43a6c9111..9704c81aff7d 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -1745,9 +1745,9 @@ static void print_bug_trap(struct pt_regs *regs)
>
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> printf("kernel BUG at %s:%u!\n",
> - bug->file, bug->line);
> + (char *)bug + bug->file_disp, bug->line);
> #else
> - printf("kernel BUG at %px!\n", (void *)bug->bug_addr);
> + printf("kernel BUG at %px!\n", (void *)bug + bug->bug_addr_disp);
> #endif
> #endif /* CONFIG_BUG */
> }
>
^ permalink raw reply
* [PATCH kernel v2] powerpc/pci: Remove LSI mappings on device teardown
From: Alexey Kardashevskiy @ 2020-12-01 7:39 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Frederic Barrat, Oliver O'Halloran,
Cédric Le Goater
From: Oliver O'Halloran <oohall@gmail.com>
When a passthrough IO adapter is removed from a pseries machine using hash
MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS
to clear all page table entries related to the adapter. If some are still
present, the RTAS call which isolates the PCI slot returns error 9001
"valid outstanding translations" and the removal of the IO adapter fails.
This is because when the PHBs are scanned, Linux maps automatically the
INTx interrupts in the Linux interrupt number space but these are never
removed.
This problem can be fixed by adding the corresponding unmap operation when
the device is removed. There's no pcibios_* hook for the remove case, but
the same effect can be achieved using a bus notifier.
Because INTx are shared among PHBs (and potentially across the system),
this adds tracking of virq to unmap them only when the last user is gone.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
[aik: added refcounter]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Doing this in the generic irq code is just too much for my small brain :-/
---
arch/powerpc/kernel/pci-common.c | 71 ++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index be108616a721..0acf17f17253 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,6 +353,55 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
return NULL;
}
+struct pci_intx_virq {
+ int virq;
+ struct kref kref;
+ struct list_head list_node;
+};
+
+static LIST_HEAD(intx_list);
+static DEFINE_MUTEX(intx_mutex);
+
+static void ppc_pci_intx_release(struct kref *kref)
+{
+ struct pci_intx_virq *vi = container_of(kref, struct pci_intx_virq, kref);
+
+ list_del(&vi->list_node);
+ irq_dispose_mapping(vi->virq);
+ kfree(vi);
+}
+
+static int ppc_pci_unmap_irq_line(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct pci_dev *pdev = to_pci_dev(data);
+
+ if (action == BUS_NOTIFY_DEL_DEVICE) {
+ struct pci_intx_virq *vi;
+
+ mutex_lock(&intx_mutex);
+ list_for_each_entry(vi, &intx_list, list_node) {
+ if (vi->virq == pdev->irq) {
+ kref_put(&vi->kref, ppc_pci_intx_release);
+ break;
+ }
+ }
+ mutex_unlock(&intx_mutex);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_pci_unmap_irq_notifier = {
+ .notifier_call = ppc_pci_unmap_irq_line,
+};
+
+static int ppc_pci_register_irq_notifier(void)
+{
+ return bus_register_notifier(&pci_bus_type, &ppc_pci_unmap_irq_notifier);
+}
+arch_initcall(ppc_pci_register_irq_notifier);
+
/*
* Reads the interrupt pin to determine if interrupt is use by card.
* If the interrupt is used, then gets the interrupt line from the
@@ -361,6 +410,12 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
static int pci_read_irq_line(struct pci_dev *pci_dev)
{
int virq;
+ struct pci_intx_virq *vi, *vitmp;
+
+ /* Preallocate vi as rewind is complex if this fails after mapping */
+ vi = kzalloc(sizeof(struct pci_intx_virq), GFP_KERNEL);
+ if (!vi)
+ return -1;
pr_debug("PCI: Try to map irq for %s...\n", pci_name(pci_dev));
@@ -401,6 +456,22 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
pci_dev->irq = virq;
+ mutex_lock(&intx_mutex);
+ list_for_each_entry(vitmp, &intx_list, list_node) {
+ if (vitmp->virq == virq) {
+ kref_get(&vitmp->kref);
+ kfree(vi);
+ vi = NULL;
+ break;
+ }
+ }
+ if (vi) {
+ vi->virq = virq;
+ kref_init(&vi->kref);
+ list_add_tail(&vi->list_node, &intx_list);
+ }
+ mutex_unlock(&intx_mutex);
+
return 0;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] selftests/powerpc: Fix uninitialized variable warning
From: Harish @ 2020-12-01 9:24 UTC (permalink / raw)
To: mpe; +Cc: Harish, linuxppc-dev
Patch fixes uninitialized variable warning in bad_accesses test
which causes the selftests build to fail in older distibutions
bad_accesses.c: In function ‘bad_access’:
bad_accesses.c:52:9: error: ‘x’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
printf("Bad - no SEGV! (%c)\n", x);
^
cc1: all warnings being treated as errors
Signed-off-by: Harish <harish@linux.ibm.com>
---
tools/testing/selftests/powerpc/mm/bad_accesses.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/mm/bad_accesses.c b/tools/testing/selftests/powerpc/mm/bad_accesses.c
index fd747b2ffcfc..65d2148b05dc 100644
--- a/tools/testing/selftests/powerpc/mm/bad_accesses.c
+++ b/tools/testing/selftests/powerpc/mm/bad_accesses.c
@@ -38,7 +38,7 @@ static void segv_handler(int n, siginfo_t *info, void *ctxt_v)
int bad_access(char *p, bool write)
{
- char x;
+ char x = 0;
fault_code = 0;
fault_addr = 0;
--
2.26.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox