linux-kernel - Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver

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]

Date:	Thu, 6 Mar 2014 14:57:52 +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:49 PM, Anton Tikhomirov wrote:
> 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@...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.
>>
>> 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.

It is needed when the same PHY provider implements multiple PHYs. 
phy-core can protect phy-ops of same PHY. However if the PHY provider 
implements multiple PHYs, phy-core won't be able to protect.

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/