On Mon, Jul 22, 2019 at 8:46 AM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > 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. Having copies of driver specific uapi headers is rather common, and you won't have much success trying to get everyone to change that. The reasons why those applications do it are: - The kernel already gives ABI guarantees so anything built with an old header file is expected to keep working indefinitely. - Using a new header file won't help unless the application also knows about the added interfaces - If an application uses more recent additions to the kernel headers, it either has to have a matching version of that header, or use a long series of #ifdef checks to deal with arbitrary versions. > > 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. The case that we are interested in is drivers that previously used platform data in legacy board files that have since been replaced with dtb based boots. > 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). It's been done before, but usually with overlays that don't necessarily make it any better than platform data. If you have a set of drivers where one of them creates a platform device for the other driver, then platform data is usually the easiest way, and I'm not aware of any move to get rid of that. As an alternative, you can use the generalized property support from include/linux/property.h that works on top of DT, ACPI or plain platform devices. Arnd
