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 9F87BC433F5 for ; Wed, 2 Feb 2022 17:34:22 +0000 (UTC) Received: from localhost ([::1]:51192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nFJWP-0004Yt-EE for qemu-devel@archiver.kernel.org; Wed, 02 Feb 2022 12:34:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFIhI-00021R-TQ for qemu-devel@nongnu.org; Wed, 02 Feb 2022 11:41:32 -0500 Received: from [2607:f8b0:4864:20::934] (port=33357 helo=mail-ua1-x934.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nFIh1-00023L-2C for qemu-devel@nongnu.org; Wed, 02 Feb 2022 11:41:32 -0500 Received: by mail-ua1-x934.google.com with SMTP id r8so333502uaj.0 for ; Wed, 02 Feb 2022 08:41:00 -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=6UJYEuCm/8aV9ng3sAr9C2XDjFyqd7pqAQxImsQoknA=; b=aBlFD52oRGYB+HC29c5dh97aNqojMi0Qrog2SQxtKYeHuCCxXVJJZAjIt1y28zAH5y iuI8Zx4CFN57ZVYVkgzig+R2lrRnAOh0DX+REuAVaG5V1I6ybwl6iibBGBY4/3oV2aGj wuxMrdZlD874jSvulJjUdZa5tWEuTe04OjKslzVP+nGrrzfBmPv/npB8Rf/PQIFSlN2K uflWlLJRISmQe5ND0iB4dW7jVHja1sh8037lq51GFmaaFJlEWGX2GI7svjj+ByltZNQG DvAK4FsqXaExc32J9dZHfFaDLj3CvCa2ymQG/hGzvZmOnDn3t96koVkofwUIwMD3ZhBk zfow== 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=6UJYEuCm/8aV9ng3sAr9C2XDjFyqd7pqAQxImsQoknA=; b=1KmgWeD9U5qBdroOdpBzPmlbdbGSNndlwd7+8Cnmo4s68qTsSTX9IJVA/+cjmzJowF goGmdwXQ9xoT1XsYDvO58bm//kqQ6jT2ZpnIvu704hnN6yU/TUGRgwXfXIXswiX2Cgna NLu4SeT8JiymIAWaKQlECYuetprEDIKPjunMphKzpMbeAFoy6HJQMHMsKc6dgx0fJvlY UFCr0HHI7gVwvQFiXZHlCBu1Jt/c+drBke01SXdRrlH5e5sTiXipgdcHtfXDj3b5tC9Q HQqQ/S5X47QG/UK3wLlJSt48RWzLjdKa48cSRDZ7DQJ0rWyl/DZKl0hQKbxBo1030RPG NItg== X-Gm-Message-State: AOAM533LeglQu7Ixy/W/i1VFIeg+l9aPQzIXG0KKpLFrozpPO+b2yaN9 A4oPZFKzdv09wT61NGyNTDcbmo4tOdUCqLuZzsGzcg== X-Google-Smtp-Source: ABdhPJxc0MDSHVaWxL6swp1ROfGA18igPwGT5suvsBuqyD+luD8x1WUyMfGvjHJMaLSOePc9qSCV2ZJbCDg5ng4OhOU= X-Received: by 2002:a67:ffcb:: with SMTP id w11mr11689104vsq.35.1643820059390; Wed, 02 Feb 2022 08:40:59 -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:40:48 -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="000000000000b7450805d70baebe" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::934 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::934; envelope-from=venture@google.com; helo=mail-ua1-x934.google.com X-Spam_score_int: -87 X-Spam_score: -8.8 X-Spam_bar: -------- X-Spam_report: (-8.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, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, USER_IN_DEF_DKIM_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" --000000000000b7450805d70baebe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 2, 2022 at 8:34 AM Patrick Venture wrote: > > > 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 >>> bus. >>> > Now this device simply owns the N i2c busses directly. >>> > >>> > Tested: Verified devices behind mux are still accessible via qmp and >>> i2c >>> > 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 >>> >> Just saw your reply, and found a bunch of other non-spam in my spam folder. I sent the message to the anti-spam team, hopefully that'll resolve this for myself and presumably others. I definitely see the same result with the qdev-monitor, but was really surprised that the qom-list worked. I'll explicitly set the name, and i2c.%d is fine. The detail that they're channels is not really important to the end user presumably. I'll have v2 out shortly. thanks, Patrick --000000000000b7450805d70baebe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 2, 2022 at 8:34 AM Patric= k Venture <venture@google.com&= gt; wrote:


On Tue, Feb 1, 2022 at 12:54 PM Patrick Ve= nture <venture@g= oogle.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>

Just saw your reply= , and found a bunch of other non-spam in my spam folder.=C2=A0 I sent the m= essage to the anti-spam team, hopefully that'll resolve this for myself= and presumably others.

I definitely see the same = result with the qdev-monitor, but was really surprised that the qom-list wo= rked.=C2=A0 I'll explicitly set the name, and i2c.%d is fine.=C2=A0 The= detail that they're channels is not really important to the end user p= resumably.

I'll have v2 out shortly.

thanks,
Patrick=C2=A0
--000000000000b7450805d70baebe--