On Fri, Oct 25, 2019 at 12:10:49AM +0300, Dmitry Osipenko wrote: > 24.10.2019 21:15, Michał Mirosław пишет: > > On Thu, Oct 24, 2019 at 07:31:37PM +0200, Thierry Reding wrote: > >> From: Thierry Reding <treding@xxxxxxxxxx> > >> > >> The ->load() and ->unload() drivers are midlayers and should be avoided > >> in modern drivers. Fix this by moving the code into the driver ->probe() > >> and ->remove() implementations, respectively. > >> > >> v2: kick out conflicting framebuffers before initializing fbdev > >> > >> Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> > >> --- > >> Michał, Dmitry, > >> > >> do you guys have a way of testing that the removal of the conflicting > >> framebuffer actually works? > > [...] > > > > I might be able to check during the weekend. Is this patch alone enough > > for v5.3? > > I don't think it will apply cleanly on top of 5.3, but should work with > linux-next or by cherry-picking 9d5a54987265. I just noticed that I based this version on top of a local branch that will cause conflicts if you apply this to either 5.3 or linux-next. I'll resend this later rebased onto drm/tegra/for-next, so it should apply cleanly on at least linux-next. drm/tegra/for-next also contains this: commit 051172e8c1ceef8749f19faacc1d3bef65d20d8d Author: Thierry Reding <treding@xxxxxxxxxx> Date: Wed Sep 25 13:26:59 2019 +0200 drm/tegra: Fix ordering of cleanup code Commit Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after initialization") changed the initialization order of the IOMMU related bits but didn't update the cleanup path accordingly. This asymmetry can cause failures during error recovery. Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after initialization") Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> Reviewed-by: Dmitry Osipenko <digetx@xxxxxxxxx> Tested-by: Dmitry Osipenko <digetx@xxxxxxxxx> which will conflict with the ->load() and ->unload() removal patch. If for some reason you can't use linux-next, it shouldn't be terribly complicated to backport this to v5.3, though. Thierry
Attachment:
signature.asc
Description: PGP signature