Re: [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input

Hi Jacopo, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [cannot apply to renesas/next v4.17-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input

Hi Jacopo, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [cannot apply to renesas/next v4.17-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] cpuidle/powernv : init all present cpus for deep states

Yes this needs to be sent to stable. Fixes: d405a98c ("powerpc/powernv: Move cpuidle related code from setup.c to new file")

Re: [PATCH] cpuidle/powernv : init all present cpus for deep states

Yes this needs to be sent to stable. Fixes: d405a98c ("powerpc/powernv: Move cpuidle related code from setup.c to new file")

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote: >Hi Chao, > >On 05/17/18 at 11:27am, Chao Fan wrote: >> >+/* Store the number of 1GB huge pages which user specified.*/ >> >+static unsigned long max_gb_huge_pages; >> >+ >> >+static int parse_gb_huge_pages(char *param, char* val) >> >+{

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote: >Hi Chao, > >On 05/17/18 at 11:27am, Chao Fan wrote: >> >+/* Store the number of 1GB huge pages which user specified.*/ >> >+static unsigned long max_gb_huge_pages; >> >+ >> >+static int parse_gb_huge_pages(char *param, char* val) >> >+{

[PATCH v7 0/6] provide power off support for iMX6 with external PMIC

2018.05.17: update patches to version v7 This patch series is providing power off support for Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). As a first step the PMIC is configured to turn off the system if the standby pin is asserted. On second step we

[PATCH v7 0/6] provide power off support for iMX6 with external PMIC

2018.05.17: update patches to version v7 This patch series is providing power off support for Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). As a first step the PMIC is configured to turn off the system if the standby pin is asserted. On second step we

[PATCH v7 6/6] ARM: dts: imx6: RIoTboard provide standby on power off option

This board, as well as some other boards with i.MX6 and a PMIC, uses a "PMIC_STBY_REQ" line to notify the PMIC about a state change. The PMIC is programmed for a specific state change before triggering the line. In this case, PMIC_STBY_REQ can be used for stand by, sleep and power off modes.

[PATCH v7 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

One of the Freescale recommended sequences for power off with external PMIC is the following: ... 3. SoC is programming PMIC for power off when standby is asserted. 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies. See:

[PATCH v7 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property

Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt

[PATCH v7 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

One of the Freescale recommended sequences for power off with external PMIC is the following: ... 3. SoC is programming PMIC for power off when standby is asserted. 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies. See:

[PATCH v7 6/6] ARM: dts: imx6: RIoTboard provide standby on power off option

This board, as well as some other boards with i.MX6 and a PMIC, uses a "PMIC_STBY_REQ" line to notify the PMIC about a state change. The PMIC is programmed for a specific state change before triggering the line. In this case, PMIC_STBY_REQ can be used for stand by, sleep and power off modes.

[PATCH v7 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property

Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index

[PATCH v7 5/6] regulator: pfuze100-regulator: provide pm_power_off_prepare handler

On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC about state changes. In this case internal state of PMIC must be preconfigured for upcomming state change. It works fine with the current regulator framework, except with the power-off case. This patch is providing an

[PATCH v7 5/6] regulator: pfuze100-regulator: provide pm_power_off_prepare handler

On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC about state changes. In this case internal state of PMIC must be preconfigured for upcomming state change. It works fine with the current regulator framework, except with the power-off case. This patch is providing an

[PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare

Export pm_power_off_prepare. It is needed to implement power off on Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). Signed-off-by: Oleksij Rempel --- kernel/reboot.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v7 4/6] regulator: pfuze100: add fsl,pmic-stby-poweroff property

Document the new optional "fsl,pmic-stby-poweroff" property. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/regulator/pfuze100.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v7 4/6] regulator: pfuze100: add fsl,pmic-stby-poweroff property

Document the new optional "fsl,pmic-stby-poweroff" property. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/regulator/pfuze100.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt

[PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare

Export pm_power_off_prepare. It is needed to implement power off on Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). Signed-off-by: Oleksij Rempel --- kernel/reboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/reboot.c b/kernel/reboot.c

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

Russell King - ARM Linux writes: > On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: >> Hi Russell, >> >> On 10 May 2018 at 02:40, Russell King - ARM Linux >> wrote: >> > This does not leak information from other namespaces because

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

Russell King - ARM Linux writes: > On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: >> Hi Russell, >> >> On 10 May 2018 at 02:40, Russell King - ARM Linux >> wrote: >> > This does not leak information from other namespaces because of the >> > uniqueness of the global PID.

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

On 05/17/18 at 07:12am, damian wrote: > On Wed, 16. May 18:05, Baoquan He wrote: > > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to > > handle conflict between KASLR and huge pages, will be used in the next > > patch. > > > > Function parse_gb_huge_pages() is used

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

On 05/17/18 at 07:12am, damian wrote: > On Wed, 16. May 18:05, Baoquan He wrote: > > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to > > handle conflict between KASLR and huge pages, will be used in the next > > patch. > > > > Function parse_gb_huge_pages() is used

Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration

On 05/17/2018 12:08 AM, Dmitry Torokhov wrote: On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote: On 05/16/2018 08:15 PM, Dmitry Torokhov wrote: Hi Oleksandr, On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote: @@ -211,93 +220,114 @@ static int

Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration

On 05/17/2018 12:08 AM, Dmitry Torokhov wrote: On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote: On 05/16/2018 08:15 PM, Dmitry Torokhov wrote: Hi Oleksandr, On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote: @@ -211,93 +220,114 @@ static int

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

Christoph Hellwig writes: > On Sat, May 05, 2018 at 07:37:33AM -0500, Eric W. Biederman wrote: >> Christoph Hellwig writes: >> >> > The shole seq_file sequence already operates under a single RCU lock pair, >> > so move the pid namespace lookup into it, and stop

Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup

Christoph Hellwig writes: > On Sat, May 05, 2018 at 07:37:33AM -0500, Eric W. Biederman wrote: >> Christoph Hellwig writes: >> >> > The shole seq_file sequence already operates under a single RCU lock pair, >> > so move the pid namespace lookup into it, and stop grabbing a reference >> > and

Re: [linux-firmware] Version in WHENCE file

On Mon, 2018-05-07 at 09:47 +0200, Sedat Dilek wrote: > On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho com> wrote: > > On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote: > > > Hi Luca, > > > > > > I hope I catched the correct MLs (not sure if linux-firmware has > > > a

Re: [linux-firmware] Version in WHENCE file

On Mon, 2018-05-07 at 09:47 +0200, Sedat Dilek wrote: > On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho com> wrote: > > On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote: > > > Hi Luca, > > > > > > I hope I catched the correct MLs (not sure if linux-firmware has > > > a > > > ML, > > > I did

Re: [PATCH] dmaengine: qcom: bam_dma: check if the runtime pm enabled

On 14-05-18, 17:18, Srinivas Kandagatla wrote: > Disabling pm runtime at probe is not sufficient to get BAM working > on remotely controller instances. pm_runtime_get_sync() would return > -EACCES in such cases. > So check if runtime pm is enabled before returning error from bam functions. > >

Re: [PATCH] dmaengine: qcom: bam_dma: check if the runtime pm enabled

On 14-05-18, 17:18, Srinivas Kandagatla wrote: > Disabling pm runtime at probe is not sufficient to get BAM working > on remotely controller instances. pm_runtime_get_sync() would return > -EACCES in such cases. > So check if runtime pm is enabled before returning error from bam functions. > >

Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration

On 11-05-18, 21:06, Baolin Wang wrote: > +struct sprd_dma_config { > + struct dma_slave_config cfg; > + u32 block_len; > + u32 transcation_len; /s/transcation/transaction now in code I see block_len and this filled by len which is sg_dma_len()? So why two varibales when you are using

Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration

On 11-05-18, 21:06, Baolin Wang wrote: > +struct sprd_dma_config { > + struct dma_slave_config cfg; > + u32 block_len; > + u32 transcation_len; /s/transcation/transaction now in code I see block_len and this filled by len which is sg_dma_len()? So why two varibales when you are using

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

On Wed, 16. May 18:05, Baoquan He wrote: > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to > handle conflict between KASLR and huge pages, will be used in the next patch. > > Function parse_gb_huge_pages() is used to parse kernel command-line to get > how many 1GB

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

On Wed, 16. May 18:05, Baoquan He wrote: > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to > handle conflict between KASLR and huge pages, will be used in the next patch. > > Function parse_gb_huge_pages() is used to parse kernel command-line to get > how many 1GB

Re: Linux 4.16-rc1: regression bisected, Debian kernel package tool make-kpkg stalls indefinitely during kernel build due to commit "kconfig: remove check_stdin()"

On Tue, Feb 13, 2018 at 2:07 PM, Ulf Magnusson wrote: >> On Tue, Feb 13, 2018 at 12:33:24PM +0100, Ulf Magnusson wrote: >> Sander Eikelenboom wrote: >>> The Debian kernel-package tool make-kpkg for easy building of upstream >>> kernels on Debian fails with linux

Re: Linux 4.16-rc1: regression bisected, Debian kernel package tool make-kpkg stalls indefinitely during kernel build due to commit "kconfig: remove check_stdin()"

On Tue, Feb 13, 2018 at 2:07 PM, Ulf Magnusson wrote: >> On Tue, Feb 13, 2018 at 12:33:24PM +0100, Ulf Magnusson wrote: >> Sander Eikelenboom wrote: >>> The Debian kernel-package tool make-kpkg for easy building of upstream >>> kernels on Debian fails with linux 4.16-rc1. >>>

Re: [PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode

> > > Anyway, I understand that Intel has been ignoring kernel.org instead of > > > sending forwarding their patches properly so you're doing a difficult > > > and thankless job... Thanks for that. I'm sure it's frustrating to > > > look at these patches for you as well. > > > > Thank you for

Re: [PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode

> > > Anyway, I understand that Intel has been ignoring kernel.org instead of > > > sending forwarding their patches properly so you're doing a difficult > > > and thankless job... Thanks for that. I'm sure it's frustrating to > > > look at these patches for you as well. > > > > Thank you for

Re: [PATCH RFC] schedutil: Allow cpufreq requests to be made even when kthread kicked

On 16-05-18, 15:45, Joel Fernandes (Google) wrote: > kernel/sched/cpufreq_schedutil.c | 36 +--- > 1 file changed, 28 insertions(+), 8 deletions(-) > > diff --git a/kernel/sched/cpufreq_schedutil.c > b/kernel/sched/cpufreq_schedutil.c > index

Re: [PATCH RFC] schedutil: Allow cpufreq requests to be made even when kthread kicked

On 16-05-18, 15:45, Joel Fernandes (Google) wrote: > kernel/sched/cpufreq_schedutil.c | 36 +--- > 1 file changed, 28 insertions(+), 8 deletions(-) > > diff --git a/kernel/sched/cpufreq_schedutil.c > b/kernel/sched/cpufreq_schedutil.c > index

[PATCH] clk: imx6sl: correct ocram_podf clock type

IMX6SL_CLK_OCRAM_PODF is a busy divider, its name in CCM_CDHIPR register of Reference Manual CCM chapter is axi_podf_busy, correct its clock type. Signed-off-by: Anson Huang --- drivers/clk/imx/clk-imx6sl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] clk: imx6sx: disable unnecessary clocks during clock initialization

Disable those unnecessary clocks during kernel boot up to save power, those modules clock should be managed by modules driver in runtime. Signed-off-by: Anson Huang --- drivers/clk/imx/clk-imx6sx.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git

[PATCH] clk: imx6sl: correct ocram_podf clock type

IMX6SL_CLK_OCRAM_PODF is a busy divider, its name in CCM_CDHIPR register of Reference Manual CCM chapter is axi_podf_busy, correct its clock type. Signed-off-by: Anson Huang --- drivers/clk/imx/clk-imx6sl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] clk: imx6sx: disable unnecessary clocks during clock initialization

Disable those unnecessary clocks during kernel boot up to save power, those modules clock should be managed by modules driver in runtime. Signed-off-by: Anson Huang --- drivers/clk/imx/clk-imx6sx.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git

[PATCH v7 2/3] gpio: pca953x: define masks for addressing common and extended registers

These mask bits are to be used to map the extended register addreseses (which are defined for an unsupported 8-bit pcal chip) to 16 and 24 bit chips (pcal6524). Reviewed-by: Andy Shevchenko Signed-off-by: H. Nikolaus Schaller ---

[PATCH v7 2/3] gpio: pca953x: define masks for addressing common and extended registers

These mask bits are to be used to map the extended register addreseses (which are defined for an unsupported 8-bit pcal chip) to 16 and 24 bit chips (pcal6524). Reviewed-by: Andy Shevchenko Signed-off-by: H. Nikolaus Schaller --- drivers/gpio/gpio-pca953x.c | 4 1 file changed, 4

Re: linux-next: build failure after merge of the drm tree

I've applied this locally for now so I can continue arm64 builds :-) Dave. On 16 May 2018 at 18:09, Oded Gabbay wrote: > On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell > wrote: >> Hi all, >> >> After merging the drm tree, today's linux-next

Re: linux-next: build failure after merge of the drm tree

I've applied this locally for now so I can continue arm64 builds :-) Dave. On 16 May 2018 at 18:09, Oded Gabbay wrote: > On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell > wrote: >> Hi all, >> >> After merging the drm tree, today's linux-next build (powerpc >> allyesconfig) failed like this:

[PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

The register constants are so far defined in a way that they fit for the pcal9555a when shifted by the number of banks, i.e. are multiplied by 2 in the accessor function. Now, the pcal6524 has 3 banks which means the relative offset is multiplied by 4 for the standard registers. Simply applying

[PATCH v7 1/3] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

The of_device_table is missing the PCA_PCAL flag so the pcal6524 would be operated in tca6424 compatibility mode which does not handle the new interrupt mask registers. Suggested-by: Andy Shevchenko Signed-off-by: H. Nikolaus Schaller ---

[PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

The register constants are so far defined in a way that they fit for the pcal9555a when shifted by the number of banks, i.e. are multiplied by 2 in the accessor function. Now, the pcal6524 has 3 banks which means the relative offset is multiplied by 4 for the standard registers. Simply applying

[PATCH v7 1/3] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

The of_device_table is missing the PCA_PCAL flag so the pcal6524 would be operated in tca6424 compatibility mode which does not handle the new interrupt mask registers. Suggested-by: Andy Shevchenko Signed-off-by: H. Nikolaus Schaller --- drivers/gpio/gpio-pca953x.c | 5 +++-- 1 file changed,

[PATCH v7 0/3] pcal6524 extensions and fixes for pca953x driver

V7: * replace PCAL register masks by hex constants 2018-05-16 19:01:29: V6: * added proper attribution to the formula used for fixing the pcal6524 register address (changes commit message only) * add back missing first patch from V2 that defines the PCA_LATCH_INT constant * removed patches

[PATCH v7 0/3] pcal6524 extensions and fixes for pca953x driver

V7: * replace PCAL register masks by hex constants 2018-05-16 19:01:29: V6: * added proper attribution to the formula used for fixing the pcal6524 register address (changes commit message only) * add back missing first patch from V2 that defines the PCA_LATCH_INT constant * removed patches

Re: [PATCH] perf annotate: Support multiple events without group

Hi, Any comments for this fix? Thanks Jin Yao On 5/10/2018 9:59 PM, Jin Yao wrote: See example, perf record -e cycles,branches ./div perf annotate main --stdio or perf annotate main --stdio2 or perf annotate main The "perf annotate" should show both cycles and branches on the left side, but

Re: [PATCH] perf annotate: Support multiple events without group

Hi, Any comments for this fix? Thanks Jin Yao On 5/10/2018 9:59 PM, Jin Yao wrote: See example, perf record -e cycles,branches ./div perf annotate main --stdio or perf annotate main --stdio2 or perf annotate main The "perf annotate" should show both cycles and branches on the left side, but

Re: [PATCH v5 13/13] mm: Clear shrinker bit if there are no objects related to memcg

On Tue, May 15, 2018 at 11:55:04AM +0300, Kirill Tkhai wrote: > >> @@ -586,8 +586,23 @@ static unsigned long shrink_slab_memcg(gfp_t > >> gfp_mask, int nid, > >>continue; > >> > >>ret = do_shrink_slab(, shrinker, priority); > >> - if (ret ==

Re: [PATCH v5 13/13] mm: Clear shrinker bit if there are no objects related to memcg

On Tue, May 15, 2018 at 11:55:04AM +0300, Kirill Tkhai wrote: > >> @@ -586,8 +586,23 @@ static unsigned long shrink_slab_memcg(gfp_t > >> gfp_mask, int nid, > >>continue; > >> > >>ret = do_shrink_slab(, shrinker, priority); > >> - if (ret ==

[PATCH 3/6] workqueue: Make worker_attach/detach_pool() update worker->pool

For historical reasons, the worker attach/detach functions don't currently manage worker->pool and the callers are manually and inconsistently updating it. This patch moves worker->pool updates into the worker attach/detach functions. This makes worker->pool consistent and clearly defines how

[PATCH 2/6] workqueue: Replace pool->attach_mutex with global wq_pool_attach_mutex

To improve workqueue visibility, we want to be able to access workqueue information from worker tasks. The per-pool attach mutex makes that difficult because there's no way of stabilizing task -> worker pool association without knowing the pool first. Worker attach/detach is a slow path and

[PATCH 3/6] workqueue: Make worker_attach/detach_pool() update worker->pool

For historical reasons, the worker attach/detach functions don't currently manage worker->pool and the callers are manually and inconsistently updating it. This patch moves worker->pool updates into the worker attach/detach functions. This makes worker->pool consistent and clearly defines how

[PATCH 2/6] workqueue: Replace pool->attach_mutex with global wq_pool_attach_mutex

To improve workqueue visibility, we want to be able to access workqueue information from worker tasks. The per-pool attach mutex makes that difficult because there's no way of stabilizing task -> worker pool association without knowing the pool first. Worker attach/detach is a slow path and

[PATCH 6/6] workqueue: Show the latest workqueue name in /proc/PID/{comm,stat,status}

There can be a lot of workqueue workers and they all show up with the cryptic kworker/* names making it difficult to understand which is doing what and how they came to be. # ps -ef | grep kworker root 4 2 0 Feb25 ?00:00:00 [kworker/0:0H] root 6 2 0

[PATCH 6/6] workqueue: Show the latest workqueue name in /proc/PID/{comm,stat,status}

There can be a lot of workqueue workers and they all show up with the cryptic kworker/* names making it difficult to understand which is doing what and how they came to be. # ps -ef | grep kworker root 4 2 0 Feb25 ?00:00:00 [kworker/0:0H] root 6 2 0

[PATCH 4/6] workqueue: Set worker->desc to workqueue name by default

Work functions can use set_worker_desc() to improve the visibility of what the worker task is doing. Currently, the desc field is unset at the beginning of each execution and there is a separate field to track the field is set during the current execution. Instead of leaving empty till desc is

[PATCH 5/6] proc: Consolidate task->comm formatting into proc_task_name()

proc shows task->comm in three places - comm, stat, status - and each is fetching and formatting task->comm slighly differently. This patch renames task_name() to proc_task_name(), makes it more generic, and updates all three paths to use it. This will enable expanding comm reporting for

[PATCH 1/6] proc: Don't allow empty /proc/PID/cmdline for user tasks

Kernel threads have empty /proc/PID/cmdline and some userland tools including ps(1) and older versions of systemd use this to detect kernel threads. However, any userland program can emulate the behavior by making its argvs unavailable and trick the affected tools into thinking that the task is a

[PATCH 4/6] workqueue: Set worker->desc to workqueue name by default

Work functions can use set_worker_desc() to improve the visibility of what the worker task is doing. Currently, the desc field is unset at the beginning of each execution and there is a separate field to track the field is set during the current execution. Instead of leaving empty till desc is

[PATCH 5/6] proc: Consolidate task->comm formatting into proc_task_name()

proc shows task->comm in three places - comm, stat, status - and each is fetching and formatting task->comm slighly differently. This patch renames task_name() to proc_task_name(), makes it more generic, and updates all three paths to use it. This will enable expanding comm reporting for

[PATCH 1/6] proc: Don't allow empty /proc/PID/cmdline for user tasks

Kernel threads have empty /proc/PID/cmdline and some userland tools including ps(1) and older versions of systemd use this to detect kernel threads. However, any userland program can emulate the behavior by making its argvs unavailable and trick the affected tools into thinking that the task is a

[PATCHSET] workqueue: Show the latest workqueue name in /proc/PID/{comm,stat,status}

There can be a lot of workqueue workers and they all show up with the cryptic kworker/* names making it difficult to understand which is doing what and how they came to be. # ps -ef | grep kworker root 4 2 0 Feb25 ?00:00:00 [kworker/0:0H] root 6 2 0

[PATCHSET] workqueue: Show the latest workqueue name in /proc/PID/{comm,stat,status}

There can be a lot of workqueue workers and they all show up with the cryptic kworker/* names making it difficult to understand which is doing what and how they came to be. # ps -ef | grep kworker root 4 2 0 Feb25 ?00:00:00 [kworker/0:0H] root 6 2 0

Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()

On Tue, May 15, 2018 at 01:12:20PM +0300, Kirill Tkhai wrote: > >> +#define root_mem_cgroup NULL > > > > Let's instead export mem_cgroup_is_root(). In case if MEMCG is disabled > > it will always return false. > > export == move to header file That and adding a stub function in case !MEMCG. >

Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()

On Tue, May 15, 2018 at 01:12:20PM +0300, Kirill Tkhai wrote: > >> +#define root_mem_cgroup NULL > > > > Let's instead export mem_cgroup_is_root(). In case if MEMCG is disabled > > it will always return false. > > export == move to header file That and adding a stub function in case !MEMCG. >

Re: [PATCH v7] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

Hi, Le 16/05/2018 à 09:56, Boris Brezillon a écrit : On Wed, 16 May 2018 09:32:57 +0200 Chris Moore wrote: Hi, Le 15/05/2018 à 09:34, Boris Brezillon a écrit : On Tue, 15 May 2018 06:45:51 +0200 Chris Moore wrote: Hi, Le 13/05/2018 à 06:30, Wan, Jane

Re: [PATCH v7] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

Hi, Le 16/05/2018 à 09:56, Boris Brezillon a écrit : On Wed, 16 May 2018 09:32:57 +0200 Chris Moore wrote: Hi, Le 15/05/2018 à 09:34, Boris Brezillon a écrit : On Tue, 15 May 2018 06:45:51 +0200 Chris Moore wrote: Hi, Le 13/05/2018 à 06:30, Wan, Jane (Nokia - US/Sunnyvale) a écrit :

Re: [PATCH net-next 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST

Hi Florian, I love your patch! Perhaps something to improve: [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807 config: xtensa-allyesconfig (attached as .config) compiler:

Re: [PATCH net-next 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST

Hi Florian, I love your patch! Perhaps something to improve: [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807 config: xtensa-allyesconfig (attached as .config) compiler:

[PATCH] of: overlay: validate offset from property fixups

From: Frank Rowand The smatch static checker marks the data in offset as untrusted, leading it to warn: drivers/of/resolver.c:125 update_usages_of_a_phandle_reference() error: buffer underflow 'prop->value' 's32min-s32max' Add check to verify that offset is within

[PATCH] of: overlay: validate offset from property fixups

From: Frank Rowand The smatch static checker marks the data in offset as untrusted, leading it to warn: drivers/of/resolver.c:125 update_usages_of_a_phandle_reference() error: buffer underflow 'prop->value' 's32min-s32max' Add check to verify that offset is within the property data.

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On 15-05-18, 11:50, Frank Mori Hess wrote: > On Tue, May 15, 2018 at 2:21 AM, Vinod wrote: > > > > For Pause/resume data loss is _not_ expected. > > > >> > and some of the 8250 drivers like 8250_dw.c set a maxburst > 1. If it > >> > can't count on the pause/residue/terminate

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On 15-05-18, 11:50, Frank Mori Hess wrote: > On Tue, May 15, 2018 at 2:21 AM, Vinod wrote: > > > > For Pause/resume data loss is _not_ expected. > > > >> > and some of the 8250 drivers like 8250_dw.c set a maxburst > 1. If it > >> > can't count on the pause/residue/terminate working without data

linux-next: manual merge of the staging tree with the v4l-dvb tree

Hi all, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/media/atomisp/TODO between commit: 51b8dc5163d2 ("media: staging: atomisp: Remove driver") from the v4l-dvb tree and commit: 1bd421154821 ("staging: atomisp: Augment TODO file with GPIO work item")

linux-next: manual merge of the staging tree with the v4l-dvb tree

Hi all, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/media/atomisp/TODO between commit: 51b8dc5163d2 ("media: staging: atomisp: Remove driver") from the v4l-dvb tree and commit: 1bd421154821 ("staging: atomisp: Augment TODO file with GPIO work item")

Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()

On Tue, May 15, 2018 at 05:49:59PM +0300, Kirill Tkhai wrote: > >> @@ -589,13 +647,7 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int > >> nid, > >>.memcg = memcg, > >>}; > >> > >> - /* > >> - * If kernel memory accounting is disabled,

Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()

On Tue, May 15, 2018 at 05:49:59PM +0300, Kirill Tkhai wrote: > >> @@ -589,13 +647,7 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int > >> nid, > >>.memcg = memcg, > >>}; > >> > >> - /* > >> - * If kernel memory accounting is disabled,

Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

On 16-05-18, 12:24, Florian Fainelli wrote: > On 05/15/2018 09:32 PM, Viresh Kumar wrote: > > On 15-05-18, 20:49, Markus Mayer wrote: > >> From: Markus Mayer > >> > >> Most CPUfreq drivers (at least on ARM) seem to be sorting the available > >> frequencies from lowest to

Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

On 16-05-18, 12:24, Florian Fainelli wrote: > On 05/15/2018 09:32 PM, Viresh Kumar wrote: > > On 15-05-18, 20:49, Markus Mayer wrote: > >> From: Markus Mayer > >> > >> Most CPUfreq drivers (at least on ARM) seem to be sorting the available > >> frequencies from lowest to highest. To match this

Re: [PATCH] sched/rt: fix call to cpufreq_update_util

On 16-05-18, 20:18, Vincent Guittot wrote: > With commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") > schedutil governor uses rq->rt.rt_nr_running to detect whether a RT task is > currently running on the CPU and to set frequency to max if necessary. > cpufreq_update_util() is

Re: [PATCH] sched/rt: fix call to cpufreq_update_util

On 16-05-18, 20:18, Vincent Guittot wrote: > With commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") > schedutil governor uses rq->rt.rt_nr_running to detect whether a RT task is > currently running on the CPU and to set frequency to max if necessary. > cpufreq_update_util() is

Re: Grant

I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation:

Re: Grant

I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation:

Re: [PATCH 1/4] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr

On 5/6/2018 3:44 PM, Alim Akhtar wrote: In the right behavior, setting the bit to '0' indicates clear and '1' indicates no change. If host controller handles this the other way, UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used. Signed-off-by: Seungwon Jeon Signed-off-by: Alim

Re: [PATCH 1/4] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr

On 5/6/2018 3:44 PM, Alim Akhtar wrote: In the right behavior, setting the bit to '0' indicates clear and '1' indicates no change. If host controller handles this the other way, UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used. Signed-off-by: Seungwon Jeon Signed-off-by: Alim Akhtar ---

Re: [PATCH net-next 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST

Hi Florian, I love your patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807 config: m68k-allmodconfig (attached as .config) compiler:

Re: [PATCH net-next 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST

Hi Florian, I love your patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807 config: m68k-allmodconfig (attached as .config) compiler:

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

Hi Chao, On 05/17/18 at 11:27am, Chao Fan wrote: > >+/* Store the number of 1GB huge pages which user specified.*/ > >+static unsigned long max_gb_huge_pages; > >+ > >+static int parse_gb_huge_pages(char *param, char* val) > >+{ > >+char *p; > >+u64 mem_size; > >+static bool gbpage_sz

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

Hi Chao, On 05/17/18 at 11:27am, Chao Fan wrote: > >+/* Store the number of 1GB huge pages which user specified.*/ > >+static unsigned long max_gb_huge_pages; > >+ > >+static int parse_gb_huge_pages(char *param, char* val) > >+{ > >+char *p; > >+u64 mem_size; > >+static bool gbpage_sz

  1   2   3   4   5   6   7   8   9   10   >