[PATCH] staging: greybus: Remove unnecessary platform_set_drvdata

Unnecessary platform_set_drvdata() has been removed since the driver core clears the driver data to NULL after device release or on probe failure. There is no need to manually clear the device driver data to NULL. The Coccinelle semantic patch used to make this change is as follows: // @@ struct

[PATCH] staging: greybus: Remove unnecessary platform_set_drvdata

Unnecessary platform_set_drvdata() has been removed since the driver core clears the driver data to NULL after device release or on probe failure. There is no need to manually clear the device driver data to NULL. The Coccinelle semantic patch used to make this change is as follows: // @@ struct

Re: [PATCH 1/1] mm/hugetlb: Make huge_pte_offset() consistent and document behaviour

On 07/26/2017 06:34 AM, Punit Agrawal wrote: > Michal Hocko writes: > >> On Wed 26-07-17 14:33:57, Michal Hocko wrote: >>> On Wed 26-07-17 13:11:46, Punit Agrawal wrote: >> [...] I've been running tests from mce-test suite and libhugetlbfs for similar changes we did

Re: [PATCH 1/1] mm/hugetlb: Make huge_pte_offset() consistent and document behaviour

On 07/26/2017 06:34 AM, Punit Agrawal wrote: > Michal Hocko writes: > >> On Wed 26-07-17 14:33:57, Michal Hocko wrote: >>> On Wed 26-07-17 13:11:46, Punit Agrawal wrote: >> [...] I've been running tests from mce-test suite and libhugetlbfs for similar changes we did on arm64. There

[PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

From: Ryder Lee Add support for MediaTek new generation controller and update related properities. Signed-off-by: Ryder Lee Signed-off-by: Honghui Zhang --- .../devicetree/bindings/pci/mediatek-pcie.txt | 168

[PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

From: Ryder Lee Add support for MediaTek new generation controller and update related properities. Signed-off-by: Ryder Lee Signed-off-by: Honghui Zhang --- .../devicetree/bindings/pci/mediatek-pcie.txt | 168 - 1 file changed, 161 insertions(+), 7 deletions(-) diff

Re: [PATCH] turbostat: Running on virtual machine is not supported

Henrique, I like your suggestion, thanks! BTW. let's discuss (and patch) turbostat on linux-pm, rather than on lkml. thanks, -Len On Tue, Jul 25, 2017 at 11:59 AM, Henrique de Moraes Holschuh wrote: > On Tue, 25 Jul 2017, Prarit Bhargava wrote: >> A common way of determining

Re: [PATCH] turbostat: Running on virtual machine is not supported

Henrique, I like your suggestion, thanks! BTW. let's discuss (and patch) turbostat on linux-pm, rather than on lkml. thanks, -Len On Tue, Jul 25, 2017 at 11:59 AM, Henrique de Moraes Holschuh wrote: > On Tue, 25 Jul 2017, Prarit Bhargava wrote: >> A common way of determining if the system is

Re: [PATCH 2/2] printk: Add boottime and real timestamps

Hi Prarit, [auto build test ERROR on linus/master] [also build test ERROR on v4.13-rc2] [cannot apply to next-20170726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Prarit-Bhargava/printk

Re: [PATCH 2/2] printk: Add boottime and real timestamps

Hi Prarit, [auto build test ERROR on linus/master] [also build test ERROR on v4.13-rc2] [cannot apply to next-20170726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Prarit-Bhargava/printk

[PATCH v2 2/5] PCI: mediatek: switch to use platform_get_resource_byname()

From: Ryder Lee This is a transitional patch. We currently use platfarm_get_resource() for retrieving the IOMEM resources, but there might be some chips don't have subsys/shared registers part, which depends on platform design, and these will be introduced in further

[PATCH v2 2/5] PCI: mediatek: switch to use platform_get_resource_byname()

From: Ryder Lee This is a transitional patch. We currently use platfarm_get_resource() for retrieving the IOMEM resources, but there might be some chips don't have subsys/shared registers part, which depends on platform design, and these will be introduced in further patches. Switch this

[PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

From: Ryder Lee Add support for MediaTek new generation controller and update related properities. Signed-off-by: Ryder Lee Signed-off-by: Honghui Zhang --- .../devicetree/bindings/pci/mediatek-pcie.txt | 168

[PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

From: Ryder Lee Add support for MediaTek new generation controller and update related properities. Signed-off-by: Ryder Lee Signed-off-by: Honghui Zhang --- .../devicetree/bindings/pci/mediatek-pcie.txt | 168 - 1 file changed, 161 insertions(+), 7 deletions(-) diff

[PATCH v2 4/5] PCI: mediatek: Add new generation controller support

From: Ryder Lee Add support for new Gen2 controller which has two root ports and shares the probing flow with legacy controller. Currently this IP block can be found on MT7622/MT2712. Signed-off-by: Ryder Lee Signed-off-by: Honghui Zhang

[PATCH v2 3/5] dt-bindings: PCI: rename and cleanup MediaTek binding text

From: Ryder Lee In order to accommodate other SoC generations, this patch updates filename to make it more generic, regroups specific properties by SoCs, and removes redundant descriptions. Signed-off-by: Ryder Lee ---

[PATCH v2 4/5] PCI: mediatek: Add new generation controller support

From: Ryder Lee Add support for new Gen2 controller which has two root ports and shares the probing flow with legacy controller. Currently this IP block can be found on MT7622/MT2712. Signed-off-by: Ryder Lee Signed-off-by: Honghui Zhang --- drivers/pci/host/Kconfig | 5 +-

[PATCH v2 3/5] dt-bindings: PCI: rename and cleanup MediaTek binding text

From: Ryder Lee In order to accommodate other SoC generations, this patch updates filename to make it more generic, regroups specific properties by SoCs, and removes redundant descriptions. Signed-off-by: Ryder Lee --- ...{mediatek,mt7623-pcie.txt => mediatek-pcie.txt} | 29

[PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations

From: Ryder Lee Introduce a structure "mtk_pcie_soc" to abstract the differences between controller generations, and the .startup() hook is used to encapsulate some SoC-dependent related setting. In doing so, the common code which will be reused by future chips. In

[PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations

From: Ryder Lee Introduce a structure "mtk_pcie_soc" to abstract the differences between controller generations, and the .startup() hook is used to encapsulate some SoC-dependent related setting. In doing so, the common code which will be reused by future chips. In addition, we change the

[PATCH v2 0/5] PCI: MediaTek: Add support for new generation host controller

From: Honghui Zhang MediaTek's PCIe host controller has two generation HWs, the new generation HW has two root ports, it shares most probing flow with the legacy controller. But the read/write config space logical is different from the lagacy controller. This patchset

[PATCH v2 0/5] PCI: MediaTek: Add support for new generation host controller

From: Honghui Zhang MediaTek's PCIe host controller has two generation HWs, the new generation HW has two root ports, it shares most probing flow with the legacy controller. But the read/write config space logical is different from the lagacy controller. This patchset abstract the common probing

Re: [PATCH] f2fs: let __get_victim successfully get a segno in corner case

Hi, Jay, Sorry for the mistake in last mail, the ovp is 462, and the reserved is 235. I check the code and have not found problems with p.max_search yet. Just forget the this patch, since there is still 870 segments below, so it should not be the assumed case of this patch. By the way, I

Re: [PATCH] f2fs: let __get_victim successfully get a segno in corner case

Hi, Jay, Sorry for the mistake in last mail, the ovp is 462, and the reserved is 235. I check the code and have not found problems with p.max_search yet. Just forget the this patch, since there is still 870 segments below, so it should not be the assumed case of this patch. By the way, I

Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management

Hi, On 26 July 2017 at 20:08, Sebastian Reichel wrote: > Hi, > > On Wed, Jul 26, 2017 at 11:05:25AM +0800, Baolin Wang wrote: >> On 25 July 2017 at 17:59, Sebastian Reichel >> wrote: >> > On Tue, Jul 25, 2017 at 04:00:01PM

Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management

Hi, On 26 July 2017 at 20:08, Sebastian Reichel wrote: > Hi, > > On Wed, Jul 26, 2017 at 11:05:25AM +0800, Baolin Wang wrote: >> On 25 July 2017 at 17:59, Sebastian Reichel >> wrote: >> > On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote: >> >> Integrate with the newly added USB

Re: [PATCH 05/11] powerpc/topology: Remove the unused parent_node() macro

Hi Michael, At 07/27/2017 10:21 AM, Michael Ellerman wrote: Dou Liyang writes: Commit a7be6e5a7f8d ("mm: drop useless local parameters of __register_one_node()") removes the last user of parent_node(). The parent_node() macro in POWERPC platform is unnecessary.

Re: [PATCH 05/11] powerpc/topology: Remove the unused parent_node() macro

Hi Michael, At 07/27/2017 10:21 AM, Michael Ellerman wrote: Dou Liyang writes: Commit a7be6e5a7f8d ("mm: drop useless local parameters of __register_one_node()") removes the last user of parent_node(). The parent_node() macro in POWERPC platform is unnecessary. Remove it for cleanup.

Re: [RFC/RFT PATCH] KVM: nVMX: fixes to nested virt interrupt injection

2017-07-24 22:20 GMT+08:00 Paolo Bonzini : > There are three issues in nested_vmx_check_exception: > > 1) it is not taking PFEC_MATCH/PFEC_MASK into account, as reported > by Wanpeng Li; > > 2) it should rebuild the interruption info and exit qualification fields > from

Re: [RFC/RFT PATCH] KVM: nVMX: fixes to nested virt interrupt injection

2017-07-24 22:20 GMT+08:00 Paolo Bonzini : > There are three issues in nested_vmx_check_exception: > > 1) it is not taking PFEC_MATCH/PFEC_MASK into account, as reported > by Wanpeng Li; > > 2) it should rebuild the interruption info and exit qualification fields > from scratch, as reported by Jim

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

On 07/27/2017 01:02 AM, Michael S. Tsirkin wrote: On Wed, Jul 26, 2017 at 11:48:41AM +0800, Wei Wang wrote: On 07/23/2017 09:45 AM, Michael S. Tsirkin wrote: On Fri, Jul 14, 2017 at 03:12:43PM +0800, Wei Wang wrote: On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote: On Thu, Jul 13, 2017 at

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

On 07/27/2017 01:02 AM, Michael S. Tsirkin wrote: On Wed, Jul 26, 2017 at 11:48:41AM +0800, Wei Wang wrote: On 07/23/2017 09:45 AM, Michael S. Tsirkin wrote: On Fri, Jul 14, 2017 at 03:12:43PM +0800, Wei Wang wrote: On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote: On Thu, Jul 13, 2017 at

Re: [PATCH v2] security: fix description of values returned by cap_inode_need_killpriv

On Wed, Jul 26, 2017 at 10:27:05PM -0400, Stefan Berger wrote: > cap_inode_need_killpriv returns 1 if security.capability exists and > has a value and inode_killpriv() is required, 0 otherwise. Fix the > description of the return value to reflect this. > > Signed-off-by: Stefan Berger

Re: [PATCH v2] security: fix description of values returned by cap_inode_need_killpriv

On Wed, Jul 26, 2017 at 10:27:05PM -0400, Stefan Berger wrote: > cap_inode_need_killpriv returns 1 if security.capability exists and > has a value and inode_killpriv() is required, 0 otherwise. Fix the > description of the return value to reflect this. > > Signed-off-by: Stefan Berger Thanks,

[PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

From: Liwei Song This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup common access width firmware bug") fix the following firmware bug: [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1] This is due to an 8-bit access width is specified

[PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

From: Liwei Song This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup common access width firmware bug") fix the following firmware bug: [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1] This is due to an 8-bit access width is specified for a 16-bit register,

Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters

On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote: > On 07/26/2017 01:08 PM, Greg KH wrote: > > On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote: > > > On 07/26/2017 10:33 AM, Greg KH wrote: > > > > On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote: > > > > > On

Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters

On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote: > On 07/26/2017 01:08 PM, Greg KH wrote: > > On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote: > > > On 07/26/2017 10:33 AM, Greg KH wrote: > > > > On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote: > > > > > On

[PATCH v2] security: fix description of values returned by cap_inode_need_killpriv

cap_inode_need_killpriv returns 1 if security.capability exists and has a value and inode_killpriv() is required, 0 otherwise. Fix the description of the return value to reflect this. Signed-off-by: Stefan Berger --- security/commoncap.c | 6 +++--- 1 file changed, 3

[PATCH v2] security: fix description of values returned by cap_inode_need_killpriv

cap_inode_need_killpriv returns 1 if security.capability exists and has a value and inode_killpriv() is required, 0 otherwise. Fix the description of the return value to reflect this. Signed-off-by: Stefan Berger --- security/commoncap.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH v2 4/5] usb: xhci: Return error when host is dead in xhci_disable_slot()

xhci_disable_slot() is a helper for disabling a slot when a device goes away or recovers from error situations. Currently, it returns success when it sees a dead host. This is not the right way to go. It should return error and let the invoker know that disable slot command was failed due to a

[PATCH v2 3/5] usb: xhci: Fix memory leak when xhci_disable_slot() returns error

If xhci_disable_slot() returns success, a disable slot command trb was queued in the command ring. The command completion handler will free the virtual device data structure associated with the slot. On the other hand, when xhci_disable_slot() returns error, the invokers should take the

[PATCH v2 2/5] usb: xhci: Fix potential memory leak in xhci_disable_slot()

xhci_disable_slot() allows the invoker to pass a command pointer as paramenter. Otherwise, it will allocate one. This will cause memory leak when a command structure was allocated inside of this function while queuing command trb fails. Another problem comes up when the invoker passed a command

[PATCH v2 4/5] usb: xhci: Return error when host is dead in xhci_disable_slot()

xhci_disable_slot() is a helper for disabling a slot when a device goes away or recovers from error situations. Currently, it returns success when it sees a dead host. This is not the right way to go. It should return error and let the invoker know that disable slot command was failed due to a

[PATCH v2 3/5] usb: xhci: Fix memory leak when xhci_disable_slot() returns error

If xhci_disable_slot() returns success, a disable slot command trb was queued in the command ring. The command completion handler will free the virtual device data structure associated with the slot. On the other hand, when xhci_disable_slot() returns error, the invokers should take the

[PATCH v2 2/5] usb: xhci: Fix potential memory leak in xhci_disable_slot()

xhci_disable_slot() allows the invoker to pass a command pointer as paramenter. Otherwise, it will allocate one. This will cause memory leak when a command structure was allocated inside of this function while queuing command trb fails. Another problem comes up when the invoker passed a command

[PATCH v2 5/5] usb: xhci: Handle USB transaction error on address command

Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response

[PATCH v2 5/5] usb: xhci: Handle USB transaction error on address command

Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response

[PATCH v2 1/5] usb: xhci: Disable slot even virt-dev is null

xhci_disable_slot() is a helper for disabling a slot when a device goes away or recovers from error situations. Currently, it checks the corespoding virt-dev pointer and returns directly (w/o issuing disable slot command) if it's null. This is unnecessary and will cause problems in case where

[PATCH v2 1/5] usb: xhci: Disable slot even virt-dev is null

xhci_disable_slot() is a helper for disabling a slot when a device goes away or recovers from error situations. Currently, it checks the corespoding virt-dev pointer and returns directly (w/o issuing disable slot command) if it's null. This is unnecessary and will cause problems in case where

[PATCH v2 0/5] usb: xhci: Handle USB transaction error on address command

Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response

[PATCH v2 0/5] usb: xhci: Handle USB transaction error on address command

Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response

Re: gigantic hugepages vs. movable zones

Michal Hocko writes: > Hi, > I've just noticed that alloc_gigantic_page ignores movability of the > gigantic page and it uses any existing zone. Considering that > hugepage_migration_supported only supports 2MB and pgd level hugepages > then 1GB pages are not migratable and as

Re: gigantic hugepages vs. movable zones

Michal Hocko writes: > Hi, > I've just noticed that alloc_gigantic_page ignores movability of the > gigantic page and it uses any existing zone. Considering that > hugepage_migration_supported only supports 2MB and pgd level hugepages > then 1GB pages are not migratable and as such allocating

Re: [PATCH 05/11] powerpc/topology: Remove the unused parent_node() macro

Dou Liyang writes: > Commit a7be6e5a7f8d ("mm: drop useless local parameters of > __register_one_node()") removes the last user of parent_node(). > > The parent_node() macro in POWERPC platform is unnecessary. > > Remove it for cleanup. > > Reported-by: Michael

Re: [PATCH 05/11] powerpc/topology: Remove the unused parent_node() macro

Dou Liyang writes: > Commit a7be6e5a7f8d ("mm: drop useless local parameters of > __register_one_node()") removes the last user of parent_node(). > > The parent_node() macro in POWERPC platform is unnecessary. > > Remove it for cleanup. > > Reported-by: Michael Ellerman > Signed-off-by: Dou

Re: ARM64 board Hikey960 boot failure due to f2545b2d4ce1 (jump_label: Reorder hotplug lock and jump_label_lock)

On Wed, Jul 26, 2017 at 04:13:49PM +0100, Marc Zyngier wrote: > [+Mark] > > Hi Leo, > > On 24/07/17 15:34, Leo Yan wrote: > > Hi all, > > > > We found the mainline arm64 kernel boot failure on Hikey960 board, > > this is caused by patch f2545b2d4ce1 (jump_label: Reorder hotplug lock > > and

Re: ARM64 board Hikey960 boot failure due to f2545b2d4ce1 (jump_label: Reorder hotplug lock and jump_label_lock)

On Wed, Jul 26, 2017 at 04:13:49PM +0100, Marc Zyngier wrote: > [+Mark] > > Hi Leo, > > On 24/07/17 15:34, Leo Yan wrote: > > Hi all, > > > > We found the mainline arm64 kernel boot failure on Hikey960 board, > > this is caused by patch f2545b2d4ce1 (jump_label: Reorder hotplug lock > > and

Re: [PATCH v2] scsi: qedf: Limit number of CQs

Thomas, > FCOE offloading failed with: > > [qed_sp_fcoe_func_start:150(sp-0-3b:00.02)]Cannot satisfy CQ amount. CQs >requested 8, CQs available 6. Aborting function start > [qed_fcoe_start:821()]Failed to start fcoe > [__qedf_probe:3041]:6: Cannot start FCoE function. > > The

Re: [PATCH v2] scsi: qedf: Limit number of CQs

Thomas, > FCOE offloading failed with: > > [qed_sp_fcoe_func_start:150(sp-0-3b:00.02)]Cannot satisfy CQ amount. CQs >requested 8, CQs available 6. Aborting function start > [qed_fcoe_start:821()]Failed to start fcoe > [__qedf_probe:3041]:6: Cannot start FCoE function. > > The

[PATCH 0/3] Add larbid init routine for mediatek's gen1 smi larb driver

From: Honghui Zhang Mediatek's gen1 smi need the hardware larbid to identify the offset for the register which controls whether enable iommu for this larb. In the commit 3c8f4ad85c4b ("memory/mediatek: add support for mt2701"), the larbid was used without properly

[PATCH 0/3] Add larbid init routine for mediatek's gen1 smi larb driver

From: Honghui Zhang Mediatek's gen1 smi need the hardware larbid to identify the offset for the register which controls whether enable iommu for this larb. In the commit 3c8f4ad85c4b ("memory/mediatek: add support for mt2701"), the larbid was used without properly initialized. This patchset

[PATCH 3/3] arm: dts: mediatek: add larbid property for larb

From: Honghui Zhang Add mediatek's hardware id information for smi larb. Signed-off-by: Honghui Zhang --- arch/arm/boot/dts/mt2701.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/mt2701.dtsi

[PATCH 1/3] memory: mtk-smi: add larbid init routine

From: Honghui Zhang In the commit 3c8f4ad85c4b ("memory/mediatek: add support for mt2701"), the larb->larbid was added but not initialized. Mediatek's gen1 smi need this hardware larbid information to get the register offset which controls whether enable iommu for

[PATCH 3/3] arm: dts: mediatek: add larbid property for larb

From: Honghui Zhang Add mediatek's hardware id information for smi larb. Signed-off-by: Honghui Zhang --- arch/arm/boot/dts/mt2701.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi index f1efdc6..2cddbec 100644 ---

[PATCH 1/3] memory: mtk-smi: add larbid init routine

From: Honghui Zhang In the commit 3c8f4ad85c4b ("memory/mediatek: add support for mt2701"), the larb->larbid was added but not initialized. Mediatek's gen1 smi need this hardware larbid information to get the register offset which controls whether enable iommu for this larb. This patch add the

[PATCH 2/3] dt-bindings: mediatek: add descriptions for larbid

From: Honghui Zhang This patch add larbid descritptions for mediatek's gen1 smi larb hardware. Signed-off-by: Honghui Zhang --- .../bindings/memory-controllers/mediatek,smi-larb.txt | 15 +++ 1 file changed, 15

[PATCH 2/3] dt-bindings: mediatek: add descriptions for larbid

From: Honghui Zhang This patch add larbid descritptions for mediatek's gen1 smi larb hardware. Signed-off-by: Honghui Zhang --- .../bindings/memory-controllers/mediatek,smi-larb.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git

Re: [patch 0/5] scsi/bnx2*: Plug hotplug race, correct locking and simplify hotplug code

Thomas, > The conversion of the cpu hotplug locking to a percpu rwsem does not > longer allow recursive locking of the hotplug lock. > > The BNX2I and BNX2FC drivers install/remove hotplug states with the > hotplug lock held. The install/removal code acquired the hotplug lock > as well. > >

Re: [patch 0/5] scsi/bnx2*: Plug hotplug race, correct locking and simplify hotplug code

Thomas, > The conversion of the cpu hotplug locking to a percpu rwsem does not > longer allow recursive locking of the hotplug lock. > > The BNX2I and BNX2FC drivers install/remove hotplug states with the > hotplug lock held. The install/removal code acquired the hotplug lock > as well. > >

[PATCH] staging: unisys: visorchipset: constify attribute_group structure

Functions working with attribute_groups provided by work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 24124 6216 448 307887844

[PATCH] staging: unisys: visorchipset: constify attribute_group structure

Functions working with attribute_groups provided by work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 24124 6216 448 307887844

Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option

On Wed, Jul 26, 2017 at 02:11:46PM -0700, Paul E. McKenney wrote: > On Wed, Jul 26, 2017 at 08:37:23PM +, Mathieu Desnoyers wrote: > > - On Jul 26, 2017, at 2:30 PM, Paul E. McKenney > > paul...@linux.vnet.ibm.com wrote: > > > > > On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu

Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option

On Wed, Jul 26, 2017 at 02:11:46PM -0700, Paul E. McKenney wrote: > On Wed, Jul 26, 2017 at 08:37:23PM +, Mathieu Desnoyers wrote: > > - On Jul 26, 2017, at 2:30 PM, Paul E. McKenney > > paul...@linux.vnet.ibm.com wrote: > > > > > On Wed, Jul 26, 2017 at 06:01:15PM +, Mathieu

Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate

Hi Kurt, On 07/26/2017 03:04 PM, Kurt Van Dijck wrote: > Hi, > > I know my response is late ... > >> Hi Oliver >> On 07/20/2017 02:43 AM, Oliver Hartkopp wrote: >>> Hi Franklin, >>> >>> On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote: >>> +#ifdef CONFIG_OF +void

Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate

Hi Kurt, On 07/26/2017 03:04 PM, Kurt Van Dijck wrote: > Hi, > > I know my response is late ... > >> Hi Oliver >> On 07/20/2017 02:43 AM, Oliver Hartkopp wrote: >>> Hi Franklin, >>> >>> On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote: >>> +#ifdef CONFIG_OF +void

Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync

On 2017年07月26日 22:16, Thomas Gleixner wrote: On Wed, 26 Jul 2017, qiaozhou wrote: Cc'ed ARM folks. I want to ask you for suggestions about how to fix one contention between expire_timers and try_to_del_timer_sync. Thanks in advance. The issue is a hard-lockup issue detected on our

Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync

On 2017年07月26日 22:16, Thomas Gleixner wrote: On Wed, 26 Jul 2017, qiaozhou wrote: Cc'ed ARM folks. I want to ask you for suggestions about how to fix one contention between expire_timers and try_to_del_timer_sync. Thanks in advance. The issue is a hard-lockup issue detected on our

[PATCH v3/resubmit 1/3] staging: gs_fpgaboot: add buffer overflow checks

Four fields in struct fpgaimage are char arrays of length MAX_STR (256). The amount of data read into these buffers is controlled by a length field in the bitstream file read from userspace. If a corrupt or malicious firmware file was supplied, kernel data beyond these buffers can be overwritten

[PATCH v3/resubmit 2/3] staging: gs_fpgaboot: change char to u8

The bitstream storage variables were changed from char to u8 arrays to prevent issues such as negative lengths. This change makes the code compatible with the "data" field in "struct firmware" which is of type u8. Signed-off-by: Jacob von Chorus v3: - reduce temporary

[PATCH v3/resubmit 1/3] staging: gs_fpgaboot: add buffer overflow checks

Four fields in struct fpgaimage are char arrays of length MAX_STR (256). The amount of data read into these buffers is controlled by a length field in the bitstream file read from userspace. If a corrupt or malicious firmware file was supplied, kernel data beyond these buffers can be overwritten

[PATCH v3/resubmit 2/3] staging: gs_fpgaboot: change char to u8

The bitstream storage variables were changed from char to u8 arrays to prevent issues such as negative lengths. This change makes the code compatible with the "data" field in "struct firmware" which is of type u8. Signed-off-by: Jacob von Chorus v3: - reduce temporary buffer size in bitstream

[PATCH v3/resubmit 3/3] staging: gs_fpgaboot: return valid error codes

The return values on error are modified to be valid error codes. Theses error codes are propagated back to the init function's return. Signed-off-by: Jacob von Chorus --- drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 14 +++--- 1 file changed, 7 insertions(+), 7

[PATCH v3/resubmit 3/3] staging: gs_fpgaboot: return valid error codes

The return values on error are modified to be valid error codes. Theses error codes are propagated back to the init function's return. Signed-off-by: Jacob von Chorus --- drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On 2017/7/27 2:26, Casey Leedom wrote: > By the way Ding, two issues: > > 1. Did we ever get any acknowledgement from either Intel or AMD > on this patch? I know that we can't ensure that, but it sure would > be nice since the PCI Quirks that we're putting in affect their >

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On 2017/7/27 2:26, Casey Leedom wrote: > By the way Ding, two issues: > > 1. Did we ever get any acknowledgement from either Intel or AMD > on this patch? I know that we can't ensure that, but it sure would > be nice since the PCI Quirks that we're putting in affect their >

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

[Added linux-usb mailing list to CC:] Short description of bug: In 4.12 or later, when Zdenek's Western Digital disk is attached to an EHCI controller, it ends up connecting at full speed to the companion UHCI controller instead. But when commit 22547c4cc4fe ("usb: hub: Wait for connection to be

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

[Added linux-usb mailing list to CC:] Short description of bug: In 4.12 or later, when Zdenek's Western Digital disk is attached to an EHCI controller, it ends up connecting at full speed to the companion UHCI controller instead. But when commit 22547c4cc4fe ("usb: hub: Wait for connection to be

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On 2017/7/27 3:05, Casey Leedom wrote: > | From: Alexander Duyck > | Sent: Wednesday, July 26, 2017 11:44 AM > | > | On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote: > | | > | | I think that the patch will need to be extended to modify > | |

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On 2017/7/27 3:05, Casey Leedom wrote: > | From: Alexander Duyck > | Sent: Wednesday, July 26, 2017 11:44 AM > | > | On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote: > | | > | | I think that the patch will need to be extended to modify > | | drivers/pci.c/iov.c:sriov_enable() to

[PATCH] selftests: sigaltstack: convert to use TAP13 ksft framework

Convert to use TAP13 ksft framework to output results. Signed-off-by: Shuah Khan --- tools/testing/selftests/sigaltstack/sas.c | 53 ++- 1 file changed, 31 insertions(+), 22 deletions(-) diff --git a/tools/testing/selftests/sigaltstack/sas.c

[PATCH] selftests: sigaltstack: convert to use TAP13 ksft framework

Convert to use TAP13 ksft framework to output results. Signed-off-by: Shuah Khan --- tools/testing/selftests/sigaltstack/sas.c | 53 ++- 1 file changed, 31 insertions(+), 22 deletions(-) diff --git a/tools/testing/selftests/sigaltstack/sas.c

Re: [PATCH] mtd: dataflash: Use ULL suffix for 64-bit constants

On Sat, Jul 15, 2017 at 12:59 AM, Geert Uytterhoeven wrote: > With gcc 4.1.2: > > drivers/mtd/devices/mtd_dataflash.c:740: warning: integer constant is too > large for ‘long’ type > drivers/mtd/devices/mtd_dataflash.c:741: warning: integer constant is too > large

Re: [PATCH] mtd: dataflash: Use ULL suffix for 64-bit constants

On Sat, Jul 15, 2017 at 12:59 AM, Geert Uytterhoeven wrote: > With gcc 4.1.2: > > drivers/mtd/devices/mtd_dataflash.c:740: warning: integer constant is too > large for ‘long’ type > drivers/mtd/devices/mtd_dataflash.c:741: warning: integer constant is too > large for ‘long’ type > > Add

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

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 7/25/2017 5:21 PM, Stefano Stabellini wrote: > > Implement the probe function for the pvcalls frontend. Read the > > supported versions, max-page-order and function-calls nodes from > > xenstore. > > > > Introduce a data structure named

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

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 7/25/2017 5:21 PM, Stefano Stabellini wrote: > > Implement the probe function for the pvcalls frontend. Read the > > supported versions, max-page-order and function-calls nodes from > > xenstore. > > > > Introduce a data structure named

Re: [PATCH v2 10/13] xen/pvcalls: implement poll command

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 07/25/2017 05:22 PM, Stefano Stabellini wrote: > > For active sockets, check the indexes and use the inflight_conn_req > > waitqueue to wait. > > > > For passive sockets, send PVCALLS_POLL to the backend. Use the > > inflight_accept_req waitqueue if

Re: [PATCH v2 10/13] xen/pvcalls: implement poll command

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 07/25/2017 05:22 PM, Stefano Stabellini wrote: > > For active sockets, check the indexes and use the inflight_conn_req > > waitqueue to wait. > > > > For passive sockets, send PVCALLS_POLL to the backend. Use the > > inflight_accept_req waitqueue if

Re: [PATCH net-next v2 07/10] net: dsa: lan9303: Added basic offloading of unicast traffic

Hi Egil, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Egil-Hjelmeland/net-dsa-lan9303-unicast-offload-fdb-mdb-STP/20170727-074246 config: x86_64-randconfig-x000-201730 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901

Re: [PATCH net-next v2 07/10] net: dsa: lan9303: Added basic offloading of unicast traffic

Hi Egil, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Egil-Hjelmeland/net-dsa-lan9303-unicast-offload-fdb-mdb-STP/20170727-074246 config: x86_64-randconfig-x000-201730 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901

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