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
| ||
|
Message-ID: <53183F98.1060100@ti.com> 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/
Powered by blists - more mailing lists