* Re: [PATCH v5 13/29] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Dan Williams @ 2019-07-30 20:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexander Viro, linux-iio-u79uwXL29TY76Z2rM5mHXA, Daniel Vetter,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Bjorn Andersson,
sparclinux-u79uwXL29TY76Z2rM5mHXA, Mauro Carvalho Chehab,
linux-scsi, linux-nvdimm, linux-rdma,
qat-linux-ral2JQCrhuEAvxtiuMwx3w, amd-gfx list, Jason Gunthorpe,
linux-input-u79uwXL29TY76Z2rM5mHXA, Darren Hart,
Linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
moderated list:DMA BUFFER SHARING FRAMEWORK, Maling
In-Reply-To: <20190730195819.901457-1-arnd-r2nGTMty4D4@public.gmane.org>
On Tue, Jul 30, 2019 at 12:59 PM Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will never run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Acked-by: Jason Gunthorpe <jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Acked-by: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
> Acked-by: Mauro Carvalho Chehab <mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> Acked-by: David Sterba <dsterba-IBi9RG/b67k@public.gmane.org>
> Acked-by: Darren Hart (VMware) <dvhart-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Acked-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Acked-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> ---
> drivers/nvdimm/bus.c | 4 ++--
[..]
> diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
> index 798c5c4aea9c..6ca142d833ab 100644
> --- a/drivers/nvdimm/bus.c
> +++ b/drivers/nvdimm/bus.c
> @@ -1229,7 +1229,7 @@ static const struct file_operations nvdimm_bus_fops = {
> .owner = THIS_MODULE,
> .open = nd_open,
> .unlocked_ioctl = bus_ioctl,
> - .compat_ioctl = bus_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> @@ -1237,7 +1237,7 @@ static const struct file_operations nvdimm_fops = {
> .owner = THIS_MODULE,
> .open = nd_open,
> .unlocked_ioctl = dimm_ioctl,
> - .compat_ioctl = dimm_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
Acked-by: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v5 12/29] compat_ioctl: move drivers to compat_ptr_ioctl
From: David Miller @ 2019-07-30 21:43 UTC (permalink / raw)
To: arnd
Cc: viro, linux-fsdevel, linux-kernel, gregkh, mst, jarkko.sakkinen,
jgg, jkosina, stefanha, linux-integrity, linux1394-devel,
linux-usb, linux-input, linux-stm32, linux-arm-kernel, linux-mtd,
netdev, devel, kvm, virtualization, ceph-devel
In-Reply-To: <20190730195227.742215-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 30 Jul 2019 21:50:28 +0200
> Each of these drivers has a copy of the same trivial helper function to
> convert the pointer argument and then call the native ioctl handler.
>
> We now have a generic implementation of that, so use it.
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
> Reviewed-by: Jiri Kosina <jkosina@suse.cz>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I assume this has to go via your series, thus:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v5 12/29] compat_ioctl: move drivers to compat_ptr_ioctl
From: Cornelia Huck @ 2019-07-31 8:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexander Viro, devel, linux-input, kvm, Michael S . Tsirkin,
Greg Kroah-Hartman, linux-usb, netdev, linux-kernel,
Jarkko Sakkinen, virtualization, Jason Gunthorpe, linux-mtd,
Stefan Hajnoczi, Jiri Kosina, linux-fsdevel, ceph-devel,
linux-integrity, linux1394-devel, linux-stm32, linux-arm-kernel
In-Reply-To: <20190730195227.742215-1-arnd@arndb.de>
On Tue, 30 Jul 2019 21:50:28 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> Each of these drivers has a copy of the same trivial helper function to
> convert the pointer argument and then call the native ioctl handler.
>
> We now have a generic implementation of that, so use it.
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
> Reviewed-by: Jiri Kosina <jkosina@suse.cz>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/vfio/vfio.c | 39 +++----------------------------
vfio changes:
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Petr Vorel @ 2019-07-31 10:59 UTC (permalink / raw)
To: YueHaibing; +Cc: jikos, benjamin.tissoires, hdegoede, linux-kernel, linux-input
In-Reply-To: <20190725145719.8344-1-yuehaibing@huawei.com>
Hi,
> In delayedwork_callback(), logi_dj_recv_query_paired_devices
> may return positive value while success now, so check it
> correctly.
> Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Kind regards,
Petr
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Petr Vorel @ 2019-07-31 11:06 UTC (permalink / raw)
To: YueHaibing; +Cc: jikos, benjamin.tissoires, hdegoede, linux-kernel, linux-input
In-Reply-To: <20190731105927.GA5092@dell5510>
Hi,
> > In delayedwork_callback(), logi_dj_recv_query_paired_devices
> > may return positive value while success now, so check it
> > correctly.
> > Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices")
> > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
OK, not only it didn't fix problems with logitech mouse (see below),
but removing mouses USB dongle effectively crashes kernel, so this one probably
shouldn't be applied :).
[ 330.721629] logitech-djreceiver: probe of 0003:046D:C52F.0013 failed with error 7
[ 331.462335] hid 0003:046D:C52F.0013: delayedwork_callback: logi_dj_recv_query_paired_devices error: 7
Kind regards,
Petr
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Hans de Goede @ 2019-07-31 11:29 UTC (permalink / raw)
To: Petr Vorel, YueHaibing
Cc: jikos, benjamin.tissoires, linux-kernel, linux-input
In-Reply-To: <20190731110629.GB5092@dell5510>
Hi Petr,
On 31-07-19 13:06, Petr Vorel wrote:
> Hi,
>
>>> In delayedwork_callback(), logi_dj_recv_query_paired_devices
>>> may return positive value while success now, so check it
>>> correctly.
>
>>> Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices")
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> Reviewed-by: Petr Vorel <pvorel@suse.cz>
> OK, not only it didn't fix problems with logitech mouse (see below),
> but removing mouses USB dongle effectively crashes kernel, so this one probably
> shouldn't be applied :).
>
> [ 330.721629] logitech-djreceiver: probe of 0003:046D:C52F.0013 failed with error 7
> [ 331.462335] hid 0003:046D:C52F.0013: delayedwork_callback: logi_dj_recv_query_paired_devices error: 7
Please test my patch titled: "HID: logitech-dj: Really fix return value of logi_dj_recv_query_hidpp_devices"
which should fix this.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Yuehaibing @ 2019-07-31 11:41 UTC (permalink / raw)
To: Hans de Goede, Petr Vorel
Cc: jikos, benjamin.tissoires, linux-kernel, linux-input
In-Reply-To: <3e9bda5b-68dc-15b9-ca79-2e73567ea0a5@redhat.com>
On 2019/7/31 19:29, Hans de Goede wrote:
> Hi Petr,
>
> On 31-07-19 13:06, Petr Vorel wrote:
>> Hi,
>>
>>>> In delayedwork_callback(), logi_dj_recv_query_paired_devices
>>>> may return positive value while success now, so check it
>>>> correctly.
>>
>>>> Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices")
>>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>> Reviewed-by: Petr Vorel <pvorel@suse.cz>
>> OK, not only it didn't fix problems with logitech mouse (see below),
>> but removing mouses USB dongle effectively crashes kernel, so this one probably
>> shouldn't be applied :).
>>
>> [ 330.721629] logitech-djreceiver: probe of 0003:046D:C52F.0013 failed with error 7
>> [ 331.462335] hid 0003:046D:C52F.0013: delayedwork_callback: logi_dj_recv_query_paired_devices error: 7
>
> Please test my patch titled: "HID: logitech-dj: Really fix return value of logi_dj_recv_query_hidpp_devices"
> which should fix this.
Yes, this is better one, thanks!
>
> Regards,
>
> Hans
>
> .
>
^ permalink raw reply
* Re: [PATCH] HID: logitech-dj: Fix check of logi_dj_recv_query_paired_devices()
From: Petr Vorel @ 2019-07-31 11:46 UTC (permalink / raw)
To: Hans de Goede
Cc: YueHaibing, jikos, benjamin.tissoires, linux-kernel, linux-input
In-Reply-To: <3e9bda5b-68dc-15b9-ca79-2e73567ea0a5@redhat.com>
Hi Hans,
> Please test my patch titled: "HID: logitech-dj: Really fix return value of logi_dj_recv_query_hidpp_devices"
> which should fix this.
Indeed, patch [1] fixed that, thanks :)
> Regards,
> Hans
Kind regards,
Petr
[1] https://patchwork.kernel.org/patch/11064087/
^ permalink raw reply
* [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Greg Kroah-Hartman @ 2019-07-31 12:43 UTC (permalink / raw)
To: linux-kernel, Richard Gong, Dmitry Torokhov
Cc: linux-input, linux-fbdev, Florian Fainelli,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Sudeep Holla, x86,
dri-devel, platform-driver-x86, Tony Prisk, Andy Shevchenko,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Darren Hart,
Thomas Gleixner, Andy Shevchenko, linux-arm-kernel
This patch originally started out just as a way for platform drivers to
easily add a sysfs group in a race-free way, but thanks to Dmitry's
patch, this series now is for all drivers in the kernel (hey, a unified
driver model works!!!)
I've only converted a few platform drivers here in this series to show
how it works, but other busses can be converted after the first patch
goes into the tree.
Here's the original 00 message, for people to get an idea of what is
going on here:
If a platform driver wants to add a sysfs group, it has to do so in a
racy way, adding it after the driver is bound. To resolve this issue,
have the platform driver core do this for the driver, making the
individual drivers logic smaller and simpler, and solving the race at
the same time.
All of these patches depend on the first patch. I'll take the first one
through my driver-core tree, and any subsystem maintainer can either ack
their individul patch and I will be glad to also merge it, or they can
wait until after 5.4-rc1 when the core patch hits Linus's tree and then
take it, it's up to them.
Thank to Richard Gong for the idea and the testing of the platform
driver patch and to Dmitry Torokhov for rewriting the first patch to
work well for all busses.
-----
V2 - work for all busses and not just platform drivers.
Dmitry Torokhov (1):
driver core: add dev_groups to all drivers
Greg Kroah-Hartman (9):
uio: uio_fsl_elbc_gpcm: convert platform driver to use dev_groups
input: keyboard: gpio_keys: convert platform driver to use dev_groups
input: axp20x-pek: convert platform driver to use dev_groups
firmware: arm_scpi: convert platform driver to use dev_groups
olpc: x01: convert platform driver to use dev_groups
platform: x86: hp-wmi: convert platform driver to use dev_groups
video: fbdev: wm8505fb: convert platform driver to use dev_groups
video: fbdev: w100fb: convert platform driver to use dev_groups
video: fbdev: sm501fb: convert platform driver to use dev_groups
arch/x86/platform/olpc/olpc-xo1-sci.c | 17 ++++------
drivers/base/dd.c | 14 ++++++++
drivers/firmware/arm_scpi.c | 5 +--
drivers/input/keyboard/gpio_keys.c | 13 ++------
drivers/input/misc/axp20x-pek.c | 15 ++-------
drivers/platform/x86/hp-wmi.c | 47 +++++++--------------------
drivers/uio/uio_fsl_elbc_gpcm.c | 23 +++++--------
drivers/video/fbdev/sm501fb.c | 37 +++++----------------
drivers/video/fbdev/w100fb.c | 23 ++++++-------
drivers/video/fbdev/wm8505fb.c | 13 ++++----
include/linux/device.h | 3 ++
11 files changed, 76 insertions(+), 134 deletions(-)
--
2.22.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 04/10] input: axp20x-pek: convert platform driver to use dev_groups
From: Greg Kroah-Hartman @ 2019-07-31 12:43 UTC (permalink / raw)
To: linux-kernel, Richard Gong, Dmitry Torokhov
Cc: Greg Kroah-Hartman, Andy Shevchenko, Florian Fainelli,
linux-input
In-Reply-To: <20190731124349.4474-1-gregkh@linuxfoundation.org>
Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files. So take advantage of that
and do not register "by hand" a sysfs group of attributes.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/misc/axp20x-pek.c | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index debeeaeb8812..235925b28772 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -195,15 +195,12 @@ DEVICE_ATTR(startup, 0644, axp20x_show_attr_startup, axp20x_store_attr_startup);
DEVICE_ATTR(shutdown, 0644, axp20x_show_attr_shutdown,
axp20x_store_attr_shutdown);
-static struct attribute *axp20x_attributes[] = {
+static struct attribute *axp20x_attrs[] = {
&dev_attr_startup.attr,
&dev_attr_shutdown.attr,
NULL,
};
-
-static const struct attribute_group axp20x_attribute_group = {
- .attrs = axp20x_attributes,
-};
+ATTRIBUTE_GROUPS(axp20x);
static irqreturn_t axp20x_pek_irq(int irq, void *pwr)
{
@@ -356,13 +353,6 @@ static int axp20x_pek_probe(struct platform_device *pdev)
axp20x_pek->info = (struct axp20x_info *)match->driver_data;
- error = devm_device_add_group(&pdev->dev, &axp20x_attribute_group);
- if (error) {
- dev_err(&pdev->dev, "Failed to create sysfs attributes: %d\n",
- error);
- return error;
- }
-
platform_set_drvdata(pdev, axp20x_pek);
return 0;
@@ -411,6 +401,7 @@ static struct platform_driver axp20x_pek_driver = {
.driver = {
.name = "axp20x-pek",
.pm = &axp20x_pek_pm_ops,
+ .dev_groups = axp20x_groups,
},
};
module_platform_driver(axp20x_pek_driver);
--
2.22.0
^ permalink raw reply related
* Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Dmitry Torokhov @ 2019-07-31 13:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, Richard Gong, H. Peter Anvin, Andy Shevchenko,
Andy Shevchenko, Bartlomiej Zolnierkiewicz, Borislav Petkov,
Darren Hart, Florian Fainelli, Ingo Molnar, Sudeep Holla,
Thomas Gleixner, Tony Prisk, dri-devel, linux-arm-kernel,
linux-fbdev, linux-input, platform-driver-x86, x86
In-Reply-To: <20190731124349.4474-1-gregkh@linuxfoundation.org>
On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> This patch originally started out just as a way for platform drivers to
> easily add a sysfs group in a race-free way, but thanks to Dmitry's
> patch, this series now is for all drivers in the kernel (hey, a unified
> driver model works!!!)
>
> I've only converted a few platform drivers here in this series to show
> how it works, but other busses can be converted after the first patch
> goes into the tree.
>
> Here's the original 00 message, for people to get an idea of what is
> going on here:
>
> If a platform driver wants to add a sysfs group, it has to do so in a
> racy way, adding it after the driver is bound. To resolve this issue,
> have the platform driver core do this for the driver, making the
> individual drivers logic smaller and simpler, and solving the race at
> the same time.
>
> All of these patches depend on the first patch. I'll take the first one
> through my driver-core tree, and any subsystem maintainer can either ack
> their individul patch and I will be glad to also merge it, or they can
> wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> take it, it's up to them.
Maybe make an immutable branch off 5.2 with just patch 1/10 so that
subsystems (and the driver core tree itself) could pull it in at their
leisure into their "*-next" branches and did not have to wait till 5.4
or risk merge clashes?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Greg Kroah-Hartman @ 2019-07-31 13:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: x86, linux-input, linux-fbdev, Andy Shevchenko,
Bartlomiej Zolnierkiewicz, Sudeep Holla, linux-kernel, dri-devel,
platform-driver-x86, Tony Prisk, Andy Shevchenko,
Florian Fainelli, Borislav Petkov, H. Peter Anvin, Darren Hart,
Thomas Gleixner, Richard Gong, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20190731131045.GB147138@dtor-ws>
On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> >
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> >
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> >
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound. To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> >
> > All of these patches depend on the first patch. I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
>
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?
Good idea, I will do that when I apply it after a few days to give
people a chance to review it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Andy Shevchenko @ 2019-07-31 13:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Greg Kroah-Hartman, linux-kernel, Richard Gong, H. Peter Anvin,
Bartlomiej Zolnierkiewicz, Borislav Petkov, Darren Hart,
Florian Fainelli, Ingo Molnar, Sudeep Holla, Thomas Gleixner,
Tony Prisk, dri-devel, linux-arm-kernel, linux-fbdev, linux-input,
platform-driver-x86, x86
In-Reply-To: <20190731131045.GB147138@dtor-ws>
On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> >
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> >
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> >
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound. To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> >
> > All of these patches depend on the first patch. I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
>
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?
Isn't cherry-pick enough for one patch?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Dmitry Torokhov @ 2019-07-31 13:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, linux-kernel, Richard Gong, H. Peter Anvin,
Bartlomiej Zolnierkiewicz, Borislav Petkov, Darren Hart,
Florian Fainelli, Ingo Molnar, Sudeep Holla, Thomas Gleixner,
Tony Prisk, dri-devel, linux-arm-kernel, linux-fbdev, linux-input,
platform-driver-x86, x86
In-Reply-To: <20190731133840.GN23480@smile.fi.intel.com>
On Wed, Jul 31, 2019 at 04:38:40PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> > On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > > This patch originally started out just as a way for platform drivers to
> > > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > > patch, this series now is for all drivers in the kernel (hey, a unified
> > > driver model works!!!)
> > >
> > > I've only converted a few platform drivers here in this series to show
> > > how it works, but other busses can be converted after the first patch
> > > goes into the tree.
> > >
> > > Here's the original 00 message, for people to get an idea of what is
> > > going on here:
> > >
> > > If a platform driver wants to add a sysfs group, it has to do so in a
> > > racy way, adding it after the driver is bound. To resolve this issue,
> > > have the platform driver core do this for the driver, making the
> > > individual drivers logic smaller and simpler, and solving the race at
> > > the same time.
> > >
> > > All of these patches depend on the first patch. I'll take the first one
> > > through my driver-core tree, and any subsystem maintainer can either ack
> > > their individul patch and I will be glad to also merge it, or they can
> > > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > > take it, it's up to them.
> >
> > Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> > subsystems (and the driver core tree itself) could pull it in at their
> > leisure into their "*-next" branches and did not have to wait till 5.4
> > or risk merge clashes?
>
> Isn't cherry-pick enough for one patch?
With cherry-picking you run into potential merge conflicts if Greg
changes more code in the same area. Plus, once everything is merged into
Linus' tree, there will be N git commits adding the same thing.
With immutable branch there is a single git commit, so merges are
guaranteed to be clean, with no conflicts.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: applespi - Fix build error
From: Dmitry Torokhov @ 2019-07-31 13:49 UTC (permalink / raw)
To: YueHaibing; +Cc: ronald, nikolas, linux-kernel, linux-input
In-Reply-To: <20190730133414.49008-1-yuehaibing@huawei.com>
On Tue, Jul 30, 2019 at 09:34:14PM +0800, YueHaibing wrote:
> If CONFIG_KEYBOARD_APPLESPI=y but CONFIG_LEDS_CLASS=m
> building fails:
>
> drivers/input/keyboard/applespi.o: In function `applespi_probe':
> applespi.c:(.text+0x1fcd): undefined reference to `devm_led_classdev_register_ext'
>
> Add "depends on LEDS_CLASS" to the Konfig
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 038b1a05eae6 ("Input: add Apple SPI keyboard and trackpad driver")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thank you.
> ---
> v2: use 'depends on LEDS_CLASS'
> ---
> drivers/input/keyboard/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index ebb19e2..90e8a7f 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -76,6 +76,7 @@ config KEYBOARD_APPLESPI
> depends on ACPI && EFI
> depends on SPI
> depends on X86 || COMPILE_TEST
> + depends on LEDS_CLASS
> select CRC16
> help
> Say Y here if you are running Linux on any Apple MacBook8,1 or later,
> --
> 2.7.4
>
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] drivers: base: swnode: link devices to software nodes
From: Dmitry Torokhov @ 2019-07-31 13:54 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Heikki Krogerus, Linus Walleij, Enrico Weigelt, metux IT consult,
linux-input, linux-gpio, linux-kernel, Andy Shevchenko
In-Reply-To: <e36fb47b-2969-5f53-97d4-8e94b4c98283@intel.com>
On Tue, Jul 30, 2019 at 04:49:50PM +0200, Rafael J. Wysocki wrote:
> On 7/30/2019 1:52 PM, Heikki Krogerus wrote:
> > On Mon, Jul 29, 2019 at 03:15:32PM +0200, Dmitry Torokhov wrote:
> > > On Mon, Jul 29, 2019 at 03:07:15PM +0300, Heikki Krogerus wrote:
> > > > On Sat, Jul 13, 2019 at 12:52:58AM -0700, Dmitry Torokhov wrote:
> > > > > It is helpful to know what device, if any, a software node is tied to, so
> > > > > let's store a pointer to the device in software node structure. Note that
> > > > > children software nodes will inherit their parent's device pointer, so we
> > > > > do not have to traverse hierarchy to see what device the [sub]tree belongs
> > > > > to.
> > > > >
> > > > > We will be using the device pointer to locate GPIO lookup tables for
> > > > > devices with static properties.
> > > > >
> > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > > ---
> > > > > drivers/base/property.c | 1 +
> > > > > drivers/base/swnode.c | 35 ++++++++++++++++++++++++++++++++++-
> > > > > include/linux/property.h | 5 +++++
> > > > > 3 files changed, 40 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > > > index 348b37e64944..3bc93d4b35c4 100644
> > > > > --- a/drivers/base/property.c
> > > > > +++ b/drivers/base/property.c
> > > > > @@ -527,6 +527,7 @@ int device_add_properties(struct device *dev,
> > > > > if (IS_ERR(fwnode))
> > > > > return PTR_ERR(fwnode);
> > > > > + software_node_link_device(fwnode, dev);
> > > > > set_secondary_fwnode(dev, fwnode);
> > > > > return 0;
> > > > > }
> > > > > diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> > > > > index 7fc5a18e02ad..fd12eea539b6 100644
> > > > > --- a/drivers/base/swnode.c
> > > > > +++ b/drivers/base/swnode.c
> > > > > @@ -24,6 +24,9 @@ struct software_node {
> > > > > /* properties */
> > > > > const struct property_entry *properties;
> > > > > +
> > > > > + /* device this node is associated with */
> > > > > + struct device *dev;
> > > > > };
> > > > Let's not do that! The nodes can be, and in many cases are, associated
> > > > with multiple devices.
> > > They do? Where? I see that set of properties can be shared between
> > > several devices, but when we instantiate SW node we create a new
> > > instance for device. This is also how ACPI and OF properties work; they
> > > not shared between devices (or, rather, the kernel creates distinct _and
> > > single_ devices for instance of ACPI or OF node). I do not think we want
> > > swnodes work differently from the other firmware nodes.
> > Having multiple devices linked to a single node is quite normal. Most
> > multifunctional devices will share a single node. The USB port devices
> > will share their node (if they have one) with any device that is
> > attached to them. Etc.
> >
> > If you want to check how this works with ACPI, then find
> > "physical_node" named files from sysfs. The ACPI node folders in sysfs
> > have symlinks named "physical_node<n>" for every device they are bind
> > to. The first one is named just "physical_node", the second
> > "physical_node1", the third "physical_node2", and so on.
> >
> > > > Every device is already linked with the software node kobject, so
> > > > isn't it possible to simply walk trough those links in order to check
> > > > the devices associated with the node?
> > > No, we need to know the exact instance of a device, not a set of
> > > devices, because even though some properties can be shared, others can
> > > not. For example, even if 2 exactly same touch controllers in the system
> > > have "reset-gpios" property, they won't be the same GPIO for the both of
> > > them.
> > I don't think I completely understand the use case you had in mind for
> > this API, but since you planned to use it with the GPIO lookup tables,
> > I'm going to assume it's not needed after all. Let's replace those
> > with the references instead like I proposed in my reply to the 2/2
> > patch.
> >
> > Linking a single device with a node like that is in any case not
> > acceptable nor possible.
> >
> I think I need to withdraw my ACK here at this point.
OK, fair enough, I'll see if I can make the references that Heikki
mentioned work for me.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Enrico Weigelt, metux IT consult @ 2019-07-31 17:26 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Enrico Weigelt, metux IT consult, linux-kernel, linux-input
In-Reply-To: <20190729184306.GA767@penguin>
On 29.07.19 20:43, Dmitry Torokhov wrote:
Hi,
> https://patchwork.kernel.org/cover/11042915/
Thanks.
> I tried putting you on CC list there, did you not get them?
hmm, maybe it went to one of the dozens of mailboxes where I didn't
look at careful enough ... I'm currently just sorting by mailing list,
but don't separate out stuff that's directly addressed to me - guess
I'll have to fix up my mail filter rules :o
Regarding your patch:
How should I now setup a proper swnode object and pass it to the
driver ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
From: Christophe JAILLET @ 2019-08-01 7:47 UTC (permalink / raw)
To: jikos, benjamin.tissoires
Cc: linux-usb, linux-input, linux-kernel, kernel-janitors,
Christophe JAILLET
There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
here. These calls are done from probe functions and using GFP_KERNEL should
be safe.
The memory itself is used within some interrupts, but it is not a
problem, once it has been allocated.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/hid/usbhid/usbkbd.c | 4 ++--
drivers/hid/usbhid/usbmouse.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
index d5b7a696a68c..63e8ef8beb45 100644
--- a/drivers/hid/usbhid/usbkbd.c
+++ b/drivers/hid/usbhid/usbkbd.c
@@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
return -1;
if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
return -1;
- if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma)))
+ if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma)))
return -1;
if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
return -1;
- if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma)))
+ if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma)))
return -1;
return 0;
diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
index 073127e65ac1..c89332017d5d 100644
--- a/drivers/hid/usbhid/usbmouse.c
+++ b/drivers/hid/usbhid/usbmouse.c
@@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
if (!mouse || !input_dev)
goto fail1;
- mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma);
+ mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma);
if (!mouse->data)
goto fail1;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
From: walter harms @ 2019-08-01 10:06 UTC (permalink / raw)
To: Christophe JAILLET
Cc: jikos, benjamin.tissoires, linux-usb, linux-input, linux-kernel,
kernel-janitors
In-Reply-To: <20190801074759.32738-1-christophe.jaillet@wanadoo.fr>
Am 01.08.2019 09:47, schrieb Christophe JAILLET:
> There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
> here. These calls are done from probe functions and using GFP_KERNEL should
> be safe.
> The memory itself is used within some interrupts, but it is not a
> problem, once it has been allocated.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/hid/usbhid/usbkbd.c | 4 ++--
> drivers/hid/usbhid/usbmouse.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> index d5b7a696a68c..63e8ef8beb45 100644
> --- a/drivers/hid/usbhid/usbkbd.c
> +++ b/drivers/hid/usbhid/usbkbd.c
> @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
> return -1;
> if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
> return -1;
> - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma)))
> + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma)))
> return -1;
> if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
> return -1;
> - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma)))
> + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma)))
> return -1;
>
the kernel style is usually:
kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma);
if (!kbd->new)
return -1;
in usbmouse.c this is done, any reason for the change here ?
re,
wh
> return 0;
> diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
> index 073127e65ac1..c89332017d5d 100644
> --- a/drivers/hid/usbhid/usbmouse.c
> +++ b/drivers/hid/usbhid/usbmouse.c
> @@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
> if (!mouse || !input_dev)
> goto fail1;
>
> - mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma);
> + mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma);
> if (!mouse->data)
> goto fail1;
>
^ permalink raw reply
* Re: [PATCH v2] HID: input: fix a4tech horizontal wheel custom usage
From: Nicolas Saenz Julienne @ 2019-08-01 10:56 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: dmitry.torokhov, wbauer, linux-input, linux-kernel
In-Reply-To: <20190611121320.30267-1-nsaenzjulienne@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On Tue, 2019-06-11 at 14:13 +0200, Nicolas Saenz Julienne wrote:
> Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
> the previous wheel report was horizontal or vertical. Before
> c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> usage was being mapped to 'Relative.Misc'. After the patch it's simply
> ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
> hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
> usage->type.
>
> We shouldn't rely on a mapping for that usage as it's nonstandard and
> doesn't really map to an input event. So we bypass the mapping and make
> sure the custom event handling properly handles both reports.
>
> Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
It would be nice for this patch not to get lost. It fixes issues both repoted
on opensuse and fedora.
I can resubmit it if needed.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
From: Greg KH @ 2019-08-01 13:47 UTC (permalink / raw)
To: walter harms
Cc: Christophe JAILLET, jikos, benjamin.tissoires, linux-usb,
linux-input, linux-kernel, kernel-janitors
In-Reply-To: <5D42B98B.40900@bfs.de>
On Thu, Aug 01, 2019 at 12:06:03PM +0200, walter harms wrote:
>
>
> Am 01.08.2019 09:47, schrieb Christophe JAILLET:
> > There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
> > here. These calls are done from probe functions and using GFP_KERNEL should
> > be safe.
> > The memory itself is used within some interrupts, but it is not a
> > problem, once it has been allocated.
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > ---
> > drivers/hid/usbhid/usbkbd.c | 4 ++--
> > drivers/hid/usbhid/usbmouse.c | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> > index d5b7a696a68c..63e8ef8beb45 100644
> > --- a/drivers/hid/usbhid/usbkbd.c
> > +++ b/drivers/hid/usbhid/usbkbd.c
> > @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
> > return -1;
> > if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
> > return -1;
> > - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma)))
> > + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma)))
> > return -1;
> > if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
> > return -1;
> > - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma)))
> > + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma)))
> > return -1;
> >
>
> the kernel style is usually:
> kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma);
> if (!kbd->new)
> return -1;
>
>
> in usbmouse.c this is done, any reason for the change here ?
If you want to be extra-correct, don't return -1, return -ENOMEM.
thanks,
greg k-h
^ permalink raw reply
* KASAN: use-after-free Read in hiddev_release
From: syzbot @ 2019-08-01 15:28 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=147ac20c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=62a1e04fd3ec2abf099e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x302a/0x3b50
kernel/locking/lockdep.c:3753
Read of size 8 at addr ffff8881cf591a08 by task syz-executor.1/26260
CPU: 1 PID: 26260 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #24
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+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
__lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753
lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159
hiddev_release+0x82/0x520 drivers/hid/usbhid/hiddev.c:221
__fput+0x2d7/0x840 fs/file_table.c:280
task_work_run+0x13f/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x8ef/0x2c50 kernel/exit.c:878
do_group_exit+0x125/0x340 kernel/exit.c:982
get_signal+0x466/0x23d0 kernel/signal.c:2728
do_signal+0x88/0x14e0 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x1a2/0x200 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f75b2a6ccf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000075c078 RCX: 0000000000459829
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000000075c078
RBP: 000000000075c070 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000075c07c
R13: 00007ffcdfe1023f R14: 00007f75b2a6d9c0 R15: 000000000075c07c
Allocated by task 104:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
hiddev_connect+0x242/0x5b0 drivers/hid/usbhid/hiddev.c:900
hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
hid_hw_start drivers/hid/hid-core.c:1981 [inline]
hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
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/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Freed by task 104:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1470 [inline]
slab_free mm/slub.c:3012 [inline]
kfree+0xe4/0x2f0 mm/slub.c:3953
hiddev_connect.cold+0x45/0x5c drivers/hid/usbhid/hiddev.c:914
hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
hid_hw_start drivers/hid/hid-core.c:1981 [inline]
hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
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/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff8881cf591900
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 264 bytes inside of
512-byte region [ffff8881cf591900, ffff8881cf591b00)
The buggy address belongs to the page:
page:ffffea00073d6400 refcount:1 mapcount:0 mapping:ffff8881da002500
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 0000000000000000 0000000100000001 ffff8881da002500
raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881cf591900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881cf591980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881cf591a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881cf591a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881cf591b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Dmitry Torokhov @ 2019-08-01 23:49 UTC (permalink / raw)
To: Michal Vokáč
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <f06a913e-09aa-3225-a495-bb290ee2bb6f@ysoft.com>
On Tue, Jul 30, 2019 at 11:25:49AM +0200, Michal Vokáč wrote:
> On 27. 07. 19 9:31, Dmitry Torokhov wrote:
> > On Fri, Jul 26, 2019 at 01:31:31PM +0200, Michal Vokáč wrote:
> > > On 25. 07. 19 16:40, Dmitry Torokhov wrote:
> > > > On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
> > > > > On 25. 07. 19 10:57, Dmitry Torokhov wrote:
> > > > > > Hi Michal,
> > > > > >
> > > > > > On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
> > > > > > > On 21. 05. 19 7:37, Dmitry Torokhov wrote:
> > > > > > > > Hi Michal,
> > > > > > > >
> > > > > > > > On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I have to deal with a situation where we have a custom i.MX6 based
> > > > > > > > > platform in production that uses the MPR121 touchkey controller.
> > > > > > > > > Unfortunately the chip is connected using only the I2C interface.
> > > > > > > > > The interrupt line is not used. Back in 2015 (Linux v3.14), my
> > > > > > > > > colleague modded the existing mpr121_touchkey.c driver to use polling
> > > > > > > > > instead of interrupt.
> > > > > > > > >
> > > > > > > > > For quite some time yet I am in a process of updating the product from
> > > > > > > > > the ancient Freescale v3.14 kernel to the latest mainline and pushing
> > > > > > > > > any needed changes upstream. The DT files for our imx6dl-yapp4 platform
> > > > > > > > > already made it into v5.1-rc.
> > > > > > > > >
> > > > > > > > > I rebased and updated our mpr121 patch to the latest mainline.
> > > > > > > > > It is created as a separate driver, similarly to gpio_keys_polled.
> > > > > > > > >
> > > > > > > > > The I2C device is quite susceptible to ESD. An ESD test quite often
> > > > > > > > > causes reset of the chip or some register randomly changes its value.
> > > > > > > > > The [PATCH 3/4] adds a write-through register cache. With the cache
> > > > > > > > > this state can be detected and the device can be re-initialied.
> > > > > > > > >
> > > > > > > > > The main question is: Is there any chance that such a polled driver
> > > > > > > > > could be accepted? Is it correct to implement it as a separate driver
> > > > > > > > > or should it be done as an option in the existing driver? I can not
> > > > > > > > > really imagine how I would do that though..
> > > > > > > > >
> > > > > > > > > There are also certain worries that the MPR121 chip may no longer be
> > > > > > > > > available in nonspecifically distant future. In case of EOL I will need
> > > > > > > > > to add a polled driver for an other touchkey chip. May it be already
> > > > > > > > > in mainline or a completely new one.
> > > > > > > >
> > > > > > > > I think that my addition of input_polled_dev was ultimately a wrong
> > > > > > > > thing to do. I am looking into enabling polling mode for regular input
> > > > > > > > devices as we then can enable polling mode in existing drivers.
> > > > > > >
> > > > > > > OK, that sounds good. Especially when one needs to switch from one chip
> > > > > > > to another that is already in tree, the need for a whole new polling
> > > > > > > driver is eliminated.
> > > > > >
> > > > > > Could you please try the patch below and see if it works for your use
> > > > > > case? Note that I have not tried running it, but it compiles so it must
> > > > > > be good ;)
> > > > >
> > > > > Hi Dmitry,
> > > > > Thank you very much for the patch!
> > > > > I gave it a shot and it seems you forgot to add the input-poller.h file
> > > > > to the patch.. it does not compile on my side :(
> > > >
> > > > Oops ;) Please see the updated patch below.
> > >
> > > Thank you, now it is (almost) good as you said :D
> > >
> > > > >
> > > > > > Input: add support for polling to input devices
> > > > > >
> > > > > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > > >
> > > > > > Separating "normal" and "polled" input devices was a mistake, as often we want
> > > > > > to allow the very same device work on both interrupt-driven and polled mode,
> > > > > > depending on the board on which the device is used.
> > > > > >
> > > > > > This introduces new APIs:
> > > > > >
> > > > > > - input_setup_polling
> > > > > > - input_set_poll_interval
> > > > > > - input_set_min_poll_interval
> > > > > > - input_set_max_poll_interval
> > > > > >
> > > > > > These new APIs allow switching an input device into polled mode with sysfs
> > > > > > attributes matching drivers using input_polled_dev APIs that will be eventually
> > > > > > removed.
> > > > >
> > > > > After reading this I am not really sure what else needs to be done
> > > > > to test/use the poller. I suspect I need to modify the input device
> > > > > driver (mpr121_touchkey.c in my case) like this:
> > > > >
> > > > > If the interrupt gpio is not provided in DT, the device driver probe
> > > > > function should:
> > > > > - not request the threaded interrupt
> > > > > - call input_setup_polling and provide it with poll_fn
> > > > > Can the mpr_touchkey_interrupt function be used as is for this
> > > > > purpose? The only problem I see is it returns IRQ_HANDLED.
> > > >
> > > > I'd factor out code suitable for polling from mpr_touchkey_interrupt()
> > > > and then do
> > > >
> > > > static irqreturn_t mpr_touchkey_interrupt(...)
> > > > {
> > > > mpr_touchkey_report(...);
> > > > return IRQ_HANDLED;
> > > > }
> > > >
> > >
> > > Probably a trivial problem for experienced kernel hacker but I can not
> > > wrap my head around this - the interrupt handler takes the mpr121
> > > device id as an argument while the poller poll_fn takes struct input_dev.
> > >
> > > I fail to figure out how to get the device id from the input device.
> > >
> Thanks for the hints Dmitry. I am trying my best but still have some
> issues with the input_set/get_drvdata.
>
> The kernel Oopses on NULL pointer dereference in mpr_touchkey_report.
> Here is the backtrace:
>
> [ 2.916960] 8<--- cut here ---
> [ 2.920022] Unable to handle kernel NULL pointer dereference at virtual address 000001d0
> [ 2.928138] pgd = (ptrval)
Ah, that's my fault I believe. Can you please try sticking
poller->input = dev;
into input_setup_polling()?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
From: Christophe JAILLET @ 2019-08-02 7:51 UTC (permalink / raw)
To: wharms
Cc: jikos, benjamin.tissoires, linux-usb, linux-input, linux-kernel,
kernel-janitors
In-Reply-To: <5D42B98B.40900@bfs.de>
Hi, (and sorry if you receive this email twice. I've used a web mail
which sends HTML by default and it was rejected by ML)
Le 01/08/2019 à 12:06, walter harms a écrit :
>
>
> Am 01.08.2019 09:47, schrieb Christophe JAILLET:
>> There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
>> here. These calls are done from probe functions and using GFP_KERNEL should
>> be safe.
>> The memory itself is used within some interrupts, but it is not a
>> problem, once it has been allocated.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> drivers/hid/usbhid/usbkbd.c | 4 ++--
>> drivers/hid/usbhid/usbmouse.c | 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
>> index d5b7a696a68c..63e8ef8beb45 100644
>> --- a/drivers/hid/usbhid/usbkbd.c
>> +++ b/drivers/hid/usbhid/usbkbd.c
>> @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
>> return -1;
>> if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
>> return -1;
>> - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma)))
>> + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma)))
>> return -1;
>> if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL)))
>> return -1;
>> - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma)))
>> + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma)))
>> return -1;
>>
>
> the kernel style is usually:
> kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma);
> if (!kbd->new)
> return -1;
>
Searching with coccinelle with:
* x = usb_alloc_coherent(..., <+... GFP_KERNEL ...+>, ...);
finds 67 files,
whereas:
* x = usb_alloc_coherent(..., <+... GFP_ATOMIC ...+>, ...);
only finds 11 files.
>
> in usbmouse.c this is done, any reason for the change here ?
>
No real reason in fact, just to be consistent with surrounding code.
Unless some allocations are done within a spin_lock/spin_unlock, using
both GFP_KERNEL and GFP_ATOMIC in the same function looks spurious to me.
Either there is a bug (GFP_KERNEL should be GFP_ATOMIC), or a useless
constraint is given to the memory allocator.
CJ
> re,
> wh
>
>> return 0;
>> diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
>> index 073127e65ac1..c89332017d5d 100644
>> --- a/drivers/hid/usbhid/usbmouse.c
>> +++ b/drivers/hid/usbhid/usbmouse.c
>> @@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
>> if (!mouse || !input_dev)
>> goto fail1;
>>
>> - mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma);
>> + mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma);
>> if (!mouse->data)
>> goto fail1;
>>
>
^ permalink raw reply
* Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Greg Kroah-Hartman @ 2019-08-02 10:46 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: x86, linux-input, linux-fbdev, Andy Shevchenko,
Bartlomiej Zolnierkiewicz, Sudeep Holla, linux-kernel, dri-devel,
platform-driver-x86, Tony Prisk, Andy Shevchenko,
Florian Fainelli, Borislav Petkov, H. Peter Anvin, Darren Hart,
Thomas Gleixner, Richard Gong, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20190731131045.GB147138@dtor-ws>
On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> >
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> >
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> >
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound. To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> >
> > All of these patches depend on the first patch. I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
>
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?
I have now done this with patch 1/10. Here's the pull info if any
subsystem maintainer wants to suck this into their tree to provide the
ability for drivers to add/remove attribute groups easily.
This is part of my driver-core tree now, and will go to Linus for
5.4-rc1, along with a few platform drivers that have been acked by their
various subsystem maintainers that convert them to use this new
functionality.
If anyone has any questions about this, please let me know.
thanks,
greg k-h
-------------------
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/dev_groups_all_drivers
for you to fetch changes up to 23b6904442d08b7dbed7622ed33b236d41a3aa8b:
driver core: add dev_groups to all drivers (2019-08-02 12:37:53 +0200)
----------------------------------------------------------------
dev_groups added to struct driver
Persistent tag for others to pull this branch from
This is the first patch in a longer series that adds the ability for the
driver core to create and remove a list of attribute groups
automatically when the device is bound/unbound from a specific driver.
See:
https://lore.kernel.org/r/20190731124349.4474-2-gregkh@linuxfoundation.org
for details on this patch, and examples of how to use it in other
drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Dmitry Torokhov (1):
driver core: add dev_groups to all drivers
drivers/base/dd.c | 14 ++++++++++++++
include/linux/device.h | 3 +++
2 files changed, 17 insertions(+)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox