From patchwork Tue Mar 29 14:05:21 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 8687481 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id E37F2C0553 for ; Tue, 29 Mar 2016 14:07:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D76C220212 for ; Tue, 29 Mar 2016 14:07:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 312DC201C8 for ; Tue, 29 Mar 2016 14:07:33 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1akuHU-0007gA-AQ; Tue, 29 Mar 2016 14:06:04 +0000 Received: from mout.kundenserver.de ([212.227.17.13]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1akuHQ-0007Zg-MM for linux-arm-kernel@lists.infradead.org; Tue, 29 Mar 2016 14:06:02 +0000 Received: from wuerfel.localnet ([78.42.132.4]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0LkjTw-1aCfuk2Lsi-00aSOK; Tue, 29 Mar 2016 16:05:26 +0200 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/2] ARM: mvebu: correct the usb node name from usb@ to ehci@ Date: Tue, 29 Mar 2016 16:05:21 +0200 Message-ID: <4079235.sABSXKnJCE@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1459259813-5278-2-git-send-email-patrick@puiterwijk.org> References: <1459259813-5278-1-git-send-email-patrick@puiterwijk.org> <1459259813-5278-2-git-send-email-patrick@puiterwijk.org> MIME-Version: 1.0 X-Provags-ID: V03:K0:vmM7wTx3ea0GFepMI7i9f06YzQOBWhHm9Auy2LT4i5K2mbxKdxy Cv3KjtF9+ThYna+U4s0vETqWLU0i3fEiV3cqypctoyy0qpqBJiIVwcyuTCMv4EswTr1TGcY f62JSob2UdSLhCLZ0IocBaAaW0/Nc3zhqWjr6f6CYCD1Qw9WK/ucRg9Gv6uGsog3TBv6Qw5 TWBv6I79mDghEXV+CO6Rw== X-UI-Out-Filterresults: notjunk:1; V01:K0:SQE1ozv6NxI=:rJN+o9nWH9llcjkLVrrGIg EjQqjpCVxhWiCEj7skn7u8NwDd3INY4Xu2ZOK7eGEM0d8orqjFfp5EsBAGDRrF9kMY+HS6yGw c+gazOSXEYjojyqVLUkX+f4oHVa5AqBdS7afiqGFbn2bIGFQFFhYes83ssO96415BdhAdeXiC 24EBcacTJR3jU5R2jMBMka7C1zGA6ebaFBtuD1ypyhtsOrUOem3d9UH+nvJf4/JsFYbPbno3O xNsL//qJgL4g8+raeh13M0xSIFb1v271X9lCIE5RMos340uzAfaWsCsP7p9XqxdKpr8Z+fae6 fIe3LQNKUTzsFMGrqSmn4qE63C3Kdq6uTbuAhzcs43hRHtYUP1AVNJuQwjW+TPAYPAmRiLLKf YZZm7Gdey6EO7KV+EChH8Bnm/GDsR7x6mEs/mboyHhvOFfW/woXXr1R1VYRdLdG3E0RpWcFZ3 gvZMZQj7Oa4qnI5ombCdYlDk12wPa4eDVvAd13/nVfn1Zp2RpM3w8fRPyi6OO4+RpzxsaFvMc /3nkjJE0qoNLciQKF3rXywQWZl4v8xujhFECeJY9Oo+E3/b6vyhhjfbNMdSlOG/vVbF13YYPc noL5EbjHXWLmYXIU/rC+ReNja5lxk9tJ1IVKANF3ANrEQM1zikH+IseBZ6V7AJ4NKKik9iZbH bWr8nK/hugXgGX/2GalgDCH6UbRj7QbaE590Vu48YNPqmRGLTqo7lKhUujeJnbNymmlXihPaH 5H8Oq805Z6xs+A5f X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160329_070601_111760_E593E830 X-CRM114-Status: GOOD ( 19.44 ) X-Spam-Score: -2.6 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: andrew@lunn.ch, linux@arm.linux.org.uk, jason@lakedaemon.net, devicetree@vger.kernel.org, pbrobinson@gmail.com, Patrick Uiterwijk , gregory.clement@free-electrons.com, sebastian.hesselbarth@gmail.com Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tuesday 29 March 2016 13:56:52 Patrick Uiterwijk wrote: > According to Documentation/devicetree/bindings/usb/ehci-orion.txt, > the Orion Marvell variant of EHCI controllers should have names > ehci@50000 for example. > > Signed-off-by: Patrick Uiterwijk > I think it's better to follow the generic USB binding that suggests the name of 'usb', unless we understand what the specific bug is you run into. Do you think it is the boot loader that messes up the hardware, or something in the kernel that goes wrong? Did it work on earlier kernels? We had a regression based on the USB device probing, but that should be fixed now with the patch below. Do you have that? Arnd commit 7222c832254a75dcd67d683df75753d4a4e125bb Author: Nicolai Stange Date: Thu Mar 17 23:53:02 2016 +0100 usb/core: usb_alloc_dev(): fix setting of ->portnum With commit 69bec7259853 ("USB: core: let USB device know device node"), the port1 argument of usb_alloc_dev() gets overwritten as follows: ... usb_alloc_dev(..., unsigned port1) { ... if (!parent->parent) { port1 = usb_hcd_find_raw_port_number(..., port1); } ... } Later on, this now overwritten port1 gets assigned to ->portnum: dev->portnum = port1; However, since xhci_find_raw_port_number() isn't idempotent, the aforementioned commit causes a number of KASAN splats like the following: BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170 at addr ffff8801d9311670 Read of size 8 by task kworker/2:1/87 [...] Workqueue: usb_hub_wq hub_event 0000000000000188 000000005814b877 ffff8800cba17588 ffffffff8191447e 0000000041b58ab3 ffffffff82a03209 ffffffff819143a2 ffffffff82a252f4 ffff8801d93115e0 0000000000000188 ffff8801d9311628 ffff8800cba17588 Call Trace: [] dump_stack+0xdc/0x15e [] ? _atomic_dec_and_lock+0xa2/0xa2 [] ? print_section+0x61/0xb0 [] print_trailer+0x179/0x2c0 [] object_err+0x34/0x40 [] kasan_report_error+0x2f8/0x8b0 [] ? __slab_alloc+0x5e/0x90 [] ? __lock_is_held+0x90/0x130 [] kasan_report+0x71/0xa0 [] ? kmem_cache_alloc_trace+0x212/0x560 [] ? xhci_find_raw_port_number+0x98/0x170 [] __asan_load8+0x64/0x70 [] xhci_find_raw_port_number+0x98/0x170 [] xhci_setup_addressable_virt_dev+0x235/0xa10 [] xhci_setup_device+0x3c1/0x1430 [] ? trace_hardirqs_on+0xd/0x10 [] ? xhci_setup_device+0x1430/0x1430 [] xhci_address_device+0x13/0x20 [] hub_port_init+0x55a/0x1550 [] hub_event+0xef5/0x24d0 [] ? hub_port_debounce+0x2f0/0x2f0 [] ? debug_object_deactivate+0x1be/0x270 [] ? print_rt_rq+0x53/0x2d0 [] ? trace_hardirqs_off+0xd/0x10 [] ? _raw_spin_unlock_irqrestore+0x5b/0x60 [] ? irq_domain_set_hwirq_and_chip+0x30/0xb0 [] ? debug_lockdep_rcu_enabled+0x39/0x40 [] ? __lock_is_held+0x90/0x130 [] process_one_work+0x567/0xec0 [...] Afterwards, xhci reports some functional errors: xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion code 0x11. xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion code 0x11. usb 4-3: device not accepting address 2, error -22 Fix this by not overwriting the port1 argument in usb_alloc_dev(), but storing the raw port number as required by OF in an additional variable, raw_port. Fixes: 69bec7259853 ("USB: core: let USB device know device node") Signed-off-by: Nicolai Stange Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c index ffa5cf13ffe1..dcb85e3cd5a7 100644 --- a/drivers/usb/core/usb.c +++ b/drivers/usb/core/usb.c @@ -424,6 +424,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent, struct usb_device *dev; struct usb_hcd *usb_hcd = bus_to_hcd(bus); unsigned root_hub = 0; + unsigned raw_port = port1; dev = kzalloc(sizeof(*dev), GFP_KERNEL); if (!dev) @@ -498,11 +499,11 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent, if (!parent->parent) { /* device under root hub's port */ - port1 = usb_hcd_find_raw_port_number(usb_hcd, + raw_port = usb_hcd_find_raw_port_number(usb_hcd, port1); } dev->dev.of_node = usb_of_get_child_node(parent->dev.of_node, - port1); + raw_port); /* hub driver sets up TT records */ }