linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: arnd@arndb.de, manivannan.sadhasivam@linaro.org,
	bjorn.andersson@linaro.org, wufan@codeaurora.org,
	pratanan@codeaurora.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 5/8] qaic: Implement data path
Date: Thu, 14 May 2020 18:37:34 +0200	[thread overview]
Message-ID: <20200514163734.GB3154055@kroah.com> (raw)
In-Reply-To: <d34d726d-7911-824d-82ac-34358874b103@codeaurora.org>

On Thu, May 14, 2020 at 10:12:03AM -0600, Jeffrey Hugo wrote:
> On 5/14/2020 9:56 AM, Greg KH wrote:
> > On Thu, May 14, 2020 at 09:06:53AM -0600, Jeffrey Hugo wrote:
> > > On 5/14/2020 8:14 AM, Greg KH wrote:
> > > > On Thu, May 14, 2020 at 08:07:43AM -0600, Jeffrey Hugo wrote:
> > > > > +struct qaic_execute {
> > > > > +	__u16		ver;    /* struct version, must be 1 */
> > > > 
> > > > No need for structures to be versioned.  If you change something, then
> > > > add a new ioctl if you really needed it.
> > > 
> > > Huh.  We had thought the botching ioctls document advised having a version,
> > > but as I double check that document, it infact does not.
> > > 
> > > Will remove.
> > 
> > Thanks, you can also remove the "reserved" variables as well as those
> > will not be needed either.
> 
> Are you sure?
> 
> Documentation/process/botching-up-ioctls.rst
> Starting at Line 38:
> 
> "Pad the entire struct to a multiple of 64-bits if the structure contains
> 64-bit types - the structure size will otherwise differ on 32-bit versus
> 64-bit. Having a different structure size hurts when passing arrays of
> structures to the kernel, or if the kernel checks the structure size, which
> e.g. the drm core does."
> 
> The "reserved" variables seem to be in line with that.

Padding is fine to use, but don't use that as a "I'm reserving this to
use it for later" type of thing which is how I read the structure
definitions.  I might be totally wrong, but you should be explicit here.

thanks,

greg k-h

  reply	other threads:[~2020-05-14 16:37 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 14:07 [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver Jeffrey Hugo
2020-05-14 14:07 ` [RFC PATCH 1/8] qaic: Add skeleton driver Jeffrey Hugo
2020-05-15  0:43   ` Jeffrey Hugo
2020-05-15  6:37     ` Greg KH
2020-05-14 14:07 ` [RFC PATCH 2/8] qaic: Add and init a basic mhi controller Jeffrey Hugo
2020-05-14 14:07 ` [RFC PATCH 3/8] qaic: Create char dev Jeffrey Hugo
2020-05-14 14:12   ` Greg KH
2020-05-14 15:05     ` Jeffrey Hugo
2020-05-14 15:56       ` Greg KH
2020-05-14 16:24         ` Jeffrey Hugo
2020-05-15 21:08           ` Jeffrey Hugo
2020-05-16  7:01             ` Greg KH
2020-05-16 21:29               ` Jeffrey Hugo
2020-05-17  7:14                 ` Greg KH
2020-05-17 19:37                   ` Jeffrey Hugo
2020-05-14 14:07 ` [RFC PATCH 4/8] qaic: Implement control path Jeffrey Hugo
2020-05-14 14:07 ` [RFC PATCH 5/8] qaic: Implement data path Jeffrey Hugo
2020-05-14 14:14   ` Greg KH
2020-05-14 15:06     ` Jeffrey Hugo
2020-05-14 15:56       ` Greg KH
2020-05-14 16:12         ` Jeffrey Hugo
2020-05-14 16:37           ` Greg KH [this message]
2020-05-14 16:45             ` Jeffrey Hugo
2020-05-14 21:36   ` Arnd Bergmann
2020-05-14 22:06     ` Jeffrey Hugo
2020-05-14 22:20       ` Arnd Bergmann
2020-05-14 14:07 ` [RFC PATCH 6/8] qaic: Implement PCI link status error handlers Jeffrey Hugo
2020-05-14 14:07 ` [RFC PATCH 7/8] qaic: Implement MHI error status handler Jeffrey Hugo
2020-05-14 14:07 ` [RFC PATCH 8/8] MAINTAINERS: Add entry for QAIC driver Jeffrey Hugo
2020-05-19  5:08 ` [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver Dave Airlie
2020-05-19 14:57   ` Jeffrey Hugo
2020-05-19 17:41     ` Greg Kroah-Hartman
2020-05-19 18:07       ` Jeffrey Hugo
2020-05-19 18:12         ` Greg Kroah-Hartman
2020-05-19 18:26           ` Jeffrey Hugo
2020-05-20  5:32             ` Greg Kroah-Hartman
2020-05-19 17:33   ` Greg Kroah-Hartman
2020-05-19  6:57 ` Manivannan Sadhasivam
2020-05-19 14:16   ` Jeffrey Hugo

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=20200514163734.GB3154055@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=jhugo@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=pratanan@codeaurora.org \
    --cc=wufan@codeaurora.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 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).