All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Przemysław Gaj" <pgaj@cadence.com>
Cc: linux-i3c@lists.infradead.org, vitor.soares@synopsys.com,
	rafalc@cadence.com, bbrezillon@kernel.org
Subject: Re: [PATCH v4 2/6] i3c: master: pre-reserve boardinfo->init_dyn_addr when available
Date: Tue, 10 Dec 2019 14:29:43 +0100	[thread overview]
Message-ID: <20191210142943.3804da04@collabora.com> (raw)
In-Reply-To: <20191210101502.8401-3-pgaj@cadence.com>

On Tue, 10 Dec 2019 11:14:58 +0100
Przemysław Gaj <pgaj@cadence.com> wrote:

> It may be the case that SETDASA fails for some reason. Reserve
> ->init_dyn_addr when it's defined to prevent assigning this address  
> to another slave device. This way when device shows up we don't
> have to re-assign addresses.
> 
> Signed-off-by: Przemysław Gaj <pgaj@cadence.com>
> ---
>  drivers/i3c/master.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 5c06c41e6660..fab6e0609fca 100755
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -1263,7 +1263,8 @@ static void i3c_master_put_i3c_addrs(struct i3c_dev_desc *dev)
>  					     I3C_ADDR_SLOT_FREE);
>  
>  	if (dev->boardinfo && dev->boardinfo->init_dyn_addr)
> -		i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr,
> +		i3c_bus_set_addr_slot_status(&master->bus,
> +					     dev->boardinfo->init_dyn_addr,
>  					     I3C_ADDR_SLOT_FREE);

Should be fixed in a separate patch, or at least mentioned in the
commit message.

>  }
>  
> @@ -1675,6 +1676,11 @@ static int i3c_master_bus_init(struct i3c_master_controller *master)
>  				ret = -EBUSY;
>  				goto err_detach_devs;
>  			}
> +
> +			/* Reserve the slot. */
> +			i3c_bus_set_addr_slot_status(&master->bus,
> +						     i3cboardinfo->init_dyn_addr,
> +						     I3C_ADDR_SLOT_I3C_DEV);

Looks like the "reserve/release init_dyn_addr slot" logic is
asymmetric. I wonder if that's not a problem. Can't we end up in a
situation where the ->init_dyn_addr is released (when SETDASA() fails)
and then re-used without being reserved (when the device is later
discovered through a regular DAA)?

So maybe I was wrong and we should indeed reserve the address in the
i3c_master_get_i3c_addrs() path.

>  		}
>  
>  		i3cdev = i3c_master_alloc_i3c_dev(master, &info);


_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply	other threads:[~2019-12-10 13:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 10:14 [PATCH v4 0/6] I3C device addresing adjustments Przemysław Gaj
2019-12-10 10:14 ` [PATCH v4 1/6] i3c: master: make sure ->boardinfo is initialized in add_i3c_dev_locked() Przemysław Gaj
2019-12-10 10:14   ` Przemysław Gaj
2019-12-10 10:14 ` [PATCH v4 2/6] i3c: master: pre-reserve boardinfo->init_dyn_addr when available Przemysław Gaj
2019-12-10 13:29   ` Boris Brezillon [this message]
2019-12-10 15:24   ` Vitor Soares
2019-12-11  8:51     ` Przemysław Gaj
2019-12-10 10:14 ` [PATCH v4 3/6] i3c: master: make sure the PID is set before registering the device Przemysław Gaj
2019-12-10 10:15 ` [PATCH v4 4/6] dt-bindings: i3c: Make 'assigned-address' valid if static address == 0 Przemysław Gaj
2019-12-10 10:15 ` [PATCH v4 5/6] dt-bindings: i3c: add a note for no guarantee of 'assigned-address' use Przemysław Gaj
2019-12-10 10:15 ` [PATCH v4 6/6] i3c: master: dw: reattach device on first available location of address table Przemysław Gaj
2019-12-10 14:40   ` Vitor Soares
2019-12-10 14:43     ` Przemysław Gaj
2019-12-10 14:52     ` Boris Brezillon

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=20191210142943.3804da04@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=bbrezillon@kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=pgaj@cadence.com \
    --cc=rafalc@cadence.com \
    --cc=vitor.soares@synopsys.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.