lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 20 Jun 2013 08:53:05 +0800
From:	Chao Xie <xiechao.mail@...il.com>
To:	Roger Quadros <rogerq@...com>
Cc:	Chao Xie <chao.xie@...vell.com>,
	Alan Stern <stern@...land.harvard.edu>,
	"balbi@...com" <balbi@...com>,
	Greg KH <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH V2] USB: initialize or shutdown PHY when add or remove
 host controller

On Wed, Jun 19, 2013 at 3:51 PM, Roger Quadros <rogerq@...com> wrote:
> Hi Chao,
>
> On 06/19/2013 05:31 AM, Chao Xie wrote:
>> Some controller need software to initialize PHY before add
>> host controller, and shut down PHY after remove host controller.
>> Add the generic code for these controllers so they do not need
>> do it in its own host controller driver.
>>
>> Signed-off-by: Chao Xie <chao.xie@...vell.com>
>> ---
>>  drivers/usb/core/hcd.c |   24 +++++++++++++++++++++++-
>>  1 files changed, 23 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index d53547d..301c639 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -40,9 +40,11 @@
>>  #include <linux/platform_device.h>
>>  #include <linux/workqueue.h>
>>  #include <linux/pm_runtime.h>
>> +#include <linux/err.h>
>>
>>  #include <linux/usb.h>
>>  #include <linux/usb/hcd.h>
>> +#include <linux/usb/phy.h>
>>
>>  #include "usb.h"
>>
>> @@ -2531,12 +2533,26 @@ int usb_add_hcd(struct usb_hcd *hcd,
>>        */
>>       set_bit(HCD_FLAG_RH_RUNNING, &hcd->flags);
>>
>> +     /* In case hcd->phy contains the error code. */
>> +     if (IS_ERR(hcd->phy))
>> +             hcd->phy = NULL;
>> +
>> +     /* Initialize the PHY before other hardware operation. */
>> +     if (hcd->phy) {
>> +             retval = usb_phy_init(hcd->phy);
>> +             if (retval) {
>> +                     dev_err(hcd->self.controller,
>> +                             "can't initialize phy\n");
>> +                     goto err_hcd_driver_setup;
>> +             }
>> +     }
>> +
>>       /* "reset" is misnamed; its role is now one-time init. the controller
>>        * should already have been reset (and boot firmware kicked off etc).
>>        */
>>       if (hcd->driver->reset && (retval = hcd->driver->reset(hcd)) < 0) {
>>               dev_err(hcd->self.controller, "can't setup\n");
>> -             goto err_hcd_driver_setup;
>> +             goto err_hcd_driver_init_phy;
>>       }
>>       hcd->rh_pollable = 1;
>>
>> @@ -2608,6 +2624,9 @@ err_hcd_driver_start:
>>       if (usb_hcd_is_primary_hcd(hcd) && hcd->irq > 0)
>>               free_irq(irqnum, hcd);
>>  err_request_irq:
>> +err_hcd_driver_init_phy:
>> +     if (hcd->phy)
>> +             usb_phy_shutdown(hcd->phy);
>>  err_hcd_driver_setup:
>>  err_set_rh_speed:
>>       usb_put_dev(hcd->self.root_hub);
>> @@ -2674,6 +2693,9 @@ void usb_remove_hcd(struct usb_hcd *hcd)
>>                       free_irq(hcd->irq, hcd);
>>       }
>>
>> +     if (hcd->phy)
>> +             usb_phy_shutdown(hcd->phy);
>> +
>>       usb_put_dev(hcd->self.root_hub);
>>       usb_deregister_bus(&hcd->self);
>>       hcd_buffer_destroy(hcd);
>>
>
> I still think that we shouldn't do this because it adds more confusion and is not
> still a generic enough solution.
>
> 1) It is better for the piece of code that does usb_phy_get() to do usb_phy_init/shutdown,
> else there will be lot of confusion. (Felipe pointed this out earlier).
>
> 2) There is no standard way of getting phy for different controllers. It is mostly platform
> dependent and it is best to leave this to the controller drivers. (Pointed out by Alan).
>
> 3) Controllers can have multiple PHYs. e.g. ehci-omap has one PHY per port and it supports
> 3 ports. This is also platform specific and difficult to handle generically.
>
> 4) Controllers can have specific timing requirements as to when the PHY is initialized relative
> to the controller being initialized. I've pointed OMAP specific stuff in the earlier patch.
>
> Considering all these points, I think we should leave things as they are. It isn't that hard
> for controllers to manage phy_init() and phy_shutdown(), and there is not much code space saved
> when compared to the complexity it creates if we move them to HCD layer.
>
In fact, the PHY setting and handling is related to platform or SOC,
and for different SOC they can
have same EHCI HCD but they PHY handling can be different.
Omap'a case is the example, and i think some other vendors may have
silimar cases.
>From above point, It is better to leave the PHY initialization and
shutdown to be done by each echi-xxx driver.

So Alan and Felipe
What are your ideas about it?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ