linux-kernel - Re: [PATCH v11 10/27] iommu/exynos: use managed device helper functions

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: <532AC6A2.9070307@gmail.com>
Date:	Thu, 20 Mar 2014 11:44:50 +0100
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	Cho KyongHo <pullip.cho@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>
CC:	Linux DeviceTree <devicetree@...r.kernel.org>,
	Linux Samsung SOC <linux-samsung-soc@...r.kernel.org>,
	Prathyush <prathyush.k@...sung.com>,
	Sachin Kamat <sachin.kamat@...aro.org>,
	Joerg Roedel <joro@...tes.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Grant Grundler <grundler@...omium.org>,
	Linux IOMMU <iommu@...ts.linux-foundation.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Varun Sethi <Varun.Sethi@...escale.com>,
	Antonios Motakis <a.motakis@...tualopensystems.com>,
	Linux ARM Kernel <linux-arm-kernel@...ts.infradead.org>,
	Rahul Sharma <rahul.sharma@...sung.com>
Subject: Re: [PATCH v11 10/27] iommu/exynos: use managed device helper functions

On 20.03.2014 11:03, Cho KyongHo wrote:
> On Wed, 19 Mar 2014 13:08:42 +0100, Tomasz Figa wrote:
>> On 19.03.2014 10:01, Sachin Kamat wrote:
>>> On 19 March 2014 14:29, Cho KyongHo <pullip.cho@...sung.com> wrote:
>>>> On Tue, 18 Mar 2014 16:14:53 +0100, Tomasz Figa wrote:
>>>>> On 18.03.2014 12:09, Cho KyongHo wrote:
>>>>>> On Fri, 14 Mar 2014 20:52:43 +0530, Sachin Kamat wrote:
>>>>>>> Hi KyongHo,
>>>>>>>
>>>>>>> On 14 March 2014 10:35, Cho KyongHo <pullip.cho@...sung.com> wrote:
>>>>>>>> This patch uses managed device helper functions in the probe().
>>>>>>>>
>>>>>>>> Signed-off-by: Cho KyongHo <pullip.cho@...sung.com>
>>>>>>>> ---
>>>>>>> [snip]
>>>>>>>
>>>>>>>> +       data->clk = devm_clk_get(dev, "sysmmu");
>>>>>>>> +       if (IS_ERR(data->clk)) {
>>>>>>>> +               dev_info(dev, "No gate clock found!\n");
>>>>>>>> +               data->clk = NULL;
>>>>>>>> +       }
>>>>>>>
>>>>>>> Why aren't you returning from here upon error?
>>>>>>
>>>>>> It is for the case of a System MMU which does not need clock gating.
>>>>>>
>>>>>
>>>>> Are there really such cases?
>>>>>
>>>>
>>>> Yes.
>>>> Especially in the case of initial stage of new SoC development.
>>>>
>>>> I have experianced some software workaround for H/W restriction
>>>> needs prevention of clock gating for some devices.
>>>
>>> So aren't these basically some exceptions/hacks rather than the usual way
>>> of functioning of the device?
>>>
>>
>> This actually raises a good question, whether we really need to support
>> such early development SoC versions in mainline.
>>
>> Another thing is that if you need to assure that a clock is ungated, you
>> must acquire it and prepare_enable explicitly, so I don't think this
>> kind of handling is correct.
>>
> On early development step of a new SoC, clock related stuffs and
> some device drivers like display controller are usually developed in parallel.
>
> In that case, -ENOENT from clk_get() must not treated as an error.
> "[PATCH v11 20/17] iommu/exynos: allow having multiple System MMUs for a master H/W"
> patch distinguishes -ENOENT from other error values returned by devm_clk_get().

I still don't think upstream is right place for such development hacks 
and such assumption will mask potential errors caused by clocks 
unspecified in DT.

If such thing is needed for development, an extra patch might be kept in 
development tree, until clock driver is implemented or a dummy 
fixed-rate clock might be specified in DT.

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/