All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Venture <venture@google.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Corey Minyard <cminyard@mvista.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Hao Wu <wuhaotsh@google.com>
Subject: Re: [PATCH] hw/i2c: flatten pca954x mux device
Date: Wed, 2 Feb 2022 08:34:32 -0800	[thread overview]
Message-ID: <CAO=notw9jYSc6xGr3_kwuAWHG2J3VJ7WxJT+tL_fbXFfTRrhpw@mail.gmail.com> (raw)
In-Reply-To: <CAO=notxPP8+b6S6UnUX7s4yWQsEhaAS0CZbn1my0HEN2idL6tA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3595 bytes --]

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

>
>
> On Tue, Feb 1, 2022 at 11:02 AM Philippe Mathieu-Daudé <f4bug@amsat.org>
> 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 <wuhaotsh@google.com>
>> > Signed-off-by: Patrick Venture <venture@google.com>
>> > ---
>> >   hw/i2c/i2c_mux_pca954x.c | 75 ++++++----------------------------------
>> >   1 file changed, 11 insertions(+), 64 deletions(-)
>>
>> >   static void pca954x_init(Object *obj)
>> >   {
>> >       Pca954xState *s = PCA954X(obj);
>> >       Pca954xClass *c = PCA954X_GET_CLASS(obj);
>> >       int i;
>> >
>> > -    /* Only initialize the children we expect. */
>> > +    /* SMBus modules. Cannot fail. */
>> >       for (i = 0; i < c->nchans; i++) {
>> > -        object_initialize_child(obj, "channel[*]", &s->channel[i],
>> > -                                TYPE_PCA954X_CHANNEL);
>> > +        /* start all channels as disabled. */
>> > +        s->enabled[i] = false;
>> > +        s->bus[i] = 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<bus>"},
> {"name": "realized", "type": "bool"},
> {"name": "hotplugged", "type": "bool"},
> {"name": "hotpluggable", "type": "bool"},
> {"name": "address", "type": "uint8"},
> {"name": "channel[3]", "type": "child<i2c-bus>"},
> {"name": "channel[0]", "type": "child<i2c-bus>"},
> {"name": "channel[1]", "type": "child<i2c-bus>"},
> {"name": "channel[2]", "type": "child<i2c-bus>"}
> ]}
>
> 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 = 0; i < c->nchans; i++) {
>> +        g_autofree gchar *bus_name = g_strdup_printf("i2c.%d", i);
>> +
>>           /* start all channels as disabled. */
>>           s->enabled[i] = false;
>> -        s->bus[i] = i2c_init_bus(DEVICE(s), "channel[*]");
>> +        s->bus[i] = i2c_init_bus(DEVICE(s), bus_name);
>>       }
>>   }
>>
>> ---
>>
>> (look at HMP 'info qtree' output).
>>
>> >       }
>> >   }
>>
>> With the change:
>> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>
>

[-- Attachment #2: Type: text/html, Size: 5811 bytes --]

  parent reply	other threads:[~2022-02-02 18:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01 16:30 [PATCH] hw/i2c: flatten pca954x mux device Patrick Venture
2022-02-01 19:02 ` Philippe Mathieu-Daudé via
2022-02-01 20:54   ` Patrick Venture
2022-02-02 16:20     ` Philippe Mathieu-Daudé via
2022-02-02 16:34     ` Patrick Venture [this message]
2022-02-02 16:40       ` Patrick Venture
2022-02-02 17:30         ` Philippe Mathieu-Daudé via
2022-02-02 21:30           ` Patrick Venture
2022-02-02 19:01         ` Peter Maydell
2022-02-02 19:53           ` Patrick Venture

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO=notw9jYSc6xGr3_kwuAWHG2J3VJ7WxJT+tL_fbXFfTRrhpw@mail.gmail.com' \
    --to=venture@google.com \
    --cc=cminyard@mvista.com \
    --cc=f4bug@amsat.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wuhaotsh@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.