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

[+cc Alex] On Thu, Jan 04, 2018 at 12:01:29PM -0700, Logan Gunthorpe wrote: > When the ACS P2P flags are set in the downstream port of the switch, > any P2P TLPs will be sent back to the root complex. The whole point of > the P2P work is to have TLPs avoid the RC seeing it may not support > P2P

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

[+cc Alex] On Thu, Jan 04, 2018 at 12:01:29PM -0700, Logan Gunthorpe wrote: > When the ACS P2P flags are set in the downstream port of the switch, > any P2P TLPs will be sent back to the root complex. The whole point of > the P2P work is to have TLPs avoid the RC seeing it may not support > P2P

[PATCH][RESEND] cgroup, docs: document the root cgroup behavior of cpu and io controllers

Currently, cgroups v2 documentation contains only a generic remark that "How resource consumption in the root cgroup is governed is up to each controller", which isn't really telling users much, who need to dig in the code and / or commit messages to learn the exact behavior. In cgroups v1 at

[PATCH][RESEND] cgroup, docs: document the root cgroup behavior of cpu and io controllers

Currently, cgroups v2 documentation contains only a generic remark that "How resource consumption in the root cgroup is governed is up to each controller", which isn't really telling users much, who need to dig in the code and / or commit messages to learn the exact behavior. In cgroups v1 at

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

[6.159992] Code: 89 83 78 06 01 00 b8 01 00 00 00 5b 41 5c 41 5d 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 31 d2 48 8b 87 c8 00 00 00 48 89 e5 0f c1 50 0c 89 97 d0 00 00 00 83 e2 01 b8 01 00 00 00 74 1d Also, attached is the full console output. Thank you, Pavel On Thu, Jan 4, 2018 at

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

[6.159992] Code: 89 83 78 06 01 00 b8 01 00 00 00 5b 41 5c 41 5d 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 31 d2 48 8b 87 c8 00 00 00 48 89 e5 0f c1 50 0c 89 97 d0 00 00 00 83 e2 01 b8 01 00 00 00 74 1d Also, attached is the full console output. Thank you, Pavel On Thu, Jan 4, 2018 at

Re: [PATCH 02/12] pci-p2p: Add sysfs group to display p2pmem stats

On Thu, Jan 04, 2018 at 12:01:27PM -0700, Logan Gunthorpe wrote: > Attributes display the total amount of P2P memory, the ammount available > and whether it is published or not. s/ammount/amount/ (also below) > Signed-off-by: Logan Gunthorpe > --- >

Re: [PATCH 02/12] pci-p2p: Add sysfs group to display p2pmem stats

On Thu, Jan 04, 2018 at 12:01:27PM -0700, Logan Gunthorpe wrote: > Attributes display the total amount of P2P memory, the ammount available > and whether it is published or not. s/ammount/amount/ (also below) > Signed-off-by: Logan Gunthorpe > --- > Documentation/ABI/testing/sysfs-bus-pci | 25

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu 2018-01-04 21:23:59, Alan Cox wrote: > On Thu, 4 Jan 2018 21:39:24 +0100 (CET) > Jiri Kosina wrote: > > > On Thu, 4 Jan 2018, Alan Cox wrote: > > > > > You never go from one user process to another except via the kernel. We > > > have no hardware scheduling going on.

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu 2018-01-04 21:23:59, Alan Cox wrote: > On Thu, 4 Jan 2018 21:39:24 +0100 (CET) > Jiri Kosina wrote: > > > On Thu, 4 Jan 2018, Alan Cox wrote: > > > > > You never go from one user process to another except via the kernel. We > > > have no hardware scheduling going on. That means that if

[PATCH v4] gpio: winbond: add driver

This commit adds GPIO driver for Winbond Super I/Os. Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is supported but in the future a support for other Winbond models, too, can be added to the driver. A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit 0 is

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

On Thu, Jan 04, 2018 at 01:27:49PM -0800, Rao Shoaib wrote: > On 01/04/2018 12:35 PM, Rao Shoaib wrote: > > As far as your previous comments are concerned, only the following one > > has not been addressed. Can you please elaborate as I do not understand > > the comment. The code was expanded

[PATCH v4] gpio: winbond: add driver

This commit adds GPIO driver for Winbond Super I/Os. Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is supported but in the future a support for other Winbond models, too, can be added to the driver. A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit 0 is

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

On Thu, Jan 04, 2018 at 01:27:49PM -0800, Rao Shoaib wrote: > On 01/04/2018 12:35 PM, Rao Shoaib wrote: > > As far as your previous comments are concerned, only the following one > > has not been addressed. Can you please elaborate as I do not understand > > the comment. The code was expanded

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

On Thu, 4 Jan 2018, Dave Hansen wrote: > > - pti=[X86_64] > + pti=[X86_64] Disable Page Table Isolation of user and That description is definitely wrong > + kernel address spaces. Disabling this feature > + removes

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

On Thu, 4 Jan 2018, Dave Hansen wrote: > > - pti=[X86_64] > + pti=[X86_64] Disable Page Table Isolation of user and That description is definitely wrong > + kernel address spaces. Disabling this feature > + removes

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, Jan 4, 2018 at 11:26 AM, Pavel Machek wrote: > Hi! > >> >> > What remains to be seen is if there are other patterns that affect >> >> > different processors. >> >> > >> >> > In the longer term the compiler itself needs to know what is and isn't >> >> > safe (ie you need to

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, Jan 4, 2018 at 11:26 AM, Pavel Machek wrote: > Hi! > >> >> > What remains to be seen is if there are other patterns that affect >> >> > different processors. >> >> > >> >> > In the longer term the compiler itself needs to know what is and isn't >> >> > safe (ie you need to be able to

Re: bonding: Completion of error handling around bond_update_slave_arr()

>>> If you see 8 out of 9 call sites in this file ignore the return value. >> >> How do you think about to fix error detection and corresponding >> exception handling then? >> > If I understand your question correctly - not having memory is not a > correctable error I am unsure if it would be

Re: bonding: Completion of error handling around bond_update_slave_arr()

>>> If you see 8 out of 9 call sites in this file ignore the return value. >> >> How do you think about to fix error detection and corresponding >> exception handling then? >> > If I understand your question correctly - not having memory is not a > correctable error I am unsure if it would be

Re: [PATCH 01/12] pci-p2p: Support peer to peer memory

Run "git log --oneline drivers/pci" and follow the convention. I think it would make sense to add a new tag like "PCI/P2P", although "P2P" has historically also been used in the "PCI-to-PCI bridge" context, so maybe there's something less ambiguous. "P2PDMA"? When you add new files, I guess

Re: [PATCH 01/12] pci-p2p: Support peer to peer memory

Run "git log --oneline drivers/pci" and follow the convention. I think it would make sense to add a new tag like "PCI/P2P", although "P2P" has historically also been used in the "PCI-to-PCI bridge" context, so maybe there's something less ambiguous. "P2PDMA"? When you add new files, I guess

Re: LKML admins (syzbot emails are not delivered)

On Thu 2018-01-04 12:09:26, Dmitry Vyukov wrote: > On Thu, Jan 4, 2018 at 10:56 AM, Pavel Machek wrote: > >> On Thu, 2018-01-04 at 10:25 +0100, Pavel Machek wrote: > >> > Hi! > >> > > > >> > > Some of syzbot emails don't appear on LKML mailing lists, while they > >> > > were mailed

Re: LKML admins (syzbot emails are not delivered)

On Thu 2018-01-04 12:09:26, Dmitry Vyukov wrote: > On Thu, Jan 4, 2018 at 10:56 AM, Pavel Machek wrote: > >> On Thu, 2018-01-04 at 10:25 +0100, Pavel Machek wrote: > >> > Hi! > >> > > > >> > > Some of syzbot emails don't appear on LKML mailing lists, while they > >> > > were mailed as any other

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

On Thu, Jan 4, 2018 at 1:23 PM, Pavel Tatashin wrote: > I tried cherry picking > 435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the > pagetable hierarchy > > on top of 4.4.110-rc1, (needed to resolve a small 5level table to > 4level page table conflict).

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

On Thu, Jan 4, 2018 at 1:23 PM, Pavel Tatashin wrote: > I tried cherry picking > 435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the > pagetable hierarchy > > on top of 4.4.110-rc1, (needed to resolve a small 5level table to > 4level page table conflict). Unfortunately, this does not

Re: [PATCH V7 12/12] arm64: dts: add clocks for SC9860

On Thu, Dec 7, 2017 at 1:57 PM, Chunyan Zhang wrote: > Some clocks on SC9860 are in the same address area with syscon devices, > those are what have a property of 'sprd,syscon' which would refer to > syscon devices, others would have a reg property indicated their

Re: [PATCH V7 12/12] arm64: dts: add clocks for SC9860

On Thu, Dec 7, 2017 at 1:57 PM, Chunyan Zhang wrote: > Some clocks on SC9860 are in the same address area with syscon devices, > those are what have a property of 'sprd,syscon' which would refer to > syscon devices, others would have a reg property indicated their address > ranges. > >

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

On 01/04/2018 12:35 PM, Rao Shoaib wrote: Hi Boqun, Thanks a lot for all your guidance and for catching the cut and paster error. Please see inline. On 01/03/2018 05:38 PM, Boqun Feng wrote: But you introduced a bug here, you should use rcu_state_p instead of _sched_state as the third

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

On 01/04/2018 12:35 PM, Rao Shoaib wrote: Hi Boqun, Thanks a lot for all your guidance and for catching the cut and paster error. Please see inline. On 01/03/2018 05:38 PM, Boqun Feng wrote: But you introduced a bug here, you should use rcu_state_p instead of _sched_state as the third

Re: Bricked x86 CPU with software?

> On Thu, Jan 4, 2018 at 11:00 PM, Tim Mouraveiko wrote: > > Pavel, > > > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > > and reset BIOS > > and etc. It made no difference. I can see that the processor was not > > drawing any power. The > >

Re: Bricked x86 CPU with software?

> On Thu, Jan 4, 2018 at 11:00 PM, Tim Mouraveiko wrote: > > Pavel, > > > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > > and reset BIOS > > and etc. It made no difference. I can see that the processor was not > > drawing any power. The > > software code behaved

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, 4 Jan 2018 21:39:24 +0100 (CET) Jiri Kosina wrote: > On Thu, 4 Jan 2018, Alan Cox wrote: > > > You never go from one user process to another except via the kernel. We > > have no hardware scheduling going on. That means that if the kernel > > and/or CPU imposes the

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, 4 Jan 2018 21:39:24 +0100 (CET) Jiri Kosina wrote: > On Thu, 4 Jan 2018, Alan Cox wrote: > > > You never go from one user process to another except via the kernel. We > > have no hardware scheduling going on. That means that if the kernel > > and/or CPU imposes the correct speculation

Re: Bricked x86 CPU with software?

Hi! > As I mentioned before, I repeatedly and fully power-cycled the motherboard > and reset BIOS > and etc. It made no difference. I can see that the processor was not drawing > any power. The > software code behaved in a similar fashion on other processors, until I fixed > it so that it

Re: Bricked x86 CPU with software?

Hi! > As I mentioned before, I repeatedly and fully power-cycled the motherboard > and reset BIOS > and etc. It made no difference. I can see that the processor was not drawing > any power. The > software code behaved in a similar fashion on other processors, until I fixed > it so that it

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

I tried cherry picking 435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy on top of 4.4.110-rc1, (needed to resolve a small 5level table to 4level page table conflict). Unfortunately, this does not solve the panic/hanging problem I reported. For some reason I do

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

I tried cherry picking 435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy on top of 4.4.110-rc1, (needed to resolve a small 5level table to 4level page table conflict). Unfortunately, this does not solve the panic/hanging problem I reported. For some reason I do

Re: [PATCH v4 6/7] ARM: davinci: convert to common clock framework

On 01/04/2018 01:26 PM, Adam Ford wrote: On Thu, Jan 4, 2018 at 11:50 AM, David Lechner wrote: On 1/4/18 6:39 AM, Sekhar Nori wrote: On Monday 01 January 2018 05:09 AM, David Lechner wrote: This converts all of arch/arm/mach-davinci to the common clock framework.

Re: [PATCH v4 6/7] ARM: davinci: convert to common clock framework

On 01/04/2018 01:26 PM, Adam Ford wrote: On Thu, Jan 4, 2018 at 11:50 AM, David Lechner wrote: On 1/4/18 6:39 AM, Sekhar Nori wrote: On Monday 01 January 2018 05:09 AM, David Lechner wrote: This converts all of arch/arm/mach-davinci to the common clock framework. The clock drivers from

RE: [PATCH 0/7] IBRS patch series

> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse > wrote: > > > > On Skylake the target for a 'ret' instruction may also come from the > > BTB. So if you ever let the RSB (which remembers where the 'call's came > > from get empty, you end up vulnerable. > > That sounds

RE: [PATCH 0/7] IBRS patch series

> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse > wrote: > > > > On Skylake the target for a 'ret' instruction may also come from the > > BTB. So if you ever let the RSB (which remembers where the 'call's came > > from get empty, you end up vulnerable. > > That sounds like it could cause

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

> On Jan 4, 2018, at 12:57 PM, Hugh Dickins wrote: > >> On Thu, Jan 4, 2018 at 12:43 PM, Andy Lutomirski wrote: >> On Jan 4, 2018, at 12:29 PM, Linus Torvalds wrote: On Thu, Jan 4, 2018 at 12:16 PM,

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

> On Jan 4, 2018, at 12:57 PM, Hugh Dickins wrote: > >> On Thu, Jan 4, 2018 at 12:43 PM, Andy Lutomirski wrote: >> On Jan 4, 2018, at 12:29 PM, Linus Torvalds wrote: On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: Attached a screenshot. Is that

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On 01/04/2018 12:51 PM, Yves-Alexis Perez wrote: > On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >> @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in, >> u32 ecx_in, >> "=S" (*esi) >> : "a" (func), "b" (ebx_in), "c" (ecx_in) >>

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On 01/04/2018 12:51 PM, Yves-Alexis Perez wrote: > On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >> @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in, >> u32 ecx_in, >> "=S" (*esi) >> : "a" (func), "b" (ebx_in), "c" (ecx_in) >>

[PATCH 2/3] powerpc/pci: use of_irq_parse_and_map_pci helper

Instead of calling both of_irq_parse_pci and irq_create_of_mapping, call of_irq_parse_and_map_pci instead which does the same thing. This will allow making of_irq_parse_pci a private, static function. This changes the logic slightly in that the fallback path will also be taken if

[PATCH 2/3] powerpc/pci: use of_irq_parse_and_map_pci helper

Instead of calling both of_irq_parse_pci and irq_create_of_mapping, call of_irq_parse_and_map_pci instead which does the same thing. This will allow making of_irq_parse_pci a private, static function. This changes the logic slightly in that the fallback path will also be taken if

[PATCH 1/3] PCI: move OF related PCI functions into PCI core

Following what has been done for other subsystems, move the remaining PCI related code out of drivers/of/ and into drivers/pci/of.c With this, we can kill a few kconfig symbols. Cc: Frank Rowand Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org

[PATCH 1/3] PCI: move OF related PCI functions into PCI core

Following what has been done for other subsystems, move the remaining PCI related code out of drivers/of/ and into drivers/pci/of.c With this, we can kill a few kconfig symbols. Cc: Frank Rowand Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring ---

[PATCH 0/3] PCI: move DT PCI functions to PCI core

Most subsystem specific functions have been moved into the respective subsystems. Only PCI and networking remain. This series moves most of the PCI related code to drivers/pci/of.c. Some bus address functions for PCI remain in of/address.c because we don't have infrastructure to split up the per

[PATCH 0/3] PCI: move DT PCI functions to PCI core

Most subsystem specific functions have been moved into the respective subsystems. Only PCI and networking remain. This series moves most of the PCI related code to drivers/pci/of.c. Some bus address functions for PCI remain in of/address.c because we don't have infrastructure to split up the per

[PATCH 3/3] PCI: make of_irq_parse_pci static

Now that the DT PCI code is merged into drivers/pci, of_irq_parse_pci can be static. Cc: Bjorn Helgaas Cc: Frank Rowand Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring --- drivers/pci/of.c | 3 +--

[PATCH 3/3] PCI: make of_irq_parse_pci static

Now that the DT PCI code is merged into drivers/pci, of_irq_parse_pci can be static. Cc: Bjorn Helgaas Cc: Frank Rowand Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring --- drivers/pci/of.c | 3 +-- include/linux/of_pci.h | 6 -- 2 files changed, 1 insertion(+), 8

Re: [PATCH v6 00/11] Intel SGX Driver

On Jan 4, 3:27pm, Greg Kroah-Hartman wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Wild day, enjoyed by all I'm sure. > On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote: > > So how does this protect against the MELTDOWN attack (CVE-2017-5754) > > and the MELTATOMBOMBA4

Re: [PATCH v6 00/11] Intel SGX Driver

On Jan 4, 3:27pm, Greg Kroah-Hartman wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Wild day, enjoyed by all I'm sure. > On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote: > > So how does this protect against the MELTDOWN attack (CVE-2017-5754) > > and the MELTATOMBOMBA4

Re: Bricked x86 CPU with software?

On Thu, Jan 4, 2018 at 11:00 PM, Tim Mouraveiko wrote: > Pavel, > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > and reset BIOS > and etc. It made no difference. I can see that the processor was not drawing > any power. The > software code

Re: Bricked x86 CPU with software?

On Thu, Jan 4, 2018 at 11:00 PM, Tim Mouraveiko wrote: > Pavel, > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > and reset BIOS > and etc. It made no difference. I can see that the processor was not drawing > any power. The > software code behaved in a similar

[rdma for-next] bnxt_re: report RoCE device support at info level

Reporting that a device doesn't support RoCE seems like a valuable piece of information to have when trying to determine why a driver is not binding to a device. Better to report this at info log level instead of requiring a user to enable all debug messages in the driver. Signed-off-by: Jonathan

[rdma for-next] bnxt_re: report RoCE device support at info level

Reporting that a device doesn't support RoCE seems like a valuable piece of information to have when trying to determine why a driver is not binding to a device. Better to report this at info log level instead of requiring a user to enable all debug messages in the driver. Signed-off-by: Jonathan

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote: > > Are there plans to make the corresponding microcode support available? > > > > The microcode patches should be released soon. In the meantime, Lenovo has started issuing BIOS/UEFI updates which include microcode updates for this. See for

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote: > > Are there plans to make the corresponding microcode support available? > > > > The microcode patches should be released soon. In the meantime, Lenovo has started issuing BIOS/UEFI updates which include microcode updates for this. See for

[PATCH V3] perf script: add script to profile and resolve physical mem type

From: Kan Liang There could be different types of memory in the system. E.g normal System Memory, Persistent Memory. To understand how the workload maps to those memories, it's important to know the I/O statistics of them. Perf can collect physical addresses, but those are

[PATCH V3] perf script: add script to profile and resolve physical mem type

From: Kan Liang There could be different types of memory in the system. E.g normal System Memory, Persistent Memory. To understand how the workload maps to those memories, it's important to know the I/O statistics of them. Perf can collect physical addresses, but those are raw data. It still

Re: Bricked x86 CPU with software?

Pavel, As I mentioned before, I repeatedly and fully power-cycled the motherboard and reset BIOS and etc. It made no difference. I can see that the processor was not drawing any power. The software code behaved in a similar fashion on other processors, until I fixed it so that it would not

Re: Bricked x86 CPU with software?

Pavel, As I mentioned before, I repeatedly and fully power-cycled the motherboard and reset BIOS and etc. It made no difference. I can see that the processor was not drawing any power. The software code behaved in a similar fashion on other processors, until I fixed it so that it would not

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/04/2018 12:16 PM, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:47AM -0800, Tim Chen wrote: >> There are 2 ways to control IBRS >> >> 1. At boot time >> noibrs kernel boot parameter will disable IBRS usage >> >> Otherwise if the above parameters are not specified, the system >> will

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/04/2018 12:16 PM, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:47AM -0800, Tim Chen wrote: >> There are 2 ways to control IBRS >> >> 1. At boot time >> noibrs kernel boot parameter will disable IBRS usage >> >> Otherwise if the above parameters are not specified, the system >> will

Re: [PATCH v1 11/15] ASoC: fsl_ssi: Setup AC97 in dai_probe()

On Thu, Jan 04, 2018 at 09:38:52PM +0100, Maciej S. Szmigiero wrote: > > Hmm...What's the dependency here? Why is it required like this? > And a AC'97 CODEC probe needs AC'97 communication to be working, > since it has to detect the CODEC model, configure it, etc. Okay. If the CODEC

Re: [PATCH v1 11/15] ASoC: fsl_ssi: Setup AC97 in dai_probe()

On Thu, Jan 04, 2018 at 09:38:52PM +0100, Maciej S. Szmigiero wrote: > > Hmm...What's the dependency here? Why is it required like this? > And a AC'97 CODEC probe needs AC'97 communication to be working, > since it has to detect the CODEC model, configure it, etc. Okay. If the CODEC

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: > @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in, > u32 ecx_in, > "=S" (*esi) > : "a" (func), "b" (ebx_in), "c" (ecx_in) > : "memory", "cc"); > +

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: > @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in, > u32 ecx_in, > "=S" (*esi) > : "a" (func), "b" (ebx_in), "c" (ecx_in) > : "memory", "cc"); > +

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

On Thu, Jan 4, 2018 at 12:43 PM, Andy Lutomirski wrote: > >> On Jan 4, 2018, at 12:29 PM, Linus Torvalds >> wrote: >> >>> On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: >>> >>> Attached a screenshot. >>> Is that useful?

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

On Thu, Jan 4, 2018 at 12:43 PM, Andy Lutomirski wrote: > >> On Jan 4, 2018, at 12:29 PM, Linus Torvalds >> wrote: >> >>> On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: >>> >>> Attached a screenshot. >>> Is that useful? Are there some debug options I can add? >> >> Not much of an oops,

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

Hi! > > It falls there so that the cpu only issues reads with known good 'index' > > values. > > > >> I suspect it would be better to have those barriers in the tun/tap > >> interfaces where userspace can inject packets and thus time them. Then > >> the code could still speculate and go fast

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

Hi! > > It falls there so that the cpu only issues reads with known good 'index' > > values. > > > >> I suspect it would be better to have those barriers in the tun/tap > >> interfaces where userspace can inject packets and thus time them. Then > >> the code could still speculate and go fast

Re: [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

On Thu, 4 Jan 2018, Chen-Yu Tsai wrote: > Nicolas mentioned that the MCPM framework is likely overkill in our > case [4]. However the framework does provide cluster/core state tracking > and proper sequencing of cache related operations. We could rework > the code to use standard smp_ops, but I

Re: [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

On Thu, 4 Jan 2018, Chen-Yu Tsai wrote: > Nicolas mentioned that the MCPM framework is likely overkill in our > case [4]. However the framework does provide cluster/core state tracking > and proper sequencing of cache related operations. We could rework > the code to use standard smp_ops, but I

[PATCH] x86/doc: add PTI description

This got kicked out of the PTI set as the implementation diverged from its contents. I've updated it so it can hopefully rejoin the set. --- From: Dave Hansen Add some details about how PTI works, what some of the downsides are, and how to debug it when things go

[PATCH] x86/doc: add PTI description

This got kicked out of the PTI set as the implementation diverged from its contents. I've updated it so it can hopefully rejoin the set. --- From: Dave Hansen Add some details about how PTI works, what some of the downsides are, and how to debug it when things go wrong. Also document the

Re: [patch V5 02/11] LICENSES: Add the GPL 2.0 license

Carmen, On Thu, Jan 4, 2018 at 5:25 PM, Carmen Bianca Bakker wrote: > Hi all, > > Since December, `GPL-2.0` is no longer the correct identifier for the > licence. The American FSF has been in talks with the SPDX Workgroup to > change it to `GPL-2.0-only`. > > See the

Re: [patch V5 02/11] LICENSES: Add the GPL 2.0 license

Carmen, On Thu, Jan 4, 2018 at 5:25 PM, Carmen Bianca Bakker wrote: > Hi all, > > Since December, `GPL-2.0` is no longer the correct identifier for the > licence. The American FSF has been in talks with the SPDX Workgroup to > change it to `GPL-2.0-only`. > > See the rationale here: > >

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, Jan 04, 2018 at 09:05:15PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > From: David Woodhouse > > > > We are impervious to the indirect branch prediction attack with retpoline > > but firmware won't be, so we still

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, Jan 04, 2018 at 09:05:15PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > From: David Woodhouse > > > > We are impervious to the indirect branch prediction attack with retpoline > > but firmware won't be, so we still need to set IBRS to

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

On 01/04/2018 11:58 AM, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:42AM -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 – Indirect Branch Restricted Speculation (IBRS) >>

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

On 01/04/2018 11:58 AM, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:42AM -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 – Indirect Branch Restricted Speculation (IBRS) >>

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

On 01/04/2018 09:56 AM, Tim Chen wrote: > If NMI runs when exiting kernel between IBRS_DISABLE and > SWAPGS, the NMI would have turned on IBRS bit 0 and then it would have > left enabled when exiting the NMI. IBRS bit 0 would then be left > enabled in userland until the next enter kernel. > >

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

On 01/04/2018 09:56 AM, Tim Chen wrote: > If NMI runs when exiting kernel between IBRS_DISABLE and > SWAPGS, the NMI would have turned on IBRS bit 0 and then it would have > left enabled when exiting the NMI. IBRS bit 0 would then be left > enabled in userland until the next enter kernel. > >

Re: [PATCH] ps3_gelic_net: Delete an error message for a failed memory allocation in gelic_descr_prepare_rx()

On 01/03/2018 06:40 AM, SF Markus Elfring wrote: > Omit an extra message for a memory allocation failure in this function. I applied this to my ps3-queue branch. As I mentioned to you several times before, please keep the commit subject line to less than 50 characters. Also, in this case the

Re: [PATCH] ps3_gelic_net: Delete an error message for a failed memory allocation in gelic_descr_prepare_rx()

On 01/03/2018 06:40 AM, SF Markus Elfring wrote: > Omit an extra message for a memory allocation failure in this function. I applied this to my ps3-queue branch. As I mentioned to you several times before, please keep the commit subject line to less than 50 characters. Also, in this case the

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

> On Jan 4, 2018, at 12:29 PM, Linus Torvalds > wrote: > >> On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: >> >> Attached a screenshot. >> Is that useful? Are there some debug options I can add? > > Not much of an oops, because the

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

> On Jan 4, 2018, at 12:29 PM, Linus Torvalds > wrote: > >> On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: >> >> Attached a screenshot. >> Is that useful? Are there some debug options I can add? > > Not much of an oops, because the SIGSEGV happens in user space. The > only reason

Re: [PATCH v3 3/9] v4l: platform: Add Renesas CEU driver

Hi Jacopo, Thank you for the patch. On Thursday, 4 January 2018 18:03:11 EET Jacopo Mondi wrote: > Add driver for Renesas Capture Engine Unit (CEU). > > The CEU interface supports capturing 'data' (YUV422) and 'images' > (NV[12|21|16|61]). > > This driver aims to replace the soc_camera-based

Re: [PATCH v3 3/9] v4l: platform: Add Renesas CEU driver

Hi Jacopo, Thank you for the patch. On Thursday, 4 January 2018 18:03:11 EET Jacopo Mondi wrote: > Add driver for Renesas Capture Engine Unit (CEU). > > The CEU interface supports capturing 'data' (YUV422) and 'images' > (NV[12|21|16|61]). > > This driver aims to replace the soc_camera-based

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

Hi! > > So this is in that same category, but yes, it's inconvenient. > > Disagreed, violently. CPU has to execute the instructions I ask it to > execute, and if it executes *anything* else that reveals any information > about the instructions that have *not* been executed, it's flawed. I

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

Hi! > > So this is in that same category, but yes, it's inconvenient. > > Disagreed, violently. CPU has to execute the instructions I ask it to > execute, and if it executes *anything* else that reveals any information > about the instructions that have *not* been executed, it's flawed. I

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, 4 Jan 2018, Alan Cox wrote: > You never go from one user process to another except via the kernel. We > have no hardware scheduling going on. That means that if the kernel > and/or CPU imposes the correct speculation barriers you can't attack > anyone but yourself. So how does this work

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, 4 Jan 2018, Alan Cox wrote: > You never go from one user process to another except via the kernel. We > have no hardware scheduling going on. That means that if the kernel > and/or CPU imposes the correct speculation barriers you can't attack > anyone but yourself. So how does this work

Re: [PATCH v1 11/15] ASoC: fsl_ssi: Setup AC97 in dai_probe()

On 04.01.2018 20:07, Nicolin Chen wrote: > On Mon, Jan 01, 2018 at 04:17:20PM +0100, Maciej S. Szmigiero wrote: >>> AC97 configures some registers earlier to start a communication >>> with CODECs, so this patch moves those register settings to the >>> dai_probe() as well, along with other register

Re: [PATCH v1 11/15] ASoC: fsl_ssi: Setup AC97 in dai_probe()

On 04.01.2018 20:07, Nicolin Chen wrote: > On Mon, Jan 01, 2018 at 04:17:20PM +0100, Maciej S. Szmigiero wrote: >>> AC97 configures some registers earlier to start a communication >>> with CODECs, so this patch moves those register settings to the >>> dai_probe() as well, along with other register

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