RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver

[Anton Tikhomirov]

Hi,

> Subject: RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
> 
> Hi,
> 
> > Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
> >
> > Hi,
> >
> > On Thursday 06 March 2014 02:22 PM, Anton Tikhomirov wrote:
> > > 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.
> >
> > Didn't get you.. We don't want to invoke power_on when init is
> getting
> > executed or you don't want power on or power off to get executed
> > simultaneously right? So we need to protect it.
> 
> I mean callbacks such as samsung_usb2_phy_power_on() which uses
> spin_lock.
> It's already protected by mutex in phy_power_on().

Well... phy_power_on() uses mutex to protect power_on() callback.
power_on() is samsung_usb2_phy_power_on() in our case.
samsung_usb2_phy_power_on() uses spinlock.
My question is why do we need to use spinlock _inside_ callback
if it is already protected by mutex.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/