Re: [PATCH v2] ACPI: NFIT: limit string attribute write

2023-07-12 Thread Ben Dooks
On 11/07/2023 16:28, Dave Jiang wrote: On 7/11/23 02:37, Ben Dooks wrote: If we're writing what could be an arbitrary sized string into an attribute we should probably use sysfs_emit() just to be safe. Most of the other attriubtes are some sort of integer so unlikely to be an issue so

Re: [PATCH] ACPI: NFIT: limit string attribute write

2023-07-11 Thread Ben Dooks
On 11/07/2023 10:22, Ben Dooks wrote: If we're writing what could be an arbitrary sized string into an attribute we should probably use sysfs_emit() just to be safe. Most of the other attriubtes are some sort of integer so unlikely to be an issue so not altered at this time. Signed-off-by: Ben

[PATCH v2] ACPI: NFIT: limit string attribute write

2023-07-11 Thread Ben Dooks
If we're writing what could be an arbitrary sized string into an attribute we should probably use sysfs_emit() just to be safe. Most of the other attriubtes are some sort of integer so unlikely to be an issue so not altered at this time. Signed-off-by: Ben Dooks --- v2: - use sysfs_emit

[PATCH] ACPI: NFIT: limit string attribute write

2023-07-11 Thread Ben Dooks
If we're writing what could be an arbitrary sized string into an attribute we should probably use sysfs_emit() just to be safe. Most of the other attriubtes are some sort of integer so unlikely to be an issue so not altered at this time. Signed-off-by: Ben Dooks --- v2: - use sysfs_emit

Re: [PATCH] ACPI: NFIT: limit string attribute write

2023-07-11 Thread Ben Dooks
On 05/07/2023 19:34, Dave Jiang wrote: On 7/4/23 01:17, Ben Dooks wrote: If we're writing what could be an arbitrary sized string into an attribute we should probably use snprintf() just to be safe. Most of the other attriubtes are some sort of integer so unlikely to be an issue so

[PATCH] ACPI: NFIT: limit string attribute write

2023-07-04 Thread Ben Dooks
If we're writing what could be an arbitrary sized string into an attribute we should probably use snprintf() just to be safe. Most of the other attriubtes are some sort of integer so unlikely to be an issue so not altered at this time. Signed-off-by: Ben Dooks --- drivers/acpi/nfit/core.c | 2

[PATCH] ACPICA: actbl2: change to be16/be32 types for big endian data

2023-07-03 Thread Ben Dooks
to restricted __be32 drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32 drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32 drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32 Signed-off-by: Ben Dooks --- drivers/acpi/nfit/core.c | 8 include

[PATCH] ACPI: NFIT: add helper to_nfit_mem() to take device to nfit_mem

2023-07-03 Thread Ben Dooks
Add a quick helper to just do struct device to the struct nfit_mem field it should be referencing. This reduces the number of code lines in some of the followgn code as it removes the intermediate struct nvdimm. Signed-off-by: Ben Dooks --- drivers/acpi/nfit/core.c | 27

[PATCH] nvdimm: make nd_class variable static

2023-06-16 Thread Ben Dooks
The nd_class is not used outside of drivers/nvdimm/bus.c and thus sparse is generating the following warning. Remove this by making it static: drivers/nvdimm/bus.c:28:14: warning: symbol 'nd_class' was not declared. Should it be static? Signed-off-by: Ben Dooks --- drivers/nvdimm/bus.c | 2

[PATCH] nvdimm: make security_show static

2023-06-16 Thread Ben Dooks
. Should it be static? Signed-off-by: Ben Dooks --- drivers/nvdimm/dimm_devs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c index 957f7c3d17ba..1273873582be 100644 --- a/drivers/nvdimm/dimm_devs.c +++ b/drivers/nvdimm

[PATCH] dax: include bus.h for definition of run_dax()

2023-06-16 Thread Ben Dooks
The run_dax() prototype is defined in "bus.h" but drivers/dax/super.c does not include this. Include bus.h to silece the following sparse warning: drivers/dax/super.c:337:6: warning: symbol 'run_dax' was not declared. Should it be static? Signed-off-by: Ben Dooks --- drivers/dax/s

Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl

2021-03-18 Thread Ben Dooks
On 18/03/2021 15:18, Dmitry Vyukov wrote: On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks wrote: On 15/03/2021 11:52, Dmitry Vyukov wrote: On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks wrote: On 14/03/2021 11:03, Dmitry Vyukov wrote: On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov wrote: On Wed

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-18 Thread Ben Dooks
On 18/03/2021 10:05, Dmitry Vyukov wrote: On Thu, Mar 18, 2021 at 10:41 AM Ben Dooks wrote: On 12/03/2021 17:38, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 6:34 PM Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 5:36 PM Ben Dooks wrote: On 12/03/2021 16:34, Ben Dooks wrote: On 12/03

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-18 Thread Ben Dooks
On 12/03/2021 17:38, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 6:34 PM Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 5:36 PM Ben Dooks wrote: On 12/03/2021 16:34, Ben Dooks wrote: On 12/03/2021 16:30, Ben Dooks wrote: On 12/03/2021 15:12, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 2

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-16 Thread Ben Dooks
On 16/03/2021 08:52, Dmitry Vyukov wrote: On Mon, Mar 15, 2021 at 10:38 PM Ben Dooks wrote: On 13/03/2021 07:20, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks wrote: On 12/03/2021 16:25, Alex Ghiti wrote: Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit : On Fri, Mar 12

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-15 Thread Ben Dooks
On 13/03/2021 07:20, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks wrote: On 12/03/2021 16:25, Alex Ghiti wrote: Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit : On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-15 Thread Ben Dooks
On 13/03/2021 07:20, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks wrote: Still no luck for the moment, can't reproduce it locally, my test is maybe not that good (I created threads all day long in order to trigger the put_user of schedule_tail). It may of course depend

Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl

2021-03-15 Thread Ben Dooks
On 15/03/2021 11:52, Dmitry Vyukov wrote: On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks wrote: On 14/03/2021 11:03, Dmitry Vyukov wrote: On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 7:28 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD

Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl

2021-03-15 Thread Ben Dooks
ine to get development work done on it. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-12 Thread Ben Dooks
On 12/03/2021 16:25, Alex Ghiti wrote: Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit : On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-12 Thread Ben Dooks
On 12/03/2021 16:34, Ben Dooks wrote: On 12/03/2021 16:30, Ben Dooks wrote: On 12/03/2021 15:12, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-12 Thread Ben Dooks
On 12/03/2021 16:30, Ben Dooks wrote: On 12/03/2021 15:12, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:    0d7588ab

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-12 Thread Ben Dooks
On 12/03/2021 15:12, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no prototype

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-12 Thread Ben Dooks
re-tried the code seqeunce and ended up retrying the faulting instruction without the SR_SUM bit set. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-11 Thread Ben Dooks
On 11/03/2021 06:52, Dmitry Vyukov wrote: On Thu, Mar 11, 2021 at 7:50 AM Dmitry Vyukov wrote: On Thu, Mar 11, 2021 at 7:40 AM Alex Ghiti wrote: Hi Ben, Le 3/10/21 à 5:24 PM, Ben Dooks a écrit : On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

2021-03-10 Thread Ben Dooks
tp://lists.infradead.org/mailman/listinfo/linux-riscv -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board

2021-03-09 Thread Ben Dooks
gmii"; + phy-handle = <>; + phy0: ethernet-phy@8 { + reg = <8>; + ti,fifo-depth = <0x01>; + }; +}; + + { + status = "okay"; + phy-mode = "sgmii"; + phy-handle = <>; + phy1: ethernet-phy

Re: [PATCH] riscv: Return -EFAULT if copy_to_user() failed in signal.c

2021-03-02 Thread Ben Dooks
fpu) err |= save_fp_state(regs, >sc_fpregs); -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

Re: [PATCH v3 0/2] Let illegal access to user-space memory die

2021-02-01 Thread Ben Dooks
 arch/riscv/mm/fault.c | 28 ++--  1 file changed, 22 insertions(+), 6 deletions(-) Thanks, these will be on for-next when the merge window ends. Just tested this and it seems to be working. -- Ben Dooks http://www.codethink.co.uk/ Senior

Re: [PATCH v1 0/5] Clock and reset improvements for Tegra ALSA drivers

2021-01-15 Thread Ben Dooks
the tegra is the i2s clock slave. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

Re: [PATCH] i2c: tegra-bpmp: ignore DMA safe buffer flag

2021-01-11 Thread Ben Dooks
ent, you can do without the test here. Just doing this would have been fine: flags &= ~I2C_M_DMA_SAFE; -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-11-03 Thread Ben Dooks
On 03/11/2020 18:40, cyril.j...@microchip.com wrote: On 11/3/20 6:28 PM, Ben Dooks wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On 03/11/2020 18:10, cyril.j...@microchip.com wrote: On 11/3/20 3:07 PM, Atish Patra wrote: EXTERNAL EMAIL: Do

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-11-03 Thread Ben Dooks
On 03/11/2020 18:36, Atish Patra wrote: On Tue, Nov 3, 2020 at 10:28 AM Ben Dooks wrote: On 03/11/2020 18:10, cyril.j...@microchip.com wrote: On 11/3/20 3:07 PM, Atish Patra wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Fri, Oct 30

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-11-03 Thread Ben Dooks
On 03/11/2020 18:10, cyril.j...@microchip.com wrote: On 11/3/20 3:07 PM, Atish Patra wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Fri, Oct 30, 2020 at 2:20 PM Ben Dooks wrote: ,snip[ @Cyril : Can we enable both eMMC & sd

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-11-03 Thread Ben Dooks
of the updated firmware with 2GB enabled. Yeah, it is really annoying the boards turned up with a number of issues including the half memory. I assume there will be a new release of HSS and U-boot which at worse can insert new memory nodes into the device tree. -- Ben Dooks

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-11-03 Thread Ben Dooks
uot;; + clocks = <>; + #clock-cells = <1>; + clock-output-names = "cpuclk", "axiclk", "ahbclk", "ENVMclk", "MAC0clk", "MAC1clk", "MMCclk", "TIMERclk", "MMUART0clk", "MMUART1clk", "MMUART2clk", "MMUART3clk", "MMUART4clk", "SPI0clk", "SPI1clk", "I2C0clk", "I2C1clk", "CAN0clk", "CAN1clk", "USBclk", "RESERVED", "RTCclk", "QSPIclk", "GPIO0clk", "GPIO1clk", "GPIO2clk", "DDRCclk", "FIC0clk", "FIC1clk", "FIC2clk", "FIC3clk", "ATHENAclk", "CFMclk"; + }; + H ow about doing something like clock-output-names = "cpuclk", "axiclk", "ahbclk", "ENVMclk", "MAC0clk", /* 0 -4 */ "MAC1clk", "MMCclk", "TIMERclk", "MMUART0clk", "MMUART1clk", /* 5-9 */ this means we can easily work out what clocks are in which index As per the previos email, I'd leave these all populated as coming back and adding ones later is just going to be a pain with merge conflicts. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-10-30 Thread Ben Dooks
On 30/10/2020 07:11, Atish Patra wrote: On Thu, Oct 29, 2020 at 3:24 AM Ben Dooks wrote: On 28/10/2020 23:27, Atish Patra wrote: Add initial DTS for Microchip ICICLE board having only essential devcies (clocks, sdhci, ethernet, serial, etc). Signed-off-by: Atish Patra --- arch/riscv

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-10-30 Thread Ben Dooks
+ arch/riscv/boot/dts/microchip/Makefile| 2 + .../microchip/microchip-icicle-kit-a000.dts | 313 ++ I suggest we split this DTS into two parts: 1. SOC (microchip-polarfire.dtsi) 2. Board (microchip-icicle-kit-a000.dts) I was just going to suggest that. -- Ben Dooks

Re: [RFC PATCH 3/3] RISC-V: Enable Microchip PolarFire ICICLE SoC

2020-10-30 Thread Ben Dooks
with all the necessary support for the polarfire/icicle boards? I so far have updated yocto patches, a rebase to v5.9 and the v17 PCIe patches (which still don't work for us) -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink

Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board

2020-10-29 Thread Ben Dooks
cap-mmc-highspeed; + cap-sd-highspeed; + card-detect-delay = <200>; + sd-uhs-sdr12; + sd-uhs-sdr25; + sd-uhs-sdr50; + sd-uhs-sdr104; +

Re: [PATCH v7 10/10] Drivers: hv: Enable Hyper-V code to be built on ARM64

2020-08-25 Thread Ben Dooks
shouldn't this depend on !CONFIG_CPU_BIG_ENDIAN ? or mark the data __le and have the appropriate accessor functions do the swapping. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html

[tip: timers/urgent] timers/sched_clock: Include local timekeeping.h for missing declarations

2019-10-23 Thread tip-bot2 for Ben Dooks (Codethink)
The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 086ee46b08634a999bcd1707eabe3b0dc1806674 Gitweb: https://git.kernel.org/tip/086ee46b08634a999bcd1707eabe3b0dc1806674 Author:Ben Dooks (Codethink) AuthorDate:Tue, 22 Oct 2019 14:12:26 +01

[PATCH] [V3] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static

2019-10-23 Thread Ben Dooks (Codethink)
? ./include/net/hwbm.h:25:5: warning: symbol 'hwbm_pool_refill' was not declared. Should it be static? ./include/net/hwbm.h:26:5: warning: symbol 'hwbm_pool_add' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: "David S. Miller" Cc: net...@vger.kernel.org

[PATCH] [V2] net: mvneta: make stub functions static inline

2019-10-23 Thread Ben Dooks (Codethink)
it be static? drivers/net/ethernet/marvell/mvneta_bm.h:182:6: warning: symbol 'mvneta_bm_put' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: "David S. Miller" Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org v2: - fixup formatting of chan

[PATCH] xfs: add mising include of xfs_pnfs.h for missing declarations

2019-10-22 Thread Ben Dooks (Codethink)
: warning: symbol 'xfs_fs_get_uuid' was not declared. Should it be static? fs/xfs/xfs_pnfs.c:77:1: warning: symbol 'xfs_fs_map_blocks' was not declared. Should it be static? fs/xfs/xfs_pnfs.c:226:1: warning: symbol 'xfs_fs_commit_blocks' was not declared. Should it be static? Signed-off-by: Ben Dooks

[PATCH] [V2] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static

2019-10-22 Thread Ben Dooks (Codethink)
? ./include/net/hwbm.h:25:5: warning: symbol 'hwbm_pool_refill' was not declared. Should it be static? ./include/net/hwbm.h:26:5: warning: symbol 'hwbm_pool_add' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: "David S. Miller" Cc: net...@vger.kernel.org

Re: [PATCH] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static

2019-10-22 Thread Ben Dooks
On 22/10/2019 16:18, Ben Dooks (Codethink) wrote: If CONFIG_NET_HWBM is not set, then these stub functions in should be declared static to avoid trying to export them from any driver that includes this. Note, add __maybe_unused as the marvell mvneta.c driver will otherwise cause gcc warnings

[PATCH] net: mvneta: make stub functions static inline

2019-10-22 Thread Ben Dooks (Codethink)
it be static? drivers/net/ethernet/marvell/mvneta_bm.h:182:6: warning: symbol 'mvneta_bm_put' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: "David S. Miller" Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethern

[PATCH] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static

2019-10-22 Thread Ben Dooks (Codethink)
? Signed-off-by: Ben Dooks (Codethink) --- Cc: "David S. Miller" Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- include/net/hwbm.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/net/hwbm.h b/include/net/hwbm.h index 81643cf8a1c4..cb

[PATCH] pinctrl: amd: fix __iomem annotation in amd_gpio_irq_handler()

2019-10-22 Thread Ben Dooks (Codethink)
] * drivers/pinctrl/pinctrl-amd.c:587:25: warning: incorrect type in argument 2 (different address spaces) drivers/pinctrl/pinctrl-amd.c:587:25:expected void volatile [noderef] *addr drivers/pinctrl/pinctrl-amd.c:587:25:got unsigned int [usertype] * Signed-off-by: Ben Dooks (Codethink

[PATCH] ipv6: include for missing declarations

2019-10-22 Thread Ben Dooks (Codethink)
'in6_dev_finish_destroy' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: Hideaki YOSHIFUJI Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- net/ipv6/addrconf_core.c | 1 + 1 file changed, 1

[PATCH] timers/sched_clock: include local timekeeping.h for missing declarations

2019-10-22 Thread Ben Dooks (Codethink)
: symbol 'sched_clock_resume' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org --- kernel/time/sched_clock.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c

[PATCH] xdp: fix type of string pointer in __XDP_ACT_SYM_TAB

2019-10-22 Thread Ben Dooks (Codethink)
integer as NULL pointer ./include/trace/events/xdp.h:356:1: warning: Using plain integer as NULL pointer ./include/trace/events/xdp.h:390:1: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks (Codethink) --- Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song

[PATCH] cpu-topology: declare parse_acpi_topology in

2019-10-22 Thread Ben Dooks (Codethink)
The parse_acpi_topology() is not declared anywhere which causes the following sparse warning: drivers/base/arch_topology.c:522:19: warning: symbol 'parse_acpi_topology' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: Sudeep Holla Cc: linux-kernel

Re: [PATCH] RFC: cpu-topology: declare parse_acpi_topology in

2019-10-22 Thread Ben Dooks
On 21/10/2019 17:52, Sudeep Holla wrote: On Mon, Oct 21, 2019 at 05:25:30PM +0100, Ben Dooks (Codethink) wrote: The parse_acpi_topology() is not declared anywhere which causes the following sparse warning: drivers/base/arch_topology.c:522:19: warning: symbol 'parse_acpi_topology

[PATCH] RFC: cpu-topology: declare parse_acpi_topology in

2019-10-21 Thread Ben Dooks (Codethink)
The parse_acpi_topology() is not declared anywhere which causes the following sparse warning: drivers/base/arch_topology.c:522:19: warning: symbol 'parse_acpi_topology' was not declared. Should it be static? RFC: is this the best place to put it? Signed-off-by: Ben Dooks (Codethink) --- Cc

sparse: __pure declaration only

2019-10-18 Thread Ben Dooks
? if not, should sparse be ignoring these. Note: include/linux/bitmap.h:extern bool __pure __bitmap_or_equal(const unsigned long *src1, lib/bitmap.c:bool __bitmap_or_equal(const unsigned long *bitmap1, -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer

Re: [PATCH] ptp_pch: include ethernet driver for external functions

2019-10-18 Thread Ben Dooks
On 18/10/2019 11:51, Ben Dooks (Codethink) wrote: The driver uses a number of functions from the ethernet driver so include the header to remove the following warnings from sparse about undeclared functions: drivers/ptp/ptp_pch.c:182:5: warning: symbol 'pch_ch_control_read' was not declared

[PATCH] ptp_pch: include ethernet driver for external functions

2019-10-18 Thread Ben Dooks (Codethink)
or if not, where should the declarations go? Signed-off-by: Ben Dooks (Codethink) --- Cc: Richard Cochran Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/ptp/ptp_pch.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c index

[PATCH] remoteproc: fix argument 2 of rproc_mem_entry_init

2019-10-17 Thread Ben Dooks (Codethink)
remoteproc/remoteproc_core.c:916:46: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks --- Cc: Ohad Ben-Cohen Cc: Bjorn Andersson Cc: linux-remotep...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/remoteproc/remoteproc_core.c | 5 +++-- 1 file changed, 3

[PATCH] rapidio: fix missing include of

2019-10-17 Thread Ben Dooks (Codethink)
'rio_mport_write_config_32' was not declared. Should it be static? drivers/rapidio/rio-access.c:136:5: warning: symbol 'rio_mport_send_doorbell' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Matt Porter Cc: Alexandre Bounine Cc: linux-kernel@vger.kernel.org --- drivers/rapidio/rio

[PATCH] rapidio: fix missing include of

2019-10-17 Thread Ben Dooks (Codethink)
' was not declared. Should it be static? drivers/rapidio/rio-driver.c:150:5: warning: symbol 'rio_register_driver' was not declared. Should it be static? drivers/rapidio/rio-driver.c:169:6: warning: symbol 'rio_unregister_driver' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Matt

[PATCH] pcmcia: include for pcmcia_parse_tuple

2019-10-17 Thread Ben Dooks (Codethink)
Include for pcmcia_parse_tuple declaration to fix the following sparse warning: drivers/pcmcia/cistpl.c:1287:5: warning: symbol 'pcmcia_parse_tuple' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Dominik Brodowski Cc: Greg Kroah-Hartman Cc: linux-kernel

[PATCH] pcmcia: include cs_internal.h for missing declarations

2019-10-17 Thread Ben Dooks (Codethink)
: symbol 'cb_free' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Dominik Brodowski Cc: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org --- drivers/pcmcia/cardbus.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pcmcia/cardbus.c b/drivers/pcmcia

[PATCH] irqchip/gic-v3-its: fix u64 to __le64 warnings

2019-10-17 Thread Ben Dooks (Codethink)
The its_cmd_block struct can either have u64 or __le64 data in it, so make a anonymous union to remove the sparse warnings when converting to/from these. Signed-off-by: Ben Dooks --- Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: linux-arm-ker...@lists.infradead.org Cc: linux

Re: [PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()

2019-10-17 Thread Ben Dooks
On 16/10/2019 21:28, David Miller wrote: From: "Ben Dooks (Codethink)" Date: Wed, 16 Oct 2019 09:22:05 +0100 The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse

[PATCH] [V2] NFSv4: add declaration of current_stateid

2019-10-16 Thread Ben Dooks (Codethink)
From: Ben Dooks The current_stateid is exported from nfs4state.c but not declared in any of the headers. Add to nfs4_fs.h to remove the following warning: fs/nfs/nfs4state.c:80:20: warning: symbol 'current_stateid' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Trond

Re: [PATCH] NFSv4: add declaration of current_stateid

2019-10-16 Thread Ben Dooks
On 15/10/2019 17:31, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 01:19:53PM +0100, Ben Dooks wrote: The current_stateid is exported from nfs4state.c but not declared in any of the headers. Add to nfs4_fs.h to remove the following warning: I think you also need to remove the extern

Re: [Linux-kernel] [PATCH] net: bpf: add static in net/core/filter.c

2019-10-16 Thread Ben Dooks
On 16/10/2019 14:11, Ben Dooks wrote: On 16/10/2019 14:10, Daniel Borkmann wrote: On Wed, Oct 16, 2019 at 02:02:31PM +0100, Ben Dooks wrote: On 16/10/2019 13:26, Daniel Borkmann wrote: On Wed, Oct 16, 2019 at 12:04:46PM +0100, Ben Dooks (Codethink) wrote: There are a number of structs in net

Re: [PATCH] net: bpf: add static in net/core/filter.c

2019-10-16 Thread Ben Dooks
On 16/10/2019 14:10, Daniel Borkmann wrote: On Wed, Oct 16, 2019 at 02:02:31PM +0100, Ben Dooks wrote: On 16/10/2019 13:26, Daniel Borkmann wrote: On Wed, Oct 16, 2019 at 12:04:46PM +0100, Ben Dooks (Codethink) wrote: There are a number of structs in net/core/filter.c that are not exported

Re: [PATCH] net: bpf: add static in net/core/filter.c

2019-10-16 Thread Ben Dooks
On 16/10/2019 13:26, Daniel Borkmann wrote: On Wed, Oct 16, 2019 at 12:04:46PM +0100, Ben Dooks (Codethink) wrote: There are a number of structs in net/core/filter.c that are not exported or declared outside of the file. Fix the following warnings by making these all static: net/core/filter.c

[PATCH] pstore: make 'pstore_choose_compression' static

2019-10-16 Thread Ben Dooks (Codethink)
The pstore_choose_compression function is not exported so make it static to avoid the following sparse warning: fs/pstore/platform.c:796:13: warning: symbol 'pstore_choose_compression' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Kees Cook Cc: Anton Vorontsov Cc

[PATCH] crypto: atmel - fix data types for __be{32,64}

2019-10-16 Thread Ben Dooks (Codethink)
) drivers/crypto/atmel-aes.c:1888:63:expected unsigned int drivers/crypto/atmel-aes.c:1888:63:got restricted __le32 [usertype] Signed-off-by: Ben Dooks --- Cc: Herbert Xu Cc: "David S. Miller" Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: linux-cry...@vger.

[PATCH] crypto: inside-secure - fix unexported warnings

2019-10-16 Thread Ben Dooks (Codethink)
/inside-secure/safexcel.c:1794:5: warning: symbol 'pcireg_rc' was not declared. Should it be static? drivers/crypto/inside-secure/safexcel.c:1797:5: warning: symbol 'ofreg_rc' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Antoine Tenart Cc: Herbert Xu Cc: "David S. M

[PATCH] RFC: Bluetooth: missed cpu_to_le16 conversion in hci_init4_req

2019-10-16 Thread Ben Dooks (Codethink)
(different base types) net/bluetooth/hci_core.c:846:28:expected restricted __le16 [usertype] tx_time net/bluetooth/hci_core.c:846:28:got unsigned short [usertype] le_max_tx_time Signed-off-by: Ben Dooks --- Cc: Marcel Holtmann Cc: Johan Hedberg Cc: "David S. Miller" Cc: li

[PATCH] kthread: make __kthread_queue_delayed_work static

2019-10-16 Thread Ben Dooks (Codethink)
The __kthread_queue_delayed_work is not exported so make it static, to avoid the following sparse warning: kernel/kthread.c:869:6: warning: symbol '__kthread_queue_delayed_work' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: linux-kernel@vger.kernel.org Cc: torva

[PATCH] net: bpf: type fixes for __be16/__be32

2019-10-16 Thread Ben Dooks (Codethink)
to restricted __be32 net/core/filter.c:242:32: warning: cast to restricted __be32 net/core/filter.c:242:32: warning: cast to restricted __be32 net/core/filter.c:242:32: warning: cast to restricted __be32 Signed-off-by: Ben Dooks --- Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau

[PATCH] net: bpf: add static in net/core/filter.c

2019-10-16 Thread Ben Dooks (Codethink)
' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Jesper Dangaard Brouer Cc: John Fastabend Cc: net...@vger.kernel

[PATCH] char/random: include for add_hwgenerator_randomness

2019-10-16 Thread Ben Dooks (Codethink)
The add_hwgenerator_randomness() is declared in but this is not being included in drivers/char/random.c so fix the following sparse warning by including it: drivers/char/random.c:2489:6: warning: symbol 'add_hwgenerator_randomness' was not declared. Should it be static? Signed-off-by: Ben

[PATCH] fs/direct-io: include internal.h for sb_init_dio_done_wq

2019-10-16 Thread Ben Dooks (Codethink)
The sb_init_dio_done_wq() is declared in internal.h but fs/direct-io.c does not include this file. Fix the warning by including internal.h fs/direct-io.c:612:5: warning: symbol 'sb_init_dio_done_wq' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Alexander Viro Cc

[PATCH] ubifs: fix type of sup->hash_algo

2019-10-16 Thread Ben Dooks (Codethink)
ifs/sb.c:187:32:expected restricted __le16 [usertype] hash_algo fs/ubifs/sb.c:187:32:got int Signed-off-by: Ben Dooks --- Cc: Richard Weinberger Cc: Artem Bityutskiy Cc: Adrian Hunter Cc: linux-...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- fs/ubifs/sb.c | 2 +- 1 f

[PATCH] ubifs: possible missed le64_to_cpu() in journal

2019-10-16 Thread Ben Dooks (Codethink)
: warning: incorrect type in argument 2 (different base types) fs/ubifs/journal.c:902:58:expected unsigned long inum fs/ubifs/journal.c:902:58:got restricted __le64 [usertype] inum Signed-off-by: Ben Dooks --- Cc: Richard Weinberger Cc: Artem Bityutskiy Cc: Adrian Hunter

[PATCH] ubifs: force prandom result to __le32

2019-10-16 Thread Ben Dooks (Codethink)
[usertype] cookie fs/ubifs/journal.c:506:30:got unsigned int Signed-off-by: Ben Dooks --- Cc: Richard Weinberger Cc: Artem Bityutskiy Cc: Adrian Hunter Cc: linux-...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- fs/ubifs/journal.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] fsnotify/fdinfo: exportfs_encode_inode_fh() takes pointer as 4th argument

2019-10-16 Thread Ben Dooks (Codethink)
The call to exportfs_encode_inode_fh() takes an pointer as the 4th argument, so replace the integer 0 with the NULL pointer. This fixes the following sparse warning: fs/notify/fdinfo.c:53:87: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks --- Cc: Jan Kara Cc: Amir

[PATCH] mm: huge_pte_offset() returns pte_t *, not integer

2019-10-16 Thread Ben Dooks (Codethink)
The huge_pte_offset() returns a pte_t *, not an integer so when huge-tlb is off, the replacement inline macro should return a pte_t * too. This fixes the following sparse warning: mm/page_vma_mapped.c:156:29: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks --- Cc: Mike

[PATCH] mm: include for vm_committed_as_batch

2019-10-16 Thread Ben Dooks (Codethink)
mm_init.c needs to include for the definition of vm_committed_as_batch. Fixes the following sparse warning: mm/mm_init.c:141:5: warning: symbol 'vm_committed_as_batch' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Andrew Morton Cc: linux...@kvack.org Cc: linux

Re: [PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()

2019-10-16 Thread Ben Dooks
On 16/10/2019 09:22, Ben Dooks (Codethink) wrote: The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning

[PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()

2019-10-16 Thread Ben Dooks (Codethink)
) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:expected void [noderef] *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:got struct mac_device_info *hw Signed-off-by: Ben Dooks --- Cc: Giuseppe Cavallaro Cc: Alexandre Torgue Cc: Jose Abreu Cc: "Da

Re: [PATCH] PCI: sysfs: remove pci_bridge_groups and pcie_dev_groups

2019-10-16 Thread Ben Dooks
On 16/10/2019 07:28, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 03:00:59PM +0100, Ben Dooks wrote: The pci_bridge_groups and pcie_dev_groups objects are not exported and not used at-all, so remove them to fix the following warnings from sparse: drivers/pci/pci-sysfs.c:1546:30: warning

[PATCH] [V2] PCI: sysfs: remove pci_bridge_groups and pcie_dev_groups

2019-10-16 Thread Ben Dooks (Codethink)
From: Ben Dooks The pci_bridge_groups and pcie_dev_groups objects are not exported and not used at-all, so remove them to fix the following warnings from sparse: drivers/pci/pci-sysfs.c:1546:30: warning: symbol 'pci_bridge_groups' was not declared. Should it be static? drivers/pci/pci-sysfs.c

Re: [PATCH] bus: moxtet: declare moxtet_bus_type

2019-10-16 Thread Ben Dooks
On 15/10/2019 17:32, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 01:25:35PM +0100, Ben Dooks wrote: The moxtet_bus_type object is exported from the bus driver, but not declared. Add a declaration for use and to silence the following warning: The symbol can be marked static instead

Re: [PATCH] PCI: sysfs: remove pci_bridge_groups and pcie_dev_groups

2019-10-16 Thread Ben Dooks
On 16/10/2019 07:28, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 03:00:59PM +0100, Ben Dooks wrote: The pci_bridge_groups and pcie_dev_groups objects are not exported and not used at-all, so remove them to fix the following warnings from sparse: drivers/pci/pci-sysfs.c:1546:30: warning

[PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()

2019-10-15 Thread Ben Dooks (Codethink)
) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:expected void [noderef] *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:got struct mac_device_info *hw Signed-off-by: Ben Dooks --- Cc: Giuseppe Cavallaro Cc: Alexandre Torgue Cc: Jose Abreu Cc: "Da

[PATCH] net: stmmac: make tc_flow_parsers static

2019-10-15 Thread Ben Dooks (Codethink)
The tc_flow_parsers is not used outside of the driver, so make it static to avoid the following sparse warning: drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c:516:3: warning: symbol 'tc_flow_parsers' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Giuseppe Cavallaro

[PATCH] davinci_cpdma: make cpdma_chan_split_pool static

2019-10-15 Thread Ben Dooks (Codethink)
The cpdma_chan_split_pool() function is not used outside of the driver, so make it static to avoid the following sparse warning: drivers/net/ethernet/ti/davinci_cpdma.c:725:5: warning: symbol 'cpdma_chan_split_pool' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc

[PATCH] PCI: mvebu: mvebu_pcie_map_registers __iomem fix

2019-10-15 Thread Ben Dooks (Codethink)
void [noderef] * drivers/pci/controller/pci-mvebu.c:716:31:got void * Signed-off-by: Ben Dooks --- Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel

[PATCH] PCI: mvebu: make mvebu_pci_bridge_emul_ops static

2019-10-15 Thread Ben Dooks (Codethink)
The mvebu_pci_bridge_emul_ops is not exported outside of the driver, so make it static to avoid the following sparse warning: drivers/pci/controller/pci-mvebu.c:557:28: warning: symbol 'mvebu_pci_bridge_emul_ops' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Thomas

[PATCH] pci: iproc-msi: fix __iomem annotation in decode_msi_hwirq()

2019-10-15 Thread Ben Dooks (Codethink)
:expected void const volatile [noderef] *addr drivers/pci/controller/pcie-iproc-msi.c:301:17:got unsigned int [usertype] *[assigned] msg Signed-off-by: Ben Dooks --- Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: Ray Jui Cc: Scott Branden Cc: bcm-kernel-feedback-l

[PATCH 1/2] phy: phy-brcm-usb-init: fix __iomem annotations

2019-10-15 Thread Ben Dooks (Codethink)
/broadcom/phy-brcm-usb-init.c:435:51:expected void [noderef] *addr drivers/phy/broadcom/phy-brcm-usb-init.c:435:51:got void *reg drivers/phy/broadcom/phy-brcm-usb-init.c:422:13: warning: too many warnings Signed-off-by: Ben Dooks --- Cc: Al Cooper Cc: Kishon Vijay Abraham I Cc: linux

[PATCH 2/2] phy: phy-brcm-usb-init: fix use of integer as pointer

2019-10-15 Thread Ben Dooks (Codethink)
The xhci_ec_base variable is a pointer, so don't compare it with an integer. Signed-off-by: Ben Dooks --- Cc: Al Cooper Cc: Kishon Vijay Abraham I Cc: linux-kernel@vger.kernel.org Cc: bcm-kernel-feedback-l...@broadcom.com --- drivers/phy/broadcom/phy-brcm-usb-init.c | 2 +- 1 file changed, 1

  1   2   3   4   5   6   7   >