On Monday 22 February 2016 17:36:36 Rob Clark wrote: > On Mon, Feb 22, 2016 at 4:08 PM, Arnd Bergmann <arnd@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
