[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5318384B.7020009@ti.com>
Date: Thu, 6 Mar 2014 14:26:43 +0530
From: Kishon Vijay Abraham I <kishon@...com>
To: Anton Tikhomirov <av.tikhomirov@...sung.com>,
"'Kamil Debski'" <k.debski@...sung.com>,
<linux-kernel@...r.kernel.org>,
<linux-samsung-soc@...r.kernel.org>, <linux-usb@...r.kernel.org>,
<devicetree@...r.kernel.org>
CC: <kyungmin.park@...sung.com>, <t.figa@...sung.com>,
<s.nawrocki@...sung.com>, <m.szyprowski@...sung.com>,
<gautam.vivek@...sung.com>, <mat.krawczuk@...il.com>,
<yulgon.kim@...sung.com>, <p.paneri@...sung.com>,
<jg1.han@...sung.com>, <galak@...eaurora.org>,
<matt.porter@...aro.org>, <tjakobi@...h.uni-bielefeld.de>,
<stern@...land.harvard.edu>, <sander@...ilis.net>
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@...sung.com>
>>>> + *
>>>> + * 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.
Cheers
Kishon
--
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