From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7AE6C4332F for ; Tue, 15 Nov 2022 18:16:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229681AbiKOSQ6 (ORCPT ); Tue, 15 Nov 2022 13:16:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231447AbiKOSQz (ORCPT ); Tue, 15 Nov 2022 13:16:55 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B5812FC15; Tue, 15 Nov 2022 10:16:54 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1FA91B81A5F; Tue, 15 Nov 2022 18:16:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4B96C4347C; Tue, 15 Nov 2022 18:16:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668536211; bh=nzoZVtAKQJIQTeBQutSbLNEtJkG6ZK7nNNBfDg5J8IA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UvaUm07ab0P3VMqxkWKNgDghtJE+sdtZU1KHbWuBHxvVyOJ9sO61YjPzGaKkmKYrq f7JGa153pJJU9JEud0fFO9J4y9NOGg9zeYUr/0B3Vv52YIWEWAb5HN6sAnvqin8B4o iynVRwQvBe0avgQkEsCj379VZM8etj5v6EdNlAjhkazH7zDcGIFGZTkoLBwfkHkaFs p/WDMqPuvPlNZ3PUhqlPZUInDfzeXcF3LDAmHDdv8BdudC0VczKdrbCYT3XAEUs3Op FuHn4kCjcsNAStEAMdonN/qbzJP09QF+zn/icCLJFKyMGC7IeAT+iAJ5Sbw75ZejZs K/8Z1P7Ixxc6Q== Received: by mail-lf1-f54.google.com with SMTP id c1so25721791lfi.7; Tue, 15 Nov 2022 10:16:51 -0800 (PST) X-Gm-Message-State: ANoB5pno0b0n3PePQMgINym4MGj1rooed6kql1dzP4ErKwNEa7B2AZXp 0EHPygDxSmoUWk22ohVqG7gONwdffhvGrPLkoA== X-Google-Smtp-Source: AA0mqf5ylXTe8JPsQerawu90MDYFzRHw/tk4HjTbjmj7U/3adbjHDxKMSHfzzcjyFwjdnPjfg8KUmkUC1XS9l9OLAcg= X-Received: by 2002:ac2:5cc3:0:b0:4ab:5a19:3455 with SMTP id f3-20020ac25cc3000000b004ab5a193455mr5796390lfq.462.1668536209685; Tue, 15 Nov 2022 10:16:49 -0800 (PST) MIME-Version: 1.0 References: <20221103094436.2136698-1-demonsingur@gmail.com> <20221103094436.2136698-2-demonsingur@gmail.com> <20221106154634.2286faf3@jic23-huawei> <20221112154040.54dc5cf2@jic23-huawei> <20221115160724.00007460@Huawei.com> In-Reply-To: <20221115160724.00007460@Huawei.com> From: Rob Herring Date: Tue, 15 Nov 2022 12:16:41 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/2] dt-bindings: iio: addac: add AD74115 To: Jonathan Cameron Cc: Cosmin Tanislav , Jonathan Cameron , Krzysztof Kozlowski , Cosmin Tanislav , Lars-Peter Clausen , Michael Hennerich , Linus Walleij , William Breathitt Gray , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Nov 15, 2022 at 10:07 AM Jonathan Cameron wrote: > > On Tue, 15 Nov 2022 14:43:53 +0200 > Cosmin Tanislav wrote: > > > On Sat, 2022-11-12 at 15:40 +0000, Jonathan Cameron wrote: > > > > > > > > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > + description: | > > > > > > + Conversion range for ADC conversion 2. > > > > > > + 0 - 0V to 12V > > > > > > + 1 - -12V to +12V > > > > > > + 2 - -2.5V to +2.5V > > > > > > + 3 - -2.5V to 0V > > > > > > + 4 - 0V to 2.5V > > > > > > + 5 - 0V to 0.625V > > > > > > + 6 - -104mV to +104mV > > > > > > + 7 - 0V to 12V > > > > > > > > > > For a lot of similar cases we handle these numerically to give > > > > > a human readable dts. Is there a strong reason not to do so here (in mv) > > > > > > > > > > > > > I used this approach mostly because it maps dirrectly to register values > > > > and because it's easier to parse. dts isn't exactly nice at handling > > > > negative values. I can switch it to mv array if you insist. > > > > > > We have quite a few existing cases of > > > adi,[output-]range-microvolt so it would be good to copy that style here. > > > > > > > With this: > > > > adi,conv2-range-microvolt: > > description: Conversion range for ADC conversion 2. > > oneOf: > > - items: > > - enum: [-2500000, 0] > > - const: 2500000 > > - items: > > - enum: [-12000000, 0] > > - const: 12000000 > > - items: > > - const: -2500000 > > - const: 0 > > - items: > > - const: -104000 > > - const: 104000 > > - items: > > - const: 0 > > - const: 625000 > > > > And this: > > > > adi,conv2-range-microvolt = <(-12000000) 12000000>; > > > > I get this: > > > > Documentation/devicetree/bindings/iio/addac/adi,ad74115.example.dtb: > > addac@0: adi,conv2-range-microvolt: 'oneOf' conditional failed, > > one must be fixed: > > 4282967296 is not one of [-2500000, 0] > > 4282967296 is not one of [-12000000, 0] > > -2500000 was expected > > -104000 was expected > > 625000 was expected > > From schema: Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml > > > > As I said, negative numbers don't play too nice... > > From what I recall we just ignore those warnings :) > > Rob, do I remember correctly that there was a plan to make this work longer term? Yes, but handling signed types is working now (since the move to validating dtbs directly). The issue here is -microvolt is defined as unsigned. IIRC, I had some issue changing it, but I think that was just with the YAML encoding which I intend to remove. I'll give it another look and update the type if there's no issues. Rob