Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: > On 12.01.2018 22:55, Jason Baron wrote: >> Hi, >>   While using livepatch, I found that when doing cumulative patches, >> if a patched >> function is completed reverted by a subsequent patch (back to its >> original state) >> livepatch does not

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: > On 12.01.2018 22:55, Jason Baron wrote: >> Hi, >>   While using livepatch, I found that when doing cumulative patches, >> if a patched >> function is completed reverted by a subsequent patch (back to its >> original state) >> livepatch does not

Hello There

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financecapital...@mail.com --- This email has been checked for viruses by Avast antivirus

Hello There

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financecapital...@mail.com --- This email has been checked for viruses by Avast antivirus

Re: [PATCH] smc: return boolean instead of integer in using_ipsec

Hi Ursula, Quoting Ursula Braun : On 01/19/2018 12:33 AM, Gustavo A. R. Silva wrote: Return statements in functions returning bool should use true/false instead of 1/0. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva

Re: [PATCH] smc: return boolean instead of integer in using_ipsec

Hi Ursula, Quoting Ursula Braun : On 01/19/2018 12:33 AM, Gustavo A. R. Silva wrote: Return statements in functions returning bool should use true/false instead of 1/0. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- net/smc/smc.h | 2 +- 1 file

Re: [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)

On 01/19/2018 12:56 PM, Andrew Morton wrote: > Should KPTI have a MAINTAINERS entry? > > Neil Berrington (cc'ed) is reporting "Double fault in load_new_mm_cr3 with > KPTI > enabled" at https://bugzilla.kernel.org/show_bug.cgi?id=198517 Seems sane to me. There have been quite a few patches I

Re: [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)

On 01/19/2018 12:56 PM, Andrew Morton wrote: > Should KPTI have a MAINTAINERS entry? > > Neil Berrington (cc'ed) is reporting "Double fault in load_new_mm_cr3 with > KPTI > enabled" at https://bugzilla.kernel.org/show_bug.cgi?id=198517 Seems sane to me. There have been quite a few patches I

Re: [PATCH 22/22] signal: Unify and correct copy_siginfo_to_user32

Al Viro writes: > On Mon, Jan 15, 2018 at 06:40:09PM -0600, Eric W. Biederman wrote: >> Among the existing architecture specific versions of >> copy_siginfo_to_user32 there are several different implementation >> problems. Some architectures fail to handle all of the

Re: [PATCH 22/22] signal: Unify and correct copy_siginfo_to_user32

Al Viro writes: > On Mon, Jan 15, 2018 at 06:40:09PM -0600, Eric W. Biederman wrote: >> Among the existing architecture specific versions of >> copy_siginfo_to_user32 there are several different implementation >> problems. Some architectures fail to handle all of the cases in in >> the siginfo

Re: [PATCH v3 3/9] doc: dt-bindings: Add doc for Ingenic TCU IRQ driver

On Wed, Jan 10, 2018 at 11:48:32PM +0100, Paul Cercueil wrote: > Add documentation about how to properly use the Ingenic TCU > (Timer/Counter Unit) IRQ driver from devicetree. Drop "doc: " from the subject in this and others. > Signed-off-by: Paul Cercueil > --- >

Re: [PATCH v3 3/9] doc: dt-bindings: Add doc for Ingenic TCU IRQ driver

On Wed, Jan 10, 2018 at 11:48:32PM +0100, Paul Cercueil wrote: > Add documentation about how to properly use the Ingenic TCU > (Timer/Counter Unit) IRQ driver from devicetree. Drop "doc: " from the subject in this and others. > Signed-off-by: Paul Cercueil > --- >

Re: [PATCH] NTB: ntb_perf: fix cast to restricted __le32

On Fri, Jan 19, 2018 at 09:42:17PM +0100, Arnd Bergmann wrote: > On Fri, Jan 19, 2018 at 6:30 PM, Serge Semin wrote: > > Sparse is whining about the u32 and __le32 mixed usage in the > > driver. > > > > drivers/ntb/test/ntb_perf.c:288:21: warning: cast to

Re: [PATCH] NTB: ntb_perf: fix cast to restricted __le32

On Fri, Jan 19, 2018 at 09:42:17PM +0100, Arnd Bergmann wrote: > On Fri, Jan 19, 2018 at 6:30 PM, Serge Semin wrote: > > Sparse is whining about the u32 and __le32 mixed usage in the > > driver. > > > > drivers/ntb/test/ntb_perf.c:288:21: warning: cast to restricted __le32 > >

Re: [RESEND RFC PATCH 0/2] fixing the gpio ownership

On Thu, Jan 18, 2018 at 4:12 PM, Ludovic Desroches wrote: > On Thu, Jan 18, 2018 at 11:16:44AM +0100, Linus Walleij wrote: >> > It seems >> > that more and more drivers are converted to use GPIO descriptors so there >> > is >> > some hope. >> >> Yeah I'm doing

Re: [RESEND RFC PATCH 0/2] fixing the gpio ownership

On Thu, Jan 18, 2018 at 4:12 PM, Ludovic Desroches wrote: > On Thu, Jan 18, 2018 at 11:16:44AM +0100, Linus Walleij wrote: >> > It seems >> > that more and more drivers are converted to use GPIO descriptors so there >> > is >> > some hope. >> >> Yeah I'm doing this when I have time. There is

Re: [PATCH 4/4] dt-bindings: pwm-backlight: move brightness-levels to optional.

On Wed, Jan 10, 2018 at 11:30:46PM +0100, Enric Balletbo i Serra wrote: > The patch 'backlight: pwm_bl: compute brightness of LED linearly to > human eye' introduced a default brightness-levels table that is used > when brightness-levels is not availablel in the dts so move move

Re: [PATCH 4/4] dt-bindings: pwm-backlight: move brightness-levels to optional.

On Wed, Jan 10, 2018 at 11:30:46PM +0100, Enric Balletbo i Serra wrote: > The patch 'backlight: pwm_bl: compute brightness of LED linearly to > human eye' introduced a default brightness-levels table that is used > when brightness-levels is not availablel in the dts so move move

Re: [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)

Should KPTI have a MAINTAINERS entry? Neil Berrington (cc'ed) is reporting "Double fault in load_new_mm_cr3 with KPTI enabled" at https://bugzilla.kernel.org/show_bug.cgi?id=198517

Re: [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)

Should KPTI have a MAINTAINERS entry? Neil Berrington (cc'ed) is reporting "Double fault in load_new_mm_cr3 with KPTI enabled" at https://bugzilla.kernel.org/show_bug.cgi?id=198517

Re: [kernel-hardening] [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references

On Fri, Jan 19, 2018 at 10:18 AM, Linus Torvalds wrote: > On Fri, Jan 19, 2018 at 2:20 AM, Jann Horn wrote: >>> + \ >>> + __u._ptr = _arr + (_i & _mask);

Re: [kernel-hardening] [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references

On Fri, Jan 19, 2018 at 10:18 AM, Linus Torvalds wrote: > On Fri, Jan 19, 2018 at 2:20 AM, Jann Horn wrote: >>> + \ >>> + __u._ptr = _arr + (_i & _mask); \ >>> + __u._bit &= _mask;

Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable

On Wed, 17 Jan 2018, David Rientjes wrote: > Yes, this is a valid point. The policy of "tree" and "all" are identical > policies and then the mechanism differs wrt to whether one process is > killed or all eligible processes are killed, respectively. My motivation > for this was to avoid

Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable

On Wed, 17 Jan 2018, David Rientjes wrote: > Yes, this is a valid point. The policy of "tree" and "all" are identical > policies and then the mechanism differs wrt to whether one process is > killed or all eligible processes are killed, respectively. My motivation > for this was to avoid

Re: [PATCH 2/4] dt-bindings: pwm-backlight: add a num-interpolation-steps property.

On Wed, Jan 10, 2018 at 11:30:44PM +0100, Enric Balletbo i Serra wrote: > The num-interpolated-steps property specifies the number of > interpolated steps between each value of brightness-level table. This is > useful for high resolution PWMs to not have to list out every possible > value in the

Re: [PATCH 2/4] dt-bindings: pwm-backlight: add a num-interpolation-steps property.

On Wed, Jan 10, 2018 at 11:30:44PM +0100, Enric Balletbo i Serra wrote: > The num-interpolated-steps property specifies the number of > interpolated steps between each value of brightness-level table. This is > useful for high resolution PWMs to not have to list out every possible > value in the

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

On Fri, Jan 19, 2018 at 12:50 PM, Stephane Eranian wrote: > On Fri, Jan 19, 2018 at 12:24 PM, Andi Kleen wrote: >>> Oh, think a bit more. >>> I think we cannot do the same thing as we did for CPU PMU's fixed counters. >>> >>> The counters here are free

[PATCH] IOMMU-Tegra: gart: Delete two error messages for a failed memory allocation in tegra_gart_probe()

From: Markus Elfring Date: Fri, 19 Jan 2018 21:44:31 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] IOMMU-Tegra: gart: Delete two error messages for a failed memory allocation in tegra_gart_probe()

From: Markus Elfring Date: Fri, 19 Jan 2018 21:44:31 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/iommu/tegra-gart.c | 8 ++-- 1 file changed, 2

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

On Fri, Jan 19, 2018 at 12:50 PM, Stephane Eranian wrote: > On Fri, Jan 19, 2018 at 12:24 PM, Andi Kleen wrote: >>> Oh, think a bit more. >>> I think we cannot do the same thing as we did for CPU PMU's fixed counters. >>> >>> The counters here are free running counters. They cannot be

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

On Fri, Jan 19, 2018 at 12:24 PM, Andi Kleen wrote: >> Oh, think a bit more. >> I think we cannot do the same thing as we did for CPU PMU's fixed counters. >> >> The counters here are free running counters. They cannot be start/stop. > > Yes free running counter have

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

On Fri, Jan 19, 2018 at 12:24 PM, Andi Kleen wrote: >> Oh, think a bit more. >> I think we cannot do the same thing as we did for CPU PMU's fixed counters. >> >> The counters here are free running counters. They cannot be start/stop. > > Yes free running counter have completely different

[PATCH 2/3] platform/x86: GPD pocket fan: Use a min-speed of 2 while charging

Newer versions of the GPD pocket BIOS set the fan-speed to 2 when a charger gets plugged in while the device is off. Mirror this in our fan driver and use a minimum speed of 2 while charging, Cc: James Suggested-by: James Signed-off-by: Hans de Goede

[PATCH 2/3] platform/x86: GPD pocket fan: Use a min-speed of 2 while charging

Newer versions of the GPD pocket BIOS set the fan-speed to 2 when a charger gets plugged in while the device is off. Mirror this in our fan driver and use a minimum speed of 2 while charging, Cc: James Suggested-by: James Signed-off-by: Hans de Goede --- drivers/platform/x86/gpd-pocket-fan.c

[PATCH 3/3] platform/x86: GPD pocket fan: Stop work on suspend

Stop the work on suspend, otherwise it may run between our suspend method running and the system suspending, possibly restarting the fan which we've just stopped. Note we already requeue the work on resume, so that we get a fresh speed at resume. Signed-off-by: Hans de Goede

[PATCH 3/3] platform/x86: GPD pocket fan: Stop work on suspend

Stop the work on suspend, otherwise it may run between our suspend method running and the system suspending, possibly restarting the fan which we've just stopped. Note we already requeue the work on resume, so that we get a fresh speed at resume. Signed-off-by: Hans de Goede ---

[PATCH 1/3] platform/x86: GPD pocket fan: Set speed to max on get_temp failure

When we fail to get the temperature, assume the worst and set the speed to max. While at it introduce a define for MAX_SPEED. Cc: James Suggested-by: James Signed-off-by: Hans de Goede --- drivers/platform/x86/gpd-pocket-fan.c

[PATCH 1/3] platform/x86: GPD pocket fan: Set speed to max on get_temp failure

When we fail to get the temperature, assume the worst and set the speed to max. While at it introduce a define for MAX_SPEED. Cc: James Suggested-by: James Signed-off-by: Hans de Goede --- drivers/platform/x86/gpd-pocket-fan.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)

Re: [PATCH] NTB: ntb_perf: fix cast to restricted __le32

On Fri, Jan 19, 2018 at 6:30 PM, Serge Semin wrote: > Sparse is whining about the u32 and __le32 mixed usage in the > driver. > > drivers/ntb/test/ntb_perf.c:288:21: warning: cast to restricted __le32 > drivers/ntb/test/ntb_perf.c:295:37: warning: incorrect type in

Re: [PATCH] NTB: ntb_perf: fix cast to restricted __le32

On Fri, Jan 19, 2018 at 6:30 PM, Serge Semin wrote: > Sparse is whining about the u32 and __le32 mixed usage in the > driver. > > drivers/ntb/test/ntb_perf.c:288:21: warning: cast to restricted __le32 > drivers/ntb/test/ntb_perf.c:295:37: warning: incorrect type in argument 4 > (different base

[PATCH net-next] hv_netvsc: Use the num_online_cpus() for channel limit

From: Haiyang Zhang Since we no longer localize channel/CPU affiliation within one NUMA node, num_online_cpus() is used as the number of channel cap, instead of the number of processors in a NUMA node. This patch allows a bigger range for tuning the number of channels.

[PATCH net-next] hv_netvsc: Use the num_online_cpus() for channel limit

From: Haiyang Zhang Since we no longer localize channel/CPU affiliation within one NUMA node, num_online_cpus() is used as the number of channel cap, instead of the number of processors in a NUMA node. This patch allows a bigger range for tuning the number of channels. Signed-off-by: Haiyang

[PATCH net-next] hv_netvsc: Use the num_online_cpus() for channel limit

From: Haiyang Zhang Since we no longer localize channel/CPU affiliation within one NUMA node, num_online_cpus() is used as the number of channel cap, instead of the number of processors in a NUMA node. This patch allows a bigger range for tuning the number of channels.

[PATCH net-next] hv_netvsc: Use the num_online_cpus() for channel limit

From: Haiyang Zhang Since we no longer localize channel/CPU affiliation within one NUMA node, num_online_cpus() is used as the number of channel cap, instead of the number of processors in a NUMA node. This patch allows a bigger range for tuning the number of channels. Signed-off-by: Haiyang

Re: [PATCH 30/35] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On 01/18/2018 08:03 PM, Kevin Easton wrote: > On Thu, Jan 18, 2018 at 04:38:32PM -0800, Tim Chen wrote: >> On 01/18/2018 05:48 AM, Peter Zijlstra wrote: >>> >>> + /* >>> +* Avoid user/user BTB poisoning by flushing the branch >>> predictor >>> +* when switching

Re: [PATCH 30/35] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On 01/18/2018 08:03 PM, Kevin Easton wrote: > On Thu, Jan 18, 2018 at 04:38:32PM -0800, Tim Chen wrote: >> On 01/18/2018 05:48 AM, Peter Zijlstra wrote: >>> >>> + /* >>> +* Avoid user/user BTB poisoning by flushing the branch >>> predictor >>> +* when switching

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> Oh, think a bit more. > I think we cannot do the same thing as we did for CPU PMU's fixed counters. > > The counters here are free running counters. They cannot be start/stop. Yes free running counter have completely different semantics. They need a separate event code. -Andi

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> Oh, think a bit more. > I think we cannot do the same thing as we did for CPU PMU's fixed counters. > > The counters here are free running counters. They cannot be start/stop. Yes free running counter have completely different semantics. They need a separate event code. -Andi

Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver

Hi Tony, On 01/16/2018 05:22 PM, Tony Lindgren wrote: > Hi, > > * Suman Anna [180116 21:23]: >> While this adaptation is very simple for replacing the RSTCTRL registers >> from the hwmod data into an existing reset driver, I am afraid that it >> doesn't fit well when you want to

Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver

Hi Tony, On 01/16/2018 05:22 PM, Tony Lindgren wrote: > Hi, > > * Suman Anna [180116 21:23]: >> While this adaptation is very simple for replacing the RSTCTRL registers >> from the hwmod data into an existing reset driver, I am afraid that it >> doesn't fit well when you want to use the reset

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

On Fri, Jan 19, 2018 at 10:00 AM, Liang, Kan wrote: > > > On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan wrote: > > >> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote: > > >> > > > > >> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

On Fri, Jan 19, 2018 at 10:00 AM, Liang, Kan wrote: > > > On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan wrote: > > >> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote: > > >> > > > > >> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote: > > >> > > > In the uncore document,

Re: [PATCH] dt-bindings: Nokia N9 audio support

On Wed, Jan 10, 2018 at 09:53:15AM +0100, Pavel Machek wrote: > From: Filip Matijević > > Add bindings for Nokia N9 audio components. > > Signed-off-by: Filip Matijević > Signed-off-by: Pavel Machek > > diff --git

Re: [PATCH] dt-bindings: Nokia N9 audio support

On Wed, Jan 10, 2018 at 09:53:15AM +0100, Pavel Machek wrote: > From: Filip Matijević > > Add bindings for Nokia N9 audio components. > > Signed-off-by: Filip Matijević > Signed-off-by: Pavel Machek > > diff --git a/Documentation/devicetree/bindings/media/ti-wl1273.txt >

Re: [PATCH] staging: android: ion: Zero CMA allocated memory

On Fri, Jan 19, 2018 at 11:16:47AM -0800, Liam Mark wrote: > Since the CMA API is now used directly the allocated memory is no longer > automatically zeroed. > > Explicitly zero CMA allocated memory to ensure that no data is exposed > to userspace. > > Change-Id:

Re: [PATCH] staging: android: ion: Zero CMA allocated memory

On Fri, Jan 19, 2018 at 11:16:47AM -0800, Liam Mark wrote: > Since the CMA API is now used directly the allocated memory is no longer > automatically zeroed. > > Explicitly zero CMA allocated memory to ensure that no data is exposed > to userspace. > > Change-Id:

Re: [tip:sched/core] sched/rt: Simplify the IPI based RT balancing logic

On Sat, 20 Jan 2018 00:27:56 +0530 Pavan Kondeti wrote: > Hi Steve, > > Thanks for the patch. > > On Fri, Jan 19, 2018 at 01:12:54PM -0500, Steven Rostedt wrote: > > On Fri, 19 Jan 2018 13:11:21 -0500 > > Steven Rostedt wrote: > > > > > void

Re: [tip:sched/core] sched/rt: Simplify the IPI based RT balancing logic

On Sat, 20 Jan 2018 00:27:56 +0530 Pavan Kondeti wrote: > Hi Steve, > > Thanks for the patch. > > On Fri, Jan 19, 2018 at 01:12:54PM -0500, Steven Rostedt wrote: > > On Fri, 19 Jan 2018 13:11:21 -0500 > > Steven Rostedt wrote: > > > > > void rto_push_irq_work_func(struct irq_work *work) >

Re: [PATCH 1/2] virtio: allow to detach a buffer from the virtqueue

On Wed, Dec 20, 2017 at 06:46:42PM +0100, Greg Kurz wrote: > It is possible for a device to stop using buffers without pushing them > back to the driver. This is the case for example with the 9p virtio > device: if the driver flushes an in-flight request, the 9p specification > specification [*]

Re: [PATCH 1/2] virtio: allow to detach a buffer from the virtqueue

On Wed, Dec 20, 2017 at 06:46:42PM +0100, Greg Kurz wrote: > It is possible for a device to stop using buffers without pushing them > back to the driver. This is the case for example with the 9p virtio > device: if the driver flushes an in-flight request, the 9p specification > specification [*]

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> But in this case it actually is the example to follow as told >>> previously. >>> >>> NAK again for these chained dma ops that only create problems. >> >> Care to explain what

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> But in this case it actually is the example to follow as told >>> previously. >>> >>> NAK again for these chained dma ops that only create problems. >> >> Care to explain what

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On Fri, 2018-01-19 at 15:34 +0800, Ming Lei wrote: > Could you explain a bit when SCSI target replies with BUSY very often? > > Inside initiator, we have limited the max per-LUN requests and per-host > requests already before calling .queue_rq(). That's correct. However, when a SCSI initiator

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On Fri, 2018-01-19 at 15:34 +0800, Ming Lei wrote: > Could you explain a bit when SCSI target replies with BUSY very often? > > Inside initiator, we have limited the max per-LUN requests and per-host > requests already before calling .queue_rq(). That's correct. However, when a SCSI initiator

Re: [PATCH 3/4] pwm: jz4740: Add support for devicetree

On Sat, Jan 06, 2018 at 05:58:42PM +0100, Paul Cercueil wrote: > Add support for probing the pwm-jz4740 directly from devicetree. > > Signed-off-by: Paul Cercueil > --- > .../devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt | 25 > ++ >

Re: [PATCH 3/4] pwm: jz4740: Add support for devicetree

On Sat, Jan 06, 2018 at 05:58:42PM +0100, Paul Cercueil wrote: > Add support for probing the pwm-jz4740 directly from devicetree. > > Signed-off-by: Paul Cercueil > --- > .../devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt | 25 > ++ > drivers/pwm/pwm-jz4740.c

[PATCH 7/7] Input: libps2 - relax command byte ACK handling

When we probe PS/2 devices we first issue "Get ID" command and only if we receive what we consider a valid keyboard or mouse ID we disable the device and continue with protocol detection. That means that the device may be transmitting motion or keystroke data, while we expect ACK response.

[PATCH 7/7] Input: libps2 - relax command byte ACK handling

When we probe PS/2 devices we first issue "Get ID" command and only if we receive what we consider a valid keyboard or mouse ID we disable the device and continue with protocol detection. That means that the device may be transmitting motion or keystroke data, while we expect ACK response.

[PATCH 2/7] Input: libps2 - use u8 for byte data

Instead of using unsigned char for the byte data switch to using u8. Also use unsigned int for the command codes and timeouts, and have ps2_handle_ack() and ps2_handle_response() return bool instead of int, as they do not return error codes but rather signal whether a byte was handled or not

[PATCH 2/7] Input: libps2 - use u8 for byte data

Instead of using unsigned char for the byte data switch to using u8. Also use unsigned int for the command codes and timeouts, and have ps2_handle_ack() and ps2_handle_response() return bool instead of int, as they do not return error codes but rather signal whether a byte was handled or not

[PATCH 5/7] Input: libps2 - add debugging statements

Debugging via i8042.debug and analyzing raw PS/2 data stream may be cumbersome as you need to locate the boundaries of commands, decipher the sliced commands, etc, etc. Let's add a bit more high level debug statements for ps2_sendbyte(), ps2_command(), and ps2_sliced_command(). We do not

[PATCH 5/7] Input: libps2 - add debugging statements

Debugging via i8042.debug and analyzing raw PS/2 data stream may be cumbersome as you need to locate the boundaries of commands, decipher the sliced commands, etc, etc. Let's add a bit more high level debug statements for ps2_sendbyte(), ps2_command(), and ps2_sliced_command(). We do not

[PATCH 6/7] Input: libps2 - support retransmission of command data

The devices are allowed to respond to either command byte or command parameter with a NAK (0xfe), and the host is supposed to resend the "correct" byte. The device then will either respond with ACK or ERR (0xfc). Let's teach libps2 to handle the NAK responses properly, so that individual drivers

[PATCH 6/7] Input: libps2 - support retransmission of command data

The devices are allowed to respond to either command byte or command parameter with a NAK (0xfe), and the host is supposed to resend the "correct" byte. The device then will either respond with ACK or ERR (0xfc). Let's teach libps2 to handle the NAK responses properly, so that individual drivers

[PATCH 3/7] Input: libps2 - use BIT() for bitmask constants

Let's explicitly document bit numbers with BIT() macro. Signed-off-by: Dmitry Torokhov --- include/linux/libps2.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/libps2.h b/include/linux/libps2.h index

[PATCH 4/7] Input: psmouse - move sliced command implementation to libps2

In preparation to adding some debugging statements to PS/2 control sequences let's move psmouse_sliced_command() into libps2 and rename it to ps2_sliced_command(). Signed-off-by: Dmitry Torokhov --- drivers/input/mouse/elantech.c | 12 ++--

[PATCH 3/7] Input: libps2 - use BIT() for bitmask constants

Let's explicitly document bit numbers with BIT() macro. Signed-off-by: Dmitry Torokhov --- include/linux/libps2.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/libps2.h b/include/linux/libps2.h index 365c50b097ded..649295a5ff47d 100644 ---

[PATCH 4/7] Input: psmouse - move sliced command implementation to libps2

In preparation to adding some debugging statements to PS/2 control sequences let's move psmouse_sliced_command() into libps2 and rename it to ps2_sliced_command(). Signed-off-by: Dmitry Torokhov --- drivers/input/mouse/elantech.c | 12 ++-- drivers/input/mouse/logips2pp.c| 2 +-

[PATCH 1/7] Input: libps2 - fix switch statement formatting

Individual labels of switch statements should have the same indentation level as the switch statement itself. Signed-off-by: Dmitry Torokhov --- drivers/input/serio/libps2.c | 131 +-- 1 file changed, 65 insertions(+), 66

[PATCH 0/7] libps2 facelift

Hi, The main reason for the patch series is to have a bit more manageable debug info for PS/2 init sequence: raw i8042 debug is way too noisy, one has to decode sliced commands by hand, etc, etc. With proposed changes you get a nice parsed command flow: [14421.985416] __ps2_command: psmouse

[PATCH 1/7] Input: libps2 - fix switch statement formatting

Individual labels of switch statements should have the same indentation level as the switch statement itself. Signed-off-by: Dmitry Torokhov --- drivers/input/serio/libps2.c | 131 +-- 1 file changed, 65 insertions(+), 66 deletions(-) diff --git

[PATCH 0/7] libps2 facelift

Hi, The main reason for the patch series is to have a bit more manageable debug info for PS/2 init sequence: raw i8042 debug is way too noisy, one has to decode sliced commands by hand, etc, etc. With proposed changes you get a nice parsed command flow: [14421.985416] __ps2_command: psmouse

[PATCH] IRQ-Renesas: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Fri, 19 Jan 2018 20:32:04 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] IRQ-Renesas: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Fri, 19 Jan 2018 20:32:04 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/irqchip/irq-renesas-intc-irqpin.c | 4 +---

Re: [PATCH][devlink-next] devlink: make functions a couple of new functions static

From: Colin King Date: Wed, 17 Jan 2018 11:23:03 + > From: Colin Ian King > > The functions devlink_resource_find and devlink_resource_validate_children > are local to the source and do not need to be in global scope, so make > them

Re: [PATCH][devlink-next] devlink: make functions a couple of new functions static

From: Colin King Date: Wed, 17 Jan 2018 11:23:03 + > From: Colin Ian King > > The functions devlink_resource_find and devlink_resource_validate_children > are local to the source and do not need to be in global scope, so make > them static. > > Cleans up sparse warnings: > symbol

Re: [PATCH][next] mlxsw: spectrum: make function mlxsw_sp_kvdl_part_occ static

From: Colin King Date: Wed, 17 Jan 2018 10:57:46 + > From: Colin Ian King > > The function mlxsw_sp_kvdl_part_occ is local to the source and does > not need to be in global scope, so make it static. > > Cleans up sparse warning: >

Re: [PATCH][next] mlxsw: spectrum: make function mlxsw_sp_kvdl_part_occ static

From: Colin King Date: Wed, 17 Jan 2018 10:57:46 + > From: Colin Ian King > > The function mlxsw_sp_kvdl_part_occ is local to the source and does > not need to be in global scope, so make it static. > > Cleans up sparse warning: > symbol 'mlxsw_sp_kvdl_part_occ' was not declared. Should

Re: [PATCH] arc: fix iounmap prototype

On 01/02/2018 06:23 AM, Geert Uytterhoeven wrote: Hi Arnd, On Tue, Jan 2, 2018 at 12:01 PM, Arnd Bergmann wrote: The missing 'volatile' keyword on the iounmap argument leads to lots of harmless warnings in an allmodconfig build: sound/pci/echoaudio/echoaudio.c:1879:10:

Re: [PATCH] arc: fix iounmap prototype

On 01/02/2018 06:23 AM, Geert Uytterhoeven wrote: Hi Arnd, On Tue, Jan 2, 2018 at 12:01 PM, Arnd Bergmann wrote: The missing 'volatile' keyword on the iounmap argument leads to lots of harmless warnings in an allmodconfig build: sound/pci/echoaudio/echoaudio.c:1879:10: warning: passing

Possible Memory Leak in KCOV Linux 4.15-rc1

Hi Dmitry, I added support for kcov in strace and I have been tracing a fairly large program but after a little while, I notice that when I mmap a new cover buffer, the call fails with ENOMEM. After killing the program, I try and rerun and I notice that there is nearly no memory on the system.

Possible Memory Leak in KCOV Linux 4.15-rc1

Hi Dmitry, I added support for kcov in strace and I have been tracing a fairly large program but after a little while, I notice that when I mmap a new cover buffer, the call fails with ENOMEM. After killing the program, I try and rerun and I notice that there is nearly no memory on the system.

Re: [PATCH v2] ARC: Force disable IOC if we don't want to use it

Hi Vineet, On Fri, 2018-01-19 at 11:17 -0800, Vineet Gupta wrote: > On 12/18/2017 07:29 AM, Alexey Brodkin wrote: > > If software that was executed before Linux kernel [like boot-ROM or > > bootloader] enabled IOC but we'd like to not use it [mostly for > > debugging of weird DMA issues] we

Re: [PATCH v2] ARC: Force disable IOC if we don't want to use it

Hi Vineet, On Fri, 2018-01-19 at 11:17 -0800, Vineet Gupta wrote: > On 12/18/2017 07:29 AM, Alexey Brodkin wrote: > > If software that was executed before Linux kernel [like boot-ROM or > > bootloader] enabled IOC but we'd like to not use it [mostly for > > debugging of weird DMA issues] we

Re: [PATCH v3 1/8] dt-bindings: mips: Add bindings for Microsemi SoCs

On Tue, Jan 16, 2018 at 11:12:33AM +0100, Alexandre Belloni wrote: > Add bindings for Microsemi SoCs. Currently only Ocelot is supported. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Signed-off-by: Alexandre Belloni > --- >

Re: [PATCH v3 1/8] dt-bindings: mips: Add bindings for Microsemi SoCs

On Tue, Jan 16, 2018 at 11:12:33AM +0100, Alexandre Belloni wrote: > Add bindings for Microsemi SoCs. Currently only Ocelot is supported. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Signed-off-by: Alexandre Belloni > --- > Documentation/devicetree/bindings/mips/mscc.txt | 44 >

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 12.01.2018 22:55, Jason Baron wrote: Hi, While using livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion to its original state. Specifically, if patch A

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 12.01.2018 22:55, Jason Baron wrote: Hi, While using livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion to its original state. Specifically, if patch A

Re: [PATCH v4 2/8] dt-bindings: pci: Add DT docs for Brcmstb PCIe device

On Mon, Jan 15, 2018 at 06:28:39PM -0500, Jim Quinlan wrote: > The DT bindings description of the Brcmstb PCIe device is described. This > node can be used by almost all Broadcom settop box chips, using > ARM, ARM64, or MIPS CPU architectures. > > Signed-off-by: Jim Quinlan

Re: [PATCH v4 2/8] dt-bindings: pci: Add DT docs for Brcmstb PCIe device

On Mon, Jan 15, 2018 at 06:28:39PM -0500, Jim Quinlan wrote: > The DT bindings description of the Brcmstb PCIe device is described. This > node can be used by almost all Broadcom settop box chips, using > ARM, ARM64, or MIPS CPU architectures. > > Signed-off-by: Jim Quinlan > --- >

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