All of lore.kernel.org
 help / color / mirror / Atom feed
From: bbrezillon@kernel.org (Boris Brezillon)
To: linux-i3c@lists.infradead.org
Subject: i3c_master_add_i3c_dev_locked() accept PID, BCR, DCR
Date: Wed, 12 Dec 2018 10:09:53 +0100	[thread overview]
Message-ID: <20181212100953.11d7cbdf@bbrezillon> (raw)
In-Reply-To: <E493F29A-767B-486F-8630-10200F0F54DD@cadence.com>

On Wed, 12 Dec 2018 09:02:17 +0000
Przemyslaw Gaj <pgaj@cadence.com> wrote:
>     >     
>     >     Okay, so this is actually one reason we'd want to add devices without
>     >     triggering transfers on the bus. The thing is, we need more than just
>     >     PID, BCR and DCR, and those information are not passed in the DEFSLVS
>     >     frame (MXDS, MRL, MWL, HDRCAP). IIRC, we started discussing that with
>     >     Arnd, Vitor and you and we listed 2 options:
>     >     
>     >     1/ force the secondary master to take bus ownership after it has
>     >        received DEFSLVS so that it can retrieve the missing bits and finally
>     >        expose devices to its users
>     >     2/ bind partially discovered devices to drivers and retrieve the device
>     >        information on-demand (when i3c_device_get_info() is called).
>     >     
>     >     If we go for option #2, we'll need a separate function that does more
>     >     than just skipping GETPID, GETDCR and GETBCR. Of course #2 is more
>     >     elegant in that it doesn't force a mastership handover until someone
>     >     really wants to access a device through the secondary master, but #1 is
>     >     definitely simpler to implement.
>     > 
>     > Ok, I see. Regarding #2, device is matched by PID, how do you want to handle this?  
>     
>     As I said, if we go for #2, we'll need a way to pass the PID, BCR and
>     DCR we received from the DEFSLVS frame. So yes, that's actually one
>     case where passing this info to i3c_master_add_i3c_dev_locked() makes
>     sense. But, you'll also have to modify this function to skip
>     i3c_master_retrieve_dev_info(). So maybe it's just simpler to have a
>     separate function for this case (i3c_master_defslvs_add_dev_locked()?)
>     
>     > I think we still need to use GETPID before registering the device. Can you see different path?  
>     
>     We need the PID for sure, but it's passed in DEFSLVS, so we should be
>     good.
> 
> As far as I remember it's not. Only BCR, DCR, DA and SA.

Oh, I thought it was. So option #2 is not even possible, which means
we don't have a choice, we must implement solution #1.

      reply	other threads:[~2018-12-12  9:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 19:21 i3c_master_add_i3c_dev_locked() accept PID, BCR, DCR vitor
2018-12-10 19:43 ` Boris Brezillon
2018-12-10 20:14   ` Boris Brezillon
2018-12-11 11:54     ` vitor
2018-12-11 11:58       ` Boris Brezillon
2018-12-11 12:07         ` vitor
2018-12-11 12:21           ` Boris Brezillon
2018-12-11 12:25             ` Boris Brezillon
2018-12-11 15:47               ` vitor
2018-12-12  6:06                 ` Przemyslaw Gaj
2018-12-12  8:21                   ` Boris Brezillon
2018-12-12  8:37                     ` Przemyslaw Gaj
2018-12-12  8:52                       ` Boris Brezillon
2018-12-12  9:02                         ` Przemyslaw Gaj
2018-12-12  9:09                           ` Boris Brezillon [this message]

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=20181212100953.11d7cbdf@bbrezillon \
    --to=bbrezillon@kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    /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.