Hi Doug
On 6/13/2023 12:33 PM, Doug Anderson wrote:
Hi,
On Mon, Jun 12, 2023 at 3:40 PM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
On 13/06/2023 01:01, Bjorn Andersson wrote:
Using devres to depopulate the aux bus made sure that upon a probe
deferral the EDP panel device would be destroyed and recreated upon next
attempt.
But the struct device which the devres is tied to is the DPUs
(drm_dev->dev), which may be happen after the DP controller is torn
down.
Indications of this can be seen in the commonly seen EDID-hexdump full
of zeros in the log, or the occasional/rare KASAN fault where the
panel's attempt to read the EDID information causes a use after free on
DP resources.
It's tempting to move the devres to the DP controller's struct device,
but the resources used by the device(s) on the aux bus are explicitly
torn down in the error path.
I hoped that proper usage of of_dp_aux_populate_bus(), with the callback
function being non-NULL would have solved at least this part. But it
seems I'll never see this patch.
Agreed. This has been pending for > 1 year now with no significant
progress. Abhinav: Is there anything that can be done about this? Not
following up on agreed-to cleanups in a timely manner doesn't set a
good precedent. Next time the Qualcomm display wants to land something
and promises to land a followup people will be less likely to believe
them...
Both QC and Google know there were other factors which delayed this last
3-4 months.
But, I do not have any concrete justification to give you for the delays
before that apart from perhaps other higher priority chrome and upstream
bugs which kept cropping up.
Hence, all I can offer is my apologies for the delay.
After seeing this patch on the list, we have revived this effort now and
re-assigned this within our team to take over from where that was left
off. It will need some time to transition but this will see the end of
the tunnel soon.
Thanks
Abhinav
