On Tue, Dec 24, 2013 at 08:15:00AM +0800, Shawn Guo wrote: > On Fri, Dec 20, 2013 at 03:52:02PM +0800, Peter Chen wrote: > > It is needed by imx6 SoC series, but not for imx23 and imx28. > > > > Signed-off-by: Peter Chen <peter.chen@xxxxxxxxxxxxx> > > --- > > drivers/usb/phy/phy-mxs-usb.c | 23 +++++++++++++++++++++-- > > 1 files changed, 21 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c > > index 0c6f3bc..0ef930a 100644 > > --- a/drivers/usb/phy/phy-mxs-usb.c > > +++ b/drivers/usb/phy/phy-mxs-usb.c > > @@ -21,6 +21,8 @@ > > #include <linux/err.h> > > #include <linux/io.h> > > #include <linux/of_device.h> > > +#include <linux/regmap.h> > > +#include <linux/mfd/syscon.h> > > > > #define DRIVER_NAME "mxs_phy" > > > > @@ -58,6 +60,9 @@ > > */ > > #define MXS_PHY_SENDING_SOF_TOO_FAST BIT(2) > > > > +/* The SoCs who have anatop module */ > > +#define MXS_PHY_HAS_ANATOP BIT(3) > > + > > struct mxs_phy_data { > > unsigned int flags; > > }; > > @@ -68,11 +73,13 @@ static const struct mxs_phy_data imx23_phy_data = { > > > > static const struct mxs_phy_data imx6q_phy_data = { > > .flags = MXS_PHY_SENDING_SOF_TOO_FAST | > > - MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS, > > + MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS | > > + MXS_PHY_HAS_ANATOP, > > }; > > > > static const struct mxs_phy_data imx6sl_phy_data = { > > - .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS, > > + .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS | > > + MXS_PHY_HAS_ANATOP, > > }; > > > > static const struct of_device_id mxs_phy_dt_ids[] = { > > @@ -87,6 +94,7 @@ struct mxs_phy { > > struct usb_phy phy; > > struct clk *clk; > > const struct mxs_phy_data *data; > > + struct regmap *regmap_anatop; > > }; > > > > static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) > > @@ -190,6 +198,7 @@ static int mxs_phy_probe(struct platform_device *pdev) > > int ret; > > const struct of_device_id *of_id = > > of_match_device(mxs_phy_dt_ids, &pdev->dev); > > + struct device_node *np = pdev->dev.of_node; > > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > base = devm_ioremap_resource(&pdev->dev, res); > > @@ -226,6 +235,16 @@ static int mxs_phy_probe(struct platform_device *pdev) > > > > platform_set_drvdata(pdev, mxs_phy); > > > > + if (mxs_phy->data->flags & MXS_PHY_HAS_ANATOP) { > > + mxs_phy->regmap_anatop = syscon_regmap_lookup_by_phandle > > + (np, "fsl,anatop"); > > + if (IS_ERR(mxs_phy->regmap_anatop)) { > > + dev_dbg(&pdev->dev, > > + "failed to find regmap for anatop\n"); > > + return PTR_ERR(mxs_phy->regmap_anatop); > > I'm looking at the merge dependency that Felipe mentions, and just think > of the DTB compatibility thing. Does the above code mean that USB will > be broken if someone runs the new kernel with an old DTB on his board? > > We're entering the stage where we need to maintain the DTB compatibility > in kernel. That said, if users choose to upgrade their kernel only > (running with an old DTB), it's okay we do not give them new > features, but we shouldn't cause any regression/breakage for them. > Then, this patch needs to change for old imx6 DTB. I will use of_find_property like my previous version patch, do you think so? http://marc.info/?l=linux-usb&m=138361742123380&w=2 I will send v8 just for this one (using my v3 patch) if you think two dts related patches are ok. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html