Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1405584 > unrolled thread

Re: [git pull] drm for v4.7

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [git pull] drm for v4.7 Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-23 21:10 +0200
    Re: [git pull] drm for v4.7 Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-23 21:20 +0200
      Re: [git pull] drm for v4.7 Stephen Rothwell <sfr@canb.auug.org.au> - 2016-05-25 04:10 +0200
        Re: [git pull] drm for v4.7 Jani Nikula <jani.nikula@linux.intel.com> - 2016-05-25 10:30 +0200
          Re: [git pull] drm for v4.7 Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-25 18:20 +0200
            Re: [git pull] drm for v4.7 Emil Velikov <emil.l.velikov@gmail.com> - 2016-05-25 18:50 +0200
    Re: [git pull] drm for v4.7 Dave Airlie <airlied@gmail.com> - 2016-05-23 21:30 +0200
      Re: [git pull] drm for v4.7 Dave Airlie <airlied@gmail.com> - 2016-05-23 22:00 +0200

#1405584 — Re: [git pull] drm for v4.7

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> Here's the main drm pull request for 4.7, it's been
> a busy one, and I've been a bit more distracted in
> real life this merge window.

Hmm.

I pulled this, but I think I'll have to unpull again.

Neither the diffstat not the shortlog match what you sent me. There's
four extra commits at the top that aren't mentioned:

  Dave Airlie (3):
      drm/edid: move displayid tiled block parsing into separate function.
      drm/edid: move displayid validation to it's own function.
      drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)

  Tomas Bzatek (1):
      drm/displayid: Iterate over all DisplayID blocks

was that intentional? What happened? Are those commits meant to be
merged, or are they wrong? They _look_ ok, but dammit, according to
your message they shouldn't be there.

I'll test this out and look what happens, but I hate getting different
results than what I'm told to expect.

This is one reason I much prefer getting explicit tags rather than a
random branch. Did you update the branch on purpose and wanted me to
get the new state, or did you update the branch just because you
happened to do development on that branch and pushed it out? With an
explicit tag, there's a much more _intentional_ "push this to Linus"
thing going on, and it's less ambiguous in cases like this.

                 Linus

[toc] | [next] | [standalone]

#1405586

On Mon, May 23, 2016 at 11:59 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'll test this out and look what happens, but I hate getting different
> results than what I'm told to expect.

Hmm. I also get a lot of

  ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference
function or variable defined in the kernel
  ./usr/include/drm/drm.h:63: userspace cannot reference function or
variable defined in the kernel
  ./usr/include/drm/drm.h:699: userspace cannot reference function or
variable defined in the kernel
  ...

warnings with my allmodconfig build. They do seem to be due to
checkpatch not really grokking the

  #if defined(__cplusplus)
  extern "C" {
  #endif

and thinking that's a sign of a kernel function or variable
declaration being exported to user space, but it's a bit annoying.

Is there a patch pending for this that I'm not aware of, or is it just
that nobody but me hates spurious warnings? Didn't this show up in
linux-next? And if it _did_ show up in linux-next, why was the pull
request not talking about it?

                 Linus

[toc] | [prev] | [next] | [standalone]

#1406557

Hi Linus,

On Mon, 23 May 2016 12:10:25 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Is there a patch pending for this that I'm not aware of, or is it just
> that nobody but me hates spurious warnings? Didn't this show up in
> linux-next? And if it _did_ show up in linux-next, why was the pull
> request not talking about it?

My bad.  That warning turned up in linux-next last Wednesday but I
didn't notice (I have other stuff to do and don't carefully watch all
the builds all day - and there are quite a few warnings to filter new
ones out out of).  Maybe I need some automated way to flag new warnings.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1406740

On Wed, 25 May 2016, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> My bad.  That warning turned up in linux-next last Wednesday but I
> didn't notice (I have other stuff to do and don't carefully watch all
> the builds all day - and there are quite a few warnings to filter new
> ones out out of).  Maybe I need some automated way to flag new warnings.

There may be better ones out there, but Artem's "aiaiai" has some
helpers [1] for diffing build logs, if you want something simple to
integrate into existing scripts.

BR,
Jani.


[1] http://git.infradead.org/users/dedekind/aiaiai.git/tree/HEAD:/helpers


-- 
Jani Nikula, Intel Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1407047

On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
>
> There may be better ones out there, but Artem's "aiaiai" has some
> helpers [1] for diffing build logs, if you want something simple to
> integrate into existing scripts.

It would be lovely to have some kind of warning detection, but quite
frankly, just doing a build and counting lines in 'stderr' from the
build and having some trigger for "oops, lots of new lines" would be
sufficient.

So I don't think anything really fancy to diff build logs is
necessarily needed, although the people who then get the report about
"your merge causes lots of new warnings" might appreciate it.

                Linus

[toc] | [prev] | [next] | [standalone]

#1407067

On 25 May 2016 at 17:13, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
>>
>> There may be better ones out there, but Artem's "aiaiai" has some
>> helpers [1] for diffing build logs, if you want something simple to
>> integrate into existing scripts.
>
> It would be lovely to have some kind of warning detection, but quite
> frankly, just doing a build and counting lines in 'stderr' from the
> build and having some trigger for "oops, lots of new lines" would be
> sufficient.
>
> So I don't think anything really fancy to diff build logs is
> necessarily needed, although the people who then get the report about
> "your merge causes lots of new warnings" might appreciate it.
>
The Intel 0-Day already checks when patch introduces new warnings,
emailing the author and subsystem with the details. In this particular
case, the patch was out the next day and I was silly enough not to ask
Dave to include it in the same pull request.

Regards,
Emil

[toc] | [prev] | [next] | [standalone]

#1405589

On 24 May 2016 at 04:59, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie <airlied@linux.ie> wrote:
>>
>> Here's the main drm pull request for 4.7, it's been
>> a busy one, and I've been a bit more distracted in
>> real life this merge window.
>
> Hmm.
>
> I pulled this, but I think I'll have to unpull again.
>
> Neither the diffstat not the shortlog match what you sent me. There's
> four extra commits at the top that aren't mentioned:
>
>   Dave Airlie (3):
>       drm/edid: move displayid tiled block parsing into separate function.
>       drm/edid: move displayid validation to it's own function.
>       drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>
>   Tomas Bzatek (1):
>       drm/displayid: Iterate over all DisplayID blocks
>
> was that intentional? What happened? Are those commits meant to be
> merged, or are they wrong? They _look_ ok, but dammit, according to
> your message they shouldn't be there.

Okay they are meant to be in there, I just had them on my merge list,
remembered I hadn't merged them, but had generated a pull request earlier
to edit for you and forgot to regenerate it. I'll follow up with a new
pull request
if you like just to keep things straight.

The "extern C" warnings were one of the patches Arnd sent, I'll follow up with
those today.
>
>
> This is one reason I much prefer getting explicit tags rather than a
> random branch. Did you update the branch on purpose and wanted me to
> get the new state, or did you update the branch just because you
> happened to do development on that branch and pushed it out? With an
> explicit tag, there's a much more _intentional_ "push this to Linus"
> thing going on, and it's less ambiguous in cases like this.

I'll try and do explicit tags from now on, it should stop me doing
stupid things as well.

Dave.

[toc] | [prev] | [next] | [standalone]

#1405599

On 24 May 2016 at 05:23, Dave Airlie <airlied@gmail.com> wrote:
> On 24 May 2016 at 05:20, Dave Airlie <airlied@gmail.com> wrote:
>> On 24 May 2016 at 04:59, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie <airlied@linux.ie> wrote:
>>>>
>>>> Here's the main drm pull request for 4.7, it's been
>>>> a busy one, and I've been a bit more distracted in
>>>> real life this merge window.
>>>
>>> Hmm.
>>>
>>> I pulled this, but I think I'll have to unpull again.
>>>
>>> Neither the diffstat not the shortlog match what you sent me. There's
>>> four extra commits at the top that aren't mentioned:
>>>
>>>   Dave Airlie (3):
>>>       drm/edid: move displayid tiled block parsing into separate function.
>>>       drm/edid: move displayid validation to it's own function.
>>>       drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>>>
>>>   Tomas Bzatek (1):
>>>       drm/displayid: Iterate over all DisplayID blocks
>>>
>>> was that intentional? What happened? Are those commits meant to be
>>> merged, or are they wrong? They _look_ ok, but dammit, according to
>>> your message they shouldn't be there.
>>
>> Okay they are meant to be in there, I just had them on my merge list,
>> remembered I hadn't merged them, but had generated a pull request earlier
>> to edit for you and forgot to regenerate it. I'll follow up with a new
>> pull request
>> if you like just to keep things straight.
>>
>> The "extern C" warnings were one of the patches Arnd sent, I'll follow up with
>> those today.

FYI:
https://patchwork.freedesktop.org/patch/87900/

is a link to Arnd's patch.

Dave.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web