[PATCH 1/1] powerpc/embedded6xx: Make reboot works on MVME5100

The mtmsr() function hangs during restart. Make reboot works on MVME5100 removing that function call. --- arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/mvme5100.c

[PATCH 1/1] powerpc/embedded6xx: Make reboot works on MVME5100

The mtmsr() function hangs during restart. Make reboot works on MVME5100 removing that function call. --- arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/mvme5100.c

RE: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings

> <wenyou.y...@atmel.com> > Subject: Re: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings > > Hi Wenyou, > > [auto build test ERROR on v4.4-rc8] > [cannot apply to next-20160307] > [if your patch is applied to the wrong git tree, please drop us a note to help &

RE: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings

el@vger.kernel.org; devicet...@vger.kernel.org; Yang, Wenyou > > Subject: Re: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings > > Hi Wenyou, > > [auto build test ERROR on v4.4-rc8] > [cannot apply to next-20160307] > [if your patch is applied to the wrong

[PATCH v3 5/7] usb: mux: add driver for Intel drcfg controlled port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. The mux is handled through the Dual Role Configuration Register. Signed-off-by: Heikki Krogerus Signed-off-by: Lu Baolu

[PATCH v3 2/7] extcon: usb-gpio: add support for ACPI gpio interface

GPIO resource could be retrieved through APCI as well. Signed-off-by: Lu Baolu Reviewed-by: Felipe Balbi Acked-by: Chanwoo Choi --- drivers/extcon/extcon-usb-gpio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH v3 1/7] extcon: usb-gpio: add device binding for platform device

This is needed to handle the GPIO connected USB ID pin found on Intel Baytrail devices. Signed-off-by: Lu Baolu Reviewed-by: Felipe Balbi Acked-by: Chanwoo Choi --- drivers/extcon/extcon-usb-gpio.c | 7 +++ 1 file changed,

[PATCH v3 5/7] usb: mux: add driver for Intel drcfg controlled port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. The mux is handled through the Dual Role Configuration Register. Signed-off-by: Heikki Krogerus Signed-off-by: Lu Baolu Signed-off-by: Wu Hao Reviewed-by: Felipe

[PATCH v3 2/7] extcon: usb-gpio: add support for ACPI gpio interface

GPIO resource could be retrieved through APCI as well. Signed-off-by: Lu Baolu Reviewed-by: Felipe Balbi Acked-by: Chanwoo Choi --- drivers/extcon/extcon-usb-gpio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-usb-gpio.c

[PATCH v3 1/7] extcon: usb-gpio: add device binding for platform device

This is needed to handle the GPIO connected USB ID pin found on Intel Baytrail devices. Signed-off-by: Lu Baolu Reviewed-by: Felipe Balbi Acked-by: Chanwoo Choi --- drivers/extcon/extcon-usb-gpio.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/extcon/extcon-usb-gpio.c

[PATCH v3 6/7] usb: pci-quirks: add Intel USB drcfg mux device

In some Intel platforms, a single usb port is shared between USB host and device controllers. The shared port is under control of a switch which is defined in the Intel vendor defined extended capability for xHCI. This patch adds the support to detect and create the platform device for the port

Re: [PATCH v1 1/1] mfd: intel-lpss: save register context on suspend

On Tue, 08 Mar 2016, Andy Shevchenko wrote: > On Tue, Mar 8, 2016 at 6:48 AM, Lee Jones wrote: > > On Tue, 26 Jan 2016, Andy Shevchenko wrote: > > > >> From: Heikki Krogerus > >> > >> All configurations are lost and the registers will have

[PATCH v3 6/7] usb: pci-quirks: add Intel USB drcfg mux device

In some Intel platforms, a single usb port is shared between USB host and device controllers. The shared port is under control of a switch which is defined in the Intel vendor defined extended capability for xHCI. This patch adds the support to detect and create the platform device for the port

Re: [PATCH v1 1/1] mfd: intel-lpss: save register context on suspend

On Tue, 08 Mar 2016, Andy Shevchenko wrote: > On Tue, Mar 8, 2016 at 6:48 AM, Lee Jones wrote: > > On Tue, 26 Jan 2016, Andy Shevchenko wrote: > > > >> From: Heikki Krogerus > >> > >> All configurations are lost and the registers will have > >> default values when the hardware is suspended and

Re: [PATCHv3 02/13] scripts/gdb: Provide kernel list item generators

On 08/03/16 10:47, Jeff Mahoney wrote: > On 3/3/16 6:40 AM, Kieran Bingham wrote: >> Facilitate linked-list items by providing a generator to return >> the dereferenced, and type-cast objects from a kernel linked list >> >> CC: Jeff Mahoney >> >> Signed-off-by: Kieran Bingham

[PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. A usb port mux could be abstracted as the following elements: 1) mux state: HOST or PERIPHERAL; 2) an extcon cable which triggers the change of mux state between

[PATCH v3 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

Some Intel platforms have an USB port mux controlled by GPIOs. There's a single ACPI platform device that provides both USB ID extcon device and a USB port mux device. This MFD driver will split the 2 devices for their respective drivers. Signed-off-by: Lu Baolu

[PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. A usb port mux could be abstracted as the following elements: 1) mux state: HOST or PERIPHERAL; 2) an extcon cable which triggers the change of mux state between

[PATCH v3 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

Some Intel platforms have an USB port mux controlled by GPIOs. There's a single ACPI platform device that provides both USB ID extcon device and a USB port mux device. This MFD driver will split the 2 devices for their respective drivers. Signed-off-by: Lu Baolu Suggested-by: David Cohen

Re: [PATCHv3 02/13] scripts/gdb: Provide kernel list item generators

On 08/03/16 10:47, Jeff Mahoney wrote: > On 3/3/16 6:40 AM, Kieran Bingham wrote: >> Facilitate linked-list items by providing a generator to return >> the dereferenced, and type-cast objects from a kernel linked list >> >> CC: Jeff Mahoney >> >> Signed-off-by: Kieran Bingham >> --- >> Changes

[PATCH v3 4/7] usb: mux: add driver for Intel gpio controlled port mux

In some Intel platforms, a single usb port is shared between USB host and device controller. The shared port is under control of GPIO pins. This patch adds the support for USB GPIO controlled port mux. Signed-off-by: David Cohen Signed-off-by: Lu Baolu

[PATCH v3 4/7] usb: mux: add driver for Intel gpio controlled port mux

In some Intel platforms, a single usb port is shared between USB host and device controller. The shared port is under control of GPIO pins. This patch adds the support for USB GPIO controlled port mux. Signed-off-by: David Cohen Signed-off-by: Lu Baolu Reviewed-by: Heikki Krogerus

[PATCH v3 0/7] usb: add support for Intel dual role port mux

Intel SOC chips are featured with USB dual role. The host role is provided by Intel xHCI IP, and the gadget role is provided by IP from designware. Tablet platform designs always share a single port for both host and gadget controllers. There is a mux to switch the port to the right controller

[PATCH v3 0/7] usb: add support for Intel dual role port mux

Intel SOC chips are featured with USB dual role. The host role is provided by Intel xHCI IP, and the gadget role is provided by IP from designware. Tablet platform designs always share a single port for both host and gadget controllers. There is a mux to switch the port to the right controller

Re: [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users

On Tue, Mar 08, 2016 at 08:25:47AM +0530, Vinod Koul wrote: > On Mon, Mar 07, 2016 at 09:30:24PM +0100, Maxime Ripard wrote: > > On Mon, Mar 07, 2016 at 04:08:57PM +0100, Boris Brezillon wrote: > > > Hi Vinod, > > > > > > On Mon, 7 Mar 2016 20:24:29 +0530 > > > Vinod Koul

Re: [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users

On Tue, Mar 08, 2016 at 08:25:47AM +0530, Vinod Koul wrote: > On Mon, Mar 07, 2016 at 09:30:24PM +0100, Maxime Ripard wrote: > > On Mon, Mar 07, 2016 at 04:08:57PM +0100, Boris Brezillon wrote: > > > Hi Vinod, > > > > > > On Mon, 7 Mar 2016 20:24:29 +0530 > > > Vinod Koul wrote: > > > > > > >

Re: [PATCH v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

On 03/08/2016 12:40 PM, Lee Jones wrote: > On Mon, 07 Mar 2016, Lu Baolu wrote: > >> Some Intel platforms have an USB port mux controlled by GPIOs. >> There's a single ACPI platform device that provides both USB ID >> extcon device and a USB port mux device. This MFD driver will >> split the 2

Re: [PATCH v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

On 03/08/2016 12:40 PM, Lee Jones wrote: > On Mon, 07 Mar 2016, Lu Baolu wrote: > >> Some Intel platforms have an USB port mux controlled by GPIOs. >> There's a single ACPI platform device that provides both USB ID >> extcon device and a USB port mux device. This MFD driver will >> split the 2

Re: [PATCH 03/15] perf session: Simplify tool stubs

On 07/03/16 21:44, Arnaldo Carvalho de Melo wrote: > From: Adrian Hunter Very sorry, but I just noticed that this and patch 5 (perf jit: Move clockid validation) have the wrong email address for the "From" and "Signed-off-by". It should be adrian.hun...@intel.com. Please

Re: [PATCH 03/15] perf session: Simplify tool stubs

On 07/03/16 21:44, Arnaldo Carvalho de Melo wrote: > From: Adrian Hunter Very sorry, but I just noticed that this and patch 5 (perf jit: Move clockid validation) have the wrong email address for the "From" and "Signed-off-by". It should be adrian.hun...@intel.com. Please consider changing it

Re: Suspicious error for CMA stress test

On Mon, Mar 07, 2016 at 01:59:12PM +0100, Vlastimil Babka wrote: > On 03/07/2016 05:34 AM, Joonsoo Kim wrote: > >On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote: > >>>Sad to hear that. > >>> > >>>Could you tell me your system's MAX_ORDER and pageblock_order? > >>> > >> > >>MAX_ORDER is

Re: Suspicious error for CMA stress test

On Mon, Mar 07, 2016 at 01:59:12PM +0100, Vlastimil Babka wrote: > On 03/07/2016 05:34 AM, Joonsoo Kim wrote: > >On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote: > >>>Sad to hear that. > >>> > >>>Could you tell me your system's MAX_ORDER and pageblock_order? > >>> > >> > >>MAX_ORDER is

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

Hi, Felipe Ferreri Tonello writes: >>> On March 5, 2016 4:28:45 PM GMT+00:00, Michal Nazarewicz >>> wrote: >> On Wed, Mar 02 2016, Felipe F. Tonello wrote: >>> @@ -16,7 +16,7 @@ >>> * Copyright (C) 2006 Thumtronics Pty Ltd. >>>

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

Hi, Felipe Ferreri Tonello writes: >>> On March 5, 2016 4:28:45 PM GMT+00:00, Michal Nazarewicz >>> wrote: >> On Wed, Mar 02 2016, Felipe F. Tonello wrote: >>> @@ -16,7 +16,7 @@ >>> * Copyright (C) 2006 Thumtronics Pty Ltd. >>> * Ben Williamson >>> * >>> - *

Re: [PATCH] HID: multitouch: force retrieving of Win8 signature blob

On Mar 07 2016 or thereabouts, Jiri Kosina wrote: > On Mon, 7 Mar 2016, Benjamin Tissoires wrote: > > > The Synaptics 0x11e5 over I2C found in the Asus T100-CHI requires to > > fetch the signature blob to actually start sending events. > > > > With this patch, we should be close enough to the

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

Hi, Felipe Ferreri Tonello writes: >>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1; >>> module_param(out_ports, uint, S_IRUGO); >>> MODULE_PARM_DESC(out_ports, "Number of MIDI output ports"); >>> >>> +static unsigned int bmAttributes =

Re: [PATCH] HID: multitouch: force retrieving of Win8 signature blob

On Mar 07 2016 or thereabouts, Jiri Kosina wrote: > On Mon, 7 Mar 2016, Benjamin Tissoires wrote: > > > The Synaptics 0x11e5 over I2C found in the Asus T100-CHI requires to > > fetch the signature blob to actually start sending events. > > > > With this patch, we should be close enough to the

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

Hi, Felipe Ferreri Tonello writes: >>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1; >>> module_param(out_ports, uint, S_IRUGO); >>> MODULE_PARM_DESC(out_ports, "Number of MIDI output ports"); >>> >>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;

Re: [PATCH v1 1/1] mfd: intel-lpss: Pass I2C configuration via properties on BXT

On Tue, Jan 26, 2016 at 02:17:49PM +0200, Andy Shevchenko wrote: > From: Mika Westerberg > > I2C host controller need to be configured properly in order to meet I2C > timings specified in the I2C protocol specification. Some Intel Broxton > based machines do not

Re: [PATCH v1 1/1] mfd: intel-lpss: Pass I2C configuration via properties on BXT

On Tue, Jan 26, 2016 at 02:17:49PM +0200, Andy Shevchenko wrote: > From: Mika Westerberg > > I2C host controller need to be configured properly in order to meet I2C > timings specified in the I2C protocol specification. Some Intel Broxton > based machines do not have this information in the ACPI

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

Please add some documentation on where/how this should be used. It's not a very obvious interface.

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

Please add some documentation on where/how this should be used. It's not a very obvious interface.

Re: [PATCH] scripts/dtc: Update to upstream version 53bf130b1cdd

On Mon, Mar 7, 2016 at 5:10 PM, Olof Johansson wrote: > Hi, > > On Fri, Mar 4, 2016 at 7:13 AM, Rob Herring wrote: >> Sync to upstream dtc commit 53bf130b1cdd ("libfdt: simplify >> fdt_node_check_compatible()"). This adds the following commits from >> upstream:

Re: [PATCH] scripts/dtc: Update to upstream version 53bf130b1cdd

On Mon, Mar 7, 2016 at 5:10 PM, Olof Johansson wrote: > Hi, > > On Fri, Mar 4, 2016 at 7:13 AM, Rob Herring wrote: >> Sync to upstream dtc commit 53bf130b1cdd ("libfdt: simplify >> fdt_node_check_compatible()"). This adds the following commits from >> upstream: >> >> 53bf130 libfdt: simplify

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

Hi, Felipe Ferreri Tonello writes: > Since f_midi_transmit is called by both ALSA and USB frameworks, it can > potentially cause a race condition between both calls. This is bad because the > way f_midi_transmit is implemented can't handle

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

Hi, Felipe Ferreri Tonello writes: > Since f_midi_transmit is called by both ALSA and USB frameworks, it can > potentially cause a race condition between both calls. This is bad because the > way f_midi_transmit is implemented can't handle concurrent calls. This is

[v5][PATCH] livepatch/ppc: Enable livepatching on powerpc

Changelog v5: 1. Removed the mini-stack frame created for klp_return_helper. As a result of the mini-stack frame, function with > 8 arguments could not be patched 2. Removed camel casing in the comments Changelog v4: 1. Renamed klp_matchaddr() to

[v5][PATCH] livepatch/ppc: Enable livepatching on powerpc

Changelog v5: 1. Removed the mini-stack frame created for klp_return_helper. As a result of the mini-stack frame, function with > 8 arguments could not be patched 2. Removed camel casing in the comments Changelog v4: 1. Renamed klp_matchaddr() to

Re: [PATCH 3/3] pci: move pci_dma_* helpers to common code

On Mon, Mar 07, 2016 at 12:28:48PM -0600, Bjorn Helgaas wrote: > I wonder if we can consolidate a little more pci_dma_*-related stuff > in pci-dma-compat.h, e.g., Looks fine to me.

Re: [PATCH 3/3] pci: move pci_dma_* helpers to common code

On Mon, Mar 07, 2016 at 12:28:48PM -0600, Bjorn Helgaas wrote: > I wonder if we can consolidate a little more pci_dma_*-related stuff > in pci-dma-compat.h, e.g., Looks fine to me.

[PATCH] Staging: media: davinci_vpfe: Fix spelling error on a comment

Fix spelling error on a comment, change 'wether' to 'whether' Signed-off-by: Manuel Rodriguez --- drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c

[PATCH] Staging: media: davinci_vpfe: Fix spelling error on a comment

Fix spelling error on a comment, change 'wether' to 'whether' Signed-off-by: Manuel Rodriguez --- drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon wrote: > On 03/07/2016 12:31 PM, Jassi Brar wrote: >> On Fri, Mar 4, 2016 at 8:05 PM, Nishanth Menon wrote: > +static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data) > +{ > + struct device

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon wrote: > On 03/07/2016 12:31 PM, Jassi Brar wrote: >> On Fri, Mar 4, 2016 at 8:05 PM, Nishanth Menon wrote: > +static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data) > +{ > + struct device *dev = chan->mbox->dev;

Re: [PATCH 0/3] net: macb: Fix coding style issues

Hi, On Monday 07 March 2016 08:17:36, Moritz Fischer wrote: > this series deals with most of the checkpatch warnings > generated for macb. There are two BUG_ON()'s that I didn't touch, yet, > that were suggested by checkpatch, that I can address in a follow up > commit if needed. I think

Re: [PATCH 0/3] net: macb: Fix coding style issues

Hi, On Monday 07 March 2016 08:17:36, Moritz Fischer wrote: > this series deals with most of the checkpatch warnings > generated for macb. There are two BUG_ON()'s that I didn't touch, yet, > that were suggested by checkpatch, that I can address in a follow up > commit if needed. I think

Re: [PATCH net-next 2/3] ipv6: per netns fib6 walkers

On Mon, Mar 07, 2016 at 04:28:26PM -0800, Cong Wang wrote: > On Mon, Mar 7, 2016 at 4:26 PM, Cong Wang wrote: > > On Fri, Mar 4, 2016 at 2:59 AM, Michal Kubecek wrote: > >> static void ipv6_route_seq_setup_walk(struct ipv6_route_iter *iter) > >> { >

RE: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding

Hello! >> BTW, you could just combine both patches. I guess you didn't to >> maintain authorship? >OK. Will squash both of these patches, unless Pavel do not any objections. I don't. Kind regards.

RE: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding

Hello! >> BTW, you could just combine both patches. I guess you didn't to >> maintain authorship? >OK. Will squash both of these patches, unless Pavel do not any objections. I don't. Kind regards.

Re: [PATCH net-next 2/3] ipv6: per netns fib6 walkers

On Mon, Mar 07, 2016 at 04:28:26PM -0800, Cong Wang wrote: > On Mon, Mar 7, 2016 at 4:26 PM, Cong Wang wrote: > > On Fri, Mar 4, 2016 at 2:59 AM, Michal Kubecek wrote: > >> static void ipv6_route_seq_setup_walk(struct ipv6_route_iter *iter) > >> { > >> +#ifdef CONFIG_NET_NS > >> + struct

[lkp] [perf] bd2afa49d1: -20.7% will-it-scale.per_thread_ops

5d/0" job_file: "/lkp/scheduled/lkp-sb03/bisect_will-it-scale-lseek1-debian-x86_64-2015-02-07.cgz-x86_64-rhel-bd2afa49d194c6412c333e9fdd48bc5d06bb465d-20160307-105931-ltzmsq-0.yaml" nr_cpu: "$(nproc)" max_uptime: 1500 initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz&qu

[lkp] [perf] bd2afa49d1: -20.7% will-it-scale.per_thread_ops

5d/0" job_file: "/lkp/scheduled/lkp-sb03/bisect_will-it-scale-lseek1-debian-x86_64-2015-02-07.cgz-x86_64-rhel-bd2afa49d194c6412c333e9fdd48bc5d06bb465d-20160307-105931-ltzmsq-0.yaml" nr_cpu: "$(nproc)" max_uptime: 1500 initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz&qu

Re: [PATCH v1 1/1] mfd: intel-lpss: save register context on suspend

On Tue, Mar 8, 2016 at 6:48 AM, Lee Jones wrote: > On Tue, 26 Jan 2016, Andy Shevchenko wrote: > >> From: Heikki Krogerus >> >> All configurations are lost and the registers will have >> default values when the hardware is suspended and

Re: [PATCH v1 1/1] mfd: intel-lpss: save register context on suspend

On Tue, Mar 8, 2016 at 6:48 AM, Lee Jones wrote: > On Tue, 26 Jan 2016, Andy Shevchenko wrote: > >> From: Heikki Krogerus >> >> All configurations are lost and the registers will have >> default values when the hardware is suspended and resumed, >> so saving the private register space context on

Re: [PATCH v5 0/6] ARM: am335x/am437x/dra7: Add PWM support for DRA7

Hi Franklin On Mon, 7 Mar 2016, Franklin S Cooper Jr wrote: > This patch series adds support for PWM for DRA7. The IP is same as that > present in AM33XX and AM437XX. > > However, before doing so remove unnecessary hwmod entries for eCAP, ePWM > and eQEP. > > This series is almost identical to

Re: [PATCH v5 0/6] ARM: am335x/am437x/dra7: Add PWM support for DRA7

Hi Franklin On Mon, 7 Mar 2016, Franklin S Cooper Jr wrote: > This patch series adds support for PWM for DRA7. The IP is same as that > present in AM33XX and AM437XX. > > However, before doing so remove unnecessary hwmod entries for eCAP, ePWM > and eQEP. > > This series is almost identical to

Re: Nokia N900 - audio TPA6130A2 problems

Hi, On 7.03.2016 13:59, Pali Rohár wrote: ... That error occurs randomly, not always. When I see it next time, I will try to comment that function if it happens... IIRC it is easier to cause it by booting to stock kernel first and then rebooting to mainline (without power-down in between)

Re: Nokia N900 - audio TPA6130A2 problems

Hi, On 7.03.2016 13:59, Pali Rohár wrote: ... That error occurs randomly, not always. When I see it next time, I will try to comment that function if it happens... IIRC it is easier to cause it by booting to stock kernel first and then rebooting to mainline (without power-down in between)

Re: [PATCH v5 4/6] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

On Mon, 7 Mar 2016, Franklin S Cooper Jr wrote: > From: Vignesh R > > Add hwmod entries for the PWMSS on DRA7. > > Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock > equal to L4PER2_L3_GICLK/2(l3_iclk_div/2). > > Signed-off-by: Vignesh R

Re: [PATCH v5 4/6] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

On Mon, 7 Mar 2016, Franklin S Cooper Jr wrote: > From: Vignesh R > > Add hwmod entries for the PWMSS on DRA7. > > Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock > equal to L4PER2_L3_GICLK/2(l3_iclk_div/2). > > Signed-off-by: Vignesh R > [fcoo...@ti.com: Do not add

Re: [PATCH v2 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack

On Sat, Mar 05, 2016 at 09:52:23PM -0800, Andy Lutomirski wrote: <--- ? So all patches before are nice and verbose in explaining what they do. Where did the commit message of this one disappear? :-) Or is it that obvious that we should have a stack canary? How about some text *why* we need it?

Re: [PATCH v2 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack

On Sat, Mar 05, 2016 at 09:52:23PM -0800, Andy Lutomirski wrote: <--- ? So all patches before are nice and verbose in explaining what they do. Where did the commit message of this one disappear? :-) Or is it that obvious that we should have a stack canary? How about some text *why* we need it?

Re: [PATCH v2 09/10] ARM: DRA7: hwmod: Add data for McASP1/2/4/5/6/7/8

On Mon, 7 Mar 2016, Peter Ujfalusi wrote: > Add missing data for all McASP ports for the dra7 family > > Signed-off-by: Peter Ujfalusi Thanks, queued for v4.7. - Paul

Re: [PATCH v2 09/10] ARM: DRA7: hwmod: Add data for McASP1/2/4/5/6/7/8

On Mon, 7 Mar 2016, Peter Ujfalusi wrote: > Add missing data for all McASP ports for the dra7 family > > Signed-off-by: Peter Ujfalusi Thanks, queued for v4.7. - Paul

Re: [PATCH v2 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup

On Sat, Mar 05, 2016 at 09:52:22PM -0800, Andy Lutomirski wrote: > Right after SYSENTER, we can get a #DB or NMI. On x86_32, there's no IST, > so the exception handler is invoked on the temporary SYSENTER stack. > > Because the SYSENTER stack is very small, we have a fixup to switch > off the

Re: [PATCH v2 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup

On Sat, Mar 05, 2016 at 09:52:22PM -0800, Andy Lutomirski wrote: > Right after SYSENTER, we can get a #DB or NMI. On x86_32, there's no IST, > so the exception handler is invoked on the temporary SYSENTER stack. > > Because the SYSENTER stack is very small, we have a fixup to switch > off the

[RESEND PATCH V4 4/4] coresight-stm: adding driver for CoreSight STM component

From: Pratik Patel This driver adds support for the STM CoreSight IP block, allowing any system compoment (HW or SW) to log and aggregate messages via a single entity. The CoreSight STM exposes an application defined number of channels called stimulus port.

[RESEND PATCH V4 2/4] Documentations: Add explanations of the case for non-configurable masters

For some STM hardware (e.g. ARM CoreSight STM), the masterID associated to a source is set at the hardware level and not user configurable. Since the masterID information isn't available to SW, introducing a new value of -1 to reflect this reality. Signed-off-by: Chunyan Zhang

[RESEND PATCH V4 1/4] stm class: provision for statically assigned masterIDs

From: Mathieu Poirier Some architecture like ARM assign masterIDs at the HW design phase. Those are therefore unreachable to users, making masterID management in the generic STM core irrelevant. In this kind of configuration channels are shared between masters

[RESEND PATCH V4 4/4] coresight-stm: adding driver for CoreSight STM component

From: Pratik Patel This driver adds support for the STM CoreSight IP block, allowing any system compoment (HW or SW) to log and aggregate messages via a single entity. The CoreSight STM exposes an application defined number of channels called stimulus port. Configuration is done using entries

[RESEND PATCH V4 2/4] Documentations: Add explanations of the case for non-configurable masters

For some STM hardware (e.g. ARM CoreSight STM), the masterID associated to a source is set at the hardware level and not user configurable. Since the masterID information isn't available to SW, introducing a new value of -1 to reflect this reality. Signed-off-by: Chunyan Zhang ---

[RESEND PATCH V4 1/4] stm class: provision for statically assigned masterIDs

From: Mathieu Poirier Some architecture like ARM assign masterIDs at the HW design phase. Those are therefore unreachable to users, making masterID management in the generic STM core irrelevant. In this kind of configuration channels are shared between masters rather than being allocated on a

[RESEND PATCH V4 3/4] coresight-stm: Bindings for System Trace Macrocell

From: Mathieu Poirier The System Trace Macrocell (STM) is an IP block falling under the CoreSight umbrella. It's main purpose it so expose stimulus channels to any system component for the purpose of information logging. Bindings for this IP block adds a couple of

[RESEND PATCH V4 3/4] coresight-stm: Bindings for System Trace Macrocell

From: Mathieu Poirier The System Trace Macrocell (STM) is an IP block falling under the CoreSight umbrella. It's main purpose it so expose stimulus channels to any system component for the purpose of information logging. Bindings for this IP block adds a couple of items to the current

[RESEND PATCH V4 0/4] Introduce CoreSight STM support

This patchset adds support for the CoreSight STM IP block. In the fourth version, comments from various people have been addressed. Representing configurations where channels are shared between multiple masterIDs has been kept unchanged from the previous version because a viable alternative

[RESEND PATCH V4 0/4] Introduce CoreSight STM support

This patchset adds support for the CoreSight STM IP block. In the fourth version, comments from various people have been addressed. Representing configurations where channels are shared between multiple masterIDs has been kept unchanged from the previous version because a viable alternative

Re: [PATCH] fat: add config option to set UTF-8 mount option by default

"Maciej S. Szmigiero" writes: > +#ifdef CONFIG_FAT_DEFAULT_UTF8 > + opts->utf8 = is_vfat; > +#else > + opts->utf8 = 0; > +#endif > + Maybe, better to use IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8)? I.e., opts->utf8 = IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8) &&

Re: [PATCH] fat: add config option to set UTF-8 mount option by default

"Maciej S. Szmigiero" writes: > +#ifdef CONFIG_FAT_DEFAULT_UTF8 > + opts->utf8 = is_vfat; > +#else > + opts->utf8 = 0; > +#endif > + Maybe, better to use IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8)? I.e., opts->utf8 = IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8) && is_vfat; Thanks. -- OGAWA

Re: Thoughts on tightening up user namespace creation

On Mon, Mar 07, 2016 at 09:15:25PM -0800, Andy Lutomirski wrote: > Hi all- > > There are several users and distros that are nervous about user > namespaces from an attack surface point of view. > > - RHEL and Arch have userns disabled. > > - Ubuntu requires CAP_SYS_ADMIN No, it does not. It

Re: Thoughts on tightening up user namespace creation

On Mon, Mar 07, 2016 at 09:15:25PM -0800, Andy Lutomirski wrote: > Hi all- > > There are several users and distros that are nervous about user > namespaces from an attack surface point of view. > > - RHEL and Arch have userns disabled. > > - Ubuntu requires CAP_SYS_ADMIN No, it does not. It

Re: [PATCH 3/3] ARM: bcm2835: Add VC4 to the device tree.

On 03/04/2016 01:32 PM, Eric Anholt wrote: VC4 is the GPU (display and 3D) present on the 283x. diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts + { + hpd-gpios = < 46 GPIO_ACTIVE_LOW>; +}; Isn't that the same everywhere? If so,

[PATCH v2 net-next 02/12] bpf: introduce percpu_freelist

Introduce simple percpu_freelist to keep single list of elements spread across per-cpu singly linked lists. /* push element into the list */ void pcpu_freelist_push(struct pcpu_freelist *, struct pcpu_freelist_node *); /* pop element from the list */ struct pcpu_freelist_node

Re: [PATCH v1] tools/vm/page-types.c: remove memset() in walk_pfn()

On Tue, Mar 08, 2016 at 08:12:09AM +0300, Konstantin Khlebnikov wrote: > On Tue, Mar 8, 2016 at 4:47 AM, Naoya Horiguchi > wrote: > > I found that page-types is very slow and my testing shows many timeout > > errors. > > Here's an example with a simple program

Re: [PATCH 3/3] ARM: bcm2835: Add VC4 to the device tree.

On 03/04/2016 01:32 PM, Eric Anholt wrote: VC4 is the GPU (display and 3D) present on the 283x. diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts + { + hpd-gpios = < 46 GPIO_ACTIVE_LOW>; +}; Isn't that the same everywhere? If so,

[PATCH v2 net-next 02/12] bpf: introduce percpu_freelist

Introduce simple percpu_freelist to keep single list of elements spread across per-cpu singly linked lists. /* push element into the list */ void pcpu_freelist_push(struct pcpu_freelist *, struct pcpu_freelist_node *); /* pop element from the list */ struct pcpu_freelist_node

Re: [PATCH v1] tools/vm/page-types.c: remove memset() in walk_pfn()

On Tue, Mar 08, 2016 at 08:12:09AM +0300, Konstantin Khlebnikov wrote: > On Tue, Mar 8, 2016 at 4:47 AM, Naoya Horiguchi > wrote: > > I found that page-types is very slow and my testing shows many timeout > > errors. > > Here's an example with a simple program allocating 1000 thps. > > > > $

[PATCH v2 net-next 07/12] samples/bpf: move ksym_search() into library

move ksym search from offwaketime into library to be reused in other tests Signed-off-by: Alexei Starovoitov --- samples/bpf/bpf_load.c | 62 ++ samples/bpf/bpf_load.h | 6 samples/bpf/offwaketime_user.c | 67

[PATCH v2 net-next 06/12] samples/bpf: make map creation more verbose

map creation is typically the first one to fail when rlimits are too low, not enough memory, etc Make this failure scenario more verbose Signed-off-by: Alexei Starovoitov --- samples/bpf/bpf_load.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v2 net-next 03/12] bpf: pre-allocate hash map elements

If kprobe is placed on spin_unlock then calling kmalloc/kfree from bpf programs is not safe, since the following dead lock is possible: kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe-> bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock) and deadlocks. The

[PATCH v2 net-next 07/12] samples/bpf: move ksym_search() into library

move ksym search from offwaketime into library to be reused in other tests Signed-off-by: Alexei Starovoitov --- samples/bpf/bpf_load.c | 62 ++ samples/bpf/bpf_load.h | 6 samples/bpf/offwaketime_user.c | 67

  1   2   3   4   5   6   7   8   9   10   >