Re: [PATCH v8 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On Thu, Dec 7, 2017 at 5:04 PM, Dan Murphy wrote: > Rob > > > On 12/07/2017 04:49 PM, Rob Herring wrote: >> On Tue, Dec 05, 2017 at 02:46:29PM -0600, Dan Murphy wrote: >>> This adds the devicetree bindings for the LM3692x >>> I2C LED string driver. >>> >>> Acked-by: Pavel Machek >>>

[PATCH v2 2/2] acpi, x86: Use SPCR table for earlycon on x86

The ACPI SPCR code has been used to define an earlycon console for ARM64 and can be used for x86. Modify the ACPI SPCR parsing code to account for console behaviour differences between ARM64 and x86. Initialize the SPCR code from x86 ACPI initialization code. Signed-off-by: Prarit Bhargava Cc:

[PATCH v2 0/2] acpi, x86: Add SPCR table support

The SPCR (Serial Port Console Redirection) Table provides information about the configuration of the serial port. This information can be used to configure the early console. SPCR support was added for ARM64 and is made available across all arches in this patchset. The first patch adds a weak

[PATCH v2 0/2] acpi, x86: Add SPCR table support

The SPCR (Serial Port Console Redirection) Table provides information about the configuration of the serial port. This information can be used to configure the early console. SPCR support was added for ARM64 and is made available across all arches in this patchset. The first patch adds a weak

[PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

Other architectures can use SPCR to setup an early console or console but the current code is ARM64 specific. Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak function acpi_arch_setup_console() that can be used for arch-specific setup. Move flags into ACPI code. Update the

[PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

Other architectures can use SPCR to setup an early console or console but the current code is ARM64 specific. Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak function acpi_arch_setup_console() that can be used for arch-specific setup. Move flags into ACPI code. Update the

Re: dm: fix uninitialized variable reference

On Mon, Dec 11, 2017 at 2:50 PM, Mike Snitzer wrote: > On Mon, Dec 11 2017 at 6:33am -0500, > Arnd Bergmann wrote: >> > > Already resolved this thanks to Stephen Rothwell's earlier > (substantially more discrete) mail. > > I always enjoy a good public shaming

Re: dm: fix uninitialized variable reference

On Mon, Dec 11, 2017 at 2:50 PM, Mike Snitzer wrote: > On Mon, Dec 11 2017 at 6:33am -0500, > Arnd Bergmann wrote: >> > > Already resolved this thanks to Stephen Rothwell's earlier > (substantially more discrete) mail. > > I always enjoy a good public shaming but this cc list is particularly >

Re: [PATCH v2 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence

On 11.12.2017 16:45, Mauro Carvalho Chehab wrote: > Em Tue, 10 Oct 2017 23:36:55 +0200 > "Maciej S. Szmigiero" escreveu: > >> This patch prepares cxusb driver for supporting the analog part of >> Medion 95700 (previously only the digital - DVB - mode was supported).

Re: [PATCH v2 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence

On 11.12.2017 16:45, Mauro Carvalho Chehab wrote: > Em Tue, 10 Oct 2017 23:36:55 +0200 > "Maciej S. Szmigiero" escreveu: > >> This patch prepares cxusb driver for supporting the analog part of >> Medion 95700 (previously only the digital - DVB - mode was supported). >> >> Specifically, it adds

Re: [RFC] Sharing PMU counters across compatible events

Hello, Peter. On Wed, Dec 06, 2017 at 01:35:00PM +0100, Peter Zijlstra wrote: > On Fri, Dec 01, 2017 at 06:19:50AM -0800, Tejun Heo wrote: > > > What do you think? Would this be something worth pursuing? > > My worry with the whole thing is that it makes PMU scheduling _far_ more > expensive.

Re: [RFC] Sharing PMU counters across compatible events

Hello, Peter. On Wed, Dec 06, 2017 at 01:35:00PM +0100, Peter Zijlstra wrote: > On Fri, Dec 01, 2017 at 06:19:50AM -0800, Tejun Heo wrote: > > > What do you think? Would this be something worth pursuing? > > My worry with the whole thing is that it makes PMU scheduling _far_ more > expensive.

Re: [PATCH v2 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence

Em Tue, 10 Oct 2017 23:36:55 +0200 "Maciej S. Szmigiero" escreveu: > This patch prepares cxusb driver for supporting the analog part of > Medion 95700 (previously only the digital - DVB - mode was supported). > > Specifically, it adds support for: > * switching the

Re: [PATCH v2 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence

Em Tue, 10 Oct 2017 23:36:55 +0200 "Maciej S. Szmigiero" escreveu: > This patch prepares cxusb driver for supporting the analog part of > Medion 95700 (previously only the digital - DVB - mode was supported). > > Specifically, it adds support for: > * switching the device between analog and

[PATCH] block/sed-opal: Fix warnings never less than zero

Fixed following smatch warnings in sed-opal.c block/sed-opal.c:2311 opal_set_new_pw() warn: unsigned 'opal_pw->session.who' is never less than zero. Unless enum opal_user interface will remain stable warning could be fixed in mentioned way by removing unnecessary check Signed-off-by: Vasyl

[PATCH] block/sed-opal: Fix warnings never less than zero

Fixed following smatch warnings in sed-opal.c block/sed-opal.c:2311 opal_set_new_pw() warn: unsigned 'opal_pw->session.who' is never less than zero. Unless enum opal_user interface will remain stable warning could be fixed in mentioned way by removing unnecessary check Signed-off-by: Vasyl

Re: [PATCH] IPI performance benchmark

On Mon, Dec 11, 2017 at 05:16:00PM +0300, Yury Norov wrote: > This benchmark sends many IPIs in different modes and measures > time for IPI delivery (first column), and total time, ie including > time to acknowledge the receive by sender (second column). > > The scenarios are: > Dry-run: do

Re: [PATCH] IPI performance benchmark

On Mon, Dec 11, 2017 at 05:16:00PM +0300, Yury Norov wrote: > This benchmark sends many IPIs in different modes and measures > time for IPI delivery (first column), and total time, ie including > time to acknowledge the receive by sender (second column). > > The scenarios are: > Dry-run: do

[PATCH] ACPI, APEI, Fix use resource_size

Use resource_size function on resource object Underneath __request_region set res->end to start + n - 1 Lets use resourse_size to set value properly. Signed-off-by: Vasyl Gomonovych --- drivers/acpi/apei/apei-base.c | 13 ++--- 1 file changed, 6 insertions(+), 7

[PATCH] ACPI, APEI, Fix use resource_size

Use resource_size function on resource object Underneath __request_region set res->end to start + n - 1 Lets use resourse_size to set value properly. Signed-off-by: Vasyl Gomonovych --- drivers/acpi/apei/apei-base.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git

Re: [PATCH v2] perf test shell: Fix check open filename arg using 'perf trace

Em Fri, Dec 08, 2017 at 06:48:17PM +0100, Michael Petlan escreveu: > Hi Arnaldo, so I have tried what you've suggested and looks good. > Patch is attached. Sorry for not posting it in-text, but I need to > fix my mail client first, since it screwes some patches up due to > flowed-text... > Cheers,

Re: [PATCH v2] perf test shell: Fix check open filename arg using 'perf trace

Em Fri, Dec 08, 2017 at 06:48:17PM +0100, Michael Petlan escreveu: > Hi Arnaldo, so I have tried what you've suggested and looks good. > Patch is attached. Sorry for not posting it in-text, but I need to > fix my mail client first, since it screwes some patches up due to > flowed-text... > Cheers,

答复: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times

Hi James, Thanks for your review and suggestion. > Hi gengdongjiu, > > On 08/12/17 04:43, gengdongjiu wrote: > > by the way, I think also change the info.si_code to "BUS_MCEERR_AR" is > > better, as shown [1]. > > BUS_MCEERR_AR can tell user space "Hardware memory error consumed on a > >

答复: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times

Hi James, Thanks for your review and suggestion. > Hi gengdongjiu, > > On 08/12/17 04:43, gengdongjiu wrote: > > by the way, I think also change the info.si_code to "BUS_MCEERR_AR" is > > better, as shown [1]. > > BUS_MCEERR_AR can tell user space "Hardware memory error consumed on a > >

[RFC][PATCH] ipc: mqueue: wq_add priority changed to dynamic priority

Previous behavior added tasks to the work queue using the static_prio value instead of the dynamic priority value in prio. This caused RT tasks to be added to the work queue in a FIFO manner rather than by priority. Normal tasks were handled by priority. This fix utilizes the dynamic priority of

[RFC][PATCH] ipc: mqueue: wq_add priority changed to dynamic priority

Previous behavior added tasks to the work queue using the static_prio value instead of the dynamic priority value in prio. This caused RT tasks to be added to the work queue in a FIFO manner rather than by priority. Normal tasks were handled by priority. This fix utilizes the dynamic priority of

Re: [PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

On 2017-12-08 13:15:24 [-0500], Steven Rostedt wrote: > On Mon, 4 Dec 2017 09:45:45 +0100 > Sebastian Andrzej Siewior wrote: > > > On 2017-12-01 20:36:59 [-0500], Steven Rostedt wrote: > > > 4.4.102-rt117-rc1 stable review patch. > > > If anyone has any objections, please

Re: [PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

On 2017-12-08 13:15:24 [-0500], Steven Rostedt wrote: > On Mon, 4 Dec 2017 09:45:45 +0100 > Sebastian Andrzej Siewior wrote: > > > On 2017-12-01 20:36:59 [-0500], Steven Rostedt wrote: > > > 4.4.102-rt117-rc1 stable review patch. > > > If anyone has any objections, please let me know. > > > >

Re: [RFC] Sharing PMU counters across compatible events

Hello, Jiri. On Wed, Dec 06, 2017 at 12:42:04PM +0100, Jiri Olsa wrote: > I see this rather on the hw level, since it concerns HW counters > > I think we could detect same (alias) events at the time counters > are added/removed on/from the cpu and share their HW part like > counter idx, regs and

Re: [RFC] Sharing PMU counters across compatible events

Hello, Jiri. On Wed, Dec 06, 2017 at 12:42:04PM +0100, Jiri Olsa wrote: > I see this rather on the hw level, since it concerns HW counters > > I think we could detect same (alias) events at the time counters > are added/removed on/from the cpu and share their HW part like > counter idx, regs and

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

Hello, Prateek. On Fri, Dec 08, 2017 at 05:15:55PM +0530, Prateek Sood wrote: > There is one deadlock issue during cgroup migration from cpu > hotplug path when a task T is being moved from source to > destination cgroup. > > kworker/0:0 > cpuset_hotplug_workfn() >

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

Hello, Prateek. On Fri, Dec 08, 2017 at 05:15:55PM +0530, Prateek Sood wrote: > There is one deadlock issue during cgroup migration from cpu > hotplug path when a task T is being moved from source to > destination cgroup. > > kworker/0:0 > cpuset_hotplug_workfn() >

Oops on 4.15-rc[123] on shutdown/reboot

I've been getting an oops when shutting down my laptop (with /sbin/halt) or rebooting it (/sbin/reboot or /usr/sbin/kexec). Unfortunately, I can't provide the backtrace because it is on the screen for only a moment before the system shuts down/reboots. I have however, bisected it and the

Oops on 4.15-rc[123] on shutdown/reboot

I've been getting an oops when shutting down my laptop (with /sbin/halt) or rebooting it (/sbin/reboot or /usr/sbin/kexec). Unfortunately, I can't provide the backtrace because it is on the screen for only a moment before the system shuts down/reboots. I have however, bisected it and the

Re: [PATCH v2 1/6] cx25840: add pin to pad mapping and output format configuration

Em Tue, 10 Oct 2017 23:34:45 +0200 "Maciej S. Szmigiero" escreveu: > This commit adds pin to pad mapping and output format configuration support > in CX2584x-series chips to cx25840 driver. > > This functionality is then used to allow disabling ivtv-specific hacks >

Re: [PATCH v2 1/6] cx25840: add pin to pad mapping and output format configuration

Em Tue, 10 Oct 2017 23:34:45 +0200 "Maciej S. Szmigiero" escreveu: > This commit adds pin to pad mapping and output format configuration support > in CX2584x-series chips to cx25840 driver. > > This functionality is then used to allow disabling ivtv-specific hacks > (called a "generic mode"),

Re: [PATCH v1 2/2] drm/tegra: Support disabled CONFIG_PM

On 11.12.2017 17:27, Thierry Reding wrote: > On Mon, Dec 11, 2017 at 04:53:56PM +0300, Dmitry Osipenko wrote: >> On 11.12.2017 13:13, Thierry Reding wrote: >>> On Mon, Dec 11, 2017 at 02:19:44AM +0300, Dmitry Osipenko wrote: Add manual HW power management to drivers probe/remove in order to

Re: [PATCH v1 2/2] drm/tegra: Support disabled CONFIG_PM

On 11.12.2017 17:27, Thierry Reding wrote: > On Mon, Dec 11, 2017 at 04:53:56PM +0300, Dmitry Osipenko wrote: >> On 11.12.2017 13:13, Thierry Reding wrote: >>> On Mon, Dec 11, 2017 at 02:19:44AM +0300, Dmitry Osipenko wrote: Add manual HW power management to drivers probe/remove in order to

Re: [PATCH v5] kernel: make groups_sort calling a responsibility group_info allocators

On Mon, Dec 11, 2017 at 01:14:20PM -0200, Thiago Rafael Becker wrote: > In testing, we found that nfsd threads may call set_groups in parallel for > the same entry cached in auth.unix.gid, racing in the call of groups_sort, > corrupting the groups for that entry and leading to permission denials

Re: [PATCH v5] kernel: make groups_sort calling a responsibility group_info allocators

On Mon, Dec 11, 2017 at 01:14:20PM -0200, Thiago Rafael Becker wrote: > In testing, we found that nfsd threads may call set_groups in parallel for > the same entry cached in auth.unix.gid, racing in the call of groups_sort, > corrupting the groups for that entry and leading to permission denials

Re: [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

* H. Nikolaus Schaller [171201 07:44]: > Official vendor string is now "tpo" and not "toppoly". > > Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1" > so that the driver understands both. Tomi, so what's the plan with the dependency patch, is that

Re: [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

* H. Nikolaus Schaller [171201 07:44]: > Official vendor string is now "tpo" and not "toppoly". > > Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1" > so that the driver understands both. Tomi, so what's the plan with the dependency patch, is that for v4.16 or for

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

On 12/11/2017 05:08 PM, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 3:46 PM, Pavel Emelyanov wrote: >> On 12/11/2017 10:05 AM, Amir Goldstein wrote: >>> On Mon, Dec 11, 2017 at 8:41 AM, Amir Goldstein wrote: On Mon, Dec 11, 2017 at 8:04 AM,

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

On 12/11/2017 05:08 PM, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 3:46 PM, Pavel Emelyanov wrote: >> On 12/11/2017 10:05 AM, Amir Goldstein wrote: >>> On Mon, Dec 11, 2017 at 8:41 AM, Amir Goldstein wrote: On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown wrote: > If a filesystem does

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

Hello, Peter. On Tue, Dec 05, 2017 at 12:01:17AM +0100, Peter Zijlstra wrote: > > AFAICS, this should remove the circular dependency you originally > > reported. I'll revert the two cpuset commits for now. > > So I liked his patches in that we would be able to go back to > synchronous

Re: [PATCH] cgroup/cpuset: fix circular locking dependency

Hello, Peter. On Tue, Dec 05, 2017 at 12:01:17AM +0100, Peter Zijlstra wrote: > > AFAICS, this should remove the circular dependency you originally > > reported. I'll revert the two cpuset commits for now. > > So I liked his patches in that we would be able to go back to > synchronous

Re: [PATCH v7 22/37] tracing: Add variable reference handling to hist triggers

Hi Tom, On Wed, Dec 06, 2017 at 04:38:03PM -0600, Tom Zanussi wrote: > Add the necessary infrastructure to allow the variables defined on one > event to be referenced in another. This allows variables set by a > previous event to be referenced and used in expressions combining the > variable

Re: [PATCH v7 22/37] tracing: Add variable reference handling to hist triggers

Hi Tom, On Wed, Dec 06, 2017 at 04:38:03PM -0600, Tom Zanussi wrote: > Add the necessary infrastructure to allow the variables defined on one > event to be referenced in another. This allows variables set by a > previous event to be referenced and used in expressions combining the > variable

[PATCH v8 2/9] x86/early-quirks: export the stolen region as a resource

We duplicate the stolen discovery code in early-quirks and in i915, however if we just export the region as a resource from early-quirks we can nuke the duplication. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä

[PATCH v8 2/9] x86/early-quirks: export the stolen region as a resource

We duplicate the stolen discovery code in early-quirks and in i915, however if we just export the region as a resource from early-quirks we can nuke the duplication. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris Wilson Cc: Paulo Zanoni Cc: Thomas Gleixner Cc:

[PATCH v8 3/9] x86/early-quirks: replace the magical increment start values

Replace the magical +2, +9 etc. with +MB, which is far easier to read. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris

[PATCH v8 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

From: Joonas Lahtinen To give upcoming SKU BIOSes more flexibility in placing the Intel graphics stolen memory, make all variables storing the placement or size compatible with full 64 bit range. Signed-off-by: Joonas Lahtinen

[PATCH v8 3/9] x86/early-quirks: replace the magical increment start values

Replace the magical +2, +9 etc. with +MB, which is far easier to read. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris Wilson Cc: Paulo Zanoni Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Cc: x...@kernel.org Cc:

[PATCH v8 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

From: Joonas Lahtinen To give upcoming SKU BIOSes more flexibility in placing the Intel graphics stolen memory, make all variables storing the placement or size compatible with full 64 bit range. Signed-off-by: Joonas Lahtinen Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä

Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver

On Mon, Dec 11, 2017 at 06:21:58PM +0900, Katsuhiro Suzuki wrote: > But I can't find how to use/map this DAI in machine driver or Device-Tree or > something. I think that it's same as PCM DAI, am I correct? Yes, that probably makes sense from a binding point of view. > I read

Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver

On Mon, Dec 11, 2017 at 06:21:58PM +0900, Katsuhiro Suzuki wrote: > But I can't find how to use/map this DAI in machine driver or Device-Tree or > something. I think that it's same as PCM DAI, am I correct? Yes, that probably makes sense from a binding point of view. > I read

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

* Tomi Valkeinen [171201 02:03]: > On 01/12/17 11:48, H. Nikolaus Schaller wrote: > > > Just a note: there is no toppoly->tpo change for *this* panel and > > Pandora board. Just omapdss removal. > > > > The GTA04 needs a toppoly->tpo change but no omapdss, removal. > > >

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

* Tomi Valkeinen [171201 02:03]: > On 01/12/17 11:48, H. Nikolaus Schaller wrote: > > > Just a note: there is no toppoly->tpo change for *this* panel and > > Pandora board. Just omapdss removal. > > > > The GTA04 needs a toppoly->tpo change but no omapdss, removal. > > > > So they solve

Re: [PATCH 7/9] workqueue: remove unneeded kallsyms include

On Fri, Dec 08, 2017 at 11:56:14AM +0900, Sergey Senozhatsky wrote: > The filw was converted from print_symbol() to %pf some time > ago (044c782ce3a901fb "workqueue: fix checkpatch issues"). > kallsyms does not seem to be needed anymore. > > Signed-off-by: Sergey Senozhatsky

Re: [PATCH 7/9] workqueue: remove unneeded kallsyms include

On Fri, Dec 08, 2017 at 11:56:14AM +0900, Sergey Senozhatsky wrote: > The filw was converted from print_symbol() to %pf some time > ago (044c782ce3a901fb "workqueue: fix checkpatch issues"). > kallsyms does not seem to be needed anymore. > > Signed-off-by: Sergey Senozhatsky > Cc: Tejun Heo >

[PATCH v5] kernel: make groups_sort calling a responsibility group_info allocators

In testing, we found that nfsd threads may call set_groups in parallel for the same entry cached in auth.unix.gid, racing in the call of groups_sort, corrupting the groups for that entry and leading to permission denials for the client. This patch: - Make groups_sort globally visible. - Move

[PATCH v5] kernel: make groups_sort calling a responsibility group_info allocators

In testing, we found that nfsd threads may call set_groups in parallel for the same entry cached in auth.unix.gid, racing in the call of groups_sort, corrupting the groups for that entry and leading to permission denials for the client. This patch: - Make groups_sort globally visible. - Move

Re: [RFC][PATCHv2] Fixing POSIX wait queue to insert in task priority order for real-time, including normal tasks

> OK, when I said to Cc the kernel mailing list, I should have said > that you > also need to still Cc everyone you want to read it. LKML gets over > 600+ emails > a day. Nobody reads it all. Some people filter it, but others (like > myself) > stopped reading it because I can barely keep up with

Re: [RFC][PATCHv2] Fixing POSIX wait queue to insert in task priority order for real-time, including normal tasks

> OK, when I said to Cc the kernel mailing list, I should have said > that you > also need to still Cc everyone you want to read it. LKML gets over > 600+ emails > a day. Nobody reads it all. Some people filter it, but others (like > myself) > stopped reading it because I can barely keep up with

Re: [PATCH] Fix resume on x86-32 machines

* Andy Lutomirski wrote: > > > > On Dec 10, 2017, at 1:38 PM, Pavel Machek wrote: > > > > > > After 4.15-rc2, suspend stopped working on Thinkpad X60. 5b06bbc > > (unintentionally?) reordered stuff with respect to > > fix_processor_context() on 32-bit and

Re: [PATCH] Fix resume on x86-32 machines

* Andy Lutomirski wrote: > > > > On Dec 10, 2017, at 1:38 PM, Pavel Machek wrote: > > > > > > After 4.15-rc2, suspend stopped working on Thinkpad X60. 5b06bbc > > (unintentionally?) reordered stuff with respect to > > fix_processor_context() on 32-bit and 64-bit. We undo that change on > >

Re: RFC(v2): Audit Kernel Container IDs

On 2017-12-09 11:20, Mickaël Salaün wrote: > > On 12/10/2017 18:33, Casey Schaufler wrote: > > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: > >> Containers are a userspace concept. The kernel knows nothing of them. > >> > >> The Linux audit system needs a way to be able to track the

Re: RFC(v2): Audit Kernel Container IDs

On 2017-12-09 11:20, Mickaël Salaün wrote: > > On 12/10/2017 18:33, Casey Schaufler wrote: > > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: > >> Containers are a userspace concept. The kernel knows nothing of them. > >> > >> The Linux audit system needs a way to be able to track the

Re: [PATCH] cgroup: avoid cgroup root name longer than max

On Fri, Dec 08, 2017 at 04:47:46PM +0800, Ma Shimiao wrote: > cgroup root name has max length limit, we should avoid copying > longer name than that to the name. > > Signed-off-by: Ma Shimiao > --- > kernel/cgroup/cgroup.c | 2 +- > 1 file changed, 1 insertion(+),

Re: [PATCH] cgroup: avoid cgroup root name longer than max

On Fri, Dec 08, 2017 at 04:47:46PM +0800, Ma Shimiao wrote: > cgroup root name has max length limit, we should avoid copying > longer name than that to the name. > > Signed-off-by: Ma Shimiao > --- > kernel/cgroup/cgroup.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH v5] pata_pdc2027x: Fix pdc_adjust_pll() to return the error value

On Wed, Dec 06, 2017 at 10:52:54PM +0530, Arvind Yadav wrote: > This change is to ensure that function pdc_adjust_pll() returns the > error value to avoid the unnecessary error check for pdc_hardware_init() > in pdc2027x_reinit_one(). > > Signed-off-by: Arvind Yadav

Re: [PATCH v5] pata_pdc2027x: Fix pdc_adjust_pll() to return the error value

On Wed, Dec 06, 2017 at 10:52:54PM +0530, Arvind Yadav wrote: > This change is to ensure that function pdc_adjust_pll() returns the > error value to avoid the unnecessary error check for pdc_hardware_init() > in pdc2027x_reinit_one(). > > Signed-off-by: Arvind Yadav Doesn't apply on

Re: [PATCH] tuners: tda8290: reduce stack usage with kasan

On Mon, Dec 11, 2017 at 7:06 AM, Arnd Bergmann wrote: > With CONFIG_KASAN enabled, we get a relatively large stack frame in one > function > > drivers/media/tuners/tda8290.c: In function 'tda8290_set_params': > drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520

Re: [PATCH] tuners: tda8290: reduce stack usage with kasan

On Mon, Dec 11, 2017 at 7:06 AM, Arnd Bergmann wrote: > With CONFIG_KASAN enabled, we get a relatively large stack frame in one > function > > drivers/media/tuners/tda8290.c: In function 'tda8290_set_params': > drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes > is

Re: [PATCH] cgroup: limit max copied char length for cgroup file name

On Sat, Dec 09, 2017 at 01:47:58PM +0800, Ma Shimiao wrote: > the result of cgroup_file_name will be used by kernfs_remove_name, > and then by kernfs_remove_by_name_ns(). > If reached the max length, may have problem printed by WARN() in > kernfs_remove_by_name_ns(). > > Signed-off-by: Ma Shimiao

Re: [PATCH] cgroup: limit max copied char length for cgroup file name

On Sat, Dec 09, 2017 at 01:47:58PM +0800, Ma Shimiao wrote: > the result of cgroup_file_name will be used by kernfs_remove_name, > and then by kernfs_remove_by_name_ns(). > If reached the max length, may have problem printed by WARN() in > kernfs_remove_by_name_ns(). > > Signed-off-by: Ma Shimiao

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

Hi Sakari, On Friday, 17 November 2017 02:36:51 EET Sakari Ailus wrote: > On Wed, Nov 15, 2017 at 03:25:11PM +0100, jacopo mondi wrote: > > On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote: > >> Hi Jacopo, > >> > >> Could you remove the original driver and send the patch using git >

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

Hi Sakari, On Friday, 17 November 2017 02:36:51 EET Sakari Ailus wrote: > On Wed, Nov 15, 2017 at 03:25:11PM +0100, jacopo mondi wrote: > > On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote: > >> Hi Jacopo, > >> > >> Could you remove the original driver and send the patch using git >

[PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB

Xen hides a bit of system memory from the OS for its own purpose by intercepting e820. This memory is unfortunately not reported as reserved, but rather completely invisible. Avoid this address space collision and possible similar problems by limiting the size of the newly allocated root hub

[PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB

Xen hides a bit of system memory from the OS for its own purpose by intercepting e820. This memory is unfortunately not reported as reserved, but rather completely invisible. Avoid this address space collision and possible similar problems by limiting the size of the newly allocated root hub

Re: [PATCH v2 4/4] crypto: exynos - Introduce mutex to prevent concurrent access to hardware

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > > > Hardware operations like reading random numbers and setting a seed need > to be conducted in a single

Re: [PATCH v2 4/4] crypto: exynos - Introduce mutex to prevent concurrent access to hardware

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > > > Hardware operations like reading random numbers and setting a seed need > to be conducted in a single thread. Therefore a mutex is required to > prevent multiple threads (processes)

Re: [PATCH v1 1/2] drm/tegra: dc: Link DC1 to DC0 on Tegra20

On 11.12.2017 13:12, Thierry Reding wrote: > On Mon, Dec 11, 2017 at 02:19:43AM +0300, Dmitry Osipenko wrote: >> HW reset isn't actually broken on Tegra20, but there is a dependency on >> first display controller to be taken out of reset for the second to be >> enabled successfully. >> >>

Re: [PATCH v1 1/2] drm/tegra: dc: Link DC1 to DC0 on Tegra20

On 11.12.2017 13:12, Thierry Reding wrote: > On Mon, Dec 11, 2017 at 02:19:43AM +0300, Dmitry Osipenko wrote: >> HW reset isn't actually broken on Tegra20, but there is a dependency on >> first display controller to be taken out of reset for the second to be >> enabled successfully. >> >>

Re: [PATCH] Fix resume on x86-32 machines

On 12/11/2017 04:22 PM, Rafael J. Wysocki wrote: On Sunday, December 10, 2017 10:58:23 PM CET Andy Lutomirski wrote: On Dec 10, 2017, at 1:38 PM, Pavel Machek wrote: After 4.15-rc2, suspend stopped working on Thinkpad X60. 5b06bbc (unintentionally?) reordered stuff with

Re: [PATCH] Fix resume on x86-32 machines

On 12/11/2017 04:22 PM, Rafael J. Wysocki wrote: On Sunday, December 10, 2017 10:58:23 PM CET Andy Lutomirski wrote: On Dec 10, 2017, at 1:38 PM, Pavel Machek wrote: After 4.15-rc2, suspend stopped working on Thinkpad X60. 5b06bbc (unintentionally?) reordered stuff with respect to

RE: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

From: Logan Gunthorpe > With Switchtec hardware, the buffer used for a memory window must be > aligned to its size (the hardware only replaces the lower bits). In > certain circumstances dma_alloc_coherent() will not provide a buffer > that adheres to this requirement like when using the CMA and >

RE: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

From: Logan Gunthorpe > With Switchtec hardware, the buffer used for a memory window must be > aligned to its size (the hardware only replaces the lower bits). In > certain circumstances dma_alloc_coherent() will not provide a buffer > that adheres to this requirement like when using the CMA and >

[PATCH] sparc32,leon: Use CASA when available for atomic operations

This probes for CASA support, that is commonly present in LEON processors, and when available, uses the CASA instruction for atomic operations rather than the spinlock based emulated atomic operations. All CASA instructions are encoded using .word to be able to assemble for v8. Signed-off-by:

[PATCH] sparc32,leon: Use CASA when available for atomic operations

This probes for CASA support, that is commonly present in LEON processors, and when available, uses the CASA instruction for atomic operations rather than the spinlock based emulated atomic operations. All CASA instructions are encoded using .word to be able to assemble for v8. Signed-off-by:

Re: [PATCH v2 3/4] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > Same as in 1/4 and 2/4. > > Reseed PRNG after reading 65 kB of randomness. Although this may reduce >

Re: [PATCH v2 3/4] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote: > Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz > Same as in 1/4 and 2/4. > > Reseed PRNG after reading 65 kB of randomness. Although this may reduce > performance, in most cases the loss is not noticeable. You missed the comment

Re: [PATCH] IPI performance benchmark

On Mon, Dec 11, 2017 at 03:35:02PM +0100, Christian Borntraeger wrote: > > > On 12/11/2017 03:16 PM, Yury Norov wrote: > > This benchmark sends many IPIs in different modes and measures > > time for IPI delivery (first column), and total time, ie including > > time to acknowledge the receive by

Re: [PATCH] IPI performance benchmark

On Mon, Dec 11, 2017 at 03:35:02PM +0100, Christian Borntraeger wrote: > > > On 12/11/2017 03:16 PM, Yury Norov wrote: > > This benchmark sends many IPIs in different modes and measures > > time for IPI delivery (first column), and total time, ie including > > time to acknowledge the receive by

Re: [PATCH v2 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

2017-12-06 22:13 GMT+01:00 Heiner Kallweit : > Currently i2c_new_device and i2c_new_dummy return just NULL in error > case although they have more error details internally. Therefore move > the functionality into new functions returning detailed errors and > add wrappers for

Re: [PATCH v2 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

2017-12-06 22:13 GMT+01:00 Heiner Kallweit : > Currently i2c_new_device and i2c_new_dummy return just NULL in error > case although they have more error details internally. Therefore move > the functionality into new functions returning detailed errors and > add wrappers for compatibilty with the

RE: [PATCH 1/2] ntb_transport: Fix bug with max_mw_size parameter

From: Logan Gunthorpe > When using the max_mw_size parameter of ntb_transport to limit the size of > the Memory windows, communication cannot be established and the queues > freeze. > > This is because the mw_size that's reported to the peer is correctly > limited but the size used locally is

RE: [PATCH 1/2] ntb_transport: Fix bug with max_mw_size parameter

From: Logan Gunthorpe > When using the max_mw_size parameter of ntb_transport to limit the size of > the Memory windows, communication cannot be established and the queues > freeze. > > This is because the mw_size that's reported to the peer is correctly > limited but the size used locally is

Re: [PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies

Hi Jacopo, Thank you for the patch. On Wednesday, 15 November 2017 12:56:03 EET Jacopo Mondi wrote: > Remove soc_camera framework dependencies from tw9910 sensor driver. > - Handle clock directly > - Register async subdevice > - Add platform specific enable/disable functions > - Adjust build

Re: [PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies

Hi Jacopo, Thank you for the patch. On Wednesday, 15 November 2017 12:56:03 EET Jacopo Mondi wrote: > Remove soc_camera framework dependencies from tw9910 sensor driver. > - Handle clock directly > - Register async subdevice > - Add platform specific enable/disable functions > - Adjust build

<    6   7   8   9   10   11   12   13   14   15   >