linux-kernel - Re: [PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation

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] [day] [month] [year] [list]

Message-ID: <CAHtQpK5wPpJOni9PtNB47KCCvGf=aGkBjF7RvHWoF_Duvkri7w@mail.gmail.com>
Date:   Fri, 8 Dec 2017 13:52:13 +0100
From:   Andrey Zhizhikin <andrey.z@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>, mark.rutland@....com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation

Hello Rob,

Thanks for your reply here!

>
> No. See prior discussions:
>
> https://lkml.org/lkml/2016/5/18/457
> https://lkml.org/lkml/2017/10/8/238

Just for my clarify; to understand how to move on with the patch:
Since UIO is not considered as a real HW and rather a aggregate, which
could be used for to wrap virtually any HW block - does that mean no
new dt-bindings would be accepted to it?

I agree it is really hard (and practically impossible) to create
compatible strings for all HW units potentially using UIO as a
container, therefore I can see clearly arguments here.

But if considered from a driver perspective: there is already DT
awareness in the UIO driver (specifically the pdrv-genirq), and we
have a "HW-like" functionality (irq handler, iomem and ioreg regions)
which could be covered by the DT bindings. What if those "generic"
properties that covers only those pieces of the UIO driver code could
be assigned corresponding dt-bindings? I believe it is not the best
and rather contradictory approach to not have any "compatible" string,
but as long as those driver parameters are covered by DT properties,
isn't it OK to have them?

I can assume a lot of people are using UIO in exactly this way:
defining a node in their DTS, assigning "compatible" via kernel
command line and having devnode instantiated. Why can't a possibility
be provided to them to have a generic description of how they can
configure, tweak and use their UIO drivers in the correct and
efficient way? This is especially true for people that are using FPGAs
and enveloping their Soft-IPs with UIO to have a generic
status/control capabilities. I cannot imagine how this tremendous
amount of variations could be easily accommodated inside UIO
compatible names...

Or am I completely missing a point here?

-- 
Regards,
Andrey.