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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 C3D4EC433DF for ; Fri, 9 Oct 2020 13:34:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6BE4422277 for ; Fri, 9 Oct 2020 13:34:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602250478; bh=EDh68wmG9wRPJUJQMeJoofc1z5bylsJgRa0mJ9uGxK4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=vrhlDZ8+eE9YzLbetdOeUXH2Whd4Ve2qKnN7/6Pyyi4qOsFP0TkC3Erc6yuXYdUij XzuZC9E6WAqp0px6YfXClAdv3lNZGE7se6GBbsW67VPXk1nChgjQBRGYXB63/U96nK ck2p5lrWS9Lknd3wRR6StSjV0hGM2pBXmrSR9C40= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733305AbgJINeh (ORCPT ); Fri, 9 Oct 2020 09:34:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:36868 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731782AbgJINee (ORCPT ); Fri, 9 Oct 2020 09:34:34 -0400 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9E290222BA for ; Fri, 9 Oct 2020 13:34:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602250473; bh=EDh68wmG9wRPJUJQMeJoofc1z5bylsJgRa0mJ9uGxK4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RvNEOP5g70n+/k47SO7hbUz9QEZGILLw6eLyCuc21geEA4BGi9TA2QiRh8z8tld3P pbLNwK6GHBImBiCzaozYd/cIVHwzSMdJfC7XpfHRh16KgilfNs9+c/XMgEwPJdC/d6 yPlmjOqKCsmZ4WcTpfKQ1rW0IsXHuQI2RweKZm3Q= Received: by mail-ot1-f50.google.com with SMTP id t15so9046001otk.0 for ; Fri, 09 Oct 2020 06:34:33 -0700 (PDT) X-Gm-Message-State: AOAM5339sOtFeWkenIliYixWDeekSuyu53F/x2huuwhTxW9t8X69qMfU TLlfoBJEXSHPi8Wj0ThzZug6nli2BE/GfXRmzw== X-Google-Smtp-Source: ABdhPJwItZMPo2QihYVy7LGx5D3n6NCmjhdMMjpDE/LG2Lzwd0W/QO7/Tgg6Eu8zTmN9kKjEkJoH7aqn5Wb11xd41Rk= X-Received: by 2002:a9d:7993:: with SMTP id h19mr5189994otm.129.1602250472680; Fri, 09 Oct 2020 06:34:32 -0700 (PDT) MIME-Version: 1.0 References: <20201008102825.3812-1-ricardo.canuelo@collabora.com> <20201008102825.3812-4-ricardo.canuelo@collabora.com> <20201008183818.GB2395464@bogus> <20201009054819.di4dlfljadsfs6cw@rcn-XPS-13-9360> In-Reply-To: <20201009054819.di4dlfljadsfs6cw@rcn-XPS-13-9360> From: Rob Herring Date: Fri, 9 Oct 2020 08:34:21 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] mfd: google,cros-ec: add missing properties To: =?UTF-8?Q?Ricardo_Ca=C3=B1uelo?= Cc: Collabora Kernel ML , Enric Balletbo i Serra , Benson Leung , Guenter Roeck , Simon Glass , Doug Anderson , devicetree@vger.kernel.org, Dmitry Torokhov , Cheng-Yi Chiang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Oct 9, 2020 at 12:48 AM Ricardo Ca=C3=B1uelo wrote: > > Hi Rob, > > Thanks for taking the time to review this. Find my answers below: > > On jue 08-10-2020 13:38:18, Rob Herring wrote: > > > + codecs: > > > > Doesn't moving this require a driver change? > > I studied the driver as thoroughly as I could (what > sound/soc/codecs/cros_ec_codec.c:cros_ec_codec_platform_probe does) and > I think the driver should still be able to handle this. Unfortunately, I > can't test it. Can any of the driver maintainers share their > input about this? I'm adding Cheng-Yi Chiang to cc as well. The question is not what cros_ec_codec_platform_probe does, but how the platform device is created by the mfd driver. I think that's just a call to of_platform_populate which will only create immediate child devices unless there's a simple-bus or simple-mfd compatible. So I guess you could also add 'simple-mfd' rather than a driver change. However, there could be some expectation in the codec driver that the immediate parent is the EC node. > > If you only need 1 codec, then just drop the unit-address. > > Thank you. Yes, as far as I can tell there's only this codec (so far). I would probably go this route. You could add this level if there's ever more than one codec. However, I'm still not clear what the address represents for the codec. Is it needed? The address space/format is defined by the parent node. So is this defined by the EC? If so, other components don't have an address? Rob