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: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	arnd@arndb.de, smohanad@codeaurora.org, kvalo@codeaurora.org,
	bjorn.andersson@linaro.org, hemantk@codeaurora.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/16] bus: mhi: core: Add support for registering MHI controllers
Date: Sat, 25 Jan 2020 14:26:15 +0100	[thread overview]
Message-ID: <20200125132615.GA3516435@kroah.com> (raw)
In-Reply-To: <e32b0a53-ce95-6d73-46c6-76d17af37146@codeaurora.org>

On Fri, Jan 24, 2020 at 11:12:57AM -0700, Jeffrey Hugo wrote:
> On 1/24/2020 10:47 AM, Greg KH wrote:
> > On Fri, Jan 24, 2020 at 07:24:43AM -0700, Jeffrey Hugo wrote:
> > > > > +/**
> > > > > + * struct mhi_result - Completed buffer information
> > > > > + * @buf_addr: Address of data buffer
> > > > > + * @dir: Channel direction
> > > > > + * @bytes_xfer: # of bytes transferred
> > > > > + * @transaction_status: Status of last transaction
> > > > > + */
> > > > > +struct mhi_result {
> > > > > +	void *buf_addr;
> > > > 
> > > > Why void *?
> > > 
> > > Because its not possible to resolve this more clearly.  The client provides
> > > the buffer and knows what the structure is.  The bus does not. Its just an
> > > opaque pointer (hence void *) to the bus, and the client needs to decode it.
> > > This is the struct that is handed to the client to allow them to decode the
> > > activity (either a received buf, or a confirmation that a transmitted buf
> > > has been consumed).
> > 
> > Then shouldn't this be a "u8 *" instead as you are saying how many bytes
> > are here?
> 
> I'm sorry, I don't see the benefit of that.  Can you elaborate on why you
> think that u8 * is a better type?
> 
> Sure, its an arbitrary byte stream from the perspective of the bus, but to
> the client, 99% of the time its going to have some structure.

So which side is in control here, the "bus" or the "client"?  For the
bus to care, it's a bytestream and should be represented as such (like
you have) with a number of bytes in the "packet".

If you already know the structure types, just make a union of all of the
valid ones and be done with it.  In other words, try to avoid using void
* as much as is ever possible please.

thanks,

greg k-h

  reply	other threads:[~2020-01-25 13:29 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23 11:18 [PATCH 00/16] Add MHI bus support Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 01/16] docs: Add documentation for MHI bus Manivannan Sadhasivam
2020-01-23 12:58   ` Arnd Bergmann
2020-01-23 13:10     ` Manivannan Sadhasivam
2020-01-23 13:19       ` Arnd Bergmann
2020-01-23 13:30         ` Manivannan Sadhasivam
2020-01-23 14:52           ` Jeffrey Hugo
2020-01-23 16:41   ` Jeffrey Hugo
2020-01-27 12:02     ` Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 02/16] bus: mhi: core: Add support for registering MHI controllers Manivannan Sadhasivam
2020-01-23 11:33   ` Greg KH
2020-01-23 11:56     ` Manivannan Sadhasivam
2020-01-23 17:05   ` Jeffrey Hugo
2020-01-23 18:14     ` Greg KH
2020-01-26 23:58     ` Jeffrey Hugo
2020-01-28  7:19       ` Manivannan Sadhasivam
2020-01-27 11:56     ` Manivannan Sadhasivam
2020-01-27 14:52       ` Jeffrey Hugo
2020-01-28  6:37         ` Manivannan Sadhasivam
2020-01-28  7:24           ` Greg KH
2020-01-28  7:27             ` Manivannan Sadhasivam
2020-01-24  8:29   ` Greg KH
2020-01-24 14:24     ` Jeffrey Hugo
2020-01-24 17:47       ` Greg KH
2020-01-24 18:12         ` Jeffrey Hugo
2020-01-25 13:26           ` Greg KH [this message]
2020-01-26 21:00             ` Jeffrey Hugo
2020-01-27  7:02       ` Manivannan Sadhasivam
2020-01-27  7:11         ` Greg KH
2020-01-23 11:18 ` [PATCH 03/16] bus: mhi: core: Add support for registering MHI client drivers Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 04/16] bus: mhi: core: Add support for creating and destroying MHI devices Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 05/16] bus: mhi: core: Add support for ringing channel/event ring doorbells Manivannan Sadhasivam
2020-01-23 11:39   ` Arnd Bergmann
2020-01-23 12:00     ` Manivannan Sadhasivam
2020-01-23 12:44       ` Arnd Bergmann
2020-01-23 13:01         ` Manivannan Sadhasivam
2020-01-23 14:44       ` Jeffrey Hugo
2020-01-24 22:51   ` Jeffrey Hugo
2020-01-25 13:46     ` Greg KH
2020-01-27  7:10       ` Manivannan Sadhasivam
2020-01-27  7:21         ` Greg KH
2020-01-23 11:18 ` [PATCH 06/16] bus: mhi: core: Add support for PM state transitions Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 07/16] bus: mhi: core: Add support for basic PM operations Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 08/16] bus: mhi: core: Add support for downloading firmware over BHIe Manivannan Sadhasivam
2020-01-28 19:36   ` Jeffrey Hugo
2020-01-29  6:56     ` Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 09/16] bus: mhi: core: Add support for downloading RDDM image during panic Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 10/16] bus: mhi: core: Add support for processing events from client device Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 11/16] bus: mhi: core: Add support for data transfer Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 12/16] bus: mhi: core: Add uevent support for module autoloading Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 13/16] MAINTAINERS: Add entry for MHI bus Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 14/16] net: qrtr: Add MHI transport layer Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 15/16] net: qrtr: Do not depend on ARCH_QCOM Manivannan Sadhasivam
2020-01-23 11:18 ` [PATCH 16/16] soc: qcom: Do not depend on ARCH_QCOM for QMI helpers Manivannan Sadhasivam
2020-01-23 11:45   ` Arnd Bergmann
2020-01-23 12:03     ` Manivannan Sadhasivam

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=20200125132615.GA3516435@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=hemantk@codeaurora.org \
    --cc=jhugo@codeaurora.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=smohanad@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).