[PATCH] Replace the type check code with typecheck() in kfifo_in

suggestion, this patch replace this with typecheck() which will be easy to understand. In the same file, there are several places with the same code style. This patch change them too. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com Reviewed-by: Andrew Morton a...@linux-foundation.org Reviewed

[PATCH] Fix the warning related to type check in kfifo.h

. kfifo_in_locked() second parameter should be type const void * Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- arch/arm/plat-omap/mailbox.c|8 drivers/char/sonypi.c |8 drivers/hid/hid-logitech-dj.c |8

[PATCH] remove untouched code in kfifo_in

In kfifo_in marco, one piece of code is arounded by if(0). This code in introduced by Stefani Seibold stef...@seibold.net to suppress a compiler warning. This warning is not there with the upgrade of gcc version. This patch just remove this code. --- include/linux/kfifo.h |4 1 files

Re: [PATCH 2/2] driver-core: remove the duplicate assignment of kobj-parent in device_add

, 2013 at 11:22:44PM +0800, Wei Yang wrote: On Thu, Mar 07, 2013 at 03:49:12PM +0100, Bjørn Mork wrote: [ not stripping any quoting to restore context for linux-kernel] Wei Yang weiy...@linux.vnet.ibm.com writes: On Thu, Mar 07, 2013 at 12:33:19PM +0100, Bjørn Mork wrote: Wei Yang weiy

Re: [PATCH 1/2] driver core: remove device_add_attrs() in drivers/base/bus.c

On Mon, Mar 18, 2013 at 05:18:22PM -0700, Greg KH wrote: On Thu, Mar 07, 2013 at 10:22:45AM +0800, Wei Yang wrote: Originally, we have two functions named device_add_attrs() in drivers/base/bus.c and drivers/base/core.c. This will cause some confusion when reading the code. Why? It's just

Re: [PATCH 0/2] Some cleanup in driver core

On Mon, Mar 18, 2013 at 05:17:08PM -0700, Greg KH wrote: On Thu, Mar 07, 2013 at 10:22:44AM +0800, Wei Yang wrote: These two patches do some cleanup in the driver core. No they do not. I understand the need to fix code, but please, do so if it is broken. These patches don't help, and in fact

[PATCH 0/2] Some cleanup in driver core

These two patches do some cleanup in the driver core. They are tested on: Hardware: Lenovo T420 Kernel Version: 3.8 Result: * /sys/devices/pci:00/ directory is correct * /sys/devices/pci:00/:00:19.0/ contains the sysfs files for a pci device Wei Yang (2): driver core

[PATCH 2/2] driver-core: remove the duplicate assignment of kobj-parent in device_add

kobject_add() will setup the kobject parent correctly. This patch removes the redundant code. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com Reviewed-by: Ram Pai linux...@us.ibm.com Reviewed-by: Gavin Shan sha...@linux.vnet.ibm.com --- drivers/base/core.c |4 +--- 1 files changed, 1

[PATCH 1/2] driver core: remove device_add_attrs() in drivers/base/bus.c

this code. This patch just do some cleanup. Remove the device_add_attrs() in drivers/base/bus.c and call device_add_attributes() directly. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com Reviewed-by: Gavin Shan sha...@linux.vnet.ibm.com --- drivers/base/bus.c | 21

[PATCH] driver-core: remove the duplicate assignment of kobj-parent in device_add

kobject_add() will setup the kobject parent correctly. This patch removes the redundant code. Tested on Lenovo T420. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com Reviewed-by: Ram Pai linux...@us.ibm.com Reviewed-by: Gavin Shan sha...@linux.vnet.ibm.com --- drivers/base/core.c |4

Re: [PATCH 2/2] powerpc/iommu: check dev-iommu_group before remove a device from iommu_group

On Fri, Aug 16, 2013 at 08:15:36PM +1000, Alexey Kardashevskiy wrote: On 08/16/2013 08:08 PM, Wei Yang wrote: --- arch/powerpc/kernel/iommu.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index b20ff17

Re: [PATCH 2/2] powerpc/iommu: check dev-iommu_group before remove a device from iommu_group

On Mon, Aug 19, 2013 at 11:39:49AM +1000, Alexey Kardashevskiy wrote: On 08/19/2013 11:29 AM, Wei Yang wrote: On Fri, Aug 16, 2013 at 08:15:36PM +1000, Alexey Kardashevskiy wrote: On 08/16/2013 08:08 PM, Wei Yang wrote: --- arch/powerpc/kernel/iommu.c |3 ++- 1 files changed, 2

Re: [PATCH 2/2] powerpc/iommu: check dev-iommu_group before remove a device from iommu_group

On Thu, Aug 22, 2013 at 05:23:34PM +1000, Alexey Kardashevskiy wrote: On 08/19/2013 11:55 AM, Wei Yang wrote: On Mon, Aug 19, 2013 at 11:39:49AM +1000, Alexey Kardashevskiy wrote: On 08/19/2013 11:29 AM, Wei Yang wrote: On Fri, Aug 16, 2013 at 08:15:36PM +1000, Alexey Kardashevskiy wrote

Re: [PATCH 2/2] powerpc/iommu: check dev-iommu_group before remove a device from iommu_group

On Thu, Aug 22, 2013 at 09:28:23AM -0600, Alex Williamson wrote: On Thu, 2013-08-22 at 15:52 +0800, Wei Yang wrote: On Thu, Aug 22, 2013 at 05:23:34PM +1000, Alexey Kardashevskiy wrote: On 08/19/2013 11:55 AM, Wei Yang wrote: On Mon, Aug 19, 2013 at 11:39:49AM +1000, Alexey Kardashevskiy wrote

Re: [PATCH 2/2] powerpc/iommu: check dev-iommu_group before remove a device from iommu_group

On Thu, Aug 22, 2013 at 10:17:20AM -0600, Alex Williamson wrote: On Thu, 2013-08-22 at 23:41 +0800, Wei Yang wrote: Alex, Sorry for not including you in the very beginning, which may spend you more efforts to track previous mails in this thread. Do you think it is reasonable

[PATCH] iommu: WARN_ON when removing a device with no iommu_group associated

with dev-iommu_group set to NULL. This helps to indicate some bad behavior and also guard the kernel. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- drivers/iommu/iommu.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu

Re: [PATCH v2] KVM: PPC: move iommu_add_device earlier

the removing without the check outside. Author: Wei Yang weiy...@linux.vnet.ibm.com Date: Wed Aug 14 04:45:06 2013 -0400 iommu: check dev-iommu_group before removing a device In some cases, one device may not associate with any iommu_group. For example, not enough DMA address

[PATCH 0/2] powerpc/iommu: check dev-iommu_group before remove it

in advance. Wei Yang (2): iommu: Don't remove device when no iommu_group associated powerpc/iommu: check dev-iommu_group before remove a device from iommu_group arch/powerpc/kernel/iommu.c |3 ++- drivers/iommu/iommu.c |3 +++ 2 files changed, 5 insertions(+), 1 deletions

[PATCH 2/2] powerpc/iommu: check dev-iommu_group before remove a device from iommu_group

--- arch/powerpc/kernel/iommu.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index b20ff17..5abf7c3 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -1149,7 +1149,8 @@ static int

[PATCH 1/2] iommu: Don't remove device when no iommu_group associated

In some cases, one device may not associated with any iommu_group. For example, not enough DMA address space. For those devices, kernel will crash when try to remove it from an iommu_group. This patch do the check before remove it. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- drivers

[PATCH 1/3] percpu: stop the loop when a cpu belongs to a new group

When a cpu belongs to a new group, there is no cpu has the same group id. This means it can be assigned a new group id without checking with every others. This patch does this optimiztion. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- mm/percpu.c |5 - 1 files changed, 4

[PATCH 2/3] percpu: merge two loops when setting up group info

There are two loops setting up the group info of pcpu_alloc_info. They share the same logic, so merge them could be time efficient when there are many groups. This patch merge these two loops into one. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- mm/percpu.c |8 +++- 1 files

[PATCH 3/3] percpu: little optimization on calculating pcpu_unit_size

pcpu_unit_size exactly equals to ai-unit_size. This patch assign this value instead of calculating from pcpu_unit_pages. Also it reorder them to make it looks more friendly to audience. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- mm/percpu.c |4 ++-- 1 files changed, 2 insertions

Re: [PATCH 1/3] percpu: stop the loop when a cpu belongs to a new group

On Fri, Nov 22, 2013 at 06:04:00PM -0500, Tejun Heo wrote: Hello, On Wed, Nov 20, 2013 at 12:51:21AM -0500, Tejun Heo wrote: The patch is just extremely marginal. Ah well... why not? I'll apply it once -rc1 drops. So, I was about to apply this patch but decided against it. It doesn't really

Re: [PATCH 1/3] percpu: stop the loop when a cpu belongs to a new group

On Mon, Oct 28, 2013 at 11:17:46PM +0800, Wei Yang wrote: On Mon, Oct 28, 2013 at 07:31:20AM -0400, Tejun Heo wrote: Hello, On Mon, Oct 28, 2013 at 11:00:55AM +0800, Wei Yang wrote: Does this actually matter? If so, it'd probably make a lot more sense to start inner loop at @cpu + 1 so

Re: [PATCH 1/3] percpu: stop the loop when a cpu belongs to a new group

On Wed, Nov 20, 2013 at 12:51:21AM -0500, Tejun Heo wrote: Hello, On Wed, Nov 20, 2013 at 11:00:56AM +0800, Wei Yang wrote: What do you think about this one? From bd70498b9df47b25ff20054e24bb510c5430c0c3 Mon Sep 17 00:00:00 2001 From: Wei Yang weiy...@linux.vnet.ibm.com Date: Thu, 10 Oct

Re: [PATCH] perf: fix two warning in bench/numa

Dear maintainer, Is this one accepted or droped? Or I missed the right person? On Sun, Sep 22, 2013 at 04:49:24PM +0800, Wei Yang wrote: There two warnings in bench/numa, when buiding this on 32-bit machine. The warning output is attached: bench/numa.c:1113:20: error: comparison between

Re: [PATCH 2/3] percpu: merge two loops when setting up group info

On Sun, Oct 27, 2013 at 08:35:42AM -0400, Tejun Heo wrote: On Mon, Oct 21, 2013 at 04:58:12PM +0800, Wei Yang wrote: There are two loops setting up the group info of pcpu_alloc_info. They share the same logic, so merge them could be time efficient when there are many groups. This patch merge

Re: [PATCH 3/3] percpu: little optimization on calculating pcpu_unit_size

On Sun, Oct 27, 2013 at 08:36:34AM -0400, Tejun Heo wrote: On Mon, Oct 21, 2013 at 04:58:13PM +0800, Wei Yang wrote: pcpu_unit_size exactly equals to ai-unit_size. This patch assign this value instead of calculating from pcpu_unit_pages. Also it reorder them to make it looks more friendly

Re: [PATCH 1/3] percpu: stop the loop when a cpu belongs to a new group

On Sun, Oct 27, 2013 at 08:30:08AM -0400, Tejun Heo wrote: On Mon, Oct 21, 2013 at 04:58:11PM +0800, Wei Yang wrote: When a cpu belongs to a new group, there is no cpu has the same group id. This means it can be assigned a new group id without checking with every others. This patch does

Re: [PATCH 1/3] percpu: stop the loop when a cpu belongs to a new group

On Mon, Oct 28, 2013 at 07:31:20AM -0400, Tejun Heo wrote: Hello, On Mon, Oct 28, 2013 at 11:00:55AM +0800, Wei Yang wrote: Does this actually matter? If so, it'd probably make a lot more sense to start inner loop at @cpu + 1 so that it becomes O(N). One of the worst case in my mind: CPU

Re: [PATCH] iommu: WARN_ON when removing a device with no iommu_group associated

Any more comments? Or this one is not proper? On Thu, Aug 22, 2013 at 09:33:27PM -0600, Alex Williamson wrote: [+cc iommu] On Fri, 2013-08-23 at 09:55 +0800, Wei Yang wrote: When removing a device from the system, iommu_group driver will try to disconnect it from its group. While in some cases

[PATCH] perf: fix two warning in bench/numa

int’, but argument 5 has type ‘u64’ [-Werror=format] This patch fixs these two warnings. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- tools/perf/bench/numa.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c index

Re: [PATCH] perf: fix two warning in bench/numa

Hi, all Any comments on this one? These two warnings will break the compile of perf under 32-bit machine. On Sun, Sep 22, 2013 at 04:49:24PM +0800, Wei Yang wrote: There two warnings in bench/numa, when buiding this on 32-bit machine. The warning output is attached: bench/numa.c:1113:20

Re: [PATCH] perf: fix two warning in bench/numa

On Wed, Sep 25, 2013 at 01:26:29PM +0200, Ingo Molnar wrote: * Wei Yang weiy...@linux.vnet.ibm.com wrote: Hi, all Any comments on this one? These two warnings will break the compile of perf under 32-bit machine. fix looks good to me. Thanks for your comments

Re: [PATCH] drivercore: refine commit 58b116b drivercore: deferral race condition fix

On Wed, May 28, 2014 at 01:52:45PM -0700, Greg KH wrote: On Wed, May 21, 2014 at 11:21:43AM +0800, Wei Yang wrote: Hi~ Is this fix reasonable? I'll leave this up to Grant... Grant, Do you have some comment? -- Richard Yang Help you, Help me -- To unsubscribe from this list: send

[PATCH] drivercore: refine commit 58b116b drivercore: deferral race condition fix

the driver_deferred_probe_trigger() is only called when a driver is successfully probed. Move the comparison in the loop of deferred probe. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- drivers/base/base.h |2 +- drivers/base/bus.c |3 ++- drivers/base/dd.c | 44

Re: [PATCH] drivercore: refine commit 58b116b drivercore: deferral race condition fix

Hi~ Is this fix reasonable? On Fri, May 09, 2014 at 01:19:59PM +0800, Wei Yang wrote: The commit 58b116b fixs a race condition in which some driver will stuck in the deferred list, while introduces another case probe flood. The root cause is in commit 58b116b, deferred_trigger_count

Re: [PATCH 6/9] powerpc/pci: Use dev_is_pci() to check whether it is pci device

Yijing, This one looks good. While I take a look at the source code, there are around 20 places with similar style. Do you think it would be good to change all these places in one patch? On Thu, Dec 05, 2013 at 08:01:20PM +0800, Yijing Wang wrote: Use PCI standard marco dev_is_pci() instead of

Re: [PATCH 6/9] powerpc/pci: Use dev_is_pci() to check whether it is pci device

On Mon, Dec 16, 2013 at 05:05:05PM +0800, Yijing Wang wrote: On 2013/12/16 15:13, Wei Yang wrote: Yijing, This one looks good. While I take a look at the source code, there are around 20 places with similar style. Do you think it would be good to change all these places in one patch? I

Re: [PATCH] drivercore: fix a corner case for deferred probe

Hi, all Anyone has some comment on this? On Mon, Apr 21, 2014 at 09:53:22AM +0800, Wei Yang wrote: There is one corner case in deferred probe which will lead a device in dream in the deferred_probe_pending_list. Suppose we have three devices, Tom, Jerry and Spike. Tom and Jerry have a close

Re: [PATCH] drivercore: fix a corner case for deferred probe

On Sun, May 04, 2014 at 08:04:32PM -0700, Greg KH wrote: On Mon, May 05, 2014 at 10:28:05AM +0800, Wei Yang wrote: Hi, all Anyone has some comment on this? Did you miss the patch from Grant that is now in Linus's tree that should resolve this issue? Hi, Greg, Nice to hear from you. Would

[PATCH] drivercore: fix a corner case for deferred probe

itself to active list again. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- drivers/base/base.h |2 +- drivers/base/bus.c |3 ++- drivers/base/dd.c | 14 +- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/base/base.h b/drivers/base/base.h index

[PATCH] slub: reduce duplicate creation on the first object

for scanning objects in a slab. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- mm/slub.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index b2b0473..beefd45 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1433,7 +1433,7 @@ static struct page

Re: [PATCH] drivercore: refine commit 58b116b drivercore: deferral race condition fix

On Wed, May 28, 2014 at 01:52:45PM -0700, Greg KH wrote: On Wed, May 21, 2014 at 11:21:43AM +0800, Wei Yang wrote: Hi~ Is this fix reasonable? I'll leave this up to Grant... Hmm... not sure this is missed or Grant's mail address is not correct? -- Richard Yang Help you, Help me

Re: [PATCH 3.10 26/52] net/mlx4_core: Preserve pci_dev_data after __mlx4_remove_one()

On Wed, Jun 25, 2014 at 09:02:26AM +0300, Or Gerlitz wrote: On 24/06/2014 18:50, Greg Kroah-Hartman wrote: 3.10-stable review patch. If anyone has any objections, please let me know. -- From: Wei Yang weiy...@linux.vnet.ibm.com [ Upstream commit

[PATCH] rbtree: fix typo in comment of __rb_insert()

. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- lib/rbtree.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/rbtree.c b/lib/rbtree.c index 65f4eff..c16c81a 100644 --- a/lib/rbtree.c +++ b/lib/rbtree.c @@ -101,7 +101,7 @@ __rb_insert(struct rb_node *node, struct

Re: mm: slub: invalid memory access in setup_object

* *Version: 1.0 *Created: 04/26/2014 09:12:04 PM * Revision: none * Compiler: gcc * * Author: Wei Yang (weiyang), weiyang.ker...@gmail.com *Company

Re: mm: slub: invalid memory access in setup_object

On Mon, Jul 07, 2014 at 08:51:08AM -0500, Christoph Lameter wrote: On Thu, 3 Jul 2014, Wei Yang wrote: Here is my refined version, hope this is more friendly to the audience. Acked-by: Christoph Lameter c...@linux.com Thanks. I am glad to work with you. -- Richard Yang Help you, Help me

Re: mm: slub: invalid memory access in setup_object

On Tue, Jul 01, 2014 at 09:58:52AM -0500, Christoph Lameter wrote: On Mon, 30 Jun 2014, David Rientjes wrote: It's not at all clear to me that that patch is correct. Wei? Looks ok to me. But I do not like the convoluted code in new_slab() which Wei's patch does not make easier to read. Makes

Re: mm: slub: invalid memory access in setup_object

On Tue, Jul 01, 2014 at 02:49:47PM -0700, Andrew Morton wrote: On Tue, 1 Jul 2014 09:58:52 -0500 (CDT) Christoph Lameter c...@gentwo.org wrote: On Mon, 30 Jun 2014, David Rientjes wrote: It's not at all clear to me that that patch is correct. Wei? Looks ok to me. But I do not like the

Re: mm: slub: invalid memory access in setup_object

On Tue, Jul 01, 2014 at 02:49:47PM -0700, Andrew Morton wrote: On Tue, 1 Jul 2014 09:58:52 -0500 (CDT) Christoph Lameter c...@gentwo.org wrote: On Mon, 30 Jun 2014, David Rientjes wrote: It's not at all clear to me that that patch is correct. Wei? Looks ok to me. But I do not like the

Re: mm: slub: invalid memory access in setup_object

On Wed, Jul 02, 2014 at 09:20:20AM -0500, Christoph Lameter wrote: On Wed, 2 Jul 2014, Wei Yang wrote: My patch is somewhat convoluted since I wanted to preserve the original logic and make minimal change. And yes, it looks not that nice to audience. Well I was the author of the initial

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote: Enhance the default implementation of pcibios_add_device() to parse and map the IRQ of the device if a DT binding is available. Cc: Bjorn Helgaas bhelg...@google.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote: On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote: On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote: Enhance the default implementation of pcibios_add_device() to parse and map the IRQ of the device if a DT binding

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote: On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote: On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote: On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote: On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote: ... Well, it will become necessary as old code gets dismantled and converted towards this patchset. To give you an example that I'm familiar with, for arch/arm the host bridge drivers have moved into drivers/pci/host, but they

Re: [PATCH] pci/probe: Enable CRS for Intel Haswell root ports

On Thu, Aug 28, 2014 at 02:55:25PM -0700, Rajat Jain wrote: The PCIe root port of the Intel Haswell CPU, has a behavior to endlessly retry the configuration cycles, if an endpoint responds with a CRS (Configuration Request Retry Status), and the CRS Software Visibility flag is not set at the root

Re: [PATCH] pci/probe: Enable CRS for Intel Haswell root ports

On Fri, Aug 29, 2014 at 10:11:16AM -0700, Rajat Jain wrote: Hello Wei Yang, Thanks for your mail and review. On Thu, Aug 28, 2014 at 9:04 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote: On Thu, Aug 28, 2014 at 02:55:25PM -0700, Rajat Jain wrote: The PCIe root port of the Intel Haswell CPU, has

[PATCH V2] vfio-pci: Fix the check on pci device type in vfio_pci_probe()

this by do the check directly on the pci_dev-hdr_type. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com V2: * Fix the problem by checking pci_dev-hdr_type --- drivers/vfio/pci/vfio_pci.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/vfio/pci/vfio_pci.c b

Re: [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it

On Tue, Dec 09, 2014 at 11:11:19AM +1100, Gavin Shan wrote: On Mon, Dec 08, 2014 at 03:59:54PM -0800, Yinghai Lu wrote: On Mon, Dec 8, 2014 at 2:56 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2014-12-08 at 13:52 -0800, Yinghai Lu wrote: 2. or scan the children resource

Re: [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it

On Mon, Dec 08, 2014 at 11:20:59PM -0800, Yinghai Lu wrote: On Mon, Dec 8, 2014 at 6:26 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote: On Tue, Dec 09, 2014 at 11:11:19AM +1100, Gavin Shan wrote: I'm going to give it a spin and Richard, could you please apply Yinghai's patch to see if your SRIOV

Re: [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it

On Tue, Dec 09, 2014 at 11:21:11AM -0700, Bjorn Helgaas wrote: On Tue, Dec 9, 2014 at 12:56 AM, Wei Yang weiy...@linux.vnet.ibm.com wrote: As you mentioned in another thread, 5b28541552ef is taking the wrong approach. (http://www.spinics.net/lists/linux-pci/msg37374.html) Maybe I don't catch

Re: [PATCH] PCI: Clear all bridge res MEM_64 if host bridge has non mem64

My mutt hang, in case the mail isn't sent out, I resend it. On Wed, Dec 10, 2014 at 10:15:37PM +0800, Wei Yang wrote: On Tue, Dec 09, 2014 at 03:13:49PM -0800, Yinghai Lu wrote: On Tue, Dec 9, 2014 at 1:53 PM, Bjorn Helgaas bhelg...@google.com wrote: On Tue, Dec 9, 2014 at 2:34 PM, Yinghai Lu

Re: [PATCH 09/10] PCI, powerpc: clip firmware assigned resource under parent bridge's

Mackerras pau...@samba.org Cc: Michael Ellerman m...@ellerman.id.au Cc: Gavin Shan gws...@linux.vnet.ibm.com Cc: Anton Blanchard an...@samba.org Cc: Sebastian Ott seb...@linux.vnet.ibm.com Cc: Wei Yang weiy...@linux.vnet.ibm.com Cc: Andrew Murray amur...@embedded-bits.co.uk Cc: linuxppc

Re: linux-next: manual merge of the powerpc-mpe tree with the powerpc tree

On Mon, Apr 13, 2015 at 05:55:31PM +1000, Stephen Rothwell wrote: Hi, On Mon, 13 Apr 2015 14:09:13 +0800 Wei Yang weiy...@linux.vnet.ibm.com wrote: Hi, Stephen, Thanks for your finding :-) Your fix looks good to me. Michael Ben, Do I need to rebase the patch or what should I do? You

Re: linux-next: manual merge of the powerpc-mpe tree with the powerpc tree

On Mon, Apr 13, 2015 at 01:27:15PM +1000, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the powerpc-mpe tree got a conflict in arch/powerpc/include/asm/machdep.h between commit 6e628c7d33d9 (powerpc/powernv: Reserve additional space for IOV BAR according to the number of total_pe)

[PATCH] x86, setup: code clean of e820_reserve_setup_data()

pa_data and found are highly related, so there is no need to set a found flag. This patch removes the found and just return when pa_data is NULL. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- arch/x86/kernel/setup.c |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff

Re: [PATCH] x86, setup: code clean of e820_reserve_setup_data()

On Thu, Jun 04, 2015 at 07:42:38AM +0200, Ingo Molnar wrote: * Wei Yang weiy...@linux.vnet.ibm.com wrote: pa_data and found are highly related, so there is no need to set a found flag. This patch removes the found and just return when pa_data is NULL. Signed-off-by: Wei Yang weiy

[PATCH] kobject: avoid unnecessary assignment of kobj-parent

kobj-parent is changed only when it is NULL originally. This patch moves the assignment in the if to avoid unnecessary assignment. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- lib/kobject.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/kobject.c b/lib

[PATCH] x86, setup: code clean of e820_reserve_setup_data()

pa_data and found are highly related, so there is no need to set a found flag. This patch removes the found and just return when pa_data is NULL. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- arch/x86/kernel/setup.c |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff

Re: [PATCH] kobject: avoid unnecessary assignment of kobj-parent

On Sat, Jun 06, 2015 at 01:22:30PM +0900, Greg KH wrote: On Thu, Jun 04, 2015 at 10:13:50AM +0800, Wei Yang wrote: kobj-parent is changed only when it is NULL originally. This patch moves the assignment in the if to avoid unnecessary assignment. Signed-off-by: Wei Yang weiy

[PATCH] rbtree: increase readability of __rb_erase_augmented()

assignment of __rb_parent_color 3. rb_is_black(node) replaces __rb_is_black(pc) 4. merges the successor's parent/color change together after every thing is set down. Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com --- include/linux/rbtree_augmented.h | 24 +--- 1 file

Re: [PATCH v2 00/49] PCI: Resource allocation cleanup for v4.3

Yinghai, Tested your latest for for-pci-v4.3-next branch, it works fine on my P8 machine. BTW, the SRIOV works fine too. Previously failure is based on my mistake, I have disabled SRIOV :-( On Tue, Jul 14, 2015 at 03:46:31PM -0700, Yinghai Lu wrote: Hi, After 5b28541552ef (PCI: Restrict 64-bit

Re: [PATCH v2 6/7] PCI: Fix sriov_enable() error path for pcibios_enable_sriov() failures

[bhelgaas: changelog, split to separate patch for reviewability] >Fixes: 995df527f399 ("PCI: Add pcibios_sriov_enable() and >pcibios_sriov_disable()") >Signed-off-by: Alexander Duyck <adu...@mirantis.com> >Signed-off-by: Bjorn Helgaas <bhelg...@google.com> Reviewed-

Re: [PATCH v2 1/7] PCI: Set SR-IOV NumVFs to zero after enumeration

On Thu, Oct 29, 2015 at 05:22:54PM -0500, Bjorn Helgaas wrote: >ines: 115 > >From: Alexander Duyck > >The enumeration path should leave NumVFs set to zero. But after >4449f079722c ("PCI: Calculate maximum number of buses required for VFs"), >we call virtfn_max_buses() in the

Re: [PATCH v2 3/7] PCI: Remove VFs in reverse order if virtfn_add() fails

e natural and doesn't require an additional >variable. > >[bhelgaas: changelog, split to separate patch for reviewability] >Signed-off-by: Alexander Duyck <adu...@mirantis.com> >Signed-off-by: Bjorn Helgaas <bhelg...@google.com> Interesting. Reviewed-by: Wei Yang <we

Re: [PATCH v2 2/7] PCI: Remove redundant validation of SR-IOV offset/stride registers

bility] >Signed-off-by: Alexander Duyck <adu...@mirantis.com> >Signed-off-by: Bjorn Helgaas <bhelg...@google.com> Reviewed-by: Wei Yang <weiy...@linux.vnet.ibm.com> >--- > drivers/pci/iov.c | 10 +- > 1 file changed, 1 insertion(+), 9 deletions(-) >

Re: [PATCH v2 5/7] PCI: Wait 1 second between disabling VFs and clearing NumVFs

On Thu, Oct 29, 2015 at 05:23:22PM -0500, Bjorn Helgaas wrote: >From: Alexander Duyck > >Per sec 3.3.3.1 of the SR-IOV spec, r1.1, we must allow 1.0s after clearing >VF Enable before reading any field in the SR-IOV Extended Capability. > >Wait 1 second before calling

Re: [PATCH v2 7/7] PCI: Set NumVFs before computing how many buses VFs require

On Thu, Oct 29, 2015 at 05:23:36PM -0500, Bjorn Helgaas wrote: >From: Alexander Duyck > >VF bus numbers depend on the First VF Offset and VF Stride, and per >sections 3.3.9 and 3.3.10 of the SR-IOV spec r1.1, these depend on the >NumVF value. > >Wait until after we set NumVFs

Re: [PATCH v2 4/7] PCI: Reorder pcibios_sriov_disable()

du...@mirantis.com> >Signed-off-by: Bjorn Helgaas <bhelg...@google.com> Reviewed-by: Wei Yang <weiy...@linux.vnet.ibm.com> >--- > drivers/pci/iov.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > >diff --git a/drivers/pci/iov.c b/drivers

Re: [PATCH v2 1/7] PCI: Set SR-IOV NumVFs to zero after enumeration

On Fri, Oct 30, 2015 at 11:48:21AM +0800, Wei Yang wrote: >On Thu, Oct 29, 2015 at 05:22:54PM -0500, Bjorn Helgaas wrote: >>ines: 115 >> >>From: Alexander Duyck <adu...@mirantis.com> >> >>The enumeration path should leave NumVFs set to zero. But after

Re: [PATCH v2 5/7] PCI: Wait 1 second between disabling VFs and clearing NumVFs

On Fri, Oct 30, 2015 at 08:57:17AM -0700, Alexander Duyck wrote: >On 10/29/2015 11:00 PM, ethan zhao wrote: >>Wei, >> >>On 2015/10/30 13:14, Wei Yang wrote: >>>On Thu, Oct 29, 2015 at 05:23:22PM -0500, Bjorn Helgaas wrote: >>>>From: Alexander Duyck <

Re: [PATCH v2 1/7] PCI: Set SR-IOV NumVFs to zero after enumeration

On Fri, Oct 30, 2015 at 08:40:52AM -0700, Alexander Duyck wrote: >On 10/29/2015 08:48 PM, Wei Yang wrote: >>On Thu, Oct 29, 2015 at 05:22:54PM -0500, Bjorn Helgaas wrote: >>>ines: 115 >>> >>>From: Alexander Duyck <adu...@mirantis.com> >>> >

Re: [PATCH v2 7/7] PCI: Set NumVFs before computing how many buses VFs require

On Fri, Oct 30, 2015 at 09:03:54AM -0700, Alexander Duyck wrote: >On 10/29/2015 10:22 PM, Wei Yang wrote: >>On Thu, Oct 29, 2015 at 05:23:36PM -0500, Bjorn Helgaas wrote: >>>From: Alexander Duyck <adu...@mirantis.com> >>> >>>VF bus numbers depend on

Re: [PATCH v2 5/7] PCI: Wait 1 second between disabling VFs and clearing NumVFs

Bjorn Helgaas <bhelg...@google.com> Reviewed-by: Wei Yang <weiy...@linux.vnet.ibm.com> >--- > drivers/pci/iov.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c >index fada98d..24428d5 100644 >--- a/drivers

Re: [PATCH v2 5/7] PCI: Wait 1 second between disabling VFs and clearing NumVFs

On Mon, Nov 02, 2015 at 07:46:24AM -0800, Alexander Duyck wrote: >On 11/02/2015 12:33 AM, Wei Yang wrote: >>On Fri, Oct 30, 2015 at 08:57:17AM -0700, Alexander Duyck wrote: >>>On 10/29/2015 11:00 PM, ethan zhao wrote: >>>>Wei, >>>> >>>>On 2015/

Re: [PATCH v2 7/7] PCI: Set NumVFs before computing how many buses VFs require

On Mon, Nov 02, 2015 at 07:39:48AM -0800, Alexander Duyck wrote: >On 11/02/2015 12:27 AM, Wei Yang wrote: >>On Fri, Oct 30, 2015 at 09:03:54AM -0700, Alexander Duyck wrote: >>>On 10/29/2015 10:22 PM, Wei Yang wrote: >>>>On Thu, Oct 29, 2015 at 05:23:36PM -0500,

Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail

On Thu, Jul 09, 2015 at 09:20:08AM -0700, Yinghai Lu wrote: On Wed, Jul 8, 2015 at 11:04 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote: This one is on top of the last one ? or replace the last one? should be just before last one. I can't apply this on top of b0b9229 PCI, x86: Add pci

Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail

On Thu, Jul 09, 2015 at 10:49:06PM -0700, Yinghai Lu wrote: On Thu, Jul 9, 2015 at 7:48 PM, Yinghai Lu ying...@kernel.org wrote: On Thu, Jul 9, 2015 at 7:30 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote: If you could update your for-pci-v4.3-next branch, that would be more convenient for me

Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail

On Fri, Jul 10, 2015 at 05:42:10PM -0700, Yinghai Lu wrote: On Fri, Jul 10, 2015 at 5:03 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote: On Thu, Jul 09, 2015 at 10:49:06PM -0700, Yinghai Lu wrote: I have tested you latest branch with this one as the last commit: ec94cc7 PCI: Don't set flags

Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail

Hi, Yinghai This patch may introduce some problem. On my P8 machine, after applying this patch, I see following error: [0.589948] pnv_ioda_setup_pe_seg: trigger IO SEG 0 [0.589992] pnv_ioda_setup_pe_seg: res[io 0x1000-0x3fff] 100 The last 0x100 is the res-flags, which indicates the

Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail

This one is on top of the last one ? or replace the last one? On Wed, Jul 08, 2015 at 10:01:47PM -0700, Yinghai Lu wrote: On Wed, Jul 8, 2015 at 8:30 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote: Hi, Yinghai This patch may introduce some problem. On my P8 machine, after applying this patch

[RFC PATCH] iommu: enable the last bit in iommu_area_alloc()

tead of [start, size]. This means the last bit is already excluded. By decrease size at the beginning, the last iommu page will not be allocated. This patch removes the decrease on size. Signed-off-by: Wei Yang <weiy...@linux.vnet.ibm.com> --- I may missed something, while the code makes me a lit

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: >On 25/05/16 00:06, Wei Yang wrote: >>Hi, Joerg >> >>Not sure whether you think this calculation is correct. >> >>If I missed something for this " + 1" in your formula, I am glad to hea

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

Hi, Joerg Not sure whether you think this calculation is correct. If I missed something for this " + 1" in your formula, I am glad to hear your explanation. So that I could learn something from you :-) Have a good day~ On Sat, May 21, 2016 at 02:41:51AM +, Wei Yang wrote:

[PATCH v2 0/2] fix and cleanup for iommu/vt-d

<robin.mur...@arm.com> * adds patch 2 for comment Wei Yang (2): iommu/vt-d: reduce extra first level entry in iommu->domains iommu/vt-d: use marco for dmar_domain's second level size and shift drivers/iommu/intel-iommu.c | 12 ++-- include/linux/intel-iommu.h | 2 ++ 2 file

[PATCH v2 1/2] iommu/vt-d: reduce extra first level entry in iommu->domains

current implementation. This patch refines this calculation to reduce the extra first level entry when ndomains is exact a multiple of 256. Signed-off-by: Wei Yang <richard.weiy...@gmail.com> --- drivers/iommu/intel-iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH v2 2/2] iommu/vt-d: use marco for dmar_domain's second level size and shift

In the origin commit, the size of the second level is hard coded to an integer, 256. This patch defines two marco for the second level size and shift. Signed-off-by: Wei Yang <richard.weiy...@gmail.com> --- drivers/iommu/intel-iommu.c | 12 ++-- include/linux/intel-iommu.h | 2

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Thu, May 26, 2016 at 11:11:51AM +0100, Robin Murphy wrote: >On 25/05/16 22:43, Wei Yang wrote: >>On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: >>>On 25/05/16 00:06, Wei Yang wrote: >>>>Hi, Joerg >>>> >>>>Not sure whethe

  1   2   3   4   5   6   7   8   9   10   >