Re: [PATCH v2 -next] media: staging: tegra-vde: Mark tegra_vde_runtime_suspend/resume as __maybe_unused
04.08.2020 04:41, YueHaibing пишет:
> If CONFIG_PM is not set, gcc warns:
>
> drivers/staging/media/tegra-vde/vde.c:916:12:
> warning: 'tegra_vde_runtime_suspend' defined but not used [-Wunused-function]
>
> Make it __maybe_unused to fix this.
>
> Signed-off-by: YueHaibing
> ---
> v2: both suspend and resume functions marked
> ---
> drivers/staging/media/tegra-vde/vde.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/tegra-vde/vde.c
> b/drivers/staging/media/tegra-vde/vde.c
> index a3c24d96d5b9..28845b5bafaf 100644
> --- a/drivers/staging/media/tegra-vde/vde.c
> +++ b/drivers/staging/media/tegra-vde/vde.c
> @@ -913,7 +913,7 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static int tegra_vde_runtime_suspend(struct device *dev)
> +static __maybe_unused int tegra_vde_runtime_suspend(struct device *dev)
> {
> struct tegra_vde *vde = dev_get_drvdata(dev);
> int err;
> @@ -929,7 +929,7 @@ static int tegra_vde_runtime_suspend(struct device *dev)
> return 0;
> }
>
> -static int tegra_vde_runtime_resume(struct device *dev)
> +static __maybe_unused int tegra_vde_runtime_resume(struct device *dev)
> {
> struct tegra_vde *vde = dev_get_drvdata(dev);
> int err;
>
Thanks!
Reviewed-by: Dmitry Osipenko
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] Provide USF for the portable equipment.
On 03-08-20, 22:31, Dongdong Yang wrote: > From: Dongdong Yang > > This patch provides USF(User Sensitive Feedback factor) auxiliary > cpufreq governor to support high level layer sysfs inodes setting > for utils adjustment purpose from the identified scenario on portable > equipment. Because the power consumption and UI response are more cared > for by portable equipment users. And the "screen off" status stands for > no request from the user, however, the kernel is still expected to > notify the user in time on modem, network or powerkey events occur. USF > provides "sched_usf_non_ux_r" sysfs inode to cut down the utils from > user space tasks according to high level scenario. In addition, it > usually hints more cpufreq demand that the preemptive counts of the > tasks on the cpu burst and over the user expecting completed time such > as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on > "screen on" status, which more likely with more UI. The sysfs inodes > "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust > the utils according to high level identified scenario to alloc the > cpufreq in time. > > Changes in v3 > - Move usf.c to kernel/sched. > - Remove trace_printk and debugfs. > - Add document draft. > - Update comments. > > Changes in v2 > - Add adjust_task_pred_set switch. > - Move adjust_task_pred_demand declaration into sched.h > - Update comments. Sending updated patchset for this isn't going to help you my friend. You need people (maintainers) to agree on the idea here first. The patch can be beautified later if required once the idea is agreed upon. I saw Peter already gave his NAK to it during V1. You need to discuss with people here to see why they don't like it first and as Greg said earlier, this should not go to staging at all if it ever makes it mainline. The more versions you send now (without proper discussions first), the harder it will be for this stuff to get merged upstream. -- viresh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 -next] media: staging: tegra-vde: Mark tegra_vde_runtime_suspend/resume as __maybe_unused
If CONFIG_PM is not set, gcc warns:
drivers/staging/media/tegra-vde/vde.c:916:12:
warning: 'tegra_vde_runtime_suspend' defined but not used [-Wunused-function]
Make it __maybe_unused to fix this.
Signed-off-by: YueHaibing
---
v2: both suspend and resume functions marked
---
drivers/staging/media/tegra-vde/vde.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/tegra-vde/vde.c
b/drivers/staging/media/tegra-vde/vde.c
index a3c24d96d5b9..28845b5bafaf 100644
--- a/drivers/staging/media/tegra-vde/vde.c
+++ b/drivers/staging/media/tegra-vde/vde.c
@@ -913,7 +913,7 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
return IRQ_HANDLED;
}
-static int tegra_vde_runtime_suspend(struct device *dev)
+static __maybe_unused int tegra_vde_runtime_suspend(struct device *dev)
{
struct tegra_vde *vde = dev_get_drvdata(dev);
int err;
@@ -929,7 +929,7 @@ static int tegra_vde_runtime_suspend(struct device *dev)
return 0;
}
-static int tegra_vde_runtime_resume(struct device *dev)
+static __maybe_unused int tegra_vde_runtime_resume(struct device *dev)
{
struct tegra_vde *vde = dev_get_drvdata(dev);
int err;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: staging: tegra-vde: Mark tegra_vde_runtime_suspend as __maybe_unused
On 2020/8/3 22:11, Dmitry Osipenko wrote:
> 03.08.2020 16:00, Yuehaibing пишет:
>> On 2020/8/3 20:51, Dmitry Osipenko wrote:
>>> 03.08.2020 14:59, YueHaibing пишет:
If CONFIG_PM is not set, gcc warns:
drivers/staging/media/tegra-vde/vde.c:916:12:
warning: 'tegra_vde_runtime_suspend' defined but not used
[-Wunused-function]
Make it __maybe_unused to fix this.
Signed-off-by: YueHaibing
---
drivers/staging/media/tegra-vde/vde.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/tegra-vde/vde.c
b/drivers/staging/media/tegra-vde/vde.c
index a3c24d96d5b9..2d043d518eef 100644
--- a/drivers/staging/media/tegra-vde/vde.c
+++ b/drivers/staging/media/tegra-vde/vde.c
@@ -913,7 +913,7 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
return IRQ_HANDLED;
}
-static int tegra_vde_runtime_suspend(struct device *dev)
+static __maybe_unused int tegra_vde_runtime_suspend(struct device *dev)
{
struct tegra_vde *vde = dev_get_drvdata(dev);
int err;
>>>
>>> Hello Yue,
>>>
>>> Shouldn't the tegra_vde_runtime_resume() be marked as well?
>>
>> No, tegra_vde_runtime_resume() always be called by tegra_vde_shutdown().
>
> Well.. it's unused, but compiler doesn't complain about runtime_resume()
> because it sees the potential reference to that function in the code
> (even that it's a dead code), while runtime_suspend() reference is
> completely removed by preprocessor before compiler sees the code.
>
I see, thanks, will send v2.
> Should be nicer to have both suspend and resume functions marked, for
> consistency, IMO.
>
> .
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v10 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.
of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code. These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 10 +--
arch/arm/mach-keystone/keystone.c | 17 +++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +--
arch/sh/kernel/dma-coherent.c | 15 ++--
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 5 +-
drivers/base/core.c | 2 +
drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 4 +-
drivers/of/address.c | 72 +--
drivers/of/device.c | 43 ++-
drivers/of/of_private.h | 10 +--
drivers/of/unittest.c | 31 +---
drivers/remoteproc/remoteproc_core.c | 8 ++-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 7 +-
drivers/usb/core/message.c| 9 ++-
drivers/usb/core/usb.c| 7 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 8 +--
include/linux/dma-mapping.h | 36 ++
kernel/dma/coherent.c | 10 +--
kernel/dma/mapping.c | 65 +
24 files changed, 269 insertions(+), 122 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..2405afeb7957 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,11 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev) {
+ phys_addr_t paddr = PFN_PHYS(pfn);
+
+ pfn -= (dma_offset_from_phys_addr(dev, paddr) >> PAGE_SHIFT);
+ }
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -45,8 +48,7 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
unsigned long pfn = __bus_to_pfn(addr);
if (dev)
- pfn += dev->dma_pfn_offset;
-
+ pfn += (dma_offset_from_dma_addr(dev, addr) >> PAGE_SHIFT);
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..78808942ad1c 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,6 @@
#include "keystone.h"
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
static int keystone_platform_notifier(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_set_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+ dev_err(dev, "set dma_offset%08llx%s\n",
+ KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
@@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
static void __init keystone_init(void)
{
- if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
- keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
- KEYSTONE_LOW_PHYS_START);
+ if
[PATCH v10 00/11] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v10:
Commit: "device-mapping: Introduce DMA range map, supplanting ..."
-- change title of commit; "bus core:" => "device-mapping:"
-- instead of allocating the DMA map with devm, use kcalloc
and call kfree() during device_release(). (RobH) Also,
for three cases that want to use the same DMA map, copy
the dma_range_map using a helper function.
-- added a missing 'return = 0;' to of_dma_get_range(). (Nicolas)
-- removed dma_range_overlaps(); instead return error if there
is an existing DMA map. (Christoph).
Commit: "PCI: brcmstb: Set additional internal memory DMA ..."
-- Changed constant 1 to 1ULL. (Nicolas)
Commit: "ata: ahci_brcm: Fix use of BCM7216 reset controller"
This commit has been removed from this patchset and will be
submitted on its own.
v9:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- A number of code improvements were implemented as suggested by
ChristophH. Unfortunately, some of these changes reversed the
implemented suggestions of other reviewers; for example, the new
macros PFN_DMA_ADDR(), DMA_ADDR_PFN() have been pulled.
v8:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- To satisfy a specific m68 compile configuration, I moved the 'struct
bus_dma_region; definition out of #ifdef CONFIG_HAS_DMA and also defined
three inline functions for !CONFIG_HAS_DMA (kernel test robot).
-- The sunXi drivers -- suc4i_csi, sun6i_csi, cedrus_hw -- set
a pfn_offset outside of_dma_configure() but the code offers no
insight on the size of the translation window. V7 had me using
SIZE_MAX as the size. I have since contacted the sunXi maintainer and
he said that using a size of SZ_4G would cover sunXi configurations.
v7:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- remove second kcalloc/copy in device.c (AndyS)
-- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS)
-- indentation, sizeof(struct ...) => sizeof(*r) (AndyS)
-- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS)
-- Fixed compile error in "sun6i_csi.c" (kernel test robot)
Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller"
-- correct name of function in the commit msg (SergeiS)
v6:
Commit "device core: Introduce DMA range map":
-- of_dma_get_range() now takes a single argument and returns either
NULL, a valid map, or an ERR_PTR. (Robin)
-- offsets are no longer a PFN value but an actual address. (Robin)
-- the bus_dma_region struct stores the range size instead of
the cpu_end and pci_end values. (Robin)
-- devices that were setting a single offset with no boundaries
have been modified to have boundaries; in a few places
where this information was unavilable a /* FIXME: ... */
comment was added. (Robin)
-- dma_attach_offset_range() can be called when an offset
map already exists; if it's range is already present
nothing is done and success is returned. (Robin)
All commits:
-- Man name/style/corrections/etc changed (Bjorn)
-- rebase to Torvalds master
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" => "*map_size = 0"
-- use kcalloc instead of kzalloc (AndyS)
-- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
Commit "PCI: brcmstb: Set internal memory viewport sizes"
-- now gives error on missing dma-ranges property.
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- removed "Allof:" from brcm,scb-sizes definition (RobH)
All Commits:
-- indentation style, use max chars 100 (AndyS)
-- rebased to torvalds master
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
-- the separate case of having a single pfn offset has
been removed and is now processed by going through the
map array. (Nicolas)
-- move attach_uniform_dma_pfn_offset() from of/address.c to
dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
-- devm_kcalloc => devm_kzalloc (DanC)
-- add/fix assignment to dev->dma_pfn_offset_map for func
attach_uniform_dma_pfn_offset() (DanC, Nicolas)
-- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
-- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
-- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
-- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
Commit "of: Include a dev param in of_dma_get_range()"
-- this commit was sqaushed with "device core: Introduce ..."
v3:
Re: [PATCH v3] sched: Provide USF for the portable equipment.
On 8/3/20 7:31 AM, Dongdong Yang wrote: > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > index 4ec5528..05b231e 100644 > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -120,4 +120,6 @@ source "drivers/staging/qlge/Kconfig" > > source "drivers/staging/wfx/Kconfig" > > +source "drivers/staging/fbsched/Kconfig" where is this fbsched/Kconfig and its associated source files? > + > endif # STAGING -- ~Randy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers: most: add character device interface driver
This patch adds the character device (cdev) driver source file
most_cdev.c and modifies the Makefiles and Kconfigs accordingly.
Signed-off-by: Christian Gromm
---
drivers/most/Kconfig | 9 +
drivers/most/Makefile | 1 +
drivers/most/most_cdev.c | 543 +
drivers/staging/most/Kconfig | 2 -
drivers/staging/most/Makefile | 1 -
drivers/staging/most/cdev/Kconfig | 13 -
drivers/staging/most/cdev/Makefile | 4 -
drivers/staging/most/cdev/cdev.c | 543 -
8 files changed, 553 insertions(+), 563 deletions(-)
create mode 100644 drivers/most/most_cdev.c
delete mode 100644 drivers/staging/most/cdev/Kconfig
delete mode 100644 drivers/staging/most/cdev/Makefile
delete mode 100644 drivers/staging/most/cdev/cdev.c
diff --git a/drivers/most/Kconfig b/drivers/most/Kconfig
index 60fc082..ebfe84e 100644
--- a/drivers/most/Kconfig
+++ b/drivers/most/Kconfig
@@ -23,4 +23,13 @@ config MOST_USB_HDM
To compile this driver as a module, choose M here: the
module will be called most_usb.
+
+config MOST_CDEV
+ tristate "Cdev"
+
+ help
+ Say Y here if you want to commumicate via character devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called most_cdev.
endif
diff --git a/drivers/most/Makefile b/drivers/most/Makefile
index 6a3cb90..8b53ca4 100644
--- a/drivers/most/Makefile
+++ b/drivers/most/Makefile
@@ -4,3 +4,4 @@ most_core-y := core.o \
configfs.o
obj-$(CONFIG_MOST_USB_HDM) += most_usb.o
+obj-$(CONFIG_MOST_CDEV) += most_cdev.o
diff --git a/drivers/most/most_cdev.c b/drivers/most/most_cdev.c
new file mode 100644
index 000..0448807
--- /dev/null
+++ b/drivers/most/most_cdev.c
@@ -0,0 +1,543 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * cdev.c - Character device component for Mostcore
+ *
+ * Copyright (C) 2013-2015 Microchip Technology Germany II GmbH & Co. KG
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CHRDEV_REGION_SIZE 50
+
+static struct cdev_component {
+ dev_t devno;
+ struct ida minor_id;
+ unsigned int major;
+ struct class *class;
+ struct most_component cc;
+} comp;
+
+struct comp_channel {
+ wait_queue_head_t wq;
+ spinlock_t unlink; /* synchronization lock to unlink channels */
+ struct cdev cdev;
+ struct device *dev;
+ struct mutex io_mutex;
+ struct most_interface *iface;
+ struct most_channel_config *cfg;
+ unsigned int channel_id;
+ dev_t devno;
+ size_t mbo_offs;
+ DECLARE_KFIFO_PTR(fifo, typeof(struct mbo *));
+ int access_ref;
+ struct list_head list;
+};
+
+#define to_channel(d) container_of(d, struct comp_channel, cdev)
+static struct list_head channel_list;
+static spinlock_t ch_list_lock;
+
+static inline bool ch_has_mbo(struct comp_channel *c)
+{
+ return channel_has_mbo(c->iface, c->channel_id, ) > 0;
+}
+
+static inline struct mbo *ch_get_mbo(struct comp_channel *c, struct mbo **mbo)
+{
+ if (!kfifo_peek(>fifo, mbo)) {
+ *mbo = most_get_mbo(c->iface, c->channel_id, );
+ if (*mbo)
+ kfifo_in(>fifo, mbo, 1);
+ }
+ return *mbo;
+}
+
+static struct comp_channel *get_channel(struct most_interface *iface, int id)
+{
+ struct comp_channel *c, *tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(_list_lock, flags);
+ list_for_each_entry_safe(c, tmp, _list, list) {
+ if ((c->iface == iface) && (c->channel_id == id)) {
+ spin_unlock_irqrestore(_list_lock, flags);
+ return c;
+ }
+ }
+ spin_unlock_irqrestore(_list_lock, flags);
+ return NULL;
+}
+
+static void stop_channel(struct comp_channel *c)
+{
+ struct mbo *mbo;
+
+ while (kfifo_out((struct kfifo *)>fifo, , 1))
+ most_put_mbo(mbo);
+ most_stop_channel(c->iface, c->channel_id, );
+}
+
+static void destroy_cdev(struct comp_channel *c)
+{
+ unsigned long flags;
+
+ device_destroy(comp.class, c->devno);
+ cdev_del(>cdev);
+ spin_lock_irqsave(_list_lock, flags);
+ list_del(>list);
+ spin_unlock_irqrestore(_list_lock, flags);
+}
+
+static void destroy_channel(struct comp_channel *c)
+{
+ ida_simple_remove(_id, MINOR(c->devno));
+ kfifo_free(>fifo);
+ kfree(c);
+}
+
+/**
+ * comp_open - implements the syscall to open the device
+ * @inode: inode pointer
+ * @filp: file pointer
+ *
+ * This stores the channel pointer in the private data field of
+ * the file structure and activates the channel within the core.
+ */
+static int comp_open(struct inode *inode, struct file *filp)
+{
+ struct comp_channel *c;
+ int ret;
+
+ c
Re: KASAN: use-after-free Read in hci_chan_del
syzbot has bisected this issue to:
commit 166beccd47e11e4d27477e8ca1d7eda47cf3b2da
Author: Eric Anholt
Date: Mon Oct 3 18:52:06 2016 +
staging/vchi: Convert to current get_user_pages() arguments.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=178321a490
start commit: 5a30a789 Merge tag 'x86-urgent-2020-08-02' of git://git.ke..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=144321a490
console output: https://syzkaller.appspot.com/x/log.txt?x=104321a490
kernel config: https://syzkaller.appspot.com/x/.config?x=e59ee776d5aa8d55
dashboard link: https://syzkaller.appspot.com/bug?extid=305a91e025a73e4fd6ce
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=127dd91490
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=122a94ec90
Reported-by: syzbot+305a91e025a73e4fd...@syzkaller.appspotmail.com
Fixes: 166beccd47e1 ("staging/vchi: Convert to current get_user_pages()
arguments.")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Sat, Aug 1, 2020 at 1:17 PM Nicolas Saenz Julienne
wrote:
>
> Hi Jim, here's some comments after testing your series against RPi4.
>
> On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> > capable of holding a single uniform offset and had no region bounds
> > checking.
> >
> > The function of_dma_get_range() has been modified so that it takes a single
> > argument -- the device node -- and returns a map, NULL, or an error code.
> > The map is an array that holds the information regarding the DMA regions.
> > Each range entry contains the address offset, the cpu_start address, the
> > dma_start address, and the size of the region.
> >
> > of_dma_configure() is the typical manner to set range offsets but there are
> > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> > driver code. These cases now invoke the function
> > dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
> >
> > Signed-off-by: Jim Quinlan
> > ---
>
> [...]
>
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 8eea3f6e29a4..4b718d199efe 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct
> > device_node *np, int index,
> > }
> > EXPORT_SYMBOL(of_io_request_and_map);
> >
> > +#ifdef CONFIG_HAS_DMA
> > /**
> > - * of_dma_get_range - Get DMA range info
> > + * of_dma_get_range - Get DMA range info and put it into a map array
> > * @np: device node to get DMA range info
> > - * @dma_addr:pointer to store initial DMA address of DMA range
> > - * @paddr: pointer to store initial CPU address of DMA range
> > - * @size:pointer to store size of DMA range
> > + * @map: dma range structure to return
> > *
> > * Look in bottom up direction for the first "dma-ranges" property
> > - * and parse it.
> > - * dma-ranges format:
> > + * and parse it. Put the information into a DMA offset map array.
> > + *
> > + * dma-ranges format:
> > * DMA addr (dma_addr) : naddr cells
> > * CPU addr (phys_addr_t) : pna cells
> > * size: nsize cells
> > *
> > - * It returns -ENODEV if "dma-ranges" property was not found
> > - * for this device in DT.
> > + * It returns -ENODEV if "dma-ranges" property was not found for this
> > + * device in the DT.
> > */
> > -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr,
> > u64 *size)
> > +int of_dma_get_range(struct device_node *np, const struct bus_dma_region
> > **map)
> > {
> > struct device_node *node = of_node_get(np);
> > const __be32 *ranges = NULL;
> > - int len;
> > - int ret = 0;
> > bool found_dma_ranges = false;
> > struct of_range_parser parser;
> > struct of_range range;
> > - u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> > + struct bus_dma_region *r;
> > + int len, num_ranges = 0;
> > + int ret;
> >
> > while (node) {
> > ranges = of_get_property(node, "dma-ranges", );
> > @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64
> > *dma_addr, u64 *paddr, u64 *siz
> > }
> >
> > of_dma_range_parser_init(, node);
> > + for_each_of_range(, )
> > + num_ranges++;
> > +
> > + of_dma_range_parser_init(, node);
> > +
> > + ret = -ENOMEM;
> > + r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> > + if (!r)
> > + goto out;
> >
> > + /*
> > + * Record all info in the generic DMA ranges array for struct device.
> > + */
> > + *map = r;
> > for_each_of_range(, ) {
> > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> >range.bus_addr, range.cpu_addr, range.size);
> > -
> > - if (dma_offset && range.cpu_addr - range.bus_addr !=
> > dma_offset) {
> > - pr_warn("Can't handle multiple dma-ranges with
> > different offsets on node(%pOF)\n", node);
> > - /* Don't error out as we'd break some existing DTs */
> > - continue;
> > - }
> > - dma_offset = range.cpu_addr - range.bus_addr;
> > -
> > - /* Take lower and upper limits */
> > - if (range.bus_addr < dma_start)
> > - dma_start = range.bus_addr;
> > - if (range.bus_addr + range.size > dma_end)
> > - dma_end = range.bus_addr + range.size;
> > - }
> > -
> > - if (dma_start >= dma_end) {
> > - ret = -EINVAL;
> > - pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > - node);
> > - goto out;
> > + r->cpu_start = range.cpu_addr;
> >
Reply...
Hello,
My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state and
Petroleum" also "Minister of State for International Cooperation" in UAE. I
write to solicit for your partnership in claiming of {us$90=Million} from a
Financial Home in Cambodia.
The Fund {us$90=Million} is my share from the (Over-invoiced) Oil/Gas deal
with Cambodia/Vietnam Government within 2013/2014, however, I don't want my
government to know about the fund. If this proposal interests you, let me
know by sending me an email and I will send to you detailed Information on
how this business would be successfully transacted. Be informed that nobody
knows about the secret of this fund except me and I know how to carry out
the entire transaction. So I am compelled to ask that you will stand on my
behalf and receive this fund into any account that is solely controlled by
you.
I will compensate you with 30% of the total amount involved as gratification
for being my partner in the transfer. Reply to my private email as stated:
reemal-hash...@yandex.com
Regards,
Ms. Reem Ebrahim Al-Hashimi.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] sched: Provide USF for the portable equipment.
On Mon, Aug 03, 2020 at 10:31:15PM +0800, Dongdong Yang wrote: > + /* > + * create a sched_usf in cpu_subsys: > + * /sys/devices/system/cpu/sched_usf/... I thought I asked you not to use a "raw" kobject, you are making this much harder than it has to be. Just use a normal struct device. Also you failed to document your new sysfs files in Documentation/ABI/ like is required :( Because of both of those things, this isn't ok as-is, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] sched: Provide USF for the portable equipment.
From: Dongdong Yang The power consumption and UI response are more cared for by the portable equipment users. USF(User Sensitive Feedback factor) auxiliary cpufreq governor is providing more utils adjustment settings to the high level by scenario identification. From the view of portable equipment, screen off status usually stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. In some scenarios, such as listening to music, low power processors, such as DSP, take more actions and CPU load requirements cut down. It would bring more power consumption benefit if high level have interfaces to adjust utils according to the current scenario and load. In addition, the portable equipment user usually heavily interact with devices by touch, and other peripherals. The boost preemptive counts are marking the load requirement urgent, vice versa. If such feedback factor could be set to high level according to the scenario, it would contribute to the power consumption and UI response. If no USF sysfs inode is set, and no screen on or off event, adjust_task_pred_demand shall not be invoked. Once sched_usf_up_l0_r sched_usf_down_r or sched_usf_non_ux_r be set, adjust_task_pred_demand shall be called back to update settings according to high level scenario identification. We can get about 17% mean power consumption save at listening to music with speaker on "screen off" scenario, as below statistical data from 7766 XiaoMi devices for two weeks with sched_usf_non_ux_r be set: day1 day2 day3 day4 count 7766.00 7766.00 7766.00 7766.00 mean88.03552585.50028283.82930586.054997 std 111.049980 108.258834 107.562583 108.558240 min 0.099000 0.037000 0.067000 0.045000 25% 34.76550034.02175034.10150034.423000 50% 54.9555.28650054.18950054.248500 75% 95.95400093.94200091.73800094.0592500 80% 114.675000 107.43 106.378000 108.673000 85% 137.851000 129.511000 127.156500 131.750750 90% 179.669000 170.208500 164.027000 172.348000 95% 272.395000 257.845500 247.750500 263.275750 98% 399.034500 412.170400 391.484000 402.835600 day5 day6day7 day8 count 7766.00 7766.0 7766.00 7766.00 mean82.53267779.2192377.61138081.075081 std 104.870079 101.34819 103.140037 97.506221 min 0.051000 0.02900 0.007000 0.068000 25% 32.87300033.4440031.96550033.863500 50% 52.18050051.5655050.80650053.08 75% 90.90575086.8262583.85925089.973000 80% 105.455000 99.6470097.271000104.225000 85% 128.30 118.47825 116.570250 126.648250 90% 166.647500 149.18000 150.649500 161.087000 95% 247.208500 224.36050 226.38 245.291250 98% 393.002000 347.92060 369.791800 378.778600 day9 day10day11day12 count 7766.00 7766.00 7766.00 7766.00 mean79.98917083.85941778.03293077.060542 std 104.226122 108.893043 102.561715 99.844276 min 0.118000 0.017000 0.028000 0.039000 25% 32.05625033.45450031.17625030.897750 50% 51.50600054.05600048.96950049.069000 75% 88.51350092.95350083.50675084.096000 80% 102.876000 107.845000 97.71700098.073000 85% 124.363000 128.288000 118.366500 116.869250 90% 160.557000 167.084000 154.342500 148.187500 95% 231.149000 242.925750 236.759000 228.131250 98% 367.206600 388.619100 385.269100 376.541600 day13day14 count 7766.00 7766.00 mean75.52803673.702878 std 90.75059486.796016 min 0.066000 0.054000 25% 31.17050031.608500 50% 48.75850049.215000 75% 84.52275083.053000 80% 97.87900094.875000 85% 116.680250 113.573750 90% 149.083500 144.089500 95% 226.177750 211.488750 98% 347.011100 331.317100 Signed-off-by: Dongdong Yang Co-developed-by: Jun Tao Co-developed-by: Qiwu Huang Co-developed-by: Peng Wang --- Documentation/scheduler/sched-ufs.txt | 78 + drivers/cpufreq/Kconfig | 11 ++ drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + include/trace/events/sched.h | 35 kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 3 + kernel/sched/sched.h | 10 ++ kernel/sched/usf.c| 305 ++ 9 files changed, 446 insertions(+) create mode 100644 Documentation/scheduler/sched-ufs.txt create mode 100644 kernel/sched/usf.c diff --git a/Documentation/scheduler/sched-ufs.txt
[PATCH v3] Provide USF for the portable equipment.
From: Dongdong Yang This patch provides USF(User Sensitive Feedback factor) auxiliary cpufreq governor to support high level layer sysfs inodes setting for utils adjustment purpose from the identified scenario on portable equipment. Because the power consumption and UI response are more cared for by portable equipment users. And the "screen off" status stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. USF provides "sched_usf_non_ux_r" sysfs inode to cut down the utils from user space tasks according to high level scenario. In addition, it usually hints more cpufreq demand that the preemptive counts of the tasks on the cpu burst and over the user expecting completed time such as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on "screen on" status, which more likely with more UI. The sysfs inodes "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust the utils according to high level identified scenario to alloc the cpufreq in time. Changes in v3 - Move usf.c to kernel/sched. - Remove trace_printk and debugfs. - Add document draft. - Update comments. Changes in v2 - Add adjust_task_pred_set switch. - Move adjust_task_pred_demand declaration into sched.h - Update comments. Dongdong Yang (1): sched: Provide USF for the portable equipment. Documentation/scheduler/sched-ufs.txt | 78 + drivers/cpufreq/Kconfig | 11 ++ drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + include/trace/events/sched.h | 35 kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 3 + kernel/sched/sched.h | 10 ++ kernel/sched/usf.c| 305 ++ 9 files changed, 446 insertions(+) create mode 100644 Documentation/scheduler/sched-ufs.txt create mode 100644 kernel/sched/usf.c -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: staging: tegra-vde: Mark tegra_vde_runtime_suspend as __maybe_unused
03.08.2020 16:00, Yuehaibing пишет:
> On 2020/8/3 20:51, Dmitry Osipenko wrote:
>> 03.08.2020 14:59, YueHaibing пишет:
>>> If CONFIG_PM is not set, gcc warns:
>>>
>>> drivers/staging/media/tegra-vde/vde.c:916:12:
>>> warning: 'tegra_vde_runtime_suspend' defined but not used
>>> [-Wunused-function]
>>>
>>> Make it __maybe_unused to fix this.
>>>
>>> Signed-off-by: YueHaibing
>>> ---
>>> drivers/staging/media/tegra-vde/vde.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/media/tegra-vde/vde.c
>>> b/drivers/staging/media/tegra-vde/vde.c
>>> index a3c24d96d5b9..2d043d518eef 100644
>>> --- a/drivers/staging/media/tegra-vde/vde.c
>>> +++ b/drivers/staging/media/tegra-vde/vde.c
>>> @@ -913,7 +913,7 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
>>> return IRQ_HANDLED;
>>> }
>>>
>>> -static int tegra_vde_runtime_suspend(struct device *dev)
>>> +static __maybe_unused int tegra_vde_runtime_suspend(struct device *dev)
>>> {
>>> struct tegra_vde *vde = dev_get_drvdata(dev);
>>> int err;
>>>
>>
>> Hello Yue,
>>
>> Shouldn't the tegra_vde_runtime_resume() be marked as well?
>
> No, tegra_vde_runtime_resume() always be called by tegra_vde_shutdown().
Well.. it's unused, but compiler doesn't complain about runtime_resume()
because it sees the potential reference to that function in the code
(even that it's a dead code), while runtime_suspend() reference is
completely removed by preprocessor before compiler sees the code.
Should be nicer to have both suspend and resume functions marked, for
consistency, IMO.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: staging: tegra-vde: Mark tegra_vde_runtime_suspend as __maybe_unused
On 2020/8/3 20:51, Dmitry Osipenko wrote:
> 03.08.2020 14:59, YueHaibing пишет:
>> If CONFIG_PM is not set, gcc warns:
>>
>> drivers/staging/media/tegra-vde/vde.c:916:12:
>> warning: 'tegra_vde_runtime_suspend' defined but not used
>> [-Wunused-function]
>>
>> Make it __maybe_unused to fix this.
>>
>> Signed-off-by: YueHaibing
>> ---
>> drivers/staging/media/tegra-vde/vde.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/media/tegra-vde/vde.c
>> b/drivers/staging/media/tegra-vde/vde.c
>> index a3c24d96d5b9..2d043d518eef 100644
>> --- a/drivers/staging/media/tegra-vde/vde.c
>> +++ b/drivers/staging/media/tegra-vde/vde.c
>> @@ -913,7 +913,7 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
>> return IRQ_HANDLED;
>> }
>>
>> -static int tegra_vde_runtime_suspend(struct device *dev)
>> +static __maybe_unused int tegra_vde_runtime_suspend(struct device *dev)
>> {
>> struct tegra_vde *vde = dev_get_drvdata(dev);
>> int err;
>>
>
> Hello Yue,
>
> Shouldn't the tegra_vde_runtime_resume() be marked as well?
No, tegra_vde_runtime_resume() always be called by tegra_vde_shutdown().
>
> .
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: staging: tegra-vde: Mark tegra_vde_runtime_suspend as __maybe_unused
03.08.2020 14:59, YueHaibing пишет:
> If CONFIG_PM is not set, gcc warns:
>
> drivers/staging/media/tegra-vde/vde.c:916:12:
> warning: 'tegra_vde_runtime_suspend' defined but not used [-Wunused-function]
>
> Make it __maybe_unused to fix this.
>
> Signed-off-by: YueHaibing
> ---
> drivers/staging/media/tegra-vde/vde.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/tegra-vde/vde.c
> b/drivers/staging/media/tegra-vde/vde.c
> index a3c24d96d5b9..2d043d518eef 100644
> --- a/drivers/staging/media/tegra-vde/vde.c
> +++ b/drivers/staging/media/tegra-vde/vde.c
> @@ -913,7 +913,7 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static int tegra_vde_runtime_suspend(struct device *dev)
> +static __maybe_unused int tegra_vde_runtime_suspend(struct device *dev)
> {
> struct tegra_vde *vde = dev_get_drvdata(dev);
> int err;
>
Hello Yue,
Shouldn't the tegra_vde_runtime_resume() be marked as well?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] sched: Provide USF for the portable equipment.
On Thu, Jul 30, 2020 at 09:35:43PM +0800, Dongdong Yang wrote: > From: Dongdong Yang > > The power consumption and UI response are more cared > for by the portable equipment users. USF(User Sensitive > Feedback factor) auxiliary cpufreq governor is > providing more utils adjustment settings to a high > level by scenario identification. > > From the view of portable equipment, screen off status > usually stands for no request from the user, however, > the kernel is still expected to notify the user > in time on modem, network or powerkey events occur. > In some scenarios, such as listening to music, > low power processors, such as DSP, take more actions > and CPU load requirements cut down. It would bring > more power consumption benefit if high level have > interfaces to adjust utils according to the current > scenario and load. > > In addition, the portable equipment user usually heavy > interact with devices by touch, and other peripherals. > The boost preemptive counts are marking the load > requirement urgent, vice versa. If such feedback > factor could be set to high level according to the > scenario, it would contribute to the power consumption > and UI response. > > If no USF sysfs inode is set, and no screen on or > off event, adjust_task_pred_demand shall not be invoked. > Once sched_usf_up_l0_r/down_r/non_ux_r be set, > adjust_task_pred_demand_impl shall be called back > to update settings according to high level scenario > identification. > > We can get about 17% mean power consumption save > at listening to music with speaker on "screen > off" scenario, as below statistical data from 7766 > XiaoMi devices for two weeks with > sched_usf_non_ux_r be set: > > day1 day2 day3 day4 > count 7766.00 7766.00 7766.00 7766.00 > mean88.03552585.50028283.82930586.054997 > std 111.049980 108.258834 107.562583 108.558240 > min 0.099000 0.037000 0.067000 0.045000 > 25% 34.76550034.02175034.10150034.423000 > 50% 54.9555.28650054.18950054.248500 > 75% 95.95400093.94200091.73800094.0592500 > 80% 114.675000 107.43 106.378000 108.673000 > 85% 137.851000 129.511000 127.156500 131.750750 > 90% 179.669000 170.208500 164.027000 172.348000 > 95% 272.395000 257.845500 247.750500 263.275750 > 98% 399.034500 412.170400 391.484000 402.835600 > > day5 day6day7 day8 > count 7766.00 7766.0 7766.00 7766.00 > mean82.53267779.2192377.61138081.075081 > std 104.870079 101.34819 103.140037 97.506221 > min 0.051000 0.02900 0.007000 0.068000 > 25% 32.87300033.4440031.96550033.863500 > 50% 52.18050051.5655050.80650053.08 > 75% 90.90575086.8262583.85925089.973000 > 80% 105.455000 99.6470097.271000104.225000 > 85% 128.30 118.47825 116.570250 126.648250 > 90% 166.647500 149.18000 150.649500 161.087000 > 95% 247.208500 224.36050 226.38 245.291250 > 98% 393.002000 347.92060 369.791800 378.778600 > > day9 day10day11day12 > count 7766.00 7766.00 7766.00 7766.00 > mean79.98917083.85941778.03293077.060542 > std 104.226122 108.893043 102.561715 99.844276 > min 0.118000 0.017000 0.028000 0.039000 > 25% 32.05625033.45450031.17625030.897750 > 50% 51.50600054.05600048.96950049.069000 > 75% 88.51350092.95350083.50675084.096000 > 80% 102.876000 107.845000 97.71700098.073000 > 85% 124.363000 128.288000 118.366500 116.869250 > 90% 160.557000 167.084000 154.342500 148.187500 > 95% 231.149000 242.925750 236.759000 228.131250 > 98% 367.206600 388.619100 385.269100 376.541600 > > day13day14 > count 7766.00 7766.00 > mean75.52803673.702878 > std 90.75059486.796016 > min 0.066000 0.054000 > 25% 31.17050031.608500 > 50% 48.75850049.215000 > 75% 84.52275083.053000 > 80% 97.87900094.875000 > 85% 116.680250 113.573750 > 90% 149.083500 144.089500 > 95% 226.177750 211.488750 > 98% 347.011100 331.317100 > > Signed-off-by: Dongdong Yang > Signed-off-by: Jun Tao > Signed-off-by: Qiwu Huang > Signed-off-by: Geliang Tang > Signed-off-by: Peng Wang > --- > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/fbsched/Kconfig | 10 ++ > drivers/staging/fbsched/Makefile | 2 + > drivers/staging/fbsched/usf.c| 351 > +++ > kernel/sched/cpufreq_schedutil.c | 11 +- > 6 files changed, 376 insertions(+), 1 deletion(-) > create mode 100644
[PATCH -next] media: staging: tegra-vde: Mark tegra_vde_runtime_suspend as __maybe_unused
If CONFIG_PM is not set, gcc warns:
drivers/staging/media/tegra-vde/vde.c:916:12:
warning: 'tegra_vde_runtime_suspend' defined but not used [-Wunused-function]
Make it __maybe_unused to fix this.
Signed-off-by: YueHaibing
---
drivers/staging/media/tegra-vde/vde.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/tegra-vde/vde.c
b/drivers/staging/media/tegra-vde/vde.c
index a3c24d96d5b9..2d043d518eef 100644
--- a/drivers/staging/media/tegra-vde/vde.c
+++ b/drivers/staging/media/tegra-vde/vde.c
@@ -913,7 +913,7 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
return IRQ_HANDLED;
}
-static int tegra_vde_runtime_suspend(struct device *dev)
+static __maybe_unused int tegra_vde_runtime_suspend(struct device *dev)
{
struct tegra_vde *vde = dev_get_drvdata(dev);
int err;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] Modernize tasklet callback API
Kees, > > [heavily trimmed CC list because I think lkml is ignoring this > thread...] > > On Thu, Jul 30, 2020 at 09:03:55AM +0200, Thomas Gleixner wrote: > > Kees, > > > > Kees Cook writes: > > > This is the infrastructure changes to prepare the tasklet API for > > > conversion to passing the tasklet struct as the callback argument instead > > > of an arbitrary unsigned long. The first patch details why this is useful > > > (it's the same rationale as the timer_struct changes from a bit ago: > > > less abuse during memory corruption attacks, more in line with existing > > > ways of doing things in the kernel, save a little space in struct, > > > etc). Notably, the existing tasklet API use is much less messy, so there > > > is less to clean up. > > > > > > It's not clear to me which tree this should go through... Greg since it > > > starts with a USB clean-up, -tip for timer or interrupt, or if I should > > > just carry it. I'm open to suggestions, but if I don't hear otherwise, > > > I'll just carry it. > > > > > > My goal is to have this merged for v5.9-rc1 so that during the v5.10 > > > development cycle the new API will be available. The entire tree of > > > changes is here[1] currently, but to split it up by maintainer the > > > infrastructure changes need to be landed first. > > > > > > Review and Acks appreciated! :) > > > > I'd rather see tasklets vanish from the planet completely, but that's > > going to be a daring feat. So, grudgingly: > > Understood! I will update the comments near the tasklet API. > > > Acked-by: Thomas Gleixner > Here's the series re-based on top of 5.8 https://github.com/allenpais/tasklets/tree/V3 Let me know how you would want these to be reviewed. Also, I was thinking if removing tasklets completely could be a task on KSPP wiki. If yes, I did like to take ownership of that task. I have a couple of ideas in mind, which could be discussed in a separate email. Thanks. -- - Allen ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
