Re: [PATCH] MAINTAINERS: intel_telemetry: Update maintainers info

On Tue, Oct 9, 2018 at 5:12 PM Bhardwaj, Rajneesh wrote: > > > > On 09-Oct-18 5:07 PM, Andy Shevchenko wrote: > > On Mon, Oct 8, 2018 at 5:44 PM Rajneesh Bhardwaj > > wrote: > >> Add myself and David as the new maintainers for Intel Telemetry driver. > >> > > There is no explanation why. > >

Re: [PATCH] MAINTAINERS: intel_telemetry: Update maintainers info

On Tue, Oct 9, 2018 at 5:12 PM Bhardwaj, Rajneesh wrote: > > > > On 09-Oct-18 5:07 PM, Andy Shevchenko wrote: > > On Mon, Oct 8, 2018 at 5:44 PM Rajneesh Bhardwaj > > wrote: > >> Add myself and David as the new maintainers for Intel Telemetry driver. > >> > > There is no explanation why. > >

Re: [PATCH 0/2] phy: ocelot-serdes: fix out-of-bounds bug

On 10/9/18 9:28 AM, Quentin Schulz wrote: > Hi Gustavo, > > On Tue, Oct 09, 2018 at 12:20:28AM +0200, Gustavo A. R. Silva wrote: >> This patchset aims to fix an out-of-bounds bug in >> the phy-ocelot-serdes driver. >> >> Currently, there is an out-of-bounds read on array ctrl->phys, >> once

Re: [PATCH 0/2] phy: ocelot-serdes: fix out-of-bounds bug

On 10/9/18 9:28 AM, Quentin Schulz wrote: > Hi Gustavo, > > On Tue, Oct 09, 2018 at 12:20:28AM +0200, Gustavo A. R. Silva wrote: >> This patchset aims to fix an out-of-bounds bug in >> the phy-ocelot-serdes driver. >> >> Currently, there is an out-of-bounds read on array ctrl->phys, >> once

Re: [PATCH] MAINTAINERS: intel_telemetry: Update maintainers info

On 09-Oct-18 5:07 PM, Andy Shevchenko wrote: On Mon, Oct 8, 2018 at 5:44 PM Rajneesh Bhardwaj wrote: Add myself and David as the new maintainers for Intel Telemetry driver. There is no explanation why. (Like previous one left the company, and / or you are doing set of the drivers related

Re: [PATCH] MAINTAINERS: intel_telemetry: Update maintainers info

On 09-Oct-18 5:07 PM, Andy Shevchenko wrote: On Mon, Oct 8, 2018 at 5:44 PM Rajneesh Bhardwaj wrote: Add myself and David as the new maintainers for Intel Telemetry driver. There is no explanation why. (Like previous one left the company, and / or you are doing set of the drivers related

Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm

On Tue 09-10-18 22:51:00, Tetsuo Handa wrote: > On 2018/10/09 22:26, Michal Hocko wrote: > > On Tue 09-10-18 22:14:24, Tetsuo Handa wrote: > >> On 2018/10/09 21:58, Michal Hocko wrote: > >>> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote: > On 2018/10/09 20:10, Michal Hocko wrote: > > On

Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm

On Tue 09-10-18 22:51:00, Tetsuo Handa wrote: > On 2018/10/09 22:26, Michal Hocko wrote: > > On Tue 09-10-18 22:14:24, Tetsuo Handa wrote: > >> On 2018/10/09 21:58, Michal Hocko wrote: > >>> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote: > On 2018/10/09 20:10, Michal Hocko wrote: > > On

[PATCH 6/6] arm64: dts: xilinx: ultra96: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 6/6] arm64: dts: xilinx: ultra96: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 4/6] arm64: dts: hisilicon: hikey960: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 5/6] arm64: dts: hisilicon: poplar: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 4/6] arm64: dts: hisilicon: hikey960: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 5/6] arm64: dts: hisilicon: poplar: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 1/6] arm64: dts: rockchip: ficus: Add on-board LED support

Add on-board LED support for Ficus board based on the following standard used by other 96Boards: device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3

[PATCH 1/6] arm64: dts: rockchip: ficus: Add on-board LED support

Add on-board LED support for Ficus board based on the following standard used by other 96Boards: device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3

[PATCH 3/6] arm64: dts: hisilicon: hikey: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 3/6] arm64: dts: hisilicon: hikey: Standardize LED labels and triggers

For all 96Boards, the following standard is used for onboard LEDs. device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD-card)

[PATCH 2/6] arm64: dts: rockchip: rock960: Add on-board LED support

Add on-board LED support for Rock960 board based on the following standard used by rest of the 96Boards: device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage)

[PATCH 2/6] arm64: dts: rockchip: rock960: Add on-board LED support

Add on-board LED support for Rock960 board based on the following standard used by rest of the 96Boards: device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage)

[PATCH 0/6] Standardize onboard LED support for 96Boards

This patchset standardizes the onboard LEDs on 96Boards by maintaining common labels and triggers as below: device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD card)

[PATCH 0/6] Standardize onboard LED support for 96Boards

This patchset standardizes the onboard LEDs on 96Boards by maintaining common labels and triggers as below: device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: mmc0/disk-activity (onboard-storage) device-name:green:user3 default-trigger: mmc1 (SD card)

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

Hi Quentin, On 09.10.2018 09:52, Quentin Schulz wrote: Hi Frieder, On Mon, Oct 08, 2018 at 11:53:21AM +0200, Frieder Schrempf wrote: Hi, On 27.09.2018 10:14, Maxime Ripard wrote: On Wed, Sep 26, 2018 at 10:19:22PM +0200, Hans de Goede wrote: On 26-09-18 16:44, Frieder Schrempf wrote: Hi,

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

Hi Quentin, On 09.10.2018 09:52, Quentin Schulz wrote: Hi Frieder, On Mon, Oct 08, 2018 at 11:53:21AM +0200, Frieder Schrempf wrote: Hi, On 27.09.2018 10:14, Maxime Ripard wrote: On Wed, Sep 26, 2018 at 10:19:22PM +0200, Hans de Goede wrote: On 26-09-18 16:44, Frieder Schrempf wrote: Hi,

Re: [PATCH 01/12] tools include: Adopt linux/bits.h

Em Tue, Oct 09, 2018 at 10:47:35AM +0200, Alexander Sverdlin escreveu: > Hello Arnaldo, > > On 09/10/2018 02:54, Arnaldo Carvalho de Melo wrote: > > From: Arnaldo Carvalho de Melo > > > > So that we reduce the difference of tools/include/linux/bitops.h to the > > original kernel file,

Re: [PATCH 01/12] tools include: Adopt linux/bits.h

Em Tue, Oct 09, 2018 at 10:47:35AM +0200, Alexander Sverdlin escreveu: > Hello Arnaldo, > > On 09/10/2018 02:54, Arnaldo Carvalho de Melo wrote: > > From: Arnaldo Carvalho de Melo > > > > So that we reduce the difference of tools/include/linux/bitops.h to the > > original kernel file,

[PATCH v1 2/2] clk: qcom : dispcc: Add support for display port clocks

SDM845 dispcc supports RCG and CBCRs for display port, so add support for the same. Signed-off-by: Taniya Das --- drivers/clk/qcom/dispcc-sdm845.c | 232 + include/dt-bindings/clock/qcom,dispcc-sdm845.h | 11 ++ 2 files changed, 243 insertions(+) diff

[PATCH v1 0/2] Add support for display port clocks and clock ops

New display port clock ops supported for display port clocks. Also add support for the display port related branches and RCGs. Taniya Das (2): clk: qcom: rcg2: Add support for display port clock ops clk: qcom : dispcc: Add support for display port clocks drivers/clk/qcom/clk-rcg.h

[PATCH v1 1/2] clk: qcom: rcg2: Add support for display port clock ops

New display port clock ops supported for display port clocks. Signed-off-by: Taniya Das --- drivers/clk/qcom/clk-rcg.h | 1 + drivers/clk/qcom/clk-rcg2.c | 86 + 2 files changed, 87 insertions(+) diff --git a/drivers/clk/qcom/clk-rcg.h

[PATCH v1 2/2] clk: qcom : dispcc: Add support for display port clocks

SDM845 dispcc supports RCG and CBCRs for display port, so add support for the same. Signed-off-by: Taniya Das --- drivers/clk/qcom/dispcc-sdm845.c | 232 + include/dt-bindings/clock/qcom,dispcc-sdm845.h | 11 ++ 2 files changed, 243 insertions(+) diff

[PATCH v1 0/2] Add support for display port clocks and clock ops

New display port clock ops supported for display port clocks. Also add support for the display port related branches and RCGs. Taniya Das (2): clk: qcom: rcg2: Add support for display port clock ops clk: qcom : dispcc: Add support for display port clocks drivers/clk/qcom/clk-rcg.h

[PATCH v1 1/2] clk: qcom: rcg2: Add support for display port clock ops

New display port clock ops supported for display port clocks. Signed-off-by: Taniya Das --- drivers/clk/qcom/clk-rcg.h | 1 + drivers/clk/qcom/clk-rcg2.c | 86 + 2 files changed, 87 insertions(+) diff --git a/drivers/clk/qcom/clk-rcg.h

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86 PMD migration entry check) On 8 Oct 2018, at 23:58, Anshuman Khandual wrote: > A normal mapped THP page at PMD level should be correctly differentiated > from a PMD migration entry while walking the page table. A

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86 PMD migration entry check) On 8 Oct 2018, at 23:58, Anshuman Khandual wrote: > A normal mapped THP page at PMD level should be correctly differentiated > from a PMD migration entry while walking the page table. A

Re: [PATCH v5 4/4] printk: Give error on attempt to set log buffer length to over 4G

On (10/09/18 15:05), Petr Mladek wrote: > > > > Yeah, I think we gonna have problems even with a 4G logbuf and a 32-bit > > user-space doing syslog(int len). > > > > I agree on the "not motivated enough" part ;) > > OK, I have pushed an updated patch that has the limit 2GB > into printk.git,

Re: [PATCH v5 4/4] printk: Give error on attempt to set log buffer length to over 4G

On (10/09/18 15:05), Petr Mladek wrote: > > > > Yeah, I think we gonna have problems even with a 4G logbuf and a 32-bit > > user-space doing syslog(int len). > > > > I agree on the "not motivated enough" part ;) > > OK, I have pushed an updated patch that has the limit 2GB > into printk.git,

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

> -Original Message- > From: Greg Kroah-Hartman > Sent: Tuesday, October 9, 2018 8:45 AM > To: Deucher, Alexander > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Wentland, Harry > ; Zhu, Rex ; Sasha Levin > > Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

> -Original Message- > From: Greg Kroah-Hartman > Sent: Tuesday, October 9, 2018 8:45 AM > To: Deucher, Alexander > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Wentland, Harry > ; Zhu, Rex ; Sasha Levin > > Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock

Re: [PATCH v3 5/8] dt-bindings: input: document stpmic1 pmic onkey

Le 10/08/2018 06:29 PM, Pascal PAILLET-LME a écrit : > From: pascal paillet > > The stpmic1 pmic is able to manage an onkey button. It can be configured > to shut-down the power supplies on a long key-press with an adjustable > duration. > > Signed-off-by: pascal paillet > --- > changes in v3: >

Re: [PATCH v3 5/8] dt-bindings: input: document stpmic1 pmic onkey

Le 10/08/2018 06:29 PM, Pascal PAILLET-LME a écrit : > From: pascal paillet > > The stpmic1 pmic is able to manage an onkey button. It can be configured > to shut-down the power supplies on a long key-press with an adjustable > duration. > > Signed-off-by: pascal paillet > --- > changes in v3: >

[no subject]

สวัสดีวันดีขอให้คุณเขียนจดหมายกลับมาฉันมีเรื่องสำคัญในการพูดคุยกับคุณ

[no subject]

สวัสดีวันดีขอให้คุณเขียนจดหมายกลับมาฉันมีเรื่องสำคัญในการพูดคุยกับคุณ

Re: [PATCH] Revert "perf tools: Fix PMU term format max value calculation"

Em Tue, Oct 09, 2018 at 11:59:17AM +0200, Jiri Olsa escreveu: > ping oops, applied to perf/urgent, added a Fixes: line so that stable@ pick this up. - Arnaldo > thanks, > jirka > > On Wed, Oct 03, 2018 at 09:20:46AM +0200, Jiri Olsa wrote: > > This reverts commit

Re: [PATCH] Revert "perf tools: Fix PMU term format max value calculation"

Em Tue, Oct 09, 2018 at 11:59:17AM +0200, Jiri Olsa escreveu: > ping oops, applied to perf/urgent, added a Fixes: line so that stable@ pick this up. - Arnaldo > thanks, > jirka > > On Wed, Oct 03, 2018 at 09:20:46AM +0200, Jiri Olsa wrote: > > This reverts commit

Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm

On 2018/10/09 22:26, Michal Hocko wrote: > On Tue 09-10-18 22:14:24, Tetsuo Handa wrote: >> On 2018/10/09 21:58, Michal Hocko wrote: >>> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote: On 2018/10/09 20:10, Michal Hocko wrote: > On Tue 09-10-18 19:00:44, Tetsuo Handa wrote: >>> 2) add

Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm

On 2018/10/09 22:26, Michal Hocko wrote: > On Tue 09-10-18 22:14:24, Tetsuo Handa wrote: >> On 2018/10/09 21:58, Michal Hocko wrote: >>> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote: On 2018/10/09 20:10, Michal Hocko wrote: > On Tue 09-10-18 19:00:44, Tetsuo Handa wrote: >>> 2) add

Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function

Mark Brown writes: > On Tue, Oct 09, 2018 at 12:05:22PM +0200, Boris Brezillon wrote: >> On Tue, 9 Oct 2018 09:52:23 + >> Chuanhua Han wrote: > >> > 1. In the dspi driver (spi controller), bits_per_word >> > (dspi->bits_per_word = transfer->bits_per_word) passed from the upper >> > layer

Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function

Mark Brown writes: > On Tue, Oct 09, 2018 at 12:05:22PM +0200, Boris Brezillon wrote: >> On Tue, 9 Oct 2018 09:52:23 + >> Chuanhua Han wrote: > >> > 1. In the dspi driver (spi controller), bits_per_word >> > (dspi->bits_per_word = transfer->bits_per_word) passed from the upper >> > layer

[PATCH v2 3/3] arm64: cpufeature: Trap CTR_EL0 access only where it is necessary

When there is a mismatch in the CTR_EL0 field, we trap access to CTR from EL0 on all CPUs to expose the safe value. However, we could skip trapping on a CPU which matches the safe value. Cc: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Suzuki K Poulose ---

[PATCH v2 1/3] arm64: cpufeature: ctr: Fix cpu capability check for late CPUs

The matches() routine for a capability must honor the "scope" passed to it and return the proper results. i.e, when passed with SCOPE_LOCAL_CPU, it should check the status of the capability on the current CPU. This is used by verify_local_cpu_capabilities() on a late secondary CPU to make sure

[PATCH v2 2/3] arm64: cpufeature: Fix handling of CTR_EL0.IDC field

CTR_EL0.IDC reports the data cache clean requirements for instruction to data coherence. However, if the field is 0, we need to check the CLIDR_EL1 fields to detect the status of the feature. Currently we don't do this and generate a warning with tainting the kernel, when there is a mismatch in

[PATCH v2 3/3] arm64: cpufeature: Trap CTR_EL0 access only where it is necessary

When there is a mismatch in the CTR_EL0 field, we trap access to CTR from EL0 on all CPUs to expose the safe value. However, we could skip trapping on a CPU which matches the safe value. Cc: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Suzuki K Poulose ---

[PATCH v2 1/3] arm64: cpufeature: ctr: Fix cpu capability check for late CPUs

The matches() routine for a capability must honor the "scope" passed to it and return the proper results. i.e, when passed with SCOPE_LOCAL_CPU, it should check the status of the capability on the current CPU. This is used by verify_local_cpu_capabilities() on a late secondary CPU to make sure

[PATCH v2 2/3] arm64: cpufeature: Fix handling of CTR_EL0.IDC field

CTR_EL0.IDC reports the data cache clean requirements for instruction to data coherence. However, if the field is 0, we need to check the CLIDR_EL1 fields to detect the status of the feature. Currently we don't do this and generate a warning with tainting the kernel, when there is a mismatch in

[PATCH v2 0/3] arm64: cpufeature: Fix handling of CTR_EL0

This series makes sure that we handle the CTR_EL0 field mismatches properly, especially for the IDC field. Also, skip trapping CTR accesses on a CPU if it matches the safe value. Applies on arm64 for-next/core. Changes since v1 - Fix wrong hunk in has_cache_idc() - Allow a late secondary CPU

[PATCH v2 0/3] arm64: cpufeature: Fix handling of CTR_EL0

This series makes sure that we handle the CTR_EL0 field mismatches properly, especially for the IDC field. Also, skip trapping CTR accesses on a CPU if it matches the safe value. Applies on arm64 for-next/core. Changes since v1 - Fix wrong hunk in has_cache_idc() - Allow a late secondary CPU

[PATCH v2 0/3] arm64: cpufeature: Fix handling of CTR_EL0

This series makes sure that we handle the CTR_EL0 field mismatches properly, especially for the IDC field. Also, skip trapping CTR accesses on a CPU if it matches the safe value. Applies on arm64 for-next/core. Changes since v1 - Fix wrong hunk in has_cache_idc() - Allow a late secondary CPU

[PATCH v2 0/3] arm64: cpufeature: Fix handling of CTR_EL0

This series makes sure that we handle the CTR_EL0 field mismatches properly, especially for the IDC field. Also, skip trapping CTR accesses on a CPU if it matches the safe value. Applies on arm64 for-next/core. Changes since v1 - Fix wrong hunk in has_cache_idc() - Allow a late secondary CPU

Re: [PATCH 2/2] ASoC: max98927: Add reset-gpio support

+reset controller maintainer Philipp Hi Mark, Sorry for the late reply. It took me a while to investigate reset controller and its possible usage. I would like to figure out the proper way of reset handling because it is common to have a shared reset line for two max98927 codecs for left and

Re: [PATCH 2/2] ASoC: max98927: Add reset-gpio support

+reset controller maintainer Philipp Hi Mark, Sorry for the late reply. It took me a while to investigate reset controller and its possible usage. I would like to figure out the proper way of reset handling because it is common to have a shared reset line for two max98927 codecs for left and

Re: [PATCH v3 1/7] dt-bindings: stm32-dma: Add DMA/MDMA chaining support bindings

On 10/09/2018 10:57 AM, Vinod wrote: > Hi Pierre, > > On 09-10-18, 09:18, Pierre Yves MORDRET wrote: > * DMA client @@ -68,7 +84,16 @@ channel: a phandle to the DMA controller plus the following four integer cells: 0x1: 1/2 full FIFO 0x2: 3/4 full FIFO

Re: [PATCH v3 1/7] dt-bindings: stm32-dma: Add DMA/MDMA chaining support bindings

On 10/09/2018 10:57 AM, Vinod wrote: > Hi Pierre, > > On 09-10-18, 09:18, Pierre Yves MORDRET wrote: > * DMA client @@ -68,7 +84,16 @@ channel: a phandle to the DMA controller plus the following four integer cells: 0x1: 1/2 full FIFO 0x2: 3/4 full FIFO

Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period constraint [Resend in plain text...]

On Tue, 09 Oct 2018 15:18:15 +0200, Mike Brady wrote: > > >> @Mike: Do you want to write a patch series which upstream "interpolate > >> audio delay" and addresses Takashi's comments? > >> > >> I would help you, in case you have questions about setup a Raspberry Pi > >> with Mainline kernel or

Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period constraint [Resend in plain text...]

On Tue, 09 Oct 2018 15:18:15 +0200, Mike Brady wrote: > > >> @Mike: Do you want to write a patch series which upstream "interpolate > >> audio delay" and addresses Takashi's comments? > >> > >> I would help you, in case you have questions about setup a Raspberry Pi > >> with Mainline kernel or

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

On 10/09/2018 06:34 PM, Kirill A. Shutemov wrote: > On Tue, Oct 09, 2018 at 09:28:58AM +0530, Anshuman Khandual wrote: >> A normal mapped THP page at PMD level should be correctly differentiated >> from a PMD migration entry while walking the page table. A mapped THP would >> additionally check

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

On 10/09/2018 06:34 PM, Kirill A. Shutemov wrote: > On Tue, Oct 09, 2018 at 09:28:58AM +0530, Anshuman Khandual wrote: >> A normal mapped THP page at PMD level should be correctly differentiated >> from a PMD migration entry while walking the page table. A mapped THP would >> additionally check

Re: [PATCH v4] perf record: encode -k clockid frequency into Perf trace

Em Tue, Oct 09, 2018 at 09:59:03AM +0300, Alexey Budankov escreveu: > > Store -k clockid frequency into Perf trace to enable timestamps > derived metrics conversion into wall clock time on reporting stage. > > Below is the example of perf report output: Some questions below, left the code for

Re: [PATCH v4] perf record: encode -k clockid frequency into Perf trace

Em Tue, Oct 09, 2018 at 09:59:03AM +0300, Alexey Budankov escreveu: > > Store -k clockid frequency into Perf trace to enable timestamps > derived metrics conversion into wall clock time on reporting stage. > > Below is the example of perf report output: Some questions below, left the code for

Re: [PATCH 12/16] locking/mutex: Replace spin_is_locked() with lockdep

On Tue, Oct 09, 2018 at 01:18:10PM +0100, Will Deacon wrote: > On Tue, Oct 02, 2018 at 10:38:58PM -0700, Lance Roy wrote: > > lockdep_assert_held() is better suited to checking locking requirements, > > since it won't get confused when someone else holds the lock. This is > > also a step towards

Re: [PATCH 12/16] locking/mutex: Replace spin_is_locked() with lockdep

On Tue, Oct 09, 2018 at 01:18:10PM +0100, Will Deacon wrote: > On Tue, Oct 02, 2018 at 10:38:58PM -0700, Lance Roy wrote: > > lockdep_assert_held() is better suited to checking locking requirements, > > since it won't get confused when someone else holds the lock. This is > > also a step towards

Pinmuxing and SDHC speeds on sdhci-esdhc-imx

I have a question regarding the pinstate and the corresponding uhs_signaling. The uhs_signaling shows a variety of timing options, MMC_TIMING_UHS_SDR12, MMC_TIMING_UHS_SDR25:, MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_SDR104, MMC_TIMING_MMC_HS200, MMC_TIMING_UHS_DDR50, MMC_TIMING_MMC_DDR52,

Pinmuxing and SDHC speeds on sdhci-esdhc-imx

I have a question regarding the pinstate and the corresponding uhs_signaling. The uhs_signaling shows a variety of timing options, MMC_TIMING_UHS_SDR12, MMC_TIMING_UHS_SDR25:, MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_SDR104, MMC_TIMING_MMC_HS200, MMC_TIMING_UHS_DDR50, MMC_TIMING_MMC_DDR52,

Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset gpio signal polarity

On 10/09/2018 03:18 PM, Vokáč Michal wrote: > On 9.10.2018 14:36, Fabio Estevam wrote: >> Hi Michal, >> >> On Tue, Oct 9, 2018 at 5:30 AM Vokáč Michal wrote: >> >>> Sorry for the inconvenience :( Lesson learned.. >>> >>> So in other words (no offense): broken drivers need to stay broken because

Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset gpio signal polarity

On 10/09/2018 03:18 PM, Vokáč Michal wrote: > On 9.10.2018 14:36, Fabio Estevam wrote: >> Hi Michal, >> >> On Tue, Oct 9, 2018 at 5:30 AM Vokáč Michal wrote: >> >>> Sorry for the inconvenience :( Lesson learned.. >>> >>> So in other words (no offense): broken drivers need to stay broken because

Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period constraint [Resend in plain text...]

Hi there. Apologies for the delay. The issue here is not the 10ms period constrain -- it’s the possible addition of code to interpolate the playback position between GPU-driven updates. The intention is to give userland a jitter-free view of the playback position. > On 19 Sep 2018, at 19:39,

Re: [PATCH 17/29] staging: bcm2835-audio: Add 10ms period constraint [Resend in plain text...]

Hi there. Apologies for the delay. The issue here is not the 10ms period constrain -- it’s the possible addition of code to interpolate the playback position between GPU-driven updates. The intention is to give userland a jitter-free view of the playback position. > On 19 Sep 2018, at 19:39,

[PATCH 02/33] powerpc/dma: remove the unused ARCH_HAS_DMA_MMAP_COHERENT define

Signed-off-by: Christoph Hellwig Acked-by: Benjamin Herrenschmidt --- arch/powerpc/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h index 8fa394520af6..f2a4a7142b1e 100644 ---

[PATCH 02/33] powerpc/dma: remove the unused ARCH_HAS_DMA_MMAP_COHERENT define

Signed-off-by: Christoph Hellwig Acked-by: Benjamin Herrenschmidt --- arch/powerpc/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h index 8fa394520af6..f2a4a7142b1e 100644 ---

Re: [PATCH v7 3/6] seccomp: add a way to get a listener fd from ptrace

On Tue, Oct 09, 2018 at 02:39:53PM +0200, Jann Horn wrote: > On Mon, Oct 8, 2018 at 8:18 PM Christian Brauner wrote: > > On Mon, Oct 08, 2018 at 06:42:00PM +0200, Jann Horn wrote: > > > On Mon, Oct 8, 2018 at 6:21 PM Christian Brauner > > > wrote: > > > > On Mon, Oct 08, 2018 at 05:33:22PM

use generic DMA mapping code in powerpc V3

Hi all, this series switches the powerpc port to use the generic swiotlb and noncoherent dma ops, and to use more generic code for the coherent direct mapping, as well as removing a lot of dead code. The changes since v1 are to big to list and v2 was not posted in public. As this series is very

Re: [PATCH v7 3/6] seccomp: add a way to get a listener fd from ptrace

On Tue, Oct 09, 2018 at 02:39:53PM +0200, Jann Horn wrote: > On Mon, Oct 8, 2018 at 8:18 PM Christian Brauner wrote: > > On Mon, Oct 08, 2018 at 06:42:00PM +0200, Jann Horn wrote: > > > On Mon, Oct 8, 2018 at 6:21 PM Christian Brauner > > > wrote: > > > > On Mon, Oct 08, 2018 at 05:33:22PM

use generic DMA mapping code in powerpc V3

Hi all, this series switches the powerpc port to use the generic swiotlb and noncoherent dma ops, and to use more generic code for the coherent direct mapping, as well as removing a lot of dead code. The changes since v1 are to big to list and v2 was not posted in public. As this series is very

[PATCH 14/33] powerpc/dart: use the generic iommu bypass code

Use the generic iommu bypass code instead of overriding set_dma_mask. Signed-off-by: Christoph Hellwig --- arch/powerpc/sysdev/dart_iommu.c | 45 +++- 1 file changed, 15 insertions(+), 30 deletions(-) diff --git a/arch/powerpc/sysdev/dart_iommu.c

[PATCH 13/33] powerpc/dart: remove dead cleanup code in iommu_init_early_dart

If dart_init failed we didn't have a chance to setup dma or controller ops yet, so there is no point in resetting them. Signed-off-by: Christoph Hellwig --- arch/powerpc/sysdev/dart_iommu.c | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git

[PATCH 20/33] powerpc/dma: remove the iommu fallback for coherent allocations

All iommu capable platforms now always use the iommu code with the internal bypass, so there is not need for this magic anymore. Signed-off-by: Christoph Hellwig --- arch/powerpc/Kconfig | 4 --- arch/powerpc/kernel/dma.c | 68 ++- 2 files changed, 2

[PATCH 17/33] powerpc/powernv: use the generic iommu bypass code

Use the generic iommu bypass code instead of overriding set_dma_mask. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/powernv/pci-ioda.c | 92 ++- 1 file changed, 25 insertions(+), 67 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c

[PATCH 18/33] powerpc/dma: stop overriding dma_get_required_mask

The ppc_md and pci_controller_ops methods are unused now and can be removed. The dma_nommu implementation is generic to the generic one except for using max_pfn instead of calling into the memblock API, and all other dma_map_ops instances implement a method of their own. Signed-off-by: Christoph

[PATCH 14/33] powerpc/dart: use the generic iommu bypass code

Use the generic iommu bypass code instead of overriding set_dma_mask. Signed-off-by: Christoph Hellwig --- arch/powerpc/sysdev/dart_iommu.c | 45 +++- 1 file changed, 15 insertions(+), 30 deletions(-) diff --git a/arch/powerpc/sysdev/dart_iommu.c

[PATCH 13/33] powerpc/dart: remove dead cleanup code in iommu_init_early_dart

If dart_init failed we didn't have a chance to setup dma or controller ops yet, so there is no point in resetting them. Signed-off-by: Christoph Hellwig --- arch/powerpc/sysdev/dart_iommu.c | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git

[PATCH 20/33] powerpc/dma: remove the iommu fallback for coherent allocations

All iommu capable platforms now always use the iommu code with the internal bypass, so there is not need for this magic anymore. Signed-off-by: Christoph Hellwig --- arch/powerpc/Kconfig | 4 --- arch/powerpc/kernel/dma.c | 68 ++- 2 files changed, 2

[PATCH 17/33] powerpc/powernv: use the generic iommu bypass code

Use the generic iommu bypass code instead of overriding set_dma_mask. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/powernv/pci-ioda.c | 92 ++- 1 file changed, 25 insertions(+), 67 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c

[PATCH 18/33] powerpc/dma: stop overriding dma_get_required_mask

The ppc_md and pci_controller_ops methods are unused now and can be removed. The dma_nommu implementation is generic to the generic one except for using max_pfn instead of calling into the memblock API, and all other dma_map_ops instances implement a method of their own. Signed-off-by: Christoph

[PATCH v3 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge Acked-by: Leon Romanovsky --- v1 -> v2: * Fixed incorrect format for printing the TID v2 -> v3: * Added Leon's a-b --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file changed,

[PATCH v3 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge Acked-by: Leon Romanovsky --- v1 -> v2: * Fixed incorrect format for printing the TID v2 -> v3: * Added Leon's a-b --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file changed,

[PATCH v3 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- v1 -> v3: * No changes --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 19/33] powerpc/pci: remove the dma_set_mask pci_controller ops methods

Unused now. Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/pci-bridge.h | 2 -- arch/powerpc/kernel/dma.c | 7 --- 2 files changed, 9 deletions(-) diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h index

[PATCH v3 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- v1 -> v3: * No changes --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 19/33] powerpc/pci: remove the dma_set_mask pci_controller ops methods

Unused now. Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/pci-bridge.h | 2 -- arch/powerpc/kernel/dma.c | 7 --- 2 files changed, 9 deletions(-) diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h index

[PATCH 22/33] powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c

pci_dma_dev_setup_swiotlb is only used by the fsl_pci code, and closely related to it, so fsl_pci.c seems like a better place for it. Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/swiotlb.h | 2 -- arch/powerpc/kernel/dma-swiotlb.c | 11 ---

[PATCH v3 0/2] IB/mlx4: Enable debug print of SMPs and enhance output for MADs

SMPs were not printed at all. Added printing of port number and TID to all MADs Håkon Bugge (2): IB/mlx4: Enable debug print of SMPs IB/mlx4: Add port and TID to MAD debug print drivers/infiniband/hw/mlx4/mad.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) --

<    4   5   6   7   8   9   10   11   12   13   >