linux-kernel - Re: [Question] orphan platform data header

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: <21af683a-a188-7aa9-9c82-98c02b8717f8@metux.net>
Date:   Mon, 22 Jul 2019 08:46:16 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Arnd Bergmann <arnd@...db.de>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Ben Dooks <ben.dooks@...ethink.co.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        DTML <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Question] orphan platform data header

On 21.07.19 16:15, Arnd Bergmann wrote:

> That is different: the hardware attaches to a serial port and may well
> be usable, and the user space side just contains a copy of the header,
> see https://github.com/nwdigitalradio/ax25-tools/tree/master/yamdrv

I believe that such header copies in userland applications are
conceptionally wrong. Whenever something changes, both sides need
to be kept in sync.

Maybe we should talk to the hamradio folks to get this cleaned up.
IMHO, this header should go to uapi.

> It seems more useful to keep looking for drivers with a platform_data
> header file that is no longer included by any platform for candidates
> that may be obsolete.

Some folks see platform_data old legacy that should be removed, but I
don't aggree. For example w/ apu2 board driver (and corresponding
amd-fch-gpio driver) I even had to introduce a pdata struct, so the
board driver could configure the gpio driver. Certainly, I would have
preferred doing everything via DT, but that's not available on x86/acpi
targets (if anybody knows a way to inject a DT snippet just for one
driver in such a scenario, please let me know).

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287