[PATCH v2 2/3] ARM: dts: NSP: Rearrage USB entries

The rest of the DTSI file is in incrementing addresses, but the USB OHCI/ECHI entries are out of sequence. Move them to put them in the proper place. Signed-off-by: Jon Mason --- arch/arm/boot/dts/bcm-nsp.dtsi | 32 1 file changed, 16

[PATCH v2 2/3] ARM: dts: NSP: Rearrage USB entries

The rest of the DTSI file is in incrementing addresses, but the USB OHCI/ECHI entries are out of sequence. Move them to put them in the proper place. Signed-off-by: Jon Mason --- arch/arm/boot/dts/bcm-nsp.dtsi | 32 1 file changed, 16 insertions(+), 16

Re: [PATCH v2 02/13] xen/pvcalls: connect to the backend

On Thu, 27 Jul 2017, Boris Ostrovsky wrote: > >>> static int pvcalls_front_probe(struct xenbus_device *dev, > >>> const struct xenbus_device_id *id) > >>> { > >>> + int ret = -EFAULT, evtchn, ref = -1, i; > >>> + unsigned int max_page_order, function_calls, len; >

Re: [PATCH v2 02/13] xen/pvcalls: connect to the backend

On Thu, 27 Jul 2017, Boris Ostrovsky wrote: > >>> static int pvcalls_front_probe(struct xenbus_device *dev, > >>> const struct xenbus_device_id *id) > >>> { > >>> + int ret = -EFAULT, evtchn, ref = -1, i; > >>> + unsigned int max_page_order, function_calls, len; >

Re: [PATCH] platform/x86: intel-hid: Wake up Dell Latitude 7275 from suspend-to-idle

On Friday, July 28, 2017 02:06:36 AM Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > On Dell Latitude 7275 the 5-button array is not exposed in the > ACPI tables, but still notifies are sent to the Intel HID device > object (device ID INT33D5) in response to

Re: [PATCH] platform/x86: intel-hid: Wake up Dell Latitude 7275 from suspend-to-idle

On Friday, July 28, 2017 02:06:36 AM Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > On Dell Latitude 7275 the 5-button array is not exposed in the > ACPI tables, but still notifies are sent to the Intel HID device > object (device ID INT33D5) in response to power button actions while >

[PATCH v2 1/3] ARM: dts: NSP: Add dma-coherent to relevant DT entries

Cache related issues with DMA rings and performance issues related to caching are being caused by not properly setting the "dma-coherent" flag in the device tree entries. Adding it here to correct the issue. Signed-off-by: Jon Mason Fixes: 3107fa5bcfb2 ("ARM: dts: NSP:

[PATCH v2 1/3] ARM: dts: NSP: Add dma-coherent to relevant DT entries

Cache related issues with DMA rings and performance issues related to caching are being caused by not properly setting the "dma-coherent" flag in the device tree entries. Adding it here to correct the issue. Signed-off-by: Jon Mason Fixes: 3107fa5bcfb2 ("ARM: dts: NSP: Add SD/MMC support")

[PATCH v2 0/3] ARM: dts: NSP: dma-coherent and USB3 changes

Changes in v2: * Removed pl330 and srab dma-coherent entries due to concerns that they were invalid Add dma-coherent to the relevant DT entries, and add USB3 support Jon Mason (3): ARM: dts: NSP: Add dma-coherent to relevant DT entries ARM: dts: NSP: Rearrage USB entries ARM: dts: NSP:

[PATCH v2 0/3] ARM: dts: NSP: dma-coherent and USB3 changes

Changes in v2: * Removed pl330 and srab dma-coherent entries due to concerns that they were invalid Add dma-coherent to the relevant DT entries, and add USB3 support Jon Mason (3): ARM: dts: NSP: Add dma-coherent to relevant DT entries ARM: dts: NSP: Rearrage USB entries ARM: dts: NSP:

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 11:18 PM, Kees Cook wrote: > On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: >> On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook wrote: >>> On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 11:18 PM, Kees Cook wrote: > On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: >> On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook wrote: >>> On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann wrote: On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua wrote: >>

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: Anatoly Pugachev Date: Tue, 1 Aug 2017 00:48:07 +0300 > Aug 01 00:35:11 v215 kernel: sched_xetattr(1527): Oops [#1] > Aug 01 00:35:11 v215 kernel: CPU: 1 PID: 1527 Comm: sched_xetattr Not > tainted 4.12.0 #365 > Aug 01 00:35:11 v215 kernel: task: fff0001231d41340

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: Anatoly Pugachev Date: Tue, 1 Aug 2017 00:48:07 +0300 > Aug 01 00:35:11 v215 kernel: sched_xetattr(1527): Oops [#1] > Aug 01 00:35:11 v215 kernel: CPU: 1 PID: 1527 Comm: sched_xetattr Not > tainted 4.12.0 #365 > Aug 01 00:35:11 v215 kernel: task: fff0001231d41340 task.stack: >

[PATCH] ACPI / PM: Prefer suspend-to-idle over S3 on some systems

From: Rafael J. Wysocki Modify the ACPI system sleep support setup code to select suspend-to-idle as the default system sleep state if (1) the ACPI_FADT_LOW_POWER_S0 flag is set in the FADT and (2) the Low Power Idle S0 _DSM interface has been discovered and (3) the

[PATCH] ACPI / PM: Prefer suspend-to-idle over S3 on some systems

From: Rafael J. Wysocki Modify the ACPI system sleep support setup code to select suspend-to-idle as the default system sleep state if (1) the ACPI_FADT_LOW_POWER_S0 flag is set in the FADT and (2) the Low Power Idle S0 _DSM interface has been discovered and (3) the default sleep state was not

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

On Mon, Jul 31, 2017 at 8:14 PM, Mikael Pettersson wrote: > Mikael Pettersson writes: > > Anatoly Pugachev writes: > > > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson > > > wrote: > > > > It's an rpmbuild --rebuild of Fedora's

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

On Mon, Jul 31, 2017 at 8:14 PM, Mikael Pettersson wrote: > Mikael Pettersson writes: > > Anatoly Pugachev writes: > > > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson > > > wrote: > > > > It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, > but according to the > >

Re: [PATCH V4] PCI: handle CRS returned by device after FLR

Hi Bjorn, On 7/13/2017 7:49 PM, Bjorn Helgaas wrote: > On Thu, Jul 06, 2017 at 05:07:14PM -0400, Sinan Kaya wrote: >> An endpoint is allowed to issue Configuration Request Retry Status (CRS) >> following a Function Level Reset (FLR) request to indicate that it is not >> ready to accept new

Re: [PATCH V4] PCI: handle CRS returned by device after FLR

Hi Bjorn, On 7/13/2017 7:49 PM, Bjorn Helgaas wrote: > On Thu, Jul 06, 2017 at 05:07:14PM -0400, Sinan Kaya wrote: >> An endpoint is allowed to issue Configuration Request Retry Status (CRS) >> following a Function Level Reset (FLR) request to indicate that it is not >> ready to accept new

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> Actually, that's the first option I considered, but I3C and I2C are > really different. I'm not talking about the physical layer here, but > the way the bus has to be handled by the software layer. Actually, I > thing the I3C bus is philosophically closer to auto-discoverable busses > like USB

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> Actually, that's the first option I considered, but I3C and I2C are > really different. I'm not talking about the physical layer here, but > the way the bus has to be handled by the software layer. Actually, I > thing the I3C bus is philosophically closer to auto-discoverable busses > like USB

Re: [PATCH v2 22/22] fpga: intel: afu: add FPGA_PORT_DMA_MAP/UNMAP ioctls support

On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote: Hi Hao, Please run checkpatch.pl --strict on this. Could you add some kernel-doc function comments here to help the new user (or reviewer) get a better handle on what this code is doing? A few mostly minor comments below. > DMA

Re: [PATCH v2 22/22] fpga: intel: afu: add FPGA_PORT_DMA_MAP/UNMAP ioctls support

On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote: Hi Hao, Please run checkpatch.pl --strict on this. Could you add some kernel-doc function comments here to help the new user (or reviewer) get a better handle on what this code is doing? A few mostly minor comments below. > DMA memory regions

Re: [PATCH v2 02/22] fpga: add FPGA device framework

On Thu, Jul 27, 2017 at 2:10 PM, Rob Herring wrote: > On Thu, Jul 27, 2017 at 11:35 AM, Alan Tull wrote: >> On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao wrote: >> >> Hi Rob, >> >> I was hoping to pick your brain a bit on a DT question. >> >>>

Re: [PATCH v2 02/22] fpga: add FPGA device framework

On Thu, Jul 27, 2017 at 2:10 PM, Rob Herring wrote: > On Thu, Jul 27, 2017 at 11:35 AM, Alan Tull wrote: >> On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao wrote: >> >> Hi Rob, >> >> I was hoping to pick your brain a bit on a DT question. >> >>> During FPGA device (e.g PCI-based) discovery, platform

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 14:18 -0700, Kees Cook wrote: > On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: > > On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook > > wrote: > > > On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann > > > wrote: > > > >

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 14:18 -0700, Kees Cook wrote: > On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: > > On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook > > wrote: > > > On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann > > > wrote: > > > > On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua > > > >

Re: [PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

On 07/31/2017 07:17 PM, Alexandru Gagniuc wrote: [...] >>> +++ b/drivers/mtd/spi-nor/anarion-quadspi.c >>> @@ -0,0 +1,490 @@ >>> +/* >>> + * Adaptrum Anarion Quad SPI controller driver >>> + * >>> + * Copyright (C) 2017, Adaptrum, Inc. >>> + * (Written by Alexandru Gagniuc for >>> Adaptrum,

Re: [PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

On 07/31/2017 10:54 PM, Alexandru Gagniuc wrote: > Hi Marek, > > Me again! > > On 07/29/2017 02:34 AM, Marek Vasut wrote: >> On 07/29/2017 12:07 AM, Alexandru Gagniuc wrote: >>> +static void aspi_drain_fifo(struct anarion_qspi *aspi, uint8_t *buf, >>> size_t len) >>> +{ >>> +uint32_t data;

Re: [PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

On 07/31/2017 07:17 PM, Alexandru Gagniuc wrote: [...] >>> +++ b/drivers/mtd/spi-nor/anarion-quadspi.c >>> @@ -0,0 +1,490 @@ >>> +/* >>> + * Adaptrum Anarion Quad SPI controller driver >>> + * >>> + * Copyright (C) 2017, Adaptrum, Inc. >>> + * (Written by Alexandru Gagniuc for >>> Adaptrum,

Re: [PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

On 07/31/2017 10:54 PM, Alexandru Gagniuc wrote: > Hi Marek, > > Me again! > > On 07/29/2017 02:34 AM, Marek Vasut wrote: >> On 07/29/2017 12:07 AM, Alexandru Gagniuc wrote: >>> +static void aspi_drain_fifo(struct anarion_qspi *aspi, uint8_t *buf, >>> size_t len) >>> +{ >>> +uint32_t data;

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On 2017-07-31 23:15, Boris Brezillon wrote: > [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register Stupid non-programmers... This part 65 41 0101 Accelerometer 66 42 0110 Gyroscope 67 43 0111 Magnetometer 68 44 01000100 Accel/Gyro Combo 69 45 01000101 Accel/Mag

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On 2017-07-31 23:15, Boris Brezillon wrote: > [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register Stupid non-programmers... This part 65 41 0101 Accelerometer 66 42 0110 Gyroscope 67 43 0111 Magnetometer 68 44 01000100 Accel/Gyro Combo 69 45 01000101 Accel/Mag

[PATCH 1/5 v2] pinctrl: Add DT bindings for Cortina Gemini

The Cortina Gemini pin controller uses the standard pin control bindings for muxing functions with groups so these bindings should be entirely uncontroversial. Cc: devicet...@vger.kernel.org Signed-off-by: Linus Walleij --- ChangeLog v1->v2: - State that the pin

[PATCH 1/5 v2] pinctrl: Add DT bindings for Cortina Gemini

The Cortina Gemini pin controller uses the standard pin control bindings for muxing functions with groups so these bindings should be entirely uncontroversial. Cc: devicet...@vger.kernel.org Signed-off-by: Linus Walleij --- ChangeLog v1->v2: - State that the pin controller must be a subnode of

Re: [PATCH v3 4/4] squashfs: Add zstd support

On 7/30/17, 6:50 PM, "Phillip Lougher" wrote: > On Thu, Jul 20, 2017 at 10:27 PM, Nick Terrell wrote: >> Add zstd compression and decompression support to SquashFS. zstd is a >> great fit for SquashFS because it can compress at ratios approaching xz,

Re: [PATCH v3 4/4] squashfs: Add zstd support

On 7/30/17, 6:50 PM, "Phillip Lougher" wrote: > On Thu, Jul 20, 2017 at 10:27 PM, Nick Terrell wrote: >> Add zstd compression and decompression support to SquashFS. zstd is a >> great fit for SquashFS because it can compress at ratios approaching xz, >> while decompressing twice as fast as zlib.

RE: FSGSBASE ABI considerations

> On an FSGSBASE-enabled system, I think we need to provide deterministic, > documented, tested behavior. I can think of three plausible choices: > 1a. modify_ldt() immediately updates FSBASE and GSBASE all threads that > reference the modified selector. > 1b. modify_ldt() immediatley updates

RE: FSGSBASE ABI considerations

> On an FSGSBASE-enabled system, I think we need to provide deterministic, > documented, tested behavior. I can think of three plausible choices: > 1a. modify_ldt() immediately updates FSBASE and GSBASE all threads that > reference the modified selector. > 1b. modify_ldt() immediatley updates

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On 07/27/2017 11:46 PM, Viresh Kumar wrote: On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU from policy-A can change frequency of CPUs belonging to policy-B. This is quite common in case of ARM platforms where we don't configure any per-cpu register. Add a flag to identify

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On 07/27/2017 11:46 PM, Viresh Kumar wrote: On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU from policy-A can change frequency of CPUs belonging to policy-B. This is quite common in case of ARM platforms where we don't configure any per-cpu register. Add a flag to identify

Re: [PATCH V5 1/2] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:46 PM, Viresh Kumar wrote: With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into cpufreq governors are only made from the scheduler if the target CPU of the event is the same as the current

Re: [PATCH V5 1/2] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:46 PM, Viresh Kumar wrote: With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into cpufreq governors are only made from the scheduler if the target CPU of the event is the same as the current

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook wrote: >> On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann wrote: >>> On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua wrote:

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook wrote: >> On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann wrote: >>> On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua wrote: > break; > default: >

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Hi Arnd, Le Mon, 31 Jul 2017 22:16:42 +0200, Arnd Bergmann a écrit : > On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon > wrote: > > Add core infrastructure to support I3C in Linux and document it. > > > - I2C backward compatibility has

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Hi Arnd, Le Mon, 31 Jul 2017 22:16:42 +0200, Arnd Bergmann a écrit : > On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon > wrote: > > Add core infrastructure to support I3C in Linux and document it. > > > - I2C backward compatibility has been designed to be transparent to I2C > > drivers

Re: [PATCH] fbcon: Use background color for margins

On Mon, Jul 31, 2017 at 12:25:28PM -0500, David Lechner wrote: > On 07/30/2017 04:51 PM, Pavel Machek wrote: > > > > > Screens that don't have a black border around the active area will > > > > > have > > > > > ugly black bars for the margin when the text background color is not > > > > > black.

[PATCH] crypto: ccp - select CONFIG_CRYPTO_RSA

Without the base RSA code, we run into a link error: ERROR: "rsa_parse_pub_key" [drivers/crypto/ccp/ccp-crypto.ko] undefined! ERROR: "rsa_parse_priv_key" [drivers/crypto/ccp/ccp-crypto.ko] undefined! Like the other drivers implementing RSA in hardware, this can be avoided by always enabling the

Re: [PATCH] fbcon: Use background color for margins

On Mon, Jul 31, 2017 at 12:25:28PM -0500, David Lechner wrote: > On 07/30/2017 04:51 PM, Pavel Machek wrote: > > > > > Screens that don't have a black border around the active area will > > > > > have > > > > > ugly black bars for the margin when the text background color is not > > > > > black.

[PATCH] crypto: ccp - select CONFIG_CRYPTO_RSA

Without the base RSA code, we run into a link error: ERROR: "rsa_parse_pub_key" [drivers/crypto/ccp/ccp-crypto.ko] undefined! ERROR: "rsa_parse_priv_key" [drivers/crypto/ccp/ccp-crypto.ko] undefined! Like the other drivers implementing RSA in hardware, this can be avoided by always enabling the

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook wrote: > On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann wrote: >> On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua wrote: break; default:

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook wrote: > On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann wrote: >> On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua wrote: break; default: return -EINVAL; >>> what happens if you replace 16 with

Re: [PATCH v2] f2fs: support journelled quota

On 07/30, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/7/30 15:35, Jaegeuk Kim wrote: > > Hi Chao, > > > > When I add this patch, xfstests/fsstress are giving some weird kernel hang > > or panic now. Without only this patch, I can't see any problem. Can you > > review > > this patch one more time

Re: [PATCH v2] f2fs: support journelled quota

On 07/30, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/7/30 15:35, Jaegeuk Kim wrote: > > Hi Chao, > > > > When I add this patch, xfstests/fsstress are giving some weird kernel hang > > or panic now. Without only this patch, I can't see any problem. Can you > > review > > this patch one more time

[PATCH] f2fs: return wrong error number on f2fs_quota_write

This must return size, not error number. Signed-off-by: Jaegeuk Kim --- fs/f2fs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index a14143c947e3..fc757c8861b7 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c

[PATCH] f2fs: return wrong error number on f2fs_quota_write

This must return size, not error number. Signed-off-by: Jaegeuk Kim --- fs/f2fs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index a14143c947e3..fc757c8861b7 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -1122,7 +1122,7 @@

Re: [PATCH 1/3] PCI / PM: Skip bridges in pci_enable_wake()

On Mon, Jul 31, 2017 at 10:53 PM, Bjorn Helgaas wrote: > On Fri, Jul 21, 2017 at 02:38:08PM +0200, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> PCI bridges only have a reason to generate wakeup signals on behalf >> of devices below

Re: [PATCH 1/3] PCI / PM: Skip bridges in pci_enable_wake()

On Mon, Jul 31, 2017 at 10:53 PM, Bjorn Helgaas wrote: > On Fri, Jul 21, 2017 at 02:38:08PM +0200, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> PCI bridges only have a reason to generate wakeup signals on behalf >> of devices below them, so avoid preparing bridges for wakeup

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua wrote: >> On Mon, Jul 31, 2017 at 9:50 AM, Arnd Bergmann wrote: >>> --- a/include/rdma/ib_addr.h >>> +++ b/include/rdma/ib_addr.h >>> @@ -172,7

Re: [PATCH] infiniband: avoid overflow warning

On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua wrote: >> On Mon, Jul 31, 2017 at 9:50 AM, Arnd Bergmann wrote: >>> --- a/include/rdma/ib_addr.h >>> +++ b/include/rdma/ib_addr.h >>> @@ -172,7 +172,8 @@ static inline int rdma_ip2gid(struct

Re: [PATCH v5] vfat: Deduplicate hex2bin()

Andy Shevchenko writes: >> > + fill = hex2bin(hc, ip + 1, 2); >> > + if (fill) >> > + return fill; >> >> This should not use random errno (in this case, it is -1 (EPERM)). > >

Re: [PATCH v5] vfat: Deduplicate hex2bin()

Andy Shevchenko writes: >> > + fill = hex2bin(hc, ip + 1, 2); >> > + if (fill) >> > + return fill; >> >> This should not use random errno (in this case, it is -1 (EPERM)). > > You perhaps missed the side note I

Re: [PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

Hi Marek, Me again! On 07/29/2017 02:34 AM, Marek Vasut wrote: On 07/29/2017 12:07 AM, Alexandru Gagniuc wrote: +static void aspi_drain_fifo(struct anarion_qspi *aspi, uint8_t *buf, size_t len) +{ + uint32_t data; Is this stuff below something like ioread32_rep() ? [snip] +

Re: [PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

Hi Marek, Me again! On 07/29/2017 02:34 AM, Marek Vasut wrote: On 07/29/2017 12:07 AM, Alexandru Gagniuc wrote: +static void aspi_drain_fifo(struct anarion_qspi *aspi, uint8_t *buf, size_t len) +{ + uint32_t data; Is this stuff below something like ioread32_rep() ? [snip] +

Re: [PATCH v5] vfat: Deduplicate hex2bin()

Andy Shevchenko writes: >> + >> + *(wchar_t *)op = uc[0] << 8 | uc[1]; >> + >> + op += 2; > > This had been in the original patch 6 years ago and had been refused > because of endianess issues. Sorry, I

Re: [PATCH v5] vfat: Deduplicate hex2bin()

Andy Shevchenko writes: >> + >> + *(wchar_t *)op = uc[0] << 8 | uc[1]; >> + >> + op += 2; > > This had been in the original patch 6 years ago and had been refused > because of endianess issues. Sorry, I forgot what I said completely.

Re: [PATCH 1/3] PCI / PM: Skip bridges in pci_enable_wake()

On Fri, Jul 21, 2017 at 02:38:08PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > PCI bridges only have a reason to generate wakeup signals on behalf > of devices below them, so avoid preparing bridges for wakeup directly > in pci_enable_wake(). > >

Re: [PATCH 1/3] PCI / PM: Skip bridges in pci_enable_wake()

On Fri, Jul 21, 2017 at 02:38:08PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > PCI bridges only have a reason to generate wakeup signals on behalf > of devices below them, so avoid preparing bridges for wakeup directly > in pci_enable_wake(). > > Also drop the

Re: [PATCH v3 01/16] switchtec: move structure definitions into a common header

Hey, I've never found any consistency in the capitalization and prefixes patch titles. I used to capitalize them all but I've seen many developers use lower case. In any case, I've changed them as you requested. I've also fixed all my spelling mistakes you've pointed out in the commit messages.

Re: [PATCH v3 01/16] switchtec: move structure definitions into a common header

Hey, I've never found any consistency in the capitalization and prefixes patch titles. I used to capitalize them all but I've seen many developers use lower case. In any case, I've changed them as you requested. I've also fixed all my spelling mistakes you've pointed out in the commit messages.

[PATCH] crypto: ccp - avoid uninitialized variable warning

The added support for version 5 CCPs introduced a false-positive warning in the RSA implementation: drivers/crypto/ccp/ccp-ops.c: In function 'ccp_run_rsa_cmd': drivers/crypto/ccp/ccp-ops.c:1856:3: error: 'sb_count' may be used uninitialized in this function [-Werror=maybe-uninitialized] This

[PATCH] crypto: ccp - avoid uninitialized variable warning

The added support for version 5 CCPs introduced a false-positive warning in the RSA implementation: drivers/crypto/ccp/ccp-ops.c: In function 'ccp_run_rsa_cmd': drivers/crypto/ccp/ccp-ops.c:1856:3: error: 'sb_count' may be used uninitialized in this function [-Werror=maybe-uninitialized] This

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Le Mon, 31 Jul 2017 21:17:21 +0200, Wolfram Sang a écrit : > > +This document is just a brief introduction to the I3C protocol and the > > concepts > > +it brings on the table. If you need more information, please refer to the > > MIPI > > +I3C specification. > > I wish

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Le Mon, 31 Jul 2017 21:17:21 +0200, Wolfram Sang a écrit : > > +This document is just a brief introduction to the I3C protocol and the > > concepts > > +it brings on the table. If you need more information, please refer to the > > MIPI > > +I3C specification. > > I wish I could. > > > + >

Re: [RFC 0/5] Add I3C subsystem

> > I agree this is the least invasive and also the most compatible > > approach. The other solution would probably be to have some kind of > > emulation layer? > > Could you detail a bit more what you mean by "emulation layer"? Not really. That was more a extremly high level approach of what

Re: [RFC 0/5] Add I3C subsystem

> > I agree this is the least invasive and also the most compatible > > approach. The other solution would probably be to have some kind of > > emulation layer? > > Could you detail a bit more what you mean by "emulation layer"? Not really. That was more a extremly high level approach of what

[PATCH] crypto: serpent: improve __serpent_setkey with UBSAN

When UBSAN is enabled, we get a very large stack frame for __serpent_setkey, when the register allocator ends up using more registers than it has, and has to spill temporary values to the stack. The code was originally optimized for in-order x86-32 CPU implementations using older compilers, but it

[PATCH] crypto: serpent: improve __serpent_setkey with UBSAN

When UBSAN is enabled, we get a very large stack frame for __serpent_setkey, when the register allocator ends up using more registers than it has, and has to spill temporary values to the stack. The code was originally optimized for in-order x86-32 CPU implementations using older compilers, but it

Re: [PATCH v2 0/2] Invert margin colors when terminal is inverted

On 07/31/2017 02:30 PM, Alan Cox wrote: On Mon, 31 Jul 2017 14:09:43 -0500 David Lechner wrote: This is v2 of "fbcon: Use background color for margins​"[1]. It turns out that using the text background color was not a good choice. So, I've started over. Can you explain

Re: [PATCH v2 0/2] Invert margin colors when terminal is inverted

On 07/31/2017 02:30 PM, Alan Cox wrote: On Mon, 31 Jul 2017 14:09:43 -0500 David Lechner wrote: This is v2 of "fbcon: Use background color for margins​"[1]. It turns out that using the text background color was not a good choice. So, I've started over. Can you explain why making the

Re: [RFC 0/5] Add I3C subsystem

Hi Wolfram, Le Mon, 31 Jul 2017 21:17:45 +0200, Wolfram Sang a écrit : > Hi Boris, > > > This patch series is a proposal for a new I3C [1] subsystem. > > Nice. Good luck with that! > > Some hi-level comments from me related to I2C. I can't say a lot more > because the

Re: [RFC 0/5] Add I3C subsystem

Hi Wolfram, Le Mon, 31 Jul 2017 21:17:45 +0200, Wolfram Sang a écrit : > Hi Boris, > > > This patch series is a proposal for a new I3C [1] subsystem. > > Nice. Good luck with that! > > Some hi-level comments from me related to I2C. I can't say a lot more > because the specs are not public

Re: [PATCH 3/3] mm/sched: memdelay: memory health interface for systems and workloads

On Mon, Jul 31, 2017 at 09:49:39PM +0200, Mike Galbraith wrote: > On Mon, 2017-07-31 at 14:41 -0400, Johannes Weiner wrote: > > > > Adding an rq counter for tasks inside memdelay sections should be > > straight-forward as well (except for maybe the migration cost of that > > state between CPUs in

Re: [PATCH 3/3] mm/sched: memdelay: memory health interface for systems and workloads

On Mon, Jul 31, 2017 at 09:49:39PM +0200, Mike Galbraith wrote: > On Mon, 2017-07-31 at 14:41 -0400, Johannes Weiner wrote: > > > > Adding an rq counter for tasks inside memdelay sections should be > > straight-forward as well (except for maybe the migration cost of that > > state between CPUs in

Re: [PATCH] ISDN: eicon: fix array-bounds warning properly

On Mon, Jul 31, 2017 at 9:38 PM, wrote: > Hi Arnd, > > I think you are right, but removing this is maybe the wrong fix. > > The issue is, that CAPI messages are packed byte streams and yes the > 64bit extension of CAPI is not very good designed for modern CPU > constrains

Re: [PATCH] ISDN: eicon: fix array-bounds warning properly

On Mon, Jul 31, 2017 at 9:38 PM, wrote: > Hi Arnd, > > I think you are right, but removing this is maybe the wrong fix. > > The issue is, that CAPI messages are packed byte streams and yes the > 64bit extension of CAPI is not very good designed for modern CPU > constrains with alignment, since

Re: [PATCH v3 12/16] switchtec_ntb: add link management

On Tue, Jul 25, 2017 at 02:57:49PM -0600, Logan Gunthorpe wrote: > switchtec_ntb checks for a link by looking at the shared memory > window. If the magic number is correct and the otherside indicates > their link is enabled then we take the link to be up. > > Whenever we change our local link

Re: [PATCH v3 12/16] switchtec_ntb: add link management

On Tue, Jul 25, 2017 at 02:57:49PM -0600, Logan Gunthorpe wrote: > switchtec_ntb checks for a link by looking at the shared memory > window. If the magic number is correct and the otherside indicates > their link is enabled then we take the link to be up. > > Whenever we change our local link

Re: [PATCH v3 10/16] switchtec_ntb: initialize hardware for doorbells and messages

On Tue, Jul 25, 2017 at 02:57:47PM -0600, Logan Gunthorpe wrote: > Set up some hardware registers and creates interrupt service routines > for the doorbells and messages. > > There are 64 doorbells in the switch that are shared between all > partitions. The upper 4 doorbells are also shared with

Re: [PATCH v3 10/16] switchtec_ntb: initialize hardware for doorbells and messages

On Tue, Jul 25, 2017 at 02:57:47PM -0600, Logan Gunthorpe wrote: > Set up some hardware registers and creates interrupt service routines > for the doorbells and messages. > > There are 64 doorbells in the switch that are shared between all > partitions. The upper 4 doorbells are also shared with

Re: [PATCH v3 09/16] switchtec_ntb: initialize hardware for memory windows

On Tue, Jul 25, 2017 at 02:57:46PM -0600, Logan Gunthorpe wrote: > Add the code to initialize the memory windows in the hardware. > This includes setting up the requester ID table, and figuring out > which bar corresponds to which memory window. (Seeing the switch > can be configured with any

Re: [PATCH v3 09/16] switchtec_ntb: initialize hardware for memory windows

On Tue, Jul 25, 2017 at 02:57:46PM -0600, Logan Gunthorpe wrote: > Add the code to initialize the memory windows in the hardware. > This includes setting up the requester ID table, and figuring out > which bar corresponds to which memory window. (Seeing the switch > can be configured with any

[PATCH] arm64: defconfig: enable fine-grained task level IRQ time accounting

Tests showed, that under certain conditions, the summary number of jiffies spent on softirq/idle, which are counted by system statistics can be even below 10% of expected value, resulting in false load presentation. The issue was observed on the quad-core Marvell Armada 8k SoC, whose two 10G

[PATCH] arm64: defconfig: enable fine-grained task level IRQ time accounting

Tests showed, that under certain conditions, the summary number of jiffies spent on softirq/idle, which are counted by system statistics can be even below 10% of expected value, resulting in false load presentation. The issue was observed on the quad-core Marvell Armada 8k SoC, whose two 10G

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Sat, 2017-07-29 at 08:47 +0200, Borislav Petkov wrote: > On Fri, Jul 28, 2017 at 06:50:56PM +, Kani, Toshimitsu wrote: > > This simply sets NULL to pvt, and does not initialize ghes_pvt. > > Yeah, I guess we need this ontop: Yes, this fix looks good. > >  As Mauro pointed out, some type

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Sat, 2017-07-29 at 08:47 +0200, Borislav Petkov wrote: > On Fri, Jul 28, 2017 at 06:50:56PM +, Kani, Toshimitsu wrote: > > This simply sets NULL to pvt, and does not initialize ghes_pvt. > > Yeah, I guess we need this ontop: Yes, this fix looks good. > >  As Mauro pointed out, some type

Re: [v3] mm: Add SLUB free list pointer obfuscation

Hello Christopher and Kees, Excuse me for the delayed reply. On 28.07.2017 02:53, Christopher Lameter wrote: > On Fri, 28 Jul 2017, Alexander Popov wrote: > >> I don't really like ignoring double-free. I think, that: >> - it will hide dangerous bugs in the kernel, >> - it can make some

Re: [v3] mm: Add SLUB free list pointer obfuscation

Hello Christopher and Kees, Excuse me for the delayed reply. On 28.07.2017 02:53, Christopher Lameter wrote: > On Fri, 28 Jul 2017, Alexander Popov wrote: > >> I don't really like ignoring double-free. I think, that: >> - it will hide dangerous bugs in the kernel, >> - it can make some

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