gmane.linux.kernel.next

Re: linux-next: triage for April 19, 2012

Geert Uytterhoeven — 2012-05-26T09:39:06

Hi Paul,

On Sat, May 26, 2012 at 12:08 AM, Paul Gortmaker
<paul.gortmaker< at >windriver.com> wrote:

I saw it. But it doesn't contain a fix for this, does it?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert< at >linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: triage for April 19, 2012

Paul Gortmaker — 2012-05-25T22:08:09

See also this thread:

http://www.spinics.net/lists/kvm/msg72785.html

Paul.

Re: linux-next: triage for April 19, 2012

Geert Uytterhoeven — 2012-05-25T20:59:10

On Fri, Apr 20, 2012 at 4:00 AM, Paul Gortmaker
<paul.gortmaker< at >windriver.com> wrote:

Not only parisc.

This breakage has now entered mainline:

parisc deconfig http://kisskb.ellerman.id.au/kisskb/buildresult/6365677/
m68k allmodconfig: http://kisskb.ellerman.id.au/kisskb/buildresult/6365681/

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert< at >linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

linux-next: no tree today

Stephen Rothwell — 2012-05-25T05:45:48

Sorry about that.  The next tree will probably be Monday (my time).

linux-next: usual request

Stephen Rothwell — 2012-05-24T22:20:43

Hi all,

Please do not add anything to your linux-next included trees that is
intended for v3.6 until after v3.5-rc1 is released.

Re: [PATCH] hwmon/sch56xx: Depend on watchdog for watchdog core functions

Wim Van Sebroeck — 2012-05-24T20:54:27

Hi Hans,


I added also the "select WATCHDOG_CORE" lines for both drivers.
In linux-watchdog-next now.

Kind regards,
Wim.

[PATCH] hwmon/sch56xx: Depend on watchdog for watchdog core functions

Hans de Goede — 2012-05-24T20:18:58

Since the watchdog code in sch56xx-common now uses the watchdog core, the
Kconfig entires for the sch5627 and sch5636 should depend on WATCHDOG
being set.

Signed-off-by: Hans de Goede <hdegoede< at >redhat.com>
---
 drivers/hwmon/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 8deedc1..3d16d66 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
< at >< at > -1036,7 +1036,7 < at >< at > config SENSORS_SCH56XX_COMMON
 
 config SENSORS_SCH5627
 tristate "SMSC SCH5627"
-depends on !PPC
+depends on !PPC && WATCHDOG
 select SENSORS_SCH56XX_COMMON
 help
   If you say yes here you get support for the hardware monitoring
< at >< at > -1048,7 +1048,7 < at >< at > config SENSORS_SCH5627
 
 config SENSORS_SCH5636
 tristate "SMSC SCH5636"
-depends on !PPC
+depends on !PPC && WATCHDOG
 select SENSORS_SCH56XX_COMMON
 help
   SMSC SCH5636 Super I/O chips include an embedded microcontroller for

Re: linux-next: Tree for May 24 (hwmon/sch56xx)

Hans de Goede — 2012-05-24T20:15:32

Hi,

On 05/24/2012 08:08 PM, Randy Dunlap wrote:

Thanks for catching this, I'll send a patch to linux-watchdog + linux-next
fixing this.

Regards,

Hans

Re: linux-next: Tree for May 24 (hwmon/sch56xx)

Randy Dunlap — 2012-05-24T18:08:21





when CONFIG_WATCHDOG is not enabled:

drivers/built-in.o: In function `sch56xx_watchdog_register':
(.text+0x50711c): undefined reference to `watchdog_register_device'
drivers/built-in.o: In function `sch56xx_watchdog_unregister':
(.text+0x507171): undefined reference to `watchdog_unregister_device'

or when SCH56XX_COMMON=m:

ERROR: "watchdog_unregister_device" [drivers/hwmon/sch56xx-common.ko] undefined!
ERROR: "watchdog_register_device" [drivers/hwmon/sch56xx-common.ko] undefined!

Re: linux-next: build failure after merge of the final tree

H. Peter Anvin — 2012-05-24T14:06:03

Apparently so... this is troublesome because it means that we have
silently built broken kernels not just with ld 2.22.52.0.x but with
older lds as well.

What originally made the ld problems surface was actually checking that
we didn't run into any absolute symbols we didn't know about, which
previously was supposed to be done by developers manually, i.e. never
done.  This is extremely serious because it means that a kernel compiled
with CONFIG_RELOCATABLE doesn't actually relocate.

The workaround -- and it is a workaround -- is to take these symbols as
they appear and add them to the [S_REL] whitelist in
arch/x86/tools/relocs.c.  This is the same workaround as existed before,
the only difference is that we are now enforcing it.

A patch for this particular subcase is attached and I will commit it to
tip:x86/urgent.



jiffies is yet another symbol created by the linker script.  This one in
particular is created outside any section, so it isn't all that strange
that some versions of the linker created it

Re: [patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself

Mark Brown — 2012-05-24T09:37:40


JFTR all randconfig means is that it doesn't seem like a configuration a
human is likely to generate for use on an actual system as opposed to
build coverage - in this case the driver is for the PMIC for some new
ARM SoCs so it's unlikely that someone would want to run the driver on a
system that doesn't have DT (and hence IRQ domains) enabled.

With this sort of dependency error failures are generally either in
configurations you'd expect people to want to run (which obviously
affect users), in allXconfig builds (which get run a lot for all sorts
of reasons and so are urgent even if it's unlikely people will use them
in production) or in randconfig builds (which should work and are
potentially sensible configurations but can also turn up combinations
that aren't that realistic).  All of these should be fixed if they
break.

Re: "blackfin: twi: move twi bit mask macro to twi head file"

Bob Liu — 2012-05-24T09:20:34

Hi Paul,

On Thu, May 24, 2012 at 8:59 AM, Paul Gortmaker
<paul.gortmaker< at >windriver.com> wrote:

That's because some blackfin i2c patches under drivers/i2c/ are still
not merged.
I'll request the i2c maintainer to merge them soon.

Thank you!

Re: [patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself

Mark Brown — 2012-05-24T09:09:58


It working right now isn't the only thing I'm concerned about, though
like I said further up the thread it's possible this is all just me
having too long a memory.


Sorry about that, I hadn't realised you were particularly attached to
the issue.  I do generally drop people doing global stuff with no
particular obvious interest in the specific topic on new patches since I
know I sometimes get a bit fed up of being CCed on random things I was
tangentially involved in at some point.


I guess since I've offended you so much already there's not much harm in
saying: it's always much better to send changes in a form that can be
directly applied with tools like git am.  Appending a patch to the
bottom of a mail requires something like hand editing the commit after
it's been applied to extract the changelog.  Not sure it actually made a
difference in this specific case but it can be the difference when
you're not sure about the approach taken, especially for small patches
where it's quick and simple to write and

Re: linux-next: build failure after merge of the final tree

Ingo Molnar — 2012-05-24T07:22:48

* Stephen Rothwell <sfr< at >canb.auug.org.au> wrote:


Hm, Peter?

Thanks,

Ingo

Re: linux-next: build failure after merge of the final tree

Stephen Rothwell — 2012-05-24T07:16:04

Hi Ingo,

On Wed, 23 May 2012 17:35:36 +0200 Ingo Molnar <mingo< at >kernel.org> wrote:

OK, clearly something is wrong :-( There could well be a problem with my
toolchain.

I am still getting this error.  Build is an i386 defconfig

$ i386-linux-gcc --version
i386-linux-gcc (GCC) 4.6.0
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ i386-linux-ld --version
GNU ld (GNU Binutils) 2.21
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

I have CONFIG_DEBUG_SECTION_MISMATCH=y and -s on the build command line.

This is the entire build log:

In file included from /scratch/sfr/next/arch/x86/include/asm/uaccess.h:580:0,
                 from /scratch/sfr/next/include/linux/uaccess.

linux-next: Tree for May 24

Stephen Rothwell — 2012-05-24T06:49:15

Hi all,

Changes since 20120523:

With the merge window open, conflicts are moving from tree to tree.

The i386 defconfig build is still broken.

The sound-current tree lost its conflicts.

The hexagon tree lost its conflict.

The target-merge tree lost its conflicts.

The crypto tree lost its conflicts.

The cgroup tree lost its conflict.

The mfd tree lost its build failure.

The watchdog tree lost its build failure.

The trivial tree lost its conflicts.

The tip tree lost a few conflicts.

The percpu tree lots its conflict.

The arm-soc tree lost several conflicts.

The signal tree gained conflicts against the tip tree and Linus' tree.

The akpm tree lost several patches to the signal tree.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "g

linux-next: manual merge of the signal tree with Linus' tree

Stephen Rothwell — 2012-05-24T05:54:53

Hi Al,

Today's linux-next merge of the signal tree got a conflict in
kernel/irq/manage.c between commit f5d89470f91f ("genirq: Be more
informative on irq type mismatch") from Linus' tree and commit
501a0effacfa ("genirq: reimplement exit_irq_thread() hook via
task_work_add()") from the signal tree.

The latter removed the code modified by the former, so I did that.

Re: [patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself

David Rientjes — 2012-05-24T04:53:21


Well pardon me for actually having a cluster of machines at Google 
dedicated to upstream build/boot/regression testing that verified my patch 
was correct and didn't result in any kind of "fragility", or what you have 
convinced yourself is "fragility."


When you propose your own version, drop all cc's (and this isn't the first 
time you've done that), and then send the git pull request less than 30 
minutes later, I don't really have the chance to review it.  Lesson 
learned, I simply won't bother to fix your code in the future.

Re: [patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself

Mark Brown — 2012-05-24T01:19:51


It's a different kind of fragility, things break immediately when you
add something new which is reasonably obvous as opposed to happening
at some other time due to a tooling issue and what I'm concerned about
avoiding.  In any case...


...Linus already merged my alternative patch which does this with a
select..if which never seems to have these issues.

Your patch *should* work but due to past issues and the fact that I can
understand why they might occur (the semantic of select is "just enable
this" which doesn't pay too much attention to the target) I'd rather go
with this different approach.

Re: [patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself

David Rientjes — 2012-05-24T01:12:18


Oh well, Linus already merged your git pull that you didn't cc to me and 
you did it with a bogus commit message that insists this is only a 
randconfig issue when in reality you never tested enabling 
CONFIG_MFD_PALMAS without CONFIG_IRQ_DOMAIN when you merged 4af8be67fd99 
("regmap: Convert regmap_irq to use irq_domain").

"blackfin: twi: move twi bit mask macro to twi head file"

Paul Gortmaker — 2012-05-24T00:59:40

Hi all,

This commit:

------
commit c55c89e939f2a0a83d5c61462be554d5d2408178
Author: Sonic Zhang <sonic.zhang< at >analog.com>
Date:   Thu Nov 24 17:40:07 2011 +0800

    blackfin: twi: move twi bit mask macro to twi head file
    
    Signed-off-by: Sonic Zhang <sonic.zhang< at >analog.com>
    Signed-off-by: Bob Liu <lliubbo< at >gmail.com>
------

seems to break linux-next builds, such as this:

http://kisskb.ellerman.id.au/kisskb/buildresult/6353497/

Please have a look, thanks.
Paul.