linux-kernel - Re: [PATCH 4/4] drm/meson: convert to the new canvas module

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]

Message-ID: <CAHStOZ6v1CAJ-7UVo6V3H0Eu3cYd8x7xSAx33EbO6Eptj0vgdw@mail.gmail.com>
Date:   Thu, 2 Aug 2018 15:09:03 +0200
From:   Maxime Jourdan <maxi.jourdan@...adoo.fr>
To:     Jerome Brunet <jbrunet@...libre.com>
Cc:     Maxime Jourdan <maxi.jourdan@...adoo.fr>,
        Neil Armstrong <narmstrong@...libre.com>,
        Kevin Hilman <khilman@...libre.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-amlogic <linux-amlogic@...ts.infradead.org>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 4/4] drm/meson: convert to the new canvas module

2018-08-02 15:01 GMT+02:00 Jerome Brunet <jbrunet@...libre.com>:
> What I don't like is precisely that you need to expose this 'struct ops' to the
> consumer. I would prefer an API for this (it can be a 1:1 mapping). The canvas
> should remain some abstract object you get from DT.
>
> IMO, this is the same as a reset, a syscon or whatever other phandle you get
> from DT. The consumer should not have to 'care' how it works (how data are
> organized), it should just use it.
>
> Whatever you need to do to deal with your canvas phandle should (IMO) reside in
> your soc/amlogic/meson-canvas.c, and not be spread in the consumers.
>
>>
>> I agree that the "fetch the node" boilerplate code could be put behind
>> a helper, but at the same time this code helps remind the developer
>> that there needs to be a canvas node in the dts, and that it has to be
>> linked in your own device node.
>
> This is why we have a DT documentation.
>
> And, as far as I understand amlogic's display and decoder stuff, you won't get
> very far w/o a canvas, so 'the developer' will be reminded fairly quickly ;)
>
>>
>> I would like to keep it that way if that is okay with you.
>
> It's just my opinion, I'm not the one merging it ... :P
>
>

Fair enough, I'll see to API-ize the module in v2 :).