Re: [PATCH v1 1/4] dt-bindings: gpu: mali-utgard: add mediatek,mt7623-mali compatible

On Wed, Apr 18, 2018 at 06:24:53PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it > and define its own vendor-specific properties. > > Signed-off-by: Sean Wang >

Re: [PATCH v1 1/4] dt-bindings: gpu: mali-utgard: add mediatek,mt7623-mali compatible

On Wed, Apr 18, 2018 at 06:24:53PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it > and define its own vendor-specific properties. > > Signed-off-by: Sean Wang > --- >

[PATCH 2/7] genirq/debugfs: Use irq_print_chip method if available

If an irqchip has provided an irq_print_chip method, let's use it instead of the name field directly. Signed-off-by: Marc Zyngier --- kernel/irq/debugfs.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c

[PATCH 2/7] genirq/debugfs: Use irq_print_chip method if available

If an irqchip has provided an irq_print_chip method, let's use it instead of the name field directly. Signed-off-by: Marc Zyngier --- kernel/irq/debugfs.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c index

[PATCH 3/7] genirq/debugfs: Allow irq domain name to be overriden

As for irqchip, it would be useful for a domain to generate its name dynamically, and thus control the name that gets used in debugfs. Signed-off-by: Marc Zyngier --- include/linux/irqdomain.h | 1 + kernel/irq/irqdomain.c| 14 ++ 2 files changed, 15

[PATCH 3/7] genirq/debugfs: Allow irq domain name to be overriden

As for irqchip, it would be useful for a domain to generate its name dynamically, and thus control the name that gets used in debugfs. Signed-off-by: Marc Zyngier --- include/linux/irqdomain.h | 1 + kernel/irq/irqdomain.c| 14 ++ 2 files changed, 15 insertions(+) diff --git

[PATCH 7/7] irqchip/partition-percpu: Move allocation of chained interrupt to activate

The partition-percpu helpers work by tying the real interrupt to an affinity-driven chained irqchip. So far, all the interrupt that can be partitionned are being created at boot time. This is a waste of resource, and means that we need to bypass some of the critical checks (such as the trigger

[PATCH 7/7] irqchip/partition-percpu: Move allocation of chained interrupt to activate

The partition-percpu helpers work by tying the real interrupt to an affinity-driven chained irqchip. So far, all the interrupt that can be partitionned are being created at boot time. This is a waste of resource, and means that we need to bypass some of the critical checks (such as the trigger

[PATCH 6/7] irqchip/partition-percpu: Allow chained_desc to be NULL

As we're about to delay the binding of the partionned interrupt to the underlying irqchip, we can end-up in a situation where chained_desc will be NULL, and the operation cannot be carried out. Let's make sure we don't explode if that happens. Signed-off-by: Marc Zyngier

[PATCH 6/7] irqchip/partition-percpu: Allow chained_desc to be NULL

As we're about to delay the binding of the partionned interrupt to the underlying irqchip, we can end-up in a situation where chained_desc will be NULL, and the operation cannot be carried out. Let's make sure we don't explode if that happens. Signed-off-by: Marc Zyngier ---

[PATCH 0/7] Partitioned percpu IRQ rework

Partitioned percpu interrupts are a very niche sport, even in the ARM world. They occur when each CPU have a private device connected to a per-CPU interrupt, but not all the devices are the same. The best example of this occurs on the Rockchip rk3399 SoC, where all the CPUs have a PMU connected

[PATCH 0/7] Partitioned percpu IRQ rework

Partitioned percpu interrupts are a very niche sport, even in the ARM world. They occur when each CPU have a private device connected to a per-CPU interrupt, but not all the devices are the same. The best example of this occurs on the Rockchip rk3399 SoC, where all the CPUs have a PMU connected

[PATCH 4/7] irqchip/partition-percpu: Override domain name in debugfs

So far, domain names that implement a percpu_devid partition inherit the main domain name, which leads to conflicts in debugfs and results in the absence of important data. Let's provide a callback that will repaint the default name, and keep all the data available. Signed-off-by: Marc Zyngier

[PATCH 4/7] irqchip/partition-percpu: Override domain name in debugfs

So far, domain names that implement a percpu_devid partition inherit the main domain name, which leads to conflicts in debugfs and results in the absence of important data. Let's provide a callback that will repaint the default name, and keep all the data available. Signed-off-by: Marc Zyngier

[PATCH 5/7] irqchip/partition-percpu: Refactor backend method calling

The various methods provided by the partition-percpu irqchip are only wrappers that end-up calling into the underlying irqchip. As we're about to change the code a bit, let's start with introducing a set of helpers that will make that transition much more painless. No functionnal change.

Re: [PATCH v2] mm: introduce memory.min

Hi Vladimir! > On Mon, Apr 23, 2018 at 01:36:10PM +0100, Roman Gushchin wrote: > > + memory.min > > + A read-write single value file which exists on non-root > > + cgroups. The default is "0". > > + > > + Hard memory protection. If the memory usage of a cgroup > > + is within its

[PATCH 5/7] irqchip/partition-percpu: Refactor backend method calling

The various methods provided by the partition-percpu irqchip are only wrappers that end-up calling into the underlying irqchip. As we're about to change the code a bit, let's start with introducing a set of helpers that will make that transition much more painless. No functionnal change.

Re: [PATCH v2] mm: introduce memory.min

Hi Vladimir! > On Mon, Apr 23, 2018 at 01:36:10PM +0100, Roman Gushchin wrote: > > + memory.min > > + A read-write single value file which exists on non-root > > + cgroups. The default is "0". > > + > > + Hard memory protection. If the memory usage of a cgroup > > + is within its

Re: [PATCH 1/3] big key: get rid of stack array allocation

Hi Eric, On Mon, Apr 23, 2018 at 09:50:15PM -0700, Eric Biggers wrote: > Hi Tycho, > > On Mon, Apr 23, 2018 at 07:03:19PM -0600, Tycho Andersen wrote: > > We're interested in getting rid of all of the stack allocated arrays in the > > kernel [1]. This patch simply hardcodes the iv length to

Re: [PATCH 1/3] big key: get rid of stack array allocation

Hi Eric, On Mon, Apr 23, 2018 at 09:50:15PM -0700, Eric Biggers wrote: > Hi Tycho, > > On Mon, Apr 23, 2018 at 07:03:19PM -0600, Tycho Andersen wrote: > > We're interested in getting rid of all of the stack allocated arrays in the > > kernel [1]. This patch simply hardcodes the iv length to

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On Tue, 24 Apr 2018 16:29:15 +0200, Oleksandr Andrushchenko wrote: > > On 04/24/2018 05:20 PM, Takashi Iwai wrote: > > On Mon, 16 Apr 2018 08:24:51 +0200, > > Oleksandr Andrushchenko wrote: > >> +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) > >> +{ > >> + struct

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On Tue, 24 Apr 2018 16:29:15 +0200, Oleksandr Andrushchenko wrote: > > On 04/24/2018 05:20 PM, Takashi Iwai wrote: > > On Mon, 16 Apr 2018 08:24:51 +0200, > > Oleksandr Andrushchenko wrote: > >> +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) > >> +{ > >> + struct

Re: [PATCH 9/9] Protect SELinux initialized state with pmalloc

On 24/04/18 16:49, Stephen Smalley wrote: On 04/23/2018 08:54 AM, Igor Stoppa wrote: [...] The patch is probably in need of rework, to make it fit better with the new SELinux internal data structures, however it shows how to deny an easy target to the attacker. I know this is just an

Re: [PATCH 9/9] Protect SELinux initialized state with pmalloc

On 24/04/18 16:49, Stephen Smalley wrote: On 04/23/2018 08:54 AM, Igor Stoppa wrote: [...] The patch is probably in need of rework, to make it fit better with the new SELinux internal data structures, however it shows how to deny an easy target to the attacker. I know this is just an

Re: [PATCH] ftrace/x86: Fix arch_syscall_match_sym_name for x86_64

On Tue, 24 Apr 2018 12:17:38 +0200 Jiri Olsa wrote: > Recent commit changed the name prefix of syscalls > for x86_64 (check the 'Fixes:' for commit number). > > The names switch from "sys_" prefix to ""__x64_sys_", > which made the default matching function always fail. > >

Re: [PATCH] ftrace/x86: Fix arch_syscall_match_sym_name for x86_64

On Tue, 24 Apr 2018 12:17:38 +0200 Jiri Olsa wrote: > Recent commit changed the name prefix of syscalls > for x86_64 (check the 'Fixes:' for commit number). > > The names switch from "sys_" prefix to ""__x64_sys_", > which made the default matching function always fail. > > Consequently the

Re: [PATCH] clk: qcom: Add some missing gcc clks for msm8996

On Tue, Apr 17, 2018 at 05:09:26PM -0700, Bjorn Andersson wrote: > From: Rajendra Nayak > > Add a few missing gcc clks for msm8996 > > Signed-off-by: Rajendra Nayak > [bjorn: omit aggre0_noc_qosgen_extref_clk] > Signed-off-by: Bjorn Andersson

Re: [PATCH] clk: qcom: Add some missing gcc clks for msm8996

On Tue, Apr 17, 2018 at 05:09:26PM -0700, Bjorn Andersson wrote: > From: Rajendra Nayak > > Add a few missing gcc clks for msm8996 > > Signed-off-by: Rajendra Nayak > [bjorn: omit aggre0_noc_qosgen_extref_clk] > Signed-off-by: Bjorn Andersson > --- > > This patch was accompanied by one that

Re: [PATCH v2 13/13] media: imx274: add SELECTION support for cropping

Hi Sakari, On 24/04/2018 11:59, Sakari Ailus wrote: > Hi Luca, > > Thank you for the patchset. > > Some comments below... what I propose is that I apply the rest of the > patches and then the comments to this one could be addressed separately. > Would that work for you? Yes, but I suggest you

Re: [PATCH v2 13/13] media: imx274: add SELECTION support for cropping

Hi Sakari, On 24/04/2018 11:59, Sakari Ailus wrote: > Hi Luca, > > Thank you for the patchset. > > Some comments below... what I propose is that I apply the rest of the > patches and then the comments to this one could be addressed separately. > Would that work for you? Yes, but I suggest you

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On 04/24/2018 05:20 PM, Takashi Iwai wrote: On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ + struct xen_snd_front_evtchnl *channel = dev_id; + struct xen_snd_front_info *front_info =

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On 04/24/2018 05:20 PM, Takashi Iwai wrote: On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ + struct xen_snd_front_evtchnl *channel = dev_id; + struct xen_snd_front_info *front_info =

Re: kernel BUG at fs/f2fs/node.c:LINE!

On Tue, Apr 24, 2018 at 8:42 AM, syzbot wrote: > Hello, > > syzbot tried to test the proposed patch but build/boot failed: > > failed to create VM pool: failed to create GCE image: failed to get create > image operation

Re: kernel BUG at fs/f2fs/node.c:LINE!

On Tue, Apr 24, 2018 at 8:42 AM, syzbot wrote: > Hello, > > syzbot tried to test the proposed patch but build/boot failed: > > failed to create VM pool: failed to create GCE image: failed to get create > image operation operation-1524552040215-56a926ecc71d9-3edfeb8b-8abca81c: > googleapi: Error

Re: [PATCH 02/39] proc: introduce proc_create_seq{,_data}

On Thu, Apr 19, 2018 at 09:41:06PM +0300, Alexey Dobriyan wrote: > Should be oopsable. > Once proc_create_data() returns, entry is live, ->open can be called. Ok, switching to opencoding proc_create_data instead.

Re: [PATCH 02/39] proc: introduce proc_create_seq{,_data}

On Thu, Apr 19, 2018 at 09:41:06PM +0300, Alexey Dobriyan wrote: > Should be oopsable. > Once proc_create_data() returns, entry is live, ->open can be called. Ok, switching to opencoding proc_create_data instead.

Re: [PATCH 03/39] proc: introduce proc_create_seq_private

On Thu, Apr 19, 2018 at 09:50:27PM +0300, Alexey Dobriyan wrote: > On Thu, Apr 19, 2018 at 02:41:04PM +0200, Christoph Hellwig wrote: > > Variant of proc_create_data that directly take a struct seq_operations > > > --- a/fs/proc/internal.h > > +++ b/fs/proc/internal.h > > @@ -45,6 +45,7 @@ struct

Re: [PATCH 03/39] proc: introduce proc_create_seq_private

On Thu, Apr 19, 2018 at 09:50:27PM +0300, Alexey Dobriyan wrote: > On Thu, Apr 19, 2018 at 02:41:04PM +0200, Christoph Hellwig wrote: > > Variant of proc_create_data that directly take a struct seq_operations > > > --- a/fs/proc/internal.h > > +++ b/fs/proc/internal.h > > @@ -45,6 +45,7 @@ struct

Re: [PATCH] Bluetooth: btusb: add ID for LiteOn 04ca:301a

Hi Matthias, > Contains a QCA6174A chipset, with USB BT. Let's support loading > firmware on it. > > From usb-devices: > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=04ca ProdID=301a Rev= 0.01 > C:*

Re: [PATCH] Bluetooth: btusb: add ID for LiteOn 04ca:301a

Hi Matthias, > Contains a QCA6174A chipset, with USB BT. Let's support loading > firmware on it. > > From usb-devices: > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=04ca ProdID=301a Rev= 0.01 > C:*

Re: [PATCH] drm/admgpu: fix mode_valid's return type

On 2018-04-24 09:14 AM, Luc Van Oostenryck wrote: > The method struct drm_connector_helper_funcs::mode_valid is defined > as returning an 'enum drm_mode_status' but the driver implementation > for this method uses an 'int' for it. > > Fix this by using 'enum drm_mode_status' in the driver too. >

Re: [PATCH] drm/admgpu: fix mode_valid's return type

On 2018-04-24 09:14 AM, Luc Van Oostenryck wrote: > The method struct drm_connector_helper_funcs::mode_valid is defined > as returning an 'enum drm_mode_status' but the driver implementation > for this method uses an 'int' for it. > > Fix this by using 'enum drm_mode_status' in the driver too. >

Re: simplify procfs code for seq_file instances

On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > git://git.infradead.org/users/hch/misc.git proc_create > > > I want to ask if it is time to start using poorman function overloading > with _b_c_e(). There are millions of allocation functions for example, > all slightly

Re: simplify procfs code for seq_file instances

On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > git://git.infradead.org/users/hch/misc.git proc_create > > > I want to ask if it is time to start using poorman function overloading > with _b_c_e(). There are millions of allocation functions for example, > all slightly

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Tue, Apr 24, 2018 at 05:07:41PM +0300, Imre Deak wrote: > On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > > Hi, > > > > > > > > while checking bug [1], I noticed

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Tue, Apr 24, 2018 at 05:07:41PM +0300, Imre Deak wrote: > On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > > Hi, > > > > > > > > while checking bug [1], I noticed

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: > +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) > +{ > + struct xen_snd_front_evtchnl *channel = dev_id; > + struct xen_snd_front_info *front_info = channel->front_info; > + struct xensnd_resp *resp;

Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling

On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: > +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) > +{ > + struct xen_snd_front_evtchnl *channel = dev_id; > + struct xen_snd_front_info *front_info = channel->front_info; > + struct xensnd_resp *resp;

[PATCH] powerpc/signal32: Use fault_in_pages_readable() to prefault user context

Use fault_in_pages_readable() to prefault user context instead of open coding Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/signal_32.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/signal_32.c

[PATCH] powerpc/signal32: Use fault_in_pages_readable() to prefault user context

Use fault_in_pages_readable() to prefault user context instead of open coding Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/signal_32.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c

Re: [PATCH 03/39] proc: introduce proc_create_seq_private

On Thu, Apr 19, 2018 at 05:18:18PM +0300, Dan Carpenter wrote: > > -static const struct file_operations cio_ignore_proc_fops = { > > - .open= cio_ignore_proc_open, > > - .read= seq_read, > > - .llseek = seq_lseek, > > - .release = seq_release_private, > > - .write =

Re: [PATCH 03/39] proc: introduce proc_create_seq_private

On Thu, Apr 19, 2018 at 05:18:18PM +0300, Dan Carpenter wrote: > > -static const struct file_operations cio_ignore_proc_fops = { > > - .open= cio_ignore_proc_open, > > - .read= seq_read, > > - .llseek = seq_lseek, > > - .release = seq_release_private, > > - .write =

Re: [PATCH] arm64: support __int128 with clang

On Tue, Apr 24, 2018 at 02:56:09PM +0100, Mark Rutland wrote: > I belevie that currently it is not possible to use a released version of > clang to build a working kernel without additional patches (at least > 5.0.0, there don't seem to be any 6.0.0 binaries that can target > AArch64). Issues

Re: [PATCH] arm64: support __int128 with clang

On Tue, Apr 24, 2018 at 02:56:09PM +0100, Mark Rutland wrote: > I belevie that currently it is not possible to use a released version of > clang to build a working kernel without additional patches (at least > 5.0.0, there don't seem to be any 6.0.0 binaries that can target > AArch64). Issues

Re: [RFC] [PATCH 0/5] procfs: reduce duplication by using symlinks

je...@suse.com writes: > From: Jeff Mahoney > > Hi all - > > I recently encountered a customer issue where, on a machine with many TiB > of memory and a few hundred cores, after a task with a few thousand threads > and hundreds of files open exited, the system would softlockup.

Re: [RFC] [PATCH 0/5] procfs: reduce duplication by using symlinks

je...@suse.com writes: > From: Jeff Mahoney > > Hi all - > > I recently encountered a customer issue where, on a machine with many TiB > of memory and a few hundred cores, after a task with a few thousand threads > and hundreds of files open exited, the system would softlockup. That > issue was

Re: [RFC v4 PATCH] mm: shmem: make stat.st_blksize return huge page size if THP is on

On 4/24/18 5:23 AM, Kirill A. Shutemov wrote: On Tue, Apr 24, 2018 at 12:00:50PM +0800, Yang Shi wrote: Since tmpfs THP was supported in 4.8, hugetlbfs is not the only filesystem with huge page support anymore. tmpfs can use huge page via THP when mounting by "huge=" mount option. When

Re: [RFC v4 PATCH] mm: shmem: make stat.st_blksize return huge page size if THP is on

On 4/24/18 5:23 AM, Kirill A. Shutemov wrote: On Tue, Apr 24, 2018 at 12:00:50PM +0800, Yang Shi wrote: Since tmpfs THP was supported in 4.8, hugetlbfs is not the only filesystem with huge page support anymore. tmpfs can use huge page via THP when mounting by "huge=" mount option. When

Re: [PATCH 16/39] ipmi: simplify procfs code

On Thu, Apr 19, 2018 at 10:29:29AM -0500, Corey Minyard wrote: > On 04/19/2018 07:41 AM, Christoph Hellwig wrote: >> Use remove_proc_subtree to remove the whole subtree on cleanup instead >> of a hand rolled list of proc entries, unwind the registration loop into >> individual calls. Switch to

Re: [PATCH 16/39] ipmi: simplify procfs code

On Thu, Apr 19, 2018 at 10:29:29AM -0500, Corey Minyard wrote: > On 04/19/2018 07:41 AM, Christoph Hellwig wrote: >> Use remove_proc_subtree to remove the whole subtree on cleanup instead >> of a hand rolled list of proc entries, unwind the registration loop into >> individual calls. Switch to

Re: [PATCH 26/39] rtc/proc: switch to proc_create_single_data

On Thu, Apr 19, 2018 at 03:10:27PM +0200, Alexandre Belloni wrote: > On 19/04/2018 14:41:27+0200, Christoph Hellwig wrote: > > And stop trying to get a reference on the submodule, procfs code deals > > with release after and unloaded module and thus removed proc entry. > > > > Are you sure about

Re: [PATCH 26/39] rtc/proc: switch to proc_create_single_data

On Thu, Apr 19, 2018 at 03:10:27PM +0200, Alexandre Belloni wrote: > On 19/04/2018 14:41:27+0200, Christoph Hellwig wrote: > > And stop trying to get a reference on the submodule, procfs code deals > > with release after and unloaded module and thus removed proc entry. > > > > Are you sure about

Re: [PATCH v3 01/19] powerpc/powermac: Mark variable x as unused

Le 04/04/2018 à 22:07, Mathieu Malaterre a écrit : Since the value of x is never intended to be read, declare it with gcc attribute as unused. Fix warning treated as error with W=1: arch/powerpc/platforms/powermac/bootx_init.c:471:21: error: variable ‘x’ set but not used

Re: [PATCH v3 01/19] powerpc/powermac: Mark variable x as unused

Le 04/04/2018 à 22:07, Mathieu Malaterre a écrit : Since the value of x is never intended to be read, declare it with gcc attribute as unused. Fix warning treated as error with W=1: arch/powerpc/platforms/powermac/bootx_init.c:471:21: error: variable ‘x’ set but not used

[PATCH 05/10] ia64: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 05/10] ia64: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

Re: [PATCH 20/39] afs: simplify procfs code

On Fri, Apr 20, 2018 at 01:29:34PM +0100, David Howells wrote: > David Howells wrote: > > > > Use remove_proc_subtree to remove the whole subtree on cleanup, and > > > unwind the registration loop into individual calls. Switch to use > > > proc_create_seq where applicable.

Re: [PATCH 20/39] afs: simplify procfs code

On Fri, Apr 20, 2018 at 01:29:34PM +0100, David Howells wrote: > David Howells wrote: > > > > Use remove_proc_subtree to remove the whole subtree on cleanup, and > > > unwind the registration loop into individual calls. Switch to use > > > proc_create_seq where applicable. > > > > Note that

[PATCH 06/10] parisc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior

[PATCH 06/10] parisc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

c9e97a1997 ("mm: initialize pages on demand during boot"): BUG: kernel reboot-without-warning in early-boot stage, last printk: early console in setup code

ng deferred pages c9e97a1997 mm: initialize pages on demand during boot 6d08b06e67 Linux 4.17-rc2 43cd1f4979 Add linux-next specific files for 20180424 +---+++---+

c9e97a1997 ("mm: initialize pages on demand during boot"): BUG: kernel reboot-without-warning in early-boot stage, last printk: early console in setup code

during boot 6d08b06e67 Linux 4.17-rc2 43cd1f4979 Add linux-next specific files for 20180424

[PATCH 09/10] x86: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior

[PATCH 09/10] x86: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

Re: [PATCH] ALSA: hda: Request driver probe from an async task

On Tue, 24 Apr 2018 16:03:53 +0200, Paul Menzel wrote: > > Dear Takashi, > > > On 04/24/18 14:15, Takashi Iwai wrote: > > On Tue, 24 Apr 2018 13:59:58 +0200, > > Paul Menzel wrote: > > >> On 04/23/18 14:33, Takashi Iwai wrote: > >>> On Mon, 23 Apr 2018 14:30:36 +0200, Paul Menzel wrote: > >> >

Re: [PATCH] ALSA: hda: Request driver probe from an async task

On Tue, 24 Apr 2018 16:03:53 +0200, Paul Menzel wrote: > > Dear Takashi, > > > On 04/24/18 14:15, Takashi Iwai wrote: > > On Tue, 24 Apr 2018 13:59:58 +0200, > > Paul Menzel wrote: > > >> On 04/23/18 14:33, Takashi Iwai wrote: > >>> On Mon, 23 Apr 2018 14:30:36 +0200, Paul Menzel wrote: > >> >

[PATCH 10/10] softirq/s390: Move default mutators of overwritten softirq mask to s390

s390 is now the last architecture that entirely overwrites local_softirq_pending() and uses the according default definitions of set_softirq_pending() and or_softirq_pending(). Just move these to s390 to debloat the generic code complexity. Suggested-by: Peter Zijlstra

[PATCH 07/10] powerpc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Acked-by: Michael Ellerman Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar

[PATCH 10/10] softirq/s390: Move default mutators of overwritten softirq mask to s390

s390 is now the last architecture that entirely overwrites local_softirq_pending() and uses the according default definitions of set_softirq_pending() and or_softirq_pending(). Just move these to s390 to debloat the generic code complexity. Suggested-by: Peter Zijlstra Signed-off-by: Frederic

[PATCH 07/10] powerpc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Acked-by: Michael Ellerman Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc: Benjamin Herrenschmidt Cc:

[PATCH 08/10] sparc: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 08/10] sparc: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[PATCH 03/10] softirq: Turn default irq_cpustat_t to standard per-cpu

In order to optimize and consolidate softirq mask accesses, let's convert the default irq_cpustat_t implementation to per-CPU standard API. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar

[PATCH 03/10] softirq: Turn default irq_cpustat_t to standard per-cpu

In order to optimize and consolidate softirq mask accesses, let's convert the default irq_cpustat_t implementation to per-CPU standard API. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[GIT PULL] softirq: Consolidate and optimize softirq mask v3

Thomas, Ingo, Please pull the softirq/mask-v3 branch that can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git softirq/mask-v3 HEAD: e225bb16aa5eb0ab83ddd0de423aca3057b1cfee (No change since last version, just a rebase against v4.17-rc1 and add

[GIT PULL] softirq: Consolidate and optimize softirq mask v3

Thomas, Ingo, Please pull the softirq/mask-v3 branch that can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git softirq/mask-v3 HEAD: e225bb16aa5eb0ab83ddd0de423aca3057b1cfee (No change since last version, just a rebase against v4.17-rc1 and add

[PATCH 04/10] softirq: Consolidate default local_softirq_pending() implementations

Consolidate and optimize default softirq mask API implementations. Per-CPU operations are expected to be faster and a few architectures already rely on them to implement local_softirq_pending() and related accessors/mutators. Those will be migrated to the new generic code. Signed-off-by: Frederic

[PATCH 04/10] softirq: Consolidate default local_softirq_pending() implementations

Consolidate and optimize default softirq mask API implementations. Per-CPU operations are expected to be faster and a few architectures already rely on them to implement local_softirq_pending() and related accessors/mutators. Those will be migrated to the new generic code. Signed-off-by: Frederic

[PATCH 02/10] sparc: Convert local_softirq_pending() to use per-cpu op

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 02/10] sparc: Convert local_softirq_pending() to use per-cpu op

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[PATCH 01/10] ia64: Convert local_softirq_pending() to per-cpu ops

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 01/10] ia64: Convert local_softirq_pending() to per-cpu ops

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

Re: [RFC 00/13] arm64: allwinner: Add A64 DE2 pipeline support

On Tue, Apr 24, 2018 at 07:04:12PM +0530, Jagan Teki wrote: > Allwinner A64 has display engine pipeline like other Allwinner SOC's > A83T/H3/H5. > > A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to tcon0 > with > RGB, LVDS MIPI-DSI and mixer1, connected to tcon1 with HDMI.

Re: [RFC 00/13] arm64: allwinner: Add A64 DE2 pipeline support

On Tue, Apr 24, 2018 at 07:04:12PM +0530, Jagan Teki wrote: > Allwinner A64 has display engine pipeline like other Allwinner SOC's > A83T/H3/H5. > > A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to tcon0 > with > RGB, LVDS MIPI-DSI and mixer1, connected to tcon1 with HDMI.

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > Hi, > > > > > > while checking bug [1], I noticed that jiffies based timing loops like > > > > > > expire = jiffies +

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > Hi, > > > > > > while checking bug [1], I noticed that jiffies based timing loops like > > > > > > expire = jiffies +

RE: [RFC 01/10] PCI: dwc: Add MSI-X callbacks handler

Hi Kishon, On 24 April 2018 10:36 Gustavo Pimentel wrote: > Hi Kishon, > > On 24/04/2018 08:07, Kishon Vijay Abraham I wrote: > > Hi, > > > > On Monday 23 April 2018 03:06 PM, Gustavo Pimentel wrote: > >> Hi Kishon, > >> > >> On 16/04/2018 10:29, Kishon Vijay Abraham I wrote: > >>> Hi Gustavo, >

RE: [RFC 01/10] PCI: dwc: Add MSI-X callbacks handler

Hi Kishon, On 24 April 2018 10:36 Gustavo Pimentel wrote: > Hi Kishon, > > On 24/04/2018 08:07, Kishon Vijay Abraham I wrote: > > Hi, > > > > On Monday 23 April 2018 03:06 PM, Gustavo Pimentel wrote: > >> Hi Kishon, > >> > >> On 16/04/2018 10:29, Kishon Vijay Abraham I wrote: > >>> Hi Gustavo, >

Re: [PATCH 1/2] clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux

On 9 April 2018 at 10:59, Jerome Brunet wrote: > > CLK_MUX_ROUND_CLOSEST is part of the clk_mux documentation but clk_mux > directly calls __clk_mux_determine_rate(), which overrides the flag. > As result, if clk_mux is instantiated with CLK_MUX_ROUND_CLOSEST, the > flag

Re: [PATCH 1/2] clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux

On 9 April 2018 at 10:59, Jerome Brunet wrote: > > CLK_MUX_ROUND_CLOSEST is part of the clk_mux documentation but clk_mux > directly calls __clk_mux_determine_rate(), which overrides the flag. > As result, if clk_mux is instantiated with CLK_MUX_ROUND_CLOSEST, the > flag will be ignored and the

<    9   10   11   12   13   14   15   16   17   18   >