linux-kernel - Re: [linux-sunxi] Re: [PATCH v2 5/9] drm/sun4i: tcon

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMty3ZBDjNa+Sso4hmKxXOg_LT8giNYQAuJCgjZW8AeVQhAtyQ@mail.gmail.com>
Date:   Tue, 18 Jun 2019 13:16:50 +0530
From:   Jagan Teki <jagan@...rulasolutions.com>
To:     Chen-Yu Tsai <wens@...e.org>
Cc:     Maxime Ripard <maxime.ripard@...tlin.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Michael Trimarchi <michael@...rulasolutions.com>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        linux-amarula <linux-amarula@...rulasolutions.com>
Subject: Re: [linux-sunxi] Re: [PATCH v2 5/9] drm/sun4i: tcon_top: Register
 clock gates in probe

On Tue, Jun 18, 2019 at 12:53 PM Chen-Yu Tsai <wens@...e.org> wrote:
>
> On Tue, Jun 18, 2019 at 3:12 PM Jagan Teki <jagan@...rulasolutions.com> wrote:
> >
> > On Mon, Jun 17, 2019 at 6:31 PM Chen-Yu Tsai <wens@...e.org> wrote:
> > >
> > > On Mon, Jun 17, 2019 at 7:45 PM Maxime Ripard <maxime.ripard@...tlin.com> wrote:
> > > >
> > > > On Fri, Jun 14, 2019 at 10:13:20PM +0530, Jagan Teki wrote:
> > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > now these are register during bind call.
> > > > >
> > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > but same can miss to get since tcon top is not bound at
> > > > > that time.
> > > > >
> > > > > To solve, this circular dependency move the clock gate
> > > > > registration from bind to probe so-that DPHY can get the
> > > > > dsi gate clock on time.
> > > >
> > > > It's not really clear to me what the circular dependency is?
> > > >
> > > > if you have a chain that is:
> > > >
> > > > tcon-top +-> DSI
> > > >          +-> D-PHY
> > > >
> > > > There's no loop, right?
> > >
> > > Looking at how the DTSI patch structures things (without going into
> > > whether it is correct or accurate):
> > >
> > > The D-PHY is not part of the component graph. However it requests
> > > the DSI gate clock from the TCON-TOP.
> > >
> > > The TCON-TOP driver, in its current form, only registers the clocks
> > > it provides at component bind time. Thus the D-PHY can't successfully
> > > probe until the TCON-TOP has been bound.
> > >
> > > The DSI interface requires the D-PHY to bind. It will return -EPROBE_DEFER
> > > if it cannot request it. This in turn goes into the error path of
> > > component_bind_all, which unbinds all previous components.
> > >
> > > So it's actually
> > >
> > >     D-PHY -> TCON-TOP -> DSI
> > >       ^                   |
> > >       |--------------------
> > >
> > > I've not checked, but I suspect there's no possibility of having other
> > > drivers probe (to deal with deferred probing) within component_bind_all.
> > > Otherwise we shouldn't run into this weird circular dependency issue.
> > >
> > > So the question for Jagan is that is this indeed the case? Does this
> > > patch solve it, or at least work around it.
> >
> > Yes, this is what I was mentioned in initial version, since the "dsi"
> > gate in tcon top is registering during bind, the dphy of dsi
> > controller won't get the associated clock for "mod" so it is keep on
> > returning -EPROBE_DEFER. By moving the clock gate registration to
> > probe, everything bound as expected.
>
> I believe you failed to mention the DSI block, which is the part that
> completes the circular dependency. Don't expect others to have full
> awareness of the context. You have to provide it in your commit log.

I have mentioned DPHY and yes it is possible to give more information
will update in next version, no problem. thanks for mentioning that.