Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1283-g327e3ec917-fm-20231207.002-g327e3ec9
MIME-Version: 1.0
Message-Id: <1992d665-cb98-4190-bee3-e5629c7d0e8d@app.fastmail.com>
In-Reply-To: <20231213095849.GA2191@pendragon.ideasonboard.com>
References: <20231212213625.3653558-1-arnd@kernel.org>
 <ZXlmnmGepRnMyNfr@kekkonen.localdomain>
 <97a826ab-cd68-4494-884e-f7bd512a7bef@app.fastmail.com>
 <ZXl0-8VgzF3YH18i@kekkonen.localdomain>
 <20231213095849.GA2191@pendragon.ideasonboard.com>
Date:   Wed, 13 Dec 2023 12:23:05 +0100
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "laurent.pinchart" <laurent.pinchart@ideasonboard.com>,
        "Sakari Ailus" <sakari.ailus@linux.intel.com>
Cc:     "Arnd Bergmann" <arnd@kernel.org>,
        "Mauro Carvalho Chehab" <mchehab@kernel.org>,
        "Nathan Chancellor" <nathan@kernel.org>,
        "Jacopo Mondi" <jacopo.mondi@ideasonboard.com>,
        "Hans Verkuil" <hverkuil-cisco@xs4all.nl>,
        "Nick Desaulniers" <ndesaulniers@google.com>,
        "Bill Wendling" <morbo@google.com>,
        "Justin Stitt" <justinstitt@google.com>,
        "Hans de Goede" <hdegoede@redhat.com>,
        "Tomi Valkeinen" <tomi.valkeinen@ideasonboard.com>,
        linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
        llvm@lists.linux.dev
Subject: Re: [PATCH] media: i2c: mt9m114: add CONFIG_COMMON_CLK dependency
Content-Type: text/plain
Precedence: bulk

On Wed, Dec 13, 2023, at 10:58, Laurent Pinchart wrote:
> On Wed, Dec 13, 2023 at 09:10:19AM +0000, Sakari Ailus wrote:
>> On Wed, Dec 13, 2023 at 09:39:01AM +0100, Arnd Bergmann wrote:
>> > On Wed, Dec 13, 2023, at 09:09, Sakari Ailus wrote:
>> 
>> The datasheet says the input clock range is between 6 MHz and 54 MHz. We
>> could check that, and return an error if it's not in the range. The rate is
>> needed for other reasons, too, and the sensor is unlikely to work if it's
>> (more than little) off.
>> 
>> I wonder if this could address the Clang 16 issue, too? I'd replace
>> udelay() with fsleep() in any case, and at the very least Clang should be
>> happy with this.
>
> I'm fine with both of those changes.

I verified that the build failure is solved by either one.
I would just do the fsleep() change in that case since that
is a sensible change regardless of the undefined behavior.

I'll send a v2.

     Arnd