linux-kernel - Re: [PATCH RFC 3/4] clk: samsung: Add driver to control CLKOUT line on Exynos SoCs

Open Source and information security mailing list archives

Message-ID: <CAPdUM4O4RKFZFR_tcwG4pd7E6KMkneG9R_VbZPt+m4fGG_UFVg@mail.gmail.com>
Date:	Fri, 16 May 2014 20:05:12 +0530
From:	Rahul Sharma <rahul.sharma@...sung.com>
To:	Tomasz Figa <t.figa@...sung.com>
Cc:	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Mike Turquette <mturquette@...aro.org>,
	Pankaj Dubey <pankaj.dubey@...sung.com>,
	Mark Brown <broonie@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Tushar Behera <tushar.behera@...aro.org>
Subject: Re: [PATCH RFC 3/4] clk: samsung: Add driver to control CLKOUT line
 on Exynos SoCs

On 16 May 2014 16:22, Tomasz Figa <t.figa@...sung.com> wrote:
> Hi Rahul,
>
> On 16.05.2014 12:39, Rahul Sharma wrote:
>> [snip]
>>> +       gate->lock = &clkout_lock;
>>> +
>>> +       mux->reg = reg + EXYNOS_PMU_DEBUG_REG;
>>> +       mux->mask = EXYNOS_CLKOUT_MUX_MASK;
>>> +       mux->shift = EXYNOS_CLKOUT_MUX_SHIFT;
>>> +       mux->lock = &clkout_lock;
>>> +
>>> +       clk = clk_register_composite(NULL, "clkout", parent_names,
>>> +                                       parent_count, &mux->hw,
>>> +                                       &clk_mux_ops, NULL, NULL, &gate->hw,
>>> +                                       &clk_gate_ops, 0);
>>> +       if (IS_ERR(clk))
>>> +               goto err_unmap;
>>> +
>>
>> Hi Tomasz,
>>
>> Do we really need a composite clock here? How about registering
>> a mux and a gate separately?
>
> What's wrong with a composite clock? It simplifies the code as just a
> single clock needs to be registered. I don't see any drawbacks compared
> to registering two clocks separately.
>

I always took it as a thumb rule to not to use composite clocks if you
can easily represent the block using basic clocks structures.

There can be a problem when drivers using such clocks assume that such
clock continue to offer composite functionality for all futures SoCs and
write code around it. This is what we faced when fixing drivers during
CCF migration.

> Best regards,
> Tomasz
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/

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