Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 2018-04-25 20:40, Frank Rowand wrote: > On 04/24/18 22:23, Jan Kiszka wrote: >> On 2018-04-24 22:56, Frank Rowand wrote: >>> Hi Alan, >>> >>> On 04/23/18 15:38, Frank Rowand wrote: Hi Jan, + Alan Tull for fpga perspective On 04/22/18 03:30, Jan Kiszka wrote: > On

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 2018-04-25 20:40, Frank Rowand wrote: > On 04/24/18 22:23, Jan Kiszka wrote: >> On 2018-04-24 22:56, Frank Rowand wrote: >>> Hi Alan, >>> >>> On 04/23/18 15:38, Frank Rowand wrote: Hi Jan, + Alan Tull for fpga perspective On 04/22/18 03:30, Jan Kiszka wrote: > On

[PATCH] fault-injection: reorder config entries

This patch reorders Kconfig entries, so that menuconfig displays proper indentation. Signed-off-by: Mikulas Patocka --- lib/Kconfig.debug | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) Index: linux-2.6/lib/Kconfig.debug

[PATCH] fault-injection: reorder config entries

This patch reorders Kconfig entries, so that menuconfig displays proper indentation. Signed-off-by: Mikulas Patocka --- lib/Kconfig.debug | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) Index: linux-2.6/lib/Kconfig.debug

[PATCH v4] fault-injection: introduce kvmalloc fallback options

On Tue, 24 Apr 2018, Michal Hocko wrote: > > > Wouldn't it be equally trivial to simply enable the fault injection? You > > > would get additional failure paths testing as a bonus. > > > > The RHEL and Fedora debugging kernels are compiled with fault injection. > > But the fault-injection

[PATCH v4] fault-injection: introduce kvmalloc fallback options

On Tue, 24 Apr 2018, Michal Hocko wrote: > > > Wouldn't it be equally trivial to simply enable the fault injection? You > > > would get additional failure paths testing as a bonus. > > > > The RHEL and Fedora debugging kernels are compiled with fault injection. > > But the fault-injection

[PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On 25/04/18 02:25, Russell King - ARM Linux wrote: > On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote: >> On 24/04/18 20:06, Russell King - ARM Linux wrote: >>> On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: On 24/04/18 13:14, Peter Rosin wrote: > On 2018-04-24

[PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On 25/04/18 02:25, Russell King - ARM Linux wrote: > On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote: >> On 24/04/18 20:06, Russell King - ARM Linux wrote: >>> On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: On 24/04/18 13:14, Peter Rosin wrote: > On 2018-04-24

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Jan, On Wed, Apr 25, 2018 at 9:40 PM, Jan Kiszka wrote: > What other pointers are we talking about? There's also the issue that some data has been allocated using kmalloc(), while others hasn't. The "other" pointers point to e.g. early bootmem or memblock.

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Jan, On Wed, Apr 25, 2018 at 9:40 PM, Jan Kiszka wrote: > What other pointers are we talking about? There's also the issue that some data has been allocated using kmalloc(), while others hasn't. The "other" pointers point to e.g. early bootmem or memblock. Gr{oetje,eeting}s,

Re: [PATCH v2] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

On Fri, Apr 20, 2018 at 01:06:31PM +0300, Kirill Tkhai wrote: > @@ -2406,12 +2407,15 @@ static inline int tg_has_rt_tasks(struct task_group > *tg) > if (task_group_is_autogroup(tg)) > return 0; > > - for_each_process_thread(g, p) { > - if (rt_task(p) &&

Re: [PATCH v2] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()

On Fri, Apr 20, 2018 at 01:06:31PM +0300, Kirill Tkhai wrote: > @@ -2406,12 +2407,15 @@ static inline int tg_has_rt_tasks(struct task_group > *tg) > if (task_group_is_autogroup(tg)) > return 0; > > - for_each_process_thread(g, p) { > - if (rt_task(p) &&

Re: [PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users to devm variant

> -Original Message- > From: Jan Kiszka > Sent: Tuesday, April 24, 2018 11:14 AM > To: Bjorn Helgaas ; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Cc: Jingoo Han

Re: [PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users to devm variant

> -Original Message- > From: Jan Kiszka > Sent: Tuesday, April 24, 2018 11:14 AM > To: Bjorn Helgaas ; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Cc: Jingoo Han ; Joao Pinto > ; Lorenzo Pieralisi > Subject:

[tip:perf/urgent] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

Commit-ID: 4e949e9b9d1e3edcdab3b54656c5851bd9e49c67 Gitweb: https://git.kernel.org/tip/4e949e9b9d1e3edcdab3b54656c5851bd9e49c67 Author: Kan Liang AuthorDate: Wed, 25 Apr 2018 14:57:17 -0400 Committer: Thomas Gleixner CommitDate: Wed, 25

[tip:perf/urgent] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

Commit-ID: 4e949e9b9d1e3edcdab3b54656c5851bd9e49c67 Gitweb: https://git.kernel.org/tip/4e949e9b9d1e3edcdab3b54656c5851bd9e49c67 Author: Kan Liang AuthorDate: Wed, 25 Apr 2018 14:57:17 -0400 Committer: Thomas Gleixner CommitDate: Wed, 25 Apr 2018 21:41:22 +0200 perf/x86/intel: Don't

Re: [RFC PATCH 00/35] overlayfs: stack file operations

On Wed, Apr 25, 2018 at 4:49 PM, J. R. Okajima wrote: > Miklos Szeredi: >> This patch series reverts the VFS hacks (with the exception of d_path) and > > I totally agree with removing d_real things. > It must be good to the world. > > If I understand correctly, this series

Re: [RFC PATCH 00/35] overlayfs: stack file operations

On Wed, Apr 25, 2018 at 4:49 PM, J. R. Okajima wrote: > Miklos Szeredi: >> This patch series reverts the VFS hacks (with the exception of d_path) and > > I totally agree with removing d_real things. > It must be good to the world. > > If I understand correctly, this series affects file_inode()

Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches

On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > For the same reasons we've added dri-devel for all fbdev patches: Most > of the actively developed drivers using this infrastructure are in > drivers/gpu/. It just makes sense to cross-post patches and keep > aligned. And total

Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches

On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > For the same reasons we've added dri-devel for all fbdev patches: Most > of the actively developed drivers using this infrastructure are in > drivers/gpu/. It just makes sense to cross-post patches and keep > aligned. And total

Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states

On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > The backlight power state handling is supremely confusing. We have: > - props.power, using FB_BLANK_* defines > - props.fb_blank, using the same, but deprecated int favour of > props.state > - props.state, using the BL_CORE_*

Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states

On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > The backlight power state handling is supremely confusing. We have: > - props.power, using FB_BLANK_* defines > - props.fb_blank, using the same, but deprecated int favour of > props.state > - props.state, using the BL_CORE_*

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 2018-04-25 21:02, Frank Rowand wrote: > On 04/25/18 11:56, Frank Rowand wrote: >> On 04/24/18 22:22, Jan Kiszka wrote: >>> On 2018-04-24 23:15, Frank Rowand wrote: On 04/23/18 22:29, Jan Kiszka wrote: > On 2018-04-24 00:38, Frank Rowand wrote: >> Hi Jan, >> >> + Alan Tull

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 2018-04-25 21:02, Frank Rowand wrote: > On 04/25/18 11:56, Frank Rowand wrote: >> On 04/24/18 22:22, Jan Kiszka wrote: >>> On 2018-04-24 23:15, Frank Rowand wrote: On 04/23/18 22:29, Jan Kiszka wrote: > On 2018-04-24 00:38, Frank Rowand wrote: >> Hi Jan, >> >> + Alan Tull

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wed, Apr 25, 2018 at 12:09 PM, Thomas Gleixner wrote: > On Wed, 25 Apr 2018, Linus Torvalds wrote: >> >> I don't see the reported watchdog things, and I run systemd and I ran >> these patches. > > With suspend/resume? Yes. I run them on my laptop, and while I don't do a

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wed, Apr 25, 2018 at 12:09 PM, Thomas Gleixner wrote: > On Wed, 25 Apr 2018, Linus Torvalds wrote: >> >> I don't see the reported watchdog things, and I run systemd and I ran >> these patches. > > With suspend/resume? Yes. I run them on my laptop, and while I don't do a _lot_ of

Re: [PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat

On 04/25/2018 09:14 PM, Roman Gushchin wrote: > Don't show nr_indirectly_reclaimable in /proc/vmstat, > because there is no need in exporting this vm counter > to the userspace, and some changes are expected > in reclaimable object accounting, which can alter > this counter. Oh, you beat me to

Re: [PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat

On 04/25/2018 09:14 PM, Roman Gushchin wrote: > Don't show nr_indirectly_reclaimable in /proc/vmstat, > because there is no need in exporting this vm counter > to the userspace, and some changes are expected > in reclaimable object accounting, which can alter > this counter. Oh, you beat me to

Re: [PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat

On Wed, 25 Apr 2018, Roman Gushchin wrote: > Don't show nr_indirectly_reclaimable in /proc/vmstat, > because there is no need in exporting this vm counter > to the userspace, and some changes are expected > in reclaimable object accounting, which can alter > this counter. > I don't think it

Re: [PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat

On Wed, 25 Apr 2018, Roman Gushchin wrote: > Don't show nr_indirectly_reclaimable in /proc/vmstat, > because there is no need in exporting this vm counter > to the userspace, and some changes are expected > in reclaimable object accounting, which can alter > this counter. > I don't think it

Greeting in Jesus name!!!

-- -- -- Greeting in Jesus name!!! Claim of donation funds!!! My name is, Sister Rose Hary from United States, I'm a widow suffering from Breast Cancer and Stroke, which denied me a child as a result i may not last till the next two months according to my doctor report. I'm married to

Greeting in Jesus name!!!

-- -- -- Greeting in Jesus name!!! Claim of donation funds!!! My name is, Sister Rose Hary from United States, I'm a widow suffering from Breast Cancer and Stroke, which denied me a child as a result i may not last till the next two months according to my doctor report. I'm married to

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 02:10 PM, Grygorii Strashko wrote: On 04/25/2018 01:57 PM, Florian Fainelli wrote: On 04/25/2018 11:47 AM, Grygorii Strashko wrote: On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 02:10 PM, Grygorii Strashko wrote: On 04/25/2018 01:57 PM, Florian Fainelli wrote: On 04/25/2018 11:47 AM, Grygorii Strashko wrote: On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli

Re: KMSAN: uninit-value in _copy_to_iter (2)

syzbot has found reproducer for the following crash on https://github.com/google/kmsan.git/master commit d2d741e5d1898dfde1a75ea3d29a9a3e2edf0617 (Sun Apr 22 15:05:22 2018 +) kmsan: add initialization for shmem pages syzbot dashboard link:

Re: KMSAN: uninit-value in _copy_to_iter (2)

syzbot has found reproducer for the following crash on https://github.com/google/kmsan.git/master commit d2d741e5d1898dfde1a75ea3d29a9a3e2edf0617 (Sun Apr 22 15:05:22 2018 +) kmsan: add initialization for shmem pages syzbot dashboard link:

Re: [V2 PATCH] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

On Wed, Apr 25, 2018 at 02:57:17PM -0400, kan.li...@linux.intel.com wrote: > From: Kan Liang > > The SMM freeze feature was introduced since PerfMon V2. But the current > code unconditionally enables the feature for all platforms. It can > generate #GP exception, if

Re: [V2 PATCH] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

On Wed, Apr 25, 2018 at 02:57:17PM -0400, kan.li...@linux.intel.com wrote: > From: Kan Liang > > The SMM freeze feature was introduced since PerfMon V2. But the current > code unconditionally enables the feature for all platforms. It can > generate #GP exception, if the related FREEZE_WHILE_SMM

[PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat

Don't show nr_indirectly_reclaimable in /proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter. Signed-off-by: Roman Gushchin Cc: Vlastimil Babka

[PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat

Don't show nr_indirectly_reclaimable in /proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter. Signed-off-by: Roman Gushchin Cc: Vlastimil Babka Cc: Matthew Wilcox Cc:

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:57 PM, Florian Fainelli wrote: > On 04/25/2018 11:47 AM, Grygorii Strashko wrote: >> >> >> On 04/25/2018 01:29 PM, Florian Fainelli wrote: >>> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: > Hi Linus, Rafael,

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:57 PM, Florian Fainelli wrote: > On 04/25/2018 11:47 AM, Grygorii Strashko wrote: >> >> >> On 04/25/2018 01:29 PM, Florian Fainelli wrote: >>> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: > Hi Linus, Rafael,

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wed, 25 Apr 2018, Linus Torvalds wrote: > On Wed, Apr 25, 2018 at 6:45 AM, tip-bot for Thomas Gleixner > wrote: > > > > As stated in the pull request for the unification of CLOCK_MONOTONIC and > > CLOCK_BOOTTIME, it was clear that we might have to revert the change. > > I'm

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wed, 25 Apr 2018, Linus Torvalds wrote: > On Wed, Apr 25, 2018 at 6:45 AM, tip-bot for Thomas Gleixner > wrote: > > > > As stated in the pull request for the unification of CLOCK_MONOTONIC and > > CLOCK_BOOTTIME, it was clear that we might have to revert the change. > > I'm ok with the

Re: [Bug 199473] New: pcieport does not scan devices behind PEX switch, while resources are allocated

[Please retain the mailing list cc when replying] On Wed, Apr 25, 2018 at 3:28 AM Janpieter Sollie wrote: > Hi Bjorn, > I'm at work now, but I saw your mail contained much more info than only the remark "does it work at 4.17?", so I'll try to answer all your

Re: [Bug 199473] New: pcieport does not scan devices behind PEX switch, while resources are allocated

[Please retain the mailing list cc when replying] On Wed, Apr 25, 2018 at 3:28 AM Janpieter Sollie wrote: > Hi Bjorn, > I'm at work now, but I saw your mail contained much more info than only the remark "does it work at 4.17?", so I'll try to answer all your questions: > 1. as stated, it only

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/25/18 11:56, Frank Rowand wrote: > On 04/24/18 22:22, Jan Kiszka wrote: >> On 2018-04-24 23:15, Frank Rowand wrote: >>> On 04/23/18 22:29, Jan Kiszka wrote: On 2018-04-24 00:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga perspective > > On 04/22/18 03:30,

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/25/18 11:56, Frank Rowand wrote: > On 04/24/18 22:22, Jan Kiszka wrote: >> On 2018-04-24 23:15, Frank Rowand wrote: >>> On 04/23/18 22:29, Jan Kiszka wrote: On 2018-04-24 00:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga perspective > > On 04/22/18 03:30,

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

On Wed, 25 Apr 2018, Paul Moore wrote: > On Wed, Apr 25, 2018 at 2:44 PM, James Morris wrote: > > On Mon, 23 Apr 2018, David Herrmann wrote: > >> This patch series tries to close this gap and makes both behave the > >> same. A new LSM-hook is added which allows LSMs to cache

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

On Wed, 25 Apr 2018, Paul Moore wrote: > On Wed, Apr 25, 2018 at 2:44 PM, James Morris wrote: > > On Mon, 23 Apr 2018, David Herrmann wrote: > >> This patch series tries to close this gap and makes both behave the > >> same. A new LSM-hook is added which allows LSMs to cache the correct > >>

[V2 PATCH] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

From: Kan Liang The SMM freeze feature was introduced since PerfMon V2. But the current code unconditionally enables the feature for all platforms. It can generate #GP exception, if the related FREEZE_WHILE_SMM bit is set for the machine with PerfMon V1. To disable

[V2 PATCH] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

From: Kan Liang The SMM freeze feature was introduced since PerfMon V2. But the current code unconditionally enables the feature for all platforms. It can generate #GP exception, if the related FREEZE_WHILE_SMM bit is set for the machine with PerfMon V1. To disable the feature for PerfMon V1,

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > > > On 04/25/2018 01:29 PM, Florian Fainelli wrote: >> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: >>> >>> >>> On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > > > On 04/25/2018 01:29 PM, Florian Fainelli wrote: >> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: >>> >>> >>> On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/24/18 22:22, Jan Kiszka wrote: > On 2018-04-24 23:15, Frank Rowand wrote: >> On 04/23/18 22:29, Jan Kiszka wrote: >>> On 2018-04-24 00:38, Frank Rowand wrote: Hi Jan, + Alan Tull for fpga perspective On 04/22/18 03:30, Jan Kiszka wrote: > On 2018-04-11 07:42, Jan

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/24/18 22:22, Jan Kiszka wrote: > On 2018-04-24 23:15, Frank Rowand wrote: >> On 04/23/18 22:29, Jan Kiszka wrote: >>> On 2018-04-24 00:38, Frank Rowand wrote: Hi Jan, + Alan Tull for fpga perspective On 04/22/18 03:30, Jan Kiszka wrote: > On 2018-04-11 07:42, Jan

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

On Wed, Apr 25, 2018 at 2:44 PM, James Morris wrote: > On Mon, 23 Apr 2018, David Herrmann wrote: >> This patch series tries to close this gap and makes both behave the >> same. A new LSM-hook is added which allows LSMs to cache the correct >> peer information on newly created

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

On Wed, Apr 25, 2018 at 2:44 PM, James Morris wrote: > On Mon, 23 Apr 2018, David Herrmann wrote: >> This patch series tries to close this gap and makes both behave the >> same. A new LSM-hook is added which allows LSMs to cache the correct >> peer information on newly created socket-pairs. > >

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

From: James Morris Date: Thu, 26 Apr 2018 04:44:38 +1000 (AEST) > On Mon, 23 Apr 2018, David Herrmann wrote: > >> This patch series tries to close this gap and makes both behave the >> same. A new LSM-hook is added which allows LSMs to cache the correct >> peer information on

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

From: James Morris Date: Thu, 26 Apr 2018 04:44:38 +1000 (AEST) > On Mon, 23 Apr 2018, David Herrmann wrote: > >> This patch series tries to close this gap and makes both behave the >> same. A new LSM-hook is added which allows LSMs to cache the correct >> peer information on newly created

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

On Mon, 23 Apr 2018, David Herrmann wrote: > This patch series tries to close this gap and makes both behave the > same. A new LSM-hook is added which allows LSMs to cache the correct > peer information on newly created socket-pairs. Looks okay to me. Once it's respun with the Smack backend and

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

On Mon, 23 Apr 2018, David Herrmann wrote: > This patch series tries to close this gap and makes both behave the > same. A new LSM-hook is added which allows LSMs to cache the correct > peer information on newly created socket-pairs. Looks okay to me. Once it's respun with the Smack backend and

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/24/18 22:23, Jan Kiszka wrote: > On 2018-04-24 22:56, Frank Rowand wrote: >> Hi Alan, >> >> On 04/23/18 15:38, Frank Rowand wrote: >>> Hi Jan, >>> >>> + Alan Tull for fpga perspective >>> >>> On 04/22/18 03:30, Jan Kiszka wrote: On 2018-04-11 07:42, Jan Kiszka wrote: > On 2018-04-05

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/24/18 22:23, Jan Kiszka wrote: > On 2018-04-24 22:56, Frank Rowand wrote: >> Hi Alan, >> >> On 04/23/18 15:38, Frank Rowand wrote: >>> Hi Jan, >>> >>> + Alan Tull for fpga perspective >>> >>> On 04/22/18 03:30, Jan Kiszka wrote: On 2018-04-11 07:42, Jan Kiszka wrote: > On 2018-04-05

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25/2018 01:17 PM, Oleg Nesterov wrote: On 04/25, Andrey Grodzovsky wrote: here (drm_sched_entity_fini) is also a bad idea, but we still want to be able to exit immediately and not wait for GPU jobs completion when the reason for reaching this code is because of KILL signal to the user

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25/2018 01:17 PM, Oleg Nesterov wrote: On 04/25, Andrey Grodzovsky wrote: here (drm_sched_entity_fini) is also a bad idea, but we still want to be able to exit immediately and not wait for GPU jobs completion when the reason for reaching this code is because of KILL signal to the user

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Giulio, On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote: > LiNova1 is not a board with various headers to connect other peripherals > such display, pcap etc. > It's an HMI that I would consider the same as a Tablet, because it has a > plastic enclosure also. > > So I would like

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Giulio, On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote: > LiNova1 is not a board with various headers to connect other peripherals > such display, pcap etc. > It's an HMI that I would consider the same as a Tablet, because it has a > plastic enclosure also. > > So I would like

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 10:44 AM, Alex Deucher wrote: > On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig wrote: >> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: >>> > It has a non-coherent transaction mode (which the chipset can opt to

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 10:44 AM, Alex Deucher wrote: > On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig wrote: >> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: >>> > It has a non-coherent transaction mode (which the chipset can opt to >>> > not implement and still flush), to

Re: [PATCH 4.14 000/183] 4.14.37-stable review

On 04/25/2018 04:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.37 release. > There are 183 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 000/183] 4.14.37-stable review

On 04/25/2018 04:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.37 release. > There are 183 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 04/17] asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro

On Wed, Apr 25, 2018 at 6:02 PM, Arnd Bergmann wrote: > The sys_llseek sytem call is needed on all 32-bit architectures and > none of the 64-bit ones, so we can remove the __ARCH_WANT_SYS_LLSEEK guard > and simplify the include/asm-generic/unistd.h header further. > > Since 32-bit

Re: [PATCH 04/17] asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro

On Wed, Apr 25, 2018 at 6:02 PM, Arnd Bergmann wrote: > The sys_llseek sytem call is needed on all 32-bit architectures and > none of the 64-bit ones, so we can remove the __ARCH_WANT_SYS_LLSEEK guard > and simplify the include/asm-generic/unistd.h header further. > > Since 32-bit tasks can run

Re: [PATCH 4.16 00/26] 4.16.5-stable review

On 04/25/2018 04:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.5 release. > There are 26 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.16 00/26] 4.16.5-stable review

On 04/25/2018 04:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.5 release. > There are 26 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 02/17] y2038: Remove newstat family from default syscall set

On Wed, Apr 25, 2018 at 6:02 PM, Arnd Bergmann wrote: > We have four generations of stat() syscalls: > - the oldstat syscalls that are only used on the older architectures > - the newstat family that is used on all 64-bit architectures but > lacked support for large files on

Re: [PATCH 02/17] y2038: Remove newstat family from default syscall set

On Wed, Apr 25, 2018 at 6:02 PM, Arnd Bergmann wrote: > We have four generations of stat() syscalls: > - the oldstat syscalls that are only used on the older architectures > - the newstat family that is used on all 64-bit architectures but > lacked support for large files on 32-bit

Re: [PATCH] rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp

From: Dag Moxnes Date: Wed, 25 Apr 2018 13:22:01 +0200 > The function rds_ib_setup_qp is calling rds_ib_get_client_data and > should correspondingly call rds_ib_dev_put. This call was lost in > the non-error path with the introduction of error handling done in > commit

Re: [PATCH] rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp

From: Dag Moxnes Date: Wed, 25 Apr 2018 13:22:01 +0200 > The function rds_ib_setup_qp is calling rds_ib_get_client_data and > should correspondingly call rds_ib_dev_put. This call was lost in > the non-error path with the introduction of error handling done in > commit 3b12f73a5c29 ("rds: ib:

[PATCH v5] cifs: Allocate validate negotiation request through kmalloc

From: Long Li The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect address can't be detected by ib_dma_mapping_error. Sending data from this address to hardware will not

[PATCH rebased] cifs: smbd: Enable signing with smbdirect

From: Long Li Now signing is supported with RDMA transport. Remove the code that disabled it. Signed-off-by: Long Li --- fs/cifs/connect.c | 8 fs/cifs/smb2pdu.c | 5 - 2 files changed, 13 deletions(-) diff --git a/fs/cifs/connect.c

[PATCH v5] cifs: Allocate validate negotiation request through kmalloc

From: Long Li The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect address can't be detected by ib_dma_mapping_error. Sending data from this address to hardware will not fail, but the remote

[PATCH rebased] cifs: smbd: Enable signing with smbdirect

From: Long Li Now signing is supported with RDMA transport. Remove the code that disabled it. Signed-off-by: Long Li --- fs/cifs/connect.c | 8 fs/cifs/smb2pdu.c | 5 - 2 files changed, 13 deletions(-) diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index e8830f0..deef270

[PATCH V3 03/39] x86/intel_rdt: Associate mode with each RDT resource group

Each RDT resource group is associated with a mode that will reflect the level of sharing of its allocations. The default, shareable, will be associated with each resource group on creation since it is zero and resource groups are created with kzalloc. The managing of the mode of a resource group

[PATCH V3 03/39] x86/intel_rdt: Associate mode with each RDT resource group

Each RDT resource group is associated with a mode that will reflect the level of sharing of its allocations. The default, shareable, will be associated with each resource group on creation since it is zero and resource groups are created with kzalloc. The managing of the mode of a resource group

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:06 AM, Grygorii Strashko wrote: > > > On 04/24/2018 05:58 PM, Florian Fainelli wrote: >> Hi Linus, Rafael, all >> >> Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which >> gets invoked when the system is brought into poweroff aka S5. So far so >> good,

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:06 AM, Grygorii Strashko wrote: > > > On 04/24/2018 05:58 PM, Florian Fainelli wrote: >> Hi Linus, Rafael, all >> >> Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which >> gets invoked when the system is brought into poweroff aka S5. So far so >> good,

[PATCH V3 06/39] x86/intel_rdt: Make useful functions available internally

In support of the work done to enable resource groups to have different modes some static functions need to be available for sharing amongst all RDT components. Signed-off-by: Reinette Chatre --- arch/x86/kernel/cpu/intel_rdt.h | 2 ++

[PATCH V3 06/39] x86/intel_rdt: Make useful functions available internally

In support of the work done to enable resource groups to have different modes some static functions need to be available for sharing amongst all RDT components. Signed-off-by: Reinette Chatre --- arch/x86/kernel/cpu/intel_rdt.h | 2 ++ arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 2

[PATCH V3 09/39] x86/intel_rdt: Enable setting of exclusive mode

The new "mode" file now accepts "exclusive" that means that the allocations of this resource group cannot be shared. Enable users to modify a resource group's mode to "exclusive". To succeed it is required that there is no overlap between resource group's current schemata and that of all the

[PATCH v4 1/1] selftests/livepatch: introduce tests

Add a few livepatch modules and simple target modules that the included regression suite can run tests against: - basic livepatching (multiple patches, atomic replace) - pre/post (un)patch callbacks - shadow variable API Signed-off-by: Joe Lawrence ---

[PATCH V3 09/39] x86/intel_rdt: Enable setting of exclusive mode

The new "mode" file now accepts "exclusive" that means that the allocations of this resource group cannot be shared. Enable users to modify a resource group's mode to "exclusive". To succeed it is required that there is no overlap between resource group's current schemata and that of all the

[PATCH v4 1/1] selftests/livepatch: introduce tests

Add a few livepatch modules and simple target modules that the included regression suite can run tests against: - basic livepatching (multiple patches, atomic replace) - pre/post (un)patch callbacks - shadow variable API Signed-off-by: Joe Lawrence ---

[PATCH v4 0/1] Add livepatch kselftests

This round incorporates feedback from SUSE folks, Miroslav, Petr and Libor. Thanks for the reviews and feedback! Like the previous version, this applies on top of Petr's shadow variable changes and the atomic replace patchset. -- Joe changes from v3: - add MAINTAINERS entry for

[PATCH v4 0/1] Add livepatch kselftests

This round incorporates feedback from SUSE folks, Miroslav, Petr and Libor. Thanks for the reviews and feedback! Like the previous version, this applies on top of Petr's shadow variable changes and the atomic replace patchset. -- Joe changes from v3: - add MAINTAINERS entry for

[PATCH v1 1/2] spi: bcm-qspi: Avoid setting MSPI_CDRAM_PCS for spi-nor master

Added fix for probing of spi-nor device non-zero chip selects. Set MSPI_CDRAM_PCS (peripheral chip select) with spi master for MSPI controller and not for MSPI/BSPI spi-nor master controller. Ensure setting of cs bit in chip select register on chip select change. Signed-off-by: Kamal Dasu

[PATCH v1 1/2] spi: bcm-qspi: Avoid setting MSPI_CDRAM_PCS for spi-nor master

Added fix for probing of spi-nor device non-zero chip selects. Set MSPI_CDRAM_PCS (peripheral chip select) with spi master for MSPI controller and not for MSPI/BSPI spi-nor master controller. Ensure setting of cs bit in chip select register on chip select change. Signed-off-by: Kamal Dasu ---

<    1   2   3   4   5   6   7   8   9   10   >