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

Hi Paul, On Tue, 18 Apr 2017 21:06:20 -0700 "Paul E. McKenney" wrote: > > Or at least broken in a more subtle and creative way. ;-) What I live for :-) -- Cheers, Stephen Rothwell

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

Hi Paul, On Tue, 18 Apr 2017 21:06:20 -0700 "Paul E. McKenney" wrote: > > Or at least broken in a more subtle and creative way. ;-) What I live for :-) -- Cheers, Stephen Rothwell

Re: Re: "mm: move pcp and lru-pcp draining into single wq" broke resume from s2ram

Geert Uytterhoeven wrote: > 8 locks held by s2ram/1899: > #0: (sb_writers#7){.+.+.+}, at: [] vfs_write+0xa8/0x15c > #1: (>mutex){+.+.+.}, at: [] > kernfs_fop_write+0xf0/0x194 > #2: (s_active#48){.+.+.+}, at: [] > kernfs_fop_write+0xf8/0x194 > #3: (pm_mutex){+.+.+.}, at: []

Re: Re: "mm: move pcp and lru-pcp draining into single wq" broke resume from s2ram

Geert Uytterhoeven wrote: > 8 locks held by s2ram/1899: > #0: (sb_writers#7){.+.+.+}, at: [] vfs_write+0xa8/0x15c > #1: (>mutex){+.+.+.}, at: [] > kernfs_fop_write+0xf0/0x194 > #2: (s_active#48){.+.+.+}, at: [] > kernfs_fop_write+0xf8/0x194 > #3: (pm_mutex){+.+.+.}, at: []

Re: export pcie_flr and remove copies of it in drivers V2

On Tue, Apr 18, 2017 at 01:36:12PM -0500, Bjorn Helgaas wrote: > On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote: > > Hi all, > > > > this exports the PCI layer pcie_flr helper, and removes various opencoded > > copies of it. > > > > Changes since V1: > > - rebase on top of the

Re: export pcie_flr and remove copies of it in drivers V2

On Tue, Apr 18, 2017 at 01:36:12PM -0500, Bjorn Helgaas wrote: > On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote: > > Hi all, > > > > this exports the PCI layer pcie_flr helper, and removes various opencoded > > copies of it. > > > > Changes since V1: > > - rebase on top of the

[PATCH V3 02/17] thermal: cpu_cooling: rearrange globals

Just to make it look better. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index be29489dd247..ce94aafed25d 100644 ---

[PATCH V3 02/17] thermal: cpu_cooling: rearrange globals

Just to make it look better. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index be29489dd247..ce94aafed25d 100644 ---

[PATCH V3 01/17] thermal: cpu_cooling: Avoid accessing potentially freed structures

After the lock is dropped, it is possible that the cpufreq_dev gets freed before we call get_level() and that can cause kernel to crash. Drop the lock after we are done using the structure. Cc: 4.2+ # 4.2+ Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems

[PATCH V3 01/17] thermal: cpu_cooling: Avoid accessing potentially freed structures

After the lock is dropped, it is possible that the cpufreq_dev gets freed before we call get_level() and that can cause kernel to crash. Drop the lock after we are done using the structure. Cc: 4.2+ # 4.2+ Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")

[PATCH V3 09/17] thermal: cpu_cooling: store cpufreq policy

The cpufreq policy can be used by the cpu_cooling driver, lets store it in the cpufreq_cooling_device structure. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/thermal/cpu_cooling.c

Re: [PATCH V3 02/16] block, bfq: add full hierarchical scheduling and cgroups support

> Il giorno 18 apr 2017, alle ore 09:04, Tejun Heo ha scritto: > > Hello, Paolo. > > On Wed, Apr 12, 2017 at 07:22:03AM +0200, Paolo Valente wrote: >> could you elaborate a bit more on this? I mean, cgroups support has >> been in BFQ (and CFQ) for almost ten years, perfectly

[PATCH V3 09/17] thermal: cpu_cooling: store cpufreq policy

The cpufreq policy can be used by the cpu_cooling driver, lets store it in the cpufreq_cooling_device structure. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c

Re: [PATCH V3 02/16] block, bfq: add full hierarchical scheduling and cgroups support

> Il giorno 18 apr 2017, alle ore 09:04, Tejun Heo ha scritto: > > Hello, Paolo. > > On Wed, Apr 12, 2017 at 07:22:03AM +0200, Paolo Valente wrote: >> could you elaborate a bit more on this? I mean, cgroups support has >> been in BFQ (and CFQ) for almost ten years, perfectly working as far >>

[PATCH V3 08/17] cpufreq: create cpufreq_table_count_valid_entries()

We need such a routine at two places already, lets create one. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq_stats.c | 13 - drivers/thermal/cpu_cooling.c | 22 +- include/linux/cpufreq.h | 14 ++ 3 files

[PATCH V3 08/17] cpufreq: create cpufreq_table_count_valid_entries()

We need such a routine at two places already, lets create one. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq_stats.c | 13 - drivers/thermal/cpu_cooling.c | 22 +- include/linux/cpufreq.h | 14 ++ 3 files changed, 27 insertions(+),

[PATCH V3 14/17] thermal: cpu_cooling: get_level() can't fail

The frequency passed to get_level() is returned by cpu_power_to_freq() and it is guaranteed that get_level() can't fail. Get rid of error code. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 20 +--- 1 file changed, 5 insertions(+), 15

[PATCH V3 14/17] thermal: cpu_cooling: get_level() can't fail

The frequency passed to get_level() is returned by cpu_power_to_freq() and it is guaranteed that get_level() can't fail. Get rid of error code. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git

[PATCH V3 15/17] thermal: cpu_cooling: don't store cpu_dev in cpufreq_cdev

'cpu_dev' is used by only one function, get_static_power(), and it wouldn't be time consuming to get the cpu device structure within it. This would help removing cpu_dev from struct cpufreq_cooling_device. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c |

[PATCH V3 15/17] thermal: cpu_cooling: don't store cpu_dev in cpufreq_cdev

'cpu_dev' is used by only one function, get_static_power(), and it wouldn't be time consuming to get the cpu device structure within it. This would help removing cpu_dev from struct cpufreq_cooling_device. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 22 ++

Re: [PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 18, 2017, at 3:59 PM, Michal Hocko wrote: > >> On Tue 18-04-17 14:48:39, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually mapped areas are never unmapped. >> So `OR` VM_STATIC

Re: [PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 18, 2017, at 3:59 PM, Michal Hocko wrote: > >> On Tue 18-04-17 14:48:39, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually mapped areas are never unmapped. >> So `OR` VM_STATIC flag to the areas in

[PATCH V3 10/17] thermal: cpu_cooling: OPPs are registered for all CPUs

The OPPs are registered for all CPUs of a cpufreq policy now and we don't need to run the loop in build_dyn_power_table(). Just check for the policy->cpu and we should be fine. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 26 +++---

[PATCH V3 12/17] thermal: cpu_cooling: merge frequency and power tables

The cpu_cooling driver keeps two tables: - freq_table: table of frequencies in descending order, built from policy->freq_table. - power_table: table of frequencies and power in ascending order, built from OPP table. If the OPPs are used for the CPU device then both these tables are actually

[PATCH V3 10/17] thermal: cpu_cooling: OPPs are registered for all CPUs

The OPPs are registered for all CPUs of a cpufreq policy now and we don't need to run the loop in build_dyn_power_table(). Just check for the policy->cpu and we should be fine. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 26 +++--- 1 file changed, 11

[PATCH V3 12/17] thermal: cpu_cooling: merge frequency and power tables

The cpu_cooling driver keeps two tables: - freq_table: table of frequencies in descending order, built from policy->freq_table. - power_table: table of frequencies and power in ascending order, built from OPP table. If the OPPs are used for the CPU device then both these tables are actually

[PATCH V3 13/17] thermal: cpu_cooling: create structure for idle time stats

We keep two arrays for idle time stats and allocate memory for them separately. It would be much easier to follow if we create an array of idle stats structure instead and allocate it once. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 53

[PATCH V3 17/17] thermal: cpu_cooling: Rearrange struct cpufreq_cooling_device

This shrinks the size of the structure on arm64 by 8 bytes by avoiding padding of 4 bytes at two places. Also add missing doc comment for freq_table Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 15 --- 1 file changed, 8 insertions(+), 7

[PATCH V3 07/17] thermal: cpu_cooling: use cpufreq_policy to register cooling device

The CPU cooling driver uses the cpufreq policy, to get clip_cpus, the frequency table, etc. Most of the callers of CPU cooling driver's registration routines have the cpufreq policy with them, but they only pass the policy->related_cpus cpumask. The __cpufreq_cooling_register() routine then gets

[PATCH V3 13/17] thermal: cpu_cooling: create structure for idle time stats

We keep two arrays for idle time stats and allocate memory for them separately. It would be much easier to follow if we create an array of idle stats structure instead and allocate it once. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 53

[PATCH V3 17/17] thermal: cpu_cooling: Rearrange struct cpufreq_cooling_device

This shrinks the size of the structure on arm64 by 8 bytes by avoiding padding of 4 bytes at two places. Also add missing doc comment for freq_table Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git

[PATCH V3 07/17] thermal: cpu_cooling: use cpufreq_policy to register cooling device

The CPU cooling driver uses the cpufreq policy, to get clip_cpus, the frequency table, etc. Most of the callers of CPU cooling driver's registration routines have the cpufreq policy with them, but they only pass the policy->related_cpus cpumask. The __cpufreq_cooling_register() routine then gets

[PATCH V3 16/17] thermal: cpu_cooling: 'freq' can't be zero in cpufreq_state2power()

The frequency table shouldn't have any zero frequency entries and so such a check isn't required. Though it would be better to make sure 'state' is within limits. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 7 --- 1 file changed, 4 insertions(+),

[PATCH V3 16/17] thermal: cpu_cooling: 'freq' can't be zero in cpufreq_state2power()

The frequency table shouldn't have any zero frequency entries and so such a check isn't required. Though it would be better to make sure 'state' is within limits. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff

[PATCH V3 03/17] thermal: cpu_cooling: Name cpufreq cooling devices as cpufreq_cdev

Objects of "struct cpufreq_cooling_device" are named a bit inconsistently. Lets use cpufreq_cdev everywhere. Also note that the lists containing such devices is renamed similarly too. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 248

[PATCH V3 06/17] thermal: cpu_cooling: get rid of a variable in cpufreq_set_cur_state()

'cpu' is used at only one place and there is no need to keep a separate variable for it. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/thermal/cpu_cooling.c

[PATCH V3 04/17] thermal: cpu_cooling: replace cool_dev with cdev

Objects of "struct thermal_cooling_device" are named a bit inconsistently. Lets use cdev everywhere. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 37 ++--- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git

[PATCH V3 03/17] thermal: cpu_cooling: Name cpufreq cooling devices as cpufreq_cdev

Objects of "struct cpufreq_cooling_device" are named a bit inconsistently. Lets use cpufreq_cdev everywhere. Also note that the lists containing such devices is renamed similarly too. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 248 +-

[PATCH V3 06/17] thermal: cpu_cooling: get rid of a variable in cpufreq_set_cur_state()

'cpu' is used at only one place and there is no need to keep a separate variable for it. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index

[PATCH V3 04/17] thermal: cpu_cooling: replace cool_dev with cdev

Objects of "struct thermal_cooling_device" are named a bit inconsistently. Lets use cdev everywhere. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 37 ++--- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git

[PATCH V3 11/17] thermal: cpu_cooling: get rid of 'allowed_cpus'

'allowed_cpus' is a copy of policy->related_cpus and can be replaced by it directly. At some places we are only concerned about online CPUs and policy->cpus can be used there. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 77

[PATCH V3 11/17] thermal: cpu_cooling: get rid of 'allowed_cpus'

'allowed_cpus' is a copy of policy->related_cpus and can be replaced by it directly. At some places we are only concerned about online CPUs and policy->cpus can be used there. Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 77 --- 1 file

[PATCH V3 05/17] thermal: cpu_cooling: remove cpufreq_cooling_get_level()

There is only one user of cpufreq_cooling_get_level() and that already has pointer to the cpufreq_cdev structure. It can directly call get_level() instead and we can get rid of cpufreq_cooling_get_level(). Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c |

[PATCH V3 05/17] thermal: cpu_cooling: remove cpufreq_cooling_get_level()

There is only one user of cpufreq_cooling_get_level() and that already has pointer to the cpufreq_cdev structure. It can directly call get_level() instead and we can get rid of cpufreq_cooling_get_level(). Signed-off-by: Viresh Kumar --- drivers/thermal/cpu_cooling.c | 33

[PATCH V3 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

Hi Guys, The cpu_cooling driver is designed to use CPU frequency scaling to avoid high thermal states for a platform. But it wasn't glued really well with cpufreq core. For example clipped-cpus is copied from the policy structure and its much better to use the policy->cpus (or related_cpus)

[PATCH V3 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

Hi Guys, The cpu_cooling driver is designed to use CPU frequency scaling to avoid high thermal states for a platform. But it wasn't glued really well with cpufreq core. For example clipped-cpus is copied from the policy structure and its much better to use the policy->cpus (or related_cpus)

Re: [PATCH] acpi: fix typo

Hi On 04/19/2017 08:20 AM, Rafael J. Wysocki wrote: > On Fri, Mar 31, 2017 at 11:46 AM, Cao jin wrote: >> Signed-off-by: Cao jin >> --- >> Documentation/acpi/linuxized-acpica.txt | 10 +- > > Please send changes to this file

Re: [PATCH] acpi: fix typo

Hi On 04/19/2017 08:20 AM, Rafael J. Wysocki wrote: > On Fri, Mar 31, 2017 at 11:46 AM, Cao jin wrote: >> Signed-off-by: Cao jin >> --- >> Documentation/acpi/linuxized-acpica.txt | 10 +- > > Please send changes to this file separately. > >> include/acpi/actypes.h |

Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

On 18-04-17, 15:40, Lukasz Luba wrote: > Hi Viresh, > > I have checkout your branch at newest commit: > 908063832c268f8add94 > I have built it and run it on my Juno r2. > I have some python tests for IPA and I run one of them. > > I seen a few issues so I have created a patch just > to be able

Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

On 18-04-17, 15:40, Lukasz Luba wrote: > Hi Viresh, > > I have checkout your branch at newest commit: > 908063832c268f8add94 > I have built it and run it on my Juno r2. > I have some python tests for IPA and I run one of them. > > I seen a few issues so I have created a patch just > to be able

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 18, 2017 at 9:58 PM, Serge E. Hallyn wrote: > On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: >> This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity >> project in-kernel. >> >> This will create the Kconfig

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 18, 2017 at 9:58 PM, Serge E. Hallyn wrote: > On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: >> This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity >> project in-kernel. >> >> This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the

Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

On Tue, Apr 18, 2017 at 8:59 PM, wlf wrote: > Dear Guenter, > > > > 在 2017年04月18日 21:18, Guenter Roeck 写道: >> >> On Mon, Apr 17, 2017 at 10:17 PM, William Wu >> wrote: >>> >>> This patch adds a quirk to disable USB 2.0 MAC linestate check >>>

Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

On Tue, Apr 18, 2017 at 8:59 PM, wlf wrote: > Dear Guenter, > > > > 在 2017年04月18日 21:18, Guenter Roeck 写道: >> >> On Mon, Apr 17, 2017 at 10:17 PM, William Wu >> wrote: >>> >>> This patch adds a quirk to disable USB 2.0 MAC linestate check >>> during HS transmit. Refer the dwc3 databook, we can

[PATCH 4/4] ARM: sun8i: h3: bananapi-m2-plus: Enable USB OTG

The Bananapi M2 Plus has a USB OTG port that can be used in both powered host mode and peripheral mode. When in peripheral mode, the port does not power the board. There is no VBUS sensing on the port. This patch adds the regulator controlling VBUS on the OTG port, the GPIO for the ID detect pin,

[PATCH 4/4] ARM: sun8i: h3: bananapi-m2-plus: Enable USB OTG

The Bananapi M2 Plus has a USB OTG port that can be used in both powered host mode and peripheral mode. When in peripheral mode, the port does not power the board. There is no VBUS sensing on the port. This patch adds the regulator controlling VBUS on the OTG port, the GPIO for the ID detect pin,

[PATCH 0/4] ARM: sunxi: device tree pinctrl clean up and H3 OTG

Hi Maxime, This series has 2 parts. The parts are largely unrelated, though the second part should be applied after the first part, so we don't accidentally mux pins that we shouldn't. Hence I'm sending them together. The first 2 patches clean up the sunxi device tree files, removing pinmux

[PATCH 0/4] ARM: sunxi: device tree pinctrl clean up and H3 OTG

Hi Maxime, This series has 2 parts. The parts are largely unrelated, though the second part should be applied after the first part, so we don't accidentally mux pins that we shouldn't. Hence I'm sending them together. The first 2 patches clean up the sunxi device tree files, removing pinmux

[PATCH 3/4] ARM: sun8i: h3: orangepi-pc: Enable USB OTG

The Orange Pi PC, PC Plus, and Plus 2E all have a USB OTG port that can be used in both powered host mode and peripheral mode. When in peripheral mode, the port does not power the board. There is no VBUS sensing on the port. All three boards have all related pins routed the same way. The device

[PATCH 3/4] ARM: sun8i: h3: orangepi-pc: Enable USB OTG

The Orange Pi PC, PC Plus, and Plus 2E all have a USB OTG port that can be used in both powered host mode and peripheral mode. When in peripheral mode, the port does not power the board. There is no VBUS sensing on the port. All three boards have all related pins routed the same way. The device

[PATCH 1/4] ARM: sunxi: common-regulators: Drop pinmux settings for GPIO pins

As part of our effort to move pinctrl/GPIO interlocking into the driver where it belongs, this patch drops the definition and usage of the pinmux settings for the common regulators defined in sunxi-common-regulators.dtsi. Signed-off-by: Chen-Yu Tsai ---

[PATCH 2/4] ARM: sunxi: Drop mmc0_cd_pin_reference_design pinmux setting

As part of our effort to move pinctrl/GPIO interlocking into the driver where it belongs, this patch drops the definition and usage of the mmc0_cd_pin_reference_design pinmux setting for the default mmc0 card detect GPIO pin. Signed-off-by: Chen-Yu Tsai ---

[PATCH 2/4] ARM: sunxi: Drop mmc0_cd_pin_reference_design pinmux setting

As part of our effort to move pinctrl/GPIO interlocking into the driver where it belongs, this patch drops the definition and usage of the mmc0_cd_pin_reference_design pinmux setting for the default mmc0 card detect GPIO pin. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun4i-a10-a1000.dts

[PATCH 1/4] ARM: sunxi: common-regulators: Drop pinmux settings for GPIO pins

As part of our effort to move pinctrl/GPIO interlocking into the driver where it belongs, this patch drops the definition and usage of the pinmux settings for the common regulators defined in sunxi-common-regulators.dtsi. Signed-off-by: Chen-Yu Tsai ---

Re: bfq-mq performance comparison to cfq

On 04/11/17 00:29, Paolo Valente wrote: > >> Il giorno 10 apr 2017, alle ore 17:15, Bart Van Assche >> ha scritto: >> >> On Mon, 2017-04-10 at 11:55 +0200, Paolo Valente wrote: >>> That said, if you do always want maximum throughput, even at the >>> expense of

Re: bfq-mq performance comparison to cfq

On 04/11/17 00:29, Paolo Valente wrote: > >> Il giorno 10 apr 2017, alle ore 17:15, Bart Van Assche >> ha scritto: >> >> On Mon, 2017-04-10 at 11:55 +0200, Paolo Valente wrote: >>> That said, if you do always want maximum throughput, even at the >>> expense of latency, then just switch off

Re: Doubt on first access for PCIe device

On 04/11/2017 10:15 AM, abhijit wrote: > Here I am assuming, the completer ID will be device number and function > number that will eventually programmed in to device. In that case, my > question is, without first write, how read request(VENDOR ID read) is > serviced/routed? You'll want to

Re: Doubt on first access for PCIe device

On 04/11/2017 10:15 AM, abhijit wrote: > Here I am assuming, the completer ID will be device number and function > number that will eventually programmed in to device. In that case, my > question is, without first write, how read request(VENDOR ID read) is > serviced/routed? You'll want to

Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote: > The FBDEV initialization would throw an error in dmesg, when we just > want to silently not initialize fbdev on a V3D-only VC4 instance. > > Signed-off-by: Eric Anholt Hm, this shouldn't be an error really,

Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote: > The FBDEV initialization would throw an error in dmesg, when we just > want to silently not initialize fbdev on a V3D-only VC4 instance. > > Signed-off-by: Eric Anholt Hm, this shouldn't be an error really, you might want to hotplug more

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: > This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity > project in-kernel. > > This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding > sysctl kernel.tiocsti_restrict that, when activated,

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: > This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity > project in-kernel. > > This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding > sysctl kernel.tiocsti_restrict that, when activated,

Re: [PATCH v2 2/2] drm: dw-hdmi: gate audio clock from the I2S enablement callbacks

On 04/14/2017 02:01 PM, Romain Perier wrote: Currently, the audio sampler clock is enabled from dw_hdmi_setup() at step E. and is kept enabled for later use. This clock should be enabled and disabled along with the actual audio stream and not always on (that is bad for PM). Futhermore, as

Re: [PATCH v2 2/2] drm: dw-hdmi: gate audio clock from the I2S enablement callbacks

On 04/14/2017 02:01 PM, Romain Perier wrote: Currently, the audio sampler clock is enabled from dw_hdmi_setup() at step E. and is kept enabled for later use. This clock should be enabled and disabled along with the actual audio stream and not always on (that is bad for PM). Futhermore, as

Re: [PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

Peter Zijlstra writes: > On Tue, Apr 11, 2017 at 07:21:05AM +0530, Madhavan Srinivasan wrote: >> From: Sukadev Bhattiprolu >> >> perf_mem_data_src is an union that is initialized via the ->val field >> and accessed via the bitmap fields. For

Re: [PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

Peter Zijlstra writes: > On Tue, Apr 11, 2017 at 07:21:05AM +0530, Madhavan Srinivasan wrote: >> From: Sukadev Bhattiprolu >> >> perf_mem_data_src is an union that is initialized via the ->val field >> and accessed via the bitmap fields. For this to work on big endian >> platforms (Which is

Re: [PATCH v2 1/2] drm: dw-hdmi: add specific I2S and AHB functions for stream handling

On 04/14/2017 02:01 PM, Romain Perier wrote: Currently, CTS+N is forced to zero as a workaround of the IP block for i.MX platforms. This is requested in the datasheet of the corresponding IP for AHB mode only. However, we have seen that it introduces glitches or delays when playing a sound on

Re: [PATCH v2 1/2] drm: dw-hdmi: add specific I2S and AHB functions for stream handling

On 04/14/2017 02:01 PM, Romain Perier wrote: Currently, CTS+N is forced to zero as a workaround of the IP block for i.MX platforms. This is requested in the datasheet of the corresponding IP for AHB mode only. However, we have seen that it introduces glitches or delays when playing a sound on

Re: [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode

On 4/19/2017 8:53 AM, Jin, Yao wrote: On 4/19/2017 2:53 AM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 06:21:05AM +0800, Jin Yao wrote: SNIP +const char *branch_type_name(int type) +{ +const char *branch_names[PERF_BR_MAX] = { +"N/A", +"JCC", +"JMP", +

Re: [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode

On 4/19/2017 8:53 AM, Jin, Yao wrote: On 4/19/2017 2:53 AM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 06:21:05AM +0800, Jin Yao wrote: SNIP +const char *branch_type_name(int type) +{ +const char *branch_names[PERF_BR_MAX] = { +"N/A", +"JCC", +"JMP", +

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

state") > > This config has CONFIG_CLASSIC_SRCU=y and CONFIG_RCU_TORTURE_TEST=m, so > CONFIG_RCU_TORTURE_TEST is not defined - CONFIG_RCU_TORTURE_TEST_MODULE > is defined. You probably want to protect srcutorture_get_gp_data() with > IS_ENABLED(CONFIG_RCU_TORTURE_TEST) instea

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

state") > > This config has CONFIG_CLASSIC_SRCU=y and CONFIG_RCU_TORTURE_TEST=m, so > CONFIG_RCU_TORTURE_TEST is not defined - CONFIG_RCU_TORTURE_TEST_MODULE > is defined. You probably want to protect srcutorture_get_gp_data() with > IS_ENABLED(CONFIG_RCU_TORTURE_TEST) instea

Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

Dear Guenter, 在 2017年04月18日 21:18, Guenter Roeck 写道: On Mon, Apr 17, 2017 at 10:17 PM, William Wu wrote: This patch adds a quirk to disable USB 2.0 MAC linestate check during HS transmit. Refer the dwc3 databook, we can use it for some special platforms if the

Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

Dear Guenter, 在 2017年04月18日 21:18, Guenter Roeck 写道: On Mon, Apr 17, 2017 at 10:17 PM, William Wu wrote: This patch adds a quirk to disable USB 2.0 MAC linestate check during HS transmit. Refer the dwc3 databook, we can use it for some special platforms if the linestate not reflect the

linux-next: build failure after merge of the rcu tree

s not defined - CONFIG_RCU_TORTURE_TEST_MODULE is defined. You probably want to protect srcutorture_get_gp_data() with IS_ENABLED(CONFIG_RCU_TORTURE_TEST) instead. I have used the rcu tree from next-20170418 for today. -- Cheers, Stephen Rothwell

linux-next: build failure after merge of the rcu tree

s not defined - CONFIG_RCU_TORTURE_TEST_MODULE is defined. You probably want to protect srcutorture_get_gp_data() with IS_ENABLED(CONFIG_RCU_TORTURE_TEST) instead. I have used the rcu tree from next-20170418 for today. -- Cheers, Stephen Rothwell

[PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity project in-kernel. This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding sysctl kernel.tiocsti_restrict that, when activated, restrict all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

[PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity project in-kernel. This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding sysctl kernel.tiocsti_restrict that, when activated, restrict all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

Re: [PATCH v2 8/9] staging: fsl-dpaa2/eth: Add TODO file

On Wed, Apr 12, 2017 at 11:25 AM, Ioana Radulescu wrote: > Add a list of TODO items for the Ethernet driver > > Signed-off-by: Ioana Radulescu > --- > v2: Add note > > drivers/staging/fsl-dpaa2/ethernet/TODO | 14 ++ > 1 file

Re: [PATCH v2 8/9] staging: fsl-dpaa2/eth: Add TODO file

On Wed, Apr 12, 2017 at 11:25 AM, Ioana Radulescu wrote: > Add a list of TODO items for the Ethernet driver > > Signed-off-by: Ioana Radulescu > --- > v2: Add note > > drivers/staging/fsl-dpaa2/ethernet/TODO | 14 ++ > 1 file changed, 14 insertions(+) > create mode 100644

WARNING: kernel stack frame pointer has bad value

Josh, I'm starting to get a bunch of these warnings, and I'm thinking they are false positives. The stack frame error is recorded at a call from entry_SYSCALL_64_fastpath, where I would expect the bp to not be valid. To trigger this, I only need to go into /sys/kernel/debug/tracing and echo

WARNING: kernel stack frame pointer has bad value

Josh, I'm starting to get a bunch of these warnings, and I'm thinking they are false positives. The stack frame error is recorded at a call from entry_SYSCALL_64_fastpath, where I would expect the bp to not be valid. To trigger this, I only need to go into /sys/kernel/debug/tracing and echo

[RFC] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

Though migrating gigantic HugeTLB pages does not sound much like real world use case, they can be affected by memory errors. Hence migration at the PGD level HugeTLB pages should be supported just to enable soft and hard offline use cases. While allocating the new gigantic HugeTLB page, it should

[RFC] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

Though migrating gigantic HugeTLB pages does not sound much like real world use case, they can be affected by memory errors. Hence migration at the PGD level HugeTLB pages should be supported just to enable soft and hard offline use cases. While allocating the new gigantic HugeTLB page, it should

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin wrote: > On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: >> On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >>> Hi, >>> > Quite true that this proves nothing. However one should note that > fbcon

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin wrote: > On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: >> On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >>> Hi, >>> > Quite true that this proves nothing. However one should note that > fbcon -> fbdev works, BTW, this

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >> Hi, >> Quite true that this proves nothing. However one should note that fbcon -> fbdev works, >>> >>> BTW, this supports Gerd's patch, since the KMS fbdev

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >> Hi, >> Quite true that this proves nothing. However one should note that fbcon -> fbdev works, >>> >>> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses >>>

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/18/17 19:46, Steven Rostedt wrote: > On Tue, 18 Apr 2017 17:07:17 -0700 > Frank Rowand wrote: > > >> As far as I know, there is no easy way to combine trace data and printk() >> style data to create a single chronology of events. If some of the >> information

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/18/17 19:46, Steven Rostedt wrote: > On Tue, 18 Apr 2017 17:07:17 -0700 > Frank Rowand wrote: > > >> As far as I know, there is no easy way to combine trace data and printk() >> style data to create a single chronology of events. If some of the >> information needed to debug an issue is

  1   2   3   4   5   6   7   8   9   10   >