| 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
| ||
|
Message-id: <025f01ced3e5$0660ecf0$1322c6d0$%debski@samsung.com>
Date: Mon, 28 Oct 2013 14:53:03 +0100
From: Kamil Debski <k.debski@...sung.com>
To: 'Vivek Gautam' <gautamvivek1987@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
'Linux USB Mailing List' <linux-usb@...r.kernel.org>,
devicetree@...r.kernel.org, linux-arm@...r.kernel.org,
'Kyungmin Park' <kyungmin.park@...sung.com>,
'kishon' <kishon@...com>, Tomasz Figa <t.figa@...sung.com>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
'Vivek Gautam' <gautam.vivek@...sung.com>,
mat.krawczuk@...il.com
Subject: RE: [PATCH 4/5] usb: ehci-s5p: Change to use phy provided by the
generic phy framework
Hi Vivek,
> From: Vivek Gautam [mailto:gautamvivek1987@...il.com]
> Sent: Saturday, October 26, 2013 11:41 AM
>
> Hi Kamil,
>
>
> On Fri, Oct 25, 2013 at 7:45 PM, Kamil Debski <k.debski@...sung.com>
> wrote:
> > Change the phy provider used from the old usb phy specific to a new
> > one using the generic phy framework.
> >
> > Signed-off-by: Kamil Debski <k.debski@...sung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@...sung.com>
> > ---
> > drivers/usb/host/ehci-s5p.c | 21 +++++++++++----------
> > 1 file changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-
> s5p.c
> > index 7cc26e6..76606ff 100644
> > --- a/drivers/usb/host/ehci-s5p.c
> > +++ b/drivers/usb/host/ehci-s5p.c
> > @@ -19,6 +19,7 @@
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/of_gpio.h>
> > +#include <linux/phy/phy.h>
> > #include <linux/platform_device.h>
> > #include <linux/platform_data/usb-ehci-s5p.h>
> > #include <linux/usb/phy.h>
> > @@ -45,7 +46,7 @@ static struct hc_driver __read_mostly
> > s5p_ehci_hc_driver;
> >
> > struct s5p_ehci_hcd {
> > struct clk *clk;
> > - struct usb_phy *phy;
> > + struct phy *phy;
> > struct usb_otg *otg;
> > struct s5p_ehci_platdata *pdata; }; @@ -77,10 +78,11 @@
> > static int s5p_ehci_probe(struct platform_device *pdev) {
> > struct s5p_ehci_platdata *pdata = pdev->dev.platform_data;
> > struct s5p_ehci_hcd *s5p_ehci;
> > + struct phy *phy;
>
> just a nit here:
> Lets keep the pointer to 'phy' and 'phy_name' together ?
> and move this above phy_name ?
Thanks for pointing this out.
> > struct usb_hcd *hcd;
> > struct ehci_hcd *ehci;
> > struct resource *res;
> > - struct usb_phy *phy;
> > + const char *phy_name;
> > int irq;
> > int err;
> >
> > @@ -103,14 +105,14 @@ static int s5p_ehci_probe(struct
> platform_device *pdev)
> > return -ENOMEM;
> > }
> > s5p_ehci = to_s5p_ehci(hcd);
> > -
> > + phy_name = of_get_property(pdev->dev.of_node, "phy-names",
> NULL);
> > + phy = devm_phy_get(&pdev->dev, phy_name);
>
> Below check for exynos5440 was supposed to skip any request phy.
> So shouldn't we place above two assignments to the original place where
> devm_usb_get_phy() was called ?
> May be i am not getting you intention of changing the place.
Hm... You are right - if we want to leave this check and skip phy request
for
5450 then I should leave the order as it was. And if we want to use the new
phy driver for 5450 then the check to skip phy requesting should be simply
removed.
>
> > if (of_device_is_compatible(pdev->dev.of_node,
> > "samsung,exynos5440-ehci")) {
> > s5p_ehci->pdata = &empty_platdata;
> > goto skip_phy;
> > }
> >
> > - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> > if (IS_ERR(phy)) {
> > /* Fallback to pdata */
> > if (!pdata) {
> > @@ -122,7 +124,6 @@ static int s5p_ehci_probe(struct platform_device
> *pdev)
> > }
> > } else {
> > s5p_ehci->phy = phy;
> > - s5p_ehci->otg = phy->otg;
> > }
> >
> > skip_phy:
> > @@ -166,7 +167,7 @@ skip_phy:
> > s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
>
> Lets remove this line and similar calls to 'set_host()' in the driver,
> since we don't have s5p_ehci->otg anymore after the same is removed
> above.
> Anyways this was helping the old phy-samsung-usb2 driver, and not
> needed now.
Ok, I will.
>
> >
> > if (s5p_ehci->phy)
> > - usb_phy_init(s5p_ehci->phy);
> > + phy_power_on(s5p_ehci->phy);
> > else if (s5p_ehci->pdata->phy_init)
> > s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
> >
> > @@ -188,7 +189,7 @@ skip_phy:
> >
> > fail_add_hcd:
> > if (s5p_ehci->phy)
> > - usb_phy_shutdown(s5p_ehci->phy);
> > + phy_power_off(s5p_ehci->phy);
> > else if (s5p_ehci->pdata->phy_exit)
> > s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> > fail_io:
> > @@ -209,7 +210,7 @@ static int s5p_ehci_remove(struct platform_device
> *pdev)
> > s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
>
> ditto
>
> >
> > if (s5p_ehci->phy)
> > - usb_phy_shutdown(s5p_ehci->phy);
> > + phy_power_off(s5p_ehci->phy);
> > else if (s5p_ehci->pdata->phy_exit)
> > s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> >
> > @@ -244,7 +245,7 @@ static int s5p_ehci_suspend(struct device *dev)
> > s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
> ditto
>
> >
> > if (s5p_ehci->phy)
> > - usb_phy_shutdown(s5p_ehci->phy);
> > + phy_power_off(s5p_ehci->phy);
> > else if (s5p_ehci->pdata->phy_exit)
> > s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> >
> > @@ -265,7 +266,7 @@ static int s5p_ehci_resume(struct device *dev)
> > s5p_ehci->otg->set_host(s5p_ehci->otg, &hcd->self);
> ditto
>
> >
> > if (s5p_ehci->phy)
> > - usb_phy_init(s5p_ehci->phy);
> > + phy_power_on(s5p_ehci->phy);
> > else if (s5p_ehci->pdata->phy_init)
> > s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
> >
> [..] Rest looks good. :-)
>
Thank you!
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
--
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