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 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 50427C433F5 for ; Wed, 2 Feb 2022 18:02:55 +0000 (UTC) Received: from localhost ([::1]:50040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nFJy1-0007YD-2h for qemu-devel@archiver.kernel.org; Wed, 02 Feb 2022 13:02:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38788) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFIak-0006Cz-S6 for qemu-devel@nongnu.org; Wed, 02 Feb 2022 11:34:47 -0500 Received: from [2607:f8b0:4864:20::929] (port=42914 helo=mail-ua1-x929.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nFIai-00005P-Ol for qemu-devel@nongnu.org; Wed, 02 Feb 2022 11:34:46 -0500 Received: by mail-ua1-x929.google.com with SMTP id e17so137894uad.9 for ; Wed, 02 Feb 2022 08:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ThK1ncxv4XZ8WNd5qDB7t8/lRyy36pZGZHRv5DVJ4no=; b=IFa9k46QhVtl3cg1JaaZyvkKbOHG2tONdbvYeykOSBmPlIiYHphPnkG10w4/X/DZNc UBce31cf+teIjTVvwPVS/hN/5O8ZRFgLKJg5B1UG/N9axHz0jr3so6JDlieeV5lT96xf Jl+cPRgjLzgZqrvbLRBULgTMxCnk2scfCByEhbo/c/NedStavgof+uA1dwLVA/3S2xlA Zhj70rKVTEEltIAkUnYQjvQV2KSlAI4gYmcfzXyWJCkCY9A+olBkDxU0raLuwF3lISCY n159Csv49qUJLKgXaZRqOXIc9VqTOh4Boyu0mqPhqfSbcLJtQhH21XVa/j0Xvz/IsZRo bVNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ThK1ncxv4XZ8WNd5qDB7t8/lRyy36pZGZHRv5DVJ4no=; b=CYiertPsbfxudJxVeT3OVm1gcAYRW5qw01Eznakmogi5NICTbc5mVXf8affBINBVnq peagzdtUL/4ueGM3TUVwDYcy77z/JYRdHdru+HKOQpY0Aawp0rCYPsJUg95sJ06FsnMB lXRWMRaEPrCMUFgE8RhaM33V+HJLC+2dO1LXbFDBbStWlJnTZ/TeWISviDNL9k1qa0o9 UCPRi0Ffz5rAh2ueeqt8AvBcBEYq0G1My8XmveKeNWCttaAtkFqV9pjo5AYot9gQkR5e AIyzcUD9RsOc6B4OIfJTbzSyp2OYz2xZdk73xk9Yqo9qyS2SJyZE4TU+eVBB+YeyyQnt yzKQ== X-Gm-Message-State: AOAM530OLLyx/eweHDsDaCmRguFwqf1/nR1GAiWsld6XqbsY3zHm5e8e E6dQdYA5j2vKXlaSbkOCsZuqfqENo1sgaHkkJ5U7Lg== X-Google-Smtp-Source: ABdhPJzw4crndAgstOhsDahlHwXIW1bOaJXPRWkmM/F+/A9F8iiZLdLQC+KL3BzoVLLIPRlwPJ6WkA+SahatPjVJ3ns= X-Received: by 2002:a9f:2626:: with SMTP id 35mr12216066uag.40.1643819683557; Wed, 02 Feb 2022 08:34:43 -0800 (PST) MIME-Version: 1.0 References: <20220201163005.989457-1-venture@google.com> <59040e43-2375-1f73-15bb-ce1a47165145@amsat.org> In-Reply-To: From: Patrick Venture Date: Wed, 2 Feb 2022 08:34:32 -0800 Message-ID: Subject: Re: [PATCH] hw/i2c: flatten pca954x mux device To: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Cc: Corey Minyard , QEMU Developers , Hao Wu Content-Type: multipart/alternative; boundary="00000000000050c60605d70b988c" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::929 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::929; envelope-from=venture@google.com; helo=mail-ua1-x929.google.com X-Spam_score_int: -167 X-Spam_score: -16.8 X-Spam_bar: ---------------- X-Spam_report: (-16.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000050c60605d70b988c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 1, 2022 at 12:54 PM Patrick Venture wrote: > > > On Tue, Feb 1, 2022 at 11:02 AM Philippe Mathieu-Daud=C3=A9 > wrote: > >> On 1/2/22 17:30, Patrick Venture wrote: >> > Previously this device created N subdevices which each owned an i2c bu= s. >> > Now this device simply owns the N i2c busses directly. >> > >> > Tested: Verified devices behind mux are still accessible via qmp and i= 2c >> > from within an arm32 SoC. >> > >> > Reviewed-by: Hao Wu >> > Signed-off-by: Patrick Venture >> > --- >> > hw/i2c/i2c_mux_pca954x.c | 75 ++++++--------------------------------= -- >> > 1 file changed, 11 insertions(+), 64 deletions(-) >> >> > static void pca954x_init(Object *obj) >> > { >> > Pca954xState *s =3D PCA954X(obj); >> > Pca954xClass *c =3D PCA954X_GET_CLASS(obj); >> > int i; >> > >> > - /* Only initialize the children we expect. */ >> > + /* SMBus modules. Cannot fail. */ >> > for (i =3D 0; i < c->nchans; i++) { >> > - object_initialize_child(obj, "channel[*]", &s->channel[i], >> > - TYPE_PCA954X_CHANNEL); >> > + /* start all channels as disabled. */ >> > + s->enabled[i] =3D false; >> > + s->bus[i] =3D i2c_init_bus(DEVICE(s), "channel[*]"); >> >> This is not a QOM property, so you need to initialize manually: >> > > that was my suspicion but this is the output I'm seeing: > > {'execute': 'qom-list', 'arguments': { 'path': > '/machine/soc/smbus[0]/i2c-bus/child[0]' }} > > {"return": [ > {"name": "type", "type": "string"}, > {"name": "parent_bus", "type": "link"}, > {"name": "realized", "type": "bool"}, > {"name": "hotplugged", "type": "bool"}, > {"name": "hotpluggable", "type": "bool"}, > {"name": "address", "type": "uint8"}, > {"name": "channel[3]", "type": "child"}, > {"name": "channel[0]", "type": "child"}, > {"name": "channel[1]", "type": "child"}, > {"name": "channel[2]", "type": "child"} > ]} > > It seems to be naming them via the order they're created. > > Is this not behaving how you expect? > Philippe, I0202 08:29:45.380384 6641 stream.go:31] qemu: child buses at "pca9546": "channel[*]", "channel[*]", "channel[*]", "channel[*]" Ok, so that's interesting. In one system (using qom-list) it's correct, but then when using it to do path assignment (qdev-monitor), it fails... I'm not as fond of the name i2c-bus.%d, since they're referred to as channels in the datasheet. If I do the manual name creation, can I keep the name channel or should I pivot over? Thanks > >> >> -- >8 -- >> diff --git a/hw/i2c/i2c_mux_pca954x.c b/hw/i2c/i2c_mux_pca954x.c >> index f9ce633b3a..a9517b612a 100644 >> --- a/hw/i2c/i2c_mux_pca954x.c >> +++ b/hw/i2c/i2c_mux_pca954x.c >> @@ -189,9 +189,11 @@ static void pca954x_init(Object *obj) >> >> /* SMBus modules. Cannot fail. */ >> for (i =3D 0; i < c->nchans; i++) { >> + g_autofree gchar *bus_name =3D g_strdup_printf("i2c.%d", i); >> + >> /* start all channels as disabled. */ >> s->enabled[i] =3D false; >> - s->bus[i] =3D i2c_init_bus(DEVICE(s), "channel[*]"); >> + s->bus[i] =3D i2c_init_bus(DEVICE(s), bus_name); >> } >> } >> >> --- >> >> (look at HMP 'info qtree' output). >> >> > } >> > } >> >> With the change: >> Reviewed-by: Philippe Mathieu-Daud=C3=A9 >> Tested-by: Philippe Mathieu-Daud=C3=A9 >> > --00000000000050c60605d70b988c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 1, 2022 at 12:54 PM Patri= ck Venture <venture@google.com= > wrote:


On Tue, Feb 1, 2022 at 11:02 AM Philippe = Mathieu-Daud=C3=A9 <f4bug@amsat.org> wrote:
On 1/2/22 17:30, Patrick Venture wrote:
> Previously this device created N subdevices which each owned an i2c bu= s.
> Now this device simply owns the N i2c busses directly.
>
> Tested: Verified devices behind mux are still accessible via qmp and i= 2c
> from within an arm32 SoC.
>
> Reviewed-by: Hao Wu <wuhaotsh@google.com>
> Signed-off-by: Patrick Venture <venture@google.com>
> ---
>=C2=A0 =C2=A0hw/i2c/i2c_mux_pca954x.c | 75 ++++++----------------------= ------------
>=C2=A0 =C2=A01 file changed, 11 insertions(+), 64 deletions(-)

>=C2=A0 =C2=A0static void pca954x_init(Object *obj)
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pca954xState *s =3D PCA954X(obj);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pca954xClass *c =3D PCA954X_GET_CLASS(obj);<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0int i;
>=C2=A0 =C2=A0
> -=C2=A0 =C2=A0 /* Only initialize the children we expect. */
> +=C2=A0 =C2=A0 /* SMBus modules. Cannot fail. */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; i < c->nchans; i++) { > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 object_initialize_child(obj, "channe= l[*]", &s->channel[i],
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TYPE_PCA954X_CHANNEL);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* start all channels as disabled. */
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 s->enabled[i] =3D false;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 s->bus[i] =3D i2c_init_bus(DEVICE(s), = "channel[*]");

This is not a QOM property, so you need to initialize manually:

that was my suspicion but this is the output I'= ;m seeing:

{'execute': 'qom-list', 'a= rguments': { 'path': '/machine/soc/smbus[0]/i2c-bus/child[0= ]' }}

{"return": [
{"name": "type&qu= ot;, "type": "string"},
{"name": "par= ent_bus", "type": "link<bus>"},
{"na= me": "realized", "type": "bool"},
{&q= uot;name": "hotplugged", "type": "bool"}= ,
{"name": "hotpluggable", "type": "b= ool"},
{"name": "address", "type": &q= uot;uint8"},
{"name": "channel[3]", "type&= quot;: "child<i2c-bus>"},
{"name": "chann= el[0]", "type": "child<i2c-bus>"},
{"= ;name": "channel[1]", "type": "child<i2c-b= us>"},
{"name": "channel[2]", "type&quo= t;: "child<i2c-bus>"}
]}

It= seems to be naming them via the order they're created.

<= /div>
Is this not behaving how you expect?

Philippe,

I0202 08:29:45.380384 =C2= =A06641 stream.go:31] qemu: child buses at "pca9546": "chann= el[*]", "channel[*]", "channel[*]", "channel[= *]"

Ok, so that's interesting.=C2=A0 In one system (using q= om-list) it's correct, but then when using it to do path assignment (qd= ev-monitor), it fails...

I'm not as fond of th= e name i2c-bus.%d, since they're referred to as channels in the datashe= et.=C2=A0 If I do the manual name creation, can I keep the name channel or = should I pivot over?

Thanks

=C2=A0
f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daud=C3=A9 <f4bug@amsat.org>
--00000000000050c60605d70b988c--