Re: [PATCH v3 10/16] MIPS: math-emu: MINA.<D|S>: Fix some cases of infinity and zero inputs

On Fri, Jul 21, 2017 at 04:09:08PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix following special cases for MINA>.: > > - if one of the inputs is zero, and the other is subnormal, normal, > or infinity, the value of the former

Re: [PATCH v3 10/16] MIPS: math-emu: MINA.: Fix some cases of infinity and zero inputs

On Fri, Jul 21, 2017 at 04:09:08PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix following special cases for MINA>.: > > - if one of the inputs is zero, and the other is subnormal, normal, > or infinity, the value of the former should be returned (that is, > a

[PATCH] dvb_frontend: initialize variable s with FE_NONE instead of 0

From: Colin Ian King In a previous commit, we added FE_NONE as an unknown fe_status. Initialize variable s to FE_NONE instead of the more opaque value 0. Signed-off-by: Colin Ian King --- drivers/media/dvb-core/dvb_frontend.c | 2 +- 1 file

[PATCH] dvb_frontend: initialize variable s with FE_NONE instead of 0

From: Colin Ian King In a previous commit, we added FE_NONE as an unknown fe_status. Initialize variable s to FE_NONE instead of the more opaque value 0. Signed-off-by: Colin Ian King --- drivers/media/dvb-core/dvb_frontend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] kbuild: modpost: Warn about references from rodata to __init text

Hi Stephen, 2017-07-21 2:52 GMT+09:00 Stephen Boyd : > On 07/20, Masahiro Yamada wrote: >> Hi Stephen, Rob, >> >> 2017-07-01 8:59 GMT+09:00 Rob Clark : >> > On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd wrote: >> >> If we have a

Re: [PATCH] kbuild: modpost: Warn about references from rodata to __init text

Hi Stephen, 2017-07-21 2:52 GMT+09:00 Stephen Boyd : > On 07/20, Masahiro Yamada wrote: >> Hi Stephen, Rob, >> >> 2017-07-01 8:59 GMT+09:00 Rob Clark : >> > On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd wrote: >> >> If we have a structure that's marked const it will be placed >> >> into the

Re: [iovisor-dev] [PATCH net 0/2] bpf: fix verifier min/max handling in BPF_SUB

Edward Cree via iovisor-dev wrote: > I managed to come up with a test for the swapped bounds in BPF_SUB, so here > it is along with a patch that fixes it, separated out from my 'rewrite > everything' series so it can go to -stable. > > Edward Cree (2): >

Re: [iovisor-dev] [PATCH net 0/2] bpf: fix verifier min/max handling in BPF_SUB

Edward Cree via iovisor-dev wrote: > I managed to come up with a test for the swapped bounds in BPF_SUB, so here > it is along with a patch that fixes it, separated out from my 'rewrite > everything' series so it can go to -stable. > > Edward Cree (2): > selftests/bpf: subtraction bounds test

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, Jul 21, 2017 at 03:34:50PM +, Kani, Toshimitsu wrote: > I suppose it'd depend on vendors, but I do not think users can do it > properly unless they have depth knowledge about the hardware. I'm talking about a menu in the BIOS where you can set the thresholding levels on the system.

Re: [RFC 1/2] net-next: add a dma_desc element to struct skb_shared_info

Hi, On Fri, 2017-07-21 at 17:20 +0200, John Crispin wrote: > In order to make HW flow offloading work in latest MediaTek silicon we need > to propagate part of the RX DMS descriptor to the upper layers populating > the flow offload engines HW tables. This patch adds an extra element to > struct

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-20 17:27, Nick Terrell wrote: Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch has relevant summaries, benchmarks, and tests. Best, Nick Terrell For patches 2-3, I've compile tested

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, Jul 21, 2017 at 03:34:50PM +, Kani, Toshimitsu wrote: > I suppose it'd depend on vendors, but I do not think users can do it > properly unless they have depth knowledge about the hardware. I'm talking about a menu in the BIOS where you can set the thresholding levels on the system.

Re: [RFC 1/2] net-next: add a dma_desc element to struct skb_shared_info

Hi, On Fri, 2017-07-21 at 17:20 +0200, John Crispin wrote: > In order to make HW flow offloading work in latest MediaTek silicon we need > to propagate part of the RX DMS descriptor to the upper layers populating > the flow offload engines HW tables. This patch adds an extra element to > struct

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On 2017-07-20 17:27, Nick Terrell wrote: Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch has relevant summaries, benchmarks, and tests. Best, Nick Terrell For patches 2-3, I've compile tested

Re: [PATCH] net: ethernet: ti: cpsw: Push the request_irq function to the end of probe

On 07/20/2017 11:45 PM, Keerthy wrote: On Friday 21 July 2017 04:14 AM, Grygorii Strashko wrote: On 07/20/2017 05:28 PM, David Miller wrote: From: Grygorii Strashko Date: Thu, 20 Jul 2017 11:08:09 -0500 In general patch looks good to me, but it's really

Re: [PATCH] net: ethernet: ti: cpsw: Push the request_irq function to the end of probe

On 07/20/2017 11:45 PM, Keerthy wrote: On Friday 21 July 2017 04:14 AM, Grygorii Strashko wrote: On 07/20/2017 05:28 PM, David Miller wrote: From: Grygorii Strashko Date: Thu, 20 Jul 2017 11:08:09 -0500 In general patch looks good to me, but it's really unexpected to receive IRQs

[PATCH v1 2/2] [media] ov9655: fix missing mutex_destroy()

Fix missing mutex_destroy() when probe fails and when driver is removed. Signed-off-by: Hugues Fruchet --- drivers/media/i2c/ov9650.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c index

[PATCH v1 2/2] [media] ov9655: fix missing mutex_destroy()

Fix missing mutex_destroy() when probe fails and when driver is removed. Signed-off-by: Hugues Fruchet --- drivers/media/i2c/ov9650.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c index e8dea28..6ffb460 100644

[PATCH v1 0/2] OV9650 code cleanup

Here is a bunch of small fixes found when upstreaming the OV9655 sensor driver based on OV9650 driver: - Fix coding style (checkpatch --strict) - Fix missing mutex_destroy, see http://www.mail-archive.com/linux-media@vger.kernel.org/msg115245.html Hugues Fruchet (2): [media] ov9650: fix coding

[PATCH v1 0/2] OV9650 code cleanup

Here is a bunch of small fixes found when upstreaming the OV9655 sensor driver based on OV9650 driver: - Fix coding style (checkpatch --strict) - Fix missing mutex_destroy, see http://www.mail-archive.com/linux-media@vger.kernel.org/msg115245.html Hugues Fruchet (2): [media] ov9650: fix coding

[PATCH v1 1/2] [media] ov9650: fix coding style

Fix a bunch of coding style issues detected by checkpatch --strict. Signed-off-by: Hugues Fruchet --- drivers/media/i2c/ov9650.c | 59 ++ 1 file changed, 33 insertions(+), 26 deletions(-) diff --git a/drivers/media/i2c/ov9650.c

[PATCH v1 1/2] [media] ov9650: fix coding style

Fix a bunch of coding style issues detected by checkpatch --strict. Signed-off-by: Hugues Fruchet --- drivers/media/i2c/ov9650.c | 59 ++ 1 file changed, 33 insertions(+), 26 deletions(-) diff --git a/drivers/media/i2c/ov9650.c

Re: [PATCH 3/3] ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()

On Fri, Jul 21, 2017 at 3:42 PM, Rafael J. Wysocki wrote: > The acpi_pci_propagate_wakeup() routine is there to handle cases in > which PCI bridges (or PCIe ports) are expected to signal wakeup > for devices below them, but currently it doesn't do that correctly. > > The

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

Em Fri, 21 Jul 2017 15:34:50 + "Kani, Toshimitsu" escreveu: > On Fri, 2017-07-21 at 17:13 +0200, Borislav Petkov wrote: > > On Fri, Jul 21, 2017 at 03:08:41PM +, Kani, Toshimitsu wrote: > > > Yes, that is correct.  Corrected errors are reported to the OS when > > >

Re: [PATCH 3/3] ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()

On Fri, Jul 21, 2017 at 3:42 PM, Rafael J. Wysocki wrote: > The acpi_pci_propagate_wakeup() routine is there to handle cases in > which PCI bridges (or PCIe ports) are expected to signal wakeup > for devices below them, but currently it doesn't do that correctly. > > The problem is that

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

Em Fri, 21 Jul 2017 15:34:50 + "Kani, Toshimitsu" escreveu: > On Fri, 2017-07-21 at 17:13 +0200, Borislav Petkov wrote: > > On Fri, Jul 21, 2017 at 03:08:41PM +, Kani, Toshimitsu wrote: > > > Yes, that is correct.  Corrected errors are reported to the OS when > > > they exceeded the

Re: [PATCH v3 09/16] MIPS: math-emu: <MAXA|MINA>.<D|S>: Fix cases of both infinite inputs

On Fri, Jul 21, 2017 at 04:09:07PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by . fd,fs,ft, if both inputs > are infinite. The previous implementation returned always the value > contained in ft in

Re: [PATCH v3 09/16] MIPS: math-emu: .: Fix cases of both infinite inputs

On Fri, Jul 21, 2017 at 04:09:07PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by . fd,fs,ft, if both inputs > are infinite. The previous implementation returned always the value > contained in ft in such cases. The correct behavior is specified > in

Re: [RFC PATCH 1/4] serial: uartps: Remove console_initcall from the driver

On Fri, 2017-07-21 at 11:32:24 +0200, Michal Simek wrote: > register_console() is called from > uart_add_one_port()->uart_configure_port() > that's why register_console() is called twice. > > This patch remove console_initcall to call register_console() only from > one location. > > Also based

Re: [RFC PATCH 1/4] serial: uartps: Remove console_initcall from the driver

On Fri, 2017-07-21 at 11:32:24 +0200, Michal Simek wrote: > register_console() is called from > uart_add_one_port()->uart_configure_port() > that's why register_console() is called twice. > > This patch remove console_initcall to call register_console() only from > one location. > > Also based

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

Hi Anup, On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel wrote: > The Broadcom FlexRM ring (i.e. mailbox channel) can handle > larger number of messages queued in one FlexRM ring hence > this patch sets msg_queue_len for each mailbox channel to > be same as

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

Hi Anup, On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel wrote: > The Broadcom FlexRM ring (i.e. mailbox channel) can handle > larger number of messages queued in one FlexRM ring hence > this patch sets msg_queue_len for each mailbox channel to > be same as RING_MAX_REQ_COUNT. > > Signed-off-by:

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Thu, Jul 20, 2017 at 4:42 PM, Paul Moore wrote: > On Thu, Jul 20, 2017 at 1:06 PM, Kees Cook wrote: >> On Thu, Jul 20, 2017 at 6:42 AM, Paul Moore wrote: >>> Alternatively, if you've got a fairly recent git repo with all the

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Thu, Jul 20, 2017 at 4:42 PM, Paul Moore wrote: > On Thu, Jul 20, 2017 at 1:06 PM, Kees Cook wrote: >> On Thu, Jul 20, 2017 at 6:42 AM, Paul Moore wrote: >>> Alternatively, if you've got a fairly recent git repo with all the >>> patches merged I can build a test kernel and give it a shot for

Re: [PATCH] bcma: gpio: Correct number of GPIOs for BCM53573

Florian Fainelli writes: > On 06/30/2017 02:37 PM, Rafał Miłecki wrote: >> On 30 June 2017 at 21:02, Florian Fainelli wrote: >>> Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16. >>> >>> Fixes: 3f37ec79dd21 ("bcma: support BCM53573 series of

Re: [PATCH] bcma: gpio: Correct number of GPIOs for BCM53573

Florian Fainelli writes: > On 06/30/2017 02:37 PM, Rafał Miłecki wrote: >> On 30 June 2017 at 21:02, Florian Fainelli wrote: >>> Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16. >>> >>> Fixes: 3f37ec79dd21 ("bcma: support BCM53573 series of wireless SoCs") >>> Signed-off-by: Florian

Re: [PATCH v3 08/16] MIPS: math-emu: <MAXA|MINA>.<D|S>: Fix cases of input values with opposite signs

On Fri, Jul 21, 2017 at 04:09:06PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by ., if inputs are normal fp > numbers of the same absolute value, but opposite signs. > > The relevant example: > >

Re: [PATCH v3 08/16] MIPS: math-emu: .: Fix cases of input values with opposite signs

On Fri, Jul 21, 2017 at 04:09:06PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by ., if inputs are normal fp > numbers of the same absolute value, but opposite signs. > > The relevant example: > > MAXA.S fd,fs,ft: > If fs contains -3, and ft

[PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

From: Hans de Goede Some sdio devices have a multiple stage bring-up process. Specifically the esp8089 (for which an out of tree driver is available) loads firmware on the first call to its sdio-drivers' probe function and then resets the device causing it to reboot from its

[PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

From: Hans de Goede Some sdio devices have a multiple stage bring-up process. Specifically the esp8089 (for which an out of tree driver is available) loads firmware on the first call to its sdio-drivers' probe function and then resets the device causing it to reboot from its RAM with the new

Re: [PATCH] oom_reaper: close race without using oom_lock

On Sat 22-07-17 00:18:48, Tetsuo Handa wrote: > Michal Hocko wrote: > > > If we ignore MMF_OOM_SKIP once, we can avoid sequence above. > > > > But we set MMF_OOM_SKIP _after_ the process lost its address space (well > > after the patch which allows to race oom reaper with the exit_mmap). > > > >

Re: [PATCH] oom_reaper: close race without using oom_lock

On Sat 22-07-17 00:18:48, Tetsuo Handa wrote: > Michal Hocko wrote: > > > If we ignore MMF_OOM_SKIP once, we can avoid sequence above. > > > > But we set MMF_OOM_SKIP _after_ the process lost its address space (well > > after the patch which allows to race oom reaper with the exit_mmap). > > > >

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, 2017-07-21 at 17:13 +0200, Borislav Petkov wrote: > On Fri, Jul 21, 2017 at 03:08:41PM +, Kani, Toshimitsu wrote: > > Yes, that is correct.  Corrected errors are reported to the OS when > > they exceeded the platform's threshold. > > Are those thresholds user-configurable? I suppose

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, 2017-07-21 at 17:13 +0200, Borislav Petkov wrote: > On Fri, Jul 21, 2017 at 03:08:41PM +, Kani, Toshimitsu wrote: > > Yes, that is correct.  Corrected errors are reported to the OS when > > they exceeded the platform's threshold. > > Are those thresholds user-configurable? I suppose

[PATCH v2 3/3] ARM: w90x900: normalize clk API

w90x900 still provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent or clk_round_rate functions when a platform lacks those interfaces. This

[PATCH v2 3/3] ARM: w90x900: normalize clk API

w90x900 still provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent or clk_round_rate functions when a platform lacks those interfaces. This

Re: commit 16ecba59 breaks 82574L under heavy load.

On Thu, Jul 20, 2017 at 04:44:55PM -0700, Benjamin Poirier wrote: > Could you please test the following patch and let me know if it: > 1) reduces the interrupt rate of the Other msi-x vector > 2) avoids the link flaps > or > 3) logs some dmesg warnings of the form "Other interrupt with unhandled

Re: commit 16ecba59 breaks 82574L under heavy load.

On Thu, Jul 20, 2017 at 04:44:55PM -0700, Benjamin Poirier wrote: > Could you please test the following patch and let me know if it: > 1) reduces the interrupt rate of the Other msi-x vector > 2) avoids the link flaps > or > 3) logs some dmesg warnings of the form "Other interrupt with unhandled

[PATCH v2 2/3] ARM: sa1100: normalize clk API

sa1100 provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent or clk_round_rate functions when a platform lacks those interfaces. This adds

[PATCH v2 2/3] ARM: sa1100: normalize clk API

sa1100 provides its own variant of the clk API rather than using the generic COMMON_CLK API. This generally works, but it causes some link errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent or clk_round_rate functions when a platform lacks those interfaces. This adds

Re: [PATCH 2/3] ACPI / PM: Split acpi_device_wakeup()

On Fri, Jul 21, 2017 at 3:40 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > To prepare for a subsequent change and make the code somewhat easier > to follow, do the following in the ACPI device wakeup handling code: > > * Replace

Re: [PATCH 2/3] ACPI / PM: Split acpi_device_wakeup()

On Fri, Jul 21, 2017 at 3:40 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > To prepare for a subsequent change and make the code somewhat easier > to follow, do the following in the ACPI device wakeup handling code: > > * Replace wakeup.flags.enabled under struct acpi_device with >

Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Quentin, > The Espressif ESP8089 WiFi chips can be often found in cheap tablets. > There is one in A23 Polaroid tablets for example. > > The chip is often embedded as an eMMC SDIO device. > > The code was taken from an out-of-tree repository and has seen a first > pass in the cleanup

Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Quentin, > The Espressif ESP8089 WiFi chips can be often found in cheap tablets. > There is one in A23 Polaroid tablets for example. > > The chip is often embedded as an eMMC SDIO device. > > The code was taken from an out-of-tree repository and has seen a first > pass in the cleanup

[PATCH v2 1/3] ARM: davinci: normalize clk API

davinci still has its own clk implementation, but lacks a clk_get_parent() helper, which can lead to link errors in randconfig builds. This adds the usual implementation. Acked-by: Sekhar Nori Signed-off-by: Arnd Bergmann --- arch/arm/mach-davinci/clock.c | 9

[PATCH v2 1/3] ARM: davinci: normalize clk API

davinci still has its own clk implementation, but lacks a clk_get_parent() helper, which can lead to link errors in randconfig builds. This adds the usual implementation. Acked-by: Sekhar Nori Signed-off-by: Arnd Bergmann --- arch/arm/mach-davinci/clock.c | 9 + 1 file changed, 9

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: > On Thu, Jul 20, 2017 at 6:41 PM, Jerome Glisse wrote: > > On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: > >> On 2017/7/20 23:03, Jerome Glisse wrote: > >> > On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: > On Thu, Jul 20, 2017 at 6:41 PM, Jerome Glisse wrote: > > On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: > >> On 2017/7/20 23:03, Jerome Glisse wrote: > >> > On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: > >> >>

[RFC 1/2] net-next: add a dma_desc element to struct skb_shared_info

In order to make HW flow offloading work in latest MediaTek silicon we need to propagate part of the RX DMS descriptor to the upper layers populating the flow offload engines HW tables. This patch adds an extra element to struct skb_shared_info allowing the ethernet drivers RX napi code to store

[RFC 1/2] net-next: add a dma_desc element to struct skb_shared_info

In order to make HW flow offloading work in latest MediaTek silicon we need to propagate part of the RX DMS descriptor to the upper layers populating the flow offload engines HW tables. This patch adds an extra element to struct skb_shared_info allowing the ethernet drivers RX napi code to store

[RFC 0/2] net-next: hw flow offloading

Hi, I managed to bring up the flow offloading on latest MedieTek silicon. When enabling HW flow offloading, the traffic coming in on either of the GMACs is first sent to the PPE for processing. Any traffic not offloaded at this point will then be forwarded to the normal RX DMA ring for SW path

[RFC 0/2] net-next: hw flow offloading

Hi, I managed to bring up the flow offloading on latest MedieTek silicon. When enabling HW flow offloading, the traffic coming in on either of the GMACs is first sent to the PPE for processing. Any traffic not offloaded at this point will then be forwarded to the normal RX DMA ring for SW path

[RFC 2/2] net-next: mediatek: populate the shared

When enabling HW flow offloading, the traffic coming in on either of the GMACs is first sent to the PPE for processing. Any traffic not offloaded at this point will then be forwarded to the normal RX DMA ring for SW path processing. In this case the PPE will send additional data inside RXD4 that

[RFC 2/2] net-next: mediatek: populate the shared

When enabling HW flow offloading, the traffic coming in on either of the GMACs is first sent to the PPE for processing. Any traffic not offloaded at this point will then be forwarded to the normal RX DMA ring for SW path processing. In this case the PPE will send additional data inside RXD4 that

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Fri, Jul 21, 2017 at 08:01:07PM +0800, Bob Liu wrote: > On Fri, Jul 21, 2017 at 10:10 AM, Bob Liu wrote: > > On 2017/7/21 9:41, Jerome Glisse wrote: > >> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: > >>> On 2017/7/20 23:03, Jerome Glisse wrote: > On Wed,

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Fri, Jul 21, 2017 at 08:01:07PM +0800, Bob Liu wrote: > On Fri, Jul 21, 2017 at 10:10 AM, Bob Liu wrote: > > On 2017/7/21 9:41, Jerome Glisse wrote: > >> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: > >>> On 2017/7/20 23:03, Jerome Glisse wrote: > On Wed, Jul 19, 2017 at

Re: [PATCH v5 0/3] TPS68470 PMIC drivers

On Fri, Jul 21, 2017 at 5:46 PM, Rajmohan Mani wrote: > This is the patch series for TPS68470 PMIC that works as a camera PMIC. > > The patch series provide the following 3 drivers, to help configure the > voltage regulators, clocks and GPIOs provided by the TPS68470

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Freitag, 21. Juli 2017, 17:09:11 CEST schrieb Arnd Bergmann: Hi Arnd, > On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: > >> Um, the timer is the largest number of interrupts on my system.

Re: [PATCH v5 0/3] TPS68470 PMIC drivers

On Fri, Jul 21, 2017 at 5:46 PM, Rajmohan Mani wrote: > This is the patch series for TPS68470 PMIC that works as a camera PMIC. > > The patch series provide the following 3 drivers, to help configure the > voltage regulators, clocks and GPIOs provided by the TPS68470 PMIC, to be > able to use

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Freitag, 21. Juli 2017, 17:09:11 CEST schrieb Arnd Bergmann: Hi Arnd, > On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: > >> Um, the timer is the largest number of interrupts on my system. Compare: > >>

Re: [PATCH] oom_reaper: close race without using oom_lock

Michal Hocko wrote: > > If we ignore MMF_OOM_SKIP once, we can avoid sequence above. > > But we set MMF_OOM_SKIP _after_ the process lost its address space (well > after the patch which allows to race oom reaper with the exit_mmap). > > > > > Process-1 Process-2 > > > >

Re: [PATCH] oom_reaper: close race without using oom_lock

Michal Hocko wrote: > > If we ignore MMF_OOM_SKIP once, we can avoid sequence above. > > But we set MMF_OOM_SKIP _after_ the process lost its address space (well > after the patch which allows to race oom reaper with the exit_mmap). > > > > > Process-1 Process-2 > > > >

Re: Problem to compile Kernel 3.18.55 in fork.c:341

On 07/21/2017 06:40 AM, Sam Przyswa (Perso) wrote: > Hi all ! > > I try to compile the kernel 3.18.55 I got this error message during 'make > deb-pkg' : > > kernel/built-in.o: In function `dup_task_struct': > /home/samp/kernel/linux-3.18.55/kernel/fork.c:341: undefined reference to >

Re: Problem to compile Kernel 3.18.55 in fork.c:341

On 07/21/2017 06:40 AM, Sam Przyswa (Perso) wrote: > Hi all ! > > I try to compile the kernel 3.18.55 I got this error message during 'make > deb-pkg' : > > kernel/built-in.o: In function `dup_task_struct': > /home/samp/kernel/linux-3.18.55/kernel/fork.c:341: undefined reference to >

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v4

Applied to cgroup/for-4.14. Thanks. -- tejun

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v4

Applied to cgroup/for-4.14. Thanks. -- tejun

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, Jul 21, 2017 at 03:08:41PM +, Kani, Toshimitsu wrote: > Yes, that is correct. Corrected errors are reported to the OS when > they exceeded the platform's threshold. Are those thresholds user-configurable? If not, what are you telling users who want to see *every* corrected error for

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, Jul 21, 2017 at 03:08:41PM +, Kani, Toshimitsu wrote: > Yes, that is correct. Corrected errors are reported to the OS when > they exceeded the platform's threshold. Are those thresholds user-configurable? If not, what are you telling users who want to see *every* corrected error for

Re: [PATCH 0/2] PM / suspend: Messaging updates

On Fri, Jul 21, 2017 at 3:48 PM, Rafael J. Wysocki wrote: > Hi, > > The first patch addresses a potential confusion regarding messages printed by > the suspend core code to the kernel log and the second one adds a pr_fmt() to > kernel/power/suspend.c. > > The patches are on

Re: [PATCH v3 07/16] MIPS: math-emu: <MAX|MIN>.<D|S>: Fix cases of both inputs negative

On Fri, Jul 21, 2017 at 04:09:05PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by ., if both inputs are negative > normal fp numbers. The previous logic did not take into account that > if both inputs have

Re: [PATCH 0/2] PM / suspend: Messaging updates

On Fri, Jul 21, 2017 at 3:48 PM, Rafael J. Wysocki wrote: > Hi, > > The first patch addresses a potential confusion regarding messages printed by > the suspend core code to the kernel log and the second one adds a pr_fmt() to > kernel/power/suspend.c. > > The patches are on top of the series I

Re: [PATCH v3 07/16] MIPS: math-emu: .: Fix cases of both inputs negative

On Fri, Jul 21, 2017 at 04:09:05PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by ., if both inputs are negative > normal fp numbers. The previous logic did not take into account that > if both inputs have the same sign, there should be separate

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: >> Um, the timer is the largest number of interrupts on my system. Compare: >> >> CPU0 CPU1 CPU2 CPU3 >> LOC:6396552

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: >> Um, the timer is the largest number of interrupts on my system. Compare: >> >> CPU0 CPU1 CPU2 CPU3 >> LOC:639655260388656558646

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, 2017-07-21 at 15:47 +0200, Borislav Petkov wrote: > On Fri, Jul 21, 2017 at 10:40:01AM -0300, Mauro Carvalho Chehab > wrote: > > What happens when the error can be corrected? Does it still report > > it to userspace, or just silently hide the error? > > > > If I remember well about a past

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, 2017-07-21 at 15:47 +0200, Borislav Petkov wrote: > On Fri, Jul 21, 2017 at 10:40:01AM -0300, Mauro Carvalho Chehab > wrote: > > What happens when the error can be corrected? Does it still report > > it to userspace, or just silently hide the error? > > > > If I remember well about a past

Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

On Fri, Jul 21, 2017 at 04:35:01PM +0200, Quentin Schulz wrote: > The Espressif ESP8089 WiFi chips can be often found in cheap tablets. > There is one in A23 Polaroid tablets for example. > > The chip is often embedded as an eMMC SDIO device. > > The code was taken from an out-of-tree repository

Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

On Fri, Jul 21, 2017 at 04:35:01PM +0200, Quentin Schulz wrote: > The Espressif ESP8089 WiFi chips can be often found in cheap tablets. > There is one in A23 Polaroid tablets for example. > > The chip is often embedded as an eMMC SDIO device. > > The code was taken from an out-of-tree repository

Re: [PATCH v3 06/16] MIPS: math-emu: <MAX|MAXA|MIN|MINA>.<D|S>: Fix cases of both inputs zero

On Fri, Jul 21, 2017 at 04:09:04PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by ., if both inputs > are zeros. The right behavior in such cases is stated in instruction > reference manual and

Re: [PATCH v3 06/16] MIPS: math-emu: .: Fix cases of both inputs zero

On Fri, Jul 21, 2017 at 04:09:04PM +0200, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fix the value returned by ., if both inputs > are zeros. The right behavior in such cases is stated in instruction > reference manual and is as follows: > >fs ft MAX MIN

Re: [PATCH v5] printk: Add pr_info_show_time

On 07/20/2017 07:00 PM, Luis R. Rodriguez wrote: On Thu, Jul 20, 2017 at 11:24:22AM -0700, Mark Salyzyn wrote: diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 98fe715522e8..0d63c3fb4e24 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -30,6 +30,58 @@ config

Re: [PATCH v5] printk: Add pr_info_show_time

On 07/20/2017 07:00 PM, Luis R. Rodriguez wrote: On Thu, Jul 20, 2017 at 11:24:22AM -0700, Mark Salyzyn wrote: diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 98fe715522e8..0d63c3fb4e24 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -30,6 +30,58 @@ config

Re: [PATCH] oom_reaper: close race without using oom_lock

On Fri 21-07-17 06:47:11, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Wed 19-07-17 05:51:03, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > On Tue 18-07-17 23:06:50, Tetsuo Handa wrote: > > > > > Commit e2fe14564d3316d1 ("oom_reaper: close race with exiting task") > > > > > guarded

Re: [PATCH] oom_reaper: close race without using oom_lock

On Fri 21-07-17 06:47:11, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Wed 19-07-17 05:51:03, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > On Tue 18-07-17 23:06:50, Tetsuo Handa wrote: > > > > > Commit e2fe14564d3316d1 ("oom_reaper: close race with exiting task") > > > > > guarded

Re: [PATCH v1 2/2] 44x/fsp2: enable eMMC arasan for fsp2 platform

On Fri, Jun 30, 2017 at 02:53:31PM +0300, Ivan Mikhaylov wrote: > Add mmc0 changes for enabling arasan emmc and change > defconfig appropriately. > > Signed-off-by: Ivan Mikhaylov > --- > arch/powerpc/boot/dts/fsp2.dts | 33 +- >

Re: [PATCH v1 2/2] 44x/fsp2: enable eMMC arasan for fsp2 platform

On Fri, Jun 30, 2017 at 02:53:31PM +0300, Ivan Mikhaylov wrote: > Add mmc0 changes for enabling arasan emmc and change > defconfig appropriately. > > Signed-off-by: Ivan Mikhaylov > --- > arch/powerpc/boot/dts/fsp2.dts | 33 +- >

[PATCH] arm: mark kprobe templates as arrays, not single elements.

As same as commit 54a7d50b9205 ("x86: mark kprobe templates as character arrays, not single characters") did, to prevent miss detection of the string fortification, make the template symbols as kprobe_opecode_t arrays, instead of single kprobe_opecode_t. Unlike x86, arm has not supported the

[PATCH] arm: mark kprobe templates as arrays, not single elements.

As same as commit 54a7d50b9205 ("x86: mark kprobe templates as character arrays, not single characters") did, to prevent miss detection of the string fortification, make the template symbols as kprobe_opecode_t arrays, instead of single kprobe_opecode_t. Unlike x86, arm has not supported the

[PATCH] iwlwifi: Demote messages about fw flags size to info

These messages are not reporting a real error, just the fact that the firmware knows about more flags then the driver. Currently these messages are presented to the user during boot if there is no bootsplash covering the console, sometimes even if the boot splash is enabled but has not started

[PATCH] iwlwifi: Demote messages about fw flags size to info

These messages are not reporting a real error, just the fact that the firmware knows about more flags then the driver. Currently these messages are presented to the user during boot if there is no bootsplash covering the console, sometimes even if the boot splash is enabled but has not started

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