On Monday 22 February 2016 17:36:36 Rob Clark wrote:
On Mon, Feb 22, 2016 at 4:08 PM, Arnd Bergmann arnd@arndb.de wrote:
I saw some regressions on today's Linux-next kernel after the Makefiles got reworked and tried to come up with a quick fix. This ended up taking much longer, but the new version should be cleaner and I no longer get any build errors in this driver.
fyi, for the time being, I've already kicked out the kconfig/makefile splitup patches..
I'll go ahead and pull in the hdmi symbol rename patch, since that is a sane thing to do.
Ok, thanks
I'm less sure about splitting things up into separate .ko's.
I think it's generally a good idea to split it up like that, though it could be taken a little further. Having one .ko file per platform_driver seems to be a very sensible split here, the main advantage being that you enforce a strict layering between the subdrivers.
And I think having the .ko name not match the drm driver name (ie. what is passed in to drmOpen() in userspace) would cause issues since libdrm could try to modprobe $drivername.ko. (I *think* that only matters in the non-udev case? Which is at least not a common case, but breaking userspace is breaking userspace...)
Ah, I see. Yes, that is unfortunate, but patch 2 then definitely has to be dropped even if you decide to take the others.
With udev, the autoloading purely depends on the MODULE_DEVICE_TABLE in the top module, which should work fine, and without patch 2, all the other drivers get loaded automatically when the main driver gets probed.
Arnd