Re: [GIT PULL] x86/platform changes for v4.11

* Linus Torvalds wrote: > On Mon, Feb 20, 2017 at 5:17 AM, Ingo Molnar wrote: > > > > Mike Travis (2): > > [...] > > > > tra...@sgi.com (8): > > [...] > > Btw, can you be a bit more careful when applying patches to make sure > that

Re: [GIT PULL] x86/platform changes for v4.11

* Linus Torvalds wrote: > On Mon, Feb 20, 2017 at 5:17 AM, Ingo Molnar wrote: > > > > Mike Travis (2): > > [...] > > > > tra...@sgi.com (8): > > [...] > > Btw, can you be a bit more careful when applying patches to make sure > that the name and email address is actually good? Yes,

Re: [PATCHv2 4/5] perf stat: Add -a as a default target

On Mon, Feb 20, 2017 at 11:47:16PM +0100, Borislav Petkov wrote: > On Mon, Feb 20, 2017 at 06:22:54PM -0300, Arnaldo Carvalho de Melo wrote: > > Well, this one should be read (and written in the tool output as): > > > > > > Do you want to change that CNTR_NOT_SUPPORTED string unconditionally to

Re: [PATCHv2 4/5] perf stat: Add -a as a default target

On Mon, Feb 20, 2017 at 11:47:16PM +0100, Borislav Petkov wrote: > On Mon, Feb 20, 2017 at 06:22:54PM -0300, Arnaldo Carvalho de Melo wrote: > > Well, this one should be read (and written in the tool output as): > > > > > > Do you want to change that CNTR_NOT_SUPPORTED string unconditionally to

Re: [PATCH 11/18] perf stat: Add -a as default target

On Mon, Feb 20, 2017 at 08:59:32PM +0100, Borislav Petkov wrote: > On Mon, Feb 20, 2017 at 04:55:40PM -0300, Arnaldo Carvalho de Melo wrote: > > I answered to that message, have you seen it? > > Nope, there's nothing in my mbox from you on that thread after jolsa's > reply. Strange... > I think

Re: [PATCH 11/18] perf stat: Add -a as default target

On Mon, Feb 20, 2017 at 08:59:32PM +0100, Borislav Petkov wrote: > On Mon, Feb 20, 2017 at 04:55:40PM -0300, Arnaldo Carvalho de Melo wrote: > > I answered to that message, have you seen it? > > Nope, there's nothing in my mbox from you on that thread after jolsa's > reply. Strange... > I think

Re: [RFC PATCH 4/4] mmc: core: Implement mmc_partial_init during resume

On 20/02/17 10:03, Ritesh Harjani wrote: > This patch adds mmc_partial_init functionality > combining with CMD5 awake feature to reduce resume > latency for emmc. > > This is not enabled for HS400 mode, since tuning > in HS400 is required to be done in HS200 timing. How does that matter?

Re: [RFC PATCH 4/4] mmc: core: Implement mmc_partial_init during resume

On 20/02/17 10:03, Ritesh Harjani wrote: > This patch adds mmc_partial_init functionality > combining with CMD5 awake feature to reduce resume > latency for emmc. > > This is not enabled for HS400 mode, since tuning > in HS400 is required to be done in HS200 timing. How does that matter?

[PATCH] scsi: ufs: Factor out ufshcd_read_desc_param

Since in UFS 2.1 specification some of the descriptor lengths differs from 2.0 specification and some devices, which are reporting spec version 2.0 have different descriptor lengths we can not rely on hardcoded values taken from 2.0 specification. This patch introduces reading these lengths per

[PATCH] scsi: ufs: Factor out ufshcd_read_desc_param

Since in UFS 2.1 specification some of the descriptor lengths differs from 2.0 specification and some devices, which are reporting spec version 2.0 have different descriptor lengths we can not rely on hardcoded values taken from 2.0 specification. This patch introduces reading these lengths per

RE: [RFC 2/5] iwlwifi: fix request_module() use

> > On Sun, Feb 19, 2017 at 09:47:59AM +, Grumbach, Emmanuel wrote: > > > > > > The return value of request_module() being 0 does not mean that the > > > driver which was requested has loaded. To properly check that the > > > driver was loaded each driver can use internal mechanisms to vet

RE: [RFC 2/5] iwlwifi: fix request_module() use

> > On Sun, Feb 19, 2017 at 09:47:59AM +, Grumbach, Emmanuel wrote: > > > > > > The return value of request_module() being 0 does not mean that the > > > driver which was requested has loaded. To properly check that the > > > driver was loaded each driver can use internal mechanisms to vet

RE: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t

> On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova > wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to

RE: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t

> On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova > wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > >

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali, > Am 20.02.2017 um 20:42 schrieb Pali Rohár : > > Hi Nikolaus! > > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote: >> Hi Dmitry, >> >>> Input driver may set resolution for given axis in units per mm (or >>> units per radian for rotational axis

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali, > Am 20.02.2017 um 20:42 schrieb Pali Rohár : > > Hi Nikolaus! > > On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote: >> Hi Dmitry, >> >>> Input driver may set resolution for given axis in units per mm (or >>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ),

Re: [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid

On 02/21, Ye Xiaolong wrote: >On 02/20, Dou Liyang wrote: >>Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting >>time. >>It keeps consistent with the WorkQueue and avoids some bugs which may be >>caused >>by the dynamic assignment. >>As we know, It is implemented by the

Re: [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid

On 02/21, Ye Xiaolong wrote: >On 02/20, Dou Liyang wrote: >>Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting >>time. >>It keeps consistent with the WorkQueue and avoids some bugs which may be >>caused >>by the dynamic assignment. >>As we know, It is implemented by the

[PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

The rate_limit_us tunable is intended to reduce the possible overhead from running the schedutil governor. However, that overhead can be divided into two separate parts: the governor computations and the invocation of the scaling driver to set the CPU frequency. The latter is where the real

[PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

The rate_limit_us tunable is intended to reduce the possible overhead from running the schedutil governor. However, that overhead can be divided into two separate parts: the governor computations and the invocation of the scaling driver to set the CPU frequency. The latter is where the real

linux-next: Tree for Feb 21

Hi all, Please do not add any material intended for v4.12 to your linux-next included branches until after v4.11-rc1 has been released. Changes since 20170220: Non-merge commits (relative to Linus' tree): 9747 10343 files changed, 444283 insertions(+), 203458 deletions

linux-next: Tree for Feb 21

Hi all, Please do not add any material intended for v4.12 to your linux-next included branches until after v4.11-rc1 has been released. Changes since 20170220: Non-merge commits (relative to Linus' tree): 9747 10343 files changed, 444283 insertions(+), 203458 deletions

[PATCH] cpufreq: qoriq: clean up unused code

From: Tang Yuantian This snip code is not needed anymore since its user get_hard_smp_processor_id() has been removed. Signed-off-by: Tang Yuantian --- drivers/cpufreq/qoriq-cpufreq.c | 4 1 file changed, 4 deletions(-) diff --git

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

Adding Marc. On Monday 20 February 2017 04:39 PM, Mark Rutland wrote: On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote: The L3 cache PMU use N-N SPI interrupt which has no support in kernel mainline. Could you elaborate on what you mean by this? I don't understand what is meant here.

[PATCH] cpufreq: qoriq: clean up unused code

From: Tang Yuantian This snip code is not needed anymore since its user get_hard_smp_processor_id() has been removed. Signed-off-by: Tang Yuantian --- drivers/cpufreq/qoriq-cpufreq.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/cpufreq/qoriq-cpufreq.c

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

Adding Marc. On Monday 20 February 2017 04:39 PM, Mark Rutland wrote: On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote: The L3 cache PMU use N-N SPI interrupt which has no support in kernel mainline. Could you elaborate on what you mean by this? I don't understand what is meant here.

[PATCH V2 3/3] serial: sprd: adjust TIMEOUT to a big value

From: Wei Qiao SPRD_TIMEOUT was 256, which is too small to wait until the status switched to workable in a while loop, so that the earlycon could not work correctly. Signed-off-by: Wei Qiao Signed-off-by: Chunyan Zhang

[PATCH V2 3/3] serial: sprd: adjust TIMEOUT to a big value

From: Wei Qiao SPRD_TIMEOUT was 256, which is too small to wait until the status switched to workable in a while loop, so that the earlycon could not work correctly. Signed-off-by: Wei Qiao Signed-off-by: Chunyan Zhang --- drivers/tty/serial/sprd_serial.c | 2 +- 1 file changed, 1

[PATCH V2 2/3] Documentation: sprd: Add bindings for SP9860G

Added support for Spreadtrum SP9860G board and SC9860 SoC. This patch also revised bindings of SC9836 to make the format more clear. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/arm/sprd.txt | 13 -

[PATCH V2 2/3] Documentation: sprd: Add bindings for SP9860G

Added support for Spreadtrum SP9860G board and SC9860 SoC. This patch also revised bindings of SC9836 to make the format more clear. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/arm/sprd.txt | 13 - Documentation/devicetree/bindings/serial/sprd-uart.txt

[PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

From: Orson Zhai SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. According to regular hierarchy of sprd dts, whale2.dtsi contains SoC peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff and sp9860g dts is for the board

[PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

From: Orson Zhai SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. According to regular hierarchy of sprd dts, whale2.dtsi contains SoC peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff and sp9860g dts is for the board level. Signed-off-by: Orson

[PATCH V2 0/3] Add Spreadtrum SP9860G support

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided into 4 Big cores and 4 little cores. This patch-set only provides a basic configuration for SC9860 in device tree to make it run to console. We will continue to submit other drivers later on, which are using on Spreadtrum's

[PATCH V2 0/3] Add Spreadtrum SP9860G support

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided into 4 Big cores and 4 little cores. This patch-set only provides a basic configuration for SC9860 in device tree to make it run to console. We will continue to submit other drivers later on, which are using on Spreadtrum's

Re: [PATCH v3 13/18] power: supply: add battery driver for AXP20X and AXP22X PMICs

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. > > This patch adds the battery power supply driver to get various data from > the PMIC, such as the battery status (charging,

Re: [PATCH v3 13/18] power: supply: add battery driver for AXP20X and AXP22X PMICs

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. > > This patch adds the battery power supply driver to get various data from > the PMIC, such as the battery status (charging, discharging, full, > dead), current max

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Dmitry, > Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov : > > On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek wrote: >> Hi, >> >> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a): >>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Dmitry, > Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov : > > On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek wrote: >> Hi, >> >> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a): >>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller >>> wrote: > Am 20.02.2017 um 22:08 schrieb

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali, > Am 20.02.2017 um 23:04 schrieb Pali Rohár : > > On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote: >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár : >>> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote: While I'm

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali, > Am 20.02.2017 um 23:04 schrieb Pali Rohár : > > On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote: >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár : >>> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote: While I'm watching this discussion... in my opinion

Re: [PATCH 1/2] Fix format overflows

Thanks for looking at this. One quick question before I put out version two with your corrections: On Tue, 2017-02-21 at 07:12 +0100, Krzysztof Opasiak wrote: > Hi, >  > W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze: > > The usbip userspace tools call sprintf()/snprintf() and don't check > >

Re: [PATCH 1/2] Fix format overflows

Thanks for looking at this. One quick question before I put out version two with your corrections: On Tue, 2017-02-21 at 07:12 +0100, Krzysztof Opasiak wrote: > Hi, >  > W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze: > > The usbip userspace tools call sprintf()/snprintf() and don't check > >

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali, > Am 20.02.2017 um 22:54 schrieb Pali Rohár : > > On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote: >> Hi Pali, >> >>> Am 20.02.2017 um 22:07 schrieb Pali Rohár : >>> >>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller

[PATCH v2 1/2] add driver for cypress cy8cmbr3102

Version 2: * removed .owner * based on branch next Signed-off-by: Patrick Vogelaar --- drivers/input/misc/Kconfig | 12 +++ drivers/input/misc/Makefile | 1 + drivers/input/misc/cy8cmbr3102.c | 221 +++ 3 files

[PATCH v2 0/2] add driver for cypress cy8cmbr3102

* compiles without errors * no errors when using checkpatch * tested with a connected touch button on HW NOTE: This implementation does not implement the full range of functions the Cypress CY8CMBR3102 CapSense Express controller provides. It only implements its use for connected

[PATCH v2 0/2] add driver for cypress cy8cmbr3102

* compiles without errors * no errors when using checkpatch * tested with a connected touch button on HW NOTE: This implementation does not implement the full range of functions the Cypress CY8CMBR3102 CapSense Express controller provides. It only implements its use for connected

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali, > Am 20.02.2017 um 22:54 schrieb Pali Rohár : > > On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote: >> Hi Pali, >> >>> Am 20.02.2017 um 22:07 schrieb Pali Rohár : >>> >>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote: Hi Pali, > Am

[PATCH v2 1/2] add driver for cypress cy8cmbr3102

Version 2: * removed .owner * based on branch next Signed-off-by: Patrick Vogelaar --- drivers/input/misc/Kconfig | 12 +++ drivers/input/misc/Makefile | 1 + drivers/input/misc/cy8cmbr3102.c | 221 +++ 3 files changed, 234 insertions(+) create

[PATCH v2 2/2] add device tree documentation for cy8cmbr3102

Version 2: * based on branch next Signed-off-by: Patrick Vogelaar --- .../bindings/input/cypress,cy8cmbr3102.txt | 32 ++ 1 file changed, 32 insertions(+) create mode 100644

[PATCH v2 2/2] add device tree documentation for cy8cmbr3102

Version 2: * based on branch next Signed-off-by: Patrick Vogelaar --- .../bindings/input/cypress,cy8cmbr3102.txt | 32 ++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt diff --git

Re: [PATCH v3 14/18] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. > > This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the > AXP209, AXP221 and AXP223 MFD. > > Signed-off-by:

Re: [PATCH v3 14/18] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. > > This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the > AXP209, AXP221 and AXP223 MFD. > > Signed-off-by: Quentin Schulz > Acked-for-MFD-by:

[PATCH v2] iio: adc: xilinx: Fix error handling

Reorder error handling labels in order to match the way resources have been allocated. Signed-off-by: Christophe JAILLET --- v2: update goto label if 'xadc->ops->setup()' fails --- drivers/iio/adc/xilinx-xadc-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH v2] iio: adc: xilinx: Fix error handling

Reorder error handling labels in order to match the way resources have been allocated. Signed-off-by: Christophe JAILLET --- v2: update goto label if 'xadc->ops->setup()' fails --- drivers/iio/adc/xilinx-xadc-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi, > Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov : > > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller > wrote: >> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár : >>> >>> On Monday 20 February 2017 20:42:15 Pali

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi, > Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov : > > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller > wrote: >> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár : >>> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote: Hi Nikolaus! On Monday 20 February 2017

Re: [kernel-hardening] [RFC 2/7] init: add set_ro_mostly_after_init_rw/ro function

> On 20 Feb 2017, at 7:22 PM, Mark Rutland wrote: > > On Sun, Feb 19, 2017 at 07:04:05PM +0900, Hoeun Ryu wrote: >> Add set_ro_mostly_after_init_rw/ro pair to modify memory attributes for >> memory marked as `ro_mostly_after_init`. >> >> I am doubtful that this is the

Re: [kernel-hardening] [RFC 2/7] init: add set_ro_mostly_after_init_rw/ro function

> On 20 Feb 2017, at 7:22 PM, Mark Rutland wrote: > > On Sun, Feb 19, 2017 at 07:04:05PM +0900, Hoeun Ryu wrote: >> Add set_ro_mostly_after_init_rw/ro pair to modify memory attributes for >> memory marked as `ro_mostly_after_init`. >> >> I am doubtful that this is the right place where these

Re: [PATCH V2 0/5] thermal: minor cleanup/fixes

On Mon, 2017-02-20 at 15:59 +0530, Viresh Kumar wrote: > On 07-02-17, 09:39, Viresh Kumar wrote: > > > > Hi, > > > > This series contains minor fixes/cleanups for thermal cooling > > drivers. > > Acked-by: Zhang Rui for the whole patch series. As this patch set depends on

Re: [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker

> On 19 Feb 2017, at 8:24 PM, Ard Biesheuvel wrote: > > On 19 February 2017 at 10:04, Hoeun Ryu wrote: >> After `__ro_after_init` marker is included in kernel, many kernel data >> objects can be read-only-after-init. But there are many other

Re: [PATCH V2 0/5] thermal: minor cleanup/fixes

On Mon, 2017-02-20 at 15:59 +0530, Viresh Kumar wrote: > On 07-02-17, 09:39, Viresh Kumar wrote: > > > > Hi, > > > > This series contains minor fixes/cleanups for thermal cooling > > drivers. > > Acked-by: Zhang Rui for the whole patch series. As this patch set depends on commit 8a31d9d94297

Re: [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker

> On 19 Feb 2017, at 8:24 PM, Ard Biesheuvel wrote: > > On 19 February 2017 at 10:04, Hoeun Ryu wrote: >> After `__ro_after_init` marker is included in kernel, many kernel data >> objects can be read-only-after-init. But there are many other places that >> would be good to read-only-after-init

Re: [PATCH v3 11/18] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. > > This patch adds the DT binding documentation for the battery power > supply which gets various data from the PMIC, such as the

Re: [PATCH v3 11/18] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. > > This patch adds the DT binding documentation for the battery power > supply which gets various data from the PMIC, such as the battery status > (charging,

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

> On 19 Feb 2017, at 8:14 PM, Ard Biesheuvel wrote: > > Hi Hoeun, > > On 19 February 2017 at 10:03, Hoeun Ryu wrote: >> After `__ro_after_init` marker is included in kernel, many kernel data >> objects can be read-only-after-init. But there are

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

> On 19 Feb 2017, at 8:14 PM, Ard Biesheuvel wrote: > > Hi Hoeun, > > On 19 February 2017 at 10:03, Hoeun Ryu wrote: >> After `__ro_after_init` marker is included in kernel, many kernel data >> objects can be read-only-after-init. But there are many other places that >> would be good to

[PATCHv2] rtc: cpcap: new rtc driver

This driver supports the Motorola CPCAP PMIC found on some of Motorola's mobile phones, such as the Droid 4. Tested-by: Tony Lindgren Signed-off-by: Sebastian Reichel --- Changes to PATCHv1: - added device_init_wakeup() at the end of probe - added Tested-by

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

On Tue, Feb 21, 2017 at 11:20:58AM +0530, Nayna wrote: > > > On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote: > > On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote: > > > There's no need to export tpm2_get_pcr_alloation() because it is only > > > a helper function for

[PATCHv2] rtc: cpcap: new rtc driver

This driver supports the Motorola CPCAP PMIC found on some of Motorola's mobile phones, such as the Droid 4. Tested-by: Tony Lindgren Signed-off-by: Sebastian Reichel --- Changes to PATCHv1: - added device_init_wakeup() at the end of probe - added Tested-by from Tony ---

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

On Tue, Feb 21, 2017 at 11:20:58AM +0530, Nayna wrote: > > > On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote: > > On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote: > > > There's no need to export tpm2_get_pcr_alloation() because it is only > > > a helper function for

Re: [Linaro-mm-sig] [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE

Hi Laura, When we enable kernel v4.4 or newer version on our platform, we meet the issue of flushing cache without reference device. It seems that this patch set is a solution. I'm curious the progress of the discussion. Do you have any plan to fix it in v4.4 and newer kernel verison? On

Re: [Linaro-mm-sig] [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE

Hi Laura, When we enable kernel v4.4 or newer version on our platform, we meet the issue of flushing cache without reference device. It seems that this patch set is a solution. I'm curious the progress of the discussion. Do you have any plan to fix it in v4.4 and newer kernel verison? On

Re: [PATCH 1/2] Fix format overflows

Hi, W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze: The usbip userspace tools call sprintf()/snprintf() and don't check for the return value which can lead the paths to overflow, truncating the final file in the path. More urgently, GCC 7 now warns that these aren't checked with

Re: [PATCH 1/2] Fix format overflows

Hi, W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze: The usbip userspace tools call sprintf()/snprintf() and don't check for the return value which can lead the paths to overflow, truncating the final file in the path. More urgently, GCC 7 now warns that these aren't checked with

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

> On 20 Feb 2017, at 7:02 PM, Mark Rutland wrote: > > On Sun, Feb 19, 2017 at 07:03:38PM +0900, Hoeun Ryu wrote: >> After `__ro_after_init` marker is included in kernel, many kernel data >> objects can be read-only-after-init. But there are many other places that >> would

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

> On 20 Feb 2017, at 7:02 PM, Mark Rutland wrote: > > On Sun, Feb 19, 2017 at 07:03:38PM +0900, Hoeun Ryu wrote: >> After `__ro_after_init` marker is included in kernel, many kernel data >> objects can be read-only-after-init. But there are many other places that >> would be good to

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

Sigh... apologies for the HTML. Trying again... On Mon, Feb 20, 2017 at 9:21 PM, Michael Pratt wrote: > On Fri, Feb 17, 2017 at 3:02 PM, Andy Lutomirski wrote: >> On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds >> wrote: >>>

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

Sigh... apologies for the HTML. Trying again... On Mon, Feb 20, 2017 at 9:21 PM, Michael Pratt wrote: > On Fri, Feb 17, 2017 at 3:02 PM, Andy Lutomirski wrote: >> On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds >> wrote: >>> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski >>> wrote:

Re: [PATCH v3 15/18] ARM: dtsi: axp209: add battery power supply subnode

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP209 PMIC exposes battery supply various data such as > the battery status (charging, discharging, full, dead), current max > limit, current current, battery capacity (in percentage),

Re: [PATCH v3 15/18] ARM: dtsi: axp209: add battery power supply subnode

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP209 PMIC exposes battery supply various data such as > the battery status (charging, discharging, full, dead), current max > limit, current current, battery capacity (in percentage), voltage max > and min limits, current

Re: [PATCH v3 16/18] ARM: dtsi: axp22x: add battery power supply subnode

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP22X PMIC exposes battery supply various data such as > the battery status (charging, discharging, full, dead), current max > limit, current current, battery capacity (in percentage),

Re: [PATCH v3 16/18] ARM: dtsi: axp22x: add battery power supply subnode

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The X-Powers AXP22X PMIC exposes battery supply various data such as > the battery status (charging, discharging, full, dead), current max > limit, current current, battery capacity (in percentage), voltage max > limit, current voltage, and

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote: On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote: There's no need to export tpm2_get_pcr_alloation() because it is only a helper function for tpm2_auto_startup(). For the same reason it does not make much sense to maintain

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote: On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote: There's no need to export tpm2_get_pcr_alloation() because it is only a helper function for tpm2_auto_startup(). For the same reason it does not make much sense to maintain

Re: [RFC 5/7] cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states

> On 20 Feb 2017, at 5:20 PM, Sebastian Andrzej Siewior > wrote: > > On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote: >> It would be good that `__ro_mostly_after_init` is marked to cpuhp state >> objects. > why? > I’m requesting for comments of a new feature called

Re: [RFC 5/7] cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states

> On 20 Feb 2017, at 5:20 PM, Sebastian Andrzej Siewior > wrote: > > On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote: >> It would be good that `__ro_mostly_after_init` is marked to cpuhp state >> objects. > why? > I’m requesting for comments of a new feature called __ro_mostly_after_init

Re: [PATCH v3 17/18] ARM: dts: sun8i: sina33: enable battery power supply subnode

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we > enable the battery power supply subnode in its Device Tree. > > Signed-off-by: Quentin Schulz >

Re: [PATCH v3 17/18] ARM: dts: sun8i: sina33: enable battery power supply subnode

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz wrote: > The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we > enable the battery power supply subnode in its Device Tree. > > Signed-off-by: Quentin Schulz > Acked-by: Maxime Ripard Battery charger enabled without any

Re: [PATCH 2/4] ARM: dts: da850: add vpif video display pins

On Monday 20 February 2017 09:12 PM, Bartosz Golaszewski wrote: > 2017-02-20 11:29 GMT+01:00 Sekhar Nori : >> On Thursday 16 February 2017 11:45 PM, Bartosz Golaszewski wrote: >>> Add a new pinctrl sub-node for vpif display pins. Move VP_CLKIN3 and >>> VP_CLKIN2 to the display node

Re: [PATCH 2/4] ARM: dts: da850: add vpif video display pins

On Monday 20 February 2017 09:12 PM, Bartosz Golaszewski wrote: > 2017-02-20 11:29 GMT+01:00 Sekhar Nori : >> On Thursday 16 February 2017 11:45 PM, Bartosz Golaszewski wrote: >>> Add a new pinctrl sub-node for vpif display pins. Move VP_CLKIN3 and >>> VP_CLKIN2 to the display node where they

Re: next-20170220 failed to build on PowerPC

On 2017-02-20 16:25, abdul wrote: Hi, next-20170220 fails to build on Power 8 (PowerVM LPAR) with these errors. with same config, next-20170215 builds fine. the config file used is attached, by default CONFIG_VIRT_CPU_ACCOUNTING_NATIVE was not set. (X) Simple tick based cputime accounting

[PATCH] auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches

The OF device table must be terminated, otherwise we'll be walking past it and into areas unknown. This causes KASAN errors reported by 0day kernel testing robot. Reported-by: Fengguang Wu Tested-by: Fengguang Wu Fixes: 0cad855fbd08 ("auxdisplay:

Re: next-20170220 failed to build on PowerPC

On 2017-02-20 16:25, abdul wrote: Hi, next-20170220 fails to build on Power 8 (PowerVM LPAR) with these errors. with same config, next-20170215 builds fine. the config file used is attached, by default CONFIG_VIRT_CPU_ACCOUNTING_NATIVE was not set. (X) Simple tick based cputime accounting

[PATCH] auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches

The OF device table must be terminated, otherwise we'll be walking past it and into areas unknown. This causes KASAN errors reported by 0day kernel testing robot. Reported-by: Fengguang Wu Tested-by: Fengguang Wu Fixes: 0cad855fbd08 ("auxdisplay: img-ascii-lcd: driver for simple ASCII...") Cc:

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

> > No. > > IMO Not fixing this immediately through stable is out of the question. > The deal is that we don't break userspace. > Having said that, I'm not against a long term vmwgfx-only solution. But > let's fix this now. > > Admittedly we missed testing this but you got to understand that

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

> > No. > > IMO Not fixing this immediately through stable is out of the question. > The deal is that we don't break userspace. > Having said that, I'm not against a long term vmwgfx-only solution. But > let's fix this now. > > Admittedly we missed testing this but you got to understand that

DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

No. IMO Not fixing this immediately through stable is out of the question. The deal is that we don't break userspace. Having said that, I'm not against a long term vmwgfx-only solution. But let's fix this now. Admittedly we missed testing this but you got to understand that not all developer

Re: [LKP] [hrtimer] 336a9cde10 WARNING: CPU: 1 PID: 1 at kernel/time/hrtimer.c:1090 hrtimer_init

On 02/21, Ye Xiaolong wrote: >Hi, fengguang >On 02/20, Thomas Gleixner wrote: >>On Tue, 21 Feb 2017, Fengguang Wu wrote: >> >>> Hi Marc, >>> >>> FYI here is another bisect result. The attached reproduce-* script can >>> be used to reproduce the bug. >> >>Again. This is a problem in the calling

DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

No. IMO Not fixing this immediately through stable is out of the question. The deal is that we don't break userspace. Having said that, I'm not against a long term vmwgfx-only solution. But let's fix this now. Admittedly we missed testing this but you got to understand that not all developer

Re: [LKP] [hrtimer] 336a9cde10 WARNING: CPU: 1 PID: 1 at kernel/time/hrtimer.c:1090 hrtimer_init

On 02/21, Ye Xiaolong wrote: >Hi, fengguang >On 02/20, Thomas Gleixner wrote: >>On Tue, 21 Feb 2017, Fengguang Wu wrote: >> >>> Hi Marc, >>> >>> FYI here is another bisect result. The attached reproduce-* script can >>> be used to reproduce the bug. >> >>Again. This is a problem in the calling

  1   2   3   4   5   6   7   8   9   10   >