Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 21 December 2016 at 15:58, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 16:53, Baolin Wang wrote: >> Hi, >> >> On 21 December 2016 at 15:20, Chanwoo Choi wrote: >>> Hi, >>> >>> On 2016년 12월 21일 15:10, Baolin Wang wrote: Current there

Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 21 December 2016 at 15:58, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 16:53, Baolin Wang wrote: >> Hi, >> >> On 21 December 2016 at 15:20, Chanwoo Choi wrote: >>> Hi, >>> >>> On 2016년 12월 21일 15:10, Baolin Wang wrote: Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP"

Re: [PATCH RFC 1/1] mm, page_alloc: fix incorrect zone_statistics data

On Tue 20-12-16 14:54:35, Mel Gorman wrote: > On Tue, Dec 20, 2016 at 03:35:02PM +0100, Michal Hocko wrote: > > On Tue 20-12-16 14:28:45, Mel Gorman wrote: > > > On Tue, Dec 20, 2016 at 02:26:43PM +0100, Michal Hocko wrote: > > > > On Tue 20-12-16 13:10:40, Mel Gorman wrote: > > > > > On Tue, Dec

Re: [PATCH RFC 1/1] mm, page_alloc: fix incorrect zone_statistics data

On Tue 20-12-16 14:54:35, Mel Gorman wrote: > On Tue, Dec 20, 2016 at 03:35:02PM +0100, Michal Hocko wrote: > > On Tue 20-12-16 14:28:45, Mel Gorman wrote: > > > On Tue, Dec 20, 2016 at 02:26:43PM +0100, Michal Hocko wrote: > > > > On Tue 20-12-16 13:10:40, Mel Gorman wrote: > > > > > On Tue, Dec

Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 2016년 12월 21일 16:53, Baolin Wang wrote: > Hi, > > On 21 December 2016 at 15:20, Chanwoo Choi wrote: >> Hi, >> >> On 2016년 12월 21일 15:10, Baolin Wang wrote: >>> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which >>> both seem to suggest a standard

Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 2016년 12월 21일 16:53, Baolin Wang wrote: > Hi, > > On 21 December 2016 at 15:20, Chanwoo Choi wrote: >> Hi, >> >> On 2016년 12월 21일 15:10, Baolin Wang wrote: >>> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which >>> both seem to suggest a standard downstream port. But there

Re: [PATCH 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 21 December 2016 at 15:29, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 15:10, Baolin Wang wrote: >> According to the documentation, we should set the EXTCON_USB when >> one SDP charger connector was reported. >> >> Signed-off-by: Baolin Wang

Re: [PATCH 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 21 December 2016 at 15:29, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 15:10, Baolin Wang wrote: >> According to the documentation, we should set the EXTCON_USB when >> one SDP charger connector was reported. >> >> Signed-off-by: Baolin Wang >> --- >>

Re: [PATCH 2/3] extcon: axp288: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 21 December 2016 at 15:22, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 15:10, Baolin Wang wrote: >> According to the documentation, we should set the EXTCON_USB when >> one SDP charger connector was reported. >> >> Signed-off-by: Baolin Wang

Re: [PATCH 2/3] extcon: axp288: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 21 December 2016 at 15:22, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 15:10, Baolin Wang wrote: >> According to the documentation, we should set the EXTCON_USB when >> one SDP charger connector was reported. >> >> Signed-off-by: Baolin Wang >> --- >> drivers/extcon/extcon-axp288.c |

Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 21 December 2016 at 15:20, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 15:10, Baolin Wang wrote: >> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which >> both seem to suggest a standard downstream port. But there is no >> documentation describing

Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 21 December 2016 at 15:20, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 21일 15:10, Baolin Wang wrote: >> Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which >> both seem to suggest a standard downstream port. But there is no >> documentation describing how these relate. >> >>

[PATCH] pci: add kernel config option for disabling common PCI quirks

From: Gabor Juhos These quirks do not effect small small plastic routers. These routers tend to have very little flash space. This patch adds a new option that allows us to build a kernel without including the common quirks, thus saving us valuable flash space. When building

[PATCH] pci: add kernel config option for disabling common PCI quirks

From: Gabor Juhos These quirks do not effect small small plastic routers. These routers tend to have very little flash space. This patch adds a new option that allows us to build a kernel without including the common quirks, thus saving us valuable flash space. When building an image for a

Re: [PATCH V2 2/2] mm/memblock.c: check return value of memblock_reserve() in memblock_virt_alloc_internal()

On Tue 20-12-16 16:48:23, Wei Yang wrote: > On Mon, Dec 19, 2016 at 04:21:57PM +0100, Michal Hocko wrote: > >On Sun 18-12-16 14:47:50, Wei Yang wrote: > >> memblock_reserve() may fail in case there is not enough regions. > > > >Have you seen this happenning in the real setups or this is a

Re: [PATCH V2 2/2] mm/memblock.c: check return value of memblock_reserve() in memblock_virt_alloc_internal()

On Tue 20-12-16 16:48:23, Wei Yang wrote: > On Mon, Dec 19, 2016 at 04:21:57PM +0100, Michal Hocko wrote: > >On Sun 18-12-16 14:47:50, Wei Yang wrote: > >> memblock_reserve() may fail in case there is not enough regions. > > > >Have you seen this happenning in the real setups or this is a

Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

On Tue, Dec 20, 2016 at 12:02:27AM -0200, Mauricio Faria de Oliveira wrote: > When a SCSI command (e.g., read operation) is partially completed > with good status and residual bytes (i.e., not all the bytes from > the specified transfer length were transferred) the SCSI midlayer > will update the

Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

On Tue, Dec 20, 2016 at 12:02:27AM -0200, Mauricio Faria de Oliveira wrote: > When a SCSI command (e.g., read operation) is partially completed > with good status and residual bytes (i.e., not all the bytes from > the specified transfer length were transferred) the SCSI midlayer > will update the

Re: [PATCH V2 1/2] mm/memblock.c: trivial code refine in memblock_is_region_memory()

On Tue 20-12-16 16:35:40, Wei Yang wrote: > On Mon, Dec 19, 2016 at 04:15:14PM +0100, Michal Hocko wrote: > >On Sun 18-12-16 14:47:49, Wei Yang wrote: > >> The base address is already guaranteed to be in the region by > >> memblock_search(). > > > > Hi, Michal > > Nice to receive your comment. >

Re: [PATCH V2 1/2] mm/memblock.c: trivial code refine in memblock_is_region_memory()

On Tue 20-12-16 16:35:40, Wei Yang wrote: > On Mon, Dec 19, 2016 at 04:15:14PM +0100, Michal Hocko wrote: > >On Sun 18-12-16 14:47:49, Wei Yang wrote: > >> The base address is already guaranteed to be in the region by > >> memblock_search(). > > > > Hi, Michal > > Nice to receive your comment. >

RE: [PATCH] acpi: Fix format string type mistakes

Hi, Kees and Emese I just helped to back port the commit here: https://github.com/acpica/acpica/pull/196/commits/5e64857f If you can see something wrong in it, please let me know. Thanks and best regards Lv > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv > Subject: Re:

RE: [PATCH] acpi: Fix format string type mistakes

Hi, Kees and Emese I just helped to back port the commit here: https://github.com/acpica/acpica/pull/196/commits/5e64857f If you can see something wrong in it, please let me know. Thanks and best regards Lv > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv > Subject: Re:

Re: OOM: Better, but still there on

TL;DR there is another version of the debugging patch. Just revert the previous one and apply this one instead. It's still not clear what is going on but I suspect either some misaccounting or unexpeted pages on the LRU lists. I have added one more tracepoint, so please enable also

Re: OOM: Better, but still there on

TL;DR there is another version of the debugging patch. Just revert the previous one and apply this one instead. It's still not clear what is going on but I suspect either some misaccounting or unexpeted pages on the LRU lists. I have added one more tracepoint, so please enable also

Re: [PATCH V2 2/3] mtd: spi-nor: add support for macronix mx25u3235f

On 21/12/2016 08:33, Marek Vasut wrote: > On 12/21/2016 08:23 AM, John Crispin wrote: >> From: André Valentin >> >> This patch adds support for a new macronix spi flash chip. We have had this >> patch inside our tree for a while and people are actively using routers >>

Re: [PATCH V2 2/3] mtd: spi-nor: add support for macronix mx25u3235f

On 21/12/2016 08:33, Marek Vasut wrote: > On 12/21/2016 08:23 AM, John Crispin wrote: >> From: André Valentin >> >> This patch adds support for a new macronix spi flash chip. We have had this >> patch inside our tree for a while and people are actively using routers >> with this chip. >> >>

Re: [PATCH V2 2/3] mtd: spi-nor: add support for macronix mx25u3235f

On 12/21/2016 08:23 AM, John Crispin wrote: > From: André Valentin > > This patch adds support for a new macronix spi flash chip. We have had this > patch inside our tree for a while and people are actively using routers > with this chip. > > Signed-off-by: John Crispin

Re: [PATCH V2 2/3] mtd: spi-nor: add support for macronix mx25u3235f

On 12/21/2016 08:23 AM, John Crispin wrote: > From: André Valentin > > This patch adds support for a new macronix spi flash chip. We have had this > patch inside our tree for a while and people are actively using routers > with this chip. > > Signed-off-by: John Crispin > Signed-off-by: André

Re: [PATCH V2 1/3] mtd: spi-nor: add support for macronix mx25u25635f

On 12/21/2016 08:23 AM, John Crispin wrote: > From: Ash Benz > > This patch adds support for a new macronix spi flash chip. > We have had this > patch inside our tree for a while and people are actively using routers > with this chip. I think this information shouldn't be part

Re: [PATCH V2 1/3] mtd: spi-nor: add support for macronix mx25u25635f

On 12/21/2016 08:23 AM, John Crispin wrote: > From: Ash Benz > > This patch adds support for a new macronix spi flash chip. > We have had this > patch inside our tree for a while and people are actively using routers > with this chip. I think this information shouldn't be part of the commit

Re: [PATCH 02/15] hyperv: uapi-fy synic event flags definitions

On Tue, Dec 20, 2016 at 09:24:53AM -0800, Stephen Hemminger wrote: > On Tue, 20 Dec 2016 18:55:49 +0300 > Roman Kagan wrote: > > > Move definitions related to the Hyper-V SynIC event flags to a header > > where they can be consumed by userspace. > > > > While doing so,

Re: [PATCH 02/15] hyperv: uapi-fy synic event flags definitions

On Tue, Dec 20, 2016 at 09:24:53AM -0800, Stephen Hemminger wrote: > On Tue, 20 Dec 2016 18:55:49 +0300 > Roman Kagan wrote: > > > Move definitions related to the Hyper-V SynIC event flags to a header > > where they can be consumed by userspace. > > > > While doing so, also clean up their use

Re: [PATCH 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 2016년 12월 21일 15:10, Baolin Wang wrote: > According to the documentation, we should set the EXTCON_USB when > one SDP charger connector was reported. > > Signed-off-by: Baolin Wang > --- > drivers/phy/phy-rockchip-inno-usb2.c |7 ++- > 1 file changed, 6

Re: [PATCH 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 2016년 12월 21일 15:10, Baolin Wang wrote: > According to the documentation, we should set the EXTCON_USB when > one SDP charger connector was reported. > > Signed-off-by: Baolin Wang > --- > drivers/phy/phy-rockchip-inno-usb2.c |7 ++- > 1 file changed, 6 insertions(+), 1

[PATCH V2 2/3] mtd: spi-nor: add support for macronix mx25u3235f

From: André Valentin This patch adds support for a new macronix spi flash chip. We have had this patch inside our tree for a while and people are actively using routers with this chip. Signed-off-by: John Crispin Signed-off-by: André Valentin

[PATCH V2 2/3] mtd: spi-nor: add support for macronix mx25u3235f

From: André Valentin This patch adds support for a new macronix spi flash chip. We have had this patch inside our tree for a while and people are actively using routers with this chip. Signed-off-by: John Crispin Signed-off-by: André Valentin --- Changes in V2 * add description * add SECT_4K

[PATCH V2 3/3] mtd: spi-nor: add support for ESMT_f25l32qa and ESMT_f25l64qa

From: "Larry D. Pinney" Add Support for the ESMT_F25L32QA and ESMT_F25L64QA These are 4MB and 8MB SPI NOR Chips from Elite Semiconductor Memory Technology Acked-by: Marek Vasut Signed-off-by: John Crispin Signed-off-by: Larry D. Pinney

[PATCH V2 3/3] mtd: spi-nor: add support for ESMT_f25l32qa and ESMT_f25l64qa

From: "Larry D. Pinney" Add Support for the ESMT_F25L32QA and ESMT_F25L64QA These are 4MB and 8MB SPI NOR Chips from Elite Semiconductor Memory Technology Acked-by: Marek Vasut Signed-off-by: John Crispin Signed-off-by: Larry D. Pinney --- drivers/mtd/spi-nor/spi-nor.c |2 ++ 1 file

[PATCH V2 1/3] mtd: spi-nor: add support for macronix mx25u25635f

From: Ash Benz This patch adds support for a new macronix spi flash chip. We have had this patch inside our tree for a while and people are actively using routers with this chip. Signed-off-by: John Crispin Signed-off-by: Ash Benz --- Changes

[PATCH V2 1/3] mtd: spi-nor: add support for macronix mx25u25635f

From: Ash Benz This patch adds support for a new macronix spi flash chip. We have had this patch inside our tree for a while and people are actively using routers with this chip. Signed-off-by: John Crispin Signed-off-by: Ash Benz --- Changes in V2 * add description

[PATCH V2 0/3] mtd: spi-nor: add some new chip ids

These have been lingering inside the owrt and lede trees for a while. André Valentin (1): mtd: spi-nor: add support for macronix mx25u3235f Ash Benz (1): mtd: spi-nor: add support for macronix mx25u25635f Larry D. Pinney (1): mtd: spi-nor: add support for ESMT_f25l32qa and ESMT_f25l64qa

[PATCH V2 0/3] mtd: spi-nor: add some new chip ids

These have been lingering inside the owrt and lede trees for a while. André Valentin (1): mtd: spi-nor: add support for macronix mx25u3235f Ash Benz (1): mtd: spi-nor: add support for macronix mx25u25635f Larry D. Pinney (1): mtd: spi-nor: add support for ESMT_f25l32qa and ESMT_f25l64qa

Re: [PATCH 2/3] extcon: axp288: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 2016년 12월 21일 15:10, Baolin Wang wrote: > According to the documentation, we should set the EXTCON_USB when > one SDP charger connector was reported. > > Signed-off-by: Baolin Wang > --- > drivers/extcon/extcon-axp288.c |7 ++- > 1 file changed, 6

Re: [PATCH 2/3] extcon: axp288: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

Hi, On 2016년 12월 21일 15:10, Baolin Wang wrote: > According to the documentation, we should set the EXTCON_USB when > one SDP charger connector was reported. > > Signed-off-by: Baolin Wang > --- > drivers/extcon/extcon-axp288.c |7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) >

Re: [PATCH] kernel: sys: fix out of place EXPORT_SYMBOL call

On Tue 20-12-16 14:39:19, Thomas Casey wrote: > Fixes two instances of EXPORT_SYMBOL not being called immediately after > the initialization of its argument What does this fix actually? > Signed-off-by: Thomas Casey > --- > kernel/sys.c | 6 ++ > 1 file changed, 2

Re: [PATCH] kernel: sys: fix out of place EXPORT_SYMBOL call

On Tue 20-12-16 14:39:19, Thomas Casey wrote: > Fixes two instances of EXPORT_SYMBOL not being called immediately after > the initialization of its argument What does this fix actually? > Signed-off-by: Thomas Casey > --- > kernel/sys.c | 6 ++ > 1 file changed, 2 insertions(+), 4

Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 2016년 12월 21일 15:10, Baolin Wang wrote: > Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which > both seem to suggest a standard downstream port. But there is no > documentation describing how these relate. > > Thus add documentation to describe EXTCON_CHG_USB_SDP should

Re: [PATCH 1/3] extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*

Hi, On 2016년 12월 21일 15:10, Baolin Wang wrote: > Current there is both "EXTCON_USB" and "EXTCON_CHG_USB_SDP" which > both seem to suggest a standard downstream port. But there is no > documentation describing how these relate. > > Thus add documentation to describe EXTCON_CHG_USB_SDP should

Re: [PATCH v6] soc: qcom: Add SoC info driver

On 12/21/2016 4:20 AM, Stephen Boyd wrote: > On 12/18, Imran Khan wrote: >> >> I had discussed this with Bjorn and it was recommended to keep it out of >> smem.h. If needed I can move it back there. > > Ok no worries from me then if this has already been discussed. > >> >> Yes. The numbers used

Re: [PATCH v6] soc: qcom: Add SoC info driver

On 12/21/2016 4:20 AM, Stephen Boyd wrote: > On 12/18, Imran Khan wrote: >> >> I had discussed this with Bjorn and it was recommended to keep it out of >> smem.h. If needed I can move it back there. > > Ok no worries from me then if this has already been discussed. > >> >> Yes. The numbers used

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

Hi Sven, [auto build test ERROR on linus/master] [also build test ERROR on next-20161221] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

Hi Sven, [auto build test ERROR on linus/master] [also build test ERROR on next-20161221] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] openrisc: Define __kernel_size_t to suppress compiler warnings

On Tue, Dec 20, 2016 at 11:44 PM, Andreas Schwab wrote: > On Dez 20 2016, Geert Uytterhoeven wrote: >> When I saw this patch, I was already a bit skeptical about it, but I noticed >> other architectures (e.g. avr32) are doing the same, so I didn't

Re: [PATCH] openrisc: Define __kernel_size_t to suppress compiler warnings

On Tue, Dec 20, 2016 at 11:44 PM, Andreas Schwab wrote: > On Dez 20 2016, Geert Uytterhoeven wrote: >> When I saw this patch, I was already a bit skeptical about it, but I noticed >> other architectures (e.g. avr32) are doing the same, so I didn't reply. >> >> In my experience, "format '%zu'

[PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

Add a new feature which supports sending the page information with range array. The current implementation uses PFNs array, which is not very efficient. Using ranges can improve the performance of inflating/deflating significantly. Signed-off-by: Liang Li Cc: Michael S.

[PATCH v6 kernel 4/5] virtio-balloon: define flags and head for host request vq

Define the flags and head struct for a new host request virtual queue. Guest can get requests from host and then responds to them on this new virtual queue. Host can make use of this virtual queue to request the guest do some operations, e.g. drop page cache, synchronize file system, etc. And the

[PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

Add a new feature which supports sending the page information with range array. The current implementation uses PFNs array, which is not very efficient. Using ranges can improve the performance of inflating/deflating significantly. Signed-off-by: Liang Li Cc: Michael S. Tsirkin Cc: Paolo

[PATCH v6 kernel 4/5] virtio-balloon: define flags and head for host request vq

Define the flags and head struct for a new host request virtual queue. Guest can get requests from host and then responds to them on this new virtual queue. Host can make use of this virtual queue to request the guest do some operations, e.g. drop page cache, synchronize file system, etc. And the

[PATCH v6 kernel 5/5] virtio-balloon: tell host vm's unused page info

This patch contains two parts: One is to add a new API to mm go get the unused page information. The virtio balloon driver will use this new API added to get the unused page info and send it to hypervisor(QEMU) to speed up live migration. During sending the bitmap, some the pages may be modified

[PATCH v6 kernel 5/5] virtio-balloon: tell host vm's unused page info

This patch contains two parts: One is to add a new API to mm go get the unused page information. The virtio balloon driver will use this new API added to get the unused page info and send it to hypervisor(QEMU) to speed up live migration. During sending the bitmap, some the pages may be modified

[PATCH v6 kernel 1/5] virtio-balloon: rework deflate to add page to a list

When doing the inflating/deflating operation, the current virtio-balloon implementation uses an array to save 256 PFNS, then send these PFNS to host through virtio and process each PFN one by one. This way is not efficient when inflating/deflating a large mount of memory because too many times of

[PATCH v6 kernel 1/5] virtio-balloon: rework deflate to add page to a list

When doing the inflating/deflating operation, the current virtio-balloon implementation uses an array to save 256 PFNS, then send these PFNS to host through virtio and process each PFN one by one. This way is not efficient when inflating/deflating a large mount of memory because too many times of

[PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

The implementation of the current virtio-balloon is not very efficient, the time spends on different stages of inflating the balloon to 7GB of a 8GB idle guest: a. allocating pages (6.5%) b. sending PFNs to host (68.3%) c. address translation (6.1%) d. madvise (19%) It takes about 4126ms for the

[PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

This patch set contains two parts of changes to the virtio-balloon. One is the change for speeding up the inflating & deflating process, the main idea of this optimization is to use {pfn|length} to present the page information instead of the PFNs, to reduce the overhead of virtio data

[PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

The implementation of the current virtio-balloon is not very efficient, the time spends on different stages of inflating the balloon to 7GB of a 8GB idle guest: a. allocating pages (6.5%) b. sending PFNs to host (68.3%) c. address translation (6.1%) d. madvise (19%) It takes about 4126ms for the

[PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

This patch set contains two parts of changes to the virtio-balloon. One is the change for speeding up the inflating & deflating process, the main idea of this optimization is to use {pfn|length} to present the page information instead of the PFNs, to reduce the overhead of virtio data

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

Hi Mathias, I have some comments for the implementation of xhci_handle_command_timeout() as well. On 12/20/2016 11:13 PM, Mathias Nyman wrote: > On 20.12.2016 09:30, Baolin Wang wrote: > ... > > Alright, I gathered all current work related to xhci races and timeouts > and put them into a branch:

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

Hi Mathias, I have some comments for the implementation of xhci_handle_command_timeout() as well. On 12/20/2016 11:13 PM, Mathias Nyman wrote: > On 20.12.2016 09:30, Baolin Wang wrote: > ... > > Alright, I gathered all current work related to xhci races and timeouts > and put them into a branch:

[PATCH v19 14/15] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer

From: Fu Wei The patch add memory-mapped timer register support by using the information provided by the new GTDT driver of ACPI. Signed-off-by: Fu Wei --- drivers/clocksource/arm_arch_timer.c | 35 --- 1 file changed, 32

[PATCH v19 15/15] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver

From: Fu Wei This driver adds support for parsing SBSA Generic Watchdog timer in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT, and creating a platform device with that information. This allows the operating system to obtain device data from the resource of

[PATCH v19 14/15] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer

From: Fu Wei The patch add memory-mapped timer register support by using the information provided by the new GTDT driver of ACPI. Signed-off-by: Fu Wei --- drivers/clocksource/arm_arch_timer.c | 35 --- 1 file changed, 32 insertions(+), 3 deletions(-) diff

[PATCH v19 15/15] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver

From: Fu Wei This driver adds support for parsing SBSA Generic Watchdog timer in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT, and creating a platform device with that information. This allows the operating system to obtain device data from the resource of platform device.

[PATCH v19 11/15] acpi/arm64: Add GTDT table parse driver

From: Fu Wei This patch adds support for parsing arch timer info in GTDT, provides some kernel APIs to parse all the PPIs and always-on info in GTDT and export them. By this driver, we can simplify arm_arch_timer drivers, and separate the ACPI GTDT knowledge from it.

[PATCH v19 13/15] acpi/arm64: Add memory-mapped timer support in GTDT driver

From: Fu Wei On platforms booting with ACPI, architected memory-mapped timers' configuration data is provided by firmware through the ACPI GTDT static table. The clocksource architected timer kernel driver requires a firmware interface to collect timer configuration and

[PATCH v19 12/15] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.

From: Fu Wei The patch update arm_arch_timer driver to use the function provided by the new GTDT driver of ACPI. By this way, arm_arch_timer.c can be simplified, and separate all the ACPI GTDT knowledge from this timer driver. Signed-off-by: Fu Wei

[PATCH v19 09/15] clocksource/drivers/arm_arch_timer: Introduce some new structs to prepare for GTDT

From: Fu Wei The patch introduce two new structs: arch_timer_mem, arch_timer_mem_frame. And also introduce a new define: ARCH_TIMER_MEM_MAX_FRAMES These will be used for refactoring the memory-mapped timer init code to prepare for GTDT Signed-off-by: Fu Wei

[PATCH v19 07/15] clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing

From: Fu Wei When system init with device-tree, we don't know which node will be initialized first. And the code in arch_timer_common_init should wait until per-cpu timer and MMIO timer are both initialized. So we need arch_timer_needs_probing to detect the init status of

[PATCH v19 09/15] clocksource/drivers/arm_arch_timer: Introduce some new structs to prepare for GTDT

From: Fu Wei The patch introduce two new structs: arch_timer_mem, arch_timer_mem_frame. And also introduce a new define: ARCH_TIMER_MEM_MAX_FRAMES These will be used for refactoring the memory-mapped timer init code to prepare for GTDT Signed-off-by: Fu Wei ---

[PATCH v19 07/15] clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing

From: Fu Wei When system init with device-tree, we don't know which node will be initialized first. And the code in arch_timer_common_init should wait until per-cpu timer and MMIO timer are both initialized. So we need arch_timer_needs_probing to detect the init status of system. But currently

[PATCH v19 12/15] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.

From: Fu Wei The patch update arm_arch_timer driver to use the function provided by the new GTDT driver of ACPI. By this way, arm_arch_timer.c can be simplified, and separate all the ACPI GTDT knowledge from this timer driver. Signed-off-by: Fu Wei Signed-off-by: Hanjun Guo Tested-by:

[PATCH v19 11/15] acpi/arm64: Add GTDT table parse driver

From: Fu Wei This patch adds support for parsing arch timer info in GTDT, provides some kernel APIs to parse all the PPIs and always-on info in GTDT and export them. By this driver, we can simplify arm_arch_timer drivers, and separate the ACPI GTDT knowledge from it. Signed-off-by: Fu Wei

[PATCH v19 13/15] acpi/arm64: Add memory-mapped timer support in GTDT driver

From: Fu Wei On platforms booting with ACPI, architected memory-mapped timers' configuration data is provided by firmware through the ACPI GTDT static table. The clocksource architected timer kernel driver requires a firmware interface to collect timer configuration and configure its driver.

[PATCH v19 08/15] clocksource/drivers/arm_arch_timer: move arch_timer_needs_of_probing into DT init call

From: Fu Wei Because arch_timer_needs_of_probing is only for booting with device-tree, but arch_timer_common_init is a generic init call which shouldn't include the FW-specific code. It's better to put arch_timer_needs_of_probing into DT init function. But for per-cpu timer,

[PATCH v19 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT

From: Fu Wei The patch refactor original memory-mapped timer init code: (1) Refactor "arch_timer_mem_init", make it become a common code for memory-mapped timer init. (2) Add a new function "arch_timer_mem_of_init" for DT init. Signed-off-by: Fu Wei

[PATCH v19 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT

From: Fu Wei The patch refactor original memory-mapped timer init code: (1) Refactor "arch_timer_mem_init", make it become a common code for memory-mapped timer init. (2) Add a new function "arch_timer_mem_of_init" for DT init. Signed-off-by: Fu Wei ---

[PATCH v19 08/15] clocksource/drivers/arm_arch_timer: move arch_timer_needs_of_probing into DT init call

From: Fu Wei Because arch_timer_needs_of_probing is only for booting with device-tree, but arch_timer_common_init is a generic init call which shouldn't include the FW-specific code. It's better to put arch_timer_needs_of_probing into DT init function. But for per-cpu timer, the

[PATCH v19 04/15] clocksource/drivers/arm_arch_timer: rename some enums and defines.

From: Fu Wei Rename some enums and defines, to unify the format of enums and defines in arm_arch_timer.h, also update all the users of these enums and defines: drivers/clocksource/arm_arch_timer.c virt/kvm/arm/hyp/timer-sr.c No functional change. Signed-off-by: Fu

[PATCH v19 04/15] clocksource/drivers/arm_arch_timer: rename some enums and defines.

From: Fu Wei Rename some enums and defines, to unify the format of enums and defines in arm_arch_timer.h, also update all the users of these enums and defines: drivers/clocksource/arm_arch_timer.c virt/kvm/arm/hyp/timer-sr.c No functional change. Signed-off-by: Fu Wei Tested-by:

[PATCH v19 03/15] clocksource/drivers/arm_arch_timer: Improve printk relevant code

From: Fu Wei This patch defines pr_fmt(fmt) for all pr_* functions, then the pr_* doesn't need to add "arch_timer:" everytime. According to the suggestion from checkpatch.pl: (1) delete some Blank Spaces in arch_timer_banner; (2) delete a redundant Tab in a bland line of

[PATCH v19 05/15] clocksource/drivers/arm_arch_timer: rework PPI determination

From: Fu Wei Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to mean the driver will use the secure PPI *and* potentialy also use the non-secure PPI. This is somewhat confusing. For arm64, where it never makes sense to use the secure PPI, this means we must

[PATCH v19 06/15] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

From: Fu Wei Currently, the counter frequency detection call(arch_timer_detect_rate) combines all the ways to get counter frequency: device-tree property, system coprocessor register, MMIO timer. But in the most of use cases, we don't need all the ways to try: For example,

[PATCH v19 01/15] clocksource/drivers/arm_arch_timer: Move enums and defines to header file

From: Fu Wei To support the arm_arch_timer via ACPI we need to share defines and enums between the driver and the ACPI parser code. Split out the relevant defines and enums into arm_arch_timer.h, and change "enum ppi_nr" to "enum arch_timer_ppi_nr" to avoid the potential name

[PATCH v19 02/15] clocksource/drivers/arm_arch_timer: Add a new enum for spi type

From: Fu Wei This patch add a new enum "arch_timer_spi_nr" and use it in the driver. Just for code's readability, no functional change. Signed-off-by: Fu Wei Acked-by: Mark Rutland --- drivers/clocksource/arm_arch_timer.c | 4 ++--

[PATCH v19 06/15] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

From: Fu Wei Currently, the counter frequency detection call(arch_timer_detect_rate) combines all the ways to get counter frequency: device-tree property, system coprocessor register, MMIO timer. But in the most of use cases, we don't need all the ways to try: For example, reading device-tree

[PATCH v19 01/15] clocksource/drivers/arm_arch_timer: Move enums and defines to header file

From: Fu Wei To support the arm_arch_timer via ACPI we need to share defines and enums between the driver and the ACPI parser code. Split out the relevant defines and enums into arm_arch_timer.h, and change "enum ppi_nr" to "enum arch_timer_ppi_nr" to avoid the potential name clashes. Also

[PATCH v19 02/15] clocksource/drivers/arm_arch_timer: Add a new enum for spi type

From: Fu Wei This patch add a new enum "arch_timer_spi_nr" and use it in the driver. Just for code's readability, no functional change. Signed-off-by: Fu Wei Acked-by: Mark Rutland --- drivers/clocksource/arm_arch_timer.c | 4 ++-- include/clocksource/arm_arch_timer.h | 6 ++ 2 files

[PATCH v19 03/15] clocksource/drivers/arm_arch_timer: Improve printk relevant code

From: Fu Wei This patch defines pr_fmt(fmt) for all pr_* functions, then the pr_* doesn't need to add "arch_timer:" everytime. According to the suggestion from checkpatch.pl: (1) delete some Blank Spaces in arch_timer_banner; (2) delete a redundant Tab in a bland line of arch_timer_init(void)

[PATCH v19 05/15] clocksource/drivers/arm_arch_timer: rework PPI determination

From: Fu Wei Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to mean the driver will use the secure PPI *and* potentialy also use the non-secure PPI. This is somewhat confusing. For arm64, where it never makes sense to use the secure PPI, this means we must always request the

[PATCH v19 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

From: Fu Wei This patchset: (1)Preparation for adding GTDT support in arm_arch_timer: 1. Move some enums and marcos to header file; 2. Add a new enum for spi type; 3. Improve printk relevant code; 4. Rename some enums and defines; 5.

[PATCH v19 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

From: Fu Wei This patchset: (1)Preparation for adding GTDT support in arm_arch_timer: 1. Move some enums and marcos to header file; 2. Add a new enum for spi type; 3. Improve printk relevant code; 4. Rename some enums and defines; 5. Rework PPI

  1   2   3   4   5   6   7   8   9   10   >