[PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

Having skl_wm_level contain all of the watermarks for each plane is annoying since it prevents us from having any sort of object to represent a single watermark level, something we take advantage of in the next commit to cut down on all of the copy paste code in here. Signed-off-by: Lyude

[PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

Having skl_wm_level contain all of the watermarks for each plane is annoying since it prevents us from having any sort of object to represent a single watermark level, something we take advantage of in the next commit to cut down on all of the copy paste code in here. Signed-off-by: Lyude Cc:

[PATCH 2/6] drm/i915/skl: Remove linetime from skl_wm_values

Next part of cleaning up the watermark code for skl. This is easy, since it seems that we never actually needed to keep track of the linetime in the skl_wm_values struct anyway. Signed-off-by: Lyude Cc: Maarten Lankhorst Cc: Ville Syrjälä

[PATCH 2/6] drm/i915/skl: Remove linetime from skl_wm_values

Next part of cleaning up the watermark code for skl. This is easy, since it seems that we never actually needed to keep track of the linetime in the skl_wm_values struct anyway. Signed-off-by: Lyude Cc: Maarten Lankhorst Cc: Ville Syrjälä Cc: Matt Roper --- drivers/gpu/drm/i915/i915_drv.h

Re: [RFC] arm64: Enforce observed order for spinlock and data

On 2016-10-05 11:10, Peter Zijlstra wrote: On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org wrote: On 2016-10-04 15:12, Mark Rutland wrote: >Hi Brent, > >Could you *please* clarify if you are trying to solve: > >(a) a correctness issue (e.g. data corruption) seen in practice.

Re: [RFC] arm64: Enforce observed order for spinlock and data

On 2016-10-05 11:10, Peter Zijlstra wrote: On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org wrote: On 2016-10-04 15:12, Mark Rutland wrote: >Hi Brent, > >Could you *please* clarify if you are trying to solve: > >(a) a correctness issue (e.g. data corruption) seen in practice.

Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

Hello, On Tue, Oct 04, 2016 at 11:25:29PM -0500, Serge E. Hallyn wrote: > > > If anything I'd say the GLOBAL_ROOT_UID check could be taken out since > > > otherwise a host-root task effectively cannot drop this capability. > > > > Is this ok to leave for a separate patch? > > Yeah. And I'm not

[RESEND PATCH v2 2/3] dt-bindings: reset: oxnas: Add include file with reset indexes

Add DT include file for Oxford Semiconductor OX810SE and OX820 reset controller support. Signed-off-by: Neil Armstrong --- include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++ include/dt-bindings/reset/oxsemi,ox820.h | 53

[RESEND PATCH v2 1/3] reset: oxnas: Add OX820 support

In order to support the Oxford Semiconductor OX820 SoC, add a new compatible string. Signed-off-by: Neil Armstrong --- drivers/reset/reset-oxnas.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c index

[RESEND PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820

Add new compatible string for reset and sys-ctrl for the Oxford Semiconductor OX820 Support. Drop the OX810SE indices since they moved in a dedicated include file. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/reset/oxnas,reset.txt | 44

[RESEND PATCH v2 0/3]

This is a resend of v2 with the actual changes on patch number 3. This patchset adds support for the reset controller in the Oxford Semiconductor OX820 SoC, big brother of the OX810SE. Since this driver uses a regmap access, it's important to tag each compatible SoC since the regmap offset could

Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

Hello, On Tue, Oct 04, 2016 at 11:25:29PM -0500, Serge E. Hallyn wrote: > > > If anything I'd say the GLOBAL_ROOT_UID check could be taken out since > > > otherwise a host-root task effectively cannot drop this capability. > > > > Is this ok to leave for a separate patch? > > Yeah. And I'm not

[RESEND PATCH v2 2/3] dt-bindings: reset: oxnas: Add include file with reset indexes

Add DT include file for Oxford Semiconductor OX810SE and OX820 reset controller support. Signed-off-by: Neil Armstrong --- include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++ include/dt-bindings/reset/oxsemi,ox820.h | 53 ++ 2 files

[RESEND PATCH v2 1/3] reset: oxnas: Add OX820 support

In order to support the Oxford Semiconductor OX820 SoC, add a new compatible string. Signed-off-by: Neil Armstrong --- drivers/reset/reset-oxnas.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c index 9449805..0d9036d 100644 ---

[RESEND PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820

Add new compatible string for reset and sys-ctrl for the Oxford Semiconductor OX820 Support. Drop the OX810SE indices since they moved in a dedicated include file. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/reset/oxnas,reset.txt | 44 +- 1 file changed, 9

[RESEND PATCH v2 0/3]

This is a resend of v2 with the actual changes on patch number 3. This patchset adds support for the reset controller in the Oxford Semiconductor OX820 SoC, big brother of the OX810SE. Since this driver uses a regmap access, it's important to tag each compatible SoC since the regmap offset could

[PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820

Add new compatible string for reset and sys-ctrl for the Oxford Semiconductor OX820 Support. Drop the OX810SE indices since they moved in a dedicated include file. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/reset/oxnas,reset.txt | 39

[PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820

Add new compatible string for reset and sys-ctrl for the Oxford Semiconductor OX820 Support. Drop the OX810SE indices since they moved in a dedicated include file. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/reset/oxnas,reset.txt | 39 ++ 1 file changed, 3

[PATCH v2 2/3] dt-bindings: reset: oxnas: Add include file with reset indexes

Add DT include file for Oxford Semiconductor OX810SE and OX820 reset controller support. Signed-off-by: Neil Armstrong --- include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++ include/dt-bindings/reset/oxsemi,ox820.h | 53

[PATCH v2 1/3] reset: oxnas: Add OX820 support

In order to support the Oxford Semiconductor OX820 SoC, add a new compatible string. Signed-off-by: Neil Armstrong --- drivers/reset/reset-oxnas.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c index

[PATCH v2 2/3] dt-bindings: reset: oxnas: Add include file with reset indexes

Add DT include file for Oxford Semiconductor OX810SE and OX820 reset controller support. Signed-off-by: Neil Armstrong --- include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++ include/dt-bindings/reset/oxsemi,ox820.h | 53 ++ 2 files

[PATCH v2 1/3] reset: oxnas: Add OX820 support

In order to support the Oxford Semiconductor OX820 SoC, add a new compatible string. Signed-off-by: Neil Armstrong --- drivers/reset/reset-oxnas.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c index 9449805..0d9036d 100644 ---

[PATCH v2 0/3] reset: Add support for OX820 SoC

This patchset adds support for the reset controller in the Oxford Semiconductor OX820 SoC, big brother of the OX810SE. Since this driver uses a regmap access, it's important to tag each compatible SoC since the regmap offset could differ in later SoCs. This patchet also moves the reset indices

[PATCH v2 0/3] reset: Add support for OX820 SoC

This patchset adds support for the reset controller in the Oxford Semiconductor OX820 SoC, big brother of the OX810SE. Since this driver uses a regmap access, it's important to tag each compatible SoC since the regmap offset could differ in later SoCs. This patchet also moves the reset indices

Re: Problem with VMAP_STACK=y

2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab : > Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST) > Jiri Kosina escreveu: > >> On Wed, 5 Oct 2016, Patrick Boettcher wrote: >> >> > > > Thanks for the quick response. >> > > > Drivers are: >> > > > dvb_core,

Re: Problem with VMAP_STACK=y

2016-10-05 11:04 GMT+02:00 Mauro Carvalho Chehab : > Em Wed, 5 Oct 2016 09:50:42 +0200 (CEST) > Jiri Kosina escreveu: > >> On Wed, 5 Oct 2016, Patrick Boettcher wrote: >> >> > > > Thanks for the quick response. >> > > > Drivers are: >> > > > dvb_core, dvb_usb, dbv_usb_cynergyT2 >> > > >> > > This

Re: [PATCH] tpm/tpm_crb: revamp starting method setting.

On Wed, Oct 05, 2016 at 04:12:08PM +0300, Tomas Winkler wrote: > Encapsulate the start method parsing in a single function > and add needed debug printouts. > It eliminates small issue with useless double checking for > ACPI_TPM2_MEMORY_MAPPED. Start method is trival to check from TPM2 dump. I'm

Re: [PATCH] tpm/tpm_crb: revamp starting method setting.

On Wed, Oct 05, 2016 at 04:12:08PM +0300, Tomas Winkler wrote: > Encapsulate the start method parsing in a single function > and add needed debug printouts. > It eliminates small issue with useless double checking for > ACPI_TPM2_MEMORY_MAPPED. Start method is trival to check from TPM2 dump. I'm

Re: [PATCH] tpm: don't destroy chip device prematurely

On Wed, Oct 05, 2016 at 07:48:59AM +, Winkler, Tomas wrote: > > > > > > > On Tue, Oct 04, 2016 at 08:19:46AM +0300, Jarkko Sakkinen wrote: > > > > > > > > > > Make the driver uncallable first. The worst race that can happen > > > > > > is that open("/dev/tpm0", ...) returns -EPIPE. I do not

Re: [PATCH 0/2] ARM: davinci: initial infrastructure for LCDC

On Wed, Oct 05, 2016 at 03:05:30PM +0200, Bartosz Golaszewski wrote: > After discussing the matter with Laurent Pinchart it turned out that > using ti,tilcdc,panel was wrong and we should go with the new > simple-vga-dac driver proposed by Maxime Ripard and currently being > reviewed. > > The

Re: [PATCH] tpm: don't destroy chip device prematurely

On Wed, Oct 05, 2016 at 07:48:59AM +, Winkler, Tomas wrote: > > > > > > > On Tue, Oct 04, 2016 at 08:19:46AM +0300, Jarkko Sakkinen wrote: > > > > > > > > > > Make the driver uncallable first. The worst race that can happen > > > > > > is that open("/dev/tpm0", ...) returns -EPIPE. I do not

Re: [PATCH 0/2] ARM: davinci: initial infrastructure for LCDC

On Wed, Oct 05, 2016 at 03:05:30PM +0200, Bartosz Golaszewski wrote: > After discussing the matter with Laurent Pinchart it turned out that > using ti,tilcdc,panel was wrong and we should go with the new > simple-vga-dac driver proposed by Maxime Ripard and currently being > reviewed. > > The

Re: [PATCH] dmaengine: DW DMAC: split pdata to hardware properties and platform quirks

Hi Andy, what do you think about these changes? On Thu, 2016-09-15 at 16:14 +0300, Eugeniy Paltsev wrote: > This patch is to address a proposal by Andy in this thread: > http://www.spinics.net/lists/dmaengine/msg10754.html > Split platform data to actual hardware properties, and platform >

Re: [PATCH] dmaengine: DW DMAC: split pdata to hardware properties and platform quirks

Hi Andy, what do you think about these changes? On Thu, 2016-09-15 at 16:14 +0300, Eugeniy Paltsev wrote: > This patch is to address a proposal by Andy in this thread: > http://www.spinics.net/lists/dmaengine/msg10754.html > Split platform data to actual hardware properties, and platform >

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 5 October 2016 at 16:04, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: >> On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >>> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >>>

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 5 October 2016 at 16:04, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: >> On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >>> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >>> an md RAID1 device composed of two SATA SSDs passed up as

Re: [RFC] arm64: Enforce observed order for spinlock and data

On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org wrote: > On 2016-10-04 15:12, Mark Rutland wrote: > >Hi Brent, > > > >Could you *please* clarify if you are trying to solve: > > > >(a) a correctness issue (e.g. data corruption) seen in practice. > >(b) a correctness issue (e.g.

Re: [RFC] arm64: Enforce observed order for spinlock and data

On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org wrote: > On 2016-10-04 15:12, Mark Rutland wrote: > >Hi Brent, > > > >Could you *please* clarify if you are trying to solve: > > > >(a) a correctness issue (e.g. data corruption) seen in practice. > >(b) a correctness issue (e.g.

Re: [RFC] arm64: Enforce observed order for spinlock and data

On 2016-10-05 10:55, bdegr...@codeaurora.org wrote: On 2016-10-04 15:12, Mark Rutland wrote: Hi Brent, Could you *please* clarify if you are trying to solve: (a) a correctness issue (e.g. data corruption) seen in practice. (b) a correctness issue (e.g. data corruption) found by inspection.

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

On 10/05/2016 08:19 AM, Waiman Long wrote: On 10/04/2016 03:06 PM, Davidlohr Bueso wrote: On Thu, 18 Aug 2016, Waiman Long wrote: The osq_lock() and osq_unlock() function may not provide the necessary acquire and release barrier in some cases. This patch makes sure that the proper barriers

Re: [RFC] arm64: Enforce observed order for spinlock and data

On 2016-10-05 10:55, bdegr...@codeaurora.org wrote: On 2016-10-04 15:12, Mark Rutland wrote: Hi Brent, Could you *please* clarify if you are trying to solve: (a) a correctness issue (e.g. data corruption) seen in practice. (b) a correctness issue (e.g. data corruption) found by inspection.

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

On 10/05/2016 08:19 AM, Waiman Long wrote: On 10/04/2016 03:06 PM, Davidlohr Bueso wrote: On Thu, 18 Aug 2016, Waiman Long wrote: The osq_lock() and osq_unlock() function may not provide the necessary acquire and release barrier in some cases. This patch makes sure that the proper barriers

[PATCH 4/6] clk: oxnas: Refactor to make use of devm_clk_hw_register()

Make usage of static tables identified by the OF match table to feed devm_clk_hw_register() and use of_clk_add_hw_provider(). This structure is cleaner and simplifies adding new SoC support while having common probe and gate ops code. Signed-off-by: Neil Armstrong ---

[PATCH 3/6] clk: oxnas: Rename to clk_oxnas_gate

Rename clock ops to clk_oxnas_gate in ops and structures. Signed-off-by: Neil Armstrong --- drivers/clk/clk-oxnas.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/clk/clk-oxnas.c b/drivers/clk/clk-oxnas.c

[PATCH 4/6] clk: oxnas: Refactor to make use of devm_clk_hw_register()

Make usage of static tables identified by the OF match table to feed devm_clk_hw_register() and use of_clk_add_hw_provider(). This structure is cleaner and simplifies adding new SoC support while having common probe and gate ops code. Signed-off-by: Neil Armstrong --- drivers/clk/clk-oxnas.c |

[PATCH 3/6] clk: oxnas: Rename to clk_oxnas_gate

Rename clock ops to clk_oxnas_gate in ops and structures. Signed-off-by: Neil Armstrong --- drivers/clk/clk-oxnas.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/clk/clk-oxnas.c b/drivers/clk/clk-oxnas.c index 47649ac..a76c7fb

[PATCH 1/6] clk: oxnas: Add dt-bindings include file for OX810SE

In order to prepare support for the Oxford Semiconductor OX820, add a dt-bindings include file used by the ox810se dtsi. Signed-off-by: Neil Armstrong --- include/dt-bindings/clock/oxsemi,ox810se.h | 30 ++ 1 file changed, 30 insertions(+)

[PATCH 1/6] clk: oxnas: Add dt-bindings include file for OX810SE

In order to prepare support for the Oxford Semiconductor OX820, add a dt-bindings include file used by the ox810se dtsi. Signed-off-by: Neil Armstrong --- include/dt-bindings/clock/oxsemi,ox810se.h | 30 ++ 1 file changed, 30 insertions(+) create mode 100644

[PATCH resend] vfs: allow FILE_EXTENT_SAME (dedupe_file_range) on a file opened ro

Instead of checking the mode of the file descriptor, let's check whether it could have been opened rw. This allows fixing intermittent exec failures when deduping a live system: anyone trying to exec a file currently being deduped gets ETXTBSY. Issuing this ioctl on a ro file was already allowed

[PATCH resend] vfs: allow FILE_EXTENT_SAME (dedupe_file_range) on a file opened ro

Instead of checking the mode of the file descriptor, let's check whether it could have been opened rw. This allows fixing intermittent exec failures when deduping a live system: anyone trying to exec a file currently being deduped gets ETXTBSY. Issuing this ioctl on a ro file was already allowed

[PATCH 6/6] dt-bindings: clk: oxnas,stdclk: Add OX820 bindings

Add OX820 bindings and remove clock indices from bindings since they are present in the dt-bindings headers files. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/clock/oxnas,stdclk.txt| 19 ++- 1 file changed, 6 insertions(+), 13

[PATCH 5/6] clk: oxnas: Add OX820 Gate clocks

Add support for the Oxford Semiconductor OX820 SoC gate clocks along the OX810SE SoC support. This rework on concerns the gate clocks since they are different. Future PLL handling code will be added for OX820. Signed-off-by: Neil Armstrong --- drivers/clk/clk-oxnas.c |

[PATCH 6/6] dt-bindings: clk: oxnas,stdclk: Add OX820 bindings

Add OX820 bindings and remove clock indices from bindings since they are present in the dt-bindings headers files. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/clock/oxnas,stdclk.txt| 19 ++- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git

[PATCH 5/6] clk: oxnas: Add OX820 Gate clocks

Add support for the Oxford Semiconductor OX820 SoC gate clocks along the OX810SE SoC support. This rework on concerns the gate clocks since they are different. Future PLL handling code will be added for OX820. Signed-off-by: Neil Armstrong --- drivers/clk/clk-oxnas.c | 58

[PATCH 0/6] clk: oxnas: Rework driver to add support for OX820

In order to to support the Oxford Semiconductor OX820 Soc clock gates, rework the original driver with a structure inspired from the Qcom or Meson drivers and using the new devm_clk_hw_register() call. The first patches add dt-bindings include file to clarify the clock indices. In future work,

[PATCH 0/6] clk: oxnas: Rework driver to add support for OX820

In order to to support the Oxford Semiconductor OX820 Soc clock gates, rework the original driver with a structure inspired from the Qcom or Meson drivers and using the new devm_clk_hw_register() call. The first patches add dt-bindings include file to clarify the clock indices. In future work,

[PATCH 2/6] clk: oxnas: Add dt-bindings include file for OX820

In order to support the Oxford Semiconductor Gate clocks, add a dedicated dt-binding include file for gate indexes. Signed-off-by: Neil Armstrong --- include/dt-bindings/clock/oxsemi,ox820.h | 40 1 file changed, 40 insertions(+) create

[PATCH 2/6] clk: oxnas: Add dt-bindings include file for OX820

In order to support the Oxford Semiconductor Gate clocks, add a dedicated dt-binding include file for gate indexes. Signed-off-by: Neil Armstrong --- include/dt-bindings/clock/oxsemi,ox820.h | 40 1 file changed, 40 insertions(+) create mode 100644

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >> an md RAID1 device composed of two SATA SSDs passed up as a raw disk >>

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >> an md RAID1 device composed of two SATA SSDs passed up as a raw disk >> mappings through a PVSCSI controller, this

Re: [PATCH V3 00/11] block-throttle: add .high limit

Hello, Paolo. On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > In this respect, for your generic, unpredictable scenario to make > sense, there must exist at least one real system that meets the > requirements of such a scenario. Or, if such a real system does not > yet exist, it

Re: [PATCH V3 00/11] block-throttle: add .high limit

Hello, Paolo. On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > In this respect, for your generic, unpredictable scenario to make > sense, there must exist at least one real system that meets the > requirements of such a scenario. Or, if such a real system does not > yet exist, it

Re: [RFC] arm64: Enforce observed order for spinlock and data

On 2016-10-04 15:12, Mark Rutland wrote: Hi Brent, Could you *please* clarify if you are trying to solve: (a) a correctness issue (e.g. data corruption) seen in practice. (b) a correctness issue (e.g. data corruption) found by inspection. (c) A performance issue, seen in practice. (d) A

Re: [RFC] arm64: Enforce observed order for spinlock and data

On 2016-10-04 15:12, Mark Rutland wrote: Hi Brent, Could you *please* clarify if you are trying to solve: (a) a correctness issue (e.g. data corruption) seen in practice. (b) a correctness issue (e.g. data corruption) found by inspection. (c) A performance issue, seen in practice. (d) A

[PATCH] DMA: nbpfaxi: check for errors from dma_map_single

Check for error return from dma_map_single. Move the addition of the node to the list to after we check for error, so we can reuse the list in unmapping. Found by enabling CONFIG_DMA_API_DEBUG. Signed-off-by: Jesper Nilsson --- drivers/dma/nbpfaxi.c | 15

[PATCH] DMA: nbpfaxi: check for errors from dma_map_single

Check for error return from dma_map_single. Move the addition of the node to the list to after we check for error, so we can reuse the list in unmapping. Found by enabling CONFIG_DMA_API_DEBUG. Signed-off-by: Jesper Nilsson --- drivers/dma/nbpfaxi.c | 15 ++- 1 file changed, 14

Re: [PATCH 00/15] improve function-level documentation

On Wed, 5 Oct 2016, Daniel Vetter wrote: > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > into a lint/checker pass over the entire kernel. I think that'd would > be more robust instead of trying to approximate the real kerneldoc > parser. Otoh that parser is a horror

Re: [PATCH 00/15] improve function-level documentation

On Wed, 5 Oct 2016, Daniel Vetter wrote: > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > into a lint/checker pass over the entire kernel. I think that'd would > be more robust instead of trying to approximate the real kerneldoc > parser. Otoh that parser is a horror

[PATCH] ARM64: dts: meson-gxbb: Add rmii pinctrl node and rename rgmii node

For boards only supporting 10/100 ethernet over a RMII PHY link, add a separate pinctrl node. By the way, rename the existing node to rgmii specific naming in all boards dts. Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-

[PATCH] ARM64: dts: meson-gxbb: Add rmii pinctrl node and rename rgmii node

For boards only supporting 10/100 ethernet over a RMII PHY link, add a separate pinctrl node. By the way, rename the existing node to rgmii specific naming in all boards dts. Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-

Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver

On 5 October 2016 at 18:01, Horng-Shyang Liao wrote: > On Wed, 2016-10-05 at 09:07 +0530, Jassi Brar wrote: >> On 5 October 2016 at 08:24, Horng-Shyang Liao wrote: >> > On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote: >> >> On Fri,

Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver

On 5 October 2016 at 18:01, Horng-Shyang Liao wrote: > On Wed, 2016-10-05 at 09:07 +0530, Jassi Brar wrote: >> On 5 October 2016 at 08:24, Horng-Shyang Liao wrote: >> > On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote: >> >> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote: >> >> > >> >

Re: [PATCH v5 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature

On Sat, 1 Oct 2016, Srinivas Pandruvada wrote: > +static int sched_itmt_update_handler(struct ctl_table *table, int write, > + void __user *buffer, size_t *lenp, loff_t *ppos) > +{ > + int ret; > + unsigned int old_sysctl; > + > + mutex_lock(_update_mutex); >

Re: [PATCH v5 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature

On Sat, 1 Oct 2016, Srinivas Pandruvada wrote: > +static int sched_itmt_update_handler(struct ctl_table *table, int write, > + void __user *buffer, size_t *lenp, loff_t *ppos) > +{ > + int ret; > + unsigned int old_sysctl; > + > + mutex_lock(_update_mutex); >

[PATCH 2/2] ARM: multi_v7_defconfig: Enable exynos-gsc driver as module

Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used to do video streams scaling and color space conversions by hardware. Enable support for its driver as a module so the GSCALER can be tested. Signed-off-by: Javier Martinez Canillas ---

Re: [PATCH v5 4/9] x86: Enable Intel Turbo Boost Max Technology 3.0

On Sat, 1 Oct 2016, Srinivas Pandruvada wrote: > +void sched_set_itmt_support(bool itmt_supported) > +{ > + mutex_lock(_update_mutex); > + > + if (itmt_supported != sched_itmt_capable) > + sched_itmt_capable = itmt_supported; Yikes. What is this conditional for? The only value

[PATCH 2/2] ARM: multi_v7_defconfig: Enable exynos-gsc driver as module

Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used to do video streams scaling and color space conversions by hardware. Enable support for its driver as a module so the GSCALER can be tested. Signed-off-by: Javier Martinez Canillas --- arch/arm/configs/multi_v7_defconfig |

Re: [PATCH v5 4/9] x86: Enable Intel Turbo Boost Max Technology 3.0

On Sat, 1 Oct 2016, Srinivas Pandruvada wrote: > +void sched_set_itmt_support(bool itmt_supported) > +{ > + mutex_lock(_update_mutex); > + > + if (itmt_supported != sched_itmt_capable) > + sched_itmt_capable = itmt_supported; Yikes. What is this conditional for? The only value

[PATCH 1/2] ARM: exynos_defconfig: Enable exynos-gsc driver as module

Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used to do video streams scaling and color space conversions by hardware. Enable support for its driver as a module so the GSCALER can be tested. Signed-off-by: Javier Martinez Canillas ---

[PATCH 1/2] ARM: exynos_defconfig: Enable exynos-gsc driver as module

Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used to do video streams scaling and color space conversions by hardware. Enable support for its driver as a module so the GSCALER can be tested. Signed-off-by: Javier Martinez Canillas --- arch/arm/configs/exynos_defconfig | 1

ERROR: ftrace_graph_ret_addr" [arch/x86/oprofile/oprofile.ko] undefined!

Hi, This has already been reported by Fengguang Wu's kbuild test robot: https://lists.01.org/pipermail/kbuild-all/2016-July/022203.html but it seems to have slipped through. Karl

ERROR: ftrace_graph_ret_addr" [arch/x86/oprofile/oprofile.ko] undefined!

Hi, This has already been reported by Fengguang Wu's kbuild test robot: https://lists.01.org/pipermail/kbuild-all/2016-July/022203.html but it seems to have slipped through. Karl

Re: [PATCH] rcu: Reword help of RCU_TRACE option

On 10/05/2016 05:03 PM, Paul E. McKenney wrote: > On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: >> Explicitly state that enabling RCU_TRACE enables more >> tracepoints and not just "additional tracing". >> >> Signed-off-by: Nikolay Borisov >> --- >> >> Hello

Re: [PATCH] rcu: Reword help of RCU_TRACE option

On 10/05/2016 05:03 PM, Paul E. McKenney wrote: > On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: >> Explicitly state that enabling RCU_TRACE enables more >> tracepoints and not just "additional tracing". >> >> Signed-off-by: Nikolay Borisov >> --- >> >> Hello Paul, >> >>

Re: [PATCH V3 00/11] block-throttle: add .high limit

> Il giorno 05 ott 2016, alle ore 15:12, Vivek Goyal ha > scritto: > > On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > > [..] >> Anyway, to avoid going on with trying speculations and arguments, let >> me retry with a practical proposal. BFQ is out there,

kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

On Wed, 05 Oct 2016, Daniel Vetter wrote: > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > into a lint/checker pass over the entire kernel. I think that'd would > be more robust instead of trying to approximate the real kerneldoc > parser. Otoh that

Re: [PATCH V3 00/11] block-throttle: add .high limit

> Il giorno 05 ott 2016, alle ore 15:12, Vivek Goyal ha > scritto: > > On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > > [..] >> Anyway, to avoid going on with trying speculations and arguments, let >> me retry with a practical proposal. BFQ is out there, free. Let's >>

kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

On Wed, 05 Oct 2016, Daniel Vetter wrote: > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > into a lint/checker pass over the entire kernel. I think that'd would > be more robust instead of trying to approximate the real kerneldoc > parser. Otoh that parser is a horror

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

On Mon, 3 Oct 2016, Yinghai Lu wrote: > init_cpu_node become: > [ 55.477160] init_cpu_to_node: > [ 55.483280] cpu 0 -> apicid 0x0 -> node 0 > [ 55.491558] cpu 1 -> apicid 0xff -> node 1 > [ 55.500017] cpu 2 -> apicid 0x2 -> node 0 > [ 55.508296] cpu 3 -> apicid 0x4 -> node 0 > [

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

On Mon, 3 Oct 2016, Yinghai Lu wrote: > init_cpu_node become: > [ 55.477160] init_cpu_to_node: > [ 55.483280] cpu 0 -> apicid 0x0 -> node 0 > [ 55.491558] cpu 1 -> apicid 0xff -> node 1 > [ 55.500017] cpu 2 -> apicid 0x2 -> node 0 > [ 55.508296] cpu 3 -> apicid 0x4 -> node 0 > [

[PATCH] devicetree: net: micrel-ksz90x1.txt: Properly explain skew settings

The KSZ9031 skew registers contain an offset, the chip's default value is "neutral" which does not add any skew. Programming a 0 into a skew property will actually set it the maximal negative adjustment and not to a neutral position as one would expect. Explain this situation in the devicetree

Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode

On 05/10/2016 15:57, Rik van Riel wrote: > On Wed, 2016-10-05 at 09:14 +0200, Paolo Bonzini wrote: >> >> On 05/10/2016 02:34, r...@redhat.com wrote: >>> >>> From: Andy Lutomirski >>> >>> Since commit 58122bf1d856 ("x86/fpu: Default eagerfpu=on on all >>> CPUs") in Linux 4.6,

Re: [PATCH 20/57] perf c2c report: Add dcacheline dimension key

On Wed, Oct 05, 2016 at 10:26:58AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 05, 2016 at 03:09:29PM +0200, Jiri Olsa escreveu: > > On Wed, Oct 05, 2016 at 02:45:37PM +0200, Jiri Olsa wrote: > > > > SNIP > > > > > > > + > > > > > + if (he->mem_info) > > > > > + addr =

Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode

On 05/10/2016 15:57, Rik van Riel wrote: > On Wed, 2016-10-05 at 09:14 +0200, Paolo Bonzini wrote: >> >> On 05/10/2016 02:34, r...@redhat.com wrote: >>> >>> From: Andy Lutomirski >>> >>> Since commit 58122bf1d856 ("x86/fpu: Default eagerfpu=on on all >>> CPUs") in Linux 4.6, eager FPU mode has

Re: [PATCH 20/57] perf c2c report: Add dcacheline dimension key

On Wed, Oct 05, 2016 at 10:26:58AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 05, 2016 at 03:09:29PM +0200, Jiri Olsa escreveu: > > On Wed, Oct 05, 2016 at 02:45:37PM +0200, Jiri Olsa wrote: > > > > SNIP > > > > > > > + > > > > > + if (he->mem_info) > > > > > + addr =

[PATCH] devicetree: net: micrel-ksz90x1.txt: Properly explain skew settings

The KSZ9031 skew registers contain an offset, the chip's default value is "neutral" which does not add any skew. Programming a 0 into a skew property will actually set it the maximal negative adjustment and not to a neutral position as one would expect. Explain this situation in the devicetree

Re: [PATCH] rcu: Reword help of RCU_TRACE option

On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: > Explicitly state that enabling RCU_TRACE enables more > tracepoints and not just "additional tracing". > > Signed-off-by: Nikolay Borisov > --- > > Hello Paul, > > Following our latest conversation re.

Re: [PATCH] rcu: Reword help of RCU_TRACE option

On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: > Explicitly state that enabling RCU_TRACE enables more > tracepoints and not just "additional tracing". > > Signed-off-by: Nikolay Borisov > --- > > Hello Paul, > > Following our latest conversation re. enabling RCU tracing > I

[PATCH] ARM64: dts: meson-gx: Add missing L2 cache node

In order to remove the boot warning : [2.290933] Unable to detect cache hierarchy from DT for CPU 0 And add missing L2 cache hierarchy information, add a simple l2 cache node and reference it from the A53 cpu nodes. Signed-off-by: Neil Armstrong ---

[PATCH] ARM64: dts: meson-gx: Add missing L2 cache node

In order to remove the boot warning : [2.290933] Unable to detect cache hierarchy from DT for CPU 0 And add missing L2 cache hierarchy information, add a simple l2 cache node and reference it from the A53 cpu nodes. Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gx.dtsi

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