Re: [linux-sunxi] [PATCH v2 2/4] ARM: dtsi: add pwm node for sun8i.

Hi, The subject line should mention the R40, there are far too many sun8i SoCs. On 25/02/18 13:51, hao_zhang wrote: > This patch adds pwm node for sun8i. > > Signed-off-by: hao_zhang > --- > arch/arm/boot/dts/sun8i-r40.dtsi | 13 + > 1 file changed, 13

Re: [linux-sunxi] [PATCH v2 2/4] ARM: dtsi: add pwm node for sun8i.

Hi, The subject line should mention the R40, there are far too many sun8i SoCs. On 25/02/18 13:51, hao_zhang wrote: > This patch adds pwm node for sun8i. > > Signed-off-by: hao_zhang > --- > arch/arm/boot/dts/sun8i-r40.dtsi | 13 + > 1 file changed, 13 insertions(+) > > diff

Re: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

On 2018/2/27 23:05, Phil Edworthy wrote: Hi Shawn, On 27 February 2018 14:42, Shawn Lin wrote: On 2018/2/27 22:31, Phil Edworthy wrote: Hi Shawn, On 27 February 2018 14:28, Shawn Lin wrote: 在 2018/2/27 21:55, Phil Edworthy 写道: Since the controller does not support the end-of-busy IRQ,

Re: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

On 2018/2/27 23:05, Phil Edworthy wrote: Hi Shawn, On 27 February 2018 14:42, Shawn Lin wrote: On 2018/2/27 22:31, Phil Edworthy wrote: Hi Shawn, On 27 February 2018 14:28, Shawn Lin wrote: 在 2018/2/27 21:55, Phil Edworthy 写道: Since the controller does not support the end-of-busy IRQ,

Re: [linux-sunxi] [PATCH v2 1/4] dt-bindings: pwm: binding allwinner sun8i.

Hi, On 25/02/18 13:50, hao_zhang wrote: > This patch adds allwinner sun8i pwm binding documents. > > Signed-off-by: hao_zhang > --- > Documentation/devicetree/bindings/pwm/pwm-sun8i.txt | 18 ++ > 1 file changed, 18 insertions(+) > create mode 100644

Re: [linux-sunxi] [PATCH v2 1/4] dt-bindings: pwm: binding allwinner sun8i.

Hi, On 25/02/18 13:50, hao_zhang wrote: > This patch adds allwinner sun8i pwm binding documents. > > Signed-off-by: hao_zhang > --- > Documentation/devicetree/bindings/pwm/pwm-sun8i.txt | 18 ++ > 1 file changed, 18 insertions(+) > create mode 100644

Re: [PATCH v4 4/4] ARM: dts: imx7s: add CAAM device node

On Thu, Feb 22, 2018 at 02:22:50PM +, Rui Miguel Silva wrote: > Add CAAM device node to the i.MX7s device tree. > > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: devicet...@vger.kernel.org > Cc: "Horia Geantă" > Cc: Aymen Sghaier

Re: [PATCH v4 4/4] ARM: dts: imx7s: add CAAM device node

On Thu, Feb 22, 2018 at 02:22:50PM +, Rui Miguel Silva wrote: > Add CAAM device node to the i.MX7s device tree. > > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: devicet...@vger.kernel.org > Cc: "Horia Geantă" > Cc: Aymen Sghaier > Cc: Fabio Estevam > Cc: Peng Fan > Cc: "David S. Miller" >

[PATCH v3 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

proc_sys_link_fill_cache() does not need to check whether we're called for a link - it's already done by scan(). Acked-by: Kees Cook Signed-off-by: Danilo Krummrich --- v2: removed 'err' as it's only used for sysctl_follow_link() v3: add ack

[PATCH v3 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

proc_sys_link_fill_cache() does not need to check whether we're called for a link - it's already done by scan(). Acked-by: Kees Cook Signed-off-by: Danilo Krummrich --- v2: removed 'err' as it's only used for sysctl_follow_link() v3: add ack --- fs/proc/proc_sysctl.c | 9 +++-- 1 file

[PATCH v3 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

proc_sys_link_fill_cache() does not take currently unregistering sysctl tables into account, which might result into a page fault in sysctl_follow_link() - add a check to fix it. This bug has been present since v3.4. Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between

[PATCH v3 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

proc_sys_link_fill_cache() does not take currently unregistering sysctl tables into account, which might result into a page fault in sysctl_follow_link() - add a check to fix it. This bug has been present since v3.4. Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between

Re: [PATCH v2 11/11] test_firmware: test three firmware kernel configs using a proc knob

On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote: > On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > > Since we now have knobs to twiddle what used to be set on kernel > > configurations we can build one base kernel configuration and modify > > behaviour to

Re: [PATCH v2 11/11] test_firmware: test three firmware kernel configs using a proc knob

On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote: > On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > > Since we now have knobs to twiddle what used to be set on kernel > > configurations we can build one base kernel configuration and modify > > behaviour to mimic such kernel

Re: [PATCH] sparse doesn't support indirect_branch attribute

2018-02-28 7:36 GMT+09:00 Luc Van Oostenryck : > On Tue, Feb 27, 2018 at 02:12:28PM -0800, Linus Torvalds wrote: >> On Tue, Feb 27, 2018 at 12:18 PM, Randy Dunlap wrote: >> > >> > I don't mind the patch, but I did send a patch for this attribute

Re: [PATCH] sparse doesn't support indirect_branch attribute

2018-02-28 7:36 GMT+09:00 Luc Van Oostenryck : > On Tue, Feb 27, 2018 at 02:12:28PM -0800, Linus Torvalds wrote: >> On Tue, Feb 27, 2018 at 12:18 PM, Randy Dunlap wrote: >> > >> > I don't mind the patch, but I did send a patch for this attribute on Feb. >> > 13, 2018, >> > to the sparse mailing

Re: dns_resolver_preparse tries to print arbitrarily-large user-provided strings

Hi Mark, On Tue, Feb 27, 2018 at 04:43:13PM +, Mark Rutland wrote: > Hi, > > As a heads-up, while fuzzing v4.16-rc3 on arm64 with Syzkaller, I hit a > system hang which I was able to minize to the reproducer below. It looks > like the system hang is an artifact of Syzkaller using

Re: dns_resolver_preparse tries to print arbitrarily-large user-provided strings

Hi Mark, On Tue, Feb 27, 2018 at 04:43:13PM +, Mark Rutland wrote: > Hi, > > As a heads-up, while fuzzing v4.16-rc3 on arm64 with Syzkaller, I hit a > system hang which I was able to minize to the reproducer below. It looks > like the system hang is an artifact of Syzkaller using

Re: [PATCH v2 07/11] firmware: split firmware fallback functionality into its own file

On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote: > On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > > The firmware fallback code is optional. Split that code out to help > > distinguish the fallback functionlity from othere core firmware loader > >

Re: [PATCH v2 07/11] firmware: split firmware fallback functionality into its own file

On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote: > On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > > The firmware fallback code is optional. Split that code out to help > > distinguish the fallback functionlity from othere core firmware loader > > features. This should make

Re: [PATCH] mm/zsmalloc: strength reduce zspage_size calculation

On Wed, Feb 28, 2018 at 09:03:19AM +0900, Minchan Kim wrote: > Thanks for the patch! However, it's used only zs_create_pool which > is really cold path so I don't feel it would improve for real practice. Very true; in retrospect this this definitely isn't a very hot path at all, haha. Cheers :)

Re: [PATCH] mm/zsmalloc: strength reduce zspage_size calculation

On Wed, Feb 28, 2018 at 09:03:19AM +0900, Minchan Kim wrote: > Thanks for the patch! However, it's used only zs_create_pool which > is really cold path so I don't feel it would improve for real practice. Very true; in retrospect this this definitely isn't a very hot path at all, haha. Cheers :)

[RFC 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings

This patch adds documentation of device-tree bindings for the Gateworks System Controller (GSC). Signed-off-by: Tim Harvey --- Documentation/devicetree/bindings/mfd/gsc.txt | 69 +++ 1 file changed, 69 insertions(+) create mode 100644

[RFC 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings

This patch adds documentation of device-tree bindings for the Gateworks System Controller (GSC). Signed-off-by: Tim Harvey --- Documentation/devicetree/bindings/mfd/gsc.txt | 69 +++ 1 file changed, 69 insertions(+) create mode 100644

[RFC 4/4] input: misc: Add Gateworks System Controller support

Add support for dispatching Linux Input events for the various interrupts the Gateworks System Controller provides. Signed-off-by: Tim Harvey --- drivers/input/misc/Kconfig | 6 ++ drivers/input/misc/Makefile| 1 + drivers/input/misc/gsc-input.c | 196

[RFC 4/4] input: misc: Add Gateworks System Controller support

Add support for dispatching Linux Input events for the various interrupts the Gateworks System Controller provides. Signed-off-by: Tim Harvey --- drivers/input/misc/Kconfig | 6 ++ drivers/input/misc/Makefile| 1 + drivers/input/misc/gsc-input.c | 196

[RFC 2/4] mfd: add Gateworks System Controller core driver

The Gateworks System Controller (GSC) is an I2C slave controller implemented with an MSP430 micro-controller whose firmware embeds the following features: - I/O expander (16 GPIO's) using PCA955x protocol - Real Time Clock using DS1672 protocol - User EEPROM using AT24 protocol - HWMON using

[RFC 0/4] Add support for the Gateworks System Controller

This series adds support for the Gateworks System Controller used on Gateworks Laguna, Ventana, and Newport product families. The GSC is an MSP430 I2C slave controller whose firmware embeds the following features: - I/O expander (16 GPIO's emulating a PCA955x) - EEPROM (enumating AT24) - RTC

[RFC 2/4] mfd: add Gateworks System Controller core driver

The Gateworks System Controller (GSC) is an I2C slave controller implemented with an MSP430 micro-controller whose firmware embeds the following features: - I/O expander (16 GPIO's) using PCA955x protocol - Real Time Clock using DS1672 protocol - User EEPROM using AT24 protocol - HWMON using

[RFC 0/4] Add support for the Gateworks System Controller

This series adds support for the Gateworks System Controller used on Gateworks Laguna, Ventana, and Newport product families. The GSC is an MSP430 I2C slave controller whose firmware embeds the following features: - I/O expander (16 GPIO's emulating a PCA955x) - EEPROM (enumating AT24) - RTC

[RFC 3/4] hwmon: add Gateworks System Controller support

The Gateworks System Controller has a hwmon sub-component that exposes up to 16 ADC's, some of which are temperature sensors, others which are voltage inputs. The ADC configuration (register mapping and name) is configured via device-tree and varies board to board. Signed-off-by: Tim Harvey

[RFC 3/4] hwmon: add Gateworks System Controller support

The Gateworks System Controller has a hwmon sub-component that exposes up to 16 ADC's, some of which are temperature sensors, others which are voltage inputs. The ADC configuration (register mapping and name) is configured via device-tree and varies board to board. Signed-off-by: Tim Harvey ---

Re: [RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

On Tue, Feb 27, 2018 at 03:28:21PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote: > > This reflects much clearer what is being done. > > > > Signed-off-by: Luis R. Rodriguez > > --- > >

Re: [RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

On Tue, Feb 27, 2018 at 03:28:21PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote: > > This reflects much clearer what is being done. > > > > Signed-off-by: Luis R. Rodriguez > > --- > > Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +- > >

Re: [RFT 3/7] firmware: make fw_add_devm_name() return 0 if cache present

On Tue, Feb 27, 2018 at 03:31:11PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote: > > Currently fw_add_devm_name() returns 1 if the firmware cache > > was already set. This makes it complicated for us to check for > > correctness. It is

Re: [RFT 3/7] firmware: make fw_add_devm_name() return 0 if cache present

On Tue, Feb 27, 2018 at 03:31:11PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote: > > Currently fw_add_devm_name() returns 1 if the firmware cache > > was already set. This makes it complicated for us to check for > > correctness. It is actually non-fatal if

Re: [RFT 2/7] firmware: fix checking for return values for fw_add_devm_name()

On Tue, Feb 27, 2018 at 03:29:53PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote: > > fw_add_devm_name() adds device's name onto the devres for the > > device so that prior to suspend we cache the firmware onto memory, > > so that on resume

Re: [RFT 2/7] firmware: fix checking for return values for fw_add_devm_name()

On Tue, Feb 27, 2018 at 03:29:53PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote: > > fw_add_devm_name() adds device's name onto the devres for the > > device so that prior to suspend we cache the firmware onto memory, > > so that on resume the firmware is

Re: [PATCH v2 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

On Tue, Feb 27, 2018 at 03:41:40PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:31 PM, Danilo Krummrich > wrote: > > proc_sys_link_fill_cache() does not need to check whether we're > > called for a link - it's already done by scan(). > > > > Signed-off-by:

Re: [PATCH v2 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

On Tue, Feb 27, 2018 at 03:41:40PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:31 PM, Danilo Krummrich > wrote: > > proc_sys_link_fill_cache() does not need to check whether we're > > called for a link - it's already done by scan(). > > > > Signed-off-by: Danilo Krummrich > > Acked-by:

[lkp-robot] [mm] df2af627c7: BUG:sleeping_function_called_from_invalid_context_at_include/linux/percpu-rwsem.h

FYI, we noticed the following commit (built with gcc-7): commit: df2af627c79ad4273b4b4c49711252c084490fd2 ("mm: initialize pages on demand during boot") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -m

[lkp-robot] [mm] df2af627c7: BUG:sleeping_function_called_from_invalid_context_at_include/linux/percpu-rwsem.h

FYI, we noticed the following commit (built with gcc-7): commit: df2af627c79ad4273b4b4c49711252c084490fd2 ("mm: initialize pages on demand during boot") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -m

Re: [PATCH v2 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

On Wed, Feb 28, 2018 at 12:31:55AM +0100, Danilo Krummrich wrote: > proc_sys_link_fill_cache() does not take currently unregistering > sysctl tables into account, which might result into a page fault in > sysctl_follow_link() - add a check to fix it. > > Signed-off-by: Danilo Krummrich

Re: [PATCH v2 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

On Wed, Feb 28, 2018 at 12:31:55AM +0100, Danilo Krummrich wrote: > proc_sys_link_fill_cache() does not take currently unregistering > sysctl tables into account, which might result into a page fault in > sysctl_follow_link() - add a check to fix it. > > Signed-off-by: Danilo Krummrich > --- >

[RFC PATCH 0/1] power: supply: bq27xxx: Call power_supply_changed on status change

Hi, It seems that bq27xxx_battery_update does not call power_supply_changed when the charging status changes, and instead only when the capacity changes. This can cause considerable delays in reporting charging status changes to userspace. This patch turns the battery status reading function

[RFC PATCH 1/1] power: supply: bq27xxx: Call power_supply_changed on status change

Signed-off-by: Merlijn Wajer --- drivers/power/supply/bq27xxx_battery.c | 59 +- include/linux/power/bq27xxx_battery.h | 1 + 2 files changed, 30 insertions(+), 30 deletions(-) diff --git a/drivers/power/supply/bq27xxx_battery.c

[RFC PATCH 0/1] power: supply: bq27xxx: Call power_supply_changed on status change

Hi, It seems that bq27xxx_battery_update does not call power_supply_changed when the charging status changes, and instead only when the capacity changes. This can cause considerable delays in reporting charging status changes to userspace. This patch turns the battery status reading function

[RFC PATCH 1/1] power: supply: bq27xxx: Call power_supply_changed on status change

Signed-off-by: Merlijn Wajer --- drivers/power/supply/bq27xxx_battery.c | 59 +- include/linux/power/bq27xxx_battery.h | 1 + 2 files changed, 30 insertions(+), 30 deletions(-) diff --git a/drivers/power/supply/bq27xxx_battery.c

Re: [PATCH v2 4/5] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

On Tue, Feb 27, 2018 at 03:49:50PM -0500, Waiman Long wrote: > diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c > index 8ad93c2..e4ab272 100644 > --- a/ipc/ipc_sysctl.c > +++ b/ipc/ipc_sysctl.c > @@ -41,12 +41,17 @@ static int proc_ipc_dointvec(struct ctl_table *table, int > write, > static int

Re: [PATCH v2 4/5] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

On Tue, Feb 27, 2018 at 03:49:50PM -0500, Waiman Long wrote: > diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c > index 8ad93c2..e4ab272 100644 > --- a/ipc/ipc_sysctl.c > +++ b/ipc/ipc_sysctl.c > @@ -41,12 +41,17 @@ static int proc_ipc_dointvec(struct ctl_table *table, int > write, > static int

Re: [PATCH v2 3/5] sysctl: Warn when a clamped sysctl parameter is set out of range

On Tue, Feb 27, 2018 at 03:49:49PM -0500, Waiman Long wrote: > Even with clamped sysctl parameters, it is still not that straight > forward to figure out the exact range of those parameters. One may > try to write extreme parameter values to see if they get clamped. > To make it easier, a warning

Re: [PATCH v2 3/5] sysctl: Warn when a clamped sysctl parameter is set out of range

On Tue, Feb 27, 2018 at 03:49:49PM -0500, Waiman Long wrote: > Even with clamped sysctl parameters, it is still not that straight > forward to figure out the exact range of those parameters. One may > try to write extreme parameter values to see if they get clamped. > To make it easier, a warning

Re: [PATCH v2] ARM: imx: avic: set low-power interrupt mask for imx25

On Tue, Feb 27, 2018 at 10:29:15PM +0100, Martin Kaiser wrote: > imx25 contains two registers (LPIMR0 and 1) to define which interrupts > are enabled in low-power mode. As of today, those two registers are > configured to enable all interrupts. Before going to low-power mode, the > AVIC's

Re: [PATCH v2] ARM: imx: avic: set low-power interrupt mask for imx25

On Tue, Feb 27, 2018 at 10:29:15PM +0100, Martin Kaiser wrote: > imx25 contains two registers (LPIMR0 and 1) to define which interrupts > are enabled in low-power mode. As of today, those two registers are > configured to enable all interrupts. Before going to low-power mode, the > AVIC's

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote: > When minimum/maximum values are specified for a sysctl parameter in > the ctl_table structure with proc_dointvec_minmax() handler, an > update > to that parameter will fail with error if the given value is outside > of the required

Re: [PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote: > When minimum/maximum values are specified for a sysctl parameter in > the ctl_table structure with proc_dointvec_minmax() handler, an > update > to that parameter will fail with error if the given value is outside > of the required

[PATCH] soc: qcom: wcnss_ctrl: Fix increment in NV upload

hdr.len includes both the size of the header and the fragment, so using this when stepping through the firmware causes us to skip 16 bytes every chunk of 3072 bytes; causing only the first fragment to actually be valid data. Instead use fragment size steps through the firmware blob. Fixes:

[PATCH] soc: qcom: wcnss_ctrl: Fix increment in NV upload

hdr.len includes both the size of the header and the fragment, so using this when stepping through the firmware causes us to skip 16 bytes every chunk of 3072 bytes; causing only the first fragment to actually be valid data. Instead use fragment size steps through the firmware blob. Fixes:

[PATCH] uprobe: add support for overlayfs

uprobes cannot successfully attach to binaries located in a directory mounted with overlayfs. To verify, create directories for mounting overlayfs (upper,lower,work,merge), move some binary into merge/ and use readelf to obtain some known instruction of the binary. I used /bin/true and the entry

[PATCH] uprobe: add support for overlayfs

uprobes cannot successfully attach to binaries located in a directory mounted with overlayfs. To verify, create directories for mounting overlayfs (upper,lower,work,merge), move some binary into merge/ and use readelf to obtain some known instruction of the binary. I used /bin/true and the entry

Re: [PATCH] ARM: dts: NSP: Fix amount of RAM on BCM958625HR

On 02/27/2018 07:02 AM, Jon Mason wrote: > On Mon, Feb 26, 2018 at 8:03 PM, Florian Fainelli > wrote: >> Jon attempted to fix the amount of RAM on the BCM958625HR in commit >> c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") >> but it seems like we

Re: [PATCH] ARM: dts: NSP: Fix amount of RAM on BCM958625HR

On 02/27/2018 07:02 AM, Jon Mason wrote: > On Mon, Feb 26, 2018 at 8:03 PM, Florian Fainelli > wrote: >> Jon attempted to fix the amount of RAM on the BCM958625HR in commit >> c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board") >> but it seems like we tripped over some

[PATCH] selftests/bpf: Add bpf_probe_read_str to bpf_helpers.h

Using bpf_probe_read_str() from samples/bpf causes compiler warning. e.g. warning: implicit declaration of function 'bpf_probe_read_str' is invalid in C99 [-Wimplicit-function-declaration] num = bpf_probe_read_str(buf, sizeof(buf), ctx->di); ^ 1 warning generated. Add

[PATCH] selftests/bpf: Add bpf_probe_read_str to bpf_helpers.h

Using bpf_probe_read_str() from samples/bpf causes compiler warning. e.g. warning: implicit declaration of function 'bpf_probe_read_str' is invalid in C99 [-Wimplicit-function-declaration] num = bpf_probe_read_str(buf, sizeof(buf), ctx->di); ^ 1 warning generated. Add

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

On 02/27/2018 01:38 PM, Josh Poimboeuf wrote: > On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote: >> 2018-02-27, Josh Poimboeuf: >>> In Documentation/kbuild/kbuild.txt, we have the following environment >>> variables: >>> >>> KCFLAGS >>>

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

On 02/27/2018 01:38 PM, Josh Poimboeuf wrote: > On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote: >> 2018-02-27, Josh Poimboeuf: >>> In Documentation/kbuild/kbuild.txt, we have the following environment >>> variables: >>> >>> KCFLAGS >>>

Re: [PATCH] RDMA/core: reduce IB_POLL_BATCH constant

On 02/27/18 14:15, Max Gurtovoy wrote: -static int __ib_process_cq(struct ib_cq *cq, int budget, struct ib_wc *poll_wc) +static int __ib_process_cq(struct ib_cq *cq, int budget, struct ib_wc *poll_wc, +  int batch)  { -   int i, n, completed = 0; -   struct

Re: [PATCH] RDMA/core: reduce IB_POLL_BATCH constant

On 02/27/18 14:15, Max Gurtovoy wrote: -static int __ib_process_cq(struct ib_cq *cq, int budget, struct ib_wc *poll_wc) +static int __ib_process_cq(struct ib_cq *cq, int budget, struct ib_wc *poll_wc, +  int batch)  { -   int i, n, completed = 0; -   struct

[PATCH] rpmsg: smd: Read remote state from channel info

In some cases the remote processor does not trigger an interrupt when transitioning a channel from OPENING to OPENED state and as such the value of the cached "remote_state" will be stale. Read the state directly from the "channel info" while waiting for the remote to negotiate the channel state

[PATCH] rpmsg: smd: Read remote state from channel info

In some cases the remote processor does not trigger an interrupt when transitioning a channel from OPENING to OPENED state and as such the value of the cached "remote_state" will be stale. Read the state directly from the "channel info" while waiting for the remote to negotiate the channel state

[PATCH v2 5/6] kconfig: invoke oldconfig instead of silentoldconfig from local*config

The purpose of local{yes,mod}config is to arrange the .config file based on actually loaded modules. It is unnecessary to update include/generated/autoconf.h and include/config/* stuff here. They will be automatically updated during the build. Signed-off-by: Masahiro Yamada

[PATCH v2 5/6] kconfig: invoke oldconfig instead of silentoldconfig from local*config

The purpose of local{yes,mod}config is to arrange the .config file based on actually loaded modules. It is unnecessary to update include/generated/autoconf.h and include/config/* stuff here. They will be automatically updated during the build. Signed-off-by: Masahiro Yamada --- Changes in v2:

[PATCH v2 2/6] kconfig: remove unneeded input_mode test in conf()

conf() is never called for listnewconfig / olddefconfig. Signed-off-by: Masahiro Yamada Reviewed-by: Ulf Magnusson --- Changes in v2: None scripts/kconfig/conf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH v2 2/6] kconfig: remove unneeded input_mode test in conf()

conf() is never called for listnewconfig / olddefconfig. Signed-off-by: Masahiro Yamada Reviewed-by: Ulf Magnusson --- Changes in v2: None scripts/kconfig/conf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c index

[PATCH v2 4/6] kconfig: hide irrelevant sub-menus for oldconfig

Historically, "make oldconfig" has changed its behavior several times, quieter or louder. (I attached the history below.) Currently, it is not as quiet as it should be. This commit addresses it. Test Case - ---(Kconfig) menu

[PATCH v2 4/6] kconfig: hide irrelevant sub-menus for oldconfig

Historically, "make oldconfig" has changed its behavior several times, quieter or louder. (I attached the history below.) Currently, it is not as quiet as it should be. This commit addresses it. Test Case - ---(Kconfig) menu

[PATCH v2 6/6] kconfig: rename silentoldconfig to syncconfig

As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a historical misnomer. That commit removed it from help and docs since it is an internal interface. If so, it should be allowed to rename it to something more

[PATCH v2 6/6] kconfig: rename silentoldconfig to syncconfig

As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a historical misnomer. That commit removed it from help and docs since it is an internal interface. If so, it should be allowed to rename it to something more

[PATCH] Bluetooth: btqcomsmd: Fix channel open check

rpmsg_create_ept() returns NULL on error and as such qcom_wcnss_open_channel() does the same. Clarify this in the kernel-doc and correct the error checks in btqcomsmd. Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Cc: sta...@vger.kernel.org Signed-off-by: Bjorn

[PATCH] Bluetooth: btqcomsmd: Fix channel open check

rpmsg_create_ept() returns NULL on error and as such qcom_wcnss_open_channel() does the same. Clarify this in the kernel-doc and correct the error checks in btqcomsmd. Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Cc: sta...@vger.kernel.org Signed-off-by: Bjorn

[PATCH v2 3/6] kconfig: remove redundant input_mode test for check_conf() loop

check_conf() never increments conf_cnt for listnewconfig, so conf_cnt is always zero. In other words, conf_cnt is not zero, "input_mode != listnewconfig" is met. Signed-off-by: Masahiro Yamada Reviewed-by: Ulf Magnusson --- Changes in v2:

[PATCH v2 3/6] kconfig: remove redundant input_mode test for check_conf() loop

check_conf() never increments conf_cnt for listnewconfig, so conf_cnt is always zero. In other words, conf_cnt is not zero, "input_mode != listnewconfig" is met. Signed-off-by: Masahiro Yamada Reviewed-by: Ulf Magnusson --- Changes in v2: None scripts/kconfig/conf.c | 2 +- 1 file changed,

[PATCH v2 1/6] kconfig: do not call check_conf() for olddefconfig

check_conf() traverses the menu tree, but it is completely no-op for olddefconfig because the following if-else block does nothing. if (input_mode == listnewconfig) { ... } else if (input_mode != olddefconfig) { ... } As the help message says, olddefconfig

[PATCH v2 0/6] kconfig: some clean-ups and rename silentoldconfig

Masahiro Yamada (6): kconfig: do not call check_conf() for olddefconfig kconfig: remove unneeded input_mode test in conf() kconfig: remove redundant input_mode test for check_conf() loop kconfig: hide irrelevant sub-menus for oldconfig kconfig: invoke oldconfig instead of silentoldconfig

[PATCH v2 1/6] kconfig: do not call check_conf() for olddefconfig

check_conf() traverses the menu tree, but it is completely no-op for olddefconfig because the following if-else block does nothing. if (input_mode == listnewconfig) { ... } else if (input_mode != olddefconfig) { ... } As the help message says, olddefconfig

[PATCH v2 0/6] kconfig: some clean-ups and rename silentoldconfig

Masahiro Yamada (6): kconfig: do not call check_conf() for olddefconfig kconfig: remove unneeded input_mode test in conf() kconfig: remove redundant input_mode test for check_conf() loop kconfig: hide irrelevant sub-menus for oldconfig kconfig: invoke oldconfig instead of silentoldconfig

[PATCH v3 1/2] iio: light: add driver for bh1730fvc chips

Ambient light sensor that supports visible light and IR measurements and configurable gain/integration time. This is written as an additional driver instead of being added into the existing bh1750 / bh1780 drivers. The bh1730 chip is significantly different from either of these two: * bh1750 is

[PATCH v3 2/2] dt-bindings: iio: light: Add bh1730fvc bindings

Signed-off-by: Pierre Bourdon --- .../devicetree/bindings/iio/light/bh1730.txt | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/bh1730.txt diff --git

[PATCH v3 1/2] iio: light: add driver for bh1730fvc chips

Ambient light sensor that supports visible light and IR measurements and configurable gain/integration time. This is written as an additional driver instead of being added into the existing bh1750 / bh1780 drivers. The bh1730 chip is significantly different from either of these two: * bh1750 is

[PATCH v3 2/2] dt-bindings: iio: light: Add bh1730fvc bindings

Signed-off-by: Pierre Bourdon --- .../devicetree/bindings/iio/light/bh1730.txt | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/bh1730.txt diff --git a/Documentation/devicetree/bindings/iio/light/bh1730.txt

Re: [PATCH] riscv/barrier: Define __smp_{store_release,load_acquire}

On Tue, Feb 27, 2018 at 02:20:37PM -0800, Daniel Lustig wrote: > On 2/27/2018 10:21 AM, Palmer Dabbelt wrote: > > On Mon, 26 Feb 2018 18:24:11 PST (-0800), parri.and...@gmail.com wrote: > >> Introduce __smp_{store_release,load_acquire}, and rely on the generic > >> definitions for

Re: [PATCH] riscv/barrier: Define __smp_{store_release,load_acquire}

On Tue, Feb 27, 2018 at 02:20:37PM -0800, Daniel Lustig wrote: > On 2/27/2018 10:21 AM, Palmer Dabbelt wrote: > > On Mon, 26 Feb 2018 18:24:11 PST (-0800), parri.and...@gmail.com wrote: > >> Introduce __smp_{store_release,load_acquire}, and rely on the generic > >> definitions for

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On Wed, Feb 28, 2018 at 12:00 AM, Mickaël Salaün wrote: > > On 28/02/2018 00:23, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski wrote: >>> On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün wrote: >>> >>> I

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On Wed, Feb 28, 2018 at 12:00 AM, Mickaël Salaün wrote: > > On 28/02/2018 00:23, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski wrote: >>> On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün wrote: >>> >>> I think you're wrong here. Any sane container trying to

[PATCH 1/2] auxdisplay: charlcd: fix x/y address commands

The current version does not parse x/y commands at all. Simplify the x/y command syntax to the one indicated in the comment all along and introduce a parsing function that handles parsing a sequence of one or two subcommands where each subcommand must appear at most once. Signed-off-by: Robert

[PATCH 1/2] auxdisplay: charlcd: fix x/y address commands

The current version does not parse x/y commands at all. Simplify the x/y command syntax to the one indicated in the comment all along and introduce a parsing function that handles parsing a sequence of one or two subcommands where each subcommand must appear at most once. Signed-off-by: Robert

[PATCH 2/2] auxdisplay: charlcd: make home command unshift display

A user has no way of unshifting the display programmatically once shifted. Users cannot rely on ^[[H (home) to result in their message being seen either. Use the actual HOME command 0x02 instead of only returning to x0/y0. Users can still do ^[[Lx0y0; (go to x/y) if they wish to use the 'old' home

[PATCH 2/2] auxdisplay: charlcd: make home command unshift display

A user has no way of unshifting the display programmatically once shifted. Users cannot rely on ^[[H (home) to result in their message being seen either. Use the actual HOME command 0x02 instead of only returning to x0/y0. Users can still do ^[[Lx0y0; (go to x/y) if they wish to use the 'old' home

[PATCH RFC 0/2] auxdisplay: charlcd: fix movement and home commands

I reworked the previous patches 2-4 into these two patches. The first patch proproses a different solution to the movement command parse code that reduces the movement command two at most two movement subcommands (x or y standalone, x followed by y or vice-versa). The second patch add comments in

[PATCH RFC 0/2] auxdisplay: charlcd: fix movement and home commands

I reworked the previous patches 2-4 into these two patches. The first patch proproses a different solution to the movement command parse code that reduces the movement command two at most two movement subcommands (x or y standalone, x followed by y or vice-versa). The second patch add comments in

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