Re: [PATCH 2/2] media: rc: remove zte zx ir driver
Hi Arnd, On Mon, Mar 01, 2021 at 10:25:22AM +, Sean Young wrote: > On Wed, Jan 20, 2021 at 03:25:42PM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > The zte zx platform is getting removed, so this driver is no > > longer needed. > > I think the keymap should go too. > > drivers/media/rc/keymaps/rc-zx-irdec.c > > Any references to RC_MAP_ZX_IRDEC or rc-zx-irdec Come to think of it, removing the keymap doesn't make a whole lot of sense. There might still be users for the remote. Sean
Re: [PATCH 2/2] media: rc: remove zte zx ir driver
Hi Arnd,
On Wed, Jan 20, 2021 at 03:25:42PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The zte zx platform is getting removed, so this driver is no
> longer needed.
I think the keymap should go too.
drivers/media/rc/keymaps/rc-zx-irdec.c
Any references to RC_MAP_ZX_IRDEC or rc-zx-irdec
Thanks
Sean
>
> Cc: Jun Nie
> Cc: Shawn Guo
> Signed-off-by: Arnd Bergmann
> ---
> .../devicetree/bindings/media/zx-irdec.txt| 14 --
> drivers/media/rc/Kconfig | 11 --
> drivers/media/rc/Makefile | 1 -
> drivers/media/rc/zx-irdec.c | 181 --
> 4 files changed, 207 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/zx-irdec.txt
> delete mode 100644 drivers/media/rc/zx-irdec.c
>
> diff --git a/Documentation/devicetree/bindings/media/zx-irdec.txt
> b/Documentation/devicetree/bindings/media/zx-irdec.txt
> deleted file mode 100644
> index 295b9fab593e..
> --- a/Documentation/devicetree/bindings/media/zx-irdec.txt
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -IR Decoder (IRDEC) on ZTE ZX family SoCs
> -
> -Required properties:
> - - compatible: Should be "zte,zx296718-irdec".
> - - reg: Physical base address and length of IRDEC registers.
> - - interrupts: Interrupt number of IRDEC.
> -
> -Exmaples:
> -
> - irdec: ir-decoder@111000 {
> - compatible = "zte,zx296718-irdec";
> - reg = <0x111000 0x1000>;
> - interrupts = ;
> - };
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 39bc75cc1848..afeef7d99a5a 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -509,17 +509,6 @@ config RC_XBOX_DVD
> To compile this driver as a module, choose M here: the module will be
> called xbox_remote.
>
> -config IR_ZX
> - tristate "ZTE ZX IR remote control"
> - depends on RC_CORE
> - depends on ARCH_ZX || COMPILE_TEST
> - help
> -Say Y if you want to use the IR remote control available
> -on ZTE ZX family SoCs.
> -
> -To compile this driver as a module, choose M here: the
> -module will be called zx-irdec.
> -
> config IR_TOY
> tristate "Infrared Toy and IR Droid"
> depends on RC_CORE
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index f46a72071a7b..23eb7d43d2ff 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -47,6 +47,5 @@ obj-$(CONFIG_IR_IMG) += img-ir/
> obj-$(CONFIG_IR_SERIAL) += serial_ir.o
> obj-$(CONFIG_IR_SIR) += sir_ir.o
> obj-$(CONFIG_IR_MTK) += mtk-cir.o
> -obj-$(CONFIG_IR_ZX) += zx-irdec.o
> obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o
> obj-$(CONFIG_IR_TOY) += ir_toy.o
> diff --git a/drivers/media/rc/zx-irdec.c b/drivers/media/rc/zx-irdec.c
> deleted file mode 100644
> index 948ad90ae5d8..
> --- a/drivers/media/rc/zx-irdec.c
> +++ /dev/null
> @@ -1,181 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/*
> - * Copyright (C) 2017 Sanechips Technology Co., Ltd.
> - * Copyright 2017 Linaro Ltd.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -
> -#define DRIVER_NAME "zx-irdec"
> -
> -#define ZX_IR_ENABLE 0x04
> -#define ZX_IREN BIT(0)
> -#define ZX_IR_CTRL 0x08
> -#define ZX_DEGL_MASK GENMASK(21, 20)
> -#define ZX_DEGL_VALUE(x) (((x) << 20) & ZX_DEGL_MASK)
> -#define ZX_WDBEGIN_MASK GENMASK(18, 8)
> -#define ZX_WDBEGIN_VALUE(x) (((x) << 8) & ZX_WDBEGIN_MASK)
> -#define ZX_IR_INTEN 0x10
> -#define ZX_IR_INTSTCLR 0x14
> -#define ZX_IR_CODE 0x30
> -#define ZX_IR_CNUM 0x34
> -#define ZX_NECRPTBIT(16)
> -
> -struct zx_irdec {
> - void __iomem *base;
> - struct rc_dev *rcd;
> -};
> -
> -static void zx_irdec_set_mask(struct zx_irdec *irdec, unsigned int reg,
> - u32 mask, u32 value)
> -{
> - u32 data;
> -
> - data = readl(irdec->base + reg);
> - data &= ~mask;
> - data |= value & mask;
> - writel(data, irdec->base + reg);
> -}
> -
> -static irqreturn_t zx_irdec_irq(int irq, void *dev_id)
> -{
> - struct zx_irdec *irdec = dev_id;
> - u8 address, not_address;
> - u8 command, not_command;
> - u32 rawcode, scancode;
> - enum rc_proto rc_proto;
> -
> - /* Clear interrupt */
> - writel(1, irdec->base + ZX_IR_INTSTCLR);
> -
> - /* Check repeat frame */
> - if (readl(irdec->base + ZX_IR_CNUM) & ZX_NECRPT) {
> - rc_repeat(irdec->rcd);
> - goto done;
> - }
> -
> - rawcode = readl(irdec->base + ZX_IR_CODE);
> - not_command = (rawcode >> 24) & 0xff;
> - command = (rawcode >> 16) & 0xff;
> - not_address = (rawcode >> 8) & 0xff;
> - address = rawcode & 0xff;
> -
> - scancode = ir_nec_bytes_to_scancode(address, not_address,
> -
Re: [PATCH 1/2] media: rc: remove tango ir driver
Hi Arnd,
On Thu, Jan 21, 2021 at 01:57:28PM +, Måns Rullgård wrote:
> Arnd Bergmann writes:
>
> > From: Arnd Bergmann
> >
> > The tango platform is getting removed, so the driver is no
> > longer needed.
> >
> > Cc: Marc Gonzalez
> > Cc: Mans Rullgard
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/media/rc/Kconfig| 10 --
> > drivers/media/rc/Makefile | 1 -
> > drivers/media/rc/tango-ir.c | 267
> > 3 files changed, 278 deletions(-)
> > delete mode 100644 drivers/media/rc/tango-ir.c
>
> The DT binding can go too.
Please can we have a patch which also removes all of:
Documentation/devicetree/bindings/media/tango-ir.txt
drivers/media/rc/keymaps/rc-tango.c
Any references to RC_MAP_TANGO and rc-tango.
Thanks
Sean
>
> Otherwise:
>
> Acked-by: Mans Rullgard
>
>
> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> > index 2c0ee2e5b446..39bc75cc1848 100644
> > --- a/drivers/media/rc/Kconfig
> > +++ b/drivers/media/rc/Kconfig
> > @@ -497,16 +497,6 @@ config IR_SIR
> >To compile this driver as a module, choose M here: the module will
> >be called sir-ir.
> >
> > -config IR_TANGO
> > - tristate "Sigma Designs SMP86xx IR decoder"
> > - depends on RC_CORE
> > - depends on ARCH_TANGO || COMPILE_TEST
> > - help
> > - Adds support for the HW IR decoder embedded on Sigma Designs
> > - Tango-based systems (SMP86xx, SMP87xx).
> > - The HW decoder supports NEC, RC-5, RC-6 IR protocols.
> > - When compiled as a module, look for tango-ir.
> > -
> > config RC_XBOX_DVD
> > tristate "Xbox DVD Movie Playback Kit"
> > depends on RC_CORE
> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> > index 5bb2932ab119..f46a72071a7b 100644
> > --- a/drivers/media/rc/Makefile
> > +++ b/drivers/media/rc/Makefile
> > @@ -48,6 +48,5 @@ obj-$(CONFIG_IR_SERIAL) += serial_ir.o
> > obj-$(CONFIG_IR_SIR) += sir_ir.o
> > obj-$(CONFIG_IR_MTK) += mtk-cir.o
> > obj-$(CONFIG_IR_ZX) += zx-irdec.o
> > -obj-$(CONFIG_IR_TANGO) += tango-ir.o
> > obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o
> > obj-$(CONFIG_IR_TOY) += ir_toy.o
> > diff --git a/drivers/media/rc/tango-ir.c b/drivers/media/rc/tango-ir.c
> > deleted file mode 100644
> > index b8eb5bc4d9be..
> > --- a/drivers/media/rc/tango-ir.c
> > +++ /dev/null
> > @@ -1,267 +0,0 @@
> > -// SPDX-License-Identifier: GPL-2.0-or-later
> > -/*
> > - * Copyright (C) 2015 Mans Rullgard
> > - */
> > -
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -
> > -#define DRIVER_NAME "tango-ir"
> > -
> > -#define IR_NEC_CTRL0x00
> > -#define IR_NEC_DATA0x04
> > -#define IR_CTRL0x08
> > -#define IR_RC5_CLK_DIV 0x0c
> > -#define IR_RC5_DATA0x10
> > -#define IR_INT 0x14
> > -
> > -#define NEC_TIME_BASE 560
> > -#define RC5_TIME_BASE 1778
> > -
> > -#define RC6_CTRL 0x00
> > -#define RC6_CLKDIV 0x04
> > -#define RC6_DATA0 0x08
> > -#define RC6_DATA1 0x0c
> > -#define RC6_DATA2 0x10
> > -#define RC6_DATA3 0x14
> > -#define RC6_DATA4 0x18
> > -
> > -#define RC6_CARRIER36000
> > -#define RC6_TIME_BASE 16
> > -
> > -#define NEC_CAP(n) ((n) << 24)
> > -#define GPIO_SEL(n)((n) << 16)
> > -#define DISABLE_NEC(BIT(4) | BIT(8))
> > -#define ENABLE_RC5 (BIT(0) | BIT(9))
> > -#define ENABLE_RC6 (BIT(0) | BIT(7))
> > -#define ACK_IR_INT (BIT(0) | BIT(1))
> > -#define ACK_RC6_INT(BIT(31))
> > -
> > -#define NEC_ANY (RC_PROTO_BIT_NEC | RC_PROTO_BIT_NECX | RC_PROTO_BIT_NEC32)
> > -
> > -struct tango_ir {
> > - void __iomem *rc5_base;
> > - void __iomem *rc6_base;
> > - struct rc_dev *rc;
> > - struct clk *clk;
> > -};
> > -
> > -static void tango_ir_handle_nec(struct tango_ir *ir)
> > -{
> > - u32 v, code;
> > - enum rc_proto proto;
> > -
> > - v = readl_relaxed(ir->rc5_base + IR_NEC_DATA);
> > - if (!v) {
> > - rc_repeat(ir->rc);
> > - return;
> > - }
> > -
> > - code = ir_nec_bytes_to_scancode(v, v >> 8, v >> 16, v >> 24, );
> > - rc_keydown(ir->rc, proto, code, 0);
> > -}
> > -
> > -static void tango_ir_handle_rc5(struct tango_ir *ir)
> > -{
> > - u32 data, field, toggle, addr, cmd, code;
> > -
> > - data = readl_relaxed(ir->rc5_base + IR_RC5_DATA);
> > - if (data & BIT(31))
> > - return;
> > -
> > - field = data >> 12 & 1;
> > - toggle = data >> 11 & 1;
> > - addr = data >> 6 & 0x1f;
> > - cmd = (data & 0x3f) | (field ^ 1) << 6;
> > -
> > - code = RC_SCANCODE_RC5(addr, cmd);
> > - rc_keydown(ir->rc, RC_PROTO_RC5, code, toggle);
> > -}
> > -
> > -static void tango_ir_handle_rc6(struct tango_ir *ir)
> > -{
> > - u32 data0, data1, toggle, mode, addr, cmd, code;
> > -
> > - data0 = readl_relaxed(ir->rc6_base + RC6_DATA0);
> > - data1 = readl_relaxed(ir->rc6_base + RC6_DATA1);
> > -
> > - mode = data0 >> 1 & 7;
>
Re: [PATCH 2/2] media: dvb-usb: Fix use-after-free access
Hi Takashi,
On Fri, Jan 22, 2021 at 04:47:44PM +0100, Robert Foss wrote:
> Hey Takashi,
>
> This patch is generating a checkpatch warning, but I think it is
> spurious and can be ignored.
The checkpatch warning isn't superious and should really be corrected.
>
> Other than that, this looks good to me.
> Reviewed-by: Robert Foss
>
> On Wed, 20 Jan 2021 at 12:51, Takashi Iwai wrote:
> >
> > dvb_usb_device_init() copies the properties to the own data, so that
> > the callers can release the original properties later (as done in the
> > commit 299c7007e936 "media: dw2102: Fix memleak on sequence of
> > probes"). However, it also stores dev->desc pointer that is a
> > reference to the original properties data. Since dev->desc is
> > referred later, it may result in use-after-free, in the worst case,
> > leading to a kernel Oops as reported.
> >
> > This patch addresses the problem by allocating and copying the
> > properties at first, then get the desc from the copied properties.
> >
> > Reported-and-tested-by: Stefan Seyfried
> > BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1181104
> > Cc:
> > Signed-off-by: Takashi Iwai
Thank you for your patch. Unfortunately, it depends on the first patch
in the series, which I think has problems (see email about this).
Thanks
Sean
> > ---
> > drivers/media/usb/dvb-usb/dvb-usb-init.c | 23 +--
> > 1 file changed, 13 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c
> > b/drivers/media/usb/dvb-usb/dvb-usb-init.c
> > index 5befec87f26a..07ff9b4d2f34 100644
> > --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c
> > +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c
> > @@ -255,27 +255,30 @@ int dvb_usb_device_init(struct usb_interface *intf,
> > if (du != NULL)
> > *du = NULL;
> >
> > - if ((desc = dvb_usb_find_device(udev, props, )) == NULL) {
> > + d = kzalloc(sizeof(struct dvb_usb_device), GFP_KERNEL);
> > + if (!d) {
> > + err("no memory for 'struct dvb_usb_device'");
> > + return -ENOMEM;
> > + }
> > +
> > + memcpy(>props, props, sizeof(struct dvb_usb_device_properties));
> > +
> > + desc = dvb_usb_find_device(udev, >props, );
> > + if (!desc) {
> > deb_err("something went very wrong, device was not found in
> > current device list - let's see what comes next.\n");
> > - return -ENODEV;
> > + ret = -ENODEV;
> > + goto error;
> > }
> >
> > if (cold) {
> > info("found a '%s' in cold state, will try to load a
> > firmware", desc->name);
> > ret = dvb_usb_download_firmware(udev, props);
> > if (!props->no_reconnect || ret != 0)
> > - return ret;
> > + goto error;
> > }
> >
> > info("found a '%s' in warm state.", desc->name);
> > - d = kzalloc(sizeof(struct dvb_usb_device), GFP_KERNEL);
> > - if (d == NULL) {
> > - err("no memory for 'struct dvb_usb_device'");
> > - return -ENOMEM;
> > - }
> > -
> > d->udev = udev;
> > - memcpy(>props, props, sizeof(struct dvb_usb_device_properties));
> > d->desc = desc;
> > d->owner = owner;
> >
> > --
> > 2.26.2
> >
Re: [PATCH 1/2] media: dvb-usb: Fix memory leak at error in dvb_usb_device_init()
On Wed, Jan 20, 2021 at 11:20:56AM +0100, Takashi Iwai wrote:
> dvb_usb_device_init() allocates a dvb_usb_device object, but it
> doesn't release it even when returning an error. The callers don't
> seem caring it as well, hence those memories are leaked.
>
> This patch assures releasing the memory at the error path in
> dvb_usb_device_init(). Also it makes sure that USB intfdata is reset
> and don't return the bogus pointer to the caller at the error path,
> too.
>
> Cc:
> Signed-off-by: Takashi Iwai
> ---
> drivers/media/usb/dvb-usb/dvb-usb-init.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c
> b/drivers/media/usb/dvb-usb/dvb-usb-init.c
> index c1a7634e27b4..5befec87f26a 100644
> --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c
> +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c
> @@ -281,15 +281,21 @@ int dvb_usb_device_init(struct usb_interface *intf,
>
> usb_set_intfdata(intf, d);
>
> - if (du != NULL)
> + ret = dvb_usb_init(d, adapter_nums);
dvb_usb_init() has different errors paths.
1. It can return -ENOMEM if it cannot kzalloc(). No other side affects.
2. It can return an error if dvb_usb_i2c_init() or dvb_usb_adapter_init()
fails. In this case, dvb_usb_exit() is called, which frees
struct dvb_usb_device*
In the last case we now have a double free.
Sean
> + if (ret) {
> + info("%s error while loading driver (%d)", desc->name, ret);
> + goto error;
> + }
> +
> + if (du)
> *du = d;
>
> - ret = dvb_usb_init(d, adapter_nums);
> + info("%s successfully initialized and connected.", desc->name);
> + return 0;
>
> - if (ret == 0)
> - info("%s successfully initialized and connected.", desc->name);
> - else
> - info("%s error while loading driver (%d)", desc->name, ret);
> + error:
> + usb_set_intfdata(intf, NULL);
> + kfree(d);
> return ret;
> }
> EXPORT_SYMBOL(dvb_usb_device_init);
> --
> 2.26.2
Re: [PATCH] media: rc: select CONFIG_BITREVERSE where needed
On Fri, Dec 04, 2020 at 12:17:03AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > A number of remote control drivers require the bitreverse > helper, and run into a link error when it is disabled: > > arm-linux-gnueabi-ld: drivers/media/rc/img-ir/img-ir-nec.o: in function > `img_ir_nec_scancode': > img-ir-nec.c:(.text+0x10c): undefined reference to `byte_rev_table' > arm-linux-gnueabi-ld: drivers/media/rc/img-ir/img-ir-nec.o: in function > `img_ir_nec_filter': > img-ir-nec.c:(.text+0x2dc): undefined reference to `byte_rev_table' > arm-linux-gnueabi-ld: drivers/media/usb/cx231xx/cx231xx-input.o: in function > `get_key_isdbt': > cx231xx-input.c:(.text+0x38c): undefined reference to `byte_rev_table' > arm-linux-gnueabi-ld: drivers/media/usb/em28xx/em28xx-input.o: in function > `em28xx_get_key_em_haup': > em28xx-input.c:(.text+0x1704): undefined reference to `byte_rev_table' > Acked-by: Sean Young Thanks Sean > Signed-off-by: Arnd Bergmann > --- > drivers/media/rc/Kconfig | 2 ++ > drivers/media/rc/img-ir/Kconfig | 1 + > drivers/media/usb/cx231xx/Kconfig | 1 + > drivers/media/usb/em28xx/Kconfig | 1 + > 4 files changed, 5 insertions(+) > > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > index 2c0ee2e5b446..8a4b4040be45 100644 > --- a/drivers/media/rc/Kconfig > +++ b/drivers/media/rc/Kconfig > @@ -92,6 +92,7 @@ config IR_SONY_DECODER > config IR_SANYO_DECODER > tristate "Enable IR raw decoder for the Sanyo protocol" > depends on RC_CORE > + select BITREVERSE > > help > Enable this option if you have an infrared remote control which > @@ -101,6 +102,7 @@ config IR_SANYO_DECODER > config IR_SHARP_DECODER > tristate "Enable IR raw decoder for the Sharp protocol" > depends on RC_CORE > + select BITREVERSE > > help > Enable this option if you have an infrared remote control which > diff --git a/drivers/media/rc/img-ir/Kconfig b/drivers/media/rc/img-ir/Kconfig > index 5c0508f2719f..a80cfcd87a95 100644 > --- a/drivers/media/rc/img-ir/Kconfig > +++ b/drivers/media/rc/img-ir/Kconfig > @@ -30,6 +30,7 @@ config IR_IMG_HW > config IR_IMG_NEC > bool "NEC protocol support" > depends on IR_IMG_HW > + select BITREVERSE > help > Say Y here to enable support for the NEC, extended NEC, and 32-bit > NEC protocols in the ImgTec infrared decoder block. > diff --git a/drivers/media/usb/cx231xx/Kconfig > b/drivers/media/usb/cx231xx/Kconfig > index 2fe2b2d335ba..b80661b8375f 100644 > --- a/drivers/media/usb/cx231xx/Kconfig > +++ b/drivers/media/usb/cx231xx/Kconfig > @@ -18,6 +18,7 @@ config VIDEO_CX231XX_RC > bool "Conexant cx231xx Remote Controller additional support" > depends on RC_CORE=y || RC_CORE=VIDEO_CX231XX > depends on VIDEO_CX231XX > + select BITREVERSE > default y > help > cx231xx hardware has a builtin RX/TX support. However, a few > diff --git a/drivers/media/usb/em28xx/Kconfig > b/drivers/media/usb/em28xx/Kconfig > index f2031a933e54..8a24731b373a 100644 > --- a/drivers/media/usb/em28xx/Kconfig > +++ b/drivers/media/usb/em28xx/Kconfig > @@ -77,5 +77,6 @@ config VIDEO_EM28XX_RC > depends on VIDEO_EM28XX > depends on !(RC_CORE=m && VIDEO_EM28XX=y) > default VIDEO_EM28XX > + select BITREVERSE > help > Enables Remote Controller support on em28xx driver. > -- > 2.27.0
Re: [PATCH v2 0/4] media: sunxi-cir: Cleanup and power management
On Mon, Jan 18, 2021 at 12:00:44AM -0600, Samuel Holland wrote: > This series cleans up some dead code in the sunxi-cir driver and adds > system power management hooks. > > --- > Changes from v1: > - Unregister the RC device first thing in sunxi_ir_remove() [3] > Thanks. I've tested it on my Cubieboard1 and everything looks fine. I've applied it to my tree. Sean > Samuel Holland (4): > media: sunxi-cir: Clean up dead register writes > media: sunxi-cir: Remove unnecessary spinlock > media: sunxi-cir: Factor out hardware initialization > media: sunxi-cir: Implement suspend/resume/shutdown callbacks > > drivers/media/rc/sunxi-cir.c | 169 --- > 1 file changed, 95 insertions(+), 74 deletions(-) > > -- > 2.26.2
Re: [PATCH 3/4] media: sunxi-cir: Factor out hardware initialization
Hi Samuel,
On Wed, Jan 13, 2021 at 09:00:20AM -0600, Samuel Holland wrote:
> On 1/13/21 8:36 AM, Sean Young wrote:
> > On Tue, Jan 12, 2021 at 10:51:31PM -0600, Samuel Holland wrote:
> >> In preparation for adding suspend/resume hooks, factor out the hardware
> >> initialization from the driver probe/remove functions.
> >>
> >> The timeout programmed during init is taken from the `struct rc_dev` so
> >> it is maintained across an exit/init cycle.
> >>
> >> This resolves some trivial issues with the probe function: throwing away
> >> the error from clk_prepare_enable and using the wrong type for the
> >> temporary register value.
> >>
> >> Signed-off-by: Samuel Holland
> >> ---
> >> drivers/media/rc/sunxi-cir.c | 128 ---
> >> 1 file changed, 74 insertions(+), 54 deletions(-)
> >>
> >> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> >> index 48be400421cd..ccb9d6b4225d 100644
> >> --- a/drivers/media/rc/sunxi-cir.c
> >> +++ b/drivers/media/rc/sunxi-cir.c
> >> @@ -169,10 +169,74 @@ static int sunxi_ir_set_timeout(struct rc_dev
> >> *rc_dev, unsigned int timeout)
> >>return 0;
> >> }
> >>
> >> +static int sunxi_ir_hw_init(struct device *dev)
> >> +{
> >> + struct sunxi_ir *ir = dev_get_drvdata(dev);
> >> + u32 tmp;
> >> + int ret;
> >> +
> >> + ret = reset_control_deassert(ir->rst);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ret = clk_prepare_enable(ir->apb_clk);
> >> + if (ret) {
> >> + dev_err(dev, "failed to enable apb clk\n");
> >> + goto exit_assert_reset;
> >> + }
> >> +
> >> + ret = clk_prepare_enable(ir->clk);
> >> + if (ret) {
> >> + dev_err(dev, "failed to enable ir clk\n");
> >> + goto exit_disable_apb_clk;
> >> + }
> >> +
> >> + /* Enable CIR Mode */
> >> + writel(REG_CTL_MD, ir->base + SUNXI_IR_CTL_REG);
> >> +
> >> + /* Set noise threshold and idle threshold */
> >> + sunxi_ir_set_timeout(ir->rc, ir->rc->timeout);
>
> Initializing ir->rc->timeout in .probe is needed because of this line.
> As the changelog mentions, this reprograms the user-configured timeout
> after an exit/init (suspend/resume) cycle. It needs some default value
> the first time, when called from .probe.
Yes, you're completely right. Sorry about that.
> >> +
> >> + /* Invert Input Signal */
> >> + writel(REG_RXCTL_RPPI, ir->base + SUNXI_IR_RXCTL_REG);
> >> +
> >> + /* Clear All Rx Interrupt Status */
> >> + writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
> >> +
> >> + /*
> >> + * Enable IRQ on overflow, packet end, FIFO available with trigger
> >> + * level
> >> + */
> >> + writel(REG_RXINT_ROI_EN | REG_RXINT_RPEI_EN |
> >> + REG_RXINT_RAI_EN | REG_RXINT_RAL(ir->fifo_size / 2 - 1),
> >> + ir->base + SUNXI_IR_RXINT_REG);
> >> +
> >> + /* Enable IR Module */
> >> + tmp = readl(ir->base + SUNXI_IR_CTL_REG);
> >> + writel(tmp | REG_CTL_GEN | REG_CTL_RXEN, ir->base + SUNXI_IR_CTL_REG);
> >> +
> >> + return 0;
> >> +
> >> +exit_disable_apb_clk:
> >> + clk_disable_unprepare(ir->apb_clk);
> >> +exit_assert_reset:
> >> + reset_control_assert(ir->rst);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +static void sunxi_ir_hw_exit(struct device *dev)
> >> +{
> >> + struct sunxi_ir *ir = dev_get_drvdata(dev);
> >> +
> >> + clk_disable_unprepare(ir->clk);
> >> + clk_disable_unprepare(ir->apb_clk);
> >> + reset_control_assert(ir->rst);
> >> +}
> >> +
> >> static int sunxi_ir_probe(struct platform_device *pdev)
> >> {
> >>int ret = 0;
> >> - unsigned long tmp = 0;
> >>
> >>struct device *dev = >dev;
> >>struct device_node *dn = dev->of_node;
> >> @@ -213,43 +277,26 @@ static int sunxi_ir_probe(struct platform_device
> >> *pdev)
> >>ir->rst = devm_reset_control_get_exclusive(dev, NULL);
> >>if (IS_ERR(ir->rst))
> >>return PTR_ERR(ir->rst);
> >> - ret = reset_co
Re: [PATCH 3/4] media: sunxi-cir: Factor out hardware initialization
On Tue, Jan 12, 2021 at 10:51:31PM -0600, Samuel Holland wrote:
> In preparation for adding suspend/resume hooks, factor out the hardware
> initialization from the driver probe/remove functions.
>
> The timeout programmed during init is taken from the `struct rc_dev` so
> it is maintained across an exit/init cycle.
>
> This resolves some trivial issues with the probe function: throwing away
> the error from clk_prepare_enable and using the wrong type for the
> temporary register value.
>
> Signed-off-by: Samuel Holland
> ---
> drivers/media/rc/sunxi-cir.c | 128 ---
> 1 file changed, 74 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> index 48be400421cd..ccb9d6b4225d 100644
> --- a/drivers/media/rc/sunxi-cir.c
> +++ b/drivers/media/rc/sunxi-cir.c
> @@ -169,10 +169,74 @@ static int sunxi_ir_set_timeout(struct rc_dev *rc_dev,
> unsigned int timeout)
> return 0;
> }
>
> +static int sunxi_ir_hw_init(struct device *dev)
> +{
> + struct sunxi_ir *ir = dev_get_drvdata(dev);
> + u32 tmp;
> + int ret;
> +
> + ret = reset_control_deassert(ir->rst);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(ir->apb_clk);
> + if (ret) {
> + dev_err(dev, "failed to enable apb clk\n");
> + goto exit_assert_reset;
> + }
> +
> + ret = clk_prepare_enable(ir->clk);
> + if (ret) {
> + dev_err(dev, "failed to enable ir clk\n");
> + goto exit_disable_apb_clk;
> + }
> +
> + /* Enable CIR Mode */
> + writel(REG_CTL_MD, ir->base + SUNXI_IR_CTL_REG);
> +
> + /* Set noise threshold and idle threshold */
> + sunxi_ir_set_timeout(ir->rc, ir->rc->timeout);
> +
> + /* Invert Input Signal */
> + writel(REG_RXCTL_RPPI, ir->base + SUNXI_IR_RXCTL_REG);
> +
> + /* Clear All Rx Interrupt Status */
> + writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
> +
> + /*
> + * Enable IRQ on overflow, packet end, FIFO available with trigger
> + * level
> + */
> + writel(REG_RXINT_ROI_EN | REG_RXINT_RPEI_EN |
> +REG_RXINT_RAI_EN | REG_RXINT_RAL(ir->fifo_size / 2 - 1),
> +ir->base + SUNXI_IR_RXINT_REG);
> +
> + /* Enable IR Module */
> + tmp = readl(ir->base + SUNXI_IR_CTL_REG);
> + writel(tmp | REG_CTL_GEN | REG_CTL_RXEN, ir->base + SUNXI_IR_CTL_REG);
> +
> + return 0;
> +
> +exit_disable_apb_clk:
> + clk_disable_unprepare(ir->apb_clk);
> +exit_assert_reset:
> + reset_control_assert(ir->rst);
> +
> + return ret;
> +}
> +
> +static void sunxi_ir_hw_exit(struct device *dev)
> +{
> + struct sunxi_ir *ir = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(ir->clk);
> + clk_disable_unprepare(ir->apb_clk);
> + reset_control_assert(ir->rst);
> +}
> +
> static int sunxi_ir_probe(struct platform_device *pdev)
> {
> int ret = 0;
> - unsigned long tmp = 0;
>
> struct device *dev = >dev;
> struct device_node *dn = dev->of_node;
> @@ -213,43 +277,26 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> ir->rst = devm_reset_control_get_exclusive(dev, NULL);
> if (IS_ERR(ir->rst))
> return PTR_ERR(ir->rst);
> - ret = reset_control_deassert(ir->rst);
> - if (ret)
> - return ret;
> }
>
> ret = clk_set_rate(ir->clk, b_clk_freq);
> if (ret) {
> dev_err(dev, "set ir base clock failed!\n");
> - goto exit_reset_assert;
> + return ret;
> }
> dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
>
> - if (clk_prepare_enable(ir->apb_clk)) {
> - dev_err(dev, "try to enable apb_ir_clk failed\n");
> - ret = -EINVAL;
> - goto exit_reset_assert;
> - }
> -
> - if (clk_prepare_enable(ir->clk)) {
> - dev_err(dev, "try to enable ir_clk failed\n");
> - ret = -EINVAL;
> - goto exit_clkdisable_apb_clk;
> - }
> -
> /* IO */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> ir->base = devm_ioremap_resource(dev, res);
> if (IS_ERR(ir->base)) {
> - ret = PTR_ERR(ir->base);
> - goto exit_clkdisable_clk;
> + return PTR_ERR(ir->base);
> }
>
> ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
> if (!ir->rc) {
> dev_err(dev, "failed to allocate device\n");
> - ret = -ENOMEM;
> - goto exit_clkdisable_clk;
> + return -ENOMEM;
> }
>
> ir->rc->priv = ir;
> @@ -265,6 +312,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
> /* Frequency after IR internal divider with sample period in us */
> ir->rc->rx_resolution = (USEC_PER_SEC /
Re: [PATCH 1/4] media: sunxi-cir: Clean up dead register writes
On Tue, Jan 12, 2021 at 10:51:29PM -0600, Samuel Holland wrote:
> The register writes during driver removal occur after the device is
> already put back in reset, so they never had any effect.
>
> Signed-off-by: Samuel Holland
> ---
> drivers/media/rc/sunxi-cir.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> index 8555c7798706..0a7f7eab3cc3 100644
> --- a/drivers/media/rc/sunxi-cir.c
> +++ b/drivers/media/rc/sunxi-cir.c
> @@ -342,22 +342,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
>
> static int sunxi_ir_remove(struct platform_device *pdev)
> {
> - unsigned long flags;
> struct sunxi_ir *ir = platform_get_drvdata(pdev);
>
> clk_disable_unprepare(ir->clk);
> clk_disable_unprepare(ir->apb_clk);
> reset_control_assert(ir->rst);
>
> - spin_lock_irqsave(>ir_lock, flags);
> - /* disable IR IRQ */
> - writel(0, ir->base + SUNXI_IR_RXINT_REG);
> - /* clear All Rx Interrupt Status */
> - writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
> - /* disable IR */
> - writel(0, ir->base + SUNXI_IR_CTL_REG);
> - spin_unlock_irqrestore(>ir_lock, flags);
> -
> rc_unregister_device(ir->rc);
> return 0;
> }
I don't think there is anything wrong with the patch, however here the
driver does rc_unregister_device() *after* disabling it. Userspace can
still hold a file descriptor open, and call e.g. LIRC_SET_REC_TIMEOUT
ioctl, which causes various writes the sunxi-cir registers.
The order should be reversed.
Sean
Re: [PATCH] Fix shift-out-of-bound in mceusb_process_ir_data
On Wed, Jan 13, 2021 at 07:11:22PM +0800, Dongliang Mu wrote:
> The missing check of ir->buf_in[i+1] can lead to an shift-out-of-bound
> in mceusb_handle_command or mceusb_dev_printdata. This patch adds a
> check to limit its value lower than 16. The concrete report of UBSAN is
> as follows.
>
> UBSAN: shift-out-of-bounds in drivers/media/rc/mceusb.c:704:13
> shift exponent 230 is too large for 32-bit type 'unsigned int'
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-syzkaller #0
> Call Trace:
>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x107/0x163 lib/dump_stack.c:120
> ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
> __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
> mceusb_dev_printdata.cold+0x19/0x1e drivers/media/rc/mceusb.c:704
> mceusb_process_ir_data drivers/media/rc/mceusb.c:1275 [inline]
> mceusb_dev_recv+0x3cb/0x1990 drivers/media/rc/mceusb.c:1376
> __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1657
> usb_hcd_giveback_urb+0x38c/0x430 drivers/usb/core/hcd.c:1728
> dummy_timer+0x11f4/0x32a0 drivers/usb/gadget/udc/dummy_hcd.c:1971
>
> Signed-off-by: Dongliang Mu
> ---
> drivers/media/rc/mceusb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index f9616158bcf4..755808c6e747 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -1272,6 +1272,8 @@ static void mceusb_process_ir_data(struct mceusb_dev
> *ir, int buf_len)
> switch (ir->parser_state) {
> case SUBCMD:
> ir->rem = mceusb_cmd_datasize(ir->cmd, ir->buf_in[i]);
> + if (ir->buf_in[i+1] >= 16)
> + continue;
I'm not sure this is correct. This checks the second byte for *any* response,
not just MCE_RSP_EQIRCFS response which is causing the "shift out of bounds"
issue.
I think the check belongs within the MCE_RSP_EQIRCFS case.
Lastly it should have been break, not continue.
Thanks
Sean
> mceusb_dev_printdata(ir, ir->buf_in, buf_len, i - 1,
>ir->rem + 2, false);
> if (i + ir->rem < buf_len)
> --
> 2.25.1
[PATCH v3 2/4] libbpf: add support for ints larger than 128 bits
clang supports arbitrary length ints using the _ExtInt extension. This can be useful to hold very large values, e.g. 256 bit or 512 bit types. This requires the _ExtInt extension enabled in clang, which is under review. Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types Link: https://reviews.llvm.org/D93103 Signed-off-by: Sean Young --- tools/lib/bpf/btf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c index 3c3f2bc6c652..a676373f052b 100644 --- a/tools/lib/bpf/btf.c +++ b/tools/lib/bpf/btf.c @@ -1722,7 +1722,7 @@ int btf__add_int(struct btf *btf, const char *name, size_t byte_sz, int encoding if (!name || !name[0]) return -EINVAL; /* byte_sz must be power of 2 */ - if (!byte_sz || (byte_sz & (byte_sz - 1)) || byte_sz > 16) + if (!byte_sz || (byte_sz & (byte_sz - 1)) || byte_sz > 64) return -EINVAL; if (encoding & ~(BTF_INT_SIGNED | BTF_INT_CHAR | BTF_INT_BOOL)) return -EINVAL; -- 2.29.2
[PATCH v3 0/4] btf: support ints larger than 128 bits
clang supports arbitrary length ints using the _ExtInt extension. This can be useful to hold very large values, e.g. 256 bit or 512 bit types. Larger types (e.g. 1024 bits) are possible but I am unaware of a use case for these. This requires the _ExtInt extension enabled in clang, which is under review. Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types Link: https://reviews.llvm.org/D93103 Signed-off-by: Sean Young changes since v2: - split patches into 4 distinct patches changes since v1: - added tests as suggested by Yonghong Song - added kernel pretty-printer Sean Young (4): btf: add support for ints larger than 128 bits libbpf: add support for ints larger than 128 bits bpftool: add support for ints larger than 128 bits bpf: add tests for ints larger than 128 bits Documentation/bpf/btf.rst | 4 +- include/uapi/linux/btf.h | 2 +- kernel/bpf/btf.c | 54 +- tools/bpf/bpftool/btf_dumper.c| 40 ++ tools/include/uapi/linux/btf.h| 2 +- tools/lib/bpf/btf.c | 2 +- tools/testing/selftests/bpf/Makefile | 3 +- tools/testing/selftests/bpf/prog_tests/btf.c | 3 +- .../selftests/bpf/progs/test_btf_extint.c | 50 ++ tools/testing/selftests/bpf/test_extint.py| 535 ++ 10 files changed, 679 insertions(+), 16 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/test_btf_extint.c create mode 100755 tools/testing/selftests/bpf/test_extint.py -- 2.29.2
[PATCH v3 1/4] btf: add support for ints larger than 128 bits
clang supports arbitrary length ints using the _ExtInt extension. This
can be useful to hold very large values, e.g. 256 bit or 512 bit types.
Larger types (e.g. 1024 bits) are possible but I am unaware of a use
case for these.
This requires the _ExtInt extension enabled in clang, which is under
review.
Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
Link: https://reviews.llvm.org/D93103
Signed-off-by: Sean Young
---
Documentation/bpf/btf.rst | 4 +--
include/uapi/linux/btf.h | 2 +-
kernel/bpf/btf.c | 54 --
tools/include/uapi/linux/btf.h | 2 +-
4 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index 44dc789de2b4..784f1743dbc7 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -132,7 +132,7 @@ The following sections detail encoding of each kind.
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
#define BTF_INT_OFFSET(VAL) (((VAL) & 0x00ff) >> 16)
- #define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
+ #define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
The ``BTF_INT_ENCODING`` has the following attributes::
@@ -147,7 +147,7 @@ pretty print. At most one encoding can be specified for the
int type.
The ``BTF_INT_BITS()`` specifies the number of actual bits held by this int
type. For example, a 4-bit bitfield encodes ``BTF_INT_BITS()`` equals to 4.
The ``btf_type.size * 8`` must be equal to or greater than ``BTF_INT_BITS()``
-for the type. The maximum value of ``BTF_INT_BITS()`` is 128.
+for the type. The maximum value of ``BTF_INT_BITS()`` is 512.
The ``BTF_INT_OFFSET()`` specifies the starting bit offset to calculate values
for this int. For example, a bitfield struct member has:
diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
index 5a667107ad2c..1696fd02b302 100644
--- a/include/uapi/linux/btf.h
+++ b/include/uapi/linux/btf.h
@@ -84,7 +84,7 @@ struct btf_type {
*/
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
#define BTF_INT_OFFSET(VAL)(((VAL) & 0x00ff) >> 16)
-#define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
+#define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
/* Attributes stored in the BTF_INT_ENCODING */
#define BTF_INT_SIGNED (1 << 0)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 8d6bdb4f4d61..44bc17207e9b 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -166,7 +166,8 @@
*
*/
-#define BITS_PER_U128 (sizeof(u64) * BITS_PER_BYTE * 2)
+#define BITS_PER_U128 128
+#define BITS_PER_U512 512
#define BITS_PER_BYTE_MASK (BITS_PER_BYTE - 1)
#define BITS_PER_BYTE_MASKED(bits) ((bits) & BITS_PER_BYTE_MASK)
#define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
@@ -1907,9 +1908,9 @@ static int btf_int_check_member(struct btf_verifier_env
*env,
nr_copy_bits = BTF_INT_BITS(int_data) +
BITS_PER_BYTE_MASKED(struct_bits_off);
- if (nr_copy_bits > BITS_PER_U128) {
+ if (nr_copy_bits > BITS_PER_U512) {
btf_verifier_log_member(env, struct_type, member,
- "nr_copy_bits exceeds 128");
+ "nr_copy_bits exceeds 512");
return -EINVAL;
}
@@ -1963,9 +1964,9 @@ static int btf_int_check_kflag_member(struct
btf_verifier_env *env,
bytes_offset = BITS_ROUNDDOWN_BYTES(struct_bits_off);
nr_copy_bits = nr_bits + BITS_PER_BYTE_MASKED(struct_bits_off);
- if (nr_copy_bits > BITS_PER_U128) {
+ if (nr_copy_bits > BITS_PER_U512) {
btf_verifier_log_member(env, struct_type, member,
- "nr_copy_bits exceeds 128");
+ "nr_copy_bits exceeds 512");
return -EINVAL;
}
@@ -2012,9 +2013,9 @@ static s32 btf_int_check_meta(struct btf_verifier_env
*env,
nr_bits = BTF_INT_BITS(int_data) + BTF_INT_OFFSET(int_data);
- if (nr_bits > BITS_PER_U128) {
- btf_verifier_log_type(env, t, "nr_bits exceeds %zu",
- BITS_PER_U128);
+ if (nr_bits > BITS_PER_U512) {
+ btf_verifier_log_type(env, t, "nr_bits exceeds %u",
+ BITS_PER_U512);
return -EINVAL;
}
@@ -2080,6 +2081,37 @@ static void btf_int128_print(struct btf_show *show, void
*data)
lower_num);
}
+static void btf_bigint_print(struct btf_show *show, void *data, u16 nr_bits)
+{
+ /* data points to 256 or 512 bit int type */
+ char buf[129];
+ int last_u64 = nr_bits / 64 - 1;
+ bool seen_nonzero = false;
+ int i;
+
+ for (i = 0; i <= las
[PATCH v3 4/4] bpf: add tests for ints larger than 128 bits
clang supports arbitrary length ints using the _ExtInt extension. This
can be useful to hold very large values, e.g. 256 bit or 512 bit types.
Larger types (e.g. 1024 bits) are possible but I am unaware of a use
case for these.
This requires the _ExtInt extension enabled in clang, which is under
review.
Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
Link: https://reviews.llvm.org/D93103
Signed-off-by: Sean Young
---
tools/testing/selftests/bpf/Makefile | 3 +-
tools/testing/selftests/bpf/prog_tests/btf.c | 3 +-
.../selftests/bpf/progs/test_btf_extint.c | 50 ++
tools/testing/selftests/bpf/test_extint.py| 535 ++
4 files changed, 589 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_btf_extint.c
create mode 100755 tools/testing/selftests/bpf/test_extint.py
diff --git a/tools/testing/selftests/bpf/Makefile
b/tools/testing/selftests/bpf/Makefile
index 8c33e999319a..436ad1aed3d9 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -70,7 +70,8 @@ TEST_PROGS := test_kmod.sh \
test_bpftool_build.sh \
test_bpftool.sh \
test_bpftool_metadata.sh \
- test_xsk.sh
+ test_xsk.sh \
+ test_extint.py
TEST_PROGS_EXTENDED := with_addr.sh \
with_tunnels.sh \
diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c
b/tools/testing/selftests/bpf/prog_tests/btf.c
index 8ae97e2a4b9d..96a93502cf27 100644
--- a/tools/testing/selftests/bpf/prog_tests/btf.c
+++ b/tools/testing/selftests/bpf/prog_tests/btf.c
@@ -4073,6 +4073,7 @@ struct btf_file_test {
static struct btf_file_test file_tests[] = {
{ .file = "test_btf_haskv.o", },
{ .file = "test_btf_newkv.o", },
+ { .file = "test_btf_extint.o", },
{ .file = "test_btf_nokv.o", .btf_kv_notfound = true, },
};
@@ -4414,7 +4415,7 @@ static struct btf_raw_test pprint_test_template[] = {
* will have both int and enum types.
*/
.raw_types = {
- /* unsighed char */ /* [1] */
+ /* unsigned char */ /* [1] */
BTF_TYPE_INT_ENC(NAME_TBD, 0, 0, 8, 1),
/* unsigned short *//* [2] */
BTF_TYPE_INT_ENC(NAME_TBD, 0, 0, 16, 2),
diff --git a/tools/testing/selftests/bpf/progs/test_btf_extint.c
b/tools/testing/selftests/bpf/progs/test_btf_extint.c
new file mode 100644
index ..b0fa9f130dda
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/test_btf_extint.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include "bpf_legacy.h"
+
+struct extint {
+ _ExtInt(256) v256;
+ _ExtInt(512) v512;
+};
+
+struct bpf_map_def SEC("maps") btf_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(int),
+ .value_size = sizeof(struct extint),
+ .max_entries = 1,
+};
+
+BPF_ANNOTATE_KV_PAIR(btf_map, int, struct extint);
+
+__attribute__((noinline))
+int test_long_fname_2(void)
+{
+ struct extint *bi;
+ int key = 0;
+
+ bi = bpf_map_lookup_elem(_map, );
+ if (!bi)
+ return 0;
+
+ bi->v256 <<= 64;
+ bi->v256 += (_ExtInt(256))0xcafedead;
+ bi->v512 <<= 128;
+ bi->v512 += (_ExtInt(512))0xff00ff00ff00ffull;
+
+ return 0;
+}
+
+__attribute__((noinline))
+int test_long_fname_1(void)
+{
+ return test_long_fname_2();
+}
+
+SEC("dummy_tracepoint")
+int _dummy_tracepoint(void *arg)
+{
+ return test_long_fname_1();
+}
+
+char _license[] SEC("license") = "GPL";
diff --git a/tools/testing/selftests/bpf/test_extint.py
b/tools/testing/selftests/bpf/test_extint.py
new file mode 100755
index ..86af815a0cf6
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_extint.py
@@ -0,0 +1,535 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0
+
+# Copyright (C) 2020 Sean Young
+# Copyright (C) 2017 Netronome Systems, Inc.
+# Copyright (c) 2019 Mellanox Technologies. All rights reserved
+#
+# This software is licensed under the GNU General License Version 2,
+# June 1991 as shown in the file COPYING in the top-level directory of this
+# source tree.
+#
+# THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
+# WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
+# BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+# FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE
+# OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME
+# THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+from datetime import datetime
+import argparse
+import errno
+import json
+import os
+import pprint
+import random
+import re
+import stat
+import s
[PATCH v3 3/4] bpftool: add support for ints larger than 128 bits
clang supports arbitrary length ints using the _ExtInt extension. This
can be useful to hold very large values, e.g. 256 bit or 512 bit types.
This requires the _ExtInt extension enabled in clang, which is under
review.
Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
Link: https://reviews.llvm.org/D93103
Signed-off-by: Sean Young
---
tools/bpf/bpftool/btf_dumper.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c
index 0e9310727281..8b5318ec5c26 100644
--- a/tools/bpf/bpftool/btf_dumper.c
+++ b/tools/bpf/bpftool/btf_dumper.c
@@ -271,6 +271,41 @@ static void btf_int128_print(json_writer_t *jw, const void
*data,
}
}
+static void btf_bigint_print(json_writer_t *jw, const void *data, int nr_bits,
+bool is_plain_text)
+{
+ char buf[nr_bits / 4 + 1];
+ int last_u64 = nr_bits / 64 - 1;
+ bool seen_nonzero = false;
+ int i;
+
+ for (i = 0; i <= last_u64; i++) {
+#ifdef __BIG_ENDIAN_BITFIELD
+ __u64 v = ((__u64 *)data)[i];
+#else
+ __u64 v = ((__u64 *)data)[last_u64 - i];
+#endif
+
+ if (!seen_nonzero) {
+ if (!v && i != last_u64)
+ continue;
+
+ snprintf(buf, sizeof(buf), "%llx", v);
+
+ seen_nonzero = true;
+ } else {
+ size_t off = strlen(buf);
+
+ snprintf(buf + off, sizeof(buf) - off, "%016llx", v);
+ }
+ }
+
+ if (is_plain_text)
+ jsonw_printf(jw, "0x%s", buf);
+ else
+ jsonw_printf(jw, "\"0x%s\"", buf);
+}
+
static void btf_int128_shift(__u64 *print_num, __u16 left_shift_bits,
__u16 right_shift_bits)
{
@@ -373,6 +408,11 @@ static int btf_dumper_int(const struct btf_type *t, __u8
bit_offset,
return 0;
}
+ if (nr_bits > 128) {
+ btf_bigint_print(jw, data, nr_bits, is_plain_text);
+ return 0;
+ }
+
if (nr_bits == 128) {
btf_int128_print(jw, data, is_plain_text);
return 0;
--
2.29.2
Re: [PATCH v2] btf: support ints larger than 128 bits
On Wed, Dec 30, 2020 at 10:21:09AM -0800, Yonghong Song wrote: > On 12/19/20 8:36 AM, Sean Young wrote: > > clang supports arbitrary length ints using the _ExtInt extension. This > > can be useful to hold very large values, e.g. 256 bit or 512 bit types. > > > > Larger types (e.g. 1024 bits) are possible but I am unaware of a use > > case for these. > > > > This requires the _ExtInt extension enabled in clang, which is under > > review. > > > > Link: > > https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types > > Link: https://reviews.llvm.org/D93103 > > > > Signed-off-by: Sean Young > > --- > > changes since v2: > > - added tests as suggested by Yonghong Song > > - added kernel pretty-printer > > > > Documentation/bpf/btf.rst | 4 +- > > include/uapi/linux/btf.h | 2 +- > > kernel/bpf/btf.c | 54 +- > > tools/bpf/bpftool/btf_dumper.c| 40 ++ > > tools/include/uapi/linux/btf.h| 2 +- > > tools/lib/bpf/btf.c | 2 +- > > tools/testing/selftests/bpf/Makefile | 3 +- > > tools/testing/selftests/bpf/prog_tests/btf.c | 3 +- > > .../selftests/bpf/progs/test_btf_extint.c | 50 ++ > > tools/testing/selftests/bpf/test_extint.py| 535 ++ > > For easier review, maybe you can break this patch into a patch series like > below? > patch 1 (kernel related changes and doc) > kernel/bpf/btf.c, include/uapi/linux/btf.h, > tools/include/uapi/linux/btf.h > Documentation/bpf/btf.rst > patch 2 (libbpf support) > tools/lib/bpf/btf.c > patch 3 (bpftool support) > tools/bpf/bpftool/btf_dumper.c > patch 4 (testing) > rest files That makes sense, I'll send out v3 shortly. Thanks, Sean
[PATCH v2] btf: support ints larger than 128 bits
clang supports arbitrary length ints using the _ExtInt extension. This
can be useful to hold very large values, e.g. 256 bit or 512 bit types.
Larger types (e.g. 1024 bits) are possible but I am unaware of a use
case for these.
This requires the _ExtInt extension enabled in clang, which is under
review.
Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
Link: https://reviews.llvm.org/D93103
Signed-off-by: Sean Young
---
changes since v2:
- added tests as suggested by Yonghong Song
- added kernel pretty-printer
Documentation/bpf/btf.rst | 4 +-
include/uapi/linux/btf.h | 2 +-
kernel/bpf/btf.c | 54 +-
tools/bpf/bpftool/btf_dumper.c| 40 ++
tools/include/uapi/linux/btf.h| 2 +-
tools/lib/bpf/btf.c | 2 +-
tools/testing/selftests/bpf/Makefile | 3 +-
tools/testing/selftests/bpf/prog_tests/btf.c | 3 +-
.../selftests/bpf/progs/test_btf_extint.c | 50 ++
tools/testing/selftests/bpf/test_extint.py| 535 ++
10 files changed, 679 insertions(+), 16 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_btf_extint.c
create mode 100755 tools/testing/selftests/bpf/test_extint.py
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index 44dc789de2b4..784f1743dbc7 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -132,7 +132,7 @@ The following sections detail encoding of each kind.
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
#define BTF_INT_OFFSET(VAL) (((VAL) & 0x00ff) >> 16)
- #define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
+ #define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
The ``BTF_INT_ENCODING`` has the following attributes::
@@ -147,7 +147,7 @@ pretty print. At most one encoding can be specified for the
int type.
The ``BTF_INT_BITS()`` specifies the number of actual bits held by this int
type. For example, a 4-bit bitfield encodes ``BTF_INT_BITS()`` equals to 4.
The ``btf_type.size * 8`` must be equal to or greater than ``BTF_INT_BITS()``
-for the type. The maximum value of ``BTF_INT_BITS()`` is 128.
+for the type. The maximum value of ``BTF_INT_BITS()`` is 512.
The ``BTF_INT_OFFSET()`` specifies the starting bit offset to calculate values
for this int. For example, a bitfield struct member has:
diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
index 5a667107ad2c..1696fd02b302 100644
--- a/include/uapi/linux/btf.h
+++ b/include/uapi/linux/btf.h
@@ -84,7 +84,7 @@ struct btf_type {
*/
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
#define BTF_INT_OFFSET(VAL)(((VAL) & 0x00ff) >> 16)
-#define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
+#define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
/* Attributes stored in the BTF_INT_ENCODING */
#define BTF_INT_SIGNED (1 << 0)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 8d6bdb4f4d61..44bc17207e9b 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -166,7 +166,8 @@
*
*/
-#define BITS_PER_U128 (sizeof(u64) * BITS_PER_BYTE * 2)
+#define BITS_PER_U128 128
+#define BITS_PER_U512 512
#define BITS_PER_BYTE_MASK (BITS_PER_BYTE - 1)
#define BITS_PER_BYTE_MASKED(bits) ((bits) & BITS_PER_BYTE_MASK)
#define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
@@ -1907,9 +1908,9 @@ static int btf_int_check_member(struct btf_verifier_env
*env,
nr_copy_bits = BTF_INT_BITS(int_data) +
BITS_PER_BYTE_MASKED(struct_bits_off);
- if (nr_copy_bits > BITS_PER_U128) {
+ if (nr_copy_bits > BITS_PER_U512) {
btf_verifier_log_member(env, struct_type, member,
- "nr_copy_bits exceeds 128");
+ "nr_copy_bits exceeds 512");
return -EINVAL;
}
@@ -1963,9 +1964,9 @@ static int btf_int_check_kflag_member(struct
btf_verifier_env *env,
bytes_offset = BITS_ROUNDDOWN_BYTES(struct_bits_off);
nr_copy_bits = nr_bits + BITS_PER_BYTE_MASKED(struct_bits_off);
- if (nr_copy_bits > BITS_PER_U128) {
+ if (nr_copy_bits > BITS_PER_U512) {
btf_verifier_log_member(env, struct_type, member,
- "nr_copy_bits exceeds 128");
+ "nr_copy_bits exceeds 512");
return -EINVAL;
}
@@ -2012,9 +2013,9 @@ static s32 btf_int_check_meta(struct btf_verifier_env
*env,
nr_bits = BTF_INT_BITS(int_data) + BTF_INT_OFFSET(int_data);
- if (nr_bits > BITS_PER_U128) {
- btf_verifier_log_type(env, t, "nr_bits exceeds %zu",
- BITS_PER_U128);
+ if (nr_bits &
Re: [PATCH] btf: support ints larger than 128 bits
Hi Yonghong,
Thank you for the detailed review.
On Thu, Dec 17, 2020 at 06:12:11PM -0800, Yonghong Song wrote:
> On 12/17/20 7:01 AM, Sean Young wrote:
> > clang supports arbitrary length ints using the _ExtInt extension. This
> > can be useful to hold very large values, e.g. 256 bit or 512 bit types.
> >
> > Larger types (e.g. 1024 bits) are possible but I am unaware of a use
> > case for these.
> >
> > This requires the _ExtInt extension to enabled for BPF in clang, which
> > is under review.
> >
> > Link:
> > https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
> > Link: https://reviews.llvm.org/D93103
> >
> > Signed-off-by: Sean Young
> > ---
> > Documentation/bpf/btf.rst | 4 ++--
> > include/uapi/linux/btf.h | 2 +-
> > tools/bpf/bpftool/btf_dumper.c | 39 ++
> > tools/include/uapi/linux/btf.h | 2 +-
> > 4 files changed, 43 insertions(+), 4 deletions(-)
>
> Thanks for the patch. But the change is not enough and no tests in the patch
> set.
>
> For example, in kernel/bpf/btf.c, we BITS_PER_U128 to guard in various
> places where the number of integer bits must be <= 128 bits which is
> what we supported now. In function btf_type_int_is_regular(), # of int
> bits larger than 128 considered false. The extint like 256/512bits should be
> also regular int.
Right, thanks for spotting that. I'll give the next version some better
testing.
> extint permits non-power-of-2 bits (e.g., 192bits), to support them
> may not be necessary and this is not your use case. what do you think?
My feeling is that non-power-of-2 types are useful for llvm targets
which such registers. I'm not sure they have much use for our use case
or bpf in general. If anyone thinks otherwise I'm easily convinced.
> lib/bpf/btf.c btf__and_int() function also has the following check,
>
> /* byte_sz must be power of 2 */
> if (!byte_sz || (byte_sz & (byte_sz - 1)) || byte_sz > 16)
> return -EINVAL;
>
> So Extint 256 bits will fail here.
Indeed it will.
> Please do add some selftests tools/testing/selftests/bpf
> directories:
>- to ensure btf with newly supported int types loaded successfully
> in kernel
>- to ensure bpftool map [pretty] print working fine with new types
>- to ensure kernel map pretty print works fine
> (tests at tools/testing/selftests/bpf/prog_tests/btf.c)
>- to ensure btf manipulation APIs works with new types.
Absolutely. I'll send out a v2 when ready.
Thanks again for the great review.
Sean
>
> >
> > diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
> > index 44dc789de2b4..784f1743dbc7 100644
> > --- a/Documentation/bpf/btf.rst
> > +++ b/Documentation/bpf/btf.rst
> > @@ -132,7 +132,7 @@ The following sections detail encoding of each kind.
> > #define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
> > #define BTF_INT_OFFSET(VAL) (((VAL) & 0x00ff) >> 16)
> > - #define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
> > + #define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
> > The ``BTF_INT_ENCODING`` has the following attributes::
> > @@ -147,7 +147,7 @@ pretty print. At most one encoding can be specified for
> > the int type.
> > The ``BTF_INT_BITS()`` specifies the number of actual bits held by this
> > int
> > type. For example, a 4-bit bitfield encodes ``BTF_INT_BITS()`` equals to
> > 4.
> > The ``btf_type.size * 8`` must be equal to or greater than
> > ``BTF_INT_BITS()``
> > -for the type. The maximum value of ``BTF_INT_BITS()`` is 128.
> > +for the type. The maximum value of ``BTF_INT_BITS()`` is 512.
> > The ``BTF_INT_OFFSET()`` specifies the starting bit offset to calculate
> > values
> > for this int. For example, a bitfield struct member has:
> > diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
> > index 5a667107ad2c..1696fd02b302 100644
> > --- a/include/uapi/linux/btf.h
> > +++ b/include/uapi/linux/btf.h
> > @@ -84,7 +84,7 @@ struct btf_type {
> >*/
> > #define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
> > #define BTF_INT_OFFSET(VAL) (((VAL) & 0x00ff) >> 16)
> > -#define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
> > +#define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
> > /* Attributes stored in the BTF_INT_ENCODING */
> > #define BTF_INT_SIGNED(1 << 0)
> > diff --git a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c
> > index 0e9310727
[PATCH] btf: support ints larger than 128 bits
clang supports arbitrary length ints using the _ExtInt extension. This
can be useful to hold very large values, e.g. 256 bit or 512 bit types.
Larger types (e.g. 1024 bits) are possible but I am unaware of a use
case for these.
This requires the _ExtInt extension to enabled for BPF in clang, which
is under review.
Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
Link: https://reviews.llvm.org/D93103
Signed-off-by: Sean Young
---
Documentation/bpf/btf.rst | 4 ++--
include/uapi/linux/btf.h | 2 +-
tools/bpf/bpftool/btf_dumper.c | 39 ++
tools/include/uapi/linux/btf.h | 2 +-
4 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index 44dc789de2b4..784f1743dbc7 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -132,7 +132,7 @@ The following sections detail encoding of each kind.
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
#define BTF_INT_OFFSET(VAL) (((VAL) & 0x00ff) >> 16)
- #define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
+ #define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
The ``BTF_INT_ENCODING`` has the following attributes::
@@ -147,7 +147,7 @@ pretty print. At most one encoding can be specified for the
int type.
The ``BTF_INT_BITS()`` specifies the number of actual bits held by this int
type. For example, a 4-bit bitfield encodes ``BTF_INT_BITS()`` equals to 4.
The ``btf_type.size * 8`` must be equal to or greater than ``BTF_INT_BITS()``
-for the type. The maximum value of ``BTF_INT_BITS()`` is 128.
+for the type. The maximum value of ``BTF_INT_BITS()`` is 512.
The ``BTF_INT_OFFSET()`` specifies the starting bit offset to calculate values
for this int. For example, a bitfield struct member has:
diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
index 5a667107ad2c..1696fd02b302 100644
--- a/include/uapi/linux/btf.h
+++ b/include/uapi/linux/btf.h
@@ -84,7 +84,7 @@ struct btf_type {
*/
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
#define BTF_INT_OFFSET(VAL)(((VAL) & 0x00ff) >> 16)
-#define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
+#define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
/* Attributes stored in the BTF_INT_ENCODING */
#define BTF_INT_SIGNED (1 << 0)
diff --git a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c
index 0e9310727281..45ed45ea9962 100644
--- a/tools/bpf/bpftool/btf_dumper.c
+++ b/tools/bpf/bpftool/btf_dumper.c
@@ -271,6 +271,40 @@ static void btf_int128_print(json_writer_t *jw, const void
*data,
}
}
+static void btf_bigint_print(json_writer_t *jw, const void *data, int nr_bits,
+bool is_plain_text)
+{
+ char buf[nr_bits / 4 + 1];
+ bool first = true;
+ int i;
+
+#ifdef __BIG_ENDIAN_BITFIELD
+ for (i = 0; i < nr_bits / 64; i++) {
+#else
+ for (i = nr_bits / 64 - 1; i >= 0; i++) {
+#endif
+ __u64 v = ((__u64 *)data)[i];
+
+ if (first) {
+ if (!v)
+ continue;
+
+ snprintf(buf, sizeof(buf), "%llx", v);
+
+ first = false;
+ } else {
+ size_t off = strlen(buf);
+
+ snprintf(buf + off, sizeof(buf) - off, "%016llx", v);
+ }
+ }
+
+ if (is_plain_text)
+ jsonw_printf(jw, "0x%s", buf);
+ else
+ jsonw_printf(jw, "\"0x%s\"", buf);
+}
+
static void btf_int128_shift(__u64 *print_num, __u16 left_shift_bits,
__u16 right_shift_bits)
{
@@ -373,6 +407,11 @@ static int btf_dumper_int(const struct btf_type *t, __u8
bit_offset,
return 0;
}
+ if (nr_bits > 128) {
+ btf_bigint_print(jw, data, nr_bits, is_plain_text);
+ return 0;
+ }
+
if (nr_bits == 128) {
btf_int128_print(jw, data, is_plain_text);
return 0;
diff --git a/tools/include/uapi/linux/btf.h b/tools/include/uapi/linux/btf.h
index 5a667107ad2c..1696fd02b302 100644
--- a/tools/include/uapi/linux/btf.h
+++ b/tools/include/uapi/linux/btf.h
@@ -84,7 +84,7 @@ struct btf_type {
*/
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f00) >> 24)
#define BTF_INT_OFFSET(VAL)(((VAL) & 0x00ff) >> 16)
-#define BTF_INT_BITS(VAL) ((VAL) & 0x00ff)
+#define BTF_INT_BITS(VAL) ((VAL) & 0x03ff)
/* Attributes stored in the BTF_INT_ENCODING */
#define BTF_INT_SIGNED (1 << 0)
--
2.29.2
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hi Uwe, On Mon, Dec 07, 2020 at 02:52:09PM +0100, Uwe Kleine-König wrote: > On Mon, Dec 07, 2020 at 09:43:20AM +0000, Sean Young wrote: > > On Mon, Dec 07, 2020 at 09:16:28AM +0100, Uwe Kleine-König wrote: > > > On Sun, Dec 06, 2020 at 02:19:41PM +, Sean Young wrote: > > > > On Sat, Dec 05, 2020 at 08:25:10PM +0100, Uwe Kleine-König wrote: > > > > > On Sat, Dec 05, 2020 at 05:34:44PM +, Sean Young wrote: > > > > > > What real life uses-cases are there for round down? If you want to > > > > > > round > > > > > > down, is there any need for round up? > > > > > > > > > > The scenario I have in mind is for driving a motor. I have to admit > > > > > however that usually the period doesn't matter much and it's the > > > > > duty_cycle that defines the motor's speed. So for this case the > > > > > conservative behaviour is round-down to not make the motor run faster > > > > > than expected. > > > > > > > > I am reading here that for driving motors, only the duty cycle matters, > > > > not the period. > > > > > > There is an upper limit (usually around 1 ms) for the period, but if you > > > choose 0.1 ms or 0.001 ms doesn't matter much AFAICT. > > > > > > @Thierry: Do you have further use cases in mind? > > I asked in the hardware department of the company I work for and they > had another usecase: Motors where for example a 1 ms pulse means "move > forwards" and 2 ms means "move backwards". They had the same idea as I > had: You want to know beforehand the result of a given > pwm_apply_state(). That sounds good, that would be nice. > > > > > For other usecases (fan, backlight, LED) exactness typically doesn't > > > > > matter that much. > > > > > > > > So, the use-cases you have are driving motor, fan, backlight, and led. > > > > And in all these cases the exact Hz does not matter. > > > > > > > > The only uses case where the exact Hz does matter is pwm-ir-tx. > > > > > > > > So, I gather there are no use-cases for round-down. Yes, should > > > > round-down > > > > be needed, then this is more difficult to implement if the driver always > > > > does a round-closest. But, since there is no reason to have round-down, > > > > this is all academic. > > > > > > > > Your policy of forcing new pwm drivers to use round-down is breaking > > > > pwm-ir-tx. > > > > > > So you're indeed suggesting that the "right" rounding strategy for > > > lowlevel drivers should be: > > > > > > - Use the period length closest to the requested period (in doubt round > > >down?) > > > - With the chosen period length use the biggest duty_cycle not bigger > > >than the requested duty_cycle. > > > > > > While this seems technically fine I think for maintenance this is a > > > nightmare. > > > > > > My preference would be to stick to the rounding strategy we used so far > > > (i.e.: > > > > > > - Use the biggest period length not bigger than the requested period > > > - With the chosen period length use the biggest duty_cycle not bigger > > >than the requested duty_cycle. > > > > > > ) and for pwm-ir-tx add support to the PWM API to still make it possible > > > (and easy) to select the best setting. > > > > > > The reasons why I think that this rounding-down strategy is the best > > > are (in order of importance): > > > > > > - It is easier to implement correctly [1] > > > > Yes, you are right. You have given a great example where a simple > > DIV_ROUND_CLOSEST() does not give the result you want. > > > > > - Same rounding method for period and duty cycle > > > - most drivers already do this (I think) > > > > > > The (IMHO nice) result would then mean: > > > > > > - All consumers can get the setting they want; and > > > > Once there is a nice pwm api for selecting round-nearest, then yes. > > > > For the uses cases you've given, fan, backlight, and led a round-nearest > > is the rounding they would want, I would expect. > > maybe, yes. Maybe it is also not important enough to spend the extra > cycles getting round nearest and so sticking to round-down is good > enough. > > > > - Code in lowlevel drivers is simple and
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hello Uwe, Thank you for taking the time to explain your thinking. On Mon, Dec 07, 2020 at 09:16:28AM +0100, Uwe Kleine-König wrote: > On Sun, Dec 06, 2020 at 02:19:41PM +0000, Sean Young wrote: > > On Sat, Dec 05, 2020 at 08:25:10PM +0100, Uwe Kleine-König wrote: > > > On Sat, Dec 05, 2020 at 05:34:44PM +, Sean Young wrote: > > > > What real life uses-cases are there for round down? If you want to round > > > > down, is there any need for round up? > > > > > > The scenario I have in mind is for driving a motor. I have to admit > > > however that usually the period doesn't matter much and it's the > > > duty_cycle that defines the motor's speed. So for this case the > > > conservative behaviour is round-down to not make the motor run faster > > > than expected. > > > > I am reading here that for driving motors, only the duty cycle matters, > > not the period. > > There is an upper limit (usually around 1 ms) for the period, but if you > choose 0.1 ms or 0.001 ms doesn't matter much AFAICT. > > @Thierry: Do you have further use cases in mind? > > > > For other usecases (fan, backlight, LED) exactness typically doesn't > > > matter that much. > > > > So, the use-cases you have are driving motor, fan, backlight, and led. > > And in all these cases the exact Hz does not matter. > > > > The only uses case where the exact Hz does matter is pwm-ir-tx. > > > > So, I gather there are no use-cases for round-down. Yes, should round-down > > be needed, then this is more difficult to implement if the driver always > > does a round-closest. But, since there is no reason to have round-down, > > this is all academic. > > > > Your policy of forcing new pwm drivers to use round-down is breaking > > pwm-ir-tx. > > So you're indeed suggesting that the "right" rounding strategy for > lowlevel drivers should be: > > - Use the period length closest to the requested period (in doubt round >down?) > - With the chosen period length use the biggest duty_cycle not bigger >than the requested duty_cycle. > > While this seems technically fine I think for maintenance this is a > nightmare. > > My preference would be to stick to the rounding strategy we used so far > (i.e.: > > - Use the biggest period length not bigger than the requested period > - With the chosen period length use the biggest duty_cycle not bigger >than the requested duty_cycle. > > ) and for pwm-ir-tx add support to the PWM API to still make it possible > (and easy) to select the best setting. > > The reasons why I think that this rounding-down strategy is the best > are (in order of importance): > > - It is easier to implement correctly [1] Yes, you are right. You have given a great example where a simple DIV_ROUND_CLOSEST() does not give the result you want. > - Same rounding method for period and duty cycle > - most drivers already do this (I think) > > The (IMHO nice) result would then mean: > > - All consumers can get the setting they want; and Once there is a nice pwm api for selecting round-nearest, then yes. For the uses cases you've given, fan, backlight, and led a round-nearest is the rounding they would want, I would expect. > - Code in lowlevel drivers is simple and the complexity is in common >code and so a single place. > > And it would also allow the pwm-ir-tx driver to notice if the PWM to be > used can for example only support frequencies under 400 kHz. I doubt pwm-ir-tx cares about this, however it is a nice-to-have. It would also be nice if the rounding could be used with atomic configuration as well. Please let me know when/if this new API exists for pwm so that pwm-ir-tx can select the right rounding. > [1] Consider a PWM with a parent frequency of 66 MHz, to select the > period you can pick an integer divider "div" resulting in the period > 4096 / (pclk * d). So the obvious implementation for round-nearest > would be: > > pclk = clk_get_rate(myclk); > div = DIV_ROUND_CLOSEST(NSEC_PER_SEC * 4096, targetperiod * pclk); Note NSEC_PER_SEC * 4096 >> 2^32 so this would need to be DIV_ROUND_CLOSEST_ULL. > , right? > > With targetperiod = 2641 ns this picks div = 23 and so a period of > 2698.2872200263505 ns (delta = 57.2872200263505 ns). > The optimal divider however is div = 24. (implemented period = > 2585.8585858585857 ns, delta = 55.14141414141448 ns) > > For round-down the correct implementation is: > > pclk = clk_get_rate(myclk); > div = DIV_ROUND_UP(NSEC_PER_SEC * 4096, targetperiod * pclk); > > Exercise for the reader: Come up with a correct implementation for > "round-nearest" and compare its complexity to the round-down code. To be fair, I haven't been been able to come up with a solution without control flow. Thank you for an interesting conversation about this. Sean
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hello Uwe, On Sat, Dec 05, 2020 at 08:25:10PM +0100, Uwe Kleine-König wrote: > On Sat, Dec 05, 2020 at 05:34:44PM +0000, Sean Young wrote: > > What real life uses-cases are there for round down? If you want to round > > down, is there any need for round up? > > The scenario I have in mind is for driving a motor. I have to admit > however that usually the period doesn't matter much and it's the > duty_cycle that defines the motor's speed. So for this case the > conservative behaviour is round-down to not make the motor run faster > than expected. I am reading here that for driving motors, only the duty cycle matters, not the period. > For other usecases (fan, backlight, LED) exactness typically doesn't > matter that much. So, the use-cases you have are driving motor, fan, backlight, and led. And in all these cases the exact Hz does not matter. The only uses case where the exact Hz does matter is pwm-ir-tx. So, I gather there are no use-cases for round-down. Yes, should round-down be needed, then this is more difficult to implement if the driver always does a round-closest. But, since there is no reason to have round-down, this is all academic. Your policy of forcing new pwm drivers to use round-down is breaking pwm-ir-tx. Thanks, Sean
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hello Uwe,
On Sat, Dec 05, 2020 at 12:28:34AM +0100, Uwe Kleine-König wrote:
> Hello Sean,
>
> On Fri, Dec 04, 2020 at 11:38:46AM +0000, Sean Young wrote:
> > On Fri, Dec 04, 2020 at 12:13:26PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Dec 04, 2020 at 08:44:17AM +, Sean Young wrote:
> > > > On Fri, Dec 04, 2020 at 12:42:15AM +0100, Lino Sanfilippo wrote:
> > > > > > You're storing an unsigned long long (i.e. 64 bits) in an u32. If
> > > > > > you are sure that this won't discard relevant bits, please explain
> > > > > > this in a comment for the cursory reader.
> > > > >
> > > > > > Also note that round_closed is probably wrong, as .apply() is
> > > > > > supposed to round down the period to the next achievable period.
> > > > > > (But
> > > > > > fixing this has to do done in a separate patch.)
> > > > >
> > > > > According to commit 11fc4edc4 rounding to the closest integer has
> > > > > been introduced
> > > > > to improve precision in case that the pwm controller is used by the
> > > > > pwm-ir-tx driver.
> > > > > I dont know how strong the requirement is to round down the period in
> > > > > apply(), but I
> > > > > can imagine that this may be a good reason to deviate from this rule.
> > > > > (CCing Sean Young who introduced DIV_ROUND_CLOSEST)
> > > >
> > > > There was a problem where the carrier is incorrect for some IR hardware
> > > > which uses a carrier of 455kHz. With periods that small, rounding errors
> > > > do really matter and rounding down might cause problems.
> > > >
> > > > A policy of rounding down the carrier is not the right thing to do
> > > > for pwm-ir-tx, and such a change will probably break pwm-ir-tx in some
> > > > edge cases.
> > >
> > > IMO it's not an option to say: pwm-driver A is used for IR, so A's
> > > .apply uses round-nearest and pwm-driver B is used for $somethingelse,
> > > so B's .apply uses round-down.
> >
> > I'm not saying that one driver should have one it one way and another driver
> > another way.
>
> I read between your lines that you think that round-nearest is the
> single best strategy, is that right?
Certain the default strategy. When setting a pwm of period X, I would
expect it set it to the closest period it can match to X. Doing anything
else by default is a surprising API.
What real life uses-cases are there for round down? If you want to round
down, is there any need for round up?
Hypothetically you may want e.g. nearest to 100kHz but absolutely no less
than 100kHz. I don't know when this comes up, it would be interesting to
hear where this is needed.
In fact, I am not sure you can guarantee this; when programming the hardware
there is some division arithmetic which may do some rounding and you'll end
up with slightly more than 100kHz.
Equally, you way want e.g. nearest 1MHz but absolutely no more than 1MHz.
This would require round-up for the period.
> If you have two consumer drivers and one requires round-nearest and the
> other requires round-down, how would you suggest to implement these two?
So when does really happen?
> Always adapting the low-level driver depending on which consumer is in
> use sounds wrong. So I conclude that the expectation about the
> implemented rounding behaviour should be the same for all drivers.
Agreed.
> And
> if your consumer happens to require a different strategy you're either
> out of luck (bad), or we need to expand the PWM API to make this
> possible, probably by implementing a round_state callback that tells the
> caller the resulting state if the given state is applied.
Agreed.
> > Why is is easier to implement?
>
> If pwm_apply_state (and so pwm_round_state) rounds down, you can achieve
> round-nearest (simplified: Ignoring polarity, just looking for period) using:
>
> lower_state = pwm_round_state(pwm, target_state);
> upper_state = {
> .period = 2 * target_state.period - lower_state.period,
> ...
> }
> tmp = pwm_round_state(pwm, upper)
>
> if tmp.period < target_state.period:
> # tmp == lower_state
> return lower_state
>
> else while tmp.period > target_state.period:
> upper = tmp;
> tmp.period -= 1
> tmp = pwm_round_state(pwm, tmp)
>
> I admit it is not pretty. But please try to implement it the other way
> around (i.e. pwm_round_state rounding to nearest and sea
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hi Uwe, On Fri, Dec 04, 2020 at 10:55:25PM +0100, Uwe Kleine-König wrote: > On Fri, Dec 04, 2020 at 11:40:36AM +0000, Sean Young wrote: > > On Fri, Dec 04, 2020 at 12:21:15PM +0100, Uwe Kleine-König wrote: > > > On Fri, Dec 04, 2020 at 12:42:15AM +0100, Lino Sanfilippo wrote: > > > > On 29.11.20 at 19:10, Uwe Kleine-König wrote: > > > > > You're storing an unsigned long long (i.e. 64 bits) in an u32. If > > > > > you are sure that this won't discard relevant bits, please explain > > > > > this in a comment for the cursory reader. > > > > > > > > What about an extra check then to make sure that the period has not > > > > been truncated, > > > > e.g: > > > > > > > > value = DIV_ROUND_CLOSEST_ULL(state->period, scaler); > > > > > > > > /* dont accept a period that is too small or has been truncated > > > > */ > > > > if ((value < PERIOD_MIN) || > > > > (value != DIV_ROUND_CLOSEST_ULL(state->period, scaler))) > > > > return -EINVAL; > > > > > > I'd make value an unsigned long long and check for > 0x instead > > > of repeating the (expensive) division. (Hmm, maybe the compiler is smart > > > enough to not actually repeat it, but still.) > > > > I wonder where you got that idea from. > > I don't know how to honestly answer your question. > Which idea do you mean? That divisions are expensive? Or that compilers > might be smart? And do you consider it a good idea? Or do you disagree? I had already made this exact suggestion -- and you had replied to my email making that suggestion -- before you emailed this. Granted, I said u64 and U32_MAX rather than unsigned long long and 0x. However, I should not have sent that snotty email. It's irrelevant. My apologies. Sean
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
On Fri, Dec 04, 2020 at 12:21:15PM +0100, Uwe Kleine-König wrote: > Hello Lino, > > On Fri, Dec 04, 2020 at 12:42:15AM +0100, Lino Sanfilippo wrote: > > On 29.11.20 at 19:10, Uwe Kleine-König wrote: > > > You're storing an unsigned long long (i.e. 64 bits) in an u32. If > > > you are sure that this won't discard relevant bits, please explain > > > this in a comment for the cursory reader. > > > > What about an extra check then to make sure that the period has not been > > truncated, > > e.g: > > > > value = DIV_ROUND_CLOSEST_ULL(state->period, scaler); > > > > /* dont accept a period that is too small or has been truncated */ > > if ((value < PERIOD_MIN) || > > (value != DIV_ROUND_CLOSEST_ULL(state->period, scaler))) > > return -EINVAL; > > I'd make value an unsigned long long and check for > 0x instead > of repeating the (expensive) division. (Hmm, maybe the compiler is smart > enough to not actually repeat it, but still.) I wonder where you got that idea from. Sean
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hi,
On Fri, Dec 04, 2020 at 12:13:26PM +0100, Uwe Kleine-König wrote:
> On Fri, Dec 04, 2020 at 08:44:17AM +0000, Sean Young wrote:
> > On Fri, Dec 04, 2020 at 12:42:15AM +0100, Lino Sanfilippo wrote:
> > > > You're storing an unsigned long long (i.e. 64 bits) in an u32. If
> > > > you are sure that this won't discard relevant bits, please explain
> > > > this in a comment for the cursory reader.
> > >
> > > What about an extra check then to make sure that the period has not been
> > > truncated,
> > > e.g:
> > >
> > > value = DIV_ROUND_CLOSEST_ULL(state->period, scaler);
> > >
> > > /* dont accept a period that is too small or has been truncated */
> > > if ((value < PERIOD_MIN) ||
> > > (value != DIV_ROUND_CLOSEST_ULL(state->period, scaler)))
> > > return -EINVAL;
> >
> > Rather than doing another 64 bit division which is expensive (esp on 32 bit
> > kernels), you could assign to u64 and check:
> >
> > if (value < PERIOD_MIN || value > U32_MAX)
> > return -EINVAL;
>
> Given that value is a u32, value > U32_MAX will never trigger.
I meant that value is declared u64 as well ("assign to u64").
> Maybe checking period before doing the division is more sensible.
That could introduce rounding errors, exactly why PERIOD_MIN was introduced.
> > > > Also note that round_closed is probably wrong, as .apply() is
> > > > supposed to round down the period to the next achievable period. (But
> > > > fixing this has to do done in a separate patch.)
> > >
> > > According to commit 11fc4edc4 rounding to the closest integer has been
> > > introduced
> > > to improve precision in case that the pwm controller is used by the
> > > pwm-ir-tx driver.
> > > I dont know how strong the requirement is to round down the period in
> > > apply(), but I
> > > can imagine that this may be a good reason to deviate from this rule.
> > > (CCing Sean Young who introduced DIV_ROUND_CLOSEST)
> >
> > There was a problem where the carrier is incorrect for some IR hardware
> > which uses a carrier of 455kHz. With periods that small, rounding errors
> > do really matter and rounding down might cause problems.
> >
> > A policy of rounding down the carrier is not the right thing to do
> > for pwm-ir-tx, and such a change will probably break pwm-ir-tx in some
> > edge cases.
>
> IMO it's not an option to say: pwm-driver A is used for IR, so A's
> .apply uses round-nearest and pwm-driver B is used for $somethingelse,
> so B's .apply uses round-down.
I'm not saying that one driver should have one it one way and another driver
another way.
> To be a sensible API pwm_apply_state
> should have a fixed behaviour. I consider round-down the sensible
> choice (because it is easier to implmement the other options with this)
It's not sensible when it's wrong about half the time.
Why is is easier to implement?
> and for consumers like the IR stuff we need to provide some more
> functions to allow it selecting a better suited state. Something like:
>
> pwm_round_state_nearest(pwm, { .period = 2198, .. }, )
>
> which queries the hardwares capabilities and then assigns state.period =
> 2200 instead of 2100.
This is very elaborate and surely not "easier to implement". Why not just
do the right thing in the first place and round-closest?
> Where can I find the affected (consumer) driver?
So there is the pwm-ir-tx driver. The infrared led is directly connected
to the pwm output pin, so that's all there is.
Thanks,
Sean
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
On Fri, Dec 04, 2020 at 08:44:17AM +, Sean Young wrote: > On Fri, Dec 04, 2020 at 12:42:15AM +0100, Lino Sanfilippo wrote: > > According to commit 11fc4edc4 rounding to the closest integer has been > > introduced > > to improve precision in case that the pwm controller is used by the > > pwm-ir-tx driver. > > I dont know how strong the requirement is to round down the period in > > apply(), but I > > can imagine that this may be a good reason to deviate from this rule. > > (CCing Sean Young who introduced DIV_ROUND_CLOSEST) > > There was a problem where the carrier is incorrect for some IR hardware > which uses a carrier of 455kHz. With periods that small, rounding errors > do really matter and rounding down might cause problems. > > A policy of rounding down the carrier is not the right thing to do > for pwm-ir-tx, and such a change will probably break pwm-ir-tx in some > edge cases. Let me rephrase that. Changing the division to rounding down will exactly revert the fix I made in commit 11fc4edc483bea8bf0efa0cc726886d2342f6fa6. So in the case described in that commit, the requested frequency was 455kHz, but rounding down resulted in a frequency of 476kHz. That's totally broken and a bad idea. Sean
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hi, On Fri, Dec 04, 2020 at 12:42:15AM +0100, Lino Sanfilippo wrote: > > You're storing an unsigned long long (i.e. 64 bits) in an u32. If > > you are sure that this won't discard relevant bits, please explain > > this in a comment for the cursory reader. > > What about an extra check then to make sure that the period has not been > truncated, > e.g: > > value = DIV_ROUND_CLOSEST_ULL(state->period, scaler); > > /* dont accept a period that is too small or has been truncated */ > if ((value < PERIOD_MIN) || > (value != DIV_ROUND_CLOSEST_ULL(state->period, scaler))) > return -EINVAL; Rather than doing another 64 bit division which is expensive (esp on 32 bit kernels), you could assign to u64 and check: if (value < PERIOD || value > U32_MAX) return -EINVAL; > > Also note that round_closed is probably wrong, as .apply() is > > supposed to round down the period to the next achievable period. (But > > fixing this has to do done in a separate patch.) > > According to commit 11fc4edc4 rounding to the closest integer has been > introduced > to improve precision in case that the pwm controller is used by the pwm-ir-tx > driver. > I dont know how strong the requirement is to round down the period in > apply(), but I > can imagine that this may be a good reason to deviate from this rule. > (CCing Sean Young who introduced DIV_ROUND_CLOSEST) There was a problem where the carrier is incorrect for some IR hardware which uses a carrier of 455kHz. With periods that small, rounding errors do really matter and rounding down might cause problems. A policy of rounding down the carrier is not the right thing to do for pwm-ir-tx, and such a change will probably break pwm-ir-tx in some edge cases. Thanks Sean
Re: linux-next: build warning after merge of the v4l-dvb tree
On Thu, Nov 26, 2020 at 05:54:52PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 18 Nov 2020 16:29:34 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the v4l-dvb tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > Documentation/output/lirc.h.rst:6: WARNING: undefined label: rc-proto-max
> > (if the link has no caption the label must precede a section header)
> >
> > Introduced by commit
> >
> > 72e637fec558 ("media: rc: validate that "rc_proto" is reasonable")
>
> I am still getting this - despite commit
>
> cea357bc2571 ("media: lirc: ensure RC_PROTO_MAX has documentation")
>
> and today I got a second copy of the warning ...
Yes, this my bad. Thanks for pointing this out -- again.
In the mean time, this should be resolved by commit 711561a41d1f ("media:
lirc: fix lirc.h documentation generation").
Thanks,
Sean
Re: [PATCH 0/2] Improve LIRC documentation
On Thu, Nov 26, 2020 at 02:00:54PM +0100, Mauro Carvalho Chehab wrote: > Hi Sean, > > Those two patches improve LIRC uAPI docs by adding the structs documented at > lirc.h to the output of > Documentation/output/userspace-api/media/rc/lirc-dev-intro.html > > Please review. Thanks, For the series: Signed-off-by: Sean Young > > Mauro Carvalho Chehab (2): > media: docs: uAPI: rc: dual-license the docs with GPL v2 > media: rc: improve LIRC documentation > > Documentation/userspace-api/media/rc/keytable.c.rst | 2 +- > .../userspace-api/media/rc/lirc-dev-intro.rst | 13 ++--- > Documentation/userspace-api/media/rc/lirc-dev.rst | 2 +- > Documentation/userspace-api/media/rc/lirc-func.rst | 2 +- > .../userspace-api/media/rc/lirc-get-features.rst| 2 +- > .../userspace-api/media/rc/lirc-get-rec-mode.rst| 2 +- > .../media/rc/lirc-get-rec-resolution.rst| 2 +- > .../userspace-api/media/rc/lirc-get-send-mode.rst | 2 +- > .../userspace-api/media/rc/lirc-get-timeout.rst | 2 +- > .../userspace-api/media/rc/lirc-header.rst | 2 +- > Documentation/userspace-api/media/rc/lirc-read.rst | 2 +- > .../media/rc/lirc-set-measure-carrier-mode.rst | 2 +- > .../media/rc/lirc-set-rec-carrier-range.rst | 2 +- > .../userspace-api/media/rc/lirc-set-rec-carrier.rst | 2 +- > .../media/rc/lirc-set-rec-timeout-reports.rst | 2 +- > .../userspace-api/media/rc/lirc-set-rec-timeout.rst | 2 +- > .../media/rc/lirc-set-send-carrier.rst | 2 +- > .../media/rc/lirc-set-send-duty-cycle.rst | 2 +- > .../media/rc/lirc-set-transmitter-mask.rst | 2 +- > .../media/rc/lirc-set-wideband-receiver.rst | 2 +- > Documentation/userspace-api/media/rc/lirc-write.rst | 2 +- > Documentation/userspace-api/media/rc/rc-intro.rst | 2 +- > Documentation/userspace-api/media/rc/rc-protos.rst | 2 +- > .../userspace-api/media/rc/rc-sysfs-nodes.rst | 2 +- > .../userspace-api/media/rc/rc-table-change.rst | 2 +- > Documentation/userspace-api/media/rc/rc-tables.rst | 2 +- > .../userspace-api/media/rc/remote_controllers.rst | 2 +- > include/uapi/linux/lirc.h | 2 +- > 28 files changed, 37 insertions(+), 30 deletions(-) > > -- > 2.28.0 >
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote: > On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > > wrote: > > > It's not about the risk of the changes it's about the cost of > > > implementing them. Even if you discount the producer time (which > > > someone gets to pay for, and if I were the engineering manager, I'd > > > be unhappy about), the review/merge/rework time is pretty > > > significant in exchange for six minor bug fixes. Fine, when a new > > > compiler warning comes along it's certainly reasonable to see if we > > > can benefit from it and the fact that the compiler people think > > > it's worthwhile is enough evidence to assume this initially. But > > > at some point you have to ask whether that assumption is supported > > > by the evidence we've accumulated over the time we've been using > > > it. And if the evidence doesn't support it perhaps it is time to > > > stop the experiment. > > > > Maintainers routinely review 1-line trivial patches, not to mention > > internal API changes, etc. > > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 > > The whole crux of your argument seems to be maintainers' time isn't > important so we should accept all trivial patches ... I'm pushing back > on that assumption in two places, firstly the valulessness of the time > and secondly that all trivial patches are valuable. You're assuming burn out or recruitment problems is due to patch workload or too many "trivial" patches. In my experience, "other maintainers" is by far the biggest cause of burn out for my kernel maintenance work. Certainly arguing with a maintainer about some obviously-correct patch series must be a good example of this. Sean
Re: [PATCH] media: rc: add keymap for KHAMSIN remote
On Thu, Nov 19, 2020 at 08:22:15AM +, Christian Hewitt wrote:
> This remote ships with the Amlogic SML-5442TW IPTV/VOD Set-tob Box [0]
> used by O2.cz. This keymap adds support for the default IR controls.
s/Set-tob/Set-top/
Not sure what [0] refers to.
> Signed-off-by: Christian Hewitt
> ---
> drivers/media/rc/keymaps/Makefile | 1 +
> drivers/media/rc/keymaps/rc-khamsin.c | 75 +++
> include/media/rc-map.h| 1 +
> 3 files changed, 77 insertions(+)
> create mode 100644 drivers/media/rc/keymaps/rc-khamsin.c
>
> diff --git a/drivers/media/rc/keymaps/Makefile
> b/drivers/media/rc/keymaps/Makefile
> index aaa1bf81d00d..1c4d6bec0ae4 100644
> --- a/drivers/media/rc/keymaps/Makefile
> +++ b/drivers/media/rc/keymaps/Makefile
> @@ -60,6 +60,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
> rc-it913x-v2.o \
> rc-kaiomy.o \
> rc-khadas.o \
> + rc-khamsin.o \
> rc-kworld-315u.o \
> rc-kworld-pc150u.o \
> rc-kworld-plus-tv-analog.o \
> diff --git a/drivers/media/rc/keymaps/rc-khamsin.c
> b/drivers/media/rc/keymaps/rc-khamsin.c
> new file mode 100644
> index ..8a397590009a
> --- /dev/null
> +++ b/drivers/media/rc/keymaps/rc-khamsin.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (c) 2020 Christian Hewitt
> +
> +#include
> +#include
> +
> +/*
> + * KHAMSIN is an IR/Bluetooth RCU supplied with the SmartLabs
> + * SML-5442TW DVB-S/VOD box. The RCU has separate IR (TV) and
> + * BT (STB) modes. This keymap suppors the IR controls.
> + */
> +
> +static struct rc_map_table khamsin[] = {
> + { 0x70702, KEY_POWER},
> +
> + { 0x70701, KEY_VIDEO}, // source
> +
> + { 0x7076c, KEY_RED},
> + { 0x70714, KEY_GREEN},
> + { 0x70715, KEY_YELLOW},
> + { 0x70716, KEY_BLUE},
> +
> + { 0x7071a, KEY_MENU},
> + { 0x7074f, KEY_EPG},
> +
> + { 0x70760, KEY_UP },
> + { 0x70761, KEY_DOWN },
> + { 0x70765, KEY_LEFT },
> + { 0x70762, KEY_RIGHT },
> + { 0x70768, KEY_ENTER },
> +
> + { 0x7072d, KEY_ESC }, // back
> +
> + { 0x70707, KEY_VOLUMEUP },
> + { 0x7070b, KEY_VOLUMEDOWN },
> + { 0x7070f, KEY_MUTE },
> + { 0x70712, KEY_CHANNELUP },
> + { 0x70710, KEY_CHANNELDOWN },
> +
> + { 0x70704, KEY_1 },
> + { 0x70705, KEY_2 },
> + { 0x70706, KEY_3 },
> + { 0x70708, KEY_4 },
> + { 0x70709, KEY_5 },
> + { 0x7070a, KEY_6 },
> + { 0x7070c, KEY_7 },
> + { 0x7070d, KEY_8 },
> + { 0x7070e, KEY_9 },
> + { 0x70711, KEY_0 },
> +};
> +
> +static struct rc_map_list khamsin_map = {
> + .map = {
> + .scan = khamsin,
> + .size = ARRAY_SIZE(khamsin),
> + .rc_proto = RC_PROTO_NEC,
Anything with scancodes > 0x is RC_PROTO_NECX.
> + .name = RC_MAP_KHAMSIN,
> + }
> +};
> +
> +static int __init init_rc_map_khamsin(void)
> +{
> + return rc_map_register(_map);
> +}
> +
> +static void __exit exit_rc_map_khamsin(void)
> +{
> + rc_map_unregister(_map);
> +}
> +
> +module_init(init_rc_map_khamsin)
> +module_exit(exit_rc_map_khamsin)
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Christian Hewitt ");
> diff --git a/include/media/rc-map.h b/include/media/rc-map.h
> index 7dbb91c601a7..fa270f16a97b 100644
> --- a/include/media/rc-map.h
> +++ b/include/media/rc-map.h
> @@ -263,6 +263,7 @@ struct rc_map *rc_map_get(const char *name);
> #define RC_MAP_IT913X_V2 "rc-it913x-v2"
> #define RC_MAP_KAIOMY"rc-kaiomy"
> #define RC_MAP_KHADAS"rc-khadas"
> +#define RC_MAP_KHAMSIN "rc-khamsin"
> #define RC_MAP_KWORLD_315U "rc-kworld-315u"
> #define RC_MAP_KWORLD_PC150U "rc-kworld-pc150u"
> #define RC_MAP_KWORLD_PLUS_TV_ANALOG "rc-kworld-plus-tv-analog"
Please can you also patch:
Documentation/devicetree/bindings/media/rc.yaml
Looks good otherwise.
Thanks,
Sean
Re: [PATCH V3 1/2] bindings: media: gpio-ir-receiver: add linux,autosuspend-period property
On Mon, Oct 05, 2020 at 08:36:39AM -0500, Rob Herring wrote: > On Sat, Oct 3, 2020 at 3:46 AM Sean Young wrote: > > > > On Tue, Sep 29, 2020 at 10:52:01AM -0500, Rob Herring wrote: > > > On Wed, Sep 23, 2020 at 03:08:06AM +0800, Joakim Zhang wrote: > > > > Add linux,autosuspend-period property for gpio ir receiver. Some cpuidle > > > > systems wake from idle may take a bit long time, for such case, need > > > > disable cpuidle temporarily. > > > > > > > > Signed-off-by: Joakim Zhang > > > > --- > > > > ChangeLogs: > > > > V1->V2: > > > > * New add. > > > > V2->V3: > > > > * linux,autosuspend-period = 125; -> linux,autosuspend-period = > > > > <125>; > > > > --- > > > > Documentation/devicetree/bindings/media/gpio-ir-receiver.txt | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > > > b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > > > index 58261fb7b408..e1447c9b0e26 100644 > > > > --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > > > +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > > > @@ -7,6 +7,8 @@ Required properties: > > > > Optional properties: > > > > - linux,rc-map-name: see rc.txt file in the same > > > > directory. > > > > +- linux,autosuspend-period: autosuspend delay time, > > > > + the unit is milisecond. > > > > > > What makes this linux specific? > > > > Good point. "linux,autosuspend-period" does not say what is being > > suspended either. How about "cpuidle-suspend-period" instead? > > 'cpuidle' is a Linuxism. And you also need a unit suffix. > > I'm not clear on how autosuspend which is generally how long a > peripheral is idle before runtime suspending it relates to this which > seems to be concerned with cpu wakeup latency. I'm assuming you need > to wake up within a certain time period to capture GPIO edges. Don't > you know what this time would be based on IR data rates and can > provide that constraint to cpuidle? > > Also, we can set autosuspend times from sysfs. Why do you need to do > this from DT? This driver collects the timings of the edges on the gpio line, and sends them to the IR decoders. Waking up the cpu out of cpuidle causes random delays and therefore timing are off, on some hardware. This setting turns off cpuidle for a period to prevent these problems. Note that on this soc cpuidle is causing huge delays, 500 microseconds or so. Sean
Re: [PATCH V3 1/2] bindings: media: gpio-ir-receiver: add linux,autosuspend-period property
On Tue, Sep 29, 2020 at 10:52:01AM -0500, Rob Herring wrote: > On Wed, Sep 23, 2020 at 03:08:06AM +0800, Joakim Zhang wrote: > > Add linux,autosuspend-period property for gpio ir receiver. Some cpuidle > > systems wake from idle may take a bit long time, for such case, need > > disable cpuidle temporarily. > > > > Signed-off-by: Joakim Zhang > > --- > > ChangeLogs: > > V1->V2: > > * New add. > > V2->V3: > > * linux,autosuspend-period = 125; -> linux,autosuspend-period = <125>; > > --- > > Documentation/devicetree/bindings/media/gpio-ir-receiver.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > index 58261fb7b408..e1447c9b0e26 100644 > > --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > > @@ -7,6 +7,8 @@ Required properties: > > Optional properties: > > - linux,rc-map-name: see rc.txt file in the same > > directory. > > +- linux,autosuspend-period: autosuspend delay time, > > + the unit is milisecond. > > What makes this linux specific? Good point. "linux,autosuspend-period" does not say what is being suspended either. How about "cpuidle-suspend-period" instead? Sean
Re: [PATCH V3 0/2] Add QoS support for cpuidle system.
On Wed, Sep 23, 2020 at 03:08:05AM +0800, Joakim Zhang wrote: > Add QoS support for cpuidle system. Reviewed-by: Sean Young Rob, would you be able to review the device tree bindings please? Thanks, Sean > > Joakim Zhang (2): > bindings: media: gpio-ir-receiver: add linux,autosuspend-period > property > media: rc: gpio-ir-recv: add QoS support for cpuidle system > > .../bindings/media/gpio-ir-receiver.txt | 3 ++ > drivers/media/rc/gpio-ir-recv.c | 53 +++ > 2 files changed, 56 insertions(+) > > -- > 2.17.1
Re: [PATCH V2 2/2] media: rc: gpio-ir-recv: add QoS support for cpuidle system
Hi Joakim,
Thanks for your updated patch.
On Sat, Sep 19, 2020 at 02:17:17AM +0800, Joakim Zhang wrote:
> GPIO IR receive is much rely on interrupt response, uneven interrupt
> latency will lead to incorrect timing, so the decoder fails to decode
> it. The issue is particularly acute on some systems which support
> cpuidle, not all, dynamically disable and enable cpuidle can solve this
> problem to a great extent.
>
> However, there is a downside to this approach, the measurement of header
> on the first frame may incorrect. Test on i.MX8M serials, when enable
> cpuidle, interrupt latency could be about 500us.
>
> With this patch:
> 1. has no side effect on non-cpuidle system.
> 2. latency is still much longer for the first gpio interrupt on cpuidle
> system, so the first frame may not be decoded. Generally, RC would transmit
> multiple frames at once press, we can sacrifice the first frame.
> 3. add "linux,autosuspend-period" property in device tree if you also
> suffer this cpuidle issue.
>
> Signed-off-by: Joakim Zhang
> ---
> ChangeLogs:
> V1->V2:
> * set autosuspend delay time via device tree.
> ---
> drivers/media/rc/gpio-ir-recv.c | 50 +
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
> index a20413008c3c..63cf8290eb19 100644
> --- a/drivers/media/rc/gpio-ir-recv.c
> +++ b/drivers/media/rc/gpio-ir-recv.c
> @@ -11,6 +11,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -20,17 +22,35 @@ struct gpio_rc_dev {
> struct rc_dev *rcdev;
> struct gpio_desc *gpiod;
> int irq;
> + struct device *dev;
> + struct pm_qos_request qos;
> };
>
> static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
> {
> int val;
> struct gpio_rc_dev *gpio_dev = dev_id;
> + struct device *dev = gpio_dev->dev;
> +
> + /*
> + * For some cpuidle systems, not all:
> + * Respond to interrupt taking more latency when cpu in idle.
> + * Invoke asynchronous pm runtime get from interrupt context,
> + * this may introduce a millisecond delay to call resume callback,
> + * where to disable cpuilde.
> + *
> + * Two issues lead to fail to decode first frame, one is latency to
> + * respond to interrupt, another is delay introduced by async api.
> + */
> + pm_runtime_get(dev);
>
> val = gpiod_get_value(gpio_dev->gpiod);
> if (val >= 0)
> ir_raw_event_store_edge(gpio_dev->rcdev, val == 1);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> +
I've dusted off my rpi and tried to see if it fails with cpuidle enabled.
As far as I can see, it always works fine. So, my only concern is that
there is a bunch of pm busy work done here for devices that do not need it,
including spinlocks, ktime. etc.
You could rename the dev field of gpio_rc_dev to pmdev and only do this
work if pm_dev != NULL. Or some other mechanism of doing this work
conditionally.
Having said that I'm not entirely sure this will make much of a difference.
> return IRQ_HANDLED;
> }
>
> @@ -40,6 +60,7 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
> struct device_node *np = dev->of_node;
> struct gpio_rc_dev *gpio_dev;
> struct rc_dev *rcdev;
> + u32 period = 0;
> int rc;
>
> if (!np)
> @@ -83,6 +104,7 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
> rcdev->map_name = RC_MAP_EMPTY;
>
> gpio_dev->rcdev = rcdev;
> + gpio_dev->dev = dev;
>
> rc = devm_rc_register_device(dev, rcdev);
> if (rc < 0) {
> @@ -90,6 +112,14 @@ static int gpio_ir_recv_probe(struct platform_device
> *pdev)
> return rc;
> }
>
> + of_property_read_u32(np, "linux,autosuspend-period", );
> + if (period) {
> + pm_runtime_set_autosuspend_delay(dev, period);
> + pm_runtime_use_autosuspend(dev);
> + pm_runtime_set_suspended(dev);
> + pm_runtime_enable(dev);
> + }
> +
> platform_set_drvdata(pdev, gpio_dev);
>
> return devm_request_irq(dev, gpio_dev->irq, gpio_ir_recv_irq,
> @@ -122,9 +152,29 @@ static int gpio_ir_recv_resume(struct device *dev)
> return 0;
> }
>
> +static int gpio_ir_recv_runtime_suspend(struct device *dev)
> +{
> + struct gpio_rc_dev *gpio_dev = dev_get_drvdata(dev);
> +
> + cpu_latency_qos_remove_request(_dev->qos);
> +
> + return 0;
> +}
> +
> +static int gpio_ir_recv_runtime_resume(struct device *dev)
> +{
> + struct gpio_rc_dev *gpio_dev = dev_get_drvdata(dev);
> +
> + cpu_latency_qos_add_request(_dev->qos, 0);
> +
> + return 0;
> +}
> +
> static const struct dev_pm_ops gpio_ir_recv_pm_ops = {
> .suspend= gpio_ir_recv_suspend,
> .resume = gpio_ir_recv_resume,
> + .runtime_suspend =
Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system
Hi Joakim, On Fri, Sep 18, 2020 at 01:42:15AM +, Joakim Zhang wrote: > > -Original Message- > > From: Sean Young > > Sent: 2020年9月18日 4:44 > > To: Joakim Zhang > > Cc: mche...@kernel.org; linux-me...@vger.kernel.org; > > linux-kernel@vger.kernel.org; dl-linux-imx > > Subject: Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle > > system -snip- > > > Autosuspend delay should be fixed value, should be set to gpio device > > > timeout > > value, which is 125ms. > > > > So the idea was that cpuidle is only enabled while IR frames are being > > received, > > that's why I suggested it. > > May be a typo, "cpuidle is only DISABLED while IR frames are being receive,", > this is not I want to implement, experiments have also shown poor results. Sorry, yes I got this wrong. You are right. > > If you set the autosuspend delay to 125ms, then the cpuidle will not be > > enabled > > between IR frames. Maybe this is what you want, but it does mean cpuidle is > > totally suspended while anyone is pressing buttons on a remote. > > Yes, this is what I want, cpuidle is totally disabled while pressing buttons, > disable cpuidle at the first frame then keep disabled until there is no > activity for a while. > So that we only can not decode the first frame, such as, if transmitting 4 > frames once, we can correctly decode 3 times. > > I also try your suggestion, set autosuspend delay time to protocol's timeout > value, but the result is terrible. If transmitting 4 frames once, we can't > correctly decode 3 times, > even can't decode it sometime. The sequence is, cpu in idle state when the > first frame coming, then disable cpu idle until protocols' timeout, cpu in > idle state again, the first frame can't be decoded. > The second frame coming, it will repeat the behavior of the first frame, may > cause the second frame can't be decode.. > > Can you take account of I have done in the first version, autosuspend delay > time is set to 125ms? Yes, in retrospect you are right. Trying to shorten the cpuidle suspended period will not work. I am sorry about this. How about setting the autosuspend period in devicetree, and 0 will turn this feature off completely? Thanks, Sean
Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system
Hi Joakim, On Thu, Sep 17, 2020 at 09:12:32AM +, Joakim Zhang wrote: > > > -Original Message- > > From: Sean Young > > Sent: 2020年9月15日 17:34 > > To: Joakim Zhang > > Cc: mche...@kernel.org; linux-me...@vger.kernel.org; > > linux-kernel@vger.kernel.org; dl-linux-imx > > Subject: Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle > > system > > > > > > [...] > > > @@ -92,6 +113,12 @@ static int gpio_ir_recv_probe(struct > > > platform_device *pdev) > > > > > > platform_set_drvdata(pdev, gpio_dev); > > > > > > + > > > + pm_runtime_set_autosuspend_delay(dev, (rcdev->timeout / 1000 / > > > +1000)); > > > > rcdev->timeout is in microseconds (since very recently), so this is wrong. > > Also, the timeout can be changed using the LIRC_SET_REC_TIMEOUT ioctl > > (using ir-ctl -t in userspace). The autosuspend delay should be updated when > > this happens. This can be done by implementing the s_timeout rcdev function. > > Hi Sean, > > I come across a problem when implementing this feature. > > At probe stage, devm_rc_register_device -> change_protocol, then timeout set > to 125ms. > > When echo sony or nec to protocols, will call change_protocol changing the > timeout value, that timeout would change to handler->min_timeout + 10ms. For > sony is 1600ns, for 15625000ns. The sony protocol decoder wants a 6ms space after the last bit. So, the timeout for the IR receiver can be set to 6ms (plus 10ms margin). This has the advantage that decoding is happens very quickly. Before this change, there as a 125ms delay before the first and last IR frame was decoded. This causes decoding to feel laggy and keys also a bit sticky. > This is not the way I want to take before, this would frequently > disable/enable cpuidle. So is it necessary to provide s_timeout, this > callback should be used to change protocols' timeout? > If implement s_timeout, users need change the timeout value from userspace, > this is a mandatory operation and unfriendly. And it will affect protocol's > timeout. > > Autosuspend delay should be fixed value, should be set to gpio device timeout > value, which is 125ms. So the idea was that cpuidle is only enabled while IR frames are being received, that's why I suggested it. If you set the autosuspend delay to 125ms, then the cpuidle will not be enabled between IR frames. Maybe this is what you want, but it does mean cpuidle is totally suspended while anyone is pressing buttons on a remote. Thanks Sean > > Best Regards, > Joakim Zhang > > > + pm_runtime_use_autosuspend(dev); > > > + pm_runtime_set_suspended(dev); > > > + pm_runtime_enable(dev); > > > + > > > return devm_request_irq(dev, gpio_dev->irq, gpio_ir_recv_irq, > > > IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, > > > "gpio-ir-recv-irq", gpio_dev);
Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system
Hi Joakim, On Wed, Sep 16, 2020 at 10:22:11AM +, Joakim Zhang wrote: > > Hi Sean, > > Thanks for your hint, I will send a V2 soon according to your suggestions. > > We also have a concern, since you are a IR expert, may you can give us > answers. With this patch, the first frame once press could not been decoded. > AFAIK, IR protocols have not specify how may frames transmitting once press, > is there ang criterion to decide this? > > Is it possible that single frame transmitting once pressing? Per my > understanding, it will transmit more than one frame. So remotes send IR signals while a button is being pressed down. For the remotes I've seen, when pressing a button a short amount of time will repeat the IR message at least three times. This is a few times when I've tried this, but by no means exhaustive of all remotes or protocols. I think the question you are trying to answer is, if we miss the first message, will we at least have another chance if the message is repeated? So I think the message will be repeated, but the repeat message is not enough for the nec protocol. The nec repeat is a shorter message which does not carry any information apart from "last key still pressed": https://www.sbprojects.net/knowledge/ir/nec.php Thanks, Sean
Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system
Hi Joakim,
On Tue, Sep 15, 2020 at 10:55:17AM +, Joakim Zhang wrote:
>
> Hi Sean,
>
> Thanks a lot for your review.
>
> > -Original Message-
> > From: Sean Young
> > Sent: 2020年9月15日 17:34
> > To: Joakim Zhang
> > Cc: mche...@kernel.org; linux-me...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; dl-linux-imx
> > Subject: Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle
> > system
> >
> >
> > Hi Joakim,
> >
> > Thanks for your patch, I think it looks good in principle but needs a few
> > small
> > fixes.
> >
> > On Tue, Sep 15, 2020 at 11:02:02PM +0800, Joakim Zhang wrote:
> > > GPIO IR receive is much rely on interrupt response, uneven interrupt
> > > latency will lead to incorrect timing, so the decoder fails to decode
> > > it. The issue is particularly acute on systems which supports cpuidle,
> > > dynamically disable and enable cpuidle can solve this problem to a
> > > great extent.
> >
> > This is the first soc to be affected by this problem, and gpio-ir-recv has
> > been
> > used on my systems. For example, the raspberry pi has cpu idle enabled and
> > does not suffer from this problem. There are many more; this driver has been
> > used on many arm devices, which will have cpuidle enabled.
> I have not noticed raspberry pi enabled cpu idle in Linux, could you point me
> where it is? Then I can have a look, whether it implements multiple idle or
> not, to see why it makes difference.
I just noticed that it not enabled on raspbian kernel, but it is enabled
on fedora:
https://src.fedoraproject.org/rpms/kernel/blob/master/f/kernel-armv7hl-fedora.config
When I use gpio-ir-recv with my own kernel and fedora kernel, there no
problems with gpio-ir-recv on this kernel.
> > > However, there is a downside to this approach, the measurement of
> > > header on the first frame may incorrect. Test on i.MX8M serials, when
> > > enable cpuidle, interrupt latency could be about 500us.
> > >
> > > With this patch:
> > > 1. has no side effect on non-cpuidle system.
> > > 2. latency is still much longer for the first gpio interrupt on
> > > cpuidle system, so the first frame may not be decoded. Generally, RC
> > > would transmit multiple frames at once press, we can sacrifice the first
> > frame.
> > >
> > > Signed-off-by: Joakim Zhang
> > > ---
> > > drivers/media/rc/gpio-ir-recv.c | 49
> > > -
> > > 1 file changed, 48 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/rc/gpio-ir-recv.c
> > > b/drivers/media/rc/gpio-ir-recv.c index a20413008c3c..42c942ce98cd
> > > 100644
> > > --- a/drivers/media/rc/gpio-ir-recv.c
> > > +++ b/drivers/media/rc/gpio-ir-recv.c
> > > @@ -11,6 +11,8 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -20,17 +22,36 @@ struct gpio_rc_dev {
> > > struct rc_dev *rcdev;
> > > struct gpio_desc *gpiod;
> > > int irq;
> > > + struct pm_qos_request qos;
> > > };
> > >
> > > static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id) {
> > > - int val;
> > > + int ret, val;
> > > struct gpio_rc_dev *gpio_dev = dev_id;
> > > + struct device *dev = gpio_dev->rcdev->dev.parent;
> > > +
> > > + /*
> > > + * For cpuidle system:
> >
> > For some cpuidle systems, not all. This is why this feature needs a device
> > tree
> > option for enabling. Otherwise, it will negatively affect power usage on
> > e.g.
> > raspberry pi.
> Yes, you are right. As you said, some cpu idle systems may not suffer such
> case, I will add a device tree property.
>
>
> > > + * Respond to interrupt taking more latency when cpu in idle.
> > > + * Invoke asynchronous pm runtime get from interrupt context,
> > > + * this may introduce a millisecond delay to call resume callback,
> > > + * where to disable cpuilde.
> > > + *
> > > + * Two issues lead to fail to decode first frame, one is latency to
> > > + * respond interupt, another is delay introduced by async api.
> > > + */
> > > + ret = pm_runtime_get(dev);
> > > + if (ret < 0)
> > > + return IRQ_NONE;
> >
> > If we end up here, we also abandon sending the IR to rc-core (below). I
>
Re: [PATCH] media: rc: fix check on dev->min_timeout for LIRC_GET_MIN_TIMEOUT ioctl
On Tue, Sep 15, 2020 at 04:36:08PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently the LIRC_GET_MIN_TIMEOUT is checking for a null dev->max_timeout
> and then accessing dev->min_timeout, hence we may have a potential null
> pointer dereference issue. This looks like a cut-n-paste typo, fix it
> by checking on dev->min_timeout before accessing it.
max_timeout and min_timeout are both u32, not pointers. So, the commit
message is wrong: there is no null pointer dereference issue.
Every driver which has max_timeout also has min_timeout set (I've checked
for this). So technically this is not wrong, but maybe it looks wrong?
Thanks,
Sean
>
> Addresses-Coverity: ("Copy-paste error")
> Fixes: e589333f346b ("V4L/DVB: IR: extend interfaces to support more device
> settings")
> Signed-off-by: Colin Ian King
> ---
> drivers/media/rc/lirc_dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
> index 220363b9a868..d230c21e1d31 100644
> --- a/drivers/media/rc/lirc_dev.c
> +++ b/drivers/media/rc/lirc_dev.c
> @@ -533,7 +533,7 @@ static long lirc_ioctl(struct file *file, unsigned int
> cmd, unsigned long arg)
>
> /* Generic timeout support */
> case LIRC_GET_MIN_TIMEOUT:
> - if (!dev->max_timeout)
> + if (!dev->min_timeout)
> ret = -ENOTTY;
> else
> val = dev->min_timeout;
> --
> 2.27.0
Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system
Hi Joakim,
Thanks for your patch, I think it looks good in principle but needs a
few small fixes.
On Tue, Sep 15, 2020 at 11:02:02PM +0800, Joakim Zhang wrote:
> GPIO IR receive is much rely on interrupt response, uneven interrupt
> latency will lead to incorrect timing, so the decoder fails to decode
> it. The issue is particularly acute on systems which supports
> cpuidle, dynamically disable and enable cpuidle can solve this problem
> to a great extent.
This is the first soc to be affected by this problem, and gpio-ir-recv
has been used on my systems. For example, the raspberry pi has cpu idle
enabled and does not suffer from this problem. There are many more; this
driver has been used on many arm devices, which will have cpuidle enabled.
>
> However, there is a downside to this approach, the measurement of header
> on the first frame may incorrect. Test on i.MX8M serials, when enable
> cpuidle, interrupt latency could be about 500us.
>
> With this patch:
> 1. has no side effect on non-cpuidle system.
> 2. latency is still much longer for the first gpio interrupt on cpuidle
> system, so the first frame may not be decoded. Generally, RC would transmit
> multiple frames at once press, we can sacrifice the first frame.
>
> Signed-off-by: Joakim Zhang
> ---
> drivers/media/rc/gpio-ir-recv.c | 49 -
> 1 file changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
> index a20413008c3c..42c942ce98cd 100644
> --- a/drivers/media/rc/gpio-ir-recv.c
> +++ b/drivers/media/rc/gpio-ir-recv.c
> @@ -11,6 +11,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -20,17 +22,36 @@ struct gpio_rc_dev {
> struct rc_dev *rcdev;
> struct gpio_desc *gpiod;
> int irq;
> + struct pm_qos_request qos;
> };
>
> static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
> {
> - int val;
> + int ret, val;
> struct gpio_rc_dev *gpio_dev = dev_id;
> + struct device *dev = gpio_dev->rcdev->dev.parent;
> +
> + /*
> + * For cpuidle system:
For some cpuidle systems, not all. This is why this feature needs a
device tree option for enabling. Otherwise, it will negatively affect
power usage on e.g. raspberry pi.
> + * Respond to interrupt taking more latency when cpu in idle.
> + * Invoke asynchronous pm runtime get from interrupt context,
> + * this may introduce a millisecond delay to call resume callback,
> + * where to disable cpuilde.
> + *
> + * Two issues lead to fail to decode first frame, one is latency to
> + * respond interupt, another is delay introduced by async api.
> + */
> + ret = pm_runtime_get(dev);
> + if (ret < 0)
> + return IRQ_NONE;
If we end up here, we also abandon sending the IR to rc-core (below). I
don't think it should do that. It should call ir_raw_event_store_edge()
always even if it can't do the pm things.
>
> val = gpiod_get_value(gpio_dev->gpiod);
> if (val >= 0)
> ir_raw_event_store_edge(gpio_dev->rcdev, val == 1);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> +
> return IRQ_HANDLED;
> }
>
> @@ -92,6 +113,12 @@ static int gpio_ir_recv_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, gpio_dev);
>
> +
> + pm_runtime_set_autosuspend_delay(dev, (rcdev->timeout / 1000 / 1000));
rcdev->timeout is in microseconds (since very recently), so this is wrong.
Also, the timeout can be changed using the LIRC_SET_REC_TIMEOUT ioctl
(using ir-ctl -t in userspace). The autosuspend delay should be updated
when this happens. This can be done by implementing the s_timeout rcdev
function.
> + pm_runtime_use_autosuspend(dev);
> + pm_runtime_set_suspended(dev);
> + pm_runtime_enable(dev);
> +
> return devm_request_irq(dev, gpio_dev->irq, gpio_ir_recv_irq,
> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
> "gpio-ir-recv-irq", gpio_dev);
> @@ -122,9 +149,29 @@ static int gpio_ir_recv_resume(struct device *dev)
> return 0;
> }
>
> +static int gpio_ir_recv_runtime_suspend(struct device *dev)
> +{
> + struct gpio_rc_dev *gpio_dev = dev_get_drvdata(dev);
> +
> + cpu_latency_qos_remove_request(_dev->qos);
> +
> + return 0;
> +}
> +
> +static int gpio_ir_recv_runtime_resume(struct device *dev)
> +{
> + struct gpio_rc_dev *gpio_dev = dev_get_drvdata(dev);
> +
> + cpu_latency_qos_add_request(_dev->qos, 0);
> +
> + return 0;
> +}
> +
> static const struct dev_pm_ops gpio_ir_recv_pm_ops = {
> .suspend= gpio_ir_recv_suspend,
> .resume = gpio_ir_recv_resume,
> + .runtime_suspend = gpio_ir_recv_runtime_suspend,
> + .runtime_resume = gpio_ir_recv_runtime_resume,
> };
> #endif
>
> --
> 2.17.1
Re: [PATCH 4.19 053/125] media: gpio-ir-tx: improve precision of transmitted signal due to scheduling
Hi Pavel,
On Wed, Sep 02, 2020 at 12:25:21PM +0200, Pavel Machek wrote:
> Hi!
> >
> > [ Upstream commit ea8912b788f8144e7d32ee61e5ccba45424bef83 ]
> >
> > usleep_range() may take longer than the max argument due to scheduling,
> > especially under load. This is causing random errors in the transmitted
> > IR. Remove the usleep_range() in favour of busy-looping with udelay().
> >
> > Signed-off-by: Sean Young
>
> I don't believe this should be in stable.
>
> Yes, it probably fixes someone's remote control.
>
> It also introduces > half a second (!) with interrupts disabled
> (according to the code comments), which will break other devices on
> the system.
Yes, I've always been uncormfortable with this code, but nothing else I
tried worked.
BTW the delay has a maximum of half a second, but the point stands of
course.
> Less intrusive solutions should be explored, first. Like.. if that
> part is time-critical, perhaps it should set itself at realtime
> priority, so that scheduler has motivation to schedule it at the right
> times?
That is an interesting idea, I'll explore that.
> Perhaps usleep_range should be delta, delta+1?
I'm pretty sure I tried that and it didn't work. I'll give it another go.
> Perhaps udelay makes sense to use for more than 10usec?
I don't follow -- what are you suggesting here?
So any other ideas here would be very welcome. I'm happy to explore options,
so far under load the output is can be total garbage if you're unlucky.
Thanks,
Sean
>
> Best regards,
>
> Pavel
>
> > @@ -87,13 +87,8 @@ static int gpio_ir_tx(struct rc_dev *dev, unsigned int
> > *txbuf,
> > // space
> > edge = ktime_add_us(edge, txbuf[i]);
> > delta = ktime_us_delta(edge, ktime_get());
> > - if (delta > 10) {
> > - spin_unlock_irqrestore(_ir->lock, flags);
> > - usleep_range(delta, delta + 10);
> > - spin_lock_irqsave(_ir->lock, flags);
> > - } else if (delta > 0) {
> > + if (delta > 0)
> > udelay(delta);
> > - }
> > } else {
> > // pulse
> > ktime_t last = ktime_add_us(edge, txbuf[i]);
> > --
> > 2.25.1
> >
> >
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 4.19 016/125] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()
Greg,
On Tue, Sep 01, 2020 at 05:09:31PM +0200, Greg Kroah-Hartman wrote:
> From: Jia-Ju Bai
>
> [ Upstream commit 6499a0db9b0f1e903d52f8244eacc1d4be00eea2 ]
>
> The value av7110->debi_virt is stored in DMA memory, and it is assigned
> to data, and thus data[0] can be modified at any time by malicious
> hardware. In this case, "if (data[0] < 2)" can be passed, but then
> data[0] can be changed into a large number, which may cause buffer
> overflow when the code "av7110->ci_slot[data[0]]" is used.
>
> To fix this possible bug, data[0] is assigned to a local variable, which
> replaces the use of data[0].
See the discussion here:
https://lkml.org/lkml/2020/8/31/479
It does not seem worthwhile merging to the stable trees.
Thanks
Sean
>
> Signed-off-by: Jia-Ju Bai
> Signed-off-by: Sean Young
> Signed-off-by: Mauro Carvalho Chehab
> Signed-off-by: Sasha Levin
> ---
> drivers/media/pci/ttpci/av7110.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/pci/ttpci/av7110.c
> b/drivers/media/pci/ttpci/av7110.c
> index d6816effb8786..d02b5fd940c12 100644
> --- a/drivers/media/pci/ttpci/av7110.c
> +++ b/drivers/media/pci/ttpci/av7110.c
> @@ -424,14 +424,15 @@ static void debiirq(unsigned long cookie)
> case DATA_CI_GET:
> {
> u8 *data = av7110->debi_virt;
> + u8 data_0 = data[0];
>
> - if ((data[0] < 2) && data[2] == 0xff) {
> + if (data_0 < 2 && data[2] == 0xff) {
> int flags = 0;
> if (data[5] > 0)
> flags |= CA_CI_MODULE_PRESENT;
> if (data[5] > 5)
> flags |= CA_CI_MODULE_READY;
> - av7110->ci_slot[data[0]].flags = flags;
> + av7110->ci_slot[data_0].flags = flags;
> } else
> ci_get_data(>ci_rbuffer,
> av7110->debi_virt,
> --
> 2.25.1
>
>
Re: [PATCH] media: pci: ttpci: av7110: avoid compiler optimization of reading data[0] in debiirq()
On Sun, Aug 30, 2020 at 04:20:42PM +0800, Jia-Ju Bai wrote:
> In debiirq(), data_0 stores the value of data[0], but it can be dropped
> by compiler optimization. Thus, data[0] is read through READ_ONCE().
>
> Fixes: 6499a0db9b0f ("media: pci: ttpci: av7110: fix possible buffer overflow
> caused by bad DMA value in debiirq()")
> Reported-by: Pavel Machek
Pavel reported that your patch was garbage, if you are trying to defend
against a malicious pci device. READ_ONCE() will not help here.
Sean
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/media/pci/ttpci/av7110.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/pci/ttpci/av7110.c
> b/drivers/media/pci/ttpci/av7110.c
> index bf36b1e22b63..f7d098d5b198 100644
> --- a/drivers/media/pci/ttpci/av7110.c
> +++ b/drivers/media/pci/ttpci/av7110.c
> @@ -406,7 +406,7 @@ static void debiirq(unsigned long cookie)
> case DATA_CI_GET:
> {
> u8 *data = av7110->debi_virt;
> - u8 data_0 = data[0];
> + u8 data_0 = READ_ONCE(data[0]);
>
> if (data_0 < 2 && data[2] == 0xff) {
> int flags = 0;
> --
> 2.17.1
Re: [PATCH v1] [media] netup_unidvb: use generic power management
On Tue, Jul 28, 2020 at 02:57:17PM +0530, Vaibhav Gupta wrote:
> The .suspend() and .resume() callbacks are not defined for this driver.
> Still, their power management structure follows the legacy framework. To
> bring it under the generic framework, simply remove the binding of
> callbacks from "struct pci_driver".
Unlisted fields in a static struct initializer will get set to 0 (or NULL
for pointers) already. Removing the NULL initializers will not change
anything.
Possibly you want to remove the redundant initializers but your commit
message should say so.
Sean
>
> Signed-off-by: Vaibhav Gupta
> ---
> drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> index 80a7c41baa90..6f3125c2d097 100644
> --- a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> +++ b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> @@ -1016,8 +1016,6 @@ static struct pci_driver netup_unidvb_pci_driver = {
> .id_table = netup_unidvb_pci_tbl,
> .probe= netup_unidvb_initdev,
> .remove = netup_unidvb_finidev,
> - .suspend = NULL,
> - .resume = NULL,
> };
>
> module_pci_driver(netup_unidvb_pci_driver);
> --
> 2.27.0
Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()
On Sat, Aug 29, 2020 at 08:16:00PM +0300, Laurent Pinchart wrote:
> On Sat, Aug 29, 2020 at 02:10:20PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > The value av7110->debi_virt is stored in DMA memory, and it is assigned
> > > to data, and thus data[0] can be modified at any time by malicious
> > > hardware. In this case, "if (data[0] < 2)" can be passed, but then
> > > data[0] can be changed into a large number, which may cause buffer
> > > overflow when the code "av7110->ci_slot[data[0]]" is used.
> > >
> > > To fix this possible bug, data[0] is assigned to a local variable, which
> > > replaces the use of data[0].
> >
> > I'm pretty sure hardware capable of manipulating memory can work
> > around any such checks, but...
> >
> > > +++ b/drivers/media/pci/ttpci/av7110.c
> > > @@ -424,14 +424,15 @@ static void debiirq(unsigned long cookie)
> > > case DATA_CI_GET:
> > > {
> > > u8 *data = av7110->debi_virt;
> > > + u8 data_0 = data[0];
> > >
> > > - if ((data[0] < 2) && data[2] == 0xff) {
> > > + if (data_0 < 2 && data[2] == 0xff) {
> > > int flags = 0;
> > > if (data[5] > 0)
> > > flags |= CA_CI_MODULE_PRESENT;
> > > if (data[5] > 5)
> > > flags |= CA_CI_MODULE_READY;
> > > - av7110->ci_slot[data[0]].flags = flags;
> > > + av7110->ci_slot[data_0].flags = flags;
> >
> > This does not even do what it says. Compiler is still free to access
> > data[0] multiple times. It needs READ_ONCE() to be effective.
>
> Yes, it seems quite dubious to me. If we *really* want to guard against
> rogue hardware here, the whole DMA buffer should be copied. I don't
> think it's worth it, a rogue PCI device can do much more harm.
That is a good point. I'm not sure what the kernel could do to protect
against a malicious PCI device (that can do dma) so this patch is totally
pointless.
Thanks
Sean
Re: KASAN: use-after-free Read in rc_dev_uevent
On Sun, Aug 09, 2020 at 11:03:28AM -0300, Ezequiel Garcia wrote: > On Sat, 8 Aug 2020 at 06:25, Sean Young wrote: > > On Fri, Aug 07, 2020 at 08:45:12PM -0300, Ezequiel Garcia wrote: > > > On Fri, 7 Aug 2020 at 06:15, Sean Young wrote: > > > > > > > > On Fri, Aug 07, 2020 at 12:26:29AM -0700, syzbot wrote: > > > > > Hello, > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > HEAD commit:7b4ea945 Revert "x86/mm/64: Do not sync > > > > > vmalloc/ioremap ma.. > > > > > git tree: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git > > > > > usb-testing > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=11a7813a90 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=72a84c46d0c668c > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=ceef16277388d6f24898 > > > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > > > commit: > > > > > Reported-by: syzbot+ceef16277388d6f24...@syzkaller.appspotmail.com > > > > > > > > > > == > > > > > BUG: KASAN: use-after-free in string_nocheck lib/vsprintf.c:611 > > > > > [inline] > > > > > BUG: KASAN: use-after-free in string+0x39c/0x3d0 lib/vsprintf.c:693 > > > > > Read of size 1 at addr 8881ca21cd20 by task systemd-udevd/5147 > > > > > > > > > > CPU: 1 PID: 5147 Comm: systemd-udevd Not tainted 5.8.0-syzkaller #0 > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, > > > > > BIOS Google 01/01/2011 > > > > > Call Trace: > > > > > __dump_stack lib/dump_stack.c:77 [inline] > > > > > dump_stack+0xf6/0x16e lib/dump_stack.c:118 > > > > > print_address_description.constprop.0+0x1a/0x210 > > > > > mm/kasan/report.c:383 > > > > > __kasan_report mm/kasan/report.c:513 [inline] > > > > > kasan_report.cold+0x37/0x7c mm/kasan/report.c:530 > > > > > string_nocheck lib/vsprintf.c:611 [inline] > > > > > string+0x39c/0x3d0 lib/vsprintf.c:693 > > > > > vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2617 > > > > > add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:664 > > > > > rc_dev_uevent+0x54/0x140 drivers/media/rc/rc-main.c:1616 > > > > > dev_uevent+0x30e/0x780 drivers/base/core.c:1916 > > > > > uevent_show+0x1bb/0x360 drivers/base/core.c:1963 > > > > > dev_attr_show+0x4b/0x90 drivers/base/core.c:1667 > > > > > sysfs_kf_seq_show+0x1f8/0x400 fs/sysfs/file.c:60 > > > > > seq_read+0x432/0x1070 fs/seq_file.c:208 > > > > > kernfs_fop_read+0xe9/0x590 fs/kernfs/file.c:251 > > > > > vfs_read+0x1df/0x520 fs/read_write.c:479 > > > > > ksys_read+0x12d/0x250 fs/read_write.c:607 > > > > > do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 > > > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > RIP: 0033:0x7f6e6c02f910 > > > > > Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 > > > > > 0f 1f 44 00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> > > > > > 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24 > > > > > RSP: 002b:7fff3cddeae8 EFLAGS: 0246 ORIG_RAX: > > > > > RAX: ffda RBX: 558492caaae0 RCX: 7f6e6c02f910 > > > > > RDX: 1000 RSI: 558492cc7530 RDI: 0007 > > > > > RBP: 7f6e6c2ea440 R08: 7f6e6c2ee298 R09: 1010 > > > > > R10: 558492caaae0 R11: 0246 R12: 1000 > > > > > R13: 0d68 R14: 558492cc7530 R15: 7f6e6c2e9900 > > > > > > > > This thread is reading the uevent sysfs file, which reads > > > > rc_dev->map.name, and also rc_dev->device_name, but that is not causing > > > > problems is this case. > > > > > > > > > > > >
Re: KASAN: use-after-free Read in rc_dev_uevent
Hi Eze, On Fri, Aug 07, 2020 at 08:45:12PM -0300, Ezequiel Garcia wrote: > On Fri, 7 Aug 2020 at 06:15, Sean Young wrote: > > > > On Fri, Aug 07, 2020 at 12:26:29AM -0700, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit:7b4ea945 Revert "x86/mm/64: Do not sync vmalloc/ioremap > > > ma.. > > > git tree: > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing > > > console output: https://syzkaller.appspot.com/x/log.txt?x=11a7813a90 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=72a84c46d0c668c > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=ceef16277388d6f24898 > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > commit: > > > Reported-by: syzbot+ceef16277388d6f24...@syzkaller.appspotmail.com > > > > > > == > > > BUG: KASAN: use-after-free in string_nocheck lib/vsprintf.c:611 [inline] > > > BUG: KASAN: use-after-free in string+0x39c/0x3d0 lib/vsprintf.c:693 > > > Read of size 1 at addr 8881ca21cd20 by task systemd-udevd/5147 > > > > > > CPU: 1 PID: 5147 Comm: systemd-udevd Not tainted 5.8.0-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > > Google 01/01/2011 > > > Call Trace: > > > __dump_stack lib/dump_stack.c:77 [inline] > > > dump_stack+0xf6/0x16e lib/dump_stack.c:118 > > > print_address_description.constprop.0+0x1a/0x210 mm/kasan/report.c:383 > > > __kasan_report mm/kasan/report.c:513 [inline] > > > kasan_report.cold+0x37/0x7c mm/kasan/report.c:530 > > > string_nocheck lib/vsprintf.c:611 [inline] > > > string+0x39c/0x3d0 lib/vsprintf.c:693 > > > vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2617 > > > add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:664 > > > rc_dev_uevent+0x54/0x140 drivers/media/rc/rc-main.c:1616 > > > dev_uevent+0x30e/0x780 drivers/base/core.c:1916 > > > uevent_show+0x1bb/0x360 drivers/base/core.c:1963 > > > dev_attr_show+0x4b/0x90 drivers/base/core.c:1667 > > > sysfs_kf_seq_show+0x1f8/0x400 fs/sysfs/file.c:60 > > > seq_read+0x432/0x1070 fs/seq_file.c:208 > > > kernfs_fop_read+0xe9/0x590 fs/kernfs/file.c:251 > > > vfs_read+0x1df/0x520 fs/read_write.c:479 > > > ksys_read+0x12d/0x250 fs/read_write.c:607 > > > do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > RIP: 0033:0x7f6e6c02f910 > > > Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f > > > 1f 44 00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 > > > ff ff 73 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24 > > > RSP: 002b:7fff3cddeae8 EFLAGS: 0246 ORIG_RAX: > > > RAX: ffda RBX: 558492caaae0 RCX: 7f6e6c02f910 > > > RDX: 1000 RSI: 558492cc7530 RDI: 0007 > > > RBP: 7f6e6c2ea440 R08: 7f6e6c2ee298 R09: 1010 > > > R10: 558492caaae0 R11: 0246 R12: 1000 > > > R13: 0d68 R14: 558492cc7530 R15: 7f6e6c2e9900 > > > > This thread is reading the uevent sysfs file, which reads > > rc_dev->map.name, and also rc_dev->device_name, but that is not causing > > problems is this case. > > > > > > > > Allocated by task 5: > > > save_stack+0x1b/0x40 mm/kasan/common.c:48 > > > set_track mm/kasan/common.c:56 [inline] > > > __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 > > > slab_post_alloc_hook mm/slab.h:586 [inline] > > > slab_alloc_node mm/slub.c:2824 [inline] > > > slab_alloc mm/slub.c:2832 [inline] > > > __kmalloc_track_caller+0xec/0x280 mm/slub.c:4430 > > > kstrdup+0x36/0x70 mm/util.c:60 > > > ir_create_table drivers/media/rc/rc-main.c:217 [inline] > > > ir_setkeytable drivers/media/rc/rc-main.c:477 [inline] > > > rc_prepare_rx_device drivers/media/rc/rc-main.c:1786 [inline] > > > rc_register_device+0x464/0x1600 drivers/media/rc/rc-main.c:1914 > > > igorplugusb_probe+0x7e6/0xc98 drivers/media/rc/igorplugusb.c:209 > > > usb_probe_interface+0x315/0x7f0 drivers
Re: KASAN: use-after-free Read in rc_dev_uevent
On Fri, Aug 07, 2020 at 09:55:40PM +0800, Hillf Danton wrote: > > On Fri, 7 Aug 2020 10:15:04 +0100 Sean Young wrote: > > On Fri, Aug 07, 2020 at 12:26:29AM -0700, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit:7b4ea945 Revert "x86/mm/64: Do not sync vmalloc/ioremap > > > ma.. > > > git tree: > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing > > > console output: https://syzkaller.appspot.com/x/log.txt?x=11a7813a90 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=72a84c46d0c668c > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=ceef16277388d6f24898 > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > commit: > > > Reported-by: syzbot+ceef16277388d6f24...@syzkaller.appspotmail.com > > > > > > == > > > BUG: KASAN: use-after-free in string_nocheck lib/vsprintf.c:611 [inline] > > > BUG: KASAN: use-after-free in string+0x39c/0x3d0 lib/vsprintf.c:693 > > > Read of size 1 at addr 8881ca21cd20 by task systemd-udevd/5147 > > > > > > CPU: 1 PID: 5147 Comm: systemd-udevd Not tainted 5.8.0-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > > Google 01/01/2011 > > > Call Trace: > > > __dump_stack lib/dump_stack.c:77 [inline] > > > dump_stack+0xf6/0x16e lib/dump_stack.c:118 > > > print_address_description.constprop.0+0x1a/0x210 mm/kasan/report.c:383 > > > __kasan_report mm/kasan/report.c:513 [inline] > > > kasan_report.cold+0x37/0x7c mm/kasan/report.c:530 > > > string_nocheck lib/vsprintf.c:611 [inline] > > > string+0x39c/0x3d0 lib/vsprintf.c:693 > > > vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2617 > > > add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:664 > > > rc_dev_uevent+0x54/0x140 drivers/media/rc/rc-main.c:1616 > > > dev_uevent+0x30e/0x780 drivers/base/core.c:1916 > > > uevent_show+0x1bb/0x360 drivers/base/core.c:1963 > > > dev_attr_show+0x4b/0x90 drivers/base/core.c:1667 > > > sysfs_kf_seq_show+0x1f8/0x400 fs/sysfs/file.c:60 > > > seq_read+0x432/0x1070 fs/seq_file.c:208 > > > kernfs_fop_read+0xe9/0x590 fs/kernfs/file.c:251 > > > vfs_read+0x1df/0x520 fs/read_write.c:479 > > > ksys_read+0x12d/0x250 fs/read_write.c:607 > > > do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > RIP: 0033:0x7f6e6c02f910 > > > Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f > > > 1f 44 00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 > > > ff ff 73 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24 > > > RSP: 002b:7fff3cddeae8 EFLAGS: 0246 ORIG_RAX: > > > RAX: ffda RBX: 558492caaae0 RCX: 7f6e6c02f910 > > > RDX: 1000 RSI: 558492cc7530 RDI: 0007 > > > RBP: 7f6e6c2ea440 R08: 7f6e6c2ee298 R09: 1010 > > > R10: 558492caaae0 R11: 0246 R12: 1000 > > > R13: 0d68 R14: 558492cc7530 R15: 7f6e6c2e9900 > > > > This thread is reading the uevent sysfs file, which reads > > rc_dev->map.name, and also rc_dev->device_name, but that is not causing > > problems is this case. > > > > > > > > Allocated by task 5: > > > save_stack+0x1b/0x40 mm/kasan/common.c:48 > > > set_track mm/kasan/common.c:56 [inline] > > > __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 > > > slab_post_alloc_hook mm/slab.h:586 [inline] > > > slab_alloc_node mm/slub.c:2824 [inline] > > > slab_alloc mm/slub.c:2832 [inline] > > > __kmalloc_track_caller+0xec/0x280 mm/slub.c:4430 > > > kstrdup+0x36/0x70 mm/util.c:60 > > > ir_create_table drivers/media/rc/rc-main.c:217 [inline] > > > ir_setkeytable drivers/media/rc/rc-main.c:477 [inline] > > > rc_prepare_rx_device drivers/media/rc/rc-main.c:1786 [inline] > > > rc_register_device+0x464/0x1600 drivers/media/rc/rc-main.c:1914 > > > igorplugusb_probe+0x7e6/0xc98 drivers/media/rc/igorplugusb.c:209 > > > usb_probe_interface+0x315/0x7f0 drivers/us
Re: KASAN: use-after-free Read in rc_dev_uevent
On Fri, Aug 07, 2020 at 12:26:29AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:7b4ea945 Revert "x86/mm/64: Do not sync vmalloc/ioremap ma.. > git tree: > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing > console output: https://syzkaller.appspot.com/x/log.txt?x=11a7813a90 > kernel config: https://syzkaller.appspot.com/x/.config?x=72a84c46d0c668c > dashboard link: https://syzkaller.appspot.com/bug?extid=ceef16277388d6f24898 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+ceef16277388d6f24...@syzkaller.appspotmail.com > > == > BUG: KASAN: use-after-free in string_nocheck lib/vsprintf.c:611 [inline] > BUG: KASAN: use-after-free in string+0x39c/0x3d0 lib/vsprintf.c:693 > Read of size 1 at addr 8881ca21cd20 by task systemd-udevd/5147 > > CPU: 1 PID: 5147 Comm: systemd-udevd Not tainted 5.8.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0xf6/0x16e lib/dump_stack.c:118 > print_address_description.constprop.0+0x1a/0x210 mm/kasan/report.c:383 > __kasan_report mm/kasan/report.c:513 [inline] > kasan_report.cold+0x37/0x7c mm/kasan/report.c:530 > string_nocheck lib/vsprintf.c:611 [inline] > string+0x39c/0x3d0 lib/vsprintf.c:693 > vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2617 > add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:664 > rc_dev_uevent+0x54/0x140 drivers/media/rc/rc-main.c:1616 > dev_uevent+0x30e/0x780 drivers/base/core.c:1916 > uevent_show+0x1bb/0x360 drivers/base/core.c:1963 > dev_attr_show+0x4b/0x90 drivers/base/core.c:1667 > sysfs_kf_seq_show+0x1f8/0x400 fs/sysfs/file.c:60 > seq_read+0x432/0x1070 fs/seq_file.c:208 > kernfs_fop_read+0xe9/0x590 fs/kernfs/file.c:251 > vfs_read+0x1df/0x520 fs/read_write.c:479 > ksys_read+0x12d/0x250 fs/read_write.c:607 > do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x7f6e6c02f910 > Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f 1f 44 > 00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 > 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24 > RSP: 002b:7fff3cddeae8 EFLAGS: 0246 ORIG_RAX: > RAX: ffda RBX: 558492caaae0 RCX: 7f6e6c02f910 > RDX: 1000 RSI: 558492cc7530 RDI: 0007 > RBP: 7f6e6c2ea440 R08: 7f6e6c2ee298 R09: 1010 > R10: 558492caaae0 R11: 0246 R12: 1000 > R13: 0d68 R14: 558492cc7530 R15: 7f6e6c2e9900 This thread is reading the uevent sysfs file, which reads rc_dev->map.name, and also rc_dev->device_name, but that is not causing problems is this case. > > Allocated by task 5: > save_stack+0x1b/0x40 mm/kasan/common.c:48 > set_track mm/kasan/common.c:56 [inline] > __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 > slab_post_alloc_hook mm/slab.h:586 [inline] > slab_alloc_node mm/slub.c:2824 [inline] > slab_alloc mm/slub.c:2832 [inline] > __kmalloc_track_caller+0xec/0x280 mm/slub.c:4430 > kstrdup+0x36/0x70 mm/util.c:60 > ir_create_table drivers/media/rc/rc-main.c:217 [inline] > ir_setkeytable drivers/media/rc/rc-main.c:477 [inline] > rc_prepare_rx_device drivers/media/rc/rc-main.c:1786 [inline] > rc_register_device+0x464/0x1600 drivers/media/rc/rc-main.c:1914 > igorplugusb_probe+0x7e6/0xc98 drivers/media/rc/igorplugusb.c:209 > usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:374 > really_probe+0x291/0xde0 drivers/base/dd.c:553 > driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:738 > __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:844 > bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431 > __device_attach+0x228/0x4a0 drivers/base/dd.c:912 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491 > device_add+0xb51/0x1c70 drivers/base/core.c:2930 > usb_set_configuration+0xf05/0x18a0 drivers/usb/core/message.c:2032 > usb_generic_driver_probe+0xba/0xf2 drivers/usb/core/generic.c:239 > usb_probe_device+0xd9/0x250 drivers/usb/core/driver.c:272 > really_probe+0x291/0xde0 drivers/base/dd.c:553 > driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:738 > __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:844 > bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431 > __device_attach+0x228/0x4a0 drivers/base/dd.c:912 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491 > device_add+0xb51/0x1c70 drivers/base/core.c:2930 > usb_new_device.cold+0x71d/0xfd4 drivers/usb/core/hub.c:2554 > hub_port_connect drivers/usb/core/hub.c:5208 [inline] > hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] > port_event
Re: [PATCH stable 4.9 00/21] Unbreak 32-bit DVB applications on 64-bit kernels
On Tue, Jun 23, 2020 at 09:13:34PM +0200, Greg KH wrote: > On Fri, Jun 05, 2020 at 09:24:57AM -0700, Florian Fainelli wrote: > > Hi all, > > > > This long patch series was motivated by backporting Jaedon's changes > > which add a proper ioctl compatibility layer for 32-bit applications > > running on 64-bit kernels. We have a number of Android TV-based products > > currently running on the 4.9 kernel and this was broken for them. > > > > Thanks to Robert McConnell for identifying and providing the patches in > > their initial format. > > > > In order for Jaedon's patches to apply cleanly a number of changes were > > applied to support those changes. If you deem the patch series too big > > please let me know. > > Now queued up,t hanks. Sorry about the delay getting this reviewed. I've spent the morning going through them and it looks good. Of the all the dvb ioctl, only the FE_SET_PROPERTY and FE_GET_PROPERTY ioctls need special handling and this series fixes that. Belated, Reviewed-by: Sean Young Sean
Re: [PATCH v2] media: budget-core: Improve exception handling in budget_register()
On Sat, Jun 06, 2020 at 12:17:28AM +0800, Chuhong Yuan wrote:
> budget_register() has no error handling after its failure.
> Add the missed undo functions for error handling to fix it.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Changes look good, but the Fixes: points to the first import of linux
into git. I'm not sure this is useful information so I've removed it.
Applied, thanks.
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v2:
> - Modify the label of error handler.
>
> drivers/media/pci/ttpci/budget-core.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/pci/ttpci/budget-core.c
> b/drivers/media/pci/ttpci/budget-core.c
> index fadbdeeb4495..293867b9e796 100644
> --- a/drivers/media/pci/ttpci/budget-core.c
> +++ b/drivers/media/pci/ttpci/budget-core.c
> @@ -369,20 +369,25 @@ static int budget_register(struct budget *budget)
> ret = dvbdemux->dmx.add_frontend(>dmx, >hw_frontend);
>
> if (ret < 0)
> - return ret;
> + goto err_release_dmx;
>
> budget->mem_frontend.source = DMX_MEMORY_FE;
> ret = dvbdemux->dmx.add_frontend(>dmx, >mem_frontend);
> if (ret < 0)
> - return ret;
> + goto err_release_dmx;
>
> ret = dvbdemux->dmx.connect_frontend(>dmx,
> >hw_frontend);
> if (ret < 0)
> - return ret;
> + goto err_release_dmx;
>
> dvb_net_init(>dvb_adapter, >dvb_net, >dmx);
>
> return 0;
> +
> +err_release_dmx:
> + dvb_dmxdev_release(>dmxdev);
> + dvb_dmx_release(>demux);
> + return ret;
> }
>
> static void budget_unregister(struct budget *budget)
> --
> 2.26.2
Re: [PATCH AUTOSEL 5.7 066/274] media: dvbdev: Fix tuner->demod media controller link
da RBX: 55a9237f63f0 RCX: > 7f3cd24dc839 > [ 253.138451] RDX: RSI: 55a922c3ad2e RDI: > > [ 253.138451] RBP: 55a922c3ad2e R08: R09: > > [ 253.138452] R10: R11: 0246 R12: > > [ 253.138453] R13: 55a9237f5550 R14: 0004 R15: > 55a9237f63f0 > [ 253.138456] ---[ end trace a60f19c54aa96ec4 ]--- > > [ 234.915628] [ cut here ] > [ 234.915640] WARNING: CPU: 0 PID: 1502 at drivers/media/mc/mc-entity.c:669 > media_create_pad_link+0x1e0/0x200 [mc] > [ 234.915641] Modules linked in: si2157 lgdt3306a cx231xx_dvb(+) dvb_core > cx231xx_alsa cx25840 cx231xx tveeprom cx2341x i2c_mux videobuf2_vmalloc > videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ir_rc5_decoder > rc_hauppauge mceusb rc_core edac_mce_amd kvm nls_iso8859 > _1 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd > cryptd glue_helper efi_pstore wmi_bmof k10temp asix usbnet mii nouveau > snd_hda_codec_realtek snd_hda_codec_generic input_leds ledtrig_audio > snd_hda_codec_hdmi mxm_wmi snd_hda_intel video snd_intel_dspcf > g ttm snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_seq_midi > snd_seq_midi_event i2c_algo_bit snd_pcm snd_rawmidi fb_sys_fops snd_seq > syscopyarea sysfillrect snd_seq_device sysimgblt snd_timer snd soundcore ccp > mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tab > les x_tables autofs4 vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio > hid_generic usbhid hid i2c_piix4 ahci libahci wmi gpio_amdpt gpio_generic > [ 234.915700] CPU: 0 PID: 1502 Comm: modprobe Not tainted 5.7.0-rc2+ #181 > [ 234.915702] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS > 2.G0 04/27/2018 > [ 234.915709] RIP: 0010:media_create_pad_link+0x1e0/0x200 [mc] > [ 234.915712] Code: 26 fd ff ff 44 8b 4d d0 eb d9 0f 0b 41 b9 ea ff ff ff 44 > 89 c8 c3 0f 0b 41 b9 ea ff ff ff eb f2 0f 0b 41 b9 ea ff ff ff eb e8 <0f> 0b > 41 b9 ea ff ff ff eb af 0f 0b 41 b9 ea ff ff ff eb a5 66 90 > [ 234.915714] RSP: 0018:b9ecc1b6fa50 EFLAGS: 00010246 > [ 234.915717] RAX: 943f8c94a9d8 RBX: RCX: > > [ 234.915719] RDX: 943f613e0900 RSI: RDI: > 943f8c94a958 > [ 234.915721] RBP: b9ecc1b6fa88 R08: 0001 R09: > 943f613e0900 > [ 234.915723] R10: 943f613e0900 R11: 943f6b590c00 R12: > > [ 234.915724] R13: 0001 R14: 943f8c94a958 R15: > 0001 > [ 234.915727] FS: 7f4ca3646540() GS:943f8ec0() > knlGS: > [ 234.915729] CS: 0010 DS: ES: CR0: 80050033 > [ 234.915731] CR2: 7fff7a53ba18 CR3: 0003da614000 CR4: > 003406f0 > [ 234.915733] Call Trace: > [ 234.915745] media_create_pad_links+0x104/0x1b0 [mc] > [ 234.915756] dvb_create_media_graph+0x350/0x5f0 [dvb_core] > [ 234.915766] dvb_init.part.4+0x691/0x1360 [cx231xx_dvb] > [ 234.915780] dvb_init+0x1a/0x20 [cx231xx_dvb] > [ 234.915787] cx231xx_register_extension+0x71/0xa0 [cx231xx] > [ 234.915791] ? 0xc042f000 > [ 234.915796] cx231xx_dvb_register+0x15/0x1000 [cx231xx_dvb] > [ 234.915802] do_one_initcall+0x71/0x250 > [ 234.915807] ? do_init_module+0x27/0x22e > [ 234.915811] ? _cond_resched+0x1a/0x50 > [ 234.915816] ? kmem_cache_alloc_trace+0x1ec/0x270 > [ 234.915820] ? __vunmap+0x1e3/0x240 > [ 234.915826] do_init_module+0x5f/0x22e > [ 234.915831] load_module+0x2525/0x2d40 > [ 234.915848] __do_sys_finit_module+0xe5/0x120 > [ 234.915850] ? __do_sys_finit_module+0xe5/0x120 > [ 234.915862] __x64_sys_finit_module+0x1a/0x20 > [ 234.915865] do_syscall_64+0x57/0x1b0 > [ 234.915870] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 234.915872] RIP: 0033:0x7f4ca3168839 > [ 234.915876] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 > f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 > [ 234.915878] RSP: 002b:7ffcea3db3b8 EFLAGS: 0246 ORIG_RAX: > 0139 > [ 234.915881] RAX: ffda RBX: 000055af22c29340 RCX: > 7f4ca3168839 > [ 234.915882] RDX: RSI: 55af22c38390 RDI: > 0001 > [ 234.915884] RBP: 55af22c38390 R08: R09: > > [ 234.915885] R10: 0001 R11: 0246 R12: > > [ 234.915887] R13: 55af22c29060 R14: 0004 R15: > > [ 234.915896] ---[ end trace a60f19c54aa96ec
Re: [PATCH 2/3] input: serio: allow more than one byte to be sent at once
On Tue, May 12, 2020 at 10:37:27AM -0700, Dmitry Torokhov wrote: > On Tue, May 12, 2020 at 10:07:24AM +0100, Sean Young wrote: > > Now it would be nice to have a discussion about this rather than being > > dismissed with: > > > > > > > Ummm, serial protocol data size is at most 9 bits so I have no earthly > > > > > idea how they expect to get 16. > > > > Which is just a tad insulting. > > That was not meant to be insulting, however serial protocol defines that > the data size is at most 9 bits, so expecting that one can transmit > anything more than that _atomically_ is wrong. If your device/firmware > requires 16 bits to be transferred as indivisible units, then serial > port abstraction is wrong one to be used. Honestly thank you for explaining that. I had no idea this was an abstract point about the demarcations of serial port-ness. There is no physical rs-232 cabling involved at all in this case. > Now serio is layer "above" serial ports (but does not have to have > an underlying serial port) that provides byte-oriented communication > that is expected to mostly flow into host. Its does not expect heavy > data flows coming from the host and into the device (if you look at all > the touchscreens, psmouse, etc, they all send initialization sequences > to the device, and then all the data flows into the host). Therefore > there is little benefit in optimizing serio writes. True, I didn't think this would make much of an measurable improvement, but still, some. > You are using performance clams as a clutch for the requirement of > sending u16s, but as I mentioned it is wrong if you use serial ports > abstraction layer. Greg mentioned ir-usb. You can maybe enhance it, or > create a similar driver that connects USB to rc-core and ensures that > you can communicate with the device with exact format it needs. Yes, I'll go down this route. Thank you for the discussion, it was very helpful. Sean
Re: [PATCH 2/3] input: serio: allow more than one byte to be sent at once
On Wed, May 13, 2020 at 10:16:46AM +0200, Greg KH wrote: > On Tue, May 12, 2020 at 10:07:24AM +0100, Sean Young wrote: > > So this device is the infrared kind which rc-core (in drivers/media/rc/) > > supports, remotes and such things (not for serial IR). So by using a > > rc-core driver, it can use kernel IR decoding, BPF decoding, lirc chardev > > and rc keymaps, etc. > > So why do you want to user serio for this? serio should only be for > input devices with a serial protocol. Admittedly this is a bit tenuous. What I'm trying to do is write a kernel driver which uses the usb serial drivers, and not write a poor man's version of usb serial in the IR driver. > I think a custom usb driver that exposes the interfaces as input devices > is going to be the simplest thing for you to do here as you will have > full control over the packet size and format much easier. Odds are it > will be less work overall for this. Admittedly I don't think it will be much code, so maybe it won't be so ugly. It's just the code duplication I was trying to avoid. So, I'll go ahead and as you suggest. Thank you for your time and thoughts on this. Sean
Re: [PATCH 2/3] input: serio: allow more than one byte to be sent at once
On Mon, May 11, 2020 at 08:51:18AM +0200, Greg KH wrote:
> On Thu, May 07, 2020 at 09:59:18PM +0100, Sean Young wrote:
> > On Thu, May 07, 2020 at 01:25:46PM -0700, Dmitry Torokhov wrote:
> > > On Thu, May 07, 2020 at 02:53:36PM +0100, Sean Young wrote:
> > > > serio drivers can only send one byte at a time. If the underlying tty
> > > > is a usb serial port, then each byte will be put into separate usb
> > > > urbs, which is not efficient.
> > > >
> > > > Additionally, the Infrared Toy device refuses to transmit IR if the
> > > > IR data is sent one byte at a time. IR data is formatted in u16 values,
> > > > and the firmware expects complete u16 values in the packet.
> > > >
> > > > https://github.com/DangerousPrototypes/USB_IR_Toy/blob/master/Firmware-main/IRs.c#L240
> > >
> > > Ummm, serial protocol data size is at most 9 bits so I have no earthly
> > > idea how they expect to get 16.
> >
> > serio is a layer on top several serial protocols, including ttys. ttys allow
> > more than one byte to be written at a time, see struct tty_operations:
> >
> > int (*write)(struct tty_struct * tty,
> > const unsigned char *buf, int count);
> >
> > ttys would be very inefficient if you could only write one byte at a time,
> > and they are very serial.
> >
> > This patch exposes the underlying tty write() functionality to serio. When
> > the underlying tty is a usb serial port this makes for far fewer usb packets
> > being used to send the same data, and fixes my driver problem, and it
> > would reduce the number of calls in a few other cases too.
> >
> > I'm happy to rework the patch if there are comments on the style or
> > approach.
>
> Why not just use the ir-usb.c driver for this device instead?
So this device is the infrared kind which rc-core (in drivers/media/rc/)
supports, remotes and such things (not for serial IR). So by using a
rc-core driver, it can use kernel IR decoding, BPF decoding, lirc chardev
and rc keymaps, etc.
This device is a PIC18F2550 type device, which is a usb serial port
microcontroller type with some firmware and IR diodes:
http://dangerousprototypes.com/docs/USB_IR_Toy_v2
serio supports a whole bunch of usb serial devices which can be attached
via inputattach(1). Not all of these are input devices, for example there
are two cec devices too.
Now, in many of these drivers, multiple bytes need to be written to the
device in order to send it a command, for example in
drivers/input/touchscreen/elo.c:
for (i = 0; i < ELO10_PACKET_LEN; i++) {
csum += packet[i];
if (serio_write(elo->serio, packet[i]))
goto out;
}
So if serio had an interface for sending a buffer, that would be less
call overhead. In fact, if the underlying serio is a serial usb port,
that would much more efficient on the usb layer too (one usb roundtrips in
stead of ELO10_PACKET_LEN roundtrips), like so:
serio_write_buf(elo->serio, packet, ELO10_PACKET_LEN);
So what I'm suggesting is extending the serio interface to allow sending
a buffer of bytes. Of course serio isn't just usb serial ports. There quite
a few instances of serio_register_port() in the kernel. Many of them
can be extended to support sending a buffer rather than a single byte,
if this makes sense. For example the ps2 serio port takes a mutex for every
byte, so this could be more efficient by reducing it to one mutex lock
per buffer.
Now it would be nice to have a discussion about this rather than being
dismissed with:
> > > Ummm, serial protocol data size is at most 9 bits so I have no earthly
> > > idea how they expect to get 16.
Which is just a tad insulting.
Sean
Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle_irq() when DMA failures/attacks occur
On Tue, May 05, 2020 at 10:21:10PM +0800, Jia-Ju Bai wrote:
> In ttusb_dec_init_usb():
> dec->irq_buffer = usb_alloc_coherent(...)
>
> Thus, "dec->irq_buffer" is a DMA value, and it is assigned to "buffer"
> in ttusb_dec_handle_irq():
> char *buffer = dec->irq_buffer;
>
> When DMA failures or attacks occur, the value of buffer[4] can be
> changed at any time. In this case, "buffer[4] - 1 < ARRAY_SIZE(rc_keys)"
> can be first satisfied, and then the value of buffer[4] can be changed
> to a large number, causing a buffer-overflow vulnerability.
>
> To avoid the risk of this vulnerability, buffer[4] is assigned to a
> non-DMA local variable "index" at the beginning of
> ttusb_dec_handle_irq(), and then this variable replaces each use of
> buffer[4] in the function.
This change is the urb completion handler. As I understand it, dma is
done by the usb host controller, in this case in response to an interrupt
request urb from the usb device side.
In the completion handler, once we are done reading the data in the buffer,
the urb is submitted again. Only then can the interrupt request urb be resent
by the device, so there is no possibility of the dma buffer being
overwritten.
Now I might be mistaken of course. I can see that firewire and pci devices
do suffer from the problems describe in the paper, but not usb.
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/media/usb/ttusb-dec/ttusb_dec.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/usb/ttusb-dec/ttusb_dec.c
> b/drivers/media/usb/ttusb-dec/ttusb_dec.c
> index 3198f9624b7c..8543c552515b 100644
> --- a/drivers/media/usb/ttusb-dec/ttusb_dec.c
> +++ b/drivers/media/usb/ttusb-dec/ttusb_dec.c
> @@ -250,6 +250,7 @@ static void ttusb_dec_handle_irq( struct urb *urb)
> struct ttusb_dec *dec = urb->context;
> char *buffer = dec->irq_buffer;
> int retval;
> + u8 index = buffer[4];
>
> switch(urb->status) {
> case 0: /*success*/
> @@ -281,11 +282,11 @@ static void ttusb_dec_handle_irq( struct urb *urb)
>* this should/could be added later ...
>* for now lets report each signal as a key down and up
>*/
> - if (buffer[4] - 1 < ARRAY_SIZE(rc_keys)) {
Here buffer[4] is signed char, so if buffer[4] == 0 then (buffer[4] - 1) = -1,
this becomes "if (-1 < ARRAY_SIZE(rc_keys))", which evaluates to false,
due to it becoming an unsigned compare. _I think_.
Not the most readable code at all.
> - dprintk("%s:rc signal:%d\n", __func__, buffer[4]);
> - input_report_key(dec->rc_input_dev, rc_keys[buffer[4] -
> 1], 1);
> + if (index - 1 < ARRAY_SIZE(rc_keys)) {
> + dprintk("%s:rc signal:%d\n", __func__, index);
> + input_report_key(dec->rc_input_dev, rc_keys[index - 1],
> 1);
> input_sync(dec->rc_input_dev);
> - input_report_key(dec->rc_input_dev, rc_keys[buffer[4] -
> 1], 0);
> + input_report_key(dec->rc_input_dev, rc_keys[index - 1],
> 0);
Like Greg said, this patch reduces the number of dereferences and makes
the code much cleaner, but the commit message is misleading.
> input_sync(dec->rc_input_dev);
> }
> }
> --
> 2.17.1
Thanks,
Sean
Re: [PATCH] media: cxusb: fix uninitialized local variable
Hi Valentin,
Thank you for your patch.
On Tue, Oct 15, 2019 at 10:03:15PM +0200, Valentin Vidic wrote:
> Make sure ircode does not contain random values if the call to
> cxusb_ctrl_msg fails for some reason.
>
> Reported-by: syzbot+98730b985cad4931a...@syzkaller.appspotmail.com
> Signed-off-by: Valentin Vidic
> ---
> drivers/media/usb/dvb-usb/cxusb.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb/cxusb.c
> b/drivers/media/usb/dvb-usb/cxusb.c
> index f02fa0a67aa4..afcd88dd96c0 100644
> --- a/drivers/media/usb/dvb-usb/cxusb.c
> +++ b/drivers/media/usb/dvb-usb/cxusb.c
> @@ -519,7 +519,7 @@ static int cxusb_d680_dmb_streaming_ctrl(struct
> dvb_usb_adapter *adap,
>
> static int cxusb_rc_query(struct dvb_usb_device *d)
> {
> - u8 ircode[4];
> + u8 ircode[4] = { 0 };
>
> cxusb_ctrl_msg(d, CMD_GET_IR_CODE, NULL, 0, ircode, 4);
The correct to do here is check the return value of cxusb_ctrl_msg() and
to not proceed if it failed, rather than assume the value of 0.
Also note that:
https://patchwork.linuxtv.org/patch/59448/
Is already being merged.
Thanks
Sean
>
> @@ -531,7 +531,7 @@ static int cxusb_rc_query(struct dvb_usb_device *d)
>
> static int cxusb_bluebird2_rc_query(struct dvb_usb_device *d)
> {
> - u8 ircode[4];
> + u8 ircode[4] = { 0 };
> struct i2c_msg msg = {
> .addr = 0x6b,
> .flags = I2C_M_RD,
> @@ -550,7 +550,7 @@ static int cxusb_bluebird2_rc_query(struct dvb_usb_device
> *d)
>
> static int cxusb_d680_dmb_rc_query(struct dvb_usb_device *d)
> {
> - u8 ircode[2];
> + u8 ircode[2] = { 0 };
>
> if (cxusb_ctrl_msg(d, 0x10, NULL, 0, ircode, 2) < 0)
> return 0;
> @@ -989,7 +989,7 @@ static int cxusb_dee1601_frontend_attach(struct
> dvb_usb_adapter *adap)
>
> static int cxusb_dualdig4_frontend_attach(struct dvb_usb_adapter *adap)
> {
> - u8 ircode[4];
> + u8 ircode[4] = { 0 };
> int i;
> struct i2c_msg msg = {
> .addr = 0x6b,
> --
> 2.20.1
Re: [PATCH] si2157: Add support for Logilink VG0022A.
On Wed, Oct 02, 2019 at 04:44:24PM +0200, Gonsolo wrote: > Hi! > > > You need a message and a Signed-off-by: here. > > Ok, I'll try to get that right the next time. > > > > + ret = si2157_power_up(dev, client); > > > + if (ret) > > > + goto err; > > > + /* query chip revision */ > > > + /* hack: do it here because after the si2168 gets 0101, commands > > > will > > > + * still be executed here but no result > > > > I don't understand. What problem are you seeing here? Why can't you do a > > query chip revision first? > > This was explained here: https://lkml.org/lkml/2017/3/15/778. To quote: Antti has some great suggestions in that thread: https://lkml.org/lkml/2017/5/24/245 Also note https://lkml.org/lkml/2017/5/26/357 if you have access to a logic analyser. Sean
Re: [PATCH] si2157: Add support for Logilink VG0022A.
On Wed, Oct 02, 2019 at 04:13:59PM +0200, Gon Solo wrote:
You need a message and a Signed-off-by: here.
> ---
> drivers/media/tuners/si2157.c | 68 +--
> drivers/media/tuners/si2157_priv.h| 1 +
> drivers/media/usb/dvb-usb-v2/af9035.c | 47 ++
> 3 files changed, 90 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
> index e87040d6eca7..8f9df2485d51 100644
> --- a/drivers/media/tuners/si2157.c
> +++ b/drivers/media/tuners/si2157.c
> @@ -66,6 +66,24 @@ static int si2157_cmd_execute(struct i2c_client *client,
> struct si2157_cmd *cmd)
> return ret;
> }
>
> +static int si2157_power_up(struct si2157_dev *dev, struct i2c_client *client)
> +{
> + struct si2157_cmd cmd;
> +
> + if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
> + memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
> + cmd.wlen = 9;
> + } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
> + memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03",
> 10);
> + cmd.wlen = 10;
> + } else {
> + memcpy(cmd.args,
> "\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
> + cmd.wlen = 15;
> + }
> + cmd.rlen = 1;
> + return si2157_cmd_execute(client, );
> +}
> +
> static int si2157_init(struct dvb_frontend *fe)
> {
> struct i2c_client *client = fe->tuner_priv;
> @@ -75,7 +93,7 @@ static int si2157_init(struct dvb_frontend *fe)
> struct si2157_cmd cmd;
> const struct firmware *fw;
> const char *fw_name;
> - unsigned int uitmp, chip_id;
> + unsigned int uitmp;
>
> dev_dbg(>dev, "\n");
>
> @@ -93,19 +111,7 @@ static int si2157_init(struct dvb_frontend *fe)
> if (uitmp == dev->if_frequency / 1000)
> goto warm;
>
> - /* power up */
> - if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
> - memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
> - cmd.wlen = 9;
> - } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
> - memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03",
> 10);
> - cmd.wlen = 10;
> - } else {
> - memcpy(cmd.args,
> "\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
> - cmd.wlen = 15;
> - }
> - cmd.rlen = 1;
> - ret = si2157_cmd_execute(client, );
> + ret = si2157_power_up(dev, client);
> if (ret)
> goto err;
>
> @@ -118,17 +124,6 @@ static int si2157_init(struct dvb_frontend *fe)
> goto err;
> }
>
> - /* query chip revision */
> - memcpy(cmd.args, "\x02", 1);
> - cmd.wlen = 1;
> - cmd.rlen = 13;
> - ret = si2157_cmd_execute(client, );
> - if (ret)
> - goto err;
> -
> - chip_id = cmd.args[1] << 24 | cmd.args[2] << 16 | cmd.args[3] << 8 |
> - cmd.args[4] << 0;
> -
> #define SI2177_A30 ('A' << 24 | 77 << 16 | '3' << 8 | '0' << 0)
> #define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
> #define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
> @@ -137,7 +132,7 @@ static int si2157_init(struct dvb_frontend *fe)
> #define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
> #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
>
> - switch (chip_id) {
> + switch (dev->chip_id) {
> case SI2158_A20:
> case SI2148_A20:
> fw_name = SI2158_A20_FIRMWARE;
> @@ -456,6 +451,27 @@ static int si2157_probe(struct i2c_client *client,
> memcpy(>ops.tuner_ops, _ops, sizeof(struct dvb_tuner_ops));
> fe->tuner_priv = client;
>
> + ret = si2157_power_up(dev, client);
> + if (ret)
> + goto err;
> + /* query chip revision */
> + /* hack: do it here because after the si2168 gets 0101, commands will
> + * still be executed here but no result
I don't understand. What problem are you seeing here? Why can't you do a
query chip revision first?
This needs resolving of course.
> + */
> + memcpy(cmd.args, "\x02", 1);
> + cmd.wlen = 1;
> + cmd.rlen = 13;
> + ret = si2157_cmd_execute(client, );
> + if (ret)
> + goto err_kfree;
> + dev->chip_id = cmd.args[1] << 24 |
> + cmd.args[2] << 16 |
> + cmd.args[3] << 8 |
> + cmd.args[4] << 0;
> + dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
> + cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
> +
> +
> #ifdef CONFIG_MEDIA_CONTROLLER
> if (cfg->mdev) {
> dev->mdev = cfg->mdev;
> diff --git a/drivers/media/tuners/si2157_priv.h
> b/drivers/media/tuners/si2157_priv.h
> index 2bda903358da..9ab7c88b01b4 100644
> --- a/drivers/media/tuners/si2157_priv.h
> +++ b/drivers/media/tuners/si2157_priv.h
> @@ -28,6 +28,7
Re: [PATCH 1/4] media: dvb-frontends: Use DIV_ROUND_CLOSEST directly to make it readable
Hi,
On Fri, Sep 06, 2019 at 12:14:49AM +0800, zhong jiang wrote:
> The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
> but is perhaps more readable.
>
> Signed-off-by: zhong jiang
> ---
> drivers/media/dvb-frontends/mt312.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/mt312.c
> b/drivers/media/dvb-frontends/mt312.c
> index 7cae7d6..251ff41 100644
> --- a/drivers/media/dvb-frontends/mt312.c
> +++ b/drivers/media/dvb-frontends/mt312.c
> @@ -137,7 +137,7 @@ static inline int mt312_writereg(struct mt312_state
> *state,
>
> static inline u32 mt312_div(u32 a, u32 b)
> {
> - return (a + (b / 2)) / b;
> + return DIV_ROUND_CLOSEST(a, b);
Well spotted, that is absolutely correct. However now mt312_div() is just
a wrapper for DIV_ROUND_CLOSEST() -- and even marked inline. Really all
the callers to mt312_div() should be replaced with DIV_ROUND_CLOSEST().
Thanks,
Sean
Re: [PATCH v4] media: si2168: Refactor command setup code
On Mon, Aug 19, 2019 at 01:54:53PM +0200, Marc Gonzalez wrote: > On 15/07/2019 11:50, Marc Gonzalez wrote: > > > Use cmd_init() to fill a struct si2168_cmd command. > > > > Signed-off-by: Marc Gonzalez > > --- > > Changes from v1: > > - Use a real function to populate struct si2168_cmd *cmd, and a trivial > > macro wrapping it (macro because sizeof). > > Changes from v2: > > - Fix header mess > > - Add Jonathan's tag > > Changes from v3: > > - Drop Jonathan's tag after rewrite > > - Completely drop macro, and explicitly provide 'wlen' argument > > --- > > drivers/media/dvb-frontends/si2168.c | 152 --- > > 1 file changed, 44 insertions(+), 108 deletions(-) > > Brad, Sean, Antti, > > I believe this patch is good to go. Is anything still wrong with it? It's been accepted: https://git.linuxtv.org/media_tree.git/commit/?id=619f6fc390909fce3247c3e07e6882b868b645da Thanks, Sean
Re: [PATCH] Fix an OOB access bug in technisat_usb2_get_ir
On Tue, Aug 20, 2019 at 02:19:16PM -0400, Hui Peng wrote:
> In the while loop of technisat_usb2_get_ir, it scans through
> a fix-sized buffer read from the device side, the termination
> condition of the loop is `*b == 0xff`. If no `0xff` byte is read
> from the device side, OOB access happens.
>
> This patch fixes the bug by adding an upper bound in the while loop.
This issue was fixed in:
https://git.linuxtv.org/media_tree.git/commit/drivers/media/usb/dvb-usb/technisat-usb2.c?id=0c4df39e504bf925ab666132ac3c98d6cbbe380b
Note this limits the loop to the size of the buffer; using the ret
return value might be better.
Sean
>
> Reported-by: Hui Peng
> Reported-by: Mathias Payer
> Signed-off-by: Hui Peng
> ---
> drivers/media/usb/dvb-usb/technisat-usb2.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c
> b/drivers/media/usb/dvb-usb/technisat-usb2.c
> index c659e18b358b..181f5f97af45 100644
> --- a/drivers/media/usb/dvb-usb/technisat-usb2.c
> +++ b/drivers/media/usb/dvb-usb/technisat-usb2.c
> @@ -612,6 +612,7 @@ static int technisat_usb2_get_ir(struct dvb_usb_device *d)
> u8 *b;
> int ret;
> struct ir_raw_event ev;
> + int i = 0;
>
> buf[0] = GET_IR_DATA_VENDOR_REQUEST;
> buf[1] = 0x08;
> @@ -656,11 +657,15 @@ static int technisat_usb2_get_ir(struct dvb_usb_device
> *d)
>
> ev.pulse = 0;
> while (1) {
> + // only `ret` bytes are read from the device side
> + if (i >= ret)
> + break;
> ev.pulse = !ev.pulse;
> ev.duration = (*b * FIRMWARE_CLOCK_DIVISOR *
> FIRMWARE_CLOCK_TICK) / 1000;
> ir_raw_event_store(d->rc_dev, );
>
> b++;
> + i++;
> if (*b == 0xff) {
> ev.pulse = 0;
> ev.duration = 88*2;
> --
> 2.23.0
Re: [PATCH v2 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
On Tue, Aug 20, 2019 at 10:52:29AM -0500, Rob Herring wrote: > On Tue, Aug 20, 2019 at 4:50 AM Maxime Ripard wrote: > > On Tue, Aug 20, 2019 at 09:15:26AM +0100, Sean Young wrote: > > > On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote: > > > > From: Maxime Ripard > > > > > > > > The RC controllers have a bunch of generic properties that are needed > > > > in a > > > > device tree. Add a YAML schemas for those. > > > > > > > > Reviewed-by: Rob Herring > > > > Signed-off-by: Maxime Ripard > > > > > > For the series (both 1/2 and 2.2): > > > > > > Reviewed-by: Sean Young > > > > > > How's tree should this go through? > > > > Either yours or Rob's, I guess? > > Sean's because there are other changes to > Documentation/devicetree/bindings/media/sunxi-ir.txt in -next. Good point, I'll take them. Thanks Sean
Re: [PATCH v2 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote: > From: Maxime Ripard > > The RC controllers have a bunch of generic properties that are needed in a > device tree. Add a YAML schemas for those. > > Reviewed-by: Rob Herring > Signed-off-by: Maxime Ripard For the series (both 1/2 and 2.2): Reviewed-by: Sean Young How's tree should this go through? Thanks Sean > > --- > > Changes from v1: > - Update the list of valid RC map name > --- > .../devicetree/bindings/media/rc.txt | 118 +- > .../devicetree/bindings/media/rc.yaml | 145 ++ > 2 files changed, 146 insertions(+), 117 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/rc.yaml > > diff --git a/Documentation/devicetree/bindings/media/rc.txt > b/Documentation/devicetree/bindings/media/rc.txt > index d3e7a012bfda..be629f7fa77e 100644 > --- a/Documentation/devicetree/bindings/media/rc.txt > +++ b/Documentation/devicetree/bindings/media/rc.txt > @@ -1,117 +1 @@ > -The following properties are common to the infrared remote controllers: > - > -- linux,rc-map-name: string, specifies the scancode/key mapping table > - defined in-kernel for the remote controller. Support values are: > - * "rc-adstech-dvb-t-pci" > - * "rc-alink-dtu-m" > - * "rc-anysee" > - * "rc-apac-viewcomp" > - * "rc-asus-pc39" > - * "rc-asus-ps3-100" > - * "rc-ati-tv-wonder-hd-600" > - * "rc-ati-x10" > - * "rc-avermedia-a16d" > - * "rc-avermedia-cardbus" > - * "rc-avermedia-dvbt" > - * "rc-avermedia-m135a" > - * "rc-avermedia-m733a-rm-k6" > - * "rc-avermedia-rm-ks" > - * "rc-avermedia" > - * "rc-avertv-303" > - * "rc-azurewave-ad-tu700" > - * "rc-behold-columbus" > - * "rc-behold" > - * "rc-budget-ci-old" > - * "rc-cec" > - * "rc-cinergy-1400" > - * "rc-cinergy" > - * "rc-delock-61959" > - * "rc-dib0700-nec" > - * "rc-dib0700-rc5" > - * "rc-digitalnow-tinytwin" > - * "rc-digittrade" > - * "rc-dm1105-nec" > - * "rc-dntv-live-dvbt-pro" > - * "rc-dntv-live-dvb-t" > - * "rc-dtt200u" > - * "rc-dvbsky" > - * "rc-empty" > - * "rc-em-terratec" > - * "rc-encore-enltv2" > - * "rc-encore-enltv-fm53" > - * "rc-encore-enltv" > - * "rc-evga-indtube" > - * "rc-eztv" > - * "rc-flydvb" > - * "rc-flyvideo" > - * "rc-fusionhdtv-mce" > - * "rc-gadmei-rm008z" > - * "rc-geekbox" > - * "rc-genius-tvgo-a11mce" > - * "rc-gotview7135" > - * "rc-hauppauge" > - * "rc-imon-mce" > - * "rc-imon-pad" > - * "rc-iodata-bctv7e" > - * "rc-it913x-v1" > - * "rc-it913x-v2" > - * "rc-kaiomy" > - * "rc-kworld-315u" > - * "rc-kworld-pc150u" > - * "rc-kworld-plus-tv-analog" > - * "rc-leadtek-y04g0051" > - * "rc-lirc" > - * "rc-lme2510" > - * "rc-manli" > - * "rc-medion-x10" > - * "rc-medion-x10-digitainer" > - * "rc-medion-x10-or2x" > - * "rc-msi-digivox-ii" > - * "rc-msi-digivox-iii" > - * "rc-msi-tvanywhere-plus" > - * "rc-msi-tvanywhere" > - * "rc-nebula" > - * "rc-nec-terratec-cinergy-xs" > - * "rc-norwood" > - * "rc-npgtech" > - * "rc-pctv-sedna" > - * "rc-pinnacle-color" > - * "rc-pinnacle-grey" > - * "rc-pinnacle-pctv-hd" > - * "rc-pixelview-new" > - * "rc-pixelview" > - * "rc-pixelview-002t" > - * "rc-pixelview-mk12" > - * "rc-powercolor-real-angel" > - * "rc-proteus-2309" > - * "rc-purpletv" > - * "rc-pv951" > - * "rc-hauppauge" > - * "rc-rc5-tv" > - * "rc-rc6-mce" > - * "rc-real-audio-220-32-keys" > - * "rc-reddo" > - * "rc-snapstream-firefly" > - * "rc-streamzap" > - * "rc-tbs-nec" > - * "rc-technisat-ts35" > - * "rc-technisat-usb2" > - * "rc-terratec-cinergy-c-pci" > - * "rc-terratec-cinergy-s2-hd" > - * "rc-
Re: [PATCH v3] media: dvb: Provide 4 devm variants
On Mon, Jul 22, 2019 at 10:13:56AM +0200, Marc Gonzalez wrote:
> On 21/07/2019 17:02, Ezequiel Garcia wrote:
>
> > On Thu, 2019-07-18 at 15:03 +0200, Marc Gonzalez wrote:
> >
> >> Provide devm variants for automatic resource release on device removal.
> >> Makes error-handling in probe() simpler, thus less error-prone.
> >> Once all resources are devmanaged, remove() is no longer needed.
> >
> > I think it would be better to add this API as part of a series
> > that also uses it.
>
> I have an outstanding RFC for a new driver:
>
> https://patchwork.kernel.org/patch/11040435/
>
> Locally, I've updated the probe function to use the proposed devm functions.
>
> I was mainly hoping to get initial feedback from the maintainers.
> 1) See if they're OK with devm APIs
devm_ has some lifetime issues, wrt to disconnect. However, for a platform
device it is fine.
> 2) See if they're OK with the way I implemented devm APIs
Looks good to me.
> 3) See what's missing to get an Ack
Please submit both this patch and a the driver as a series.
Thanks,
Sean
>
> static int tsif_probe(struct platform_device *pdev)
> {
> int err, virq;
> struct tsif *tsif;
> struct resource *res;
> struct dvb_frontend *fe;
> struct dvb_adapter *adap;
> struct device *dev = >dev;
> short num = DVB_UNSET;
>
> fe = dvb_get_demod_fe(dev->of_node);
> if (!fe)
> return -ENXIO;
>
> tsif = devm_kzalloc(dev, sizeof(*tsif), GFP_KERNEL);
> if (!tsif)
> return -ENOMEM;
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "tsif0");
> tsif->base = devm_ioremap_resource(dev, res);
> if (IS_ERR(tsif->base))
> return PTR_ERR(tsif->base);
>
> virq = platform_get_irq_byname(pdev, "tsif0");
> err = devm_request_irq(dev, virq, tsif_isr, IRQF_SHARED, "tsif", tsif);
> if (err)
> return err;
>
> tsif->clk = devm_clk_get(dev, "iface");
> if (IS_ERR(tsif->clk))
> return PTR_ERR(tsif->clk);
>
> err = devm_clk_prepare_enable(dev, tsif->clk);
> if (err)
> return err;
>
> adap = >adapter;
> err = devm_dvb_register_adapter(dev, adap, "tsif", THIS_MODULE, );
> if (err) return err;
>
> /* Not sure the diff between filter and feed? */
> tsif->demux.filternum = 16; /*** Dunno what to put here ***/
> tsif->demux.feednum = 16; /*** Dunno what to put here ***/
> tsif->demux.start_feed = noop;
> tsif->demux.stop_feed = noop;
> err = devm_dvb_dmx_init(dev, >demux);
> if (err) return err;
>
> /* What relation to dvb_demux.filternum??? */
> /* Do I need this object?? */
> tsif->dmxdev.filternum = 16;
> tsif->dmxdev.demux = >demux.dmx;
> err = devm_dvb_dmxdev_init(dev, >dmxdev, adap);
> if (err) return err;
>
> err = devm_dvb_register_frontend(dev, adap, fe);
> if (err) return err;
>
> writel_relaxed(TSIF_START + ENABLE_IRQ, tsif->base + TSIF_STS_CTL);
> devm_add_action(dev, stop_tsif, tsif);
> INIT_WORK(>work, handle_pkt);
>
> return 0;
> }
Re: [PATCH 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
On Tue, Aug 13, 2019 at 02:45:12PM +0200, Maxime Ripard wrote: > From: Maxime Ripard > > The RC controllers have a bunch of generic properties that are needed in a > device tree. Add a YAML schemas for those. > > Signed-off-by: Maxime Ripard > --- > .../devicetree/bindings/media/rc.txt | 118 +-- > .../devicetree/bindings/media/rc.yaml | 135 ++ > 2 files changed, 136 insertions(+), 117 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/rc.yaml > > diff --git a/Documentation/devicetree/bindings/media/rc.txt > b/Documentation/devicetree/bindings/media/rc.txt > index d3e7a012bfda..be629f7fa77e 100644 > --- a/Documentation/devicetree/bindings/media/rc.txt > +++ b/Documentation/devicetree/bindings/media/rc.txt > @@ -1,117 +1 @@ > -The following properties are common to the infrared remote controllers: > - > -- linux,rc-map-name: string, specifies the scancode/key mapping table > - defined in-kernel for the remote controller. Support values are: > - * "rc-adstech-dvb-t-pci" > - * "rc-alink-dtu-m" > - * "rc-anysee" > - * "rc-apac-viewcomp" > - * "rc-asus-pc39" > - * "rc-asus-ps3-100" > - * "rc-ati-tv-wonder-hd-600" > - * "rc-ati-x10" > - * "rc-avermedia-a16d" > - * "rc-avermedia-cardbus" > - * "rc-avermedia-dvbt" > - * "rc-avermedia-m135a" > - * "rc-avermedia-m733a-rm-k6" > - * "rc-avermedia-rm-ks" > - * "rc-avermedia" > - * "rc-avertv-303" > - * "rc-azurewave-ad-tu700" > - * "rc-behold-columbus" > - * "rc-behold" > - * "rc-budget-ci-old" > - * "rc-cec" > - * "rc-cinergy-1400" > - * "rc-cinergy" > - * "rc-delock-61959" > - * "rc-dib0700-nec" > - * "rc-dib0700-rc5" > - * "rc-digitalnow-tinytwin" > - * "rc-digittrade" > - * "rc-dm1105-nec" > - * "rc-dntv-live-dvbt-pro" > - * "rc-dntv-live-dvb-t" > - * "rc-dtt200u" > - * "rc-dvbsky" > - * "rc-empty" > - * "rc-em-terratec" > - * "rc-encore-enltv2" > - * "rc-encore-enltv-fm53" > - * "rc-encore-enltv" > - * "rc-evga-indtube" > - * "rc-eztv" > - * "rc-flydvb" > - * "rc-flyvideo" > - * "rc-fusionhdtv-mce" > - * "rc-gadmei-rm008z" > - * "rc-geekbox" > - * "rc-genius-tvgo-a11mce" > - * "rc-gotview7135" > - * "rc-hauppauge" > - * "rc-imon-mce" > - * "rc-imon-pad" > - * "rc-iodata-bctv7e" > - * "rc-it913x-v1" > - * "rc-it913x-v2" > - * "rc-kaiomy" > - * "rc-kworld-315u" > - * "rc-kworld-pc150u" > - * "rc-kworld-plus-tv-analog" > - * "rc-leadtek-y04g0051" > - * "rc-lirc" > - * "rc-lme2510" > - * "rc-manli" > - * "rc-medion-x10" > - * "rc-medion-x10-digitainer" > - * "rc-medion-x10-or2x" > - * "rc-msi-digivox-ii" > - * "rc-msi-digivox-iii" > - * "rc-msi-tvanywhere-plus" > - * "rc-msi-tvanywhere" > - * "rc-nebula" > - * "rc-nec-terratec-cinergy-xs" > - * "rc-norwood" > - * "rc-npgtech" > - * "rc-pctv-sedna" > - * "rc-pinnacle-color" > - * "rc-pinnacle-grey" > - * "rc-pinnacle-pctv-hd" > - * "rc-pixelview-new" > - * "rc-pixelview" > - * "rc-pixelview-002t" > - * "rc-pixelview-mk12" > - * "rc-powercolor-real-angel" > - * "rc-proteus-2309" > - * "rc-purpletv" > - * "rc-pv951" > - * "rc-hauppauge" > - * "rc-rc5-tv" > - * "rc-rc6-mce" > - * "rc-real-audio-220-32-keys" > - * "rc-reddo" > - * "rc-snapstream-firefly" > - * "rc-streamzap" > - * "rc-tbs-nec" > - * "rc-technisat-ts35" > - * "rc-technisat-usb2" > - * "rc-terratec-cinergy-c-pci" > - * "rc-terratec-cinergy-s2-hd" > - * "rc-terratec-cinergy-xs" > - * "rc-terratec-slim" > - * "rc-terratec-slim-2" > - * "rc-tevii-nec" > - * "rc-tivo" > - * "rc-total-media-in-hand" > - * "rc-t
Re: [PATCH v2 1/2] media: ir-kbd-i2c: convert to i2c_new_dummy_device()
On Sat, Aug 03, 2019 at 01:17:49PM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 30 Jul 2019 19:55:54 +0200 > Wolfram Sang escreveu: > > > Convert this driver to use the new i2c_new_dummy_device() call and bail > > out if the dummy device cannot be registered to make failure more > > visible to the user. > > > > Please don't do that. > > At first glance, devm_* sounds a good idea, but we had enough issues > using it on media system. > > I don't mind mind much if some SoC specific would use it, but doing > it on generic drivers is a very bad idea. We have removed almost all > devm_* calls from the media system. > > The problem with devm is that it the de-allocation routines aren't > called during device unbind. They happen a way later, only when the > device itself is physically removed, or the driver is removed. Yes, good point. > That caused lots of headaches to debug memory lifetime issues on > media. Indeed this becomes much more complex. Explicit freeing is much better. Thanks, Sean
Re: [PATCH v2] media:dvb-frontends:Remove dvb_pll_devcount and id module parameters.
On Fri, Aug 02, 2019 at 12:20:19PM +0530, Vandana BN wrote: > > On 01/08/19 2:31 PM, Michael Ira Krufky wrote: > > Sean, > > > > Please pardon the late reply. See my responses inline below: > > > > On Wed, Jul 24, 2019 at 1:36 AM Sean Young wrote: > >> On Sat, Jul 20, 2019 at 11:43:02AM +0530, Vandana BN wrote: > >>> Syzbot reported global-out-of-bounds Read in dvb_pll_attach, while > >>> accessing id[dvb_pll_devcount], because dvb_pll_devcount was 65, > >>> that is more than size of 'id' which is DVB_PLL_MAX(64). > >>> > >>> Fix would be to check if DVB_PLL_MAX devices are attached and if so return > >>> NULL from dvb_pll_attach(). But this will put a limit on the number of > >>> devices that can be attached. > >>> Also dvb_pll_devcount and "id" module parameter are used for debugging > >>> purpose to override/force PLL type. > >>> So this patch removes these module parameters. > >>> > >>> Reported-by: syz...@syzkaller.appspotmail.com > >>> > >>> usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the > >>> software demuxer > >>> dvbdev: DVB: registering new adapter (774 Friio White ISDB-T USB2.0) > >>> usb 1-1: media controller created > >>> dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. > >>> tc90522 0-0018: Toshiba TC90522 attached. > >>> usb 1-1: DVB: registering adapter 0 frontend 0 (Toshiba TC90522 ISDB-T > >>> module)... > >>> dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-T > >>> module' registered. > >>> == > >>> BUG: KASAN: global-out-of-bounds in dvb_pll_attach+0x6c5/0x830 > >>> drivers/media/dvb-frontends/dvb-pll.c:798 > >>> Read of size 4 at addr 89c9e5e0 by task kworker/0:1/12 > >>> > >>> CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #13 > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > >>> Google 01/01/2011 > >>> Workqueue: usb_hub_wq hub_event > >>> Call Trace: > >>> __dump_stack lib/dump_stack.c:77 [inline] > >>> dump_stack+0xca/0x13e lib/dump_stack.c:113 > >>> print_address_description+0x67/0x231 mm/kasan/report.c:188 > >>> __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 > >>> kasan_report+0xe/0x20 mm/kasan/common.c:614 > >>> dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 > >>> dvb_pll_probe+0xfe/0x174 drivers/media/dvb-frontends/dvb-pll.c:877 > >>> i2c_device_probe+0x790/0xaa0 drivers/i2c/i2c-core-base.c:389 > >>> really_probe+0x281/0x660 drivers/base/dd.c:509 > >>> driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > >>> __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > >>> bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > >>> __device_attach+0x217/0x360 drivers/base/dd.c:843 > >>> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > >>> device_add+0xae6/0x16f0 drivers/base/core.c:2111 > >>> i2c_new_client_device+0x5b3/0xc40 drivers/i2c/i2c-core-base.c:778 > >>> i2c_new_device+0x19/0x50 drivers/i2c/i2c-core-base.c:821 > >>> dvb_module_probe+0xf9/0x220 drivers/media/dvb-core/dvbdev.c:985 > >>> friio_tuner_attach+0x125/0x1d0 drivers/media/usb/dvb-usb-v2/gl861.c:536 > >>> dvb_usbv2_adapter_frontend_init > >>> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:675 [inline] > >>> dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:804 > >>> [inline] > >>> dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:865 [inline] > >>> dvb_usbv2_probe.cold+0x24dc/0x255d > >>> drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:980 > >>> usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 > >>> really_probe+0x281/0x660 drivers/base/dd.c:509 > >>> driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > >>> __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > >>> bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > >>> __device_attach+0x217/0x360 drivers/base/dd.c:843 > >>> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > >>> device_add+0xae6/0x16f0 drivers/base/core.c:2111 > >>> usb_set_configuration+0xdf6/0x1670 drivers/usb/core/messa
Re: [PATCH v2] media:dvb-frontends:Remove dvb_pll_devcount and id module parameters.
On Wed, Jul 24, 2019 at 06:36:35AM +0100, Sean Young wrote: > On Sat, Jul 20, 2019 at 11:43:02AM +0530, Vandana BN wrote: > > Syzbot reported global-out-of-bounds Read in dvb_pll_attach, while > > accessing id[dvb_pll_devcount], because dvb_pll_devcount was 65, > > that is more than size of 'id' which is DVB_PLL_MAX(64). > > > > Fix would be to check if DVB_PLL_MAX devices are attached and if so return > > NULL from dvb_pll_attach(). But this will put a limit on the number of > > devices that can be attached. > > Also dvb_pll_devcount and "id" module parameter are used for debugging > > purpose to override/force PLL type. > > So this patch removes these module parameters. > > > > Reported-by: syz...@syzkaller.appspotmail.com > > > > usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the > > software demuxer > > dvbdev: DVB: registering new adapter (774 Friio White ISDB-T USB2.0) > > usb 1-1: media controller created > > dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. > > tc90522 0-0018: Toshiba TC90522 attached. > > usb 1-1: DVB: registering adapter 0 frontend 0 (Toshiba TC90522 ISDB-T > > module)... > > dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-T > > module' registered. > > == > > BUG: KASAN: global-out-of-bounds in dvb_pll_attach+0x6c5/0x830 > > drivers/media/dvb-frontends/dvb-pll.c:798 > > Read of size 4 at addr 89c9e5e0 by task kworker/0:1/12 > > > > CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #13 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Workqueue: usb_hub_wq hub_event > > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0xca/0x13e lib/dump_stack.c:113 > > print_address_description+0x67/0x231 mm/kasan/report.c:188 > > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 > > kasan_report+0xe/0x20 mm/kasan/common.c:614 > > dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 > > dvb_pll_probe+0xfe/0x174 drivers/media/dvb-frontends/dvb-pll.c:877 > > i2c_device_probe+0x790/0xaa0 drivers/i2c/i2c-core-base.c:389 > > really_probe+0x281/0x660 drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > > __device_attach+0x217/0x360 drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > > i2c_new_client_device+0x5b3/0xc40 drivers/i2c/i2c-core-base.c:778 > > i2c_new_device+0x19/0x50 drivers/i2c/i2c-core-base.c:821 > > dvb_module_probe+0xf9/0x220 drivers/media/dvb-core/dvbdev.c:985 > > friio_tuner_attach+0x125/0x1d0 drivers/media/usb/dvb-usb-v2/gl861.c:536 > > dvb_usbv2_adapter_frontend_init > > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:675 [inline] > > dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:804 > > [inline] > > dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:865 [inline] > > dvb_usbv2_probe.cold+0x24dc/0x255d > > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:980 > > usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 > > really_probe+0x281/0x660 drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > > __device_attach+0x217/0x360 drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > > usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 > > generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 > > usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 > > really_probe+0x281/0x660 drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > > __device_attach+0x217/0x360 drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > > usb_new_device.cold+0x8c1/0x1016 drivers/usb/core/hub.c:2534 > > hub_port_connect drivers/usb/core/hub.c:5089 [inline] > > hub_port_connect_change drivers/usb/co
Re: [PATCH 1/2] media: ir-kbd-i2c: prevent potential NULL pointer access
Hi Wolfram, On Thu, Jul 25, 2019 at 09:55:38AM +0200, Wolfram Sang wrote: > Hi Sean, > > thanks for the review! > > On Thu, Jul 25, 2019 at 06:12:02AM +0100, Sean Young wrote: > > On Mon, Jul 22, 2019 at 07:26:31PM +0200, Wolfram Sang wrote: > > > i2c_new_dummy() can fail returning a NULL pointer. The code does not > > > bail out in this case and the returned pointer is blindly used. > > > > I don't see how. The existing code tries to set up the tx part; if > > i2c_new_dummy() return NULL then the rcdev is registered without tx, > > and tx_c is never used. > > Yes, you are totally right. I missed that the send_block function is > also only called iff zilog_init succeeded. Thanks for the heads up and > sorry for the noise. Not at all, thank you for the patch. > > > Convert > > > to devm_i2c_new_dummy_device() which returns an ERR_PTR and also bail > > > out when failing the validity check. > > > > Possibly I was being overly cautious with not bailing out if tx can't > > be registered; moving to devm is probably a good idea. However the > > commit message is misleading, because the existing code has no > > NULL pointer access. > > Yep, I will resend with a proper commit message. Technically, there is > no need to bail out anymore because there is no NULL pointer access. My > tendency is now to not bail out and keep the old behaviour (registering > without tx). What do you think? Since I write this code I've got pretty much every model with this zilog transmitter/receiver, and they all work fine, including different firmware versions. If there is a problem it would be nice to hear about it, and not silently swallow the error. I think. Thanks, Sean
Re: [PATCH 1/2] media: ir-kbd-i2c: prevent potential NULL pointer access
On Mon, Jul 22, 2019 at 07:26:31PM +0200, Wolfram Sang wrote:
> i2c_new_dummy() can fail returning a NULL pointer. The code does not
> bail out in this case and the returned pointer is blindly used.
I don't see how. The existing code tries to set up the tx part; if
i2c_new_dummy() return NULL then the rcdev is registered without tx,
and tx_c is never used.
> Convert
> to devm_i2c_new_dummy_device() which returns an ERR_PTR and also bail
> out when failing the validity check.
Possibly I was being overly cautious with not bailing out if tx can't
be registered; moving to devm is probably a good idea. However the
commit message is misleading, because the existing code has no
NULL pointer access.
Sean
>
> Signed-off-by: Wolfram Sang
> ---
> drivers/media/i2c/ir-kbd-i2c.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
> index 876d7587a1da..f46717052efc 100644
> --- a/drivers/media/i2c/ir-kbd-i2c.c
> +++ b/drivers/media/i2c/ir-kbd-i2c.c
> @@ -885,9 +885,12 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> INIT_DELAYED_WORK(>work, ir_work);
>
> if (probe_tx) {
> - ir->tx_c = i2c_new_dummy(client->adapter, 0x70);
> - if (!ir->tx_c) {
> + ir->tx_c = devm_i2c_new_dummy_device(>dev,
> + client->adapter, 0x70);
> + if (IS_ERR(ir->tx_c)) {
> dev_err(>dev, "failed to setup tx i2c address");
> + err = PTR_ERR(ir->tx_c);
> + goto err_out_free;
> } else if (!zilog_init(ir)) {
> ir->carrier = 38000;
> ir->duty_cycle = 40;
> @@ -904,9 +907,6 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> return 0;
>
> err_out_free:
> - if (ir->tx_c)
> - i2c_unregister_device(ir->tx_c);
> -
> /* Only frees rc if it were allocated internally */
> rc_free_device(rc);
> return err;
> @@ -919,9 +919,6 @@ static int ir_remove(struct i2c_client *client)
> /* kill outstanding polls */
> cancel_delayed_work_sync(>work);
>
> - if (ir->tx_c)
> - i2c_unregister_device(ir->tx_c);
> -
> /* unregister device */
> rc_unregister_device(ir->rc);
>
> --
> 2.20.1
Re: [PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition
On Tue, Jul 23, 2019 at 09:04:40AM +0200, Maxime Ripard wrote: > Hi Sean, > > On Tue, Jul 23, 2019 at 07:25:57AM +0100, Sean Young wrote: > > On Mon, Jul 15, 2019 at 01:12:45PM +0100, Sean Young wrote: > > > On Sun, Jul 14, 2019 at 04:32:22PM +0200, Clément Péron wrote: > > > > Hi Sean, > > > > > > > > You acked the whole v3 series but this patch has been introduced in v5 > > > > could you ack this one too? > > > > > > Acked-by: Sean Young > > > > So who's tree should this series go through? It seems mostly device tree. > > Alternatively I'm happy to try it get merged via the media tree. > > Ideally the media bits should go through the media tree, the DT bits > will go through arm-soc > > So you can apply the patches 1-4, 7 and 10, I'll apply the rest. > > Does that work for you? Works for me, I'll add them to my next pull request to Mauro. Thanks, Sean
Re: [PATCH v2] media:dvb-frontends:Remove dvb_pll_devcount and id module parameters.
On Sat, Jul 20, 2019 at 11:43:02AM +0530, Vandana BN wrote: > Syzbot reported global-out-of-bounds Read in dvb_pll_attach, while > accessing id[dvb_pll_devcount], because dvb_pll_devcount was 65, > that is more than size of 'id' which is DVB_PLL_MAX(64). > > Fix would be to check if DVB_PLL_MAX devices are attached and if so return > NULL from dvb_pll_attach(). But this will put a limit on the number of > devices that can be attached. > Also dvb_pll_devcount and "id" module parameter are used for debugging > purpose to override/force PLL type. > So this patch removes these module parameters. > > Reported-by: syz...@syzkaller.appspotmail.com > > usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the > software demuxer > dvbdev: DVB: registering new adapter (774 Friio White ISDB-T USB2.0) > usb 1-1: media controller created > dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. > tc90522 0-0018: Toshiba TC90522 attached. > usb 1-1: DVB: registering adapter 0 frontend 0 (Toshiba TC90522 ISDB-T > module)... > dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-T > module' registered. > == > BUG: KASAN: global-out-of-bounds in dvb_pll_attach+0x6c5/0x830 > drivers/media/dvb-frontends/dvb-pll.c:798 > Read of size 4 at addr 89c9e5e0 by task kworker/0:1/12 > > CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #13 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: usb_hub_wq hub_event > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0xca/0x13e lib/dump_stack.c:113 > print_address_description+0x67/0x231 mm/kasan/report.c:188 > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 > kasan_report+0xe/0x20 mm/kasan/common.c:614 > dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 > dvb_pll_probe+0xfe/0x174 drivers/media/dvb-frontends/dvb-pll.c:877 > i2c_device_probe+0x790/0xaa0 drivers/i2c/i2c-core-base.c:389 > really_probe+0x281/0x660 drivers/base/dd.c:509 > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > __device_attach+0x217/0x360 drivers/base/dd.c:843 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > i2c_new_client_device+0x5b3/0xc40 drivers/i2c/i2c-core-base.c:778 > i2c_new_device+0x19/0x50 drivers/i2c/i2c-core-base.c:821 > dvb_module_probe+0xf9/0x220 drivers/media/dvb-core/dvbdev.c:985 > friio_tuner_attach+0x125/0x1d0 drivers/media/usb/dvb-usb-v2/gl861.c:536 > dvb_usbv2_adapter_frontend_init > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:675 [inline] > dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:804 > [inline] > dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:865 [inline] > dvb_usbv2_probe.cold+0x24dc/0x255d > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:980 > usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 > really_probe+0x281/0x660 drivers/base/dd.c:509 > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > __device_attach+0x217/0x360 drivers/base/dd.c:843 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 > generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 > usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 > really_probe+0x281/0x660 drivers/base/dd.c:509 > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > __device_attach+0x217/0x360 drivers/base/dd.c:843 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > usb_new_device.cold+0x8c1/0x1016 drivers/usb/core/hub.c:2534 > hub_port_connect drivers/usb/core/hub.c:5089 [inline] > hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] > port_event drivers/usb/core/hub.c:5350 [inline] > hub_event+0x1ada/0x3590 drivers/usb/core/hub.c:5432 > process_one_work+0x905/0x1570 kernel/workqueue.c:2269 > process_scheduled_works kernel/workqueue.c:2331 [inline] > worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 > kthread+0x30b/0x410 kernel/kthread.c:255 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 > > The buggy address belongs to the variable: > id+0x100/0x120 > > Memory state around the buggy address: > 89c9e480: fa fa fa fa 00 00 fa fa fa fa fa fa 00 00 00 00 > 89c9e500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 89c9e580: 00 00 00 00 00 00 00 00 00 00 00 00
Re: [PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition
Hi, On Mon, Jul 15, 2019 at 01:12:45PM +0100, Sean Young wrote: > On Sun, Jul 14, 2019 at 04:32:22PM +0200, Clément Péron wrote: > > Hi Sean, > > > > You acked the whole v3 series but this patch has been introduced in v5 > > could you ack this one too? > > Acked-by: Sean Young So who's tree should this series go through? It seems mostly device tree. Alternatively I'm happy to try it get merged via the media tree. Thanks Sean
Re: [PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition
On Sun, Jul 14, 2019 at 04:32:22PM +0200, Clément Péron wrote: > Hi Sean, > > You acked the whole v3 series but this patch has been introduced in v5 > could you ack this one too? Acked-by: Sean Young Thanks Sean > > Thanks, > Clément > > > > > On Mon, 10 Jun 2019 at 11:52, Maxime Ripard wrote: > > > > On Sat, Jun 08, 2019 at 01:10:51AM +0200, Clément Péron wrote: > > > We are using RXINT bits definition when looking at RXSTA register. > > > > > > These bits are equal but it's not really proper. > > > > > > Introduce the RXSTA bits and use them to have coherency. > > > > > > Signed-off-by: Clément Péron > > > > Acked-by: Maxime Ripard > > > > Maxime > > > > -- > > Maxime Ripard, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com
Re: [PATCH] media: cxd2880: Add missing newline at end of file
On Mon, Jun 17, 2019 at 04:38:01PM +0200, Geert Uytterhoeven wrote: > "git diff" says: > > \ No newline at end of file > > after modifying the file. git diff says this because after patching using the diff output, files should be byte-for-byte identifical. It does not mean there necessarily is a problem. I'm not sure this worth fixing or whether it solves an actual problem; the Kconfig is parsed correctly. Sean > > Signed-off-by: Geert Uytterhoeven > --- > drivers/media/dvb-frontends/cxd2880/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/dvb-frontends/cxd2880/Kconfig > b/drivers/media/dvb-frontends/cxd2880/Kconfig > index 9d989676e8007264..94a8e0b936b951dd 100644 > --- a/drivers/media/dvb-frontends/cxd2880/Kconfig > +++ b/drivers/media/dvb-frontends/cxd2880/Kconfig > @@ -5,4 +5,4 @@ config DVB_CXD2880 > depends on DVB_CORE && SPI > default m if !MEDIA_SUBDRV_AUTOSELECT > help > - Say Y when you want to support this frontend. > \ No newline at end of file > + Say Y when you want to support this frontend. > -- > 2.17.1
[PATCH] media: technisat-usb2: break out of loop at end of buffer
Ensure we do not access the buffer beyond the end if no 0xff byte
is encountered.
Reported-by: syzbot+eaaaf38a95427be88...@syzkaller.appspotmail.com
Signed-off-by: Sean Young
---
drivers/media/usb/dvb-usb/technisat-usb2.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c
b/drivers/media/usb/dvb-usb/technisat-usb2.c
index c659e18b358b..676d233d46d5 100644
--- a/drivers/media/usb/dvb-usb/technisat-usb2.c
+++ b/drivers/media/usb/dvb-usb/technisat-usb2.c
@@ -608,10 +608,9 @@ static int technisat_usb2_frontend_attach(struct
dvb_usb_adapter *a)
static int technisat_usb2_get_ir(struct dvb_usb_device *d)
{
struct technisat_usb2_state *state = d->priv;
- u8 *buf = state->buf;
- u8 *b;
- int ret;
struct ir_raw_event ev;
+ u8 *buf = state->buf;
+ int i, ret;
buf[0] = GET_IR_DATA_VENDOR_REQUEST;
buf[1] = 0x08;
@@ -647,26 +646,25 @@ static int technisat_usb2_get_ir(struct dvb_usb_device *d)
return 0; /* no key pressed */
/* decoding */
- b = buf+1;
#if 0
deb_rc("RC: %d ", ret);
- debug_dump(b, ret, deb_rc);
+ debug_dump(buf + 1, ret, deb_rc);
#endif
ev.pulse = 0;
- while (1) {
- ev.pulse = !ev.pulse;
- ev.duration = (*b * FIRMWARE_CLOCK_DIVISOR *
FIRMWARE_CLOCK_TICK) / 1000;
- ir_raw_event_store(d->rc_dev, );
-
- b++;
- if (*b == 0xff) {
+ for (i = 1; i < ARRAY_SIZE(state->buf); i++) {
+ if (buf[i] == 0xff) {
ev.pulse = 0;
ev.duration = 88*2;
ir_raw_event_store(d->rc_dev, );
break;
}
+
+ ev.pulse = !ev.pulse;
+ ev.duration = (buf[i] * FIRMWARE_CLOCK_DIVISOR *
+ FIRMWARE_CLOCK_TICK) / 1000;
+ ir_raw_event_store(d->rc_dev, );
}
ir_raw_event_handle(d->rc_dev);
--
2.21.0
Re: [PATCH] media: dvbsky: use a single mutex and state buffers for all R/W ops
On Sat, Jun 15, 2019 at 10:47:28AM +0300, Andrei Koshkosh wrote:
> ---
> drivers/media/usb/dvb-usb-v2/dvbsky.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
Missing signed-off-by. Please read:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
> b/drivers/media/usb/dvb-usb-v2/dvbsky.c
> index c41e10b..0b5da891 100644
> --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
> +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
> @@ -22,7 +22,7 @@ MODULE_PARM_DESC(disable_rc, "Disable inbuilt IR
> receiver.");
> DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
> struct dvbsky_state {
> - struct mutex stream_mutex;
> + //struct mutex stream_mutex;
Please remove rather comment out.
> u8 ibuf[DVBSKY_BUF_LEN];
> u8 obuf[DVBSKY_BUF_LEN];
> u8 last_lock;
> @@ -61,16 +61,18 @@ static int dvbsky_stream_ctrl(struct dvb_usb_device *d,
> u8 onoff)
> {
> struct dvbsky_state *state = d_to_priv(d);
> int ret;
> - u8 obuf_pre[3] = { 0x37, 0, 0 };
> - u8 obuf_post[3] = { 0x36, 3, 0 };
> + static u8 obuf_pre[3] = { 0x37, 0, 0 };
> + static u8 obuf_post[3] = { 0x36, 3, 0 };
Can these be const?
>
> - mutex_lock(>stream_mutex);
> - ret = dvbsky_usb_generic_rw(d, obuf_pre, 3, NULL, 0);
> + mutex_lock(>usb_mutex);
> + memcpy(state->obuf, obuf_pre, 3);
> + ret = dvb_usbv2_generic_write_locked(d, state->obuf, 3);
> if (!ret && onoff) {
> msleep(20);
> - ret = dvbsky_usb_generic_rw(d, obuf_post, 3, NULL, 0);
> + memcpy(state->obuf, obuf_post, 3);
> + ret = dvb_usbv2_generic_write_locked(d, state->obuf, 3);
> }
> - mutex_unlock(>stream_mutex);
> + mutex_unlock(>usb_mutex);
> return ret;
> }
>
> @@ -599,7 +601,7 @@ static int dvbsky_init(struct dvb_usb_device *d)
> if (ret)
> return ret;
> */
> - mutex_init(>stream_mutex);
> + //mutex_init(>stream_mutex);
Remove.
>
> state->last_lock = 0;
>
> --
> 2.7.4
Thanks,
Sean
Re: [PATCH 3/3] media: ttpci: add RC_CORE dependency
On Mon, Jun 17, 2019 at 01:16:53PM +0200, Arnd Bergmann wrote:
> The ttpci driver now uses the rc-core, so we need to ensure it
> is enabled:
>
> ERROR: "rc_unregister_device" [drivers/media/pci/ttpci/dvb-ttpci.ko]
> undefined!
> ERROR: "rc_allocate_device" [drivers/media/pci/ttpci/dvb-ttpci.ko] undefined!
> ERROR: "rc_free_device" [drivers/media/pci/ttpci/dvb-ttpci.ko] undefined!
> ERROR: "rc_keydown" [drivers/media/pci/ttpci/dvb-ttpci.ko] undefined!
> ERROR: "rc_register_device" [drivers/media/pci/ttpci/dvb-ttpci.ko] undefined!
>
> Fixes: 71f49a8bf5c5 ("media: ttpci: use rc-core for the IR receiver")
> Signed-off-by: Arnd Bergmann
Thank you for the patch, unfortunately this was already fixed in
commit 12e23ebb396e6ffea88b8c5e483059a297326afb (which was accepted
after you sent your patch).
Thanks
Sean
Re: [PATCH] media: ttpci: Fix build error without RC_CORE
On Wed, Jun 12, 2019 at 06:37:08AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 12 Jun 2019 08:42:55 +0100
> Sean Young escreveu:
>
> > On Wed, Jun 12, 2019 at 11:43:10AM +0800, YueHaibing wrote:
> > > If RC_CORE is not set, building fails:
> > >
> > > drivers/media/pci/ttpci/av7110_ir.o: In function `av7110_ir_init':
> > > av7110_ir.c:(.text+0x1b0): undefined reference to `rc_allocate_device'
> > > av7110_ir.c:(.text+0x2c1): undefined reference to `rc_register_device'
> > > av7110_ir.c:(.text+0x2dc): undefined reference to `rc_free_device'
> > >
> > > Reported-by: Hulk Robot
> > > Fixes: 71f49a8bf5c5 ("media: ttpci: use rc-core for the IR receiver")
> > > Signed-off-by: YueHaibing
> >
> > Thank you for spotting this and writing a patch.
> >
> > > ---
> > > drivers/media/pci/ttpci/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/pci/ttpci/Kconfig
> > > b/drivers/media/pci/ttpci/Kconfig
> > > index d96d4fa..b705631 100644
> > > --- a/drivers/media/pci/ttpci/Kconfig
> > > +++ b/drivers/media/pci/ttpci/Kconfig
> > > @@ -7,7 +7,7 @@ config DVB_AV7110
> > > depends on DVB_CORE && PCI && I2C
> > > select TTPCI_EEPROM
> > > select VIDEO_SAA7146_VV
> > > - select DVB_AV7110_IR if INPUT_EVDEV=y || INPUT_EVDEV=DVB_AV7110
> >
> > This says if
> > - select DVB_AV7110_IR if INPUT_EVDEV and DVB_AV7110 are both y or m
> > - select DVB_AV7110_IR if INPUT_EVDEV=y
> >This exists for the case when INPUT_EVDEV=y and DVB_AV7110=m, which is
> > fine
> >
> > > + select DVB_AV7110_IR if RC_CORE=DVB_AV7110 && (INPUT_EVDEV=y ||
> > > INPUT_EVDEV=DVB_AV7110)
> >
> > That's not exactly the same. For one thing it should not longer depend on
> > INPUT_EVDEV=y.
> >
> > Now if DVB_AV7110=m and RC_CORE=y is not allowed which should be (this is
> > the case in Fedora default kernel config for example).
>
> My suggestion here is to stop using select here, using, instead
> a depends on for DVB_AV7110_IR, e. g. something like (untested):
>
> config DVB_AV7110_IR
> bool
> depends on RC_CORE && DVB_AV7110
> default DVB_AV7110
Build will fail if RC_CORE=m && DVB_AV7110=y. So it should be
depends on RC_CORE=y || RC_CORE = DVB_AV7110
Thanks,
Sean
Re: [PATCH] media: ttpci: Fix build error without RC_CORE
On Wed, Jun 12, 2019 at 11:43:10AM +0800, YueHaibing wrote:
> If RC_CORE is not set, building fails:
>
> drivers/media/pci/ttpci/av7110_ir.o: In function `av7110_ir_init':
> av7110_ir.c:(.text+0x1b0): undefined reference to `rc_allocate_device'
> av7110_ir.c:(.text+0x2c1): undefined reference to `rc_register_device'
> av7110_ir.c:(.text+0x2dc): undefined reference to `rc_free_device'
>
> Reported-by: Hulk Robot
> Fixes: 71f49a8bf5c5 ("media: ttpci: use rc-core for the IR receiver")
> Signed-off-by: YueHaibing
Thank you for spotting this and writing a patch.
> ---
> drivers/media/pci/ttpci/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/pci/ttpci/Kconfig b/drivers/media/pci/ttpci/Kconfig
> index d96d4fa..b705631 100644
> --- a/drivers/media/pci/ttpci/Kconfig
> +++ b/drivers/media/pci/ttpci/Kconfig
> @@ -7,7 +7,7 @@ config DVB_AV7110
> depends on DVB_CORE && PCI && I2C
> select TTPCI_EEPROM
> select VIDEO_SAA7146_VV
> - select DVB_AV7110_IR if INPUT_EVDEV=y || INPUT_EVDEV=DVB_AV7110
This says if
- select DVB_AV7110_IR if INPUT_EVDEV and DVB_AV7110 are both y or m
- select DVB_AV7110_IR if INPUT_EVDEV=y
This exists for the case when INPUT_EVDEV=y and DVB_AV7110=m, which is fine
> + select DVB_AV7110_IR if RC_CORE=DVB_AV7110 && (INPUT_EVDEV=y ||
> INPUT_EVDEV=DVB_AV7110)
That's not exactly the same. For one thing it should not longer depend on
INPUT_EVDEV=y.
Now if DVB_AV7110=m and RC_CORE=y is not allowed which should be (this is
the case in Fedora default kernel config for example).
> depends on VIDEO_DEV# dependencies of VIDEO_SAA7146_VV
> select DVB_VES1820 if MEDIA_SUBDRV_AUTOSELECT
> select DVB_VES1X93 if MEDIA_SUBDRV_AUTOSELECT
> --
> 2.7.4
>
Thanks,
Sean
Re: [PATCH v3 00/12] Allwinner A64/H6 IR support
On Tue, May 28, 2019 at 06:14:28PM +0200, Clément Péron wrote: > Hi, > > A64 IR support series[1] pointed out that an A31 bindings should be > introduced. > > This series introduce the A31 compatible bindings, then switch it on > the already existing board. > > Finally introduce A64 and H6 support. > > I didn't enable the IR on other H6 boards as Ondrej reported an issue > on his board[2]. For the whole series: Acked-by: Sean Young > > Regards, > Clément > > [1] https://lore.kernel.org/patchwork/patch/1031390/#1221464 > [2] https://lkml.org/lkml/2019/5/27/321 > > Changes since v2: > - Disable IR for other H6 boards > - Split DTS patch for H3/H5 > - Introduce IR quirks > > Changes since v1: > - Document reset lines as required since A31 > - Explain the memory mapping difference in commit log > - Fix misspelling "Allwiner" to "Allwinner" > > Clément Péron (10): > dt-bindings: media: sunxi-ir: add A31 compatible > media: rc: Introduce sunxi_ir_quirks > media: rc: sunxi: Add A31 compatible > ARM: dts: sunxi: Prefer A31 bindings for IR > ARM: dts: sunxi: Prefer A31 bindings for IR > dt-bindings: media: sunxi-ir: Add A64 compatible > dt-bindings: media: sunxi-ir: Add H6 compatible > arm64: dts: allwinner: h6: Add IR receiver node > arm64: dts: allwinner: h6: Enable IR on Beelink GS1 > arm64: defconfig: enable IR SUNXI option > > Igors Makejevs (1): > arm64: dts: allwinner: a64: Add IR node > > Jernej Skrabec (1): > arm64: dts: allwinner: a64: Enable IR on Orange Pi Win > > .../devicetree/bindings/media/sunxi-ir.txt| 11 ++- > arch/arm/boot/dts/sun6i-a31.dtsi | 2 +- > arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +- > arch/arm/boot/dts/sun9i-a80.dtsi | 2 +- > arch/arm/boot/dts/sunxi-h3-h5.dtsi| 2 +- > .../dts/allwinner/sun50i-a64-orangepi-win.dts | 4 ++ > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 18 + > .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ++ > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 19 + > arch/arm64/configs/defconfig | 1 + > drivers/media/rc/sunxi-cir.c | 70 +++ > 11 files changed, 115 insertions(+), 20 deletions(-) > > -- > 2.20.1
Re: [PATCH] drivers/media/dvb-frontends: Implement probe/remove for stv6110x
Hi Tobias,
On Sun, May 12, 2019 at 04:53:06PM +0200, Tobias Klausmann wrote:
> Ping,
>
> comments for this patch are appreciated!
Sorry for not back to you earlier.
Please run script/checkpatch.pl --strict on your patch. There are several
cosmetic changes needed.
>
> Thanks,
>
> Tobias
>
>
> On 09.05.19 21:51, Tobias Klausmann wrote:
> > Refactor out the common parts of stv6110x_probe() and stv6110x_attach() into
> > separate functions.
> >
> > This provides the needed functionality to use dvb_module_probe() instead of
> > dvb_attach()!
The lines shouldn't be longer than 75 characters.
This is a great improvement. It would be nice to see an actual driver use
dvb_module_probe() rather than dvb_attach(), so that the new code paths
are used. Do you have hardware to test this?
> >
> > Signed-off-by: Tobias Klausmann
> > ---
> > drivers/media/dvb-frontends/stv6110x.c | 125
> > drivers/media/dvb-frontends/stv6110x.h | 3 +
> > drivers/media/dvb-frontends/stv6110x_priv.h | 3 +-
> > 3 files changed, 109 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/media/dvb-frontends/stv6110x.c
> > b/drivers/media/dvb-frontends/stv6110x.c
> > index 82c002d3833a..17bc7adf3771 100644
> > --- a/drivers/media/dvb-frontends/stv6110x.c
> > +++ b/drivers/media/dvb-frontends/stv6110x.c
> > @@ -345,6 +345,33 @@ static void stv6110x_release(struct dvb_frontend *fe)
> > kfree(stv6110x);
> > }
> > +void st6110x_init_regs(struct stv6110x_state *stv6110x)
> > +{
> > + u8 default_regs[] = {0x07, 0x11, 0xdc, 0x85, 0x17, 0x01, 0xe6, 0x1e};
> > +
> > + memcpy(stv6110x->regs, default_regs, 8);
> > +}
> > +
> > +void stv6110x_setup_divider(struct stv6110x_state *stv6110x)
> > +{
> > + switch (stv6110x->config->clk_div) {
> > + default:
> > + case 1:
> > + STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV,
> > 0);
> > + break;
> > + case 2:
> > + STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV,
> > 1);
> > + break;
> > + case 4:
> > + STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV,
> > 2);
> > + break;
> > + case 8:
> > + case 0:
> > + STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV,
> > 3);
> > + break;
> > + }
> > +}
> > +
> > static const struct dvb_tuner_ops stv6110x_ops = {
> > .info = {
> > .name = "STV6110(A) Silicon Tuner",
> > @@ -354,7 +381,7 @@ static const struct dvb_tuner_ops stv6110x_ops = {
> > .release= stv6110x_release
> > };
> > -static const struct stv6110x_devctl stv6110x_ctl = {
> > +static struct stv6110x_devctl stv6110x_ctl = {
> > .tuner_init = stv6110x_init,
> > .tuner_sleep= stv6110x_sleep,
> > .tuner_set_mode = stv6110x_set_mode,
> > @@ -368,39 +395,77 @@ static const struct stv6110x_devctl stv6110x_ctl = {
> > .tuner_get_status = stv6110x_get_status,
> > };
> > +void stv6110x_set_frontend_opts(struct stv6110x_state *stv6110x)
> > +{
> > + stv6110x->frontend->tuner_priv = stv6110x;
> > + stv6110x->frontend->ops.tuner_ops = stv6110x_ops;
> > +}
> > +
> > +static struct stv6110x_devctl *stv6110x_get_devctl(struct i2c_client
> > *client)
> > +{
> > + struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
> > +
> > + dev_dbg(>dev, "\n");
> > +
> > + return stv6110x->devctl;
> > +}
> > +
> > +static int stv6110x_probe(struct i2c_client *client,
> > + const struct i2c_device_id *id)
> > +{
> > + struct stv6110x_config *config = client->dev.platform_data;
> > +
> > + struct stv6110x_state *stv6110x;
> > +
> > + stv6110x = kzalloc(sizeof(struct stv6110x_state), GFP_KERNEL);
This should be:
stv6110x = kzalloc(sizeof(*stv6110x), GFP_KERNEL);
> > + if (!stv6110x)
> > + return -ENOMEM;
> > +
> > + stv6110x->frontend = config->frontend;
> > + stv6110x->i2c = client->adapter;
> > + stv6110x->config= config;
> > + stv6110x->devctl= _ctl;
> > +
> > + st6110x_init_regs(stv6110x);
> > + stv6110x_setup_divider(stv6110x);
> > + stv6110x_set_frontend_opts(stv6110x);
> > +
> > + printk(KERN_INFO "%s: Probed STV6110x\n", __func__);
Please use dev_info().
> > +
> > + i2c_set_clientdata(client, stv6110x);
> > +
> > + /* setup callbacks */
> > + config->get_devctl = stv6110x_get_devctl;
> > +
> > + return 0;
> > +}
> > +
> > +static int stv6110x_remove(struct i2c_client *client)
> > +{
> > + struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
> > +
> > + stv6110x_release(stv6110x->frontend);
> > + return 0;
> > +}
> > +
> > const struct stv6110x_devctl *stv6110x_attach(struct dvb_frontend *fe,
> > const struct stv6110x_config *config,
> > struct i2c_adapter *i2c)
> > {
> >
[PATCH] media: au0828: fix null dereference in error path
au0828_usb_disconnect() gets the au0828_dev struct via usb_get_intfdata,
so it needs to set up for the error paths.
Reported-by: syzbot+357d86bcb4cca1a2f...@syzkaller.appspotmail.com
Signed-off-by: Sean Young
---
drivers/media/usb/au0828/au0828-core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index 925a80437822..e306d5d5bebb 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -729,6 +729,12 @@ static int au0828_usb_probe(struct usb_interface
*interface,
/* Setup */
au0828_card_setup(dev);
+ /*
+* Store the pointer to the au0828_dev so it can be accessed in
+* au0828_usb_disconnect
+*/
+ usb_set_intfdata(interface, dev);
+
/* Analog TV */
retval = au0828_analog_register(dev, interface);
if (retval) {
@@ -747,12 +753,6 @@ static int au0828_usb_probe(struct usb_interface
*interface,
/* Remote controller */
au0828_rc_register(dev);
- /*
-* Store the pointer to the au0828_dev so it can be accessed in
-* au0828_usb_disconnect
-*/
- usb_set_intfdata(interface, dev);
-
pr_info("Registered device AU0828 [%s]\n",
dev->board.name == NULL ? "Unset" : dev->board.name);
--
2.20.1
Re: [PATCH 1/3] media: dvb-usb-v2: Report error on all error paths
Hi Stefan,
On Fri, Apr 12, 2019 at 03:12:58AM +0200, Stefan Brüns wrote:
> actual_length != wlen is the only error path which does not generate an
> error message. Adding an error message here allows to report a more
> specific error and to remove the error reporting from the call sites.
>
> Also clean up the error paths - in case of an error, the remaining
> code is skipped, and ret is returned. Skip setting ret and return
> immediately (no cleanup necessary).
There is no Signed-off-by: line:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=signed%20off#sign-your-work-the-developer-s-certificate-of-origin
This is needed for merging.
Sean
> ---
> drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c
> b/drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c
> index 5bafeb6486be..5b32d159f968 100644
> --- a/drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c
> +++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c
> @@ -37,14 +37,19 @@ static int dvb_usb_v2_generic_io(struct dvb_usb_device *d,
> ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev,
> d->props->generic_bulk_ctrl_endpoint), wbuf, wlen,
> _length, 2000);
> - if (ret < 0)
> + if (ret) {
> dev_err(>udev->dev, "%s: usb_bulk_msg() failed=%d\n",
> KBUILD_MODNAME, ret);
> - else
> - ret = actual_length != wlen ? -EIO : 0;
> + return ret;
> + }
> + if (actual_length != wlen) {
> + dev_err(>udev->dev, "%s: usb_bulk_msg() write length=%d,
> actual=%d\n",
> + KBUILD_MODNAME, wlen, actual_length);
> + return -EIO;
> + }
>
> - /* an answer is expected, and no error before */
> - if (!ret && rbuf && rlen) {
> + /* an answer is expected */
> + if (rbuf && rlen) {
> if (d->props->generic_bulk_ctrl_delay)
> usleep_range(d->props->generic_bulk_ctrl_delay,
> d->props->generic_bulk_ctrl_delay
> --
> 2.21.0
Re: [PATCH] media: drxk: add a missed check of the return value of write16
On Tue, Dec 25, 2018 at 02:03:07AM -0600, Kangjie Lu wrote: > write16() could fail. The fix inserts a check for its return value > in case it fails. > > Signed-off-by: Kangjie Lu Unless it is tested on the actual hardware we can't apply this. This could introduce regressions. Sean > --- > drivers/media/dvb-frontends/drxk_hard.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/dvb-frontends/drxk_hard.c > b/drivers/media/dvb-frontends/drxk_hard.c > index 84ac3f73f8fe..b7579ffae690 100644 > --- a/drivers/media/dvb-frontends/drxk_hard.c > +++ b/drivers/media/dvb-frontends/drxk_hard.c > @@ -6610,7 +6610,9 @@ static int drxk_get_stats(struct dvb_frontend *fe) > if (status < 0) > goto error; > pkt_error_count = reg16; > - write16(state, SCU_RAM_FEC_ACCUM_PKT_FAILURES__A, 0); > + status = write16(state, SCU_RAM_FEC_ACCUM_PKT_FAILURES__A, 0); > + if (status < 0) > + goto error; > > post_bit_err_count *= post_bit_error_scale; > > -- > 2.17.2 (Apple Git-113)
Re: [PATCH v2] media: si2165: fix a missing check of return value
On Fri, Dec 21, 2018 at 09:24:46AM +0100, Matthias Schwarzott wrote:
> Am 21.12.18 um 05:54 schrieb Kangjie Lu:
> > si2165_readreg8() may fail. Looking into si2165_readreg8(), we will find
> > that "val_tmp" will be an uninitialized value when regmap_read() fails.
> > "val_tmp" is then assigned to "val". So if si2165_readreg8() fails,
> > "val" will be a random value. Further use will lead to undefined
> > behaviors. The fix checks if si2165_readreg8() fails, and if so, returns
> > its error code upstream.
> >
> > Signed-off-by: Kangjie Lu
>
> Reviewed-by: Matthias Schwarzott
Unless it is tested on the actual hardware we can't apply this. This could
introduce regressions.
Sean
>
> > ---
> > drivers/media/dvb-frontends/si2165.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/dvb-frontends/si2165.c
> > b/drivers/media/dvb-frontends/si2165.c
> > index feacd8da421d..d55d8f169dca 100644
> > --- a/drivers/media/dvb-frontends/si2165.c
> > +++ b/drivers/media/dvb-frontends/si2165.c
> > @@ -275,18 +275,20 @@ static u32 si2165_get_fe_clk(struct si2165_state
> > *state)
> >
> > static int si2165_wait_init_done(struct si2165_state *state)
> > {
> > - int ret = -EINVAL;
> > + int ret;
> > u8 val = 0;
> > int i;
> >
> > for (i = 0; i < 3; ++i) {
> > - si2165_readreg8(state, REG_INIT_DONE, );
> > + ret = si2165_readreg8(state, REG_INIT_DONE, );
> > + if (ret < 0)
> > + return ret;
> > if (val == 0x01)
> > return 0;
> > usleep_range(1000, 5);
> > }
> > dev_err(>client->dev, "init_done was not set\n");
> > - return ret;
> > + return -EINVAL;
> > }
> >
> > static int si2165_upload_firmware_block(struct si2165_state *state,
> >
Re: [PATCH 1/3] [media] rc/keymaps: add keytable for Pine64 IR Remote Controller
On Mon, Feb 18, 2019 at 09:59:36PM +, Jonas Karlman wrote:
> This RC map is based on remote key schema at [1], the mouse button key
> did not have an obvious target and was mapped to KEY_CONTEXT_MENU.
How about BTN_LEFT ?
Thanks,
Sean
>
> [1] http://files.pine64.org/doc/Pine%20A64%20Schematic/remote-wit-logo.jpg
>
> Signed-off-by: Jonas Karlman
> ---
> drivers/media/rc/keymaps/Makefile| 1 +
> drivers/media/rc/keymaps/rc-pine64.c | 59
> include/media/rc-map.h | 1 +
> 3 files changed, 61 insertions(+)
> create mode 100644 drivers/media/rc/keymaps/rc-pine64.c
>
> diff --git a/drivers/media/rc/keymaps/Makefile
> b/drivers/media/rc/keymaps/Makefile
> index 5b1399af6b3a..0ea52f65bb03 100644
> --- a/drivers/media/rc/keymaps/Makefile
> +++ b/drivers/media/rc/keymaps/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
> rc-norwood.o \
> rc-npgtech.o \
> rc-pctv-sedna.o \
> + rc-pine64.o \
> rc-pinnacle-color.o \
> rc-pinnacle-grey.o \
> rc-pinnacle-pctv-hd.o \
> diff --git a/drivers/media/rc/keymaps/rc-pine64.c
> b/drivers/media/rc/keymaps/rc-pine64.c
> new file mode 100644
> index ..94e5624f63f4
> --- /dev/null
> +++ b/drivers/media/rc/keymaps/rc-pine64.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Keytable for Pine64 IR Remote Controller
> +// Copyright (c) 2017 Jonas Karlman
> +
> +#include
> +#include
> +
> +static struct rc_map_table pine64[] = {
> + { 0x404000, KEY_NUMERIC_0 },
> + { 0x404001, KEY_NUMERIC_1 },
> + { 0x404002, KEY_NUMERIC_2 },
> + { 0x404003, KEY_NUMERIC_3 },
> + { 0x404004, KEY_NUMERIC_4 },
> + { 0x404005, KEY_NUMERIC_5 },
> + { 0x404006, KEY_NUMERIC_6 },
> + { 0x404007, KEY_NUMERIC_7 },
> + { 0x404008, KEY_NUMERIC_8 },
> + { 0x404009, KEY_NUMERIC_9 },
> + { 0x40400a, KEY_MUTE },
> + { 0x40400b, KEY_UP },
> + { 0x40400c, KEY_BACKSPACE },
> + { 0x40400d, KEY_OK },
> + { 0x40400e, KEY_DOWN },
> + { 0x404010, KEY_LEFT },
> + { 0x404011, KEY_RIGHT },
> + { 0x404017, KEY_VOLUMEDOWN },
> + { 0x404018, KEY_VOLUMEUP },
> + { 0x40401a, KEY_HOME },
> + { 0x40401d, KEY_MENU },
> + { 0x40401f, KEY_WWW },
> + { 0x404045, KEY_BACK },
> + { 0x404047, KEY_CONTEXT_MENU },
> + { 0x40404d, KEY_POWER },
> +};
> +
> +static struct rc_map_list pine64_map = {
> + .map = {
> + .scan = pine64,
> + .size = ARRAY_SIZE(pine64),
> + .rc_proto = RC_PROTO_NECX,
> + .name = RC_MAP_PINE64,
> + }
> +};
> +
> +static int __init init_rc_map_pine64(void)
> +{
> + return rc_map_register(_map);
> +}
> +
> +static void __exit exit_rc_map_pine64(void)
> +{
> + rc_map_unregister(_map);
> +}
> +
> +module_init(init_rc_map_pine64)
> +module_exit(exit_rc_map_pine64)
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jonas Karlman");
> diff --git a/include/media/rc-map.h b/include/media/rc-map.h
> index d621acadfbf3..52b554aa784d 100644
> --- a/include/media/rc-map.h
> +++ b/include/media/rc-map.h
> @@ -236,6 +236,7 @@ struct rc_map *rc_map_get(const char *name);
> #define RC_MAP_NORWOOD "rc-norwood"
> #define RC_MAP_NPGTECH "rc-npgtech"
> #define RC_MAP_PCTV_SEDNA"rc-pctv-sedna"
> +#define RC_MAP_PINE64"rc-pine64"
> #define RC_MAP_PINNACLE_COLOR"rc-pinnacle-color"
> #define RC_MAP_PINNACLE_GREY "rc-pinnacle-grey"
> #define RC_MAP_PINNACLE_PCTV_HD "rc-pinnacle-pctv-hd"
> --
> 2.17.1
Re: DVB-T2 Stick
Hi,
On Wed, Jan 30, 2019 at 11:32:12AM +0100, Gonsolo wrote:
> Hi!
>
> The following patch adds support for the Logilink VG0022A DVB-T2 stick.
> After patching and building the kernel it shows up with lsusb and I
> used w_scan to scan for channels and vlc for watching.
> The original patches were from Andreas Kemnade.
> The only thing that doesn't work is wake up after standby.
>
> Do you think you can apply this patch?
I'm afraid there are many problems with this patch. First of all it looks
like support was added for a si2168 tuner but it looks like it will break
for any other si2157-type device.
Secondly there are lots of coding style issues, see:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
Thanks,
Sean
>
> Thanks
> --
> g
> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
> index d389f1fc237a..1f923418ff10 100644
> --- a/drivers/media/tuners/si2157.c
> +++ b/drivers/media/tuners/si2157.c
> @@ -84,7 +84,7 @@ static int si2157_init(struct dvb_frontend *fe)
> struct si2157_cmd cmd;
> const struct firmware *fw;
> const char *fw_name;
> - unsigned int uitmp, chip_id;
> +unsigned int uitmp;
>
> dev_dbg(>dev, "\n");
>
> @@ -126,7 +126,7 @@ static int si2157_init(struct dvb_frontend *fe)
> if (ret)
> goto err;
> }
> -
> +#if 0
> /* query chip revision */
> memcpy(cmd.args, "\x02", 1);
> cmd.wlen = 1;
> @@ -146,6 +146,8 @@ static int si2157_init(struct dvb_frontend *fe)
> #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
>
> switch (chip_id) {
> +#endif
> +switch (dev->chip_id) {
> case SI2158_A20:
> case SI2148_A20:
> fw_name = SI2158_A20_FIRMWARE;
> @@ -166,9 +168,9 @@ static int si2157_init(struct dvb_frontend *fe)
> goto err;
> }
>
> - dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
> - cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
> -
> +// dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
> +// cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
> +//
> if (fw_name == NULL)
> goto skip_fw_download;
>
> @@ -461,6 +463,38 @@ static int si2157_probe(struct i2c_client *client,
> memcpy(>ops.tuner_ops, _ops, sizeof(struct dvb_tuner_ops));
> fe->tuner_priv = client;
>
> + /* power up */
> + if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
> + memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
> + cmd.wlen = 9;
> + } else {
> + memcpy(cmd.args,
> +
> "\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01",
> + 15);
> + cmd.wlen = 15;
> + }
> + cmd.rlen = 1;
> + ret = si2157_cmd_execute(client, );
> + if (ret)
> + goto err;
> + /* query chip revision */
> + /* hack: do it here because after the si2168 gets 0101, commands will
> +* still be executed here but no result
> +*/
> + memcpy(cmd.args, "\x02", 1);
> + cmd.wlen = 1;
> + cmd.rlen = 13;
> + ret = si2157_cmd_execute(client, );
> + if (ret)
> + goto err_kfree;
> + dev->chip_id = cmd.args[1] << 24 |
> + cmd.args[2] << 16 |
> + cmd.args[3] << 8 |
> + cmd.args[4] << 0;
> + dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
> + cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
> +
> +
> #ifdef CONFIG_MEDIA_CONTROLLER
> if (cfg->mdev) {
> dev->mdev = cfg->mdev;
> diff --git a/drivers/media/tuners/si2157_priv.h
> b/drivers/media/tuners/si2157_priv.h
> index 50f86300d965..3592146cf49a 100644
> --- a/drivers/media/tuners/si2157_priv.h
> +++ b/drivers/media/tuners/si2157_priv.h
> @@ -37,6 +37,7 @@ struct si2157_dev {
> u8 chiptype;
> u8 if_port;
> u32 if_frequency;
> +u32 chip_id;
> struct delayed_work stat_work;
>
> #if defined(CONFIG_MEDIA_CONTROLLER)
> @@ -51,6 +52,13 @@ struct si2157_dev {
> #define SI2157_CHIPTYPE_SI2146 1
> #define SI2157_CHIPTYPE_SI2141 2
>
> +#define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
> +#define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
> +#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
> +#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
> +#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
> +#define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
> +
> /* firmware command struct */
> #define SI2157_ARGLEN 30
> struct si2157_cmd {
> diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
> b/drivers/media/usb/dvb-usb-v2/af9035.c
> index 80d3bd3a0f24..28b073bfe0d4 100644
> --- a/drivers/media/usb/dvb-usb-v2/af9035.c
> +++
Re: [PATCH] selftests: ir: fix warning: ‘%s’ directive output may be truncated
On Thu, Jan 31, 2019 at 12:43:12PM -0700, Shuah Khan wrote:
> Fix the following warning by sizing the buffer to max. of sysfs
> path max. size + d_name max. size.
>
> gcc -Wall -O2 -I../../../include/uapi ir_loopback.c -o
> ../tools/testing/selftests/ir/ir_loopback
> ir_loopback.c: In function ‘lirc_open’:
> ir_loopback.c:71:37: warning: ‘%s’ directive output may be truncated writing
> up to 255 bytes into a region of size 95 [-Wformat-truncation=]
> snprintf(buf, sizeof(buf), "/dev/%s", dent->d_name);
> ^~
> In file included from /usr/include/stdio.h:862:0,
> from ir_loopback.c:14:
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: note:
> ‘__builtin___snprintf_chk’ output between 6 and 261 bytes into a destination
> of size 100
>return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
> ^~~~
> __bos (__s), __fmt, __va_arg_pack ());
> ~
>
> Signed-off-by: Shuah Khan
Thank you for catching and fixing these. For all three patches:
Acked-by: Sean Young
> ---
> tools/testing/selftests/ir/ir_loopback.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/ir/ir_loopback.c
> b/tools/testing/selftests/ir/ir_loopback.c
> index 858c19caf224..8cdf1b89ac9c 100644
> --- a/tools/testing/selftests/ir/ir_loopback.c
> +++ b/tools/testing/selftests/ir/ir_loopback.c
> @@ -27,6 +27,8 @@
>
> #define TEST_SCANCODES 10
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#define SYSFS_PATH_MAX 256
> +#define DNAME_PATH_MAX 256
>
> static const struct {
> enum rc_proto proto;
> @@ -56,7 +58,7 @@ static const struct {
> int lirc_open(const char *rc)
> {
> struct dirent *dent;
> - char buf[100];
> + char buf[SYSFS_PATH_MAX + DNAME_PATH_MAX];
> DIR *d;
> int fd;
>
> --
> 2.17.1
Re: [PATCH] [media] dib7000p: Remove dead code
On Tue, Dec 04, 2018 at 09:57:14AM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 4 Dec 2018 10:26:40 +
> Sean Young escreveu:
>
> > On Mon, Sep 17, 2018 at 07:39:36PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Mon, 17 Sep 2018 10:58:32 -0700
> > > Nick Desaulniers escreveu:
> > >
> > > > On Fri, Sep 14, 2018 at 10:47 PM Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > Clang warns that 'interleaving' is assigned to itself in this
> > > > > function.
> > > > >
> > > > > drivers/media/dvb-frontends/dib7000p.c:1874:15: warning: explicitly
> > > > > assigning value of variable of type 'int' to itself [-Wself-assign]
> > > > > interleaving = interleaving;
> > > > > ^
> > > > > 1 warning generated.
> > > > >
> > > > > It's correct. Just removing the self-assignment would sufficiently
> > > > > hide
> > > > > the warning but all of this code is dead because 'tmp' is zero due to
> > > > > being multiplied by zero. This doesn't appear to be an issue with
> > > > > dib8000, which this code was copied from in commit 041ad449683b
> > > > > ("[media] dib7000p: Add DVBv5 stats support").
> > > > >
> > > > > Reported-by: Nick Desaulniers
> > > > > Signed-off-by: Nathan Chancellor
> > > > > ---
> > > > > drivers/media/dvb-frontends/dib7000p.c | 10 ++
> > > > > 1 file changed, 2 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/dvb-frontends/dib7000p.c
> > > > > b/drivers/media/dvb-frontends/dib7000p.c
> > > > > index 58387860b62d..25843658fc68 100644
> > > > > --- a/drivers/media/dvb-frontends/dib7000p.c
> > > > > +++ b/drivers/media/dvb-frontends/dib7000p.c
> > > > > @@ -1800,9 +1800,8 @@ static u32 dib7000p_get_time_us(struct
> > > > > dvb_frontend *demod)
> > > >
> > > > Something looks wrong here (with this function). The patch is no
> > > > functional change, since as you point out `interleaving` is
> > > > initialized to 0, then never updated before read, but I think there's
> > > > an underlying bug here that should be fixed differently. Thanks for
> > > > the patch though, as it does raise the question.
> > > >
> > > > dib7000p_get_time_us has this comment above it:
> > > >
> > > > 1798 /* FIXME: may require changes - this one was borrowed from
> > > > dib8000 */
> > >
> > > The goal of dib7000p_get_time_us() is to estimate how much time it
> > > takes, with current tuning parameters, to have a certain number of
> > > DVB-T packets. This is used for block error count. That's said,
> > > on a quick look, it seems that the code is not right on many ways.
> > >
> > > It should be aligned with the amount of data it is required for
> > > dib7000 to update the block/bit error counters. There are two kinds
> > > of implementation:
> > >
> > > 1) the frontend has an internal counter that it is shifted and made
> > >available to the driver after a certain amount of received data
> > >(usually in the order of 10^5 to 10^7 bits);
> > >
> > > 2) the frontend has an internal timer that shifts the data from its
> > >internal counter after a certain amount of time (usually at the
> > >seconds range).
> > >
> > > Different vendors opt for either one of the strategy. Some updates
> > > a counter with the amount of bits taken. Unfortunately, this is not
> > > the case of those dib* frontends. So, the Kernel has to estimate
> > > it, based on the tuning parameters.
> > >
> > > From the code, it seems that, for block errors, it waits for 1,250,000
> > > bits to arrive (e. g. about 766 packets), so, it uses type (1) strategy:
> > >
> > > /* Estimate the number of packets based on bitrate */
> > > if (!time_us)
> > > time_us = dib7000p_get_time_us(demod);
> > >
> > > if (time_us) {
> > > blocks = 125ULL * 100ULL; // the multiply
> > > here is to convert to microsseconds...
> > > do_div(blocks, time_us * 8 * 204);// As
Re: [PATCH] [media] dib7000p: Remove dead code
On Tue, Dec 04, 2018 at 09:57:14AM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 4 Dec 2018 10:26:40 +
> Sean Young escreveu:
>
> > On Mon, Sep 17, 2018 at 07:39:36PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Mon, 17 Sep 2018 10:58:32 -0700
> > > Nick Desaulniers escreveu:
> > >
> > > > On Fri, Sep 14, 2018 at 10:47 PM Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > Clang warns that 'interleaving' is assigned to itself in this
> > > > > function.
> > > > >
> > > > > drivers/media/dvb-frontends/dib7000p.c:1874:15: warning: explicitly
> > > > > assigning value of variable of type 'int' to itself [-Wself-assign]
> > > > > interleaving = interleaving;
> > > > > ^
> > > > > 1 warning generated.
> > > > >
> > > > > It's correct. Just removing the self-assignment would sufficiently
> > > > > hide
> > > > > the warning but all of this code is dead because 'tmp' is zero due to
> > > > > being multiplied by zero. This doesn't appear to be an issue with
> > > > > dib8000, which this code was copied from in commit 041ad449683b
> > > > > ("[media] dib7000p: Add DVBv5 stats support").
> > > > >
> > > > > Reported-by: Nick Desaulniers
> > > > > Signed-off-by: Nathan Chancellor
> > > > > ---
> > > > > drivers/media/dvb-frontends/dib7000p.c | 10 ++
> > > > > 1 file changed, 2 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/dvb-frontends/dib7000p.c
> > > > > b/drivers/media/dvb-frontends/dib7000p.c
> > > > > index 58387860b62d..25843658fc68 100644
> > > > > --- a/drivers/media/dvb-frontends/dib7000p.c
> > > > > +++ b/drivers/media/dvb-frontends/dib7000p.c
> > > > > @@ -1800,9 +1800,8 @@ static u32 dib7000p_get_time_us(struct
> > > > > dvb_frontend *demod)
> > > >
> > > > Something looks wrong here (with this function). The patch is no
> > > > functional change, since as you point out `interleaving` is
> > > > initialized to 0, then never updated before read, but I think there's
> > > > an underlying bug here that should be fixed differently. Thanks for
> > > > the patch though, as it does raise the question.
> > > >
> > > > dib7000p_get_time_us has this comment above it:
> > > >
> > > > 1798 /* FIXME: may require changes - this one was borrowed from
> > > > dib8000 */
> > >
> > > The goal of dib7000p_get_time_us() is to estimate how much time it
> > > takes, with current tuning parameters, to have a certain number of
> > > DVB-T packets. This is used for block error count. That's said,
> > > on a quick look, it seems that the code is not right on many ways.
> > >
> > > It should be aligned with the amount of data it is required for
> > > dib7000 to update the block/bit error counters. There are two kinds
> > > of implementation:
> > >
> > > 1) the frontend has an internal counter that it is shifted and made
> > >available to the driver after a certain amount of received data
> > >(usually in the order of 10^5 to 10^7 bits);
> > >
> > > 2) the frontend has an internal timer that shifts the data from its
> > >internal counter after a certain amount of time (usually at the
> > >seconds range).
> > >
> > > Different vendors opt for either one of the strategy. Some updates
> > > a counter with the amount of bits taken. Unfortunately, this is not
> > > the case of those dib* frontends. So, the Kernel has to estimate
> > > it, based on the tuning parameters.
> > >
> > > From the code, it seems that, for block errors, it waits for 1,250,000
> > > bits to arrive (e. g. about 766 packets), so, it uses type (1) strategy:
> > >
> > > /* Estimate the number of packets based on bitrate */
> > > if (!time_us)
> > > time_us = dib7000p_get_time_us(demod);
> > >
> > > if (time_us) {
> > > blocks = 125ULL * 100ULL; // the multiply
> > > here is to convert to microsseconds...
> > > do_div(blocks, time_us * 8 * 204);// As
Re: [PATCH] media: dvb: fix a missing-check bug
Hi Wenwen, On Mon, Oct 29, 2018 at 01:46:04PM -0500, Wenwen Wang wrote: > Hello, > > Can anyone confirm this bug? Thanks! > > Wenwen > > On Fri, Oct 19, 2018 at 9:12 AM Wenwen Wang wrote: > > > > In dvb_audio_write(), the first byte of the user-space buffer 'buf' is > > firstly copied and checked to see whether this is a TS packet, which always > > starts with 0x47 for synchronization purposes. If yes, ts_play() will be > > called. Otherwise, dvb_aplay() will be called. In ts_play(), the content of > > 'buf', including the first byte, is copied again from the user space. > > However, after the copy, no check is re-enforced on the first byte of the > > copied data. Given that 'buf' is in the user space, a malicious user can > > race to change the first byte after the check in dvb_audio_write() but > > before the copy in ts_play(). Up to here your analysis makes sense. > > Through this way, the user can supply > > inconsistent code, which can cause undefined behavior of the kernel and > > introduce potential security risk. So how can this cause undefined behaviour? > > This patch adds a necessary check in ts_play() to make sure the first byte > > acquired in the second copy contains the expected value. Otherwise, an > > error code EINVAL will be returned. So what about the other case, if dvb_play() was called due to the first byte not being 0x47 and then swapped for 0x47? Sean > > > > Signed-off-by: Wenwen Wang > > --- > > drivers/media/pci/ttpci/av7110_av.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/media/pci/ttpci/av7110_av.c > > b/drivers/media/pci/ttpci/av7110_av.c > > index ef1bc17..1ff6062 100644 > > --- a/drivers/media/pci/ttpci/av7110_av.c > > +++ b/drivers/media/pci/ttpci/av7110_av.c > > @@ -468,6 +468,8 @@ static ssize_t ts_play(struct av7110 *av7110, const > > char __user *buf, > > } > > if (copy_from_user(kb, buf, TS_SIZE)) > > return -EFAULT; > > + if (kb[0] != 0x47) > > + return -EINVAL; > > write_ts_to_decoder(av7110, type, kb, TS_SIZE); > > todo -= TS_SIZE; > > buf += TS_SIZE; > > -- > > 2.7.4 > >
Re: [PATCH] media: dvb: fix a missing-check bug
Hi Wenwen, On Mon, Oct 29, 2018 at 01:46:04PM -0500, Wenwen Wang wrote: > Hello, > > Can anyone confirm this bug? Thanks! > > Wenwen > > On Fri, Oct 19, 2018 at 9:12 AM Wenwen Wang wrote: > > > > In dvb_audio_write(), the first byte of the user-space buffer 'buf' is > > firstly copied and checked to see whether this is a TS packet, which always > > starts with 0x47 for synchronization purposes. If yes, ts_play() will be > > called. Otherwise, dvb_aplay() will be called. In ts_play(), the content of > > 'buf', including the first byte, is copied again from the user space. > > However, after the copy, no check is re-enforced on the first byte of the > > copied data. Given that 'buf' is in the user space, a malicious user can > > race to change the first byte after the check in dvb_audio_write() but > > before the copy in ts_play(). Up to here your analysis makes sense. > > Through this way, the user can supply > > inconsistent code, which can cause undefined behavior of the kernel and > > introduce potential security risk. So how can this cause undefined behaviour? > > This patch adds a necessary check in ts_play() to make sure the first byte > > acquired in the second copy contains the expected value. Otherwise, an > > error code EINVAL will be returned. So what about the other case, if dvb_play() was called due to the first byte not being 0x47 and then swapped for 0x47? Sean > > > > Signed-off-by: Wenwen Wang > > --- > > drivers/media/pci/ttpci/av7110_av.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/media/pci/ttpci/av7110_av.c > > b/drivers/media/pci/ttpci/av7110_av.c > > index ef1bc17..1ff6062 100644 > > --- a/drivers/media/pci/ttpci/av7110_av.c > > +++ b/drivers/media/pci/ttpci/av7110_av.c > > @@ -468,6 +468,8 @@ static ssize_t ts_play(struct av7110 *av7110, const > > char __user *buf, > > } > > if (copy_from_user(kb, buf, TS_SIZE)) > > return -EFAULT; > > + if (kb[0] != 0x47) > > + return -EINVAL; > > write_ts_to_decoder(av7110, type, kb, TS_SIZE); > > todo -= TS_SIZE; > > buf += TS_SIZE; > > -- > > 2.7.4 > >
[PATCH] MIPS: Remove superfluous check for __linux__
When building BPF code using "clang -target bpf -c", clang does not define __linux__. To build BPF IR decoders the include linux/lirc.h is needed which includes linux/types.h. Currently this workaround is needed: https://git.linuxtv.org/v4l-utils.git/commit/?id=dd3ff81f58c4e1e6f33765dc61ad33c48ae6bb07 This check might otherwise be useful to stop users from using a non-linux compiler, but if you're doing that you are going to have a lot more trouble anyway. Signed-off-by: Sean Young --- arch/mips/include/uapi/asm/sgidefs.h | 8 1 file changed, 8 deletions(-) diff --git a/arch/mips/include/uapi/asm/sgidefs.h b/arch/mips/include/uapi/asm/sgidefs.h index 26143e3b7c26..69c3de90c536 100644 --- a/arch/mips/include/uapi/asm/sgidefs.h +++ b/arch/mips/include/uapi/asm/sgidefs.h @@ -11,14 +11,6 @@ #ifndef __ASM_SGIDEFS_H #define __ASM_SGIDEFS_H -/* - * Using a Linux compiler for building Linux seems logic but not to - * everybody. - */ -#ifndef __linux__ -#error Use a Linux compiler or give up. -#endif - /* * Definitions for the ISA levels * -- 2.19.1
[PATCH] MIPS: Remove superfluous check for __linux__
When building BPF code using "clang -target bpf -c", clang does not define __linux__. To build BPF IR decoders the include linux/lirc.h is needed which includes linux/types.h. Currently this workaround is needed: https://git.linuxtv.org/v4l-utils.git/commit/?id=dd3ff81f58c4e1e6f33765dc61ad33c48ae6bb07 This check might otherwise be useful to stop users from using a non-linux compiler, but if you're doing that you are going to have a lot more trouble anyway. Signed-off-by: Sean Young --- arch/mips/include/uapi/asm/sgidefs.h | 8 1 file changed, 8 deletions(-) diff --git a/arch/mips/include/uapi/asm/sgidefs.h b/arch/mips/include/uapi/asm/sgidefs.h index 26143e3b7c26..69c3de90c536 100644 --- a/arch/mips/include/uapi/asm/sgidefs.h +++ b/arch/mips/include/uapi/asm/sgidefs.h @@ -11,14 +11,6 @@ #ifndef __ASM_SGIDEFS_H #define __ASM_SGIDEFS_H -/* - * Using a Linux compiler for building Linux seems logic but not to - * everybody. - */ -#ifndef __linux__ -#error Use a Linux compiler or give up. -#endif - /* * Definitions for the ISA levels * -- 2.19.1
Re: [PATCH v5 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2
On Mon, Jun 04, 2018 at 07:47:30PM +0200, Matthias Reichl wrote: > Hi Sean, > > I finally found the time to test your patch series and noticed > 2 issues - comments are inline > > On Sun, May 27, 2018 at 12:24:09PM +0100, Sean Young wrote: > > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > > index eb2c3b6eca7f..d5b35a6ba899 100644 > > --- a/drivers/media/rc/Kconfig > > +++ b/drivers/media/rc/Kconfig > > @@ -25,6 +25,19 @@ config LIRC > >passes raw IR to and from userspace, which is needed for > >IR transmitting (aka "blasting") and for the lirc daemon. > > > > +config BPF_LIRC_MODE2 > > + bool "Support for eBPF programs attached to lirc devices" > > + depends on BPF_SYSCALL > > + depends on RC_CORE=y > > Requiring rc-core to be built into the kernel could become > problematic in the future for people using media_build. > > Currently the whole media tree (including rc-core) can be built > as modules so DVB and IR drivers can be replaced by newer versions. > But with rc-core in the kernel things could easily break if internal > data structures are changed. > > Maybe we should add a small layer with a stable API/ABI between > bpf-lirc and rc-core to decouple them? Or would it be possible > to build rc-core with bpf support as a module? Unfortunately bpf cannot be built as a module. > > + depends on LIRC > > + help > > + Allow attaching eBPF programs to a lirc device using the bpf(2) > > + syscall command BPF_PROG_ATTACH. This is supported for raw IR > > + receivers. > > + > > + These eBPF programs can be used to decode IR into scancodes, for > > + IR protocols not supported by the kernel decoders. > > + > > menuconfig RC_DECODERS > > bool "Remote controller decoders" > > depends on RC_CORE > > [...] > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > > index 388d4feda348..3c104113d040 100644 > > --- a/kernel/bpf/syscall.c > > +++ b/kernel/bpf/syscall.c > > @@ -11,6 +11,7 @@ > > */ > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -1578,6 +1579,8 @@ static int bpf_prog_attach(const union bpf_attr *attr) > > case BPF_SK_SKB_STREAM_PARSER: > > case BPF_SK_SKB_STREAM_VERDICT: > > return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, true); > > + case BPF_LIRC_MODE2: > > + return lirc_prog_attach(attr); > > default: > > return -EINVAL; > > } > > @@ -1648,6 +1651,8 @@ static int bpf_prog_detach(const union bpf_attr *attr) > > case BPF_SK_SKB_STREAM_PARSER: > > case BPF_SK_SKB_STREAM_VERDICT: > > return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, false); > > + case BPF_LIRC_MODE2: > > + return lirc_prog_detach(attr); > > default: > > return -EINVAL; > > } > > @@ -1695,6 +1700,8 @@ static int bpf_prog_query(const union bpf_attr *attr, > > case BPF_CGROUP_SOCK_OPS: > > case BPF_CGROUP_DEVICE: > > break; > > + case BPF_LIRC_MODE2: > > + return lirc_prog_query(attr, uattr); > > When testing this patch series I was wondering why I always got > -EINVAL when trying to query the registered programs. > > Closer inspection revealed that bpf_prog_attach/detach/query and > calls to them in the bpf syscall are in "#ifdef CONFIG_CGROUP_BPF" > blocks - and as I built the kernel without CONFIG_CGROUP_BPF > BPF_PROG_ATTACH/DETACH/QUERY weren't handled in the syscall switch > and I got -EINVAL from the bpf syscall function. > > I haven't checked in detail yet, but it looks to me like > bpf_prog_attach/detach/query could always be built (or when > either cgroup bpf or lirc bpf are enabled) and the #ifdefs moved > inside the switch(). So lirc bpf could be used without cgroup bpf. > Or am I missing something? You are right, this features depends on CONFIG_CGROUP_BPF right now. This also affects the BPF_SK_MSG_VERDICT, BPF_SK_SKB_STREAM_VERDICT and BPF_SK_SKB_STREAM_PARSER type bpf attachments, and as far as I know these shouldn't depend on CONFIG_CGROUP_BPF either. Sean
