lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 17 Feb 2020 17:04:52 +0100
From:   Arnd Bergmann <>
To:     Greg KH <>
Cc:     Manivannan Sadhasivam <>,, Jeffrey Hugo <>,
        Kalle Valo <>,
        Bjorn Andersson <>,,
        linux-arm-msm <>,
        "" <>
Subject: Re: [PATCH v2 02/16] bus: mhi: core: Add support for registering MHI controllers

On Mon, Feb 17, 2020 at 3:15 PM Greg KH <> wrote:
> On Mon, Feb 17, 2020 at 06:34:19PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Feb 17, 2020 at 12:59:30PM +0100, Greg KH wrote:
> > ```
> > struct mhi_device *mhi_alloc_device(struct mhi_controller *mhi_cntrl)
> > {
> > ...
> > dev->parent = mhi_cntrl->dev;
> > ...
> > ```
> >
> > Hence, having the parent dev pointer really helps.
> Yes, saving the parent device is fine, but you should be doing your own
> dma calls using _your_ device, not the parents.  Only mess with the
> parent pointer if you need to do something "normal" for a parent.

The MHI device is not involved in DMA at all, as it is not a DMA master,
and has no knowledge of the memory management or whether there
is any DMA at all. I think it is the right abstraction for an MHI driver to
pass kernel pointers into the subsystem interfaces, which then get
mapped by the bus driver that owns the DMA master.

This is similar to how e.g. USB drivers pass data into the USB core
interfaces, which then get the HCI driver to map/unmap it into the
DMA masters.


Powered by blists - more mailing lists