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]

Message-id: <006301cf391a$c99c7280$5cd55780$%tikhomirov@samsung.com>
Date:	Thu, 06 Mar 2014 18:02:22 +0900
From:	Anton Tikhomirov <av.tikhomirov@...sung.com>
To:	'Kishon Vijay Abraham I' <kishon@...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,

> 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().

> 
> 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/