[PATCH v2 2/2] MIPS: DTS: img: add device tree for Marduk board

Add support for Imagination Technologies' Marduk board which is based on Pistachio SoC. It is also known as Creator Ci40. Marduk is legacy name and will be there for decades. Documentation for this board can be found on https://docs.creatordev.io/ci40/ This patch adds initial support for board

[PATCH v2 2/2] MIPS: DTS: img: add device tree for Marduk board

Add support for Imagination Technologies' Marduk board which is based on Pistachio SoC. It is also known as Creator Ci40. Marduk is legacy name and will be there for decades. Documentation for this board can be found on https://docs.creatordev.io/ci40/ This patch adds initial support for board

[PATCH v2 1/2] MIPS: DTS: add base device tree for Pistachio SoC

Add support for the base Device Tree for Imagination Technologies' Pistachio SoC. This commit supports the following peripherals: * Clocks * Pinctrl and GPIO * UART * SPI * I2C * PWM * ADC * Watchdog * Ethernet * MMC * DMA engine * Crypto * I2S * SPDIF * Internal DAC * Timer *

[PATCH v2 1/2] MIPS: DTS: add base device tree for Pistachio SoC

Add support for the base Device Tree for Imagination Technologies' Pistachio SoC. This commit supports the following peripherals: * Clocks * Pinctrl and GPIO * UART * SPI * I2C * PWM * ADC * Watchdog * Ethernet * MMC * DMA engine * Crypto * I2S * SPDIF * Internal DAC * Timer *

Re: [PATCH v4 2/4] fusion: remove iopriority handling

On 10/13/2016 09:53 PM, Adam Manzanares wrote: > The request priority is now by default coming from the ioc. It was not > clear what this code was trying to do based upon the iopriority class or > data. The driver should check that a device supports priorities and use > them according to the

Re: [PATCH v4 2/4] fusion: remove iopriority handling

On 10/13/2016 09:53 PM, Adam Manzanares wrote: > The request priority is now by default coming from the ioc. It was not > clear what this code was trying to do based upon the iopriority class or > data. The driver should check that a device supports priorities and use > them according to the

Re: [PATCH v4 1/4] block: Add iocontext priority to request

On 10/13/2016 09:53 PM, Adam Manzanares wrote: > Patch adds an association between iocontext ioprio and the ioprio of a > request. This value is set in blk_rq_set_prio which takes the request and > the ioc as arguments. If the ioc is valid in blk_rq_set_prio then the > iopriority of the request is

Re: [PATCH v4 1/4] block: Add iocontext priority to request

On 10/13/2016 09:53 PM, Adam Manzanares wrote: > Patch adds an association between iocontext ioprio and the ioprio of a > request. This value is set in blk_rq_set_prio which takes the request and > the ioc as arguments. If the ioc is valid in blk_rq_set_prio then the > iopriority of the request is

Re: [PATCH] firmware: declare __{start,end}_builtin_fw as pointers

On 06/26/2016, 07:17 PM, Linus Torvalds wrote: > On Sun, Jun 26, 2016 at 2:24 AM, Vegard Nossum > wrote: >> >> This is the best I could come up with: assuming gcc is not allowed to >> reason about what's inside the asm(), this is the only way I could >> think of to lose

Re: [PATCH] firmware: declare __{start,end}_builtin_fw as pointers

On 06/26/2016, 07:17 PM, Linus Torvalds wrote: > On Sun, Jun 26, 2016 at 2:24 AM, Vegard Nossum > wrote: >> >> This is the best I could come up with: assuming gcc is not allowed to >> reason about what's inside the asm(), this is the only way I could >> think of to lose the array information

Re: [media] RedRat3: Use kcalloc() in two functions?

> Markus, please stop being _so_ mechanical and use your > brain a little too. By definition, sizeof(char) == 1. > > This _really_ should be kzalloc(RR3_FW_VERSION_LEN + 1,...) Do you expect that function call examples like the following will be equivalent? zbuffer = kzalloc(123, …);

Re: [media] RedRat3: Use kcalloc() in two functions?

> Markus, please stop being _so_ mechanical and use your > brain a little too. By definition, sizeof(char) == 1. > > This _really_ should be kzalloc(RR3_FW_VERSION_LEN + 1,...) Do you expect that function call examples like the following will be equivalent? zbuffer = kzalloc(123, …);

Re: [PATCH v5 2/4] fusion: remove iopriority handling

> Style wise you can further remove the extra parens around > SCpnt->device->tagged_supported > As well as the now redundant braces. I did send a patch looking just like that earlier :)

Re: [PATCH v5 2/4] fusion: remove iopriority handling

> Style wise you can further remove the extra parens around > SCpnt->device->tagged_supported > As well as the now redundant braces. I did send a patch looking just like that earlier :)

Re: [PATCH] staging: sm750fb: Fix printk() style warning

On Thu, Oct 13, 2016 at 05:39:22PM +0300, Mike Rapoport wrote: > On Mon, Oct 10, 2016 at 07:31:46AM -0700, Edward Lipinsky wrote: > > > > Thanks, that makes sense. I tried deleting the if statement and printk() > > from ddk750_help.c, and adding the following in lynxfb_pci_probe() after > >

Re: [PATCH] staging: sm750fb: Fix printk() style warning

On Thu, Oct 13, 2016 at 05:39:22PM +0300, Mike Rapoport wrote: > On Mon, Oct 10, 2016 at 07:31:46AM -0700, Edward Lipinsky wrote: > > > > Thanks, that makes sense. I tried deleting the if statement and printk() > > from ddk750_help.c, and adding the following in lynxfb_pci_probe() after > >

Re: [PATCH RESEND v3] dma: omap-dma: add support for pause of non-cyclic transfers

On Thursday 13 October 2016 03:37 PM, Peter Ujfalusi wrote: > On 10/10/16 17:12, Peter Ujfalusi wrote: >> On 10/10/16 15:07, Vignesh R wrote: >>> From: Sebastian Andrzej Siewior >>> >>> This DMA driver is used by 8250-omap on DRA7-evm. There is one >>> requirement that is

Re: [PATCH 3/4] remoteproc: Add a sysfs interface for firmware and state

On Thu 13 Oct 07:39 PDT 2016, loic pallardy wrote: > > > On 10/13/2016 04:25 PM, Matt Redfearn wrote: > >Hi Loic, > > > > > >On 13/10/16 14:56, loic pallardy wrote: > >> > >> > >>On 10/11/2016 03:39 PM, Matt Redfearn wrote: [..] > >>>diff --git a/drivers/remoteproc/remoteproc_internal.h >

Re: [PATCH RESEND v3] dma: omap-dma: add support for pause of non-cyclic transfers

On Thursday 13 October 2016 03:37 PM, Peter Ujfalusi wrote: > On 10/10/16 17:12, Peter Ujfalusi wrote: >> On 10/10/16 15:07, Vignesh R wrote: >>> From: Sebastian Andrzej Siewior >>> >>> This DMA driver is used by 8250-omap on DRA7-evm. There is one >>> requirement that is to pause a transfer.

Re: [PATCH 3/4] remoteproc: Add a sysfs interface for firmware and state

On Thu 13 Oct 07:39 PDT 2016, loic pallardy wrote: > > > On 10/13/2016 04:25 PM, Matt Redfearn wrote: > >Hi Loic, > > > > > >On 13/10/16 14:56, loic pallardy wrote: > >> > >> > >>On 10/11/2016 03:39 PM, Matt Redfearn wrote: [..] > >>>diff --git a/drivers/remoteproc/remoteproc_internal.h >

Re: [PATCH 3/4] remoteproc: Add a sysfs interface for firmware and state

On Tue 11 Oct 06:39 PDT 2016, Matt Redfearn wrote: > This patch adds a sysfs interface to rproc allowing the firmware name > and processor state to be changed dynamically. > > State was previously available in debugfs, and is replicated here. The > firmware file allows retrieval of the running

Re: [PATCH 3/4] remoteproc: Add a sysfs interface for firmware and state

On Tue 11 Oct 06:39 PDT 2016, Matt Redfearn wrote: > This patch adds a sysfs interface to rproc allowing the firmware name > and processor state to be changed dynamically. > > State was previously available in debugfs, and is replicated here. The > firmware file allows retrieval of the running

[PATCH v4] dmaengine: omap-dma: add support for pause of non-cyclic transfers

From: Sebastian Andrzej Siewior This DMA driver is used by 8250-omap on DRA7-evm. There is one requirement that is to pause a transfer. This is currently used on the RX side. It is possible that the UART HW aborted the RX (UART's RX-timeout) but the DMA controller starts

[PATCH v4] dmaengine: omap-dma: add support for pause of non-cyclic transfers

From: Sebastian Andrzej Siewior This DMA driver is used by 8250-omap on DRA7-evm. There is one requirement that is to pause a transfer. This is currently used on the RX side. It is possible that the UART HW aborted the RX (UART's RX-timeout) but the DMA controller starts the transfer shortly

Re: [LKP] [x86] 811565123a: BUG: kernel hang in early-boot stage, last printk: Probing EDD (edd=off to disable)... ok

On 10/14, Ye Xiaolong wrote: >On 10/13, Andi Kleen wrote: >>Andi Kleen writes: >> >>Any comments on this? >> >>I still cannot reproduce the failure unfortunately. >> > >Btw, you can try below commands to reproduce the error on your local >host, they will download the

Re: [LKP] [x86] 811565123a: BUG: kernel hang in early-boot stage, last printk: Probing EDD (edd=off to disable)... ok

On 10/14, Ye Xiaolong wrote: >On 10/13, Andi Kleen wrote: >>Andi Kleen writes: >> >>Any comments on this? >> >>I still cannot reproduce the failure unfortunately. >> > >Btw, you can try below commands to reproduce the error on your local >host, they will download the necessary images and run

Re: [PATCH 2/4] remoteproc: Introduce rproc_change_firmware

On Tue 11 Oct 06:39 PDT 2016, Matt Redfearn wrote: > It is often desirable to be able to change the running firmware on a > remote processor dynamically. This used to require a complete > destruction and readdition of the struct rproc, but now that the > firmware name is fixed length, it can be

Re: [PATCH 2/4] remoteproc: Introduce rproc_change_firmware

On Tue 11 Oct 06:39 PDT 2016, Matt Redfearn wrote: > It is often desirable to be able to change the running firmware on a > remote processor dynamically. This used to require a complete > destruction and readdition of the struct rproc, but now that the > firmware name is fixed length, it can be

Re: [PATCH 1/4] remoteproc: Use fixed length field for firmware name

On Tue 11 Oct 06:39 PDT 2016, Matt Redfearn wrote: > Storage of the firmware name was inconsistent, either storing a pointer > to a name stored with unknown ownership, or a variable length tacked > onto the end of the struct proc allocated in rproc_alloc. > Instead of using a statically sized

Re: [PATCH 1/4] remoteproc: Use fixed length field for firmware name

On Tue 11 Oct 06:39 PDT 2016, Matt Redfearn wrote: > Storage of the firmware name was inconsistent, either storing a pointer > to a name stored with unknown ownership, or a variable length tacked > onto the end of the struct proc allocated in rproc_alloc. > Instead of using a statically sized

Re: [GIT PULL] Please pull NFS client changes for Linux 4.9

On Thu, Oct 13, 2016 at 1:21 PM, Anna Schumaker wrote: > > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.9-1 Please keep the summary of changes in the email too. I can see it in the tag, and it will show up when I do a pull that way, but I'd

Re: [GIT PULL] Please pull NFS client changes for Linux 4.9

On Thu, Oct 13, 2016 at 1:21 PM, Anna Schumaker wrote: > > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.9-1 Please keep the summary of changes in the email too. I can see it in the tag, and it will show up when I do a pull that way, but I'd _really_ like to see it in the

Re: [GIT PULL] overlayfs update for 4.9

On Thu, Oct 13, 2016 at 7:37 AM, Miklos Szeredi wrote: > > Please pull from: No. Or rather, I pulled and then immediately unpulled. When I look at the diff, I saw an obvious bug in the very first chunk. I'm not going to pull something that is this obviously buggy and

Re: [GIT PULL] overlayfs update for 4.9

On Thu, Oct 13, 2016 at 7:37 AM, Miklos Szeredi wrote: > > Please pull from: No. Or rather, I pulled and then immediately unpulled. When I look at the diff, I saw an obvious bug in the very first chunk. I'm not going to pull something that is this obviously buggy and untested. Your change to

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

在 2016-10-14 11:25，John Stultz 写道： On Thu, Oct 13, 2016 at 7:02 PM, Xiaogang Cui wrote: This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

在 2016-10-14 11:25，John Stultz 写道： On Thu, Oct 13, 2016 at 7:02 PM, Xiaogang Cui wrote: This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang Cui ---

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/13/16 at 04:53pm, Baoquan He wrote: > Hi Pratyush, > > On 10/12/16 at 02:39pm, Pratyush Anand wrote: > > > > > > On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote: > > > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only > > > > > VMALLOC_BASE and VMEMMAP_BASE is

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/13/16 at 04:53pm, Baoquan He wrote: > Hi Pratyush, > > On 10/12/16 at 02:39pm, Pratyush Anand wrote: > > > > > > On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote: > > > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only > > > > > VMALLOC_BASE and VMEMMAP_BASE is

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

On Thu, Oct 13, 2016 at 7:02 PM, Xiaogang Cui wrote: > This is a initial version so it's very similar with syscon > reboot mode driver. We will add more functionalities in the > further after dependency is ready. > > Signed-off-by: Xiaogang Cui >

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

On Thu, Oct 13, 2016 at 7:02 PM, Xiaogang Cui wrote: > This is a initial version so it's very similar with syscon > reboot mode driver. We will add more functionalities in the > further after dependency is ready. > > Signed-off-by: Xiaogang Cui > --- >

[PATCH v8 3/8] binding-doc: usb: usb-device: add optional properties for power sequence

Add optional properties for power sequence. Signed-off-by: Peter Chen Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH v8 4/8] usb: core: add power sequence handling for USB devices

Some hard-wired USB devices need to do power sequence to let the device work normally, the typical power sequence like: enable USB PHY clock, toggle reset pin, etc. But current Linux USB driver lacks of such code to do it, it may cause some hard-wired USB devices works abnormal or can't be

[PATCH v8 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

The current dts describes USB HUB's property at USB controller's entry, it is improper. The USB HUB should be the child node under USB controller, and power sequence properties are under it. Besides, using gpio pinctrl setting for USB2415's reset pin. Tested-by: Maciej S. Szmigiero

[PATCH v8 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

From: Peter Chen At device tree, we have no device node for chipidea core, the glue layer's node is the parent node for host and udc device. But in related driver, the parent device is chipidea core. So, in order to let the common driver get parent's node, we let the

[PATCH v8 6/8] ARM: dts: imx6qdl: Enable usb node children with

From: Joshua Clayton Give usb nodes #address and #size attributes, so that a child node representing a permanently connected device such as an onboard hub may be addressed with a attribute Signed-off-by: Joshua Clayton Signed-off-by: Peter

[PATCH v8 4/8] usb: core: add power sequence handling for USB devices

Some hard-wired USB devices need to do power sequence to let the device work normally, the typical power sequence like: enable USB PHY clock, toggle reset pin, etc. But current Linux USB driver lacks of such code to do it, it may cause some hard-wired USB devices works abnormal or can't be

[PATCH v8 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

The current dts describes USB HUB's property at USB controller's entry, it is improper. The USB HUB should be the child node under USB controller, and power sequence properties are under it. Besides, using gpio pinctrl setting for USB2415's reset pin. Tested-by: Maciej S. Szmigiero

[PATCH v8 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

From: Peter Chen At device tree, we have no device node for chipidea core, the glue layer's node is the parent node for host and udc device. But in related driver, the parent device is chipidea core. So, in order to let the common driver get parent's node, we let the core's device node equals

[PATCH v8 6/8] ARM: dts: imx6qdl: Enable usb node children with

From: Joshua Clayton Give usb nodes #address and #size attributes, so that a child node representing a permanently connected device such as an onboard hub may be addressed with a attribute Signed-off-by: Joshua Clayton Signed-off-by: Peter Chen --- arch/arm/boot/dts/imx6qdl.dtsi | 6 ++

[PATCH v8 3/8] binding-doc: usb: usb-device: add optional properties for power sequence

Add optional properties for power sequence. Signed-off-by: Peter Chen Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt

[PATCH v8 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line

From: Joshua Clayton Previously the onboard hub was made to work by treating its reset gpio as a regulator enable. Get rid of that kludge now that pwseq has added reset gpio support Move pin muxing the hub reset pin into the usbh1 group Signed-off-by: Joshua Clayton

[PATCH v8 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line

From: Joshua Clayton Previously the onboard hub was made to work by treating its reset gpio as a regulator enable. Get rid of that kludge now that pwseq has added reset gpio support Move pin muxing the hub reset pin into the usbh1 group Signed-off-by: Joshua Clayton Signed-off-by: Peter Chen

[PATCH v8 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

Add binding doc for generic power sequence library. Signed-off-by: Peter Chen Acked-by: Philipp Zabel Acked-by: Rob Herring --- .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++ 1 file changed, 48

[PATCH v8 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

Add binding doc for generic power sequence library. Signed-off-by: Peter Chen Acked-by: Philipp Zabel Acked-by: Rob Herring --- .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++ 1 file changed, 48 insertions(+) create mode 100644

[GIT PULL] cgroup changes for v4.9-rc1

Hello, Linus. cgroup changes for v4.9-rc1. * Tracepoints for basic cgroup management operations added. * kernfs and cgroup path formatting functions updated to behave in the style of strlcpy(). * Non-critical bug fixes. Thanks. The following changes since commit

[GIT PULL] cgroup changes for v4.9-rc1

Hello, Linus. cgroup changes for v4.9-rc1. * Tracepoints for basic cgroup management operations added. * kernfs and cgroup path formatting functions updated to behave in the style of strlcpy(). * Non-critical bug fixes. Thanks. The following changes since commit

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

Hi, Andy: 在 2016-10-14 10:41，Andy Yan 写道： Hi Xiaogang: On 2016年10月14日 10:02, Xiaogang Cui wrote: This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang Cui

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

Hi, Andy: 在 2016-10-14 10:41，Andy Yan 写道： Hi Xiaogang: On 2016年10月14日 10:02, Xiaogang Cui wrote: This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang Cui ---

[PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

From: Joonsoo Kim Attached cover-letter: This series try to solve problems of current CMA implementation. CMA is introduced to provide physically contiguous pages at runtime without exclusive reserved memory area. But, current implementation works like as previous

[PATCH v6 5/6] mm/cma: remove MIGRATE_CMA

From: Joonsoo Kim Now, all reserved pages for CMA region are belong to the ZONE_CMA and there is no other type of pages. Therefore, we don't need to use MIGRATE_CMA to distinguish and handle differently for CMA pages and ordinary pages. Remove MIGRATE_CMA. Unfortunately,

[PATCH v6 1/6] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

From: Joonsoo Kim Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that important to reserve. When ZONE_MOVABLE is used, this problem would theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE allocation request which is mainly used

[PATCH v6 6/6] mm/cma: remove per zone CMA stat

From: Joonsoo Kim Now, all reserved pages for CMA region are belong to the ZONE_CMA so we don't need to maintain CMA stat in other zones. Remove it. Reviewed-by: Aneesh Kumar K.V Acked-by: Vlastimil Babka Signed-off-by:

[PATCH v6 1/6] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

From: Joonsoo Kim Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that important to reserve. When ZONE_MOVABLE is used, this problem would theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE allocation request which is mainly used for page cache and anon

[PATCH v6 6/6] mm/cma: remove per zone CMA stat

From: Joonsoo Kim Now, all reserved pages for CMA region are belong to the ZONE_CMA so we don't need to maintain CMA stat in other zones. Remove it. Reviewed-by: Aneesh Kumar K.V Acked-by: Vlastimil Babka Signed-off-by: Joonsoo Kim --- fs/proc/meminfo.c | 2 +- include/linux/cma.h

[PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

From: Joonsoo Kim Attached cover-letter: This series try to solve problems of current CMA implementation. CMA is introduced to provide physically contiguous pages at runtime without exclusive reserved memory area. But, current implementation works like as previous reserved memory approach,

[PATCH v6 5/6] mm/cma: remove MIGRATE_CMA

From: Joonsoo Kim Now, all reserved pages for CMA region are belong to the ZONE_CMA and there is no other type of pages. Therefore, we don't need to use MIGRATE_CMA to distinguish and handle differently for CMA pages and ordinary pages. Remove MIGRATE_CMA. Unfortunately, this patch make free

[PATCH v6 3/6] mm/cma: populate ZONE_CMA

From: Joonsoo Kim Until now, reserved pages for CMA are managed in the ordinary zones where page's pfn are belong to. This approach has numorous problems and fixing them isn't easy. (It is mentioned on previous patch.) To fix this situation, ZONE_CMA is introduced in

[PATCH v6 4/6] mm/cma: remove ALLOC_CMA

From: Joonsoo Kim Now, all reserved pages for CMA region are belong to the ZONE_CMA and it only serves for GFP_HIGHUSER_MOVABLE. Therefore, we don't need to consider ALLOC_CMA at all. Reviewed-by: Aneesh Kumar K.V Acked-by: Vlastimil

[PATCH v6 3/6] mm/cma: populate ZONE_CMA

From: Joonsoo Kim Until now, reserved pages for CMA are managed in the ordinary zones where page's pfn are belong to. This approach has numorous problems and fixing them isn't easy. (It is mentioned on previous patch.) To fix this situation, ZONE_CMA is introduced in previous patch, but, not yet

[PATCH v6 4/6] mm/cma: remove ALLOC_CMA

From: Joonsoo Kim Now, all reserved pages for CMA region are belong to the ZONE_CMA and it only serves for GFP_HIGHUSER_MOVABLE. Therefore, we don't need to consider ALLOC_CMA at all. Reviewed-by: Aneesh Kumar K.V Acked-by: Vlastimil Babka Signed-off-by: Joonsoo Kim --- mm/compaction.c | 4

[PATCH v6 0/6] Introduce ZONE_CMA

From: Joonsoo Kim <iamjoonsoo@lge.com> Hello, Changes from v5 o Add acked/reviewed-by tag from Vlastimil and Aneesh o Rebase on next-20161013 o Cosmetic change on patch 1 o Optimize span of ZONE_CMA on multiple node system Changes from v4 o Rebase on next-20160825 o Add general fix

[PATCH v6 0/6] Introduce ZONE_CMA

From: Joonsoo Kim Hello, Changes from v5 o Add acked/reviewed-by tag from Vlastimil and Aneesh o Rebase on next-20161013 o Cosmetic change on patch 1 o Optimize span of ZONE_CMA on multiple node system Changes from v4 o Rebase on next-20160825 o Add general fix patch for lowmem reserve o Fix

Re: [PATCH v4 0/3] Broadcom STB AVS CPUfreq driver

On 13-10-16, 14:49, Rafael J. Wysocki wrote: > I gess patch [1/3] needs some ACKs from the DT bindings maintainers? It would be better if we get one.. -- viresh

Re: [PATCH v4 0/3] Broadcom STB AVS CPUfreq driver

On 13-10-16, 14:49, Rafael J. Wysocki wrote: > I gess patch [1/3] needs some ACKs from the DT bindings maintainers? It would be better if we get one.. -- viresh

[PATCH v8 2/8] power: add power sequence library

We have an well-known problem that the device needs to do some power sequence before it can be recognized by related host, the typical example like hard-wired mmc devices and usb devices. This power sequence is hard to be described at device tree and handled by related host driver, so we have

Re: [PATCH v4 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

On 12-10-16, 15:12, Markus Mayer wrote: > Add the binding document for the new brcmstb-avs-cpufreq driver. > > Signed-off-by: Markus Mayer > Acked-by: Viresh Kumar > --- > .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 76 >

Re: [PATCH v4 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

On 12-10-16, 15:12, Markus Mayer wrote: > Add the binding document for the new brcmstb-avs-cpufreq driver. > > Signed-off-by: Markus Mayer > Acked-by: Viresh Kumar > --- > .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 76 > ++ > MAINTAINERS

[PATCH v8 2/8] power: add power sequence library

We have an well-known problem that the device needs to do some power sequence before it can be recognized by related host, the typical example like hard-wired mmc devices and usb devices. This power sequence is hard to be described at device tree and handled by related host driver, so we have

[PATCH v8 0/8] power: add power sequence library

Hi all, This is a follow-up for my last power sequence framework patch set [1]. According to Rob Herring and Ulf Hansson's comments[2]. The kinds of power sequence instances will be added at postcore_initcall, the match criteria is compatible string first, if the compatible string is not matched

[PATCH v8 0/8] power: add power sequence library

Hi all, This is a follow-up for my last power sequence framework patch set [1]. According to Rob Herring and Ulf Hansson's comments[2]. The kinds of power sequence instances will be added at postcore_initcall, the match criteria is compatible string first, if the compatible string is not matched

Re: [PATCH] ceph: Fix uninitialized dentry pointer in ceph_real_mount()

On Thu, Oct 13, 2016 at 11:15 PM, Geert Uytterhoeven wrote: > fs/ceph/super.c: In function ‘ceph_real_mount’: > fs/ceph/super.c:818: warning: ‘root’ may be used uninitialized in this > function > > If s_root is already valid, dentry pointer root is never

Re: [PATCH] ceph: Fix uninitialized dentry pointer in ceph_real_mount()

On Thu, Oct 13, 2016 at 11:15 PM, Geert Uytterhoeven wrote: > fs/ceph/super.c: In function ‘ceph_real_mount’: > fs/ceph/super.c:818: warning: ‘root’ may be used uninitialized in this > function > > If s_root is already valid, dentry pointer root is never initialized, > and returned by

Re: [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once

Andrey Vagin writes: > On Thu, Oct 13, 2016 at 2:46 PM, Andrei Vagin wrote: >> On Thu, Oct 13, 2016 at 02:53:46PM -0500, Eric W. Biederman wrote: >>> >>> Adrei Vagin pointed out that time to executue propagate_umount can go >>> non-linear (and take a

Re: [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once

Andrey Vagin writes: > On Thu, Oct 13, 2016 at 2:46 PM, Andrei Vagin wrote: >> On Thu, Oct 13, 2016 at 02:53:46PM -0500, Eric W. Biederman wrote: >>> >>> Adrei Vagin pointed out that time to executue propagate_umount can go >>> non-linear (and take a ludicrious amount of time) when the mount

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

Hi Xiaogang: On 2016年10月14日 10:02, Xiaogang Cui wrote: This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang Cui --- As your commit

Re: [PATCH 1/2] power: reset: Add qcom reboot mode driver

Hi Xiaogang: On 2016年10月14日 10:02, Xiaogang Cui wrote: This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang Cui --- As your commit messages said, "it's very

Re: [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once

On Thu, Oct 13, 2016 at 2:46 PM, Andrei Vagin wrote: > On Thu, Oct 13, 2016 at 02:53:46PM -0500, Eric W. Biederman wrote: >> >> Adrei Vagin pointed out that time to executue propagate_umount can go >> non-linear (and take a ludicrious amount of time) when the mount >>

Re: [RFC][PATCH] mount: In mark_umount_candidates and __propogate_umount visit each mount once

On Thu, Oct 13, 2016 at 2:46 PM, Andrei Vagin wrote: > On Thu, Oct 13, 2016 at 02:53:46PM -0500, Eric W. Biederman wrote: >> >> Adrei Vagin pointed out that time to executue propagate_umount can go >> non-linear (and take a ludicrious amount of time) when the mount >> propogation trees of the

linux-next: Tree for Oct 14

Hi all, Please do *not* add any v4.10 material to your linux-next included trees until v4.9-rc1 has been released i.e. the merge window closes. Changes since 20161013: The akpm-current tree still had its build failures for which I applied 2 patches. The akpm tree gained a conflict against

linux-next: Tree for Oct 14

Hi all, Please do *not* add any v4.10 material to your linux-next included trees until v4.9-rc1 has been released i.e. the merge window closes. Changes since 20161013: The akpm-current tree still had its build failures for which I applied 2 patches. The akpm tree gained a conflict against

[PATCH 1/2] power: reset: Add qcom reboot mode driver

This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang Cui --- .../bindings/power_supply/qcom-reboot-mode.txt | 23 +

[PATCH 1/2] power: reset: Add qcom reboot mode driver

This is a initial version so it's very similar with syscon reboot mode driver. We will add more functionalities in the further after dependency is ready. Signed-off-by: Xiaogang Cui --- .../bindings/power_supply/qcom-reboot-mode.txt | 23 + drivers/power/reset/Kconfig

linux-next: manual merge of the akpm tree with the net tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: include/linux/mlx5/device.h between commit: b8a4ddb2e8f4 ("net/mlx5: Add MLX5_ARRAY_SET64 to fix BUILD_BUG_ON") from the net tree and patch: "include/linux/mlx5/device.h: kill BUILD_BUG_ON()s" from the akpm tree.

linux-next: manual merge of the akpm tree with the net tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: include/linux/mlx5/device.h between commit: b8a4ddb2e8f4 ("net/mlx5: Add MLX5_ARRAY_SET64 to fix BUILD_BUG_ON") from the net tree and patch: "include/linux/mlx5/device.h: kill BUILD_BUG_ON()s" from the akpm tree.

[PATCH 2/2] arm64: dts: add msm8996 reboot mode support

Add reboot mode entry for MSM8996 platform. Signed-off-by: Xiaogang Cui --- arch/arm64/boot/dts/qcom/pm8994.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/pm8994.dtsi b/arch/arm64/boot/dts/qcom/pm8994.dtsi index

[PATCH 2/2] arm64: dts: add msm8996 reboot mode support

Add reboot mode entry for MSM8996 platform. Signed-off-by: Xiaogang Cui --- arch/arm64/boot/dts/qcom/pm8994.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/pm8994.dtsi b/arch/arm64/boot/dts/qcom/pm8994.dtsi index 1222d2e..c9b14ab 100644 ---

Re: [PATCH] irqchip/gic: Enable gic_set_affinity set more than one cpu

Marc, Thanks for your comments. Cheng on 10/13/2016 11:31 PM, Marc Zyngier wrote: > On Thu, 13 Oct 2016 18:57:14 +0800 > Cheng Chao wrote: > >> GIC can distribute an interrupt to more than one cpu, >> but now, gic_set_affinity sets only one cpu to handle interrupt. >

Re: [PATCH] irqchip/gic: Enable gic_set_affinity set more than one cpu

Marc, Thanks for your comments. Cheng on 10/13/2016 11:31 PM, Marc Zyngier wrote: > On Thu, 13 Oct 2016 18:57:14 +0800 > Cheng Chao wrote: > >> GIC can distribute an interrupt to more than one cpu, >> but now, gic_set_affinity sets only one cpu to handle interrupt. > > What makes you think

Re: [RFC PATCH 5/5] mm/page_alloc: support fixed migratetype pageblock

On Thu, Oct 13, 2016 at 01:05:11PM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >We have migratetype facility to minimise fragmentation. It dynamically > >changes migratetype of pageblock based on some criterias

Re: [RFC PATCH 5/5] mm/page_alloc: support fixed migratetype pageblock

On Thu, Oct 13, 2016 at 01:05:11PM +0200, Vlastimil Babka wrote: > On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >We have migratetype facility to minimise fragmentation. It dynamically > >changes migratetype of pageblock based on some criterias but it never > >be

  1   2   3   4   5   6   7   8   9   10   >