Re: [git pull] drm for v4.11 - main pull request
Hi Linus, Yeah this went wrong. My experience with anything Kconfig (whether new drivers or anything else) is that it takes 0day a few days to 1-2 weeks to crunch through all the combos. I guess we could block new drivers pulls like we already do with regular feature pulls in drm (e.g. drm-intel.git cuts out around -rc5/6-ish, drm-misc.git works similar), but delaying new drivers isn't that great. On Thu, Feb 23, 2017 at 05:44:04PM -0800, Linus Torvalds wrote: > [snip] Don't shit on (new) contributors like this. Noralf has done good work (go look), Kconfig is an impossible combinatorial maze, and I'd be rather annoyed if you managed to drive away Noralf (and other contributors) with your mail. I know that you need to rage every once in a while, but at least only send those mails to Dave (and me) in private. On dri-devel here, this isn't accepted. We'll discuss late driver pull requests and what to with them in drm in the future more after -rc1, after the heat has dissipated. Yours, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [git pull] drm for v4.11 - main pull request
On Thu, Feb 23, 2017 at 5:44 PM, Linus Torvalds wrote: > > AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED > YESTERDAY? .. and a slightly less annoying piece of crap in this pull request: that "PRIME_NUMBERS" config thing is utter garbage too. Why would you ask a user about it? The only valid use is for a kernel module that needs it to "select" it, so there's no point in asking the user if they want it. We don't want to make the kernel config phase any worse than it already is (and it's bad). Asking people idiotic and pointless questions is simply not ok. Christ. I dislike this pull request intensely, and I haven't even gotten to the point where I can even _test_ it yet. I'm very close to just saying "this is complete bullshit" and not pull any DRM crap this merge window. Honestly, if I find anything else, that's what I'll do. I might do it even without finding anything elze. And _reghardless_ of what happens this merge window, I will instate a hard rule that the DRM code needs to be in linux-next *before* the merge window opens. No last-minute crap. No shit that hasn't even been build-tested. Because I am _never_ going to accept this kind of crap in the future. If I find broken stuff like this from just a cursory examination and build test, things are seriously wrong. I think I'm also going to require the DRM pull requests to be split up, because as it is now, I'm in the situation that I have to accept all or nothing. Which is not good, when the "all" stuff is of this dubious quality. And if the DRM "maintenance" is about sending me random half-arsed crap in one big pull, I'm just not willing to deal with it. This is like the crazy ARM tree used to be. Guys, this needs to be fixed. Linus
Re: [git pull] drm for v4.11 - main pull request
On Thu, Feb 23, 2017 at 4:01 PM, Dave Airlie wrote:
>
> This is the main drm pull request for v4.11.
>
> Nothing too major, the tinydrm and mmu-less support should make writing
> smaller drivers easier for some of the simpler platforms, and there are
> a bunch of documentation updates.
The tinydrm code seems like absolute pure shit that has never seen a compiler.
I'm upset, because I expect better quality control. In fact, I expect
*some* qualitty control, and this piece-of-shit driver has clearly
seen none at all.
And those patches were apparently committed yesterday.
WHAT THE ACTUAL FUCK?
I get tons and tons of lines of warnings:
drivers/gpu/drm/tinydrm/mipi-dbi.c: In function ‘mipi_dbi_typec1_command’:
drivers/gpu/drm/tinydrm/mipi-dbi.c:65:20: warning: field width
specifier ‘*’ expects argument of type ‘int’, but argument 5 has type
‘size_t {aka long unsigned int}’ [-Wformat=]
DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, len, data); \
with nasty chains of nested defines, but then I also get actual compile failures
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:198:26: error:
redefinition of ‘tinydrm_of_find_backlight’
struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
^
In file included from drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:11:0:
./include/drm/tinydrm/tinydrm-helpers.h:53:1: note: previous
definition of ‘tinydrm_of_find_backlight’ was here
tinydrm_of_find_backlight(struct device *dev)
^
(with similar stuff for tinydrm_disable_backlight()).
It looks like it might compile if CONFIG_BACKLIGHT_CLASS_DEVICE was
enabled rather than being a module.
Doing this:
-#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
in tinydrm-helpers.h gets rid of the complete build failure, and only
leaves the tens of lines of warnings.
How the hell did this get to the point where crap like this is even
sent to me? Nobody tested *anything*?
AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED YESTERDAY?
Linus
