linux-kernel - Re: [PATCH v3 6/7] clk: qcom: Add display clock controller driver for SM8150

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: <160092815523.310579.15502532225598451868@swboyd.mtv.corp.google.com>
Date:   Wed, 23 Sep 2020 23:15:55 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Jonathan Marek <jonathan@...ek.ca>, linux-arm-msm@...r.kernel.org
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v3 6/7] clk: qcom: Add display clock controller driver for SM8150

Quoting Jonathan Marek (2020-09-23 09:24:04)
> On 9/22/20 3:04 PM, Stephen Boyd wrote:
> > Quoting Jonathan Marek (2020-09-11 08:34:06)
> >> Add support for the display clock controller found on SM8150
> >> based devices. This would allow display drivers to probe and
> >> control their clocks.
> >>
> >> Signed-off-by: Jonathan Marek <jonathan@...ek.ca>
> >> ---
> >>   drivers/clk/qcom/Kconfig         |    9 +
> >>   drivers/clk/qcom/Makefile        |    1 +
> >>   drivers/clk/qcom/dispcc-sm8150.c | 1152 ++++++++++++++++++++++++++++++
> >>   3 files changed, 1162 insertions(+)
> >>   create mode 100644 drivers/clk/qcom/dispcc-sm8150.c
> > 
> > If the bindings are the same for these two drivers I wonder if there is
> > anything different between the two. Maybe the two drivers can be one
> > driver?
> > 
> 
> Possibly, the biggest difference seems to be the plls (trion vs lucid, 
> different config), which could be resolved in the probe() function. If 
> you think combining the drivers is the right thing to do then I can do that.

If that's the main difference then it sounds OK to merge the two.