On 10/24/26 1:19 AM, Dmitry Baryshkov wrote: > A failed priv->kms_init() or ->hw_init() is cleaned up by the ->destroy() > callback, which makes ->destroy() responsible for tearing down a KMS in > any state between "not initialised at all" and "fully initialised". The > kernel convention is the opposite: a function which fails undoes its own > steps, and the teardown only ever sees a fully set up object. > > Let the kms drivers switch to that convention one at a time: skip > ->destroy() after a failed kms_init() of a driver which sets > init_unwinds, and let the drivers fold their hardware setup into > kms_init() and drop ->hw_init(). Set up the mode config before calling > kms_init(), so that it is already in place for the hardware setup. > > While at it, tear the snapshot worker down after the KMS, in the reverse > order of its setup. Nothing queues a snapshot until msm_drm_kms_init() > has succeeded, so no dump can be pending when the KMS goes away.
LLM: msm_kms_init_vm() arms the IOMMU fault handler inside kms_init, and that handler queues dump_work, so a fault during init can queue a dump. The patch then tears down the KMS before the snapshot worker. kthread_destroy_worker() flushes queued work, so the pending dump would run against a destroyed KMS. The original order, snapshot first, avoids that. Unbind (msm_drm_kms_uninit()) keeps the original order, so the two paths now disagree. Konrad: I don't think it's entirely unreasonable to get a iommu error halfway through init Konrad
