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] [day] [month] [year] [list]
Message-ID: <20210916163000.6ezo6muhq23bewyi@gilmour>
Date:   Thu, 16 Sep 2021 18:30:00 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc:     linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        linux-kernel@...r.kernel.org, linux-phy@...ts.infradead.org,
        linux-clk@...r.kernel.org, linux-staging@...ts.linux.dev,
        Yong Deng <yong.deng@...ewell.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Helen Koike <helen.koike@...labora.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 01/22] clk: sunxi-ng: v3s: Make the ISP PLL clock public

Salut Paul,

On Mon, Sep 13, 2021 at 10:53:51AM +0200, Paul Kocialkowski wrote:
> On Mon 13 Sep 21, 09:54, Maxime Ripard wrote:
> > On Fri, Sep 10, 2021 at 08:41:26PM +0200, Paul Kocialkowski wrote:
> > > In order to reparent the CSI module clock to the ISP PLL via
> > > device-tree, export the ISP PLL clock declaration in the public
> > > device-tree header.
> > 
> > You use clk_set_rate_exclusive in the ISP driver on the module clock so
> > it should prevent what you're mentioning from happening.
> 
> It does, but then it breaks display support entirely (because the DRM
> driver doesn't use clk_set_rate_exclusive).
> 
> The bottomline is that using the same PLL for both display and camera
> easily results in conflicts.

The commit log should reflect that then

> > If it doesn't, then clk_set_rate_exclusive has a bug and should be
> > fixed.
> > 
> > Either way, using assigned-clock-parents is not a good solution here
> > either, it only makes sure that this is the case when probe is run.
> 
> I'm not sure what could provide better guarantees. There is a clock
> parenting API (in the clock framework) which may, but this implies
> providing the parent clock to the driver which seems way out of line
> since this is a platform-specific matter that should certainly not
> be handled by the driver.
> 
> I also tried hardcoding the reparenting bit in the CCU driver, but
> this felt less clean than doing it in device-tree.
> 
> What do you think?

This is essentially policy, and putting it in the DT fails for the
reason we already discussed, but also if we ever want to change it for
example to optimize it a bit. In this case, we would have to deal with
the old and new DT, and the possible consequences.

So yeah, hardcoding it in the clock driver seems like a more sensible
choice.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ