Re: [git pull] drm for v4.11 - main pull request

2017-02-24 Thread Daniel Vetter
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

2017-02-24 Thread Daniel Vetter
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

2017-02-23 Thread Linus Torvalds
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

2017-02-23 Thread Linus Torvalds
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

2017-02-23 Thread Linus Torvalds
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


Re: [git pull] drm for v4.11 - main pull request

2017-02-23 Thread Linus Torvalds
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