[RFC v4 1/5] drm/nouveau: Add support for basic clockgating on Kepler1

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling

[RFC v4 2/5] drm/nouveau: Add support for BLCG on Kepler1

This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more

[RFC v4 0/5] Implement full clockgating for Kepler1 and 2

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ One small change: - Set therm->clkgate_enabled to false until the last patch, where we introduce the

[RFC v4 0/5] Implement full clockgating for Kepler1 and 2

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ One small change: - Set therm->clkgate_enabled to false until the last patch, where we introduce the

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On 30 January 2018 at 08:38, Bjorn Helgaas wrote: > On Tue, Jan 30, 2018 at 07:43:21AM +1000, Dave Airlie wrote: >> On 3 January 2018 at 22:44, Sinan Kaya wrote: >> > On 12/19/2017 12:37 AM, Sinan Kaya wrote: >> >> pci_get_bus_and_slot() is restrictive

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On 30 January 2018 at 08:38, Bjorn Helgaas wrote: > On Tue, Jan 30, 2018 at 07:43:21AM +1000, Dave Airlie wrote: >> On 3 January 2018 at 22:44, Sinan Kaya wrote: >> > On 12/19/2017 12:37 AM, Sinan Kaya wrote: >> >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as >> >>

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

> Even if we expose bit to indicate that FMS matches the underlying host, when > does the guest know to query that? The VM can be moved at any point in time, > including after the guest asks if FMS matches host. There's no way to enable these mitigations later, so if you always have to enable

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

> Even if we expose bit to indicate that FMS matches the underlying host, when > does the guest know to query that? The VM can be moved at any point in time, > including after the guest asks if FMS matches host. There's no way to enable these mitigations later, so if you always have to enable

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

Kirill A. Shutemov wrote: > On Mon, Jan 29, 2018 at 05:57:22PM +0100, Florian Westphal wrote: > > Kirill A. Shutemov wrote: > > > On Mon, Jan 29, 2018 at 08:23:57AM +0100, Florian Westphal wrote: > > > > > vmalloc() once became killable by commit

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

Kirill A. Shutemov wrote: > On Mon, Jan 29, 2018 at 05:57:22PM +0100, Florian Westphal wrote: > > Kirill A. Shutemov wrote: > > > On Mon, Jan 29, 2018 at 08:23:57AM +0100, Florian Westphal wrote: > > > > > vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: > > > > > back > > >

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On Tue, Jan 30, 2018 at 07:43:21AM +1000, Dave Airlie wrote: > On 3 January 2018 at 22:44, Sinan Kaya wrote: > > On 12/19/2017 12:37 AM, Sinan Kaya wrote: > >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > >> where a PCI device is present. This

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On Tue, Jan 30, 2018 at 07:43:21AM +1000, Dave Airlie wrote: > On 3 January 2018 at 22:44, Sinan Kaya wrote: > > On 12/19/2017 12:37 AM, Sinan Kaya wrote: > >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > >> where a PCI device is present. This restricts the device

Re: [patch -mm v2 1/3] mm, memcg: introduce per-memcg oom policy tunable

On Fri, 26 Jan 2018, Michal Hocko wrote: > > The cgroup aware oom killer is needlessly declared for the entire system > > by a mount option. It's unnecessary to force the system into a single > > oom policy: either cgroup aware, or the traditional process aware. > > > > This patch introduces a

Re: [patch -mm v2 1/3] mm, memcg: introduce per-memcg oom policy tunable

On Fri, 26 Jan 2018, Michal Hocko wrote: > > The cgroup aware oom killer is needlessly declared for the entire system > > by a mount option. It's unnecessary to force the system into a single > > oom policy: either cgroup aware, or the traditional process aware. > > > > This patch introduces a

[ANNOUNCE] v4.14.15-rt13

Dear RT folks! I'm pleased to announce the v4.14.15-rt13 patch set. Changes since v4.14.15-rt12: - In the previous release the ping-sysrq patch was removed from the queue but has been left listed in the series by mistake. "git quiltimport" simply ignored that patch while "quilt push

[ANNOUNCE] v4.14.15-rt13

Dear RT folks! I'm pleased to announce the v4.14.15-rt13 patch set. Changes since v4.14.15-rt12: - In the previous release the ping-sysrq patch was removed from the queue but has been left listed in the series by mistake. "git quiltimport" simply ignored that patch while "quilt push

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On 01/19/18 07:24, Jens Axboe wrote: That's what I thought. So for a low queue depth underlying queue, it's quite possible that this situation can happen. Two potential solutions I see: 1) As described earlier in this thread, having a mechanism for being notified when the scarce resource

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On 01/19/18 07:24, Jens Axboe wrote: That's what I thought. So for a low queue depth underlying queue, it's quite possible that this situation can happen. Two potential solutions I see: 1) As described earlier in this thread, having a mechanism for being notified when the scarce resource

Re: [PATCH 1/3] mm, numa: rework do_pages_move

On Mon, 29 Jan 2018 17:06:14 -0500 "Zi Yan" wrote: > I discover that this patch does not hold mmap_sem while migrating pages in > do_move_pages_to_node(). > > A simple fix below moves mmap_sem from add_page_for_migration() > to the outmost do_pages_move(): I'm not

Re: [PATCH 1/3] mm, numa: rework do_pages_move

On Mon, 29 Jan 2018 17:06:14 -0500 "Zi Yan" wrote: > I discover that this patch does not hold mmap_sem while migrating pages in > do_move_pages_to_node(). > > A simple fix below moves mmap_sem from add_page_for_migration() > to the outmost do_pages_move(): I'm not surprised. Why does

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, 2018-01-29 at 13:45:07 -0800, Eduardo Habkost wrote: > Maybe a generic "family/model/stepping/microcode really matches > the CPU you are running on" bit would be useful. The bit could > be enabled only on host-passthrough (aka "-cpu host") mode. > > If we really want to be able to

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, 2018-01-29 at 13:45:07 -0800, Eduardo Habkost wrote: > Maybe a generic "family/model/stepping/microcode really matches > the CPU you are running on" bit would be useful. The bit could > be enabled only on host-passthrough (aka "-cpu host") mode. > > If we really want to be able to

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

I agree with your point that the common hypervisor practice to fake old model numbers will break some of the workarounds. Hypervisors may need to revisit their practice. > > In general, making these kinds of decisions based on F/M/S is probably > > unwise when running in a VM. > > Certainly.

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

I agree with your point that the common hypervisor practice to fake old model numbers will break some of the workarounds. Hypervisors may need to revisit their practice. > > In general, making these kinds of decisions based on F/M/S is probably > > unwise when running in a VM. > > Certainly.

Re: [patch -mm v2 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable

On Fri, 26 Jan 2018, Andrew Morton wrote: > > > > -ECONFUSED. We want to have a mount option that has the sole purpose > > > > of > > > > doing echo cgroup > /mnt/cgroup/memory.oom_policy? > > > > > > Approximately. Let me put it another way: can we modify your patchset > > > so that the

Re: [patch -mm v2 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable

On Fri, 26 Jan 2018, Andrew Morton wrote: > > > > -ECONFUSED. We want to have a mount option that has the sole purpose > > > > of > > > > doing echo cgroup > /mnt/cgroup/memory.oom_policy? > > > > > > Approximately. Let me put it another way: can we modify your patchset > > > so that the

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 1:50 PM, Eduardo Habkost wrote: > On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote: >> For GCE, "you might be migrated to Skylake" is pretty much a >> certainty. Even if you're in a zone that doesn't currently have >> Skylake machines,

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 1:50 PM, Eduardo Habkost wrote: > On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote: >> For GCE, "you might be migrated to Skylake" is pretty much a >> certainty. Even if you're in a zone that doesn't currently have >> Skylake machines, chances are pretty good

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 07:44:21PM -0200, Eduardo Habkost wrote: > On Mon, Jan 29, 2018 at 09:02:39PM +, David Woodhouse wrote: > > > > > > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: > > > On 1/29/2018 12:42 PM, Eduardo Habkost wrote: > > > > > > > > The question is how the

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 07:44:21PM -0200, Eduardo Habkost wrote: > On Mon, Jan 29, 2018 at 09:02:39PM +, David Woodhouse wrote: > > > > > > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: > > > On 1/29/2018 12:42 PM, Eduardo Habkost wrote: > > > > > > > > The question is how the

[PATCH] vt: change SGR 21 to follow the standards

From: Mike Frysinger ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined" since at least March 1984. The Linux kernel has treated it as SGR 22 "normal intensity" since it was added in Linux-0.96b in June 1992. Before that, it was simply ignored. Other

[PATCH] vt: change SGR 21 to follow the standards

From: Mike Frysinger ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined" since at least March 1984. The Linux kernel has treated it as SGR 22 "normal intensity" since it was added in Linux-0.96b in June 1992. Before that, it was simply ignored. Other terminal emulators have

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Sat, Jan 27, 2018 at 12:20:18PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jarkko, > > On 17 November 2017 at 19:27, Jarkko Sakkinen > wrote: > > On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko Sakkinen wrote: > > > > At least signed-off-by from

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Sat, Jan 27, 2018 at 12:20:18PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jarkko, > > On 17 November 2017 at 19:27, Jarkko Sakkinen > wrote: > > On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko Sakkinen wrote: > > > > At least signed-off-by from PrassanaKumar is missing from the 2nd > >

Re: [PATCH 1/3] mm, numa: rework do_pages_move

Hi Michal, I discover that this patch does not hold mmap_sem while migrating pages in do_move_pages_to_node(). A simple fix below moves mmap_sem from add_page_for_migration() to the outmost do_pages_move(): diff --git a/mm/migrate.c b/mm/migrate.c index 5d0dc7b85f90..28b9e126cb38 100644 ---

Re: [PATCH 1/3] mm, numa: rework do_pages_move

Hi Michal, I discover that this patch does not hold mmap_sem while migrating pages in do_move_pages_to_node(). A simple fix below moves mmap_sem from add_page_for_migration() to the outmost do_pages_move(): diff --git a/mm/migrate.c b/mm/migrate.c index 5d0dc7b85f90..28b9e126cb38 100644 ---

[PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

From: Tim Chen Flush indirect branches when switching into a process that marked itself non dumpable. This protects high value processes like gpg better, without having too high performance overhead. If done naïvely, we could switch to a kernel idle thread and then

[PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

From: Tim Chen Flush indirect branches when switching into a process that marked itself non dumpable. This protects high value processes like gpg better, without having too high performance overhead. If done naïvely, we could switch to a kernel idle thread and then back to the original process,

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On 1/29/2018 4:43 PM, Dave Airlie wrote: >> 12/19/2017 12:37 AM, Sinan Kaya wrote: >>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as >>> where a PCI device is present. This restricts the device drivers to be >>> reused for other domain numbers. > So not a major problem,

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On 1/29/2018 4:43 PM, Dave Airlie wrote: >> 12/19/2017 12:37 AM, Sinan Kaya wrote: >>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as >>> where a PCI device is present. This restricts the device drivers to be >>> reused for other domain numbers. > So not a major problem,

Re: [PATCH 4/4] rtc: isl1208: add support for isl1219 with hwmon for tamper detection

On Wed, Jan 24, 2018 at 10:03:33AM +0100, Michael Grzeschik wrote: [ ... ] > > > + > > > diff --git a/Documentation/hwmon/sysfs-interface > > > b/Documentation/hwmon/sysfs-interface > > > index fc337c317c673..a12b3c2b2a18c 100644 > > > --- a/Documentation/hwmon/sysfs-interface > > > +++

Re: [PATCH 4/4] rtc: isl1208: add support for isl1219 with hwmon for tamper detection

On Wed, Jan 24, 2018 at 10:03:33AM +0100, Michael Grzeschik wrote: [ ... ] > > > + > > > diff --git a/Documentation/hwmon/sysfs-interface > > > b/Documentation/hwmon/sysfs-interface > > > index fc337c317c673..a12b3c2b2a18c 100644 > > > --- a/Documentation/hwmon/sysfs-interface > > > +++

Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL

On Mon, Jan 29, 2018 at 12:31:13PM -0500, Konrad Rzeszutek Wilk wrote: > On Mon, Jan 29, 2018 at 08:46:03AM +, David Woodhouse wrote: > > On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote: > > > > > > Windows use IBRS and Microsoft don't have any plans to switch to > > > retpoline. > > >

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 1:50 PM, Linus Torvalds wrote: > > Hmm. I have pulled this, but it is really really broken in one place, > to the degree that I always went "no, I won't pull this garbage". always=almost. I'd blame auto-correct, but I'm not on the phone.

Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL

On Mon, Jan 29, 2018 at 12:31:13PM -0500, Konrad Rzeszutek Wilk wrote: > On Mon, Jan 29, 2018 at 08:46:03AM +, David Woodhouse wrote: > > On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote: > > > > > > Windows use IBRS and Microsoft don't have any plans to switch to > > > retpoline. > > >

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 1:50 PM, Linus Torvalds wrote: > > Hmm. I have pulled this, but it is really really broken in one place, > to the degree that I always went "no, I won't pull this garbage". always=almost. I'd blame auto-correct, but I'm not on the phone. Linus

Re: [PATCH v2 00/43] DRM Rockchip rk3399 (Kevin)

On Fri, Jan 26, 2018 at 02:16:27PM +0100, Thierry Escande wrote: > Hi, > > This patchset includes cleanups, improvements, and bug fixes for > Rockchip DRM driver and PSR support. > > this patchset depends and needs to be applied on top of Rockchip rk3399 > eDP support [1]. > > [1]

Re: [PATCH v2 00/43] DRM Rockchip rk3399 (Kevin)

On Fri, Jan 26, 2018 at 02:16:27PM +0100, Thierry Escande wrote: > Hi, > > This patchset includes cleanups, improvements, and bug fixes for > Rockchip DRM driver and PSR support. > > this patchset depends and needs to be applied on top of Rockchip rk3399 > eDP support [1]. > > [1]

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote: > For GCE, "you might be migrated to Skylake" is pretty much a > certainty. Even if you're in a zone that doesn't currently have > Skylake machines, chances are pretty good that it will have Skylake > machines some day in the

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote: > For GCE, "you might be migrated to Skylake" is pretty much a > certainty. Even if you're in a zone that doesn't currently have > Skylake machines, chances are pretty good that it will have Skylake > machines some day in the

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote: > > This pile of patches is a rework of the inode->i_version field. We have > traditionally incremented that field on every inode data or metadata > change. Typically this increment needs to be logged on disk even when >

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote: > > This pile of patches is a rework of the inode->i_version field. We have > traditionally incremented that field on every inode data or metadata > change. Typically this increment needs to be logged on disk even when > nothing else has

Re: [GIT pull] printk updates for 4.15

On Mon, 29 Jan 2018, Mark Salyzyn wrote: > Any movement on the following proposal? tglx@ do you have an update? This sits in my inbox since then due to the melted spectrum mess

Re: [GIT pull] printk updates for 4.15

On Mon, 29 Jan 2018, Mark Salyzyn wrote: > Any movement on the following proposal? tglx@ do you have an update? This sits in my inbox since then due to the melted spectrum mess

Re: [PATCH v4 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

On Wed, 24 Jan 2018, Radim Krčmář wrote: > 2018-01-24 14:23+0100, Vitaly Kuznetsov: > > Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're > > not supposed to see many of them. However, it may be important to know > > that the event has happened in case we have L2 nested

Re: [PATCH v4 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

On Wed, 24 Jan 2018, Radim Krčmář wrote: > 2018-01-24 14:23+0100, Vitaly Kuznetsov: > > Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're > > not supposed to see many of them. However, it may be important to know > > that the event has happened in case we have L2 nested

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

On 01/29/2018 01:21 AM, Yong Deng wrote: > Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 > interface and CSI1 is used for parallel interface. This is not > documented in datasheet but by test and guess. > > This patch implement a v4l2 framework driver for it. > >

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

On 01/29/2018 01:21 AM, Yong Deng wrote: > Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 > interface and CSI1 is used for parallel interface. This is not > documented in datasheet but by test and guess. > > This patch implement a v4l2 framework driver for it. > >

Re: [PATCH v2 15/16] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

On 29 January 2018 at 17:45, Marc Zyngier wrote: > One of the major improvement of SMCCC v1.1 is that it only clobbers > the first 4 registers, both on 32 and 64bit. This means that it > becomes very easy to provide an inline version of the SMC call > primitive, and avoid

Re: [PATCH v2 15/16] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

On 29 January 2018 at 17:45, Marc Zyngier wrote: > One of the major improvement of SMCCC v1.1 is that it only clobbers > the first 4 registers, both on 32 and 64bit. This means that it > becomes very easy to provide an inline version of the SMC call > primitive, and avoid performing a function

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 09:02:39PM +, David Woodhouse wrote: > > > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: > > On 1/29/2018 12:42 PM, Eduardo Habkost wrote: > > > > > > The question is how the hypervisor could tell that to the guest. > > > If Intel doesn't give us a CPUID

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On Mon, Jan 29, 2018 at 09:02:39PM +, David Woodhouse wrote: > > > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: > > On 1/29/2018 12:42 PM, Eduardo Habkost wrote: > > > > > > The question is how the hypervisor could tell that to the guest. > > > If Intel doesn't give us a CPUID

Re: [PATCH v2 37/43] drm/rockchip: Disable PSR on input events

On Fri, Jan 26, 2018 at 02:17:04PM +0100, Thierry Escande wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get a

Re: [PATCH v2 37/43] drm/rockchip: Disable PSR on input events

On Fri, Jan 26, 2018 at 02:17:04PM +0100, Thierry Escande wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get a head start on coming

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On 3 January 2018 at 22:44, Sinan Kaya wrote: > On 12/19/2017 12:37 AM, Sinan Kaya wrote: >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as >> where a PCI device is present. This restricts the device drivers to be >> reused for other domain numbers.

Re: [PATCH V4 05/26] agp: nvidia: deprecate pci_get_bus_and_slot()

On 3 January 2018 at 22:44, Sinan Kaya wrote: > On 12/19/2017 12:37 AM, Sinan Kaya wrote: >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as >> where a PCI device is present. This restricts the device drivers to be >> reused for other domain numbers. So not a major

Re: [PATCH v2 29/43] drm/bridge: analogix_dp: Move fast link training detect to set_bridge

On Fri, Jan 26, 2018 at 02:16:56PM +0100, Thierry Escande wrote: > From: zain wang > > It's too early to detect fast link training, if other step after it > failed, we will set fast_link flag to 1, and retry set_bridge again. In > this case we will power down and power up

Re: [PATCH v2 29/43] drm/bridge: analogix_dp: Move fast link training detect to set_bridge

On Fri, Jan 26, 2018 at 02:16:56PM +0100, Thierry Escande wrote: > From: zain wang > > It's too early to detect fast link training, if other step after it > failed, we will set fast_link flag to 1, and retry set_bridge again. In > this case we will power down and power up panel power supply, and

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

> The question is about all the additional RSB-frobbing and call depth > counting and other bits that don't really even exist for Skylake yet in > a coherent form. We have had several patch kits posted that all are in a "coherent form" That was the original one

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

> The question is about all the additional RSB-frobbing and call depth > counting and other bits that don't really even exist for Skylake yet in > a coherent form. We have had several patch kits posted that all are in a "coherent form" That was the original one

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

For GCE, "you might be migrated to Skylake" is pretty much a certainty. Even if you're in a zone that doesn't currently have Skylake machines, chances are pretty good that it will have Skylake machines some day in the not-too-distant future. In general, making these kinds of decisions based on

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

For GCE, "you might be migrated to Skylake" is pretty much a certainty. Even if you're in a zone that doesn't currently have Skylake machines, chances are pretty good that it will have Skylake machines some day in the not-too-distant future. In general, making these kinds of decisions based on

Re: [PATCH v2 28/43] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

On Fri, Jan 26, 2018 at 02:16:55PM +0100, Thierry Escande wrote: > From: zain wang > > Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to > Exynos: > > on Exynos edp phy, > BIT 7 MASTER_VID_FUNC_EN_N > BIT 6 reserved > BIT 5

Re: [PATCH v2 28/43] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

On Fri, Jan 26, 2018 at 02:16:55PM +0100, Thierry Escande wrote: > From: zain wang > > Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to > Exynos: > > on Exynos edp phy, > BIT 7 MASTER_VID_FUNC_EN_N > BIT 6 reserved > BIT 5 SLAVE_VID_FUNC_EN_N > > on

[GIT PULL] LED updates for 4.16-rc1

Hi Linus, Please pull LED updates for 4.16-rc1. New LED class driver: - Introduce LM3692x dual string driver New LED trigger: - Introduce a NETDEV trigger leds-lp8860: - Various fixes to align with LED framework - Add regulator enable during init - DT support related improvements

[GIT PULL] LED updates for 4.16-rc1

Hi Linus, Please pull LED updates for 4.16-rc1. New LED class driver: - Introduce LM3692x dual string driver New LED trigger: - Introduce a NETDEV trigger leds-lp8860: - Various fixes to align with LED framework - Add regulator enable during init - DT support related improvements

Re: [PATCH v2 22/43] drm/bridge: analogix_dp: Check dpcd write/read status

On Mon, Jan 29, 2018 at 04:14:41PM -0500, Sean Paul wrote: > On Fri, Jan 26, 2018 at 02:16:49PM +0100, Thierry Escande wrote: > > From: Lin Huang > > > > We need to check the dpcd write/read return value to see whether the > > write/read was successful > > > > Cc: Kristian

Re: [PATCH v2 22/43] drm/bridge: analogix_dp: Check dpcd write/read status

On Mon, Jan 29, 2018 at 04:14:41PM -0500, Sean Paul wrote: > On Fri, Jan 26, 2018 at 02:16:49PM +0100, Thierry Escande wrote: > > From: Lin Huang > > > > We need to check the dpcd write/read return value to see whether the > > write/read was successful > > > > Cc: Kristian H. Kristensen > >

Re: [PATCH 4.4 00/74] 4.4.114-stable review

On Mon, Jan 29, 2018 at 01:56:05PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.114 release. > There are 74 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

Re: [PATCH 4.4 00/74] 4.4.114-stable review

On Mon, Jan 29, 2018 at 01:56:05PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.114 release. > There are 74 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

Re: [PATCH v2 24/43] drm/bridge: analogix_dp: Reset aux channel if an error occurred

On Fri, Jan 26, 2018 at 02:16:51PM +0100, Thierry Escande wrote: > From: Lin Huang > > AUX errors are caused by many different reasons. We may not know what > happened in aux channel on failure, so let's reset aux channel if some > errors occurred. > > Cc: 征增 王

Re: [PATCH v2 24/43] drm/bridge: analogix_dp: Reset aux channel if an error occurred

On Fri, Jan 26, 2018 at 02:16:51PM +0100, Thierry Escande wrote: > From: Lin Huang > > AUX errors are caused by many different reasons. We may not know what > happened in aux channel on failure, so let's reset aux channel if some > errors occurred. > > Cc: 征增 王 > Cc: Douglas Anderson >

[PATCH] iio/orientation: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Mon, 29 Jan 2018 22:20:07 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] iio/orientation: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Mon, 29 Jan 2018 22:20:07 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/iio/orientation/hid-sensor-incl-3d.c | 4 +---

[PATCH 4.9 34/66] ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings [ Upstream commit e9191ffb65d8e159680ce0ad2224e1acbde6985c ] Commit 513674b5a2c9 ("net: reevalulate autoflowlabel setting after sysctl setting")

[PATCH 4.9 34/66] ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings [ Upstream commit e9191ffb65d8e159680ce0ad2224e1acbde6985c ] Commit 513674b5a2c9 ("net: reevalulate autoflowlabel setting after sysctl setting") removed the initialisation of

[PATCH 3.18 41/52] net: tcp: close sock if net namespace is exiting

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Dan Streetman [ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ] When a tcp socket is closed, if it detects that its net namespace is exiting, close immediately

[PATCH 3.18 41/52] net: tcp: close sock if net namespace is exiting

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Dan Streetman [ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ] When a tcp socket is closed, if it detects that its net namespace is exiting, close immediately and do not wait for

[PATCH 4.14 44/71] ip6_gre: init dev->mtu and dev->hard_header_len correctly

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Kodanev [ Upstream commit 128bb975dc3c25d00de04e503e2fe0a780d04459 ] Commit b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions")

[PATCH 4.14 44/71] ip6_gre: init dev->mtu and dev->hard_header_len correctly

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Kodanev [ Upstream commit 128bb975dc3c25d00de04e503e2fe0a780d04459 ] Commit b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions") moved dev->mtu initialization

[PATCH 3.18 02/52] scsi: sg: disable SET_FORCE_LOW_DMA

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hannes Reinecke commit 745dfa0d8ec26b24f3304459ff6e9eacc5c8351b upstream. The ioctl SET_FORCE_LOW_DMA has never worked since the initial git check-in, and the respective setting

[PATCH 3.18 02/52] scsi: sg: disable SET_FORCE_LOW_DMA

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hannes Reinecke commit 745dfa0d8ec26b24f3304459ff6e9eacc5c8351b upstream. The ioctl SET_FORCE_LOW_DMA has never worked since the initial git check-in, and the respective setting is nowadays

Re: [PATCH] dt-bindings: Nokia N9 audio support

Hi! > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/ti-wl1273.txt > > @@ -0,0 +1,36 @@ > > +Texas Instruments - wl1273 radio/bluetooth module > > bluetooth chips have a binding location: bindings/net/bluetooth. > > And we already have a WL1273 binding. Plus there's the one

Re: [PATCH] dt-bindings: Nokia N9 audio support

Hi! > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/ti-wl1273.txt > > @@ -0,0 +1,36 @@ > > +Texas Instruments - wl1273 radio/bluetooth module > > bluetooth chips have a binding location: bindings/net/bluetooth. > > And we already have a WL1273 binding. Plus there's the one

[PATCH 3.18 22/52] can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Marc Kleine-Budde commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream. If an invalid CAN frame is received, from a driver or from a tun interface, a Kernel warning

[PATCH 3.18 22/52] can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Marc Kleine-Budde commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream. If an invalid CAN frame is received, from a driver or from a tun interface, a Kernel warning is generated. This

[PATCH 4.14 31/71] net: qdisc_pkt_len_init() should be more robust

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 7c68d1a6b4db9012790af7ac0f0fdc0d2083422a ] Without proper validation of DODGY packets, we might very well feed qdisc_pkt_len_init() with

[PATCH 4.14 31/71] net: qdisc_pkt_len_init() should be more robust

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 7c68d1a6b4db9012790af7ac0f0fdc0d2083422a ] Without proper validation of DODGY packets, we might very well feed qdisc_pkt_len_init() with invalid GSO packets.

[PATCH 4.9 40/66] net: tcp: close sock if net namespace is exiting

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Streetman [ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ] When a tcp socket is closed, if it detects that its net namespace is exiting, close immediately

[PATCH 4.9 40/66] net: tcp: close sock if net namespace is exiting

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Streetman [ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ] When a tcp socket is closed, if it detects that its net namespace is exiting, close immediately and do not wait for

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