Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp3649267ybk; Tue, 19 May 2020 09:37:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1QWfPqceMIjUnX3J2zn1UUphhb1WfIKGNMbIwiN4XUxh5mE624+rdueB53YFe5vVfef+3 X-Received: by 2002:a17:906:409:: with SMTP id d9mr34970eja.445.1589906231954; Tue, 19 May 2020 09:37:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589906231; cv=none; d=google.com; s=arc-20160816; b=mrxwy0neSb5PHsi4FwZ8+334oEJDhNCEfQ1U4ivvbGUJ3BX50kiwP2owxEBOJzwolN t+v9W5xQy6ftHpgxT/9pf2JfTNmfA4NIiRTCYs519kQS22Juyi7pWVN0NT6+Qc+JXu7e y5gTt3WCOdAg3xICO4ImLQnD+R4h+J1MD2bP8fXIJHdibyLLs+kNsAJveT9x5wN1Aj+c VqR3JNAGQ9imJa2czJneQbcylYfj8+Oad/oPQSaH+QN80cx2uHN276kNwOsLlHOxQ6ow yfETBO4fZvGsOERyNiZDa8TnLNGDfJRsYmWCD3/IehF5Us8CEFZry2dNjMIprhDpRKAe OmVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=erHld5g8aUsGObcGGn0MGFVIEHLOUjB0Us6LDfsWtwI=; b=lAxA1qxYlVB3FaXv3nSqmG7jrZiVSdP9xWN4cpiRWEWe00SI9Ila8zfK4Jb7qySZQE HZUyi8rFS02Au+cF7jJl/NDjg394jOe6CCtMAJYoA1fZWXgHDdnjEsqymwsIlrexDdc7 +DW+keIRMkbnRL4PRfpY8+G7czJWcFROVFxv1BGALPE4CnVdwGQHXAcn0KvIlc/cGGfb slx398UffX1FWTGH+LxtN8YlC98//+a8TjTdIfXeVWEH1OjpZoQuCtO3IZiYf8d6ernx gl8ZpkIiiyZV9eqxmKwUFapBj1nPPXo5277uty+v1nZalWwSkYoeg5xTzqDy58rpxSSY mNPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PXXIEkHb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk26si6742903edb.179.2020.05.19.09.36.47; Tue, 19 May 2020 09:37:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PXXIEkHb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729493AbgESQdr (ORCPT + 99 others); Tue, 19 May 2020 12:33:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729488AbgESQdn (ORCPT ); Tue, 19 May 2020 12:33:43 -0400 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E863BC08C5C0; Tue, 19 May 2020 09:33:41 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id c12so40979lfc.10; Tue, 19 May 2020 09:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=erHld5g8aUsGObcGGn0MGFVIEHLOUjB0Us6LDfsWtwI=; b=PXXIEkHbyn+P/kMEEJSfC4wL0O4hX4OmmwcfZbc+VOa1IlbTxAww8MjZF1eb69czSl JhNxWfdAvNvf0aLOJ2zIgjjWjoo3/qMuhePXkwjT47u0273RtTb2w6fbghDsX1IyOsh7 ycbxPguVWsvQKY0q2jHaG22jnYYiiQMY92Rhi39x4/Lpu35VITIeAg19c9SUDG8w/qVo OX3zjE3HtGEFaPiApNAXpWAwHWvFp5S5zxBcHjnSAgOQpvSbZOc664cbBcgISbUKtgLG FhgDukKAHwsL4iNX8v0Uc6U3aGczmzdO5M2bQ+S/NnIv/eLlwVXMGR8NYl2RmzgB+wk1 u8mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=erHld5g8aUsGObcGGn0MGFVIEHLOUjB0Us6LDfsWtwI=; b=mZVYCtG+b8MGjjdEASra3n+ImZWjkBDnrWDrC04vcBrkKpwVrAzsBgrLbKLTXgh3yR /2fn0nTzN+q2YQxeqF9vf0MQgbBA0peUj4mfnBgY7B2h6ExnN2tPKoAeKTGRcbaLgyw7 /EHdPZ3vbE2Oh0aZi1Ifok1uZdAI61FFAAarRYs64E1Z1tMXUOi/TqG5L3LZNIIbZyld ceCYu6T93g6eN86KXYKA83yokL8qi4zJdYX2NlvVdODRfQFKshE6CqH6XxIXzXdHnPDp xtcjFHup8nGbEc/qjM5zHoe3pANHaDpaOxD+GnsyCqhiSix3mPuPWd3hpbN164eFfKFT piZw== X-Gm-Message-State: AOAM531y+Ayjle6mwW5EvlH6xxYXtEVRvsYkdKpecs7K+YN5emUbOIm/ jAxzSxZP/Ohh6GqO7ruNWANN11Iw X-Received: by 2002:ac2:5ccf:: with SMTP id f15mr15638072lfq.216.1589906019877; Tue, 19 May 2020 09:33:39 -0700 (PDT) Received: from [192.168.2.145] (ppp91-78-208-152.pppoe.mtu-net.ru. [91.78.208.152]) by smtp.googlemail.com with ESMTPSA id v4sm52411ljj.104.2020.05.19.09.33.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2020 09:33:39 -0700 (PDT) Subject: Re: [PATCH v1] sdhci: tegra: Remove warnings about missing device-tree properties To: Thierry Reding Cc: Ulf Hansson , Jonathan Hunter , Adrian Hunter , Sowjanya Komatineni , "linux-mmc@vger.kernel.org" , linux-tegra , Linux Kernel Mailing List References: <20200516154314.14769-1-digetx@gmail.com> <20200519162444.GD2113674@ulmo> From: Dmitry Osipenko Message-ID: Date: Tue, 19 May 2020 19:33:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200519162444.GD2113674@ulmo> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 19.05.2020 19:24, Thierry Reding пишет: > On Tue, May 19, 2020 at 05:05:27PM +0300, Dmitry Osipenko wrote: >> 19.05.2020 10:28, Ulf Hansson пишет: >>> On Sat, 16 May 2020 at 17:44, Dmitry Osipenko wrote: >>>> >>>> Several people asked me about the MMC warnings in the KMSG log and >>>> I had to tell to ignore them because these warning are irrelevant to >>>> pre-Tegra210 SoCs. >>> >>> Why are the warnings irrelevant? >> >> That's what the DT binding doc says [1]. >> >> [1] >> https://www.kernel.org/doc/Documentation/devicetree/bindings/mmc/nvidia%2Ctegra20-sdhci.txt >> >> Although, looking at the driver's code and TRM docs, it seems that all >> those properties are really irrelevant only to the older Terga20 SoC. So >> the binding doc is a bit misleading. >> >> Nevertheless, the binding explicitly says that the properties are >> optional, which is correct. > > Optional only means that drivers must not fail if these properties > aren't found, it doesn't mean that the driver can't warn that they > are missing. > > Quite possibly the only reason why they were made optional is because > they weren't part of the bindings since the beginning. Anything added > to a binding after the first public release has to be optional by > definition, otherwise DT ABI wouldn't be stable. > > I think these warnings were added on purpose, though I also see that > there are only values for these in device tree for Tegra186 and Tegra194 > but not Tegra210 where these should also be necessary. > > Adding Sowjanya who wrote this code. Perhaps she can clarify why the > warnings were added. If these values /should/ be there on a subset of > Tegra, then I think we should keep them, or add them again, but perhaps > add a better way of identifying when they are necessary and when it is > safe to work without them. > > That said, looking at those checks I wonder if they are perhaps just > wrong. Or at the very least they seem redundant. It looks to me like > they can just be: > > if (tegra_host->pinctrl_state_XYZ == NULL) { > ... > } > > That !IS_ERR(...) doesn't seem to do anything. But in that case, it's > also obvious why we're warning about them on platforms where these > properties don't exist in DT. > > So I think we either need to add those values where appropriate so that > the warning doesn't show, or we need to narrow down where they are > really needed and add a corresponding condition. > > But again, perhaps Sowjanya can help clarify if these really are only > needed on Tegra210 and later or if these also apply to older chips. Either way will be cleaner to convert the DT binding to YAML rather than clutter the driver, IMO.