gmane.linux.kernel
http://blog.gmane.org/gmane.linux.kernel
hourly11901-01-01T00:00+00:00Gmanehttp://gmane.org/img/gmane-25t.png
http://gmane.org
[PATCH] Staging: comedi: mpc82860: fixed a brace coding style issue
http://comments.gmane.org/gmane.linux.kernel/1303939
<pre>Fixed a coding style issue
Signed-off-by: Michael Dabydeen<mdabydeen< at >gmail.com>
---
drivers/staging/comedi/drivers/mpc8260cpm.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/mpc8260cpm.c b/drivers/staging/comedi/drivers/mpc8260cpm.c
index 364470e..6d291b7 100644
--- a/drivers/staging/comedi/drivers/mpc8260cpm.c
+++ b/drivers/staging/comedi/drivers/mpc8260cpm.c
< at >< at > -36,7 +36,7 < at >< at > It is apparently missing some code.
#include "../comedidev.h"
-extern unsigned long mpc8260_dio_reserved[4];
+unsigned long mpc8260_dio_reserved[4];
struct mpc8260cpm_private {
< at >< at > -71,10 +71,8 < at >< at > static int mpc8260cpm_dio_config(struct comedi_device *dev,
port = (int)s->private;
mask = 1 << CR_CHAN(insn->chanspec);
-if (mask & cpm_reserved_bits[port]) {
+if (mask & cpm_reserved_bits[port])
return -EINVAL;
-}
-
switch (data[0]) {
case INSN_CONFIG_DIO_OUTPUT:
s->io_bits |= mask;
< at >< at > -122,7 +120,7 < at >< at > static int mpc8260cpm_attach(struct comedi_device *dev,
struct comedi_subdevice *s;
int i;
-printk("comedi%d: mpc8260cpm: ", dev->minor);
+printk(KERN_ERROR , "comedi%d: mpc8260cpm: ", dev->minor);
dev->board_ptr = mpc8260cpm_boards + dev->board;
</pre>Michael Dabydeen2012-05-26T15:21:43[PULL REQUEST] i2c-embedded for 3.5
http://comments.gmane.org/gmane.linux.kernel/1303932
<pre>Linus,
here is the pull request for the embedded part of the i2c subsystem.
Major changes:
- lots of devicetree additions for existing drivers. I tried hard to
make sure the bindings are proper. In more complicated cases, I
requested acks from people having more experience with them than me.
That took a bit of extra time and also some time went into discussions
with developers about what bindings are and what not. I have the
feeling that the workflow with bindings should be improved to scale
better. I will spend some more thought on this...
- i2c-muxes are succesfully used meanwhile, so we dropped EXPERIMENTAL
for them and renamed the drivers to a standard pattern to match the
rest of the subsystem. They can also be used with devicetree now.
- ixp2000 was removed since the whole platform goes away.
- cleanups (strlcpy instead of strcpy, NULL instead of 0)
- The rest is typical driver fixes I assume.
All patches have been in linux-next at least since v3.4-rc6.
Note that you will get a trivial merge-conflict because some
lpc32xx-patches have already come in via arm-soc to reduce dependencies.
I read that you want to see such conflicts so I didn't take any actions.
I'll add Arnd and Roland to CC, because they know best about LPC32xx
changes.
Thanks,
Wolfram
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-next
for you to fetch changes up to 9868a060ccf769c08ec378a9829137e272e9a92c:
i2c: davinci: Free requested IRQ in remove (2012-05-12 20:36:24 +0200)
----------------------------------------------------------------
David Daney (2):
i2c: Add a struct device * parameter to i2c_add_mux_adapter()
i2c/of: Automatically populate i2c mux busses from device tree data.
Deepak Sikri (1):
i2c: designware: add PM support
Ganesan Ramalingam (1):
i2c: ocores: register OF i2c devices
Jean Delvare (1):
i2c: Rename last mux driver to standard pattern
Karol Lewandowski (5):
i2c-s3c2410: Drop unused define
i2c-pxa: Drop leftover comment
i2c: Dynamically assign adapter id if it wasn't explictly specified
i2c-s3c2410: Rework device type handling
i2c-s3c2410: Add HDMIPHY quirk for S3C2440
Lars-Peter Clausen (1):
I2C: xiic: Add OF binding support
Laxman Dewangan (2):
i2c: tegra: fix 10bit address configuration
i2c: tegra: notify transfer-complete after clearing status.
Magnus Damm (1):
i2c: sh_mobile: add device tree support
Marcus Folkesson (1):
i2c: davinci: Free requested IRQ in remove
Rob Herring (1):
i2c: ixp2000: remove driver
Roland Stigge (3):
i2c-pnx.c: Use resources in platforms
i2c-pnx.c: Remove duplicated i2c.h
i2c: pnx: add device tree support
Stefan Roese (1):
i2c: designware: Add support for 16bit register access
Stephen Warren (3):
of/i2c: call i2c_verify_client from of_find_i2c_device_by_node
i2c: implement i2c_verify_adapter
of/i2c: implement of_find_i2c_adapter_by_node
Tomoya MORINAGA (3):
i2c-eg20t: Call init() when wait-event timeout occurs
i2c-eg20t: add helper function for xfer check
i2c-eg20t: Merge two functions
Viresh Kumar (1):
i2c: designware: Add clk_{un}prepare() support
Wolfram Sang (7):
i2c: eg20t: use NULL instead of 0
i2c: eg20t: pass on return value in i2c_xfer
i2c: eg20t: remove unused function
i2c: eg20t: don't use strcpy but strlcpy
i2c: imx: don't use strcpy but strlcpy
i2c: muxes are not EXPERIMENTAL anymore
i2c: muxes: rename first set of drivers to a standard pattern
Zhao Chenhui (1):
i2c-mpc: avoid I2C abnormal after resuming from deep sleep
Documentation/devicetree/bindings/i2c/mux.txt | 60 +++++
Documentation/devicetree/bindings/i2c/pnx.txt | 36 +++
.../devicetree/bindings/i2c/samsung-i2c.txt | 8 +-
Documentation/devicetree/bindings/i2c/xiic.txt | 22 ++
.../i2c/muxes/{gpio-i2cmux => i2c-mux-gpio} | 12 +-
MAINTAINERS | 8 +-
arch/arm/mach-lpc32xx/common.c | 67 ++++--
arch/arm/mach-lpc32xx/include/mach/i2c.h | 63 -----
arch/arm/mach-pnx4008/i2c.c | 64 +++--
arch/arm/mach-pnx4008/include/mach/i2c.h | 64 -----
drivers/i2c/Kconfig | 1 -
drivers/i2c/busses/Kconfig | 14 --
drivers/i2c/busses/Makefile | 1 -
drivers/i2c/busses/i2c-davinci.c | 2 +-
drivers/i2c/busses/i2c-designware-core.c | 31 ++-
drivers/i2c/busses/i2c-designware-core.h | 5 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 33 ++-
drivers/i2c/busses/i2c-eg20t.c | 246 ++++++--------------
drivers/i2c/busses/i2c-gpio.c | 7 +-
drivers/i2c/busses/i2c-imx.c | 2 +-
drivers/i2c/busses/i2c-ixp2000.c | 157 -------------
drivers/i2c/busses/i2c-mpc.c | 30 +++
drivers/i2c/busses/i2c-ocores.c | 3 +
drivers/i2c/busses/i2c-pca-platform.c | 2 +-
drivers/i2c/busses/i2c-pnx.c | 157 +++++++++----
drivers/i2c/busses/i2c-pxa.c | 5 -
drivers/i2c/busses/i2c-s3c2410.c | 109 +++++----
drivers/i2c/busses/i2c-sh_mobile.c | 11 +
drivers/i2c/busses/i2c-tegra.c | 24 +-
drivers/i2c/busses/i2c-versatile.c | 9 +-
drivers/i2c/busses/i2c-xiic.c | 23 +-
drivers/i2c/i2c-core.c | 17 ++
drivers/i2c/i2c-mux.c | 42 +++-
drivers/i2c/muxes/Kconfig | 6 +-
drivers/i2c/muxes/Makefile | 6 +-
.../i2c/muxes/{gpio-i2cmux.c => i2c-mux-gpio.c} | 42 ++--
drivers/i2c/muxes/{pca9541.c => i2c-mux-pca9541.c} | 3 +-
drivers/i2c/muxes/{pca954x.c => i2c-mux-pca954x.c} | 2 +-
drivers/of/of_i2c.c | 16 +-
include/linux/{gpio-i2cmux.h => i2c-mux-gpio.h} | 14 +-
include/linux/i2c-mux.h | 3 +-
include/linux/i2c-pnx.h | 10 +-
include/linux/i2c.h | 1 +
include/linux/of_i2c.h | 4 +
44 files changed, 720 insertions(+), 722 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/mux.txt
create mode 100644 Documentation/devicetree/bindings/i2c/pnx.txt
create mode 100644 Documentation/devicetree/bindings/i2c/xiic.txt
rename Documentation/i2c/muxes/{gpio-i2cmux => i2c-mux-gpio} (85%)
delete mode 100644 arch/arm/mach-lpc32xx/include/mach/i2c.h
delete mode 100644 arch/arm/mach-pnx4008/include/mach/i2c.h
delete mode 100644 drivers/i2c/busses/i2c-ixp2000.c
rename drivers/i2c/muxes/{gpio-i2cmux.c => i2c-mux-gpio.c} (73%)
rename drivers/i2c/muxes/{pca9541.c => i2c-mux-pca9541.c} (99%)
rename drivers/i2c/muxes/{pca954x.c => i2c-mux-pca954x.c} (99%)
rename include/linux/{gpio-i2cmux.h => i2c-mux-gpio.h} (74%)
</pre>Wolfram Sang2012-05-26T14:06:50[ANNOUNCE][PATCH 5/26]Rotary Interactivity Favor Scheduler Version 3(Brain-Eating) Update.
http://comments.gmane.org/gmane.linux.kernel/1303922
<pre>Hi everyone.
RIFS v3 has been released.
This version make a big change from RIFS v2(Algorithm).
Actually it solves problems that V2 left.
On my box I can play 320K MP3 music without any skipping(SMOOTH!).Also
I can shake my windows frequently.
1.latt benchmark
Parameters: min_wait=100ms, max_wait=500ms, clients=1
Entries logged: 108
Wakeup averages
-------------------------------------
Max 25 usec
Avg 10 usec
Stdev 2 usec
Stdev mean 0 usec
Work averages
-------------------------------------
Max 21183 usec
Avg 20129 usec
Stdev 246 usec
Stdev mean 24 usec
2.latt benchmark
Parameters: min_wait=100ms, max_wait=500ms, clients=1
Entries logged: 108
Wakeup averages
-------------------------------------
Max 22 usec
Avg 8 usec
Stdev 2 usec
Stdev mean 0 usec
Work averages
-------------------------------------
Max 20326 usec
Avg 20016 usec
Stdev 85 usec
Stdev mean 8 usec
~~~ :-)
Enjoy the interactive feels.
享受交互性带来的感觉把
Chen
</pre>Chen2012-05-26T13:38:16[PATCH 0/5] Function tracing support for pstore
http://comments.gmane.org/gmane.linux.kernel/1303921
<pre>Hi all,
With this support kernel can save functions call chain log into a
persistent ram buffer that can be decoded and dumped after reboot
through pstore filesystem. It can be used to determine what function
was last called before a hang or an unexpected reset (caused by, for
example, a buggy driver that abuses HW).
Here's a "nano howto", to get the idea:
# mount -t debugfs debugfs /sys/kernel/debug/
# cd /sys/kernel/debug/tracing
# echo persistent > current_tracer
# reboot -f
[...]
# mount -t pstore pstore /mnt/
# tail /mnt/ftrace-ramoops
0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0
0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0
0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90
0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90
0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40
0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0
0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0
0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0
0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40
0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20
Mostly the code comes from trace_persistent.c driver found in the
Android git tree, written by Colin Cross <ccross< at >android.com>
(according to sign-off history). I reworked the driver a little bit,
and ported it to pstore subsystem.
The patches depend on a pile of other pstore-related work, so
if anyone is willing to try the patches, they would rather grab
the whole git tree:
git://git.infradead.org/users/cbou/linux-pstore.git
or gitweb:
http://git.infradead.org/users/cbou/linux-pstore.git
Note that so far I've tried to not change the original idea, but if
we consider inclusion, there are some open questions:
1. Should we merge persistent tracer with normal function tracer,
i.e. add some flag that makes function tracer to duplicate the
events into pstore (via a callback to pstore)?
2. If we keep the two separate, should the code live in fs/pstore
or kernel/trace?.. I can see valid points for both approaches.
Thanks,
---
Documentation/ramoops.txt | 24 +++++++++
fs/pstore/Kconfig | 12 +++++
fs/pstore/Makefile | 6 +++
fs/pstore/ftrace.c | 122 ++++++++++++++++++++++++++++++++++++++++++++
fs/pstore/inode.c | 111 ++++++++++++++++++++++++++++++++++++++--
fs/pstore/internal.h | 49 ++++++++++++++++++
fs/pstore/platform.c | 13 ++++-
fs/pstore/ram.c | 54 +++++++++++++++-----
include/linux/pstore.h | 5 ++
include/linux/pstore_ram.h | 1 +
kernel/trace/trace.c | 7 +--
11 files changed, 384 insertions(+), 20 deletions(-)
</pre>Anton Vorontsov2012-05-26T13:34:13[PATCH 0/5] Some pstore/ramoops fixes
http://comments.gmane.org/gmane.linux.kernel/1303892
<pre>Hi Greg,
In the light of Linus' response, and I said this to Colin already, I'll
just zap a prz at boot time for pstore/console interface, which means
that nowadays there shouldn't be any objections to this bunch of fixes.
These are valid fixes for v3.5, they restore old pstore's behavior
nuances, which I changed accidentaly.
Except for the last patch, which is just a fix I happened to make when
I got bored of the warning. :-) Not a regression fix, though.
Thanks,
---
fs/pstore/inode.c | 2 +-
fs/pstore/ram.c | 3 +++
fs/pstore/ram_core.c | 27 +++++++++++++++++----------
include/linux/pstore_ram.h | 2 ++
4 files changed, 23 insertions(+), 11 deletions(-)
</pre>Anton Vorontsov2012-05-26T13:06:50Waiting to hear from you
http://comments.gmane.org/gmane.linux.kernel/1303882
<pre>
I have a business for you to handle with me. Should you be interested,
Kindly contact me via (ahwoi.kwesi< at >yahoo.com) for more details.
Thanks
Hon. Kwesi Ahwoi
+233543146547
-----------------------------------------
This email was sent using TCEMail Service.
Thiagarajar College of Engineering
Madurai-625 015, India
</pre>Hon. Kwesi Ahwoi2012-05-23T03:33:09[GIT PULL FOR v3.5] Move sta2x11_vip to staging
http://comments.gmane.org/gmane.linux.kernel/1303866
<pre>Mauro,
This patch moves the sta2x11_vip driver to the staging directory. In my opinion
this driver is not ready for prime-time.
As I mentioned a week ago, I never saw this driver when it was posted as that
was during a period were I was unavoidably absent from the list. The problem
with this driver is that it doesn't use any of the new frameworks (the control
framework and videobuf2 in particular), and this should be corrected first.
In addition it has a clear V4L2 API violation in that only one filehandle at
a time can open the video node. Developers really *must* run v4l2-compliance
before posting a new driver! Almost all of this would be caught by that tool
(except for using videobuf instead of vb2). Personally I think showing the
output of v4l2-compliance should be a requirement for getting a driver merged
under drivers/media/video.
I didn't get any reply from Federico when I posted my concerns last week, so
that makes me unhappy as well.
I hope the author will fix these issues, but in the meantime this will move
it to staging waiting for further developments.
Regards,
Hans
The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181:
[media] mt9m032: Implement V4L2_CID_PIXEL_RATE control (2012-05-24 09:27:24 -0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git sta2x11
for you to fetch changes up to 66e2c2572a2b59df5d9f6043c5706a73ce624f89:
sta2x11_vip: move to staging. (2012-05-26 09:27:15 +0200)
----------------------------------------------------------------
Hans Verkuil (1):
sta2x11_vip: move to staging.
drivers/media/video/Kconfig | 13 -------------
drivers/media/video/Makefile | 1 -
drivers/staging/media/Kconfig | 2 ++
drivers/staging/media/Makefile | 1 +
drivers/staging/media/sta2x11/Kconfig | 12 ++++++++++++
drivers/staging/media/sta2x11/Makefile | 1 +
drivers/{media/video => staging/media/sta2x11}/sta2x11_vip.c | 0
drivers/{media/video => staging/media/sta2x11}/sta2x11_vip.h | 0
8 files changed, 16 insertions(+), 14 deletions(-)
create mode 100644 drivers/staging/media/sta2x11/Kconfig
create mode 100644 drivers/staging/media/sta2x11/Makefile
rename drivers/{media/video => staging/media/sta2x11}/sta2x11_vip.c (100%)
rename drivers/{media/video => staging/media/sta2x11}/sta2x11_vip.h (100%)
</pre>Hans Verkuil2012-05-26T07:39:58[GIT PULL 0/8] Second batch of arm-soc branches for 3.5
http://comments.gmane.org/gmane.linux.kernel/1303853
<pre>Hi Linus,
This is the second and last large set of arm-soc branches for the 3.5
merge window. There will likely be a couple of small pull requests next
week (and thereafter fixes).
Descriptions of each branch are in the corresponding request.
Most of them have some trivial merge conflicts with earlier branches or
other code that has gone in since they were staged. Notes below are for
the slightly trickier cases. Just like with the last batch I've pushed
up resolved/<tagname> branches with proposed resolutions if you want
to compare.
cleanup2 branch:
omap_init_clocksource_32k(): Keep the version from this branch but add
in the register_persistent_clock() addition from bd0493e.
clock branch:
An awkward add/remove conflict in mach-kirkwood/common.c. Code is removed
here that was fixed in one of our earlier branches. The right thing to
do is to still just remove the code.
dt2 branch:
gpio-mxs.c: Keep the (port) side but change false -> 0 on the last arg.
soc2 branch:
gpio-samsung.c: Slightly awkward move/change conflict. Essentially
re-apply the second hunk of f10590c9 in the moved function
(exynos5_gpiolib_init()).
cleanup-initcall branch:
Trivial conflict deltas and a deleted file conflict. The removed file
should remain removed.
Thanks!
-Olof
</pre>Olof Johansson2012-05-26T07:22:30[PATCH] tools libtraceevent: Silence compiler warning on 32bit build
http://comments.gmane.org/gmane.linux.kernel/1303844
<pre>The gcc complains about casting a pointer to unsigned long long directly:
SUBDIR ../lib/traceevent/
CC FPIC event-parse.o
CC FPIC trace-seq.o
CC FPIC parse-filter.o
/home/namhyung/project/linux/tools/lib/traceevent/parse-filter.c: In function ‘get_value’:
/home/namhyung/project/linux/tools/lib/traceevent/parse-filter.c:1588: warning: cast from pointer to integer of different size
CC FPIC parse-utils.o
BUILD STATIC LIB libtraceevent.a
Signed-off-by: Namhyung Kim <namhyung< at >gmail.com>
---
tools/lib/traceevent/parse-filter.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/lib/traceevent/parse-filter.c b/tools/lib/traceevent/parse-filter.c
index 2d40c5e..aa30b43 100644
--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
< at >< at > -1585,7 +1585,7 < at >< at > get_value(struct event_format *event,
const char *name;
name = get_comm(event, record);
-return (unsigned long long)name;
+return (unsigned long)name;
}
pevent_read_number_field(field, record->data, &val);
</pre>Namhyung Kim2012-05-26T03:41:31Lockdep warning from 3.4-gitX
http://comments.gmane.org/gmane.linux.kernel/1303842
<pre>A newly built mainline kernel that git-describe shows as v3.4-7895-g1937f4f has
the following lockdep log splat:
[ 69.013395] =============================================
[ 69.013397] [ INFO: possible recursive locking detected ]
[ 69.013401] 3.4.0-Linus-07895-g1937f4f #148 Not tainted
[ 69.013403] ---------------------------------------------
[ 69.013405] bash/3631 is trying to acquire lock:
[ 69.013415] (&tty->legacy_mutex){+.+.+.}, at: [<ffffffff81382662>]
tty_lock+0x32/0x70
[ 69.013417]
[ 69.013417] but task is already holding lock:
[ 69.013423] (&tty->legacy_mutex){+.+.+.}, at: [<ffffffff81382662>]
tty_lock+0x32/0x70
[ 69.013425]
[ 69.013425] other info that might help us debug this:
[ 69.013427] Possible unsafe locking scenario:
[ 69.013427]
[ 69.013429] CPU0
[ 69.013430] ----
[ 69.013433] lock(&tty->legacy_mutex);
[ 69.013435] lock(&tty->legacy_mutex);
[ 69.013437]
[ 69.013437] *** DEADLOCK ***
[ 69.013437]
[ 69.013439] May be due to missing lock nesting notation
[ 69.013439]
[ 69.013442] 2 locks held by bash/3631:
[ 69.013449] #0: (tty_mutex){+.+.+.}, at: [<ffffffff812577e1>]
tty_release+0x191/0x580
[ 69.013456] #1: (&tty->legacy_mutex){+.+.+.}, at: [<ffffffff81382662>]
tty_lock+0x32/0x70
[ 69.013457]
[ 69.013457] stack backtrace:
[ 69.013461] Pid: 3631, comm: bash Not tainted 3.4.0-Linus-07895-g1937f4f #148
[ 69.013463] Call Trace:
[ 69.013468] [<ffffffff8108c3d8>] __lock_acquire+0xee8/0x1c80
[ 69.013472] [<ffffffff81382662>] ? tty_lock+0x32/0x70
[ 69.013476] [<ffffffff8108d735>] lock_acquire+0x95/0x150
[ 69.013479] [<ffffffff81382662>] ? tty_lock+0x32/0x70
[ 69.013483] [<ffffffff8137f933>] ? mutex_lock_nested+0x273/0x350
[ 69.013486] [<ffffffff8137f72b>] mutex_lock_nested+0x6b/0x350
[ 69.013490] [<ffffffff81382662>] ? tty_lock+0x32/0x70
[ 69.013493] [<ffffffff8108e185>] ? trace_hardirqs_on_caller+0x105/0x190
[ 69.013497] [<ffffffff81382662>] tty_lock+0x32/0x70
[ 69.013500] [<ffffffff813826f5>] tty_lock_pair+0x55/0x5c
[ 69.013504] [<ffffffff812577ec>] tty_release+0x19c/0x580
[ 69.013509] [<ffffffff8112c3a5>] fput+0xf5/0x260
[ 69.013513] [<ffffffff81382886>] ? retint_swapgs+0xe/0x13
[ 69.013517] [<ffffffff81128846>] filp_close+0x56/0x80
[ 69.013520] [<ffffffff8112890b>] sys_close+0x9b/0x100
[ 69.013525] [<ffffffff81382fe2>] system_call_fastpath+0x16/0x1b
Thanks,
Larry
</pre>Larry Finger2012-05-26T03:18:24[PATCH] tty: tty_mutex: fix lockdep warning in tty_lock_pair(v3)
http://comments.gmane.org/gmane.linux.kernel/1303840
<pre>From: Ming Lei <tom.leiming< at >gmail.com>
Commit d29f3ef39be4eec0362b985305fc526d9be318cf(tty_lock:
Localise the lock) introduces tty_lock_pair, in which
may cause lockdep warning[1] because two locks with same lock
class are to be acquired one after another.
This patch uses mutex_lock_nested annotation to avoid
the warning as suggested by Peter.
[1], lockdep warning
[ 104.147918] =============================================
[ 104.153564] [ INFO: possible recursive locking detected ]
[ 104.159240] 3.4.0-next-20120524+ #887 Not tainted
[ 104.164184] ---------------------------------------------
[ 104.169830] dropbear/1337 is trying to acquire lock:
[ 104.175079] (&tty->legacy_mutex){+.+.+.}, at: [<c025f1d8>] tty_release+0x174/0x440
[ 104.183105]
[ 104.183105] but task is already holding lock:
[ 104.189270] (&tty->legacy_mutex){+.+.+.}, at: [<c03d7294>] tty_lock_pair+0x34/0x40
[ 104.197296]
[ 104.197296] other info that might help us debug this:
[ 104.204132] Possible unsafe locking scenario:
[ 104.204132]
[ 104.210357] CPU0
[ 104.212921] ----
[ 104.215484] lock(&tty->legacy_mutex);
[ 104.219512] lock(&tty->legacy_mutex);
[ 104.223541]
[ 104.223541] *** DEADLOCK ***
[ 104.223541]
[ 104.229736] May be due to missing lock nesting notation
[ 104.229736]
[ 104.236877] 2 locks held by dropbear/1337:
[ 104.241180] #0: (tty_mutex){+.+.+.}, at: [<c025f1cc>] tty_release+0x168/0x440
[ 104.248870] #1: (&tty->legacy_mutex){+.+.+.}, at: [<c03d7294>] tty_lock_pair+0x34/0x40
[ 104.257354]
[ 104.257354] stack backtrace:
[ 104.261962] [<c0015694>] (unwind_backtrace+0x0/0x11c) from [<c007dba0>] (__lock_acquire+0x1a54/0x1b10)
[ 104.271759] [<c007dba0>] (__lock_acquire+0x1a54/0x1b10) from [<c007e2d8>] (lock_acquire+0x120/0x144)
[ 104.281341] [<c007e2d8>] (lock_acquire+0x120/0x144) from [<c03d435c>] (mutex_lock_nested+0x50/0x390)
[ 104.290954] [<c03d435c>] (mutex_lock_nested+0x50/0x390) from [<c025f1d8>] (tty_release+0x174/0x440)
[ 104.300445] [<c025f1d8>] (tty_release+0x174/0x440) from [<c00f3294>] (fput+0x10c/0x21c)
[ 104.308868] [<c00f3294>] (fput+0x10c/0x21c) from [<c00efeec>] (filp_close+0x70/0x7c)
[ 104.317016] [<c00efeec>] (filp_close+0x70/0x7c) from [<c00effa8>] (sys_close+0xb0/0xf0)
[ 104.325408] [<c00effa8>] (sys_close+0xb0/0xf0) from [<c000e020>] (ret_fast_syscall+0x0/0x48)
Cc: Alan Cox <alan< at >linux.intel.com>
Cc: Arnd Bergmann <arnd< at >arndb.de>
Signed-off-by: Peter Zijlstra <peterz< at >infradead.org>
Signed-off-by: Ming Lei <ming.lei< at >canonical.com>
---
v3:
fix unlock order in tty_unlock_pair
drivers/tty/tty_mutex.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/tty_mutex.c b/drivers/tty/tty_mutex.c
index 69adc80..c7f4523 100644
--- a/drivers/tty/tty_mutex.c
+++ b/drivers/tty/tty_mutex.c
< at >< at > -10,7 +10,8 < at >< at >
* Getting the big tty mutex.
*/
-void __lockfunc tty_lock(struct tty_struct *tty)
+static void __lockfunc tty_lock_nested(struct tty_struct *tty,
+int subclass)
{
if (tty->magic != TTY_MAGIC) {
printk(KERN_ERR "L Bad %p\n", tty);
< at >< at > -18,7 +19,12 < at >< at > void __lockfunc tty_lock(struct tty_struct *tty)
return;
}
tty_kref_get(tty);
-mutex_lock(&tty->legacy_mutex);
+mutex_lock_nested(&tty->legacy_mutex, subclass);
+}
+
+void __lockfunc tty_lock(struct tty_struct *tty)
+{
+tty_lock_nested(tty, 0);
}
EXPORT_SYMBOL(tty_lock);
< at >< at > -43,11 +49,14 < at >< at > void __lockfunc tty_lock_pair(struct tty_struct *tty,
{
if (tty < tty2) {
tty_lock(tty);
-tty_lock(tty2);
+tty_lock_nested(tty2, SINGLE_DEPTH_NESTING);
} else {
-if (tty2 && tty2 != tty)
+int nested = 0;
+if (tty2 && tty2 != tty) {
tty_lock(tty2);
-tty_lock(tty);
+nested = SINGLE_DEPTH_NESTING;
+}
+tty_lock_nested(tty, nested);
}
}
EXPORT_SYMBOL(tty_lock_pair);
< at >< at > -55,8 +64,13 < at >< at > EXPORT_SYMBOL(tty_lock_pair);
void __lockfunc tty_unlock_pair(struct tty_struct *tty,
struct tty_struct *tty2)
{
-tty_unlock(tty);
-if (tty2 && tty2 != tty)
+if (tty < tty2) {
tty_unlock(tty2);
+tty_unlock(tty);
+} else {
+tty_unlock(tty);
+if (tty2 && tty2 != tty)
+tty_unlock(tty2);
+}
}
EXPORT_SYMBOL(tty_unlock_pair);
</pre>Ming Lei2012-05-26T02:54:29The $1,549 per day ZERO traffic system (UPDATE) Recommends Advanced Sports to you
http://comments.gmane.org/gmane.linux.kernel/1303838
<pre>Email :sniperxsystem< at >support.com
Friend Name :Friend
Friend Email :linux-kernel< at >vger.kernel.org
comment :
Listen to this... pretty crazy...
So many people rushed to download this
$530k/year system yesterday...
That they crashed the ENTIRE server!
=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=
(The site was down ALL day) Pretty crazy.
... The "ghetto" video alone has sent shockwaves
through the Clickbank community.
Can you believe THIS guy's one of Clickbanks
biggest super affiliates?
=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=
Talk soon
P.S. This is **BRAND NEW**...
It works and it's made $1,549.87 a DAY for
the past 739 days in a ROW!
No PPC, no PPV, no CPA, no so-called 'push
button softwares' scams, no 'loopholes'...
Something TOTALLY different.
Check it out (fast, while it's still open):
=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=
</pre>sniperxsystem< at >support.com2012-05-26T02:21:32[RFC PATCH] ASoC: make snd_soc_dai_link more symmetrical
http://comments.gmane.org/gmane.linux.kernel/1303828
<pre>From: Stephen Warren <swarren< at >nvidia.com>
Prior to this patch, the CPU side of a DAI link was specified using a
single name. Often, this was the result of calling dev_name() on the
device providing the DAI, but in the case of a CPU DAI driver that
provided multiple DAIs, it needed to mix together both the device name
and some device-relative name, in order to form a single globally unique
name.
However, the CODEC side of the DAI link was specified using separate
fields for device (name or OF node) and device-relative DAI name.
This patch allows the CPU side of a DAI link to be specified in the same
way as the CODEC side, separating concepts of device and device-relative
DAI name.
I believe this will be important in multi-codec and/or dynamic PCM
scenarios, where a single CPU driver provides multiple DAIs, while also
booting using device tree, with accompanying desire not to hard-code the
CPU side device's name into the original .cpu_dai_name field.
Ideally, both the CPU DAI and CODEC DAI loops in soc_bind_dai_link()
would now be identical. However, two things prevent that at present:
1) The need to save rtd->codec for the CODEC side, which means we have
to search for the CODEC explicitly, and not just the CODEC side DAI.
2) Since we know the CODEC side DAI is part of a codec, and not just
a standalone DAI, it's slightly more efficient to convert .codec_name/
.codec_of_node into a codec first, and then compare each DAI's .codec
field, since this avoids strcmp() on each DAI's CODEC's name within
the loop.
However, the two loops are essentially semantically equivalent.
Signed-off-by: Stephen Warren <swarren< at >nvidia.com>
---
Following on from this, it seems like rtd->codec is ripe for removal.
Since in fact there can be more than one codec per DAI link, having such
a top-level variable seems wrong . Any code that needs that value should
be able to access rtd->codec_dai->codec.
However, there are some sysfs files that rely on that value being either
rtd-codec_dai->codec *or* being the aux dev codec, which scuppers that
plan. Are those sysfs files still useful; they are "codec_reg" and
"dapm_widget" which are both in debugfs. I don't see either file documented
in Documentation/ anywhere, so it seems it shouldn't be an ABI people are
relying upon.
If we could remove those, it paves the way to not storing aux devs in an
rtd, but a standalone array of devices right in the card.
Am I way off base or going the wrong direction in my thinking here; I feel
I must be missing something...
include/sound/soc.h | 33 ++++++++++++++++++++++++++----
sound/soc/mxs/mxs-sgtl5000.c | 2 +-
sound/soc/soc-core.c | 42 ++++++++++++++++++++++++++++----------
sound/soc/tegra/tegra_alc5632.c | 6 ++--
sound/soc/tegra/tegra_wm8753.c | 6 ++--
sound/soc/tegra/tegra_wm8903.c | 6 ++--
sound/soc/tegra/trimslice.c | 6 ++--
7 files changed, 72 insertions(+), 29 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index c703871..23c4efb 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
< at >< at > -785,13 +785,36 < at >< at > struct snd_soc_dai_link {
/* config - must be set by machine driver */
const char *name;/* Codec name */
const char *stream_name;/* Stream name */
-const char *codec_name;/* for multi-codec */
-const struct device_node *codec_of_node;
-const char *platform_name;/* for multi-platform */
-const struct device_node *platform_of_node;
+/*
+ * You MAY specify the link's CPU-side device, either by device name,
+ * or by DT/OF node, but not both. If this information is omitted,
+ * the CPU-side DAI is matched using .cpu_dai_name only, which hence
+ * must be globally unique. These fields are currently typically used
+ * only for codec to codec links, or systems using device tree.
+ */
+const char *cpu_name;
+const struct device_node *cpu_of_node;
+/*
+ * You MAY specify the DAI name of the CPU DAI. If this information is
+ * omitted, the CPU-side DAI is matched using .cpu_name/.cpu_of_node
+ * only, which only works well when that device exposes a single DAI.
+ */
const char *cpu_dai_name;
-const struct device_node *cpu_dai_of_node;
+/*
+ * You MUST specify the link's codec, either by device name, or by
+ * DT/OF node, but not both.
+ */
+const char *codec_name;
+const struct device_node *codec_of_node;
+/* You MUST specify the DAI name within the codec */
const char *codec_dai_name;
+/*
+ * You MAY specify the link's platform/PCM/DMA driver, either by
+ * device name, or by DT/OF node, but not both. Some forms of link
+ * do not need a platform.
+ */
+const char *platform_name;
+const struct device_node *platform_of_node;
int be_id;/* optional ID for machine driver BE identification */
const struct snd_soc_pcm_stream *params;
diff --git a/sound/soc/mxs/mxs-sgtl5000.c b/sound/soc/mxs/mxs-sgtl5000.c
index 3e6e876..215113b 100644
--- a/sound/soc/mxs/mxs-sgtl5000.c
+++ b/sound/soc/mxs/mxs-sgtl5000.c
< at >< at > -133,7 +133,7 < at >< at > static int __devinit mxs_sgtl5000_probe_dt(struct platform_device *pdev)
mxs_sgtl5000_dai[i].codec_name = NULL;
mxs_sgtl5000_dai[i].codec_of_node = codec_np;
mxs_sgtl5000_dai[i].cpu_dai_name = NULL;
-mxs_sgtl5000_dai[i].cpu_dai_of_node = saif_np[i];
+mxs_sgtl5000_dai[i].cpu_of_node = saif_np[i];
mxs_sgtl5000_dai[i].platform_name = NULL;
mxs_sgtl5000_dai[i].platform_of_node = saif_np[i];
}
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index b37ee80..ec83505 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
< at >< at > -812,13 +812,15 < at >< at > static int soc_bind_dai_link(struct snd_soc_card *card, int num)
/* Find CPU DAI from registered DAIs*/
list_for_each_entry(cpu_dai, &dai_list, list) {
-if (dai_link->cpu_dai_of_node) {
-if (cpu_dai->dev->of_node != dai_link->cpu_dai_of_node)
-continue;
-} else {
-if (strcmp(cpu_dai->name, dai_link->cpu_dai_name))
-continue;
-}
+if (dai_link->cpu_of_node &&
+ (cpu_dai->dev->of_node != dai_link->cpu_of_node))
+continue;
+if (dai_link->cpu_name &&
+ strcmp(dev_name(cpu_dai->dev), dai_link->cpu_name))
+continue;
+if (dai_link->cpu_dai_name &&
+ strcmp(cpu_dai->name, dai_link->cpu_dai_name))
+continue;
rtd->cpu_dai = cpu_dai;
}
< at >< at > -3346,6 +3348,12 < at >< at > int snd_soc_register_card(struct snd_soc_card *card)
link->name);
return -EINVAL;
}
+/* Codec DAI name must be specified */
+if (!link->codec_dai_name) {
+dev_err(card->dev, "codec_dai_name not set for %s\n",
+link->name);
+return -EINVAL;
+}
/*
* Platform may be specified by either name or OF node, but
< at >< at > -3358,12 +3366,24 < at >< at > int snd_soc_register_card(struct snd_soc_card *card)
}
/*
- * CPU DAI must be specified by 1 of name or OF node,
- * not both or neither.
+ * CPU device may be specified by either name or OF node, but
+ * can be left unspecified, and will be matched based on DAI
+ * name alone..
+ */
+if (link->cpu_name && link->cpu_of_node) {
+dev_err(card->dev,
+"Neither/both cpu name/of_node are set for %s\n",
+link->name);
+return -EINVAL;
+}
+/*
+ * At least one of CPU DAI name or CPU device name/node must be
+ * specified
*/
-if (!!link->cpu_dai_name == !!link->cpu_dai_of_node) {
+if (!link->cpu_dai_name &&
+ !(link->cpu_name || link->cpu_of_node)) {
dev_err(card->dev,
-"Neither/both cpu_dai name/of_node are set for %s\n",
+"Neither cpu_dai_name nor cpu_name/of_node are set for %s\n",
link->name);
return -EINVAL;
}
diff --git a/sound/soc/tegra/tegra_alc5632.c b/sound/soc/tegra/tegra_alc5632.c
index 1566957..417b09b 100644
--- a/sound/soc/tegra/tegra_alc5632.c
+++ b/sound/soc/tegra/tegra_alc5632.c
< at >< at > -197,16 +197,16 < at >< at > static __devinit int tegra_alc5632_probe(struct platform_device *pdev)
goto err;
}
-tegra_alc5632_dai.cpu_dai_of_node = of_parse_phandle(
+tegra_alc5632_dai.cpu_of_node = of_parse_phandle(
pdev->dev.of_node, "nvidia,i2s-controller", 0);
-if (!tegra_alc5632_dai.cpu_dai_of_node) {
+if (!tegra_alc5632_dai.cpu_of_node) {
dev_err(&pdev->dev,
"Property 'nvidia,i2s-controller' missing or invalid\n");
ret = -EINVAL;
goto err;
}
-tegra_alc5632_dai.platform_of_node = tegra_alc5632_dai.cpu_dai_of_node;
+tegra_alc5632_dai.platform_of_node = tegra_alc5632_dai.cpu_of_node;
ret = tegra_asoc_utils_init(&alc5632->util_data, &pdev->dev);
if (ret)
diff --git a/sound/soc/tegra/tegra_wm8753.c b/sound/soc/tegra/tegra_wm8753.c
index 4e77026..02bd5a8 100644
--- a/sound/soc/tegra/tegra_wm8753.c
+++ b/sound/soc/tegra/tegra_wm8753.c
< at >< at > -157,9 +157,9 < at >< at > static __devinit int tegra_wm8753_driver_probe(struct platform_device *pdev)
goto err;
}
-tegra_wm8753_dai.cpu_dai_of_node = of_parse_phandle(
+tegra_wm8753_dai.cpu_of_node = of_parse_phandle(
pdev->dev.of_node, "nvidia,i2s-controller", 0);
-if (!tegra_wm8753_dai.cpu_dai_of_node) {
+if (!tegra_wm8753_dai.cpu_of_node) {
dev_err(&pdev->dev,
"Property 'nvidia,i2s-controller' missing or invalid\n");
ret = -EINVAL;
< at >< at > -167,7 +167,7 < at >< at > static __devinit int tegra_wm8753_driver_probe(struct platform_device *pdev)
}
tegra_wm8753_dai.platform_of_node =
-tegra_wm8753_dai.cpu_dai_of_node;
+tegra_wm8753_dai.cpu_of_node;
ret = tegra_asoc_utils_init(&machine->util_data, &pdev->dev);
if (ret)
diff --git a/sound/soc/tegra/tegra_wm8903.c b/sound/soc/tegra/tegra_wm8903.c
index b75e0e8..1fd71e5 100644
--- a/sound/soc/tegra/tegra_wm8903.c
+++ b/sound/soc/tegra/tegra_wm8903.c
< at >< at > -331,9 +331,9 < at >< at > static __devinit int tegra_wm8903_driver_probe(struct platform_device *pdev)
}
tegra_wm8903_dai.cpu_dai_name = NULL;
-tegra_wm8903_dai.cpu_dai_of_node = of_parse_phandle(np,
+tegra_wm8903_dai.cpu_of_node = of_parse_phandle(np,
"nvidia,i2s-controller", 0);
-if (!tegra_wm8903_dai.cpu_dai_of_node) {
+if (!tegra_wm8903_dai.cpu_of_node) {
dev_err(&pdev->dev,
"Property 'nvidia,i2s-controller' missing or invalid\n");
ret = -EINVAL;
< at >< at > -342,7 +342,7 < at >< at > static __devinit int tegra_wm8903_driver_probe(struct platform_device *pdev)
tegra_wm8903_dai.platform_name = NULL;
tegra_wm8903_dai.platform_of_node =
-tegra_wm8903_dai.cpu_dai_of_node;
+tegra_wm8903_dai.cpu_of_node;
} else {
card->dapm_routes = harmony_audio_map;
card->num_dapm_routes = ARRAY_SIZE(harmony_audio_map);
diff --git a/sound/soc/tegra/trimslice.c b/sound/soc/tegra/trimslice.c
index 4a8d5b6..5815430 100644
--- a/sound/soc/tegra/trimslice.c
+++ b/sound/soc/tegra/trimslice.c
< at >< at > -162,9 +162,9 < at >< at > static __devinit int tegra_snd_trimslice_probe(struct platform_device *pdev)
}
trimslice_tlv320aic23_dai.cpu_dai_name = NULL;
-trimslice_tlv320aic23_dai.cpu_dai_of_node = of_parse_phandle(
+trimslice_tlv320aic23_dai.cpu_of_node = of_parse_phandle(
pdev->dev.of_node, "nvidia,i2s-controller", 0);
-if (!trimslice_tlv320aic23_dai.cpu_dai_of_node) {
+if (!trimslice_tlv320aic23_dai.cpu_of_node) {
dev_err(&pdev->dev,
"Property 'nvidia,i2s-controller' missing or invalid\n");
ret = -EINVAL;
< at >< at > -173,7 +173,7 < at >< at > static __devinit int tegra_snd_trimslice_probe(struct platform_device *pdev)
trimslice_tlv320aic23_dai.platform_name = NULL;
trimslice_tlv320aic23_dai.platform_of_node =
-trimslice_tlv320aic23_dai.cpu_dai_of_node;
+trimslice_tlv320aic23_dai.cpu_of_node;
}
ret = tegra_asoc_utils_init(&trimslice->util_data, &pdev->dev);
</pre>Stephen Warren2012-05-26T00:22:11[RESEND][PATCH] pcmcia: move unbind/rebind into dev_pm_ops.complete
http://comments.gmane.org/gmane.linux.kernel/1303821
<pre>The idea of moving rebind procedure into pm.complete
was taken from the usb-subsystem, which has similar
problems with reattaching devices during/after
resume.
Signed-off-by: Christian Lamparter <chunkeey< at >googlemail.com>
---
Note: I have submitted this patch before in march.
But as far as I can tell it was neither rejected
nor accepted?!
Regards,
Chr
PS: I'm not on the pcmcia/kernel list, so please keep the
'CC'.
---
drivers/pcmcia/cs.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
index d9ea192..503596f 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
< at >< at > -512,6 +512,13 < at >< at > static int socket_late_resume(struct pcmcia_socket *skt)
return socket_insert(skt);
}
+if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
+skt->callback->early_resume(skt);
+return 0;
+}
+
+static int socket_complete_resume(struct pcmcia_socket *skt)
+{
#ifdef CONFIG_CARDBUS
if (skt->state & SOCKET_CARDBUS) {
/* We can't be sure the CardBus card is the same
< at >< at > -519,11 +526,8 < at >< at > static int socket_late_resume(struct pcmcia_socket *skt)
* and re-add... */
cb_free(skt);
cb_alloc(skt);
-return 0;
}
#endif
-if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
-skt->callback->early_resume(skt);
return 0;
}
< at >< at > -534,11 +538,15 < at >< at > static int socket_late_resume(struct pcmcia_socket *skt)
*/
static int socket_resume(struct pcmcia_socket *skt)
{
+int err;
if (!(skt->state & SOCKET_SUSPEND))
return -EBUSY;
socket_early_resume(skt);
-return socket_late_resume(skt);
+err = socket_late_resume(skt);
+if (!err)
+socket_complete_resume(skt);
+return err;
}
static void socket_remove(struct pcmcia_socket *skt)
< at >< at > -849,6 +857,11 < at >< at > static int __used pcmcia_socket_dev_resume(struct device *dev)
return __pcmcia_pm_op(dev, socket_late_resume);
}
+static void __used pcmcia_socket_dev_complete(struct device *dev)
+{
+__pcmcia_pm_op(dev, socket_complete_resume);
+}
+
static const struct dev_pm_ops pcmcia_socket_pm_ops = {
/* dev_resume may be called with IRQs enabled */
SET_SYSTEM_SLEEP_PM_OPS(NULL,
< at >< at > -863,6 +876,7 < at >< at > static const struct dev_pm_ops pcmcia_socket_pm_ops = {
.resume_noirq = pcmcia_socket_dev_resume_noirq,
.thaw_noirq = pcmcia_socket_dev_resume_noirq,
.restore_noirq = pcmcia_socket_dev_resume_noirq,
+.complete = pcmcia_socket_dev_complete,
};
#define PCMCIA_SOCKET_CLASS_PM_OPS (&pcmcia_socket_pm_ops)
</pre>Christian Lamparter2012-05-25T23:41:43[PATCH] MAINTAINERS: add OMAP CPUfreq driver to OMAP Power Management section
http://comments.gmane.org/gmane.linux.kernel/1303810
<pre>Add the OMAP CPUFreq driver to the list of files in the OMAP Power
Management section.
I've already been maintaining this driver, this just makes it
official.
Signed-off-by: Kevin Hilman <khilman< at >ti.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b362709..60ff5d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
< at >< at > -4791,6 +4791,7 < at >< at > M:Kevin Hilman <khilman< at >ti.com>
L:linux-omap< at >vger.kernel.org
S:Maintained
F:arch/arm/*omap*/*pm*
+F:drivers/cpufreq/omap-cpufreq.c
OMAP POWERDOMAIN/CLOCKDOMAIN SOC ADAPTATION LAYER SUPPORT
M:Rajendra Nayak <rnayak< at >ti.com>
</pre>Kevin Hilman2012-05-25T22:53:19Generic Red-Black Trees (status update)
http://comments.gmane.org/gmane.linux.kernel/1303807
<pre>For anybody that's keeping up with this, I've gone through multiple
iterations and tests with 9 different gcc versions and concluded that
the search, insert & remove cores need to be coded in rbtree.h, using
the traditional interface (i.e., passing struct rb_node & rb_root
pointers instead of pointers to your specific object types). The reason
is that gcc can't handle the cool fully-generic code until 4.6. In gcc
4.5.x, optimization completely breaks expanding the inline functions
into huge bloated monsters. Also, while I'm re-coding it all, I'm
adding find_near & insert_near, for more efficient insertion & retrieval
when you already have a node that should be close to the one you want
(which is often the case when inserting many objects at once).
So after I'm done with this, I'll start on a new header file (grbtree.h
probably) using the "grb_" prefix for it's functions that implements the
gcc 4.6.x+ fully generic & type safe interface, but using cute
pre-processor tricks for pre-4.6.x compatibility (basically, something
to consider using once gcc 4.6+ is more widely used).
Daniel
</pre>Daniel Santos2012-05-25T22:48:48[PATCH] net: compute a more reasonable default ip6_rt_max_size (v2)
http://comments.gmane.org/gmane.linux.kernel/1303799
<pre>The algorithm is based on ipv4 and alloc_large_system_hash().
The following data is from a x86_64 box I tested:
128MB
$ cat /proc/sys/net/ipv{4,6}/route/max_size
16384
22444
512MB
$ cat /proc/sys/net/ipv{4,6}/route/max_size
65536
99856
1GB
$ cat /proc/sys/net/ipv{4,6}/route/max_size
524288
203068
2GB
$ cat /proc/sys/net/ipv{4,6}/route/max_size
1048576
524288
4GB
$ cat /proc/sys/net/ipv{4,6}/route/max_size
2097152
524288
Signed-off-by: Arun Sharma <asharma< at >fb.com>
Cc: netdev< at >vger.kernel.org
Cc: linux-kernel< at >vger.kernel.org
Cc: David Miller <davem< at >davemloft.net>
---
net/ipv6/route.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 49d6ce1..bf85926 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
< at >< at > -2827,6 +2827,16 < at >< at > struct ctl_table * __net_init ipv6_route_sysctl_init(struct net *net)
}
#endif
+static __initdata unsigned long ip6_rt_entries;
+static int __init set_rt_entries(char *str)
+{
+if (!str)
+return 0;
+ip6_rt_entries = simple_strtoul(str, &str, 0);
+return 1;
+}
+__setup("ip6_rt_entries=", set_rt_entries);
+
static int __net_init ip6_route_net_init(struct net *net)
{
int ret = -ENOMEM;
< at >< at > -2872,8 +2882,17 < at >< at > static int __net_init ip6_route_net_init(struct net *net)
ip6_template_metrics, true);
#endif
+/* Compute a reasonable default based on what we do for ipv4
+ * total size = 1/16th of total RAM
+ * No more than 512k entries unless overridden on kernel cmdline */
+if (ip6_rt_entries == 0) {
+ip6_rt_entries = (totalram_pages << PAGE_SHIFT) >> 4;
+ip6_rt_entries /= sizeof(struct rt6_info);
+ip6_rt_entries = min(512 * 1024UL, ip6_rt_entries);
+}
+
net->ipv6.sysctl.flush_delay = 0;
-net->ipv6.sysctl.ip6_rt_max_size = 4096;
+net->ipv6.sysctl.ip6_rt_max_size = ip6_rt_entries;
net->ipv6.sysctl.ip6_rt_gc_min_interval = HZ / 2;
net->ipv6.sysctl.ip6_rt_gc_timeout = 60*HZ;
net->ipv6.sysctl.ip6_rt_gc_interval = 30*HZ;
</pre>Arun Sharma2012-05-25T22:26:56btrfs: kernel BUG at fs/btrfs/volumes.c:3653
http://comments.gmane.org/gmane.linux.kernel/1303798
<pre>I have a btrfs volume that's made up of 10 devices, only one
filesystem on the volume. Have been running this for probably over a
year. Recently noticed kernel oops, in syslog there's this:
May 25 17:22:42 www kernel: ------------[ cut here ]------------
May 25 17:22:42 www kernel: kernel BUG at fs/btrfs/volumes.c:3653!
May 25 17:22:42 www kernel: invalid opcode: 0000 [#1] SMP
May 25 17:22:42 www kernel: Modules linked in: i2c_i801 i2c_core evdev
May 25 17:22:42 www kernel:
May 25 17:22:42 www kernel: Pid: 1777, comm: btrfs-transacti Not tainted 3.3.7 #1 Gigabyte Technology Co., Ltd. 965P-DS3/965P-DS3
May 25 17:22:42 www kernel: EIP: 0060:[<c1229c77>] EFLAGS: 00010282 CPU: 1
May 25 17:22:42 www kernel: EIP is at __btrfs_map_block+0x9e7/0xa10
May 25 17:22:42 www kernel: EAX: 00000033 EBX: ee205cac ECX: 00004948 EDX: 00000046
May 25 17:22:42 www kernel: ESI: ed512108 EDI: ee205cac EBP: ee205c68 ESP: ee205be4
May 25 17:22:42 www kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
May 25 17:22:42 www kernel: Process btrfs-transacti (pid: 1777, ti=ee204000 task=f4d86bd0 task.ti=ee204000)
May 25 17:22:42 www kernel: Stack:
May 25 17:22:42 www kernel: c15950c0 b2400000 0000002b 00001000 00000000 c104dee0 acf6461a 00000000
May 25 17:22:42 www kernel: acf6461a 00000019 00000000 00000202 0015380c 00011220 f5675cc0 f4d86bd0
May 25 17:22:42 www kernel: ee205c2c c1083ebe ee205c64 c108411b ee205c3c c1083ebe 00000010 00011270
May 25 17:22:42 www kernel: Call Trace:
May 25 17:22:42 www kernel: [<c104dee0>] ? sched_clock_local+0xf0/0x1f0
May 25 17:22:42 www kernel: [<c1083ebe>] ? mempool_alloc_slab+0xe/0x10
May 25 17:22:42 www kernel: [<c108411b>] ? mempool_alloc+0x3b/0x100
May 25 17:22:42 www kernel: [<c1083ebe>] ? mempool_alloc_slab+0xe/0x10
May 25 17:22:42 www kernel: [<c122d4de>] btrfs_map_block+0x2e/0x40
May 25 17:22:42 www kernel: [<c1205b2a>] btrfs_merge_bio_hook+0x8a/0xc0
May 25 17:22:42 www kernel: [<c1205aa0>] ? btrfs_set_page_dirty+0x10/0x10
May 25 17:22:42 www kernel: [<c12232d7>] submit_extent_page.isra.26+0xb7/0x1d0
May 25 17:22:42 www kernel: [<c1205aa0>] ? btrfs_set_page_dirty+0x10/0x10
May 25 17:22:42 www kernel: [<c122447c>] __extent_writepage+0x8cc/0x920
May 25 17:22:42 www kernel: [<c12230a0>] ? end_extent_writepage+0x130/0x130
May 25 17:22:42 www kernel: [<c11fc2c0>] ? btrfs_end_buffer_write_sync+0x60/0x60
May 25 17:22:42 www kernel: [<c1224945>] extent_writepages+0x255/0x340
May 25 17:22:42 www kernel: [<c11fbf10>] ? verify_parent_transid+0x1b0/0x1b0
May 25 17:22:42 www kernel: [<c11fc5d5>] btree_writepages+0x65/0x70
May 25 17:22:42 www kernel: [<c108a396>] do_writepages+0x16/0x40
May 25 17:22:42 www kernel: [<c1082824>] __filemap_fdatawrite_range+0x54/0x60
May 25 17:22:42 www kernel: [<c1083806>] filemap_fdatawrite_range+0x26/0x30
May 25 17:22:42 www kernel: [<c120327a>] btrfs_write_marked_extents+0x8a/0xe0
May 25 17:22:42 www kernel: [<c12033bb>] btrfs_write_and_wait_marked_extents+0x1b/0x40
May 25 17:22:42 www kernel: [<c1203400>] btrfs_write_and_wait_transaction+0x20/0x40
May 25 17:22:42 www kernel: [<c1203ab2>] btrfs_commit_transaction+0x592/0x790
May 25 17:22:42 www kernel: [<c10417b0>] ? __init_waitqueue_head+0x30/0x30
May 25 17:22:42 www kernel: [<c11fc8bd>] transaction_kthread+0x1ed/0x250
May 25 17:22:42 www kernel: [<c1048b79>] ? complete+0x49/0x60
May 25 17:22:42 www kernel: [<c11fc6d0>] ? btrfs_alloc_root+0x30/0x30
May 25 17:22:42 www kernel: [<c104115d>] kthread+0x6d/0x80
May 25 17:22:42 www kernel: [<c1040000>] ? posix_clock_realtime_get+0x10/0x10
May 25 17:22:42 www kernel: [<c10410f0>] ? __init_kthread_worker+0x30/0x30
May 25 17:22:42 www kernel: [<c14c13b6>] kernel_thread_helper+0x6/0xd
May 25 17:22:42 www kernel: Code: 98 8b 5d 10 8b 03 8b 53 04 c7 04 24 c0 50 59 c1 89 44 24 0c 8b 45 08 89 54 24 10 8b 55 0c 89 44 24 04 89 54 24 08 e8 42 f6 28 00 <0f> 0b 0f 0b c7 45 18 01 00 00 00 c7 45 e4 00 00 00 00 e9 ce fa
May 25 17:22:42 www kernel: EIP: [<c1229c77>] __btrfs_map_block+0x9e7/0xa10 SS:ESP 0068:ee205be4
May 25 17:22:42 www kernel: ---[ end trace d849ee5ca409ca44 ]---
As soon as the filesystem is mounted this happens, also get this at the console:
Message from syslogd< at >www at Fri May 25 17:15:11 2012 ...
www kernel: Stack:
Message from syslogd< at >www at Fri May 25 17:15:11 2012 ...
www kernel: Process flush-btrfs-3 (pid: 4548, ti=ee178000 task=f08d7870 task.ti=ee178000)
Message from syslogd< at >www at Fri May 25 17:15:11 2012 ...
www kernel: Call Trace:
Message from syslogd< at >www at Fri May 25 17:15:11 2012 ...
www kernel: Code: 98 8b 5d 10 8b 03 8b 53 04 c7 04 24 c0 50 59 c1 89 44 24 0c 8b 45 08 89 54 24 10 8b 55 0c 89 44 24 04 89 54 24 08 e8 42 f6 28 00 <0f> 0b 0f 0b c7 45 18 01 00 00 00 c7 45 e4 00 00 00 00 e9 ce fa
Message from syslogd< at >www at Fri May 25 17:15:11 2012 ...
www kernel: EIP: [<c1229c77>] __btrfs_map_block+0x9e7/0xa10 SS:ESP
0068:ee179bf8
I can read the files and copy them to other drives. I can't do a software reboot, using the reboot command the machine just hangs and waits forever so I have to do a hard reset. Sometimes I can delete files, but after the hard reboot they are back. Other times I'll try to delete a file and the rm command just hangs. I can still use the machine and all other filesystems work fine. Thought it was maybe being low on space, this is what btrfs-show reports:
Label: btrfslvm uuid: f5361a96-1470-4c3a-9247-e9a1636cdd1b
Total devices 10 FS bytes used 5.64TB
devid 1 size 1.82TB used 1.70TB path /dev/sdd1
devid 4 size 1.82TB used 1.70TB path /dev/sdg1
devid 2 size 1.82TB used 1.70TB path /dev/sdj1
devid 5 size 1.36TB used 1.25TB path /dev/sdh1
devid 3 size 1.82TB used 1.70TB path /dev/sdf1
devid 10 size 1.82TB used 1.03TB path /dev/sdc1
devid 9 size 232.88GB used 111.25GB path /dev/sdl1
devid 6 size 372.61GB used 250.50GB path /dev/sdk1
devid 7 size 1.82TB used 1.70TB path /dev/sde1
devid 8 size 819.51GB used 697.25GB path /dev/sda3
Btrfs Btrfs v0.19
Tried adding a drive but get an error back:
www:# btrfs device add /dev/sdh1 /videos
ERROR: error adding the device '/dev/sdh1'
Not sure what to try next, any suggestions?
Thank you in advance,
Kevin
</pre>Kevin2012-05-25T22:16:13native_save_fl taking good amount of time in profile
http://comments.gmane.org/gmane.linux.kernel/1303794
<pre>I have collected a profile on the whole system. But the only thing
that is really running is a mysql database server. I have noticed that
there is a function in kernel that took 5% of the overall running
time. what does native_save_fl do ? does it make sense that
native_save_fl takes the most amount of time among all kernel
functions ?
Thank
</pre>Xin Tong2012-05-25T22:12:10[patch 0/4] timers: Fix get_next_timer_interrupt() proper
http://comments.gmane.org/gmane.linux.kernel/1303788
<pre>This series was inspired by the patch Gilad sent to fix a shortcoming
in get_next_timer_interrupt().
Instead of working around the problem I think it's better to avoid it
completely.
The fix is on top of a consolidation of the mindlessly copied code in
various timer API functions. Even with the added functionality that
makes the obj code footprint shrink
text data bss dec hexfilename
18589 3682 8257 30528 7740../build/kernel/timer.o
17997 3682 8257 29936 74f0../build/kernel/timer.o
Thanks,
tglx
----
timer.c | 110 +++++++++++++++++++++++++++++++++++-----------------------------
1 file changed, 61 insertions(+), 49 deletions(-)
</pre>Thomas Gleixner2012-05-25T22:08:56[PATCH] fixes to xen-blk[back|front] to deal with 32/64 host/guest combination with BLKIF_DISCARD (v1).
http://comments.gmane.org/gmane.linux.kernel/1303766
<pre>These two patches came out of hitting https://bugzilla.redhat.com/show_bug.cgi?id=824641
where a 32-bit guest would send a BLKIF_DISCARD request to a 64-bit
host. The xen-blkback did not copy the 'id' field into the response (it ended
up with a random value), which the frontend uses to lookup in its array to
find the 'struct request' that corresponded to this BLKIF_DISCARD.
The result was the __blk_end_request_all ended being called with a NULL
pointer and crashed the guest.
The fix is easy enough - make xen-blkback copy the 'id' field when
dealing with 32/64 or 64/32 host/guest combinations. The problem
does not exist if we are using a 64/64 combination.
I also added two BUG_ON to xen-blkfront to detect this misuse of 'id'
field in case there are other backends that do this.
If there are no problems with these patches I was thinking to put them
in my stable/for-jens-3.5 tree and ask Jens to pull them.
drivers/block/xen-blkback/common.h | 2 ++
drivers/block/xen-blkfront.c | 7 +++++++
2 files changed, 9 insertions(+), 0 deletions(-)
</pre>Konrad Rzeszutek Wilk2012-05-25T21:50:01Search EngineSearch the mailing list at Gmanequery
http://search.gmane.org/?group=$group=gmane.linux.kernel