Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp2208015ybm; Sun, 31 May 2020 12:12:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwF4zP2GUQB/fCwJELM+7uthAqkXEUZdbGkJak65m5W2hERFfS5qc7i8fPrVbQRvi3ERazc X-Received: by 2002:a17:906:8595:: with SMTP id v21mr5719287ejx.30.1590952339991; Sun, 31 May 2020 12:12:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590952339; cv=none; d=google.com; s=arc-20160816; b=Sv2CkqYF2sEbPujULeWqrDVYvpCy5qbc6JcQAkb5dEODEdFjruvlIpqF0/QOiTzHyu b6C4DDD13P0iaOywt+B3DHlN1HAaf5Wf/+1anNOlIArWKy+96FOa5psqq6/e9vojPF5t Cb1UzJEblNEziaMRsBk3WMFxY07lU6vNM9MSh6fsBpDmaNYq7O5dvLCqeBuCzMlxyQBO NKEmsBYnUKe8COklbzWMEgjHhPhaV4TrAJP1nzx9nUIALdh1UxKsrBsrpYl5KCid8T7K 9To74rxnnNJs2x81CeHynbAFGlPq29UOAfH/9ip6S380Z+OvTjU8028ktodZsz+hqOMq 7eqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=AgC2+RUz/GF0eTwOkEH2JLRx7A7gQezajgbEl5uEqlc=; b=oMJTWaqrTT5J8L21e5hZIie49We/CFND1d5NSmdi91Or79kbVWdWs7o4Qsz/06vpO2 K70G83Q8T0JU4qOaOL8dTGmGxWzkrlEzKKCQpHPSg7RYfKne7kS42x0WMqLnoF9ISNny Qjkk0Uu54Z2nSwtCqW83XaY0XrIkNkjEDaKMBWPcLPpf3w04kJNRKguXgWSOEiX66MTq /JQUXDmL2F8jle28jBMNEj8gvuH088irTKOpkzfT3MQ+S/7CfsATf8HWNITjib0QGmFK QKF2AHPQdu25h4e32fVgUFj9ogHOFmdzj0Xkt0f/Tt3O9qn0lyYwo6wQUPzSA4+dAYYy gWPA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v7si9530072edr.33.2020.05.31.12.11.56; Sun, 31 May 2020 12:12:19 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728355AbgEaTHI (ORCPT + 99 others); Sun, 31 May 2020 15:07:08 -0400 Received: from mail.baikalelectronics.com ([87.245.175.226]:45952 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbgEaTHI (ORCPT ); Sun, 31 May 2020 15:07:08 -0400 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id E97B18030866; Sun, 31 May 2020 19:07:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at baikalelectronics.ru Received: from mail.baikalelectronics.ru ([127.0.0.1]) by localhost (mail.baikalelectronics.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9PNAVpwnQW7; Sun, 31 May 2020 22:07:05 +0300 (MSK) Date: Sun, 31 May 2020 22:07:04 +0300 From: Serge Semin To: Wolfram Sang CC: Serge Semin , , Alexey Malahov , Thomas Bogendoerfer , Jarkko Nikula , Andy Shevchenko , Frank Rowand , Rob Herring , , , Subject: Re: [PATCH v2] check: Add 10bit/slave i2c reg flags support Message-ID: <20200531190704.2kluwj3nipvdfccs@mobilestation> References: <20200527122525.6929-1-Sergey.Semin@baikalelectronics.ru> <20200527141517.22677-1-Sergey.Semin@baikalelectronics.ru> <20200530093152.GA1038@ninjato> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200530093152.GA1038@ninjato> X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 30, 2020 at 11:31:52AM +0200, Wolfram Sang wrote: > > > + addr = reg & 0x3FFFFFFFU; > > + snprintf(unit_addr, sizeof(unit_addr), "%x", addr); > > Hmm, this hardcoded value will not work if we ever need to add another > bit. I hope this will never happen, though. > > > + if ((reg & (1U << 31)) && addr > 0x3ff) > > Same here with bit 31. I'd be glad to use a macro or some helper here, but alas there is no ready-to-use i2c-related one in the dtc code. See, there are hard-coded literals in the PCI nodes checkers (check_pci_device_reg(), check_pci_device_bus_num()) and the hard-coded literals've been in the i2c-nodes checkers even before this patch. > I haven't checked DTC but can't we import the > header with the defines into the project? Or is this then a circular > dependency? > I guess importing header would be much better than the hard-coded values currently used. What do the code maintainers say about that? Any idea how it is supposed to be implemented? -Sergey