linux-kernel - Re: [PATCH 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically

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]

Date:   Tue, 18 Apr 2023 10:47:07 +0200
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Marek Vasut <marex@...x.de>, Adam Ford <aford173@...il.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        aford@...conembedded.com, dri-devel@...ts.freedesktop.org,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        m.szyprowski@...sung.com, Robert Foss <rfoss@...nel.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Jagan Teki <jagan@...rulasolutions.com>,
        NXP Linux Team <linux-imx@....com>,
        devicetree@...r.kernel.org, Jonas Karlman <jonas@...boo.se>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-kernel@...r.kernel.org,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>
Subject: Re: [PATCH 3/6] drm: bridge: samsung-dsim: Fetch
 pll-clock-frequency automatically

Am Dienstag, dem 18.04.2023 um 10:30 +0200 schrieb Marek Vasut:
> On 4/18/23 04:29, Adam Ford wrote:
> > On Sun, Apr 16, 2023 at 5:08 PM Marek Vasut <marex@...x.de> wrote:
> > > 
> > > On 4/15/23 12:41, Adam Ford wrote:
> > > > Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> > > > having an entry in the device tree for samsung,pll-clock-frequency.
> > > > 
> > > > Signed-off-by: Adam Ford <aford173@...il.com>
> > > > ---
> > > >    drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++++++------
> > > >    1 file changed, 6 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > index 9fec32b44e05..73f0c3fbbdf5 100644
> > > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > > @@ -1744,11 +1744,6 @@ static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
> > > >        struct device_node *node = dev->of_node;
> > > >        int ret;
> > > > 
> > > > -     ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
> > > > -                                    &dsi->pll_clk_rate);
> > > > -     if (ret < 0)
> > > > -             return ret;
> > > > -
> > > >        ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
> > > >                                       &dsi->burst_clk_rate);
> > > >        if (ret < 0)
> > > 
> > > Does this break compatibility with old samsung DTs ?
> > 
> > My goal here was to declutter the device tree stuff and fetch data
> > automatically if possible. What if I changed this to make them
> > optional?  If they exist, we can use them, if they don't exist, we
> > could read the clock rate.  Would that be acceptable?
> 
> If you do not see any potential problem with ignoring the DT property 
> altogether, that would be better of course, but I think you cannot do 
> that with old DTs, so you should retain backward compatibility fallback, 
> yes. What do you think ?

I'm very much in favor of this patch, but I also think we shouldn't
risk breaking Samsung devices, where we don't now 100% that the input
clock rate provided by the clock driver is correct.

So I think the right approach is to use "samsung,pll-clock-frequency"
when present in DT and get it from the clock provider otherwise. Then
just remove the property from the DTs where we can validate that the
input clock rate is correct, i.e. all i.MX8M*.

Regards,
Lucas