Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY

On Fri, Aug 11, 2017 at 08:03:29AM -0700, Florian Fainelli wrote: > On August 11, 2017 6:25:26 AM PDT, Corentin Labbe > wrote: > >On Fri, Aug 11, 2017 at 04:22:11PM +0800, Chen-Yu Tsai wrote: > >> On Fri, Aug 11, 2017 at 4:19 PM, Corentin Labbe > >>

Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY

On Fri, Aug 11, 2017 at 08:03:29AM -0700, Florian Fainelli wrote: > On August 11, 2017 6:25:26 AM PDT, Corentin Labbe > wrote: > >On Fri, Aug 11, 2017 at 04:22:11PM +0800, Chen-Yu Tsai wrote: > >> On Fri, Aug 11, 2017 at 4:19 PM, Corentin Labbe > >> wrote: > >> > On Fri, Aug 11, 2017 at

Re: [PATCH v2 1/3] dt-bindings: i2c: Document the POWER system power supply device

On Thu, Aug 10, 2017 at 05:19:44PM -0500, Eddie James wrote: > From: "Edward A. James" > > Signed-off-by: Edward A. James > --- > .../devicetree/bindings/i2c/ibm,power-ps.txt| 21 > + > 1 file changed, 21 insertions(+) >

Re: [PATCH v2 1/3] dt-bindings: i2c: Document the POWER system power supply device

On Thu, Aug 10, 2017 at 05:19:44PM -0500, Eddie James wrote: > From: "Edward A. James" > > Signed-off-by: Edward A. James > --- > .../devicetree/bindings/i2c/ibm,power-ps.txt| 21 > + > 1 file changed, 21 insertions(+) > create mode 100644

Re: [PATCH v4 2/4] dt-bindings: can: can-transceiver: Document new binding

On Wed, Aug 09, 2017 at 07:59:14PM -0500, Franklin S Cooper Jr wrote: > Add documentation to describe usage of the new can-transceiver binding. > This new binding is applicable for any CAN device therefore it exists as > its own document. > > Signed-off-by: Franklin S Cooper Jr >

Re: [PATCH v4 2/4] dt-bindings: can: can-transceiver: Document new binding

On Wed, Aug 09, 2017 at 07:59:14PM -0500, Franklin S Cooper Jr wrote: > Add documentation to describe usage of the new can-transceiver binding. > This new binding is applicable for any CAN device therefore it exists as > its own document. > > Signed-off-by: Franklin S Cooper Jr > --- > Version 4

Re: [PATCH] ARM: imx_v6_v7_defconfig: Add CONFIG_FW_LOADER_USER_HELPER_FALLBACK

Hi Gary, On Thu, Aug 17, 2017 at 11:04 AM, Gary Bisson wrote: > Allows to load firmware files which aren't built inside the kernel. > > Especially useful for CODA firmware (vpu_fw_imx6q.bin) which is usually > located in the rootfs. > > Signed-off-by: Gary Bisson

Re: [PATCH] ARM: imx_v6_v7_defconfig: Add CONFIG_FW_LOADER_USER_HELPER_FALLBACK

Hi Gary, On Thu, Aug 17, 2017 at 11:04 AM, Gary Bisson wrote: > Allows to load firmware files which aren't built inside the kernel. > > Especially useful for CODA firmware (vpu_fw_imx6q.bin) which is usually > located in the rootfs. > > Signed-off-by: Gary Bisson > --- > Hi Shawn, > > I'm not

Re: [PATCH 1/3] Documentation: dt: iio: at91-sama5d2_adc: add optional dma property

On Thu, Aug 10, 2017 at 03:34:57PM +0300, Eugen Hristev wrote: > Added property for DMA configuration of the device. "dt-bindings: iio: ..." is preferred for subject. > > Signed-off-by: Eugen Hristev > --- >

Re: [PATCH 1/3] Documentation: dt: iio: at91-sama5d2_adc: add optional dma property

On Thu, Aug 10, 2017 at 03:34:57PM +0300, Eugen Hristev wrote: > Added property for DMA configuration of the device. "dt-bindings: iio: ..." is preferred for subject. > > Signed-off-by: Eugen Hristev > --- > Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt | 7 +++ > 1 file

Re: [PATCH v4 06/12] net: stmmac: dwmac-rk: Add internal phy support

On Wed, Aug 09, 2017 at 08:11:01PM +0800, David Wu wrote: > To make internal phy work, need to configure the phy_clock, > phy cru_reset and related registers. > > Signed-off-by: David Wu > --- > change in v4: > - PHY is internal or not base on the phy-is-internal

Re: [PATCH v4 06/12] net: stmmac: dwmac-rk: Add internal phy support

On Wed, Aug 09, 2017 at 08:11:01PM +0800, David Wu wrote: > To make internal phy work, need to configure the phy_clock, > phy cru_reset and related registers. > > Signed-off-by: David Wu > --- > change in v4: > - PHY is internal or not base on the phy-is-internal property via phy node. > >

Re: [PATCH v5 5/6] dt-bindings: Document devicetree binding for ARM DSU PMU

On Tue, Aug 08, 2017 at 12:37:25PM +0100, Suzuki K Poulose wrote: > This patch documents the devicetree bindings for ARM DSU PMU. > > Cc: Mark Rutland > Cc: Will Deacon > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Cc:

Re: [PATCH v5 5/6] dt-bindings: Document devicetree binding for ARM DSU PMU

On Tue, Aug 08, 2017 at 12:37:25PM +0100, Suzuki K Poulose wrote: > This patch documents the devicetree bindings for ARM DSU PMU. > > Cc: Mark Rutland > Cc: Will Deacon > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Cc: frowand.l...@gmail.com > Signed-off-by: Suzuki K Poulose > --- >

Re: refactoring timers to avoid init_timer*()

On Thu, Aug 17, 2017 at 7:40 AM, Christoph Hellwig wrote: > Instea of bloating the timer even more we should kill off > the data field eventually, which should give you the same > protection. > > See my proposal and the related discussion here: > >

Re: refactoring timers to avoid init_timer*()

On Thu, Aug 17, 2017 at 7:40 AM, Christoph Hellwig wrote: > Instea of bloating the timer even more we should kill off > the data field eventually, which should give you the same > protection. > > See my proposal and the related discussion here: > >

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

On Wed, Aug 16, 2017 at 11:22:35AM -0400, Steven Rostedt wrote: > On Tue, 15 Aug 2017 09:16:29 -0700 > "Paul E. McKenney" wrote: > > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > and it appears that all callers could do just as well with

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

On Wed, Aug 16, 2017 at 11:22:35AM -0400, Steven Rostedt wrote: > On Tue, 15 Aug 2017 09:16:29 -0700 > "Paul E. McKenney" wrote: > > > There is no agreed-upon definition of spin_unlock_wait()'s semantics, > > and it appears that all callers could do just as well with a lock/unlock > > pair.

Re: [PATCH -tip v2 0/2] kprobes/x86: RO text code bugfix and cleanup

On Thu, 17 Aug 2017 11:55:30 +0200 Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > > > Hi, > > > > This series fixes a kprobe-x86 bug related to RO text and > > cleans up addressof operators. > > > > The first one is an obvious bug that misses to

Re: [PATCH -tip v2 0/2] kprobes/x86: RO text code bugfix and cleanup

On Thu, 17 Aug 2017 11:55:30 +0200 Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > > > Hi, > > > > This series fixes a kprobe-x86 bug related to RO text and > > cleans up addressof operators. > > > > The first one is an obvious bug that misses to set memory > > RO when the function

Re: [PATCH v4 7/7] ima: Support module-style appended signatures for appraisal

On Fri, 2017-08-04 at 19:03 -0300, Thiago Jung Bauermann wrote: > This patch introduces the modsig keyword to the IMA policy syntax to > specify that a given hook should expect the file to have the IMA signature > appended to it. Here is how it can be used in a rule: > > appraise

Re: [PATCH v4 7/7] ima: Support module-style appended signatures for appraisal

On Fri, 2017-08-04 at 19:03 -0300, Thiago Jung Bauermann wrote: > This patch introduces the modsig keyword to the IMA policy syntax to > specify that a given hook should expect the file to have the IMA signature > appended to it. Here is how it can be used in a rule: > > appraise

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

* Tejun Heo wrote: > 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

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

* Tejun Heo wrote: > 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.

Re: [PATCH] ARM: dts: imx6qdl-nitrogen6_som2: fix PCIe reset

On Thu, Aug 17, 2017 at 03:50:10PM +0200, Gary Bisson wrote: > Previous value was a bad copy of nitrogen6_max device tree. > > Signed-off-by: Gary Bisson > --- > arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2

Re: [PATCH] ARM: dts: imx6qdl-nitrogen6_som2: fix PCIe reset

On Thu, Aug 17, 2017 at 03:50:10PM +0200, Gary Bisson wrote: > Previous value was a bad copy of nitrogen6_max device tree. > > Signed-off-by: Gary Bisson > --- > arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This is not the correct

Re: [PATCH v3] pinctrl: aspeed: Fix ast2500 strap register write logic

Thanks Andrew for your thoughtful input. Let me send out another version :) 2017-08-16 20:19 GMT-07:00 Andrew Jeffery : > Hi Yong, > > On Wed, 2017-08-16 at 08:05 -0700, Yong Li wrote: >> Hi Andrew, >> >> Thanks for your review. I checked the patch before I sent out, but the >>

Re: [PATCH v3] pinctrl: aspeed: Fix ast2500 strap register write logic

Thanks Andrew for your thoughtful input. Let me send out another version :) 2017-08-16 20:19 GMT-07:00 Andrew Jeffery : > Hi Yong, > > On Wed, 2017-08-16 at 08:05 -0700, Yong Li wrote: >> Hi Andrew, >> >> Thanks for your review. I checked the patch before I sent out, but the >> tool did not

Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array

2017-08-17 09:04+0200, Alexander Graf: > On 16.08.17 21:40, Radim Krčmář wrote: > > The goal is to increase KVM_MAX_VCPUS without worrying about memory > > impact of many small guests. > > > > This is a second out of three major "dynamic" options: > > 1) size vcpu array at VM creation time > >

Re: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array

2017-08-17 09:04+0200, Alexander Graf: > On 16.08.17 21:40, Radim Krčmář wrote: > > The goal is to increase KVM_MAX_VCPUS without worrying about memory > > impact of many small guests. > > > > This is a second out of three major "dynamic" options: > > 1) size vcpu array at VM creation time > >

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

On Thu, 17 Aug 2017 16:43:08 +0200 Joerg Roedel wrote: > Hi Alex, > > On Thu, Aug 17, 2017 at 08:35:20AM -0600, Alex Williamson wrote: > > Wouldn't it be much more friendly to downstreams and out-of-tree > > drivers to introduce new functions for the async semantics? ie. > >

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

On Thu, 17 Aug 2017 16:43:08 +0200 Joerg Roedel wrote: > Hi Alex, > > On Thu, Aug 17, 2017 at 08:35:20AM -0600, Alex Williamson wrote: > > Wouldn't it be much more friendly to downstreams and out-of-tree > > drivers to introduce new functions for the async semantics? ie. > > iommu_map_async(),

Re: [PATCH v5 6/6] perf: ARM DynamIQ Shared Unit PMU support

Hi Mark, On 16/08/17 15:10, Mark Rutland wrote: On Tue, Aug 08, 2017 at 12:37:26PM +0100, Suzuki K Poulose wrote: +/* + * struct dsu_pmu - DSU PMU descriptor + * + * @pmu_lock : Protects accesses to DSU PMU register from multiple + * CPUs. + * @hw_events

Re: [PATCH v5 6/6] perf: ARM DynamIQ Shared Unit PMU support

Hi Mark, On 16/08/17 15:10, Mark Rutland wrote: On Tue, Aug 08, 2017 at 12:37:26PM +0100, Suzuki K Poulose wrote: +/* + * struct dsu_pmu - DSU PMU descriptor + * + * @pmu_lock : Protects accesses to DSU PMU register from multiple + * CPUs. + * @hw_events

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

> On Wed, Aug 16, 2017 at 09:39:08PM +0300, Meelis Roos wrote: > > > > > I noticed that in 4.13.0-rc4 there is a new error in dmesg on my > > > > > sparc64 > > > > > t5120 server: can't allocate MSI-X affinity masks. > > > > > > > > > > [ 30.274284] qla2xxx [:00:00.0]-0005: : QLogic Fibre

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

> On Wed, Aug 16, 2017 at 09:39:08PM +0300, Meelis Roos wrote: > > > > > I noticed that in 4.13.0-rc4 there is a new error in dmesg on my > > > > > sparc64 > > > > > t5120 server: can't allocate MSI-X affinity masks. > > > > > > > > > > [ 30.274284] qla2xxx [:00:00.0]-0005: : QLogic Fibre

Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs

Hi, On 07/17/2017 02:18 PM, Smitha T Murthy wrote: > On Fri, 2017-07-07 at 17:59 +0300, Stanimir Varbanov wrote: >> Hi, >> >> On 06/19/2017 08:10 AM, Smitha T Murthy wrote: >>> Added V4l2 controls for HEVC encoder >>> >>> Signed-off-by: Smitha T Murthy >>> --- >>>

Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs

Hi, On 07/17/2017 02:18 PM, Smitha T Murthy wrote: > On Fri, 2017-07-07 at 17:59 +0300, Stanimir Varbanov wrote: >> Hi, >> >> On 06/19/2017 08:10 AM, Smitha T Murthy wrote: >>> Added V4l2 controls for HEVC encoder >>> >>> Signed-off-by: Smitha T Murthy >>> --- >>>

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

Hi Alex, On Thu, Aug 17, 2017 at 08:35:20AM -0600, Alex Williamson wrote: > Wouldn't it be much more friendly to downstreams and out-of-tree > drivers to introduce new functions for the async semantics? ie. > iommu_map_async(), etc. The API also seems a little cleaner that > iommu_map() stands

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

Hi Alex, On Thu, Aug 17, 2017 at 08:35:20AM -0600, Alex Williamson wrote: > Wouldn't it be much more friendly to downstreams and out-of-tree > drivers to introduce new functions for the async semantics? ie. > iommu_map_async(), etc. The API also seems a little cleaner that > iommu_map() stands

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

Hi Marc, Thanks for your reply. On 08/17/2017 09:34 PM, Marc Zyngier wrote: On 17/08/17 13:46, jeffy wrote: 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,

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

Hi Marc, Thanks for your reply. On 08/17/2017 09:34 PM, Marc Zyngier wrote: On 17/08/17 13:46, jeffy wrote: 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,

Re: [PATCH] iio: accel: mma8452: Bugfix to enbale and allow different events to work parallely.

On Thu, 17 Aug 2017 07:55:45 -0400 Harinath Nampally wrote: > > This patch fixes by detaching the event related information from > > chip_info struct, > >>> and based on channel type and event direction the corresponding > > event configuration registers > >>> are

Re: [PATCH] iio: accel: mma8452: Bugfix to enbale and allow different events to work parallely.

On Thu, 17 Aug 2017 07:55:45 -0400 Harinath Nampally wrote: > > This patch fixes by detaching the event related information from > > chip_info struct, > >>> and based on channel type and event direction the corresponding > > event configuration registers > >>> are picked dynamically. Hence

Re: refactoring timers to avoid init_timer*()

Instea of bloating the timer even more we should kill off the data field eventually, which should give you the same protection. See my proposal and the related discussion here: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1397209.html

Re: refactoring timers to avoid init_timer*()

Instea of bloating the timer even more we should kill off the data field eventually, which should give you the same protection. See my proposal and the related discussion here: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1397209.html

Re: refactoring timers to avoid init_timer*()

On Thu, Aug 17, 2017 at 7:30 AM, Thomas Gleixner wrote: > On Wed, 16 Aug 2017, Kees Cook wrote: >> In the process I noticed that we already have >> scripts/coccinelle/api/setup_timer.cocci to detect existing cases of: >> >> init_timer(t); >> t->function = func; >> t->data =

Re: refactoring timers to avoid init_timer*()

On Thu, Aug 17, 2017 at 7:30 AM, Thomas Gleixner wrote: > On Wed, 16 Aug 2017, Kees Cook wrote: >> In the process I noticed that we already have >> scripts/coccinelle/api/setup_timer.cocci to detect existing cases of: >> >> init_timer(t); >> t->function = func; >> t->data = data; >> >> And

Re: [PATCH] iio: adc: select triggered buffer for sama5d2 adc

On Tue, 15 Aug 2017 16:46:31 +0200 Arnd Bergmann wrote: > Without the triggered buffer code, we get a link error: > > drivers/iio/adc/at91-sama5d2_adc.o: In function `at91_adc_probe': > at91-sama5d2_adc.c:(.text+0x938): undefined reference to > `devm_iio_triggered_buffer_setup'

RE: [PATCH] Input: elan_i2c - Make hardware buttons work properly on Asus ROG G752xx

-Original Message- From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] Sent: Thursday, August 17, 2017 2:27 AM To: Maxime Bellengé; KT Liao Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] Input: elan_i2c - Make hardware buttons work properly on

Re: [PATCH] iio: adc: select triggered buffer for sama5d2 adc

On Tue, 15 Aug 2017 16:46:31 +0200 Arnd Bergmann wrote: > Without the triggered buffer code, we get a link error: > > drivers/iio/adc/at91-sama5d2_adc.o: In function `at91_adc_probe': > at91-sama5d2_adc.c:(.text+0x938): undefined reference to > `devm_iio_triggered_buffer_setup' > > This adds

RE: [PATCH] Input: elan_i2c - Make hardware buttons work properly on Asus ROG G752xx

-Original Message- From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] Sent: Thursday, August 17, 2017 2:27 AM To: Maxime Bellengé; KT Liao Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] Input: elan_i2c - Make hardware buttons work properly on

Re: [PATCH 0/5] arm-smmu: performance optimization

Thunder, Nate, Robin, On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote: > I described the optimization more detail in patch 1 and 2, and patch 3-5 are > the implementation on arm-smmu/arm-smmu-v3 of patch 2. > > Patch 1 is v2. In v1, I directly replaced writel with writel_relaxed in >

Re: [PATCH 0/5] arm-smmu: performance optimization

Thunder, Nate, Robin, On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote: > I described the optimization more detail in patch 1 and 2, and patch 3-5 are > the implementation on arm-smmu/arm-smmu-v3 of patch 2. > > Patch 1 is v2. In v1, I directly replaced writel with writel_relaxed in >

[PATCH 2/2] lockd: Adjust 61 checks for null pointers

From: Markus Elfring Date: Thu, 17 Aug 2017 16:00:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written … Thus

[PATCH 2/2] lockd: Adjust 61 checks for null pointers

From: Markus Elfring Date: Thu, 17 Aug 2017 16:00:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written … Thus fix the affected source code

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

On Thu, 17 Aug 2017 14:56:23 +0200 Joerg Roedel wrote: > 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

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

On Thu, 17 Aug 2017 14:56:23 +0200 Joerg Roedel wrote: > 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

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

On Thu, Aug 17, 2017 at 04:30:48PM +0200, Lucas Stach wrote: > Yeah, the IOMMU API being used internally is a historical accident, that > we didn't get around to rectify yet. It's on my things-we-need-to-do > list to prune the usage of the IOMMU API in etnaviv. Okay, so for the time being, I drop

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

On Thu, Aug 17, 2017 at 04:30:48PM +0200, Lucas Stach wrote: > Yeah, the IOMMU API being used internally is a historical accident, that > we didn't get around to rectify yet. It's on my things-we-need-to-do > list to prune the usage of the IOMMU API in etnaviv. Okay, so for the time being, I drop

[PATCH 1/2] lockd: Delete an error message for a failed memory allocation in reclaimer()

From: Markus Elfring Date: Wed, 16 Aug 2017 22:35:24 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] lockd: Delete an error message for a failed memory allocation in reclaimer()

From: Markus Elfring Date: Wed, 16 Aug 2017 22:35:24 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- fs/lockd/clntlock.c | 6 +- 1 file changed, 1 insertion(+), 5

Re: [PATCH] KVM: SVM: refactor avic VM ID allocation

On 15/08/2017 22:12, Radim Krčmář wrote: > 2017-08-11 22:11+0200, Denys Vlasenko: >> With lightly tweaked defconfig: >> >> textdata bss dec hex filename >> 11259661 5109408 2981888 19350957 12745ad vmlinux.before >> 11259661 5109408 884736 17253805 10745ad vmlinux.after >> >>

Re: [PATCH] KVM: SVM: refactor avic VM ID allocation

On 15/08/2017 22:12, Radim Krčmář wrote: > 2017-08-11 22:11+0200, Denys Vlasenko: >> With lightly tweaked defconfig: >> >> textdata bss dec hex filename >> 11259661 5109408 2981888 19350957 12745ad vmlinux.before >> 11259661 5109408 884736 17253805 10745ad vmlinux.after >> >>

[PATCH 0/2] lockd: Adjustments for some function implementations

From: Markus Elfring Date: Thu, 17 Aug 2017 16:17:18 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in reclaimer() Adjust 61 checks for null

[PATCH 0/2] lockd: Adjustments for some function implementations

From: Markus Elfring Date: Thu, 17 Aug 2017 16:17:18 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in reclaimer() Adjust 61 checks for null pointers fs/lockd/clnt4xdr.c | 12

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

Am Donnerstag, den 17.08.2017, 16:18 +0200 schrieb Joerg Roedel: > On Thu, Aug 17, 2017 at 04:03:54PM +0200, Lucas Stach wrote: > > There is no IOMMU driver in use. Etnaviv just uses part of the IOMMU API > > to manage the GPU internal MMU, see > > drivers/gpu/drm/etnaviv/etnaviv_iommu.c > > That

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

Am Donnerstag, den 17.08.2017, 16:18 +0200 schrieb Joerg Roedel: > On Thu, Aug 17, 2017 at 04:03:54PM +0200, Lucas Stach wrote: > > There is no IOMMU driver in use. Etnaviv just uses part of the IOMMU API > > to manage the GPU internal MMU, see > > drivers/gpu/drm/etnaviv/etnaviv_iommu.c > > That

Re: refactoring timers to avoid init_timer*()

On Wed, 16 Aug 2017, Kees Cook wrote: > In the process I noticed that we already have > scripts/coccinelle/api/setup_timer.cocci to detect existing cases of: > > init_timer(t); > t->function = func; > t->data = data; > > And replace it with: setup_timer(t, func, data); > > Another pattern was:

Re: refactoring timers to avoid init_timer*()

On Wed, 16 Aug 2017, Kees Cook wrote: > In the process I noticed that we already have > scripts/coccinelle/api/setup_timer.cocci to detect existing cases of: > > init_timer(t); > t->function = func; > t->data = data; > > And replace it with: setup_timer(t, func, data); > > Another pattern was:

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

On 17/08/2017 15:20, Yu Zhang wrote: >> > > OK. And to return 0 for eax/ebx/ecx/edx if check_cpuid_limit() is also > to be omitted, > I'd better refactor this patch and move the "out:" before the if > statement. :-) > > best = check_cpuid_limit(vcpu, function, index); > }

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

On 17/08/2017 15:20, Yu Zhang wrote: >> > > OK. And to return 0 for eax/ebx/ecx/edx if check_cpuid_limit() is also > to be omitted, > I'd better refactor this patch and move the "out:" before the if > statement. :-) > > best = check_cpuid_limit(vcpu, function, index); > }

Re: [PATCH v2 1/5] iio: srf08: add device tree binding for srf02 and srf10

On Mon, 14 Aug 2017 14:37:26 +0200 Wolfram Sang wrote: > On Mon, Aug 14, 2017 at 12:39:18PM +0200, Andreas Klinger wrote: > > Wolfram Sang schrieb am Mon, 14. Aug 11:11: > > > On Mon, Aug 14, 2017 at 10:59:41AM +0200, Andreas Klinger wrote: > > > >

Re: [PATCH v2 1/5] iio: srf08: add device tree binding for srf02 and srf10

On Mon, 14 Aug 2017 14:37:26 +0200 Wolfram Sang wrote: > On Mon, Aug 14, 2017 at 12:39:18PM +0200, Andreas Klinger wrote: > > Wolfram Sang schrieb am Mon, 14. Aug 11:11: > > > On Mon, Aug 14, 2017 at 10:59:41AM +0200, Andreas Klinger wrote: > > > > add trivial device tree binding

Re: [PATCH v1 4/4] KVM: MMU: Expose the LA57 feature to VM.

On 17/08/2017 13:53, Yu Zhang wrote: > > > On 8/17/2017 7:57 PM, Paolo Bonzini wrote: >> On 12/08/2017 15:35, Yu Zhang wrote: >>> index a98b88a..50107ae 100644 >>> --- a/arch/x86/kvm/emulate.c >>> +++ b/arch/x86/kvm/emulate.c >>> @@ -694,7 +694,7 @@ static __always_inline int __linearize(struct

Re: [PATCH v1 4/4] KVM: MMU: Expose the LA57 feature to VM.

On 17/08/2017 13:53, Yu Zhang wrote: > > > On 8/17/2017 7:57 PM, Paolo Bonzini wrote: >> On 12/08/2017 15:35, Yu Zhang wrote: >>> index a98b88a..50107ae 100644 >>> --- a/arch/x86/kvm/emulate.c >>> +++ b/arch/x86/kvm/emulate.c >>> @@ -694,7 +694,7 @@ static __always_inline int __linearize(struct

Re: [PATCH 1/3] sound: ASoC: tegra: Remove SoC-specific Kconfig depends and selects

On Thu, Aug 17, 2017 at 04:22:11PM +0200, Thierry Reding wrote: > do you want to pick this up, or would you rather provide an Acked-by so > that I can take it through the Tegra tree along with the defconfig > changes? I can provide a branch with this patch in case we ever need it > for conflict

Re: [PATCH 1/3] sound: ASoC: tegra: Remove SoC-specific Kconfig depends and selects

On Thu, Aug 17, 2017 at 04:22:11PM +0200, Thierry Reding wrote: > do you want to pick this up, or would you rather provide an Acked-by so > that I can take it through the Tegra tree along with the defconfig > changes? I can provide a branch with this patch in case we ever need it > for conflict

Re: [PATCH 1/3] sound: ASoC: tegra: Remove SoC-specific Kconfig depends and selects

On Mon, Jul 31, 2017 at 12:23:09PM +0200, Thierry Reding wrote: > On Sun, Jul 30, 2017 at 01:22:18PM +0200, Paul Kocialkowski wrote: > > This removes the SoC-specific dependencies on the platform drivers, > > as well as SoC-specific selections of platform drivers for the > > machine drivers. The

Re: [PATCH 1/3] sound: ASoC: tegra: Remove SoC-specific Kconfig depends and selects

On Mon, Jul 31, 2017 at 12:23:09PM +0200, Thierry Reding wrote: > On Sun, Jul 30, 2017 at 01:22:18PM +0200, Paul Kocialkowski wrote: > > This removes the SoC-specific dependencies on the platform drivers, > > as well as SoC-specific selections of platform drivers for the > > machine drivers. The

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

On Thu, Aug 17, 2017 at 04:03:54PM +0200, Lucas Stach wrote: > There is no IOMMU driver in use. Etnaviv just uses part of the IOMMU API > to manage the GPU internal MMU, see > drivers/gpu/drm/etnaviv/etnaviv_iommu.c That looks like a very fragile construct, because it relies on internal behavior

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

On Thu, Aug 17, 2017 at 04:03:54PM +0200, Lucas Stach wrote: > There is no IOMMU driver in use. Etnaviv just uses part of the IOMMU API > to manage the GPU internal MMU, see > drivers/gpu/drm/etnaviv/etnaviv_iommu.c That looks like a very fragile construct, because it relies on internal behavior

RE: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

>-Original Message- >From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >ow...@vger.kernel.org] On Behalf Of Ding Tianhong >Sent: Wednesday, August 16, 2017 8:25 PM >To: da...@davemloft.net; Kirsher, Jeffrey T ; >keesc...@chromium.org;

RE: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

>-Original Message- >From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >ow...@vger.kernel.org] On Behalf Of Ding Tianhong >Sent: Wednesday, August 16, 2017 8:25 PM >To: da...@davemloft.net; Kirsher, Jeffrey T ; >keesc...@chromium.org; linux-kernel@vger.kernel.org;

[RFC PATCH v4 4/6] i2c: sh_mobile: use helper to decide if DMA is useful

This ensures that we fall back to PIO if the message length is too small for DMA being useful. Otherwise, we use DMA. A bounce buffer might be applied by the helper if the original message buffer is not DMA safe. Signed-off-by: Wolfram Sang ---

[RFC PATCH v4 4/6] i2c: sh_mobile: use helper to decide if DMA is useful

This ensures that we fall back to PIO if the message length is too small for DMA being useful. Otherwise, we use DMA. A bounce buffer might be applied by the helper if the original message buffer is not DMA safe. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-sh_mobile.c | 8 ++-- 1

[RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it

So, after revisiting old mail threads, taking part in a similar discussion on the USB list, and implementing a not-convincing solution before, here is what I cooked up to document and ease DMA handling for I2C within Linux. Please have a look at the documentation introduced in patch 3 for details.

[RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it

So, after revisiting old mail threads, taking part in a similar discussion on the USB list, and implementing a not-convincing solution before, here is what I cooked up to document and ease DMA handling for I2C within Linux. Please have a look at the documentation introduced in patch 3 for details.

[RFC PATCH v4 5/6] i2c: rcar: skip DMA if buffer is not safe

This HW is prone to races, so it needs to setup new messages in irq context. That means we can't alloc bounce buffers if a message buffer is not DMA safe. So, in that case, simply fall back to PIO. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c |

[RFC PATCH v4 5/6] i2c: rcar: skip DMA if buffer is not safe

This HW is prone to races, so it needs to setup new messages in irq context. That means we can't alloc bounce buffers if a message buffer is not DMA safe. So, in that case, simply fall back to PIO. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-rcar.c | 2 +- 1 file changed, 1

[RFC PATCH v4 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-dev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c index 6f638bbc922db4..bbc7aadb4c899d 100644 --- a/drivers/i2c/i2c-dev.c +++ b/drivers/i2c/i2c-dev.c @@

[RFC PATCH v4 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-dev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c index 6f638bbc922db4..bbc7aadb4c899d 100644 --- a/drivers/i2c/i2c-dev.c +++ b/drivers/i2c/i2c-dev.c @@ -280,6 +280,8 @@ static noinline int

[RFC PATCH v4 2/6] i2c: add helpers to ease DMA handling

One helper checks if DMA is suitable and optionally creates a bounce buffer, if not. The other function returns the bounce buffer and makes sure the data is properly copied back to the message. Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-core-base.c | 45

[RFC PATCH v4 1/6] i2c: add a message flag for DMA safe buffers

I2C has no requirement that the buffer of a message needs to be DMA safe. In case it is, it can now be flagged, so drivers wishing to do DMA can use the buffer directly. Signed-off-by: Wolfram Sang --- include/uapi/linux/i2c.h | 3 +++ 1 file changed, 3

[RFC PATCH v4 2/6] i2c: add helpers to ease DMA handling

One helper checks if DMA is suitable and optionally creates a bounce buffer, if not. The other function returns the bounce buffer and makes sure the data is properly copied back to the message. Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-core-base.c | 45

[RFC PATCH v4 1/6] i2c: add a message flag for DMA safe buffers

I2C has no requirement that the buffer of a message needs to be DMA safe. In case it is, it can now be flagged, so drivers wishing to do DMA can use the buffer directly. Signed-off-by: Wolfram Sang --- include/uapi/linux/i2c.h | 3 +++ 1 file changed, 3 insertions(+) diff --git

[RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

Signed-off-by: Wolfram Sang --- Documentation/i2c/DMA-considerations | 50 1 file changed, 50 insertions(+) create mode 100644 Documentation/i2c/DMA-considerations diff --git a/Documentation/i2c/DMA-considerations

[RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

Signed-off-by: Wolfram Sang --- Documentation/i2c/DMA-considerations | 50 1 file changed, 50 insertions(+) create mode 100644 Documentation/i2c/DMA-considerations diff --git a/Documentation/i2c/DMA-considerations b/Documentation/i2c/DMA-considerations new

Re: [PATCH] ARM: imx_v6_v7_defconfig: Add CONFIG_FW_LOADER_USER_HELPER_FALLBACK

On Thu, Aug 17, 2017 at 04:04:24PM +0200, Gary Bisson wrote: > Allows to load firmware files which aren't built inside the kernel. > > Especially useful for CODA firmware (vpu_fw_imx6q.bin) which is usually > located in the rootfs. > > Signed-off-by: Gary Bisson

Re: [PATCH] ARM: imx_v6_v7_defconfig: Add CONFIG_FW_LOADER_USER_HELPER_FALLBACK

On Thu, Aug 17, 2017 at 04:04:24PM +0200, Gary Bisson wrote: > Allows to load firmware files which aren't built inside the kernel. > > Especially useful for CODA firmware (vpu_fw_imx6q.bin) which is usually > located in the rootfs. > > Signed-off-by: Gary Bisson > --- > Hi Shawn, > > I'm not

<    6   7   8   9   10   11   12   13   14   15   >