Re: [PATCH v2 00/21] MHI changes for v5.10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 29, 2020 at 08:58:34PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
> 
> On Mon, Sep 28, 2020 at 09:39:30AM +0530, Manivannan Sadhasivam wrote:
> > Hi Greg,
> > 
> > Here is the MHI series for v5.10 cycle. Most of the patches are cleanups
> > in the MHI stack. Notable changes are below:
> > 
> > * Saving the client device hardware information obtained through the BHI
> >   protocol. This information will be exposed through sysfs to make use in
> >   the userland applications.
> > * Introduce sysfs entries to read the serial number and OEM PK hash values
> >   of the client device obtained from BHI protocol. Relevant API documentation
> >   is also added.
> > * Introduce debugfs entries to show MHI states, events, channels, register
> >   state etc... to aid debug.
> > * Remove the channel name from MHI device name as the device is not specific
> >   to channels. Used generic names instead!
> > * Fix the warning reported by Kbuild bot by using append (+=) Kbuild rule
> >   to the mhi/core Makefile.
> > * Introduce APIs to allocate and free MHI controllers. This is done to make
> >   sure that the allocated structs are initialized to NULL before passing to
> >   the MHI core.
> > * Remove the requirement to have a dedicated IRQ for each event ring.
> >   The MHI controllers can now use a single IRQ for all event rings.
> > * Remove the auto-start option for MHI channels. This is done to avoid
> >   receiving spurious uplink from MHI client device when the client driver
> >   is not up. The corresponding qrtr change is also included with Dave's ACK.
> > 
> > Please consider merging!
> > 
> 
> Can you please drop the below two patches while applying this series?
> 
> bus: mhi: Remove auto-start option
> net: qrtr: Start MHI channels during init
> 
> We realized that without these patches, net-next will be broken for QCA6390.
> Proper way to handle this is by using an immutable branch or by carrying the
> ath11k change through MHI tree. We decided to handle this in next merge window.
> 
> Or if you prefer to have a next revision of the series without these patches
> I can send it. Please let me know!

Please just send a new series, that way I "know" I got it right.

thanks,

greg k-h



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux