linux-i3c.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <bbrezillon@kernel.org>
To: Ryan Chen <ryan_chen@aspeedtech.com>
Cc: "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	Vitor Soares <Vitor.Soares@synopsys.com>
Subject: Re: i3c application
Date: Tue, 29 Jan 2019 14:30:21 +0100	[thread overview]
Message-ID: <20190129143021.475588a7@bbrezillon> (raw)
In-Reply-To: <f778a542ef6647069681ed4a4d35c907@TWMBX02.aspeed.com>

+Vitor who started a discussion around i3c-tools and the associate
kernel <-> userspace interface.

Hi Ryan,

On Tue, 29 Jan 2019 00:54:05 +0000
Ryan Chen <ryan_chen@aspeedtech.com> wrote:

> Hi all,
> 	I just work with I3C, does there have any application like i2c-tools I can used?

No, but I'll ask the same question I already asked Vitor: what would
you use i3c-tools for? What should it contain? I'm not against the
idea, but I'd like to delimit the scope of the userspace interface.

> 	Or any Linux i3c application I can have i3c slave and master loop test? 

Not sure I get this request correctly. Are you talking about a dummy
slave driver that would return any data it receives to the TX queue
so that the next read request coming from the master returns what the
master wrote in its previous write access?

If that's what you have in mind, then it's definitely not supported.
But before we even consider doing that, we should first introduce the
concept of I3C slave controller and then decide how we want to expose
slave features. Note that Vitor and I disagree on the solution: I think
we should mimic the USB gadget approach (where you can attach a generic
profile to any USB device controller), and Vitor thinks slave IPs
should have their profile/feature-set hardcoded in the driver (which
works fine for hardcoded slave IPs, but is not that great if the slave
block is generic).

Regards,

Boris

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

  reply	other threads:[~2019-01-29 13:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-29  0:54 i3c application Ryan Chen
2019-01-29 13:30 ` Boris Brezillon [this message]
2019-02-02  3:01   ` Ryan Chen
2019-02-03 17:33     ` Boris Brezillon
2019-02-04  7:08       ` Ryan Chen
2019-02-04 10:59         ` vitor
2019-02-05 14:49           ` Ryan Chen

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=20190129143021.475588a7@bbrezillon \
    --to=bbrezillon@kernel.org \
    --cc=Vitor.Soares@synopsys.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=ryan_chen@aspeedtech.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).