[PATCH] staging: ks7010: ks7010_sdio.c: Fixing multiple assignments

Running checkpatch on ks7010_sdio.c shows two locations where multiple assignment statements are used. This patch modifies the assignments into single assignments. Signed-off-by: Nick Rosbrook --- drivers/staging/ks7010/ks7010_sdio.c | 6 -- 1 file changed, 4

[PATCH] staging: ks7010: ks7010_sdio.c: Fixing multiple assignments

Running checkpatch on ks7010_sdio.c shows two locations where multiple assignment statements are used. This patch modifies the assignments into single assignments. Signed-off-by: Nick Rosbrook --- drivers/staging/ks7010/ks7010_sdio.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)

[PATCH 0/2] Broadcom BCM54612E support

This series is based on tip of torvalds/master. The first patch adds register definitions from Broadcom docs. The second patch adds the BCM54612E PHY ID, flags, and device-specific RGMII internal delay initialization. I tested on a custom board with an Aspeed AST2500 SOC with its second MAC

[PATCH 0/2] Broadcom BCM54612E support

This series is based on tip of torvalds/master. The first patch adds register definitions from Broadcom docs. The second patch adds the BCM54612E PHY ID, flags, and device-specific RGMII internal delay initialization. I tested on a custom board with an Aspeed AST2500 SOC with its second MAC

[PATCH 3/5] ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig symbol

From: Patrice Chotard Driver code has been already removed, see http://www.spinics.net/lists/devicetree/msg143322.html Remove the multi_v7_defconfig part Signed-off-by: Patrice Chotard Cc: Cc: ---

[PATCH 3/5] ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig symbol

From: Patrice Chotard Driver code has been already removed, see http://www.spinics.net/lists/devicetree/msg143322.html Remove the multi_v7_defconfig part Signed-off-by: Patrice Chotard Cc: Cc: --- arch/arm/configs/multi_v7_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH 15/26] ubifs: Implement encrypt/decrypt for all IO

On Fri, Oct 21, 2016 at 02:48:30PM +0200, Richard Weinberger wrote: > Signed-off-by: Richard Weinberger > --- > fs/ubifs/file.c| 36 ++ > fs/ubifs/journal.c | 105 > +++-- > fs/ubifs/super.c | 6 ++- >

Re: [PATCH 15/26] ubifs: Implement encrypt/decrypt for all IO

On Fri, Oct 21, 2016 at 02:48:30PM +0200, Richard Weinberger wrote: > Signed-off-by: Richard Weinberger > --- > fs/ubifs/file.c| 36 ++ > fs/ubifs/journal.c | 105 > +++-- > fs/ubifs/super.c | 6 ++- > fs/ubifs/ubifs.h |

[PATCH] drm: tilcdc: implement palette loading for rev1

Revision 1 of the IP doesn't work if we don't load the palette (even if it's not used, which is the case for the RGB565 format). Add a function called from tilcdc_crtc_enable() which performs all required actions if we're dealing with a rev1 chip. Signed-off-by: Bartosz Golaszewski

[PATCH] drm: tilcdc: implement palette loading for rev1

Revision 1 of the IP doesn't work if we don't load the palette (even if it's not used, which is the case for the RGB565 format). Add a function called from tilcdc_crtc_enable() which performs all required actions if we're dealing with a rev1 chip. Signed-off-by: Bartosz Golaszewski ---

[PATCH libdrm 2/2] Silence runtime complaints on platform devices

glxgears was spamming this 12 times at startup because of Mesa's probing of the DRM device code, which doesn't support platform devices. Signed-off-by: Eric Anholt --- xf86drm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index

[PATCH libdrm 2/2] Silence runtime complaints on platform devices

glxgears was spamming this 12 times at startup because of Mesa's probing of the DRM device code, which doesn't support platform devices. Signed-off-by: Eric Anholt --- xf86drm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 9b52889e4cef..52add5e441d7 100644

[PATCH libdrm 1/2] Return an -ENODEV from drmGetDevice() when no device was found.

From: Rob Herring Fixes crashes in Mesa on platform device, which expected *device to have a device when 0 was returned. (code from a paste by Rob, commit message by anholt) Signed-off-by: Eric Anholt --- xf86drm.c | 2 ++ 1 file changed, 2 insertions(+)

[PATCH libdrm 1/2] Return an -ENODEV from drmGetDevice() when no device was found.

From: Rob Herring Fixes crashes in Mesa on platform device, which expected *device to have a device when 0 was returned. (code from a paste by Rob, commit message by anholt) Signed-off-by: Eric Anholt --- xf86drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xf86drm.c b/xf86drm.c

[PATCH 1/5] fs/dcache: include wait.h

Since commit d9171b934526 ("parallel lookups machinery, part 4 (and last)") dcache.h is using but does not include wait.h. It works as long as it is included somehow earlier and fails otherwise. Cc: Al Viro Cc: Miklos Szeredi Signed-off-by:

[PATCH 2/5] rbtree: include rcu.h because we use it

Since commit c1adf20052d8 ("Introduce rb_replace_node_rcu()") rbtree_augmented.h uses RCU related data structures but does not include them. It works as long as gets somehow included before that and fails otherwise. Cc: David Howells Cc: "Peter Zijlstra (Intel)"

[PATCH 2/5] rbtree: include rcu.h because we use it

Since commit c1adf20052d8 ("Introduce rb_replace_node_rcu()") rbtree_augmented.h uses RCU related data structures but does not include them. It works as long as gets somehow included before that and fails otherwise. Cc: David Howells Cc: "Peter Zijlstra (Intel)" Signed-off-by: Sebastian Andrzej

[PATCH 1/5] fs/dcache: include wait.h

Since commit d9171b934526 ("parallel lookups machinery, part 4 (and last)") dcache.h is using but does not include wait.h. It works as long as it is included somehow earlier and fails otherwise. Cc: Al Viro Cc: Miklos Szeredi Signed-off-by: Sebastian Andrzej Siewior --- include/linux/dcache.h

[PATCH 4/5] iommu/iova: don't disable preempt around this_cpu_ptr()

Commit 583248e6620a ("iommu/iova: Disable preemption around use of this_cpu_ptr()") disables preemption while accessing a per-CPU variable. This does keep lockdep quiet. However I don't see the point why it is bad if we get migrated after its access to another CPU. __iova_rcache_insert() and

[PATCH 4/5] iommu/iova: don't disable preempt around this_cpu_ptr()

Commit 583248e6620a ("iommu/iova: Disable preemption around use of this_cpu_ptr()") disables preemption while accessing a per-CPU variable. This does keep lockdep quiet. However I don't see the point why it is bad if we get migrated after its access to another CPU. __iova_rcache_insert() and

[PATCH 5/5] iommu/vt-d: don't disable preemption while accessing deferred_flush()

get_cpu() disables preemption and returns the current CPU number. The CPU number is later only used once while retrieving the address of the local's CPU deferred_flush pointer. We can instead use raw_cpu_ptr() while we remain preemptible. The worst thing that can happen is that

[PATCH 3/5] fs/dcache: init in_lookup_hashtable

in_lookup_hashtable was introduced in commit 94bdd655caba ("parallel lookups machinery, part 3") and never initialized but since it is in the data it is all zeros. But we need this for -RT. Cc: Alexander Viro Cc: linux-fsde...@vger.kernel.org Signed-off-by: Sebastian

[PATCH 5/5] iommu/vt-d: don't disable preemption while accessing deferred_flush()

get_cpu() disables preemption and returns the current CPU number. The CPU number is later only used once while retrieving the address of the local's CPU deferred_flush pointer. We can instead use raw_cpu_ptr() while we remain preemptible. The worst thing that can happen is that

[PATCH 3/5] fs/dcache: init in_lookup_hashtable

in_lookup_hashtable was introduced in commit 94bdd655caba ("parallel lookups machinery, part 3") and never initialized but since it is in the data it is all zeros. But we need this for -RT. Cc: Alexander Viro Cc: linux-fsde...@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior ---

Re: Reset implementation for Zynq

Iztok, On Fri, Oct 21, 2016 at 03:08:47AM -0700, iztok.je...@redpitaya.com wrote: > Hi Moritz, > > I was looking at your reset implementation for Zynq: > https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/drivers/reset/reset-zynq.c > I went through related

Re: Reset implementation for Zynq

Iztok, On Fri, Oct 21, 2016 at 03:08:47AM -0700, iztok.je...@redpitaya.com wrote: > Hi Moritz, > > I was looking at your reset implementation for Zynq: > https://github.com/Xilinx/linux-xlnx/blob/629041605b93343ad2e8971ceaac3edcef0b043b/drivers/reset/reset-zynq.c > I went through related

Re: [PATCH V3 0/3] Add support for session ID user filtering

On Fri, Oct 21, 2016 at 2:46 AM, Richard Guy Briggs wrote: > On 2016-10-20 15:27, Paul Moore wrote: >> On Thursday, August 18, 2016 01:43:12 PM Richard Guy Briggs wrote: >> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter >> > RFE Session ID User

Re: [PATCH V3 0/3] Add support for session ID user filtering

On Fri, Oct 21, 2016 at 2:46 AM, Richard Guy Briggs wrote: > On 2016-10-20 15:27, Paul Moore wrote: >> On Thursday, August 18, 2016 01:43:12 PM Richard Guy Briggs wrote: >> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Session-ID-User-Filter >> > RFE Session ID User Filter >> > >> >

[RESEND PATCH] usb: chipidea: Configure DMA properties and ops from DT

hcd_alloc_coherent() and usb_alloc_coherent() ends up allocating coherent memory on behalf of ci_hdrc driver. But as the ci_hdrc is instantiated manually it will not have any dma_mem or dma_ops assigned, which makes the dma_alloc_coherent() fail on some platforms (e.g. arm64). This patch solves

[RESEND PATCH] usb: chipidea: Configure DMA properties and ops from DT

hcd_alloc_coherent() and usb_alloc_coherent() ends up allocating coherent memory on behalf of ci_hdrc driver. But as the ci_hdrc is instantiated manually it will not have any dma_mem or dma_ops assigned, which makes the dma_alloc_coherent() fail on some platforms (e.g. arm64). This patch solves

Re: PROBLEM: OHCI watchdog timeouts inside VirtualBox, probably due to timer wheel rework

On Fri, 21 Oct 2016, Michael Thayer wrote: > Hello Alan (LKML on CC), > > Contacting you about this on Thomas Gleixner's (also on CC) suggestion. > The short summary is that when Linux 4.8.0 (also tested with a few later > kernels) is run on a VirtualBox virtual machine with USB enabled, OHCI

Re: [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup: close FOLL MAP_PRIVATE race"

Hi Michal, On Fri, Oct 21, 2016 at 08:46:02AM +0200, Michal Hocko wrote: > On Thu 20-10-16 23:39:39, Brian Norris wrote: > > I'm not sure the best way to report this, but the Chrome OS test > > infrastructure noticed some problems when testing the following patch > > backported to our 3.8

Re: PROBLEM: OHCI watchdog timeouts inside VirtualBox, probably due to timer wheel rework

On Fri, 21 Oct 2016, Michael Thayer wrote: > Hello Alan (LKML on CC), > > Contacting you about this on Thomas Gleixner's (also on CC) suggestion. > The short summary is that when Linux 4.8.0 (also tested with a few later > kernels) is run on a VirtualBox virtual machine with USB enabled, OHCI

Re: [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup: close FOLL MAP_PRIVATE race"

Hi Michal, On Fri, Oct 21, 2016 at 08:46:02AM +0200, Michal Hocko wrote: > On Thu 20-10-16 23:39:39, Brian Norris wrote: > > I'm not sure the best way to report this, but the Chrome OS test > > infrastructure noticed some problems when testing the following patch > > backported to our 3.8

Re: [PATCH] iio: light: acpi-als: Add IO_CHAN_INFO_OFFSET/SCALE to mask.

On Fri, Oct 21, 2016 at 1:17 AM, Enric Balletbo i Serra wrote: > According the ACPI specification (Version 5.0 Errata A) [1], the data > coming from the sensor represent the ambient light illuminance reading > expressed in lux. Unfortunately ACPI interface doesn't

Re: [PATCH] iio: light: acpi-als: Add IO_CHAN_INFO_OFFSET/SCALE to mask.

On Fri, Oct 21, 2016 at 1:17 AM, Enric Balletbo i Serra wrote: > According the ACPI specification (Version 5.0 Errata A) [1], the data > coming from the sensor represent the ambient light illuminance reading > expressed in lux. Unfortunately ACPI interface doesn't provide a > mechanism to

[RFC PATCH] NFSv4: replace seqcount_t with a seqlock_t

The raw_write_seqcount_begin() in nfs4_reclaim_open_state() bugs me because it maps to preempt_disable() in -RT which I can't have at this point. So I took a look at the code. It the lockdep part was removed in commit abbec2da13f0 ("NFS: Use raw_write_seqcount_begin/end int

[RFC PATCH] NFSv4: replace seqcount_t with a seqlock_t

The raw_write_seqcount_begin() in nfs4_reclaim_open_state() bugs me because it maps to preempt_disable() in -RT which I can't have at this point. So I took a look at the code. It the lockdep part was removed in commit abbec2da13f0 ("NFS: Use raw_write_seqcount_begin/end int

Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

Hi Ioannis, first of all, when you reply to a mail on lkml, please use the "reply-to-all" functionality of your mail client - otherwise replies might get missed on such a high volume mailing list. On Fri, Oct 21, 2016 at 07:19:07PM +0300, sonofa...@openmailbox.org wrote: > Sorry for the late

Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

Hi Ioannis, first of all, when you reply to a mail on lkml, please use the "reply-to-all" functionality of your mail client - otherwise replies might get missed on such a high volume mailing list. On Fri, Oct 21, 2016 at 07:19:07PM +0300, sonofa...@openmailbox.org wrote: > Sorry for the late

[GIT PULL] SCSI fixes for 4.9-rc1

Five small fixes. Some of these, like the nested spinlock overwriting saved flags and the Kasan use after free look serious, but they seem not to have been picked up in testing or seen in the field. The biggest user visible issue is probably the wrong device handler for Clariion, which means

[GIT PULL] SCSI fixes for 4.9-rc1

Five small fixes. Some of these, like the nested spinlock overwriting saved flags and the Kasan use after free look serious, but they seem not to have been picked up in testing or seen in the field. The biggest user visible issue is probably the wrong device handler for Clariion, which means

Re: [PATCH] usb: xhci: Workaround for erratum-A010129

On Fri, 21 Oct 2016, Sriram Dash wrote: > For the USB3.0 controller, USB 2.0 reset not driven while > port is in Resume state. So, do not program the USB 2.0 reset > (PORTSC[PR]=1) while in Resume state. > > Signed-off-by: Rajat Srivastava > Signed-off-by: Sriram Dash

Re: [PATCH] usb: xhci: Workaround for erratum-A010129

On Fri, 21 Oct 2016, Sriram Dash wrote: > For the USB3.0 controller, USB 2.0 reset not driven while > port is in Resume state. So, do not program the USB 2.0 reset > (PORTSC[PR]=1) while in Resume state. > > Signed-off-by: Rajat Srivastava > Signed-off-by: Sriram Dash > Signed-off-by: Rajesh

[PATCH V7 3/4] dmaengine: qcom_hidma: protect common data structures

When MSI interrupts are supported, error and the transfer interrupt can come from multiple processor contexts. Each error interrupt is an MSI interrupt. If the channel is disabled by the first error interrupt, the remaining error interrupts will gracefully return in the interrupt handler. If an

[PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts

The interrupts can now be delivered as platform MSI interrupts on newer platforms. The code looks for a new OF and ACPI strings in order to enable the functionality. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c| 143

[PATCH V7 3/4] dmaengine: qcom_hidma: protect common data structures

When MSI interrupts are supported, error and the transfer interrupt can come from multiple processor contexts. Each error interrupt is an MSI interrupt. If the channel is disabled by the first error interrupt, the remaining error interrupts will gracefully return in the interrupt handler. If an

[PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts

The interrupts can now be delivered as platform MSI interrupts on newer platforms. The code looks for a new OF and ACPI strings in order to enable the functionality. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c| 143 ++--

Re: [PATCH 1/5] ftrace: Support full glob matching

On Thu, 20 Oct 2016 09:43:20 -0400 Steven Rostedt wrote: > On Thu, 20 Oct 2016 11:07:52 +0900 > Masami Hiramatsu wrote: > > > > And OK, what kind of tests are failed on 4.9-rc1? I though a possible > > kernel freeze in 4.8 when I ran ftracetest, but

Re: [PATCH 1/5] ftrace: Support full glob matching

On Thu, 20 Oct 2016 09:43:20 -0400 Steven Rostedt wrote: > On Thu, 20 Oct 2016 11:07:52 +0900 > Masami Hiramatsu wrote: > > > > And OK, what kind of tests are failed on 4.9-rc1? I though a possible > > kernel freeze in 4.8 when I ran ftracetest, but it seemed disappeared > > in 4.9-rc1. > >

Re: [PATCH] clk: fix link error for rcar-gen2

Hello. On 10/21/2016 06:47 PM, Arnd Bergmann wrote: The addition of one more rcar-gen2 based SoC caused a build error (again) in my randconfig builds: arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init': setup-rcar-gen2.c:(.init.text+0x200): undefined reference to

Re: [PATCH] clk: fix link error for rcar-gen2

Hello. On 10/21/2016 06:47 PM, Arnd Bergmann wrote: The addition of one more rcar-gen2 based SoC caused a build error (again) in my randconfig builds: arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init': setup-rcar-gen2.c:(.init.text+0x200): undefined reference to

Re: [PATCH 01/12] Documentation/HOWTO: Mark subsection in rst format

On Sat, Oct 22, 2016 at 12:45 AM, Mauro Carvalho Chehab wrote: > Em Sat, 22 Oct 2016 00:19:46 +0900 > SeongJae Park escreveu: > >> Subsections in HOWTO is not marked in rst format. This commit specifies >> them in rst format. >> >> Signed-off-by:

Re: [PATCH 01/12] Documentation/HOWTO: Mark subsection in rst format

On Sat, Oct 22, 2016 at 12:45 AM, Mauro Carvalho Chehab wrote: > Em Sat, 22 Oct 2016 00:19:46 +0900 > SeongJae Park escreveu: > >> Subsections in HOWTO is not marked in rst format. This commit specifies >> them in rst format. >> >> Signed-off-by: SeongJae Park >> --- >> Documentation/HOWTO |

[PATCH] KVM: x86: fix wbinvd_dirty_mask use-after-free

vcpu->arch.wbinvd_dirty_mask may still be used after freeing it, corrupting memory. For example, the following call trace may set a bit in an already freed cpu mask: kvm_arch_vcpu_load vcpu_load vmx_free_vcpu_nested vmx_free_vcpu kvm_arch_vcpu_free Fix this by deferring

[PATCH] KVM: x86: fix wbinvd_dirty_mask use-after-free

vcpu->arch.wbinvd_dirty_mask may still be used after freeing it, corrupting memory. For example, the following call trace may set a bit in an already freed cpu mask: kvm_arch_vcpu_load vcpu_load vmx_free_vcpu_nested vmx_free_vcpu kvm_arch_vcpu_free Fix this by deferring

[PATCH V7 2/4] dmaengine: qcom_hidma: bring out interrupt cause

Bring out the interrupt cause to the top level so that MSI interrupts can be hooked at a later stage. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 62 - 1 file changed, 33 insertions(+), 29 deletions(-) diff --git

[PATCH V7 2/4] dmaengine: qcom_hidma: bring out interrupt cause

Bring out the interrupt cause to the top level so that MSI interrupts can be hooked at a later stage. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 62 - 1 file changed, 33 insertions(+), 29 deletions(-) diff --git

Disabling an interrupt in the handler locks the system up

Hello, On my platform, one HW block pulls the interrupt line high as long as it remains idle, and low when it is busy. The device tree node is: test@2 { compatible = "vendor,testme"; interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;

Disabling an interrupt in the handler locks the system up

Hello, On my platform, one HW block pulls the interrupt line high as long as it remains idle, and low when it is busy. The device tree node is: test@2 { compatible = "vendor,testme"; interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;

[PATCH V7 1/4] dmaengine: qcom_hidma: make pending_tre_count atomic

Getting ready for the MSI interrupts. The pending_tre_count is used in the interrupt handler to make sure all outstanding requests are serviced. The driver will allocate 11 MSI interrupts. Each MSI interrupt can be assigned to a different CPU. Then, we have a race condition for common variables

[PATCH V7 1/4] dmaengine: qcom_hidma: make pending_tre_count atomic

Getting ready for the MSI interrupts. The pending_tre_count is used in the interrupt handler to make sure all outstanding requests are serviced. The driver will allocate 11 MSI interrupts. Each MSI interrupt can be assigned to a different CPU. Then, we have a race condition for common variables

[PATCH] scripts/faddr2line: fix "size mismatch" error

I'm not sure how we missed this problem before. When I take a function address and size from an oops and give it to faddr2line, it usually complains about a size mismatch: $ scripts/faddr2line ~/k/vmlinux write_sysrq_trigger+0x51/0x60 skipping write_sysrq_trigger address at

[PATCH] scripts/faddr2line: fix "size mismatch" error

I'm not sure how we missed this problem before. When I take a function address and size from an oops and give it to faddr2line, it usually complains about a size mismatch: $ scripts/faddr2line ~/k/vmlinux write_sysrq_trigger+0x51/0x60 skipping write_sysrq_trigger address at

[PATCH 2/5] ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol

From: Patrice Chotard STiH415/6 SoC support is being removed from the kernel and was the only platform using this Kconfig symbol Signed-off-by: Patrice Chotard Cc: Cc: ---

[PATCH 2/5] ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol

From: Patrice Chotard STiH415/6 SoC support is being removed from the kernel and was the only platform using this Kconfig symbol Signed-off-by: Patrice Chotard Cc: Cc: --- arch/arm/configs/multi_v7_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH] flow_dissector: avoid uninitialized variable access

Fri, Oct 21, 2016 at 05:55:53PM CEST, a...@arndb.de wrote: >gcc warns about an uninitialized pointer dereference in the vlan >priority handling: > >net/core/flow_dissector.c: In function '__skb_flow_dissect': >net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in >this

Re: [PATCH] flow_dissector: avoid uninitialized variable access

Fri, Oct 21, 2016 at 05:55:53PM CEST, a...@arndb.de wrote: >gcc warns about an uninitialized pointer dereference in the vlan >priority handling: > >net/core/flow_dissector.c: In function '__skb_flow_dissect': >net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in >this

[PATCH] Staging:vt6656:main_usb: fix Block comments should align the * on each line

Block comments should align the * on each line as reported by checkpatch.pl Signed-off-by: Nadim Almas --- drivers/staging/vt6656/main_usb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/vt6656/main_usb.c

[PATCH] Staging:vt6656:main_usb: fix Block comments should align the * on each line

Block comments should align the * on each line as reported by checkpatch.pl Signed-off-by: Nadim Almas --- drivers/staging/vt6656/main_usb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c index

Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

Sorry for the late reply! This machine has caused nothing but trouble. HP will not fix it and we will not choose their laptops anymore... My brother told me that we apply a quirk to the last Ontario APUs that do not need it but I did not think it would be an issue since they have fixed the

Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

Sorry for the late reply! This machine has caused nothing but trouble. HP will not fix it and we will not choose their laptops anymore... My brother told me that we apply a quirk to the last Ontario APUs that do not need it but I did not think it would be an issue since they have fixed the

Re: [PATCH] pci: pcie-designware-plat: changing driver authors e-mail

Thank you Bjorn! On 10/21/2016 3:57 PM, Bjorn Helgaas wrote: > On Fri, Oct 21, 2016 at 10:31:48AM +0100, Joao Pinto wrote: >> Although I am leaving Synopsys, I would like to keep working with the >> linux kernel community and help in what you might find useful. For that >> I am sending this

Re: [PATCH] pci: pcie-designware-plat: changing driver authors e-mail

Thank you Bjorn! On 10/21/2016 3:57 PM, Bjorn Helgaas wrote: > On Fri, Oct 21, 2016 at 10:31:48AM +0100, Joao Pinto wrote: >> Although I am leaving Synopsys, I would like to keep working with the >> linux kernel community and help in what you might find useful. For that >> I am sending this

RE: [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Friday, October 21, 2016 10:37 AM > To: Leo Li > Cc: Bjorn Helgaas ; Minghuan Lian > ; Mingkai Hu ; > Roy Zang

RE: [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Friday, October 21, 2016 10:37 AM > To: Leo Li > Cc: Bjorn Helgaas ; Minghuan Lian > ; Mingkai Hu ; > Roy Zang ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org;

Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers

Hi, On Thu, Oct 20, 2016 at 01:55:22PM -0400, Jarod Wilson wrote: > hsi/clients/ssi_protocol: > - use core MTU range checking > - remove now redundant ssip_pn_set_mtu Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature

Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers

Hi, On Thu, Oct 20, 2016 at 01:55:22PM -0400, Jarod Wilson wrote: > hsi/clients/ssi_protocol: > - use core MTU range checking > - remove now redundant ssip_pn_set_mtu Acked-By: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature

[RFC][PATCH] Add EXPORT_MACRO_SYMBOL() for asm

Commit 784d5699eddc5 ("x86: move exports to actual definitions") removed the EXPORT_SYMBOL(__fentry__) and EXPORT_SYMBOL(mcount) from x8664_ksyms_64.c, and added EXPORT_SYMBOL(function_hook) in mcount_64.S instead. The problem is that function_hook isn't a function at all, but a macro that is

[RFC][PATCH] Add EXPORT_MACRO_SYMBOL() for asm

Commit 784d5699eddc5 ("x86: move exports to actual definitions") removed the EXPORT_SYMBOL(__fentry__) and EXPORT_SYMBOL(mcount) from x8664_ksyms_64.c, and added EXPORT_SYMBOL(function_hook) in mcount_64.S instead. The problem is that function_hook isn't a function at all, but a macro that is

Re: [PATCH V3 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

On Fri, Oct 21, 2016 at 02:12:44PM +0800, Dongdong Liu wrote: [...] > >>+static int hisi_pcie_init(struct pci_config_window *cfg) > >>+{ > >>+ int ret; > >>+ struct acpi_device *adev = to_acpi_device(cfg->parent); > > > >Why is this expected to be struct acpi_device? > > I use this

[PATCH 1/5] thermal: st_thermal_syscfg: Remove obsolete STiH415/416 platform support.

From: Patrice Chotard STiH415/6 SoC support is being removed from the kernel. This patch removes support from the syscfg thermal driver. This driver also supports STiD127 SoC which has never been upstreamed. Signed-off-by: Patrice Chotard Cc:

Re: [PATCH V3 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

On Fri, Oct 21, 2016 at 02:12:44PM +0800, Dongdong Liu wrote: [...] > >>+static int hisi_pcie_init(struct pci_config_window *cfg) > >>+{ > >>+ int ret; > >>+ struct acpi_device *adev = to_acpi_device(cfg->parent); > > > >Why is this expected to be struct acpi_device? > > I use this

[PATCH 1/5] thermal: st_thermal_syscfg: Remove obsolete STiH415/416 platform support.

From: Patrice Chotard STiH415/6 SoC support is being removed from the kernel. This patch removes support from the syscfg thermal driver. This driver also supports STiD127 SoC which has never been upstreamed. Signed-off-by: Patrice Chotard Cc: Cc: --- drivers/thermal/st/Kconfig

[PATCH 0/5] Remove STiH415/416 SoC platform support remaining parts

From: Patrice Chotard ST have sent patches which remove clock support for these SoCs [1] which once applied mean the platform will no longer boot. This series cleans up remaining STi drivers which have support for these SoC's, by removing code, and updating the DT

[PATCH 0/5] Remove STiH415/416 SoC platform support remaining parts

From: Patrice Chotard ST have sent patches which remove clock support for these SoCs [1] which once applied mean the platform will no longer boot. This series cleans up remaining STi drivers which have support for these SoC's, by removing code, and updating the DT documentation accordingly.

Re: [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection

Hi Neil > Yes this would be a good idea if we were able to scan the internal > and external PHYs at the same time, but with our limited knowledge > the values we write in the register seems to switch a mux for the > whole RMII and MDIO signals to either interface. Ah, O.K. So you need something

Re: [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection

Hi Neil > Yes this would be a good idea if we were able to scan the internal > and external PHYs at the same time, but with our limited knowledge > the values we write in the register seems to switch a mux for the > whole RMII and MDIO signals to either interface. Ah, O.K. So you need something

[PATCH 4/5] irqchip: st: remove STiH415/416 irqchip support

From: Patrice Chotard Support for STiH415/6 SoCs is being removed from the kernel because the platforms are obsolete. This patch removes the irqchip for these SoC's. Signed-off-by: Patrice Chotard Cc: Cc:

[PATCH 4/5] irqchip: st: remove STiH415/416 irqchip support

From: Patrice Chotard Support for STiH415/6 SoCs is being removed from the kernel because the platforms are obsolete. This patch removes the irqchip for these SoC's. Signed-off-by: Patrice Chotard Cc: Cc: Cc: --- drivers/irqchip/irq-st.c | 10 -- 1 file changed, 10 deletions(-)

Re: [PATCH] softirq: Display IRQ_POLL for irq-poll statistics

On 10/10/2016 06:10 AM, Sagi Grimberg wrote: This library was moved to the generic area and was renamed to irq-poll. Hence, update proc/softirqs output accordingly. Added, thanks. -- Jens Axboe

Re: [PATCH] softirq: Display IRQ_POLL for irq-poll statistics

On 10/10/2016 06:10 AM, Sagi Grimberg wrote: This library was moved to the generic area and was renamed to irq-poll. Hence, update proc/softirqs output accordingly. Added, thanks. -- Jens Axboe

[PATCH 5/5] irqchip: st: Remove obsolete platforms from dt binding doc

From: Patrice Chotard STiH415/6 SoC support is being removed from the kernel. This patch updates the sti irchip and removes references to these obsolete platforms. Signed-off-by: Patrice Chotard Cc: Cc:

Re: [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

On 10/21/2016 7:45 AM, Bjorn Helgaas wrote: > [1] http://marc.info/?l=linux-acpi=145580159209240=2) > >> > Acked-by: Bjorn Helgaas > Wait a minute, I still have a question here: what about other ACPI > arches (ia64, arm64)? Don't they need to call acpi_penalize_sci_irq() >

[PATCH 5/5] irqchip: st: Remove obsolete platforms from dt binding doc

From: Patrice Chotard STiH415/6 SoC support is being removed from the kernel. This patch updates the sti irchip and removes references to these obsolete platforms. Signed-off-by: Patrice Chotard Cc: Cc: Cc: --- .../devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt | 6 ++

Re: [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

On 10/21/2016 7:45 AM, Bjorn Helgaas wrote: > [1] http://marc.info/?l=linux-acpi=145580159209240=2) > >> > Acked-by: Bjorn Helgaas > Wait a minute, I still have a question here: what about other ACPI > arches (ia64, arm64)? Don't they need to call acpi_penalize_sci_irq() > somewhere? > ACPI

Re: [PATCH v2] mailbox: PCC: Fix lockdep warning when request PCC channel

Hi Hoan, On 10/18/2016 1:00 AM, Hoan Tran wrote: > This patch fixes the lockdep warning below > > [7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) > [7.229776] [ cut here ] > [7.229787] WARNING: CPU: 1 PID: 1 at >

Re: [PATCH v2] mailbox: PCC: Fix lockdep warning when request PCC channel

Hi Hoan, On 10/18/2016 1:00 AM, Hoan Tran wrote: > This patch fixes the lockdep warning below > > [7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) > [7.229776] [ cut here ] > [7.229787] WARNING: CPU: 1 PID: 1 at >

[GIT PULL] Block fixes for 4.9-rc

Hi Linus, A set of fixes that missed the merge window, mostly due to me being away around that time. Nothing major here, a mix of nvme cleanups and fixes, and one fix for the badblocks handling. Please pull! git://git.kernel.dk/linux-block.git for-linus

[GIT PULL] Block fixes for 4.9-rc

Hi Linus, A set of fixes that missed the merge window, mostly due to me being away around that time. Nothing major here, a mix of nvme cleanups and fixes, and one fix for the badblocks handling. Please pull! git://git.kernel.dk/linux-block.git for-linus

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