linux.kernel - 26 new messages in 16 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* [v3.12][v3.13][Regression] EISA: Initialize device before its resources - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/bf9255ff181e65b5?hl=en
* Revert EISA init changes - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6aec178ebd69b628?hl=en
* Phase out pci_enable_msi_block() - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/7ded004c0804c466?hl=en
* of: add functions to count number of elements in a property - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/acd84f37cf4fbad7?hl=en
* cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of
tristate - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/3a3c8584cdd64136?hl=en
* linux-next: build failure after merge of the tip tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5d213db28c0ba532?hl=en
* firewire: Enable remote DMA above 4 GB - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c6d94c75fb22f3cc?hl=en
* x86 idle: restore mwait_idle() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4173ff2d30e48dc0?hl=en
* ext4: add cross rename support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2b03f04905ff68d3?hl=en
* kmem_cache_alloc panic in 3.10+ - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d0b30c0add6af2fa?hl=en
* ipv4_dst_destroy panic regression after 3.10.15 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f9a10b1dd49cf609?hl=en
* Help Needed - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4797d3981d6da8c1?hl=en
* Documentation: move all DMA documentations into Documentaion/dma - 2
messages, 1 author
http://groups.google.com/group/linux.kernel/t/c13767ccffe6446b?hl=en
* Hello - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9b32bb3b6d90167b?hl=en
* powerpc32 broken by ef1313deafb7 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f8490776ff58a734?hl=en
* usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/02bb633f7aaf9195?hl=en

==============================================================================
TOPIC: [v3.12][v3.13][Regression] EISA: Initialize device before its resources
http://groups.google.com/group/linux.kernel/t/bf9255ff181e65b5?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 18 2014 6:40 am
From: Bjorn Helgaas


On Fri, Jan 17, 2014 at 6:35 PM, Joseph Salisbury
<joseph.salisbury@canonical.com> wrote:
> On 01/17/2014 05:19 PM, Bjorn Helgaas wrote:
>> On Fri, Jan 17, 2014 at 02:26:23PM -0500, Joseph Salisbury wrote:
>>> On 01/17/2014 12:02 PM, Bjorn Helgaas wrote:
>>>> On Thu, Jan 16, 2014 at 01:14:01PM -0500, Joseph Salisbury wrote:
>>>>> On 01/16/2014 01:12 PM, Bjorn Helgaas wrote:
>>>>>> On Thu, Jan 16, 2014 at 10:53 AM, Joseph Salisbury
>>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>>> Hi Bjorn,
>>>>>>>
>>>>>>> A kernel bug was opened against Ubuntu [0]. After a kernel bisect, it
>>>>>>> was found the following commit introduced this bug:
>>>>>> Sorry about that, and thanks for the report. Did you mean to include
>>>>>> URL for the bug?
>>>>> Yes, sorry about that:
>>>>> http://pad.lv/1251816
>>>> Hi Joseph,
>>>>
>>>> Can you attach the 3.8.0-32-generic config (the one matching the successful
>>>> boot at https://launchpadlibrarian.net/156685076/BootDmesg.txt) to the bug?
>>> I attached the config file to the bug:
>>> https://launchpadlibrarian.net/162754666/config.common.ubuntu
>>>
>>> I also attached a tar file with the complete config directory for that
>>> kernel version.
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/+attachment/3951156/+files/raring-config.tar
>> Thanks again. I attached the following reverts to launchpad. I screwed up
>> when doing those EISA changes. I'd like to squeeze these into my v3.14
>> merge request (probably early next week), so please test and let me know
>> if this fixes the problem. I'm really sorry for the inconvenience.
>>
>> Bjorn
>>
>>
>> Revert "EISA: Log device resources in dmesg"
>>
>> From: Bjorn Helgaas <bhelgaas@google.com>
>>
>> This reverts commit a2080d0c561c546d73cb8b296d4b7ca414e6860b.
>>
>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>> ---
>> drivers/eisa/eisa-bus.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
>> index 8842cde69177..1b86fe0c2e80 100644
>> --- a/drivers/eisa/eisa-bus.c
>> +++ b/drivers/eisa/eisa-bus.c
>> @@ -288,7 +288,6 @@ static int __init eisa_request_resources(struct eisa_root_device *root,
>> edev->res[i].flags = IORESOURCE_IO | IORESOURCE_BUSY;
>> }
>>
>> - dev_printk(KERN_DEBUG, &edev->dev, "%pR\n", &edev->res[i]);
>> if (request_resource(root->res, &edev->res[i]))
>> goto failed;
>> }
>> Revert "EISA: Initialize device before its resources"
>>
>> From: Bjorn Helgaas <bhelgaas@google.com>
>>
>> This reverts commit 26abfeed4341872364386c6a52b9acef8c81a81a.
>>
>> In the eisa_probe() force_probe path, if we were unable to request slot
>> resources (e.g., [io 0x800-0x8ff]), we skipped the slot with "Cannot
>> allocate resource for EISA slot %d" before reading the EISA signature in
>> eisa_init_device().
>>
>> Commit 26abfeed4341 moved eisa_init_device() earlier, so we tried to read
>> the EISA signature before requesting the slot resources, and this caused
>> hangs during boot.
>>
>> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816
>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>> ---
>> drivers/eisa/eisa-bus.c | 26 +++++++++++++++-----------
>> 1 file changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
>> index 1b86fe0c2e80..612afeaec3cb 100644
>> --- a/drivers/eisa/eisa-bus.c
>> +++ b/drivers/eisa/eisa-bus.c
>> @@ -277,11 +277,13 @@ static int __init eisa_request_resources(struct eisa_root_device *root,
>> }
>>
>> if (slot) {
>> + edev->res[i].name = NULL;
>> edev->res[i].start = SLOT_ADDRESS(root, slot)
>> + (i * 0x400);
>> edev->res[i].end = edev->res[i].start + 0xff;
>> edev->res[i].flags = IORESOURCE_IO;
>> } else {
>> + edev->res[i].name = NULL;
>> edev->res[i].start = SLOT_ADDRESS(root, slot)
>> + EISA_VENDOR_ID_OFFSET;
>> edev->res[i].end = edev->res[i].start + 3;
>> @@ -327,19 +329,20 @@ static int __init eisa_probe(struct eisa_root_device *root)
>> return -ENOMEM;
>> }
>>
>> - if (eisa_init_device(root, edev, 0)) {
>> + if (eisa_request_resources(root, edev, 0)) {
>> + dev_warn(root->dev,
>> + "EISA: Cannot allocate resource for mainboard\n");
>> kfree(edev);
>> if (!root->force_probe)
>> - return -ENODEV;
>> + return -EBUSY;
>> goto force_probe;
>> }
>>
>> - if (eisa_request_resources(root, edev, 0)) {
>> - dev_warn(root->dev,
>> - "EISA: Cannot allocate resource for mainboard\n");
>> + if (eisa_init_device(root, edev, 0)) {
>> + eisa_release_resources(edev);
>> kfree(edev);
>> if (!root->force_probe)
>> - return -EBUSY;
>> + return -ENODEV;
>> goto force_probe;
>> }
>>
>> @@ -362,11 +365,6 @@ static int __init eisa_probe(struct eisa_root_device *root)
>> continue;
>> }
>>
>> - if (eisa_init_device(root, edev, i)) {
>> - kfree(edev);
>> - continue;
>> - }
>> -
>> if (eisa_request_resources(root, edev, i)) {
>> dev_warn(root->dev,
>> "Cannot allocate resource for EISA slot %d\n",
>> @@ -375,6 +373,12 @@ static int __init eisa_probe(struct eisa_root_device *root)
>> continue;
>> }
>>
>> + if (eisa_init_device(root, edev, i)) {
>> + eisa_release_resources(edev);
>> + kfree(edev);
>> + continue;
>> + }
>> +
>> if (edev->state == (EISA_CONFIG_ENABLED | EISA_CONFIG_FORCED))
>> enabled_str = " (forced enabled)";
>> else if (edev->state == EISA_CONFIG_FORCED)
> Thanks again for looking at this, Bjorn!
>
> Yes, reverting commit 26abfeed4 does in fact resolve the bug. I already
> built a test kernel, noted in comment #34:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/comments/34
>
> The original bug reporter tested the kernel to confirm it fixes the bug:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/comments/36

OK. I don't know exactly what patch you applied to revert this. I
assume that you reverted both a2080d0c561 and 26abfeed43.

> Would it be also possible for you to request the revert in the stable
> trees, in addition to 3.14?

Oh, of course, thanks for the reminder. I added a stable tag and re-pushed.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Revert EISA init changes
http://groups.google.com/group/linux.kernel/t/6aec178ebd69b628?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 18 2014 6:40 am
From: Bjorn Helgaas


I tried to make EISA device enumeration messages a bit nicer, but I
screwed up and caused some machines to hang during boot.

This was reported at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816

This reverts those changes. I plan to include these in the PCI tree
for v3.14.

---

Bjorn Helgaas (2):
Revert "EISA: Log device resources in dmesg"
Revert "EISA: Initialize device before its resources"


drivers/eisa/eisa-bus.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Sat, Jan 18 2014 6:40 am
From: Bjorn Helgaas


This reverts commit 26abfeed4341872364386c6a52b9acef8c81a81a.

In the eisa_probe() force_probe path, if we were unable to request slot
resources (e.g., [io 0x800-0x8ff]), we skipped the slot with "Cannot
allocate resource for EISA slot %d" before reading the EISA signature in
eisa_init_device().

Commit 26abfeed4341 moved eisa_init_device() earlier, so we tried to read
the EISA signature before requesting the slot resources, and this caused
hangs during boot.

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.10+ a2080d0c561c: Revert "EISA: Log device resources in dmesg"
---
drivers/eisa/eisa-bus.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
index 1b86fe0c2e80..612afeaec3cb 100644
--- a/drivers/eisa/eisa-bus.c
+++ b/drivers/eisa/eisa-bus.c
@@ -277,11 +277,13 @@ static int __init eisa_request_resources(struct eisa_root_device *root,
}

if (slot) {
+ edev->res[i].name = NULL;
edev->res[i].start = SLOT_ADDRESS(root, slot)
+ (i * 0x400);
edev->res[i].end = edev->res[i].start + 0xff;
edev->res[i].flags = IORESOURCE_IO;
} else {
+ edev->res[i].name = NULL;
edev->res[i].start = SLOT_ADDRESS(root, slot)
+ EISA_VENDOR_ID_OFFSET;
edev->res[i].end = edev->res[i].start + 3;
@@ -327,19 +329,20 @@ static int __init eisa_probe(struct eisa_root_device *root)
return -ENOMEM;
}

- if (eisa_init_device(root, edev, 0)) {
+ if (eisa_request_resources(root, edev, 0)) {
+ dev_warn(root->dev,
+ "EISA: Cannot allocate resource for mainboard\n");
kfree(edev);
if (!root->force_probe)
- return -ENODEV;
+ return -EBUSY;
goto force_probe;
}

- if (eisa_request_resources(root, edev, 0)) {
- dev_warn(root->dev,
- "EISA: Cannot allocate resource for mainboard\n");
+ if (eisa_init_device(root, edev, 0)) {
+ eisa_release_resources(edev);
kfree(edev);
if (!root->force_probe)
- return -EBUSY;
+ return -ENODEV;
goto force_probe;
}

@@ -362,11 +365,6 @@ static int __init eisa_probe(struct eisa_root_device *root)
continue;
}

- if (eisa_init_device(root, edev, i)) {
- kfree(edev);
- continue;
- }
-
if (eisa_request_resources(root, edev, i)) {
dev_warn(root->dev,
"Cannot allocate resource for EISA slot %d\n",
@@ -375,6 +373,12 @@ static int __init eisa_probe(struct eisa_root_device *root)
continue;
}

+ if (eisa_init_device(root, edev, i)) {
+ eisa_release_resources(edev);
+ kfree(edev);
+ continue;
+ }
+
if (edev->state == (EISA_CONFIG_ENABLED | EISA_CONFIG_FORCED))
enabled_str = " (forced enabled)";
else if (edev->state == EISA_CONFIG_FORCED)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Phase out pci_enable_msi_block()
http://groups.google.com/group/linux.kernel/t/7ded004c0804c466?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 18 2014 6:40 am
From: Bjorn Helgaas


On Sat, Jan 18, 2014 at 12:15 AM, Alexander Gordeev <agordeev@redhat.com> wrote:
> On Fri, Jan 17, 2014 at 02:00:32PM -0700, Bjorn Helgaas wrote:
>> > As the release is supposedly this weekend, do you prefer
>> > the patches to go to your tree or to individual trees after
>> > the release?
>>
>> I'd be happy to merge them, except for the fact that they probably
>> wouldn't have any time in -next before I ask Linus to pull them. So
>> how about if we wait until after the release, ask the area maintainers
>> to take them, and if they don't take them, I'll put them in my tree
>> for v3.15?
>
> Patch 11 depends on patches 1-10, so I am not sure how to better handle it.
> Whatever works for you ;)
>
> I am only concerned with a regression fix "ahci: Fix broken fallback to
> single MSI mode" which would be nice to have in 3.14. But it seems pretty
> much too late.

Tejun, if you want to ack that one, I can put it in either the first
3.14 pull request or a subsequent one. Either way, since it's a
regression fix, we should be able to get it in 3.14.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Sat, Jan 18 2014 7:10 am
From: Tejun Heo


On Sat, Jan 18, 2014 at 07:38:55AM -0700, Bjorn Helgaas wrote:
> On Sat, Jan 18, 2014 at 12:15 AM, Alexander Gordeev <agordeev@redhat.com> wrote:
> > On Fri, Jan 17, 2014 at 02:00:32PM -0700, Bjorn Helgaas wrote:
> >> > As the release is supposedly this weekend, do you prefer
> >> > the patches to go to your tree or to individual trees after
> >> > the release?
> >>
> >> I'd be happy to merge them, except for the fact that they probably
> >> wouldn't have any time in -next before I ask Linus to pull them. So
> >> how about if we wait until after the release, ask the area maintainers
> >> to take them, and if they don't take them, I'll put them in my tree
> >> for v3.15?
> >
> > Patch 11 depends on patches 1-10, so I am not sure how to better handle it.
> > Whatever works for you ;)
> >
> > I am only concerned with a regression fix "ahci: Fix broken fallback to
> > single MSI mode" which would be nice to have in 3.14. But it seems pretty
> > much too late.
>
> Tejun, if you want to ack that one, I can put it in either the first
> 3.14 pull request or a subsequent one. Either way, since it's a
> regression fix, we should be able to get it in 3.14.

Acked-by: Tejun Heo <tj@kernel.org>

Please feel free to route it any way you see fit.

Thanks!

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: of: add functions to count number of elements in a property
http://groups.google.com/group/linux.kernel/t/acd84f37cf4fbad7?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 18 2014 7:10 am
From: Rob Herring


On Sat, Jan 18, 2014 at 6:02 AM, Heiko St�bner <heiko@sntech.de> wrote:
> The need to know the number of array elements in a property is
> a common pattern. To prevent duplication of open-coded implementations
> add a helper static function that also centralises strict sanity
> checking and DTB format details, as well as a set of wrapper functions
> for u8, u16, u32 and u64.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---

Looks good. Do you plan to convert some users to use this?

Rob

> changes since v3:
> address more comments from Rob Herring
> - export the base function and inline the type-specific wrappers
> changes since v2:
> address more comments from Mark Rutland
> - switch to of_property_count_elems_of_size
> - use full_name instead of name in error message
> changes since v1:
> address comments from Rob Herring and Mark Rutland:
> - provide a helper and a set of wrappers for u8-u64
> - get rid of extra len variable, prop->length is enough
> - include node name in error message
>
> Mark, does your Reviewed-by holds for this variant too?
>
> drivers/of/base.c | 32 ++++++++++++++++++++++
> include/linux/of.h | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 108 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f807d0e..21646c0 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -862,6 +862,38 @@ struct device_node *of_find_node_by_phandle(phandle handle)
> EXPORT_SYMBOL(of_find_node_by_phandle);
>
> /**
> + * of_property_count_elems_of_size - Count the number of elements in a property
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @elem_size: size of the individual element
> + *
> + * Search for a property in a device node and count the number of elements of
> + * size elem_size in it. Returns number of elements on sucess, -EINVAL if the
> + * property does not exist or its length does not match a multiple of u16 and
> + * -ENODATA if the property does not have a value.
> + */
> +int of_property_count_elems_of_size(const struct device_node *np,
> + const char *propname, int elem_size)
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> +
> + if (prop->length % elem_size != 0) {
> + pr_err("size of %s in node %s is not a multiple of %d\n",
> + propname, np->full_name, elem_size);
> + return -EINVAL;
> + }
> +
> + return prop->length / elem_size;
> +}
> +EXPORT_SYMBOL_GPL(of_property_count_elems_of_size);
> +
> +/**
> * of_find_property_value_of_size
> *
> * @np: device node from which the property value is to be read.
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 276c546..293920d 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -250,6 +250,8 @@ extern struct device_node *of_find_node_with_property(
> extern struct property *of_find_property(const struct device_node *np,
> const char *name,
> int *lenp);
> +extern int of_property_count_elems_of_size(const struct device_node *np,
> + const char *propname, int elem_size);
> extern int of_property_read_u32_index(const struct device_node *np,
> const char *propname,
> u32 index, u32 *out_value);
> @@ -426,6 +428,12 @@ static inline struct device_node *of_find_compatible_node(
> return NULL;
> }
>
> +static inline int of_property_count_elems_of_size(const struct device_node *np,
> + const char *propname, int elem_size)
> +{
> + return -ENOSYS;
> +}
> +
> static inline int of_property_read_u32_index(const struct device_node *np,
> const char *propname, u32 index, u32 *out_value)
> {
> @@ -565,6 +573,74 @@ static inline int of_node_to_nid(struct device_node *device) { return 0; }
>