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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 47C51C433DF for ; Mon, 19 Oct 2020 16:54:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAB3522269 for ; Mon, 19 Oct 2020 16:54:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="OuBRRIaN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730668AbgJSQyl (ORCPT ); Mon, 19 Oct 2020 12:54:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730322AbgJSQyl (ORCPT ); Mon, 19 Oct 2020 12:54:41 -0400 Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B002FC0613CE for ; Mon, 19 Oct 2020 09:54:39 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id l2so364506lfk.0 for ; Mon, 19 Oct 2020 09:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WWe1nyT09mfP995hqz7RZGWn3qxoOPoS4oyItVvSHIA=; b=OuBRRIaNVW4sTCoqWv1mPmTw7hVN3ZKuzZpOcOF5DDEf/55sVq99t/SFPfjSK/56KA oCp/8BNdCL7+xQJJXdjtBzwqWKHzB6VfZxcXStrY/0/16UcUNhMpE/0lPrPazKKI11Hm q9wLB13d9P9GsiPO66kJn/lpgvunLWukaHsNI= 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=WWe1nyT09mfP995hqz7RZGWn3qxoOPoS4oyItVvSHIA=; b=CcBLftbAAZ/E51nygbOJl8qeEpYSKhldVv27nMnDGfDOuxuPQXyjo4mDbpINKlWyWt +P4BbKvYBxIXCK5UMdLEZJ8lwHIAJO4CJYJp4u/v6PfvsFzRwc0khUUyorgDUT0oxH5D isKPoN6YyHHhRN8Cq3C0MCCqC591PlH57L0iG6YtwnVxkfci6FoT10h6R9Q6uXiZHKIr vynDOqOtSbEKwrstparlxvghcYmt3D2pHsU2TvEsd32mVFvXfDt2L5zAc7p7NDFuHqov hT5BTVuPYhvbz7DWoJ1EagCHmAiHb4wbode9xLUYDH83KPFk097imzpR3uSDqDpGiE5K W+VA== X-Gm-Message-State: AOAM530r5tIWztpGcCsNKT/lsBse+b0KHxmbsw81akjBarlVU6QApjdV DYF/1ZTU4F7euiZmH7YtAbNz5XoXHlt54A== X-Google-Smtp-Source: ABdhPJxVjjLnHKm1OtsZo+SetO4+BPlLjyOT4/K5o7uPpBqyo/KzcmkjpfveH8kODiMS6FwbqEI+Qg== X-Received: by 2002:a19:7009:: with SMTP id h9mr206539lfc.201.1603126477889; Mon, 19 Oct 2020 09:54:37 -0700 (PDT) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id v20sm67966ljg.111.2020.10.19.09.54.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Oct 2020 09:54:37 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id h20so798658lji.9 for ; Mon, 19 Oct 2020 09:54:36 -0700 (PDT) X-Received: by 2002:a2e:9955:: with SMTP id r21mr380357ljj.124.1603126476431; Mon, 19 Oct 2020 09:54:36 -0700 (PDT) MIME-Version: 1.0 References: <20201016222523.364218-1-evgreen@chromium.org> <20201016152454.v3.2.Idef164c23d326f5e5edecfc5d3eb2a68fcf18be1@changeid> In-Reply-To: From: Evan Green Date: Mon, 19 Oct 2020 09:53:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] i2c: i2c-mux-gpio: Enable this driver in ACPI land To: Andy Shevchenko Cc: Peter Rosin , Wolfram Sang , Randy Dunlap , Peter Korsgaard , linux-i2c , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 18, 2020 at 11:58 AM Andy Shevchenko wrote: > > On Sat, Oct 17, 2020 at 8:30 AM Evan Green wrote: > > > > Enable i2c-mux-gpio devices to be defined via ACPI. The idle-state > > property translates directly to a fwnode_property_*() call. The child > > reg property translates naturally into _ADR in ACPI. > > > > The i2c-parent binding is a relic from the days when the bindings > > dictated that all direct children of an I2C controller had to be I2C > > devices. These days that's no longer required. The i2c-mux can sit as a > > direct child of its parent controller, which is where it makes the most > > sense from a hardware description perspective. For the ACPI > > implementation we'll assume that's always how the i2c-mux-gpio is > > instantiated. > > Can you tell me if the following is relevant to what you are looking for? > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-mux.c#L393 I don't think so, but let me know if I'm reading between the lines incorrectly. The code you pointed to links the newly-minted fake i2c controller back together with its ACPI node. This is important, since I think that's how child I2C devices underneath the fake busses get populated in ACPI land. But the paragraph above is discussing how to identify the parent adapter (ie the real hardware) for an i2c-mux-gpio device. In DT-land, the i2c-mux-gpio floats at the top of the tree directly under /, and then uses a phandle to point to where transactions should be forwarded. I'm told the reason for this is historical limitations with the DT bindings. Rather than trying to translate the phandle over 1:1 into ACPI-land, I'm asserting that the mux device should live underneath the adapter it wants to forward traffic to. -Evan > > -- > With Best Regards, > Andy Shevchenko