lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 27 Apr 2018 09:51:46 +0200
From:   Peter Rosin <>
To:     Andrzej Hajda <>,
Cc:     Archit Taneja <>,
        Laurent Pinchart <>,
        David Airlie <>,
        Martin Donnelly <>,
        Martyn Welch <>,
        Gustavo Padovan <>,
        Maarten Lankhorst <>,
        Sean Paul <>,
        Inki Dae <>,
        Joonyoung Shim <>,
        Seung-Woo Kim <>,
        Kyungmin Park <>,
        Kukjin Kim <>,
        Krzysztof Kozlowski <>,
        CK Hu <>,
        Philipp Zabel <>,
        Matthias Brugger <>,
        Rob Clark <>,
        Benjamin Gaignard <>,
        Vincent Abriou <>,
        Jyri Sarha <>,,,,,,,
Subject: Re: [PATCH 00/24] device link, bridge supplier <-> drm device

On 2018-04-27 09:37, Peter Rosin wrote:
> On 2018-04-27 09:11, Andrzej Hajda wrote:
>> Hi Peter,
>> On 27.04.2018 00:31, Peter Rosin wrote:
>>> Hi!
>>> It was noted by Russel King [1] that bridges (not using components)
>>> might disappear unexpectedly if the owner of the bridge was unbound.
>>> Jyri Sarha had previously noted the same thing with panels [2]. Jyri
>>> came up with using device links to resolve the panel issue, which
>>> was also my (independent) reaction to the note from Russel.
>>> This series builds up to the addition of that link in the last
>>> patch, but in my opinion the other 23 patches do have merit on their
>>> own.
>>> The last patch needs testing, while the others look trivial. That
>>> said, I might have missed some subtlety.
>> of_node is used as an identifier of the bridge in the kernel. If you
>> replace it with device pointer there will be potential problem with
>> devices having two or more bridges, how do you differentiate bridges if
>> the owner is the same? If I remember correctly current bridge code does
>> not allow to have multiple bridges in one device, but that should be
>> quite easy to fix if necessary. After this change it will become more
>> difficult.
> I don't see how it will be more difficult?
>> Anyway I remember discussion that in DT world bridge should be
>> identified rather by of_graph port node, not by parent node as it is
>> now. If you want to translate this relation to device owner, you should
>> add also port number to have full identification of the bridge, ie pair
>> (owner, port_number) would be equivalent of port node.
> You even state the trivial solution here, just add the port/endpoint ID
> when/if it is needed. So, what is the significant difference?

Or, since this is apparently a rare requirement, you could make the owners
that do need it fix it themselves. E.g. by embedding the struct drm_bridge
in another struct that contains the needed ID, and use container_of to get
to that containing struct with the ID.


Powered by blists - more mailing lists