Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5729779ybp; Tue, 15 Oct 2019 04:17:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxtXrP1/yCXFq//5NNhb6KZ3efV3rYHplau3iFYpyEtyxv1ArSHbQQvPxGyw6My/s6NOTUB X-Received: by 2002:a05:6402:2025:: with SMTP id ay5mr33112919edb.93.1571138229571; Tue, 15 Oct 2019 04:17:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571138229; cv=none; d=google.com; s=arc-20160816; b=vvXv2iunJqjaOBw3f1sfO4lRWZt43FUd+fJ/GIAat2+wwNjNDsDjtBAwva37bhr+ku EKUW9Ueos6zNU35OS4KywpZqjUDudBhQkk2FgeFWRK9DpJjOMpVkcIsLHlOFjXoQFDqK zJovqwh+6xBzhS/Sgqb/88prAa10/jwdtw7qsyIruxf2mRpsL8t/Xoml8SvMgKKydTFg C17LKgq0l4L462lBTKPBhTPa+WtGiJwQ+2VIqdItgLvLxjVyEQ9m0s3ia7nHguUS6Sgi liYCTE/0tFlNs1aqOV5syR58oRf9CAzsQ7WUKaYWSNJxB8OHMmHDEwGtvtJYWtD3hNAz D06g== 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=Y/FDmIN7D8CAH00XLKSbXEilWCinqJP7n+EcoU7otuk=; b=HP7QRTFe5LuRq+AdMuTY6bhnG70AEK5YLZehiFdun6/pXXIZ/zlIXTwuPmZviomU6Y UudDo59UKd5K0m62ry+xByZciCkkxlfShJcrCGsvHzX4JvqZtZygxNtuUUQYFyu3ROwY AuTslwCXPUdMc+CXVKoihFNcBaf5t2me1wGS3Eq5NI7ty8NO00+iQ9XUk3GnmIYx/If9 1NU+9ZzTHNDm9fakmEb3A6LcnlpuS7cPkvGZEy8F+h98Nfu4yoJ96NqrlYaNAmm6pbSG KvvXlsg2tQUWOVRa+MJF0X6hLpN5rYGC6C0GAT16Tj5o9r0S6EXfdHs4RRmJjiyv9QNG f1yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HoCuT2+l; 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 w5si15239077edf.283.2019.10.15.04.16.46; Tue, 15 Oct 2019 04:17:09 -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=HoCuT2+l; 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 S1729397AbfJOJCQ (ORCPT + 99 others); Tue, 15 Oct 2019 05:02:16 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:37882 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727838AbfJOJCO (ORCPT ); Tue, 15 Oct 2019 05:02:14 -0400 Received: by mail-pl1-f193.google.com with SMTP id u20so9280321plq.4; Tue, 15 Oct 2019 02:02:12 -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=Y/FDmIN7D8CAH00XLKSbXEilWCinqJP7n+EcoU7otuk=; b=HoCuT2+lllpMGI7rxiT0hR8SrLG0PxTVSag1/oMBtvUyOxazz+MUgiI1f8MRbx46ej GOavSu+uhk8b6OY/Z4K8ksOea6AVOo8YvnixA0pmAn8Mj43ZoY4HXbCK5fX9F657AIpm Iq4zItG0MZtz4yqXJx1lRI03gq7wX7c2zG9nq9luguy0oKWRsBC89Uf2XwMAa1e0Zzgc h5kIKDSpesNdliArJBfcRHOcLLZERWLYirCf6ScpT36OkkoWyWhkh6eDDAYLxQ/fnYR6 4r6LXRWVC+f7kDgeGRRcu7pFWdZ6JI5CZAipJ7DMvBp8pV14/qNA9T0F8LAIPtFD5imQ CQYQ== 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=Y/FDmIN7D8CAH00XLKSbXEilWCinqJP7n+EcoU7otuk=; b=gg7oh5ZjQGjulF3Z2xTfieQDXc84zKmcMo35UuBk5nfnSAmC4JYT5rxPQDgWxciDvd hERTfEdJ9DfLImmNEGGd53klHCz66hxh6G32lV9FFFnUwsgsKIuRgE1wfEkHKaI9vCdf YcGwxfhF5lPgkEolBj40eG/ZVaXXE/54BYwkpdY5vCwdGEpQJUZnzHBQk5W0OY21RrmO iHFlBKPZke4xg3ibefT9gG7Mjv1XYMatWSktp7r8P+7SaCjFnbZpHWiIL+CkeO4Ay1L+ UeDPFGMMoqRDL4GzGNtF1gmz7UZQwta7cdt4a7klPIzsI5WYA03t/oifUbrTaIA62nH6 j4lw== X-Gm-Message-State: APjAAAUd2c8aQoDPpv3ILU9u3RRcreu/QZM3bMI0QUYYhcL/8KXe38gO SMWUrml5FmR8vibqqREqXyWqlEbAVVKZZVg1vwI= X-Received: by 2002:a17:902:9881:: with SMTP id s1mr35148119plp.18.1571130132022; Tue, 15 Oct 2019 02:02:12 -0700 (PDT) MIME-Version: 1.0 References: <20191004214334.149976-1-swboyd@chromium.org> <20191004214334.149976-2-swboyd@chromium.org> <5da4e084.1c69fb81.567f9.4b9c@mx.google.com> In-Reply-To: <5da4e084.1c69fb81.567f9.4b9c@mx.google.com> From: Andy Shevchenko Date: Tue, 15 Oct 2019 12:02:01 +0300 Message-ID: Subject: Re: [PATCH 01/10] leds: pca953x: Use of_device_get_match_data() To: Stephen Boyd Cc: Wolfram Sang , Linux Kernel Mailing List , Arnd Bergmann , Geert Uytterhoeven , Riku Voipio , Rob Herring , Frank Rowand , Jacek Anaszewski , Pavel Machek , Dan Murphy , Linux LED Subsystem 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 Mon, Oct 14, 2019 at 11:54 PM Stephen Boyd wrote: > Quoting Andy Shevchenko (2019-10-14 10:50:06) > > On Sat, Oct 5, 2019 at 12:47 AM Stephen Boyd wrote: > > > > > > This driver can use the of_device_get_match_data() API to simplify the > > > code. Replace calls to of_match_device() with this newer API under the > > > assumption that where it is called will be when we know the device is > > > backed by a DT node. This nicely avoids referencing the match table when > > > it is undefined with configurations where CONFIG_OF=n. > > > > > + devid = (int)(uintptr_t)of_device_get_match_data(dev); > > > > > + devid = (int)(uintptr_t)of_device_get_match_data(&client->dev); > > > > This still leaves it OF-centric. > > Better to use device_get_match_data(). > > > > Also, I'm thinking that following may help to clean a lot of the i2c > > client drivers > > > > static inline // perhaps no > > const void *i2c_device_get_match_data(struct i2c_client *client, const > > struct i2c_device_id *id) > > { > > if (id) > > return (const void *)id->driver_data; > > return device_get_match_data(&client->dev); > > } > > > > Looks alright to me. Maybe device_get_match_data() can look at the bus > and call some bus op if the firmware match isn't present? Then we can > replace a bunch of these calls with device_get_match_data() and it will > "do the right thing" regardless of what bus or firmware the device is > running on. It will be something ugly like buses { #ifdef I2C &i2c_bus_type, #endif ... } in the code. I won't do this. See generic_match_buses[] for example. -- With Best Regards, Andy Shevchenko