| Message ID | 20231127051414.3783108-1-victor.liu@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/bridge: panel: Check device dependency before managing device link | expand |
On Mon, Nov 27, 2023 at 6:10 AM Liu Ying <victor.liu@nxp.com> wrote: > This series aims to check panel device dependency upon DRM device before > managing device link between them. It fixes eariler patches in v6.7-rc1 > which tried to manage the link. Without this series, the link fails to > be added for dependent panel devices and hence relevant panel bridges > fail to be attached. A real broken panel is "novatek,nt35510" defined > in arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts as reported by > Linus Walleij. > > Patch 1 exports device_is_dependent() to modules as needed by patch 2. > Patch 2 checks device dependency before managing the device link. > > Note that patch 2 is already in drm-misc/drm-misc-fixes and > drm-misc/for-linux-next-fixes. Patch 1 needs to be reviewed and picked up. > > v2: > * Introduce patch 1 to export device_is_dependent() to modules as needed by > patch 2. > > Liu Ying (2): > driver core: Export device_is_dependent() to modules > drm/bridge: panel: Check device dependency before managing device link I just applied patch 1 directly to the drm-misc-fixes so we don't have to revert and then re-apply patches, because that is a bigger evil. (We can't rebase these branches...) Yours, Linus Walleij
On Mon, Nov 27, 2023 at 05:03:53PM +0100, Linus Walleij wrote: > On Mon, Nov 27, 2023 at 6:10 AM Liu Ying <victor.liu@nxp.com> wrote: > > > This series aims to check panel device dependency upon DRM device before > > managing device link between them. It fixes eariler patches in v6.7-rc1 > > which tried to manage the link. Without this series, the link fails to > > be added for dependent panel devices and hence relevant panel bridges > > fail to be attached. A real broken panel is "novatek,nt35510" defined > > in arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts as reported by > > Linus Walleij. > > > > Patch 1 exports device_is_dependent() to modules as needed by patch 2. > > Patch 2 checks device dependency before managing the device link. > > > > Note that patch 2 is already in drm-misc/drm-misc-fixes and > > drm-misc/for-linux-next-fixes. Patch 1 needs to be reviewed and picked up. > > > > v2: > > * Introduce patch 1 to export device_is_dependent() to modules as needed by > > patch 2. > > > > Liu Ying (2): > > driver core: Export device_is_dependent() to modules > > drm/bridge: panel: Check device dependency before managing device link > > I just applied patch 1 directly to the drm-misc-fixes so we don't have to > revert and then re-apply patches, because that is a bigger evil. (We can't > rebase these branches...) Erm, you did wait for GKH or Rafael's ACK to do that, right? Maxime
On Mon, Nov 27, 2023 at 5:29 PM Maxime Ripard <mripard@kernel.org> wrote: > On Mon, Nov 27, 2023 at 05:03:53PM +0100, Linus Walleij wrote: > > > Liu Ying (2): > > > driver core: Export device_is_dependent() to modules > > > drm/bridge: panel: Check device dependency before managing device link > > > > I just applied patch 1 directly to the drm-misc-fixes so we don't have to > > revert and then re-apply patches, because that is a bigger evil. (We can't > > rebase these branches...) > > Erm, you did wait for GKH or Rafael's ACK to do that, right? No. It is a bigger evil to leave the tree broken than to enforce formal process, and it is pretty self-evident. If any of them get annoyed about it we can revert the patch, or both. Yours, Linus Walleij
Hi Linus, On Mon, Nov 27, 2023 at 11:13:31PM +0100, Linus Walleij wrote: > On Mon, Nov 27, 2023 at 5:29 PM Maxime Ripard <mripard@kernel.org> wrote: > > On Mon, Nov 27, 2023 at 05:03:53PM +0100, Linus Walleij wrote: > > > > > Liu Ying (2): > > > > driver core: Export device_is_dependent() to modules > > > > drm/bridge: panel: Check device dependency before managing device link > > > > > > I just applied patch 1 directly to the drm-misc-fixes so we don't have to > > > revert and then re-apply patches, because that is a bigger evil. (We can't > > > rebase these branches...) > > > > Erm, you did wait for GKH or Rafael's ACK to do that, right? > > No. > > It is a bigger evil to leave the tree broken than to enforce formal process, > and it is pretty self-evident. If any of them get annoyed about it we can > revert the patch, or both. Yeah, I definitely understand why you did it, but I don't think it's something we would encourage in drm-misc. We've discussed it with Sima yesterday, and I think we would even need the extra check in dim to make sure that a committer shouldn't do that without dim complaining. Sima played a bit with it, and it should be doable to get something fairly reliable if you use get_maintainers.pl to retrieve the git tree (through scripts/get_maintainer.pl --no-email --no-l --scm) and figuring out if only drm.git, drm-intel.git or drm-misc.git is involved. If it isn't, then we should check that there's the ack of one of the maintainers. Could you write a patch to do so? Thanks! Maxime
On Wed, Nov 29, 2023 at 1:32 PM Maxime Ripard <mripard@kernel.org> wrote: [Me] > > It is a bigger evil to leave the tree broken than to enforce formal process, > > and it is pretty self-evident. If any of them get annoyed about it we can > > revert the patch, or both. > > Yeah, I definitely understand why you did it, but I don't think it's > something we would encourage in drm-misc. Hm OK I guess, it can be debated but no point in debating it either. > We've discussed it with Sima yesterday, and I think we would even need > the extra check in dim to make sure that a committer shouldn't do that > without dim complaining. (...) > Sima played a bit with it, and it should be doable to get something > fairly reliable if you use get_maintainers.pl to retrieve the git tree > (through scripts/get_maintainer.pl --no-email --no-l --scm) and figuring > out if only drm.git, drm-intel.git or drm-misc.git is involved. > > If it isn't, then we should check that there's the ack of one of the > maintainers. So check for any code that is hitting namespaces outside drivers/gpu/* Documentation/gpu/* or include/[uapi/]drm/* that it is ACKed by the respective maintainer for that area of the kernel? > Could you write a patch to do so? Patch dim? Well my bash skills are a bit so-so. But I guess I could learn it. But did you say there is already a prototype? Yours, Linus Walleij
Hi Linus, On Wed, Nov 29, 2023 at 03:38:35PM +0100, Linus Walleij wrote: > On Wed, Nov 29, 2023 at 1:32 PM Maxime Ripard <mripard@kernel.org> wrote: > [Me] > > > It is a bigger evil to leave the tree broken than to enforce formal process, > > > and it is pretty self-evident. If any of them get annoyed about it we can > > > revert the patch, or both. > > > > Yeah, I definitely understand why you did it, but I don't think it's > > something we would encourage in drm-misc. > > Hm OK I guess, it can be debated but no point in debating it either. > > > We've discussed it with Sima yesterday, and I think we would even need > > the extra check in dim to make sure that a committer shouldn't do that > > without dim complaining. > (...) > > Sima played a bit with it, and it should be doable to get something > > fairly reliable if you use get_maintainers.pl to retrieve the git tree > > (through scripts/get_maintainer.pl --no-email --no-l --scm) and figuring > > out if only drm.git, drm-intel.git or drm-misc.git is involved. > > > > If it isn't, then we should check that there's the ack of one of the > > maintainers. > > So check for any code that is hitting namespaces outside drivers/gpu/* > Documentation/gpu/* or include/[uapi/]drm/* that it is ACKed by the respective > maintainer for that area of the kernel? We can have something more reliable if we just check the git tree listed in MAINTAINERS (and returned by get_maintainers --scm). That way we don't have to whitelist anything, and it will always by in sync with MAINTAINERS. And if it's not one of drm trees, then it requires an ack from someone else get_maintainers will also tell you about. > > Could you write a patch to do so? > > Patch dim? Well my bash skills are a bit so-so. But I guess I could > learn it. But did you say there is already a prototype? My shell skills are also fairly limited, so we just discussed the solution but didn't do a prototype yet :) Maxime