Re: [PATCH 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

On 26/06/2017 at 10:15:46 -0700, Florian Fainelli wrote: > > This is not needed since d68778b80dd7 > > Great, I will take that out. > > Do you care whether some dev_dbg() prints are left in the driver or > should I remove those in v2? > It could have stayed but it seems you removed it from v2.

Re: [PATCH 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

On 26/06/2017 at 10:15:46 -0700, Florian Fainelli wrote: > > This is not needed since d68778b80dd7 > > Great, I will take that out. > > Do you care whether some dev_dbg() prints are left in the driver or > should I remove those in v2? > It could have stayed but it seems you removed it from v2.

Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

On Monday, June 26, 2017 04:40:08 PM Lyude wrote: > There's quite a number of machines on the market, mainly Lenovo > ThinkPads, that make the horrible mistake in their firmware of reusing > the PCIBAR space reserved for the SMBus for things that are completely > unrelated to the SMBus controller,

Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

On Monday, June 26, 2017 04:40:08 PM Lyude wrote: > There's quite a number of machines on the market, mainly Lenovo > ThinkPads, that make the horrible mistake in their firmware of reusing > the PCIBAR space reserved for the SMBus for things that are completely > unrelated to the SMBus controller,

Re: [PATCH] MIPS: perf: fix build failure

On Mon, Jun 26, 2017 at 08:44:48AM +0200, Marcin Nowakowski wrote: > Hi Sudip, > > This patch fixes the build error, but leaves the I6500 handling incorrect. I am failing to understand why I6500 handling is incorrect. I am seeing that after applying my patch the I6500 handling is same as

Re: [PATCH] MIPS: perf: fix build failure

On Mon, Jun 26, 2017 at 08:44:48AM +0200, Marcin Nowakowski wrote: > Hi Sudip, > > This patch fixes the build error, but leaves the I6500 handling incorrect. I am failing to understand why I6500 handling is incorrect. I am seeing that after applying my patch the I6500 handling is same as

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Mon, Jun 26, 2017 at 08:19:07PM +0200, Rafał Miłecki wrote: > On 2017-06-26 19:33, Luis R. Rodriguez wrote: > > On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote: > > > > There are still other requirements and features in the pipeline for > > > > which we > > > > can consider parameters

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Mon, Jun 26, 2017 at 08:19:07PM +0200, Rafał Miłecki wrote: > On 2017-06-26 19:33, Luis R. Rodriguez wrote: > > On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote: > > > > There are still other requirements and features in the pipeline for > > > > which we > > > > can consider parameters

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

On 6/26/2017 2:43 PM, Arnd Bergmann wrote: This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which I find rather confusing, as only about one in five drivers wants this behavior. I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures, but rather use the

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

On 6/26/2017 2:43 PM, Arnd Bergmann wrote: This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which I find rather confusing, as only about one in five drivers wants this behavior. I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures, but rather use the

[PATCH v2] firmware: fix batched requests - wake all waiters

From: Jakub Kicinski The firmware cache mechanism serves two purposes, the secondary purpose is not well documented nor understood. This fixes a regression with the secondary purpose of the firmware cache mechanism: batched requests. The firmware cache is used for:

[PATCH v2] firmware: fix batched requests - wake all waiters

From: Jakub Kicinski The firmware cache mechanism serves two purposes, the secondary purpose is not well documented nor understood. This fixes a regression with the secondary purpose of the firmware cache mechanism: batched requests. The firmware cache is used for: 1) Addressing races with

Re: [PATCH] firmware: wake all waiters

Thank you for your patch! On Fri, Jun 23, 2017 at 04:37:02PM -0700, Jakub Kicinski wrote: > Multiple devices may be waiting for firmware with the same name. This is due to a hidden and not-well understood feature of the firmware API. I can trace commit logs loosely documenting this as an

Re: [PATCH] firmware: wake all waiters

Thank you for your patch! On Fri, Jun 23, 2017 at 04:37:02PM -0700, Jakub Kicinski wrote: > Multiple devices may be waiting for firmware with the same name. This is due to a hidden and not-well understood feature of the firmware API. I can trace commit logs loosely documenting this as an

Re: [PATCH v3 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

On Mon 26 Jun 13:20 PDT 2017, Suman Anna wrote: > On 06/26/2017 03:06 PM, Bjorn Andersson wrote: > > On Mon 26 Jun 08:54 PDT 2017, Suman Anna wrote: > >> On 06/25/2017 03:15 PM, Bjorn Andersson wrote: [..] > > I still would like to have resources allocated at probe() time, so I > > would

Re: [PATCH v3 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

On Mon 26 Jun 13:20 PDT 2017, Suman Anna wrote: > On 06/26/2017 03:06 PM, Bjorn Andersson wrote: > > On Mon 26 Jun 08:54 PDT 2017, Suman Anna wrote: > >> On 06/25/2017 03:15 PM, Bjorn Andersson wrote: [..] > > I still would like to have resources allocated at probe() time, so I > > would

Re: [PATCH 0/4] firmware: fix fallback mechanism by ignoring SIGCHLD

On Wed, Jun 14, 2017 at 03:20:13PM -0700, Luis R. Rodriguez wrote: > Martin reported an issue with Android where if sysfs is used to trigger a sync > fw load which *relies* on the fallback mechanism and a background job > completes > while the trigger is ongoing in the foreground it will

Re: [PATCH 0/4] firmware: fix fallback mechanism by ignoring SIGCHLD

On Wed, Jun 14, 2017 at 03:20:13PM -0700, Luis R. Rodriguez wrote: > Martin reported an issue with Android where if sysfs is used to trigger a sync > fw load which *relies* on the fallback mechanism and a background job > completes > while the trigger is ongoing in the foreground it will

Re: [PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

On 6/23/2017 11:06 AM, Brijesh Singh wrote: Update pci and platform files to use devres interface to allocate the PCI and iomap resources. Also add helper functions to consolicate module init, exit and power mangagement code duplication. Signed-off-by: Brijesh Singh ---

Re: [PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

On 6/23/2017 11:06 AM, Brijesh Singh wrote: Update pci and platform files to use devres interface to allocate the PCI and iomap resources. Also add helper functions to consolicate module init, exit and power mangagement code duplication. Signed-off-by: Brijesh Singh ---

[PATCH v2 0/2] Broadcom STB wake-timer support

Hi Alexandre, This patch series adds support for the Broadcom STB wake-timer. This is a 27Mhz timer which allows the system to exit S2/S3/S5 sleep states when configured. The wake-timer has has a long history within our internal/downstream tree, and Brian authored it in the first place, then

[PATCH v2 0/2] Broadcom STB wake-timer support

Hi Alexandre, This patch series adds support for the Broadcom STB wake-timer. This is a 27Mhz timer which allows the system to exit S2/S3/S5 sleep states when configured. The wake-timer has has a long history within our internal/downstream tree, and Brian authored it in the first place, then

[PATCH v2 1/2] dt-bindings: Document the Broadcom STB wake-up timer node

Document the binding for the Broadcom STB SoCs wake-up timer node allowing the system to generate alarms and exit low power states. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../bindings/rtc/brcm,brcmstb-waketimer.txt| 22

[PATCH v2 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

From: Brian Norris This adds support for the Broadcom STB wake-timer which is a timer in the chip's 27Mhz clock domain that offers the ability to wake the system (wake-up source) from suspend states (S2, S3, S5). It is supported using the rtc framework allowing us to

[PATCH v2 1/2] dt-bindings: Document the Broadcom STB wake-up timer node

Document the binding for the Broadcom STB SoCs wake-up timer node allowing the system to generate alarms and exit low power states. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../bindings/rtc/brcm,brcmstb-waketimer.txt| 22 ++ 1 file changed, 22

[PATCH v2 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

From: Brian Norris This adds support for the Broadcom STB wake-timer which is a timer in the chip's 27Mhz clock domain that offers the ability to wake the system (wake-up source) from suspend states (S2, S3, S5). It is supported using the rtc framework allowing us to configure alarms for system

Re: [PATCH] kernel/power/suspend: use CONFIG_HAVE_SET_MEMORY for include condition

On Monday, June 26, 2017 01:34:52 PM Balbir Singh wrote: > On Sat, Jun 3, 2017 at 11:27 PM, Pavel Machek wrote: > > On Sat 2017-06-03 20:52:32, Balbir Singh wrote: > >> Kbuild reported a build failure when CONFIG_STRICT_KERNEL_RWX was > >> enabled on powerpc. We don't yet have

Re: [PATCH] kernel/power/suspend: use CONFIG_HAVE_SET_MEMORY for include condition

On Monday, June 26, 2017 01:34:52 PM Balbir Singh wrote: > On Sat, Jun 3, 2017 at 11:27 PM, Pavel Machek wrote: > > On Sat 2017-06-03 20:52:32, Balbir Singh wrote: > >> Kbuild reported a build failure when CONFIG_STRICT_KERNEL_RWX was > >> enabled on powerpc. We don't yet have ARCH_HAS_SET_MEMORY

Re: [PATCH v2] mtd: spi-nor: Add support for Spansion S25FL064L

Le 22/06/2017 à 21:58, Harry Chou a écrit : > It's an 8 MiB flash with 4 KiB erase sectors. > > Signed-off-by: Harry Chou Applied to the spi-nor/next branch of l2-mtd Thanks! > --- > Changes v1 -> v2: > - added SPI_NOR_DUAL_READ flag (supports Dual Output and I/O) >

Re: [PATCH v2] mtd: spi-nor: Add support for Spansion S25FL064L

Le 22/06/2017 à 21:58, Harry Chou a écrit : > It's an 8 MiB flash with 4 KiB erase sectors. > > Signed-off-by: Harry Chou Applied to the spi-nor/next branch of l2-mtd Thanks! > --- > Changes v1 -> v2: > - added SPI_NOR_DUAL_READ flag (supports Dual Output and I/O) > - added

Re: [PATCH] Added SIOCSMIIREG (mii write) support to intel igb driver

On Thu, 2017-06-22 at 15:23 +0200, Michael Moese wrote: > From: Andreas Werner > > Signed-off-by: Andreas Werner > --- >  drivers/net/ethernet/intel/igb/igb_main.c | 4 >  1 file changed, 4 insertions(+) NACK Why? Your lack of patch

Re: [PATCH] Added SIOCSMIIREG (mii write) support to intel igb driver

On Thu, 2017-06-22 at 15:23 +0200, Michael Moese wrote: > From: Andreas Werner > > Signed-off-by: Andreas Werner > --- >  drivers/net/ethernet/intel/igb/igb_main.c | 4 >  1 file changed, 4 insertions(+) NACK Why? Your lack of patch description does not provide a reasoning on why we need

non-x86 per-task stack canaries

Hi, The stack protector functionality on x86_64 uses %gs:0x28 (%gs is the percpu area) for __stack_chk_guard, and all other architectures use a global variable instead. This means we never change the stack canary on non-x86 architectures which allows for a leak in one task to expose the canary in

non-x86 per-task stack canaries

Hi, The stack protector functionality on x86_64 uses %gs:0x28 (%gs is the percpu area) for __stack_chk_guard, and all other architectures use a global variable instead. This means we never change the stack canary on non-x86 architectures which allows for a leak in one task to expose the canary in

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Mon, 26 Jun 2017, Frans Klaver wrote: > On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote: > > > > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > > > > > Hm. For some reason the great mail filtering scheme decided to push > > > this past my inbox :-/ > > > > > > On Sat, Jun 17,

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Mon, 26 Jun 2017, Frans Klaver wrote: > On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote: > > > > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > > > > > Hm. For some reason the great mail filtering scheme decided to push > > > this past my inbox :-/ > > > > > > On Sat, Jun 17,

RE: [PATCH 08/10] x86/hyper-v: use hypercall for remote TLB flush

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Vitaly Kuznetsov > Sent: Monday, June 26, 2017 1:15 AM > To: k...@exchange.microsoft.com > Cc: o...@aepfle.de; Stephen Hemminger ; >

RE: [PATCH 08/10] x86/hyper-v: use hypercall for remote TLB flush

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Vitaly Kuznetsov > Sent: Monday, June 26, 2017 1:15 AM > To: k...@exchange.microsoft.com > Cc: o...@aepfle.de; Stephen Hemminger ; > gre...@linuxfoundation.org; jasow...@redhat.com;

Re: [PATCH] writeback: Simplify wb_stat_sum

[CC'ing Andrew since he seems to be taking those patches through -mm ] On 23.06.2017 18:11, Nikolay Borisov wrote: > wb_stat_sum disables interrupts and calls __wb_stat_sum which eventually calls > __percpu_counter_sum. However, the percpu routine is already irq-safe. > Simplify > the code a bit

Re: [PATCH] writeback: Simplify wb_stat_sum

[CC'ing Andrew since he seems to be taking those patches through -mm ] On 23.06.2017 18:11, Nikolay Borisov wrote: > wb_stat_sum disables interrupts and calls __wb_stat_sum which eventually calls > __percpu_counter_sum. However, the percpu routine is already irq-safe. > Simplify > the code a bit

Re: [PATCH] sata_via: Enable optional hotplug on VT6420

On Sun, Jun 25, 2017 at 10:25:36PM +0200, Ondrej Zary wrote: > VT6420 seems to have the same hotplug capability as VT6421. > > However, enabling hotplug needs to expose SCR registers which can cause > problems. It works for me but might break elsewhere. So add a module > parameter vt6420_hotplug

Re: [PATCH] sata_via: Enable optional hotplug on VT6420

On Sun, Jun 25, 2017 at 10:25:36PM +0200, Ondrej Zary wrote: > VT6420 seems to have the same hotplug capability as VT6421. > > However, enabling hotplug needs to expose SCR registers which can cause > problems. It works for me but might break elsewhere. So add a module > parameter vt6420_hotplug

Re: [PATCH 02/11] dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrs

On Mon, Jun 26, 2017 at 12:07:30AM -0700, Christoph Hellwig wrote: > Tejun, does this look ok to you? Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH 01/11] dma-mapping: remove dmam_free_noncoherent

On Mon, Jun 26, 2017 at 12:07:15AM -0700, Christoph Hellwig wrote: > Tejun, does this look ok to you? Sure, Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH 02/11] dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrs

On Mon, Jun 26, 2017 at 12:07:30AM -0700, Christoph Hellwig wrote: > Tejun, does this look ok to you? Acked-by: Tejun Heo Thanks. -- tejun

Re: [PATCH 01/11] dma-mapping: remove dmam_free_noncoherent

On Mon, Jun 26, 2017 at 12:07:15AM -0700, Christoph Hellwig wrote: > Tejun, does this look ok to you? Sure, Acked-by: Tejun Heo Thanks. -- tejun

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote: > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > > > Hm. For some reason the great mail filtering scheme decided to push > > this past my inbox :-/ > > > > On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: > > >

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote: > > > On Sat, 24 Jun 2017, Frans Klaver wrote: > > > Hm. For some reason the great mail filtering scheme decided to push > > this past my inbox :-/ > > > > On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: > > > On Fri,

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On 2017-06-26 19:33, Luis R. Rodriguez wrote: On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote: On Sat, Jun 24, 2017 at 02:48:28AM +0200, Luis R. Rodriguez wrote: > On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote: > > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On 2017-06-26 19:33, Luis R. Rodriguez wrote: On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote: On Sat, Jun 24, 2017 at 02:48:28AM +0200, Luis R. Rodriguez wrote: > On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote: > > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

> On Jun 26, 2017, at 1:22 PM, Tahsin Erdogan wrote: > > On Thu, Jun 22, 2017 at 4:23 PM, Khazhismel Kumykov wrote: >> - /* read error, skip block & hope for the best */ >>EXT4_ERROR_INODE(dir, "reading

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

> On Jun 26, 2017, at 1:22 PM, Tahsin Erdogan wrote: > > On Thu, Jun 22, 2017 at 4:23 PM, Khazhismel Kumykov wrote: >> - /* read error, skip block & hope for the best */ >>EXT4_ERROR_INODE(dir, "reading directory lblock %lu", >>

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

> +u64 ioread64(void __iomem *addr) > +{ > + u64 low, high; > + > + low = ioread32(addr); > + high = ioread32(addr + sizeof(u32)); > + return low | (high << 32); > +} > +u64 ioread64be(void __iomem *addr) > +{ > + u64 low, high; > + > + low = ioread32be(addr +

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

> +u64 ioread64(void __iomem *addr) > +{ > + u64 low, high; > + > + low = ioread32(addr); > + high = ioread32(addr + sizeof(u32)); > + return low | (high << 32); > +} > +u64 ioread64be(void __iomem *addr) > +{ > + u64 low, high; > + > + low = ioread32be(addr +

[PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

There's quite a number of machines on the market, mainly Lenovo ThinkPads, that make the horrible mistake in their firmware of reusing the PCIBAR space reserved for the SMBus for things that are completely unrelated to the SMBus controller, such as the OpRegion used for i915. This is very bad and

[PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

There's quite a number of machines on the market, mainly Lenovo ThinkPads, that make the horrible mistake in their firmware of reusing the PCIBAR space reserved for the SMBus for things that are completely unrelated to the SMBus controller, such as the OpRegion used for i915. This is very bad and

Re: [PATCH v2 5/8] dt-bindings: iio: Add STM32 LPTimer trigger binding

On 26 June 2017 19:14:16 BST, Rob Herring wrote: >On Wed, Jun 21, 2017 at 04:30:12PM +0200, Fabrice Gasnier wrote: >> Add documentation for STMicroelectronics STM32 Low-Power Timer >Trigger >> binding. >> >> Signed-off-by: Fabrice Gasnier >> --- >>

Re: [PATCH v2 5/8] dt-bindings: iio: Add STM32 LPTimer trigger binding

On 26 June 2017 19:14:16 BST, Rob Herring wrote: >On Wed, Jun 21, 2017 at 04:30:12PM +0200, Fabrice Gasnier wrote: >> Add documentation for STMicroelectronics STM32 Low-Power Timer >Trigger >> binding. >> >> Signed-off-by: Fabrice Gasnier >> --- >> Changes in v2: >> - s/Low Power/Low-Power >>

Re: [PATCH v2] PM / wakeirq: Convert to SRCU

On Sun, Jun 25, 2017 at 07:31:13PM +0200, Thomas Gleixner wrote: > The wakeirq infrastructure uses RCU to protect the list of wakeirqs. That > breaks the irq bus locking infrastructure, which is allows sleeping > functions to be called so interrupt controllers behind slow busses, > e.g. i2c, can

Re: [PATCH v2] PM / wakeirq: Convert to SRCU

On Sun, Jun 25, 2017 at 07:31:13PM +0200, Thomas Gleixner wrote: > The wakeirq infrastructure uses RCU to protect the list of wakeirqs. That > breaks the irq bus locking infrastructure, which is allows sleeping > functions to be called so interrupt controllers behind slow busses, > e.g. i2c, can

[PATCH] soc: qcom: mdt_loader: Use request_firmware_into_buf()

By switching to the request_firmware_into_buf() we load the segment data straight into the preallocated buffers, reducing the need for allocating scratch buffers for these. In particular the modem firmware consists of multiple segments in the range 5-15MB, making this worth while. Signed-off-by:

[PATCH] soc: qcom: mdt_loader: Use request_firmware_into_buf()

By switching to the request_firmware_into_buf() we load the segment data straight into the preallocated buffers, reducing the need for allocating scratch buffers for these. In particular the modem firmware consists of multiple segments in the range 5-15MB, making this worth while. Signed-off-by:

Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups

On Mon, 26 Jun 2017, Don Zickus wrote: > On Fri, Jun 23, 2017 at 11:50:25PM +0200, Thomas Gleixner wrote: > > On Fri, 23 Jun 2017, Don Zickus wrote: > > > Hmm, all this work for a temp fix. Kan, how much longer until the real > > > fix > > > of having perf count the right cycles? > > > > Quite

Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups

On Mon, 26 Jun 2017, Don Zickus wrote: > On Fri, Jun 23, 2017 at 11:50:25PM +0200, Thomas Gleixner wrote: > > On Fri, 23 Jun 2017, Don Zickus wrote: > > > Hmm, all this work for a temp fix. Kan, how much longer until the real > > > fix > > > of having perf count the right cycles? > > > > Quite

Re: [PATCH v2 8/8] iio: counter: Add support for STM32 LPTimer

On Sat, Jun 24, 2017 at 09:35:39PM +0100, Jonathan Cameron wrote: >On Wed, 21 Jun 2017 16:30:15 +0200 >Fabrice Gasnier wrote: > >> Add support for STM32 Low-Power Timer, that can be used as counter >> or quadrature encoder. >> >> Signed-off-by: Fabrice Gasnier

Re: [PATCH v2 8/8] iio: counter: Add support for STM32 LPTimer

On Sat, Jun 24, 2017 at 09:35:39PM +0100, Jonathan Cameron wrote: >On Wed, 21 Jun 2017 16:30:15 +0200 >Fabrice Gasnier wrote: > >> Add support for STM32 Low-Power Timer, that can be used as counter >> or quadrature encoder. >> >> Signed-off-by: Fabrice Gasnier >Hmm. Sometime I'm going to ask

[PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

We wanted to add RISC-V to the list of architectures that used the generic PCI setup-irq.o inside the Makefile and it was suggested that instead we define a Kconfig entry and use that. I've done very minimal testing on this: I just checked to see that an aarch64 defconfig still build setup-irq.o

[PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

We wanted to add RISC-V to the list of architectures that used the generic PCI setup-irq.o inside the Makefile and it was suggested that instead we define a Kconfig entry and use that. I've done very minimal testing on this: I just checked to see that an aarch64 defconfig still build setup-irq.o

Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

rop us a note to >> help improve the system] >> >> url: >> https://github.com/0day-ci/linux/commits/Palmer-Dabbelt/pci-Add-and-use-PCI_GENERIC_SETUP-Kconfig-entry/20170626-043558 >> config: m68k-allnoconfig (attached as .config) >> compile

Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

elp improve the system] >> >> url: >> https://github.com/0day-ci/linux/commits/Palmer-Dabbelt/pci-Add-and-use-PCI_GENERIC_SETUP-Kconfig-entry/20170626-043558 >> config: m68k-allnoconfig (attached as .config) >> compiler: m68k-linux-gcc (GCC) 4.9.0 >> repro

Re: [PATCH] firmware: remove request_firmware_into_buf()

On Fri, Jun 23, 2017 at 9:03 AM, Greg Kroah-Hartman wrote: > As Luis pointed out, there are no in-kernel users of > request_firmware_into_buf(), so remove it, and the now unused internal > flag, which simplifies the logic around buffer handling a bit. > This API was

Re: [PATCH] firmware: remove request_firmware_into_buf()

On Fri, Jun 23, 2017 at 9:03 AM, Greg Kroah-Hartman wrote: > As Luis pointed out, there are no in-kernel users of > request_firmware_into_buf(), so remove it, and the now unused internal > flag, which simplifies the logic around buffer handling a bit. > This API was implemented to reduce the

Re: [PATCH v3 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

On 06/26/2017 03:06 PM, Bjorn Andersson wrote: > On Mon 26 Jun 08:54 PDT 2017, Suman Anna wrote: > >> Hi Bjorn, >> >> On 06/25/2017 03:15 PM, Bjorn Andersson wrote: >>> On Tue 13 Jun 16:45 PDT 2017, Suman Anna wrote: >>> +static int keystone_rproc_start(struct rproc *rproc) +{ +

Re: [PATCH v3 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

On 06/26/2017 03:06 PM, Bjorn Andersson wrote: > On Mon 26 Jun 08:54 PDT 2017, Suman Anna wrote: > >> Hi Bjorn, >> >> On 06/25/2017 03:15 PM, Bjorn Andersson wrote: >>> On Tue 13 Jun 16:45 PDT 2017, Suman Anna wrote: >>> +static int keystone_rproc_start(struct rproc *rproc) +{ +

[RFC] COMPAT_IPMICTL_RECEIVE_MSG semantics

There's something odd about IPMICTL_RECEIVE_MSG and its compat counterpart. The former checks if copying struct ipmi_recv back to userland succeeds and put the message back into queue on failure. The latter does not; it copies native structure to userland stack and then (after having

[RFC] COMPAT_IPMICTL_RECEIVE_MSG semantics

There's something odd about IPMICTL_RECEIVE_MSG and its compat counterpart. The former checks if copying struct ipmi_recv back to userland succeeds and put the message back into queue on failure. The latter does not; it copies native structure to userland stack and then (after having

Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups

On Fri, Jun 23, 2017 at 11:50:25PM +0200, Thomas Gleixner wrote: > On Fri, 23 Jun 2017, Don Zickus wrote: > > Hmm, all this work for a temp fix. Kan, how much longer until the real fix > > of having perf count the right cycles? > > Quite a while. The approach is wilfully breaking the user space

Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups

On Fri, Jun 23, 2017 at 11:50:25PM +0200, Thomas Gleixner wrote: > On Fri, 23 Jun 2017, Don Zickus wrote: > > Hmm, all this work for a temp fix. Kan, how much longer until the real fix > > of having perf count the right cycles? > > Quite a while. The approach is wilfully breaking the user space

Re: [PATCH v2] nvme: explicitly disable APST on quirked devices

On Mon, Jun 26, 2017 at 12:01:29AM -0700, Kai-Heng Feng wrote: > A user reports APST is enabled, even when the NVMe is quirked or with > option "default_ps_max_latency_us=0". > > The current logic will not set APST if the device is quirked. But the > NVMe in question will enable APST

Re: [PATCH v2] nvme: explicitly disable APST on quirked devices

On Mon, Jun 26, 2017 at 12:01:29AM -0700, Kai-Heng Feng wrote: > A user reports APST is enabled, even when the NVMe is quirked or with > option "default_ps_max_latency_us=0". > > The current logic will not set APST if the device is quirked. But the > NVMe in question will enable APST

Re: [PATCH] media: omap3isp: handle NULL return of omap3isp_video_format_info() in ccdc_is_shiftable().

Hi Nikolaus, On Mon, Jun 26, 2017 at 07:54:19PM +0200, H. Nikolaus Schaller wrote: > If a camera module driver specifies a format that is not > supported by omap3isp this ends in a NULL pointer > dereference instead of a simple fail. Has this happened in practice? If it does, it is probably a

Re: [PATCH] media: omap3isp: handle NULL return of omap3isp_video_format_info() in ccdc_is_shiftable().

Hi Nikolaus, On Mon, Jun 26, 2017 at 07:54:19PM +0200, H. Nikolaus Schaller wrote: > If a camera module driver specifies a format that is not > supported by omap3isp this ends in a NULL pointer > dereference instead of a simple fail. Has this happened in practice? If it does, it is probably a

Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer syscalls

On Mon, Jun 26, 2017 at 8:17 PM, Deepa Dinamani wrote: > On Sun, Jun 25, 2017 at 7:35 PM, Al Viro wrote: >> On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote: >>> The series aims at isolating data conversions of time_t based

Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer syscalls

On Mon, Jun 26, 2017 at 8:17 PM, Deepa Dinamani wrote: > On Sun, Jun 25, 2017 at 7:35 PM, Al Viro wrote: >> On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote: >>> The series aims at isolating data conversions of time_t based structures: >>> struct timespec and struct itimerspec at

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 06:16:11 PDT (-0700), will.dea...@arm.com wrote: > [sorry, jumping in here because it's the only mail I have relating to > patch 13] > > On Wed, Jun 07, 2017 at 02:58:50PM +0200, Peter Zijlstra wrote: >> On Wed, Jun 07, 2017 at 02:36:27PM +0200, Peter Zijlstra wrote: >> >

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 06:16:11 PDT (-0700), will.dea...@arm.com wrote: > [sorry, jumping in here because it's the only mail I have relating to > patch 13] > > On Wed, Jun 07, 2017 at 02:58:50PM +0200, Peter Zijlstra wrote: >> On Wed, Jun 07, 2017 at 02:36:27PM +0200, Peter Zijlstra wrote: >> >

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 05:58:50 PDT (-0700), pet...@infradead.org wrote: > On Wed, Jun 07, 2017 at 02:36:27PM +0200, Peter Zijlstra wrote: >> Which (pending the sub confusion) will generate the entire set of: >> >> atomic_add, atomic_add_return{_relaxed,_acquire,_release,} >>

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 05:58:50 PDT (-0700), pet...@infradead.org wrote: > On Wed, Jun 07, 2017 at 02:36:27PM +0200, Peter Zijlstra wrote: >> Which (pending the sub confusion) will generate the entire set of: >> >> atomic_add, atomic_add_return{_relaxed,_acquire,_release,} >>

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 06:17:27 PDT (-0700), pet...@infradead.org wrote: > On Tue, Jun 06, 2017 at 04:00:03PM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/spinlock.h >> b/arch/riscv/include/asm/spinlock.h >> new file mode 100644 >> index ..9736f5714e54 >> ---

Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 06:17:27 PDT (-0700), pet...@infradead.org wrote: > On Tue, Jun 06, 2017 at 04:00:03PM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/riscv/include/asm/spinlock.h >> b/arch/riscv/include/asm/spinlock.h >> new file mode 100644 >> index ..9736f5714e54 >> ---

Re: [PATCH v3 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

On Mon 26 Jun 08:54 PDT 2017, Suman Anna wrote: > Hi Bjorn, > > On 06/25/2017 03:15 PM, Bjorn Andersson wrote: > > On Tue 13 Jun 16:45 PDT 2017, Suman Anna wrote: > > > >> +static int keystone_rproc_start(struct rproc *rproc) > >> +{ > >> + struct keystone_rproc *ksproc = rproc->priv; > >> +

Re: [PATCH v3 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

On Mon 26 Jun 08:54 PDT 2017, Suman Anna wrote: > Hi Bjorn, > > On 06/25/2017 03:15 PM, Bjorn Andersson wrote: > > On Tue 13 Jun 16:45 PDT 2017, Suman Anna wrote: > > > >> +static int keystone_rproc_start(struct rproc *rproc) > >> +{ > >> + struct keystone_rproc *ksproc = rproc->priv; > >> +

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/26/2017 12:35 PM, Hugues FRUCHET wrote: >> What I am missing to support the GTA04 camera is the control of the optional >> "vana-supply". >> So the driver does not power up the camera module when needed and therefore >> probing fails. >> >> - vana-supply: a regulator to power up the

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/26/2017 12:35 PM, Hugues FRUCHET wrote: >> What I am missing to support the GTA04 camera is the control of the optional >> "vana-supply". >> So the driver does not power up the camera module when needed and therefore >> probing fails. >> >> - vana-supply: a regulator to power up the

Re: [PATCH] iio: dac: DS4424: add Maxim DS4422/DS4424 DAC driver support

On Fri, Jun 23, 2017 at 04:04:04PM -0700, Ismail Kose wrote: > From: "Ismail H. Kose" > > Add iio driver for DS4422/DS4424 chips that support two/four channel 7-bit > Sink/Source Current DAC. > > The driver supports device tree and platfrom files for the configurations. > >

Re: [PATCH] iio: dac: DS4424: add Maxim DS4422/DS4424 DAC driver support

On Fri, Jun 23, 2017 at 04:04:04PM -0700, Ismail Kose wrote: > From: "Ismail H. Kose" > > Add iio driver for DS4422/DS4424 chips that support two/four channel 7-bit > Sink/Source Current DAC. > > The driver supports device tree and platfrom files for the configurations. > > Datasheet publicly

[PATCH] ntb: use correct mw_count function in ntb_tool and ntb_transport

After converting to the new API, both ntb_tool and ntb_transport are using ntb_mw_count to iterate through ntb_peer_get_addr when they should be using ntb_peer_mw_count. This probably isn't an issue with the Intel and AMD drivers but this will matter for any future driver with asymetric memory

[PATCH] ntb: use correct mw_count function in ntb_tool and ntb_transport

After converting to the new API, both ntb_tool and ntb_transport are using ntb_mw_count to iterate through ntb_peer_get_addr when they should be using ntb_peer_mw_count. This probably isn't an issue with the Intel and AMD drivers but this will matter for any future driver with asymetric memory

Re: [PATCH v2 00/14] improve the fb_setcmap helper

> > I'm traveling and cannot make progress this week. The merge window is > also real close so this series will therefore probably miss it unless > something unexpected happens... Don't worry you missed the merge window for drm already, we don't merge things after -rc6. Please remember the Linus

Re: [PATCH v2 00/14] improve the fb_setcmap helper

> > I'm traveling and cannot make progress this week. The merge window is > also real close so this series will therefore probably miss it unless > something unexpected happens... Don't worry you missed the merge window for drm already, we don't merge things after -rc6. Please remember the Linus

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