On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote: > On 5/22/20 9:55 AM, Jason Gunthorpe wrote: > > Maybe not great, but at least it is consistent with all the lifetime > > models and the operation of the driver core. > I agree your comments are valid ones, I just don't have a solution to be > fully compliant with these models and report failures of the driver probe > for a child device due to configuration issues (bad audio topology, etc). > My understanding is that errors on probe are explicitly not handled in the > driver core, see e.g. comments such as: It's just not an error for a child device to not instantiate, we don't even know if the driver is loaded yet. The parent really should not care if the child is there or not. > > > PCI device creates an audio card represented as a platform device. When the > > > card registration fails, typically due to configuration issues, the PCI > > > probe still completes. That's really confusing and the source of lots of > > > support questions. If we use these virtual bus extensions to stpo abusing > > > platform devices, it'd be really nice to make those unreported probe > > > failures go away. > > I think you need to address this in some other way that is hot plug > > safe. > > Surely you can make this failure visible to users in some other way? > Not at the moment, no. there are no failures reported in dmesg, and the user > does not see any card created. This is a silent error. If we're failing to do something we should report it. This includes deferred probe failures.
Attachment:
signature.asc
Description: PGP signature
