linux-kernel - Re: [PATCH v1 0/2] Add QCOM video clock controller driver

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, 08 May 2018 13:15:07 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Amit Nischal <anischal@...eaurora.org>,
        Rob Herring <robh@...nel.org>
Cc:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Odelu Kukatla <okukatla@...eaurora.org>,
        Taniya Das <tdas@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-soc@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org, linux-clk-owner@...r.kernel.org
Subject: Re: [PATCH v1 0/2] Add QCOM video clock controller driver

Quoting Rob Herring (2018-05-08 05:48:07)
> On Mon, May 7, 2018 at 11:53 PM, Amit Nischal <anischal@...eaurora.org> wrote:
> > On 2018-05-07 22:41, Rob Herring wrote:
> >>
> >> On Mon, May 07, 2018 at 04:16:53PM +0530, Amit Nischal wrote:
> >>>
> >>> On 2018-05-04 22:01, Stephen Boyd wrote:
> >>> > Quoting Amit Nischal (2018-05-03 05:35:23)
> >>> > > Changes in v1:
> >>> > >    https://lkml.org/lkml/2018/4/24/545
> >>> > > Addressed below review comments given by Rob
> >>> > > - Change the compatible property as per '<vendor>,<soc>-<block>'
> >>> > > format.
> >>> > > - Add header definitions for resets and power-domain cells.
> >>> >
> >>> > You didn't add any reset definitions though?
> >>>
> >>> We haven't added the reset definitions for videocc as there is no
> >>> video reset client.
> >>
> >>
> >> So? You don't know what resets there are?
> >>
> >
> > We know the resets, but video driver doesn't do any block resets
> > prior to accessing the video subsystem so that's the reason we do
> > not want to expose the resets in videocc driver.
> 
> Bindings don't have to match what drivers currently use but should be
> complete as possible.

Right. Please add the #defines in the header file for the resets. You
can leave them out of the driver if you really want to, but typically we
still add them and then rely on not touching them if they shouldn't be
used.