gmane.linux.kernel.next

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 absolute.  Again, such a
kernel would have malfunctioned if relocated.

The really disturbing part of this one is that it shows that these
problems covers multiple GNU ld versions.

-hpa

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 test the replacement.

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.h:5,
                 from /scratch/sfr/next/include/linux/highmem.h:8,
                 from /scratch/sfr/next/include/linux/pagemap.h:10,
                 from /scratch/sfr/next/fs/binfmt_misc.c:27:
/scratch/sfr/next/arch/x86/include/asm/uaccess_32.h: In function 'parse_command.part.1':
/scratch/sfr/next/arch/x86/include/asm/uaccess_32.h:211:26: warning: call to 'copy_from_user_overflow' declared with attribute warning: copy_from_user() buffer size is not provably correct [enabled by default]
sort done marker at 9112a4
Invalid absolute R_386_32 relocation: jiffies
make[3]: *** [arch/x86/boot/compressed/vmlinux.relocs] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [arch/x86/boot/compressed/vmlinux] Error 2
make[1]: *** [bzImage] Error 2
make: *** [sub-make] Error 2

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 "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 190 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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.

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

David Rientjes — 2012-05-24T00:36:38


So my patch to select IRQ_DOMAIN for REGMAP_IRQ is correct since 
REGMAP_IRQ now requires IRC_DOMAIN since the commit listed in the 
changelog.

What's fragile is going around and adding "select IRQ_DOMAIN" to 
everything that does "select REGMAP_IRQ".  So I removed that and just made 
IRQ_DOMAIN select REGMAP_IRQ itself.

So can this be merged or what's the issue?

Re: linux-next: Tree for May 23 (uml)

Al Viro — 2012-05-23T23:47:30

Fine by me...  Pushed into for-next, should be on git.kernel.org shortly...

Re: linux-next: Tree for May 23 (uml)

Stephen Rothwell — 2012-05-23T23:13:06

Hi Al,

On Wed, 23 May 2012 20:37:07 +0100 Al Viro <viro< at >ZenIV.linux.org.uk> wrote:

So variant2 sits on top of variant1 and you are intending to push the
work in variant2 in this merge window anyway?   In that case variant2
makes sense.  The number of small conflicts don't matter to much (up to a
point anyway :-)).  Also, these cherry-picks are out of Andrew's tree,
right (so they are already in linuc-next)?  In which case I would
probably go with variant2.