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 X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC1AEC433F5 for ; Thu, 16 Sep 2021 10:48:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8E2C861212 for ; Thu, 16 Sep 2021 10:48:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236647AbhIPKtp (ORCPT ); Thu, 16 Sep 2021 06:49:45 -0400 Received: from smtp-relay-internal-0.canonical.com ([185.125.188.122]:41046 "EHLO smtp-relay-internal-0.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235628AbhIPKtn (ORCPT ); Thu, 16 Sep 2021 06:49:43 -0400 Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 94A983FDC7 for ; Thu, 16 Sep 2021 10:48:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1631789302; bh=kVs9piweAjfYKX1/D2zYPYLh8oMdXLORitDm0x3OItc=; h=To:Cc:References:From:Subject:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=Z+L8RQG5ANhF34LExzxkQYwIdTOymYuyFGbAHKYFocaLCX0/e2gUFpLHUB9WHRMMs 7A2Y25zay3vg8bmSJm1K40XQMR2jhvOsRc4vZkPB27prf/XX70m7XzbDbKEzOrsDA5 4eN/c8CFj+3UMf/Id1ONvw7cbHle7KJshuKrLgiYqok8CT6sAc05yIyJCAraZx1k3b N0/Nj9iN/a3to9lQ3xF20cC6lxLica/SZUGPtlS0AB1vyKuV8NEbijWM3BcMnrCN6Q YunoCZdIEJnEx1excPiW39+kxfF95/AHsSnOkbL1sCOA6iNY/j3y4UVdrfkZDtEbs8 Q/5MwZYmU8B9w== Received: by mail-ed1-f71.google.com with SMTP id n5-20020a05640206c500b003cf53f7cef2so2230128edy.12 for ; Thu, 16 Sep 2021 03:48:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kVs9piweAjfYKX1/D2zYPYLh8oMdXLORitDm0x3OItc=; b=QrnWaLx98beYAcs8zn/kEfy45BNIU9jqYxNtIZc9T4RGCpHuBasrGJVfoqZw9JHHWS ToznBCjYi76kDScxE0aRQwg3I/kaCiOhTxZTVwyLtyF+NR65uW+RB8b7g5SvRgjoWojB nyR8sjqsNeVcVCrGBq7JwojbG1TrkwbjmzKtjhnHIU31vaBgU0DiQufNR3pXZQudbZ9G yPmGfmV24Sav1mk/PEictoOORIU/CsZm2uyRfV7sVlefGnuDp7inOR550ZoJlIYC/Fbe 0kJNjky61g+u/y+pDKjQ3wQEtSJh/Dt9VpLnd6mbbYg7s6lLW7OM3WvwJHMhsvrf5288 F9XQ== X-Gm-Message-State: AOAM531G0alsXXzQko/2mU7rSVMuY5OX67MwnAczRMZGLzqAdITs3M8L 4oqX41g3pa5gBGsVgySHs5OqHz/dY3lYtZZRg61MYzpQetlB9KXLuGuUEBzZiopQ0ARropUoTZl LMMOALcbyQ7yo12qJuBFuCK/sYmG2WY+3cmoydjJLgw== X-Received: by 2002:a17:906:d045:: with SMTP id bo5mr5518403ejb.461.1631789301890; Thu, 16 Sep 2021 03:48:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynS1M3E+u6uh9PExpnyfy/1dCw+s8TwhyM85ZmKchIA4QZXHFyZ+/z9Io2RWKgwjZkL25Tow== X-Received: by 2002:a17:906:d045:: with SMTP id bo5mr5518370ejb.461.1631789301532; Thu, 16 Sep 2021 03:48:21 -0700 (PDT) Received: from [192.168.3.211] (lk.84.20.244.219.dc.cable.static.lj-kabel.net. [84.20.244.219]) by smtp.gmail.com with ESMTPSA id m10sm1007452ejx.76.2021.09.16.03.48.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Sep 2021 03:48:21 -0700 (PDT) To: Roger Quadros , tony@atomide.com Cc: robh+dt@kernel.org, grygorii.strashko@ti.com, nm@ti.com, lokeshvutla@ti.com, nsekhar@ti.com, miquel.raynal@bootlin.com, devicetree@vger.kernel.org, linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210907113226.31876-1-rogerq@kernel.org> <20210907113226.31876-9-rogerq@kernel.org> From: Krzysztof Kozlowski Subject: Re: [PATCH v3 8/8] memory: gpmc-omap: "gpmc,device-width" DT property is optional Message-ID: <35643319-e3b0-bde1-c51b-57c3b5474146@canonical.com> Date: Thu, 16 Sep 2021 12:48:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/09/2021 11:11, Roger Quadros wrote: > Hi Krzysztof, > > On 07/09/2021 15:36, Krzysztof Kozlowski wrote: >> On 07/09/2021 13:32, Roger Quadros wrote: >>> Check for valid gpmc,device-width, nand-bus-width and bank-width >>> at one place. Default to 8-bit width if none present. >> >> I don't understand the message in the context of the patch. The title >> says one property is optional - that's it. The message says you >> consolidate checks. How is this related to the title? >> >> The patch itself moves around checking of properties and reads >> nand-bus-width *always*. It does not "check at one place" but rather >> "check always". In the same time, the patch does not remove >> gpmc,device-width check in other place. >> >> All three elements - the title, message and patch - do different things. >> What did you want to achieve here? Can you help in clarifying it? >> > > OK I will explain it better in commit log in next revision. Let me explain here a bit. > > Prior to this patch it was working like this > > /* in gpmc_read_settings_dt() */ > s->device_width = 0; /* invalid width, should be 1 for 8-bit, 2 for 16-bit */ > of_property_read_u32(np, "gpmc,device-width", s->device_width); > > /* in gpmc_probe_generic_child () */ > if (of_device_is_compatible(child, "ti,omap2-nand")) { > /* check for nand-bus-width, if absent set s->device_width to 1 (i.e. 8-bit) */ > } else { > /* check for bank-width, if absent and s->device_width not set, error out */ > } > > So that means if all three, "gpmc,device-width". "nand-bus-width" and "bank-width" are missing then > it would create an error situation. > > The patch is doing 3 things. > 1) Make sure all DT checks related to bus width are being done at one place for better readability. Not entirely. The gpmc,device-width is still done in the other place because you did not remove it from the code. Unless you meant parsing of gpmc,device-width not reading from DT? But then another round of checks is in gpmc_cs_program_settings() so not in one place. If you consolidate the checks to one place, I would expect the code to be removed from other places, so from gpmc_cs_program_settings() and gpmc_read_settings_dt(). Since this is not happening, the message confuses me. > 2) even if all 3 width properties are absent, we will not treat it as error and default to 8-bit. This is not mentioned in commit msg. > 3) check for nand-bus-width regardless of whether compatible to "ti,omap2-nand" or not. Also not mentioned in commit msg. Your commit reorganizes parsing and validating the child DT properties but it does not change from "multiple place" to "one place". At least I don't see it. Best regards, Krzysztof