linux-kernel - Re: [PATCH] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Apr 2014 13:07:28 +0530
From:	Vivek Gautam <gautam.vivek@...sung.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>, linux-doc@...r.kernel.org,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	"robh+dt" <robh+dt@...nel.org>, Jingoo Han <jg1.han@...sung.com>
Subject: Re: [PATCH] usb: ohci-exynos: Add facility to use phy provided by the
 generic phy framework

Hi Alan,


On Tue, Apr 22, 2014 at 11:28 PM, Alan Stern <stern@...land.harvard.edu> wrote:

Thanks for reviewing this. Please find my comments inline below.

> On Thu, 10 Apr 2014, Vivek Gautam wrote:
>
>> Add support to consume phy provided by Generic phy framework.
>> Keeping the support for older usb-phy intact right now, in order
>> to prevent any functionality break in absence of relevant
>> device tree side change for ohci-exynos.
>> Once we move to new phy in the device nodes for ohci, we can
>> remove the support for older phys.
>>
>> Signed-off-by: Vivek Gautam <gautam.vivek@...sung.com>
>> Cc: Jingoo Han <jg1.han@...sung.com>
>> Cc: Alan Stern <stern@...land.harvard.edu>
>
>> +static int exynos_ohci_phyg_on(struct phy *phy, bool on)
>> +{
>> +     int ret = 0;
>> +
>> +     if (phy) {
>> +             if (on)
>> +                     ret = phy_power_on(phy);
>> +             else
>> +                     ret = phy_power_off(phy);
>> +     }
>> +
>> +     return ret;
>> +}
>
> This would be cleaner if you had separate routines for
> exynos_ohci_phyg_of and exynos_ohci_phyg_off.  For example:
>
> static int exynos_ohci_phyg_on(struct phy *phy)
> {
>         return phy ? phy_power_on(phy) : 0;
> }

Sure, i will make two separate routines here.

>
>> @@ -88,16 +104,49 @@ static int exynos_ohci_probe(struct platform_device *pdev)
>>                                       "samsung,exynos5440-ohci"))
>>               goto skip_phy;
>>
>> -     phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
>> -     if (IS_ERR(phy)) {
>> -             usb_put_hcd(hcd);
>> -             dev_warn(&pdev->dev, "no platform data or transceiver defined\n");
>> -             return -EPROBE_DEFER;
>> +     exynos_ohci->phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
>> +     if (IS_ERR(exynos_ohci->phy)) {
>> +             err = PTR_ERR(exynos_ohci->phy);
>> +             if (err == -ENXIO || err == -ENODEV) {
>> +                     exynos_ohci->phy = NULL;
>> +             } else if (err == -EPROBE_DEFER) {
>> +                     usb_put_hcd(hcd);
>> +                     return err;
>> +             } else {
>> +                     dev_err(&pdev->dev, "no usb2 phy configured\n");
>> +                     usb_put_hcd(hcd);
>> +                     return err;
>> +             }
>
> Instead of all the calls to usb_put_hcd() here and below, just goto
> fail_clk.  Or add a new fail_phy label at the same spot and goto it.

Sure, i can use a new label here.

>
> Otherwise this looks basically okay.

Sure, i will send the next version of this patch after rework.
--
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/