Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp6920916ybi; Wed, 5 Jun 2019 08:22:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqxfQ0MkZr2mx3rJHjKpdQJ5Fi1Uvx6Ckq/jk6z1oAxyuCMjYQDgSSe84ae05Gt8wUTNZkHe X-Received: by 2002:a63:5c11:: with SMTP id q17mr5174606pgb.385.1559748156230; Wed, 05 Jun 2019 08:22:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559748156; cv=none; d=google.com; s=arc-20160816; b=0IGDq3eGKBecIk36nKtrazl74oIruvkg7XoItLqTNlNLKP6zkjyqYXPRrYalYraK8K Ht7dOyzK9ZgFi0JED9SlEpqgmlRA5ifut/NvCPGyVnp3LiQNym6/Gyr2eUhkfSw06Uu0 eSxXCIDTKgMp/Zx0/TNHA1D0Vyc8HSp2qsw6wMY+Sj928VpSJLz7+kd1Tgwao0C4+x6K VeqDPciDvWWXcFsse20mzK2fQ64JBMKEBrN8mmqVPKo559Qi49+Vypy2UE5IrB+A3opX +9KztmYm5pkE4IXVg7gq/csYm3BeHcmE/KIzc5OgCoWCigXoo40Hsul8G6jcC7fE4qMk au9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ytP8/UBgkO5jaVHKQWoDG4zyk6kKGN8zAlZwPlNeK+0=; b=i0v0qObvmR481Xe6I7MPzz08/s21RcUu6b0FK/L/rsnQMtRWf1bATNatt++BsSrhsm cVM+jgdHv17SB/nHBmAOQBz/cSMrkinj6jPu3znm4+YHyZn7TwLSojfUXvDfJLOBh94v W77KiRt2mmXPKA4Qgyo8/zvIzMS6r474ajqDnBj3zdvSxkCxUxUpG73xnmJMM2efwuAq YF+kVaBBrhgTt+YMSHRoc21U2yTV6XiR/rODXGwbyQKF/1NPqK0BYdXGg6X7HwMIwmrn VA4PaykPKuNApUjE3pqjlK3fgJXFjFoynh8AAfH4BTZPUHKWjxrbuFL4dyzKx2dZ53+F AQrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eydmK6tc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id v65si32314614pfb.77.2019.06.05.08.22.00; Wed, 05 Jun 2019 08:22:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eydmK6tc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1728304AbfFEPUt (ORCPT + 99 others); Wed, 5 Jun 2019 11:20:49 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:46443 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728089AbfFEPUs (ORCPT ); Wed, 5 Jun 2019 11:20:48 -0400 Received: by mail-pf1-f195.google.com with SMTP id y11so14997553pfm.13; Wed, 05 Jun 2019 08:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ytP8/UBgkO5jaVHKQWoDG4zyk6kKGN8zAlZwPlNeK+0=; b=eydmK6tc4MgDPycaqdm/O5Q+CSa79lSoqm8NG+ARuvnKj6Z8eUG7QCmZ1QUwQu22zB 4zjJyUXjp42Rvpc8fI/wI70hTuR12hqBAb3iFow2sG4zFUlhqmRfLNn7Tng/ZA8WVtXm dTQlYO+ysBAOFfsuS09hjzAhyQz0HjSKRy78XyYNJcwdquIKYgHSisxvxv97JrPYQZN7 TpD8WggHqwa+ga5dtlWnDiMbSDzw4C+1lXA5wiVdDk/yvB2mS8UJuv5inoTQDGNH6ZY0 u7Zk5kJN2rjKISogeVuP5jCyY6URY525DadPzqA4OCFYTHNmZWsYFsAMlZFrzX7EjThY fHWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ytP8/UBgkO5jaVHKQWoDG4zyk6kKGN8zAlZwPlNeK+0=; b=Fb7hwfZyEYMESOiC823ygTCCuWv2Vg2ELufBjxFWFu5QUhIZUZYRTDOyrvxrKj5MX/ prr1VmV75BckNN/QF9009P1rdhLZMOqxXpvAsKXb5vYEk4p9beiV449YUflCVs6Y+y6P NDw7ynVDE2y+bk+MVMoggzdggEAv2kfijCX0ipDnp5XQiEpe2p7SzDYLEMc3M+NLqKbZ 6cUr9Wa8vr3Zv7Ldv7b9jY0kXK24nU58xfOudp0dIZNZS1wMLvUxlfzIPaPVL8rw1bDB 7YHOqxJqrN4QMcBNx4SiROJuqlwjKX0omCN+9m8DmAuWsiuzT6NxaVZ4m2ffUIxaV9Hk pHDw== X-Gm-Message-State: APjAAAWQZBBdtPBNazoj5wtGrEsriH55AYjHnGufhzzEAv/aLn54vhis WheVD+ZmaEreYUU7kVpRI3Gz5/xLvVVbrJWatqI= X-Received: by 2002:a17:90a:a596:: with SMTP id b22mr32581985pjq.20.1559748047820; Wed, 05 Jun 2019 08:20:47 -0700 (PDT) MIME-Version: 1.0 References: <20190531043347.4196-1-eduval@amazon.com> <20190531043347.4196-3-eduval@amazon.com> <20190604171611.GS9224@smile.fi.intel.com> <20190605032709.GA1534@u40b0340c692b58f6553c.ant.amazon.com> <20190605143158.GB1534@u40b0340c692b58f6553c.ant.amazon.com> In-Reply-To: <20190605143158.GB1534@u40b0340c692b58f6553c.ant.amazon.com> From: Andy Shevchenko Date: Wed, 5 Jun 2019 18:20:37 +0300 Message-ID: Subject: Re: [PATCH 2/3] i2c: slave-mqueue: add a slave backend to receive and queue messages To: Eduardo Valentin Cc: Andy Shevchenko , Wolfram Sang , Haiyue Wang , Jarkko Nikula , Brendan Higgins , Rob Herring , Mark Rutland , linux-i2c , devicetree , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 5, 2019 at 5:32 PM Eduardo Valentin wrote: > On Wed, Jun 05, 2019 at 11:25:39AM +0300, Andy Shevchenko wrote: > > On Wed, Jun 5, 2019 at 6:30 AM Eduardo Valentin wrote: > Well, yes, but the point is you would be switching from a simple AND (&) operation > to a division... > > I am keeping the power of 2 dep so that we can keep this with a simple &. Works for me. > > > > > + .of_match_table = of_match_ptr(i2c_slave_mqueue_of_match), > > > > > > > > Wouldn't compiler warn you due to unused data? > > > > Perhaps drop of_match_ptr() for good... > > > > > > Not sure what you meant here. I dont see any compiler warning. > > > Also, of_match_ptr seams to be well spread in the kernel. > > > > If this will be compiled with CONFIG_OF=n... > > I see.. I obviously did not test with that config.. > > > Though I didn't check all dependencies to see if it even possible. In > > any case of_match_ptr() is redundant in both cases here. > > Either you need to protect i2c_slave_mqueue_of_match with #ifdef > > CONFIG_OF, or drop the macro use. > > I will wrap it into CONFIG_OF.. Would be this expected to work in the case of CONFIG_OF=n? If no, why to introduce ugly #ifdef:s and additional macros? Wouldn't be better to have depends on OF || COMPILE_TEST ? -- With Best Regards, Andy Shevchenko