Hello,
> Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
>
>
>
> On Thursday 06 March 2014 01:56 PM, Anton Tikhomirov wrote:
> > Hi Kamil,
> >
> > ...
> >
> >> +| 3. Supporting SoCs
> >> ++--------------------
> >> +
> >> +To support a new SoC a new file should be added to the drivers/phy
> >> +directory. Each SoC's configuration is stored in an instance of the
> >> +struct samsung_usb2_phy_config.
> >> +
> >> +struct samsung_usb2_phy_config {
> >> + const struct samsung_usb2_common_phy *phys;
> >> + unsigned int num_phys;
> >> + bool has_mode_switch;
> >
> > You missed rate_to_clk here.
> >
> >> +};
> >> +
> >
> > ...
> >
> >> diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
> samsung-
> >> usb2.c
> >> new file mode 100644
> >> index 0000000..c3b7719
> >> --- /dev/null
> >> +++ b/drivers/phy/phy-samsung-usb2.c
> >> @@ -0,0 +1,222 @@
> >> +/*
> >> + * Samsung SoC USB 1.1/2.0 PHY driver
> >> + *
> >> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> >> + * Author: Kamil Debski <k.debski@xxxxxxxxxxx>
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> modify
> >> + * it under the terms of the GNU General Public License version 2
> as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +
> >> +#include <linux/clk.h>
> >> +#include <linux/mfd/syscon.h>
> >> +#include <linux/module.h>
> >> +#include <linux/of.h>
> >> +#include <linux/of_address.h>
> >> +#include <linux/phy/phy.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/spinlock.h>
> >> +#include "phy-samsung-usb2.h"
> >> +
> >> +static int samsung_usb2_phy_power_on(struct phy *phy)
> >> +{
> >> + struct samsung_usb2_phy_instance *inst = phy_get_drvdata(phy);
> >> + struct samsung_usb2_phy_driver *drv = inst->drv;
> >> + int ret;
> >> +
> >> + dev_dbg(drv->dev, "Request to power_on \"%s\" usb phy\n",
> >> + inst->cfg->label);
> >> + ret = clk_prepare_enable(drv->clk);
> >
> > clk_prepare_enable() can sleep, and therefore doesn't allow
> > samusng_usb2_phy_power_on() to be used in atomic context
> > (e.g. inside spin_lock-ed area), what sometimes may be desirable.
> > What about to prepare clock in probe, and just enable it here
> > (note: clk_enable() doesn't sleep).
>
> The PHY power-on callback is anyway called with mutex held, so I guess
> it's fine to have clk_prepare_enable() here.
If we rely totally on generic PHY functions such as phy_power_on()
and friends, why do we need to use locking in callbacks at all.
>
> Thanks
> Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
