lists.openwall.net   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  linux-cve-announce  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:   Tue, 28 May 2019 09:53:23 +0200
From:   Dariusz Marcinkiewicz <darekm@...gle.com>
To:     Hans Verkuil <hverkuil@...all.nl>
Cc:     linux-media@...r.kernel.org, hans.verkuil@...co.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/3] media: cec: expose HDMI connector to CEC dev mapping

On Fri, May 24, 2019 at 11:21 AM Hans Verkuil <hverkuil@...all.nl> wrote:
>
> Hi Dariusz,
>
> I did some more testing with the Khadas VIM2 and found another problem,
> something that will, unfortunately, require some redesign.
>
...
>
> The other problem is in the CEC driver: it creates the CEC device as
> soon as the HDMI device is found (cec_notifier_parse_hdmi_phandle).
>
> But that doesn't mean that the HDMI device also had registered itself
> as a CEC notifier.
>
> Until now that never mattered: as long as the HDMI device was found
> the CEC adapter would function fine, it would just have no physical
> address until so notified by the HDMI device once it registered its
> CEC notifier.
>
> But if we want to have valid connector info during the lifetime of
> the CEC adapter, then this no longer works.
>
> I'm not entirely sure how to handle this.
>
> Another issue here is that when the HDMI driver removes the notifier,
> then it should also zero the connector info. Remember that both the
> HDMI and the CEC drivers can be loaded and unloaded independently from
> one another.
>
Given all of the above, what do you think about coming back to the v1
of the patch, where a connector info could be set on an adapter at any
time and an event was used to notify userland when that happened? That
approach seems to cover all the scenarios mentioned above.

Thank you for testing the patches!

Best regards.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ