All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 


  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 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.