linux-kernel - Re: [PATCH v5 1/4] dt-bindings: media: imx258: add bindings for IMX258 sensor

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: <20201020124654.GX13341@paasikivi.fi.intel.com>
Date:   Tue, 20 Oct 2020 15:46:54 +0300
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Rob Herring <robh@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-clk@...r.kernel.org
Subject: Re: [PATCH v5 1/4] dt-bindings: media: imx258: add bindings for
 IMX258 sensor

On Tue, Oct 20, 2020 at 02:26:21PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Oct 20, 2020 at 03:00:58PM +0300, Sakari Ailus wrote:
> > Hi Krzysztof,
> > 
> > On Tue, Oct 20, 2020 at 12:54:09PM +0200, Krzysztof Kozlowski wrote:
> > > On Tue, 20 Oct 2020 at 12:38, Sakari Ailus <sakari.ailus@...ux.intel.com> wrote:
> > > >
> > > > Hi Krzysztof,
> > > >
> > > > On Mon, Oct 19, 2020 at 07:02:44PM +0200, Krzysztof Kozlowski wrote:
> > > > > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > > > > driver, are quite limited, e.g. do not support regulator supplies.
> > > > >
> > > > > Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>
> > > > > Reviewed-by: Rob Herring <robh@...nel.org>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes since v4:
> > > > > 1. Add clock-lanes,
> > > > > 2. Add Rob's review,
> > > > > 3. Add one more example and extend existing one,
> > > > > 4. Add common clock properties (assigned-*).
> > > >
> > > > Using the assigned-* clock properties may be workable for this driver at
> > > > the moment. But using these properties does not guarantee the external
> > > > clock frequency intended to be used on the hardware.
> > > 
> > > It guarantees it. The clock frequency will be as expected (except if
> > > someone misconfigures the DTS).
> > 
> > Is that guaranteed?
> > 
> > I'm not saying no to the approach, but if we change how camera sensor DT
> > bindings are defined, I'd prefer an informed decision is made on the
> > matter.
> > 
> > > 
> > > > Using other
> > > > frequencies *is not* expected to work. That applies to this driver as well.
> > > 
> > > This is the binding which is HW description. According to HW datasheet
> > > other frequencies from described range are accepted and expected to
> > > work.
> > 
> > As per datasheet, yes, different external clock frequencies can be used.
> > But the link frequency is still not independent of the external clock
> > frequency.
> > 
> > The properties of the sensor's PLL tree determines what can be achieved
> > given a certain external clock frequency. So picking a wrong external clock
> > frequency quite possibly means that none of the designated link frequencies
> > are available, rendering the sensor inoperable.
> 
> The driver then controls the HW and knows exactly what is needed. If
> link frequency (which has its own DT property) requires some clock
> frequency, the driver will configure the clock to that value. The same

Well it doesn't if it doesn't get that information from DT.

The frequency is usually a range, and looking at these bindings, it's from
6 MHz to 27 MHz. That'd be a lot of frequencies for a driver to try.

> going other direction. Driver has the knowledge about both its input
> clock and link frequency, therefore it can make the best decision.

Again you're assuming a particular driver implementation.

Typically only a few frequencies are really available on platforms, so a in
practice a driver would not be able to get any requested frequency. I
wouldn't start hard-coding every possible frequency to camera sensor
drivers.

> > > > This, instead of the clock-frequency property, effectively removes the
> > > > ability to set the correct frequency from the driver, at least with current
> > > > set of the used APIs.
> > > 
> > > It seems you confuse DT bindings with some specific driver
> > > implementation. Bindings do not describe the driver behavior but the
> > > HW. The ability to set the correct frequency from the driver is not
> > > removed. It was never part of the bindings and never should. It is
> > > part of the driver.
> > > 
> > > >
> > > > I suppose you could add a function to set the assigned clock frequency and
> > > > keep it, just as clk_set_rate_exclusive does?
> 
> I did not reply to this comment, so let me know. Of course, one could
> add such functions. It's not a job for DT bindings, though.

I'm not suggesting to add it to DT binding patch. What I'm saying that with
this approach is looks like it may well be needed.

-- 
Regards,

Sakari Ailus