[Regression?] iptables broken on 32bit with pre-4.7-rc

Hey Florian, Pablo, In updating a 32bit arm device from 4.6 to Linus' current HEAD, I noticed I was having some trouble with networking, and realized that /proc/net/ip_tables_names was suddenly empty. Digging through the registration process, it seems we're catching on the: if

[Regression?] iptables broken on 32bit with pre-4.7-rc

Hey Florian, Pablo, In updating a 32bit arm device from 4.6 to Linus' current HEAD, I noticed I was having some trouble with networking, and realized that /proc/net/ip_tables_names was suddenly empty. Digging through the registration process, it seems we're catching on the: if

Re: [PATCH 0/2] arm: dra7: Add i2c6 instance hwmod and dt entries

On 25/05/16 19:09, Nishanth Menon wrote: On 05/25/2016 07:53 AM, Ravikumar Kattekola wrote: DRA72x devices have a sixth i2c ocntroller instance. Following patches add the required hwmod structure and device tree nodes. Reference doc: DRA72x TRM [ SPRUHP2Q ] Tested on : DRA72x Rev B EVM

Re: [PATCH 0/2] arm: dra7: Add i2c6 instance hwmod and dt entries

On 25/05/16 19:09, Nishanth Menon wrote: On 05/25/2016 07:53 AM, Ravikumar Kattekola wrote: DRA72x devices have a sixth i2c ocntroller instance. Following patches add the required hwmod structure and device tree nodes. Reference doc: DRA72x TRM [ SPRUHP2Q ] Tested on : DRA72x Rev B EVM

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/25/16, Jani Nikula wrote: > On Wed, 25 May 2016, Sedat Dilek wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel SandyBridge GPU... >> >> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] >> *ERROR* CPU

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/25/16, Jani Nikula wrote: > On Wed, 25 May 2016, Sedat Dilek wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel SandyBridge GPU... >> >> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] >> *ERROR* CPU pipe A FIFO underrun >> [ 17.630652]

Re: [PATCH] ACPI / Thermal / video: fix max_level incorrect value

On 05/26/2016 09:49 AM, valdis.kletni...@vt.edu wrote: > On Wed, 25 May 2016 13:15:26 +0800, Aaron Lu said: >> Valdis, can you please give the patch a try? Thanks. > > Sorry, had a few days where actual work commitments and other > things got in the way... I tested this patch against

Re: [PATCH] ACPI / Thermal / video: fix max_level incorrect value

On 05/26/2016 09:49 AM, valdis.kletni...@vt.edu wrote: > On Wed, 25 May 2016 13:15:26 +0800, Aaron Lu said: >> Valdis, can you please give the patch a try? Thanks. > > Sorry, had a few days where actual work commitments and other > things got in the way... I tested this patch against

[PATCH] mm/cma: silence warnings due to max() usage

pageblock_order can be (at least) an unsigned int or an unsigned long depending on the kernel config and architecture, so use max_t(unsigned long, ...) when comparing it. fixes these warnings: In file included from include/asm-generic/bug.h:13:0, from

[PATCH] mm/cma: silence warnings due to max() usage

pageblock_order can be (at least) an unsigned int or an unsigned long depending on the kernel config and architecture, so use max_t(unsigned long, ...) when comparing it. fixes these warnings: In file included from include/asm-generic/bug.h:13:0, from

Re: [PATCH 2/2] staging: dgnc: remove redundant null check in

2016-05-26 7:00 GMT+09:00 Luis de Bethencourt : > On 20/05/16 10:51, Daeseok Youn wrote: >> the "brd" was already checked for NULL before calling dgnc_do_remap(). >> >> Signed-off-by: Daeseok Youn >> --- >> drivers/staging/dgnc/dgnc_driver.c | 3

Re: [PATCH] cpufreq: stats: Make the stats code non-modular

On 26-05-16, 00:23, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The modularity of cpufreq_stats is quite problematic. > > First off, the usage of policy notifiers for the initialization > and cleanup in the cpufreq_stats module is inherently racy with >

Re: [PATCH 2/2] staging: dgnc: remove redundant null check in

2016-05-26 7:00 GMT+09:00 Luis de Bethencourt : > On 20/05/16 10:51, Daeseok Youn wrote: >> the "brd" was already checked for NULL before calling dgnc_do_remap(). >> >> Signed-off-by: Daeseok Youn >> --- >> drivers/staging/dgnc/dgnc_driver.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff

Re: [PATCH] cpufreq: stats: Make the stats code non-modular

On 26-05-16, 00:23, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The modularity of cpufreq_stats is quite problematic. > > First off, the usage of policy notifiers for the initialization > and cleanup in the cpufreq_stats module is inherently racy with > respect to CPU offline/online

[PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

When handling the endpoint interrupt handler, it maybe disable the endpoint from another core user to set the USB endpoint descriptor pointor to be NULL while issuing usb_gadget_giveback_request() function to release lock. So it will be one bug to check the endpoint type by usb_endpoint_xfer_xxx()

[PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

When handling the endpoint interrupt handler, it maybe disable the endpoint from another core user to set the USB endpoint descriptor pointor to be NULL while issuing usb_gadget_giveback_request() function to release lock. So it will be one bug to check the endpoint type by usb_endpoint_xfer_xxx()

Re: [PATCH 1/2] staging: dgnc: remove redundant NULL check for brd

2016-05-26 6:48 GMT+09:00 Luis de Bethencourt : > On 20/05/16 10:51, Daeseok Youn wrote: >> the "brd" value cannot be NULL in dgnc_finalize_board_init(). >> Because "brd" as a parameter of this function was already >> checked for NULL. >> >> Signed-off-by: Daeseok Youn

Re: [PATCH 1/2] staging: dgnc: remove redundant NULL check for brd

2016-05-26 6:48 GMT+09:00 Luis de Bethencourt : > On 20/05/16 10:51, Daeseok Youn wrote: >> the "brd" value cannot be NULL in dgnc_finalize_board_init(). >> Because "brd" as a parameter of this function was already >> checked for NULL. >> >> Signed-off-by: Daeseok Youn >> --- >>

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On Tue 24 May 12:54 PDT 2016, Neil Leeder wrote: > > > On 5/24/2016 07:23 AM, Mark Rutland wrote: > > On Mon, May 23, 2016 at 02:22:59PM -0400, Neil Leeder wrote: > >> > >> On 5/23/2016 01:25 PM, Mark Rutland wrote: > >>> On Fri, May 20, 2016 at 03:13:07PM -0400, Neil Leeder wrote: > >

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On Tue 24 May 12:54 PDT 2016, Neil Leeder wrote: > > > On 5/24/2016 07:23 AM, Mark Rutland wrote: > > On Mon, May 23, 2016 at 02:22:59PM -0400, Neil Leeder wrote: > >> > >> On 5/23/2016 01:25 PM, Mark Rutland wrote: > >>> On Fri, May 20, 2016 at 03:13:07PM -0400, Neil Leeder wrote: > >

Re: [PATCH v6 11/12] zsmalloc: page migration support

On Thu, May 26, 2016 at 09:59:26AM +0900, Sergey Senozhatsky wrote: > btw, I've uploaded zram-fio test script to > https://github.com/sergey-senozhatsky/zram-perf-test > > it's very minimalistic and half baked, but can be used > to some degree. open to patches, improvements, etc. Awesome!

Re: [PATCH v6 11/12] zsmalloc: page migration support

On Thu, May 26, 2016 at 09:59:26AM +0900, Sergey Senozhatsky wrote: > btw, I've uploaded zram-fio test script to > https://github.com/sergey-senozhatsky/zram-perf-test > > it's very minimalistic and half baked, but can be used > to some degree. open to patches, improvements, etc. Awesome!

Re: [PATCH] f2fs: Return the errno to the caller to avoid using a wrong page

Forget this wrong version, I have re-sent a patch v2 version. -- Thanks, Yunlong Song

Re: [PATCH] f2fs: Return the errno to the caller to avoid using a wrong page

Forget this wrong version, I have re-sent a patch v2 version. -- Thanks, Yunlong Song

[PATCH v2] f2fs: Return the errno to the caller to avoid using a wrong page

Commit aaf9607516ed38825268515ef4d773289a44f429 ("f2fs: check node page contents all the time") pointed out that "sometimes it was reported that its contents was missing", so it checks the page's mapping and contents. When "nid != nid_of_node(page)", ERR_PTR(-EIO) will be returned to the caller.

[PATCH v2] f2fs: Return the errno to the caller to avoid using a wrong page

Commit aaf9607516ed38825268515ef4d773289a44f429 ("f2fs: check node page contents all the time") pointed out that "sometimes it was reported that its contents was missing", so it checks the page's mapping and contents. When "nid != nid_of_node(page)", ERR_PTR(-EIO) will be returned to the caller.

[PATCH] f2fs: Return the errno to the caller to avoid using a wrong page

Commit aaf9607516ed38825268515ef4d773289a44f429 ("f2fs: check node page contents all the time") pointed out that "sometimes it was reported that its contents was missing", so it checks the page's mapping and contents. When "nid != nid_of_node(page)", ERR_PTR(-EIO) will be returned to the caller.

[PATCH] f2fs: Return the errno to the caller to avoid using a wrong page

Commit aaf9607516ed38825268515ef4d773289a44f429 ("f2fs: check node page contents all the time") pointed out that "sometimes it was reported that its contents was missing", so it checks the page's mapping and contents. When "nid != nid_of_node(page)", ERR_PTR(-EIO) will be returned to the caller.

linux-next: Tree for May 26

Hi all, Please do not add any v4.8 destined material to your linux-next included branches until after v4.7-rc1 has been released. Changes since 20160525: Non-merge commits (relative to Linus' tree): 1019 884 files changed, 34784 insertions(+), 11132 deletions

linux-next: Tree for May 26

Hi all, Please do not add any v4.8 destined material to your linux-next included branches until after v4.7-rc1 has been released. Changes since 20160525: Non-merge commits (relative to Linus' tree): 1019 884 files changed, 34784 insertions(+), 11132 deletions

Re: [PATCH v3 1/5] thermal: Add support for hardware-tracked trip points

On 2016年05月26日 08:34, Caesar Wang wrote: On 2016年05月26日 00:42, Javi Merino wrote: Hi Caesar, On Wed, May 25, 2016 at 11:47:45AM +0800, Caesar Wang wrote: From: Sascha Hauer This adds support for hardware-tracked trip points to the device tree thermal sensor

Re: [PATCH v3 1/5] thermal: Add support for hardware-tracked trip points

On 2016年05月26日 08:34, Caesar Wang wrote: On 2016年05月26日 00:42, Javi Merino wrote: Hi Caesar, On Wed, May 25, 2016 at 11:47:45AM +0800, Caesar Wang wrote: From: Sascha Hauer This adds support for hardware-tracked trip points to the device tree thermal sensor framework. The framework

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

在 2016/5/26 11:59, Jaehoon Chung 写道: On 05/26/2016 11:23 AM, Shawn Lin wrote: Hi Jaehoon, On 2016/5/19 21:07, Jaehoon Chung wrote: On 05/19/2016 08:31 PM, Shawn Lin wrote: Hi, On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

在 2016/5/26 11:59, Jaehoon Chung 写道: On 05/26/2016 11:23 AM, Shawn Lin wrote: Hi Jaehoon, On 2016/5/19 21:07, Jaehoon Chung wrote: On 05/19/2016 08:31 PM, Shawn Lin wrote: Hi, On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: Hi On 2016-5-18

RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

Hi Uffe, Could we merge this patchset? ... It has been a long time to wait for Arnd's response... Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Yangbo Lu > Sent: Friday, May 20, 2016 2:06 PM > To: 'Scott Wood'; Arnd Bergmann; linux-arm-ker...@lists.infradead.org

RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

Hi Uffe, Could we merge this patchset? ... It has been a long time to wait for Arnd's response... Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Yangbo Lu > Sent: Friday, May 20, 2016 2:06 PM > To: 'Scott Wood'; Arnd Bergmann; linux-arm-ker...@lists.infradead.org

Re: [PATCH 1/2] arm: dra7: Add hwmod entry for i2c6

On Wednesday 25 May 2016 06:23 PM, Ravikumar Kattekola wrote: > dra72x device has i2c6 controller. > Adding hwmod definition for the same. > > Reference DRA72x TRM [ SPRUHP2Q ] > > Signed-off-by: Ravikumar Kattekola > --- > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23

Re: [PATCH 1/2] arm: dra7: Add hwmod entry for i2c6

On Wednesday 25 May 2016 06:23 PM, Ravikumar Kattekola wrote: > dra72x device has i2c6 controller. > Adding hwmod definition for the same. > > Reference DRA72x TRM [ SPRUHP2Q ] > > Signed-off-by: Ravikumar Kattekola > --- > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

On 05/26/2016 11:23 AM, Shawn Lin wrote: > Hi Jaehoon, > > On 2016/5/19 21:07, Jaehoon Chung wrote: >> On 05/19/2016 08:31 PM, Shawn Lin wrote: >>> Hi, >>> >>> On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

On 05/26/2016 11:23 AM, Shawn Lin wrote: > Hi Jaehoon, > > On 2016/5/19 21:07, Jaehoon Chung wrote: >> On 05/19/2016 08:31 PM, Shawn Lin wrote: >>> Hi, >>> >>> On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: > Hi > >

Re: [PATCH 2/5] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping

On Wed, May 25, 2016 at 01:54:23PM +0800, Yongji Xie wrote: > On 2016/5/25 5:11, Bjorn Helgaas wrote: > >On Wed, Apr 27, 2016 at 08:43:27PM +0800, Yongji Xie wrote: > >>The capability of IRQ remapping is abstracted on IOMMU side on > >>some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for

Re: [PATCH 2/5] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping

On Wed, May 25, 2016 at 01:54:23PM +0800, Yongji Xie wrote: > On 2016/5/25 5:11, Bjorn Helgaas wrote: > >On Wed, Apr 27, 2016 at 08:43:27PM +0800, Yongji Xie wrote: > >>The capability of IRQ remapping is abstracted on IOMMU side on > >>some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for

Re: [PATCHv3] support for AD5820 camera auto-focus coil

On 24.05.2016 23:20, Pavel Machek wrote: Hi! devm_regulator_get()? I'd rather avoid devm_ here. Driver is simple enough to allow it. Now thinking about it, what would happen here if regulator_get() returns -EPROBE_DEFER? Wouldn't it be better to move regulator_get to the probe()

Re: [PATCHv3] support for AD5820 camera auto-focus coil

On 24.05.2016 23:20, Pavel Machek wrote: Hi! devm_regulator_get()? I'd rather avoid devm_ here. Driver is simple enough to allow it. Now thinking about it, what would happen here if regulator_get() returns -EPROBE_DEFER? Wouldn't it be better to move regulator_get to the probe()

Re: [PATCH 1/1] arm64: fix flush_cache_range

On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >

Re: [PATCH 1/1] arm64: fix flush_cache_range

On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >

Re: ARM: dts: exynos: Add MFC memory banks for Peach boards

Hi Javier, On Wednesday 25 May 2016 08:32 PM, Javier Martinez Canillas wrote: > Hello Pankaj, > > On 05/25/2016 04:33 AM, pankaj.dubey wrote: >> Hi Javier, >> >>> Signed-off-by: Javier Martinez Canillas >> >> Just noticed that, current krzk/for-next failed to boot on

Re: ARM: dts: exynos: Add MFC memory banks for Peach boards

Hi Javier, On Wednesday 25 May 2016 08:32 PM, Javier Martinez Canillas wrote: > Hello Pankaj, > > On 05/25/2016 04:33 AM, pankaj.dubey wrote: >> Hi Javier, >> >>> Signed-off-by: Javier Martinez Canillas >> >> Just noticed that, current krzk/for-next failed to boot on Exynos5880 >> based

[PATCH] fs: Do not check for valid page->mapping in page_cache_pipe_buf_confirm

If the page is truncated after being spliced into the pipe, it's probably not invalid. For filesystems that invalidate pages, we used to return -ENODATA even though the data is there, it's just possibly different from what was spliced into the pipe. We shouldn't have to throw away the buffer or

[PATCH] fs: Do not check for valid page->mapping in page_cache_pipe_buf_confirm

If the page is truncated after being spliced into the pipe, it's probably not invalid. For filesystems that invalidate pages, we used to return -ENODATA even though the data is there, it's just possibly different from what was spliced into the pipe. We shouldn't have to throw away the buffer or

Re: [PATCH 1/2] Revert "mtd: atmel_nand: Support variable RB_EDGE interrupts"

Hi, On Mon, May 09, 2016 at 02:51:18PM +0800, Wenyou Yang wrote: > This reverts commit 5ddc7bd43ccc ("mtd: atmel_nand: Support variable > RB_EDGE interrupts") > > Because for current SoCs, the RB_EDGE3(i.e. bit 27) of HSMC_SR > register does not exist, the RB_EDGE0 (i.e. bit 24) is the

Re: [PATCH 1/2] Revert "mtd: atmel_nand: Support variable RB_EDGE interrupts"

Hi, On Mon, May 09, 2016 at 02:51:18PM +0800, Wenyou Yang wrote: > This reverts commit 5ddc7bd43ccc ("mtd: atmel_nand: Support variable > RB_EDGE interrupts") > > Because for current SoCs, the RB_EDGE3(i.e. bit 27) of HSMC_SR > register does not exist, the RB_EDGE0 (i.e. bit 24) is the

Re: [PATCH 1/2] Revert "mtd: atmel_nand: Support variable RB_EDGE interrupts"

Hi, On Mon, May 23, 2016 at 09:55:57AM +0200, Boris Brezillon wrote: > On Mon, 9 May 2016 14:51:18 +0800 > Wenyou Yang wrote: > > > This reverts commit 5ddc7bd43ccc ("mtd: atmel_nand: Support variable > > RB_EDGE interrupts") > > > > Because for current SoCs, the

Re: [PATCH 1/2] Revert "mtd: atmel_nand: Support variable RB_EDGE interrupts"

Hi, On Mon, May 23, 2016 at 09:55:57AM +0200, Boris Brezillon wrote: > On Mon, 9 May 2016 14:51:18 +0800 > Wenyou Yang wrote: > > > This reverts commit 5ddc7bd43ccc ("mtd: atmel_nand: Support variable > > RB_EDGE interrupts") > > > > Because for current SoCs, the RB_EDGE3(i.e. bit 27) of

[RFC PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

dw_mci_get_cd have already dealed with these for both of internal card-detect and gpio card-detect. Signed-off-by: Shawn Lin --- drivers/mmc/host/dw_mmc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c

[RFC PATCH 2/2] mmc: dw_mmc: check card present before starting request

The main reason to add this check is to avoid unnecessary mmc_request if the card is removed. Although we have already check this in dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot for noremovable devices, but there is a timing gap before it really calls dw_mci_get_cd as

[RFC PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

dw_mci_get_cd have already dealed with these for both of internal card-detect and gpio card-detect. Signed-off-by: Shawn Lin --- drivers/mmc/host/dw_mmc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index

[RFC PATCH 2/2] mmc: dw_mmc: check card present before starting request

The main reason to add this check is to avoid unnecessary mmc_request if the card is removed. Although we have already check this in dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot for noremovable devices, but there is a timing gap before it really calls dw_mci_get_cd as

[PATCH v2 1/3] cpufreq: add resolve_freq driver callback

Cpufreq governors may need to know what a particular target frequency maps to in the driver without necessarily wanting to set the frequency. Support this operation via a new cpufreq API, cpufreq_driver_resolve_freq(). The above API will call a new cpufreq driver callback, resolve_freq(), if it

[PATCH v2 1/3] cpufreq: add resolve_freq driver callback

Cpufreq governors may need to know what a particular target frequency maps to in the driver without necessarily wanting to set the frequency. Support this operation via a new cpufreq API, cpufreq_driver_resolve_freq(). The above API will call a new cpufreq driver callback, resolve_freq(), if it

[PATCH v2 0/3] cpufreq: avoid redundant driver calls in schedutil

In the series [0] I included a patch which attempted to avoid redundant driver calls in the schedutil governor by mapping the raw required CPU frequencies to driver frequencies. This vastly increases the likelihood of detecting a redundant cpufreq driver call, i.e. one which will end up attempting

[PATCH v2 2/3] cpufreq: acpi-cpufreq: add resolve_freq callback

Support the new resolve_freq cpufreq callback which resolves a target frequency to a driver-supported frequency without actually setting it. The target frequency and resolved frequency table entry are cached so that a subsequent fast_switch operation may avoid the frequency table walk assuming

[PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

The slow-path frequency transition path is relatively expensive as it requires waking up a thread to do work. Should support be added for remote CPU cpufreq updates that is also expensive since it requires an IPI. These activities should be avoided if they are not necessary. To that end,

[PATCH v2 0/3] cpufreq: avoid redundant driver calls in schedutil

In the series [0] I included a patch which attempted to avoid redundant driver calls in the schedutil governor by mapping the raw required CPU frequencies to driver frequencies. This vastly increases the likelihood of detecting a redundant cpufreq driver call, i.e. one which will end up attempting

[PATCH v2 2/3] cpufreq: acpi-cpufreq: add resolve_freq callback

Support the new resolve_freq cpufreq callback which resolves a target frequency to a driver-supported frequency without actually setting it. The target frequency and resolved frequency table entry are cached so that a subsequent fast_switch operation may avoid the frequency table walk assuming

[PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

The slow-path frequency transition path is relatively expensive as it requires waking up a thread to do work. Should support be added for remote CPU cpufreq updates that is also expensive since it requires an IPI. These activities should be avoided if they are not necessary. To that end,

[PATCH 1/3] of/numa: remove a duplicated pr_debug information

This information will be printed in the subfunction numa_add_memblk. They are not the same, but very similar. Signed-off-by: Zhen Lei --- drivers/of/of_numa.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c index

[PATCH 1/3] of/numa: remove a duplicated pr_debug information

This information will be printed in the subfunction numa_add_memblk. They are not the same, but very similar. Signed-off-by: Zhen Lei --- drivers/of/of_numa.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c index 0f2784b..21d831f 100644 ---

[PATCH 3/3] arm64/numa: fix type info

numa_init(of_numa_init) may returned error because of numa configuration error. So "No NUMA configuration found" is inaccurate. In fact, specific configuration error information can be immediately printed by the testing branch. So "No NUMA..." only needs to be printed when numa_off.

[PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

For a normal memory@ devicetree node, its reg property can contains more memory blocks. Because we don't known how many memory blocks maybe contained, so we try from index=0, increase 1 until error returned(the end). Signed-off-by: Zhen Lei --- drivers/of/of_numa.c

[PATCH 3/3] arm64/numa: fix type info

numa_init(of_numa_init) may returned error because of numa configuration error. So "No NUMA configuration found" is inaccurate. In fact, specific configuration error information can be immediately printed by the testing branch. So "No NUMA..." only needs to be printed when numa_off.

[PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

For a normal memory@ devicetree node, its reg property can contains more memory blocks. Because we don't known how many memory blocks maybe contained, so we try from index=0, increase 1 until error returned(the end). Signed-off-by: Zhen Lei --- drivers/of/of_numa.c | 30

Re: dma-buf/sync_file: de-stage sync_file

On Sat, May 21, 2016 at 05:31:53AM +, Linux Kernel wrote: > dma-buf/sync_file: de-stage sync_file > > sync_file is useful to connect one or more fences to the file. The file > is > used by userspace to track fences between drivers that share DMA bufs. > >

Re: dma-buf/sync_file: de-stage sync_file

On Sat, May 21, 2016 at 05:31:53AM +, Linux Kernel wrote: > dma-buf/sync_file: de-stage sync_file > > sync_file is useful to connect one or more fences to the file. The file > is > used by userspace to track fences between drivers that share DMA bufs. > >

[PATCH v2 2/7] mm/page_owner: initialize page owner without holding the zone lock

From: Joonsoo Kim It's not necessary to initialized page_owner with holding the zone lock. It would cause more contention on the zone lock although it's not a big problem since it is just debug feature. But, it is better than before so do it. This is also preparation step

[PATCH v2 4/7] mm/page_owner: introduce split_page_owner and replace manual handling

From: Joonsoo Kim split_page() calls set_page_owner() to set up page_owner to each pages. But, it has a drawback that head page and the others have different stacktrace because callsite of set_page_owner() is slightly differnt. To avoid this problem, this patch copies

[PATCH v2 2/7] mm/page_owner: initialize page owner without holding the zone lock

From: Joonsoo Kim It's not necessary to initialized page_owner with holding the zone lock. It would cause more contention on the zone lock although it's not a big problem since it is just debug feature. But, it is better than before so do it. This is also preparation step to use stackdepot in

[PATCH v2 4/7] mm/page_owner: introduce split_page_owner and replace manual handling

From: Joonsoo Kim split_page() calls set_page_owner() to set up page_owner to each pages. But, it has a drawback that head page and the others have different stacktrace because callsite of set_page_owner() is slightly differnt. To avoid this problem, this patch copies head page's page_owner to

[PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace

From: Joonsoo Kim Currently, we store each page's allocation stacktrace on corresponding page_ext structure and it requires a lot of memory. This causes the problem that memory tight system doesn't work well if page_owner is enabled. Moreover, even with this large memory

[PATCH v2 7/7] mm/page_alloc: introduce post allocation processing on page allocator

From: Joonsoo Kim This patch is motivated from Hugh and Vlastimil's concern [1]. There are two ways to get freepage from the allocator. One is using normal memory allocation API and the other is __isolate_free_page() which is internally used for compaction and pageblock

[PATCH v2 3/7] mm/page_owner: copy last_migrate_reason in copy_page_owner()

From: Joonsoo Kim Currently, copy_page_owner() doesn't copy all the owner information. It skips last_migrate_reason because copy_page_owner() is used for migration and it will be properly set soon. But, following patch will use copy_page_owner() and this skip will cause

[PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace

From: Joonsoo Kim Currently, we store each page's allocation stacktrace on corresponding page_ext structure and it requires a lot of memory. This causes the problem that memory tight system doesn't work well if page_owner is enabled. Moreover, even with this large memory consumption, we cannot

[PATCH v2 7/7] mm/page_alloc: introduce post allocation processing on page allocator

From: Joonsoo Kim This patch is motivated from Hugh and Vlastimil's concern [1]. There are two ways to get freepage from the allocator. One is using normal memory allocation API and the other is __isolate_free_page() which is internally used for compaction and pageblock isolation. Later usage

[PATCH v2 3/7] mm/page_owner: copy last_migrate_reason in copy_page_owner()

From: Joonsoo Kim Currently, copy_page_owner() doesn't copy all the owner information. It skips last_migrate_reason because copy_page_owner() is used for migration and it will be properly set soon. But, following patch will use copy_page_owner() and this skip will cause the problem that

[PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock

From: Joonsoo Kim We don't need to split freepages with holding the zone lock. It will cause more contention on zone lock so not desirable. Signed-off-by: Joonsoo Kim --- include/linux/mm.h | 1 - mm/compaction.c| 42

[PATCH v2 5/7] tools/vm/page_owner: increase temporary buffer size

From: Joonsoo Kim Page owner will be changed to store more deep stacktrace so current temporary buffer size isn't enough. Increase it. Signed-off-by: Joonsoo Kim --- tools/vm/page_owner_sort.c | 9 +++-- 1 file changed, 7 insertions(+), 2

[PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock

From: Joonsoo Kim We don't need to split freepages with holding the zone lock. It will cause more contention on zone lock so not desirable. Signed-off-by: Joonsoo Kim --- include/linux/mm.h | 1 - mm/compaction.c| 42 ++ mm/page_alloc.c| 27

[PATCH v2 5/7] tools/vm/page_owner: increase temporary buffer size

From: Joonsoo Kim Page owner will be changed to store more deep stacktrace so current temporary buffer size isn't enough. Increase it. Signed-off-by: Joonsoo Kim --- tools/vm/page_owner_sort.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] MAINTAINERS: Kdump maintainers update

Hi, Vivek On 05/25/16 at 09:37am, Vivek Goyal wrote: > On Wed, May 25, 2016 at 06:24:10AM -0700, Joe Perches wrote: > > On Wed, 2016-05-25 at 09:16 -0400, Vivek Goyal wrote: > > > I am proposing following updates to kdump maintainership. I have got > > > busy in other things and not getting time

Re: [PATCH] MAINTAINERS: Kdump maintainers update

Hi, Vivek On 05/25/16 at 09:37am, Vivek Goyal wrote: > On Wed, May 25, 2016 at 06:24:10AM -0700, Joe Perches wrote: > > On Wed, 2016-05-25 at 09:16 -0400, Vivek Goyal wrote: > > > I am proposing following updates to kdump maintainership. I have got > > > busy in other things and not getting time

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

Hi Jaehoon, On 2016/5/19 21:07, Jaehoon Chung wrote: On 05/19/2016 08:31 PM, Shawn Lin wrote: Hi, On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: Hi On 2016-5-18 12:12, Doug Anderson wrote: Hi, On Tue, May 17,

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

Hi Jaehoon, On 2016/5/19 21:07, Jaehoon Chung wrote: On 05/19/2016 08:31 PM, Shawn Lin wrote: Hi, On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: Hi On 2016-5-18 12:12, Doug Anderson wrote: Hi, On Tue, May 17, 2016 at 6:59 PM, Shawn Lin

RE: [PATCH] usb: core: add debugobjects support for urb object

> On Tue, May 24, 2016 at 03:53:53PM +0800, changbin...@intel.com wrote: > > From: "Du, Changbin" > > > > Add debugobject support to track the life time of struct urb. > > This feature help us detect violation of urb operations by > > generating a warning message from

RE: [PATCH] usb: core: add debugobjects support for urb object

> On Tue, May 24, 2016 at 03:53:53PM +0800, changbin...@intel.com wrote: > > From: "Du, Changbin" > > > > Add debugobject support to track the life time of struct urb. > > This feature help us detect violation of urb operations by > > generating a warning message from debugobject core. And we fix

Re: [PATCH] MAINTAINERS: Kdump maintainers update

On Wed, May 25, 2016 at 09:37:13AM -0400, Vivek Goyal wrote: > On Wed, May 25, 2016 at 06:24:10AM -0700, Joe Perches wrote: > > On Wed, 2016-05-25 at 09:16 -0400, Vivek Goyal wrote: > > > I am proposing following updates to kdump maintainership. I have got > > > busy in other things and not

Re: [PATCH] MAINTAINERS: Kdump maintainers update

On Wed, May 25, 2016 at 09:37:13AM -0400, Vivek Goyal wrote: > On Wed, May 25, 2016 at 06:24:10AM -0700, Joe Perches wrote: > > On Wed, 2016-05-25 at 09:16 -0400, Vivek Goyal wrote: > > > I am proposing following updates to kdump maintainership. I have got > > > busy in other things and not

[PATCH] brcmfmac: rework function picking free BSS index

The old implementation was overcomplicated and slightly bugged in some corner cases. Consider following state of BSS-es (limited to 6 for simplification): drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, } drvr->iflist[1]: (null) drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }

[PATCH] brcmfmac: rework function picking free BSS index

The old implementation was overcomplicated and slightly bugged in some corner cases. Consider following state of BSS-es (limited to 6 for simplification): drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, } drvr->iflist[1]: (null) drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }

[PATCH] Revert "platform/chrome: chromeos_laptop: Add Leon Touch"

This reverts commit bff3c624dc7261a084a4d25a0b09c3fb0fec872a. Board "Leon" is otherwise known as "Toshiba CB35" and we already have the entry that supports that board as of this commit : 963cb6f platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch Remove this duplicate. Signed-off-by:

[PATCH] Revert "platform/chrome: chromeos_laptop: Add Leon Touch"

This reverts commit bff3c624dc7261a084a4d25a0b09c3fb0fec872a. Board "Leon" is otherwise known as "Toshiba CB35" and we already have the entry that supports that board as of this commit : 963cb6f platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch Remove this duplicate. Signed-off-by:

  1   2   3   4   5   6   7   8   9   10   >