Re: [PATCH v5 00/13] bus/fsl-mc: Extend mc-bus driver functionalities in preparation for mc-bus VFIO support

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Oct 14, 2020 at 08:27:42PM -0600, Alex Williamson wrote:
> On Fri, 2 Oct 2020 16:05:49 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > On Fri, Oct 02, 2020 at 04:56:52PM +0300, Laurentiu Tudor wrote:
> > > Hi Greg,
> > > 
> > > On 10/2/2020 4:55 PM, Greg KH wrote:  
> > > > On Tue, Sep 29, 2020 at 02:06:41PM +0300, Laurentiu Tudor wrote:  
> > > >>
> > > >>
> > > >> On 9/29/2020 11:54 AM, Diana Craciun wrote:  
> > > >>> The vfio-mc bus driver needs some additional services to be exported by the
> > > >>> mc-bus driver like:
> > > >>> - a way to reset the DPRC container
> > > >>> - driver_override support
> > > >>> - functions to setup/tear down a DPRC
> > > >>> - functions for allocating the pool of interrupts. In case of VFIO the
> > > >>> interrupts are not configured at probe time, but later by userspace
> > > >>> request
> > > >>>
> > > >>> v4 -> v5
> > > >>> - dprc_celanup should not fail
> > > >>>
> > > >>> v3 -> v4
> > > >>> - Rebased on the latest kernel.
> > > >>> - Exported a dprc_remove function
> > > >>>
> > > >>> v2 -> v3
> > > >>> - Add a new version for dprc_get_obj_region
> > > >>> - Export the cacheability bus specific bits defines
> > > >>>
> > > >>> v1 -> v2
> > > >>> - Remove driver_override propagation through various functions
> > > >>> - Cache the DPRC API version
> > > >>>
> > > >>> The patches are related with "vfio/fsl-mc: VFIO support for FSL-MC
> > > >>> devices" patches, but the series were split because they are targeting
> > > >>> different subsystems. However, the mc-bus patches may suffer changes
> > > >>> when addressing the VFIO review comments.
> > > >>>
> > > >>> The patches do not address the comment regarding moving driver_override
> > > >>> in the core code. I prefer not to tie these patches on that change and
> > > >>> address that separately.
> > > >>>
> > > >>> Bharat Bhushan (3):
> > > >>>   bus/fsl-mc: add support for 'driver_override' in the mc-bus
> > > >>>   bus/fsl-mc: Add dprc-reset-container support
> > > >>>   bus/fsl-mc: Extend ICID size from 16bit to 32bit
> > > >>>
> > > >>> Diana Craciun (10):
> > > >>>   bus/fsl-mc: Do no longer export the total number of irqs outside
> > > >>>     dprc_scan_objects
> > > >>>   bus/fsl-mc: Add a new parameter to dprc_scan_objects function
> > > >>>   bus/fsl-mc: Set the QMAN/BMAN region flags
> > > >>>   bus/fsl-mc: Cache the DPRC API version
> > > >>>   bus/fsl-mc: Export dprc_scan/dprc_remove functions to be used by
> > > >>>     multiple entities
> > > >>>   bus/fsl-mc: Export a cleanup function for DPRC
> > > >>>   bus/fsl-mc: Add a container setup function
> > > >>>   bus/fsl_mc: Do not rely on caller to provide non NULL mc_io
> > > >>>   bus/fsl-mc: Export IRQ pool handling functions to be used by VFIO
> > > >>>   bus/fsl-mc: Add a new version for dprc_get_obj_region command
> > > >>>
> > > >>>  drivers/bus/fsl-mc/dprc-driver.c      | 190 ++++++++++++++++----------
> > > >>>  drivers/bus/fsl-mc/dprc.c             | 141 +++++++++++++++----
> > > >>>  drivers/bus/fsl-mc/fsl-mc-allocator.c |  12 +-
> > > >>>  drivers/bus/fsl-mc/fsl-mc-bus.c       |  64 ++++++++-
> > > >>>  drivers/bus/fsl-mc/fsl-mc-private.h   |  31 ++---
> > > >>>  drivers/bus/fsl-mc/mc-io.c            |   7 +-
> > > >>>  include/linux/fsl/mc.h                |  41 +++++-
> > > >>>  7 files changed, 359 insertions(+), 127 deletions(-)
> > > >>>  
> > > >>
> > > >> For the series:
> > > >> Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > >> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>  
> > > > 
> > > > Do you want me to take these patches in my tree, or are they going to
> > > > Linus some other way?  
> > > 
> > > I'm prefectly fine with you picking up the patches through your tree.  
> > 
> > Great, now queued up.
> 
> Hi Greg,
> 
> Diana has a vfio bus driver for fsl-mc devices queued up in my tree as
> well.  After a linux-next build failure due to our branches being
> applied in the wrong order, Stephen advised that the proper way to
> handle this is to merge a shared branch with this series.  Do you have
> a pull request imminent with this series or if not, would you mind
> pushing such a branch?  Thanks,

This should all now be in Linus's tree, so I don't think you need any
shared branch anymore :)

thanks,

greg k-h