Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote: > This patch adds a member in fam15h_power_data which specifies the > compute unit accumulated power. It adds do_read_registers_on_cu to do > all the read to all MSRs and run it on one of the online cores on each > compute unit with

Re: [PATCH v2 5/5] dmaengine: qcom: bam_dma: rename BAM_MAX_DATA_SIZE define

On 04/06/2016 02:47 AM, Vinod Koul wrote: > On Wed, Apr 06, 2016 at 01:56:22AM +0300, Stanimir Varbanov wrote: >> It seems that the define has not been with acurate name and >> makes confusion while reading the code. The more acurate >> name should be BAM_FIFO_SIZE. > > And not sure by that, what

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote: > This patch adds a member in fam15h_power_data which specifies the > compute unit accumulated power. It adds do_read_registers_on_cu to do > all the read to all MSRs and run it on one of the online cores on each > compute unit with

Re: [PATCH v2 5/5] dmaengine: qcom: bam_dma: rename BAM_MAX_DATA_SIZE define

On 04/06/2016 02:47 AM, Vinod Koul wrote: > On Wed, Apr 06, 2016 at 01:56:22AM +0300, Stanimir Varbanov wrote: >> It seems that the define has not been with acurate name and >> makes confusion while reading the code. The more acurate >> name should be BAM_FIFO_SIZE. > > And not sure by that, what

Re: [lkp] [x86, ACPI, cpu] f962c29c2f: BUG: unable to handle kernel paging request at 0000000000001b00

On 4/6/2016 2:43 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next commit f962c29c2f5d80be28bd76e2c3fadf1ce97ccd76 ("x86, ACPI, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting")

Re: [lkp] [x86, ACPI, cpu] f962c29c2f: BUG: unable to handle kernel paging request at 0000000000001b00

On 4/6/2016 2:43 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next commit f962c29c2f5d80be28bd76e2c3fadf1ce97ccd76 ("x86, ACPI, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting")

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 6:03 AM, Emrah Demir wrote: > > By this patch after insertion resources, start and end address are zeroed. I'd much rather just not insert the resources in the first place then. Linus

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 6:03 AM, Emrah Demir wrote: > > By this patch after insertion resources, start and end address are zeroed. I'd much rather just not insert the resources in the first place then. Linus

[PATCH V2 5/9] arm64: exception: handle instruction abort at current EL

Add a handler for instruction aborts at the current EL (ESR_ELx_EC_IABT_CUR) so they are no longer handled in el1_inv. This allows firmware first handling for possible SEA (Synchronous External Abort) caused instruction abort at current EL. Signed-off-by: Tyler Baicar

[PATCH V2 5/9] arm64: exception: handle instruction abort at current EL

Add a handler for instruction aborts at the current EL (ESR_ELx_EC_IABT_CUR) so they are no longer handled in el1_inv. This allows firmware first handling for possible SEA (Synchronous External Abort) caused instruction abort at current EL. Signed-off-by: Tyler Baicar Signed-off-by: Naveen Kaje

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On Mon, Apr 4, 2016 at 3:22 PM, Ezequiel Garcia wrote: > It's desirable to specify which LEDs are to be blinked on a kernel > panic. Therefore, introduce a devicetree boolean property to mark > which LEDs should be treated this way. > > Signed-off-by: Ezequiel

Re: [PATCH 1/3] intel_pstate: Use pr_fmt

On Wed, 2016-04-06 at 07:51 -0700, Doug Smythies wrote: > On 2016.04.05 02:44 Srinivas Pandruvada wrote: > > > > On Tue, 2016-04-05 at 13:28 -0700, Joe Perches wrote: > > > > > > Prefix the output using the more common kernel style. > > > > > > Signed-off-by: Joe Perches > >

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On Mon, Apr 4, 2016 at 3:22 PM, Ezequiel Garcia wrote: > It's desirable to specify which LEDs are to be blinked on a kernel > panic. Therefore, introduce a devicetree boolean property to mark > which LEDs should be treated this way. > > Signed-off-by: Ezequiel Garcia > --- >

Re: [PATCH 1/3] intel_pstate: Use pr_fmt

On Wed, 2016-04-06 at 07:51 -0700, Doug Smythies wrote: > On 2016.04.05 02:44 Srinivas Pandruvada wrote: > > > > On Tue, 2016-04-05 at 13:28 -0700, Joe Perches wrote: > > > > > > Prefix the output using the more common kernel style. > > > > > > Signed-off-by: Joe Perches > > Acked-by: Srinivas

[PATCH V2 9/9] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V2 2/9] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3 structure. The timestamp of when the firmware generated the error is now being reported. Signed-off-by: Jonathan (Zhixiong) Zhang

[PATCH V2 3/9] efi: parse ARMv8 processor error

Add support for ARMv8 Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARMv8 specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Jonathan (Zhixiong) Zhang

[PATCH V2 9/9] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V2 2/9] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3 structure. The timestamp of when the firmware generated the error is now being reported. Signed-off-by: Jonathan (Zhixiong) Zhang Signed-off-by: Richard

[PATCH V2 3/9] efi: parse ARMv8 processor error

Add support for ARMv8 Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARMv8 specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Jonathan (Zhixiong) Zhang Signed-off-by:

[PATCH V2 6/9] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchrounous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V2 8/9] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V2 0/9] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

Add support for Generic Hardware Error Source (GHES) v2, which introduces the capability for the OS to acknowledge the consumption of the error record generated by the Reliability, Availability and Serviceability (RAS) controller. This eliminates potential race conditions between the OS and the

[PATCH V2 7/9] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification

Re: [PATCH 11/11] perf, tools, stat: Add extra output of counter values with -v

Em Wed, Apr 06, 2016 at 08:10:08AM -0700, Andi Kleen escreveu: > On Wed, Apr 06, 2016 at 11:32:20AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Mon, Apr 04, 2016 at 01:41:54PM -0700, Andi Kleen escreveu: > > > From: Andi Kleen > > > > > > Add debug output of raw counter

[PATCH V2 1/9] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

Re: [PATCH 11/11] perf, tools, stat: Add extra output of counter values with -v

Em Wed, Apr 06, 2016 at 08:10:08AM -0700, Andi Kleen escreveu: > On Wed, Apr 06, 2016 at 11:32:20AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Mon, Apr 04, 2016 at 01:41:54PM -0700, Andi Kleen escreveu: > > > From: Andi Kleen > > > > > > Add debug output of raw counter values per CPU when > >

[PATCH V2 1/9] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

[PATCH V2 6/9] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchrounous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V2 8/9] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V2 0/9] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

Add support for Generic Hardware Error Source (GHES) v2, which introduces the capability for the OS to acknowledge the consumption of the error record generated by the Reliability, Availability and Serviceability (RAS) controller. This eliminates potential race conditions between the OS and the

[PATCH V2 7/9] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification type. The OS should

[PATCH V2 4/9] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, go through the handlers registered in the notification list.

Re: [PATCH v2 1/3] mmc: sdhci: introduce sdhci_compute_clock_config

On Wed, Apr 06, 2016 at 05:04:45PM +0200, Ludovic Desroches wrote: > On Wed, Apr 06, 2016 at 03:37:28PM +0300, Adrian Hunter wrote: > > On 04/04/16 18:27, Ludovic Desroches wrote: > > > In order to remove the SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST and to > > > reduce code duplication, put the

Re: Re: PG_reserved and compound pages

Hi Michal, On Wednesday 06 April 2016 17:02:06 Michal Hocko wrote: > [CCing linux-mm mailing list] > > On Wed 06-04-16 13:28:37, Frank Mehnert wrote: > > Hi, > > > > Linux 4.5 introduced additional checks to ensure that compound pages are > > never marked as reserved. In our code we use

[PATCH V2 4/9] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, go through the handlers registered in the notification list.

Re: [PATCH v2 1/3] mmc: sdhci: introduce sdhci_compute_clock_config

On Wed, Apr 06, 2016 at 05:04:45PM +0200, Ludovic Desroches wrote: > On Wed, Apr 06, 2016 at 03:37:28PM +0300, Adrian Hunter wrote: > > On 04/04/16 18:27, Ludovic Desroches wrote: > > > In order to remove the SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST and to > > > reduce code duplication, put the

Re: Re: PG_reserved and compound pages

Hi Michal, On Wednesday 06 April 2016 17:02:06 Michal Hocko wrote: > [CCing linux-mm mailing list] > > On Wed 06-04-16 13:28:37, Frank Mehnert wrote: > > Hi, > > > > Linux 4.5 introduced additional checks to ensure that compound pages are > > never marked as reserved. In our code we use

Re: [PATCH 1/4] KVM: MMU: fix permission_fault()

On 04/06/2016 04:56 PM, Paolo Bonzini wrote: On 25/03/2016 14:19, Xiao Guangrong wrote: @@ -193,11 +193,11 @@ static inline u8 permission_fault(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, ((pte_access & PT_USER_MASK) << (PFERR_RSVD_BIT - PT_USER_SHIFT)); One more

Re: [PATCH 1/4] KVM: MMU: fix permission_fault()

On 04/06/2016 04:56 PM, Paolo Bonzini wrote: On 25/03/2016 14:19, Xiao Guangrong wrote: @@ -193,11 +193,11 @@ static inline u8 permission_fault(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, ((pte_access & PT_USER_MASK) << (PFERR_RSVD_BIT - PT_USER_SHIFT)); One more

Re: [PATCH 11/11] perf, tools, stat: Add extra output of counter values with -v

On Wed, Apr 06, 2016 at 11:32:20AM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Apr 04, 2016 at 01:41:54PM -0700, Andi Kleen escreveu: > > From: Andi Kleen > > > > Add debug output of raw counter values per CPU when > > perf stat -v is specified, together with their cpu

Re: [PATCH 11/11] perf, tools, stat: Add extra output of counter values with -v

On Wed, Apr 06, 2016 at 11:32:20AM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Apr 04, 2016 at 01:41:54PM -0700, Andi Kleen escreveu: > > From: Andi Kleen > > > > Add debug output of raw counter values per CPU when > > perf stat -v is specified, together with their cpu numbers. > > This is

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

On Wed, 6 Apr 2016, Michal Nazarewicz wrote: > On Tue, Apr 05 2016, Alan Stern wrote: > > Suppose one usb_function is carrying out an I/O operation while > > another one in the same config gets a Set-Interface request from the > > host. > > That cannot happen. A single instance of mass_storage

Re: [PATCH 1/3] iio: core: Add devm_ APIs for iio_channel_{get,release}

Hi Daniel, On Wednesday 06 April 2016 07:19 PM, Daniel Baluta wrote: On Wed, Apr 6, 2016 at 1:31 PM, Laxman Dewangan wrote: Some of kernel driver uses the IIO framework to get the sensor value via ADC or IIO HW driver. The client driver get iio channel by

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

On Wed, 6 Apr 2016, Michal Nazarewicz wrote: > On Tue, Apr 05 2016, Alan Stern wrote: > > Suppose one usb_function is carrying out an I/O operation while > > another one in the same config gets a Set-Interface request from the > > host. > > That cannot happen. A single instance of mass_storage

Re: [PATCH 1/3] iio: core: Add devm_ APIs for iio_channel_{get,release}

Hi Daniel, On Wednesday 06 April 2016 07:19 PM, Daniel Baluta wrote: On Wed, Apr 6, 2016 at 1:31 PM, Laxman Dewangan wrote: Some of kernel driver uses the IIO framework to get the sensor value via ADC or IIO HW driver. The client driver get iio channel by iio_channel_get() and release it by

[PATCH net-next v2] net: dsa: document missing functions

Add description for the missing port_vlan_prepare, port_fdb_prepare, port_fdb_dump functions in the DSA documentation. Signed-off-by: Vivien Didelot --- Documentation/networking/dsa/dsa.txt | 16 1 file changed, 16 insertions(+) diff --git

[PATCH net-next v2] net: dsa: document missing functions

Add description for the missing port_vlan_prepare, port_fdb_prepare, port_fdb_dump functions in the DSA documentation. Signed-off-by: Vivien Didelot --- Documentation/networking/dsa/dsa.txt | 16 1 file changed, 16 insertions(+) diff --git

Re: [PATCH v2 1/3] mmc: sdhci: introduce sdhci_compute_clock_config

On Wed, Apr 06, 2016 at 03:37:28PM +0300, Adrian Hunter wrote: > On 04/04/16 18:27, Ludovic Desroches wrote: > > In order to remove the SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST and to > > reduce code duplication, put the code relative to the SD clock > > configuration in a function which can be

Re: [PATCH v2 3/5] dmaengine: qcom: bam_dma: add controlled remotely dt property

On 04/06/2016 02:44 AM, Vinod Koul wrote: > On Wed, Apr 06, 2016 at 01:56:20AM +0300, Stanimir Varbanov wrote: >> Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++ >> drivers/dma/qcom/bam_dma.c | 7 +++ > > The binding should be a separate patch.. I'm

Re: [PATCH v2 1/3] mmc: sdhci: introduce sdhci_compute_clock_config

On Wed, Apr 06, 2016 at 03:37:28PM +0300, Adrian Hunter wrote: > On 04/04/16 18:27, Ludovic Desroches wrote: > > In order to remove the SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST and to > > reduce code duplication, put the code relative to the SD clock > > configuration in a function which can be

Re: [PATCH v2 3/5] dmaengine: qcom: bam_dma: add controlled remotely dt property

On 04/06/2016 02:44 AM, Vinod Koul wrote: > On Wed, Apr 06, 2016 at 01:56:20AM +0300, Stanimir Varbanov wrote: >> Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++ >> drivers/dma/qcom/bam_dma.c | 7 +++ > > The binding should be a separate patch.. I'm

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, 06 Apr, at 12:07:36PM, George Dunlap wrote: > > So rather than make a new entry point which does just the minimal > amount of work to run on a software interface (Xen), you want to take > an interface designed for hardware (EFI) and put in hacks so that it > knows that sometimes some EFI

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, 06 Apr, at 12:07:36PM, George Dunlap wrote: > > So rather than make a new entry point which does just the minimal > amount of work to run on a software interface (Xen), you want to take > an interface designed for hardware (EFI) and put in hacks so that it > knows that sometimes some EFI

Re: PG_reserved and compound pages

[CCing linux-mm mailing list] On Wed 06-04-16 13:28:37, Frank Mehnert wrote: > Hi, > > Linux 4.5 introduced additional checks to ensure that compound pages are > never marked as reserved. In our code we use PG_reserved to ensure that > the kernel does never swap out such pages, e.g. Are you

Re: PG_reserved and compound pages

[CCing linux-mm mailing list] On Wed 06-04-16 13:28:37, Frank Mehnert wrote: > Hi, > > Linux 4.5 introduced additional checks to ensure that compound pages are > never marked as reserved. In our code we use PG_reserved to ensure that > the kernel does never swap out such pages, e.g. Are you

Re: [PATCH 1/3] intel_pstate: Use pr_fmt

On 06-04-16, 07:51, Doug Smythies wrote: > On 2016.04.05 02:44 Srinivas Pandruvada wrote: > > On Tue, 2016-04-05 at 13:28 -0700, Joe Perches wrote: > >> Prefix the output using the more common kernel style. > >> > >> Signed-off-by: Joe Perches > > Acked-by: Srinivas Pandruvada

Re: [PATCH 1/3] intel_pstate: Use pr_fmt

On 06-04-16, 07:51, Doug Smythies wrote: > On 2016.04.05 02:44 Srinivas Pandruvada wrote: > > On Tue, 2016-04-05 at 13:28 -0700, Joe Perches wrote: > >> Prefix the output using the more common kernel style. > >> > >> Signed-off-by: Joe Perches > > Acked-by: Srinivas Pandruvada > >> --- > >>

Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

On Sat, Apr 2, 2016 at 10:31 PM, Aniroop Mathur wrote: > Hello Mr. Torokhov, > > First of all, Thank you for your reply. > > On Sat, Apr 2, 2016 at 3:21 AM, Dmitry Torokhov > wrote: >> On Fri, Mar 11, 2016 at 12:26:57AM +0530, Aniroop Mathur

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

On 4/6/2016 11:12 AM, Vineet Gupta wrote: Hi, On Thursday 17 March 2016 03:11 PM, Alexey Brodkin wrote: Following commit broke DW GMAC functionality on AXS10x boards: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763 That's what

Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

On Sat, Apr 2, 2016 at 10:31 PM, Aniroop Mathur wrote: > Hello Mr. Torokhov, > > First of all, Thank you for your reply. > > On Sat, Apr 2, 2016 at 3:21 AM, Dmitry Torokhov > wrote: >> On Fri, Mar 11, 2016 at 12:26:57AM +0530, Aniroop Mathur wrote: >>> Hi Henrik, >>> >>> On Thu, Mar 10, 2016 at

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

On 4/6/2016 11:12 AM, Vineet Gupta wrote: Hi, On Thursday 17 March 2016 03:11 PM, Alexey Brodkin wrote: Following commit broke DW GMAC functionality on AXS10x boards: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763 That's what

[PATCH v3] iio: imu: Add initial support for Bosch BMI160

BMI160 is an Inertial Measurement Unit (IMU) which provides acceleration and angular rate measurement. It also offers a secondary I2C interface for connecting a magnetometer sensor (usually BMM160). Current driver offers support for accelerometer and gyroscope readings via sysfs or via buffer

[PATCH v3] iio: imu: Add initial support for Bosch BMI160

BMI160 is an Inertial Measurement Unit (IMU) which provides acceleration and angular rate measurement. It also offers a secondary I2C interface for connecting a magnetometer sensor (usually BMM160). Current driver offers support for accelerometer and gyroscope readings via sysfs or via buffer

Re: [PATCH v2] Security: Keys: Big keys stored encrypted

Kirill Marinushkin wrote: > Solved TODO task: big keys saved to shmem file are now stored encrypted. > The encryption key is randomly generated and saved to payload[big_key_data]. > > Signed-off-by: Kirill Marinushkin Applied. David

Re: [PATCH v2] Security: Keys: Big keys stored encrypted

Kirill Marinushkin wrote: > Solved TODO task: big keys saved to shmem file are now stored encrypted. > The encryption key is randomly generated and saved to payload[big_key_data]. > > Signed-off-by: Kirill Marinushkin Applied. David

Re: [PATCH BUGFIX] clk: imx6q: fix typo in CAN clock definition

On Wed, Mar 30, 2016 at 02:23:03PM +0200, Lothar Waßmann wrote: > commit ee36027427c7 ("clk: imx: Add clock support for imx6qp") > introduced a regression due to a subtle typo in the 'can_root' clock > definition. The effect is that trying to configure the bitrate of the > can interfaces fails

Re: [PATCH BUGFIX] clk: imx6q: fix typo in CAN clock definition

On Wed, Mar 30, 2016 at 02:23:03PM +0200, Lothar Waßmann wrote: > commit ee36027427c7 ("clk: imx: Add clock support for imx6qp") > introduced a regression due to a subtle typo in the 'can_root' clock > definition. The effect is that trying to configure the bitrate of the > can interfaces fails

RE: [PATCH 1/3] intel_pstate: Use pr_fmt

On 2016.04.05 02:44 Srinivas Pandruvada wrote: > On Tue, 2016-04-05 at 13:28 -0700, Joe Perches wrote: >> Prefix the output using the more common kernel style. >> >> Signed-off-by: Joe Perches > Acked-by: Srinivas Pandruvada >> --- >>

RE: [PATCH 1/3] intel_pstate: Use pr_fmt

On 2016.04.05 02:44 Srinivas Pandruvada wrote: > On Tue, 2016-04-05 at 13:28 -0700, Joe Perches wrote: >> Prefix the output using the more common kernel style. >> >> Signed-off-by: Joe Perches > Acked-by: Srinivas Pandruvada >> --- >> drivers/cpufreq/intel_pstate.c | 18 ++ >>

RE: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

Hi, sorry to be late on this > -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Jisheng Zhang > Sent: 16 March 2016 11:41 > To: jingooh...@gmail.com; pratyush.an...@gmail.com; bhelg...@google.com > Cc:

RE: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

Hi, sorry to be late on this > -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Jisheng Zhang > Sent: 16 March 2016 11:41 > To: jingooh...@gmail.com; pratyush.an...@gmail.com; bhelg...@google.com > Cc:

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Tue, 5 Apr 2016 21:46:44 +0800 Yongji Xie wrote: > This patch enables mmapping MSI-X tables if > hardware supports interrupt remapping which > can ensure that a given pci device can only > shoot the MSIs assigned for it. > > Signed-off-by: Yongji Xie

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Tue, 5 Apr 2016 21:46:44 +0800 Yongji Xie wrote: > This patch enables mmapping MSI-X tables if > hardware supports interrupt remapping which > can ensure that a given pci device can only > shoot the MSIs assigned for it. > > Signed-off-by: Yongji Xie > --- > drivers/vfio/pci/vfio_pci.c

[PATCH] perf/x86/intel/pt: Use boot_cpu_has() because it's there

At the moment, initialization path is using test_cpu_cap(_cpu_data), to detect PT, which is just open coding boot_cpu_has(). Use the latter instead. Signed-off-by: Alexander Shishkin --- arch/x86/events/intel/pt.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] perf/x86/intel/pt: Use boot_cpu_has() because it's there

At the moment, initialization path is using test_cpu_cap(_cpu_data), to detect PT, which is just open coding boot_cpu_has(). Use the latter instead. Signed-off-by: Alexander Shishkin --- arch/x86/events/intel/pt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v1] net: cdc_ncm: update datagram size after changing mtu

Robert Dobrowolski writes: > From: Rafal Redzimski > > Current implementation updates the mtu size and notify cdc_ncm > device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram > size change instead of changing

Re: [PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

* Anton Blanchard [2016-04-06 21:59:50]: > Looks good, and the patch below does fix the oops for me. > > Anton > -- > > task_pt_regs() can return NULL for kernel threads, so add a check. > This fixes an oops at boot on ppc64. > > Signed-off-by: Anton Blanchard

Re: [PATCH v1] net: cdc_ncm: update datagram size after changing mtu

Robert Dobrowolski writes: > From: Rafal Redzimski > > Current implementation updates the mtu size and notify cdc_ncm > device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram > size change instead of changing rx_urb_size. > > Whenever mtu is being changed, datagram size should also

Re: [PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

* Anton Blanchard [2016-04-06 21:59:50]: > Looks good, and the patch below does fix the oops for me. > > Anton > -- > > task_pt_regs() can return NULL for kernel threads, so add a check. > This fixes an oops at boot on ppc64. > > Signed-off-by: Anton Blanchard Works for me too.

Re: [PATCH] csiostor: Fix backwards locking in the function __csio_unreg_rnode

On 2016-04-06 10:24 AM, James Bottomley wrote: > On Wed, 2016-04-06 at 10:11 -0400, Bastien Philbert wrote: >> >> On 2016-04-06 09:38 AM, James Bottomley wrote: >>> On Wed, 2016-04-06 at 09:21 -0400, Bastien Philbert wrote: On 2016-04-06 03:48 AM, Julian Calaby wrote: > Hi Bastien,

Re: [PATCH] csiostor: Fix backwards locking in the function __csio_unreg_rnode

On 2016-04-06 10:24 AM, James Bottomley wrote: > On Wed, 2016-04-06 at 10:11 -0400, Bastien Philbert wrote: >> >> On 2016-04-06 09:38 AM, James Bottomley wrote: >>> On Wed, 2016-04-06 at 09:21 -0400, Bastien Philbert wrote: On 2016-04-06 03:48 AM, Julian Calaby wrote: > Hi Bastien,

Re: [PATCH v6 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting.

[+Dennis since he reported ARM64 build breakage] On Thu, Mar 17, 2016 at 09:32:40AM +0800, Zhu Guihua wrote: > From: Gu Zheng > > The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So > that, > when node online/offline happens, cache based on cpuid

Re: [PATCH v6 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting.

[+Dennis since he reported ARM64 build breakage] On Thu, Mar 17, 2016 at 09:32:40AM +0800, Zhu Guihua wrote: > From: Gu Zheng > > The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So > that, > when node online/offline happens, cache based on cpuid <-> nodeid mapping >

Re: [PATCH 2/2] tools/perf: Fix kallsyms perf test on ppc64le

On Wed, Apr 06, 2016 at 06:02:58PM +0530, Naveen N. Rao wrote: > ppc64le functions have a Global Entry Point (GEP) and a Local Entry > Point (LEP). While placing a probe, we always prefer the LEP since it > catches function calls through both the GEP and the LEP. In order to do > this, we fixup

Re: [PATCH 2/2] tools/perf: Fix kallsyms perf test on ppc64le

On Wed, Apr 06, 2016 at 06:02:58PM +0530, Naveen N. Rao wrote: > ppc64le functions have a Global Entry Point (GEP) and a Local Entry > Point (LEP). While placing a probe, we always prefer the LEP since it > catches function calls through both the GEP and the LEP. In order to do > this, we fixup

Re: [PATCH 11/11] perf, tools, stat: Add extra output of counter values with -v

Em Mon, Apr 04, 2016 at 01:41:54PM -0700, Andi Kleen escreveu: > From: Andi Kleen > > Add debug output of raw counter values per CPU when > perf stat -v is specified, together with their cpu numbers. > This is very useful to debug problems with per core counters, > where we

Re: [PATCH 11/11] perf, tools, stat: Add extra output of counter values with -v

Em Mon, Apr 04, 2016 at 01:41:54PM -0700, Andi Kleen escreveu: > From: Andi Kleen > > Add debug output of raw counter values per CPU when > perf stat -v is specified, together with their cpu numbers. > This is very useful to debug problems with per core counters, > where we can normally only see

Re: [RESEND 0/2] dmaengine: edma: cyclic slot limitation wa and TPTC pm fix

On Wed, Apr 06, 2016 at 01:01:45PM +0300, Peter Ujfalusi wrote: > Hi Vinod, > > I just noticed that the following two patch got lost somehow. If it is still > possible, it would be great to send them for 4.6 as they are correcting > important issues in the driver. Done now. I will check how they

Re: [RESEND 0/2] dmaengine: edma: cyclic slot limitation wa and TPTC pm fix

On Wed, Apr 06, 2016 at 01:01:45PM +0300, Peter Ujfalusi wrote: > Hi Vinod, > > I just noticed that the following two patch got lost somehow. If it is still > possible, it would be great to send them for 4.6 as they are correcting > important issues in the driver. Done now. I will check how they

[PATCH 1/3] mm, oom: move GFP_NOFS check to out_of_memory

From: Michal Hocko __alloc_pages_may_oom is the central place to decide when the out_of_memory should be invoked. This is a good approach for most checks there because they are page allocator specific and the allocation fails right after for all of them. The notable exception

[PATCH 1/3] mm, oom: move GFP_NOFS check to out_of_memory

From: Michal Hocko __alloc_pages_may_oom is the central place to decide when the out_of_memory should be invoked. This is a good approach for most checks there because they are page allocator specific and the allocation fails right after for all of them. The notable exception is GFP_NOFS

Re: [PATCH] Revert "netpoll: Fix extra refcount release in netpoll_cleanup()"

On 04/05/16 13:58, Bjorn Helgaas wrote: This reverts commit 543e3a8da5a4c453e992d5351ef405d5e32f27d7. Direct callers of __netpoll_setup() depend on it to set np->dev, so we can't simply move that assignment up to netpoll_stup(). Reported-by: Bart Van Assche

Re: [PATCH] Revert "netpoll: Fix extra refcount release in netpoll_cleanup()"

On 04/05/16 13:58, Bjorn Helgaas wrote: This reverts commit 543e3a8da5a4c453e992d5351ef405d5e32f27d7. Direct callers of __netpoll_setup() depend on it to set np->dev, so we can't simply move that assignment up to netpoll_stup(). Reported-by: Bart Van Assche Signed-off-by: Bjorn Helgaas

Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void

Hi Andrew, Andrew Lunn writes: >> >> mutex_lock(>smi_mutex); >> >> - ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state); >> >> + if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state)) >> >> + netdev_warn(ds->ports[port], "cannot load

Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void

Hi Andrew, Andrew Lunn writes: >> >> mutex_lock(>smi_mutex); >> >> - ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state); >> >> + if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state)) >> >> + netdev_warn(ds->ports[port], "cannot load address\n"); >> > >>

RE: [PATCH V2 1/1] perf/core: don't find side-band event from all pmus

> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Wednesday, April 06, 2016 4:10 AM > To: Arnaldo Carvalho de Melo > Cc: Liang, Kan ; a...@linux.intel.com; > eran...@google.com; vincent.wea...@maine.edu;

RE: [PATCH V2 1/1] perf/core: don't find side-band event from all pmus

> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Wednesday, April 06, 2016 4:10 AM > To: Arnaldo Carvalho de Melo > Cc: Liang, Kan ; a...@linux.intel.com; > eran...@google.com; vincent.wea...@maine.edu; t...@linutronix.de; > mi...@kernel.org;

Re: [PATCH] csiostor: Fix backwards locking in the function __csio_unreg_rnode

On Wed, 2016-04-06 at 10:11 -0400, Bastien Philbert wrote: > > On 2016-04-06 09:38 AM, James Bottomley wrote: > > On Wed, 2016-04-06 at 09:21 -0400, Bastien Philbert wrote: > > > > > > On 2016-04-06 03:48 AM, Julian Calaby wrote: > > > > Hi Bastien, > > > > > > > > On Wed, Apr 6, 2016 at 7:19

Re: [PATCH] csiostor: Fix backwards locking in the function __csio_unreg_rnode

On Wed, 2016-04-06 at 10:11 -0400, Bastien Philbert wrote: > > On 2016-04-06 09:38 AM, James Bottomley wrote: > > On Wed, 2016-04-06 at 09:21 -0400, Bastien Philbert wrote: > > > > > > On 2016-04-06 03:48 AM, Julian Calaby wrote: > > > > Hi Bastien, > > > > > > > > On Wed, Apr 6, 2016 at 7:19

<    6   7   8   9   10   11   12   13   14   15   >