[PATCH 49/61] staging: nvec: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/staging/nvec/nvec.c | 6 ++ 1 file

[PATCH 49/61] staging: nvec: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/staging/nvec/nvec.c | 6 ++ 1 file changed, 2 insertions(+), 4

Hello

I have a business to discuss with you, can we talk? Regards Faruk Sakawo

Hello

I have a business to discuss with you, can we talk? Regards Faruk Sakawo

[PATCH v3] ARM: dts: sunxi: Add sid for a83t

Allwinner a83t has a 1 KB sid block with efuse for security rootkey and thermal calibration data, add node to describe it. a83t-sid is not currently supported by nvmem/sunxi-sid, but it is supported in an external driver for FreeBSD. Signed-off-by: Kyle Evans --- Changes in

[PATCH v3] ARM: dts: sunxi: Add sid for a83t

Allwinner a83t has a 1 KB sid block with efuse for security rootkey and thermal calibration data, add node to describe it. a83t-sid is not currently supported by nvmem/sunxi-sid, but it is supported in an external driver for FreeBSD. Signed-off-by: Kyle Evans --- Changes in v3: - rebased

Re: [PATCH] x86/ldt: Fix support_pte_mask filtering in map_ldt_struct()

On Thu, Apr 19, 2018 at 03:00:11PM +0200, Borislav Petkov wrote: > fb43d6cb91ef x86/mm: Do not auto-massage page protections <--- NOT OK Hmm, that hunk from above patch looks suspicious: - set_pgd(pgd + pgd_index(restore_jump_address), __pgd(__pa(pud) | _KERNPG_TABLE)); +

Re: [PATCH] x86/ldt: Fix support_pte_mask filtering in map_ldt_struct()

On Thu, Apr 19, 2018 at 03:00:11PM +0200, Borislav Petkov wrote: > fb43d6cb91ef x86/mm: Do not auto-massage page protections <--- NOT OK Hmm, that hunk from above patch looks suspicious: - set_pgd(pgd + pgd_index(restore_jump_address), __pgd(__pa(pud) | _KERNPG_TABLE)); +

[PATCH 51/61] thermal: int340x_thermal: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/thermal/int340x_thermal/int3400_thermal.c

[PATCH 43/61] pwm: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/pwm/pwm-atmel-tcb.c | 6 ++

[PATCH 51/61] thermal: int340x_thermal: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/thermal/int340x_thermal/int3400_thermal.c | 9 +++-- 1 file changed, 3

[PATCH 43/61] pwm: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/pwm/pwm-atmel-tcb.c | 6 ++ drivers/pwm/pwm-rcar.c | 3 +-- 2

[PATCH 54/61] uio: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/uio/uio_fsl_elbc_gpcm.c | 6 ++ 1

[PATCH 54/61] uio: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/uio/uio_fsl_elbc_gpcm.c | 6 ++ 1 file changed, 2 insertions(+), 4

[PATCH 52/61] thermal: st: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/thermal/st/st_thermal.c | 6 ++ 1

[PATCH 52/61] thermal: st: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/thermal/st/st_thermal.c | 6 ++ 1 file changed, 2 insertions(+), 4

[PATCH 50/61] thermal: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/thermal/rockchip_thermal.c | 8 +++-

[PATCH 50/61] thermal: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/thermal/rockchip_thermal.c | 8 +++- drivers/thermal/spear_thermal.c

[PATCH 57/61] video: fbdev: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/video/fbdev/auo_k190x.c| 12

[PATCH 57/61] video: fbdev: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/video/fbdev/auo_k190x.c| 12

[PATCH 56/61] usb: phy: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/usb/phy/phy-am335x.c | 6 ++ 1 file

[PATCH 56/61] usb: phy: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/usb/phy/phy-am335x.c | 6 ++ 1 file changed, 2 insertions(+), 4

Re: [PATCH] KVM: X86: Extend MAX_IRQ_ROUTES to 4096

On Thu, 19 Apr 2018 13:42:55 + Wanpeng Li wrote: > On Thu, 19 Apr 2018 05:30:40 -0700 > > Wanpeng Li wrote: > > > From: Wanpeng Li > > > > Our virtual machines make use of device assignment by configuring > > 12 NVMe

Re: [PATCH] KVM: X86: Extend MAX_IRQ_ROUTES to 4096

On Thu, 19 Apr 2018 13:42:55 + Wanpeng Li wrote: > On Thu, 19 Apr 2018 05:30:40 -0700 > > Wanpeng Li wrote: > > > From: Wanpeng Li > > > > Our virtual machines make use of device assignment by configuring > > 12 NVMe disks for high I/O performance. Each NVMe device has 129 > > MSI-X

[PATCH 58/61] video: fbdev: omap2: omapfb: displays: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually.

[PATCH 58/61] video: fbdev: omap2: omapfb: displays: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. .../video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 18 ++ 1

[PATCH 59/61] watchdog: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/watchdog/cadence_wdt.c | 6 ++

[PATCH 59/61] watchdog: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/watchdog/cadence_wdt.c | 6 ++ drivers/watchdog/of_xilinx_wdt.c | 6

Re: KASAN: slab-out-of-bounds Write in tty_insert_flip_string_fixed_flag

On Thu, Apr 19, 2018 at 09:25:08PM +0900, DaeRyong Jeong wrote: > The patch is attached at the end of this email and can be downloaded from > here. > https://kiwi.cs.purdue.edu/static/race-fuzzer/tty_insert_flip_string_fixed_flag.patch > > We applied the patch to v4.16 and tested our reproducer.

Re: [patch V2 7/8] dm verity fec: Check result of init_rs()

On Thu, 19 Apr 2018, Mike Snitzer wrote: > On Thu, Apr 19 2018 at 6:04am -0400, > Thomas Gleixner wrote: > > > From: Thomas Gleixner > > > > The allocation of the reed solomon control structure can fail, but > > fec_alloc_bufs() ignores that and

Re: [patch V2 7/8] dm verity fec: Check result of init_rs()

On Thu, 19 Apr 2018, Mike Snitzer wrote: > On Thu, Apr 19 2018 at 6:04am -0400, > Thomas Gleixner wrote: > > > From: Thomas Gleixner > > > > The allocation of the reed solomon control structure can fail, but > > fec_alloc_bufs() ignores that and subsequent operations in dm verity use > > the

Re: KASAN: slab-out-of-bounds Write in tty_insert_flip_string_fixed_flag

On Thu, Apr 19, 2018 at 09:25:08PM +0900, DaeRyong Jeong wrote: > The patch is attached at the end of this email and can be downloaded from > here. > https://kiwi.cs.purdue.edu/static/race-fuzzer/tty_insert_flip_string_fixed_flag.patch > > We applied the patch to v4.16 and tested our reproducer.

[PATCH 53/61] tty: serial: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/tty/serial/imx.c | 18

[PATCH 53/61] tty: serial: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/tty/serial/imx.c | 18 ++

[PATCH 60/61] net: dsa: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. net/dsa/legacy.c | 6 ++ 1 file changed, 2

[PATCH 60/61] net: dsa: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. net/dsa/legacy.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff

[PATCH 61/61] ASoC: atmel: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. sound/soc/atmel/atmel_ssc_dai.c | 6 ++ 1

[PATCH 61/61] ASoC: atmel: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. sound/soc/atmel/atmel_ssc_dai.c | 6 ++ 1 file changed, 2 insertions(+), 4

Re: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

On Thu, Apr 19, 2018 at 03:32:33PM +0200, Alexandre Belloni wrote: > My suggestion was to add an MFD driver that would match the current > compatible and either have an atmel,usart-mode property or maybe more > risky, check whether there are children nodes. Based on that, the > correct platform

Re: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

On Thu, Apr 19, 2018 at 03:32:33PM +0200, Alexandre Belloni wrote: > My suggestion was to add an MFD driver that would match the current > compatible and either have an atmel,usart-mode property or maybe more > risky, check whether there are children nodes. Based on that, the > correct platform

[PATCH 04/61] bus: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/bus/brcmstb_gisb.c | 12 1

[PATCH 55/61] usb: mtu3: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/usb/mtu3/mtu3_plat.c | 6 ++ 1 file

[PATCH 04/61] bus: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/bus/brcmstb_gisb.c | 12 1 file changed, 4 insertions(+), 8

[PATCH 55/61] usb: mtu3: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/usb/mtu3/mtu3_plat.c | 6 ++ 1 file changed, 2 insertions(+), 4

[PATCH 23/61] input: touchscreen: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/input/touchscreen/imx6ul_tsc.c | 6 ++

[PATCH 23/61] input: touchscreen: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/input/touchscreen/imx6ul_tsc.c | 6 ++ 1 file changed, 2 insertions(+),

[PATCH 03/61] auxdisplay: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/auxdisplay/arm-charlcd.c | 6 ++ 1

[PATCH 03/61] auxdisplay: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/auxdisplay/arm-charlcd.c | 6 ++ 1 file changed, 2 insertions(+), 4

[PATCH RFC] ASoC: dai playback_active and capture_active may be greater than 1

At the moment playback_active and capture_active are using only 1 bit so the maximum active count is 1. However, snd_soc_runtime_activate() may be called several time on the same dai. This happens when a dai is part of several dai_links. It is often the case for "snd-soc-dummy-dai". This is a

[PATCH RFC] ASoC: dai playback_active and capture_active may be greater than 1

At the moment playback_active and capture_active are using only 1 bit so the maximum active count is 1. However, snd_soc_runtime_activate() may be called several time on the same dai. This happens when a dai is part of several dai_links. It is often the case for "snd-soc-dummy-dai". This is a

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

On Thu 19-04-18 15:59:43, Greg KH wrote: > On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: > > Den 16-04-2018 kl. 19:19, skrev Sasha Levin: > > > On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: > > > > On Mon, 16 Apr 2018 16:02:03 + > > > > Sasha Levin

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

On Thu 19-04-18 15:59:43, Greg KH wrote: > On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: > > Den 16-04-2018 kl. 19:19, skrev Sasha Levin: > > > On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: > > > > On Mon, 16 Apr 2018 16:02:03 + > > > > Sasha Levin wrote:

[PATCH v2] platform/x86: asus-wireless: Fix NULL pointer dereference

When the module is removed the led workqueue is destroyed in the remove callback, before the led device is unregistered from the led subsystem. This leads to a NULL pointer derefence when the led device is unregistered automatically later as part of the module removal cleanup. Bellow is the

[PATCH v2] platform/x86: asus-wireless: Fix NULL pointer dereference

When the module is removed the led workqueue is destroyed in the remove callback, before the led device is unregistered from the led subsystem. This leads to a NULL pointer derefence when the led device is unregistered automatically later as part of the module removal cleanup. Bellow is the

Re: [PATCH 16/21] regulator: wm8994: Pass descriptor instead of GPIO number

On Thu, Apr 19, 2018 at 03:55:35PM +0200, Linus Walleij wrote: > drivers pass an enable GPIO to the regulator core. The wm2200 > for example is just managing the LDO without the use of the > regulator framework (I guess this is technically incorrect). It's fine if it's internal to the chip and

Re: [PATCH 16/21] regulator: wm8994: Pass descriptor instead of GPIO number

On Thu, Apr 19, 2018 at 03:55:35PM +0200, Linus Walleij wrote: > drivers pass an enable GPIO to the regulator core. The wm2200 > for example is just managing the LDO without the use of the > regulator framework (I guess this is technically incorrect). It's fine if it's internal to the chip and

Re: [PATCH V2 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

On Thu, Apr 19, 2018 at 03:23:39AM +, Anson Huang wrote: > If so, I think we should use V1 patch to keep clocks container? Ah, right. I will just pick up v1 of patch #2. Shawn

Re: [PATCH V2 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

On Thu, Apr 19, 2018 at 03:23:39AM +, Anson Huang wrote: > If so, I think we should use V1 patch to keep clocks container? Ah, right. I will just pick up v1 of patch #2. Shawn

Re: [PATCH V2 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

On Wed, Apr 18, 2018 at 08:17:35PM -0700, Stephen Boyd wrote: > Quoting Shawn Guo (2018-04-17 07:22:05) > > On Mon, Mar 19, 2018 at 10:30:45AM +0800, Anson Huang wrote: > > > On i.MX6SX SabreAuto board, there is external 24MHz clock > > > source for analog clock2, add this clock source to clock

Re: [PATCH 4.9 00/66] 4.9.95-stable review

On Thu, Apr 19, 2018 at 04:42:56PM +0530, Naresh Kamboju wrote: > > > > Can you try 'git bisect'? I'll hold off on releasing 4.9.y until this > > gets figured out. > > After reverting this patch, network started works on arm32 x15 device. > d7ba3c00047d ("net: phy: micrel: Restore led_mode and

Re: [PATCH V2 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

On Wed, Apr 18, 2018 at 08:17:35PM -0700, Stephen Boyd wrote: > Quoting Shawn Guo (2018-04-17 07:22:05) > > On Mon, Mar 19, 2018 at 10:30:45AM +0800, Anson Huang wrote: > > > On i.MX6SX SabreAuto board, there is external 24MHz clock > > > source for analog clock2, add this clock source to clock

Re: [PATCH 4.9 00/66] 4.9.95-stable review

On Thu, Apr 19, 2018 at 04:42:56PM +0530, Naresh Kamboju wrote: > > > > Can you try 'git bisect'? I'll hold off on releasing 4.9.y until this > > gets figured out. > > After reverting this patch, network started works on arm32 x15 device. > d7ba3c00047d ("net: phy: micrel: Restore led_mode and

Re: [v2] drm/sun4i: add lvds mode_valid function

Hi everybody, Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto: On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman wrote: Hello Giulio, this patch breaks LVDS output on A83T. Without it, modesetting works, with it there's no output. Some more info below... On Tue, Mar

Re: [v2] drm/sun4i: add lvds mode_valid function

Hi everybody, Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto: On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman wrote: Hello Giulio, this patch breaks LVDS output on A83T. Without it, modesetting works, with it there's no output. Some more info below... On Tue, Mar 13, 2018 at 12:20:19PM +0100,

Re: [PATCH] platform/x86: asus-wireless: Fix NULL pointer dereference

On Sat, Apr 7, 2018 at 8:50 AM, Darren Hart wrote: > On Fri, Apr 06, 2018 at 10:37:29PM -0700, João Paulo Rechi Vita wrote: >> When the module is removed the led workqueue is destroyed in the remove >> callback, before the led device is unregistered from the led subsystem.

Re: [PATCH] platform/x86: asus-wireless: Fix NULL pointer dereference

On Sat, Apr 7, 2018 at 8:50 AM, Darren Hart wrote: > On Fri, Apr 06, 2018 at 10:37:29PM -0700, João Paulo Rechi Vita wrote: >> When the module is removed the led workqueue is destroyed in the remove >> callback, before the led device is unregistered from the led subsystem. >> >> This leads to a

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: > Den 16-04-2018 kl. 19:19, skrev Sasha Levin: > > On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: > > > On Mon, 16 Apr 2018 16:02:03 + > > > Sasha Levin wrote: > > > > > > > One

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: > Den 16-04-2018 kl. 19:19, skrev Sasha Levin: > > On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: > > > On Mon, 16 Apr 2018 16:02:03 + > > > Sasha Levin wrote: > > > > > > > One of the things Greg is pushing

[PATCH v6 1/7] clk: meson: migrate to devm_of_clk_add_hw_provider API

There is a protential memory leak, as of_clk_del_provider is never called if of_clk_add_hw_provider has been executed. Fix this by using devm variant API. Fixes: f8c11f79912d ("clk: meson: Add GXBB AO Clock and Reset controller driver") Suggested-by: Stephen Boyd

[PATCH v6 1/7] clk: meson: migrate to devm_of_clk_add_hw_provider API

There is a protential memory leak, as of_clk_del_provider is never called if of_clk_add_hw_provider has been executed. Fix this by using devm variant API. Fixes: f8c11f79912d ("clk: meson: Add GXBB AO Clock and Reset controller driver") Suggested-by: Stephen Boyd Signed-off-by: Yixun Lan ---

[PATCH v6 6/7] clk: meson: drop CLK_SET_RATE_PARENT flag

The clk81 is not expected to be changed, so drop this flag. Signed-off-by: Yixun Lan --- drivers/clk/meson/gxbb-aoclk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/meson/gxbb-aoclk.c b/drivers/clk/meson/gxbb-aoclk.c index

[PATCH v6 6/7] clk: meson: drop CLK_SET_RATE_PARENT flag

The clk81 is not expected to be changed, so drop this flag. Signed-off-by: Yixun Lan --- drivers/clk/meson/gxbb-aoclk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/meson/gxbb-aoclk.c b/drivers/clk/meson/gxbb-aoclk.c index c785ee7586d1..e145ebcdef38 100644 ---

Re: [patch V2 4/8] rslib: Remove GPL boilerplate

On Thu, Apr 19, 2018 at 12:04:45PM +0200, Thomas Gleixner wrote: > From: Thomas Gleixner > > Now that SPDX identifiers are in place, remove the GPL boiler plate > text. Leave the notices which document that Phil Karn granted permission in > place (encode/decode source code).

Re: [patch V2 4/8] rslib: Remove GPL boilerplate

On Thu, Apr 19, 2018 at 12:04:45PM +0200, Thomas Gleixner wrote: > From: Thomas Gleixner > > Now that SPDX identifiers are in place, remove the GPL boiler plate > text. Leave the notices which document that Phil Karn granted permission in > place (encode/decode source code). The modified files

Re: [PATCH] kvm: Change return type to vm_fault_t

On Thu, 19 Apr 2018 00:49:58 +0530 Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a

Re: [PATCH] kvm: Change return type to vm_fault_t

On Thu, 19 Apr 2018 00:49:58 +0530 Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. > >

[PATCH v6 5/7] clk: meson-axg: Add AO Clock and Reset controller driver

From: Qiufang Dai Adds a Clock and Reset controller driver for the Always-On part of the Amlogic Meson-AXG SoC. Signed-off-by: Qiufang Dai Signed-off-by: Yixun Lan --- drivers/clk/meson/Kconfig | 1 +

[PATCH v6 5/7] clk: meson-axg: Add AO Clock and Reset controller driver

From: Qiufang Dai Adds a Clock and Reset controller driver for the Always-On part of the Amlogic Meson-AXG SoC. Signed-off-by: Qiufang Dai Signed-off-by: Yixun Lan --- drivers/clk/meson/Kconfig | 1 + drivers/clk/meson/Makefile| 2 +- drivers/clk/meson/axg-aoclk.c | 165

Re: [PATCH 16/21] regulator: wm8994: Pass descriptor instead of GPIO number

On Tue, Feb 13, 2018 at 12:11 PM, Charles Keepax wrote: >> +static struct gpiod_lookup_table wm8994_gpiod_table = { >> + .dev_id = "i2c-wm8958", /* I2C device name */ >> + .table = { >> + GPIO_LOOKUP("GPION", 6, >> +

[PATCH v6 0/7] clk: meson-axg: Add AO Cloclk and Reset driver

This patch try to add AO clock and Reset driver for Amlogic's Meson-AXG SoC. Please note that patch 7 need to wait for the DTS changes[3] merged into mainline first, otherwise it will break the serial console. patch 2: factor the common code into a dedicated file patch 3-5: add the aoclk

[PATCH v6 3/7] dt-bindings: clock: axg-aoclkc: New binding for Meson-AXG SoC

Update the dt-binding documentation to support new compatible string for the Amlogic's Meson-AXG SoC. Reviewed-by: Rob Herring Signed-off-by: Yixun Lan --- Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt | 1 + 1 file changed, 1

Re: [patch V2 3/8] rslib: Add SPDX identifiers

On Thu, Apr 19, 2018 at 12:04:44PM +0200, Thomas Gleixner wrote: > From: Thomas Gleixner > > The Reed-Solomon library is based on code from Phil Karn who granted > permission to import it into the kernel under the GPL V2. > > See commit 15b5423757a7 ("Shared Reed-Solomon ECC

Re: [PATCH 16/21] regulator: wm8994: Pass descriptor instead of GPIO number

On Tue, Feb 13, 2018 at 12:11 PM, Charles Keepax wrote: >> +static struct gpiod_lookup_table wm8994_gpiod_table = { >> + .dev_id = "i2c-wm8958", /* I2C device name */ >> + .table = { >> + GPIO_LOOKUP("GPION", 6, >> + "wlf,ldo1ena", GPIO_ACTIVE_HIGH),

[PATCH v6 0/7] clk: meson-axg: Add AO Cloclk and Reset driver

This patch try to add AO clock and Reset driver for Amlogic's Meson-AXG SoC. Please note that patch 7 need to wait for the DTS changes[3] merged into mainline first, otherwise it will break the serial console. patch 2: factor the common code into a dedicated file patch 3-5: add the aoclk

[PATCH v6 3/7] dt-bindings: clock: axg-aoclkc: New binding for Meson-AXG SoC

Update the dt-binding documentation to support new compatible string for the Amlogic's Meson-AXG SoC. Reviewed-by: Rob Herring Signed-off-by: Yixun Lan --- Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [patch V2 3/8] rslib: Add SPDX identifiers

On Thu, Apr 19, 2018 at 12:04:44PM +0200, Thomas Gleixner wrote: > From: Thomas Gleixner > > The Reed-Solomon library is based on code from Phil Karn who granted > permission to import it into the kernel under the GPL V2. > > See commit 15b5423757a7 ("Shared Reed-Solomon ECC library") in the

[PATCH v6 2/7] clk: meson: aoclk: refactor common code into dedicated file

We try to refactor the common code into one dedicated file, while preparing to add new Meson-AXG aoclk driver, this would help us to better share the code by all aoclk drivers. Suggested-by: Jerome Brunet Signed-off-by: Yixun Lan ---

[PATCH v6 7/7] clk: meson: drop CLK_IGNORE_UNUSED flag

Rely on drivers to request the clock explicitly. Previous the kernel will leave the clock on while bootloader adready initilized the clock, this wasn't optimal way, so fix it here. Signed-off-by: Yixun Lan --- drivers/clk/meson/axg-aoclk.c | 1 -

[PATCH v6 2/7] clk: meson: aoclk: refactor common code into dedicated file

We try to refactor the common code into one dedicated file, while preparing to add new Meson-AXG aoclk driver, this would help us to better share the code by all aoclk drivers. Suggested-by: Jerome Brunet Signed-off-by: Yixun Lan --- drivers/clk/meson/Kconfig | 7 +++

[PATCH v6 7/7] clk: meson: drop CLK_IGNORE_UNUSED flag

Rely on drivers to request the clock explicitly. Previous the kernel will leave the clock on while bootloader adready initilized the clock, this wasn't optimal way, so fix it here. Signed-off-by: Yixun Lan --- drivers/clk/meson/axg-aoclk.c | 1 - drivers/clk/meson/gxbb-aoclk.c | 1 - 2 files

Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

On 04/19/2018 04:35 PM, Andrey Ryabinin wrote: > > > On 04/18/2018 09:37 PM, Linus Torvalds wrote: >> Ugh, that lustre code is disgusting. >> >> I thought we were getting rid of it. >> >> Anyway, I started looking at why the stack trace is such an incredible >> mess, with lots of stale

Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

On 04/19/2018 04:35 PM, Andrey Ryabinin wrote: > > > On 04/18/2018 09:37 PM, Linus Torvalds wrote: >> Ugh, that lustre code is disgusting. >> >> I thought we were getting rid of it. >> >> Anyway, I started looking at why the stack trace is such an incredible >> mess, with lots of stale

Re: [PATCH 1/2] atomic_ops.rst: Fix wrong example code

On Thu, Apr 19, 2018 at 05:42:44PM +0900, SeongJae Park wrote: > Example code snippets for necessary of READ_ONCE() and WRITE_ONCE() has > an unnecessary line of code and wrong condition. This commit fixes > them. > > Signed-off-by: SeongJae Park Good catch!!! I queued

Re: [PATCH 1/2] atomic_ops.rst: Fix wrong example code

On Thu, Apr 19, 2018 at 05:42:44PM +0900, SeongJae Park wrote: > Example code snippets for necessary of READ_ONCE() and WRITE_ONCE() has > an unnecessary line of code and wrong condition. This commit fixes > them. > > Signed-off-by: SeongJae Park Good catch!!! I queued and pushed both patches

[PATCH v6 4/7] dt-bindings: clock: reset: Add AXG AO Clock and Reset Bindings

Add dt-bindings headers for the Meson-AXG's AO clock and reset controller. Reviewed-by: Rob Herring Signed-off-by: Yixun Lan --- include/dt-bindings/clock/axg-aoclkc.h | 26 ++ include/dt-bindings/reset/axg-aoclkc.h | 20

[PATCH v6 4/7] dt-bindings: clock: reset: Add AXG AO Clock and Reset Bindings

Add dt-bindings headers for the Meson-AXG's AO clock and reset controller. Reviewed-by: Rob Herring Signed-off-by: Yixun Lan --- include/dt-bindings/clock/axg-aoclkc.h | 26 ++ include/dt-bindings/reset/axg-aoclkc.h | 20 2 files changed, 46

Re: [v2 1/1] i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()

On Thu, Apr 19, 2018 at 03:29:22PM +0300, Alexander Popov wrote: > i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which > returns ZERO_SIZE_PTR if i2c_msg.len is zero. > > Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case > of I2C_M_RD | I2C_M_RECV_LEN

Re: [v2 1/1] i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()

On Thu, Apr 19, 2018 at 03:29:22PM +0300, Alexander Popov wrote: > i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which > returns ZERO_SIZE_PTR if i2c_msg.len is zero. > > Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case > of I2C_M_RD | I2C_M_RECV_LEN

[PATCH v7 0/5] cpuset: Enable cpuset controller in default hierarchy

v7: - Add a root-only cpuset.cpus.isolated control file for CPU isolation. - Enforce that load_balancing can only be turned off on cpusets with CPUs from the isolated list. - Update sched domain generation to allow cpusets with CPUs only from the isolated CPU list to be in separate root

Re: 4.15.17 regression: bisected: timeout during microcode update

On Thu, Apr 19, 2018 at 05:32:18AM -0700, Raj, Ashok wrote: > Thanks.. also can you remove the ret below, and send the output > of /proc/cpuinfo before and after? > > On Thu, Apr 19, 2018 at 02:18:41PM +0200, Borislav Petkov wrote: > > } else { > > + pr_info("%s: CPU%d returning

<    7   8   9   10   11   12   13   14   15   16   >