This perf tool patch adds the ability to filter monitoring based on container groups (cgroups) for both perf stat and perf record. The cgroup to monitor are passed via a new -G option followed by a list of cgroups. The cgroup filesystem has to be mounted. The tool will find it automatically, open the right file and pass the descriptor to perf_events. Example: $ perf stat -B -a -e cycles:u,cycles:u,cycles:u -G test1,,test2 -- sleep 1 Performance counter stats for 'sleep 1': ...

You have been officially chosen by the Board of Trustees of the Oxfam GB (NGO UK) as one of the final Recipients of a Cash Grant/Donation of £850,000.00 grant entitlements,Contact email enquiry_terrywilliams0210001@live.co.uk,Qualification Number(OG/N231/E101/BDB) --

Oops... I tested it and it seemed to work fine. Even gcc did not complain... -- Ondrej Zary --

This patch adds the MAX98088 CODEC driver. Signed-off-by: Peter Hsiang <peter.hsiang at maxim-ic.com> --- include/sound/max98088.h | 87 ++ sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/max98088.c | 2871 +++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/max98088.h | 161 +++ 5 files changed, 3125 insertions(+), 0 deletions(-) create mode 100644 include/sound/max98088.h create mode 100644 sound/soc/codecs/max98088.c create ...

In fact, it does not. The idProduct text is from usb.ids file (which is often incorrect). The device says that it's "USB NET CARD" (iProduct). But I don't Maybe ignoring the device if class is 255 and iProduct is "USB NET CARD" (or This is from usb.ids ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ All these devices seem to use bDeviceClass 0 and iProduct "ADSL USB MODEM". -- Ondrej Zary --

Ingo, This only fixes a build warning, so I'm guessing that it can wait till 2.6.37. If you think otherwise, I could add it to my tip/perf/urgent branch instead. Please pull the latest tip/perf/core tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git tip/perf/core Steven Rostedt (1): tracing/lockdep: Fix dependency of TRACE_IRQFLAGS ---- lib/Kconfig.debug | 8 ++++---- 1 files changed, 4 insertions(+), 4 ...

In the hope that this will make it into Google and help others, and maybe someone will clarify the Kconfig.... I've just spent a gew hours trying to figure out why simple code attempting to use Netfilter Queues has been failing to even do the nice simple nfq_bind_pf(h, AF_INET). I eventually spotted some /proc code that lead me to find /proc/net/netfilter/nf_queue which contained: 0 NONE 1 NONE 2 ip_queue 3 NONE 4 NONE 5 NONE 6 NONE 7 NONE 8 NONE 9 NONE 10 NONE 11 ...

Hi. Very rarely I get this warning in my kernel log: [ 9224.980599] ------------[ cut here ]------------ [ 9224.980622] WARNING: at net/mac80211/scan.c:269 ieee80211_scan_completed+0x19e/0x1a0 [mac80211]() [ 9224.980627] Hardware name: Aspire 1810T [ 9224.980630] Modules linked in: fuse coretemp hwmon cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput snd_hda_codec_intelhdmi snd_hda_codec_realtek arc4 snd_hda_intel ecb ...

While you are bisecting, don't believe the version in Makefile. I got similarly freaked out a couple of years ago - if I understood correctly, it's something to do with when a change was created. The key point is that during bisection the apparent version *can* go back to a version that appears to be before the initial "good" kernel. ken -- das eine Mal als Tragödie, das andere Mal als Farce --

Hello, Yes I wanted to see if the community was interested in the general idea before I considered the implementation in too much detail. Though the two obvious choices spring to mind. 1) Simply serialise and print any suitable values to the console - these can be parsed with a bootscript much like the way you parse initcall_debug. 2) Output these values to a proc file which the use can extract. The difficult part as I see it - is passing it back to the kernel - as you suggested they may be ...

Since we no longer need to provide KM_type, the whole pte_*map_nested() API is now redundant, remove it. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- arch/alpha/include/asm/pgtable.h | 2 -- arch/arm/include/asm/pgtable.h | 6 ++---- arch/arm/mm/fault-armv.c | 4 ++-- arch/arm/mm/pgd.c | 4 ++-- arch/avr32/include/asm/pgtable.h | 2 -- arch/cris/include/asm/pgtable.h | 2 -- ...

Now that the KM_type stuff is history, clean up the compiler warning. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- arch/x86/kernel/cpu/perf_event.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Index: linux-2.6/arch/x86/kernel/cpu/perf_event.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/perf_event.c +++ linux-2.6/arch/x86/kernel/cpu/perf_event.c @@ -49,7 +49,6 @@ static unsigned long ...

Keep the current interface but ignore the KM_type and use a stack based approach. The advantage is that we get rid of crappy code like: #define __KM_PTE \ (in_nmi() ? KM_NMI_PTE : \ in_irq() ? KM_IRQ_PTE : \ KM_PTE0) and in general can stop worrying about what context we're in and what kmap slots might be appropriate for that. The down-side is that FRV kmap_atomic gets more expensive. For now we use a CPP trick suggested by Andrew: #define kmap_atomic(page, args...) ...

Ingo, Please pull this version instead. The only difference is that I Cc'd the stable list. Thanks, -- Steve Please pull the latest tip/perf/urgent-2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git tip/perf/urgent-2 Li Zefan (1): tracing: Fix a race in function profile ---- kernel/trace/ftrace.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-) --------------------------- commit ...

Add the USB ID needed to support B&B Electronic's 2-port, optically-isolated, powered, USB to RS485 converter. Signed-off-by: Dave Ludlow <dave.ludlow@bay.ws> --- drivers/usb/serial/mos7840.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c index 585b7e6..9a5ea9d 100644 --- a/drivers/usb/serial/mos7840.c +++ b/drivers/usb/serial/mos7840.c @@ -129,6 +129,7 @@ #define BANDB_DEVICE_ID_USOPTL4_2 0xAC42 ...

Thanks, this approach makes sense to me. --

For type A devices, the filtering is performed in userspace, in mtdev, in the same manner as it would have been performed in the kernel in the MT slot case. Therefore, knowing the amount of messages coming out of mtdev is a direct The jitter is better measured by the actual amount of events. Henrik --

From: Chase Douglas <chase.douglas@ubuntu.com> By moving the feature reports to an array, we can easily support more products with different initialization reports. This will be useful for enabling the Apple Magic Trackpad. Signed-off-by: Chase Douglas <chase.douglas@canonical.com> Acked-by: Michael Poole <mdpoole@troilus.org> --- drivers/hid/hid-magicmouse.c | 35 ++++++++++++++++++++--------------- 1 files changed, 20 insertions(+), 15 deletions(-) diff --git ...

The trackpad speaks a similar, but different, protocol from the magic mouse. However, only small code tweaks here and there are needed to make basic multitouch work. Extra logic is required for single-touch emulation of the touchpad. The changes made here take the approach that only one finger may emulate the single pointer when multiple fingers have touched the screen. Once that finger is raised, all touches must be raised before any further single touch events can be sent. Sometimes the ...

The new format should be easier to read to determine which bits correspond to which data. It also brings all the manipulation logic to the top of the function. This makes size and orientation reading more clear. Note that the impetus for this change is the forthcoming support for the Magic Trackpad, which has a different touch data protocol. Signed-off-by: Chase Douglas <chase.douglas@canonical.com> Acked-by: Michael Poole <mdpoole@troilus.org> --- drivers/hid/hid-magicmouse.c | 25 ...

As it is right now, hid-magicmouse doesn't support MT slots. I think all the fuzz code ends up comparing in the MT case is between one touch and another touch, not between one touch's current location and its previous location. If I'm correct, then it means a fuzz > 0 is incorrect for non-slotted MT devices. In fact, the code in drivers/input/input.c around line 194 looks like it discards defuzzing in this case, so one could say this patch is making things more correct :). Now a fuzz > 0 ...

Thanks for this driver. Comments inline. The logic using single_touch_id seems complicated. Any chance you could get by The tracking id reported by the macpad is not ideal; it works more like a slot that a MT protocol tracking id. Perhaps it is a slot? I would recommend looking at the recent submissions for bamboo touch, 3m-pct and w8001 to see how the If the pointer emulation was handled differently, and the above was replaced with something like if ...

Yes, there's still per-driver fuzz data. If a device is jittery it makes sense to set the in-kernel fuzz factor to a reasonable value. If a device is not jittery, I don't see a need to do any defuzzing of the values in the driver itself. If we think it's necessary to reduce bandwidth, then the kernel should be defuzzing uniformly across devices to compensate. mtdev could do this defuzzing for bandwidth uniformly too. As it is, this driver just has an arbitrary value that is not used in the ...

On second thought, if there's no jitter from the device, the only reason to filter is to save bandwidth. The magicmouse devices are very verbose strictly because they have a higher resolution than most devices. If that's an issue for userspace, then the filtering should be based on the resolution. In fact, I see that's what you do in mtdev when the in-kernel fuzz is 0. This separates the kernel fuzz into a removal of jitter, and the mtdev fuzz into a dampening of the number of events passed ...

Hello, I tested savagefb on 3 different Savage 4 cards: Diamond Stealth III S520 Number Nine SR9 Datapath Horizon 2S (two savage chips on a PCI card) it worked except the DDC which did not work on any of them. Looking at the BIOS code, it does not use MMIO register 0xff20 but CRT register 0xa0 or 0xb1 - depending on the chip revision and something in register 0xa6. With this patch, DDC works fine on all 3 cards (even on the second head of Horizon 2S - although it does not display anything ...

Reviewed-by: Christoph Lameter <cl@linux.com> --

Ordinarily watermark checks are based on the vmstat NR_FREE_PAGES as it is cheaper than scanning a number of lists. To avoid synchronization overhead, counter deltas are maintained on a per-cpu basis and drained both periodically and when the delta is above a threshold. On large CPU systems, the difference between the estimated and real value of NR_FREE_PAGES can be very high. If NR_FREE_PAGES is much higher than number of real free page in buddy, the VM can allocate pages below min watermark, at ...

When under significant memory pressure, a process enters direct reclaim and immediately afterwards tries to allocate a page. If it fails and no further progress is made, it's possible the system will go OOM. However, on systems with large amounts of memory, it's possible that a significant number of pages are on per-cpu lists and inaccessible to the calling process. This leads to a process entering direct reclaim more often than it should increasing the pressure on the system and compounding the ...

When allocating a page, the system uses NR_FREE_PAGES counters to determine if watermarks would remain intact after the allocation was made. This check is made without interrupts disabled or the zone lock held and so is race-prone by nature. Unfortunately, when pages are being freed in batch, the counters are updated before the pages are added on the list. During this window, the counters are misleading as the pages do not exist yet. When under significant pressure on systems with large numbers of ...

When using bluetooth-applet adding my apple magic mouse I'm getting a total system freeze. I used firescope to grab the crash data(below) The results of the bisect pointed to here: Bluetooth: Implemented HCI frame reassembly from RX stream commit:9981151086385eecc2febf4ba95a14593f834b3d after looking through, and at the crash log, I couldn't help but notice something in there with IRQ, then after looking at hci_h4.c /* H4 receiver States */ #58 I noticed #define H4_W4_PACKET_TYPE 0 is at zero ...

Fix missing consts in h8300's kernel_execve(): arch/h8300/kernel/sys_h8300.c: In function 'kernel_execve': arch/h8300/kernel/sys_h8300.c:59: warning: initialization from incompatible pointer type arch/h8300/kernel/sys_h8300.c:60: warning: initialization from incompatible pointer type Signed-off-by: David Howells <dhowells@redhat.com> --- arch/h8300/kernel/sys_h8300.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/h8300/kernel/sys_h8300.c ...

The following changes since commit 502adf5778f4151dcba3f64dd6ed322151f3712c: Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-08-24 12:21:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 for-linus As promised, here are the changes from Rafael and Kenji-san that fix up our OSC handling to conform much better to what platforms expect. The patchset does include some ...

Hmm, the function you change returns -ENODEV if a clock cannot be found, but the return type is u32. This should better be 0. Can you take care of this as well? You could then add my -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |

Acked-by: Wolfgang Grandegger <wg@grandegger.com> --

Add a call to of_node_put in the error handling code following a call to of_find_node_by_type. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression x; expression E,E1,E2; statement S; @@ *x = ...

This perf tool patch adds the ability to filter monitoring based on container groups (cgroups) for both perf stat and perf record. The cgroup to monitor are passed via a new -G option followed by a list of cgroups. The cgroup filesystem has to be mounted. The tool will find it automatically, open the right file and pass the descriptor to perf_events. Example: $ perf stat -a -e cycles:u -G test1 -- sleep 1 Performance counter stats for 'sleep 1': 9528573157 cycles test1 ...

This series of patches adds per-container (cgroup) filtering capability to per-cpu monitoring. In other words, we can monitor all threads belonging to a specific cgroup and running on a specific CPU. This is useful to measure what is going on inside a cgroup. Something that cannot easily and cheaply be achieved with either per-thread or per-cpu mode. Cgroups can span multiple CPUs. CPUs can be shared between cgroups. Cgroups can have lots of threads. Threads can come and go during a ...

Hello, This patchset tries to cleanup init/initramfs code especially for syscall invocation which produces many warnings from sparse because of address space change. This can be done by wrapping each syscall invocation and doing such conversions in it using kernel_sys_call() macro suggested by Arnd Bergmann. This patchset depends on my previous patch "init: mark __user address space on string literals" [1] now contained in -mm tree. Actually now it can be replaced by these patches. Andrew, I ...

After discovering a problem in regulator reference counting I took Mark Brown's advice to move the reference count into the MMC core by making the regulator status a member of struct mmc_host. I took this opportunity to also implement NULL versions of the regulator functions so as to rid the driver code from some ugly #ifdef CONFIG_REGULATOR clauses. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: ...

When the kernel sees those invalid low-speed bulk endpoint descriptors, it changes its internal copy of the descriptor to interrupt. Hence when the driver submits interrupt URBs, they work correctly. Alan Stern --

Yes, I think it would be a good idea to try to abstract it out a bit... Linus --

Looking at the other changes I believe that the logic for proc also needs to look at the previous vma to decide whether to hide the first page of it or not. The following patch against current head should fix that (only compile tested here . I only made the change to task_mmu.c here. But basically its the same check as in mlock.c. Maybe its would be worth moving the inlines to mm.h. -Stefan Current output before: ... b778e000-b7790000 rw-p 00000000 00:00 0 bfdc8000-bfddd000 rw-p 00000000 ...

The PL08X include file is using struct tasklet so let us bring this in apropriately. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> --- include/linux/amba/pl08x.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h index 8435f4a..2bb7ac4 100644 --- a/include/linux/amba/pl08x.h +++ b/include/linux/amba/pl08x.h @@ -20,6 +20,7 @@ /* We need sizes of structs from this header */ #include ...

This change makes the PL08X not being a singleton anymore, this piece was missing earlier: we move the struct dma_device entries into the driver state holder. Also flag channels as slaves and fix up the channel freeing code. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> --- drivers/dma/amba-pl08x.c | 112 +++++++++++++++++++++++++------------------- include/linux/amba/pl08x.h | 2 + 2 files changed, 66 insertions(+), 48 deletions(-) diff --git a/drivers/dma/amba-pl08x.c ...

Since DMA jobs can be prepared and fired in IRQ context, request GFP_NOWAIT memory for the structs. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> --- drivers/dma/amba-pl08x.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c index 506749b..d1a4813 100644 --- a/drivers/dma/amba-pl08x.c +++ b/drivers/dma/amba-pl08x.c @@ -628,7 +628,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data ...

Sometimes oversubscribed channels fail to mux in a signal line for the transmission, and we bail out. Make sure we also clean out any pending txd lists when this happens. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> --- drivers/dma/amba-pl08x.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c index 65f595c..65892d5 100644 --- a/drivers/dma/amba-pl08x.c +++ b/drivers/dma/amba-pl08x.c @@ -1270,6 ...

This change makes the memcpy transfers wait for a physical channel to become available if no free channel is available when the job is submitted. When the first physical channel fires its tasklet, it will spin over the memcpy channels to see if one of these is waiting. This is necessary to get the memcpy semantics right: the generic memcpy API assume transfers never fail, and with our oversubscribed physical channels this becomes a problem: sometimes submit would fail. This fixes it by letting ...

This adds a debugfs file for the PL08X showing the current allocation of physical to virtual channels. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> --- drivers/dma/amba-pl08x.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 57 insertions(+), 0 deletions(-) diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c index 65892d5..a99ad19 100644 --- a/drivers/dma/amba-pl08x.c +++ b/drivers/dma/amba-pl08x.c @@ -68,6 +68,8 @@ #include ...

Changes since v3: - broken out separate patches adding time_change_notify syscall to arm, powerpc, x86, ia64, s390 and blackfin Changes since v2: - replaced sysfs interface with a syscall - added sysctl/procfs handle to set a limit to the number of users - fixed issues pointed out by Greg. Changes since v1: - updated against 2.6.36-rc1, - added notification/filtering options, - added Documentation/ABI/sysfs-kernel-time-notify interface description. Certain userspace applications ...

On Tue, 31 Aug 2010 14:45:51 +0300 System-call wiring for s390 looks good. Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com> -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --

Oops. Will do. --

Alexander Shishkin writes: > sys_time_change_notify() is a new syscall with number and types of > parameters such that no ARM-specific processing is needed. > > Tested with 2.6.36-rc3 using Documentation/time-change-notify-example.c. > > Signed-off-by: Alexander Shishkin <virtuoso@slind.org> > CC: Russell King <linux@arm.linux.org.uk> > CC: Andrew Morton <akpm@linux-foundation.org> > CC: David Howells <dhowells@redhat.com> > CC: Christoph Hellwig <hch@lst.de> > CC: "H. Peter ...

Signed-off-by: Alexander Shishkin <virtuoso@slind.org> CC: Tony Luck <tony.luck@intel.com> CC: Fenghua Yu <fenghua.yu@intel.com> CC: "David S. Miller" <davem@davemloft.net> CC: Arnaldo Carvalho de Melo <acme@redhat.com> CC: David Howells <dhowells@redhat.com> CC: Alexander Shishkin <virtuoso@slind.org> CC: linux-ia64@vger.kernel.org CC: linux-kernel@vger.kernel.org --- arch/ia64/include/asm/unistd.h | 3 ++- arch/ia64/kernel/entry.S | 1 + 2 files changed, 3 insertions(+), 1 ...

Fix VMLINUZ_LOAD_ADDRESS calculation to be based on the length of vmlinux.bin, the actual uncompressed kernel binary. Previously it was based on the length of KBUILD_IMAGE (the unstripped ELF vmlinux), which is bigger than vmlinux.bin. As a result, vmlinuz was loaded into a memory address higher then actually needed - a problem for small memory platforms. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> --- diff --git a/arch/mips/boot/compressed/Makefile ...

Hello, Linus. Please pull from the following branch to receive percpu fixes for v2.6.36-rc3. git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus The branch contains four patches. A memory leak in pcpu_extend_area_map() is fixed. The other three are sparse annotation and comment update. Thanks. Huang Shijie (1): percpu: fix a memory leak in pcpu_extend_area_map() Namhyung Kim (3): percpu: handle __percpu notations in UP accessors percpu: ...

ok, this one got no objection except original patch author. then, I'll push it to mainline. I'm glad that I who stabilization developer have finished this work. If you think this patch is slightly large, please run, % git diff a63d83f42^ mm/oom_kill.c you'll understand this is minimal revert of unnecessary change. Thanks. =================================================================== From 938ce3a7aa79ae4a6cbc275259d586086c41eb87 Mon Sep 17 00:00:00 2001 From: KOSAKI Motohiro ...

Hi, linux has supported nanosecond order file's timestamp since 2.5.48. However current file timestamp is got by current_fs_time() and is only updated once a tick. It can't say true nanosecond accuracy. In addition, gettimeofday() before a file operation updating {a,c,m}time would outstrip file's timestamp because of the difference about time source between gettimeofday() and file's timestamp. A certain kind of application would corrupted by this problem. I attached a most simple patch ...

Hello Michal, Sam, I did not see any further comments on the patch series about the initramfs cleanup and new size calculation. This is a resend and now I am asking you for your review and ack. Please let me know if you have questions or comments. Thanks and kind regards, Hendrik --

Remove initramfs_data.{lzo,lzma,gz,bz2}.S variants and use a common implementation in initramfs_data.S. The common implementation expects the file name of the initramfs to be defined in INITRAMFS_IMAGE. Change the Makefile to set the INITRAMFS_IMAGE define symbol according to the selected compression method. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> --- usr/Makefile | 6 ++++-- usr/initramfs_data.S | 5 +++-- usr/initramfs_data.bz2.S | 29 ...

This patch set adds (yet) another scheduling domain to the scheduler. The reason for this is that the recent (s390) z196 architecture has four cache levels and uniform memory access (sort of -- see below). The cpu/cache/memory hierarchy is as follows: Each cpu has its private L1 (64KB I-cache + 128KB D-cache) and L2 (1.5MB) cache. A core consists of four cpus with a 24MB shared L3 cache. A book consists of six cores with a 192MB shared L4 cache. The z196 architecture has no SMT. Also the ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> Create attributes /sys/devices/system/cpu/cpuX/topology/book_id /sys/devices/system/cpu/cpuX/topology/book_siblings which show the book id and the book siblings of a cpu. Unlike the attributes for SMT and MC these attributes are only present if CONFIG_SCHED_BOOK is set. There is no reason to pollute sysfs for every architecture with unused attributes. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- ...

From: Xing Wei <weixing@hanwang.com.cn> Add support for Art Master III tablet of BeiJing HanwangTechnology Co, Ltd. Signed-off-by: Xing Wei <weixing@hanwang.com.cn> --- Thanks for dmitry's comment & advice. And I removed the part -- "Make sure to say Y to 'Mouse support(CONFIG_INPUT_MOUSEDEV)' and/or 'Event interface support' (CONFIG_INPUT_EVDEV) as well" in the Kconfig. diff -uprN -X linux-2.6.35.3-vanilla/Documentation/dontdiff linux-2.6.35.3-vanilla/drivers/hid/hid-core.c ...

FYI, there's a new crash in the vnet driver that occasionally triggers on ordinary host bootups as well, when (non-virtualized) networking initializes: [ 86.563889] [<ffffffff81b05655>] page_fault+0x25/0x30 [ 86.569065] [<ffffffff8186d899>] ? vhost_poll_flush+0x11a/0x156 [ 86.575119] [<ffffffff8105f511>] ? kthread_stop+0xa/0x57 [ 86.580544] [<ffffffff8186e535>] vhost_dev_cleanup+0x269/0x271 [ 86.586528] [<ffffffff8186e974>] vhost_net_release+0x48/0x7f [ 86.592359] ...

Sure ! Just in case, I resubmit the patch, clearing dev->worker, because I am not sure if vhost_dev_cleanup() can be run several times on same struct vhost_dev. Patch is needed even if you add this check in kthread_stop() [PATCH v2] vhost: stop worker only if created Its currently illegal to call kthread_stop(NULL) Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> --- drivers/vhost/vhost.c | 5 ++++- 1 file changed, 4 insertions(+), 1 ...

Btw., i think this check should be pushed into kthread_stop() instead - just like kfree(NULL) is possible as well - it simplifies cleanup sequences. Thanks, Ingo --

The bad loader probably loads the image wrong (incorrect data or not whole image). regards, -- js --

Nope. It's code and data inside .init, .exit and similar sections. Those are marked by __init, __exit etc. in the code. This memory is freed after the kernel is up and running, since this memory (code and data) is not needed anymore. regards, -- js --

Hi all, Whenever the kernel starts booting, I am getting the bellow log : Memory: 110080k/262144k available (2566k kernel code, 151952k reserved, 561k data, 15328k init, 0k highmem). For 'init' on what bases this amount of memory is decided ? Anyways I can alter it? Thanks in advance, Prabhu --

NAK. We should not export SPI1 has x86 core has no way to access its register. though the device physically exists. Thanks, Feng On Tue, 31 Aug 2010 14:14:16 +0800 --

-- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |

Hi all, Changes since 20100830: My fixes tree contains: powerpc: don't use kernel stack with translation off The kvm tree lost its build failure. The net tree lost its build failure but gained another so I reverted a commit. I still have a patch to the drivers-x86 tree to remove a Kconfig warning. ---------------------------------------------------------------------------- I have created today's linux-next tree ...

From: Stephen Rothwell <sfr@canb.auug.org.au> I anticipated this and Fujita is working on a solution involving adding a CONFIG_DMA_ADDR_T_64BIT that the starfire can check instead of that ugly CPP test. --

Good move. I'm actually very inclined to move this into include/linux/input/. And you may try '-M' when generating patches with 'git format-patch', and --

I'd rather the irq handler not being changed and use platform_data instead. How about something below: diff --git a/arch/arm/mach-mmp/include/mach/pxa168.h b/arch/arm/mach-mmp/include/mach/pxa168.h index 27e1bc7..d2b7946 100644 --- a/arch/arm/mach-mmp/include/mach/pxa168.h +++ b/arch/arm/mach-mmp/include/mach/pxa168.h @@ -5,6 +5,7 @@ struct sys_timer; extern struct sys_timer pxa168_timer; extern void __init pxa168_init_irq(void); +extern void pxa168_clear_keypad_wakeup(void); ...

It seems good. Acked --

On Tue, Aug 31, 2010 at 12:53 AM, Haojian Zhuang Haojian, this is an usual case, but without that clear wake event you will not be able to clear the keypad interrupt. For my push to open source I re-wrote the workaround code and added it as a special case IRQ handler. In the Marvell pxa168 code base it is actually located in the keypad interrupt handler as the function clear_wakeup(). I felt it was better to isolate this code in the mmp common code base instead. Regards, -- Mark --

Eric, the boot-rom for pxa168 starts at 0xffff_0000. I am pretty sure about that! If you set the reset vector to 0x0 it will crash during reboot. I will send you xdb snapshots if you need me to. Regards, -- Mark --

The reset code is in below. .align 5 ENTRY(cpu_mohawk_reset) mov ip, #0 mcr p15, 0, ip, c7, c7, 0 @ invalidate I,D caches mcr p15, 0, ip, c7, c10, 4 @ drain WB mcr p15, 0, ip, c8, c7, 0 @ invalidate I & D TLBs mrc p15, 0, ip, c1, c0, 0 @ ctrl register bic ip, ip, #0x0007 @ .............cam bic ip, ip, #0x1100 @ ...i...s........ mcr p15, 0, ip, c1, c0, 0 @ ctrl register mov pc, r0 MMU is disabled at here and replace PC with r0 value. I doubt code executed correctly at ...

In early boot code, 1:1 (physical:virtual) mapping is used. It means that physical address is same as virtual address. So you can operature mmu as you wish. By the way, I don't suggest to reset CPU by this way. Reset is not only make code running from the head, it should also clear registers and RTL logic in CPU. --

On Tue, Aug 31, 2010 at 3:02 PM, Haojian Zhuang Depends on if pxa168 has a reset signal asserted from internal or from external GPIO, which is controllable from the CPU itself. That's what pxa is doing at this moment. --

On Tue, Aug 31, 2010 at 3:21 AM, Haojian Zhuang Haojian, That is true, I am planning to send an update to support watchdog timer reset soon. The problem is I need to test pxa910 and mmp2 as well and determine if the watchdog reset code is consistent. It was simpler for me to just fix this at the moment. --

It does depend on the prefetch unit for that. So the branch instruction --

On Tue, Aug 31, 2010 at 2:26 AM, Haojian Zhuang Haojian, I think there is a pipeline execution of the mov pc, r0 instruction. If I remember correctly you need to do a similar jump when you turn the MMU on in early boot code. If it makes any difference I did test this code on pxa168 before submitting it. I will double check the mmp2 and the pxa910 reset vectors with the Boot ROM developers. --

FYI, the MTD maintainer id dwmw2, I'm just helping him sometimes. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) --

From: Stephen Rothwell <sfr@canb.auug.org.au> ... I've checked the following into net-next-2.6 to combat-this (see, proactively fixing warnings in code I'm more or less responsible for instead of letting the issue rot for 2 months :-): -------------------- stmmac: Fix build warnings. In file included from drivers/net/stmmac/stmmac_ethtool.c:30: drivers/net/stmmac/stmmac.h:111: warning: 'struct platform_device' declared inside parameter list drivers/net/stmmac/stmmac.h:111: warning: its ...

Unable to reproduce it any more after applied the patch, NET: Registered protocol family 16 ACPI FADT declares the system doesn't support PCIe ASPM, so disable it ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 PCI: Using configuration type 1 for base access bio: create slab <bio-0> at 0 XXX kintegrityd: rescuer dispatching to cpu0 XXX kintegrityd: rescuer ...

If there are any inodes in the page cache that point to this superblock, a cleancache_put_page may happen asynchronously that grabs from page->...->i_sb->cleancache_poolid. If the cleancache_flush_fs races with it and another cleancache_init_fs happens after the cleancache_put_page gets the poolid, the poolid could be stale. Yeah, I decided to defer to Chris Mason's wisdom and left it. :-) --

I get a build error when I try to build this driver: drivers/staging/westbridge/astoria/block/../include/linux/westbridge/cyasmisc.h:521:2: error: expected declaration specifiers or ‘...’ before ‘cy_as_hal_device_tag’ It looks like the #include mess isn't working quite properly. Also note that this driver is building on an x86-64 platform, which is something that you probably don't want :) So, for now, I'll just mark the driver as CONFIG_BROKEN and can you send me some Kconfig patches ...

It's up to the Kconfig rules to ensure that there can never be a "non-correct" .config file, so that needs to be fixed so that the build will never be broken no matter what type of options are selected. Care to send a patch for that? thanks, greg k-h --

Arve, Are you planning to move this forward or is Greg going to? I've asked Greg (or you) for some changes to this.. If you have a problem with the changes please speak up .. The signed-off is wrong on this commit also, You need to sign off on the commit (and Greg if needed). Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --

Can you drop everything that's un-used .. There's also the enter/exit sleep functions, which I'm pretty sure aren't used. Also break this into two patches one for gpio and another for the interrupt component .. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --

Hi David, Allright, I will respin with those changes. Note that I chose to prefix the data structures with gen_ (for obvious C language reasons), I hope this is The board this driver is being used on had no SPI signals left I think, so it was hooked up on separate GPIO lines (which cannot be muxed to the GPIO pad). -- Florian --

Please drop this patch, I'll make a version that detects which type of endpoint it is and uses an interrupt or bulk URB as appropriate. Some devices which may/may not be compatible appear to have interrupt command endpoints as referenced in the original comment. -- Simon Arlott --

I didn't see that commit last year, but wouldn't it break devices like the ESI MIDI Mate whose descriptors want to have low-speed bulk transfers and where the driver has to submit interrupt transfers instead to get it to work at all? Regards, Clemens --

Reading this stuff again, I wonder if we should not revert commit 17762060c25590bfddd and use a different trick Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Mon Jul 5 21:29:28 2010 +0000 bridge: Clear IPCB before possible entry into IP stack The bridge protocol lives dangerously by having incestuous relations with the IP stack. In this instance an abomination has been created where a bogus IPCB area from a bridged packet leads to a crash in the IP ...

Once again, the IP stack -> bridge -> IP stack flow bites us, because bridge likes to dirty IPCB. We can correct every bug we find once in a while (you did in commit 17762060c255 for a particular bug), or just make bridge not touch IPCB. --

Bandan did not provide a full stack trace, but I believe the problem was : br_nf_dev_queue_xmit() -> ip_fragment -> icmp_send() -> ip_options_echo() : crash, because ip_options_echo take bridge CB as IPCB data. http://www.spinics.net/lists/netdev/msg139370.html --

Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --

Good. Except that we usually recommend to include files from include/linux if thye exist rather than asm/xxx I asked git: $ git grep kern_ | wc -l 962 $ git grep kernel_ | wc -l 6361 There seems to be preference for kernel_ Sam --

I would generally put the rcu lock outside the IRQ disabled section on the basis that it's better to keep the amount of time we have interrupts disabled 'Reported-by' might be more consistent with what others use. David --

Good points, how about the following? Thanx, Paul ------------------------------------------------------------------------ pid: make setpgid() system call use RCU read-side critical section [ 23.584719] [ 23.584720] =================================================== [ 23.585059] [ INFO: suspicious rcu_dereference_check() usage. ] [ 23.585176] --------------------------------------------------- [ 23.585176] kernel/pid.c:419 invoked rcu_dereference_check() without ...

Thanks, the fixed patch below. == From 6c61c97b5b85a350e3f195309b70a271457208ca Mon Sep 17 00:00:00 2001 From: Naohiro Aota <naota@elisp.net> Date: Fri, 27 Aug 2010 17:43:46 +0900 Subject: [PATCH 2/2] idr: describe how nextidp works in idr_get_next(). It was unclear in original kernel-doc how nextidp worked in idr_get_next(). Let's describe it. Signed-off-by: Naohiro Aota <naota@elisp.net> --- lib/idr.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git ...

Applied, thanks. -- Jiri Kosina SUSE Labs, Novell Inc. --

Ok :) --

Right. But one of the problems people have reported is that they can miss interrupts samples if they happen in idle. Hence we have decided that exclude_idle should exclude events that happen in idle process context but not in interrupts interrupting idle. So adding an in_interrupt() check would perhaps be better. I plan to do this exclusion using the per context exclusion, which is But yeah if we add an in_interrupt() check in perf_exclude_event(), it won't work here. This one ...

--

On Tue, Aug 31 2010 at 6:29am -0400, Still hit the hang on the 5th iteration of my test: while true ; do ./test_dm_discard_mpath.sh && sleep 1 ; done Would you like me to (re)send my test script offlist? INFO: task vgcreate:2617 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. vgcreate D ffff88007bf7ba00 4688 2617 2479 0x00000080 ffff88007bf7b998 0000000000000046 ffff880000000000 ffff88007bf7bfd8 ffff88005542a430 ...

Only in x86(32bit and 64bit) system. Did you patch it in power and test it? It' need more test for different archs, but I have no other arch. correct. A GP is also controled by a set ring counters in (domain's done_complete, this GP's complete], this GP is only completed until all these conters become zero. No. any rcu read site has a locked_complete, if a cpu hold a locked_complete, the counter of this locked_complete will not become zero. Any quiescent states will release its ...

In unexpected_thermal_interrupt(), "LVT TMR interrupt" is used in error message. I don't think TMR is a suitable abbreviation for thermal. 1.TMR has been used in IA32 Architectures Software Developer's Manual, and is the abbreviation for Trigger Mode Register. 2.There is not an standard abbreviation "TMR" defined for thermal in IA32 Architectures Software Developer's Manual. 3.Though we could understand it as Thermal Monitor Register, it is easy to be misunderstood as a ...

Hi Vivek, This patch doesn't break the original sheduling logic. That is cfqg => st => cfqq. If q1 and q2 in root group, I treat q1 and q2 bundle as a queue sched entity, and it will schedule on root group service with G1, as following: root group / \ qse(q1,q2) gse(G1) Thanks, --

Ok. That's interesting. That raises another question that how hierarchy should look like. IOW, how queue and groups should be treated in hierarchy. CFS cpu scheduler treats queues and group at the same level. That is as follows. root / | \ q1 q2 G1 In the past I had raised this question and Jens and corrado liked treating queues and group at same level. Logically, q1, q2 and G1 are all children of root, so it makes sense to treat them at same level and not group q1 ...

Sure it is not a very good argument but at the same time one would need a very good argument that why we should do things differently. - If a user has mounted cpu and blkio controller together and both the controllers are viewing the same hierarchy differently, then it is odd. We need a good reason that why different arrangement makes sense. - To me, both group and cfq queue are children of root group and it makes sense to treat them independent childrens instead of putting all the ...

Dear Rafael Wysocki, This regression still exists in 2.6.35.4. (I haven't tested 2.6.36-rcX series.) Kosaki Motohiro has kindly helped me with this issue and found a fix for the regression. Today I have successfully tested his patch, but I don't know whether the patch needs to be further refined and tested. Regards, M. Vefa Bicakci --

Thanks for the information. Do you have a pointer to the patch? Rafael --

On Tue, 31 Aug 2010 08:08:57 +0200 There certainly were people using it, which suggests maybe it needs looking at not binning. Alan --

Perhaps it's better to remove your name and set the status to Orphan instead. --

Are you sure about isicom: https://bugzilla.kernel.org/show_bug.cgi?id=11067 ? The last kernel he tried was 2.6.28 and there isicom sleeps forever in isicom_open. thanks, -- js suse labs --

Mostly locking - it's not a trivial entry point thing. The gs layer for example was full of races and needed rewriting so just got declared Did that several years ago. I think you still need to use the ioctl because several years is apparently a bit short for glibc to get with it Mostly done. See tty_port_* Alan --

The most important question is whether you think that there are people somewhere in the world that are using the device drivers on machines with recent kernels. If you still get bug reports for the drivers, that would be a clear indication to make them stay, while if you haven't heard from a user during the last five years, it's probably obsolete enough that it can be removed (after a few kernels of grace period in drivers/staging). Arnd --

And it is always possible to revert a removal at a later time and fix up a driver if someone does show up in a few years asking where the driver went. thanks, greg k-h --

Geert, can you comment on the 68k serial drivers? Which I'll leave isicom then. Specialix is marked in MAINTAINERS as supported by Roger, ip2 is maintained by Michael, maybe they have a preference for their drivers. Both drivers have a web page that is ~10 years old, which hints Not yet ;-) You didn't reply to my question why it couldn't be. I'll let Mike judge this one when he has looked at the hvc infrastructure. I wouldn't move it to that directory unless the code gets ...

On 20100831 14:46, Mike Fedyk wrote: > There is little reason not to use duplicate metadata. Only small > files (less than 2kb) get stored in the tree, so there should be no > worries about images being duplicated without data duplication set at > mkfs time. My benchmarks show that for my kinds of data, btrfs is somewhat slower than ext4, (which is slightly slower than ext3 which is somewhat slower than ext2), when using the defaults, (ie, duplicate metadata). It's a hair faster than ...

I have applied patch #1 and #2 to git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git core with some small modifications: Patch #1: Commit message, x86 removed. Patch #2: Order of freeing memory: +out: + if (ret) { + for_each_possible_cpu(cpu) + kfree(perf_events[cpu]); + kfree(counter_config); + } + There is also the patch below on top of it. Thanks Will, -Robert -- From ...

Ok, will change this. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center --

This is the patch, applied to: git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent -Robert -- From 10f0412f57f2a76a90eff4376f59cbb0a39e4e18 Mon Sep 17 00:00:00 2001 From: Robert Richter <robert.richter@amd.com> Date: Mon, 30 Aug 2010 10:56:18 +0200 Subject: [PATCH] oprofile, x86: fix init_sysfs error handling On failure init_sysfs() might not properly free resources. The error code of the function is not checked. And, when reinitializing the exit function might ...

Commit-ID: 7ac41ccf47d82569d26f34beab1dec92cc3b6347 Gitweb: http://git.kernel.org/tip/7ac41ccf47d82569d26f34beab1dec92cc3b6347 Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> AuthorDate: Mon, 30 Aug 2010 14:10:02 -0400 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Tue, 31 Aug 2010 08:06:10 +0200 x86, iommu: Fix IOMMU_INIT alignment rules This boot crash was observed: DMA-API: preallocated 32768 debug entries DMA-API: debugging enabled by kernel config BUG: unable ...

Yeah I know. This bit was to increase readability, explicitly showing the power state like this makes it more clear what is happening I think. The rest of the comments are fixed, new patch soon. Yours, Linus Walleij --

Do you really check it on your gcc? nr_swap_pages is not file scope variable, it's global variable. afaik, current gcc's link time optimization is not so cool. Do you have a disassemble list? --

On Tue, Aug 31, 2010 at 11:09 AM, KOSAKI Motohiro Thanks. -- Kind regards, Minchan Kim --

Hi, KOSAKI. On Tue, Aug 31, 2010 at 9:56 AM, KOSAKI Motohiro My intention is that smart gcc can compile out inactive_anon_is_low call in case of non swap configurable system. -- Kind regards, Minchan Kim --

It may be a good thing, since swap will often be freed again (when something is swapped in, or exits). Having some more anonymous pages sit on the inactive list gives them a chance to get used again, potentially giving us a better chance of preserving the working set when swap is full or near full a lot of the time. -- All rights reversed --

On Tue, Aug 31, 2010 at 9:56 AM, KOSAKI Motohiro Ying's one and mine both has a same effect. Only difference happens swap is full. My version maintains old behavior but Ying's one changes the behavior. I admit swap full is rare event but I hoped not changed old behavior if we doesn't find any problem. If kswapd does aging when swap full happens, is it a problem? We have been used to it from 2.6.28. If we regard a code consistency is more important than _unexpected_ result, Okay. I don't ...

Thanks, I'm convinced. --

applied to merge - k --

Model does have \0 at the end. This code is using strncmp to We use strcmp when parsing the device tree because the the length of the model property string is unknown and in most cases we *must* match the exact entire string, such as with this PowerMac7,2 example. Using strncmp would also happen to match with something like "PowerMac7,2345" which is not the desired behaviour. g. --

It seems to me that model has no '\0' in the end. If model is got from the hardware then we should double check it - maybe harware is buggy. Otherwise we'll overflow model. But why strcmp(model, "PowerMac7,2")? IMO it should be replaced with strncmp(). -- Vasiliy --

And here's a fix. Using current_thread_info() everywhere is better anyways, you are not supposed to touch the local_flags within anything but "current" so we may as well make it explicit. Feel free to fold that into your -rt patch and this one if you decide not to drop that whole part. diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 6ee4b09..6e8b6de 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -517,12 +517,12 @@ struct ...

Now I had done it the second way you described and everything seems to be working ok. aapi205:~# uname -r 2.6.36-rc3-20100831-1507-pz+ If there will be any problems I'll write here. Regards, Piotr Hosowicz -- Z cyklu "Uroki demokracji", czyli pytania i odpowiedzi w teledurniejach: - Który aktor amerykański jest mężem Nicole Kidman? - Forrest Gump. NP: Peter Green Splinter Group - You'll Be Sorry Someday NB: 2.6.36-rc3-20100831-1507-pz+ --

Indeed, those parts are only strictly needed for -rt, I was hoping the tiny bit of overhead wouldn't be too bad and we could keep it. If not I guess we should put those two bits in __switch_to() under Thanks! And yeah I'd prefer to keep it to reduce Thomas' burden if possible. --

If you can, it's best to just use code other people have already written :) If you can reboot the computer to test the memory, Memtest86+ is a well-known and very reliable tool which does just what you ask. You can obtain it from http://www.memtest.org/ There's some work done on an in-kernel memory tester, but testing memory while Linux is running is somewhat limited as there are sections of memory that you can't overwrite during testing. Take a look at CONFIG_MEMTEST and ...

For reviewers view, we are reviewing your patch to merge immediately if all issue are fixed. Then, I'm unhappy if you don't drop merge blocker item even though you merely want asking. At least, you can make separate thread, no? Of cource, wen other user also want to expose via /proc interface, we are resume this discusstion gradly. --

OK. May not get patch out today but will incorporate these fixes. Thank you again. mrubin --

Btw., because this is an older base, before we can push this to linux-next i suspect we'll need fixes for those architectures that did a memblock conversion in this cycle? Thanks, Ingo --

I can't access these bugs. Does that makes sense/work for you? http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=326c5fc3ea684825629ecca... Kay --

Exactly my patch :) --

I ask Harald (but he wasn't around and I don't know the answer) if it is a problem that this changes the behavior of non "add" events. Previously a non "add" event with an incorrect mask/uid/gid would have reset the SELinux context but now it will not. It fixes the issue at hand, my boxes boot with everything labeled nicely, but I'm not sure if there is some other corner case that expected the old behavior with change events.... -Eric --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NOOOOO libvirt is going in and changing fixed_disk_device_t:s0 to svirt_t:c0,c124 We do not want udev to see this and ask what label a device should have I think either figure out if the device is newly created versus modified -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - ...

Is there an easy test to differentiate? --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another option would be to check the label of the containing directory and if they match run the lsetfilecon, If they don't then leave it be. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkx9GGgACgkQrlYvE4MpobNwkgCgvzHFWYTZND+xMSukZXc1M+a0 fC4AoNaVap4UfoOoq1U+8X7JWYqktNHy =TljD -----END PGP SIGNATURE----- --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So the problem is happening because the kernel creates the device rather then udev, and then udev does not change the context because it can not differentiate between this and libvirt putting down a label. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkx9Da0ACgkQrlYvE4MpobOYKwCeK1IcX1z/B1lqMbkhYRTVNGsc o3gAn02Q+xVyfmRysEqvLT36ea3EUeHZ =3H/v -----END ...

Hi Rhyland, Following the naming used for other options in this menu, this would be Please remove, this doesn't add much value and is likely to get This structure doesn't seem terribly useful. You typically need the client to get to this information... And storing the device pointer as -EINVAL doesn't look like the right error code. -ENODEV or -EIO would seem more appropriate. Same issue several times, please address them You should pass down the exact error ...

Hi Dmitry, I can assure you that the keyboard is on the 8*18 GPIO matrix on the Nuvoton EC (only 8*16 being used in the current design). There certainly are 3 PS/2 ports on the EC, but in the board designs I have only one of those is used as a PS/2 port, and that is for the touchpad. The other two ports are muxed with GPIOs and the pins are being used as GPIOs for other functions, not PS/2 ports. The firmware on the EC converts keypresses on the GPIO matrix to scancodes and sends ...

Brad, Roland - Thank you for your comments and your work on this. Agreed. Alexander --

Thanks, applied. Alex --

----- Original Message ----- From: "Grant Likely" <grant.likely@secretlab.ca> To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com> Cc: "Thomas Gleixner" <tglx@linutronix.de>; <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "David Brownell" <dbrownell@users.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>; <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; "Tomoya MORINAGA" <morinaga526@dsn.okisemi.com>; "David Woodhouse" <dwmw2@infradead.org>; ...

----- Original Message ----- From: "Grant Likely" <grant.likely@secretlab.ca> To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com> Cc: "Thomas Gleixner" <tglx@linutronix.de>; <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "David Brownell" <dbrownell@users.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>; <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; "Tomoya MORINAGA" <morinaga526@dsn.okisemi.com>; "David Woodhouse" <dwmw2@infradead.org>; ...

Brownell" <dbrownell@users.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>; <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; "Tomoya MORINAGA" How should we register spi_device information ? Thanks, Ohtake(OKISemi) --

----- Original Message ----- From: "Grant Likely" <grant.likely@secretlab.ca> To: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com> Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "David Brownell" <dbrownell@users.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>; <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; "Tomoya MORINAGA" <morinaga526@dsn.okisemi.com>; "Thomas Gleixner" <tglx@linutronix.de>; "David Woodhouse" ...

Thanks for your explanation. It's ok. Regards, Weidong --

Justin, There were no changes in the driver other than to force a 60 second I/O timeout. You probably have a udev rule that was already giving you 60 second timeouts for all scsi devices, so this patch did absolutely nothing. More likely is that there is an I/O pattern change between the kernels that is causing a 3ware firmware issue (or drive firmware issue) on your configuration. I have forwarded your case to 3ware firmware support. -Adam --

Per my earlier message, both cards were resetting, scsi0 and scsi1 under kernel 2.6.35(.x), with 2.6.34, the lag problem is gone and my machine is back to normal again. It is unlikely that both cards would be at fault, in addition I spent several hours trying different things, removing the BBU modules for example, but always staying on the 2.6.35 kernel. I am now able to run rss2email (which ALWAYS caused the machine to lockup and freeze until one of the controllers reset) without any ...

Hi again, Yes. Something like re-programming the context. but it would make sure that the module draws no power at all. Also, would it not be correct to include a cancel_work_sync in case of return here? +fail4: + misc_deregister(&chip->miscdev); +fail3: + ak8974_regulators_off(chip); +fail2: + regulator_bulk_free(ARRAY_SIZE(chip->regs), chip->regs); +fail1: + kfree(chip); + return err; +} Cheers! --

Is i_ino == 0 a valid inode number? If not, then Acked-by: Steven Rostedt <rostedt@goodmis.org> --

From: Andreas Herrmann <andreas.herrmann3@amd.com> The file names are somehow misleading as the code is not specific to AMD K8 CPUs anymore. The files accomodate code for other AMD CPU northbridges as well. Same is true for the config option which is valid for AMD CPU northbridges in general and not specific to K8. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> --- arch/x86/Kconfig | 4 +- arch/x86/include/asm/amd_nb.h | 39 +++++++++ ...

Following patches are against tip/master as of v2.6.36-rc3-1233-gf3d0a67 Patch 1 sets the correct dependency to K8_NB for L3 cache index disable code Patch 2 allows separate handling of gart and AMD northbridges Patch 3 renames k8.[ch] and CONFIG_K8_NB to the more appropriate amd_nb.[ch] and CONFIG_AMD_NB Please apply. Thanks, Andreas --

There's certainly already weird behaviors you can cause by regular filesystem over-mounts on NFS. For example, I have an NFS server that exports a "/srv/git" directory; if I was to do the following actions on a client: # mkdir /srv/git # mount -t nfs myserver:/srv/git /srv/git # mkdir /srv/git/mnt # mount -t ext3 /dev/sda3 /srv/git/mnt And then from the server I were to: # rmdir /srv/git/mnt Terrible terrible things would happen... by which I mean I can no longer access or unmount ...

No, I don't think this design will do that. So it might be enough just to document that online modification of upper or lower filesystems results in undefined behavior. But to prevent accidental damage, it's prudent (at least by default) to enforce the no-modification policy. Why do you think this feature of allowing modification is important? Lets take some typical use cases: - live cd: lower layer is hard r/o, upper layer makes no sense to modify online - thin client: lower ...

Remind me again why mounting the filesystem '-oro' on the server (and possibly exporting it 'ro') isn't an option? Trond --

Now I get it! For throughput we need to do a sum. Ok, we need sum comparator/performance aggregaters too! Do we also need to figure out the max throughput and warn if the pm_qos requests are going over? I suppose the network stack could register each device with a max bus bandwidth and pm_qos could warn on exceeding I need to think on this a bit. You are correct, and it looks like we thanks for the example! it really helped me to understand the issue better. --mark --

That's orthogonal to this patch series, however. I'm dealing with IRQ flags management, not hardirq support. Out of interest, will the m68knommu arch be integrated into the m68k arch at some point? It's certainly possible to have an arch that is bimodal in this aspect (FRV has CONFIG_MMU as a config option). David --

Sure, will do! Thanks. --

These names are actually the names of types of performance counters, not a specific cpu. All SH-4 cpus that have performance counters have 7750-style performance counters and all SH-4A cpus have SH-4A-style counters. It's unlikely we'd have to update this code in the near future. Paul, OK, seeing as the two architectures that will use this initially don't require wrappers I've no problem doing it your way. It can always be extended later if necessary. And more importantly, with a ...

Ok, we don't need it if we add architectural dependencies to Kconfig No, but with that implementation we always have to update the cpu string with each new cpu though nothing else changes. We may keep this code. But, shouldn't we return a default string "sh/<name>" for all other cases? We will then need to update only the oprofile userland I am not sure if we need such wrappers, and if so we could implement it anyway, e.g.: oprofile_perf_init(perf_ops, name, num_events); ...

Actually, that would probably happen automatically. If you are working on a subsystem, you should probably be working against the git tree for that subsystem. When something is done in the todo list, the subsystem tree would be updated with the commit that does said change. Then, the list is maintained outside of mainline (in the subsystem git tree) and will automatically update mainline in the next merge window when the tree is pulled. -- Steve --

Seriously, given the known history of Documentation/feature-removal-schedule.txt, I don't think this is going to work. Thanks, Rafael --

There are already reasonable mechanisms for this. It's perfectly fine to have multiple T: entries, one for a current tree, another for a -next tree. SECTION - name M: who <email.address> T: git <url> T: git <url-next> F: dir/file_pattern Linus rarely seems to object to pulling Documentation updates. Note the Documentation updates after any -rc2 $ for ((i=25 ; i<36 ; i++)) ; do \ cv=v2.6.$i-rc2..v2.6.$i ; \ echo -n "$cv: " ; \ git log --pretty=oneline --no-merges $cv -- ...

Excellent stuff. I didn't look at your vmstat output because it was for an old patch and you have already highlighted the problems related to the workload. Chances are, I'd just reach the same conclusions. What is Ok, well there was some significant feedback on why wholesale changing of congestion_wait() reached too far and I've incorporated that feedback. I also integrated your workload into my testsuite (btw, because there is no license the script has to download it from a google archive. I ...

This is in per-thread mode. This is what happens when you do perf record foo for instance. This is sampling, but you can do --

This is a gigabit You aren't going to modify this text after the product is released, are you? Topcliff PCH is the platform controller hub that is used in Intel's -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

Perhaps this is clearer. Signed-off-by: Joe Perches <joe@perches.com> --- drivers/net/pch_gbe/pch_gbe.h | 6 +++--- drivers/net/pch_gbe/pch_gbe_main.c | 33 +++++++++++++++++---------------- 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/drivers/net/pch_gbe/pch_gbe.h b/drivers/net/pch_gbe/pch_gbe.h index a615ddc..a2b2c55 100644 --- a/drivers/net/pch_gbe/pch_gbe.h +++ b/drivers/net/pch_gbe/pch_gbe.h @@ -638,9 +638,9 @@ struct pch_gbe_adapter { struct ...

I find hard to believe this driver needs to copy all outgoing frames on pre-allocated skbs. + /* [Header:14][payload] ---> [Header:14][paddong:2][payload] */ + memcpy(tmp_skb->data, skb->data, ETH_HLEN); + tmp_skb->data[ETH_HLEN] = 0x00; + tmp_skb->data[ETH_HLEN + 1] = 0x00; + tmp_skb->len = skb->len; + memcpy(&tmp_skb->data[ETH_HLEN + 2], &skb->data[ETH_HLEN], + (skb->len - ETH_HLEN)); + buffer_info->kernel_skb = skb; + ...

This fix is incorrect. In this patch, a previous error prevents from adding any further devices. There shouldn't be such dependency among the devices. Thanks. -Fenghua --

Hi Jin Even though you are lucky that in the end it still works, this check is misplaced. You should instead have: if (cpu_has(c, X86_FEATURE_PLN)) { err = sysfs_add_file_to_group(&sys_dev->kobj, &attr_package_power_limit_count.attr, thermal_attr_group.name); if (err) goto error; -- Jean Delvare --

I don't think there is dependency among the count files, i.e. failure to add a count file to the group shouldn't impact other files. Other filles can still be added to the group. In this case, user application only sees part of count numbers. And kernel may just warn on the failure instead of providing nothing to user. In the patch, any failure to add a file will remove the whole group. This is too strict. Kernel doesn't provide any count number to user application. Agree with you that such ...

I don't know all the specifics of the virtio driver and the KVM backend but don't the KVM target io is eventually directed to a local file or device? If so the scsi device has disappeard but the bulk of the data is in host cache at the backstore (file or bdev). Once all files are closed the data is synced to disk. Is it not the same as Ric's problem of disconnecting the sata cable but Thanks Boaz --

Hello, There are two layers of caching there. drive cache - host page cache - guest When guest issues FLUSH, qemu will translate it into fdatasync which will flush the host page cache followed by FLUSH to the drive which will flush the drive cache to the media. If you delete the host disk device, it will be detached w/o host page cache flushed. So, although it's not complete, it will lose good part of cache. With out write out timeout increased and/or with laptop mode enabled, it ...

$ echo 1 > /sys/block/sdX/device/delete $ echo - - - > /sys/class/scsi_host/hostX/scan should do the trick. Thanks. -- tejun --

On Wed, 25 Aug 2010 17:11:40 +0900 Reviewed-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> It might be better to update this comment too. /* Update file-stat data for mem_cgroup */ or something ? Thanks, Daisuke Nishimura. --

On Wed, 25 Aug 2010 17:10:50 +0900 It doesn't cause any problem, but I think it would be better to change this to "id_to_memcg(..., false)". It's just under rcu_read_lock(), not under page_cgroup lock anymore. Otherwise, it looks good to me. Reviewed-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Thanks, Daisuke Nishimura. --

I cc'ed Santosh as well. I'm not sure whether TI are using a Cortex-A9 Maybe __v7_ca9mp_setup. Future MP processors from ARM may not need this We could restrict it to: .long 0x410fc090 .long 0xff0ffff0 Otherwise the patch looks fine. Thanks. -- Catalin --

Thanks, I'll test this to make sure it doesn't break x86, and then push it into a stable/-rc patch queue. --

Ingo has applied it already in perf/urgent. Thanks. --

Hmm, I never saw the tip-bot reply :-( I guess it only sends to the Cc tags. -- Steve --

Hi, Mike On Wed, 25 Aug 2010 07:56:01 +0200 I'm interested in this problem, because I hit the same problem in RHEL6 beta2. (It based on 2.6.32) Are you writing a patch to solving this problem? If you are doing, I can test it in RHEL6 beta2 (or latest). Appendix. I could reproduce this problem without ltp. See below.(case 1) But if cpus are not completely busy, it couldn't occure.(case 2) [case1] 1) Run busy loop process (number of cpu) in same cpu cgroup. 2) attach process to ...

This doesn't actually solve the problem, and gpiochip should remain undefined when CONFIG_GPIOLIB=n to catch exactly these build failures. The real problem is that I merged a change into the mpc5200 code that required CONFIG_GPIOLIB be enabled without reflecting that requirement in Kconfig. --

Looking even closer, we're both wrong. You're right I didn't look carefully enough, and the error is in of_gpio.h, not the .c file. However, it is not okay to get the definitions from of_gpio.h when CONFIG_GPIOLIB=n. If GPIOLIB, or more specifically OF_GPIO isn't set, then the of_gpio.h definitions should either not be defined, or should be defined as empty stubs (where appropriate). So, instead of adding a forward declarations of the struct, the correct thing I think to do is to #ifdef ...

Commit-ID: 3aaba20f26f58843e8f20611e5c0b1c06954310f Gitweb: http://git.kernel.org/tip/3aaba20f26f58843e8f20611e5c0b1c06954310f Author: Li Zefan <lizf@cn.fujitsu.com> AuthorDate: Mon, 23 Aug 2010 16:50:12 +0800 Committer: Steven Rostedt <rostedt@goodmis.org> CommitDate: Tue, 31 Aug 2010 16:46:23 -0400 tracing: Fix a race in function profile While we are reading trace_stat/functionX and someone just disabled function_profile at that time, we can trigger this: divide error: 0000 ...

The TRACE_IRQFLAGS was originally written for lockdep, but it is now used by Ftrace's irqsoff tracer. I just compiled and booted with TRACE_IRQFLAGS=y and PROVE_LOCKING not set, and it worked fine. I think the correct patch is to remove the dependency of TRACE_IRQFLAGS on PROVE_LOCKING. -- Steve --

Ah a non-movable page allocation could fall back into the movable zone. See __rmqueue_fallback() and the fallbacks[][] array. So the if (type != MIGRATE_MOVABLE && !pageblock_free(page)) check in is_mem_section_removable() is correct. It is set_migratetype_isolate() that should be fixed to use the same check. Thanks, Fengguang --

You don't have strong reasons to remove the free pages test, so why not keep it? We never know what the user will do. He may regretted immediately after onlining a node, and want to offline it.. Some hackers may want to offline some 128MB memory blocks (by chance) with the help of drop_caches. Thanks, --

Yes, I will try to do that. thanks, greg k-h --

Nope, sorry. I got sick and combined with vacation requirements from the family, and my "real job" and other things lately, I hope to get to it by the end of this week. If not, kick me, I'll have time on a trans-continent flight next week that should give me plenty of time to do this... thanks, greg k-h --

This breaks the build, are you sure you tested it after making the patch? thanks, greg k-h --

It's already on its way, see <http://permalink.gmane.org/gmane.linux.raid/29357>. Andreas. -- Andreas Schwab, schwab@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." --

Thanks. I didn't spot that since it came after my report and didn't reference it (so it didn't appear in my searches). --

Hello! I have applied the patches you mentioned, and rebuilt and tested the 2.6.35.4 kernel. I am really happy to say that your patches (cumulatively) fixed the issue! Unfortunately, because the hibernation is rather quick, I am having a hard time getting screen-shots with my camera. If you would like, I can try to put some sleeps around the code so that I can get the output for you. For the record, the attached patch is the cumulative version of all of your patches. It applies cleanly ...

Great! I've attached more verbose debug message patch and trial bug fixing patch.

<spi-devel-general@lists.sourceforge.net>; "Wang, Qi" <qi.wang@intel.com>; "Wang, Yong Y" <yong.y.wang@intel.com>; Topcliff doesn't have register which shows the number of spi bus interfaces. This multi-channel code is for other IOH device's. Thus, I think there is not another way except for hard coding. I understand. We will move mutex variable into private data structure. Thanks, Ohtake(OKISEMI) --

Even if an arch defines the override for the sysfs dir size, I still don't think this breaks anything (it shouldn't). We move _all_ of the directories over, all at once, to a single, uniform size. The only apparent change to a user moving kernels would be a larger block_size_bytes (which is certainly not changing the ABI) and a new sysfs file for the end of the section. The new sysfs file is _completely_ redundant at this point. The architecture is only supposed to bump up the directory ...

Maybe I'm just a weirdo, but I don't really use modules much. That effectively means that I'm stuck at boot with one zram device. Making it a read-only module param also means that someone can't add a second at runtime while the first is still in use. It doesn't seem to be used very pervasively, but there is a module_param_cb() function so you can register callbacks when the param gets updated. Might come in handy for this. -- Dave --

Yes, this_cpu_add() seems sufficient. I can't recall why I used u64_stats_* but if it's not required for atomic access to 64-bit then why was it added to the mainline in the first place? Thanks, Nitin --

IMHO, this_cpu_read() is fine as is : a _read_ operation. Dont pretend it can be used in every context, its not true. --

"Pristine" is not a word which non native speaker have in its vocabulary. Quick-format is the best, because it is exactly what it is The user never knows what he is doing, believe me that is what live This did not work in our NSN transport environment. It would take to much time to explain why, because the PCU software managment server is a 10 year old application which handles a wide range of transport boards in the same way, including the old JFFS2 systems and the new UBIFS based Never ...

Yes, I think so. Unless there are objections, I intend to merge this (with the review fixes) through net-2.6 together with a vhost-net patch I think it doesn't affect anything except 2.6.36-rcX, --

Hey Peter, I was wondering if you have time to take a look at this? The patchset introduces a driver which takes care of allowing pci_conf_read/write in a virtualized environements with PCI passthrough devices. Unfortunatly for MSI operations that is not so simple, so this patch alongside with the previous one (https://patchwork.kernel.org/patch/117105/) expands the arch_* calls. This makes it possible to register on top --

I'm reposting this patch series as v4 since there have been no additional comments, and I cleaned up one extra bit of unneeded code (in 3/3). The patches are against Linus's tree: 2bfc96a127bc1cc94d26bfaa40159966064f9c8c (2.6.36-rc3). Would this patchset be suitable for inclusion in an mm branch? This changes adds a partition_meta_info struct which itself contains a union of structures that provide partition table specific metadata. This change leaves the union empty. The subsequent patch ...

It does sounds like there is some variety, then. Thank you for the info! Thanx, Paul --

That's just horrible, move it to the right like it was, just don't add the extra spaces where they are not needed. And think, why would you want to cast from an unsigned long and then to an unsigned int, something is really wrong with that code, it should be fixed properly. Care to try again? thanks, greg k-h --

Hi Stephen. What I submitted I think reasonable. He can extract what he wants if he prefers it done that way. cheers, Joe --

Hi all, Can we have a fix for these please? They make too much noise in the builds. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

From: Joe Perches <joe@perches.com> Exactly, he's the maintainter so if he wants something fixed a specific way he can do it as he likes. --

A straight forward port to QT4 using qt3to4 and compiling against qt3support * Use pkg-config to detect QT4 which is hopefully portable enough * If no QT4, QT3 will by tried instead * Classes renamed using qt3to4 * If build using QT3 renamed to QT3 class names using defines * ConfigInfoView::menu has to be renamed as QT4 moc strips struct from struct menu and creates a name conflict * QT2 support has been dropped * The hidden options inserted in ...

Hi, On Mon, 30 Aug 2010 15:43:52 -0700, Dmitry Torokhov I disagree. If the device is used as input and currently app developers have to find other ways to use such input data, having a standard interface other than input layer will just make the mess standardized, but it will still Why are we trying to overengineer on such simple devices ? Wasn't it so that we will design and implement solutions when the problem arrives ? Why are we trying to think of all cases such a simple it might ...

> IIO which is currently in staging. Except we had ALS before that as a layer and Linus vetoed it. So there is zero faith in IIO ever going anywhere. Instead we now have about ten different light sensor APIs to the point developers are writing a toolkit userspace plugin for *each* sensor. --

I have more faith - those developing it have limited time, but we will get there. (another plug for anyone interested to get involved!) IIRC Linus and others disliked ALS for two reasons... * It was too specific. They didn't want to fragment sensors types that much. * Userspace is used to dealing input and in some cases a light sensor can look like a switch. The first certainly doesn't apply to IIO, the second will be fixed via an input bridge. I agree. This is a big problem. We have in ...

Probably because most of these devices have nothing to do with industrial That tends to make little sense where the API is the same and applications benefit enormously from consistency. I'd rather have an input->IIO bridge because that is the real world today ! The question is what does the API make *sense* for. Not what can you use the API for. Unix (and Linux) are enormously powerful because of the use of common interfaces and APIs. So a voltmeter really makes no sense. It's not a set ...

linux-iio cc'd for comments on the code dump at end of email.. Hmm.. The 'industrial' bit is somewhat misleading. Ultimately it was the best name anyone came up with a while ago. Happy to change it if someone Really basic proof of concept at bottom of this email... It's nasty and not remotely general. General version will be a bit longer. This is just a hack combining the lis3l02dqbuffersimple.c example and a uinput example googling gave me... I have no idea if I got the uinput It covered ...

One thing I forgot to mention. IIO uses two different paths for what become events in input. The main data stream (which is predictable) comes via the buffer interface handled here. Threshold type events (and all the weird and wonderful variants) come via a second chrdev if the device supports them. These are trivial to add to the below and I'll put them in the generalized version (basically a second fd and a call to select + a big translation table - which may want to --

IMHO I think sensors no more can be considered as non-input-devices. Things changed too much in recent years. Input "sources" have now a very different use as before (smartphones, Tablets and handheld devices...) They all have much inputs that come mostly from sensors. So the definition of an input device is something that the user can interact on it ? Maybe we should consider input devices to be made from 1 to N sensors with some filtering blocks which only expose the useful data. If we ...

Hi, Maxim, Could you send out thermal zone info under /proc/acpi/thermal_zone/TZ*? Thanks. -Fenghua --

In the attachment is an updated version of uio_jand. The module uio_jand.ko can be inserted and removed, no messages visible by dmesg, no kernel oops, no dev/uio* and no class entries available. There are only entries of uio_jand in /sys/module, /sys/bus/platform/drivers and /sys/uio/holders ... I'm really confused =:-/ It's completely unclear how to write the initial platform_data of the platform device in the example uio_smx.c : regs = platform_get_resource(dev, ...

That doesn't make sense. uio_pdrv/uio_pdrv_genirq both need some help Yes, of course. It doesn't make sense for distros to ship these modules. Both are useful only for developers who build there own kernels and add What you did was in general the right thing. Find the reason for that oops and fix it. Thanks, Hans --

I'm not sure what "the sites where the regulators were actually enabled/disabled in respective driver" are but my understanding was that there's a bit of an issue here in that the MMC core does not guarantee balanced enable/disable calls. --