Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps

On Tue, Jan 16, 2018 at 6:28 PM, Thomas Hellstrom wrote: > Hi, Arnd, > > Sinclair's on paternal leave and I thought this patch was already in > drm-next. My bad. No worries. > Dave, is it too late to pull this in for the next merge window? The patch isn't urgent, it's

Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps

On Tue, Jan 16, 2018 at 6:28 PM, Thomas Hellstrom wrote: > Hi, Arnd, > > Sinclair's on paternal leave and I thought this patch was already in > drm-next. My bad. No worries. > Dave, is it too late to pull this in for the next merge window? The patch isn't urgent, it's fine to wait until after

[PATCH] [v4] media: s3c-camif: fix out-of-bounds array access

While experimenting with older compiler versions, I ran into a warning that no longer shows up on gcc-4.8 or newer: drivers/media/platform/s3c-camif/camif-capture.c: In function '__camif_subdev_try_format': drivers/media/platform/s3c-camif/camif-capture.c:1265:25: error: array subscript is

[PATCH] [v4] media: s3c-camif: fix out-of-bounds array access

While experimenting with older compiler versions, I ran into a warning that no longer shows up on gcc-4.8 or newer: drivers/media/platform/s3c-camif/camif-capture.c: In function '__camif_subdev_try_format': drivers/media/platform/s3c-camif/camif-capture.c:1265:25: error: array subscript is

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 01:30:19PM -0800, Luck, Tony wrote: > I could get you a list of model numbers that you can check against > model_name. Yeah, we're not doing that again. :) > But that seems way worse. Especially as the 2.5MB thing is what is > called out in the erratum. Oh well. Thx.

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 01:30:19PM -0800, Luck, Tony wrote: > I could get you a list of model numbers that you can check against > model_name. Yeah, we're not doing that again. :) > But that seems way worse. Especially as the 2.5MB thing is what is > called out in the erratum. Oh well. Thx.

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: [PATCH] ACPI/PCI: pci_link: reduce verbosity when IRQ is enabled

On Tue, Jan 16, 2018 at 01:53:00PM -0500, Sinan Kaya wrote: > Correcting linux-pci email. > > On 1/16/2018 1:51 PM, Sinan Kaya wrote: > > When ACPI Link object is enabled, the message is printed with a warning > > prefix. Some test tools are capturing warning and test error types as > > errors.

Re: [PATCH] ACPI/PCI: pci_link: reduce verbosity when IRQ is enabled

On Tue, Jan 16, 2018 at 01:53:00PM -0500, Sinan Kaya wrote: > Correcting linux-pci email. > > On 1/16/2018 1:51 PM, Sinan Kaya wrote: > > When ACPI Link object is enabled, the message is printed with a warning > > prefix. Some test tools are capturing warning and test error types as > > errors.

[PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

Remove soc_camera framework dependencies from ov772x sensor driver. - Handle clock and gpios - Register async subdevice - Remove soc_camera specific g/s_mbus_config operations - Change image format colorspace from JPEG to SRGB as the two use the same colorspace information but JPEG makes

[PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

Remove soc_camera framework dependencies from ov772x sensor driver. - Handle clock and gpios - Register async subdevice - Remove soc_camera specific g/s_mbus_config operations - Change image format colorspace from JPEG to SRGB as the two use the same colorspace information but JPEG makes

[REGRESSION] mux/gpio.c is not able to get any gpio pins

Hi! I have found that the drivers/mux/gpio.c driver fails to get the required gpio pins when I test with next-20180116. The driver calls devm_gpiod_get_array() during probe and that request returns -EPROBE_DEFER in three probes long after the pinctrl driver has been registered (verified

[REGRESSION] mux/gpio.c is not able to get any gpio pins

Hi! I have found that the drivers/mux/gpio.c driver fails to get the required gpio pins when I test with next-20180116. The driver calls devm_gpiod_get_array() during probe and that request returns -EPROBE_DEFER in three probes long after the pinctrl driver has been registered (verified

Re: [PATCH] [v3] media: s3c-camif: fix out-of-bounds array access

On Tue, Jan 16, 2018 at 9:17 PM, Laurent Pinchart wrote: > Hi Arnd, > > Thank you for the patch. > > On Tuesday, 16 January 2018 18:47:24 EET Arnd Bergmann wrote: >> While experimenting with older compiler versions, I ran >> into a warning that no longer shows

Re: [PATCH] [v3] media: s3c-camif: fix out-of-bounds array access

On Tue, Jan 16, 2018 at 9:17 PM, Laurent Pinchart wrote: > Hi Arnd, > > Thank you for the patch. > > On Tuesday, 16 January 2018 18:47:24 EET Arnd Bergmann wrote: >> While experimenting with older compiler versions, I ran >> into a warning that no longer shows up on gcc-4.8 or newer: >> >>

[PATCH v6 8/9] media: i2c: tw9910: Remove soc_camera dependencies

Remove soc_camera framework dependencies from tw9910 sensor driver. - Handle clock and gpios - Register async subdevice - Remove soc_camera specific g/s_mbus_config operations - Add kernel doc to driver interface header file - Adjust build system This commit does not remove the original

[PATCH v6 8/9] media: i2c: tw9910: Remove soc_camera dependencies

Remove soc_camera framework dependencies from tw9910 sensor driver. - Handle clock and gpios - Register async subdevice - Remove soc_camera specific g/s_mbus_config operations - Add kernel doc to driver interface header file - Adjust build system This commit does not remove the original

[PATCH v6 9/9] arch: sh: migor: Use new renesas-ceu camera driver

Migo-R platform uses sh_mobile_ceu camera driver, which is now being replaced by a proper V4L2 camera driver named 'renesas-ceu'. Move Migo-R platform to use the v4l2 renesas-ceu camera driver interface and get rid of soc_camera defined components used to register sensor drivers and of platform

[PATCH v6 7/9] v4l: i2c: Copy tw9910 soc_camera sensor driver

Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi

Re: [PATCH v16 00/10] Add backlight helper functions

On Tue, Jan 16, 2018 at 10:31:07AM +, Meghana Madhyastha wrote: > Move drm helper functions from tinydrm-helpers to linux/backlight for > ease of use by callers in other drivers. > > Changes in v16: > -Add a comment about setting brightness = max_brightness in of_find_backlight > -Add

[PATCH v6 9/9] arch: sh: migor: Use new renesas-ceu camera driver

Migo-R platform uses sh_mobile_ceu camera driver, which is now being replaced by a proper V4L2 camera driver named 'renesas-ceu'. Move Migo-R platform to use the v4l2 renesas-ceu camera driver interface and get rid of soc_camera defined components used to register sensor drivers and of platform

[PATCH v6 7/9] v4l: i2c: Copy tw9910 soc_camera sensor driver

Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi Acked-by: Laurent

Re: [PATCH v16 00/10] Add backlight helper functions

On Tue, Jan 16, 2018 at 10:31:07AM +, Meghana Madhyastha wrote: > Move drm helper functions from tinydrm-helpers to linux/backlight for > ease of use by callers in other drivers. > > Changes in v16: > -Add a comment about setting brightness = max_brightness in of_find_backlight > -Add

[PATCH v6 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

Add Capture Engine Unit (CEU) node to device tree. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil ---

[PATCH v6 1/9] dt-bindings: media: Add Renesas CEU bindings

Add bindings documentation for Renesas Capture Engine Unit (CEU). Signed-off-by: Jacopo Mondi Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil ---

[PATCH v6 5/9] v4l: i2c: Copy ov772x soc_camera sensor driver

Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi

[PATCH v6 2/9] include: media: Add Renesas CEU driver interface

Add renesas-ceu header file. Do not remove the existing sh_mobile_ceu.h one as long as the original driver does not go away. Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil

[PATCH v6 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

Add Capture Engine Unit (CEU) node to device tree. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil --- arch/arm/boot/dts/r7s72100.dtsi | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git

[PATCH v6 1/9] dt-bindings: media: Add Renesas CEU bindings

Add bindings documentation for Renesas Capture Engine Unit (CEU). Signed-off-by: Jacopo Mondi Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil --- .../devicetree/bindings/media/renesas,ceu.txt | 81 ++ 1 file changed, 81 insertions(+)

[PATCH v6 5/9] v4l: i2c: Copy ov772x soc_camera sensor driver

Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi Acked-by: Laurent

[PATCH v6 2/9] include: media: Add Renesas CEU driver interface

Add renesas-ceu header file. Do not remove the existing sh_mobile_ceu.h one as long as the original driver does not go away. Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil --- include/media/drv-intf/renesas-ceu.h | 26 ++ 1 file

[PATCH v6 3/9] v4l: platform: Add Renesas CEU driver

Add driver for Renesas Capture Engine Unit (CEU). The CEU interface supports capturing 'data' (YUV422) and 'images' (NV[12|21|16|61]). This driver aims to replace the soc_camera-based sh_mobile_ceu one. Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ platform GR-Peach.

[PATCH v6 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

Hello, new version of CEU after Hans' review. Added his Acked-by to most patches and closed review comments. Running v4l2-compliance, I noticed a new failure introduced by the way I now calculate the plane sizes in set/try_fmt. This is the function used to update per-plane bytesperline and

[PATCH v6 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

Hello, new version of CEU after Hans' review. Added his Acked-by to most patches and closed review comments. Running v4l2-compliance, I noticed a new failure introduced by the way I now calculate the plane sizes in set/try_fmt. This is the function used to update per-plane bytesperline and

[PATCH v6 3/9] v4l: platform: Add Renesas CEU driver

Add driver for Renesas Capture Engine Unit (CEU). The CEU interface supports capturing 'data' (YUV422) and 'images' (NV[12|21|16|61]). This driver aims to replace the soc_camera-based sh_mobile_ceu one. Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ platform GR-Peach.

[RFT 3/3] arm64: dts: exynos: Fix missing missing reg warning for syscon restart nodes

Fix DTC warnings like: arch/arm64/boot/dts/exynos/exynos7-espresso.dtb: Warning (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges property by moving the syscon restart node into the PMU (Power Management Unit) node. The PMU node is the actual block responsible

[RFT 3/3] arm64: dts: exynos: Fix missing missing reg warning for syscon restart nodes

Fix DTC warnings like: arch/arm64/boot/dts/exynos/exynos7-espresso.dtb: Warning (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges property by moving the syscon restart node into the PMU (Power Management Unit) node. The PMU node is the actual block responsible

[PATCH 2/3] ARM: dts: exynos: Fix missing missing reg warning for syscon restart nodes

Fix DTC warnings like: arch/arm/boot/dts/exynos4412-trats2.dtb: Warning (simple_bus_reg): Node /soc/syscon-poweroff missing or empty reg/ranges property arch/arm/boot/dts/exynos4412-trats2.dtb: Warning (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges

[PATCH 1/3] ARM: dts: exynos: Remove duplicated inclusion of syscon restart nodes on Exynos5410

The exynos-syscon-restart.dtsi is already included by exynos5.dtsi (through exynos54xx.dtsi). Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos5410.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5410.dtsi

[PATCH 2/3] ARM: dts: exynos: Fix missing missing reg warning for syscon restart nodes

Fix DTC warnings like: arch/arm/boot/dts/exynos4412-trats2.dtb: Warning (simple_bus_reg): Node /soc/syscon-poweroff missing or empty reg/ranges property arch/arm/boot/dts/exynos4412-trats2.dtb: Warning (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges

[PATCH 1/3] ARM: dts: exynos: Remove duplicated inclusion of syscon restart nodes on Exynos5410

The exynos-syscon-restart.dtsi is already included by exynos5.dtsi (through exynos54xx.dtsi). Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos5410.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi index

Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps

Thomas Hellstrom wrote: Hi, Arnd, Sinclair's on paternal leave and I thought this patch was already in drm-next. My bad. Dave, is it too late to pull this in for the next merge window? /Thomas On 01/16/2018 06:18 PM, Arnd Bergmann wrote: DRM_VMW_EVENT_FENCE_SIGNALED (struct

Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps

Thomas Hellstrom wrote: Hi, Arnd, Sinclair's on paternal leave and I thought this patch was already in drm-next. My bad. Dave, is it too late to pull this in for the next merge window? /Thomas On 01/16/2018 06:18 PM, Arnd Bergmann wrote: DRM_VMW_EVENT_FENCE_SIGNALED (struct

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

On Tue, Jan 16, 2018 at 09:19:13PM +, Marc Zyngier wrote: > > I understand that it should take care of the condition field as > > a general instruction handler. Just for curiosity: If we confine > > the topic to read access of CNTVCT/CNTFRQ, what'd be the penalty > > by ignoring the condition

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

On Tue, Jan 16, 2018 at 09:19:13PM +, Marc Zyngier wrote: > > I understand that it should take care of the condition field as > > a general instruction handler. Just for curiosity: If we confine > > the topic to read access of CNTVCT/CNTFRQ, what'd be the penalty > > by ignoring the condition

Re: [PATCH v13 0/7] cgroup-aware OOM killer

On Mon, 15 Jan 2018, Michal Hocko wrote: > > No, this isn't how kernel features get introduced. We don't design a new > > kernel feature with its own API for a highly specialized usecase and then > > claim we'll fix the problems later. Users will work around the > > constraints of the new

Re: [PATCH v13 0/7] cgroup-aware OOM killer

On Mon, 15 Jan 2018, Michal Hocko wrote: > > No, this isn't how kernel features get introduced. We don't design a new > > kernel feature with its own API for a highly specialized usecase and then > > claim we'll fix the problems later. Users will work around the > > constraints of the new

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 09:50:37PM +0100, Borislav Petkov wrote: > ... and there's not a more reliable way to detect those like platform ID > or so? Because if for anywhere, this is where one *should* use platform > ID. > > Or perhaps some other bit somewhere instead of this cache size thing? I

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 09:50:37PM +0100, Borislav Petkov wrote: > ... and there's not a more reliable way to detect those like platform ID > or so? Because if for anywhere, this is where one *should* use platform > ID. > > Or perhaps some other bit somewhere instead of this cache size thing? I

Re: [PATCH] lightnvm/pblk-gc: Delete an error message for a failed memory allocation in pblk_gc_line_prepare_ws()

On 01/16/2018 10:10 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Tue, 16 Jan 2018 22:00:15 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus

Re: [PATCH] lightnvm/pblk-gc: Delete an error message for a failed memory allocation in pblk_gc_line_prepare_ws()

On 01/16/2018 10:10 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Tue, 16 Jan 2018 22:00:15 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [PATCH v6 02/12] drivers: base: cacheinfo: setup DT cache properties early

Hi, On 01/15/2018 10:07 AM, Palmer Dabbelt wrote: On Mon, 15 Jan 2018 04:33:38 PST (-0800), sudeep.ho...@arm.com wrote: On Fri, Jan 12, 2018 at 06:59:10PM -0600, Jeremy Linton wrote: The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the

Re: [PATCH v6 02/12] drivers: base: cacheinfo: setup DT cache properties early

Hi, On 01/15/2018 10:07 AM, Palmer Dabbelt wrote: On Mon, 15 Jan 2018 04:33:38 PST (-0800), sudeep.ho...@arm.com wrote: On Fri, Jan 12, 2018 at 06:59:10PM -0600, Jeremy Linton wrote: The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the

Re: [PATCH] mm: numa: Do not trap faults on shared data section pages.

On Tue, Jan 16, 2018 at 11:28:44AM -0800, Henry Willard wrote: > Workloads consisting of a large number processes running the same program > with a large shared data section may suffer from excessive numa balancing > page migration of the pages in the shared data section. This shows up as > high

Re: [PATCH v4 00/17] ASoC: fsl_ssi: Clean up - program flow level

On Mon, Jan 15, 2018 at 3:16 PM, Nicolin Chen wrote: > ==Change log== > v4 > * Reworked the series by taking suggestions from Maciej > + Added TXBIT0 bit back to play safe in PATCH-14 > + Made bool synchronous exclusive with AC97 mode in PATCH-16 > v3 > * Reworked

Re: [PATCH] mm: numa: Do not trap faults on shared data section pages.

On Tue, Jan 16, 2018 at 11:28:44AM -0800, Henry Willard wrote: > Workloads consisting of a large number processes running the same program > with a large shared data section may suffer from excessive numa balancing > page migration of the pages in the shared data section. This shows up as > high

Re: [PATCH v4 00/17] ASoC: fsl_ssi: Clean up - program flow level

On Mon, Jan 15, 2018 at 3:16 PM, Nicolin Chen wrote: > ==Change log== > v4 > * Reworked the series by taking suggestions from Maciej > + Added TXBIT0 bit back to play safe in PATCH-14 > + Made bool synchronous exclusive with AC97 mode in PATCH-16 > v3 > * Reworked the series by taking

Re: [PATCH v3] retpoline: Add retpoline tag to VERMAGIC

On Tue, 16 Jan 2018, Andi Kleen wrote: > From: Andi Kleen > > Add a marker for retpoline to the module VERMAGIC. This catches > the case when a non RETPOLINE compiled module gets loaded into > a retpoline kernel, making it insecure. > > It doesn't handle the case when

Re: [PATCH v3] retpoline: Add retpoline tag to VERMAGIC

On Tue, 16 Jan 2018, Andi Kleen wrote: > From: Andi Kleen > > Add a marker for retpoline to the module VERMAGIC. This catches > the case when a non RETPOLINE compiled module gets loaded into > a retpoline kernel, making it insecure. > > It doesn't handle the case when retpoline has been

Re: [PATCH v2] retpoline/module: Warn for missing retpoline in module

On Tue, 16 Jan 2018, Andi Kleen wrote: > Thanks. > > I just sent a v3 that changes the VERMAGIC only, based on Greg's > earlier feedback. > > It has the drawbacks that it: > - refuses loading instead of warns > - doesn't stop refusing when the feature is runtime disabled > > But it's much

Re: [PATCH v2] retpoline/module: Warn for missing retpoline in module

On Tue, 16 Jan 2018, Andi Kleen wrote: > Thanks. > > I just sent a v3 that changes the VERMAGIC only, based on Greg's > earlier feedback. > > It has the drawbacks that it: > - refuses loading instead of warns > - doesn't stop refusing when the feature is runtime disabled > > But it's much

Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver

Hi Tony, On 01/16/2018 09:03 AM, Tony Lindgren wrote: > Hi, > > * Philipp Zabel [180116 09:52]: >> On Mon, 2018-01-15 at 17:11 -0800, Tony Lindgren wrote: >>> +Example: >>> + >>> + prcm: prcm@20 { >>> + compatible = "ti,am3-prcm", "simple-bus"; >>> +

Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver

Hi Tony, On 01/16/2018 09:03 AM, Tony Lindgren wrote: > Hi, > > * Philipp Zabel [180116 09:52]: >> On Mon, 2018-01-15 at 17:11 -0800, Tony Lindgren wrote: >>> +Example: >>> + >>> + prcm: prcm@20 { >>> + compatible = "ti,am3-prcm", "simple-bus"; >>> + reg = <0x20

Re: [PATCH v13 0/7] cgroup-aware OOM killer

On Mon, 15 Jan 2018, Johannes Weiner wrote: > > It's quite trivial to allow the root mem cgroup to be compared exactly the > > same as another cgroup. Please see > > https://marc.info/?l=linux-kernel=151579459920305. > > This only says "that will be fixed" and doesn't address why I care. >

Re: [PATCH v13 0/7] cgroup-aware OOM killer

On Mon, 15 Jan 2018, Johannes Weiner wrote: > > It's quite trivial to allow the root mem cgroup to be compared exactly the > > same as another cgroup. Please see > > https://marc.info/?l=linux-kernel=151579459920305. > > This only says "that will be fixed" and doesn't address why I care. >

Re: [RFC PATCH 00/16] PTI support for x86-32

On Tue, 16 Jan 2018, Joerg Roedel wrote: > here is my current WIP code to enable PTI on x86-32. It is > still in a pretty early state, but it successfully boots my > KVM guest with PAE and with legacy paging. The existing PTI > code for x86-64 already prepares a lot of the stuff needed > for 32

Re: [RFC PATCH 00/16] PTI support for x86-32

On Tue, 16 Jan 2018, Joerg Roedel wrote: > here is my current WIP code to enable PTI on x86-32. It is > still in a pretty early state, but it successfully boots my > KVM guest with PAE and with legacy paging. The existing PTI > code for x86-64 already prepares a lot of the stuff needed > for 32

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

On Tue, 16 Jan 2018 20:32:19 +, Nicolin Chen wrote: > > Hello Marc, > > On Thu, Jan 11, 2018 at 08:51:37AM +, Marc Zyngier wrote: > > > [ I also added cntfrq here for safety as theoretically it could > > > trigger the trap as well. However, my another test case (with > > > mrc

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

On Tue, 16 Jan 2018 20:32:19 +, Nicolin Chen wrote: > > Hello Marc, > > On Thu, Jan 11, 2018 at 08:51:37AM +, Marc Zyngier wrote: > > > [ I also added cntfrq here for safety as theoretically it could > > > trigger the trap as well. However, my another test case (with > > > mrc

Re: [PATCH 12/16] x86/mm/pae: Populate the user page-table with user pgd's

On 01/16/2018 01:10 PM, Thomas Gleixner wrote: > > static inline pteval_t supported_pgd_mask(void) > { > if (IS_ENABLED(CONFIG_X86_64)) > return __supported_pte_mask; > return __supported_pte_mask & ~_PAGE_NX); > } > > and get rid of the ifdeffery completely. Heh,

Re: [PATCH 12/16] x86/mm/pae: Populate the user page-table with user pgd's

On 01/16/2018 01:10 PM, Thomas Gleixner wrote: > > static inline pteval_t supported_pgd_mask(void) > { > if (IS_ENABLED(CONFIG_X86_64)) > return __supported_pte_mask; > return __supported_pte_mask & ~_PAGE_NX); > } > > and get rid of the ifdeffery completely. Heh,

Re: [PATCH 3/4] tty: Iterate only thread group leaders in __do_SAK()

On 01/16, Kirill Tkhai wrote: > > On 15.01.2018 23:51, Oleg Nesterov wrote: > > > >> kill: > >> - force_sig(SIGKILL, p); > >> + send_sig(SIGKILL, p, 1); > > > > Agreed, I didn't actually want to use force_sig(SIGKILL), copy-and-paste > > error. > > force_sig() is still safe

Re: [PATCH 3/4] tty: Iterate only thread group leaders in __do_SAK()

On 01/16, Kirill Tkhai wrote: > > On 15.01.2018 23:51, Oleg Nesterov wrote: > > > >> kill: > >> - force_sig(SIGKILL, p); > >> + send_sig(SIGKILL, p, 1); > > > > Agreed, I didn't actually want to use force_sig(SIGKILL), copy-and-paste > > error. > > force_sig() is still safe

RE: [PATCH v2] retpoline/module: Warn for missing retpoline in module

> I just sent a v3 that changes the VERMAGIC only, based on Greg's > earlier feedback. > > It has the drawbacks that it: > - refuses loading instead of warns > - doesn't stop refusing when the feature is runtime disabled > > But it's much simpler, just a few lines of ifdef. I think simple is

RE: [PATCH v2] retpoline/module: Warn for missing retpoline in module

> I just sent a v3 that changes the VERMAGIC only, based on Greg's > earlier feedback. > > It has the drawbacks that it: > - refuses loading instead of warns > - doesn't stop refusing when the feature is runtime disabled > > But it's much simpler, just a few lines of ifdef. I think simple is

Re: [PATCH 12/16] x86/mm/pae: Populate the user page-table with user pgd's

On Tue, 16 Jan 2018, Joerg Roedel wrote: > > +#ifdef CONFIG_X86_64 > /* >* If this is normal user memory, make it NX in the kernel >* pagetables so that, if we somehow screw up and return to > @@ -134,10 +135,16 @@ pgd_t __pti_set_user_pgd(pgd_t *pgdp, pgd_t pgd) >*

Re: [PATCH 12/16] x86/mm/pae: Populate the user page-table with user pgd's

On Tue, 16 Jan 2018, Joerg Roedel wrote: > > +#ifdef CONFIG_X86_64 > /* >* If this is normal user memory, make it NX in the kernel >* pagetables so that, if we somehow screw up and return to > @@ -134,10 +135,16 @@ pgd_t __pti_set_user_pgd(pgd_t *pgdp, pgd_t pgd) >*

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Tue, Jan 16, 2018 at 10:02 PM, Arnd Bergmann wrote: > On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney > wrote: >> On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: >>> On Fri, 2 Jun 2017, Paul E. McKenney wrote: > It took me around

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Tue, Jan 16, 2018 at 10:02 PM, Arnd Bergmann wrote: > On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney > wrote: >> On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: >>> On Fri, 2 Jun 2017, Paul E. McKenney wrote: > It took me around 20 randconfig builds since May, but I

[PATCH] lightnvm/pblk-gc: Delete an error message for a failed memory allocation in pblk_gc_line_prepare_ws()

From: Markus Elfring Date: Tue, 16 Jan 2018 22:00:15 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] lightnvm/pblk-gc: Delete an error message for a failed memory allocation in pblk_gc_line_prepare_ws()

From: Markus Elfring Date: Tue, 16 Jan 2018 22:00:15 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/lightnvm/pblk-gc.c | 4 +--- 1 file changed, 1 insertion(+),

Re: [PATCH v6 02/12] drivers: base: cacheinfo: setup DT cache properties early

Hi, On 01/15/2018 06:33 AM, Sudeep Holla wrote: On Fri, Jan 12, 2018 at 06:59:10PM -0600, Jeremy Linton wrote: The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the hardware and then cache_shared_cpu_map_setup() and

Re: [PATCH v6 02/12] drivers: base: cacheinfo: setup DT cache properties early

Hi, On 01/15/2018 06:33 AM, Sudeep Holla wrote: On Fri, Jan 12, 2018 at 06:59:10PM -0600, Jeremy Linton wrote: The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the hardware and then cache_shared_cpu_map_setup() and

Re: [PATCH 10/16] x86/mm/pti: Populate valid user pud entries

On Tue, 16 Jan 2018, Joerg Roedel wrote: > From: Joerg Roedel > > With PAE paging we don't have PGD and P4D levels in the > page-table, instead the PUD level is the highest one. > > In PAE page-tables at the top-level most bits we usually set > with _KERNPG_TABLE are reserved,

Re: [PATCH 10/16] x86/mm/pti: Populate valid user pud entries

On Tue, 16 Jan 2018, Joerg Roedel wrote: > From: Joerg Roedel > > With PAE paging we don't have PGD and P4D levels in the > page-table, instead the PUD level is the highest one. > > In PAE page-tables at the top-level most bits we usually set > with _KERNPG_TABLE are reserved, resulting in a

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

On Tue, Jan 16, 2018 at 12:17:01PM -0600, Christopher Lameter wrote: > Draft patch of how the data structs could change. kmem_cache_attr is read > only. Looks good. Although I would add Kees' user feature: struct kmem_cache_attr { char name[16]; unsigned int size;

Re: [PATCH 09/16] x86/mm/pti: Clone CPU_ENTRY_AREA on PMD level on x86_32

On Tue, 16 Jan 2018, Joerg Roedel wrote: > +#ifdef CONFIG_X86_64 > /* > * Clone a single p4d (i.e. a top-level entry on 4-level systems and a > * next-level entry on 5-level systems. > @@ -322,13 +323,29 @@ static void __init pti_clone_p4d(unsigned long addr) > kernel_p4d =

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

On Tue, Jan 16, 2018 at 12:17:01PM -0600, Christopher Lameter wrote: > Draft patch of how the data structs could change. kmem_cache_attr is read > only. Looks good. Although I would add Kees' user feature: struct kmem_cache_attr { char name[16]; unsigned int size;

Re: [PATCH 09/16] x86/mm/pti: Clone CPU_ENTRY_AREA on PMD level on x86_32

On Tue, 16 Jan 2018, Joerg Roedel wrote: > +#ifdef CONFIG_X86_64 > /* > * Clone a single p4d (i.e. a top-level entry on 4-level systems and a > * next-level entry on 5-level systems. > @@ -322,13 +323,29 @@ static void __init pti_clone_p4d(unsigned long addr) > kernel_p4d =

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney wrote: > On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: >> On Fri, 2 Jun 2017, Paul E. McKenney wrote: >> >> > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: >> > > On Fri, May 12,

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney wrote: > On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote: >> On Fri, 2 Jun 2017, Paul E. McKenney wrote: >> >> > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: >> > > On Fri, May 12, 2017 at 02:59:48PM -0400,

Re: [PATCH v2 01/19] Documentation: document array_ptr

On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams wrote: > From: Mark Rutland > > Document the rationale and usage of the new array_ptr() helper. > > Signed-off-by: Mark Rutland > Signed-off-by: Will Deacon

Re: [PATCH v2 01/19] Documentation: document array_ptr

On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams wrote: > From: Mark Rutland > > Document the rationale and usage of the new array_ptr() helper. > > Signed-off-by: Mark Rutland > Signed-off-by: Will Deacon > Cc: Dan Williams > Cc: Jonathan Corbet > Cc: Peter Zijlstra > Signed-off-by: Dan

Re: [PATCH v2] retpoline/module: Warn for missing retpoline in module

Thanks. I just sent a v3 that changes the VERMAGIC only, based on Greg's earlier feedback. It has the drawbacks that it: - refuses loading instead of warns - doesn't stop refusing when the feature is runtime disabled But it's much simpler, just a few lines of ifdef. We can either go with the

Re: [PATCH v2] retpoline/module: Warn for missing retpoline in module

Thanks. I just sent a v3 that changes the VERMAGIC only, based on Greg's earlier feedback. It has the drawbacks that it: - refuses loading instead of warns - doesn't stop refusing when the feature is runtime disabled But it's much simpler, just a few lines of ifdef. We can either go with the

Re: [PATCH arm/aspeed/ast2500 v1] ipmi: add an Aspeed KCS IPMI BMC driver

On 01/16/2018 05:43 AM, Haiyue Wang wrote: The KCS (Keyboard Controller Style) interface is used to perform in-band IPMI communication between a server host and its BMC (BaseBoard Management Controllers). This driver exposes the KCS interface on ASpeed SOCs (AST2400 and AST2500) as a character

Re: [PATCH arm/aspeed/ast2500 v1] ipmi: add an Aspeed KCS IPMI BMC driver

On 01/16/2018 05:43 AM, Haiyue Wang wrote: The KCS (Keyboard Controller Style) interface is used to perform in-band IPMI communication between a server host and its BMC (BaseBoard Management Controllers). This driver exposes the KCS interface on ASpeed SOCs (AST2400 and AST2500) as a character

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