[RFC][PATCH 3/4] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands

From: Suren Baghdasaryan When handling SHDLC I-Frame commands "pipe" field used for indexing into an array should be checked before usage. If left unchecked it might access memory outside of the array of size NFC_HCI_MAX_PIPES(127). Signed-off-by: Suren Baghdasaryan

[RFC][PATCH 3/4] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands

From: Suren Baghdasaryan When handling SHDLC I-Frame commands "pipe" field used for indexing into an array should be checked before usage. If left unchecked it might access memory outside of the array of size NFC_HCI_MAX_PIPES(127). Signed-off-by: Suren Baghdasaryan Signed-off-by: Amit Pundir

[RFC][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler

From: Suren Baghdasaryan Overflow on memcpy is possible in kernel driver for st21nfca's NFC HCI layer when handling connectivity events if aid_len or params_len are bigger than the buffer size. Memory leak is possible when parameter tag is invalid. Signed-off-by: Suren

[RFC][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler

From: Suren Baghdasaryan Overflow on memcpy is possible in kernel driver for st21nfca's NFC HCI layer when handling connectivity events if aid_len or params_len are bigger than the buffer size. Memory leak is possible when parameter tag is invalid. Signed-off-by: Suren Baghdasaryan

[RFC][PATCH 4/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver

From: Suren Baghdasaryan Possible buffer overflow when reading next_read_size bytes into tmp buffer after next_read_size was extracted from a previous packet. Signed-off-by: Suren Baghdasaryan Signed-off-by: Amit Pundir ---

[RFC][PATCH 4/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver

From: Suren Baghdasaryan Possible buffer overflow when reading next_read_size bytes into tmp buffer after next_read_size was extracted from a previous packet. Signed-off-by: Suren Baghdasaryan Signed-off-by: Amit Pundir --- drivers/nfc/fdp/i2c.c | 10 ++ 1 file changed, 10

[RFC][PATCH 0/4] Few NFC changes from experimental/android-4.14 tree

Hi, I ran into following NFC fixes in experimental/android-4.14 tree[1] and they seem like reasonable upstream candidates. So posting them here for review and comments. Also like to point out that I have not feature tested these patches at all. Only made a couple of small tweaks to the patches

[RFC][PATCH 0/4] Few NFC changes from experimental/android-4.14 tree

Hi, I ran into following NFC fixes in experimental/android-4.14 tree[1] and they seem like reasonable upstream candidates. So posting them here for review and comments. Also like to point out that I have not feature tested these patches at all. Only made a couple of small tweaks to the patches

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

Hi Greg, On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. I'm sorry, but I already objected to this one during the discussion here: https://patchwork.kernel.org/patch/10065483/ [PATCH 4.13 03/28]

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

Hi Greg, On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. I'm sorry, but I already objected to this one during the discussion here: https://patchwork.kernel.org/patch/10065483/ [PATCH 4.13 03/28]

Re: [PATCH V2] iommu/amd - Set the device table entry PPR bit for IOMMU V2 devices

On 12/20/2017 01:02 PM, Alex Williamson wrote: On Tue, 19 Dec 2017 16:15:41 -0600 Gary R Hook wrote: The AMD IOMMU specification Rev 3.00 (December 2016) introduces a new Enhanced PPR Handling Support (EPHSup) bit in the MMIO register offset 0030h (IOMMU Extended Feature

Re: [PATCH V2] iommu/amd - Set the device table entry PPR bit for IOMMU V2 devices

On 12/20/2017 01:02 PM, Alex Williamson wrote: On Tue, 19 Dec 2017 16:15:41 -0600 Gary R Hook wrote: The AMD IOMMU specification Rev 3.00 (December 2016) introduces a new Enhanced PPR Handling Support (EPHSup) bit in the MMIO register offset 0030h (IOMMU Extended Feature Register). When

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

On Wed, 20 Dec 2017, Juergen Gross wrote: > On 20/12/17 01:22, Thomas Gleixner wrote: > > On Tue, 19 Dec 2017, Thomas Gleixner wrote: > >> On Tue, 19 Dec 2017, Ingo Molnar wrote: > >> We don't run out of space, but the 0-day robot triggered a nasty issue. > >> > >> The fixmap bottom address, which

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

On Wed, 20 Dec 2017, Juergen Gross wrote: > On 20/12/17 01:22, Thomas Gleixner wrote: > > On Tue, 19 Dec 2017, Thomas Gleixner wrote: > >> On Tue, 19 Dec 2017, Ingo Molnar wrote: > >> We don't run out of space, but the 0-day robot triggered a nasty issue. > >> > >> The fixmap bottom address, which

[PATCH] USB: serial: ftdi_sio: add id for Airbus DS P8GR

Add AIRBUS_DS_P8GR device IDs to ftdi_sio driver. Signed-off-by: Max Schulze --- The device allows a simple AT style modem command set. Tested up to the advertised maximum of 115200 baud. Bus 001 Device 013: ID 1e8e:6001 Device Descriptor: bLength18

[PATCH] USB: serial: ftdi_sio: add id for Airbus DS P8GR

Add AIRBUS_DS_P8GR device IDs to ftdi_sio driver. Signed-off-by: Max Schulze --- The device allows a simple AT style modem command set. Tested up to the advertised maximum of 115200 baud. Bus 001 Device 013: ID 1e8e:6001 Device Descriptor: bLength18 bDescriptorType

Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support

Hello to all, Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu: > On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote: >> This is a series that adds: >> - PCI endpoint mode support in the ARTPEC-6 driver. >> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).

Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support

Hello to all, Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu: > On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote: >> This is a series that adds: >> - PCI endpoint mode support in the ARTPEC-6 driver. >> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).

Re: [PATCH 1/2] scsi: ufs: introduce static sysfs entries

On 12/20, Greg KH wrote: > On Tue, Dec 19, 2017 at 12:02:53PM -0800, Jaegeuk Kim wrote: > > From: Jaegeuk Kim > > > > This patch introduces attribute group to show existing sysfs entries. > > > > Cc: Greg KH > > Signed-off-by: Jaegeuk Kim

Re: [PATCH 1/2] scsi: ufs: introduce static sysfs entries

On 12/20, Greg KH wrote: > On Tue, Dec 19, 2017 at 12:02:53PM -0800, Jaegeuk Kim wrote: > > From: Jaegeuk Kim > > > > This patch introduces attribute group to show existing sysfs entries. > > > > Cc: Greg KH > > Signed-off-by: Jaegeuk Kim > > --- > > drivers/scsi/ufs/ufshcd.c | 48 > >

[PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

From: Kan Liang When the PEBS interrupt threshold is larger than one, there is no way to get exact auto-reload times and value needed for event update unless flush the PEBS buffer. Drain the PEBS buffer in event read when large PEBS is enabled. For the threshold is

[PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

From: Kan Liang When the PEBS interrupt threshold is larger than one, there is no way to get exact auto-reload times and value needed for event update unless flush the PEBS buffer. Drain the PEBS buffer in event read when large PEBS is enabled. For the threshold is one, even auto-reload is

[PATCH V2 1/4] perf/x86/intel: fix event update for auto-reload

From: Kan Liang There is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 There is auto-reload mechanism enabled for PEBS events in fixed period mode. But

[PATCH V2 1/4] perf/x86/intel: fix event update for auto-reload

From: Kan Liang There is bug when mmap read event->count with large PEBS enabled. Here is an example. #./read_count 0x71f0 0x122c0 0x11c54 0x10001257d 0x2bdc5 There is auto-reload mechanism enabled for PEBS events in fixed period mode. But the calculation of

[PATCH V2 2/4] perf/x86: introduce read function for x86_pmu

From: Kan Liang Large PEBS need to be specially handled in event count read. Signed-off-by: Kan Liang --- arch/x86/events/core.c | 2 ++ arch/x86/events/perf_event.h | 1 + 2 files changed, 3 insertions(+) diff --git

[PATCH V2 2/4] perf/x86: introduce read function for x86_pmu

From: Kan Liang Large PEBS need to be specially handled in event count read. Signed-off-by: Kan Liang --- arch/x86/events/core.c | 2 ++ arch/x86/events/perf_event.h | 1 + 2 files changed, 3 insertions(+) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index

[PATCH V2 4/4] perf/x86: fix: disable userspace RDPMC usage for large PEBS

From: Kan Liang The userspace RDPMC usage never works for large PEBS since the large PEBS is introduced by commit b8241d20699e ("perf/x86/intel: Implement batched PEBS interrupt handling (large PEBS interrupt threshold)") When the PEBS interrupt threshold is larger

[PATCH V2 4/4] perf/x86: fix: disable userspace RDPMC usage for large PEBS

From: Kan Liang The userspace RDPMC usage never works for large PEBS since the large PEBS is introduced by commit b8241d20699e ("perf/x86/intel: Implement batched PEBS interrupt handling (large PEBS interrupt threshold)") When the PEBS interrupt threshold is larger than one, there is no way to

[PATCH V2 0/4] bug fix mmap read and rdpmc read in large PEBS

From: Kan Liang -- Changes since V1: - Check PERF_X86_EVENT_AUTO_RELOAD before call intel_pmu_save_and_restore() - Introduce a special purpose intel_pmu_save_and_restart() just for AUTO_RELOAD. - New patch to disable userspace RDPMC usage if large PEBS is

[PATCH V2 0/4] bug fix mmap read and rdpmc read in large PEBS

From: Kan Liang -- Changes since V1: - Check PERF_X86_EVENT_AUTO_RELOAD before call intel_pmu_save_and_restore() - Introduce a special purpose intel_pmu_save_and_restart() just for AUTO_RELOAD. - New patch to disable userspace RDPMC usage if large PEBS is enabled. -- There is

Re: [PATCH 2/3] KVM: vmx: simplify MSR bitmap setup

This doesn't look right to me. Without APIC-register virtualization, the only X2APIC MSR intercept that should be disabled is TPR. On Wed, Dec 20, 2017 at 4:05 AM, Paolo Bonzini wrote: > The APICv-enabled MSR bitmap is a superset of the APICv-disabled bitmap. > Make that

Re: [PATCH 2/3] KVM: vmx: simplify MSR bitmap setup

This doesn't look right to me. Without APIC-register virtualization, the only X2APIC MSR intercept that should be disabled is TPR. On Wed, Dec 20, 2017 at 4:05 AM, Paolo Bonzini wrote: > The APICv-enabled MSR bitmap is a superset of the APICv-disabled bitmap. > Make that obvious in

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

Hello, Shakeel. On Tue, Dec 19, 2017 at 02:39:19PM -0800, Shakeel Butt wrote: > Suppose a user wants to run multiple instances of a specific job on > different datacenters and s/he has budget of 100MiB for each instance. > The instances are schduled on the requested datacenters and the >

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

Hello, Shakeel. On Tue, Dec 19, 2017 at 02:39:19PM -0800, Shakeel Butt wrote: > Suppose a user wants to run multiple instances of a specific job on > different datacenters and s/he has budget of 100MiB for each instance. > The instances are schduled on the requested datacenters and the >

Re: [PATCH 2/2 v2] scsi: ufs: use sysfs entry for health info

On 12/20, gre...@linuxfoundation.org wrote: > On Tue, Dec 19, 2017 at 02:46:44PM -0800, Jaegeuk Kim wrote: > > >From 3368207da5988b8fed4e41e6c0f49a60ac014222 Mon Sep 17 00:00:00 2001 > > From: Jaegeuk Kim > > Date: Tue, 26 Sep 2017 20:53:48 -0700 > > Subject: [PATCH 2/2] scsi:

Re: [PATCH 2/2 v2] scsi: ufs: use sysfs entry for health info

On 12/20, gre...@linuxfoundation.org wrote: > On Tue, Dec 19, 2017 at 02:46:44PM -0800, Jaegeuk Kim wrote: > > >From 3368207da5988b8fed4e41e6c0f49a60ac014222 Mon Sep 17 00:00:00 2001 > > From: Jaegeuk Kim > > Date: Tue, 26 Sep 2017 20:53:48 -0700 > > Subject: [PATCH 2/2] scsi: ufs: introduce

Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Add a generic function for raising MSI irqs that can be used by all > DWC based controllers. > > Note that certain controllers, like DRA7xx, have a special convenience > register for raising MSI irqs that doesn't require you to explicitly

Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Add a generic function for raising MSI irqs that can be used by all > DWC based controllers. > > Note that certain controllers, like DRA7xx, have a special convenience > register for raising MSI irqs that doesn't require you to explicitly

Re: [PATCH v6 04/18] PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Certain SoCs need to map the MSI address in raise_irq. > To map an address, you first need to call pci_epc_mem_alloc_addr(), > however, pci_epc_mem_alloc_addr() calls ioremap() (which can sleep). > > Since raise_irq is only called from

Re: [PATCH v6 04/18] PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Certain SoCs need to map the MSI address in raise_irq. > To map an address, you first need to call pci_epc_mem_alloc_addr(), > however, pci_epc_mem_alloc_addr() calls ioremap() (which can sleep). > > Since raise_irq is only called from

Re: [PATCH V3 net-next 00/17] add some features and fix some bugs for HNS3 driver

From: Lipeng Date: Wed, 20 Dec 2017 16:43:02 +0800 > This patchset adds some new feature support and fixes some bugs: > [Patch 1/17 - 5/17] add the support to modify/query the tqp number > through ethtool -L/l command, and also fix some related bugs for > change tqp number.

Re: [PATCH V3 net-next 00/17] add some features and fix some bugs for HNS3 driver

From: Lipeng Date: Wed, 20 Dec 2017 16:43:02 +0800 > This patchset adds some new feature support and fixes some bugs: > [Patch 1/17 - 5/17] add the support to modify/query the tqp number > through ethtool -L/l command, and also fix some related bugs for > change tqp number. > [Patch 6/17 - 9-17]

[PATCH 1/2] arm64: dts: exynos: Use lower case hex addresses in node unit addresses

Convert all hex addresses in node unit addresses to lower case to fix warnings like: arch/arm64/boot/dts/exynos/exynos5433-tm2e.dtb: Warning (simple_bus_reg): Node /soc/video-scaler@13C0 simple-bus unit address format error, expected "13c0" Conversion was done using sed: $

[PATCH 1/2] arm64: dts: exynos: Use lower case hex addresses in node unit addresses

Convert all hex addresses in node unit addresses to lower case to fix warnings like: arch/arm64/boot/dts/exynos/exynos5433-tm2e.dtb: Warning (simple_bus_reg): Node /soc/video-scaler@13C0 simple-bus unit address format error, expected "13c0" Conversion was done using sed: $

[PATCH 2/2] arm64: dts: exynos: Fix typo in MSCL clock controller unit address

Fix typo in unit address of MSCL clock controller (the reg entry is correct). Signed-off-by: Krzysztof Kozlowski --- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi

[PATCH 2/2] arm64: dts: exynos: Fix typo in MSCL clock controller unit address

Fix typo in unit address of MSCL clock controller (the reg entry is correct). Signed-off-by: Krzysztof Kozlowski --- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi

[PATCH] agp: Add bridge parameter documentation

This patch add documentation about the bridge parameter in several function. This will fix the following build warning: drivers/char/agp/generic.c:220: warning: No description found for parameter 'bridge' drivers/char/agp/generic.c:364: warning: No description found for parameter 'bridge'

[PATCH] agp: Add bridge parameter documentation

This patch add documentation about the bridge parameter in several function. This will fix the following build warning: drivers/char/agp/generic.c:220: warning: No description found for parameter 'bridge' drivers/char/agp/generic.c:364: warning: No description found for parameter 'bridge'

Re: [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation

Quoting Matthias Brugger (2017-12-20 09:13:12) > > > On 12/19/2017 02:32 AM, Stephen Boyd wrote: > > On 12/14, Matthias Brugger wrote: > >> Hi Stephen, Michael, > >> > >> On 12/01/2017 01:07 PM, Matthias Brugger wrote: > >>> The ethsys registers a reset controller, so we need to specify a > >>>

Re: [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation

Quoting Matthias Brugger (2017-12-20 09:13:12) > > > On 12/19/2017 02:32 AM, Stephen Boyd wrote: > > On 12/14, Matthias Brugger wrote: > >> Hi Stephen, Michael, > >> > >> On 12/01/2017 01:07 PM, Matthias Brugger wrote: > >>> The ethsys registers a reset controller, so we need to specify a > >>>

[PATCH] HID: intel-ish-hid: Enable Cannon Lake and Coffee Lake laptop/desktop

Added PCI ID for Cannon Lake and Coffee Lake laptop/desktop skews. Signed-off-by: Srinivas Pandruvada --- drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 + drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 + 2 files changed, 2 insertions(+) diff --git

[PATCH] HID: intel-ish-hid: Enable Cannon Lake and Coffee Lake laptop/desktop

Added PCI ID for Cannon Lake and Coffee Lake laptop/desktop skews. Signed-off-by: Srinivas Pandruvada --- drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 + drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

Quoting David Lechner (2017-12-20 10:53:27) > On 12/19/2017 04:29 PM, Michael Turquette wrote: > > Hi David, > > > > Quoting David Lechner (2017-12-15 08:29:56) > >> On 12/12/2017 10:14 PM, David Lechner wrote: > >>> On 12/12/2017 05:43 PM, David Lechner wrote: > If clk_enable() is called in

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

Quoting David Lechner (2017-12-20 10:53:27) > On 12/19/2017 04:29 PM, Michael Turquette wrote: > > Hi David, > > > > Quoting David Lechner (2017-12-15 08:29:56) > >> On 12/12/2017 10:14 PM, David Lechner wrote: > >>> On 12/12/2017 05:43 PM, David Lechner wrote: > If clk_enable() is called in

Re: [PATCH net-next v4 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events

From: David Miller Date: Wed, 20 Dec 2017 14:20:40 -0500 (EST) > From: Masami Hiramatsu > Date: Wed, 20 Dec 2017 13:14:11 +0900 > >> This series is v4 of the replacement of jprobe usage with trace >> events. This version is rebased on net-next, fixes a

Re: [PATCH net-next v4 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events

From: David Miller Date: Wed, 20 Dec 2017 14:20:40 -0500 (EST) > From: Masami Hiramatsu > Date: Wed, 20 Dec 2017 13:14:11 +0900 > >> This series is v4 of the replacement of jprobe usage with trace >> events. This version is rebased on net-next, fixes a build warning >> and moves a temporal

Re: [PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries

On Wed, 2017-12-20 at 11:16 -0800, Jaegeuk Kim wrote: > From: Jaegeuk Kim Hello Jaegeuk, For future patch series submissions, please include a cover letter that explains the purpose of the patch series and please also document the changes between the different versions of

Re: [PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries

On Wed, 2017-12-20 at 11:16 -0800, Jaegeuk Kim wrote: > From: Jaegeuk Kim Hello Jaegeuk, For future patch series submissions, please include a cover letter that explains the purpose of the patch series and please also document the changes between the different versions of the patch series in

Re: [PATCH net-next v4 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events

From: Masami Hiramatsu Date: Wed, 20 Dec 2017 13:14:11 +0900 > This series is v4 of the replacement of jprobe usage with trace > events. This version is rebased on net-next, fixes a build warning > and moves a temporal variable definition in a block. > > Previous version is

Re: [PATCH net-next v4 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events

From: Masami Hiramatsu Date: Wed, 20 Dec 2017 13:14:11 +0900 > This series is v4 of the replacement of jprobe usage with trace > events. This version is rebased on net-next, fixes a build warning > and moves a temporal variable definition in a block. > > Previous version is here; >

Re: [PATCH v5 4/4] ARM: dts: tegra20: Add video decoder node

On Tue, Dec 12, 2017 at 03:26:10AM +0300, Dmitry Osipenko wrote: > Add Video Decoder Engine device node. > > Signed-off-by: Dmitry Osipenko > --- > arch/arm/boot/dts/tegra20.dtsi | 27 +++ > 1 file changed, 27 insertions(+) Applied, thanks. Thierry

Re: [PATCH v5 4/4] ARM: dts: tegra20: Add video decoder node

On Tue, Dec 12, 2017 at 03:26:10AM +0300, Dmitry Osipenko wrote: > Add Video Decoder Engine device node. > > Signed-off-by: Dmitry Osipenko > --- > arch/arm/boot/dts/tegra20.dtsi | 27 +++ > 1 file changed, 27 insertions(+) Applied, thanks. Thierry signature.asc

Re: [PATCH v5 3/4] ARM: dts: tegra20: Add device tree node to describe IRAM

On Tue, Dec 12, 2017 at 03:26:09AM +0300, Dmitry Osipenko wrote: > From: Vladimir Zapolskiy > > All Tegra20 SoCs contain 256KiB IRAM, which is used to store > resume code and by a video decoder engine. > > Signed-off-by: Vladimir Zapolskiy > Signed-off-by:

Re: [PATCH v5 3/4] ARM: dts: tegra20: Add device tree node to describe IRAM

On Tue, Dec 12, 2017 at 03:26:09AM +0300, Dmitry Osipenko wrote: > From: Vladimir Zapolskiy > > All Tegra20 SoCs contain 256KiB IRAM, which is used to store > resume code and by a video decoder engine. > > Signed-off-by: Vladimir Zapolskiy > Signed-off-by: Dmitry Osipenko > --- >

Re: [PATCH v6 03/18] PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Certain registers that pcie-designware-ep tries to write to are read-only > registers. However, these registers can become read/write if we first > enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after > writing these

Re: [PATCH v6 03/18] PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Certain registers that pcie-designware-ep tries to write to are read-only > registers. However, these registers can become read/write if we first > enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after > writing these

Re: [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq

Hi, * Brian Norris [171219 00:50]: > On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote: > > Did this problem ever get resolved? To be clear, I believe the problem > at hand is: > > (a) in suspend/resume (not runtime PM; we may not even have runtime PM >

Re: [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq

Hi, * Brian Norris [171219 00:50]: > On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote: > > Did this problem ever get resolved? To be clear, I believe the problem > at hand is: > > (a) in suspend/resume (not runtime PM; we may not even have runtime PM > support for most PCI devices)

Race-free unlinking of directory entries

Hi! Linux kernel currently does not provide any race-free way for calling unlink() syscall on file entry which points to opened file descriptor. On the other hand Linux kernel already provides race-free way for creating file entry by linkat() syscall with AT_EMPTY_PATH or AT_SYMLINK_FOLLOW

Race-free unlinking of directory entries

Hi! Linux kernel currently does not provide any race-free way for calling unlink() syscall on file entry which points to opened file descriptor. On the other hand Linux kernel already provides race-free way for creating file entry by linkat() syscall with AT_EMPTY_PATH or AT_SYMLINK_FOLLOW

[PATCH] ia64: agp: Replace empty define with do while

It's dangerous to use empty code define. Furthermore it lead to the following warning: drivers/char/agp/generic.c: In function « agp_generic_destroy_page »: drivers/char/agp/generic.c:1266:28: attention : suggest braces around empty body in an « if » statement [-Wempty-body] So let's replace

[PATCH] ia64: agp: Replace empty define with do while

It's dangerous to use empty code define. Furthermore it lead to the following warning: drivers/char/agp/generic.c: In function « agp_generic_destroy_page »: drivers/char/agp/generic.c:1266:28: attention : suggest braces around empty body in an « if » statement [-Wempty-body] So let's replace

Re: [PATCH v6 02/18] PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control > register, thus overwriting the PCI_MSI_FLAGS_64BIT bit. > By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI > on systems where the RC has set a 64 bit MSI address.

Re: [PATCH v6 02/18] PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits

Hi, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control > register, thus overwriting the PCI_MSI_FLAGS_64BIT bit. > By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI > on systems where the RC has set a 64 bit MSI address.

[PATCH 2/2 v3] scsi: ufs: introduce sysfs entries exposing UFS health info

From: Jaegeuk Kim This patch adds a new sysfs group, namely health, via: /sys/devices/soc/X.ufshc/health/ This directory contains the below entries, each of which shows an 8-bytes hex number representing different meanings defined by JEDEC specfication. Users can simply

[PATCH 2/2 v3] scsi: ufs: introduce sysfs entries exposing UFS health info

From: Jaegeuk Kim This patch adds a new sysfs group, namely health, via: /sys/devices/soc/X.ufshc/health/ This directory contains the below entries, each of which shows an 8-bytes hex number representing different meanings defined by JEDEC specfication. Users can simply read these entries

[PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries

From: Jaegeuk Kim This patch introduces attribute group to show existing sysfs entries. Cc: Greg Kroah-Hartman Signed-off-by: Jaegeuk Kim --- Change log from v1: - use ATTRIBUTE_GROUPS and sysfs_create_groups()

[PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries

From: Jaegeuk Kim This patch introduces attribute group to show existing sysfs entries. Cc: Greg Kroah-Hartman Signed-off-by: Jaegeuk Kim --- Change log from v1: - use ATTRIBUTE_GROUPS and sysfs_create_groups() drivers/scsi/ufs/ufshcd.c | 46 +-

RE: [PATCH 1/4] tpm: fix access attempt to an already unmapped I/O memory region

>-Original Message- >From: Jason Gunthorpe [mailto:j...@ziepe.ca] >Sent: Wednesday, December 20, 2017 10:55 AM >To: Javier Martinez Canillas >Cc: linux-kernel@vger.kernel.org; James Ettle ; Hans de >Goede ; Shaikh, Azhar

RE: [PATCH 1/4] tpm: fix access attempt to an already unmapped I/O memory region

>-Original Message- >From: Jason Gunthorpe [mailto:j...@ziepe.ca] >Sent: Wednesday, December 20, 2017 10:55 AM >To: Javier Martinez Canillas >Cc: linux-kernel@vger.kernel.org; James Ettle ; Hans de >Goede ; Shaikh, Azhar ; >Arnd Bergmann ; Jarkko Sakkinen >; Peter Huewe ; >Greg

Re: [PATCH v1 1/3] x86/mm: Centralize PMD flags in sme_encrypt_kernel()

On Thu, Dec 07, 2017 at 05:33:52PM -0600, Tom Lendacky wrote: > In preparation for encrypting more than just the kernel during early > boot processing, centralize the use of the PMD flag settings based > on the type of mapping desired. When 4KB aligned encryption is added, > this will allow

Re: [PATCH v1 1/3] x86/mm: Centralize PMD flags in sme_encrypt_kernel()

On Thu, Dec 07, 2017 at 05:33:52PM -0600, Tom Lendacky wrote: > In preparation for encrypting more than just the kernel during early > boot processing, centralize the use of the PMD flag settings based > on the type of mapping desired. When 4KB aligned encryption is added, > this will allow

Re: [PATCH v6 01/18] PCI: dwc: Use the DMA-API to get the MSI address

Hi Niklas, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Use the DMA-API to get the MSI address. This address will be written to > our PCI config space and to the register which determines which AXI > address the DWC IP will spoof for incoming MSI irqs. > > Since it is a PCIe endpoint

Re: [PATCH v6 01/18] PCI: dwc: Use the DMA-API to get the MSI address

Hi Niklas, Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > Use the DMA-API to get the MSI address. This address will be written to > our PCI config space and to the register which determines which AXI > address the DWC IP will spoof for incoming MSI irqs. > > Since it is a PCIe endpoint

[PATCH] Fixed typo in onewire generic doc

Onewire devices has 6 byte long unique serial numbers, 1 byte family code and 1 byte CRC. Linux sysfs presents the device folder in the form of familyID-deviceID, so CRC is not shown. The consequence is that the device serial number is always a 12 long hex-string, but doc says 13 in one place.

[PATCH] Fixed typo in onewire generic doc

Onewire devices has 6 byte long unique serial numbers, 1 byte family code and 1 byte CRC. Linux sysfs presents the device folder in the form of familyID-deviceID, so CRC is not shown. The consequence is that the device serial number is always a 12 long hex-string, but doc says 13 in one place.

Re: [PATCH] MAINTAINERS: Move all MTD related branches to a single repo

On Mon, Dec 18, 2017 at 04:49:34PM +0100, Boris Brezillon wrote: > Hi MTD maintainers, > > As discussed a few weeks ago, this patch is moving all MTD related > branches to the linux-mtd repo in an attempt to make things easier > for maintainers (it's not unusal to push the next or fixes branch to

[GIT PULL] ACPI fixes for v4.15-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.15-rc5 with top-most commit 9245fe9fccdbda5d81d97155e5c5de7e16510cee Merge branch 'acpi-cppc' on top of commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b Linux 4.15-rc4 to receive

Re: [PATCH] MAINTAINERS: Move all MTD related branches to a single repo

On Mon, Dec 18, 2017 at 04:49:34PM +0100, Boris Brezillon wrote: > Hi MTD maintainers, > > As discussed a few weeks ago, this patch is moving all MTD related > branches to the linux-mtd repo in an attempt to make things easier > for maintainers (it's not unusal to push the next or fixes branch to

[GIT PULL] ACPI fixes for v4.15-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.15-rc5 with top-most commit 9245fe9fccdbda5d81d97155e5c5de7e16510cee Merge branch 'acpi-cppc' on top of commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b Linux 4.15-rc4 to receive

Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC

On 12/20/2017, 06:45 PM, Josh Poimboeuf wrote: > It might not be until 2018 though. But in the meantime you can go ahead > and update your patches accordingly and then we can combine them for > testing next year. I already did ;). So when you have that ready, I will send it on top right after.

Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC

On 12/20/2017, 06:45 PM, Josh Poimboeuf wrote: > It might not be until 2018 though. But in the meantime you can go ahead > and update your patches accordingly and then we can combine them for > testing next year. I already did ;). So when you have that ready, I will send it on top right after.

[GIT PULL] Power management fixes for v4.15-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.15-rc5 with top-most commit 63d15e8c2ac134b3fd5460d19043ffde6f6eeb61 Merge branch 'pm-pci' on top of commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b Linux 4.15-rc4 to receive

[GIT PULL] Power management fixes for v4.15-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.15-rc5 with top-most commit 63d15e8c2ac134b3fd5460d19043ffde6f6eeb61 Merge branch 'pm-pci' on top of commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b Linux 4.15-rc4 to receive

Re: [PATCH] iommu/amd - Record more information about unknown events

On Mon, 04 Dec 2017 13:52:42 -0600 Gary R Hook wrote: > When an unknown type event occurs, the default information written to > the syslog should dump raw event data. This could provide insight into > the event that occurred. > > Signed-off-by: Gary R Hook

Re: [PATCH] iommu/amd - Record more information about unknown events

On Mon, 04 Dec 2017 13:52:42 -0600 Gary R Hook wrote: > When an unknown type event occurs, the default information written to > the syslog should dump raw event data. This could provide insight into > the event that occurred. > > Signed-off-by: Gary R Hook > --- > drivers/iommu/amd_iommu.c |

Re: [PATCH V2] iommu/amd - Set the device table entry PPR bit for IOMMU V2 devices

On Tue, 19 Dec 2017 16:15:41 -0600 Gary R Hook wrote: > The AMD IOMMU specification Rev 3.00 (December 2016) introduces a > new Enhanced PPR Handling Support (EPHSup) bit in the MMIO register > offset 0030h (IOMMU Extended Feature Register). > > When EPHSup=1, the IOMMU

Re: [PATCH V2] iommu/amd - Set the device table entry PPR bit for IOMMU V2 devices

On Tue, 19 Dec 2017 16:15:41 -0600 Gary R Hook wrote: > The AMD IOMMU specification Rev 3.00 (December 2016) introduces a > new Enhanced PPR Handling Support (EPHSup) bit in the MMIO register > offset 0030h (IOMMU Extended Feature Register). > > When EPHSup=1, the IOMMU hardware requires the

Re: [PATCH] iommu/vt-d: clean up pr_irq if request_threaded_irq fails

On Wed, 6 Dec 2017 09:49:59 -0700 Jerry Snitselaar wrote: > It is unlikely request_threaded_irq will fail, but if it does for some > reason we should clear iommu->pr_irq in the error path. Also > intel_svm_finish_prq shouldn't try to clean up the page request > interrupt if

Re: [PATCH] iommu/vt-d: clean up pr_irq if request_threaded_irq fails

On Wed, 6 Dec 2017 09:49:59 -0700 Jerry Snitselaar wrote: > It is unlikely request_threaded_irq will fail, but if it does for some > reason we should clear iommu->pr_irq in the error path. Also > intel_svm_finish_prq shouldn't try to clean up the page request > interrupt if pr_irq is 0. Without

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