linux-kernel - Re: [PATCH v3 1/3] phy: Add exynos-simple-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: <5375ED80.2010008@samsung.com>
Date:	Fri, 16 May 2014 12:50:40 +0200
From:	Tomasz Figa <t.figa@...sung.com>
To:	Rahul Sharma <rahul.sharma@...sung.com>,
	Tomasz Figa <tomasz.figa@...il.com>
Cc:	Tomasz Stanislawski <t.stanislaws@...sung.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	PANKAJ KUMAR DUBEY <pankaj.dubey@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	sunil joshi <joshi@...sung.com>,
	Andrzej Hajda <a.hajda@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Grant Likely <grant.likely@...aro.org>,
	Sylwester Nawrocki <sylvester.nawrocki@...il.com>,
	Kishon Vijay Abraham I <kishon@...com>
Subject: Re: [PATCH v3 1/3] phy: Add exynos-simple-phy driver

On 16.05.2014 12:35, Rahul Sharma wrote:
> On 16 May 2014 15:12, Rahul Sharma <rahul.sharma@...sung.com> wrote:
>> On 16 May 2014 03:14, Tomasz Figa <tomasz.figa@...il.com> wrote:
>>> On 15.05.2014 06:01, Rahul Sharma wrote:
> [snip]
>>>>> the PHY provider.
>>>>>
>>>>
>>>> Please correct me if I got you wrong. You want somthing like this:
>>>>
>>>> pmu_system_controller: system-controller@...40000 {
>>>>          ...
>>>>           simple_phys: simple-phys {
>>>>                         compatible = "samsung,exynos5420-simple-phy";
>>>>                         ...
>>>>           };
>>>> };
>>>
>>> Not exactly.
>>>
>>> What I meant is that the PMU node itself should be the PHY provider, e.g.
>>>
>>> pmu_system_controller: system-controller@...40000 {
>>>         /* ... */
>>>         #phy-cells = <1>;
>>> };
>>>
>>> and then the PMU node should instantiate the Exynos simple PHY driver,
>>> as this is a driver for a facility existing entirely inside of the PMU.
>>> Moreover, the driver should be rather called Exynos PMU PHY.
>>>
>>> I know this isn't really possible at the moment, but with device tree we
>>> must design things carefully, so it's better to take a bit more time and
>>> do things properly.
>>>
>>> So my opinion on this is that there should be a central Exynos PMU
>>> driver that claims the IO region and instantiates necessary subdrivers,
>>> such as Exynos PMU PHY driver, Exynos CLKOUT driver, Exynos cpuidle
>>> driver and more, similar to what is being done in drivers/mfd.
>>
> 
> Hi Tomasz,
> 
> These PHYs are not part of PMU as such. I am not sure if it is correct to
> probe them as phy provider for all these phys. Only relation of these phys with
> the PMU is 'enable/disable control'.

Well, in reality what is implemented by this driver is not even a PHY,
just some kind of power controllers, which are contained entirely in the
PMU.

> Controlling this bit using regmap interface
> still looks better to me.

Well, when there is a choice between using regmap and not using regmap,
I'd rather choose the latter. Why would you want to introduce additional
abstraction layer if there is no need for such?

> 
> IMHO Ideal method would be probing these PHYs independently and resolving
> the necessary dependencies like syscon handle, clocks etc. This way we will
> not be having any common phy provider for all these independent PHYs and it
> would be clean to add each of these phy nodes in DT. Please see my original
> comment below.
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1404.1/00701.html

With the solution I proposed, you don't need any kind of dependencies
for those simple power controllers. They are just single bits that don't
need anything special to operate, except PMU clock running.

Best regards,
Tomasz
--
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/