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]
Message-ID: <1495708587.12055.97.camel@collabora.co.uk>
Date:   Thu, 25 May 2017 12:36:27 +0200
From:   Fabien Lahoudere <fabien.lahoudere@...labora.co.uk>
To:     Stephen Boyd <sboyd@...eaurora.org>
Cc:     Peter Chen <peter.chen@....com>,
        Peter Senna Tschudin <peter.senna@...labora.com>,
        Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "open list:USB PHY LAYER" <linux-usb@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

On Tue, 2017-05-23 at 14:00 -0700, Stephen Boyd wrote:
> On 05/23, Fabien Lahoudere wrote:
> > Hi,
> > 
> > We investigate on the topic and now our device tree look like:
> > 
> > in imx53.dtsi:
> > 
> > usbh2: usb@...80400 {
> > 	compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> >         reg = <0x53f80400 0x0200>;
> >         interrupts = <16>;
> >         clocks = <&clks IMX5_CLK_USBOH3_GATE>;
> >         fsl,usbmisc = <&usbmisc 2>;
> >         dr_mode = "host";
> >         status = "disabled";
> > };
> > 
> > usbmisc: usbmisc@...80800 {
> > 	#index-cells = <1>;
> > 	compatible = "fsl,imx53-usbmisc";
> > 	reg = <0x53f80800 0x200>;
> > 	clocks = <&clks IMX5_CLK_USBOH3_GATE>;
> > };
> > 
> > and in our dts:
> > 
> > &usbh2 {
> >         pinctrl-names = "default";
> > 	pinctrl-0 = <&pinctrl_usbh2>;
> > 	disable-int60ck;
> >         dr_mode = "host";
> >         //fsl,usbphy = <&usbphy2>;
> >         vbus-supply = <&reg_usbh2_vbus>;
> >         status = "okay";
> > 	ulpi {
> >                 phy {
> >                         compatible = "smsc,usb3315-ulpi";
> >                         reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
> > 			clock-names = "main_clk";
> > 			/*
> >                          * Hardware uses CKO2 at 24MHz at several places. Set the parent
> > 			 *  clock of CKO2 to OSC.
> >                          */
> > 			clock-frequency = <24000000>;
> > 			clocks = <&clks IMX5_CLK_CKO2>;
> >                         assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
> > 			assigned-clock-parents = <&clks IMX5_CLK_OSC>;
> >                         status = "okay";
> >                 };
> >         };
> > };
> > 
> > And we create a basic driver to check what happened:
> > 
> > static int smsc_usb3315_phy_probe(struct ulpi *ulpi)
> > {
> >         printk(KERN_ERR "Fabien: %s:%d-%s\n", __FILE__, __LINE__, __func__);
> > 
> >         return 0;
> > }
> > 
> > static const struct of_device_id smsc_usb3315_phy_match[] = {
> >         { .compatible = "smsc,usb3315-phy", },
> >         { }
> > };
> > MODULE_DEVICE_TABLE(of, smsc_usb3315_phy_match);
> > 
> > static struct ulpi_driver smsc_usb3315_phy_driver = {
> >         .probe = smsc_usb3315_phy_probe,
> >         .driver = {
> >                 .name = "smsc_usb3315_phy",
> >                 .of_match_table = smsc_usb3315_phy_match,
> >         },
> > };
> > module_ulpi_driver(smsc_usb3315_phy_driver);
> > 
> > /*MODULE_ALIAS("platform:usb_phy_generic");*/
> > MODULE_AUTHOR("GE Healthcare");
> > MODULE_DESCRIPTION("SMSC USB 3315 ULPI Phy driver");
> > MODULE_LICENSE("GPL v2");
> > 
> > I checked that the driver is registered by drivers/usb/common/ulpi.c:__ulpi_register_driver
> > successfully.
> 
> Does the ulpi device have some vendor/product ids associated
> with it? The design is made to only fallback to matching the
> device to driver based on DT if the ulpi vendor id is 0.
> Otherwise, if vendor is non-zero you'll need to have a
> ulpi_device_id id table in your ulpi_driver structure.
> 

Hi,

Thanks Stephen for your reply.
Indeed we have a vendor/product so I modify my code but without effect.

After looking at the ulpi source code in the kernel, it seems that I need to call
ulpi_register_interface. ci_hdrc_probe should be called to execute the ulpi init.

The problem is that we replace "fsl,usbphy = <&usbphy2>;" by an ulpi node but ci_hdrc_imx_probe fail
because of "data->phy = devm_usb_get_phy_by_phandle(&pdev->dev, "fsl,usbphy", 0);"

So I will try to adapt ci_hdrc_imx_probe to continue phy initialisation if fsl,usbphy is missing.
Is it the good way to proceed?

Thanks for any advice
Fabien

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ