Messages in this thread | | | Date | Thu, 15 Oct 2020 19:27:06 +0200 | From | Greg KH <> | Subject | Re: [PATCH v5 00/13] bus/fsl-mc: Extend mc-bus driver functionalities in preparation for mc-bus VFIO support |
| |
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
| |