[GIT PULL] Btrfs fixes for 4.15-rc7

Hi, we have two more fixes for 4.15, aimed for stable. The leak fix is obvious, the second patch fixes a bug revealed by the refcount API, when it behaves differently than previous atomic_t and reports refs going from 0 to 1 in one case. No merge conflicts. Please pull, thanks. The following

[GIT PULL] Btrfs fixes for 4.15-rc7

Hi, we have two more fixes for 4.15, aimed for stable. The leak fix is obvious, the second patch fixes a bug revealed by the refcount API, when it behaves differently than previous atomic_t and reports refs going from 0 to 1 in one case. No merge conflicts. Please pull, thanks. The following

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Sat, Jan 06, 2018 at 02:20:16AM +0900, Alice Ferrazzi wrote: > On Thu, Jan 4, 2018 at 5:11 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.4.110 release. > > There are 37 patches in this series, all will be posted as a

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Sat, Jan 06, 2018 at 02:20:16AM +0900, Alice Ferrazzi wrote: > On Thu, Jan 4, 2018 at 5:11 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.4.110 release. > > There are 37 patches in this series, all will be posted as a response > > to this one. If

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:57:15PM +0100, Willy Tarreau wrote: > On Fri, Jan 05, 2018 at 04:51:32PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote: > (...) > > > Reboots after about 30 seconds. > > > > > > Boots fine with nopti option. > > > >

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:57:15PM +0100, Willy Tarreau wrote: > On Fri, Jan 05, 2018 at 04:51:32PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote: > (...) > > > Reboots after about 30 seconds. > > > > > > Boots fine with nopti option. > > > >

Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

On 01/05/2018 04:27 AM, Dr. David Alan Gilbert wrote: >>> Patches for 1-3 are out there and 4 is pretty straightforward. Doing a >>> arch_prctl() is still straightforward, but will be a much more niche >>> thing than any of the other choices. Plus, with a user interface, we >>> have to argue

Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

On 01/05/2018 04:27 AM, Dr. David Alan Gilbert wrote: >>> Patches for 1-3 are out there and 4 is pretty straightforward. Doing a >>> arch_prctl() is still straightforward, but will be a much more niche >>> thing than any of the other choices. Plus, with a user interface, we >>> have to argue

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > diff --git a/arch/arm/include/asm/jump_label.h > b/arch/arm/include/asm/jump_label.h > index e12d7d096fc0..7b05b404063a 100644 > --- a/arch/arm/include/asm/jump_label.h > +++ b/arch/arm/include/asm/jump_label.h > @@ -45,5 +45,32 @@

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > diff --git a/arch/arm/include/asm/jump_label.h > b/arch/arm/include/asm/jump_label.h > index e12d7d096fc0..7b05b404063a 100644 > --- a/arch/arm/include/asm/jump_label.h > +++ b/arch/arm/include/asm/jump_label.h > @@ -45,5 +45,32 @@

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Wed, Jan 03, 2018 at 09:11:06PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.110 release. > There are 37 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/37] 4.4.110-stable review

On Wed, Jan 03, 2018 at 09:11:06PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.110 release. > There are 37 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 v3 1/9] dt-bindings: media: Add Renesas CEU bindings

Hi Laurent, On Fri, Jan 05, 2018 at 12:28:03AM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Thursday, 4 January 2018 18:03:09 EET Jacopo Mondi wrote: > > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > > > Signed-off-by: Jacopo Mondi

Re: [PATCH v3 1/9] dt-bindings: media: Add Renesas CEU bindings

Hi Laurent, On Fri, Jan 05, 2018 at 12:28:03AM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Thursday, 4 January 2018 18:03:09 EET Jacopo Mondi wrote: > > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > > > Signed-off-by: Jacopo Mondi > >

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 5, 2018 at 4:33 AM, Borislav Petkov wrote: > On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote: >> Also, I want to add vsyscall=emulate_noread that makes the vsyscall >> page be --x. And I want to add a per-process option to turn off >> vsyscalls. > >

Re: [RFC] selftests/x86: Add test_vsyscall

On Fri, Jan 5, 2018 at 4:33 AM, Borislav Petkov wrote: > On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote: >> Also, I want to add vsyscall=emulate_noread that makes the vsyscall >> page be --x. And I want to add a per-process option to turn off >> vsyscalls. > > What for? > > It

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 12:48:54PM -0500, Pavel Tatashin wrote: > Boots successfully with "noefi" kernel parameter :) Thanks, that will help me narrow it down. I'll dig through more patches when I get home tonight... greg k-h

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 12:48:54PM -0500, Pavel Tatashin wrote: > Boots successfully with "noefi" kernel parameter :) Thanks, that will help me narrow it down. I'll dig through more patches when I get home tonight... greg k-h

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 02:41:04PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 03:45:55PM -0800, Guenter Roeck wrote: > > On Wed, Jan 03, 2018 at 09:11:06PM +0100, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.110 release. > > > There are

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 02:41:04PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 03:45:55PM -0800, Guenter Roeck wrote: > > On Wed, Jan 03, 2018 at 09:11:06PM +0100, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.110 release. > > > There are

New Technology To Produce The Perfect Heat Pipes Collectors

New Products-Solar heating 1). SHC series CPC reflectors heat pipe collectors: biggest aperture area, highest power output, overheating solution 2). A9 series integrated pressure solar water heaters, EN12976 approved. 3). PVT, hybrid photovoltaic+solar thermal panels. …… Please contact with me

New Technology To Produce The Perfect Heat Pipes Collectors

New Products-Solar heating 1). SHC series CPC reflectors heat pipe collectors: biggest aperture area, highest power output, overheating solution 2). A9 series integrated pressure solar water heaters, EN12976 approved. 3). PVT, hybrid photovoltaic+solar thermal panels. …… Please contact with me

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote: > > Yes, I would suggest against expecting altinstructions to have > relocation information. They are generated in a different place, so.. > > That said, I honestly like the inline version (the one that is in the > google paper first) of

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Boots successfully with "noefi" kernel parameter :) On Fri, Jan 5, 2018 at 12:43 PM, Andy Lutomirski wrote: > >> On Jan 5, 2018, at 9:14 AM, Pavel Tatashin wrote: >> >> Hi Andy, >> >> This is bare metal, not VM, read my other email in this thread

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote: > > Yes, I would suggest against expecting altinstructions to have > relocation information. They are generated in a different place, so.. > > That said, I honestly like the inline version (the one that is in the > google paper first) of

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Boots successfully with "noefi" kernel parameter :) On Fri, Jan 5, 2018 at 12:43 PM, Andy Lutomirski wrote: > >> On Jan 5, 2018, at 9:14 AM, Pavel Tatashin wrote: >> >> Hi Andy, >> >> This is bare metal, not VM, read my other email in this thread about >> the machine on which I am testing.

[PATCH] phylink: mark expected switch fall-throughs in phylink_mii_ioctl

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1463447 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva --- This code was compiled with GCC 7.2.0

[PATCH] phylink: mark expected switch fall-throughs in phylink_mii_ioctl

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1463447 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva --- This code was compiled with GCC 7.2.0 drivers/net/phy/phylink.c | 2 ++ 1 file changed,

[PATCH] [v4] x86/doc: add PTI description

Changes from v3: * Increasingly minor text fixes. Changes from v2: * Update some wording * Minor typo and grammar fixes * Further clarify what INVPCID is. Changes from v1: * update kernel-parameters.txt to clarify that the pti= option is not just for disabling. Also describe what

[PATCH] [v4] x86/doc: add PTI description

Changes from v3: * Increasingly minor text fixes. Changes from v2: * Update some wording * Minor typo and grammar fixes * Further clarify what INVPCID is. Changes from v1: * update kernel-parameters.txt to clarify that the pti= option is not just for disabling. Also describe what

Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables

On 5 January 2018 at 17:41, Catalin Marinas wrote: > On Tue, Jan 02, 2018 at 08:05:44PM +, Ard Biesheuvel wrote: >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> index 10684b17d0bd..b6d51b4d5ce1 100644 >> --- a/drivers/pci/quirks.c >> +++

Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables

On 5 January 2018 at 17:41, Catalin Marinas wrote: > On Tue, Jan 02, 2018 at 08:05:44PM +, Ard Biesheuvel wrote: >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> index 10684b17d0bd..b6d51b4d5ce1 100644 >> --- a/drivers/pci/quirks.c >> +++ b/drivers/pci/quirks.c >> @@ -3556,9

Re: [PATCH] i40iw: Replace mdelay with msleep in i40iw_wait_pe_ready

On Sun, Dec 24, 2017 at 03:39:40AM -0700, Jia-Ju Bai wrote: > i40iw_wait_pe_ready is not called in an interrupt handler > nor holding a spinlock. > The function mdelay in it can be replaced with msleep, > to reduce busy wait. > > Signed-off-by: Jia-Ju Bai > --- >

Re: [PATCH] i40iw: Replace mdelay with msleep in i40iw_wait_pe_ready

On Sun, Dec 24, 2017 at 03:39:40AM -0700, Jia-Ju Bai wrote: > i40iw_wait_pe_ready is not called in an interrupt handler > nor holding a spinlock. > The function mdelay in it can be replaced with msleep, > to reduce busy wait. > > Signed-off-by: Jia-Ju Bai > --- >

Re: [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry

On 05/01/18 11:51, Honghui Zhang wrote: > On Thu, 2018-01-04 at 19:04 +, Marc Zyngier wrote: >> On 04/01/18 18:40, Lorenzo Pieralisi wrote: >>> [+Marc] >>> >>> On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zh...@mediatek.com wrote: From: Honghui Zhang

Re: [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry

On 05/01/18 11:51, Honghui Zhang wrote: > On Thu, 2018-01-04 at 19:04 +, Marc Zyngier wrote: >> On 04/01/18 18:40, Lorenzo Pieralisi wrote: >>> [+Marc] >>> >>> On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zh...@mediatek.com wrote: From: Honghui Zhang There maybe a same IRQ

Re: [PATCH 4.4 00/37] 4.4.110-stable review

> On Jan 5, 2018, at 9:14 AM, Pavel Tatashin wrote: > > Hi Andy, > > This is bare metal, not VM, read my other email in this thread about > the machine on which I am testing. Sometime hang happens a little > later: > > [5.088948] microcode: CPU36 sig=0x406f1,

Re: [PATCH 4.4 00/37] 4.4.110-stable review

> On Jan 5, 2018, at 9:14 AM, Pavel Tatashin wrote: > > Hi Andy, > > This is bare metal, not VM, read my other email in this thread about > the machine on which I am testing. Sometime hang happens a little > later: > > [5.088948] microcode: CPU36 sig=0x406f1, pf=0x1, revision=0xb1d >

[GIT PULL] xfs: fixes for 4.15-rc7

Hi Linus, I have just a few fixes for bugs and resource cleanup problems this week. It merges cleanly against your tree as of ~5min ago. --Darrick The following changes since commit 68c58e9b9a88c1a9d0c2eaf6c7acefb00f5fbbfb: xfs: only skip rmap owner checks for unknown-owner rmap removal

[GIT PULL] xfs: fixes for 4.15-rc7

Hi Linus, I have just a few fixes for bugs and resource cleanup problems this week. It merges cleanly against your tree as of ~5min ago. --Darrick The following changes since commit 68c58e9b9a88c1a9d0c2eaf6c7acefb00f5fbbfb: xfs: only skip rmap owner checks for unknown-owner rmap removal

Re: [PATCH v2] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"

On Fri, 5 Jan 2018, Andy Shevchenko wrote: > On Thu, 2017-12-28 at 13:34 +0100, Ingo Molnar wrote: > > * Andy Shevchenko wrote: > > > > > v2: low the tone of accusation that this made a regression > > > > BTW., don't worry about that aspect too much: after a

Re: [PATCH v2] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"

On Fri, 5 Jan 2018, Andy Shevchenko wrote: > On Thu, 2017-12-28 at 13:34 +0100, Ingo Molnar wrote: > > * Andy Shevchenko wrote: > > > > > v2: low the tone of accusation that this made a regression > > > > BTW., don't worry about that aspect too much: after a long debugging > > session it's > >

Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables

On Tue, Jan 02, 2018 at 08:05:44PM +, Ard Biesheuvel wrote: > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 10684b17d0bd..b6d51b4d5ce1 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev,

Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables

On Tue, Jan 02, 2018 at 08:05:44PM +, Ard Biesheuvel wrote: > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 10684b17d0bd..b6d51b4d5ce1 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev,

Re: [PATCH] kconfig: fix relational operators for bool and tristate symbols

2017-11-17 10:06 GMT+09:00 Nicolas Pitre : > Since commit 31847b67bec0 ("kconfig: allow use of relations other than > (in)equality") it is possible to use relational operators in Kconfig > statements. However, those operators give unexpected results when > applied to

Re: [PATCH] kconfig: fix relational operators for bool and tristate symbols

2017-11-17 10:06 GMT+09:00 Nicolas Pitre : > Since commit 31847b67bec0 ("kconfig: allow use of relations other than > (in)equality") it is possible to use relational operators in Kconfig > statements. However, those operators give unexpected results when > applied to bool/tristate values: > >

Re: [PATCH v2] serial: imx: fix endless loop during suspend

Hi Martin, On Fri, Jan 5, 2018 at 2:46 PM, Martin Kaiser wrote: > Hi Fabio and all, > > here's a different approach for fixing the awake issue that I see on my > board. I tried to stick as much as possible to the original order in > which the operations were done. Could you do

Re: [PATCH v2] serial: imx: fix endless loop during suspend

Hi Martin, On Fri, Jan 5, 2018 at 2:46 PM, Martin Kaiser wrote: > Hi Fabio and all, > > here's a different approach for fixing the awake issue that I see on my > board. I tried to stick as much as possible to the original order in > which the operations were done. Could you do a quick check on

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 5, 2018 at 9:12 AM, Woodhouse, David wrote: > > I typed 'jmp __x86.indirect_thunk' and it actually jumped to an address > which I believe is (__x86.indirect_thunk + - ). > Which made me sad, and took a while to debug. Yes, I would suggest against expecting

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 5, 2018 at 9:12 AM, Woodhouse, David wrote: > > I typed 'jmp __x86.indirect_thunk' and it actually jumped to an address > which I believe is (__x86.indirect_thunk + - ). > Which made me sad, and took a while to debug. Yes, I would suggest against expecting altinstructions to have

Re: [PATCH v2] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"

On Thu, 2017-12-28 at 13:34 +0100, Ingo Molnar wrote: > * Andy Shevchenko wrote: > > > v2: low the tone of accusation that this made a regression > > BTW., don't worry about that aspect too much: after a long debugging > session it's > pretty natural to be

Re: [PATCH v2] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"

On Thu, 2017-12-28 at 13:34 +0100, Ingo Molnar wrote: > * Andy Shevchenko wrote: > > > v2: low the tone of accusation that this made a regression > > BTW., don't worry about that aspect too much: after a long debugging > session it's > pretty natural to be upset at whoever introduced a

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, 2018-01-05 at 17:45 +0100, Borislav Petkov wrote: > On Fri, Jan 05, 2018 at 04:41:46PM +, Woodhouse, David wrote: > > Nope, alternatives are broken. Only a jmp as the *first* opcode of > > altinstr gets handled by recompute_jump(), while any subsequent insn is > > just copied

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, 2018-01-05 at 17:45 +0100, Borislav Petkov wrote: > On Fri, Jan 05, 2018 at 04:41:46PM +, Woodhouse, David wrote: > > Nope, alternatives are broken. Only a jmp as the *first* opcode of > > altinstr gets handled by recompute_jump(), while any subsequent insn is > > just copied

[PATCHv2 0/2] Improve stability of system clock

(resending with fixed CC) v1->v2 - rebased to current code - improved commit messages This patch set improves stability and accuracy of the system clock when synchronized to precise time sources like the new PTP KVM clock or NTP/PTP with hardware timestamping. The biggest difference is expected

[PATCHv2 0/2] Improve stability of system clock

(resending with fixed CC) v1->v2 - rebased to current code - improved commit messages This patch set improves stability and accuracy of the system clock when synchronized to precise time sources like the new PTP KVM clock or NTP/PTP with hardware timestamping. The biggest difference is expected

Re: [PATCH] selftests: sync: missing CFLAGS while compiling

On 5 January 2018 at 22:03, Anders Roxell wrote: > Based on patch: https://patchwork.kernel.org/patch/10042045/ > > arch64-linux-gnu-gcc -c sync.c -o sync/sync.o > sync.c:42:29: fatal error: linux/sync_file.h: No such file or directory > #include >

Re: [PATCH] selftests: sync: missing CFLAGS while compiling

On 5 January 2018 at 22:03, Anders Roxell wrote: > Based on patch: https://patchwork.kernel.org/patch/10042045/ > > arch64-linux-gnu-gcc -c sync.c -o sync/sync.o > sync.c:42:29: fatal error: linux/sync_file.h: No such file or directory > #include > ^ > CFLAGS is not

Re: [alsa-devel] [PATCH v6 07/14] regmap: Add SoundWire bus support

On 1/5/18 11:04 AM, Mark Brown wrote: On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: + /* SoundWire register address are contiguous */ + if (config->reg_stride != 0) + return -ENOTSUPP; That doesn't mean the chip hasn't decided not to use half the

Re: [alsa-devel] [PATCH v6 07/14] regmap: Add SoundWire bus support

On 1/5/18 11:04 AM, Mark Brown wrote: On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: + /* SoundWire register address are contiguous */ + if (config->reg_stride != 0) + return -ENOTSUPP; That doesn't mean the chip hasn't decided not to use half the

Re: [v2 PATCH 3/6] dt-bindings: usb: mtu3: update USB wakeup properties

On Wed, Jan 03, 2018 at 04:53:19PM +0800, Chunfeng Yun wrote: > Add two arguments in "mediatek,syscon-wakeup" to support multi > wakeup glue layer between SSUSB and SPM, and use standard property > "wakeup-source" to replace the private "mediatek,enable-wakeup" > > Signed-off-by: Chunfeng Yun

Re: [v2 PATCH 3/6] dt-bindings: usb: mtu3: update USB wakeup properties

On Wed, Jan 03, 2018 at 04:53:19PM +0800, Chunfeng Yun wrote: > Add two arguments in "mediatek,syscon-wakeup" to support multi > wakeup glue layer between SSUSB and SPM, and use standard property > "wakeup-source" to replace the private "mediatek,enable-wakeup" > > Signed-off-by: Chunfeng Yun >

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 4, 2018 at 5:11 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.110 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 4, 2018 at 5:11 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.110 release. > There are 37 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. > >

Re: [PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

On Fri, 5 Jan 2018 10:10:51 -0700 Logan Gunthorpe wrote: > On 04/01/18 08:33 PM, Alex Williamson wrote: > > That's exactly what IOMMU groups represent, the smallest set of devices > > which have DMA isolation from other devices. By poking this hole, the > > IOMMU group is

Re: [PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

On Fri, 5 Jan 2018 10:10:51 -0700 Logan Gunthorpe wrote: > On 04/01/18 08:33 PM, Alex Williamson wrote: > > That's exactly what IOMMU groups represent, the smallest set of devices > > which have DMA isolation from other devices. By poking this hole, the > > IOMMU group is invalid. We cannot

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

On Fri, 5 Jan 2018, Michal Hocko wrote: > Yes. I am really wondering because there souldn't anything specific to > improve the situation with patch 2 and 3. Likewise the only overhead > from the patch 1 I can see is the reduced batching of the mmap_sem. But > then I am wondering what would

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

On Fri, 5 Jan 2018, Michal Hocko wrote: > Yes. I am really wondering because there souldn't anything specific to > improve the situation with patch 2 and 3. Likewise the only overhead > from the patch 1 I can see is the reduced batching of the mmap_sem. But > then I am wondering what would

[PATCHv2 1/2] timekeeping: Don't align frequency adjustments to ticks

When the timekeeping multiplier is changed, the NTP error is updated to correct the clock for the delay between the tick and the update of the clock. This error is corrected in later updates and the clock appears as if the frequency was changed exactly on the tick. Remove this correction to keep

[PATCHv2 2/2] timekeeping: Determine multiplier directly from NTP tick length

When the length of the NTP tick changes significantly, e.g. when an NTP/PTP application is correcting the initial offset of the clock, a large value may accumulate in the NTP error before the multiplier converges to the correct value. It may then take a very long time (hours or even days) before

[PATCHv2 1/2] timekeeping: Don't align frequency adjustments to ticks

When the timekeeping multiplier is changed, the NTP error is updated to correct the clock for the delay between the tick and the update of the clock. This error is corrected in later updates and the clock appears as if the frequency was changed exactly on the tick. Remove this correction to keep

[PATCHv2 2/2] timekeeping: Determine multiplier directly from NTP tick length

When the length of the NTP tick changes significantly, e.g. when an NTP/PTP application is correcting the initial offset of the clock, a large value may accumulate in the NTP error before the multiplier converges to the correct value. It may then take a very long time (hours or even days) before

[PATCHv2 0/2] Improve stability of system clock

v1->v2 - rebased to current code - improved commit messages This patch set improves stability and accuracy of the system clock when synchronized to precise time sources like the new PTP KVM clock or NTP/PTP with hardware timestamping. The biggest difference is expected on mostly idle systems

[PATCHv2 0/2] Improve stability of system clock

v1->v2 - rebased to current code - improved commit messages This patch set improves stability and accuracy of the system clock when synchronized to precise time sources like the new PTP KVM clock or NTP/PTP with hardware timestamping. The biggest difference is expected on mostly idle systems

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Hi Andy, This is bare metal, not VM, read my other email in this thread about the machine on which I am testing. Sometime hang happens a little later: [5.088948] microcode: CPU36 sig=0x406f1, pf=0x1, revision=0xb1d [5.096076] microcode: CPU37 sig=0x406f1, pf=0x1, revision=0xb1d [

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Hi Andy, This is bare metal, not VM, read my other email in this thread about the machine on which I am testing. Sometime hang happens a little later: [5.088948] microcode: CPU36 sig=0x406f1, pf=0x1, revision=0xb1d [5.096076] microcode: CPU37 sig=0x406f1, pf=0x1, revision=0xb1d [

[PATCH 1/5] clk: divider: read-only divider can propagate rate change

When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the register shall be left un-touched, but it does not mean the clock should stop rate propagation if CLK_SET_RATE_PARENT is set This is properly handled in qcom clk-regmap-divider but it was not in the generic divider Fixes:

[PATCH 1/5] clk: divider: read-only divider can propagate rate change

When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the register shall be left un-touched, but it does not mean the clock should stop rate propagation if CLK_SET_RATE_PARENT is set This is properly handled in qcom clk-regmap-divider but it was not in the generic divider Fixes:

Re: [PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

On 04/01/18 08:33 PM, Alex Williamson wrote: That's exactly what IOMMU groups represent, the smallest set of devices which have DMA isolation from other devices. By poking this hole, the IOMMU group is invalid. We cannot turn off ACS only for a specific device, in order to enable p2p it

Re: [PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

On 04/01/18 08:33 PM, Alex Williamson wrote: That's exactly what IOMMU groups represent, the smallest set of devices which have DMA isolation from other devices. By poking this hole, the IOMMU group is invalid. We cannot turn off ACS only for a specific device, in order to enable p2p it

[PATCH 0/5] clk: read-only dividers and rate propagation fixup

A read-only divider may also have CLK_SET_RATE_PARENT flag set, in which case it should propagate the requested rate to its parent, taking the read-only divider value into account. While this is done correctly in qcom's clk-regmap-divider, it is not in the generic divider and lpc32xx. Other

[PATCH 5/5] clk: qcom: use divider_ro_round_rate helper

There is now an helper function to round the rate when the divider is read-only. Let's use it Signed-off-by: Jerome Brunet --- drivers/clk/qcom/clk-regmap-divider.c | 19 ++- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git

[PATCH 0/5] clk: read-only dividers and rate propagation fixup

A read-only divider may also have CLK_SET_RATE_PARENT flag set, in which case it should propagate the requested rate to its parent, taking the read-only divider value into account. While this is done correctly in qcom's clk-regmap-divider, it is not in the generic divider and lpc32xx. Other

[PATCH 5/5] clk: qcom: use divider_ro_round_rate helper

There is now an helper function to round the rate when the divider is read-only. Let's use it Signed-off-by: Jerome Brunet --- drivers/clk/qcom/clk-regmap-divider.c | 19 ++- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/clk/qcom/clk-regmap-divider.c

[PATCH 4/5] clk: lpc32xx: use divider_ro_round_rate helper

There is now an helper function to round the rate when the divider is read-only. Let's use it Signed-off-by: Jerome Brunet --- drivers/clk/nxp/clk-lpc32xx.c | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git

[PATCH 4/5] clk: lpc32xx: use divider_ro_round_rate helper

There is now an helper function to round the rate when the divider is read-only. Let's use it Signed-off-by: Jerome Brunet --- drivers/clk/nxp/clk-lpc32xx.c | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/drivers/clk/nxp/clk-lpc32xx.c

Re: [lkp-robot] [perf machine] 8edf8850d5: stderr./usr/src/linux-perf-x86_64-rhel-#/tools/perf/util/rb_resort.h:#:#:error:passing_argument#of'threads_sorted__new'from_incompatible_pointer_type[-Werro

On Thu, 04 Jan 2018, kernel test robot wrote: [ 68.830934] /usr/src/linux-perf-x86_64-rhel-7.2-8edf8850d51e911a35b5d7aad4f8604db11abc66/tools/perf/util/rb_resort.h:148:28: error: passing argument 1 of 'threads_sorted__new' from incompatible pointer type [-Werror=incompatible-pointer-types]

Re: [lkp-robot] [perf machine] 8edf8850d5: stderr./usr/src/linux-perf-x86_64-rhel-#/tools/perf/util/rb_resort.h:#:#:error:passing_argument#of'threads_sorted__new'from_incompatible_pointer_type[-Werro

On Thu, 04 Jan 2018, kernel test robot wrote: [ 68.830934] /usr/src/linux-perf-x86_64-rhel-7.2-8edf8850d51e911a35b5d7aad4f8604db11abc66/tools/perf/util/rb_resort.h:148:28: error: passing argument 1 of 'threads_sorted__new' from incompatible pointer type [-Werror=incompatible-pointer-types]

[PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change

When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the register shall be left un-touched, but it does not mean the clock should stop rate propagation if CLK_SET_RATE_PARENT is set This properly handled in qcom clk-regmap-divider but it was not in the lpc32xx divider Fixes:

RE: [V3 2/2] ASoC: max98373: Added Amplifier Driver

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, January 4, 2018 9:14 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; a...@arndb.de; >a...@ti.com; robert.jarz...@free.fr; supercraig0...@gmail.com;

[PATCH 3/5] clk: divider: add divider_ro_round_rate helper

Like divider_round_rate, a couple a of driver are doing more or less the same operation to round the rate of the divider when it is read-only. We can factor this code so let's provide an helper function for this Signed-off-by: Jerome Brunet --- drivers/clk/clk-divider.c

[PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change

When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the register shall be left un-touched, but it does not mean the clock should stop rate propagation if CLK_SET_RATE_PARENT is set This properly handled in qcom clk-regmap-divider but it was not in the lpc32xx divider Fixes:

RE: [V3 2/2] ASoC: max98373: Added Amplifier Driver

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, January 4, 2018 9:14 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; a...@arndb.de; >a...@ti.com; robert.jarz...@free.fr; supercraig0...@gmail.com; >jbru...@baylibre.com;

[PATCH 3/5] clk: divider: add divider_ro_round_rate helper

Like divider_round_rate, a couple a of driver are doing more or less the same operation to round the rate of the divider when it is read-only. We can factor this code so let's provide an helper function for this Signed-off-by: Jerome Brunet --- drivers/clk/clk-divider.c| 43

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 05:45:06PM +0100, Borislav Petkov wrote: > On Fri, Jan 05, 2018 at 04:41:46PM +, Woodhouse, David wrote: > > Nope, alternatives are broken. Only a jmp as the *first* opcode of > > altinstr gets handled by recompute_jump(), while any subsequent insn is > > just copied

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 05:45:06PM +0100, Borislav Petkov wrote: > On Fri, Jan 05, 2018 at 04:41:46PM +, Woodhouse, David wrote: > > Nope, alternatives are broken. Only a jmp as the *first* opcode of > > altinstr gets handled by recompute_jump(), while any subsequent insn is > > just copied

Re: [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation

On 01/05/2018 07:14 AM, Tom Lendacky wrote: > On 1/5/2018 5:14 AM, David Woodhouse wrote: >> On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >>> cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature >>> IA32_SPEC_CTRL (0x48) and IA32_PRED_CMD (0x49) >>> IA32_SPEC_CTRL, bit0 –

Re: [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation

On 01/05/2018 07:14 AM, Tom Lendacky wrote: > On 1/5/2018 5:14 AM, David Woodhouse wrote: >> On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >>> cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature >>> IA32_SPEC_CTRL (0x48) and IA32_PRED_CMD (0x49) >>> IA32_SPEC_CTRL, bit0 –

Re: [PATCH v6 07/14] regmap: Add SoundWire bus support

On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > SoundWire bus provides sdw_read() and sdw_write() APIs for Slave > devices to program the registers. Provide support in regmap for > SoundWire bus. I can't apply this because you've changed the soundwire Kconfig in this patch :(

Re: [PATCH v6 07/14] regmap: Add SoundWire bus support

On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote: > SoundWire bus provides sdw_read() and sdw_write() APIs for Slave > devices to program the registers. Provide support in regmap for > SoundWire bus. I can't apply this because you've changed the soundwire Kconfig in this patch :(

<    3   4   5   6   7   8   9   10   11   12   >