mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeffrey Hugo <jhugo@codeaurora.org>
To: Greg KH <gregkh@linuxfoundation.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: Fri, 24 Jan 2020 11:12:57 -0700	[thread overview]
Message-ID: <e32b0a53-ce95-6d73-46c6-76d17af37146@codeaurora.org> (raw)
In-Reply-To: <20200124174707.GB3417153@kroah.com>

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.

In the call back, the first thing the client is likely to do is:
struct my_struct *s = buf_addr;

This works great when its a void *.  If buf_addr is a u8 *, that's not 
valid, and will result in a compiler error (at-least per gcc 5.4.0).
With u8 *, the client has to do:
struct my_struct *s = (struct my_struct *)buf_addr;

I don't see a benefit to u8 * over void * in this case.

The only possibly benefit I might see is if the client wants to use 
buf_addr as an array to poke into it and maybe check a magic number, but 
that assumes said magic number is a u8.  Otherwise the client has to do 
an explicit cast.  It seems like such a small amount of the time that 
usecase would be valid, that its not worth it to cater to it.

rpmsg, as one example, does the exact same thing where the received 
buffer is a void *, and there is a size parameter.

-- 
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

  reply	other threads:[~2020-01-24 18:13 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 [this message]
2020-01-25 13:26           ` Greg KH
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=e32b0a53-ce95-6d73-46c6-76d17af37146@codeaurora.org \
    --to=jhugo@codeaurora.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hemantk@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

all inboxes | Powered by JetHome®