[GIT PULL 1/2] bcm2835-dt-next-2018-02-28

Hi Florian, The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) are available in the Git repository at: git://github.com/anholt/linux tags/bcm2835-dt-next-2018-02-28 for you to fetch changes up to

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote: I think I found the reason for the strange crashes we were experiencing (emac core->name being NULL) thanks to Sekhar who pointed me in the right direction. The mdio driver fails to probe with v7 due to the supplied clock rate being wrong.

[GIT PULL 1/2] bcm2835-dt-next-2018-02-28

Hi Florian, The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) are available in the Git repository at: git://github.com/anholt/linux tags/bcm2835-dt-next-2018-02-28 for you to fetch changes up to

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote: I think I found the reason for the strange crashes we were experiencing (emac core->name being NULL) thanks to Sekhar who pointed me in the right direction. The mdio driver fails to probe with v7 due to the supplied clock rate being wrong.

Re: [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/02/2018 19:27, Maran Wilson wrote: > Sorry for the delay between this version and the last -- it was mostly > due to holidays and everyone being focused on security bug mitigation > issues. Here are the links to the previous email threads in case it is > helpful: > > V3:

Re: [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/02/2018 19:27, Maran Wilson wrote: > Sorry for the delay between this version and the last -- it was mostly > due to holidays and everyone being focused on security bug mitigation > issues. Here are the links to the previous email threads in case it is > helpful: > > V3:

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote: > +obj-$(CONFIG_XEN_PVH) += pvh.o > +obj-$(CONFIG_XEN_PVH) += pvh-head.o > + Probably a better place for these would be arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no .c or .S files in arch/x86). Maybe Xen ought to be

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote: > +obj-$(CONFIG_XEN_PVH) += pvh.o > +obj-$(CONFIG_XEN_PVH) += pvh-head.o > + Probably a better place for these would be arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no .c or .S files in arch/x86). Maybe Xen ought to be

Re: [PATCH] pci: Store more data about VFs into the SRIOV struct

On Wed, 2018-02-28 at 15:30 -0600, Bjorn Helgaas wrote: > On Wed, Jan 17, 2018 at 06:44:23PM +0100, KarimAllah Ahmed wrote: > > > > ... to avoid reading them from the config space of all the PCI VFs. This is > > specially a useful optimization when bringing up thousands of VFs. > > > > Cc: Bjorn

Re: [PATCH] pci: Store more data about VFs into the SRIOV struct

On Wed, 2018-02-28 at 15:30 -0600, Bjorn Helgaas wrote: > On Wed, Jan 17, 2018 at 06:44:23PM +0100, KarimAllah Ahmed wrote: > > > > ... to avoid reading them from the config space of all the PCI VFs. This is > > specially a useful optimization when bringing up thousands of VFs. > > > > Cc: Bjorn

[PATCH v3] Documentation: Update ncurses package names for menuconfig

The package name is ncurses-devel for Redhat based distros and libncurses-dev for Debian based distros. Signed-off-by: Arvind Prasanna --- Changes in v3: - Fix a package name in the commit message. Changes in v2: - Add a missing echo as pointed out by one of the

[PATCH v3] Documentation: Update ncurses package names for menuconfig

The package name is ncurses-devel for Redhat based distros and libncurses-dev for Debian based distros. Signed-off-by: Arvind Prasanna --- Changes in v3: - Fix a package name in the commit message. Changes in v2: - Add a missing echo as pointed out by one of the reviewers.

Re: [PATCH] selftests/bpf: Add bpf_probe_read_str to bpf_helpers.h

On 02/28/2018 10:28 PM, Tushar Dave wrote: > On 02/28/2018 08:57 AM, Daniel Borkmann wrote: >> Hi Tushar, >> >> On 02/28/2018 01:33 AM, Tushar Dave wrote: >>> Using bpf_probe_read_str() from samples/bpf causes compiler warning. >>> e.g. >>> warning: implicit declaration of function

Re: [PATCH] selftests/bpf: Add bpf_probe_read_str to bpf_helpers.h

On 02/28/2018 10:28 PM, Tushar Dave wrote: > On 02/28/2018 08:57 AM, Daniel Borkmann wrote: >> Hi Tushar, >> >> On 02/28/2018 01:33 AM, Tushar Dave wrote: >>> Using bpf_probe_read_str() from samples/bpf causes compiler warning. >>> e.g. >>> warning: implicit declaration of function

Re: [PATCH] pci: Store more data about VFs into the SRIOV struct

On Wed, Jan 17, 2018 at 06:44:23PM +0100, KarimAllah Ahmed wrote: > ... to avoid reading them from the config space of all the PCI VFs. This is > specially a useful optimization when bringing up thousands of VFs. > > Cc: Bjorn Helgaas > Cc: linux-...@vger.kernel.org > Cc:

Re: [PATCH] pci: Store more data about VFs into the SRIOV struct

On Wed, Jan 17, 2018 at 06:44:23PM +0100, KarimAllah Ahmed wrote: > ... to avoid reading them from the config space of all the PCI VFs. This is > specially a useful optimization when bringing up thousands of VFs. > > Cc: Bjorn Helgaas > Cc: linux-...@vger.kernel.org > Cc:

Re: [PATCH] selftests/bpf: Add bpf_probe_read_str to bpf_helpers.h

On 02/28/2018 08:57 AM, Daniel Borkmann wrote: Hi Tushar, On 02/28/2018 01:33 AM, Tushar Dave wrote: Using bpf_probe_read_str() from samples/bpf causes compiler warning. e.g. warning: implicit declaration of function 'bpf_probe_read_str' is invalid in C99

Re: [PATCH] selftests/bpf: Add bpf_probe_read_str to bpf_helpers.h

On 02/28/2018 08:57 AM, Daniel Borkmann wrote: Hi Tushar, On 02/28/2018 01:33 AM, Tushar Dave wrote: Using bpf_probe_read_str() from samples/bpf causes compiler warning. e.g. warning: implicit declaration of function 'bpf_probe_read_str' is invalid in C99

Re: [PATCH V2] PCI/ASPM: Suppress common clock mode setting failure

On Mon, Jan 22, 2018 at 03:12:01PM -0500, Sinan Kaya wrote: > Code is emitting warnings when it tries to set the common clock mode for > ASPM and ASPM is already configured to common clock mode by the UEFI BIOS. > Let's bail out silently in such a case. > > pci 0004:00:00.0: ASPM: Could not

Re: [PATCH V2] PCI/ASPM: Suppress common clock mode setting failure

On Mon, Jan 22, 2018 at 03:12:01PM -0500, Sinan Kaya wrote: > Code is emitting warnings when it tries to set the common clock mode for > ASPM and ASPM is already configured to common clock mode by the UEFI BIOS. > Let's bail out silently in such a case. > > pci 0004:00:00.0: ASPM: Could not

Re: [PATCH v2 00/16] Implement H3/H5 HDMI driver

operation for some resolutions, > is also fixed. > > Code is based on linux-next, next-20180226 tag. Today I tried on this series on next-20180228, but resolution switching doesn't really work. The reason for this is use of clk_set_rate_exclusive() in sun4i_tcon1_mode_set(). If I rev

Re: [PATCH v2 00/16] Implement H3/H5 HDMI driver

operation for some resolutions, > is also fixed. > > Code is based on linux-next, next-20180226 tag. Today I tried on this series on next-20180228, but resolution switching doesn't really work. The reason for this is use of clk_set_rate_exclusive() in sun4i_tcon1_mode_set(). If I rev

Re: [PATCH v2 01/15] KVM: s390: refactor crypto initialization

On 02/28/2018 12:37 PM, Cornelia Huck wrote: On Tue, 27 Feb 2018 09:27:59 -0500 Tony Krowiak wrote: The crypto control block designation (CRYCBD) is a 32-bit field in the KVM guest's SIE state description. The contents of bits 1-28 of this field, with three zero

Re: [PATCH v2 01/15] KVM: s390: refactor crypto initialization

On 02/28/2018 12:37 PM, Cornelia Huck wrote: On Tue, 27 Feb 2018 09:27:59 -0500 Tony Krowiak wrote: The crypto control block designation (CRYCBD) is a 32-bit field in the KVM guest's SIE state description. The contents of bits 1-28 of this field, with three zero bits appended on the right,

Re: 4.16 regression: s2ram broken on non-PAE i686

Woody, On Wed, 28 Feb 2018, Woody Suwalski wrote: > Certainly. I understand you want dmesg output for kernels build with and > without PAE, not just PAE=n on the cmdline :-) > Here it is... Thanks for providing the data. It did not pinpoint the issue but at least it gave me the hint to look into

Re: 4.16 regression: s2ram broken on non-PAE i686

Woody, On Wed, 28 Feb 2018, Woody Suwalski wrote: > Certainly. I understand you want dmesg output for kernels build with and > without PAE, not just PAE=n on the cmdline :-) > Here it is... Thanks for providing the data. It did not pinpoint the issue but at least it gave me the hint to look into

[PATCH] rtc: nvmem: allow registering the nvmem device before the rtc

Switch the parent of the nvmem device to the parent of the rtc device so it can be registered before the RTC. This is a small change in the ABI as the nvmem moves out of the /sys/class/rtc/rtcX folder to be under the parent device folder (that is where the previous nvram files where registered).

[PATCH] rtc: nvmem: allow registering the nvmem device before the rtc

Switch the parent of the nvmem device to the parent of the rtc device so it can be registered before the RTC. This is a small change in the ABI as the nvmem moves out of the /sys/class/rtc/rtcX folder to be under the parent device folder (that is where the previous nvram files where registered).

Re: [RFT 0/7] firmware: enable caching of firmware for reboot optimization

On 28/02/18 20:45, Luis R. Rodriguez wrote: On Wed, Feb 28, 2018 at 08:03:26PM +0200, cantabile wrote: On 28/02/18 01:20, Luis R. Rodriguez wrote: Cantabile, please give these patches a spin and let me know if it fixes your reported issue. They depend on other pending patches I have in line

Re: [RFT 0/7] firmware: enable caching of firmware for reboot optimization

On 28/02/18 20:45, Luis R. Rodriguez wrote: On Wed, Feb 28, 2018 at 08:03:26PM +0200, cantabile wrote: On 28/02/18 01:20, Luis R. Rodriguez wrote: Cantabile, please give these patches a spin and let me know if it fixes your reported issue. They depend on other pending patches I have in line

Re: [PATCH] regmap: irq: fix ack-invert

On Tue, Feb 27, 2018 at 10:39 AM, Tony Lindgren wrote: > * Tim Harvey [180227 16:07]: >> When acking irqs we need to take into account the ack-invert case. Without >> this chips that require 0's to ACK interrupts will never clear the interrupt. >> >> I am

Re: [PATCH] regmap: irq: fix ack-invert

On Tue, Feb 27, 2018 at 10:39 AM, Tony Lindgren wrote: > * Tim Harvey [180227 16:07]: >> When acking irqs we need to take into account the ack-invert case. Without >> this chips that require 0's to ACK interrupts will never clear the interrupt. >> >> I am working on an mfd driver that will use

Re: [PATCH] IB/rxe: Remove unused variable (char *rxe_qp_state_name[])

On Tue, Feb 27, 2018 at 07:07:58PM -0300, Hernán Gonzalez wrote: > Note: This is compile only tested as I have no access to the hw. > This variable was not used anywhere in the code. Removing it saves 24 bytes. > > add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-24 (-24) > Function

Re: [PATCH] IB/rxe: Remove unused variable (char *rxe_qp_state_name[])

On Tue, Feb 27, 2018 at 07:07:58PM -0300, Hernán Gonzalez wrote: > Note: This is compile only tested as I have no access to the hw. > This variable was not used anywhere in the code. Removing it saves 24 bytes. > > add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-24 (-24) > Function

Re: [RFC 2/4] mfd: add Gateworks System Controller core driver

On Wed, Feb 28, 2018 at 10:53 AM, Andrew Lunn wrote: >> + dev_err(>dev, ">> 0x%02x %d\n", reg, ret); >> + return ret; >> + } >> + dev_dbg(>dev, ">> 0x%02x=0x%02x (%d)\n", reg, val, retry); >> + >> +return 0; > > Hi Tim > > There appears to

Re: [PATCH 1/2] IB/qib: Remove unused variable (char *qib_sdma_event_names[])

On Tue, Feb 27, 2018 at 07:05:42PM -0300, Hernán Gonzalez wrote: > Note: This is compile only tested as I have no access to the hw. > > This variable was not used anywhere in the code. Removing it saves 88 bytes. > > add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-88 (-88) > Function

Re: [RFC 2/4] mfd: add Gateworks System Controller core driver

On Wed, Feb 28, 2018 at 10:53 AM, Andrew Lunn wrote: >> + dev_err(>dev, ">> 0x%02x %d\n", reg, ret); >> + return ret; >> + } >> + dev_dbg(>dev, ">> 0x%02x=0x%02x (%d)\n", reg, val, retry); >> + >> +return 0; > > Hi Tim > > There appears to be a few spaces

Re: [PATCH 1/2] IB/qib: Remove unused variable (char *qib_sdma_event_names[])

On Tue, Feb 27, 2018 at 07:05:42PM -0300, Hernán Gonzalez wrote: > Note: This is compile only tested as I have no access to the hw. > > This variable was not used anywhere in the code. Removing it saves 88 bytes. > > add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-88 (-88) > Function

Re: [PATCH 1/2] infiniband: qplib_fp: fix pointer cast

On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote: > Building for a 32-bit target results in a couple of warnings from casting > between > a 32-bit pointer and a 64-bit integer: > > drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq': >

Re: [PATCH 1/2] infiniband: qplib_fp: fix pointer cast

On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote: > Building for a 32-bit target results in a couple of warnings from casting > between > a 32-bit pointer and a 64-bit integer: > > drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq': >

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On Wed, Feb 28, 2018 at 10:27:58AM -0800, Maran Wilson wrote: > Once hypervisors other than Xen start using the PVH entry point for > starting VMs, we would like the option of being able to compile PVH entry > capable kernels without enabling CONFIG_XEN and all the code that comes > along with

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On Wed, Feb 28, 2018 at 10:27:58AM -0800, Maran Wilson wrote: > Once hypervisors other than Xen start using the PVH entry point for > starting VMs, we would like the option of being able to compile PVH entry > capable kernels without enabling CONFIG_XEN and all the code that comes > along with

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote: > In order to pave the way for hypervisors other then Xen to use the PVH > entry point for VMs, we need to factor the PVH entry code into Xen specific > and hypervisor agnostic components. The first step in doing that, is to > create a

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote: > In order to pave the way for hypervisors other then Xen to use the PVH > entry point for VMs, we need to factor the PVH entry code into Xen specific > and hypervisor agnostic components. The first step in doing that, is to > create a

Re: [PATCH] IB/usnic: Delete an error message for a failed memory allocation in usnic_transport_init()

On Sat, Jan 27, 2018 at 08:15:17PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jan 2018 20:06:59 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle

Re: [RFC 2/4] mfd: add Gateworks System Controller core driver

On Tue, Feb 27, 2018 at 6:00 PM, Randy Dunlap wrote: > On 02/27/2018 05:21 PM, Tim Harvey wrote: >> The Gateworks System Controller (GSC) is an I2C slave controller >> implemented with an MSP430 micro-controller whose firmware embeds the >> following features: >> - I/O

Re: [PATCH] IB/usnic: Delete an error message for a failed memory allocation in usnic_transport_init()

On Sat, Jan 27, 2018 at 08:15:17PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jan 2018 20:06:59 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus

Re: [RFC 2/4] mfd: add Gateworks System Controller core driver

On Tue, Feb 27, 2018 at 6:00 PM, Randy Dunlap wrote: > On 02/27/2018 05:21 PM, Tim Harvey wrote: >> The Gateworks System Controller (GSC) is an I2C slave controller >> implemented with an MSP430 micro-controller whose firmware embeds the >> following features: >> - I/O expander (16 GPIO's) using

Re: [PATCH 1/3] RDMA/iwpm: Delete an error message for a failed memory allocation in iwpm_create_nlmsg()

On Sat, Jan 27, 2018 at 10:19:05PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jan 2018 21:48:01 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle

Re: [PATCH 1/3] RDMA/iwpm: Delete an error message for a failed memory allocation in iwpm_create_nlmsg()

On Sat, Jan 27, 2018 at 10:19:05PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jan 2018 21:48:01 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus

Re: [Xen-devel] [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

On Wed, Feb 28, 2018 at 10:27:59AM -0800, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > The first step in that direction is to create a new file that will > eventually hold the Xen specific routines. >

Re: [Xen-devel] [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

On Wed, Feb 28, 2018 at 10:27:59AM -0800, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > The first step in that direction is to create a new file that will > eventually hold the Xen specific routines. >

Re: [Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

On Wed, Feb 28, 2018 at 10:28:00AM -0800, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific

Re: [Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

On Wed, Feb 28, 2018 at 10:28:00AM -0800, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific

[GIT PULL] kselftest fixes update for 4.16-rc4

Hi Linus, Please pull the following Kselftest update for 4.16-rc4. This kselftest fixes update for 4.16-rc4 consists of of fixes for various problems in test output, compile errors, and missing configs. Diff for the update is attached. thanks, -- Shuah

[GIT PULL] kselftest fixes update for 4.16-rc4

Hi Linus, Please pull the following Kselftest update for 4.16-rc4. This kselftest fixes update for 4.16-rc4 consists of of fixes for various problems in test output, compile errors, and missing configs. Diff for the update is attached. thanks, -- Shuah

Re: [PATCH] rcu: Call wake_nocb_leader_defer() with 'FORCE' when nocb_q_count is high

On Wed, Feb 28, 2018 at 02:49:02PM +0900, Byungchul Park wrote: > If many callbacks have been queued and waking up the nocb leader should > be deferred, then we should wake up the leader unconditionally when > it's safe to do so. > > It was well managed in commit fbce7497ee(rcu: Parallelize and

Re: [PATCH] rcu: Call wake_nocb_leader_defer() with 'FORCE' when nocb_q_count is high

On Wed, Feb 28, 2018 at 02:49:02PM +0900, Byungchul Park wrote: > If many callbacks have been queued and waking up the nocb leader should > be deferred, then we should wake up the leader unconditionally when > it's safe to do so. > > It was well managed in commit fbce7497ee(rcu: Parallelize and

xhci: Not enough bandwidth for new device state

Hi, I am getting these messages from a Debian 9.3 system using Linux 4.9.x: [ 547.352746] usb 3-5.2: 3:1: usb_set_interface failed (-28) [ 548.352865] usb 3-5.3: Not enough bandwidth for new device state. [ 548.352868] usb 3-5.3: Not enough bandwidth for altsetting 1 I have connected a 7-Port

xhci: Not enough bandwidth for new device state

Hi, I am getting these messages from a Debian 9.3 system using Linux 4.9.x: [ 547.352746] usb 3-5.2: 3:1: usb_set_interface failed (-28) [ 548.352865] usb 3-5.3: Not enough bandwidth for new device state. [ 548.352868] usb 3-5.3: Not enough bandwidth for altsetting 1 I have connected a 7-Port

[BUG] Kernel crash on Allwinner H3 due to sound core changes

Hi all, with todays linux-next (next-20180228), kernel on Allwinner H3 SoC crashes with dmesg like that: https://pastebin.com/raw/0D5JeaJ8 I bisected the kernel and first offending commit is: be7ee5f32a9a ("ASoC: soc-generic-dmaengine-pcm: replace platform to component") I know

Re: [RFC PATCH] Randomization of address chosen by mmap.

The option to add at least one guard page would be useful whether or not it's tied to randomization. It's not feasible to do that in userspace for mmap as a whole, only specific users of mmap like malloc and it adds significant overhead vs. a kernel implementation. It could optionally let you

[BUG] Kernel crash on Allwinner H3 due to sound core changes

Hi all, with todays linux-next (next-20180228), kernel on Allwinner H3 SoC crashes with dmesg like that: https://pastebin.com/raw/0D5JeaJ8 I bisected the kernel and first offending commit is: be7ee5f32a9a ("ASoC: soc-generic-dmaengine-pcm: replace platform to component") I know

Re: [RFC PATCH] Randomization of address chosen by mmap.

The option to add at least one guard page would be useful whether or not it's tied to randomization. It's not feasible to do that in userspace for mmap as a whole, only specific users of mmap like malloc and it adds significant overhead vs. a kernel implementation. It could optionally let you

RE: [PATCH v2 0/8] Decode IA32/X64 CPER

> -Original Message- > From: Borislav Petkov [mailto:b...@suse.de] > Sent: Wednesday, February 28, 2018 11:36 AM > To: Ghannam, Yazen > Cc: Tony Luck ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; ard.biesheu...@linaro.org;

RE: [PATCH v2 0/8] Decode IA32/X64 CPER

> -Original Message- > From: Borislav Petkov [mailto:b...@suse.de] > Sent: Wednesday, February 28, 2018 11:36 AM > To: Ghannam, Yazen > Cc: Tony Luck ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; ard.biesheu...@linaro.org; x...@kernel.org > Subject: Re: [PATCH v2 0/8]

Re: [PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/28/18 12:19, Andy Shevchenko wrote: > On Wed, Feb 28, 2018 at 9:44 PM, Frank Rowand wrote: >> On 02/28/18 11:31, Andy Shevchenko wrote: >>> On Wed, Feb 28, 2018 at 9:04 PM, wrote: > >>> The question is why O(1) is so important? O(log(n))

Re: [PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On 02/28/18 12:19, Andy Shevchenko wrote: > On Wed, Feb 28, 2018 at 9:44 PM, Frank Rowand wrote: >> On 02/28/18 11:31, Andy Shevchenko wrote: >>> On Wed, Feb 28, 2018 at 9:04 PM, wrote: > >>> The question is why O(1) is so important? O(log(n)) wouldn't work? >> >> O(1) is not critical. It was

[PATCH] x86/tsc: Always Running Timer (ART) nanoseconds clocksource

Some clock distribution mechanisms (e.g. PCIe-PTM) require time to be distributed in units of nanoseconds. In order to cross-timestamp local device time across domains the local device timestamp needs to be correlated with TSC. On systems that support ART, a CPUID leaf (0x15) returns parameter

[PATCH] x86/tsc: Always Running Timer (ART) nanoseconds clocksource

Some clock distribution mechanisms (e.g. PCIe-PTM) require time to be distributed in units of nanoseconds. In order to cross-timestamp local device time across domains the local device timestamp needs to be correlated with TSC. On systems that support ART, a CPUID leaf (0x15) returns parameter

Re: [PATCH] PCI/ASPM: Change type of threshold_ns variable to u32

On Tue, Feb 27, 2018 at 05:19:52PM -0600, Gustavo A. R. Silva wrote: > It seems that the expression threshold_us * 1000 will never exceed the > 32-bit limits [1]. So changing the type of threshold_ns from u64 to u32 > seems sensible [2]. > > [1] https://marc.info/?l=linux-kernel=151855021100725=2

Re: [PATCH] PCI/ASPM: Change type of threshold_ns variable to u32

On Tue, Feb 27, 2018 at 05:19:52PM -0600, Gustavo A. R. Silva wrote: > It seems that the expression threshold_us * 1000 will never exceed the > 32-bit limits [1]. So changing the type of threshold_ns from u64 to u32 > seems sensible [2]. > > [1] https://marc.info/?l=linux-kernel=151855021100725=2

Re: [PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On Wed, Feb 28, 2018 at 2:19 PM, Andy Shevchenko wrote: > On Wed, Feb 28, 2018 at 9:44 PM, Frank Rowand wrote: >> On 02/28/18 11:31, Andy Shevchenko wrote: >>> On Wed, Feb 28, 2018 at 9:04 PM, wrote: > >>> The question

Re: [PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On Wed, Feb 28, 2018 at 2:19 PM, Andy Shevchenko wrote: > On Wed, Feb 28, 2018 at 9:44 PM, Frank Rowand wrote: >> On 02/28/18 11:31, Andy Shevchenko wrote: >>> On Wed, Feb 28, 2018 at 9:04 PM, wrote: > >>> The question is why O(1) is so important? O(log(n)) wouldn't work? >> >> O(1) is not

Re: [PATCH] Documentation: Update ncurses package names for menuconfig

Hi, I think that you are missing my point, so let me start over and try to clarify it. In the patch description, it says "libncurses-devel" (not libncurses-dev). In the patch itself, it says libncurses-dev (not libncurses-devel). I suspect that one of these is incorrect. Which one is it?

Re: [PATCH] Documentation: Update ncurses package names for menuconfig

Hi, I think that you are missing my point, so let me start over and try to clarify it. In the patch description, it says "libncurses-devel" (not libncurses-dev). In the patch itself, it says libncurses-dev (not libncurses-devel). I suspect that one of these is incorrect. Which one is it?

Re: [PATCH] of: Kconfig: OF_OVERLAY, select OF_EARLY_FLATTREE

Sorry for the delay, been away for a few days. On Mon, Feb 19, 2018 at 12:24 AM, Frank Rowand wrote: > > On 02/18/18 17:46, Rob Herring wrote: > > On Sun, Feb 18, 2018 at 6:29 PM, wrote: > >> From: Frank Rowand > >> > >>

Re: [PATCH] of: Kconfig: OF_OVERLAY, select OF_EARLY_FLATTREE

Sorry for the delay, been away for a few days. On Mon, Feb 19, 2018 at 12:24 AM, Frank Rowand wrote: > > On 02/18/18 17:46, Rob Herring wrote: > > On Sun, Feb 18, 2018 at 6:29 PM, wrote: > >> From: Frank Rowand > >> > >> kbuild test robot reported a new warning for a recent patch: >

Re: [PATCH v2 13/15] KVM: s390: Configure the guest's CRYCB

On 02/28/2018 04:49 AM, David Hildenbrand wrote: +static int vfio_ap_mdev_open(struct mdev_device *mdev) +{ + struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); + unsigned long events; + int ret; + + matrix_mdev->group_notifier.notifier_call =

Re: [PATCH v2 13/15] KVM: s390: Configure the guest's CRYCB

On 02/28/2018 04:49 AM, David Hildenbrand wrote: +static int vfio_ap_mdev_open(struct mdev_device *mdev) +{ + struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); + unsigned long events; + int ret; + + matrix_mdev->group_notifier.notifier_call =

Re: [PATCH v2 08/15] KVM: s390: interface to enable AP execution mode

On 02/28/2018 04:44 AM, David Hildenbrand wrote: On 27.02.2018 15:28, Tony Krowiak wrote: Introduces a new interface to enable AP interpretive execution (IE) mode for the KVM guest. When running with IE mode enabled, AP instructions executed on the KVM guest will be interpreted by the firmware

Re: [PATCH v2 08/15] KVM: s390: interface to enable AP execution mode

On 02/28/2018 04:44 AM, David Hildenbrand wrote: On 27.02.2018 15:28, Tony Krowiak wrote: Introduces a new interface to enable AP interpretive execution (IE) mode for the KVM guest. When running with IE mode enabled, AP instructions executed on the KVM guest will be interpreted by the firmware

Re: [PATCH v2 08/15] KVM: s390: interface to enable AP execution mode

On 02/28/2018 04:42 AM, David Hildenbrand wrote: On 27.02.2018 15:28, Tony Krowiak wrote: Introduces a new interface to enable AP interpretive execution (IE) mode for the KVM guest. When running with IE mode enabled, AP instructions executed on the KVM guest will be interpreted by the firmware

Re: [PATCH v2 08/15] KVM: s390: interface to enable AP execution mode

On 02/28/2018 04:42 AM, David Hildenbrand wrote: On 27.02.2018 15:28, Tony Krowiak wrote: Introduces a new interface to enable AP interpretive execution (IE) mode for the KVM guest. When running with IE mode enabled, AP instructions executed on the KVM guest will be interpreted by the firmware

Re: [PATCH v2 05/15] s390: vfio-ap: base implementation of VFIO AP device driver

On 02/28/2018 01:10 PM, Cornelia Huck wrote: On Wed, 28 Feb 2018 11:43:37 -0500 Tony Krowiak wrote: On 02/28/2018 10:33 AM, Pierre Morel wrote: On 27/02/2018 15:28, Tony Krowiak wrote: (...) diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index

Re: [PATCH v2 05/15] s390: vfio-ap: base implementation of VFIO AP device driver

On 02/28/2018 01:10 PM, Cornelia Huck wrote: On Wed, 28 Feb 2018 11:43:37 -0500 Tony Krowiak wrote: On 02/28/2018 10:33 AM, Pierre Morel wrote: On 27/02/2018 15:28, Tony Krowiak wrote: (...) diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index cbe1d97..9f23caf 100644 ---

[PATCH V2] x86: mce: fix kernel panic when check_interval is changed

I am Seunghun Han and a senior security researcher at National Security Research Institute of South Korea. I found a security issue which can make kernel panic in userspace. After analyzing the issue carefully, I found that MCE driver in the kernel has a problem which can be occurred in SMP

[PATCH V2] x86: mce: fix kernel panic when check_interval is changed

I am Seunghun Han and a senior security researcher at National Security Research Institute of South Korea. I found a security issue which can make kernel panic in userspace. After analyzing the issue carefully, I found that MCE driver in the kernel has a problem which can be occurred in SMP

Re: [PATCH 2/5] tpm: migrate tpm2_shutdown() to use struct tpm_buf

On Wed, Feb 28, 2018 at 09:58:15PM +0200, Jarkko Sakkinen wrote: > In order to make struct tpm_buf the first class object for constructing TPM > commands, migrate tpm2_shutdown() to use it. In addition, removed the klog > entry when tpm_transmit_cmd() fails because tpm_tansmit_cmd() already >

Re: [PATCH 2/5] tpm: migrate tpm2_shutdown() to use struct tpm_buf

On Wed, Feb 28, 2018 at 09:58:15PM +0200, Jarkko Sakkinen wrote: > In order to make struct tpm_buf the first class object for constructing TPM > commands, migrate tpm2_shutdown() to use it. In addition, removed the klog > entry when tpm_transmit_cmd() fails because tpm_tansmit_cmd() already >

Re: [PATCH] tinydrm: add backlight dependency

On Wed, Feb 28, 2018 at 02:40:48PM +0100, Arnd Bergmann wrote: > Calling devm_of_find_backlight directly means we get a link failure > without CONFIG_BACKLIGHT_CLASS_DEVICE: > > drivers/gpu/drm/tinydrm/mi0283qt.o: In function `mi0283qt_probe': > mi0283qt.c:(.text+0x684): undefined reference to

Re: [PATCH] tinydrm: add backlight dependency

On Wed, Feb 28, 2018 at 02:40:48PM +0100, Arnd Bergmann wrote: > Calling devm_of_find_backlight directly means we get a link failure > without CONFIG_BACKLIGHT_CLASS_DEVICE: > > drivers/gpu/drm/tinydrm/mi0283qt.o: In function `mi0283qt_probe': > mi0283qt.c:(.text+0x684): undefined reference to

Re: [PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On Wed, Feb 28, 2018 at 9:44 PM, Frank Rowand wrote: > On 02/28/18 11:31, Andy Shevchenko wrote: >> On Wed, Feb 28, 2018 at 9:04 PM, wrote: >> The question is why O(1) is so important? O(log(n)) wouldn't work? > > O(1) is not critical. It was

Re: [PATCH v4 1/2] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()

On Wed, Feb 28, 2018 at 9:44 PM, Frank Rowand wrote: > On 02/28/18 11:31, Andy Shevchenko wrote: >> On Wed, Feb 28, 2018 at 9:04 PM, wrote: >> The question is why O(1) is so important? O(log(n)) wouldn't work? > > O(1) is not critical. It was just a nice side result. > > >> Using radix_tree()

Re: [PATCH v4 2/4] HID: steam: add serial number information.

On Wed, Feb 28, 2018 at 8:43 PM, Rodrigo Rivas Costa wrote: > This device has a feature report to send and receive commands. > Use it to get the serial number and set the device's uniq value. > #include > #include > #include > +#include Better to keep it

Re: [PATCH v4 2/4] HID: steam: add serial number information.

On Wed, Feb 28, 2018 at 8:43 PM, Rodrigo Rivas Costa wrote: > This device has a feature report to send and receive commands. > Use it to get the serial number and set the device's uniq value. > #include > #include > #include > +#include Better to keep it somehow sorted (yes, I see it's

[PATCH 3/3] vfio/pci: Add ioeventfd support

The ioeventfd here is actually irqfd handling of an ioeventfd such as supported in KVM. A user is able to pre-program a device write to occur when the eventfd triggers. This is yet another instance of eventfd-irqfd triggering between KVM and vfio. The impetus for this is high frequency writes

[PATCH 3/3] vfio/pci: Add ioeventfd support

The ioeventfd here is actually irqfd handling of an ioeventfd such as supported in KVM. A user is able to pre-program a device write to occur when the eventfd triggers. This is yet another instance of eventfd-irqfd triggering between KVM and vfio. The impetus for this is high frequency writes

[PATCH 2/3] vfio/pci: Use endian neutral helpers

The iowriteXX/ioreadXX functions assume little endian hardware and convert to little endian on a write and from little endian on a read. We currently do our own explicit conversion to negate this. Instead, add some endian dependent defines to avoid all byte swaps. There should be no functional

[PATCH 2/3] vfio/pci: Use endian neutral helpers

The iowriteXX/ioreadXX functions assume little endian hardware and convert to little endian on a write and from little endian on a read. We currently do our own explicit conversion to negate this. Instead, add some endian dependent defines to avoid all byte swaps. There should be no functional

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