* Re: [PATCH] input: tablet: aiptek: Replace GFP_ATOMIC with GFP_KERNEL in aiptek_probe()
From: Dmitry Torokhov @ 2018-07-27 18:35 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: linux-input, linux-kernel
In-Reply-To: <20180727022920.1233-1-baijiaju1990@gmail.com>
On Fri, Jul 27, 2018 at 10:29:20AM +0800, Jia-Ju Bai wrote:
> aiptek_probe() is never called in atomic context.
> It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
> GFP_ATOMIC can be replaced with GFP_KERNEL.
>
> This is found by a static analysis tool named DCNS written by myself.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Applied, thank you.
> ---
> drivers/input/tablet/aiptek.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/tablet/aiptek.c b/drivers/input/tablet/aiptek.c
> index 545fa6e89035..c82cd5079d0e 100644
> --- a/drivers/input/tablet/aiptek.c
> +++ b/drivers/input/tablet/aiptek.c
> @@ -1712,7 +1712,7 @@ aiptek_probe(struct usb_interface *intf, const struct usb_device_id *id)
> }
>
> aiptek->data = usb_alloc_coherent(usbdev, AIPTEK_PACKET_LENGTH,
> - GFP_ATOMIC, &aiptek->data_dma);
> + GFP_KERNEL, &aiptek->data_dma);
> if (!aiptek->data) {
> dev_warn(&intf->dev, "cannot allocate usb buffer\n");
> goto fail1;
> --
> 2.17.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: misc: powermate: Replace GFP_ATOMIC with GFP_KERNEL in powermate_alloc_buffers()
From: Dmitry Torokhov @ 2018-07-27 18:33 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: arvind.yadav.cs, linux-input, linux-kernel
In-Reply-To: <20180727021723.709-1-baijiaju1990@gmail.com>
On Fri, Jul 27, 2018 at 10:17:23AM +0800, Jia-Ju Bai wrote:
> powermate_alloc_buffers() is never called in atomic context.
> It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
> GFP_ATOMIC can be replaced with GFP_KERNEL.
>
> This is found by a static analysis tool named DCNS written by myself.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Applied, thank you.
> ---
> drivers/input/misc/powermate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/powermate.c b/drivers/input/misc/powermate.c
> index 5c8c79623c87..e8de3aaf9f63 100644
> --- a/drivers/input/misc/powermate.c
> +++ b/drivers/input/misc/powermate.c
> @@ -277,7 +277,7 @@ static int powermate_input_event(struct input_dev *dev, unsigned int type, unsig
> static int powermate_alloc_buffers(struct usb_device *udev, struct powermate_device *pm)
> {
> pm->data = usb_alloc_coherent(udev, POWERMATE_PAYLOAD_SIZE_MAX,
> - GFP_ATOMIC, &pm->data_dma);
> + GFP_KERNEL, &pm->data_dma);
> if (!pm->data)
> return -1;
>
> --
> 2.17.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: misc: keyspan_remote: Replace GFP_ATOMIC with GFP_KERNEL in keyspan_probe()
From: Dmitry Torokhov @ 2018-07-27 18:33 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: arvind.yadav.cs, gregkh, pombredanne, linux-input, linux-kernel
In-Reply-To: <20180727021258.29675-1-baijiaju1990@gmail.com>
On Fri, Jul 27, 2018 at 10:12:58AM +0800, Jia-Ju Bai wrote:
> keyspan_probe() is never called in atomic context.
> It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
> GFP_ATOMIC can be replace with GFP_KERNEL.
>
> This is found by a static analysis tool named DCNS written by myself.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Applied, thank you.
> ---
> drivers/input/misc/keyspan_remote.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/keyspan_remote.c b/drivers/input/misc/keyspan_remote.c
> index 67482b248b2d..a8937ceac66a 100644
> --- a/drivers/input/misc/keyspan_remote.c
> +++ b/drivers/input/misc/keyspan_remote.c
> @@ -466,7 +466,7 @@ static int keyspan_probe(struct usb_interface *interface, const struct usb_devic
> remote->in_endpoint = endpoint;
> remote->toggle = -1; /* Set to -1 so we will always not match the toggle from the first remote message. */
>
> - remote->in_buffer = usb_alloc_coherent(udev, RECV_SIZE, GFP_ATOMIC, &remote->in_dma);
> + remote->in_buffer = usb_alloc_coherent(udev, RECV_SIZE, GFP_KERNEL, &remote->in_dma);
> if (!remote->in_buffer) {
> error = -ENOMEM;
> goto fail1;
> --
> 2.17.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: touchscreen: wdt87xx_i2c: Replace mdelay() with msleep() in wdt87xx_resume()
From: Dmitry Torokhov @ 2018-07-27 18:30 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: rydberg, gregkh, andi, linux-input, linux-kernel
In-Reply-To: <20180727023216.1467-1-baijiaju1990@gmail.com>
On Fri, Jul 27, 2018 at 10:32:16AM +0800, Jia-Ju Bai wrote:
> wdt87xx_resume() is never called in atomic context.
> It calls mdelay() to busily wait, which is not necessary.
> mdelay() can be replaced with msleep().
>
> This is found by a static analysis tool named DCNS written by myself.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Applied, thank you.
> ---
> drivers/input/touchscreen/wdt87xx_i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/wdt87xx_i2c.c b/drivers/input/touchscreen/wdt87xx_i2c.c
> index 20f7f3902757..166edeb77776 100644
> --- a/drivers/input/touchscreen/wdt87xx_i2c.c
> +++ b/drivers/input/touchscreen/wdt87xx_i2c.c
> @@ -1142,7 +1142,7 @@ static int __maybe_unused wdt87xx_resume(struct device *dev)
> * The chip may have been reset while system is resuming,
> * give it some time to settle.
> */
> - mdelay(100);
> + msleep(100);
>
> error = wdt87xx_send_command(client, VND_CMD_START, 0);
> if (error)
> --
> 2.17.0
>
--
Dmitry
^ permalink raw reply
* [PATCH] input: touchscreen: wdt87xx_i2c: Replace mdelay() with msleep() in wdt87xx_resume()
From: Jia-Ju Bai @ 2018-07-27 2:32 UTC (permalink / raw)
To: dmitry.torokhov, rydberg, gregkh, andi
Cc: linux-input, linux-kernel, Jia-Ju Bai
wdt87xx_resume() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/input/touchscreen/wdt87xx_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/wdt87xx_i2c.c b/drivers/input/touchscreen/wdt87xx_i2c.c
index 20f7f3902757..166edeb77776 100644
--- a/drivers/input/touchscreen/wdt87xx_i2c.c
+++ b/drivers/input/touchscreen/wdt87xx_i2c.c
@@ -1142,7 +1142,7 @@ static int __maybe_unused wdt87xx_resume(struct device *dev)
* The chip may have been reset while system is resuming,
* give it some time to settle.
*/
- mdelay(100);
+ msleep(100);
error = wdt87xx_send_command(client, VND_CMD_START, 0);
if (error)
--
2.17.0
^ permalink raw reply related
* [PATCH] input: tablet: aiptek: Replace GFP_ATOMIC with GFP_KERNEL in aiptek_probe()
From: Jia-Ju Bai @ 2018-07-27 2:29 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Jia-Ju Bai
aiptek_probe() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/input/tablet/aiptek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/tablet/aiptek.c b/drivers/input/tablet/aiptek.c
index 545fa6e89035..c82cd5079d0e 100644
--- a/drivers/input/tablet/aiptek.c
+++ b/drivers/input/tablet/aiptek.c
@@ -1712,7 +1712,7 @@ aiptek_probe(struct usb_interface *intf, const struct usb_device_id *id)
}
aiptek->data = usb_alloc_coherent(usbdev, AIPTEK_PACKET_LENGTH,
- GFP_ATOMIC, &aiptek->data_dma);
+ GFP_KERNEL, &aiptek->data_dma);
if (!aiptek->data) {
dev_warn(&intf->dev, "cannot allocate usb buffer\n");
goto fail1;
--
2.17.0
^ permalink raw reply related
* [PATCH] input: mouse: appletouch: Replace GFP_ATOMIC with GFP_KERNEL
From: Jia-Ju Bai @ 2018-07-27 2:26 UTC (permalink / raw)
To: dmitry.torokhov, gustavo, arvind.yadav.cs
Cc: linux-input, linux-kernel, Jia-Ju Bai
atp_open(), atp_recover() and atp_resume() are never
called in atomic context.
They call usb_submit_urb() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/input/mouse/appletouch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index 032d27983b6c..f593ec96c95f 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -810,7 +810,7 @@ static int atp_open(struct input_dev *input)
{
struct atp *dev = input_get_drvdata(input);
- if (usb_submit_urb(dev->urb, GFP_ATOMIC))
+ if (usb_submit_urb(dev->urb, GFP_KERNEL))
return -EIO;
dev->open = true;
@@ -976,7 +976,7 @@ static int atp_recover(struct atp *dev)
if (error)
return error;
- if (dev->open && usb_submit_urb(dev->urb, GFP_ATOMIC))
+ if (dev->open && usb_submit_urb(dev->urb, GFP_KERNEL))
return -EIO;
return 0;
@@ -994,7 +994,7 @@ static int atp_resume(struct usb_interface *iface)
{
struct atp *dev = usb_get_intfdata(iface);
- if (dev->open && usb_submit_urb(dev->urb, GFP_ATOMIC))
+ if (dev->open && usb_submit_urb(dev->urb, GFP_KERNEL))
return -EIO;
return 0;
--
2.17.0
^ permalink raw reply related
* [PATCH] input: misc: yealink: Replace GFP_ATOMIC with GFP_KERNEL in usb_probe()
From: Jia-Ju Bai @ 2018-07-27 2:20 UTC (permalink / raw)
To: Henk.Vergonet, dmitry.torokhov
Cc: usbb2k-api-dev, linux-input, linux-kernel, Jia-Ju Bai
usb_probe() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/input/misc/yealink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index f0c9bf87b4e3..1365cd94ed9b 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -894,12 +894,12 @@ static int usb_probe(struct usb_interface *intf, const struct usb_device_id *id)
/* allocate usb buffers */
yld->irq_data = usb_alloc_coherent(udev, USB_PKT_LEN,
- GFP_ATOMIC, &yld->irq_dma);
+ GFP_KERNEL, &yld->irq_dma);
if (yld->irq_data == NULL)
return usb_cleanup(yld, -ENOMEM);
yld->ctl_data = usb_alloc_coherent(udev, USB_PKT_LEN,
- GFP_ATOMIC, &yld->ctl_dma);
+ GFP_KERNEL, &yld->ctl_dma);
if (!yld->ctl_data)
return usb_cleanup(yld, -ENOMEM);
--
2.17.0
^ permalink raw reply related
* [PATCH] input: misc: powermate: Replace GFP_ATOMIC with GFP_KERNEL in powermate_alloc_buffers()
From: Jia-Ju Bai @ 2018-07-27 2:17 UTC (permalink / raw)
To: dmitry.torokhov, arvind.yadav.cs; +Cc: linux-input, linux-kernel, Jia-Ju Bai
powermate_alloc_buffers() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/input/misc/powermate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/misc/powermate.c b/drivers/input/misc/powermate.c
index 5c8c79623c87..e8de3aaf9f63 100644
--- a/drivers/input/misc/powermate.c
+++ b/drivers/input/misc/powermate.c
@@ -277,7 +277,7 @@ static int powermate_input_event(struct input_dev *dev, unsigned int type, unsig
static int powermate_alloc_buffers(struct usb_device *udev, struct powermate_device *pm)
{
pm->data = usb_alloc_coherent(udev, POWERMATE_PAYLOAD_SIZE_MAX,
- GFP_ATOMIC, &pm->data_dma);
+ GFP_KERNEL, &pm->data_dma);
if (!pm->data)
return -1;
--
2.17.0
^ permalink raw reply related
* [PATCH] input: misc: keyspan_remote: Replace GFP_ATOMIC with GFP_KERNEL in keyspan_probe()
From: Jia-Ju Bai @ 2018-07-27 2:12 UTC (permalink / raw)
To: dmitry.torokhov, arvind.yadav.cs, gregkh, pombredanne
Cc: linux-input, linux-kernel, Jia-Ju Bai
keyspan_probe() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replace with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/input/misc/keyspan_remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/misc/keyspan_remote.c b/drivers/input/misc/keyspan_remote.c
index 67482b248b2d..a8937ceac66a 100644
--- a/drivers/input/misc/keyspan_remote.c
+++ b/drivers/input/misc/keyspan_remote.c
@@ -466,7 +466,7 @@ static int keyspan_probe(struct usb_interface *interface, const struct usb_devic
remote->in_endpoint = endpoint;
remote->toggle = -1; /* Set to -1 so we will always not match the toggle from the first remote message. */
- remote->in_buffer = usb_alloc_coherent(udev, RECV_SIZE, GFP_ATOMIC, &remote->in_dma);
+ remote->in_buffer = usb_alloc_coherent(udev, RECV_SIZE, GFP_KERNEL, &remote->in_dma);
if (!remote->in_buffer) {
error = -ENOMEM;
goto fail1;
--
2.17.0
^ permalink raw reply related
* [git pull] Input updates for v4.18-rc6
From: Dmitry Torokhov @ 2018-07-27 0:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem:
- a couple of new device IDs added to Elan i2c touchpad controller
driver
- another entry in i8042 reset quirk list.
Changelog:
---------
Chen-Yu Tsai (1):
Input: i8042 - add Lenovo LaVie Z to the i8042 reset list
Donald Shanty III (1):
Input: elan_i2c - add ACPI ID for lenovo ideapad 330
Geert Uytterhoeven (1):
MAINTAINERS: Add file patterns for serio device tree bindings
KT Liao (1):
Input: elan_i2c - add another ACPI ID for Lenovo Ideapad 330-15AST
Diffstat:
--------
MAINTAINERS | 1 +
drivers/input/mouse/elan_i2c_core.c | 2 ++
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
3 files changed, 10 insertions(+)
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Baoquan He @ 2018-07-26 15:10 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree
In-Reply-To: <20180726140152.GM28386@dhcp22.suse.cz>
On 07/26/18 at 04:01pm, Michal Hocko wrote:
> On Thu 26-07-18 21:37:05, Baoquan He wrote:
> > On 07/26/18 at 03:14pm, Michal Hocko wrote:
> > > On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > > > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > > > > have this worry.
> > > > > > > >
> > > > > > > > I do not have the full context here but let me note that you should be
> > > > > > > > careful when doing top-down reservation because you can easily get into
> > > > > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > > > > this is done. See memblock_find_in_range_node
> > > > > > >
> > > > > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > > > > the @buf stores the user space buffer address, @mem stores the position
> > > > > > > where kernel/initrd will be put. In kernel, it calls
> > > > > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > > > > @mem we searched in the whole system RAM might be lost along with
> > > > > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > > > > detected.
> > > > > >
> > > > > > I am not sure I am following. If @mem is placed at movable node then the
> > > > > > memory hotremove simply won't work, because we are seeing reserved pages
> > > > > > and do not know what to do about them. They are not migrateable.
> > > > > > Allocating intermediate pages from other nodes doesn't really help.
> > > > >
> > > > > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > > > > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > > > > is at top of system RAM and the top RAM is in movable node.
> > > >
> > > > It will affect the 1st kernel (which does the memblock allocation
> > > > top-down) as well. For reasons mentioned above.
> > >
> > > And btw. in the ideal world, we would restrict the memblock allocation
> > > top-down from the non-movable nodes. But I do not think we have that
> > > information ready at the time when the reservation is done.
> >
> > Oh, you could mix kexec loading up with kdump kernel loading. For kdump
> > kernel, we need reserve memory region during bootup with memblock
> > allocator. For kexec loading, we just operate after system up, and do
> > not need to reserve any memmory region. About memory used to load them,
> > it's quite different way.
>
> I didn't know about that. I thought both use the same underlying
> reservation mechanism. My bad and sorry for the noise.
Not at all. It's truly confusing. I often need take time to recall those
details.
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 14:01 UTC (permalink / raw)
To: Baoquan He
Cc: nicolas.pitre, brijesh.singh, devicetree, airlied, linux-pci,
richard.weiyang, keith.busch, jcmvbkbc, baiyaowei, frowand.list,
dan.j.williams, lorenzo.pieralisi, sthemmin, linux-nvdimm,
patrik.r.jakobsson, andy.shevchenko, linux-input, gustavo, bp,
dyoung, vgoyal, thomas.lendacky, haiyangz, maarten.lankhorst,
josh, jglisse, robh+dt, seanpaul, bhelgaas, tglx, yinghai,
jonathan.derrick, chris, monstr, linux-parisc, gregkh,
dmitry.torokhov
In-Reply-To: <20180726133705.GM6480@MiWiFi-R3L-srv>
On Thu 26-07-18 21:37:05, Baoquan He wrote:
> On 07/26/18 at 03:14pm, Michal Hocko wrote:
> > On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > > > have this worry.
> > > > > > >
> > > > > > > I do not have the full context here but let me note that you should be
> > > > > > > careful when doing top-down reservation because you can easily get into
> > > > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > > > this is done. See memblock_find_in_range_node
> > > > > >
> > > > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > > > the @buf stores the user space buffer address, @mem stores the position
> > > > > > where kernel/initrd will be put. In kernel, it calls
> > > > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > > > @mem we searched in the whole system RAM might be lost along with
> > > > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > > > detected.
> > > > >
> > > > > I am not sure I am following. If @mem is placed at movable node then the
> > > > > memory hotremove simply won't work, because we are seeing reserved pages
> > > > > and do not know what to do about them. They are not migrateable.
> > > > > Allocating intermediate pages from other nodes doesn't really help.
> > > >
> > > > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > > > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > > > is at top of system RAM and the top RAM is in movable node.
> > >
> > > It will affect the 1st kernel (which does the memblock allocation
> > > top-down) as well. For reasons mentioned above.
> >
> > And btw. in the ideal world, we would restrict the memblock allocation
> > top-down from the non-movable nodes. But I do not think we have that
> > information ready at the time when the reservation is done.
>
> Oh, you could mix kexec loading up with kdump kernel loading. For kdump
> kernel, we need reserve memory region during bootup with memblock
> allocator. For kexec loading, we just operate after system up, and do
> not need to reserve any memmory region. About memory used to load them,
> it's quite different way.
I didn't know about that. I thought both use the same underlying
reservation mechanism. My bad and sorry for the noise.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Baoquan He @ 2018-07-26 13:37 UTC (permalink / raw)
To: Michal Hocko
Cc: nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A, brijesh.singh-5C7GfCeVMHo,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w,
jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w,
baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/,
kys-0li6OtcxBFHby3iVrkZq2A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
lorenzo.pieralisi-5wv7dgnIgG8, sthemmin-0li6OtcxBFHby3iVrkZq2A,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
patrik.r.jakobsson-Re5JQEeQqe8AvxtiuMwx3w,
andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w,
linux-input-u79uwXL29TY76Z2rM5mHXA,
gustavo-THi1TnShQwVAfugRpC6u6w, bp-l3A5Bk7waGM,
dyoung-H+wXaHxf7aLQT0dZR+AlfA, thomas.lendacky-5C7GfCeVMHo,
haiyangz-0li6OtcxBFHby3iVrkZq2A,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
josh-iaAMLnmF4UmaiuxdJuQwMA, jglisse-H+wXaHxf7aLQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, tglx-hfZtesqFncYOwBW4kG4KsQ,
yinghai-DgEjT+Ai2ygdnm+yROfE0A,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
chris-YvXeqwSYzG2sTnJN9+BGXg, monstr-pSz03upnqPeHXe+LvDLADg,
linux-parisc-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel
In-Reply-To: <20180726131420.GJ28386-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On 07/26/18 at 03:14pm, Michal Hocko wrote:
> On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > > have this worry.
> > > > > >
> > > > > > I do not have the full context here but let me note that you should be
> > > > > > careful when doing top-down reservation because you can easily get into
> > > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > > this is done. See memblock_find_in_range_node
> > > > >
> > > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > > the @buf stores the user space buffer address, @mem stores the position
> > > > > where kernel/initrd will be put. In kernel, it calls
> > > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > > @mem we searched in the whole system RAM might be lost along with
> > > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > > detected.
> > > >
> > > > I am not sure I am following. If @mem is placed at movable node then the
> > > > memory hotremove simply won't work, because we are seeing reserved pages
> > > > and do not know what to do about them. They are not migrateable.
> > > > Allocating intermediate pages from other nodes doesn't really help.
> > >
> > > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > > is at top of system RAM and the top RAM is in movable node.
> >
> > It will affect the 1st kernel (which does the memblock allocation
> > top-down) as well. For reasons mentioned above.
>
> And btw. in the ideal world, we would restrict the memblock allocation
> top-down from the non-movable nodes. But I do not think we have that
> information ready at the time when the reservation is done.
Oh, you could mix kexec loading up with kdump kernel loading. For kdump
kernel, we need reserve memory region during bootup with memblock
allocator. For kexec loading, we just operate after system up, and do
not need to reserve any memmory region. About memory used to load them,
it's quite different way.
Thanks
Baoquan
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 13:14 UTC (permalink / raw)
To: Baoquan He
Cc: nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A, brijesh.singh-5C7GfCeVMHo,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w,
jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w,
baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/,
kys-0li6OtcxBFHby3iVrkZq2A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
lorenzo.pieralisi-5wv7dgnIgG8, sthemmin-0li6OtcxBFHby3iVrkZq2A,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
patrik.r.jakobsson-Re5JQEeQqe8AvxtiuMwx3w,
andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w,
linux-input-u79uwXL29TY76Z2rM5mHXA,
gustavo-THi1TnShQwVAfugRpC6u6w, bp-l3A5Bk7waGM,
dyoung-H+wXaHxf7aLQT0dZR+AlfA, thomas.lendacky-5C7GfCeVMHo,
haiyangz-0li6OtcxBFHby3iVrkZq2A,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
josh-iaAMLnmF4UmaiuxdJuQwMA, jglisse-H+wXaHxf7aLQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, tglx-hfZtesqFncYOwBW4kG4KsQ,
yinghai-DgEjT+Ai2ygdnm+yROfE0A,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
chris-YvXeqwSYzG2sTnJN9+BGXg, monstr-pSz03upnqPeHXe+LvDLADg,
linux-parisc-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel
In-Reply-To: <20180726131242.GI28386-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > have this worry.
> > > > >
> > > > > I do not have the full context here but let me note that you should be
> > > > > careful when doing top-down reservation because you can easily get into
> > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > this is done. See memblock_find_in_range_node
> > > >
> > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > the @buf stores the user space buffer address, @mem stores the position
> > > > where kernel/initrd will be put. In kernel, it calls
> > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > @mem we searched in the whole system RAM might be lost along with
> > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > detected.
> > >
> > > I am not sure I am following. If @mem is placed at movable node then the
> > > memory hotremove simply won't work, because we are seeing reserved pages
> > > and do not know what to do about them. They are not migrateable.
> > > Allocating intermediate pages from other nodes doesn't really help.
> >
> > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > is at top of system RAM and the top RAM is in movable node.
>
> It will affect the 1st kernel (which does the memblock allocation
> top-down) as well. For reasons mentioned above.
And btw. in the ideal world, we would restrict the memblock allocation
top-down from the non-movable nodes. But I do not think we have that
information ready at the time when the reservation is done.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 13:12 UTC (permalink / raw)
To: Baoquan He
Cc: nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A, brijesh.singh-5C7GfCeVMHo,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w,
jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w,
baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/,
kys-0li6OtcxBFHby3iVrkZq2A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
lorenzo.pieralisi-5wv7dgnIgG8, sthemmin-0li6OtcxBFHby3iVrkZq2A,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
patrik.r.jakobsson-Re5JQEeQqe8AvxtiuMwx3w,
andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w,
linux-input-u79uwXL29TY76Z2rM5mHXA,
gustavo-THi1TnShQwVAfugRpC6u6w, bp-l3A5Bk7waGM,
dyoung-H+wXaHxf7aLQT0dZR+AlfA, thomas.lendacky-5C7GfCeVMHo,
haiyangz-0li6OtcxBFHby3iVrkZq2A,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
josh-iaAMLnmF4UmaiuxdJuQwMA, jglisse-H+wXaHxf7aLQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, tglx-hfZtesqFncYOwBW4kG4KsQ,
yinghai-DgEjT+Ai2ygdnm+yROfE0A,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
chris-YvXeqwSYzG2sTnJN9+BGXg, monstr-pSz03upnqPeHXe+LvDLADg,
linux-parisc-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel
In-Reply-To: <20180726130904.GL6480@MiWiFi-R3L-srv>
On Thu 26-07-18 21:09:04, Baoquan He wrote:
> On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > those kind of very large machine can make use of this feature to speed
> > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > it. It may have possibility to not be able to find a usable space for
> > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > have this worry.
> > > >
> > > > I do not have the full context here but let me note that you should be
> > > > careful when doing top-down reservation because you can easily get into
> > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > this is done. See memblock_find_in_range_node
> > >
> > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > for them to do the later copying. You can see below struct kexec_segment,
> > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > the @buf stores the user space buffer address, @mem stores the position
> > > where kernel/initrd will be put. In kernel, it calls
> > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > kexec jumping, it will do the final copying from the intermediate pages
> > > to the real destination pages which @mem pointed. Because we can't touch
> > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > understanding, GFP_KERNEL will make those intermediate pages be
> > > allocated inside immovable area, it won't impact hotplugging. But the
> > > @mem we searched in the whole system RAM might be lost along with
> > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > detected.
> >
> > I am not sure I am following. If @mem is placed at movable node then the
> > memory hotremove simply won't work, because we are seeing reserved pages
> > and do not know what to do about them. They are not migrateable.
> > Allocating intermediate pages from other nodes doesn't really help.
>
> OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> in 1st kernel, it does impact the kernel which kexec jump into if kernel
> is at top of system RAM and the top RAM is in movable node.
It will affect the 1st kernel (which does the memblock allocation
top-down) as well. For reasons mentioned above.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Baoquan He @ 2018-07-26 13:09 UTC (permalink / raw)
To: Michal Hocko
Cc: nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A, brijesh.singh-5C7GfCeVMHo,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w,
jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w,
baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/,
kys-0li6OtcxBFHby3iVrkZq2A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
lorenzo.pieralisi-5wv7dgnIgG8, sthemmin-0li6OtcxBFHby3iVrkZq2A,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
patrik.r.jakobsson-Re5JQEeQqe8AvxtiuMwx3w,
andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w,
linux-input-u79uwXL29TY76Z2rM5mHXA,
gustavo-THi1TnShQwVAfugRpC6u6w, bp-l3A5Bk7waGM,
dyoung-H+wXaHxf7aLQT0dZR+AlfA, thomas.lendacky-5C7GfCeVMHo,
haiyangz-0li6OtcxBFHby3iVrkZq2A,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
josh-iaAMLnmF4UmaiuxdJuQwMA, jglisse-H+wXaHxf7aLQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, tglx-hfZtesqFncYOwBW4kG4KsQ,
yinghai-DgEjT+Ai2ygdnm+yROfE0A,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
chris-YvXeqwSYzG2sTnJN9+BGXg, monstr-pSz03upnqPeHXe+LvDLADg,
linux-parisc-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel
In-Reply-To: <20180726125957.GH28386-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On 07/26/18 at 02:59pm, Michal Hocko wrote:
> On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > Kexec has been a formal feature in our distro, and customers owning
> > > > those kind of very large machine can make use of this feature to speed
> > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > search place to put kernel under 4G from top to down. As we know, the
> > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > it. It may have possibility to not be able to find a usable space for
> > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > have this worry.
> > >
> > > I do not have the full context here but let me note that you should be
> > > careful when doing top-down reservation because you can easily get into
> > > hotplugable memory and break the hotremove usecase. We even warn when
> > > this is done. See memblock_find_in_range_node
> >
> > Kexec read kernel/initrd file into buffer, just search usable positions
> > for them to do the later copying. You can see below struct kexec_segment,
> > for the old kexec_load, kernel/initrd are read into user space buffer,
> > the @buf stores the user space buffer address, @mem stores the position
> > where kernel/initrd will be put. In kernel, it calls
> > kimage_load_normal_segment() to copy user space buffer to intermediate
> > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > are recorded as entries, later when user execute "kexec -e" to trigger
> > kexec jumping, it will do the final copying from the intermediate pages
> > to the real destination pages which @mem pointed. Because we can't touch
> > the existed data in 1st kernel when do kexec kernel loading. With my
> > understanding, GFP_KERNEL will make those intermediate pages be
> > allocated inside immovable area, it won't impact hotplugging. But the
> > @mem we searched in the whole system RAM might be lost along with
> > hotplug. Hence we need do kexec kernel again when hotplug event is
> > detected.
>
> I am not sure I am following. If @mem is placed at movable node then the
> memory hotremove simply won't work, because we are seeing reserved pages
> and do not know what to do about them. They are not migrateable.
> Allocating intermediate pages from other nodes doesn't really help.
OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
in 1st kernel, it does impact the kernel which kexec jump into if kernel
is at top of system RAM and the top RAM is in movable node.
>
> The memblock code warns exactly for that reason.
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 12:59 UTC (permalink / raw)
To: Baoquan He
Cc: nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A, brijesh.singh-5C7GfCeVMHo,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w,
jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w,
baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/,
kys-0li6OtcxBFHby3iVrkZq2A, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
lorenzo.pieralisi-5wv7dgnIgG8, sthemmin-0li6OtcxBFHby3iVrkZq2A,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
patrik.r.jakobsson-Re5JQEeQqe8AvxtiuMwx3w,
andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w,
linux-input-u79uwXL29TY76Z2rM5mHXA,
gustavo-THi1TnShQwVAfugRpC6u6w, bp-l3A5Bk7waGM,
dyoung-H+wXaHxf7aLQT0dZR+AlfA, thomas.lendacky-5C7GfCeVMHo,
haiyangz-0li6OtcxBFHby3iVrkZq2A,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
josh-iaAMLnmF4UmaiuxdJuQwMA, jglisse-H+wXaHxf7aLQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, tglx-hfZtesqFncYOwBW4kG4KsQ,
yinghai-DgEjT+Ai2ygdnm+yROfE0A,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
chris-YvXeqwSYzG2sTnJN9+BGXg, monstr-pSz03upnqPeHXe+LvDLADg,
linux-parisc-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel
In-Reply-To: <20180725064813.GI6480@MiWiFi-R3L-srv>
On Wed 25-07-18 14:48:13, Baoquan He wrote:
> On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > Kexec has been a formal feature in our distro, and customers owning
> > > those kind of very large machine can make use of this feature to speed
> > > up the reboot process. On uefi machine, the kexec_file loading will
> > > search place to put kernel under 4G from top to down. As we know, the
> > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > it. It may have possibility to not be able to find a usable space for
> > > kernel/initrd. From the top down of the whole memory space, we don't
> > > have this worry.
> >
> > I do not have the full context here but let me note that you should be
> > careful when doing top-down reservation because you can easily get into
> > hotplugable memory and break the hotremove usecase. We even warn when
> > this is done. See memblock_find_in_range_node
>
> Kexec read kernel/initrd file into buffer, just search usable positions
> for them to do the later copying. You can see below struct kexec_segment,
> for the old kexec_load, kernel/initrd are read into user space buffer,
> the @buf stores the user space buffer address, @mem stores the position
> where kernel/initrd will be put. In kernel, it calls
> kimage_load_normal_segment() to copy user space buffer to intermediate
> pages which are allocated with flag GFP_KERNEL. These intermediate pages
> are recorded as entries, later when user execute "kexec -e" to trigger
> kexec jumping, it will do the final copying from the intermediate pages
> to the real destination pages which @mem pointed. Because we can't touch
> the existed data in 1st kernel when do kexec kernel loading. With my
> understanding, GFP_KERNEL will make those intermediate pages be
> allocated inside immovable area, it won't impact hotplugging. But the
> @mem we searched in the whole system RAM might be lost along with
> hotplug. Hence we need do kexec kernel again when hotplug event is
> detected.
I am not sure I am following. If @mem is placed at movable node then the
memory hotremove simply won't work, because we are seeing reserved pages
and do not know what to do about them. They are not migrateable.
Allocating intermediate pages from other nodes doesn't really help.
The memblock code warns exactly for that reason.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: stop telling users to snail-mail Vojtech
From: Vojtech Pavlik @ 2018-07-26 10:33 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20180724184554.GA74150@dtor-ws>
On Tue, Jul 24, 2018 at 11:45:54AM -0700, Dmitry Torokhov wrote:
> I do not think Vojtech wants snail mail these days, even if the
> address were correct (I do not know if it is), so let's remove
> snail-mail instructions from the sources.
Thanks. Nobody has ever sent me mail this way, but nevertheless, the
address isn't valid anymore, so removing it makes good sense.
--
Vojtech Pavlik
Director SUSE Labs
^ permalink raw reply
* Re: WARNING in input_alloc_absinfo
From: Dmitry Vyukov @ 2018-07-26 9:40 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: syzkaller-bugs, linux-input, LKML, rydberg
In-Reply-To: <CACT4Y+b-=gPGQsbeFf44NTxhBJTAGwu+mUsAZDsquiUvpR9ROg@mail.gmail.com>
On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Fri, Jun 29, 2018 at 11:59 PM, <dmitry.torokhov@gmail.com> wrote:
>> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote:
>>>
>>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov
>>> <dmitry....@gmail.com> wrote:
>>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote:
>>> >> Hello,
>>> >>
>>> >> syzbot found the following crash on:
>>> >>
>>> >> HEAD commit: d2d741e5d189 kmsan: add initialization for shmem pages
>>> >> git tree: https://github.com/google/kmsan.git/master
>>> >> console output:
>>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae7800000
>>> >> kernel config:
>>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
>>> >> dashboard link:
>>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8
>>> >> compiler: clang version 7.0.0 (trunk 329391)
>>> >> syzkaller
>>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae7800000
>>> >> C reproducer:
>>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b800000
>>> >>
>>> >> IMPORTANT: if you fix the bug, please add the following tag to the
>>> >> commit:
>>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com
>>> >>
>>> >> RBP: 00000000006cb018 R08: 0000000000000001 R09: 00007ffe93080031
>>> >> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
>>> >> R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
>>> >> ------------[ cut here ]------------
>>> >> input_alloc_absinfo(): kcalloc() failed?
>>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487
>>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487
>>> >> Kernel panic - not syncing: panic_on_warn set ...
>>> >
>>> > Hmm, so there is not really a problem as far as I am concerned. We do
>>> > generate a warning if we can't allocate memory for absinfo, as this is
>>> > really unexpected, but the case is handled properly by the callers so
>>> > there is no reason for us to go belly up here.
>>>
>>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify
>>> valid uses of WARN()" is fully merged.
>>
>>
>> No, this warning will still be there even after the "clarifying" patch is
>> merged. It does not check user inputs, it warns that the system is so low on
>> memory that we could not allocate measly amount needed for absinfo. Treat it
>> as you treat OOM warnings from kmalloc() itself.
>
> Hi Dmitry,
>
> kmalloc does not produce WARNING on OOM. The rule is not only about
> invalid inputs, it's also about any transient conditions and "WARNING
> only for kernel bugs".
>
> To put this in larger context, being able to distinguish kernel bugs
> from non-bugs is a very important and practically useful capability,
> which in particular enables systematic testing, but also makes things
> simpler for all kernel users. There must be a very significant reason
> to abandon this capability. What is that reason in this case?
>
> I also don't understand what is so special about this case. If we want
> user message for kmalloc failures, kmalloc is the right place for such
> warning, rather than a random call site out of thousands. Consider,
> the allocation failure can happen on the very next or previous kmalloc
> call, and user won't be warned. The rest of the kernel (including the
> rest of input sybsystem) does not warn on allocation failures, so that
> looks like what we need to do here as well. Or, if there is something
> very special about this particular kmalloc call site, something that
> makes it different from thousands of other call sites, why don't you
> want to replace it with pr_err which would both give the diagnostics
> but also not block systematic testing? Which looks like a win-win to
> me.
>
> Thanks
So, Dmitry, do you mind fixing this in the name of unblocking kernel testing?
^ permalink raw reply
* Re: [PATCH v4 2/3] Input: edt-ft5x06 - Set wake/reset values on resume/suspend
From: Dmitry Torokhov @ 2018-07-26 0:52 UTC (permalink / raw)
To: Mylène Josserand
Cc: robh+dt, mark.rutland, maxime.ripard, wens, linux-input,
devicetree, linux-kernel, linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20180725073410.730-3-mylene.josserand@bootlin.com>
Hi Mylène,
On Wed, Jul 25, 2018 at 09:34:09AM +0200, Mylène Josserand wrote:
> On resume and suspend, set the value of wake and reset gpios
> to be sure that we are in a know state after suspending/resuming.
>
> Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
> ---
> drivers/input/touchscreen/edt-ft5x06.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index dcde719094f7..dad2f1f8bf89 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -1158,6 +1158,12 @@ static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> else
> regulator_disable(tsdata->vcc);
>
> + if (tsdata->wake_gpio)
> + gpiod_set_value(tsdata->wake_gpio, 0);
> +
> + if (tsdata->reset_gpio)
> + gpiod_set_value(tsdata->reset_gpio, 1);
Ondřej mentioned in previous review that if you power off the controller
it will not be able to wake up the system, and you had to move call to
regulator_disable() into "else" branch of check whether the controller
is a wakeup device. Guess what happens if you unconditionally put the
device into reset state?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 1/3] Input: edt-ft5x06 - Add support for regulator
From: Dmitry Torokhov @ 2018-07-26 0:47 UTC (permalink / raw)
To: Mylène Josserand
Cc: robh+dt, mark.rutland, maxime.ripard, wens, linux-input,
devicetree, linux-kernel, linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20180725073410.730-2-mylene.josserand@bootlin.com>
Hi Mylène,
On Wed, Jul 25, 2018 at 09:34:08AM +0200, Mylène Josserand wrote:
> Add the support of regulator to use it as VCC source.
>
> Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
> drivers/input/touchscreen/edt-ft5x06.c | 43 ++++++++++++++++++++++
> 2 files changed, 44 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> index 025cf8c9324a..48e975b9c1aa 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> @@ -30,6 +30,7 @@ Required properties:
> Optional properties:
> - reset-gpios: GPIO specification for the RESET input
> - wake-gpios: GPIO specification for the WAKE input
> + - vcc-supply: Regulator that supplies the touchscreen
>
> - pinctrl-names: should be "default"
> - pinctrl-0: a phandle pointing to the pin settings for the
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index 1e18ca0d1b4e..dcde719094f7 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -39,6 +39,7 @@
> #include <linux/input/mt.h>
> #include <linux/input/touchscreen.h>
> #include <linux/of_device.h>
> +#include <linux/regulator/consumer.h>
>
> #define WORK_REGISTER_THRESHOLD 0x00
> #define WORK_REGISTER_REPORT_RATE 0x08
> @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> struct touchscreen_properties prop;
> u16 num_x;
> u16 num_y;
> + struct regulator *vcc;
>
> struct gpio_desc *reset_gpio;
> struct gpio_desc *wake_gpio;
> @@ -963,6 +965,13 @@ edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data *tsdata)
> }
> }
>
> +static void edt_ft5x06_disable_regulator(void *arg)
> +{
> + struct edt_ft5x06_ts_data *data = arg;
> +
> + regulator_disable(data->vcc);
> +}
> +
> static int edt_ft5x06_ts_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -991,6 +1000,28 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
>
> tsdata->max_support_points = chip_data->max_support_points;
>
> + tsdata->vcc = devm_regulator_get(&client->dev, "vcc");
> + if (IS_ERR(tsdata->vcc)) {
> + error = PTR_ERR(tsdata->vcc);
> + if (error != -EPROBE_DEFER)
> + dev_err(&client->dev, "failed to request regulator: %d\n",
> + error);
> + return error;
> + }
> +
> + error = regulator_enable(tsdata->vcc);
> + if (error < 0) {
> + dev_err(&client->dev, "failed to enable vcc: %d\n",
> + error);
> + return error;
> + }
It is better to put the chip into reset and then power up the regulatori
and take it out of the reset, rather than power up and then toggle reset
on and off.
> +
> + error = devm_add_action_or_reset(&client->dev,
> + edt_ft5x06_disable_regulator,
> + tsdata);
> + if (error)
> + return error;
> +
> tsdata->reset_gpio = devm_gpiod_get_optional(&client->dev,
> "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(tsdata->reset_gpio)) {
> @@ -1120,9 +1151,12 @@ static int edt_ft5x06_ts_remove(struct i2c_client *client)
> static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> + struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
>
> if (device_may_wakeup(dev))
> enable_irq_wake(client->irq);
> + else
> + regulator_disable(tsdata->vcc);
>
> return 0;
> }
> @@ -1130,9 +1164,18 @@ static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> + struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> + int ret;
>
> if (device_may_wakeup(dev))
> disable_irq_wake(client->irq);
> + else {
> + ret = regulator_enable(tsdata->vcc);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable vcc: %d\n", ret);
> + return ret;
> + }
> + }
I believe I mentioned in other review that once you powered up the
device, you need to restore its settings, include switching to factory
mode, if it was in factory mode, and restoring threshold/gain/offset
settings.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: pxrc - do not store USB device in private struct
From: Dmitry Torokhov @ 2018-07-25 23:37 UTC (permalink / raw)
To: Marcus Folkesson; +Cc: Alexey Khoroshilov, linux-input, linux-kernel
In-Reply-To: <20180724180959.GA2864@gmail.com>
On Tue, Jul 24, 2018 at 08:09:59PM +0200, Marcus Folkesson wrote:
> Hello Dmitry,
>
> On Tue, Jul 24, 2018 at 02:38:04AM +0000, Dmitry Torokhov wrote:
> > Hi Marcus,
> >
> > On Mon, Jul 16, 2018 at 04:40:14PM +0200, Marcus Folkesson wrote:
> > > The USB device is only needed during setup, so put it back after
> > > initialization and do not store it in our private struct.
> > >
> > > Also, the USB device is a parent of USB interface so our driver
> > > model rules ensure that USB device should not disappear while
> > > interface device is still there.
> > > So not keep a refcount on the device is safe.
> > >
> > > Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
> > > Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
> > > ---
> > > drivers/input/joystick/pxrc.c | 22 ++++++++++++----------
> > > 1 file changed, 12 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/input/joystick/pxrc.c b/drivers/input/joystick/pxrc.c
> > > index 07a0dbd3ced2..46a7acb747bf 100644
> > > --- a/drivers/input/joystick/pxrc.c
> > > +++ b/drivers/input/joystick/pxrc.c
> > ...
> >
> > > @@ -204,23 +204,25 @@ static int pxrc_probe(struct usb_interface *intf,
> > > return -ENOMEM;
> > >
> > > mutex_init(&pxrc->pm_mutex);
> > > - pxrc->udev = usb_get_dev(interface_to_usbdev(intf));
> > > + udev = usb_get_dev(interface_to_usbdev(intf));
> >
> > There is really no need to "get" device for the probe duration, or in
> > general, when you are not storing the reference to it.
> >
> > I posted series with an updated version of this patch plus couple more
> > cleanups/fixes, and would appreciate if you could give it a spin.
>
> Thank you for doing this.
>
> I have reviewed the patchset and tested on real hardware, and it looks good
> to me.
>
> For what it's worth:
>
> Reviewed-by: Marcus Folkesson <marcus.folkesson@gmail.com>
> Tested-by: Marcus Folkesson <marcus.folkesson@gmail.com>
>
> On the whole patchset.
Excellent, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 09/10] Input: atmel_mxt_ts - tool type is ignored when slot is closed
From: Dmitry Torokhov @ 2018-07-25 23:21 UTC (permalink / raw)
To: Peter Hutterer
Cc: Benjamin Tissoires, Nick Dyer, lkml, open list:HID CORE LAYER,
cphealy, nikita.yoush, l.stach, nick.dyer
In-Reply-To: <20180725052641.GA7072@jelly>
On Wed, Jul 25, 2018 at 03:26:41PM +1000, Peter Hutterer wrote:
> On Tue, Jul 24, 2018 at 10:23:27AM +0200, Benjamin Tissoires wrote:
> > On Tue, Jul 24, 2018 at 12:34 AM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > On Fri, Jul 20, 2018 at 10:51:21PM +0100, Nick Dyer wrote:
> > > > From: Nick Dyer <nick.dyer@itdev.co.uk>
> > > >
> > > > input_mt_report_slot_state() ignores the tool when the slot is closed.
> > > > Remove the tool type from these function calls, which has caused a bit of
> > > > confusion.
> > >
> > > Hmm, maybe we could introduce MT_TOOL_NONE or MT_TOOL_INACTIVE and get
> > > rid of the 3rd parameter? It will require a bit of macro trickery for a
> > > release or 2...
> >
> > I am not sure what would be the benefit of adding those new tools, if
> > the input_mt code discards them. Do you want to forward them to the
> > userspace with the release?
> > This reminds me the discussion we had recently with the touchscreens
> > releasing the slots with a MT_TOOL_PALM.
> >
> > Anyway, better include Peter as he will be using this new MT_TOOL.
>
> thanks for the CC, would've missed this.
>
> From what I read this would be a helper for internal changes only, not
> exposed to userspace? If so maybe it's better/easier/more readable to break
> it into two functions
> input_mt_open_slot(dev, MT_TOOL_FINGER)
> input_mt_close_slot(dev)
>
> This removes any ambiguity about the handling of the tool and should be a
> fairly trivial search/replace. Replace the 'open/close' terminology with
> whatever suits better.
Hmm, I do like the "input_mt_close_slot()", or
"input_mt_report_slot_inactive()". I think the
input_mt_report_slot_state() is fine for "opening" the slot, as, with it
now returning bool, we can do:
if (input_mt_report_slot_state(dev, MT_TOOL_FINGER, state)) {
...
< report events for active slot >
}
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: atmel_mxt_ts: Document optional voltage regulators
From: Rob Herring @ 2018-07-25 16:02 UTC (permalink / raw)
To: Paweł Chmiel
Cc: nick, dmitry.torokhov, mark.rutland, nicolas.ferre,
alexandre.belloni, linux-input, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1531851386-17840-3-git-send-email-pawel.mikolaj.chmiel@gmail.com>
On Tue, Jul 17, 2018 at 08:16:26PM +0200, Paweł Chmiel wrote:
> Document new optional voltage regulators, which can be used
> to power down/up touchscreen.
>
> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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