archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <>
To: Randy Dunlap <>
Cc:, LKML <>,
	Mark Brown <>,
Subject: Re: linux-next: Tree for Oct 21 (panel-simple.c)
Date: Tue, 22 Oct 2013 10:10:20 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Mon, Oct 21, 2013 at 04:20:02PM -0700, Randy Dunlap wrote:
> On 10/21/13 08:36, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://
> > 
> > A next-20131021 tag is also provided for convenience.
> > 
> > Gained a couple new conflicts, loads of build failures. I've tried to
> > fix the most obvious ones, but as a downside haven't gotten around to
> > write up the specifics about the conflicts. I might still do that
> > tomorrow, but I figured most people wouldn't have time to look into
> > those anyway given that they'll be busy with the conferences.
> on i386:
> drivers/built-in.o: In function `panel_simple_probe':
> panel-simple.c:(.text+0x3c7ca): undefined reference to `of_find_backlight_by_node'

Hi Randy,

Thanks for running this. I'll come up with a patch to fix this, since I
originally wrote of_find_backlight_by_node().

Running the randconfig that you provided yielded some other interesting
warnings, though. There are a few occurrences where gcc compiles about
functions not returning a value, which is caused by people assuming that
BUG() never returns. But it happens that your randconfig also unsets
CONFIG_BUG, which turns BUG into a no-op and therefore causing gcc to
rightfully complain.

Before attempting to fix these, I was wondering whether that would be
considered useful. I personally think that we should eliminate warnings
as much as possible because it helps filtering out genuine problems. But
the BUG Kconfig option also depends on EXPERT, so I guess it's usually
not even visible and possibly not worth bothering about.


[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-10-22  8:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 15:36 linux-next: Tree for Oct 21 Thierry Reding
2013-10-21 23:20 ` linux-next: Tree for Oct 21 (panel-simple.c) Randy Dunlap
2013-10-22  8:10   ` Thierry Reding [this message]
2013-10-22  0:58 ` linux-next: Tree for Oct 21 (sound/pci/hda/patch_hdmi.c) Randy Dunlap
2013-10-22  7:42   ` Takashi Iwai
2013-10-22 15:10 ` linux-next: manual merge of the net-next tree Thierry Reding
2013-10-22 15:10   ` linux-next: manual merge of the wireless-next tree Thierry Reding
2013-10-22 15:10   ` linux-next: manual merge of the drm tree Thierry Reding
2013-10-22 15:10   ` linux-next: manual merge of the arm-soc tree Thierry Reding
2013-10-23 12:19     ` Tony Lindgren
2013-10-22 15:10   ` linux-next: manual merge of the mvebu tree Thierry Reding
2013-10-23  8:59     ` Jason Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).