From: Corey Minyard <minyard@acm.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Joe Komlodi <komlodi@google.com>,
qemu-devel@nongnu.org, venture@google.com
Subject: Re: [PATCH v3 1/3] hw/i2c: core: Add reset
Date: Fri, 16 Feb 2024 19:04:29 -0600 [thread overview]
Message-ID: <ZdAGHThxd2JSyX7b@mail.minyard.net> (raw)
In-Reply-To: <CAFEAcA8R13bQ7niSXhZPJ3vUD_OdNWpvjpKrWpz-gZsJxO_=dg@mail.gmail.com>
On Thu, Feb 08, 2024 at 04:39:10PM +0000, Peter Maydell wrote:
> On Fri, 2 Feb 2024 at 20:48, Joe Komlodi <komlodi@google.com> wrote:
> >
> > It's possible for a reset to come in the middle of a transaction, which
> > causes the bus to be in an old state when a new transaction comes in.
> >
> > Signed-off-by: Joe Komlodi <komlodi@google.com>
> > ---
> > hw/i2c/core.c | 19 +++++++++++++++++++
> > include/hw/i2c/i2c.h | 2 +-
> > 2 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/i2c/core.c b/hw/i2c/core.c
> > index 4cf30b2c86..3128067bba 100644
> > --- a/hw/i2c/core.c
> > +++ b/hw/i2c/core.c
> > @@ -23,10 +23,29 @@ static Property i2c_props[] = {
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
> > +static void i2c_bus_hold_reset(Object *obj)
> > +{
> > + I2CBus *bus = I2C_BUS(obj);
> > + I2CNode *node, *next;
> > +
> > + bus->broadcast = false;
> > + QLIST_FOREACH_SAFE(node, &bus->current_devs, next, next) {
> > + QLIST_REMOVE(node, next);
> > + g_free(node);
> > + }
> > +}
>
> This does what it says it's going to do; but I think it
> would be good to hear from Corey whether it's better to
> do this, or instead to call i2c_end_transfer() in the
> reset-enter phase.
Sorry, I missed this, I'm having major chaos going on right now in my
life.
I don't think i2c_end_transfer() is the right thing to do. The transfer
has not cleanly ended, it is just forgotten.
>
> Mostly QEMU's "reset" is like power-cycling, in which case
> I guess that what we have here where we just forget about
> the in-progress transfer and assume the device on the other
> end is also going to reset back to a neutral state is what
> we want.
>
> Does i2c have a concept of a bus-level "reset" operation?
No, it does not. Most I2C devices don't even have a reset pin. In a
reset situation in real hardware, the operation would be aborted by
the lines drifting high after the bus master has been reset.
So I think this is fine as is.
-corey
>
> > +
> > +static void i2c_bus_class_init(ObjectClass *klass, void *data)
> > +{
> > + ResettableClass *rc = RESETTABLE_CLASS(klass);
> > + rc->phases.hold = i2c_bus_hold_reset;
> > +}
> > +
> > static const TypeInfo i2c_bus_info = {
> > .name = TYPE_I2C_BUS,
> > .parent = TYPE_BUS,
> > .instance_size = sizeof(I2CBus),
> > + .class_init = i2c_bus_class_init,
> > };
>
>
>
> > static int i2c_bus_pre_save(void *opaque)
> > diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
> > index 2a3abacd1b..49580e30e2 100644
> > --- a/include/hw/i2c/i2c.h
> > +++ b/include/hw/i2c/i2c.h
> > @@ -64,7 +64,7 @@ struct I2CSlave {
> > };
> >
> > #define TYPE_I2C_BUS "i2c-bus"
> > -OBJECT_DECLARE_SIMPLE_TYPE(I2CBus, I2C_BUS)
> > +OBJECT_DECLARE_TYPE(I2CBus, I2CBusClass, I2C_BUS)
>
> I don't think you need this change any more ?
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2024-02-17 1:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 20:48 [PATCH v3 0/3] hw/i2c: smbus: Reset fixes Joe Komlodi
2024-02-02 20:48 ` [PATCH v3 1/3] hw/i2c: core: Add reset Joe Komlodi
2024-02-08 16:39 ` Peter Maydell
2024-02-16 23:05 ` Joe Komlodi
2024-02-17 1:04 ` Corey Minyard [this message]
2024-02-20 19:11 ` Joe Komlodi
2024-02-02 20:48 ` [PATCH v3 2/3] hw/i2c/smbus_slave: Add object path on error prints Joe Komlodi
2024-02-08 16:28 ` Peter Maydell
2024-02-02 20:48 ` [PATCH v3 3/3] hw/i2c: smbus_slave: Reset state on reset Joe Komlodi
2024-02-08 16:31 ` Peter Maydell
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=ZdAGHThxd2JSyX7b@mail.minyard.net \
--to=minyard@acm.org \
--cc=komlodi@google.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=venture@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).