All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitor Soares <Vitor.Soares@synopsys.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: "bbrezillon@kernel.org" <bbrezillon@kernel.org>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	Jose Abreu <Jose.Abreu@synopsys.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"wsa@the-dreams.de" <wsa@the-dreams.de>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: RE: [PATCH v3 0/5] Introduce i3c device userspace interface
Date: Mon, 24 Feb 2020 10:53:25 +0000	[thread overview]
Message-ID: <CH2PR12MB4216F86F6820CC5247B89BA8AEEC0@CH2PR12MB4216.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20200221184116.1d8f0677@collabora.com>

Hi Boris,

From: Boris Brezillon <boris.brezillon@collabora.com>
Date: Fri, Feb 21, 2020 at 17:41:16

> > > > 
> > > > I want to make you know that none of your previous comments was ignored 
> > > > and  I would like to start the discussion from this point.  
> > > 
> > > Sure, np. I'll probably wait for a v4 exploring the option I proposed
> > > then.  
> > 
> > I would like to check with you:
> >   - How can we prioritize the device driver over the i3cdev driver if the 
> > driver is loaded after i3cdev? Currently, this is done automatically 
> > without any command, and for me, this is a requirement.
> 
> No devs would be bound to the i3cdev driver by default, it would have
> to be done explicitly through a sysfs knob. Which makes me realize
> we can't use the generic bind knob since it doesn't let the subsystem
> know that it's a manual bind. I thought there was a way to distinguish
> between manual and auto-bind.
> 
> >   - For the ioctl command structure, there is no rule about the way I did 
> > or what you proposed, both are currently used in the kernel. For me it is 
> > one more structure to deal with, can you point the advantages of your 
> > purpose?
> 
> I don't have a strong opinion on that one, though I find it a bit
> easier to follow when the number of xfers is encoded in a separate
> struct rather than extracted from the data size passed through the cmd
> argument.

I will change it then. Do you have any suggestion for the naming to keep 
it short?

> 
> >   - Regarding the ioctl codes, I tried to use those after I2C.
> 
> Why start from 0x30? It doesn't make sense to me. Just because you base
> your code on something that already exists doesn't mean you have to
> copy all of it.

I might be wrong but last I2C command is 0x20 and I tried to let some 
free space in case they need.
Also I think that make sense I2C and I3C share the same 'magic number'.

BTW, in ioctl-numbers documentation there is no reference for code 0x07.

Best regards,
Vitor Soares

WARNING: multiple messages have this Message-ID (diff)
From: Vitor Soares <Vitor.Soares@synopsys.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"wsa@the-dreams.de" <wsa@the-dreams.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"bbrezillon@kernel.org" <bbrezillon@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: RE: [PATCH v3 0/5] Introduce i3c device userspace interface
Date: Mon, 24 Feb 2020 10:53:25 +0000	[thread overview]
Message-ID: <CH2PR12MB4216F86F6820CC5247B89BA8AEEC0@CH2PR12MB4216.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20200221184116.1d8f0677@collabora.com>

Hi Boris,

From: Boris Brezillon <boris.brezillon@collabora.com>
Date: Fri, Feb 21, 2020 at 17:41:16

> > > > 
> > > > I want to make you know that none of your previous comments was ignored 
> > > > and  I would like to start the discussion from this point.  
> > > 
> > > Sure, np. I'll probably wait for a v4 exploring the option I proposed
> > > then.  
> > 
> > I would like to check with you:
> >   - How can we prioritize the device driver over the i3cdev driver if the 
> > driver is loaded after i3cdev? Currently, this is done automatically 
> > without any command, and for me, this is a requirement.
> 
> No devs would be bound to the i3cdev driver by default, it would have
> to be done explicitly through a sysfs knob. Which makes me realize
> we can't use the generic bind knob since it doesn't let the subsystem
> know that it's a manual bind. I thought there was a way to distinguish
> between manual and auto-bind.
> 
> >   - For the ioctl command structure, there is no rule about the way I did 
> > or what you proposed, both are currently used in the kernel. For me it is 
> > one more structure to deal with, can you point the advantages of your 
> > purpose?
> 
> I don't have a strong opinion on that one, though I find it a bit
> easier to follow when the number of xfers is encoded in a separate
> struct rather than extracted from the data size passed through the cmd
> argument.

I will change it then. Do you have any suggestion for the naming to keep 
it short?

> 
> >   - Regarding the ioctl codes, I tried to use those after I2C.
> 
> Why start from 0x30? It doesn't make sense to me. Just because you base
> your code on something that already exists doesn't mean you have to
> copy all of it.

I might be wrong but last I2C command is 0x20 and I tried to let some 
free space in case they need.
Also I think that make sense I2C and I3C share the same 'magic number'.

BTW, in ioctl-numbers documentation there is no reference for code 0x07.

Best regards,
Vitor Soares

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

  reply	other threads:[~2020-02-24 10:53 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19  0:20 [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares
2020-02-19  0:20 ` Vitor Soares
2020-02-19  0:20 ` [PATCH v3 1/5] i3c: master: export i3c_masterdev_type Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  0:20 ` [PATCH v3 2/5] i3c: master: export i3c_bus_type symbol Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  0:20 ` [PATCH v3 3/5] i3c: master: add i3c_for_each_dev helper Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  7:35   ` Greg KH
2020-02-19  7:35     ` Greg KH
2020-02-21 11:47     ` Vitor Soares
2020-02-21 11:47       ` Vitor Soares
2020-02-21 11:52       ` Greg KH
2020-02-21 11:52         ` Greg KH
2020-02-21 12:59         ` Boris Brezillon
2020-02-21 12:59           ` Boris Brezillon
2020-02-21 16:44           ` Boris Brezillon
2020-02-21 16:44             ` Boris Brezillon
2020-02-21 16:45             ` Boris Brezillon
2020-02-21 16:45               ` Boris Brezillon
2020-02-21 17:19             ` Vitor Soares
2020-02-21 17:19               ` Vitor Soares
2020-02-22  8:38             ` Boris Brezillon
2020-02-22  8:38               ` Boris Brezillon
2020-02-19  0:20 ` [PATCH v3 4/5] i3c: add i3cdev module to expose i3c dev in /dev Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  7:37   ` Greg KH
2020-02-19  7:37     ` Greg KH
2020-02-19  8:45     ` Vitor Soares
2020-02-19  8:45       ` Vitor Soares
2020-02-19  7:39   ` Greg KH
2020-02-19  7:39     ` Greg KH
2020-02-21 11:50     ` Vitor Soares
2020-02-21 11:50       ` Vitor Soares
2020-02-19  8:42   ` Greg KH
2020-02-19  8:42     ` Greg KH
2020-02-21 22:32   ` Boris Brezillon
2020-02-21 22:32     ` Boris Brezillon
2020-02-24 11:04     ` Vitor Soares
2020-02-24 11:04       ` Vitor Soares
2020-02-24 11:22       ` Boris Brezillon
2020-02-24 11:22         ` Boris Brezillon
2020-02-19  0:20 ` [PATCH v3 5/5] add i3cdev documentation Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  0:46   ` Vitor Soares
2020-02-19  0:46     ` Vitor Soares
2020-02-19  4:34   ` Randy Dunlap
2020-02-19  4:34     ` Randy Dunlap
2020-02-21 10:31     ` Vitor Soares
2020-02-21 10:31       ` Vitor Soares
2020-02-21 15:36       ` Randy Dunlap
2020-02-21 15:36         ` Randy Dunlap
2020-02-19  0:39 ` [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares
2020-02-19  0:39   ` Vitor Soares
2020-02-19  8:16   ` Boris Brezillon
2020-02-19  8:16     ` Boris Brezillon
2020-02-21 17:08     ` Vitor Soares
2020-02-21 17:08       ` Vitor Soares
2020-02-21 17:41       ` Boris Brezillon
2020-02-21 17:41         ` Boris Brezillon
2020-02-24 10:53         ` Vitor Soares [this message]
2020-02-24 10:53           ` Vitor Soares
2020-02-24 11:24           ` Boris Brezillon
2020-02-24 11:24             ` 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=CH2PR12MB4216F86F6820CC5247B89BA8AEEC0@CH2PR12MB4216.namprd12.prod.outlook.com \
    --to=vitor.soares@synopsys.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=bbrezillon@kernel.org \
    --cc=boris.brezillon@collabora.com \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /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.