Re: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

On Mon, Oct 2, 2017 at 1:08 PM, Segher Boessenkool wrote: > On Mon, Oct 02, 2017 at 12:29:45PM -0700, Kees Cook wrote: >> On Mon, Sep 25, 2017 at 12:41 PM, Segher Boessenkool >> wrote: >> > On Mon, Sep 25, 2017 at 04:01:55PM +, David

Re: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

On Mon, Oct 2, 2017 at 1:08 PM, Segher Boessenkool wrote: > On Mon, Oct 02, 2017 at 12:29:45PM -0700, Kees Cook wrote: >> On Mon, Sep 25, 2017 at 12:41 PM, Segher Boessenkool >> wrote: >> > On Mon, Sep 25, 2017 at 04:01:55PM +, David Laight wrote: >> >> From: Segher Boessenkool >> >> > The

Re: [PATCH 3/4] reset: tegra: check BPMP response return code

On 07/09/17 10:31, Timo Alho wrote: > Add checks for return code in BPMP response message. > > Signed-off-by: Timo Alho > --- > drivers/reset/tegra/reset-bpmp.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/reset/tegra/reset-bpmp.c

Re: [PATCH 3/4] reset: tegra: check BPMP response return code

On 07/09/17 10:31, Timo Alho wrote: > Add checks for return code in BPMP response message. > > Signed-off-by: Timo Alho > --- > drivers/reset/tegra/reset-bpmp.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/reset/tegra/reset-bpmp.c >

Re: [PATCH 2/4] clk: tegra: check BPMP response return code

On 02/10/17 09:43, Timo Alho wrote: > > > On 29.09.2017 17:53, Jonathan Hunter wrote: >> >> On 29/09/17 14:46, Timo Alho wrote: >>> Hi Jon, >>> >>> On 21.09.2017 14:21, Jonathan Hunter wrote: On 07/09/17 10:31, Timo Alho wrote: > Check return code in BPMP response message(s).

Re: [PATCH 2/4] clk: tegra: check BPMP response return code

On 02/10/17 09:43, Timo Alho wrote: > > > On 29.09.2017 17:53, Jonathan Hunter wrote: >> >> On 29/09/17 14:46, Timo Alho wrote: >>> Hi Jon, >>> >>> On 21.09.2017 14:21, Jonathan Hunter wrote: On 07/09/17 10:31, Timo Alho wrote: > Check return code in BPMP response message(s).

Re: [v8 0/4] cgroup-aware OOM killer

On Mon, Oct 2, 2017 at 12:56 PM, Michal Hocko wrote: > On Mon 02-10-17 12:45:18, Shakeel Butt wrote: >> > I am sorry to cut the rest of your proposal because it simply goes over >> > the scope of the proposed solution while the usecase you are mentioning >> > is still possible.

Re: [v8 0/4] cgroup-aware OOM killer

On Mon, Oct 2, 2017 at 12:56 PM, Michal Hocko wrote: > On Mon 02-10-17 12:45:18, Shakeel Butt wrote: >> > I am sorry to cut the rest of your proposal because it simply goes over >> > the scope of the proposed solution while the usecase you are mentioning >> > is still possible. If we want to

Re: [PATCH 0/4] Quirks cleanup and hid-generic niceness

On Mon, Oct 2, 2017 at 10:18 PM, Fedora Kernel Team wrote: Ouch, I happen to be in a git tree of the Fedora kernel, so git send-email decided to rewrite the 'from:' field. I'll add this to my check list before sending :/ Cheers, Benjamin > From: Benjamin

Re: [PATCH 0/4] Quirks cleanup and hid-generic niceness

On Mon, Oct 2, 2017 at 10:18 PM, Fedora Kernel Team wrote: Ouch, I happen to be in a git tree of the Fedora kernel, so git send-email decided to rewrite the 'from:' field. I'll add this to my check list before sending :/ Cheers, Benjamin > From: Benjamin Tissoires > > Hi, > > This is the

[PATCH 2/4] HID: quirks: move the list of special devices into a quirk

From: Benjamin Tissoires It is better to centralize the information of special devices in one single file. Instead of manually parsing the list of devices that have a special driver or those that need to be ignored, introduce HID_QUIRK_HAVE_SPECIAL_DRIVER and set

Re: [v8 0/4] cgroup-aware OOM killer

(Replying again as format of previous reply got messed up). On Mon, Oct 2, 2017 at 1:00 PM, Tim Hockin wrote: > In the example above: > >root >/\ > A D > / \ >B C > > Does oom_group allow me to express "compare A and D; if A is chosen

[PATCH 2/4] HID: quirks: move the list of special devices into a quirk

From: Benjamin Tissoires It is better to centralize the information of special devices in one single file. Instead of manually parsing the list of devices that have a special driver or those that need to be ignored, introduce HID_QUIRK_HAVE_SPECIAL_DRIVER and set the correct quirks while

Re: [v8 0/4] cgroup-aware OOM killer

(Replying again as format of previous reply got messed up). On Mon, Oct 2, 2017 at 1:00 PM, Tim Hockin wrote: > In the example above: > >root >/\ > A D > / \ >B C > > Does oom_group allow me to express "compare A and D; if A is chosen > compare B and C;

[PATCH 1/4] HID: core: move the dynamic quirks handling in core

From: Benjamin Tissoires usbhid has a list of dynamic quirks in addition to a list of static quirks. There is not much USB specific in that, so move this part of the module in core so we can have one central place for quirks. Signed-off-by: Benjamin Tissoires

[PATCH 1/4] HID: core: move the dynamic quirks handling in core

From: Benjamin Tissoires usbhid has a list of dynamic quirks in addition to a list of static quirks. There is not much USB specific in that, so move this part of the module in core so we can have one central place for quirks. Signed-off-by: Benjamin Tissoires --- drivers/hid/Makefile

[PATCH 3/4] HID: core: move the list of ignored devices in hid-quirks.c

From: Benjamin Tissoires Better having all the devices quirks in one place. Note that this change introduces an initial lookup for the device in hid_gets_squirk(), which should not theoretically be required, but which actually allows to not have to reparse the

[PATCH 3/4] HID: core: move the list of ignored devices in hid-quirks.c

From: Benjamin Tissoires Better having all the devices quirks in one place. Note that this change introduces an initial lookup for the device in hid_gets_squirk(), which should not theoretically be required, but which actually allows to not have to reparse the list of ignored devices if we call

[PATCH 4/4] HID: core: remove the absolute need of hid_have_special_driver[]

From: Benjamin Tissoires Most HID devices behave properly when they are used with hid-generic. Since kernel v4.12, we do not poll for input reports at plug in, so hid-generic should behave properly with all HID devices. There has been a long standing list of HID

[PATCH 4/4] HID: core: remove the absolute need of hid_have_special_driver[]

From: Benjamin Tissoires Most HID devices behave properly when they are used with hid-generic. Since kernel v4.12, we do not poll for input reports at plug in, so hid-generic should behave properly with all HID devices. There has been a long standing list of HID devices that have a special

[PATCH 0/4] Quirks cleanup and hid-generic niceness

From: Benjamin Tissoires Hi, This is the series I was talking about earlier[1]. Basically, Jiri, I'd like to see 1-3 applied in for-next at your earliest convenience, and we can discuss about 4/4 without any rush. I have this in my local tree since June, but I

[PATCH 0/4] Quirks cleanup and hid-generic niceness

From: Benjamin Tissoires Hi, This is the series I was talking about earlier[1]. Basically, Jiri, I'd like to see 1-3 applied in for-next at your earliest convenience, and we can discuss about 4/4 without any rush. I have this in my local tree since June, but I made some late minute changes

Re: [PATCH v3 01/12] pinctrl: move gpio-axp209 to pinctrl

On Mon, Oct 02, 2017 at 12:08:43PM +, Quentin Schulz wrote: > To prepare the driver for the upcoming pinctrl features, move the GPIO > driver AXP209 from GPIO to pinctrl subsystem. > > Signed-off-by: Quentin Schulz Acked-by: Maxime Ripard

Re: [PATCH v3 01/12] pinctrl: move gpio-axp209 to pinctrl

On Mon, Oct 02, 2017 at 12:08:43PM +, Quentin Schulz wrote: > To prepare the driver for the upcoming pinctrl features, move the GPIO > driver AXP209 from GPIO to pinctrl subsystem. > > Signed-off-by: Quentin Schulz Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons

[PATCH] clk: tegra30: make tegra_clk_pll_params __ro_after_init

These structures are only passed to the functions tegra_clk_register_pll, tegra_clk_register_pll{e/u} or tegra_periph_clk_init during the init phase. These functions modify the structures only during the init phase and after that the structures are never modified. Therefore, make them

[PATCH] clk: tegra30: make tegra_clk_pll_params __ro_after_init

These structures are only passed to the functions tegra_clk_register_pll, tegra_clk_register_pll{e/u} or tegra_periph_clk_init during the init phase. These functions modify the structures only during the init phase and after that the structures are never modified. Therefore, make them

Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be

Bringing in Josh on this, because the merge commit gets fingered because it seems to be an interaction between the new code from the merge and the ORC unwinder changes. It's probably some almost trivial code difference that just causes some code generation to change. And because Josh wasn't

Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be

Bringing in Josh on this, because the merge commit gets fingered because it seems to be an interaction between the new code from the merge and the ORC unwinder changes. It's probably some almost trivial code difference that just causes some code generation to change. And because Josh wasn't

Re: [v8 0/4] cgroup-aware OOM killer

On Mon 02-10-17 13:00:54, Tim Hockin wrote: > In the example above: > >root >/\ > A D > / \ >B C > > Does oom_group allow me to express "compare A and D; if A is chosen > compare B and C; kill the loser" ? As I understand the proposal (from > reading

Re: [v8 0/4] cgroup-aware OOM killer

On Mon 02-10-17 13:00:54, Tim Hockin wrote: > In the example above: > >root >/\ > A D > / \ >B C > > Does oom_group allow me to express "compare A and D; if A is chosen > compare B and C; kill the loser" ? As I understand the proposal (from > reading

Re: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

On Mon, Oct 02, 2017 at 12:29:45PM -0700, Kees Cook wrote: > On Mon, Sep 25, 2017 at 12:41 PM, Segher Boessenkool > wrote: > > On Mon, Sep 25, 2017 at 04:01:55PM +, David Laight wrote: > >> From: Segher Boessenkool > >> > The compiler puts this item in .sdata, for

Re: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

On Mon, Oct 02, 2017 at 12:29:45PM -0700, Kees Cook wrote: > On Mon, Sep 25, 2017 at 12:41 PM, Segher Boessenkool > wrote: > > On Mon, Sep 25, 2017 at 04:01:55PM +, David Laight wrote: > >> From: Segher Boessenkool > >> > The compiler puts this item in .sdata, for 32-bit. There is no

Re: [PATCH v3 05/14] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function

On Fri, Sep 29, 2017 at 08:22:57AM +, Chen-Yu Tsai wrote: > The HDMI driver enables the bus and mod clocks in the bind function, but > does not disable them if it then bails our due to any errors. Neither > does it disable the clocks in the unbind function. > > Fix this by adding a proper

Re: [PATCH v3 05/14] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function

On Fri, Sep 29, 2017 at 08:22:57AM +, Chen-Yu Tsai wrote: > The HDMI driver enables the bus and mod clocks in the bind function, but > does not disable them if it then bails our due to any errors. Neither > does it disable the clocks in the unbind function. > > Fix this by adding a proper

Re: [v8 0/4] cgroup-aware OOM killer

In the example above: root /\ A D / \ B C Does oom_group allow me to express "compare A and D; if A is chosen compare B and C; kill the loser" ? As I understand the proposal (from reading thread, not patch) it does not. On Mon, Oct 2, 2017 at 12:56 PM,

Re: [v8 0/4] cgroup-aware OOM killer

In the example above: root /\ A D / \ B C Does oom_group allow me to express "compare A and D; if A is chosen compare B and C; kill the loser" ? As I understand the proposal (from reading thread, not patch) it does not. On Mon, Oct 2, 2017 at 12:56 PM,

Re: [PATCH RFC] mm: implement write-behind policy for sequential file writes

On 10/02/2017 03:54 AM, Konstantin Khlebnikov wrote: > Traditional writeback tries to accumulate as much dirty data as possible. > This is worth strategy for extremely short-living files and for batching > writes for saving battery power. But for workloads where disk latency is > important this

Re: [PATCH RFC] mm: implement write-behind policy for sequential file writes

On 10/02/2017 03:54 AM, Konstantin Khlebnikov wrote: > Traditional writeback tries to accumulate as much dirty data as possible. > This is worth strategy for extremely short-living files and for batching > writes for saving battery power. But for workloads where disk latency is > important this

Re: [v8 0/4] cgroup-aware OOM killer

On Mon 02-10-17 12:45:18, Shakeel Butt wrote: > > I am sorry to cut the rest of your proposal because it simply goes over > > the scope of the proposed solution while the usecase you are mentioning > > is still possible. If we want to compare intermediate nodes (which seems > > to be the case)

Re: [v8 0/4] cgroup-aware OOM killer

On Mon 02-10-17 12:45:18, Shakeel Butt wrote: > > I am sorry to cut the rest of your proposal because it simply goes over > > the scope of the proposed solution while the usecase you are mentioning > > is still possible. If we want to compare intermediate nodes (which seems > > to be the case)

Re: [PATCH RFC] mm: implement write-behind policy for sequential file writes

On Mon, Oct 2, 2017 at 2:54 AM, Konstantin Khlebnikov wrote: > > This patch implements write-behind policy which tracks sequential writes > and starts background writeback when have enough dirty pages in a row. This looks lovely to me. I do wonder if you also looked

Re: [PATCH RFC] mm: implement write-behind policy for sequential file writes

On Mon, Oct 2, 2017 at 2:54 AM, Konstantin Khlebnikov wrote: > > This patch implements write-behind policy which tracks sequential writes > and starts background writeback when have enough dirty pages in a row. This looks lovely to me. I do wonder if you also looked at finishing the background

Re: [PATCH] writeback: remove unused parameter from balance_dirty_pages()

On Mon, Oct 02, 2017 at 09:56:16AM +0200, Michal Hocko wrote: > On Wed 27-09-17 15:13:11, Tahsin Erdogan wrote: > > "mapping" parameter to balance_dirty_pages() is not used anymore. > > > > Fixes: dfb8ae567835 ("writeback: let balance_dirty_pages() work on the > > matching cgroup bdi_writeback")

Re: [PATCH] writeback: remove unused parameter from balance_dirty_pages()

On Mon, Oct 02, 2017 at 09:56:16AM +0200, Michal Hocko wrote: > On Wed 27-09-17 15:13:11, Tahsin Erdogan wrote: > > "mapping" parameter to balance_dirty_pages() is not used anymore. > > > > Fixes: dfb8ae567835 ("writeback: let balance_dirty_pages() work on the > > matching cgroup bdi_writeback")

Re: [PATCH] ARM: OMAP2+: make omap_dma_dev_info __initdata

* Bhumika Goyal [170918 09:48]: > Make this __initdata as it is only modified only during the initialisation > phase in the function omap2_system_dma_init_dev and after this it is not > referenced anywhere in the kernel. Applying into omap-for-v4.15/soc thanks. Tony

Re: [PATCH] ARM: OMAP2+: make omap_dma_dev_info __initdata

* Bhumika Goyal [170918 09:48]: > Make this __initdata as it is only modified only during the initialisation > phase in the function omap2_system_dma_init_dev and after this it is not > referenced anywhere in the kernel. Applying into omap-for-v4.15/soc thanks. Tony

Re: [RFC] yamldt v0.5, now a DTS compiler too

Hi Rob, On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote: > On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou > wrote: > > Hello again, > > > > Significant progress has been made on yamldt and is now capable of > > not only generating yaml from DTS source but

Re: [RFC] yamldt v0.5, now a DTS compiler too

Hi Rob, On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote: > On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou > wrote: > > Hello again, > > > > Significant progress has been made on yamldt and is now capable of > > not only generating yaml from DTS source but also compiling DTS sources > >

Re: [v8 0/4] cgroup-aware OOM killer

> I am sorry to cut the rest of your proposal because it simply goes over > the scope of the proposed solution while the usecase you are mentioning > is still possible. If we want to compare intermediate nodes (which seems > to be the case) then we can always provide a knob to opt-in - be it your

Re: [v8 0/4] cgroup-aware OOM killer

> I am sorry to cut the rest of your proposal because it simply goes over > the scope of the proposed solution while the usecase you are mentioning > is still possible. If we want to compare intermediate nodes (which seems > to be the case) then we can always provide a knob to opt-in - be it your

Re: [PATCH] ARM: omap1: add const and initconst to omap_lcd_config

* Bhumika Goyal [170821 23:26]: > Make these const as they are only passed to a const argument of the function > omapfb_set_lcd_config. > Also, replace __initdata with __initconst to avoid section conflict error. > Done using Coccinelle. Applying into omap-for-v4.15/omap1

Re: [PATCH] ARM: omap1: add const and initconst to omap_lcd_config

* Bhumika Goyal [170821 23:26]: > Make these const as they are only passed to a const argument of the function > omapfb_set_lcd_config. > Also, replace __initdata with __initconst to avoid section conflict error. > Done using Coccinelle. Applying into omap-for-v4.15/omap1 thanks. Tony

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

On Mon, 2 Oct 2017 12:33:30 -0700 Joel Fernandes wrote: > diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h > index 5dd1272d1ab2..2a1af0dd9cc4 100644 > --- a/include/linux/irqflags.h > +++ b/include/linux/irqflags.h > @@ -93,7 +93,9 @@ > #define

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

On Mon, 2 Oct 2017 12:33:30 -0700 Joel Fernandes wrote: > diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h > index 5dd1272d1ab2..2a1af0dd9cc4 100644 > --- a/include/linux/irqflags.h > +++ b/include/linux/irqflags.h > @@ -93,7 +93,9 @@ > #define local_irq_save(flags)

Re: [PATCH RFC V4 1/6] perf tools: lock to protect namespaces and comm list

Em Mon, Oct 02, 2017 at 07:14:10PM +, Liang, Kan escreveu: > > Em Fri, Sep 29, 2017 at 07:47:52AM -0700, kan.li...@intel.com escreveu: > > > From: Kan Liang > > > > > > Add two locks to protect namespaces_list and comm_list. > > > > > > The lock is only needed for

Re: [PATCH RFC V4 1/6] perf tools: lock to protect namespaces and comm list

Em Mon, Oct 02, 2017 at 07:14:10PM +, Liang, Kan escreveu: > > Em Fri, Sep 29, 2017 at 07:47:52AM -0700, kan.li...@intel.com escreveu: > > > From: Kan Liang > > > > > > Add two locks to protect namespaces_list and comm_list. > > > > > > The lock is only needed for multithreaded code, so using

Re: [RFC GIT Pull] core watchdog sanitizing

On Mon, 2 Oct 2017, Linus Torvalds wrote: > Side note: would it perhaps make sense to have that > cpus_read_lock/unlock() sequence around the whole reconfiguration > section? > > Because while looking at that sequence, it looks a bit odd to me that > cpu's can come and go in the middle of the nmi

Re: [RFC GIT Pull] core watchdog sanitizing

On Mon, 2 Oct 2017, Linus Torvalds wrote: > Side note: would it perhaps make sense to have that > cpus_read_lock/unlock() sequence around the whole reconfiguration > section? > > Because while looking at that sequence, it looks a bit odd to me that > cpu's can come and go in the middle of the nmi

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

On Mon, Oct 2, 2017 at 12:23 PM, Joel Fernandes wrote: > Hi Steven, > > On Sat, Sep 30, 2017 at 2:08 AM, Steven Rostedt wrote: >> On Mon, 25 Sep 2017 17:23:00 -0700 >> Joel Fernandes wrote: >> >>> The trace_hardirqs_off API can be

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

On Mon, Oct 2, 2017 at 12:23 PM, Joel Fernandes wrote: > Hi Steven, > > On Sat, Sep 30, 2017 at 2:08 AM, Steven Rostedt wrote: >> On Mon, 25 Sep 2017 17:23:00 -0700 >> Joel Fernandes wrote: >> >>> The trace_hardirqs_off API can be called even when IRQs are already >>> off. This is unlike the

[PATCH v3] staging: atomisp: add a driver for ov5648 camera sensor

The ov5648 5-megapixel camera sensor from OmniVision supports up to 2592x1944 resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with 10 bits per colour (SGRBG10_1X10). This patch is a port of ov5648 driver after applying following 01org/ProductionKernelQuilts patches: -

[PATCH v3] staging: atomisp: add a driver for ov5648 camera sensor

The ov5648 5-megapixel camera sensor from OmniVision supports up to 2592x1944 resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with 10 bits per colour (SGRBG10_1X10). This patch is a port of ov5648 driver after applying following 01org/ProductionKernelQuilts patches: -

Re: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

On Mon, Sep 25, 2017 at 12:41 PM, Segher Boessenkool wrote: > On Mon, Sep 25, 2017 at 04:01:55PM +, David Laight wrote: >> From: Segher Boessenkool >> > The compiler puts this item in .sdata, for 32-bit. There is no .srodata, >> > so if it wants to use a small

Re: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

On Mon, Sep 25, 2017 at 12:41 PM, Segher Boessenkool wrote: > On Mon, Sep 25, 2017 at 04:01:55PM +, David Laight wrote: >> From: Segher Boessenkool >> > The compiler puts this item in .sdata, for 32-bit. There is no .srodata, >> > so if it wants to use a small data section, it must use

Re: [PATCH] HID: i2c-hid: Use device properties (instead of device tree)

On Fri, Sep 29, 2017 at 5:08 PM, Brian Norris wrote: > Hi Rajat, > > On Fri, Sep 29, 2017 at 03:44:41PM -0700, Rajat Jain wrote: >> Use the device properties (that can be provided by ACPI systems >> as well as non ACPI systems) instead of device tree properties >> (that

Re: [PATCH] HID: i2c-hid: Use device properties (instead of device tree)

On Fri, Sep 29, 2017 at 5:08 PM, Brian Norris wrote: > Hi Rajat, > > On Fri, Sep 29, 2017 at 03:44:41PM -0700, Rajat Jain wrote: >> Use the device properties (that can be provided by ACPI systems >> as well as non ACPI systems) instead of device tree properties >> (that are not provided ACPI

Re: [v8 0/4] cgroup-aware OOM killer

On Mon 02-10-17 12:00:43, Shakeel Butt wrote: > > Yes and nobody is disputing that, really. I guess the main disconnect > > here is that different people want to have more detailed control over > > the victim selection while the patchset tries to handle the most > > simplistic scenario when a no

Re: [v8 0/4] cgroup-aware OOM killer

On Mon 02-10-17 12:00:43, Shakeel Butt wrote: > > Yes and nobody is disputing that, really. I guess the main disconnect > > here is that different people want to have more detailed control over > > the victim selection while the patchset tries to handle the most > > simplistic scenario when a no

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

Hi Steven, On Sat, Sep 30, 2017 at 2:08 AM, Steven Rostedt wrote: > On Mon, 25 Sep 2017 17:23:00 -0700 > Joel Fernandes wrote: > >> The trace_hardirqs_off API can be called even when IRQs are already >> off. This is unlike the trace_hardirqs_on which

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

Hi Steven, On Sat, Sep 30, 2017 at 2:08 AM, Steven Rostedt wrote: > On Mon, 25 Sep 2017 17:23:00 -0700 > Joel Fernandes wrote: > >> The trace_hardirqs_off API can be called even when IRQs are already >> off. This is unlike the trace_hardirqs_on which checks if IRQs are off >> (atleast from some

Re: [PATCH] HID: i2c-hid: Use device properties (instead of device tree)

OK, I think my patch changes more than what is needed (to solve my problem), and in the process creates concerns. Please allow me to step back and elaborate on the problem I'm trying to solve. The hardware I am working on (Wacom touchscreen) does require a good 100ms delay after the reset, which

Re: [PATCH] HID: i2c-hid: Use device properties (instead of device tree)

OK, I think my patch changes more than what is needed (to solve my problem), and in the process creates concerns. Please allow me to step back and elaborate on the problem I'm trying to solve. The hardware I am working on (Wacom touchscreen) does require a good 100ms delay after the reset, which

Re: [PATCH 00/18] use ARRAY_SIZE macro

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > >

Re: [PATCH 00/18] use ARRAY_SIZE macro

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > > > series is

[PATCH 3/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO

Nearly all modern compilers support a stack-protector option, and nearly all modern distributions enable the kernel stack-protector, so enabling this by default in kernel builds would make sense. However, Kconfig does not have knowledge of available compiler features, so it isn't safe to force on,

[PATCH 3/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO

Nearly all modern compilers support a stack-protector option, and nearly all modern distributions enable the kernel stack-protector, so enabling this by default in kernel builds would make sense. However, Kconfig does not have knowledge of available compiler features, so it isn't safe to force on,

[PATCH 1/3] sh/boot: Add static stack-protector to pre-kernel

The sh decompressor code triggers stack-protector code generation when using CONFIG_CC_STACKPROTECTOR_STRONG. As done for arm and mips, add a simple static stack-protector canary. As this wasn't protected before, the risk of using a weak canary is minimized. Once the kernel is actually up, a

[PATCH 1/3] sh/boot: Add static stack-protector to pre-kernel

The sh decompressor code triggers stack-protector code generation when using CONFIG_CC_STACKPROTECTOR_STRONG. As done for arm and mips, add a simple static stack-protector canary. As this wasn't protected before, the risk of using a weak canary is minimized. Once the kernel is actually up, a

[PATCH 2/3] Makefile: Move stackprotector availability out of Kconfig

Various portions of the kernel, especially per-architecture pieces, need to know if the compiler is building it with the stack protector. This was done in the arch/Kconfig with 'select', but this doesn't allow a way to do auto-detected compiler support. In preparation for creating an

[PATCH 2/3] Makefile: Move stackprotector availability out of Kconfig

Various portions of the kernel, especially per-architecture pieces, need to know if the compiler is building it with the stack protector. This was done in the arch/Kconfig with 'select', but this doesn't allow a way to do auto-detected compiler support. In preparation for creating an

[PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO

As described in the final patch: Nearly all modern compilers support a stack-protector option, and nearly all modern distributions enable the kernel stack-protector, so enabling this by default in kernel builds would make sense. However, Kconfig does not have knowledge of available compiler

[PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO

As described in the final patch: Nearly all modern compilers support a stack-protector option, and nearly all modern distributions enable the kernel stack-protector, so enabling this by default in kernel builds would make sense. However, Kconfig does not have knowledge of available compiler

RE: [PATCH RFC V4 1/6] perf tools: lock to protect namespaces and comm list

> Em Fri, Sep 29, 2017 at 07:47:52AM -0700, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > Add two locks to protect namespaces_list and comm_list. > > > > The lock is only needed for multithreaded code, so using mutex > > wrappers provided by perf tool. > > > > Not

RE: [PATCH RFC V4 1/6] perf tools: lock to protect namespaces and comm list

> Em Fri, Sep 29, 2017 at 07:47:52AM -0700, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > Add two locks to protect namespaces_list and comm_list. > > > > The lock is only needed for multithreaded code, so using mutex > > wrappers provided by perf tool. > > > > Not all the

Re: [PATCH] uio/uio_pci_generic: Add SR-IOV support

On Mon, 2017-10-02 at 14:52 -0400, Don Dutile wrote: > On 10/02/2017 08:35 AM, David Woodhouse wrote: > > This would allow you to enable SR-IOV on a PF before its driver is > > loaded, right? Even when that driver *is* going to need to perform > > resource management for those VFs? > > > > Would

Re: [PATCH] uio/uio_pci_generic: Add SR-IOV support

On Mon, 2017-10-02 at 14:52 -0400, Don Dutile wrote: > On 10/02/2017 08:35 AM, David Woodhouse wrote: > > This would allow you to enable SR-IOV on a PF before its driver is > > loaded, right? Even when that driver *is* going to need to perform > > resource management for those VFs? > > > > Would

RE: keyboard backlight max_brightness bug on Dell Latitude E6410

Original Message Subject: Re: keyboard backlight max_brightness bug on Dell Latitude E6410 From: Pali Rohár Date: Mon, October 02, 2017 8:15 am To: gabr...@tekgnowsys.com Cc: andy.shevche...@gmail.com, gabr...@tekgnowsys.com, gabriele@gmail.com,

RE: keyboard backlight max_brightness bug on Dell Latitude E6410

Original Message Subject: Re: keyboard backlight max_brightness bug on Dell Latitude E6410 From: Pali Rohár Date: Mon, October 02, 2017 8:15 am To: gabr...@tekgnowsys.com Cc: andy.shevche...@gmail.com, gabr...@tekgnowsys.com, gabriele@gmail.com, dvh...@infradead.org,

Re: [Xen-devel] KVM PV

Paolo Bonzini wrote: > On 02/10/2017 12:36, George Dunlap wrote: Although I'm not business man, I don't think the top cloud provider[s] would allow nested virtualization, however mature nested virtualization is. Even xen-pv is unable to be nested in the aws

Re: [Xen-devel] KVM PV

Paolo Bonzini wrote: > On 02/10/2017 12:36, George Dunlap wrote: Although I'm not business man, I don't think the top cloud provider[s] would allow nested virtualization, however mature nested virtualization is. Even xen-pv is unable to be nested in the aws and azure. >>> >>>

Re: [PATCH] vfio-mdev: make mdev_fops const and static

On Sat, 30 Sep 2017 21:47:24 +0530 Bhumika Goyal wrote: > Make this const as it is only passed to a const argument of the function > mdev_register_device. Make it static as it is not referenced in any > other file. > > Structure found using Coccinelle and changes done by

Re: [PATCH] vfio-mdev: make mdev_fops const and static

On Sat, 30 Sep 2017 21:47:24 +0530 Bhumika Goyal wrote: > Make this const as it is only passed to a const argument of the function > mdev_register_device. Make it static as it is not referenced in any > other file. > > Structure found using Coccinelle and changes done by hand. > >

Re: [PATCH] exthdr: Add support for reserved header and address

Hi Harsha, On Mon, Oct 02, 2017 at 02:07:00AM +0530, Harsha Sharma wrote: > Add support for IPV6 type 0 routing header reserved field and address > unable to test it with nft-test.py It seems you didn't test this patch. # python nft-test.py ip6/rt.t

Re: [PATCH] exthdr: Add support for reserved header and address

Hi Harsha, On Mon, Oct 02, 2017 at 02:07:00AM +0530, Harsha Sharma wrote: > Add support for IPV6 type 0 routing header reserved field and address > unable to test it with nft-test.py It seems you didn't test this patch. # python nft-test.py ip6/rt.t

Re: [PATCH 9/9] arm64: dts: register Hi3660's thermal sensor

On 22/09/2017 11:42, Tao Wang wrote: > From: Kevin Wangtao > > add binding for tsensor on H3660, this tsensor is used for > SoC thermal control, it supports alarm interrupt. > > Signed-off-by: Kevin Wangtao I'm not able to apply this patch.

Re: [PATCH 9/9] arm64: dts: register Hi3660's thermal sensor

On 22/09/2017 11:42, Tao Wang wrote: > From: Kevin Wangtao > > add binding for tsensor on H3660, this tsensor is used for > SoC thermal control, it supports alarm interrupt. > > Signed-off-by: Kevin Wangtao I'm not able to apply this patch. Does it rely on another patch? > --- >

Re: [RFC GIT Pull] core watchdog sanitizing

On Mon, Oct 2, 2017 at 11:46 AM, Thomas Gleixner wrote: > > I agree that adding that 'run' argument was certainly not a piece of > art. Though I disagree with the sentiment that non-functional garbage is > preferrable over functionally correct code which merily contains a bad

Re: [RFC GIT Pull] core watchdog sanitizing

On Mon, Oct 2, 2017 at 11:46 AM, Thomas Gleixner wrote: > > I agree that adding that 'run' argument was certainly not a piece of > art. Though I disagree with the sentiment that non-functional garbage is > preferrable over functionally correct code which merily contains a bad > implementation

Re: [v8 0/4] cgroup-aware OOM killer

> Yes and nobody is disputing that, really. I guess the main disconnect > here is that different people want to have more detailed control over > the victim selection while the patchset tries to handle the most > simplistic scenario when a no userspace control over the selection is > required. And

Re: [v8 0/4] cgroup-aware OOM killer

> Yes and nobody is disputing that, really. I guess the main disconnect > here is that different people want to have more detailed control over > the victim selection while the patchset tries to handle the most > simplistic scenario when a no userspace control over the selection is > required. And

<    1   2   3   4   5   6   7   8   9   10   >