linux-kernel - Re: [PATCH v5 2/5] media: i2c: ov5645: Drop reading clock-frequency dt-property

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, 7 Apr 2020 09:22:41 +0300
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        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>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Lad Prabhakar <prabhakar.csengg@...il.com>,
        Maxime Ripard <maxime@...no.tech>
Subject: Re: [PATCH v5 2/5] media: i2c: ov5645: Drop reading clock-frequency
 dt-property

Hi Laurent,

On Mon, Apr 06, 2020 at 08:32:34PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> (CC'ing Maxime)
> 
> On Mon, Apr 06, 2020 at 07:51:08PM +0300, Sakari Ailus wrote:
> > On Mon, Apr 06, 2020 at 05:42:38PM +0100, Lad Prabhakar wrote:
> > > Modes in the driver are based on xvclk frequency fixed to 24MHz, but where
> > > as the OV5645 sensor can support the xvclk frequency ranging from 6MHz to
> > > 24MHz. So instead making clock-frequency as dt-property just let the
> > > driver enforce the required clock frequency.
> > 
> > Even if some current systems where the driver is used are using 24 MHz
> > clock, that doesn't mean there wouldn't be systems using another frequency
> > that the driver does not support right now.
> > 
> > The driver really should not set the frequency unless it gets it from DT,
> > but I think the preferred means is to use assigned-clock-rates instead, and
> > not to involve the driver with setting the frequency.
> > 
> > Otherwise we'll make it impossible to support other frequencies, at least
> > without more or less random defaults.
> 
> We're running in circles here.
> 
> As the driver only supports 24MHz at the moment, the frequency should be
> set by the driver, as it's a driver limitation. We can then work on
> supporting additional frequencies, which will require DT to provide a
> list of supported frequencies for the system, but that can be done on
> top.

I guess it would be possible to use different external clock frequencies on
a sensor in a given system but that seems to be a bit far fetched, to the
extent I've never seen anyone doing that in practice.

Originally, the driver set the frequency based on the clock-frequency
property. If we're removing that but use a fixed frequency instead, then
how is that going to work going forward when someone adds support for other
frequencies in the driver and has a system requiring that, while there are
some other platforms relying on the driver setting a particular frequency?

Although, if you're saying that this driver only needs to work with DT that
comes with the kernel and you don't care about DT binary compatibility,
this would be fine.

-- 
Regards,

Sakari Ailus