Date:   Wed, 1 Feb 2023 14:04:41 +0100
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc:     linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        ioana.ciornei@nxp.com
Subject: Re: [PATCH] bus: fsl-mc: don't assume child devices are all fsl-mc
 devices
Message-ID: <Y9pjaQVOda8tY/Qt@kroah.com>
References: <20230127131636.20889-1-laurentiu.tudor@nxp.com>
 <Y9kB8F3Nls8d1Koi@kroah.com>
 <d6297aae-7f9e-1b4e-d2f3-da5664804ab0@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d6297aae-7f9e-1b4e-d2f3-da5664804ab0@nxp.com>
Precedence: bulk

On Wed, Feb 01, 2023 at 01:50:11PM +0200, Laurentiu Tudor wrote:
> Hi Greg,
> 
> On 1/31/2023 1:56 PM, Greg KH wrote:
> > On Fri, Jan 27, 2023 at 03:16:36PM +0200, laurentiu.tudor@nxp.com wrote:
> > > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > 
> > > Changes in VFIO caused a pseudo-device to be created as child of
> > > fsl-mc devices causing a crash [1] when trying to bind a fsl-mc
> > > device to VFIO. Fix this by checking the device type when enumerating
> > > fsl-mc child devices.
> > 
> > What changes?  What commit id does this fix?  Does it need to be
> > backported?
> 
> There were a lot of changes in the VFIO area but I'd point at this commit
> [1].
> 
> I'll resend the patch with a "Fixes:" tag pointing at this commit if that's
> ok with you.

Please do.

> > And what type of "pseudo device" is being created? Why would it be
> > passed to this driver if it's the wrong type?
> 
> It's not passed to the driver per-se. The problem shows up when the
> implementation of the driver does a device_for_each_child() [2] and the
> callback blindly assumes that all enumerated children devices are fsl-mc
> devices. The patch just adds a check for this case.

Ah, that makes more sense, sorry for the noise.

greg k-h