Re: [RFC PATCH] media: vb2: add bidirectional flag in vb2_queue

Hi, 2017-08-17 20:11 GMT+08:00 Stanimir Varbanov : > Hi Laurent, > > On 08/16/2017 03:28 PM, Laurent Pinchart wrote: >> Hi Stan, >> >> On Wednesday 16 Aug 2017 14:46:50 Stanimir Varbanov wrote: >>> On 08/15/2017 01:04 PM, Hans Verkuil wrote: On 08/14/17 10:41,

Re: [RFC PATCH] media: vb2: add bidirectional flag in vb2_queue

Hi, 2017-08-17 20:11 GMT+08:00 Stanimir Varbanov : > Hi Laurent, > > On 08/16/2017 03:28 PM, Laurent Pinchart wrote: >> Hi Stan, >> >> On Wednesday 16 Aug 2017 14:46:50 Stanimir Varbanov wrote: >>> On 08/15/2017 01:04 PM, Hans Verkuil wrote: On 08/14/17 10:41, Stanimir Varbanov wrote: >

[PATCH 0/2 v7] printk: Add new timestamps

printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware

[PATCH 0/2 v7] printk: Add new timestamps

printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware

[PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps

printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware

[PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps

printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware

[PATCH 1/2 v7] time: Make fast functions return 0 before timekeeping is initialized

printk timestamps will be extended to include mono and boot time by using the fast timekeeping functions ktime_get_mono|boot_fast_ns() functions. The functions can return garbage before timekeeping is initialized resulting in garbage timestamps. The fast time functions must return 0 before

[PATCH 1/2 v7] time: Make fast functions return 0 before timekeeping is initialized

printk timestamps will be extended to include mono and boot time by using the fast timekeeping functions ktime_get_mono|boot_fast_ns() functions. The functions can return garbage before timekeeping is initialized resulting in garbage timestamps. The fast time functions must return 0 before

[PATCH] crypto: nx: 842: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/crypto/nx/nx-842-pseries.c | 2 +- 1 file changed,

[PATCH] crypto: nx: 842: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/crypto/nx/nx-842-pseries.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] crypto: nx: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/crypto/nx/nx.c | 2 +- 1 file changed, 1

[PATCH] crypto: nx: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/crypto/nx/nx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH 3/3] cgroup: Implement cgroup2 basic CPU usage accounting

Hello, On Thu, Aug 17, 2017 at 01:07:41PM +0100, Roman Gushchin wrote: > On Fri, Aug 11, 2017 at 09:37:54AM -0700, Tejun Heo wrote: > > In cgroup1, while cpuacct isn't actually controlling any resources, it > > is a separate controller due to combinaton of two factors - > >

Re: [PATCH 3/3] cgroup: Implement cgroup2 basic CPU usage accounting

Hello, On Thu, Aug 17, 2017 at 01:07:41PM +0100, Roman Gushchin wrote: > On Fri, Aug 11, 2017 at 09:37:54AM -0700, Tejun Heo wrote: > > In cgroup1, while cpuacct isn't actually controlling any resources, it > > is a separate controller due to combinaton of two factors - > >

warning: objtool: ...: call without frame pointer save/setup; return with modified stack frame

Today I coticed the following objtool warnings when compiling 4.13-rc5+git for my Atom 330 PC: call without frame pointer save/setup return with modified stack frame Examples (there is a lot more of them in practice): arch/x86/kernel/smpboot.o: warning: objtool:

warning: objtool: ...: call without frame pointer save/setup; return with modified stack frame

Today I coticed the following objtool warnings when compiling 4.13-rc5+git for my Atom 330 PC: call without frame pointer save/setup return with modified stack frame Examples (there is a lot more of them in practice): arch/x86/kernel/smpboot.o: warning: objtool:

Re: [RFT PATCH] [media] partial revert of "[media] tvp5150: add HW input connectors support"

Hi, On Tue, 2016-12-13 at 12:39 -0300, Javier Martinez Canillas wrote: > Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support") > added input signals support for the tvp5150, but the approach was found > to be incorrect so the corresponding DT binding commit 82c2ffeb217a >

Re: [RFT PATCH] [media] partial revert of "[media] tvp5150: add HW input connectors support"

Hi, On Tue, 2016-12-13 at 12:39 -0300, Javier Martinez Canillas wrote: > Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support") > added input signals support for the tvp5150, but the approach was found > to be incorrect so the corresponding DT binding commit 82c2ffeb217a >

Re: [PATCH] mtd: physmap_of: Fix resources leak in 'of_flash_probe()'

Le Sun, 6 Aug 2017 14:55:01 +0200, Christophe JAILLET a écrit : > If 'of_flash_probe_gemini()' or 'of_flash_probe_versatile()' fail, we must > reslease some resources, as already done in all error handling paths in > this function. Applied to l2-mtd/master.

Re: [PATCH] mtd: physmap_of: Fix resources leak in 'of_flash_probe()'

Le Sun, 6 Aug 2017 14:55:01 +0200, Christophe JAILLET a écrit : > If 'of_flash_probe_gemini()' or 'of_flash_probe_versatile()' fail, we must > reslease some resources, as already done in all error handling paths in > this function. Applied to l2-mtd/master. Thanks, Boris > > Signed-off-by:

Re: [PATCH v9 2/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 08/14/17 at 10:54pm, Baoquan He wrote: > Currently KASLR will parse all e820 entries of RAM type and add all > candidate position into slots array. Then we will choose one slot > randomly as the new position which kernel will be decompressed into > and run at. > > On system with EFI enabled,

Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries

On 08/17/2017 12:00 AM, Wangkai (Kevin,C) wrote: > >>> >>> Hi Longman, >>> I am a fresher of fsdevel, about 2 weeks before, I have joined this >>> mail list, recently I have met the same problem of negative dentries, >>> in my opinion, the dentries should be remove together with the files or >>

Re: [PATCH v9 2/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 08/14/17 at 10:54pm, Baoquan He wrote: > Currently KASLR will parse all e820 entries of RAM type and add all > candidate position into slots array. Then we will choose one slot > randomly as the new position which kernel will be decompressed into > and run at. > > On system with EFI enabled,

Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries

On 08/17/2017 12:00 AM, Wangkai (Kevin,C) wrote: > >>> >>> Hi Longman, >>> I am a fresher of fsdevel, about 2 weeks before, I have joined this >>> mail list, recently I have met the same problem of negative dentries, >>> in my opinion, the dentries should be remove together with the files or >>

[PATCH 04/13] iommu/dma: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 04/13] iommu/dma: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

Re: [PATCH 0/6] constify mtd pci_device_id

Le Thu, 3 Aug 2017 21:52:04 +0530, Arvind Yadav a écrit : > pci_device_id are not supposed to change at runtime. All functions > working with pci_device_id provided by work with > const pci_device_id. So mark the non-const structs as const. Applied the whole series

Re: [PATCH 0/6] constify mtd pci_device_id

Le Thu, 3 Aug 2017 21:52:04 +0530, Arvind Yadav a écrit : > pci_device_id are not supposed to change at runtime. All functions > working with pci_device_id provided by work with > const pci_device_id. So mark the non-const structs as const. Applied the whole series to l2-mtd/master. Thanks,

[PATCH 02/13] iommu: Introduce Interface for IOMMU TLB Flushing

From: Joerg Roedel With the current IOMMU-API the hardware TLBs have to be flushed in every iommu_map(), iommu_map_sg(), and iommu_unmap() call. For unmapping large amounts of address space, like it happens when a KVM domain with assigned devices is destroyed, this causes

[PATCH 02/13] iommu: Introduce Interface for IOMMU TLB Flushing

From: Joerg Roedel With the current IOMMU-API the hardware TLBs have to be flushed in every iommu_map(), iommu_map_sg(), and iommu_unmap() call. For unmapping large amounts of address space, like it happens when a KVM domain with assigned devices is destroyed, this causes thousands of

[PATCH 1/2] hwmon: (ltq-cputemp) add cpu temp sensor for xrx200

Add the lantiq cpu temperature sensor support for xrx200. Signed-off-by: Florian Eckert --- drivers/hwmon/Kconfig | 8 +++ drivers/hwmon/Makefile | 1 + drivers/hwmon/ltq-cputemp.c | 155 3 files changed, 164

[PATCH 1/2] hwmon: (ltq-cputemp) add cpu temp sensor for xrx200

Add the lantiq cpu temperature sensor support for xrx200. Signed-off-by: Florian Eckert --- drivers/hwmon/Kconfig | 8 +++ drivers/hwmon/Makefile | 1 + drivers/hwmon/ltq-cputemp.c | 155 3 files changed, 164 insertions(+) create mode

[PATCH 2/2] hwmon: (ltq-cputemp) add devicetree bindings documentation

Document the devicetree bindings for the ltq-cputemp Signed-off-by: Florian Eckert --- Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt diff

[PATCH 2/2] hwmon: (ltq-cputemp) add devicetree bindings documentation

Document the devicetree bindings for the ltq-cputemp Signed-off-by: Florian Eckert --- Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt diff --git

Re: [Nouveau] [PATCH] drm/nouveau: remove redundant null check on array mstm->msto

On 17/08/17 13:21, Emil Velikov wrote: > On 17 August 2017 at 11:37, Colin King wrote: >> From: Colin Ian King >> >> The check to see if mstm->msto is null is redundant because it is >> an array and hence can never be null. Remove the

Re: [Nouveau] [PATCH] drm/nouveau: remove redundant null check on array mstm->msto

On 17/08/17 13:21, Emil Velikov wrote: > On 17 August 2017 at 11:37, Colin King wrote: >> From: Colin Ian King >> >> The check to see if mstm->msto is null is redundant because it is >> an array and hence can never be null. Remove the redundant check. >> >> Detected by CoverityScan, CID#1375915

Re: [PATCHSET for-4.14] cgroup, sched: cgroup2 basic resource accounting

Hello, Ingo. On Thu, Aug 17, 2017 at 10:13:04AM +0200, Ingo Molnar wrote: > Please hold off on applying it before PeterZ gets back from vacation and has > had a > chance to review it. Of course. These aren't going anywhere without Peter's explicit acks. Thanks. -- tejun

Re: [PATCHSET for-4.14] cgroup, sched: cgroup2 basic resource accounting

Hello, Ingo. On Thu, Aug 17, 2017 at 10:13:04AM +0200, Ingo Molnar wrote: > Please hold off on applying it before PeterZ gets back from vacation and has > had a > chance to review it. Of course. These aren't going anywhere without Peter's explicit acks. Thanks. -- tejun

[PATCH 03/13] vfio/type1: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 03/13] vfio/type1: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

Re: [PATCH] [RESEND] mtd: only use __xipram annotation when XIP_KERNEL is set

Le Fri, 4 Aug 2017 11:00:05 +0200, Arnd Bergmann a écrit : > On Fri, Aug 4, 2017 at 9:35 AM, Boris Brezillon > wrote: > > On Fri, 21 Jul 2017 22:26:25 +0200 > > Arnd Bergmann wrote: > > >> Note that MTD_XIP has been broken on

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

On Thu, Aug 17, 2017 at 12:51:33PM +0200, Danilo Krummrich wrote: > That having the correct execution order is not enough on some buses because > of buffering is really something to be aware of, thanks again for pointing > this out. PCI guarantees the order of writes to a device, but there are

Re: [PATCH] [RESEND] mtd: only use __xipram annotation when XIP_KERNEL is set

Le Fri, 4 Aug 2017 11:00:05 +0200, Arnd Bergmann a écrit : > On Fri, Aug 4, 2017 at 9:35 AM, Boris Brezillon > wrote: > > On Fri, 21 Jul 2017 22:26:25 +0200 > > Arnd Bergmann wrote: > > >> Note that MTD_XIP has been broken on ARM since around 2011 or 2012. I > >> have sent another patch[2]

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

On Thu, Aug 17, 2017 at 12:51:33PM +0200, Danilo Krummrich wrote: > That having the correct execution order is not enough on some buses because > of buffering is really something to be aware of, thanks again for pointing > this out. PCI guarantees the order of writes to a device, but there are

[PATCH 00/13] Introduce IOMMU-API TLB Flushing Interface

Hi, here is a patch-set to introduce an explicit interface to the IOMMU-API to flush IOMMU and device IO/TLBs. Currently the iommu_map(), iommu_map_sg(), and iommu_unmap() functions have to make sure all IO/TLBs in the system are synchronized with the page-table updates they made. This is very

[PATCH 00/13] Introduce IOMMU-API TLB Flushing Interface

Hi, here is a patch-set to introduce an explicit interface to the IOMMU-API to flush IOMMU and device IO/TLBs. Currently the iommu_map(), iommu_map_sg(), and iommu_unmap() functions have to make sure all IO/TLBs in the system are synchronized with the page-table updates they made. This is very

[PATCH 05/13] arm: dma-mapping: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 05/13] arm: dma-mapping: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset

On Thu, 17 Aug 2017 10:14:23 +0200 Jan Glauber wrote: > If a PCI device supports neither function-level reset, nor slot > or bus reset then refuse to probe it. A line is printed to inform > the user. But that's not what this does, this requires that the device is on a

Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset

On Thu, 17 Aug 2017 10:14:23 +0200 Jan Glauber wrote: > If a PCI device supports neither function-level reset, nor slot > or bus reset then refuse to probe it. A line is printed to inform > the user. But that's not what this does, this requires that the device is on a reset-able bus. This is a

Re: [PATCH] mtd: Convert to using %pOF instead of full_name

Le Tue, 18 Jul 2017 16:43:17 -0500, Rob Herring a écrit : > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. Applied to l2-mtd/master. Thanks,

Re: [PATCH] mtd: Convert to using %pOF instead of full_name

Le Tue, 18 Jul 2017 16:43:17 -0500, Rob Herring a écrit : > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. Applied to l2-mtd/master. Thanks, Boris > >

Re: [PATCH V6 21/21] net-next/hinic: Add netpoll

Will be fixed in V7 Thanks On 8/17/2017 3:57 PM, Sergei Shtylyov wrote: > Hello. > > On 08/17/2017 03:25 PM, Aviad Krawczyk wrote: > >> Add more netdev operation - netpoll. >> >> Signed-off-by: Aviad Krawczyk >> Signed-off-by: Zhao Chen >> ---

Re: [PATCH V6 21/21] net-next/hinic: Add netpoll

Will be fixed in V7 Thanks On 8/17/2017 3:57 PM, Sergei Shtylyov wrote: > Hello. > > On 08/17/2017 03:25 PM, Aviad Krawczyk wrote: > >> Add more netdev operation - netpoll. >> >> Signed-off-by: Aviad Krawczyk >> Signed-off-by: Zhao Chen >> --- >> MAINTAINERS

[PATCH 06/13] drm/etnaviv: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 06/13] drm/etnaviv: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

Re: [PATCH 03/11] mtd: physmap_of: Drop unnecessary static

Le Sat, 15 Jul 2017 22:07:38 +0200, Julia Lawall a écrit : > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. > > The semantic patch that fixes this problem is as follows: >

[PATCH 11/13] gpu: host1x: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH v2] staging: pi433: replace INVALID_PARAM macro with inline code

The following macro: \#define INVALID_PARAM { \ dev_dbg(>dev, "set: illegal input param"); \ return -EINVAL; \ } affects control flow by having return statement. This is against Linux Kernel Coding Style and should be avoided and therefore this macro

Re: [PATCH 03/11] mtd: physmap_of: Drop unnecessary static

Le Sat, 15 Jul 2017 22:07:38 +0200, Julia Lawall a écrit : > Drop static on a local variable, when the variable is initialized before > any possible use. Thus, the static has no benefit. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // >

[PATCH 11/13] gpu: host1x: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

[PATCH v2] staging: pi433: replace INVALID_PARAM macro with inline code

The following macro: \#define INVALID_PARAM { \ dev_dbg(>dev, "set: illegal input param"); \ return -EINVAL; \ } affects control flow by having return statement. This is against Linux Kernel Coding Style and should be avoided and therefore this macro

[PATCH 08/13] drm/nouveau/imem/gk20a: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 08/13] drm/nouveau/imem/gk20a: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

[PATCH 01/13] iommu/amd: Rename a few flush functions

From: Joerg Roedel Rename a few iommu cache-flush functions that start with iommu_ to start with amd_iommu now. This is to prevent name collisions with generic iommu code later on. Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu.c | 16

[PATCH 01/13] iommu/amd: Rename a few flush functions

From: Joerg Roedel Rename a few iommu cache-flush functions that start with iommu_ to start with amd_iommu now. This is to prevent name collisions with generic iommu code later on. Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu.c | 16 1 file changed, 8

[PATCH 10/13] drm/tegra: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 10/13] drm/tegra: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

Re: [PATCH] mtd: spear_smi: add NULL check on devm_kzalloc() return value

Le Thu, 6 Jul 2017 17:25:50 -0500, "Gustavo A. R. Silva" a écrit : > Check return value from call to devm_kzalloc() > in order to prevent a NULL pointer dereference. > > This issue was detected using Coccinelle and the following semantic patch: > > @@ > expression x; >

[PATCH 13/13] remoteproc: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

Re: [PATCH] mtd: spear_smi: add NULL check on devm_kzalloc() return value

Le Thu, 6 Jul 2017 17:25:50 -0500, "Gustavo A. R. Silva" a écrit : > Check return value from call to devm_kzalloc() > in order to prevent a NULL pointer dereference. > > This issue was detected using Coccinelle and the following semantic patch: > > @@ > expression x; > identifier fld; > @@ >

[PATCH 13/13] remoteproc: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

[PATCH 12/13] IB/usnic: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 12/13] IB/usnic: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

Re: [PATCH V6 21/21] net-next/hinic: Add netpoll

Hello. On 08/17/2017 03:25 PM, Aviad Krawczyk wrote: Add more netdev operation - netpoll. Signed-off-by: Aviad Krawczyk Signed-off-by: Zhao Chen --- MAINTAINERS| 7 +++

Re: [PATCH V6 21/21] net-next/hinic: Add netpoll

Hello. On 08/17/2017 03:25 PM, Aviad Krawczyk wrote: Add more netdev operation - netpoll. Signed-off-by: Aviad Krawczyk Signed-off-by: Zhao Chen --- MAINTAINERS| 7 +++ drivers/net/ethernet/huawei/hinic/hinic_main.c | 20 2

[PATCH 09/13] drm/rockchip: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 09/13] drm/rockchip: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

[PATCH 07/13] drm/msm: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which

[PATCH 07/13] drm/msm: Use sychronized interface of the IOMMU-API

From: Joerg Roedel The map and unmap functions of the IOMMU-API changed their semantics: They do no longer guarantee that the hardware TLBs are synchronized with the page-table updates they made. To make conversion easier, new synchronized functions have been introduced which give these

Re: [PATCH] staginig: pi433: replace INVALID_PARAM macro with inline code

There is a typo in patch subject. Please drop this patch. I will send v2 with corrected subject. Thanks, Marcin

Re: [PATCH] staginig: pi433: replace INVALID_PARAM macro with inline code

There is a typo in patch subject. Please drop this patch. I will send v2 with corrected subject. Thanks, Marcin

Re: [tip:locking/core 36/40] arch/x86/include/asm/refcount.h:21:2: error: expected ':' or ')' before 'ASM_UNREACHABLE'

On Thu, Aug 17, 2017 at 06:33:35PM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking/core > head: 52fa5bc5cbba089f09bc2c372e3432f3f3e48051 > commit: 7a46ec0e2f4850407de5e1d19a44edee6efa58ec [36/40] locking/refcounts, > x86/asm:

Re: [tip:locking/core 36/40] arch/x86/include/asm/refcount.h:21:2: error: expected ':' or ')' before 'ASM_UNREACHABLE'

On Thu, Aug 17, 2017 at 06:33:35PM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking/core > head: 52fa5bc5cbba089f09bc2c372e3432f3f3e48051 > commit: 7a46ec0e2f4850407de5e1d19a44edee6efa58ec [36/40] locking/refcounts, > x86/asm:

Re: [PATCH v2 1/5] KVM: x86: Add return value to kvm_cpuid().

On 8/17/2017 8:23 PM, Yu Zhang wrote: On 8/17/2017 8:29 PM, Paolo Bonzini wrote: On 17/08/2017 21:52, Yu Zhang wrote: diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h index ac15193..3e759cf 100644 --- a/arch/x86/kvm/cpuid.h +++ b/arch/x86/kvm/cpuid.h @@ -21,7 +21,14 @@ int

Re: [PATCH v2 1/5] KVM: x86: Add return value to kvm_cpuid().

On 8/17/2017 8:23 PM, Yu Zhang wrote: On 8/17/2017 8:29 PM, Paolo Bonzini wrote: On 17/08/2017 21:52, Yu Zhang wrote: diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h index ac15193..3e759cf 100644 --- a/arch/x86/kvm/cpuid.h +++ b/arch/x86/kvm/cpuid.h @@ -21,7 +21,14 @@ int

Re: [PATCH] powerpc: powernv: Fix build error on const discarding

Corentin Labbe writes: > When building a random powerpc kernel I hit this build error: > CC arch/powerpc/platforms/powernv/opal-imc.o > arch/powerpc/platforms/powernv/opal-imc.c: In function «  > disable_nest_pmu_counters »: >

Re: [PATCH] powerpc: powernv: Fix build error on const discarding

Corentin Labbe writes: > When building a random powerpc kernel I hit this build error: > CC arch/powerpc/platforms/powernv/opal-imc.o > arch/powerpc/platforms/powernv/opal-imc.c: In function «  > disable_nest_pmu_counters »: > arch/powerpc/platforms/powernv/opal-imc.c:130:13: error :

[PATCH] drivers: spi: Kernel coding style fixes

s - fix warnings, suspect code indent for conditional statements - fix errors, code indent should use tabs - remove spaces at the start of the line Signed-off-by: Suniel Mahesh <suni...@techveda.org> --- Note: - Patch was compile tested and built(ARCH=arm) on next-20170817. - No build/ru

Re: [PATCH v5 tip/core/rcu 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair

* Paul E. McKenney wrote: > > this change - or can I pick this up into the scheduler tree? > > Timely question! ;-) > > My current plan is to send you a pull request like the following later > today, Pacific Time (but rebased adding Steve Rostedt's Reviewed-by). >

[PATCH] drivers: spi: Kernel coding style fixes

ode indent for conditional statements - fix errors, code indent should use tabs - remove spaces at the start of the line Signed-off-by: Suniel Mahesh --- Note: - Patch was compile tested and built(ARCH=arm) on next-20170817. - No build/run-time issues reported. --- drivers/spi/

Re: [PATCH v5 tip/core/rcu 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair

* Paul E. McKenney wrote: > > this change - or can I pick this up into the scheduler tree? > > Timely question! ;-) > > My current plan is to send you a pull request like the following later > today, Pacific Time (but rebased adding Steve Rostedt's Reviewed-by). > This patch is on one of the

Re: [PATCH v2 2/5] KVM: MMU: check guest CR3 reserved bits based on its physical address width.

On 8/17/2017 8:31 PM, Paolo Bonzini wrote: On 17/08/2017 21:52, Yu Zhang wrote: + if (efer & EFER_LMA) { + u64 maxphyaddr; + u32 eax = 0x8008; + + if (ctxt->ops->get_cpuid(ctxt, , NULL, NULL, NULL, +

Re: [PATCH v2 2/5] KVM: MMU: check guest CR3 reserved bits based on its physical address width.

On 8/17/2017 8:31 PM, Paolo Bonzini wrote: On 17/08/2017 21:52, Yu Zhang wrote: + if (efer & EFER_LMA) { + u64 maxphyaddr; + u32 eax = 0x8008; + + if (ctxt->ops->get_cpuid(ctxt, , NULL, NULL, NULL, +

Re: [PATCH V4 net-next 21/21] net-next/hinic: Add select_queue and netpoll

Hi David, Fixed in V6. In V5 patch-set there was a problem in cover-letter msg-id. Thanks, Aviad On 8/16/2017 9:47 PM, David Miller wrote: > From: Aviad Krawczyk > Date: Wed, 16 Aug 2017 20:03:06 +0800 > >> +static u16 hinic_select_queue(struct net_device *netdev,

Re: [PATCH V4 net-next 21/21] net-next/hinic: Add select_queue and netpoll

Hi David, Fixed in V6. In V5 patch-set there was a problem in cover-letter msg-id. Thanks, Aviad On 8/16/2017 9:47 PM, David Miller wrote: > From: Aviad Krawczyk > Date: Wed, 16 Aug 2017 20:03:06 +0800 > >> +static u16 hinic_select_queue(struct net_device *netdev, struct sk_buff >> *skb, >>

Re: [V6,3/9] irqdomain: Don't set type when mapping an IRQ

Hi guys, I hit an problem when testing a level triggered irq with: irq = platform_get_irq_byname(pdev, "wake"); ...<-- irq trigger type is correct irq_set_status_flags(irq, IRQ_NOAUTOEN); ...<-- irq trigger type become zero request_threaded_irq(irq, ...) the trigger type

Re: [V6,3/9] irqdomain: Don't set type when mapping an IRQ

Hi guys, I hit an problem when testing a level triggered irq with: irq = platform_get_irq_byname(pdev, "wake"); ...<-- irq trigger type is correct irq_set_status_flags(irq, IRQ_NOAUTOEN); ...<-- irq trigger type become zero request_threaded_irq(irq, ...) the trigger type

Re: [PATCH v2 1/5] KVM: x86: Add return value to kvm_cpuid().

On 8/17/2017 8:29 PM, Paolo Bonzini wrote: On 17/08/2017 21:52, Yu Zhang wrote: diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h index ac15193..3e759cf 100644 --- a/arch/x86/kvm/cpuid.h +++ b/arch/x86/kvm/cpuid.h @@ -21,7 +21,14 @@ int kvm_vcpu_ioctl_set_cpuid2(struct kvm_vcpu *vcpu,

Re: [PATCH v2 1/5] KVM: x86: Add return value to kvm_cpuid().

On 8/17/2017 8:29 PM, Paolo Bonzini wrote: On 17/08/2017 21:52, Yu Zhang wrote: diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h index ac15193..3e759cf 100644 --- a/arch/x86/kvm/cpuid.h +++ b/arch/x86/kvm/cpuid.h @@ -21,7 +21,14 @@ int kvm_vcpu_ioctl_set_cpuid2(struct kvm_vcpu *vcpu,

<    8   9   10   11   12   13   14   15   16   17   >