From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-by2on0123.outbound.protection.outlook.com ([207.46.100.123]:11591 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754994AbbGTDdF (ORCPT ); Sun, 19 Jul 2015 23:33:05 -0400 Date: Mon, 20 Jul 2015 10:07:33 +0800 From: Peter Chen To: Alan Stern CC: , Jun Li , Subject: Re: [PATCH 1/1] usb: chipidea: host: add own hc_driver for each hcd Message-ID: <20150720020732.GD4584@shlinux2> References: <20150720003716.GA4584@shlinux2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Sun, Jul 19, 2015 at 10:22:47PM -0400, Alan Stern wrote: > On Mon, 20 Jul 2015, Peter Chen wrote: > > > On Fri, Jul 17, 2015 at 09:52:26AM -0400, Alan Stern wrote: > > > On Fri, 17 Jul 2015, Peter Chen wrote: > > > > > > > There are several benefits for doing like this: > > > > > > > > - hc_driver can be customized for each hcd > > > > - Other hcd hc_driver's initialization will not affect current one. > > > > We run out NULL pointer dereference problem when one hcd is started > > > > by module_init, and the other is started by otg thread at SMP platform. > > > > The reason for this problem is ehci_init_driver will do memory copy > > > > for current uniform hc_driver, and this memory copy will do memset (as 0) > > > > first, so when the first hcd is running usb_add_hcd, and the second > > > > hcd may clear the uniform hc_driver's space (at ehci_init_driver), > > > > then the first hcd will meet NULL pointer at the same time. > > > > > > It seems to me the real problem is that ehci_init_driver gets called at > > > the wrong time. It's not supposed to be called whenever a new host > > > controller is initialized; rather, it should be called just once when > > > the driver is initialized. This means the call should be in a > > > module_init routine in host.c, not in ci_hdrc_host_init. > > > > > > > But we have no platform driver dedicated for host controller, is it a > > must? The core driver requests io_address, interrupt, dma_mask, etc for > > both device and host driver, and device and host part (we does not take > > it as a driver) should not request resources again. > > It doesn't matter. There's no harm in calling ehci_init_driver, even > if the hardware doesn't contain a host controller. The point is that > this call should be made only once, when the main ci_hdrc driver starts > up. It should not be made every time a platform driver registers a > host controller. > > > Would you accept it as another use case for ehci driver? > > I don't think a new use case is needed. All you have to do is add > something like this to host.c: > > static void ci_hdrc_host_driver_init(void) > { > ehci_init_driver(&ci_ehci_hc_driver, &ehci_ci_overrides); > } > module_init(ci_hdrc_host_driver_init); > > Can you think of any reason this won't work? > No, it will not work. The core driver's probe will run which will call host_start to call ehci APIs before ci_hdrc_host_driver_init is called. -- Best Regards, Peter Chen