Re: [RFC] capabilities: add capability cgroup controller

On Wed, Jun 22, 2016 at 5:01 PM, Serge E. Hallyn wrote: > Quoting Kees Cook (keesc...@chromium.org): >> On Wed, Jun 22, 2016 at 11:17 AM, Serge E. Hallyn wrote: >> > Quoting Topi Miettinen (toiwo...@gmail.com): >> >> On 06/22/16 17:14, Serge E. Hallyn wrote:

Re: [RFC] capabilities: add capability cgroup controller

On Wed, Jun 22, 2016 at 5:01 PM, Serge E. Hallyn wrote: > Quoting Kees Cook (keesc...@chromium.org): >> On Wed, Jun 22, 2016 at 11:17 AM, Serge E. Hallyn wrote: >> > Quoting Topi Miettinen (toiwo...@gmail.com): >> >> On 06/22/16 17:14, Serge E. Hallyn wrote: >> >> > Quoting Topi Miettinen

Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass off_t

On Tue, Jun 21, 2016 at 10:35:27AM +, Joseph Myers wrote: > On Tue, 21 Jun 2016, Yury Norov wrote: > > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate64.c > > create mode 100644

Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass off_t

On Tue, Jun 21, 2016 at 10:35:27AM +, Joseph Myers wrote: > On Tue, 21 Jun 2016, Yury Norov wrote: > > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate64.c > > create mode 100644

[PATCH 1/2] net: thunderx: Fix link status reporting

From: Sunil Goutham Check for SMU RX local/remote faults along with SPU LINK status. Otherwise at times link is UP at our end but DOWN at link partner's side. Also due to an issue in BGX it's rarely seen that initialization doesn't happen properly and SMU RX reports faults

[PATCH 1/2] net: thunderx: Fix link status reporting

From: Sunil Goutham Check for SMU RX local/remote faults along with SPU LINK status. Otherwise at times link is UP at our end but DOWN at link partner's side. Also due to an issue in BGX it's rarely seen that initialization doesn't happen properly and SMU RX reports faults with everything fine

[PATCH 2/2] net: thunderx: Fix TL4 configuration for secondary Qsets

From: Sunil Goutham TL4 calculation for a given SQ of secondary Qsets is incorrect and goes out of bounds and also for some SQ's TL4 chosen will transmit data via a different BGX interface and not same as primary Qset's interface. This patch fixes this issue.

[PATCH 2/2] net: thunderx: Fix TL4 configuration for secondary Qsets

From: Sunil Goutham TL4 calculation for a given SQ of secondary Qsets is incorrect and goes out of bounds and also for some SQ's TL4 chosen will transmit data via a different BGX interface and not same as primary Qset's interface. This patch fixes this issue. Signed-off-by: Sunil Goutham ---

[PATCH 0/2] net: thunderx: Miscellaneous fixes

From: Sunil Goutham This 2 patch series fixes issues w.r.t physical link status reporting and transmit datapath configuration for secondary qsets. Sunil Goutham (2): net: thunderx: Fix link status reporting net: thunderx: Fix TL4 configuration for secondary Qsets

[PATCH 0/2] net: thunderx: Miscellaneous fixes

From: Sunil Goutham This 2 patch series fixes issues w.r.t physical link status reporting and transmit datapath configuration for secondary qsets. Sunil Goutham (2): net: thunderx: Fix link status reporting net: thunderx: Fix TL4 configuration for secondary Qsets

[PATCH v5] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

When decoding the perf_regs mask in regs_dump__printf(), we loop through the mask using find_first_bit and find_next_bit functions. "mask" is of type "u64", but sent as a "unsigned long *" to lib functions along with sizeof(). While the exisitng code works fine in most of the case, the logic is

[PATCH v5] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

When decoding the perf_regs mask in regs_dump__printf(), we loop through the mask using find_first_bit and find_next_bit functions. "mask" is of type "u64", but sent as a "unsigned long *" to lib functions along with sizeof(). While the exisitng code works fine in most of the case, the logic is

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

- Original Message - From: "Dave Young" To: "Thiago Jung Bauermann" Cc: linuxppc-...@lists.ozlabs.org, ke...@lists.infradead.org, linux-kernel@vger.kernel.org, "Eric Biederman" Sent: Thursday, June 23, 2016

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

- Original Message - From: "Dave Young" To: "Thiago Jung Bauermann" Cc: linuxppc-...@lists.ozlabs.org, ke...@lists.infradead.org, linux-kernel@vger.kernel.org, "Eric Biederman" Sent: Thursday, June 23, 2016 10:30:52 AM Subject: Re: [PATCH v3 3/9] kexec_file: Factor out

Re: [PATCH net-next 10/19] net: hns: bugfix about pfc pause frame statistics

在 2016/6/22 17:41, Andy Shevchenko 写道: > On Wed, 2016-06-22 at 09:43 +0800, Yisen Zhuang wrote: >> >> 在 2016/6/21 18:32, Andy Shevchenko 写道: >>> On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote: From: Daode Huang For SoC hip06, PFC pause handled in

Re: [PATCH net-next 10/19] net: hns: bugfix about pfc pause frame statistics

在 2016/6/22 17:41, Andy Shevchenko 写道: > On Wed, 2016-06-22 at 09:43 +0800, Yisen Zhuang wrote: >> >> 在 2016/6/21 18:32, Andy Shevchenko 写道: >>> On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote: From: Daode Huang For SoC hip06, PFC pause handled in dsaf, while hip05 in

Re: [PATCH v3 2/2] pci/aer: interrupt fixup in the quirk

在 2016/6/14 16:24, Po Liu 写道: On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode. When chip support the aer interrupt with none MSI/MSI-X/INTx mode, maybe there is interrupt line for aer pme etc. Search the interrupt number in the fdt file. Then fixup the dev->irq with it.

Re: [PATCH v3 2/2] pci/aer: interrupt fixup in the quirk

在 2016/6/14 16:24, Po Liu 写道: On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode. When chip support the aer interrupt with none MSI/MSI-X/INTx mode, maybe there is interrupt line for aer pme etc. Search the interrupt number in the fdt file. Then fixup the dev->irq with it.

[PATCH v4 2/3] staging: wilc1000: Replace kthread with workqueue for host interface

Deconstruct the kthread / message_queue logic, replacing it with create_singlethread_workqueue() / queue_work() setup, by adding a 'struct work_struct' to 'struct host_if_msg'. The current kthread hostIFthread() is converted to a work queue helper with the name 'host_if_work'. Signed-off-by:

[PATCH v4 2/3] staging: wilc1000: Replace kthread with workqueue for host interface

Deconstruct the kthread / message_queue logic, replacing it with create_singlethread_workqueue() / queue_work() setup, by adding a 'struct work_struct' to 'struct host_if_msg'. The current kthread hostIFthread() is converted to a work queue helper with the name 'host_if_work'. Signed-off-by:

[PATCH v4 3/3] staging: wilc1000: Change interface wilc_mq_send to wilc_enqueue_cmd

Replace the interface 'wilc_mq_send' with 'wilc_enqueue_cmd' and remove the now unused structures 'message' and 'message_queue'. Restructure switch statement in the work queue helper function host_if_work and remove unwanted indentation. Signed-off-by: Binoy Jayan ---

[PATCH v4 3/3] staging: wilc1000: Change interface wilc_mq_send to wilc_enqueue_cmd

Replace the interface 'wilc_mq_send' with 'wilc_enqueue_cmd' and remove the now unused structures 'message' and 'message_queue'. Restructure switch statement in the work queue helper function host_if_work and remove unwanted indentation. Signed-off-by: Binoy Jayan ---

[PATCH v4 1/3] staging: wilc1000: message_queue: Move code to host interface

Move the contents of wilc_msgqueue.c and wilc_msgqueue.h into host_interface.c, remove 'wilc_msgqueue.c' and 'wilc_msgqueue.h'. This is done so as to restructure the implementation of the kthread 'hostIFthread' using a work queue. Signed-off-by: Binoy Jayan ---

[PATCH v4 0/3] *** staging: wilc1000: Replace semaphores ***

Hi, Thank you Arnd for patiently reviewing this patch series multiple times and apologies to everyone for spamming you inboxes with a patch (v3) that does not even build. It was due to an uncommited change in my git repo before generating the patch. It is corrected in v4. This patchset [v4] is

[PATCH v4 1/3] staging: wilc1000: message_queue: Move code to host interface

Move the contents of wilc_msgqueue.c and wilc_msgqueue.h into host_interface.c, remove 'wilc_msgqueue.c' and 'wilc_msgqueue.h'. This is done so as to restructure the implementation of the kthread 'hostIFthread' using a work queue. Signed-off-by: Binoy Jayan --- drivers/staging/wilc1000/Makefile

[PATCH v4 0/3] *** staging: wilc1000: Replace semaphores ***

Hi, Thank you Arnd for patiently reviewing this patch series multiple times and apologies to everyone for spamming you inboxes with a patch (v3) that does not even build. It was due to an uncommited change in my git repo before generating the patch. It is corrected in v4. This patchset [v4] is

Re: [PATCH v4] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

On Thursday 23 June 2016 10:48 AM, Yury Norov wrote: > On Thu, Jun 23, 2016 at 10:31:16AM +0530, Madhavan Srinivasan wrote: >> When decoding the perf_regs mask in regs_dump__printf(), >> we loop through the mask using find_first_bit and find_next_bit functions. >> "mask" is of type "u64", but

Re: [PATCH v4] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

On Thursday 23 June 2016 10:48 AM, Yury Norov wrote: > On Thu, Jun 23, 2016 at 10:31:16AM +0530, Madhavan Srinivasan wrote: >> When decoding the perf_regs mask in regs_dump__printf(), >> we loop through the mask using find_first_bit and find_next_bit functions. >> "mask" is of type "u64", but

[PATCH v10 03/10] perf record: Prepare picking perf_event_mmap_page from multiple evlists

Following commits introduce new evlists to record. This patch adjusts record__pick_pc() and introduces perf_evlist__pick_pc() to read control page from one specific evlist. record__pick_pc() will be improved to search control page from multiple evlists. Signed-off-by: Wang Nan

[PATCH v10 03/10] perf record: Prepare picking perf_event_mmap_page from multiple evlists

Following commits introduce new evlists to record. This patch adjusts record__pick_pc() and introduces perf_evlist__pick_pc() to read control page from one specific evlist. record__pick_pc() will be improved to search control page from multiple evlists. Signed-off-by: Wang Nan Cc: He Kuang Cc:

[PATCH v10 05/10] perf tests: Add testcase for auxiliary evlist

Improve test backward-ring-buffer, trace both enter and exit event of prctl() syscall, utilize auxiliary evlist to mmap enter and exit event into separated mmaps. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc:

[PATCH v10 01/10] perf record: Prepare mmap multiple evlists

Following commits introduce multiple evlists to record. This patch extracts perf_evlist__mmap_ex() processing to a new function, creates record__mmap() and record__mmap_evlist() to wrap perf_evlist__mmap_ex() and its error processing. They will be improvemented to create mmap for all evlists.

[PATCH v10 01/10] perf record: Prepare mmap multiple evlists

Following commits introduce multiple evlists to record. This patch extracts perf_evlist__mmap_ex() processing to a new function, creates record__mmap() and record__mmap_evlist() to wrap perf_evlist__mmap_ex() and its error processing. They will be improvemented to create mmap for all evlists.

[PATCH v10 05/10] perf tests: Add testcase for auxiliary evlist

Improve test backward-ring-buffer, trace both enter and exit event of prctl() syscall, utilize auxiliary evlist to mmap enter and exit event into separated mmaps. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: He

[PATCH v10 06/10] perf record: Introduce rec->overwrite_evlist for overwritable events

Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's corresponding attributes, with these two evlists an event goes to either

[PATCH v10 06/10] perf record: Introduce rec->overwrite_evlist for overwritable events

Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's corresponding attributes, with these two evlists an event goes to either

Re: [PATCH 1/6] regulator: core: Allow simultaneous use of enable op and GPIO

On Thu, Jun 23, 2016 at 10:10 AM, Alexandre Courbot wrote: > On Wed, Jun 22, 2016 at 7:34 PM, Mark Brown wrote: >> On Wed, Jun 22, 2016 at 05:25:53PM +0900, Alexandre Courbot wrote: >>> The current regulator enable/disable mechanism does not call the driver

[PATCH v10 02/10] perf record: Prepare reading from multiple evlists in record__mmap_read_all()

Following commits introduce new evlists to record. This patch adjusts record__mmap_read_all() and record__mmap_read(): converting original record__mmap_read_all() to record__mmap_read_evlist(), read from one evlist; makes record__mmap_read() reading from specific evlist. record__mmap_read_all()

[PATCH v10 10/10] perf tools: Add --tail-synthesize option

When working with overwritable ring buffer there's a inconvenience problem: if perf dumps data after a long period after it starts, non-sample events may lost, which makes following 'perf report' unable to identify proc name and mmap layout. For example: # perf record -m 4 -e raw_syscalls:* -g

Re: [PATCH 1/6] regulator: core: Allow simultaneous use of enable op and GPIO

On Thu, Jun 23, 2016 at 10:10 AM, Alexandre Courbot wrote: > On Wed, Jun 22, 2016 at 7:34 PM, Mark Brown wrote: >> On Wed, Jun 22, 2016 at 05:25:53PM +0900, Alexandre Courbot wrote: >>> The current regulator enable/disable mechanism does not call the driver >>> enable/disable op if an enable

[PATCH v10 02/10] perf record: Prepare reading from multiple evlists in record__mmap_read_all()

Following commits introduce new evlists to record. This patch adjusts record__mmap_read_all() and record__mmap_read(): converting original record__mmap_read_all() to record__mmap_read_evlist(), read from one evlist; makes record__mmap_read() reading from specific evlist. record__mmap_read_all()

[PATCH v10 10/10] perf tools: Add --tail-synthesize option

When working with overwritable ring buffer there's a inconvenience problem: if perf dumps data after a long period after it starts, non-sample events may lost, which makes following 'perf report' unable to identify proc name and mmap layout. For example: # perf record -m 4 -e raw_syscalls:* -g

[PATCH v10 08/10] perf tools: Enable overwrite settings

This patch allows following config terms and option: Globally setting events to overwrite; # perf record --overwrite ... Set specific events to be overwrite or no-overwrite. # perf record --event cycles/overwrite/ ... # perf record --event cycles/no-overwrite/ ... Add missing config terms

[PATCH v3] mwifiex: Reduce endian conversion for REG Host Commands

For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS, HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved to driver. So, "leX_to_cpu" conversion is required too many times afterwards in driver. This patch reduces the endian: conversion without saving

[PATCH v10 09/10] perf tools: Don't warn about out of order event if write_backward is used

If write_backward attribute is set, records are written into kernel ring buffer from end to beginning, but read from beginning to end. To avoid 'XX out of order events recorded' warning message (timestamps of records is in reverse order when using write_backward), suppress the warning message if

[PATCH v10 07/10] perf record: Read from overwritable ring buffer

overwrite_evt_state is introduced to reflect the state of overwritable ring buffers. It is a state machine with 3 states: .(forbid)_. | | | V RUNNING --(1)--> DATA_PENDING --(2)-->

[PATCH v3] mwifiex: Reduce endian conversion for REG Host Commands

For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS, HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved to driver. So, "leX_to_cpu" conversion is required too many times afterwards in driver. This patch reduces the endian: conversion without saving

[PATCH v10 09/10] perf tools: Don't warn about out of order event if write_backward is used

If write_backward attribute is set, records are written into kernel ring buffer from end to beginning, but read from beginning to end. To avoid 'XX out of order events recorded' warning message (timestamps of records is in reverse order when using write_backward), suppress the warning message if

[PATCH v10 07/10] perf record: Read from overwritable ring buffer

overwrite_evt_state is introduced to reflect the state of overwritable ring buffers. It is a state machine with 3 states: .(forbid)_. | | | V RUNNING --(1)--> DATA_PENDING --(2)-->

[PATCH v10 08/10] perf tools: Enable overwrite settings

This patch allows following config terms and option: Globally setting events to overwrite; # perf record --overwrite ... Set specific events to be overwrite or no-overwrite. # perf record --event cycles/overwrite/ ... # perf record --event cycles/no-overwrite/ ... Add missing config terms

[PATCH v10 00/10] perf tools: Support overwritable ring buffer

This patch set enables daemonized perf recording by utilizing overwritable backward ring buffer. With this feature one can put perf background, and dump ring buffer records by a SIGUSR2 when he/she find something unusual. For example, following command record system calls, schedule events and

[PATCH v10 00/10] perf tools: Support overwritable ring buffer

This patch set enables daemonized perf recording by utilizing overwritable backward ring buffer. With this feature one can put perf background, and dump ring buffer records by a SIGUSR2 when he/she find something unusual. For example, following command record system calls, schedule events and

[PATCH v10 04/10] perf evlist: Introduce aux evlist

An auxiliary evlist is created by perf_evlist__new_aux() using an existing evlist as its parent. An auxiliary evlist can have its own 'struct perf_mmap', but can't have any other data. User should use its parent instead when accessing other data. Auxiliary evlists are containers of 'struct

[PATCH v10 04/10] perf evlist: Introduce aux evlist

An auxiliary evlist is created by perf_evlist__new_aux() using an existing evlist as its parent. An auxiliary evlist can have its own 'struct perf_mmap', but can't have any other data. User should use its parent instead when accessing other data. Auxiliary evlists are containers of 'struct

Re: [PATCH V4 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

From: Rui Wang On Wed, June 22, 2016 11:15 PM Bjorn Helgaas wrote: > [...] > > @@ -1779,8 +1780,12 @@ void __init > > pci_assign_unassigned_resources(void) > > { > > struct pci_bus *root_bus; > > > > - list_for_each_entry(root_bus, _root_buses, node) > > +

Re: [PATCH V4 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

From: Rui Wang On Wed, June 22, 2016 11:15 PM Bjorn Helgaas wrote: > [...] > > @@ -1779,8 +1780,12 @@ void __init > > pci_assign_unassigned_resources(void) > > { > > struct pci_bus *root_bus; > > > > - list_for_each_entry(root_bus, _root_buses, node) > > + list_for_each_entry(root_bus,

Re: [PATCH] mmc: core: add auto bkops support

On 23/06/16 04:33, Shawn Lin wrote: > 在 2016/6/22 22:08, Alex Lemberg 写道: >> HI Shawn, >> >> On 6/21/16, 4:44 AM, "Shawn Lin" wrote: >> >>> On 2016/6/20 21:33, Alex Lemberg wrote: Hi Shawn, […] >>> + >>> +static int mmc_stop_auto_bkops(struct

Re: [PATCH] mmc: core: add auto bkops support

On 23/06/16 04:33, Shawn Lin wrote: > 在 2016/6/22 22:08, Alex Lemberg 写道: >> HI Shawn, >> >> On 6/21/16, 4:44 AM, "Shawn Lin" wrote: >> >>> On 2016/6/20 21:33, Alex Lemberg wrote: Hi Shawn, […] >>> + >>> +static int mmc_stop_auto_bkops(struct mmc_card *card) >>> +{

[PATCH v3] mwifiex: Reduce endian conversion for REG Host Commands

For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS, HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved to driver. So, "leX_to_cpu" conversion is required too many times afterwards in driver. This patch reduces the endian: conversion without saving

[PATCH v3] mwifiex: Reduce endian conversion for REG Host Commands

For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS, HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved to driver. So, "leX_to_cpu" conversion is required too many times afterwards in driver. This patch reduces the endian: conversion without saving

Re: [PATCH v4] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

On Thu, Jun 23, 2016 at 10:31:16AM +0530, Madhavan Srinivasan wrote: > When decoding the perf_regs mask in regs_dump__printf(), > we loop through the mask using find_first_bit and find_next_bit functions. > "mask" is of type "u64", but sent as a "unsigned long *" to > lib functions along with

Re: [PATCH v4] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

On Thu, Jun 23, 2016 at 10:31:16AM +0530, Madhavan Srinivasan wrote: > When decoding the perf_regs mask in regs_dump__printf(), > we loop through the mask using find_first_bit and find_next_bit functions. > "mask" is of type "u64", but sent as a "unsigned long *" to > lib functions along with

Re: [PATCH v4 2/2] dt-bindings: analogix_dp: rockchip: correct the wrong compatible name

Hi, On Wed, Jun 22, 2016 at 6:47 PM, Yakir Yang wrote: > The document about rockchip platform make a mistaken in available > compatible name of "rk3288-edp", we should correct it to "rk3288-dp" > which correspond to the compatible name in driver. > > This mistaken was

Re: [PATCH v4 2/2] dt-bindings: analogix_dp: rockchip: correct the wrong compatible name

Hi, On Wed, Jun 22, 2016 at 6:47 PM, Yakir Yang wrote: > The document about rockchip platform make a mistaken in available > compatible name of "rk3288-edp", we should correct it to "rk3288-dp" > which correspond to the compatible name in driver. > > This mistaken was introduced in commit

Re: [PATCH v4.1 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

Yakir, On Wed, Jun 22, 2016 at 6:58 PM, Yakir Yang wrote: > For RK3399's GRF module, if we want to operate the graphic related grf > registers, we need to enable the pclk_vio_grf which supply power for VIO > GRF IOs, so it's better to introduce an optional grf clock in

Re: [PATCH v4.1 1/2] drm/rockchip: analogix_dp: introduce the pclk for grf

Yakir, On Wed, Jun 22, 2016 at 6:58 PM, Yakir Yang wrote: > For RK3399's GRF module, if we want to operate the graphic related grf > registers, we need to enable the pclk_vio_grf which supply power for VIO > GRF IOs, so it's better to introduce an optional grf clock in driver. > > Signed-off-by:

Re: [PATCH net-next V2] tun: introduce tx skb ring

On 2016年06月23日 02:18, Michael S. Tsirkin wrote: On Fri, Jun 17, 2016 at 03:41:20AM +0300, Michael S. Tsirkin wrote: >Would it help to have ptr_ring_resize that gets an array of >rings and resizes them both to same length? OK, here it is. Untested so far, and no skb wrapper. Pls let me know

Re: [PATCH net-next V2] tun: introduce tx skb ring

On 2016年06月23日 02:18, Michael S. Tsirkin wrote: On Fri, Jun 17, 2016 at 03:41:20AM +0300, Michael S. Tsirkin wrote: >Would it help to have ptr_ring_resize that gets an array of >rings and resizes them both to same length? OK, here it is. Untested so far, and no skb wrapper. Pls let me know

[PATCH] xen: fix upper bound of pmd loop in xen_cleanhighmap()

xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper bound of the loop setting non-kernel-image entries to zero should not exceed the size of level2_kernel_pgt. Reported-by: Linus Torvalds Signed-off-by: Juergen Gross ---

[PATCH] xen: fix upper bound of pmd loop in xen_cleanhighmap()

xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper bound of the loop setting non-kernel-image entries to zero should not exceed the size of level2_kernel_pgt. Reported-by: Linus Torvalds Signed-off-by: Juergen Gross --- arch/x86/xen/mmu.c | 2 +- 1 file changed, 1

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Mittwoch, 22. Juni 2016, 15:45:38 schrieb Mat Martineau: Hi Mat, > > > > Ok, I'll update the patch. > > Thanks, that helps (especially with pkcs1pad). Tadeusz received the updated patch from me to integrate it into his patch set. > > This brings me to another proposal for read buffer

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On Wed, Jun 22, 2016 at 9:35 PM, Yury Norov wrote: > On Tue, Jun 21, 2016 at 11:14:54AM +0100, Szabolcs Nagy wrote: >> On 21/06/16 06:06, Yury Norov wrote: >> > From: Andrew Pinski >> > >> > NOTE This is an ABI change for AARCH64. >> > If you have

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Mittwoch, 22. Juni 2016, 15:45:38 schrieb Mat Martineau: Hi Mat, > > > > Ok, I'll update the patch. > > Thanks, that helps (especially with pkcs1pad). Tadeusz received the updated patch from me to integrate it into his patch set. > > This brings me to another proposal for read buffer

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On Wed, Jun 22, 2016 at 9:35 PM, Yury Norov wrote: > On Tue, Jun 21, 2016 at 11:14:54AM +0100, Szabolcs Nagy wrote: >> On 21/06/16 06:06, Yury Norov wrote: >> > From: Andrew Pinski >> > >> > NOTE This is an ABI change for AARCH64. >> > If you have some AARCH32 and AARCH64 applications and they

Re: [PATCH v2 0/2] Correct iTCO Watchdog for Apollo Lake

On Tue, Jun 21, 2016 at 11:01:01PM -0700, Guenter Roeck wrote: > On 06/21/2016 09:53 PM, Yong, Jonathan wrote: > > On 06/17/2016 08:36, Yong, Jonathan wrote: > > > These patches fix the iTCO watchdog for Apollo Lake. > > > I changed the watchdog memory io to only use 4 bytes rather > > > the whole

Re: [PATCH v2 0/2] Correct iTCO Watchdog for Apollo Lake

On Tue, Jun 21, 2016 at 11:01:01PM -0700, Guenter Roeck wrote: > On 06/21/2016 09:53 PM, Yong, Jonathan wrote: > > On 06/17/2016 08:36, Yong, Jonathan wrote: > > > These patches fix the iTCO watchdog for Apollo Lake. > > > I changed the watchdog memory io to only use 4 bytes rather > > > the whole

[PATCH v4] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

When decoding the perf_regs mask in regs_dump__printf(), we loop through the mask using find_first_bit and find_next_bit functions. "mask" is of type "u64", but sent as a "unsigned long *" to lib functions along with sizeof(). While the exisitng code works fine in most of the case, the logic is

[PATCH v4] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

When decoding the perf_regs mask in regs_dump__printf(), we loop through the mask using find_first_bit and find_next_bit functions. "mask" is of type "u64", but sent as a "unsigned long *" to lib functions along with sizeof(). While the exisitng code works fine in most of the case, the logic is

[PATCH] i40e: Remove redundant memset

Remove redundant call to memset before a call to memcpy. The Coccinelle semantic patch used to make this change is as follows: @@ expression e1,e2,e3,e4; @@ - memset(e1,e2,e3); memcpy(e1,e4,e3); Signed-off-by: Amitoj Kaur Chawla ---

[PATCH] i40e: Remove redundant memset

Remove redundant call to memset before a call to memcpy. The Coccinelle semantic patch used to make this change is as follows: @@ expression e1,e2,e3,e4; @@ - memset(e1,e2,e3); memcpy(e1,e4,e3); Signed-off-by: Amitoj Kaur Chawla --- drivers/net/ethernet/intel/i40e/i40e_main.c | 1 - 1 file

[PATCH 1/2] Bluetooth: Add LED triggers for HCI frames tx and rx

Two LED triggers are defined: tx_led and rx_led. Upon frames available in HCI core layer, for tx or for rx, the combined LED can blink. Verified on HiKey, 96boards. It uses hi6220 SoC and TI WL1835 combo chip. Signed-off-by: Guodong Xu ---

[PATCH 2/2] arm64: dts: hikey: set bluetooth led trigger

Set bluetooth led trigger to hci0-rx, and so LED blinks on hci frame receiving. Signed-off-by: Guodong Xu --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts

[PATCH 1/2] Bluetooth: Add LED triggers for HCI frames tx and rx

Two LED triggers are defined: tx_led and rx_led. Upon frames available in HCI core layer, for tx or for rx, the combined LED can blink. Verified on HiKey, 96boards. It uses hi6220 SoC and TI WL1835 combo chip. Signed-off-by: Guodong Xu --- include/net/bluetooth/hci_core.h | 1 +

[PATCH 2/2] arm64: dts: hikey: set bluetooth led trigger

Set bluetooth led trigger to hci0-rx, and so LED blinks on hci frame receiving. Signed-off-by: Guodong Xu --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts

Re: [PATCH 19/27] [AARCH64] Add typesizes.h for ILP32

On Tue, Jun 21, 2016 at 07:59:27PM +0800, Zhangjian (Bamvor) wrote: > Hi, > > On 2016/6/21 15:58, Andreas Schwab wrote: > >Yury Norov writes: > > > >>diff --git a/sysdeps/unix/sysv/linux/sysdep-vdso.h > >>b/sysdeps/unix/sysv/linux/sysdep-vdso.h > >>index

Re: [PATCH 19/27] [AARCH64] Add typesizes.h for ILP32

On Tue, Jun 21, 2016 at 07:59:27PM +0800, Zhangjian (Bamvor) wrote: > Hi, > > On 2016/6/21 15:58, Andreas Schwab wrote: > >Yury Norov writes: > > > >>diff --git a/sysdeps/unix/sysv/linux/sysdep-vdso.h > >>b/sysdeps/unix/sysv/linux/sysdep-vdso.h > >>index e8c4a7b..351d6bb 100644 > >>---

Re: [PATCH 3.14 00/29] 3.14.73-stable review -rc2

-rc2! Please test this... This is the start of the stable review cycle for the 3.14.73 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 25

Re: [PATCH 3.14 00/29] 3.14.73-stable review -rc2

-rc2! Please test this... This is the start of the stable review cycle for the 3.14.73 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 25

Re: [PATCH 4.4 00/75] 4.4.14-stable review -rc2

-rc2! This is the start of the stable review cycle for the 4.4.14 release. There are 81 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 25 04:51:37 UTC 2016. Anything

Re: [PATCH 4.4 00/75] 4.4.14-stable review -rc2

-rc2! This is the start of the stable review cycle for the 4.4.14 release. There are 81 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 25 04:51:37 UTC 2016. Anything

[PATCH 4.6 00/87] 4.6.3-stable review -rc2

Let's try a -rc2! This is the start of the stable review cycle for the 4.6.3 release. There are 87 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 25 04:47:50 UTC

[PATCH 4.6 00/87] 4.6.3-stable review -rc2

Let's try a -rc2! This is the start of the stable review cycle for the 4.6.3 release. There are 87 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 25 04:47:50 UTC

[PATCH] dlm: Use kmemdup instead of kmalloc and memcpy

Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. The Coccinelle semantic patch used to make this change is as follows: @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S

[PATCH] dlm: Use kmemdup instead of kmalloc and memcpy

Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. The Coccinelle semantic patch used to make this change is as follows: @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S

Re: [PATCHv4 1/1] thermal: core: call thermal_zone_device_update() after mode update

On Wed, Jun 22, 2016 at 08:03:18AM -0700, Eduardo Valentin wrote: > Because several drivers do the following pattern: > .set_mode() >... >local_data->mode = new_mode; >thermal_zone_device_update(tz); > > makes sense to simply do the thermal_zone_device_update() > in thermal core,

Re: [PATCHv4 1/1] thermal: core: call thermal_zone_device_update() after mode update

On Wed, Jun 22, 2016 at 08:03:18AM -0700, Eduardo Valentin wrote: > Because several drivers do the following pattern: > .set_mode() >... >local_data->mode = new_mode; >thermal_zone_device_update(tz); > > makes sense to simply do the thermal_zone_device_update() > in thermal core,

[PATCH] tipc: Use kmemdup instead of kmalloc and memcpy

Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. The Coccinelle semantic patch used to make this change is as follows: @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S

[PATCH] tipc: Use kmemdup instead of kmalloc and memcpy

Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. The Coccinelle semantic patch used to make this change is as follows: @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On Mon, Jun 20, 2016 at 04:26:52PM +0200, Matthieu CASTET wrote: > Hi, > > the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it > change to syscall to an equivalent to FUTEX_WAIT_BITSET | > FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY. > > It seems wrong to me,

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On Mon, Jun 20, 2016 at 04:26:52PM +0200, Matthieu CASTET wrote: > Hi, > > the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it > change to syscall to an equivalent to FUTEX_WAIT_BITSET | > FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY. > > It seems wrong to me,

  1   2   3   4   5   6   7   8   9   10   >