[PATCH] cpufreq: core: Fix typo in comment describing show_bios_limit()
show_bios_limit is mistakenly written as show_scaling_driver in a comment describing purpose of show_bios_limit() routine. Fix it. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index fb8a527..021973b 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -581,7 +581,7 @@ static ssize_t show_scaling_setspeed(struct cpufreq_policy *policy, char *buf) } /** - * show_scaling_driver - show the current cpufreq HW/BIOS limitation + * show_bios_limit - show the current cpufreq HW/BIOS limitation */ static ssize_t show_bios_limit(struct cpufreq_policy *policy, char *buf) { -- 1.7.12.rc2.18.g61b472e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] regulator: tps65090: add external control support for DCDC
On Tue, Oct 09, 2012 at 11:51:19AM +0530, Laxman Dewangan wrote: > On Tuesday 09 October 2012 11:58 AM, Mark Brown wrote: > >There's support for GPIO driven enable lines in the framework already, > >this driver should be able to use this happily, this sort of hardware is > >exactly the use case it was written for. > yes, I am using the gpio driven enable lines in the framework. > This patch does the some configuration in register to enable external > control and configure the regulator_config (fill gpio related stuff > in config) before registering > the regulator. There is no call of gpio libs from the driver. The code seemed way more complex than that... did you notice the fact that if a GPIO is specified then the register enable/disable control will be ignored if provided? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 9, 2012 at 12:19 PM, Mark Brown > It seems better to punt that decision to callers - for example, the case In fact, -ENOENT is returned to caller for non-direct loading situation, see_request_firmware_load(). I understand drivers(caller) may be cheated if a zero-length firmware image is obtained. In normal situation, one firmware image should include something, instead of nothing, :-) > I ran into this with was a driver that was using a zero length firmware > to say that it didn't want to load an optional image but also didn't > want to have to time out if that was the case. That doesn't seem If so, I am wondering why the driver has to call request_firmware()? Looks just bypassing request_firmware() is fine for the driver, doesn't it? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.5 regression / mcs7830 / bisected] bridge constantly toggeling between disabled and forwarding
On Tuesday 09 October 2012, Michael Leun wrote: > On Thu, 27 Sep 2012 10:39:05 -0700 > > Greg KH wrote: > > On Tue, Jul 24, 2012 at 01:36:34AM +0200, Michael Leun wrote: > > > On Mon, 23 Jul 2012 09:15:04 +0200 > > > Michael Leun wrote: > > > > > > [see issue description below] > > > > > > Bisecting yielded > > > > > > b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 is the first bad commit > > > commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 > > > Author: Ondrej Zary > > > Date: Fri Jun 1 10:29:08 2012 + > > > > > > mcs7830: Implement link state detection > > > > > > Add .status callback that detects link state changes. > > > Tested with MCS7832CV-AA chip (9710:7830, identified as rev.C > > > by the driver). Fixes > > > https://bugzilla.kernel.org/show_bug.cgi?id=28532 > > > > > > Signed-off-by: Ondrej Zary > > > Signed-off-by: David S. Miller > > > > > > :04 04 5480780cb5e75c57122a621fc3bab0108c16be27 > > > > > > d97efd9cc0a465dff76bcd3a3c547f718f2a5345 Mdrivers > > > > > > > > > Reverting that from 3.5 makes the issue go away. > > > > Did this ever get resolved in 3.6-rc7 or any older kernel? I can't > > revert the patch from 3.5.y unless it's also fixed in Linus's tree. > > Please excuse me for answering a bit late. > > No, that never got resolved, I still have the problem with 3.6 but I'm > not shure about the correct solution. > > Maybe link state detection just does not work with some of that devices > and we should have an possibility to enable/disable it per device, > maybe it can be handeled with an blacklist of not working devices, > maybe it could be fixed - I do not know and also do not know how to > find out. > > But I'm willing to test. Does the problem appear only in a bridge? Or the link state detection is completely wrong? -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> -Original Message- > From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] > Sent: Tuesday, October 09, 2012 4:23 AM > To: Jaegeuk Kim > Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; > gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; > jooyoung.hw...@samsung.com; > linux-fsde...@vger.kernel.org > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > Hi, > > On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote: > > >> -Original Message- > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] > >> Sent: Sunday, October 07, 2012 9:09 PM > >> To: Jaegeuk Kim > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; > >> gre...@linuxfoundation.org; linux- > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; > >> jooyoung.hw...@samsung.com; > >> linux-fsde...@vger.kernel.org > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > >> > >> Hi, > >> > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: > >> > -Original Message- > From: Marco Stornelli [mailto:marco.storne...@gmail.com] > Sent: Sunday, October 07, 2012 4:10 PM > To: Jaegeuk Kim > Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; > gre...@linuxfoundation.org; > linux-kernel@vger.kernel.org; chur@samsung.com; > cm224@samsung.com; > >> jooyoung.hw...@samsung.com; > linux-fsde...@vger.kernel.org > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: > > 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: > >> Hi Jaegeuk, > > > > Hi. > > We know each other, right? :) > > > >> > >>> From: 김재극 > >>> To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' > >>> , > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > chur@samsung.com, > >> cm224@samsung.com, > jaegeuk@samsung.com, jooyoung.hw...@samsung.com > >>> Subject: [PATCH 00/16] f2fs: introduce flash-friendly > >>> file system > >>> Date: Fri, 05 Oct 2012 20:55:07 +0900 > >>> > >>> This is a new patch set for the f2fs file system. > >>> > >>> What is F2FS? > >>> = > >>> > >>> NAND flash memory-based storage devices, such as SSD, eMMC, and SD > >>> cards, have > >>> been widely being used for ranging from mobile to server systems. > >>> Since they are > >>> known to have different characteristics from the conventional > >>> rotational disks, > >>> a file system, an upper layer to the storage device, should adapt to > >>> the changes > >>> from the sketch. > >>> > >>> F2FS is a new file system carefully designed for the NAND flash > >>> memory-based storage > >>> devices. We chose a log structure file system approach, but we tried > >>> to adapt it > >>> to the new form of storage. Also we remedy some known issues of the > >>> very old log > >>> structured file system, such as snowball effect of wandering tree and > >>> high cleaning > >>> overhead. > >>> > >>> Because a NAND-based storage device shows different characteristics > >>> according to > >>> its internal geometry or flash memory management scheme aka FTL, we > >>> add various > >>> parameters not only for configuring on-disk layout, but also for > >>> selecting allocation > >>> and cleaning algorithms. > >>> > >> > >> What about F2FS performance? Could you share benchmarking results of > >> the new file system? > >> > >> It is very interesting the case of aged file system. How is GC's > >> implementation efficient? > Could > you share benchmarking results for the very aged file system state? > >> > > > > Although I have benchmark results, currently I'd like to see the results > > measured by community as a black-box. As you know, the results are very > > dependent on the workloads and parameters, so I think it would be better > > to see other results for a while. > > Thanks, > > > > 1) Actually it's a strange approach. If you have got any results you > should share them with the community explaining how (the workload, hw > and so on) your benchmark works and the specific condition. I really > don't like the approach "I've got the results but I don't say anything, > if you want a number, do it yourself". > >>> > >>> It's definitely right, and I meant *for a while*. > >>> I just wanted to avoid arguing with how to age file system in this time. > >>> Before then, I share the primitive results as follows. > >>> > >>> 1. iozone in Panda board > >>> - ARM A9 > >>> - DRAM : 1GB > >>> - Kernel: Linux 3.3 > >>> - Partition: 12GB (64GB Samsung eMMC) > >>> - Tested on 2GB f
Re: [Patch v2 2/7] Regulator: DA9055 Regulator driver
On Mon, Oct 08, 2012 at 07:00:39PM +0530, Ashish Jangam wrote: Mostly OK, but there's a few issues including yet more reimplementation of framework features. > +static int da9055_list_voltage(struct regulator_dev *rdev, > + unsigned int selector) > +{ > + struct da9055_regulator *regulator = rdev_get_drvdata(rdev); > + struct da9055_regulator_info *info = regulator->info; > + int volt_uV; > + > + volt_uV = (selector * info->step_uV) + info->min_uV; > + > + if (volt_uV > info->max_uV) > + return -EINVAL; > + > + return volt_uV; > +} This is regulator_list_voltage_linear() > +static int da9055_map_voltage(struct regulator_dev *rdev, > + int min_uV, int max_uV) > +{ > + struct da9055_regulator *regulator = rdev_get_drvdata(rdev); > + struct da9055_regulator_info *info = regulator->info; > + int ret, sel; > + > + ret = verify_range(info, min_uV, max_uV); > + if (ret < 0) > + return ret; > + > + if (min_uV < info->min_uV) > + min_uV = info->min_uV; > + > + sel = DIV_ROUND_UP(min_uV - info->min_uV, info->step_uV); > + > + ret = da9055_list_voltage(rdev, sel); > + if (ret < 0) > + return ret; > + > + return sel; > +} This is regulator_map_voltage_linear(). > + int gpio = pdata->gpio_base + pdata->gpio_ren[id]; > + sprintf(name, "DA9055 REG %d STATE", id); snprintf(). > + /* Set the GPIO I/P pin for controlling the regulator state. */ > + ret = devm_gpio_request_one(config->dev, gpio, GPIOF_DIR_IN, > + name); > + if (ret < 0) > + goto err; We never actually appear to use this GPIO anywhere... why are we requesting it? Also, why is the ability to read the regulator state via a GPIO associated with controlling it via a GPIO, it's unusual for these things to be tied together. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 09, 2012 at 03:05:30PM +0800, Ming Lei wrote: > On Tue, Oct 9, 2012 at 12:19 PM, Mark Brown > > It seems better to punt that decision to callers - for example, the case > In fact, -ENOENT is returned to caller for non-direct loading situation, > see_request_firmware_load(). > I understand drivers(caller) may be cheated if a zero-length firmware > image is obtained. In normal situation, one firmware image should > include something, instead of nothing, :-) Hrm, that didn't seem to be happening for me - the firmware load completed successfully. Have to check how that happened. > > I ran into this with was a driver that was using a zero length firmware > > to say that it didn't want to load an optional image but also didn't > > want to have to time out if that was the case. That doesn't seem > If so, I am wondering why the driver has to call request_firmware()? > Looks just bypassing request_firmware() is fine for the driver, doesn't it? A driver has no way to tell if the firmware is there or not without asking for it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] time: cast ->raw_interval to u64 to avoid shift overflow
We fixed a bunch of integer overflows in timekeeping code during the 3.6 cycle. I did an audit based on that and found this potential overflow. Signed-off-by: Dan Carpenter --- I'm not super familiar with this code so please review my work carefully. diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 5ce06a3..1d1ee67 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1113,7 +1113,7 @@ static cycle_t logarithmic_accumulation(struct timekeeper *tk, cycle_t offset, accumulate_nsecs_to_secs(tk); /* Accumulate raw time */ - raw_nsecs = tk->raw_interval << shift; + raw_nsecs = (u64)tk->raw_interval << shift; raw_nsecs += tk->raw_time.tv_nsec; if (raw_nsecs >= NSEC_PER_SEC) { u64 raw_secs = raw_nsecs; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.5 regression / mcs7830 / bisected] bridge constantly toggeling between disabled and forwarding
On Tuesday 09 October 2012, Michael Leun wrote: > On Thu, 27 Sep 2012 10:39:05 -0700 > > Greg KH wrote: > > On Tue, Jul 24, 2012 at 01:36:34AM +0200, Michael Leun wrote: > > > On Mon, 23 Jul 2012 09:15:04 +0200 > > > Michael Leun wrote: > > > > > > [see issue description below] > > > > > > Bisecting yielded > > > > > > b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 is the first bad commit > > > commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 > > > Author: Ondrej Zary > > > Date: Fri Jun 1 10:29:08 2012 + > > > > > > mcs7830: Implement link state detection > > > > > > Add .status callback that detects link state changes. > > > Tested with MCS7832CV-AA chip (9710:7830, identified as rev.C > > > by the driver). Fixes > > > https://bugzilla.kernel.org/show_bug.cgi?id=28532 > > > > > > Signed-off-by: Ondrej Zary > > > Signed-off-by: David S. Miller > > > > > > :04 04 5480780cb5e75c57122a621fc3bab0108c16be27 > > > > > > d97efd9cc0a465dff76bcd3a3c547f718f2a5345 Mdrivers > > > > > > > > > Reverting that from 3.5 makes the issue go away. > > > > Did this ever get resolved in 3.6-rc7 or any older kernel? I can't > > revert the patch from 3.5.y unless it's also fixed in Linus's tree. > > Please excuse me for answering a bit late. > > No, that never got resolved, I still have the problem with 3.6 but I'm > not shure about the correct solution. > > Maybe link state detection just does not work with some of that devices > and we should have an possibility to enable/disable it per device, > maybe it can be handeled with an blacklist of not working devices, > maybe it could be fixed - I do not know and also do not know how to > find out. > > But I'm willing to test. Can you please apply this debug patch and provide the output? --- a/drivers/net/usb/mcs7830.c +++ b/drivers/net/usb/mcs7830.c @@ -638,6 +638,7 @@ static void mcs7830_status(struct usbnet *dev, struct urb *urb) return; link = !(buf[1] & 0x20); + printk("netif_carrier_ok=%d, link=%d, buf[0]=0x%02x, buf[1]=0x%02x\n", netif_carrier_ok(dev->net), link, buf[0], buf[1]); if (netif_carrier_ok(dev->net) != link) { if (link) { netif_carrier_on(dev->net); -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] x86, xen, mm: fix mapping_pagetable_reserve logic
On 10/09/2012 02:33 PM, Yinghai Lu wrote: >> >> make_range_readwrite is particularly toxic, though, because it makes it >> sound like it something along the lines of set_memory_rw(), which it >> most distinctly is not. > > it just change some page range from RO back to RW. > > so how about update_range_ro_to_rw? > You're focusing on what the low-level mechanics of one particular implementation (Xen) of the hook, and then try to make it describe the hook itself. What the hook does, if I am reading it correctly, is take a range that used to be page tables and turn it back to "ordinary memory". As such, assuming I'm following the logic correctly, something like pagetable_unreserve() seems like a reasonable name. However, why during initialization, why do we have to unreserve memory that has already been reserved for pagetables? (Keep in mind there may very well be an entirely sensible answer for that question -- I just can't tell from the patchset without a much more in-depth analysis. Keep in mind that that in-depth analysis sucks up time, and it doesn't scale to expect the maintainer to have to do that.) >> >> Magic variables augmented with more magic variables. Why? This also >> seems to assume that we still do all the kernel page tables in one >> chunk, which is exactly what we don't want to do. > > for 64bit, page table will be three parts > 1. initial page table from arch/x86/kernel/head_64.S > 2. page table from BRK. > 3. page near end of RAM. > > verified from /sys/kernel/debug/kernel_page_tables > > only range E820_RAM is mapped. > > all initial page table for hole between [0, 1G) get cleared too. > No, this is wrong, and more importantly, your choice of data structures encode this. There should not be any requirement for the page tables near the end of RAM to be contiguous -- consider the case of a memory hole near the end of RAM, or a large-memory machine where memory is highly discontiguous and we have to use more than one chunk before we run out. Then the questions become: 1. do we *have* to have this tracking at all? Obviously we have to know this memory is in use, but memblock reserve should take care of that. 2. if we do, please use a data structure which can handle an arbitrary number of ranges. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
On Mon, 8 Oct 2012 23:59:07 -0700 Jonathan Nieder wrote: > Feng Tang wrote: > > Jonathan Nieder wrote: > > >> What would go wrong if the threshold were just increased to 20 on all > >> models? > > > > Then some other platform will stop to work. > > https://bugzilla.kernel.org/show_bug.cgi?id=11892 > > > > The 26/30 and 27/30 patches are bound together to fix one bug. Some > > quote from description from the 26th patch: > > > > ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and > > was changed to 8 in 2.6.28 commit 06cf7d3c7 "ACPI: EC: lower interrupt storm > > threshold" to fix kernel bug 11892 by forcing the laptop in that bug to > > work in polling mode. > > > > Hope this answers your question. > > Thanks much. Yes, that clarifies. > > The magic numbers are not too thrilling. If the polling mode just > doesn't work on the Clevo M720, why isn't the appropriate storm > threshold 99 or infinity rather than 20? Do we know why the > polling mode doesn't work? I don't know why it doesn't work, if you check the https://bugzilla.kernel.org/show_bug.cgi?id=45151 you'll see the debugging model is test result --> patch --> 1-2 weeks + result --> patch --> 1-2 weeks + result ... over and over, which makes it difficult to root cause it but provide a workaround. And frankly speaking, I'm not sure if I can figure it out 100% even if I had that HW at hand. As per my understanding, EC is very tricky, as OS, ACPI FW, EC FW, BIOS will all access it without a global lock (in most cases), which makes it hard to work properly without race condition. Not mentioning its hardware may be broken. Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] virtio-net: inline header support
Il 09/10/2012 06:59, Rusty Russell ha scritto: > Paolo Bonzini writes: >> Il 05/10/2012 07:43, Rusty Russell ha scritto: >>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I >>> said to Anthony, the best rules are "always" and "never", so I'd really >>> rather not have to grandfather that in. >> >> It is, but we can add a rule that if the (transport) flag >> VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in >> virtio-blk. > > Could we do that? It's the cmd length I'm concerned about; is it always > 32 in practice for some reason? It is always 32 or less except in very obscure cases that are pretty much confined to iSCSI. We don't care about the obscure cases, and the extra bytes don't hurt. BTW, 32 is the default cdb_size used by virtio-scsi. > Currently qemu does: > > struct sg_io_hdr hdr; > memset(&hdr, 0, sizeof(struct sg_io_hdr)); > hdr.interface_id = 'S'; > hdr.cmd_len = req->elem.out_sg[1].iov_len; > hdr.cmdp = req->elem.out_sg[1].iov_base; > hdr.dxfer_len = 0; > > If it's a command which expects more output data, there's no way to > guess where the boundary is between that command and the data. Yep, so I understood the problem right. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 9, 2012 at 3:13 PM, Mark Brown wrote: >> If so, I am wondering why the driver has to call request_firmware()? >> Looks just bypassing request_firmware() is fine for the driver, doesn't it? > > A driver has no way to tell if the firmware is there or not without > asking for it. Yes, I agree, and my question is only on what you mentioned: "it didn't want to load an optional image" maybe I misunderstood the above, never mind, :-) So one driver should suppose the firmware is there, and the firmware shouldn't be zero length, because the driver always expects getting some bytes by calling request_firmware(). Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/06] input/rmi4: Public header and documentation
On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny wrote: > As requested in the feedback from the previous patch, we've documented the > debugfs and sysfs attributes in files in Documentation/ABI/testing. There's > two files, one for debugfs and one for sysfs. This is a massive improvement! Atleast as far as I've read... If you fix the below remarks I think I'm ready to accept this file, but that's just me and doesn't say anything about what Dmitry et al will comment on... (...) > + The RMI4 driver implementation exposes a set of informational and control > + parameters via debugs. These parameters are those that typically are only s/debugs/debugfs (...) > + comms_debug - (rw) Write 1 to this dump information about register > + reads and writes to the console. Write 0 to this to turn > + this feature off. WARNING: Imposes a major performance > + penalty when turned on. > + irq_debug - (rw) Write 1 to this dump information about interrupts > + to the console. Write 0 to this to turn this feature off. > + WARNIG: Imposes a major performance penalty when turned on. Hm. Usually we control dynamic debug prints by standard kernel frameworks, can you tell what is wrong with this and why you need a custom mechanism? See the following: Documentation/dynamic-debug-howto.txt http://lwn.net/Articles/434833/ (...) > +++ b/Documentation/ABI/testing/sysfs-rmi4 (...) > + chargerinput ... (rw) User space programs can use this to tell the > + sensor that the system is plugged into an external power > + source (as opposed to running on batteries). This allows > + the sensor firmware to make necessary adjustments for the > + current capacitence regime. Write 1 to this when the > + system is using external power, write 0 to this when the > + system is running on batteries. See spec for full details. I remember discussing in-kernel notifiers for this. I don't really see the point in tunnelling a notification from the drivers/power subsystem to the drivers/input subsystem through userspace for no good. It's no blocker though, I don't expect you to fix this as part of this driver submission. Maybe Anton can comment? (...) > + interrupt_enable ... (ro) This represents the current RMI4 > interrupt > + mask (F01_RMI_Ctrl1 registers). See spec for full details. What does the userspace have to do with this stuff? Seems way too low-level, but whatever. (...) > + sleepmode ... (rw) Controls power management on the device. > Writing > + 0 to this parameter puts the device into its normal > operating > + mode. Writing 1 to this parameter fully disables touch > + sensors and similar inputs - no touch data will be reported > + from the device in this mode. Writing 2 or 3 to this > device > + may or may not have an effect, depending on the particular > + device - see the product specification for your sensor for > + details. Usually power management is controlled from kernelspace, but no big deal, maybe userspace knows even more details in some cases. > + unconfigured ... (ro) This is the opposite of the configured bit, > + described above. So why is it needed? Isn't it implicit from the "configured" property if this is 0 then it's unconfigured? Seems superfluous. (...) > +++ b/include/linux/rmi.h (...) > +#ifdef CONFIG_RMI4_DEBUG > +#include > +#endif Don't include it conditionally, always just include it whether you use it or not. It doesn't hurt, and doesn't cause compile problems. (...) > +/** > + * struct rmi_device_platform_data_spi - provides paramters used in SPI s/paramters/parameters/ > + * communitcations. All Synaptics SPI products support a standard SPI s/communitcations/communications > + * @cs_assert - For systems where the SPI subsystem does not control the > CS/SSB > + * line, or where such control is broken, you can provide a custom routine to > + * handle a GPIO as CS/SSB. This routine will be called at the beginning and > + * end of each SPI transaction. The RMI SPI implementation will wait > + * pre_delay_us after this routine returns before starting the SPI transfer; > + * and post_delay_us after completion of the SPI transfer(s) before calling > it > + * with assert==FALSE. Hm hm, can you describe the case where this happens? Usually we don't avoid fixes for broken drivers by duct-taping solutions into other drivers, instead we fix the SPI driver. I can think of systems where CS is asserted not by using GPIO but by poking some special register for example, which is a valid reason for including this, but working around broken SPI drivers is not a valid reason to include this. (Pagin
Re: [PATCH] video: imxfb: Do not crash on reboot
On Mon, Oct 08, 2012 at 10:35:36AM -0300, Fabio Estevam wrote: > Issuing a "reboot" command after the LCD times out causes the following > warnings: > > Requesting system reboot > [ cut here ] > WARNING: at drivers/clk/clk.c:471 clk_disable+0x24/0x50() > Modules linked in: > [] (unwind_backtrace+0x0/0xf4) from [] > (warn_slowpath_common+0x48/0x60) > [] (warn_slowpath_common+0x48/0x60) from [] > (warn_slowpath_null+0x1c/0x24) > [] (warn_slowpath_null+0x1c/0x24) from [] > (clk_disable+0x24/0x50) > [] (clk_disable+0x24/0x50) from [] > (imxfb_disable_controller+0x48/0x7c) > [] (imxfb_disable_controller+0x48/0x7c) from [] > (platform_drv_shutdown+0x18/0x1c) > [] (platform_drv_shutdown+0x18/0x1c) from [] > (device_shutdown+0x48/0x14c) > [] (device_shutdown+0x48/0x14c) from [] > (kernel_restart_prepare+0x2c/0x3c) > [] (kernel_restart_prepare+0x2c/0x3c) from [] > (kernel_restart+0xc/0x48) > [] (kernel_restart+0xc/0x48) from [] > (sys_reboot+0xc0/0x1bc) > [] (sys_reboot+0xc0/0x1bc) from [] > (ret_fast_syscall+0x0/0x2c) > ---[ end trace da6b502ca79c854f ]--- > [ cut here ] > WARNING: at drivers/clk/clk.c:380 clk_unprepare+0x1c/0x2c() > Modules linked in: > [] (unwind_backtrace+0x0/0xf4) from [] > (warn_slowpath_common+0x48/0x60) > [] (warn_slowpath_common+0x48/0x60) from [] > (warn_slowpath_null+0x1c/0x24) > [] (warn_slowpath_null+0x1c/0x24) from [] > (clk_unprepare+0x1c/0x2c) > [] (clk_unprepare+0x1c/0x2c) from [] > (imxfb_disable_controller+0x50/0x7c) > [] (imxfb_disable_controller+0x50/0x7c) from [] > (platform_drv_shutdown+0x18/0x1c) > [] (platform_drv_shutdown+0x18/0x1c) from [] > (device_shutdown+0x48/0x14c) > [] (device_shutdown+0x48/0x14c) from [] > (kernel_restart_prepare+0x2c/0x3c) > [] (kernel_restart_prepare+0x2c/0x3c) from [] > (kernel_restart+0xc/0x48) > [] (kernel_restart+0xc/0x48) from [] > (sys_reboot+0xc0/0x1bc) > [] (sys_reboot+0xc0/0x1bc) from [] > (ret_fast_syscall+0x0/0x2c) > ---[ end trace da6b502ca79c8550 ]--- > [ cut here ] > > This happens because "reboot" triggers imxfb_shutdown(), which calls > imxfb_disable_controller with the clocks already disabled. > > To prevent this, add a clock enabled status so that we can check if the clocks > are enabled before disabling them. > > Signed-off-by: Fabio Estevam > --- > drivers/video/imxfb.c | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) > > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c > index f3363b2..6acf98a 100644 > --- a/drivers/video/imxfb.c > +++ b/drivers/video/imxfb.c > @@ -134,6 +134,7 @@ struct imxfb_info { > struct clk *clk_ipg; > struct clk *clk_ahb; > struct clk *clk_per; > + int enabled; I didn't really know the driver, but I wonder if the name "enabled" is a tad too generic. Maybe better "clks_enabled"? Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: use module_i2c_driver to simplify the code
On 10/08/2012 04:09 PM, Wei Yongjun wrote: From: Wei Yongjun Use the module_i2c_driver() macro to make the code smaller and a bit simpler. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun Acked-by: Michael Hennerich --- drivers/mfd/adp5520.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/mfd/adp5520.c b/drivers/mfd/adp5520.c index ea8b947..94e7a6d 100644 --- a/drivers/mfd/adp5520.c +++ b/drivers/mfd/adp5520.c @@ -360,17 +360,7 @@ static struct i2c_driver adp5520_driver = { .id_table = adp5520_id, }; -static int __init adp5520_init(void) -{ - return i2c_add_driver(&adp5520_driver); -} -module_init(adp5520_init); - -static void __exit adp5520_exit(void) -{ - i2c_del_driver(&adp5520_driver); -} -module_exit(adp5520_exit); +module_i2c_driver(adp5520_driver); MODULE_AUTHOR("Michael Hennerich "); MODULE_DESCRIPTION("ADP5520(01) PMIC-MFD Driver"); -- Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] mm/swap: automatic tuning for swapin readahead
Hugh Dickins wrote: On Thu, 4 Oct 2012, Konstantin Khlebnikov wrote: Here results of my test. Workload isn't very realistic, but at least it threaded: compiling linux-3.6 with defconfig in 16 threads on tmpfs, 512mb ram, dualcore cpu, ordinary hard disk. (test script in attachment) average results for ten runs: RA=3RA=0RA=1RA=2RA=4HughShaohua real time 500 542 528 519 500 523 522 user time 738 737 735 737 739 737 739 sys time93 93 91 92 96 92 93 pgmajfault 62918 110533 92454 78221 54342 86601 77229 pgpgin 2070372 795228 1034046 1471010 3177192 1154532 1599388 pgpgout 2597278 2022037 2110020 2350380 2802670 2286671 2526570 pswpin 462747 138873 202148 310969 739431 232710 341320 pswpout 646363 502599 524613 584731 697797 568784 628677 So, last two columns shows mostly equal results: +4.6% and +4.4% in comparison to vanilla kernel with RA=3, but your version shows more stable results (std-error 2.7% against 4.8%) (all this numbers in huge table in attachment) Thanks for doing this, Konstantin, but I'm stuck for anything much to say! Shaohua and I are both about 4.5% bad for this particular test, but I'm more consistently bad - hurrah! I suspect (not a convincing argument) that if the test were just slightly different (a little more or a little less memory, SSD instead of hard disk, diskcache instead of tmpfs), then it would come out differently. Yes, results depends mostly on tmpfs. Did you draw any conclusions from the numbers you found? Yeah, I have some ideas: Numbers for vanilla kernel shows strong dependence between time and readahead size. Seems like main problem is that tmpfs does not have it's own readahead, it can only rely on swap-in readahead. There are about 25% readahead hits for RA=3. As "pswpin" row shows both your and Shaohua patches makes readahead smaller. Plus tmpfs doesn't keeps copy for clean pages in the swap (unlike to anon pages). On swapin path it always marks page dirty and releases swap-entry. I didn't have any measurements but this particular test definitely re-reads some files multiple times and writes them back to the swap after that. I haven't done any more on this in the last few days, except to verify that once an anon_vma is judged random with Shaohua's, then it appears to be condemned to no-readahead ever after. That's probably something that a hack like I had in mine would fix, but that addition might change its balance further (and increase vma or anon_vma size) - not tried yet. All I want to do right now, is suggest to Andrew that he hold Shaohua's patch back from 3.7 for the moment: I'll send a response to Sep 7th's mm-commits mail to suggest that - but no great disaster if he ignores me. Hugh Numbers from your tests formatted into table for better readability HDD Vanilla Shaohua RA=3RA=0RA=4 SEQ, ANON 73921 76210 75611 121542 77950 SEQ, SHMEM 73601 73176 73855 118322 73534 RND, ANON 895392 831243 871569 841680 863871 RND, SHMEM 1058375 1053486 827935 756489 834804 SDD Vanilla Shaohua RA=3RA=0RA=4 SEQ, ANON 24634 24198 24673 70018 21125 SEQ, SHMEM 24959 24932 25052 69678 21387 RND, ANON 43014 26146 28075 25901 28686 RND, SHMEM 45349 45215 28249 24332 28226 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 3.6.0 kernel BUG at fs/dcache.c:967 during shutdown / restart
On Mon 08-10-12 17:10:52, Neil Salstrom wrote: > On 10/08/2012 10:14 AM, Jan Kara wrote: > >On Sat 06-10-12 10:20:26, Neil Salstrom wrote: > >>I've not submitted a kernel bug before but I've read the bug > >>reporting pages. I'll try to do my best and if you need more > >>information please let me know. Please feel free to cc me on the > >>answer or if you have questions. > >> > >>I'm using Linux Mint 13 (64 bit) on AMD hardware with a self > >>compiled 3.6.0 kernel for my MythTV HTPC. > >> > >>Kernel version: Linux version 3.6.0 (gcc version 4.6.3 > >>(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Tue Oct 2 15:34:46 PDT 2012 > >> > >>CPU: model name : AMD A6-3500 APU with Radeon(tm) HD Graphics > >> > >>If you need any other system variables please let me know and I can > >>get those as well. > >> > >>Upon shutdown or restart (from either the hard button on the case or > >>a "sudo shutdown -r now" the system crashes and does not actually > >>shut down. I can ssh in to the system and a dmesg shows the > >>following: > > There should be a line like: > >BUG: Dentry ... still in use (%d) [unmount of %s %s] > > > >just before the oops. Can you please post that one as well? Also I see that > >you are using nvidia module which taints the kernel. Can you try > >reproducing the issue without the module loaded? > > > > Honza > > Here is the full output with no nvidia module. I also have the full > dmeg from start to finish if you would like it. Thanks for the new report. Since the use count of the problematic dentry is 1, I guess this is really some bug in rpc_pipefs. Bruce, any idea? Honza > [ 237.186167] BUG: Dentry 880118772540{i=6e,n=info} still in > use (1) [unmount of rpc_pipefs rpc_pipefs] > [ 237.186179] [ cut here ] > [ 237.186181] kernel BUG at fs/dcache.c:967! > [ 237.186182] invalid opcode: [#1] SMP > [ 237.186185] Modules linked in: nls_utf8 udf crc_itu_t nfsv4 > binfmt_misc nfsd nfs_acl auth_rpcgss nfs fscache lockd sunrpc > snd_hda_codec_hdmi snd_hda_codec_realtek xfs snd_hda_intel > snd_hda_codec snd_seq_midi snd_hwdep snd_rawmidi snd_pcm psmouse > snd_seq_midi_event rc_imon_mce serio_raw snd_seq imon rc_core > snd_timer snd_seq_device snd soundcore snd_page_alloc f71882fg r8169 > ahci libahci > [ 237.186203] CPU 2 > [ 237.186206] Pid: 3063, comm: umount Not tainted 3.6.0 #1 System > manufacturer System Product Name/F1A55-M LX PLUS > [ 237.186208] RIP: 0010:[] [] > shrink_dcache_for_umount_subtree+0x1e6/0x1f0 > [ 237.186214] RSP: 0018:8801181afd98 EFLAGS: 00010296 > [ 237.186215] RAX: 005d RBX: 880118772540 RCX: > 14bd > [ 237.186217] RDX: 3256 RSI: 0046 RDI: > 81bbf9bc > [ 237.186218] RBP: 8801181afdb8 R08: 000a R09: > > [ 237.186219] R10: 0383 R11: 0382 R12: > 88011873b9c0 > [ 237.186220] R13: 8801177a2b80 R14: 8801177a2bb0 R15: > 88011287d800 > [ 237.186222] FS: 7f67049b1800() GS:88011ed0() > knlGS: > [ 237.186223] CS: 0010 DS: ES: CR0: 8005003b > [ 237.186225] CR2: 7f3e1de8 CR3: 000118a18000 CR4: > 07e0 > [ 237.186226] DR0: DR1: DR2: > > [ 237.186227] DR3: DR6: 0ff0 DR7: > 0400 > [ 237.186229] Process umount (pid: 3063, threadinfo > 8801181ae000, task 880110fbc440) > [ 237.186230] Stack: > [ 237.186231] 88011287db50 88011873b780 88011287d800 > a021d3c0 > [ 237.186233] 8801181afdd8 8116de93 0001 > 88011287d800 > [ 237.186235] 8801181afe08 811583bc 88011873b820 > 0015 > [ 237.186238] Call Trace: > [ 237.186241] [] shrink_dcache_for_umount+0x33/0x60 > [ 237.186244] [] generic_shutdown_super+0x2c/0xf0 > [ 237.186247] [] kill_anon_super+0x16/0x30 > [ 237.186249] [] kill_litter_super+0x27/0x30 > [ 237.186265] [] rpc_kill_sb+0x99/0xc0 [sunrpc] > [ 237.186268] [] deactivate_locked_super+0x3c/0xa0 > [ 237.186270] [] deactivate_super+0x4e/0x70 > [ 237.186273] [] mntput_no_expire+0x106/0x160 > [ 237.186276] [] sys_umount+0x6e/0x3b0 > [ 237.186279] [] system_call_fastpath+0x1a/0x1f > [ 237.186280] Code: 00 00 48 8b 40 28 4c 8b 08 48 8b 43 30 48 85 c0 > 74 04 48 8b 50 40 48 89 34 24 48 c7 c7 48 69 7c 81 48 89 de 31 c0 e8 > 09 62 40 00 <0f> 0b 0f 0b 66 0f 1f 44 00 00 55 48 89 e5 41 54 53 66 > 66 66 66 > [ 237.186301] RIP [] > shrink_dcache_for_umount_subtree+0x1e6/0x1f0 > [ 237.186303] RSP > [ 237.186320] ---[ end trace 74629a120592ec3c ]--- > [ 238.707925] mtrr: no MTRR for f900,e0 found > [ 245.162939] imon:send_packet: task interrupted > [ 245.218338] nfsd: last server has exited, flushing ex
Re: [PATCH v3 3/3] acpi : acpi_bus_trim() stops removing devices when failing to remove the device
Hi, ishimatsu: At 07/12/2012 07:28 PM, Yasuaki Ishimatsu Wrote: > acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error > number. But acpi_bus_remove() cannot return error number correctly. > acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if > device cannot be removed correctly, acpi_bus_trim() ignores and continues to > remove devices. acpi_bus_hot_remove_device() uses acpi_bus_trim() for removing > devices. Therefore acpi_bus_hot_remove_device() can send "_EJ0" to firmware, > even if the device is running on the system. In this case, the system cannot > work well. So acpi_bus_trim() should check whether device was removed or not > correctly. The patch adds error check into some functions to remove the > device. What is the status about this patch? Vasilis Liaskovitis found a similar bug about the memory hotplug, and this patch can fix this problem: https://lkml.org/lkml/2012/9/26/318 Thanks Wen Congyang > > Signed-off-by: Yasuaki Ishimatsu > > --- > drivers/acpi/scan.c| 15 --- > drivers/base/dd.c | 22 +- > include/linux/device.h |2 +- > 3 files changed, 30 insertions(+), 9 deletions(-) > > Index: linux-3.5-rc6/drivers/acpi/scan.c > === > --- linux-3.5-rc6.orig/drivers/acpi/scan.c2012-07-12 20:11:37.316443808 > +0900 > +++ linux-3.5-rc6/drivers/acpi/scan.c 2012-07-12 20:17:17.927185231 +0900 > @@ -425,12 +425,17 @@ static int acpi_device_remove(struct dev > { > struct acpi_device *acpi_dev = to_acpi_device(dev); > struct acpi_driver *acpi_drv = acpi_dev->driver; > + int ret; > > if (acpi_drv) { > if (acpi_drv->ops.notify) > acpi_device_remove_notify_handler(acpi_dev); > - if (acpi_drv->ops.remove) > - acpi_drv->ops.remove(acpi_dev, acpi_dev->removal_type); > + if (acpi_drv->ops.remove) { > + ret = acpi_drv->ops.remove(acpi_dev, > +acpi_dev->removal_type); > + if (ret) > + return ret; > + } > } > acpi_dev->driver = NULL; > acpi_dev->driver_data = NULL; > @@ -1208,11 +1213,15 @@ static int acpi_device_set_context(struc > > static int acpi_bus_remove(struct acpi_device *dev, int rmdevice) > { > + int ret; > + > if (!dev) > return -EINVAL; > > dev->removal_type = ACPI_BUS_REMOVAL_EJECT; > - device_release_driver(&dev->dev); > + ret = device_release_driver(&dev->dev); > + if (ret) > + return ret; > > if (!rmdevice) > return 0; > Index: linux-3.5-rc6/drivers/base/dd.c > === > --- linux-3.5-rc6.orig/drivers/base/dd.c 2012-07-12 20:11:37.316443808 > +0900 > +++ linux-3.5-rc6/drivers/base/dd.c 2012-07-12 20:17:17.928185218 +0900 > @@ -464,9 +464,10 @@ EXPORT_SYMBOL_GPL(driver_attach); > * __device_release_driver() must be called with @dev lock held. > * When called for a USB interface, @dev->parent lock must be held as well. > */ > -static void __device_release_driver(struct device *dev) > +static int __device_release_driver(struct device *dev) > { > struct device_driver *drv; > + int ret; > > drv = dev->driver; > if (drv) { > @@ -482,9 +483,11 @@ static void __device_release_driver(stru > pm_runtime_put_sync(dev); > > if (dev->bus && dev->bus->remove) > - dev->bus->remove(dev); > + ret = dev->bus->remove(dev); > else if (drv->remove) > - drv->remove(dev); > + ret = drv->remove(dev); > + if (ret) > + goto rollback; > devres_release_all(dev); > dev->driver = NULL; > klist_remove(&dev->p->knode_driver); > @@ -494,6 +497,12 @@ static void __device_release_driver(stru >dev); > > } > + > + return ret; > + > +rollback: > + driver_sysfs_add(dev); > + return ret; > } > > /** > @@ -503,16 +512,19 @@ static void __device_release_driver(stru > * Manually detach device from driver. > * When called for a USB interface, @dev->parent lock must be held. > */ > -void device_release_driver(struct device *dev) > +int device_release_driver(struct device *dev) > { > + int ret; > /* >* If anyone calls device_release_driver() recursively from >* within their ->remove callback for the same device, they >* will deadlock right here. >*/ > device_lock(dev); > - __device_release_driver(dev); > + ret = __device_release_driver(dev); > device_unlock(dev); > + > + return ret; > } > EXPORT_SYMBOL_GPL(devic
RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
--- Jaegeuk Kim Samsung > -Original Message- > From: Namjae Jeon [mailto:linkinj...@gmail.com] > Sent: Tuesday, October 09, 2012 12:52 PM > To: Jaegeuk Kim > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu; > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > chur@samsung.com; cm224@samsung.com; > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > 2012/10/8, Jaegeuk Kim : > >> -Original Message- > >> From: Namjae Jeon [mailto:linkinj...@gmail.com] > >> Sent: Monday, October 08, 2012 8:22 PM > >> To: Jaegeuk Kim > >> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; > >> ty...@mit.edu; > >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > >> chur@samsung.com; cm224@samsung.com; > >> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > >> > >> 2012/10/8, Jaegeuk Kim : > >> >> -Original Message- > >> >> From: Namjae Jeon [mailto:linkinj...@gmail.com] > >> >> Sent: Monday, October 08, 2012 7:00 PM > >> >> To: Jaegeuk Kim > >> >> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; > >> >> ty...@mit.edu; > >> >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > >> >> chur@samsung.com; cm224@samsung.com; > >> >> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > >> >> > >> >> 2012/10/8, Jaegeuk Kim : > >> >> >> -Original Message- > >> >> >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] > >> >> >> Sent: Sunday, October 07, 2012 9:09 PM > >> >> >> To: Jaegeuk Kim > >> >> >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; > >> >> >> gre...@linuxfoundation.org; linux- > >> >> >> ker...@vger.kernel.org; chur@samsung.com; > >> >> >> cm224@samsung.com; > >> >> >> jooyoung.hw...@samsung.com; > >> >> >> linux-fsde...@vger.kernel.org > >> >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file > >> >> >> system > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: > >> >> >> > >> >> >> >> -Original Message- > >> >> >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com] > >> >> >> >> Sent: Sunday, October 07, 2012 4:10 PM > >> >> >> >> To: Jaegeuk Kim > >> >> >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; > >> >> >> >> ty...@mit.edu; gre...@linuxfoundation.org; > >> >> >> >> linux-kernel@vger.kernel.org; chur@samsung.com; > >> >> >> >> cm224@samsung.com; > >> >> >> jooyoung.hw...@samsung.com; > >> >> >> >> linux-fsde...@vger.kernel.org > >> >> >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file > >> >> >> >> system > >> >> >> >> > >> >> >> >> Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: > >> >> >> >>> 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: > >> >> >> Hi Jaegeuk, > >> >> >> >>> > >> >> >> >>> Hi. > >> >> >> >>> We know each other, right? :) > >> >> >> >>> > >> >> >> > >> >> >> > From: 김재극 > >> >> >> > To:v...@zeniv.linux.org.uk, 'Theodore Ts'o' > >> >> >> > , > >> >> >> >> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > >> >> >> >> chur@samsung.com, > >> >> >> cm224@samsung.com, > >> >> >> >> jaegeuk@samsung.com, jooyoung.hw...@samsung.com > >> >> >> > Subject: [PATCH 00/16] f2fs: introduce > >> >> >> > flash-friendly file > >> >> >> > system > >> >> >> > Date: Fri, 05 Oct 2012 20:55:07 +0900 > >> >> >> > > >> >> >> > This is a new patch set for the f2fs file system. > >> >> >> > > >> >> >> > What is F2FS? > >> >> >> > = > >> >> >> > > >> >> >> > NAND flash memory-based storage devices, such as SSD, eMMC, > >> >> >> > and > >> >> >> > SD > >> >> >> > cards, have > >> >> >> > been widely being used for ranging from mobile to server > >> >> >> > systems. > >> >> >> > Since they are > >> >> >> > known to have different characteristics from the conventional > >> >> >> > rotational disks, > >> >> >> > a file system, an upper layer to the storage device, should > >> >> >> > adapt > >> >> >> > to > >> >> >> > the changes > >> >> >> > from the sketch. > >> >> >> > > >> >> >> > F2FS is a new file system carefully designed for the NAND > >> >> >> > flash > >> >> >> > memory-based storage > >> >> >> > devices. We chose a log structure file system approach, but > >> >> >> > we > >> >> >> > tried > >> >> >> > to adapt it > >> >> >> > to the new form of storage. Also we remedy some known issues > >> >> >> > of > >> >> >> > the > >> >> >> > very old log > >> >> >> > structured file system, such as snowball effect of wandering > >> >> >> > tree > >> >
Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote: > Hi, > > I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes > [1],[2],[3] > Running in a guest (qemu+seabios from [4]). > CONFIG_SLAB=y > CONFIG_DEBUG_SLAB=y > > After succesfull hot-add and online, I am doing a hot-remove with "echo 1 > > /sys/bus/acpi/devices/PNP/eject" > When I do the OSPM-eject, I often get slab corruption in "acpi-state" cache, > or in other caches The following patch can fix this problem: https://lkml.org/lkml/2012/7/12/186 Thanks Wen Congyang > > [ 170.566995] Slab corruption (Not tainted): Acpi-State > start=88009fc1e548, len=80 > [ 170.567265] Redzone: 0x0/0x0. > [ 170.567399] Last user: [< (null)>](0x0) > [ 170.567667] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > [ 170.568078] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > [ 170.568487] 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > [ 170.568894] 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > [ 170.569302] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > [ 170.569712] Prev obj: start=9fc1e4d0, len=80 > [ 170.569869] BUG: unable to handle kernel paging request at 9fc1e520 > [ 170.570171] IP: [] print_objinfo+0x9c/0x110 > [ 170.570397] PGD 7cf37067 PUD 0 > [ 170.570619] Oops: [#1] SMP > [ 170.570843] Modules linked in: netconsole acpiphp pci_hotplug > acpi_memhotplug loop kvm_amd kvm tpm_tis microcode tpm tpm_bios psmouse > parport_pc serio_raw evdev parport i2c_piix4 processor thermal_sys i2c_core > button ext3 jbd mbcache sg sr_mod cdrom ata_generic virtio_net virtio_blk > ata_piix libata scsi_mod virtio_pci virtio_ring virtio > [ 170.573474] CPU 0 > [ 170.573568] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 > Bochs Bochs > [ 170.573830] RIP: 0010:[] [] > print_objinfo+0x9c/0x110 > [ 170.574106] RSP: 0018:88003eaf3a70 EFLAGS: 00010202 > [ 170.574268] RAX: 9fc1e4c8 RBX: 0002 RCX: > 24b8 > [ 170.574468] RDX: 9fc1e4c8 RSI: 9fc1e4c8 RDI: > 88003e9bb980 > [ 170.574668] RBP: 88003e9bb980 R08: 880037964078 R09: > > [ 170.574870] R10: 021e R11: 0002 R12: > 9fc1e4c8 > [ 170.575070] R13: 9fc1e520 R14: 004f R15: > ffa5 > [ 170.575274] FS: 7fc6b7530700() GS:88003fc0() > knlGS: > [ 170.575494] CS: 0010 DS: ES: CR0: 8005003b > [ 170.575665] CR2: 9fc1e520 CR3: 7c9c1000 CR4: > 06f0 > [ 170.575870] DR0: DR1: DR2: > > [ 170.576075] DR3: DR6: 0ff0 DR7: > 0400 > [ 170.576276] Process kworker/0:1 (pid: 29, threadinfo 88003eaf2000, > task 88003ea941c0) > [ 170.576507] Stack: > [ 170.576599] 0010 01893fbe 88009fc1e000 > 0050 > [ 170.576938] 9fc1e4c8 004f ffa5 > 8112899f > [ 170.576938] 88003eb309d8 81712d6d 88003e9bb980 > 88009fc1e540 > [ 170.576938] Call Trace: > [ 170.576938] [] ? check_poison_obj+0x1df/0x1f0 > [ 170.576938] [] ? acpi_ut_create_generic_state+0x2f/0x4c > [ 170.576938] [] ? acpi_ut_create_generic_state+0x2f/0x4c > [ 170.576938] [] ? > cache_alloc_debugcheck_after.isra.52+0xed/0x220 > [ 170.576938] [] ? acpi_ut_create_generic_state+0x2f/0x4c > [ 170.576938] [] ? kmem_cache_alloc+0xb5/0x1e0 > [ 170.576938] [] ? acpi_ut_create_generic_state+0x2f/0x4c > [ 170.576938] [] ? acpi_ds_result_push+0x5d/0x12e > [ 170.576938] [] ? acpi_ds_exec_end_op+0x28e/0x3d3 > [ 170.576938] [] ? acpi_ps_parse_loop+0x79f/0x931 > [ 170.576938] [] ? acpi_ps_parse_aml+0x89/0x261 > [ 170.576938] [] ? acpi_ps_execute_method+0x1be/0x266 > [ 170.576938] [] ? acpi_ns_evaluate+0xd3/0x19a > [ 170.576938] [] ? acpi_evaluate_object+0xf3/0x1f4 > [ 170.576938] [] ? acpi_os_wait_events_complete+0x1b/0x1b > [ 170.576938] [] ? acpi_bus_hot_remove_device+0xeb/0x123 > [ 170.576938] [] ? acpi_os_execute_deferred+0x1d/0x29 > [ 170.576938] [] ? process_one_work+0x125/0x560 > [ 170.576938] [] ? worker_thread+0x16a/0x4e0 > [ 170.576938] [] ? manage_workers+0x310/0x310 > [ 170.576938] [] ? kthread+0x85/0x90 > [ 170.576938] [] ? kernel_thread_helper+0x4/0x10 > [ 170.576938] [] ? flush_kthread_worker+0xa0/0xa0 > [ 170.576938] [] ? gs_change+0x13/0x13 > [ 170.576938] Code: cb 75 dc 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 8b > 7f 0c 4c 89 e2 e8 02 fd ff ff 4c 89 e6 49 89 c5 48 89 ef e8 d4 fc ff ff <49> > 8b 55 00 48 8b 30 48 c7 c7 8c 39 6f 81 31 c0 e8 3e 34 3b 00 > > Other times, the problem happens on a slab object free: > > [ 52.313366] Offlined Pages 32768 > [ 52.800232] slab err
Re: PROBLEM: 3.6.0 kernel BUG at fs/dcache.c:967 during shutdown / restart
09.10.2012 11:54, Jan Kara пишет: On Mon 08-10-12 17:10:52, Neil Salstrom wrote: On 10/08/2012 10:14 AM, Jan Kara wrote: On Sat 06-10-12 10:20:26, Neil Salstrom wrote: I've not submitted a kernel bug before but I've read the bug reporting pages. I'll try to do my best and if you need more information please let me know. Please feel free to cc me on the answer or if you have questions. I'm using Linux Mint 13 (64 bit) on AMD hardware with a self compiled 3.6.0 kernel for my MythTV HTPC. Kernel version: Linux version 3.6.0 (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Tue Oct 2 15:34:46 PDT 2012 CPU: model name : AMD A6-3500 APU with Radeon(tm) HD Graphics If you need any other system variables please let me know and I can get those as well. Upon shutdown or restart (from either the hard button on the case or a "sudo shutdown -r now" the system crashes and does not actually shut down. I can ssh in to the system and a dmesg shows the following: There should be a line like: BUG: Dentry ... still in use (%d) [unmount of %s %s] just before the oops. Can you please post that one as well? Also I see that you are using nvidia module which taints the kernel. Can you try reproducing the issue without the module loaded? Honza Here is the full output with no nvidia module. I also have the full dmeg from start to finish if you would like it. Thanks for the new report. Since the use count of the problematic dentry is 1, I guess this is really some bug in rpc_pipefs. Bruce, any idea? Hi. Could you, please, give more details about your configuration. Currently, PipeFS is mounted on SUNRPC module install. Would be great to understand, what process tries to umount it and when. Also, do you have NFS mounts on the node, then Pipefs is umounting? Is systemd is active on your node? Could you trigger this panic manually? Honza [ 237.186167] BUG: Dentry 880118772540{i=6e,n=info} still in use (1) [unmount of rpc_pipefs rpc_pipefs] [ 237.186179] [ cut here ] [ 237.186181] kernel BUG at fs/dcache.c:967! [ 237.186182] invalid opcode: [#1] SMP [ 237.186185] Modules linked in: nls_utf8 udf crc_itu_t nfsv4 binfmt_misc nfsd nfs_acl auth_rpcgss nfs fscache lockd sunrpc snd_hda_codec_hdmi snd_hda_codec_realtek xfs snd_hda_intel snd_hda_codec snd_seq_midi snd_hwdep snd_rawmidi snd_pcm psmouse snd_seq_midi_event rc_imon_mce serio_raw snd_seq imon rc_core snd_timer snd_seq_device snd soundcore snd_page_alloc f71882fg r8169 ahci libahci [ 237.186203] CPU 2 [ 237.186206] Pid: 3063, comm: umount Not tainted 3.6.0 #1 System manufacturer System Product Name/F1A55-M LX PLUS [ 237.186208] RIP: 0010:[] [] shrink_dcache_for_umount_subtree+0x1e6/0x1f0 [ 237.186214] RSP: 0018:8801181afd98 EFLAGS: 00010296 [ 237.186215] RAX: 005d RBX: 880118772540 RCX: 14bd [ 237.186217] RDX: 3256 RSI: 0046 RDI: 81bbf9bc [ 237.186218] RBP: 8801181afdb8 R08: 000a R09: [ 237.186219] R10: 0383 R11: 0382 R12: 88011873b9c0 [ 237.186220] R13: 8801177a2b80 R14: 8801177a2bb0 R15: 88011287d800 [ 237.186222] FS: 7f67049b1800() GS:88011ed0() knlGS: [ 237.186223] CS: 0010 DS: ES: CR0: 8005003b [ 237.186225] CR2: 7f3e1de8 CR3: 000118a18000 CR4: 07e0 [ 237.186226] DR0: DR1: DR2: [ 237.186227] DR3: DR6: 0ff0 DR7: 0400 [ 237.186229] Process umount (pid: 3063, threadinfo 8801181ae000, task 880110fbc440) [ 237.186230] Stack: [ 237.186231] 88011287db50 88011873b780 88011287d800 a021d3c0 [ 237.186233] 8801181afdd8 8116de93 0001 88011287d800 [ 237.186235] 8801181afe08 811583bc 88011873b820 0015 [ 237.186238] Call Trace: [ 237.186241] [] shrink_dcache_for_umount+0x33/0x60 [ 237.186244] [] generic_shutdown_super+0x2c/0xf0 [ 237.186247] [] kill_anon_super+0x16/0x30 [ 237.186249] [] kill_litter_super+0x27/0x30 [ 237.186265] [] rpc_kill_sb+0x99/0xc0 [sunrpc] [ 237.186268] [] deactivate_locked_super+0x3c/0xa0 [ 237.186270] [] deactivate_super+0x4e/0x70 [ 237.186273] [] mntput_no_expire+0x106/0x160 [ 237.186276] [] sys_umount+0x6e/0x3b0 [ 237.186279] [] system_call_fastpath+0x1a/0x1f [ 237.186280] Code: 00 00 48 8b 40 28 4c 8b 08 48 8b 43 30 48 85 c0 74 04 48 8b 50 40 48 89 34 24 48 c7 c7 48 69 7c 81 48 89 de 31 c0 e8 09 62 40 00 <0f> 0b 0f 0b 66 0f 1f 44 00 00 55 48 89 e5 41 54 53 66 66 66 66 [ 237.186301] RIP [] shrink_dcache_for_umount_subtree+0x1e6/0x1f0 [ 237.186303] RSP [ 237.186320] ---[ end trace 74629a120592ec3c ]--- [ 238.707925] mtrr: no M
[PATCH] thermal: rcar: fixup compilation errors
This patch fixup following error ${LINUX}/drivers/thermal/rcar_thermal.c: In function 'rcar_thermal_probe': ${LINUX}/drivers/thermal/rcar_thermal.c:214:9: warning: passing argument 3 \ of 'thermal_zone_device_register' makes integer from pointer without\ a cast [enabled by default] ${LINUX}/include/linux/thermal.h:215:29: note: expected 'int' but argument \ is of type 'struct rcar_thermal_priv *' ${LINUX}/drivers/thermal/rcar_thermal.c:214:9:\ error: too few arguments to function 'thermal_zone_device_register' Signed-off-by: Devendra Naga Signed-off-by: Kuninori Morimoto --- for linus/master branch drivers/thermal/rcar_thermal.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c index b13fe5d..762f637 100644 --- a/drivers/thermal/rcar_thermal.c +++ b/drivers/thermal/rcar_thermal.c @@ -210,7 +210,7 @@ static int rcar_thermal_probe(struct platform_device *pdev) goto error_free_priv; } - zone = thermal_zone_device_register("rcar_thermal", 0, priv, + zone = thermal_zone_device_register("rcar_thermal", 0, 0, priv, &rcar_thermal_zone_ops, NULL, 0, 0); if (IS_ERR(zone)) { dev_err(&pdev->dev, "thermal zone device is NULL\n"); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 09, 2012 at 03:34:52PM +0800, Ming Lei wrote: > Yes, I agree, and my question is only on what you mentioned: > "it didn't want to load an optional image" > maybe I misunderstood the above, never mind, :-) > So one driver should suppose the firmware is there, and the > firmware shouldn't be zero length, because the driver always > expects getting some bytes by calling request_firmware(). The point is that there's some firmware which the driver wants to load but where it's happy to continue if the user didn't provide one and doesn't want to introduce needless delays. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] acpi : acpi_bus_trim() stops removing devices when failing to remove the device
Hi Wen, 2012/10/09 17:02, Wen Congyang wrote: Hi, ishimatsu: At 07/12/2012 07:28 PM, Yasuaki Ishimatsu Wrote: acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error number. But acpi_bus_remove() cannot return error number correctly. acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if device cannot be removed correctly, acpi_bus_trim() ignores and continues to remove devices. acpi_bus_hot_remove_device() uses acpi_bus_trim() for removing devices. Therefore acpi_bus_hot_remove_device() can send "_EJ0" to firmware, even if the device is running on the system. In this case, the system cannot work well. So acpi_bus_trim() should check whether device was removed or not correctly. The patch adds error check into some functions to remove the device. What is the status about this patch? I need to update the description against Toshi's comment as follows: "I agree with this change as driver's remove interface can fail. However, there are other callers to this function, which do not check the return value. I suppose there is no impact to the other paths since you only changed the CPU hotplug path to fail properly, but please confirm this is the case. I recommend documenting this change to the change log." I have already checked that the patch does not impact the other path with the exception of CPU and Memory hotplug path. So I will adds the result of investigation and following Vasislis's problem into the patch and resend to lklml. Vasilis Liaskovitis found a similar bug about the memory hotplug, and this patch can fix this problem: https://lkml.org/lkml/2012/9/26/318 Thanks, Yasuaki Ishimatsu Thanks Wen Congyang Signed-off-by: Yasuaki Ishimatsu --- drivers/acpi/scan.c| 15 --- drivers/base/dd.c | 22 +- include/linux/device.h |2 +- 3 files changed, 30 insertions(+), 9 deletions(-) Index: linux-3.5-rc6/drivers/acpi/scan.c === --- linux-3.5-rc6.orig/drivers/acpi/scan.c 2012-07-12 20:11:37.316443808 +0900 +++ linux-3.5-rc6/drivers/acpi/scan.c 2012-07-12 20:17:17.927185231 +0900 @@ -425,12 +425,17 @@ static int acpi_device_remove(struct dev { struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = acpi_dev->driver; + int ret; if (acpi_drv) { if (acpi_drv->ops.notify) acpi_device_remove_notify_handler(acpi_dev); - if (acpi_drv->ops.remove) - acpi_drv->ops.remove(acpi_dev, acpi_dev->removal_type); + if (acpi_drv->ops.remove) { + ret = acpi_drv->ops.remove(acpi_dev, + acpi_dev->removal_type); + if (ret) + return ret; + } } acpi_dev->driver = NULL; acpi_dev->driver_data = NULL; @@ -1208,11 +1213,15 @@ static int acpi_device_set_context(struc static int acpi_bus_remove(struct acpi_device *dev, int rmdevice) { + int ret; + if (!dev) return -EINVAL; dev->removal_type = ACPI_BUS_REMOVAL_EJECT; - device_release_driver(&dev->dev); + ret = device_release_driver(&dev->dev); + if (ret) + return ret; if (!rmdevice) return 0; Index: linux-3.5-rc6/drivers/base/dd.c === --- linux-3.5-rc6.orig/drivers/base/dd.c2012-07-12 20:11:37.316443808 +0900 +++ linux-3.5-rc6/drivers/base/dd.c 2012-07-12 20:17:17.928185218 +0900 @@ -464,9 +464,10 @@ EXPORT_SYMBOL_GPL(driver_attach); * __device_release_driver() must be called with @dev lock held. * When called for a USB interface, @dev->parent lock must be held as well. */ -static void __device_release_driver(struct device *dev) +static int __device_release_driver(struct device *dev) { struct device_driver *drv; + int ret; drv = dev->driver; if (drv) { @@ -482,9 +483,11 @@ static void __device_release_driver(stru pm_runtime_put_sync(dev); if (dev->bus && dev->bus->remove) - dev->bus->remove(dev); + ret = dev->bus->remove(dev); else if (drv->remove) - drv->remove(dev); + ret = drv->remove(dev); + if (ret) + goto rollback; devres_release_all(dev); dev->driver = NULL; klist_remove(&dev->p->knode_driver); @@ -494,6 +497,12 @@ static void __device_release_driver(stru dev); } + + return ret; + +rollback: + driver_sysfs_add(dev); + return ret; } /** @@ -503,16 +512,19 @@ static void __devic
Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
Hi Congyang, I think we should also free pages which are used by page tables after removing page tables of the memory. From: Jianguo Wu Signed-off-by: Jianguo Wu Signed-off-by: Jiang Liu --- arch/x86/mm/init_64.c | 110 +++- 1 files changed, 89 insertions(+), 21 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 5596dfa..81f9c3b 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -675,6 +675,74 @@ int arch_add_memory(int nid, u64 start, u64 size) } EXPORT_SYMBOL_GPL(arch_add_memory); +static inline void free_pagetable(struct page *page) +{ + struct zone *zone; + + __ClearPageReserved(page); + __free_page(page); + + zone = page_zone(page); + zone_span_writelock(zone); + zone->present_pages++; + zone_span_writeunlock(zone); + totalram_pages++; +} + +static void free_pte_table(pte_t *pte_start, pmd_t *pmd) +{ + pte_t *pte; + int i; + + for (i = 0; i < PTRS_PER_PTE; i++) { + pte = pte_start + i; + if (pte_val(*pte)) + break; + } + + /* free a pte talbe */ + if (i == PTRS_PER_PTE) { + free_pagetable(pmd_page(*pmd)); + pmd_clear(pmd); + } +} + +static void free_pmd_table(pmd_t *pmd_start, pud_t *pud) +{ + pmd_t *pmd; + int i; + + for (i = 0; i < PTRS_PER_PMD; i++) { + pmd = pmd_start + i; + if (pmd_val(*pmd)) + break; + } + + /* free a pmd talbe */ + if (i == PTRS_PER_PMD) { + free_pagetable(pud_page(*pud)); + pud_clear(pud); + } +} + +static void free_pud_table(pud_t *pud_start, pgd_t *pgd) +{ + pud_t *pud; + int i; + + for (i = 0; i < PTRS_PER_PUD; i++) { + pud = pud_start + i; + if (pud_val(*pud)) + break; + } + + /* free a pud table */ + if (i == PTRS_PER_PUD) { + free_pagetable(pgd_page(*pgd)); + pgd_clear(pgd); + } +} + static void __meminit phys_pte_remove(pte_t *pte_page, unsigned long addr, unsigned long end) { @@ -704,21 +772,19 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end) unsigned long pages = 0, next; int i = pmd_index(addr); - for (; i < PTRS_PER_PMD; i++, addr = next) { + for (; i < PTRS_PER_PMD && addr < end; i++, addr = next) { unsigned long pte_phys; pmd_t *pmd = pmd_page + pmd_index(addr); pte_t *pte; - if (addr >= end) - break; - - next = (addr & PMD_MASK) + PMD_SIZE; + next = pmd_addr_end(addr, end); if (!pmd_present(*pmd)) continue; if (pmd_large(*pmd)) { - if ((addr & ~PMD_MASK) == 0 && next <= end) { + if (IS_ALIGNED(addr, PMD_SIZE) && + IS_ALIGNED(next, PMD_SIZE)) { set_pmd(pmd, __pmd(0)); pages++; continue; @@ -729,7 +795,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end) * so split 2M page to 4K page. */ pte = alloc_low_page(&pte_phys); - __split_large_page((pte_t *)pmd, addr, pte); + __split_large_page((pte_t *)pmd, + (unsigned long)__va(addr), pte); spin_lock(&init_mm.page_table_lock); pmd_populate_kernel(&init_mm, pmd, __va(pte_phys)); @@ -738,7 +805,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end) spin_lock(&init_mm.page_table_lock); pte = map_low_page((pte_t *)pmd_page_vaddr(*pmd)); - phys_pte_remove(pte, addr, end); + phys_pte_remove(pte, addr, next); + free_pte_table(pte, pmd); unmap_low_page(pte); spin_unlock(&init_mm.page_table_lock); } @@ -751,21 +819,19 @@ phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end) unsigned long pages = 0, next; int i = pud_index(addr); - for (; i < PTRS_PER_PUD; i++, addr = next) { + for (; i < PTRS_PER_PUD && addr < end; i++, addr = next) { unsigned long pmd_phys; pud_t *pud = pud_page + pud_index(addr); pmd_t *pmd; - if (addr >= end) - break; - - next = (addr & PUD_MASK) + PUD_SIZE; + next = pud_addr_end(addr, end); if (!pud_present(*pud)) continue; if (pud_large(
Re: [RFC PATCH 01/06] input/rmi4: Public header and documentation
On Tue, Oct 09, 2012 at 09:43:13AM +0200, Linus Walleij wrote: > On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny > wrote: > > + * @cs_assert - For systems where the SPI subsystem does not control the > > CS/SSB > > + * line, or where such control is broken, you can provide a custom routine > > to > > + * handle a GPIO as CS/SSB. This routine will be called at the beginning > > and > > + * end of each SPI transaction. The RMI SPI implementation will wait > > + * pre_delay_us after this routine returns before starting the SPI > > transfer; > > + * and post_delay_us after completion of the SPI transfer(s) before > > calling it > > + * with assert==FALSE. > Hm hm, can you describe the case where this happens? > Usually we don't avoid fixes for broken drivers by duct-taping > solutions into other drivers, instead we fix the SPI driver. > I can think of systems where CS is asserted not by using > GPIO but by poking some special register for example, which > is a valid reason for including this, but working around broken > SPI drivers is not a valid reason to include this. > (Paging Mark about it.) Yeah, this seems silly - by this logic we'd have to go round implementing manual /CS control in every single SPI client driver which isn't terribly sensible. The driver should just assume that the SPI controller does what it's told. As you say if there's an issue the relevant controller driver should take care of things. We should also have generic support in the SPI framework for GPIO based /CS, there's enough drivers open coding this already either due to hardware limitations or to support extra chip selects. The ability of SPI hardware and driver authors to get /CS right is pretty depressing :/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
At 10/09/2012 02:21 PM, David Rientjes Wrote: > On Mon, 8 Oct 2012, Tang Chen wrote: > >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 66b36ab..e76dce9 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -1263,18 +1263,24 @@ EXPORT_SYMBOL_GPL(kick_process); >> */ >> static int select_fallback_rq(int cpu, struct task_struct *p) >> { >> -const struct cpumask *nodemask = cpumask_of_node(cpu_to_node(cpu)); >> +int nid = cpu_to_node(cpu); >> +const struct cpumask *nodemask = NULL; >> enum { cpuset, possible, fail } state = cpuset; >> int dest_cpu; >> >> -/* Look for allowed, online CPU in same node. */ >> -for_each_cpu(dest_cpu, nodemask) { >> -if (!cpu_online(dest_cpu)) >> -continue; >> -if (!cpu_active(dest_cpu)) >> -continue; >> -if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p))) >> -return dest_cpu; >> +/* If the cpu has been offlined, its nid was set to -1. */ >> +if (nid != -1) { > > NUMA_NO_NODE. > > Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this > should be called at CPU_DYING level and migrate_tasks() still sees a valid > cpu. the cpu's node is set when the cpu is hotpluged(not online), and it will be cleared when the cpu is hotremoved(This patch is in akpm tree): https://lkml.org/lkml/2012/9/3/39 I guess the task is in sleep state when the cpu is offlined, and it doesn't be migrated to another cpu. Thanks Wen Congyang > > On x86, cpumask_of_node() is always guaranteed to return a valid cpumask > after boot so presumably this is a problem in some non-x86 arch code and > isn't actually a sched problem. > >> +nodemask = cpumask_of_node(nid); >> + >> +/* Look for allowed, online CPU in same node. */ >> +for_each_cpu(dest_cpu, nodemask) { >> +if (!cpu_online(dest_cpu)) >> +continue; >> +if (!cpu_active(dest_cpu)) >> +continue; >> +if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p))) >> +return dest_cpu; >> +} >> } >> >> for (;;) { > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: android: binder: Fixed multi-line strings
On Tue, Oct 09, 2012 at 12:31:03AM +0530, Anmol Sarma wrote: > Changed all user visible multi-line stings to single line. > > Signed-off-by: Anmol Sarma These sorts of things are really a judgement call. checkpatch.pl is being bossier than it should be. I would ignore keep the maintaier's original code. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
On Mon, 8 Oct 2012, Jaegeuk Kim wrote: > Date: Mon, 08 Oct 2012 19:52:03 +0900 > From: Jaegeuk Kim > To: 'Namjae Jeon' > Cc: 'Vyacheslav Dubeyko' , > 'Marco Stornelli' , > 'Jaegeuk Kim' , > 'Al Viro' , ty...@mit.edu, > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com, > linux-fsde...@vger.kernel.org > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > -Original Message- > > From: Namjae Jeon [mailto:linkinj...@gmail.com] > > Sent: Monday, October 08, 2012 7:00 PM > > To: Jaegeuk Kim > > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; > > ty...@mit.edu; > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > chur@samsung.com; cm224@samsung.com; > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > > > 2012/10/8, Jaegeuk Kim : > > >> -Original Message- > > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] > > >> Sent: Sunday, October 07, 2012 9:09 PM > > >> To: Jaegeuk Kim > > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; > > >> gre...@linuxfoundation.org; linux- > > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; > > >> jooyoung.hw...@samsung.com; > > >> linux-fsde...@vger.kernel.org > > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > >> > > >> Hi, > > >> > > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: > > >> > > >> >> -Original Message- > > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com] > > >> >> Sent: Sunday, October 07, 2012 4:10 PM > > >> >> To: Jaegeuk Kim > > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; > > >> >> ty...@mit.edu; gre...@linuxfoundation.org; > > >> >> linux-kernel@vger.kernel.org; chur@samsung.com; > > >> >> cm224@samsung.com; > > >> jooyoung.hw...@samsung.com; > > >> >> linux-fsde...@vger.kernel.org > > >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > >> >> > > >> >> Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: > > >> >>> 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: > > >> Hi Jaegeuk, > > >> >>> > > >> >>> Hi. > > >> >>> We know each other, right? :) > > >> >>> > > >> > > >> > From: 김재극 > > >> > To:v...@zeniv.linux.org.uk, 'Theodore Ts'o' > > >> > , > > >> >> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, > > >> >> chur@samsung.com, > > >> cm224@samsung.com, > > >> >> jaegeuk@samsung.com, jooyoung.hw...@samsung.com > > >> > Subject: [PATCH 00/16] f2fs: introduce flash-friendly > > >> > file system > > >> > Date: Fri, 05 Oct 2012 20:55:07 +0900 > > >> > > > >> > This is a new patch set for the f2fs file system. > > >> > > > >> > What is F2FS? > > >> > = > > >> > > > >> > NAND flash memory-based storage devices, such as SSD, eMMC, and SD > > >> > cards, have > > >> > been widely being used for ranging from mobile to server systems. > > >> > Since they are > > >> > known to have different characteristics from the conventional > > >> > rotational disks, > > >> > a file system, an upper layer to the storage device, should adapt > > >> > to > > >> > the changes > > >> > from the sketch. > > >> > > > >> > F2FS is a new file system carefully designed for the NAND flash > > >> > memory-based storage > > >> > devices. We chose a log structure file system approach, but we > > >> > tried > > >> > to adapt it > > >> > to the new form of storage. Also we remedy some known issues of the > > >> > very old log > > >> > structured file system, such as snowball effect of wandering tree > > >> > and high cleaning > > >> > overhead. > > >> > > > >> > Because a NAND-based storage device shows different characteristics > > >> > according to > > >> > its internal geometry or flash memory management scheme aka FTL, we > > >> > add various > > >> > parameters not only for configuring on-disk layout, but also for > > >> > selecting allocation > > >> > and cleaning algorithms. > > >> > > > >> > > >> What about F2FS performance? Could you share benchmarking results of > > >> the new file system? > > >> > > >> It is very interesting the case of aged file system. How is GC's > > >> implementation efficient? Could > > >> >> you share benchmarking results for the very aged file system state? > > >> > > >> >>> > > >> >>> Although I have benchmark results, currently I'd like to see the > > >> >>> results > > >> >>> measured by community as a black-box. As you know, the results are > > >> >>> very > > >> >>> dependent on the workloads and parameters, so I think it would be > > >> >>> be
Re: [PATCH 0/3] Volatile Ranges (v7) & Lots of words
On Fri, Sep 28, 2012 at 11:16:30PM -0400, John Stultz wrote: > fd based interfaces vs madvise: > In talking with Taras Glek, he pointed out that for his > needs, the fd based interface is a little annoying, as it > requires having to get access to tmpfs file and mmap it in, > then instead of just referencing a pointer to the data he > wants to mark volatile, he has to calculate the offset from > start of the mmap and pass those file offsets to the interface. > Instead he mentioned that using something like madvise would be > much nicer, since they could just pass a pointer to the object > in memory they want to make volatile and avoid the extra work. > > I'm not opposed to adding an madvise interface for this as > well, but since we have a existing use case with Android's > ashmem, I want to make sure we support this existing behavior. > Specifically as with ashmem applications can be sharing > these tmpfs fds, and so file-relative volatile ranges make > more sense if you need to coordinate what data is volatile > between two applications. > > Also, while I agree that having an madvise interface for > volatile ranges would be nice, it does open up some more > complex implementation issues, since with files, there is a > fixed relationship between pages and the files' address_space > mapping, where you can't have pages shared between different > mappings. This makes it easy to hang the volatile-range tree > off of the mapping (well, indirectly via a hash table). With > general anonymous memory, pages can be shared between multiple > processes, and as far as I understand, don't have any grouping > structure we could use to determine if the page is in a > volatile range or not. We would also need to determine more > complex questions like: What are the semantics of volatility > with copy-on-write pages? I'm hoping to investigate this > idea more deeply soon so I can be sure whatever is pushed has > a clear plan of how to address this idea. Further thoughts > here would be appreciated. Note it doesn't have to be a vs. situation. madvise could be an additional way to interface with volatile ranges on a given fd. That is, madvise doesn't have to mean anonymous memory. As a matter of fact, MADV_WILLNEED/MADV_DONTNEED are usually used on mmaped files. Similarly, there could be a way to use madvise to mark volatile ranges, without the application having to track what memory ranges are associated to what part of what file, which the kernel already tracks. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
Hi David, Thanks for reviewing this patch. :) On 10/09/2012 04:34 PM, Wen Congyang wrote: At 10/09/2012 02:21 PM, David Rientjes Wrote: On Mon, 8 Oct 2012, Tang Chen wrote: + /* If the cpu has been offlined, its nid was set to -1. */ + if (nid != -1) { NUMA_NO_NODE. Yes, NUMA_NO_NODE is better. I'll improve it, thanks. :) Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this should be called at CPU_DYING level and migrate_tasks() still sees a valid cpu. As Wen said below, nid is now set to -1 when cpu is hotremoved. I reproduce this problem in this situation: all cpus are online, and hot remove a system board directorily, without offlining any cpu. As a result, the removed cpu's nid is set to -1, and this causes problems. the cpu's node is set when the cpu is hotpluged(not online), and it will be cleared when the cpu is hotremoved(This patch is in akpm tree): https://lkml.org/lkml/2012/9/3/39 I guess the task is in sleep state when the cpu is offlined, and it doesn't be migrated to another cpu. Thanks Wen Congyang On x86, cpumask_of_node() is always guaranteed to return a valid cpumask after boot so presumably this is a problem in some non-x86 arch code and isn't actually a sched problem. BTW, my box is x86. I think for the reason I said above, cpumask_of_node() will no longer guaranteed anything even if on x86. Thanks. :) + nodemask = cpumask_of_node(nid); + + /* Look for allowed, online CPU in same node. */ + for_each_cpu(dest_cpu, nodemask) { + if (!cpu_online(dest_cpu)) + continue; + if (!cpu_active(dest_cpu)) + continue; + if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p))) + return dest_cpu; + } } for (;;) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 02/06] input/rmi4: Core files
On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny wrote: > rmi_bus.c implements the basic functionality of the RMI bus. This file is > greatly simplified compared to the previous patch - we've switched from > "do it yourself" device/driver binding to using device_type to distinguish > between the two kinds of devices on the bus (sensor devices and function > specific devices) and using the standard bus implementation to manage devices > and drivers. So I think you really want Greg KH to look at this bus implementation now. Please include Greg on future mailings... It looks much improved from previous versions, and sorry if I am now adding even more comments, but it's because you cleared out some noise that was disturbing my perception so I can cleanly review the architecture of this thing now. (I'm impressed by your work and new high-speed turnaround time!) > +#ifdef CONFIG_RMI4_DEBUG > +#include > +#endif As noted previously, drop the #ifdef:s > +#ifdef CONFIG_RMI4_DEBUG > +static struct dentry *rmi_debugfs_root; > +#endif I'd use #ifdef CONFIG_DEBUG_FS and try to move this declaration closer to the actual debugfs code block. Apart from this the core bus looks good to me, but it's not my area of expertise... (...) > diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c > +#ifdef CONFIG_RMI4_DEBUG I'd just use CONFIG_DEBUG_FS > +struct driver_debugfs_data { > + bool done; > + struct rmi_device *rmi_dev; > +}; (...) > +#define DELAY_NAME "delay" This is only used in one place, why not just use the string "delay" there? (...) > + if (IS_ENABLED(CONFIG_RMI4_SPI) && !strncmp("spi", info->proto, 3)) { > + data->debugfs_delay = debugfs_create_file(DELAY_NAME, > + RMI_RW_ATTR, rmi_dev->debugfs_root, rmi_dev, > + &delay_fops); i.e. there. (...) > +/* Useful helper functions for u8* */ > + > +static bool u8_is_any_set(u8 *target, int size) > +{ > + int i; > + /* We'd like to use find_first_bit, but it ALWAYS returns 1, > + * no matter what we pass it. So we have to do this the hard way. > + * return find_first_bit((long unsigned int *) target, size) != 0; > + */ > + for (i = 0; i < size; i++) { > + if (target[i]) > + return true; > + } > + return false; > +} Instead of: if (u8_is_any_set(foo, 128) {} Why can't you use: if (!bitmap_empty(foo, 128*8) {} ? If you look at the implementation in the header and __bitmap_empty() in lib/bitmap.c you will realize that this function is already optimized like this (and I actually don't think the RMI4 code is performance-critical for these functions anyway, but prove me wrong!) > + > +/** This is here because all those casts made for some ugly code. > + */ > +static void u8_and(u8 *dest, u8 *target1, u8 *target2, int nbits) > +{ > + bitmap_and((long unsigned int *) dest, > + (long unsigned int *) target1, > + (long unsigned int *) target2, > + nbits); > +} Hm, getting rid of unreadable casts is a valid case. I'll be OK with this but maybe the real solution is to introduce such helpers into ? (...) > +static int process_interrupt_requests(struct rmi_device *rmi_dev) > +{ > + struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev); > + struct device *dev = &rmi_dev->dev; > + struct rmi_function_container *entry; > + u8 irq_status[data->num_of_irq_regs]; Looking at this... What does the data->num_of_irq_regs actually contain? I just fear that it is something constant like always 2 or always 4, so there is actually, in reality, a 16 or 32 bit register hiding in there. In that case what you should do is to represent it as a u16 or u32 here, just or the bits into a status word, and then walk over that status word with something like ffs(bitword); ... (...) > +static int standard_resume(struct rmi_device *rmi_dev) Standard eh? :-) Atleast prefix with rmi4_*... > +static int rmi_driver_suspend(struct device *dev) > +{ > + struct rmi_device *rmi_dev = to_rmi_device(dev); > + return standard_suspend(rmi_dev); > +} > + > +static int rmi_driver_resume(struct device *dev) > +{ > + struct rmi_device *rmi_dev = to_rmi_device(dev); > + return standard_resume(rmi_dev); > +} If all these two are doing are to call another function with almost the same name, what is the point? Just sink the code from "standard_suspend()" and "standard_resume()" into these functions and remove a pointless layer of abstraction. Apart from this the core driver looks good to me. (...) > diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h (...) > +#define simple_show_union_struct(regtype, propname, fmt)\ > +static ssize_t tricat(rmi_fn_, FNUM, _##propname##_show)(struct device *dev,\ > + struct device_attribute
Re: ANN: linux-kernel-lzo-2.06.20120123 - update LZO to v2.06
On Wed, Jan 25, 2012 at 02:36:18AM +0100, Andi Kleen wrote: > I ran benchmarks on the new miniLZO and LZ4 on 64bit. LZ4 is generally slower > than snappy/lzo in the micro benchmarks. And the reason why you measured worse speed for LZ4 although (AFAICT) everybody else's measurements claim the opposite is quite simple: likely due to a copy&paste error you did not benchmark LZ4 at all: https://github.com/andikleen/snappy-c/blob/master/glue.c#L282 274 void test_lz4(char *map, size_t size, char *fn) 275 { 276 int i; 277 int err; 278 size_t outlen = size * 2; 279 char *out = xmalloc(outlen); 280 char *buf2 = xmalloc(size); 281 282 BENCH(fastlz, "lz4", fn, NULL); ^^ 283 284 free(out); 285 free(buf2); 286 } (LZ4 is on it's track towards kernel) david -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CMA broken in next-20120926
Hi, On Monday 08 October 2012 10:48:07 Mel Gorman wrote: > On Mon, Oct 08, 2012 at 05:06:54PM +0900, Minchan Kim wrote: > > Hi Mel, > > > > On Tue, Oct 02, 2012 at 04:12:17PM +0100, Mel Gorman wrote: > > > On Tue, Oct 02, 2012 at 05:03:07PM +0200, Thierry Reding wrote: > > > > On Tue, Oct 02, 2012 at 03:41:35PM +0100, Mel Gorman wrote: > > > > > On Tue, Oct 02, 2012 at 02:48:14PM +0200, Thierry Reding wrote: > > > > > > > So this really isn't all that new, but I just wanted to confirm my > > > > > > > results from last week. We'll see if bisection shows up something > > > > > > > interesting. > > > > > > > > > > > > I just finished bisecting this and git reports: > > > > > > > > > > > > 3750280f8bd0ed01753a72542756a8c82ab27933 is the first bad commit > > > > > > > > > > > > I'm attaching the complete bisection log and a diff of all the > > > > > > changes > > > > > > applied on top of the bad commit to make it compile and run on my > > > > > > board. > > > > > > Most of the patch is probably not important, though. There are two > > > > > > hunks > > > > > > which have the pageblock changes I already posted an two other hunks > > > > > > with the patch you posted earlier. > > > > > > > > > > > > I hope this helps. If you want me to run any other tests, please > > > > > > let me > > > > > > know. > > > > > > > > > > > > > > > > Can you test with this on top please? > > > > > > > > That doesn't build on top of the bad commit. Or is it supposed to go on > > > > top of next-20120926? > > > > > > > > > > It doesn't build or do you mean it doesn't apply? Assuming the problem > > > was that it didn't apply then try this one. It applies on top of > > > next-20120928 which is the closest tag I have to next-20120926. > > > > > > ---8<--- > > > mm: compaction: Cache if a pageblock was scanned and no pages were > > > isolated -fix3 > > > > > > CMA requires that the PG_migrate_skip hint be skipped but it was only > > > skipping it when isolating pages for migration, not for free. Ensure > > > cc->isolate_skip_hint gets passed in both cases. > > > > > > This is a fix for > > > mm-compaction-cache-if-a-pageblock-was-scanned-and-no-pages-were-isolated-fix.patch > > > > > > Signed-off-by: Mel Gorman > > Acked-by: Minchan Kim > > > > But please resend below compile error fixing. > > > > Thanks Minchan. I did resent this patch to Andrew with the subject "[PATCH] > mm: compaction: Cache if a pageblock was scanned and no pages were isolated > -fix3". It should have had the build errors fixed but has not been > picked up yet. I also need following patch to make CONFIG_CMA=y && CONFIG_COMPACTION=y case work: From: Bartlomiej Zolnierkiewicz Subject: [PATCH] mm: compaction: cache if a pageblock was scanned and no pages were isolated - cma fix Patch "mm: compaction: cache if a pageblock was scanned and no pages were isolated" needs a following fix to successfully boot next-20121002 kernel (same with next-20121008) with CONFIG_CMA=y and CONFIG_COMPACTION=y (with applied -fix1, -fix2, -fix3 patches from Mel Gorman and also with cmatest module from Thierry Reding compiled in). Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park --- mm/compaction.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: b/mm/compaction.c === --- a/mm/compaction.c 2012-10-08 18:10:53.491679716 +0200 +++ b/mm/compaction.c 2012-10-08 18:11:33.615679713 +0200 @@ -117,7 +117,8 @@ static void update_pageblock_skip(struct bool migrate_scanner) { struct zone *zone = cc->zone; - if (!page) + + if (!page || cc->ignore_skip_hint) return; if (!nr_isolated) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [staging][zram] Fix handling of incompressible pages
On Mon, Oct 08, 2012 at 06:32:44PM -0700, Nitin Gupta wrote: > Change 130f315a introduced a bug in the handling of incompressible When you mention a patch, please include the human readable patch title as well as the hash. "staging: zram: remove special handle of uncompressed page". regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
acpi : acpi_bus_trim() stops removing devices when failing to remove the device
acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error number. But acpi_bus_remove() cannot return error number correctly. acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if device cannot be removed correctly, acpi_bus_trim() ignores and continues to remove devices. acpi_bus_hot_remove_device() uses acpi_bus_trim() for removing devices. Therefore acpi_bus_hot_remove_device() can send "_EJ0" to firmware, even if the device is running on the system. In this case, the system cannot work well. Vasilis hit the bug at memory hotplug and reported it as follow: https://lkml.org/lkml/2012/9/26/318 So acpi_bus_trim() should check whether device was removed or not correctly. The patch adds error check into some functions to remove the device. Applying the patch, acpi_bus_trim() stops removing devices when failing to remove the device. But I think there is no impact with the exceptionof CPU and Memory hotplug path. Because other device also fails but the fail is an irregular case like device is NULL. Signed-off-by: Yasuaki Ishimatsu --- drivers/acpi/scan.c| 15 --- drivers/base/dd.c | 22 +- include/linux/device.h |2 +- 3 files changed, 30 insertions(+), 9 deletions(-) Index: linux-3.6/drivers/acpi/scan.c === --- linux-3.6.orig/drivers/acpi/scan.c 2012-10-09 17:25:40.956496325 +0900 +++ linux-3.6/drivers/acpi/scan.c 2012-10-09 17:25:55.405497800 +0900 @@ -445,12 +445,17 @@ static int acpi_device_remove(struct dev { struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = acpi_dev->driver; + int ret; if (acpi_drv) { if (acpi_drv->ops.notify) acpi_device_remove_notify_handler(acpi_dev); - if (acpi_drv->ops.remove) - acpi_drv->ops.remove(acpi_dev, acpi_dev->removal_type); + if (acpi_drv->ops.remove) { + ret = acpi_drv->ops.remove(acpi_dev, + acpi_dev->removal_type); + if (ret) + return ret; + } } acpi_dev->driver = NULL; acpi_dev->driver_data = NULL; @@ -1226,11 +1231,15 @@ static int acpi_device_set_context(struc static int acpi_bus_remove(struct acpi_device *dev, int rmdevice) { + int ret; + if (!dev) return -EINVAL; dev->removal_type = ACPI_BUS_REMOVAL_EJECT; - device_release_driver(&dev->dev); + ret = device_release_driver(&dev->dev); + if (ret) + return ret; if (!rmdevice) return 0; Index: linux-3.6/drivers/base/dd.c === --- linux-3.6.orig/drivers/base/dd.c2012-10-01 08:47:46.0 +0900 +++ linux-3.6/drivers/base/dd.c 2012-10-09 17:25:55.442497825 +0900 @@ -475,9 +475,10 @@ EXPORT_SYMBOL_GPL(driver_attach); * __device_release_driver() must be called with @dev lock held. * When called for a USB interface, @dev->parent lock must be held as well. */ -static void __device_release_driver(struct device *dev) +static int __device_release_driver(struct device *dev) { struct device_driver *drv; + int ret = 0; drv = dev->driver; if (drv) { @@ -493,9 +494,11 @@ static void __device_release_driver(stru pm_runtime_put_sync(dev); if (dev->bus && dev->bus->remove) - dev->bus->remove(dev); + ret = dev->bus->remove(dev); else if (drv->remove) - drv->remove(dev); + ret = drv->remove(dev); + if (ret) + goto rollback; devres_release_all(dev); dev->driver = NULL; dev_set_drvdata(dev, NULL); @@ -506,6 +509,12 @@ static void __device_release_driver(stru dev); } + + return ret; + +rollback: + driver_sysfs_add(dev); + return ret; } /** @@ -515,16 +524,19 @@ static void __device_release_driver(stru * Manually detach device from driver. * When called for a USB interface, @dev->parent lock must be held. */ -void device_release_driver(struct device *dev) +int device_release_driver(struct device *dev) { + int ret; /* * If anyone calls device_release_driver() recursively from * within their ->remove callback for the same device, they * will deadlock right here. */ device_lock(dev); - __device_release_driver(dev); + ret = __device_release_driver(dev); device_unlock(dev); + + return ret; } EXPORT_SYMBOL_GPL(device_release_driver); Index: linux-3.6/include/linux/devi
RE: [PATCH RESEND] x86/fixup_irq: Clean the offlining CPU from the irq affinity mask
One suggestion below, thanks. > -Original Message- > From: Siddha, Suresh B > Sent: Thursday, September 27, 2012 6:46 AM > To: Srivatsa S. Bhat > Cc: Liu, Chuansheng; t...@linutronix.de; mi...@redhat.com; x...@kernel.org; > linux-kernel@vger.kernel.org; yanmin_zh...@linux.intel.com; Paul E. > McKenney; Peter Zijlstra; ru...@rustcorp.com.au > Subject: Re: [PATCH RESEND] x86/fixup_irq: Clean the offlining CPU from the > irq > affinity mask > > On Wed, 2012-09-26 at 23:00 +0530, Srivatsa S. Bhat wrote: > > On 09/26/2012 10:36 PM, Suresh Siddha wrote: > > > On Wed, 2012-09-26 at 21:33 +0530, Srivatsa S. Bhat wrote: > > >> I have some fundamental questions here: > > >> 1. Why was the CPU never removed from the affinity masks in the original > > >> code? I find it hard to believe that it was just an oversight, because > > >> the > > >> whole point of fixup_irqs() is to affine the interrupts to other CPUs, > > >> IIUC. > > >> So, is that really a bug or is the existing code correct for some reason > > >> which I don't know of? > > > > > > I am not aware of the history but my guess is that the affinity mask > > > which is coming from the user-space wants to be preserved. And > > > fixup_irqs() is fixing the underlying interrupt routing when the cpu > > > goes down > > > > and the code that corresponds to that is: > > irq_force_complete_move(irq); is it? > > No. irq_set_affinity() > > > > with a hope that things will be corrected when the cpu comes > > > back online. But as Liu noted, we are not correcting the underlying > > > routing when the cpu comes back online. I think we should fix that > > > rather than modifying the user-specified affinity. > > > > > > > Hmm, I didn't entirely get your suggestion. Are you saying that we should > change > > data->affinity (by calling ->irq_set_affinity()) during offline but > > maintain a > > copy of the original affinity mask somewhere, so that we can try to match it > > when possible (ie., when CPU comes back online)? > > Don't change the data->affinity in the fixup_irqs() and shortly after a > cpu is online, call irq_chip's irq_set_affinity() for those irq's who > affinity included this cpu (now that the cpu is back online, > irq_set_affinity() will setup the HW routing tables correctly). > > This presumes that across the suspend/resume, cpu offline/online > operations, we don't want to break the irq affinity setup by the > user-level entity like irqbalance etc... > In fixup_irqs(), could we untouch the data->affinity, but calling ->irq_set_affinity() without offlined CPU. If so, the better affinity is set, and user-space can use the data->affinity correctly, also new affinity setting will and online cpus. > > > That happens only if the irq chip doesn't have the irq_set_affinity() > > > setup. > > > > That is my other point of concern : setting irq affinity can fail even if > > we have ->irq_set_affinity(). (If __ioapic_set_affinity() fails, for > > example). > > Why don't we complain in that case? I think we should... and if its serious > > enough, abort the hotplug operation or atleast indicate that offline > > failed.. > > yes if there is a failure then we are in trouble, as the cpu is already > disappeared from the online-masks etc. For platforms with > interrupt-remapping, interrupts can be migrated from the process context > and as such this all can be done much before. > > And for legacy platforms we have done quite a few changes in the recent > past like using eoi_ioapic_irq() for level triggered interrupts etc, > that makes it as safe as it can be. Perhaps we can move most of the > fixup_irqs() code much ahead and the lost section of the current > fixup_irqs() (which check IRR bits and use the retrigger function to > trigger the interrupt on another cpu) can still be done late just like > now. > > thanks, > suresh N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a��� 0��h���i
Re: [PATCH resend] net, bluetooth: don't attempt to free a channel that wasn't created
Hi Sasha, * Sasha Levin [2012-10-08 16:48:32 -0400]: > We may currently attempt to free a channel which wasn't created due to > an error in the initialization path, this would cause a NULL ptr deref. > > This would cause the following oops: > > [ 12.919073] BUG: unable to handle kernel NULL pointer dereference at > 0010 > [ 12.919131] IP: [] l2cap_chan_put+0x34/0x50 > [ 12.919135] PGD 0 > [ 12.919138] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 12.919193] Dumping ftrace buffer: > [ 12.919242](ftrace buffer empty) > [ 12.919314] Modules linked in: > [ 12.919318] CPU 1 > [ 12.919319] Pid: 6210, comm: krfcommd Tainted: GW > 3.6.0-next-20121004-sasha-5-gb010653-dirty #30 > [ 12.919374] RIP: 0010:[] [] > l2cap_chan_put+0x34/0x50 > [ 12.919377] RSP: :880066933c38 EFLAGS: 00010246 > [ 12.919378] RAX: 8366c780 RBX: RCX: > 6667 > [ 12.919379] RDX: 0fa0 RSI: 84d3f79e RDI: > 0010 > [ 12.919381] RBP: 880066933c48 R08: 859989f8 R09: > 0001 > [ 12.919382] R10: R11: 7fff R12: > > [ 12.919383] R13: 88009b00a200 R14: 88009b00a200 R15: > 0001 > [ 12.919385] FS: () GS:88003360() > knlGS: > [ 12.919437] CS: 0010 DS: ES: CR0: 80050033 > [ 12.919440] CR2: 0010 CR3: 05026000 CR4: > 000406e0 > [ 12.919446] DR0: DR1: DR2: > > [ 12.919451] DR3: DR6: 0ff0 DR7: > 0400 > [ 12.919504] Process krfcommd (pid: 6210, threadinfo 880066932000, task > 880065c4b000) > [ 12.919506] Stack: > [ 12.919510] 88009b00a200 880032084000 880066933c68 > 8366c7bc > [ 12.919513] 7fff 880032084000 880066933c98 > 833ae0ae > [ 12.919516] 880066933ca8 > 88009b00a200 > [ 12.919517] Call Trace: > [ 12.919522] [] l2cap_sock_destruct+0x3c/0x80 > [ 12.919527] [] __sk_free+0x1e/0x1f0 > [ 12.919530] [] sk_free+0x17/0x20 > [ 12.919585] [] l2cap_sock_alloc.constprop.5+0x9e/0xd0 > [ 12.919591] [] l2cap_sock_create+0x7e/0x100 > [ 12.919652] [] ? _raw_read_lock+0x6a/0x80 > [ 12.919658] [] ? bt_sock_create+0x74/0x110 > [ 12.919660] [] bt_sock_create+0xb8/0x110 > [ 12.919664] [] __sock_create+0x282/0x3b0 > [ 12.919720] [] ? __sock_create+0x100/0x3b0 > [ 12.919725] [] ? rfcomm_process_sessions+0x17e0/0x17e0 > [ 12.919779] [] sock_create_kern+0x1f/0x30 > [ 12.919784] [] rfcomm_l2sock_create+0x44/0x70 > [ 12.919787] [] ? rfcomm_process_sessions+0x17e0/0x17e0 > [ 12.919790] [] rfcomm_run+0x4e/0x1f0 > [ 12.919846] [] ? rfcomm_process_sessions+0x17e0/0x17e0 > [ 12.919852] [] kthread+0xe3/0xf0 > [ 12.919908] [] ? put_lock_stats.isra.14+0xe/0x40 > [ 12.919914] [] ? flush_kthread_work+0x1f0/0x1f0 > [ 12.919968] [] ret_from_fork+0x7c/0x90 > [ 12.919973] [] ? flush_kthread_work+0x1f0/0x1f0 > [ 12.920161] Code: 83 ec 08 f6 05 ff 58 44 02 04 74 1b 8b 4f 10 48 89 fa 48 > c7 c6 d9 d7 d4 84 48 c7 c7 80 9e aa 85 31 c0 e8 80 > ac 3a fe 48 8d 7b 10 83 6b 10 01 0f 94 c0 84 c0 74 05 e8 8b e0 ff ff 48 > 83 c4 08 > [ 12.920165] RIP [] l2cap_chan_put+0x34/0x50 > [ 12.920166] RSP > [ 12.920167] CR2: 0010 > [ 12.920417] ---[ end trace 5a9114e8a158ab84 ]--- > > Introduced in commit 61d6ef3e ("Bluetooth: Make better use of l2cap_chan > reference counting"). > > Signed-off-by: Sasha Levin > --- > net/bluetooth/l2cap_sock.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Patch has been applied to bluetooth-next. Thanks. Gustavo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
With recent changes in omap gpmc driver code, in case of DT boot mode, where bootloader does not configure gpmc cs space will result into kernel BUG() inside gpmc_mem_init() function, as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and gpmc_config7[0].baseaddress is set to '0' on reset. This use-case is applicable for any board/EVM which doesn't have any peripheral connected to gpmc cs0, for example BeagleXM and BeagleBone, so DT boot mode fails. This patch adds of_have_populated_dt() check before creating device, so that for DT boot mode, gpmc probe will not be called which is expected behavior, as gpmc is not supported yet from DT. Signed-off-by: Vaibhav Hiremath Cc: Afzal Mohammed Cc: Tony Lindgren Cc Paul Walmsley --- This should go in for rc1, as this breaks AM33xx boot. arch/arm/mach-omap2/gpmc.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 8ab1e1b..c68f9e1 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -981,6 +981,10 @@ static int __init omap_gpmc_init(void) struct platform_device *pdev; char *oh_name = "gpmc"; + /* If dtb is there, the devices will be created dynamically */ + if (of_have_populated_dt()) + return -ENODEV; + oh = omap_hwmod_lookup(oh_name); if (!oh) { pr_err("Could not look up %s\n", oh_name); -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
On 10/08/2012 07:35 PM, Tony Lindgren wrote: > - omap-dma.c and omap-pcm.c can test the arch locally as > omap1 and omap2 cannot be compiled together because of > conflicting compiler flags > sound/soc/omap/omap-pcm.c |9 +++-- Tony: is this going to be included in 3.7? Acked-by: Peter Ujfalusi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PULL REQUEST] i2c-embedded for 3.7
Hi Linus, please pull the changes for i2c-embedded for the 3.7 kernel. They include: - massive rework of the omap driver - massive rework of the at91 driver. In fact, the old driver gets removed; I am okay with this approach since the old driver was depending on BROKEN and its limitations made it practically unusable, so people used bitbanging instead. But even if there are users, there is no platform_data or module parameter which would need to be converted. It is just another driver doing I2C transfers, just way better. Modifications of arch/arm/at91 related files have proper acks from the maintainer. - new driver for R-Car I2C - devicetree and generic_clock conversions and fixes - ususal driver fixes and changes. The rework patches have come a long way and lots of people have been involved in creating/testing them. Most patches have been in linux-next at least since 3.6-rc5. A few have been added in the last week, I have to admit. An unexpected (but welcome :)) peak in private life is the cause for that. The "late" patches shouldn't cause any merge conflicts and I will have a special eye on them during the stabilization phase. This is an exception and I want to have the patches in place properly in time again for the next kernels. So, please pull. Regards, Wolfram The following changes since commit 979570e02981d4a8fc20b3cc8fd651856c98ee9d: Linux 3.6-rc7 (2012-09-23 18:10:57 -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 62885f59a26195d9f6a3f8c795225dfbab62a110: MXS: Implement DMA support into mxs-i2c (2012-10-08 12:47:33 +0200) Fabio Estevam (2): i2c: imx: Use dev_info to indicate that i2c driver was succesfully registered i2c: imx: Use dev_dbg logging style Felipe Balbi (21): i2c: omap: switch to devm_* API i2c: omap: simplify num_bytes handling i2c: omap: decrease indentation level on data handling i2c: omap: add blank lines i2c: omap: simplify omap_i2c_ack_stat() i2c: omap: split out [XR]DR and [XR]RDY i2c: omap: improve i462 errata handling i2c: omap: re-factor receive/transmit data loop i2c: omap: switch over to do {} while loop i2c: omap: ack IRQ in parts i2c: omap: switch to platform_get_irq() i2c: omap: bus: add a receiver flag i2c: omap: simplify errata check i2c: omap: always return IRQ_HANDLED i2c: omap: simplify IRQ exit path i2c: omap: resize fifos before each message i2c: omap: get rid of the "complete" label i2c: omap: switch to threaded IRQ support i2c: omap: remove unnecessary pm_runtime_suspended check i2c: omap: switch over to autosuspend API i2c: omap: sanitize exit path Florian Vaussard (1): omap-i2c: fix incorrect log message when using a device tree Heiko Schocher (1): i2c: davinci: add OF support Jean Pihet (1): ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints Joakim Tjernlund (1): i2c: mpc: Wait for STOP to hit the bus Kuninori Morimoto (1): i2c: add Renesas R-Car I2C driver Lee Jones (1): i2c: nomadik: Add Device Tree support to the Nomadik I2C driver Linus Walleij (1): i2c: nomadik: stop fetching the regulator Ludovic Desroches (5): ARM: at91: do not configure at91sam9g10 twi pio as open-drain i2c: at91: add dt support to i2c-at91 ARM: at91: add clocks for I2C DT entries ARM: dts: add twi nodes for atmel SoCs ARM: dts: add twi nodes for atmel boards Marek Vasut (1): MXS: Implement DMA support into mxs-i2c Murali Karicheri (1): i2c: davinci: preparation for switch to common clock framework Nikolaus Voss (4): Replace clk_lookup.con_id with clk_lookup.dev_id entries for twi clk i2c: at91: remove old polling driver i2c: at91: add new driver arm: at91: G45 TWI: remove open drain setting for twi function gpios Shubhrajyoti D (1): i2c: omap: remove redundant status read Thomas Abraham (1): i2c: s3c2410: use clk_prepare_enable and clk_disable_unprepare Thomas Kavanagh (1): i2c: algo: pca: Fix chip reset function for PCA9665 Wolfram Sang (1): Merge tag 'v3.6-rc7' into i2c-embedded/for-next .../devicetree/bindings/i2c/atmel-i2c.txt | 30 + Documentation/devicetree/bindings/i2c/davinci.txt | 28 + Documentation/devicetree/bindings/i2c/i2c-mxs.txt |2 + Documentation/devicetree/bindings/i2c/nomadik.txt | 23 + arch/arm/boot/dts/at91sam9260.dtsi | 10 + arch/arm/boot/dts/at91sam9263.dtsi | 10 + arch/arm/boot/dts/at91sam9g20.dtsi |4 + arch/arm/boot/dts/at91sam9g25ek.dts| 12 + arch/arm/boot/dts/at91sam9g45.dtsi | 20 + arch/arm/boot/dts/at91sam9m10g45ek.dts |8 + arch/
Re: [RFC PATCH 03/06] input/rmi4: I2C physical interface
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote: > The I2C physical driver is not extensively changed in terms of functionality > since the previous patch. Management of the attention GPIO has been moved to > rmi_driver.c (see previous email), and most of the debug related interfaces > have been moved from sysfs to debugfs. Control of the debug features has been > moved from compile-time to runtime switches available via debugfs. > > The core I2C functionality was previously ACKed by Jean Delvare. I don't > believe that portion of the code has changed much since then, but we'd > appreciate a second glance at this. The above commit blurb looks more like a changelog than a description of the actual patch. Nothing wrong with that but begin by describing the patch first. (...) > +#ifdef CONFIG_RMI4_DEBUG > + > +#include > +#include Just move these up to the common includes. It doesn't matter that they get included even when debug is not enabled. > +static int setup_debugfs(struct rmi_device *rmi_dev, struct rmi_i2c_data > *data); > +static void teardown_debugfs(struct rmi_i2c_data *data); Why do you need to forward-declare these? Can't you just move them up above the functions using them? > +struct i2c_debugfs_data { > + bool done; Done with what? ... needs some doc. > + struct rmi_i2c_data *i2c_data; > +}; (...) > +static int __devinit rmi_i2c_probe(struct i2c_client *client, > + const struct i2c_device_id *id) (...) > + rmi_phys = kzalloc(sizeof(struct rmi_phys_device), GFP_KERNEL); (...) > + data = kzalloc(sizeof(struct rmi_i2c_data), GFP_KERNEL); Can you use devm_kzalloc(&client->dev, ...) for these so you don't need to free() them explicitly? (...) > +static int __devexit rmi_i2c_remove(struct i2c_client *client) > +{ > + struct rmi_phys_device *phys = i2c_get_clientdata(client); > + struct rmi_device_platform_data *pd = client->dev.platform_data; > + > + /* Can I remove this disable_device */ > + /*disable_device(phys); */ So just delete these two lines then? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] Reset PCIe devices to address DMA problem on kdump with iommu
(2012/10/03 22:23), Don Dutile wrote: On 10/02/2012 03:49 AM, Takao Indoh wrote: These patches reset PCIe devices at boot time to address DMA problem on kdump with iommu. When "reset_devices" is specified, a hot reset is triggered on each PCIe root port and downstream port to reset its downstream endpoint. Background: A kdump problem about DMA has been discussed for a long time. That is, when a kernel is switched to the kdump kernel DMA derived from first kernel affects second kernel. Recently this problem surfaces when iommu is used for PCI passthrough on KVM guest. In the case of the machine I use, when intel_iommu=on is specified, DMAR error is detected in kdump kernel and PCI SERR is also detected. Finally kdump fails because some devices does not work correctly. The root cause is that ongoing DMA from first kernel causes DMAR fault because page table of DMAR is initialized while kdump kernel is booting up. Therefore to address this problem DMA needs to be stopped before DMAR is initialized at kdump kernel boot time. By these patches, PCIe devices are reset by hot reset and its DMA is stopped when reset_devices is specified. One problem of this solution is that the monitor blacks out when VGA controller is reset. So this patch does not reset the port whose child endpoint is VGA device. v2: Reset devices in setup_arch() because reset need to be done before interrupt remapping is initialized. v1: https://lkml.org/lkml/2012/8/3/160 Thanks, Takao Indoh -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Maybe you've tried the following, and I missed a thread on it, but instead of a somewhat-large, reset hammer, did any one try just reading all the endpoint-only device CMD register, flip the MasterEnable bit off, and write it back? that would stop all DMA (should stop all MSI writes as well since they are just another DMA), and then restart the system? May also have to do PCI INT Disable as well... and note, that's a PCI 2.3 optional feature so devices using INT signalling vs MSI is just borked on IOMMU/intr-remapping systems... which I would expect are few. Then again, if this is foolishly done, then reset legacy PCI busses as the fallback. Just clearing bus master bit and INTx disable bit in setup_arch() did not solve this problem. I still got DMAR error on devices(for exmaple, igb and megaraid_sas). Clearing bus master in setup_arch() and resetting devices in fixup_final like v1 patch is better, DMAR error was not detected. But on certain machine kdump kernel hung up when resetting devices. It seems to be a problem specific to the platform. And, resetting devices in setup_arch() like v2 patch solves all problems I found so far. Thanks, Takao Indoh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/11] net: xilinx: Show csum in bootlog
On 10/05/2012 03:51 PM, Ben Hutchings wrote: On Fri, 2012-10-05 at 11:35 +0200, Michal Simek wrote: On 10/04/2012 09:15 PM, Ben Hutchings wrote: On Thu, 2012-10-04 at 20:14 +0200, Michal Simek wrote: Just show current setting in bootlog. [...] --- a/drivers/net/ethernet/xilinx/ll_temac_main.c +++ b/drivers/net/ethernet/xilinx/ll_temac_main.c @@ -1052,12 +1052,14 @@ static int __devinit temac_of_probe(struct platform_device *op) /* Setup checksum offload, but default to off if not specified */ lp->temac_features = 0; p = (__be32 *)of_get_property(op->dev.of_node, "xlnx,txcsum", NULL); + dev_info(&op->dev, "TX_CSUM %d\n", be32_to_cpup(p)); if (p && be32_to_cpu(*p)) { lp->temac_features |= TEMAC_FEATURE_TX_CSUM; /* Can checksum TCP/UDP over IPv4. */ ndev->features |= NETIF_F_IP_CSUM; } p = (__be32 *)of_get_property(op->dev.of_node, "xlnx,rxcsum", NULL); + dev_info(&op->dev, "RX_CSUM %d\n", be32_to_cpup(p)); [...] Is there any particular reason you think this needs to be logged by default, rather than letting users run ethtool -k? I suggest using dev_dbg() instead. Ok. I have looked at it and there are missing some bits in ndev->features. Can you please check that my setting is correct? It is SG DMA ip/driver. ndev->features = NETIF_F_FRAGLIST | NETIF_F_SG NETIF_F_SG only; NETIF_F_FRAGLIST means you can handle skbs chained through the frag_list pointer. The driver is able to handle skb fragments too. temac_start_xmit With two options for csum on RX/TX. They can be selected independently. tx Partial csum over IPv4. -> NETIF_F_IP_CSUM tx Full csum. -> NETIF_F_HW_CSUM NETIF_F_IP_CSUM means you have hardware checksum generation for TCP/IPv4 and UDP/IPv4 only (XAE_FEATURE_FULL_TX_CSUM). NETIF_F_HW_CSUM means you have generic TCP-style checksum generation using the csum_start and csum_offset fields of the skb (XAE_FEATURE_PARTIAL_TX_CSUM). By the way, you're actually testing XAE_FEATURE_PARTIAL_RX_CSUM in axienet_start_xmit()... We have used non mainline ll_temac driver for a long time but we will move to this mainline version soon. It is on my todo list to clean this driver and test all these options. Also performance tests will be necessary to do. rx Full csum -> NETIF_F_RXCSUM Is there any option to support partial csum? There is no need to differentiate these in the device features. For TX the stack needs to know whether to use a software fallback before passing the skb to you, but on RX it looks at the ip_summed field of each skb you pass up. Hardware can be setup asymmetrically. It means enable CSUM only on RX or TX. All combination are valid. The point here is if Linux is not able to handle this then we have to create logic in the driver to support these options too. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 04/06] input/rmi4: Config files and makefiles
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote: (...) > diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig (...) > +config RMI4_DEBUG > + bool "RMI4 Debugging" > + depends on RMI4_BUS select DEBUG_FS This has been illustrated many times in the review. You definatley have code depending on debugfs when this is selected. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: busses: i2c-ocores: switch to devm_request_and_ioremap
Hi Peter, On Sun, Sep 23, 2012 at 2:22 PM, Peter Korsgaard wrote: >> "Maxin" == Maxin B John writes: > > Maxin> This drops a few lines of code and allows common APIs to handle > Maxin> those for us. > > Maxin> Signed-off-by: Maxin B. John > > Acked-by: Peter Korsgaard Is there any update on this ? > -- > Bye, Peter Korsgaard Best Regards, Maxin B. John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for alpha [ver #2]
Can you merge the following branch into the alpha tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-alpha-20121009 for you to fetch changes up to 55492254705f10d67f4225a0840156f856971519: UAPI: (Scripted) Disintegrate arch/alpha/include/asm (2012-10-09 09:46:29 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/alpha/include/asm arch/alpha/include/asm/Kbuild | 10 - arch/alpha/include/asm/a.out.h | 89 + arch/alpha/include/asm/compiler.h | 115 +- arch/alpha/include/asm/console.h| 48 +-- arch/alpha/include/asm/fpu.h| 124 +-- arch/alpha/include/asm/pal.h| 50 +-- arch/alpha/include/asm/param.h | 20 +- arch/alpha/include/asm/ptrace.h | 68 +--- arch/alpha/include/asm/signal.h | 135 +-- arch/alpha/include/asm/socket.h | 78 +--- arch/alpha/include/asm/termios.h| 68 +--- arch/alpha/include/asm/types.h | 13 +- arch/alpha/include/asm/unistd.h | 469 +-- arch/alpha/include/uapi/asm/Kbuild | 40 ++ arch/alpha/include/uapi/asm/a.out.h | 91 + arch/alpha/include/{ => uapi}/asm/auxvec.h | 0 arch/alpha/include/{ => uapi}/asm/bitsperlong.h | 0 arch/alpha/include/{ => uapi}/asm/byteorder.h | 0 arch/alpha/include/uapi/asm/compiler.h | 117 ++ arch/alpha/include/uapi/asm/console.h | 50 +++ arch/alpha/include/{ => uapi}/asm/errno.h | 0 arch/alpha/include/{ => uapi}/asm/fcntl.h | 0 arch/alpha/include/uapi/asm/fpu.h | 123 +++ arch/alpha/include/{ => uapi}/asm/gentrap.h | 0 arch/alpha/include/{ => uapi}/asm/ioctl.h | 0 arch/alpha/include/{ => uapi}/asm/ioctls.h | 0 arch/alpha/include/{ => uapi}/asm/ipcbuf.h | 0 arch/alpha/include/{ => uapi}/asm/kvm_para.h| 0 arch/alpha/include/{ => uapi}/asm/mman.h| 0 arch/alpha/include/{ => uapi}/asm/msgbuf.h | 0 arch/alpha/include/uapi/asm/pal.h | 52 +++ arch/alpha/include/uapi/asm/param.h | 21 ++ arch/alpha/include/{ => uapi}/asm/poll.h| 0 arch/alpha/include/{ => uapi}/asm/posix_types.h | 0 arch/alpha/include/uapi/asm/ptrace.h| 70 arch/alpha/include/{ => uapi}/asm/reg.h | 0 arch/alpha/include/{ => uapi}/asm/regdef.h | 0 arch/alpha/include/{ => uapi}/asm/resource.h| 0 arch/alpha/include/{ => uapi}/asm/sembuf.h | 0 arch/alpha/include/{ => uapi}/asm/setup.h | 0 arch/alpha/include/{ => uapi}/asm/shmbuf.h | 0 arch/alpha/include/{ => uapi}/asm/sigcontext.h | 0 arch/alpha/include/{ => uapi}/asm/siginfo.h | 0 arch/alpha/include/uapi/asm/signal.h| 135 +++ arch/alpha/include/uapi/asm/socket.h| 80 arch/alpha/include/{ => uapi}/asm/sockios.h | 0 arch/alpha/include/{ => uapi}/asm/stat.h| 0 arch/alpha/include/{ => uapi}/asm/statfs.h | 0 arch/alpha/include/{ => uapi}/asm/swab.h| 0 arch/alpha/include/{ => uapi}/asm/sysinfo.h | 0 arch/alpha/include/{ => uapi}/asm/termbits.h| 0 arch/alpha/include/uapi/asm/termios.h | 70 arch/alpha/include/uapi/asm/types.h | 16 + arch/alpha/include/uapi/asm/unistd.h| 471 54 files changed, 1348 insertions(+), 1275 deletions(-) create mode 100644 arch/alpha/include/uapi/asm/a.out.h rename arch/alpha/include/{ => uapi}/asm/auxvec.h (100%) rename arch/alpha/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/alpha/include/{ => uapi}/asm/byteorder.h (100%) create mode 100644 arch/alpha/include/uapi/asm/compiler.h create mode 100644 arch/alpha/include/uapi/asm/console.h rename arch/alpha/include/{ => uapi}/asm/errno.h (100%) rename arch/alpha/include/{ => uapi}/asm/fcntl.h (100%) create mode 100644 arch/alpha/incl
[GIT PULL] Disintegrate UAPI for ia64 [ver #2]
Can you merge the following branch into the ia64 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-ia64-20121009 for you to fetch changes up to 43e40f25d2c090392fc36cb900b42972e88cc2e2: UAPI: (Scripted) Disintegrate arch/ia64/include/asm (2012-10-09 09:47:00 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/ia64/include/asm arch/ia64/include/asm/Kbuild | 14 - arch/ia64/include/asm/gcc_intrin.h | 615 +--- arch/ia64/include/asm/intrinsics.h | 120 +--- arch/ia64/include/asm/kvm_para.h | 10 +- arch/ia64/include/asm/mman.h | 12 +- arch/ia64/include/asm/param.h | 22 +- arch/ia64/include/asm/perfmon.h| 171 +- arch/ia64/include/asm/ptrace.h | 236 +--- arch/ia64/include/asm/siginfo.h| 118 +--- arch/ia64/include/asm/signal.h | 122 +--- arch/ia64/include/asm/termios.h| 46 +- arch/ia64/include/asm/types.h | 19 +- arch/ia64/include/asm/unistd.h | 324 +-- arch/ia64/include/asm/ustack.h | 11 +- arch/ia64/include/uapi/asm/Kbuild | 45 ++ arch/ia64/include/{ => uapi}/asm/auxvec.h | 0 arch/ia64/include/{ => uapi}/asm/bitsperlong.h | 0 arch/ia64/include/{ => uapi}/asm/break.h | 0 arch/ia64/include/{ => uapi}/asm/byteorder.h | 0 arch/ia64/include/{ => uapi}/asm/cmpxchg.h | 0 arch/ia64/include/{ => uapi}/asm/errno.h | 0 arch/ia64/include/{ => uapi}/asm/fcntl.h | 0 arch/ia64/include/{ => uapi}/asm/fpu.h | 0 arch/ia64/include/uapi/asm/gcc_intrin.h| 618 + arch/ia64/include/{ => uapi}/asm/ia64regs.h| 0 arch/ia64/include/{ => uapi}/asm/intel_intrin.h| 0 arch/ia64/include/uapi/asm/intrinsics.h| 124 + arch/ia64/include/{ => uapi}/asm/ioctl.h | 0 arch/ia64/include/{ => uapi}/asm/ioctls.h | 0 arch/ia64/include/{ => uapi}/asm/ipcbuf.h | 0 arch/ia64/include/{ => uapi}/asm/kvm.h | 0 arch/ia64/include/uapi/asm/mman.h | 16 + arch/ia64/include/{ => uapi}/asm/msgbuf.h | 0 arch/ia64/include/uapi/asm/param.h | 29 + arch/ia64/include/uapi/asm/perfmon.h | 177 ++ .../include/{ => uapi}/asm/perfmon_default_smpl.h | 0 arch/ia64/include/{ => uapi}/asm/poll.h| 0 arch/ia64/include/{ => uapi}/asm/posix_types.h | 0 arch/ia64/include/uapi/asm/ptrace.h| 247 arch/ia64/include/{ => uapi}/asm/ptrace_offsets.h | 0 arch/ia64/include/{ => uapi}/asm/resource.h| 0 arch/ia64/include/{ => uapi}/asm/rse.h | 0 arch/ia64/include/{ => uapi}/asm/sembuf.h | 0 arch/ia64/include/{ => uapi}/asm/setup.h | 0 arch/ia64/include/{ => uapi}/asm/shmbuf.h | 0 arch/ia64/include/{ => uapi}/asm/sigcontext.h | 0 arch/ia64/include/uapi/asm/siginfo.h | 121 arch/ia64/include/uapi/asm/signal.h| 127 + arch/ia64/include/{ => uapi}/asm/socket.h | 0 arch/ia64/include/{ => uapi}/asm/sockios.h | 0 arch/ia64/include/{ => uapi}/asm/stat.h| 0 arch/ia64/include/{ => uapi}/asm/statfs.h | 0 arch/ia64/include/{ => uapi}/asm/swab.h| 0 arch/ia64/include/{ => uapi}/asm/termbits.h| 0 arch/ia64/include/uapi/asm/termios.h | 50 ++ arch/ia64/include/uapi/asm/types.h | 31 ++ arch/ia64/include/{ => uapi}/asm/ucontext.h| 0 arch/ia64/include/uapi/asm/unistd.h| 328 +++ arch/ia64/include/uapi/asm/ustack.h| 12 + 59 files changed, 1961 insertions(+), 1804 deletions(-) rename arch/ia64/include/{ => uapi}/asm/auxvec.h (100%) renam
[GIT PULL] Disintegrate UAPI for m68k [ver #2]
Can you merge the following branch into the m68k tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-m68k-20121009 for you to fetch changes up to 10b3a979347d4aba7de19e8d33eb8b87fe2a11dd: UAPI: (Scripted) Disintegrate arch/m68k/include/asm (2012-10-09 09:47:06 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/m68k/include/asm arch/m68k/include/asm/Kbuild | 2 - arch/m68k/include/asm/ptrace.h | 72 + arch/m68k/include/asm/setup.h | 82 +- arch/m68k/include/asm/signal.h | 118 +--- arch/m68k/include/asm/termios.h| 44 +-- arch/m68k/include/asm/unistd.h | 354 +--- arch/m68k/include/uapi/asm/Kbuild | 23 ++ arch/m68k/include/{ => uapi}/asm/a.out.h | 0 arch/m68k/include/{ => uapi}/asm/auxvec.h | 0 arch/m68k/include/{ => uapi}/asm/byteorder.h | 0 arch/m68k/include/{ => uapi}/asm/cachectl.h| 0 arch/m68k/include/{ => uapi}/asm/fcntl.h | 0 arch/m68k/include/{ => uapi}/asm/ioctls.h | 0 arch/m68k/include/{ => uapi}/asm/msgbuf.h | 0 arch/m68k/include/{ => uapi}/asm/param.h | 0 arch/m68k/include/{ => uapi}/asm/poll.h| 0 arch/m68k/include/{ => uapi}/asm/posix_types.h | 0 arch/m68k/include/uapi/asm/ptrace.h| 79 ++ arch/m68k/include/{ => uapi}/asm/sembuf.h | 0 arch/m68k/include/uapi/asm/setup.h | 103 +++ arch/m68k/include/{ => uapi}/asm/shmbuf.h | 0 arch/m68k/include/{ => uapi}/asm/sigcontext.h | 0 arch/m68k/include/uapi/asm/signal.h| 118 arch/m68k/include/{ => uapi}/asm/socket.h | 0 arch/m68k/include/{ => uapi}/asm/sockios.h | 0 arch/m68k/include/{ => uapi}/asm/stat.h| 0 arch/m68k/include/{ => uapi}/asm/swab.h| 0 arch/m68k/include/{ => uapi}/asm/termbits.h| 0 arch/m68k/include/uapi/asm/termios.h | 44 +++ arch/m68k/include/uapi/asm/unistd.h| 356 + 30 files changed, 728 insertions(+), 667 deletions(-) rename arch/m68k/include/{ => uapi}/asm/a.out.h (100%) rename arch/m68k/include/{ => uapi}/asm/auxvec.h (100%) rename arch/m68k/include/{ => uapi}/asm/byteorder.h (100%) rename arch/m68k/include/{ => uapi}/asm/cachectl.h (100%) rename arch/m68k/include/{ => uapi}/asm/fcntl.h (100%) rename arch/m68k/include/{ => uapi}/asm/ioctls.h (100%) rename arch/m68k/include/{ => uapi}/asm/msgbuf.h (100%) rename arch/m68k/include/{ => uapi}/asm/param.h (100%) rename arch/m68k/include/{ => uapi}/asm/poll.h (100%) rename arch/m68k/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/m68k/include/uapi/asm/ptrace.h rename arch/m68k/include/{ => uapi}/asm/sembuf.h (100%) create mode 100644 arch/m68k/include/uapi/asm/setup.h rename arch/m68k/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/m68k/include/{ => uapi}/asm/sigcontext.h (100%) create mode 100644 arch/m68k/include/uapi/asm/signal.h rename arch/m68k/include/{ => uapi}/asm/socket.h (100%) rename arch/m68k/include/{ => uapi}/asm/sockios.h (100%) rename arch/m68k/include/{ => uapi}/asm/stat.h (100%) rename arch/m68k/include/{ => uapi}/asm/swab.h (100%) rename arch/m68k/include/{ => uapi}/asm/termbits.h (100%) create mode 100644 arch/m68k/include/uapi/asm/termios.h create mode 100644 arch/m68k/include/uapi/asm/unistd.h . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for microblaze [ver #2]
Can you merge the following branch into the microblaze tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-microblaze-20121009 for you to fetch changes up to 1883baaa2ea07d83228d5a83a3133cd02bab7fc6: UAPI: (Scripted) Disintegrate arch/microblaze/include/asm (2012-10-09 09:47:10 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/microblaze/include/asm arch/microblaze/include/asm/Kbuild | 2 - arch/microblaze/include/asm/elf.h | 97 + arch/microblaze/include/asm/ptrace.h | 62 +--- arch/microblaze/include/asm/setup.h| 6 +- arch/microblaze/include/asm/unistd.h | 390 +--- arch/microblaze/include/uapi/asm/Kbuild| 32 ++ arch/microblaze/include/{ => uapi}/asm/auxvec.h| 0 .../include/{ => uapi}/asm/bitsperlong.h | 0 arch/microblaze/include/{ => uapi}/asm/byteorder.h | 0 arch/microblaze/include/uapi/asm/elf.h | 121 +++ arch/microblaze/include/{ => uapi}/asm/errno.h | 0 arch/microblaze/include/{ => uapi}/asm/fcntl.h | 0 arch/microblaze/include/{ => uapi}/asm/ioctl.h | 0 arch/microblaze/include/{ => uapi}/asm/ioctls.h| 0 arch/microblaze/include/{ => uapi}/asm/ipcbuf.h| 0 arch/microblaze/include/{ => uapi}/asm/kvm_para.h | 0 arch/microblaze/include/{ => uapi}/asm/mman.h | 0 arch/microblaze/include/{ => uapi}/asm/msgbuf.h| 0 arch/microblaze/include/{ => uapi}/asm/param.h | 0 arch/microblaze/include/{ => uapi}/asm/poll.h | 0 .../include/{ => uapi}/asm/posix_types.h | 0 arch/microblaze/include/uapi/asm/ptrace.h | 72 arch/microblaze/include/{ => uapi}/asm/resource.h | 0 arch/microblaze/include/{ => uapi}/asm/sembuf.h| 0 arch/microblaze/include/uapi/asm/setup.h | 19 + arch/microblaze/include/{ => uapi}/asm/shmbuf.h| 0 .../microblaze/include/{ => uapi}/asm/sigcontext.h | 0 arch/microblaze/include/{ => uapi}/asm/siginfo.h | 0 arch/microblaze/include/{ => uapi}/asm/signal.h| 0 arch/microblaze/include/{ => uapi}/asm/socket.h| 0 arch/microblaze/include/{ => uapi}/asm/sockios.h | 0 arch/microblaze/include/{ => uapi}/asm/stat.h | 0 arch/microblaze/include/{ => uapi}/asm/statfs.h| 0 arch/microblaze/include/{ => uapi}/asm/swab.h | 0 arch/microblaze/include/{ => uapi}/asm/termbits.h | 0 arch/microblaze/include/{ => uapi}/asm/termios.h | 0 arch/microblaze/include/{ => uapi}/asm/types.h | 0 arch/microblaze/include/uapi/asm/unistd.h | 400 + 38 files changed, 649 insertions(+), 552 deletions(-) rename arch/microblaze/include/{ => uapi}/asm/auxvec.h (100%) rename arch/microblaze/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/microblaze/include/{ => uapi}/asm/byteorder.h (100%) create mode 100644 arch/microblaze/include/uapi/asm/elf.h rename arch/microblaze/include/{ => uapi}/asm/errno.h (100%) rename arch/microblaze/include/{ => uapi}/asm/fcntl.h (100%) rename arch/microblaze/include/{ => uapi}/asm/ioctl.h (100%) rename arch/microblaze/include/{ => uapi}/asm/ioctls.h (100%) rename arch/microblaze/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/microblaze/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/microblaze/include/{ => uapi}/asm/mman.h (100%) rename arch/microblaze/include/{ => uapi}/asm/msgbuf.h (100%) rename arch/microblaze/include/{ => uapi}/asm/param.h (100%) rename arch/microblaze/include/{ => uapi}/asm/poll.h (100%) rename arch/microblaze/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/microblaze/include/uapi/asm/ptrace.h rename arch/microblaze/include/{ => uapi}/asm/resource.h (100%) rename arch/microblaze/include/{ => uapi}/asm/sembuf.h (100%) create mode 100644 arch/microblaze/include/uapi/asm/setup.h rename arch/microblaze/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/microblaze/include/{ => uapi}/
[GIT PULL] Disintegrate UAPI for s390 [ver #2]
Can you merge the following branch into the s390 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-s390-20121009 for you to fetch changes up to 9807f75955ea7f1877981056755284481873115c: UAPI: (Scripted) Disintegrate arch/s390/include/asm (2012-10-09 09:47:31 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/s390/include/asm arch/s390/include/asm/Kbuild | 14 - arch/s390/include/asm/chpid.h | 17 +- arch/s390/include/asm/cmb.h| 51 +-- arch/s390/include/asm/debug.h | 28 +- arch/s390/include/asm/kvm_para.h | 14 +- arch/s390/include/asm/mman.h | 6 +- arch/s390/include/asm/ptrace.h | 462 +--- arch/s390/include/asm/schid.h | 15 +- arch/s390/include/asm/setup.h | 7 +- arch/s390/include/asm/signal.h | 128 +-- arch/s390/include/asm/termios.h| 42 +-- arch/s390/include/asm/types.h | 15 +- arch/s390/include/asm/unistd.h | 367 +-- arch/s390/include/uapi/asm/Kbuild | 45 +++ arch/s390/include/{ => uapi}/asm/auxvec.h | 0 arch/s390/include/{ => uapi}/asm/bitsperlong.h | 0 arch/s390/include/{ => uapi}/asm/byteorder.h | 0 arch/s390/include/uapi/asm/chpid.h | 22 ++ arch/s390/include/{ => uapi}/asm/chsc.h| 0 arch/s390/include/uapi/asm/cmb.h | 53 +++ arch/s390/include/{ => uapi}/asm/dasd.h| 0 arch/s390/include/uapi/asm/debug.h | 34 ++ arch/s390/include/{ => uapi}/asm/errno.h | 0 arch/s390/include/{ => uapi}/asm/fcntl.h | 0 arch/s390/include/{ => uapi}/asm/ioctl.h | 0 arch/s390/include/{ => uapi}/asm/ioctls.h | 0 arch/s390/include/{ => uapi}/asm/ipcbuf.h | 0 arch/s390/include/{ => uapi}/asm/kvm.h | 0 arch/s390/include/{ => uapi}/asm/kvm_virtio.h | 0 arch/s390/include/uapi/asm/mman.h | 6 + arch/s390/include/{ => uapi}/asm/monwriter.h | 0 arch/s390/include/{ => uapi}/asm/msgbuf.h | 0 arch/s390/include/{ => uapi}/asm/param.h | 0 arch/s390/include/{ => uapi}/asm/poll.h| 0 arch/s390/include/{ => uapi}/asm/posix_types.h | 0 arch/s390/include/uapi/asm/ptrace.h| 472 + arch/s390/include/{ => uapi}/asm/qeth.h| 0 arch/s390/include/{ => uapi}/asm/resource.h| 0 arch/s390/include/uapi/asm/schid.h | 16 + arch/s390/include/{ => uapi}/asm/sembuf.h | 0 arch/s390/include/uapi/asm/setup.h | 13 + arch/s390/include/{ => uapi}/asm/shmbuf.h | 0 arch/s390/include/{ => uapi}/asm/sigcontext.h | 0 arch/s390/include/{ => uapi}/asm/siginfo.h | 0 arch/s390/include/uapi/asm/signal.h| 135 +++ arch/s390/include/{ => uapi}/asm/socket.h | 0 arch/s390/include/{ => uapi}/asm/sockios.h | 0 arch/s390/include/{ => uapi}/asm/stat.h| 0 arch/s390/include/{ => uapi}/asm/statfs.h | 0 arch/s390/include/{ => uapi}/asm/swab.h| 0 arch/s390/include/{ => uapi}/asm/tape390.h | 0 arch/s390/include/{ => uapi}/asm/termbits.h| 0 arch/s390/include/uapi/asm/termios.h | 49 +++ arch/s390/include/uapi/asm/types.h | 22 ++ arch/s390/include/{ => uapi}/asm/ucontext.h| 0 arch/s390/include/uapi/asm/unistd.h| 374 arch/s390/include/{ => uapi}/asm/vtoc.h| 0 arch/s390/include/{ => uapi}/asm/zcrypt.h | 0 58 files changed, 1258 insertions(+), 1149 deletions(-) rename arch/s390/include/{ => uapi}/asm/auxvec.h (100%) rename arch/s390/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/s390/include/{ => uapi}/asm/byteorder.h (100%) create mode 100644 arch/s390/include/uapi/asm/chpid.h rename arch/s390/include/{ => uapi}/asm/chsc.h (100%) create mode 100644 arch/s390/include/uapi/asm/cm
[GIT PULL] Disintegrate UAPI for xtensa [ver #2]
Can you merge the following branch into the xtensa tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-xtensa-20121009 for you to fetch changes up to 91a0696e40414e9f1554cd91060f6b404d545cb3: UAPI: (Scripted) Disintegrate arch/xtensa/include/asm (2012-10-09 09:47:57 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/xtensa/include/asm arch/xtensa/include/asm/Kbuild | 1 - arch/xtensa/include/asm/param.h | 20 +- arch/xtensa/include/asm/ptrace.h | 66 +-- arch/xtensa/include/asm/signal.h | 134 + arch/xtensa/include/asm/termios.h| 43 +- arch/xtensa/include/asm/types.h | 15 +- arch/xtensa/include/asm/unistd.h | 698 +- arch/xtensa/include/uapi/asm/Kbuild | 31 + arch/xtensa/include/{ => uapi}/asm/auxvec.h | 0 arch/xtensa/include/{ => uapi}/asm/bitsperlong.h | 0 arch/xtensa/include/{ => uapi}/asm/byteorder.h | 0 arch/xtensa/include/{ => uapi}/asm/errno.h | 0 arch/xtensa/include/{ => uapi}/asm/fcntl.h | 0 arch/xtensa/include/{ => uapi}/asm/ioctl.h | 0 arch/xtensa/include/{ => uapi}/asm/ioctls.h | 0 arch/xtensa/include/{ => uapi}/asm/ipcbuf.h | 0 arch/xtensa/include/{ => uapi}/asm/kvm_para.h| 0 arch/xtensa/include/{ => uapi}/asm/mman.h| 0 arch/xtensa/include/{ => uapi}/asm/msgbuf.h | 0 arch/xtensa/include/uapi/asm/param.h | 30 + arch/xtensa/include/{ => uapi}/asm/poll.h| 0 arch/xtensa/include/{ => uapi}/asm/posix_types.h | 0 arch/xtensa/include/uapi/asm/ptrace.h| 77 +++ arch/xtensa/include/{ => uapi}/asm/resource.h| 0 arch/xtensa/include/{ => uapi}/asm/sembuf.h | 0 arch/xtensa/include/{ => uapi}/asm/setup.h | 0 arch/xtensa/include/{ => uapi}/asm/shmbuf.h | 0 arch/xtensa/include/{ => uapi}/asm/sigcontext.h | 0 arch/xtensa/include/{ => uapi}/asm/siginfo.h | 0 arch/xtensa/include/uapi/asm/signal.h| 148 + arch/xtensa/include/{ => uapi}/asm/socket.h | 0 arch/xtensa/include/{ => uapi}/asm/sockios.h | 0 arch/xtensa/include/{ => uapi}/asm/stat.h| 0 arch/xtensa/include/{ => uapi}/asm/statfs.h | 0 arch/xtensa/include/{ => uapi}/asm/swab.h| 0 arch/xtensa/include/{ => uapi}/asm/termbits.h| 0 arch/xtensa/include/uapi/asm/termios.h | 56 ++ arch/xtensa/include/uapi/asm/types.h | 28 + arch/xtensa/include/uapi/asm/unistd.h| 709 +++ 39 files changed, 1086 insertions(+), 970 deletions(-) rename arch/xtensa/include/{ => uapi}/asm/auxvec.h (100%) rename arch/xtensa/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/xtensa/include/{ => uapi}/asm/byteorder.h (100%) rename arch/xtensa/include/{ => uapi}/asm/errno.h (100%) rename arch/xtensa/include/{ => uapi}/asm/fcntl.h (100%) rename arch/xtensa/include/{ => uapi}/asm/ioctl.h (100%) rename arch/xtensa/include/{ => uapi}/asm/ioctls.h (100%) rename arch/xtensa/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/xtensa/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/xtensa/include/{ => uapi}/asm/mman.h (100%) rename arch/xtensa/include/{ => uapi}/asm/msgbuf.h (100%) create mode 100644 arch/xtensa/include/uapi/asm/param.h rename arch/xtensa/include/{ => uapi}/asm/poll.h (100%) rename arch/xtensa/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/xtensa/include/uapi/asm/ptrace.h rename arch/xtensa/include/{ => uapi}/asm/resource.h (100%) rename arch/xtensa/include/{ => uapi}/asm/sembuf.h (100%) rename arch/xtensa/include/{ => uapi}/asm/setup.h (100%) rename arch/xtensa/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/xtensa/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/xtensa/include/{ => uapi}/asm/siginfo.h (100%) create mode 100644 arch/xtensa/include/uapi/asm/signal.h rename arch/xtensa/include/{ =
[GIT PULL] Disintegrate UAPI for parisc [ver #2]
Can you merge the following branch into the parisc tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-parisc-20121009 for you to fetch changes up to 7869b46c99d8de719f7543d6ba432a7fcc3c78b3: UAPI: (Scripted) Disintegrate arch/parisc/include/asm (2012-10-09 09:47:22 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/parisc/include/asm arch/parisc/include/asm/Kbuild | 2 - arch/parisc/include/asm/pdc.h| 423 +--- arch/parisc/include/asm/ptrace.h | 46 +- arch/parisc/include/asm/signal.h | 113 +-- arch/parisc/include/asm/termios.h| 41 +- arch/parisc/include/asm/unistd.h | 835 +- arch/parisc/include/uapi/asm/Kbuild | 32 + arch/parisc/include/{ => uapi}/asm/auxvec.h | 0 arch/parisc/include/{ => uapi}/asm/bitsperlong.h | 0 arch/parisc/include/{ => uapi}/asm/byteorder.h | 0 arch/parisc/include/{ => uapi}/asm/errno.h | 0 arch/parisc/include/{ => uapi}/asm/fcntl.h | 0 arch/parisc/include/{ => uapi}/asm/ioctl.h | 0 arch/parisc/include/{ => uapi}/asm/ioctls.h | 0 arch/parisc/include/{ => uapi}/asm/ipcbuf.h | 0 arch/parisc/include/{ => uapi}/asm/kvm_para.h| 0 arch/parisc/include/{ => uapi}/asm/mman.h| 0 arch/parisc/include/{ => uapi}/asm/msgbuf.h | 0 arch/parisc/include/{ => uapi}/asm/param.h | 0 arch/parisc/include/uapi/asm/pdc.h | 427 arch/parisc/include/{ => uapi}/asm/poll.h| 0 arch/parisc/include/{ => uapi}/asm/posix_types.h | 0 arch/parisc/include/uapi/asm/ptrace.h| 47 ++ arch/parisc/include/{ => uapi}/asm/resource.h| 0 arch/parisc/include/{ => uapi}/asm/sembuf.h | 0 arch/parisc/include/{ => uapi}/asm/setup.h | 0 arch/parisc/include/{ => uapi}/asm/shmbuf.h | 0 arch/parisc/include/{ => uapi}/asm/sigcontext.h | 0 arch/parisc/include/{ => uapi}/asm/siginfo.h | 0 arch/parisc/include/uapi/asm/signal.h| 118 arch/parisc/include/{ => uapi}/asm/socket.h | 0 arch/parisc/include/{ => uapi}/asm/sockios.h | 0 arch/parisc/include/{ => uapi}/asm/stat.h| 0 arch/parisc/include/{ => uapi}/asm/statfs.h | 0 arch/parisc/include/{ => uapi}/asm/swab.h| 0 arch/parisc/include/{ => uapi}/asm/termbits.h| 0 arch/parisc/include/uapi/asm/termios.h | 43 ++ arch/parisc/include/{ => uapi}/asm/types.h | 0 arch/parisc/include/uapi/asm/unistd.h| 837 +++ 39 files changed, 1511 insertions(+), 1453 deletions(-) rename arch/parisc/include/{ => uapi}/asm/auxvec.h (100%) rename arch/parisc/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/parisc/include/{ => uapi}/asm/byteorder.h (100%) rename arch/parisc/include/{ => uapi}/asm/errno.h (100%) rename arch/parisc/include/{ => uapi}/asm/fcntl.h (100%) rename arch/parisc/include/{ => uapi}/asm/ioctl.h (100%) rename arch/parisc/include/{ => uapi}/asm/ioctls.h (100%) rename arch/parisc/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/parisc/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/parisc/include/{ => uapi}/asm/mman.h (100%) rename arch/parisc/include/{ => uapi}/asm/msgbuf.h (100%) rename arch/parisc/include/{ => uapi}/asm/param.h (100%) create mode 100644 arch/parisc/include/uapi/asm/pdc.h rename arch/parisc/include/{ => uapi}/asm/poll.h (100%) rename arch/parisc/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/parisc/include/uapi/asm/ptrace.h rename arch/parisc/include/{ => uapi}/asm/resource.h (100%) rename arch/parisc/include/{ => uapi}/asm/sembuf.h (100%) rename arch/parisc/include/{ => uapi}/asm/setup.h (100%) rename arch/parisc/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/parisc/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/parisc/include/{ => uapi}/asm/siginfo.h (100%) create mode
[GIT PULL] Disintegrate UAPI for unicore32 [ver #2]
Can you merge the following branch into the unicore32 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-unicore32-20121009 for you to fetch changes up to 2a0a9522d64a73b8c5b37a375cd0d46c2abc18fb: UAPI: (Scripted) Disintegrate arch/unicore32/include/asm (2012-10-09 09:47:48 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/unicore32/include/asm arch/unicore32/include/asm/Kbuild | 1 - arch/unicore32/include/asm/ptrace.h| 76 +- arch/unicore32/include/uapi/asm/Kbuild | 5 ++ arch/unicore32/include/{ => uapi}/asm/byteorder.h | 0 arch/unicore32/include/{ => uapi}/asm/kvm_para.h | 0 arch/unicore32/include/uapi/asm/ptrace.h | 90 ++ arch/unicore32/include/{ => uapi}/asm/sigcontext.h | 0 arch/unicore32/include/{ => uapi}/asm/unistd.h | 0 8 files changed, 96 insertions(+), 76 deletions(-) rename arch/unicore32/include/{ => uapi}/asm/byteorder.h (100%) rename arch/unicore32/include/{ => uapi}/asm/kvm_para.h (100%) create mode 100644 arch/unicore32/include/uapi/asm/ptrace.h rename arch/unicore32/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/unicore32/include/{ => uapi}/asm/unistd.h (100%) . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for score [ver #2]
Can you merge the following branch into the score tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-score-20121009 for you to fetch changes up to f2f8f65349ca712d47d50c58f37fb76bc56992e3: UAPI: (Scripted) Disintegrate arch/score/include/asm (2012-10-09 09:47:35 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/score/include/asm arch/score/include/asm/Kbuild | 1 - arch/score/include/asm/ptrace.h | 74 +--- arch/score/include/asm/setup.h | 7 +-- arch/score/include/uapi/asm/Kbuild | 31 ++ arch/score/include/{ => uapi}/asm/auxvec.h | 0 arch/score/include/{ => uapi}/asm/bitsperlong.h | 0 arch/score/include/{ => uapi}/asm/byteorder.h | 0 arch/score/include/{ => uapi}/asm/errno.h | 0 arch/score/include/{ => uapi}/asm/fcntl.h | 0 arch/score/include/{ => uapi}/asm/ioctl.h | 0 arch/score/include/{ => uapi}/asm/ioctls.h | 0 arch/score/include/{ => uapi}/asm/ipcbuf.h | 0 arch/score/include/{ => uapi}/asm/kvm_para.h| 0 arch/score/include/{ => uapi}/asm/mman.h| 0 arch/score/include/{ => uapi}/asm/msgbuf.h | 0 arch/score/include/{ => uapi}/asm/param.h | 0 arch/score/include/{ => uapi}/asm/poll.h| 0 arch/score/include/{ => uapi}/asm/posix_types.h | 0 arch/score/include/uapi/asm/ptrace.h| 76 + arch/score/include/{ => uapi}/asm/resource.h| 0 arch/score/include/{ => uapi}/asm/sembuf.h | 0 arch/score/include/uapi/asm/setup.h | 9 +++ arch/score/include/{ => uapi}/asm/shmbuf.h | 0 arch/score/include/{ => uapi}/asm/sigcontext.h | 0 arch/score/include/{ => uapi}/asm/siginfo.h | 0 arch/score/include/{ => uapi}/asm/signal.h | 0 arch/score/include/{ => uapi}/asm/socket.h | 0 arch/score/include/{ => uapi}/asm/sockios.h | 0 arch/score/include/{ => uapi}/asm/stat.h| 0 arch/score/include/{ => uapi}/asm/statfs.h | 0 arch/score/include/{ => uapi}/asm/swab.h| 0 arch/score/include/{ => uapi}/asm/termbits.h| 0 arch/score/include/{ => uapi}/asm/termios.h | 0 arch/score/include/{ => uapi}/asm/types.h | 0 arch/score/include/{ => uapi}/asm/unistd.h | 0 35 files changed, 118 insertions(+), 80 deletions(-) rename arch/score/include/{ => uapi}/asm/auxvec.h (100%) rename arch/score/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/score/include/{ => uapi}/asm/byteorder.h (100%) rename arch/score/include/{ => uapi}/asm/errno.h (100%) rename arch/score/include/{ => uapi}/asm/fcntl.h (100%) rename arch/score/include/{ => uapi}/asm/ioctl.h (100%) rename arch/score/include/{ => uapi}/asm/ioctls.h (100%) rename arch/score/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/score/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/score/include/{ => uapi}/asm/mman.h (100%) rename arch/score/include/{ => uapi}/asm/msgbuf.h (100%) rename arch/score/include/{ => uapi}/asm/param.h (100%) rename arch/score/include/{ => uapi}/asm/poll.h (100%) rename arch/score/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/score/include/uapi/asm/ptrace.h rename arch/score/include/{ => uapi}/asm/resource.h (100%) rename arch/score/include/{ => uapi}/asm/sembuf.h (100%) create mode 100644 arch/score/include/uapi/asm/setup.h rename arch/score/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/score/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/score/include/{ => uapi}/asm/siginfo.h (100%) rename arch/score/include/{ => uapi}/asm/signal.h (100%) rename arch/score/include/{ => uapi}/asm/socket.h (100%) rename arch/score/include/{ => uapi}/asm/sockios.h (100%) rename arch/score/include/{ => uapi}/asm/stat.h (100%) rename arch/score/include/{ => uapi}/asm/statfs.h (100%) rename arch/score/include/{ => uapi}/asm/swab.h (100%) rename arch/score/include/{ => uapi}/asm/term
[GIT PULL] Disintegrate UAPI for x86 [ver #2]
Can you merge the following branch into the x86 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-x86-20121009 for you to fetch changes up to 8d2c63c2b664bae1fb0f386661ea5f635330e570: UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-10-09 09:47:54 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/x86/include/asm arch/x86/include/asm/Kbuild | 23 --- arch/x86/include/asm/boot.h | 9 +- arch/x86/include/asm/debugreg.h | 79 +--- arch/x86/include/asm/e820.h | 74 +--- arch/x86/include/asm/hw_breakpoint.h | 5 +- arch/x86/include/asm/ist.h| 17 +- arch/x86/include/asm/kvm_para.h | 99 +- arch/x86/include/asm/mce.h| 119 +--- arch/x86/include/asm/msr.h| 11 +- arch/x86/include/asm/mtrr.h | 93 + arch/x86/include/asm/posix_types.h| 10 - arch/x86/include/asm/processor-flags.h| 97 +- arch/x86/include/asm/ptrace.h | 75 +--- arch/x86/include/asm/setup.h | 5 +- arch/x86/include/asm/sigcontext.h | 216 + arch/x86/include/asm/signal.h | 140 +- arch/x86/include/asm/unistd.h | 14 +- arch/x86/include/asm/vm86.h | 128 + arch/x86/include/asm/vsyscall.h | 16 +- arch/x86/include/uapi/asm/Kbuild | 55 ++ arch/x86/include/{ => uapi}/asm/a.out.h | 0 arch/x86/include/{ => uapi}/asm/auxvec.h | 0 arch/x86/include/{ => uapi}/asm/bitsperlong.h | 0 arch/x86/include/uapi/asm/boot.h | 10 + arch/x86/include/{ => uapi}/asm/bootparam.h | 0 arch/x86/include/{ => uapi}/asm/byteorder.h | 0 arch/x86/include/uapi/asm/debugreg.h | 80 arch/x86/include/uapi/asm/e820.h | 75 arch/x86/include/{ => uapi}/asm/errno.h | 0 arch/x86/include/{ => uapi}/asm/fcntl.h | 0 arch/x86/include/{ => uapi}/asm/hyperv.h | 0 arch/x86/include/{ => uapi}/asm/ioctl.h | 0 arch/x86/include/{ => uapi}/asm/ioctls.h | 0 arch/x86/include/{ => uapi}/asm/ipcbuf.h | 0 arch/x86/include/uapi/asm/ist.h | 29 +++ arch/x86/include/{ => uapi}/asm/kvm.h | 0 arch/x86/include/uapi/asm/kvm_para.h | 100 ++ arch/x86/include/{ => uapi}/asm/ldt.h | 0 arch/x86/include/uapi/asm/mce.h | 121 arch/x86/include/{ => uapi}/asm/mman.h| 0 arch/x86/include/{ => uapi}/asm/msgbuf.h | 0 arch/x86/include/{ => uapi}/asm/msr-index.h | 0 arch/x86/include/uapi/asm/msr.h | 15 ++ arch/x86/include/uapi/asm/mtrr.h | 117 arch/x86/include/{ => uapi}/asm/param.h | 0 arch/x86/include/{ => uapi}/asm/poll.h| 0 arch/x86/include/uapi/asm/posix_types.h | 9 + arch/x86/include/{ => uapi}/asm/posix_types_32.h | 0 arch/x86/include/{ => uapi}/asm/posix_types_64.h | 0 arch/x86/include/{ => uapi}/asm/posix_types_x32.h | 0 arch/x86/include/{ => uapi}/asm/prctl.h | 0 arch/x86/include/uapi/asm/processor-flags.h | 99 ++ arch/x86/include/{ => uapi}/asm/ptrace-abi.h | 0 arch/x86/include/uapi/asm/ptrace.h| 78 arch/x86/include/{ => uapi}/asm/resource.h| 0 arch/x86/include/{ => uapi}/asm/sembuf.h | 0 arch/x86/include/{ => uapi}/asm/shmbuf.h | 0 arch/x86/include/uapi/asm/sigcontext.h| 221 ++ arch/x86/include/{ => uapi}/asm/sigcontext32.h| 0 arch/x86/include/{ => uapi}/asm/siginfo.h | 0 arch/x86/include/uapi/asm/signal.h
[GIT PULL] Disintegrate UAPI for h8300 [ver #2]
Can you merge the following branch into the h8300 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-h8300-20121009 for you to fetch changes up to c0c32782cbbd986aa2b309bca1dc6eb418ef1014: UAPI: (Scripted) Disintegrate arch/h8300/include/asm (2012-10-09 09:46:54 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/h8300/include/asm arch/h8300/include/asm/Kbuild | 1 - arch/h8300/include/asm/param.h | 15 +- arch/h8300/include/asm/ptrace.h | 40 +-- arch/h8300/include/asm/signal.h | 121 + arch/h8300/include/asm/termios.h| 44 +--- arch/h8300/include/asm/types.h | 5 +- arch/h8300/include/asm/unistd.h | 328 +-- arch/h8300/include/uapi/asm/Kbuild | 31 +++ arch/h8300/include/{ => uapi}/asm/auxvec.h | 0 arch/h8300/include/{ => uapi}/asm/bitsperlong.h | 0 arch/h8300/include/{ => uapi}/asm/byteorder.h | 0 arch/h8300/include/{ => uapi}/asm/errno.h | 0 arch/h8300/include/{ => uapi}/asm/fcntl.h | 0 arch/h8300/include/{ => uapi}/asm/ioctl.h | 0 arch/h8300/include/{ => uapi}/asm/ioctls.h | 0 arch/h8300/include/{ => uapi}/asm/ipcbuf.h | 0 arch/h8300/include/{ => uapi}/asm/kvm_para.h| 0 arch/h8300/include/{ => uapi}/asm/mman.h| 0 arch/h8300/include/{ => uapi}/asm/msgbuf.h | 0 arch/h8300/include/uapi/asm/param.h | 16 ++ arch/h8300/include/{ => uapi}/asm/poll.h| 0 arch/h8300/include/{ => uapi}/asm/posix_types.h | 0 arch/h8300/include/uapi/asm/ptrace.h| 44 arch/h8300/include/{ => uapi}/asm/resource.h| 0 arch/h8300/include/{ => uapi}/asm/sembuf.h | 0 arch/h8300/include/{ => uapi}/asm/setup.h | 0 arch/h8300/include/{ => uapi}/asm/shmbuf.h | 0 arch/h8300/include/{ => uapi}/asm/sigcontext.h | 0 arch/h8300/include/{ => uapi}/asm/siginfo.h | 0 arch/h8300/include/uapi/asm/signal.h| 121 + arch/h8300/include/{ => uapi}/asm/socket.h | 0 arch/h8300/include/{ => uapi}/asm/sockios.h | 0 arch/h8300/include/{ => uapi}/asm/stat.h| 0 arch/h8300/include/{ => uapi}/asm/statfs.h | 0 arch/h8300/include/{ => uapi}/asm/swab.h| 0 arch/h8300/include/{ => uapi}/asm/termbits.h| 0 arch/h8300/include/uapi/asm/termios.h | 44 arch/h8300/include/uapi/asm/types.h | 1 + arch/h8300/include/uapi/asm/unistd.h| 330 39 files changed, 595 insertions(+), 546 deletions(-) rename arch/h8300/include/{ => uapi}/asm/auxvec.h (100%) rename arch/h8300/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/h8300/include/{ => uapi}/asm/byteorder.h (100%) rename arch/h8300/include/{ => uapi}/asm/errno.h (100%) rename arch/h8300/include/{ => uapi}/asm/fcntl.h (100%) rename arch/h8300/include/{ => uapi}/asm/ioctl.h (100%) rename arch/h8300/include/{ => uapi}/asm/ioctls.h (100%) rename arch/h8300/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/h8300/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/h8300/include/{ => uapi}/asm/mman.h (100%) rename arch/h8300/include/{ => uapi}/asm/msgbuf.h (100%) create mode 100644 arch/h8300/include/uapi/asm/param.h rename arch/h8300/include/{ => uapi}/asm/poll.h (100%) rename arch/h8300/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/h8300/include/uapi/asm/ptrace.h rename arch/h8300/include/{ => uapi}/asm/resource.h (100%) rename arch/h8300/include/{ => uapi}/asm/sembuf.h (100%) rename arch/h8300/include/{ => uapi}/asm/setup.h (100%) rename arch/h8300/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/h8300/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/h8300/include/{ => uapi}/asm/siginfo.h (100%) create mode 100644 arch/h8300/include/uapi/asm/signal.h rename arch/h8300/include/{ => uapi}/asm/socket.h (100%) rename arch/h8
[GIT PULL] Disintegrate UAPI for m32r [ver #2]
Can you merge the following branch into the m32r tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-m32r-20121009 for you to fetch changes up to 90fc366ea41f3595286f18e15b49d3cef8b85ceb: UAPI: (Scripted) Disintegrate arch/m32r/include/asm (2012-10-09 09:47:03 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/m32r/include/asm arch/m32r/include/asm/Kbuild | 1 - arch/m32r/include/asm/ptrace.h | 110 +--- arch/m32r/include/asm/setup.h | 9 +- arch/m32r/include/asm/signal.h | 123 + arch/m32r/include/asm/termios.h| 42 +--- arch/m32r/include/asm/types.h | 5 +- arch/m32r/include/asm/unistd.h | 333 +--- arch/m32r/include/uapi/asm/Kbuild | 30 +++ arch/m32r/include/{ => uapi}/asm/auxvec.h | 0 arch/m32r/include/{ => uapi}/asm/bitsperlong.h | 0 arch/m32r/include/{ => uapi}/asm/byteorder.h | 0 arch/m32r/include/{ => uapi}/asm/errno.h | 0 arch/m32r/include/{ => uapi}/asm/fcntl.h | 0 arch/m32r/include/{ => uapi}/asm/ioctl.h | 0 arch/m32r/include/{ => uapi}/asm/ioctls.h | 0 arch/m32r/include/{ => uapi}/asm/ipcbuf.h | 0 arch/m32r/include/{ => uapi}/asm/mman.h| 0 arch/m32r/include/{ => uapi}/asm/msgbuf.h | 0 arch/m32r/include/{ => uapi}/asm/param.h | 0 arch/m32r/include/{ => uapi}/asm/poll.h| 0 arch/m32r/include/{ => uapi}/asm/posix_types.h | 0 arch/m32r/include/uapi/asm/ptrace.h| 117 + arch/m32r/include/{ => uapi}/asm/resource.h| 0 arch/m32r/include/{ => uapi}/asm/sembuf.h | 0 arch/m32r/include/uapi/asm/setup.h | 11 + arch/m32r/include/{ => uapi}/asm/shmbuf.h | 0 arch/m32r/include/{ => uapi}/asm/sigcontext.h | 0 arch/m32r/include/{ => uapi}/asm/siginfo.h | 0 arch/m32r/include/uapi/asm/signal.h| 123 + arch/m32r/include/{ => uapi}/asm/socket.h | 0 arch/m32r/include/{ => uapi}/asm/sockios.h | 0 arch/m32r/include/{ => uapi}/asm/stat.h| 0 arch/m32r/include/{ => uapi}/asm/statfs.h | 0 arch/m32r/include/{ => uapi}/asm/swab.h| 0 arch/m32r/include/{ => uapi}/asm/termbits.h| 0 arch/m32r/include/uapi/asm/termios.h | 43 arch/m32r/include/uapi/asm/types.h | 1 + arch/m32r/include/uapi/asm/unistd.h| 335 + 38 files changed, 668 insertions(+), 615 deletions(-) rename arch/m32r/include/{ => uapi}/asm/auxvec.h (100%) rename arch/m32r/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/m32r/include/{ => uapi}/asm/byteorder.h (100%) rename arch/m32r/include/{ => uapi}/asm/errno.h (100%) rename arch/m32r/include/{ => uapi}/asm/fcntl.h (100%) rename arch/m32r/include/{ => uapi}/asm/ioctl.h (100%) rename arch/m32r/include/{ => uapi}/asm/ioctls.h (100%) rename arch/m32r/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/m32r/include/{ => uapi}/asm/mman.h (100%) rename arch/m32r/include/{ => uapi}/asm/msgbuf.h (100%) rename arch/m32r/include/{ => uapi}/asm/param.h (100%) rename arch/m32r/include/{ => uapi}/asm/poll.h (100%) rename arch/m32r/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/m32r/include/uapi/asm/ptrace.h rename arch/m32r/include/{ => uapi}/asm/resource.h (100%) rename arch/m32r/include/{ => uapi}/asm/sembuf.h (100%) create mode 100644 arch/m32r/include/uapi/asm/setup.h rename arch/m32r/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/m32r/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/m32r/include/{ => uapi}/asm/siginfo.h (100%) create mode 100644 arch/m32r/include/uapi/asm/signal.h rename arch/m32r/include/{ => uapi}/asm/socket.h (100%) rename arch/m32r/include/{ => uapi}/asm/sockios.h (100%) rename arch/m32r/include/{ => uapi}/asm/stat.h (100%) rename arch/m32r/include/{ => uapi}/asm/statfs.h (100%) rename arch
[GIT PULL] Disintegrate UAPI for openrisc [ver #2]
Can you merge the following branch into the openrisc tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-openrisc-20121009 for you to fetch changes up to 913c230200ceea66dda3fda325af8365b3fdc670: UAPI: (Scripted) Disintegrate arch/openrisc/include/asm (2012-10-09 09:47:18 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/openrisc/include/asm arch/openrisc/include/asm/Kbuild | 2 - arch/openrisc/include/asm/elf.h | 51 + arch/openrisc/include/asm/ptrace.h| 17 +- arch/openrisc/include/uapi/asm/Kbuild | 7 +++ arch/openrisc/include/{ => uapi}/asm/byteorder.h | 0 arch/openrisc/include/uapi/asm/elf.h | 69 +++ arch/openrisc/include/{ => uapi}/asm/kvm_para.h | 0 arch/openrisc/include/{ => uapi}/asm/param.h | 0 arch/openrisc/include/uapi/asm/ptrace.h | 35 arch/openrisc/include/{ => uapi}/asm/sigcontext.h | 0 arch/openrisc/include/{ => uapi}/asm/unistd.h | 0 11 files changed, 113 insertions(+), 68 deletions(-) rename arch/openrisc/include/{ => uapi}/asm/byteorder.h (100%) create mode 100644 arch/openrisc/include/uapi/asm/elf.h rename arch/openrisc/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/openrisc/include/{ => uapi}/asm/param.h (100%) create mode 100644 arch/openrisc/include/uapi/asm/ptrace.h rename arch/openrisc/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/openrisc/include/{ => uapi}/asm/unistd.h (100%) . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for powerpc [ver #2]
Can you merge the following branch into the powerpc tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-powerpc-20121009 for you to fetch changes up to c3617f72036c909e1f6086b5b9e364e0ef90a6da: UAPI: (Scripted) Disintegrate arch/powerpc/include/asm (2012-10-09 09:47:26 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/powerpc/include/asm arch/powerpc/include/asm/Kbuild | 35 -- arch/powerpc/include/asm/bootx.h | 123 +-- arch/powerpc/include/asm/cputable.h | 35 +- arch/powerpc/include/asm/elf.h| 311 +- arch/powerpc/include/asm/kvm_para.h | 70 +--- arch/powerpc/include/asm/mman.h | 27 +- arch/powerpc/include/asm/nvram.h | 55 +--- arch/powerpc/include/asm/ptrace.h | 242 +- arch/powerpc/include/asm/signal.h | 143 +--- arch/powerpc/include/asm/spu_info.h | 29 +- arch/powerpc/include/asm/swab.h | 15 +- arch/powerpc/include/asm/termios.h| 69 +--- arch/powerpc/include/asm/types.h | 30 +- arch/powerpc/include/asm/unistd.h | 374 + arch/powerpc/include/uapi/asm/Kbuild | 41 +++ arch/powerpc/include/{ => uapi}/asm/auxvec.h | 0 arch/powerpc/include/{ => uapi}/asm/bitsperlong.h | 0 arch/powerpc/include/uapi/asm/bootx.h | 132 arch/powerpc/include/{ => uapi}/asm/byteorder.h | 0 arch/powerpc/include/uapi/asm/cputable.h | 36 ++ arch/powerpc/include/uapi/asm/elf.h | 307 + arch/powerpc/include/{ => uapi}/asm/errno.h | 0 arch/powerpc/include/{ => uapi}/asm/fcntl.h | 0 arch/powerpc/include/{ => uapi}/asm/ioctl.h | 0 arch/powerpc/include/{ => uapi}/asm/ioctls.h | 0 arch/powerpc/include/{ => uapi}/asm/ipcbuf.h | 0 arch/powerpc/include/{ => uapi}/asm/kvm.h | 0 arch/powerpc/include/uapi/asm/kvm_para.h | 90 + arch/powerpc/include/{ => uapi}/asm/linkage.h | 0 arch/powerpc/include/uapi/asm/mman.h | 31 ++ arch/powerpc/include/{ => uapi}/asm/msgbuf.h | 0 arch/powerpc/include/uapi/asm/nvram.h | 62 arch/powerpc/include/{ => uapi}/asm/param.h | 0 arch/powerpc/include/{ => uapi}/asm/poll.h| 0 arch/powerpc/include/{ => uapi}/asm/posix_types.h | 0 arch/powerpc/include/{ => uapi}/asm/ps3fb.h | 0 arch/powerpc/include/uapi/asm/ptrace.h| 259 +++ arch/powerpc/include/{ => uapi}/asm/resource.h| 0 arch/powerpc/include/{ => uapi}/asm/seccomp.h | 0 arch/powerpc/include/{ => uapi}/asm/sembuf.h | 0 arch/powerpc/include/{ => uapi}/asm/setup.h | 0 arch/powerpc/include/{ => uapi}/asm/shmbuf.h | 0 arch/powerpc/include/{ => uapi}/asm/sigcontext.h | 0 arch/powerpc/include/{ => uapi}/asm/siginfo.h | 0 arch/powerpc/include/uapi/asm/signal.h| 145 + arch/powerpc/include/{ => uapi}/asm/socket.h | 0 arch/powerpc/include/{ => uapi}/asm/sockios.h | 0 arch/powerpc/include/uapi/asm/spu_info.h | 53 +++ arch/powerpc/include/{ => uapi}/asm/stat.h| 0 arch/powerpc/include/{ => uapi}/asm/statfs.h | 0 arch/powerpc/include/uapi/asm/swab.h | 23 ++ arch/powerpc/include/{ => uapi}/asm/termbits.h| 0 arch/powerpc/include/uapi/asm/termios.h | 76 + arch/powerpc/include/uapi/asm/types.h | 40 +++ arch/powerpc/include/{ => uapi}/asm/ucontext.h| 0 arch/powerpc/include/uapi/asm/unistd.h| 380 ++ 56 files changed, 1705 insertions(+), 1528 deletions(-) rename arch/powerpc/include/{ => uapi}/asm/auxvec.h (100%) rename arch/powerpc/include/{ => uapi}/asm/bitsperlong.h (100%) create mode 100644 arch/powerpc/include/uapi/asm/bootx.h rename arch/powerpc/include/{ => uapi}/asm
[GIT PULL] Disintegrate UAPI for tile [ver #2]
Can you merge the following branch into the tile tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-tile-20121009 for you to fetch changes up to df842f79f0e2aed9092a73f611f41f03630a3823: UAPI: (Scripted) Disintegrate arch/tile/include/asm (2012-10-09 09:47:47 +0100) UAPI Disintegration 2012-10-09 David Howells (2): UAPI: (Scripted) Disintegrate arch/tile/include/arch UAPI: (Scripted) Disintegrate arch/tile/include/asm arch/tile/include/arch/Kbuild | 17 - arch/tile/include/arch/spr_def.h | 12 +-- arch/tile/include/asm/Kbuild | 3 - arch/tile/include/asm/hardwall.h | 33 +--- arch/tile/include/asm/ptrace.h | 72 +- arch/tile/include/asm/setup.h | 7 +- arch/tile/include/asm/signal.h | 12 +-- arch/tile/include/asm/unistd.h | 25 +- arch/tile/include/uapi/arch/Kbuild | 17 + arch/tile/include/{ => uapi}/arch/abi.h| 0 arch/tile/include/{ => uapi}/arch/chip.h | 0 arch/tile/include/{ => uapi}/arch/chip_tile64.h| 0 arch/tile/include/{ => uapi}/arch/chip_tilegx.h| 0 arch/tile/include/{ => uapi}/arch/chip_tilepro.h | 0 arch/tile/include/{ => uapi}/arch/icache.h | 0 arch/tile/include/{ => uapi}/arch/interrupts.h | 0 arch/tile/include/{ => uapi}/arch/interrupts_32.h | 0 arch/tile/include/{ => uapi}/arch/interrupts_64.h | 0 arch/tile/include/{ => uapi}/arch/opcode.h | 0 arch/tile/include/{ => uapi}/arch/opcode_tilegx.h | 0 arch/tile/include/{ => uapi}/arch/opcode_tilepro.h | 0 arch/tile/include/{ => uapi}/arch/sim.h| 0 arch/tile/include/{ => uapi}/arch/sim_def.h| 0 arch/tile/include/uapi/arch/spr_def.h | 26 +++ arch/tile/include/{ => uapi}/arch/spr_def_32.h | 6 +- arch/tile/include/{ => uapi}/arch/spr_def_64.h | 6 +- arch/tile/include/uapi/asm/Kbuild | 15 arch/tile/include/{ => uapi}/asm/auxvec.h | 0 arch/tile/include/{ => uapi}/asm/bitsperlong.h | 0 arch/tile/include/{ => uapi}/asm/byteorder.h | 0 arch/tile/include/{ => uapi}/asm/cachectl.h| 0 arch/tile/include/uapi/asm/hardwall.h | 51 + arch/tile/include/{ => uapi}/asm/kvm_para.h| 0 arch/tile/include/{ => uapi}/asm/mman.h| 0 arch/tile/include/uapi/asm/ptrace.h| 88 ++ arch/tile/include/uapi/asm/setup.h | 21 ++ arch/tile/include/{ => uapi}/asm/sigcontext.h | 0 arch/tile/include/{ => uapi}/asm/siginfo.h | 0 arch/tile/include/uapi/asm/signal.h| 27 +++ arch/tile/include/{ => uapi}/asm/stat.h| 0 arch/tile/include/{ => uapi}/asm/swab.h| 0 arch/tile/include/uapi/asm/unistd.h| 34 + 42 files changed, 295 insertions(+), 177 deletions(-) rename arch/tile/include/{ => uapi}/arch/abi.h (100%) rename arch/tile/include/{ => uapi}/arch/chip.h (100%) rename arch/tile/include/{ => uapi}/arch/chip_tile64.h (100%) rename arch/tile/include/{ => uapi}/arch/chip_tilegx.h (100%) rename arch/tile/include/{ => uapi}/arch/chip_tilepro.h (100%) rename arch/tile/include/{ => uapi}/arch/icache.h (100%) rename arch/tile/include/{ => uapi}/arch/interrupts.h (100%) rename arch/tile/include/{ => uapi}/arch/interrupts_32.h (100%) rename arch/tile/include/{ => uapi}/arch/interrupts_64.h (100%) rename arch/tile/include/{ => uapi}/arch/opcode.h (100%) rename arch/tile/include/{ => uapi}/arch/opcode_tilegx.h (100%) rename arch/tile/include/{ => uapi}/arch/opcode_tilepro.h (100%) rename arch/tile/include/{ => uapi}/arch/sim.h (100%) rename arch/tile/include/{ => uapi}/arch/sim_def.h (100%) create mode 100644 arch/tile/include/uapi/arch/spr_def.h rename arch/tile/include/{ => uapi}/arch/spr_def_32.h (98%) rename arch/tile/include/{ => uapi}/arch/spr_def_64.h (98%
2nd CfP World Congress The Frontiers in Intelligent Data and Signal Analysis DSA 2013
* World Congress 2nd Call for Papers The Frontiers in Intelligent Data and Signal Analysis DSA 2013 New York, USA July, 13th - July, 25th 2013 www.worldcongressdsa.com ** Dear Colleagues, Ladies and Gentlemens, We like to invite you to contribute to the World Congress "The Frontiers in Intelligent Data and Signal Analysis DSA 2013" in New York, USA on July, 13th - July 25th, 2013. We are looking forward to your contributions. Sincerely yours, Prof. Dr. Petra Perner Congress Chair *** The Congress will feature three International Conferences: * International Conference on Machine Learning and Data Mining, MLDM 2013 July 19th - July 25th, 2013 http://www.mldm.de * Industrial Conference on Data Mining, ICDM 2013 July 16th - July 21st, 2013 http://www.data-mining-forum.de * International Conference on Mass Data Analysis of Images and Signals in Medicine, Biotechnology, Chemistry, and Food Industry, MDA 2013 July 13th - July 16th, 2013 http://www.mda-signals.de. *** Paper submission deadline will be Dezember, 18th 2012. *** *** Besides that five workshops will be held: * Intern. Workshop Case-Based Reasoning, CBR-MD 2013 http://www.data-mining-forum.de/w_casebased.php * Intern. Workshop Data Mining in Agriculture, DMA 2013 http://www.data-mining-forum.de/w_agriculture.php * Intern. Workshop on Data Mining in the Life Sciences, DMLS 2013 http://www.data-mining-forum.de/w_life_sciences.php * Intern. Workshop on Data Mining in Marketing, DMM 2013 http://www.data-mining-forum.de/w_marketing.php * Intern. Workshop on Intelligent Pattern Recognition and Applications, WIPRA2013 http://www.mldm.de/w_pattern_recognition.php *** Five Tutorials will be given: * Data Mining http://www.data-mining-tutorial.de/ * Case-Based Reasoning http://www.data-mining-forum.de/t_cbr.php * Intelligent Signal and Image Analysis http://www.mda-signals.de * Standardization in Immunofluorescence http://www.imageinterpret.de/ * Big Data & Text Analytics http://www.data-mining-forum.de/t_bdta.php *** Special Sessions * Industry Session http://www.data-mining-forum.de/industry_session.php * Special Session on Discrete Event Formalisms Applied on Medical Data Analysis http://www.mda-signals.de/specialsession.php *** Publications Papers are published by Springer Verlag http://www.springer.de and by ibai-publishing house http://www.ibai-publishing.org. *** Industrial Exhibition, Book and Job Fair We like to invite you to present your company or publishing house at the Industrial Exhibition ieda 2013. http://www.iedaexhibition.de *** Social Events Party in New York *** Sponsors ibai solutions http://www.ibai-solutions.de ImageInterpret GmbH http://www.imageinterpret.de *** New York Di, 9.Okt.2012 If you do not wish to receive this newsletter please press unsubscribe here http://ibai-institut-newsletter.de/cgi-bin/mail/manager.cgi?action=delete&email=linux-kernel%40vger.kernel.org&group1=mldm2. You will be automatically deleted from the data base. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for sh [ver #2]
Can you merge the following branch into the sh tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-sh-20121009 for you to fetch changes up to 0a9426df1858f71ac84eb7eef500b4247de5e3bb: UAPI: (Scripted) Disintegrate arch/sh/include/asm (2012-10-09 09:47:37 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/sh/include/asm arch/sh/include/asm/Kbuild | 11 arch/sh/include/asm/hw_breakpoint.h | 4 +- arch/sh/include/asm/posix_types.h | 8 --- arch/sh/include/asm/ptrace.h| 34 +-- arch/sh/include/asm/ptrace_32.h | 75 +--- arch/sh/include/asm/ptrace_64.h | 12 +--- arch/sh/include/asm/setup.h | 5 +- arch/sh/include/asm/types.h | 5 +- arch/sh/include/asm/unistd.h| 9 +-- arch/sh/include/uapi/asm/Kbuild | 22 +++ arch/sh/include/{ => uapi}/asm/auxvec.h | 0 arch/sh/include/{ => uapi}/asm/byteorder.h | 0 arch/sh/include/{ => uapi}/asm/cachectl.h | 0 arch/sh/include/{ => uapi}/asm/cpu-features.h | 0 arch/sh/include/{ => uapi}/asm/ioctls.h | 0 arch/sh/include/uapi/asm/posix_types.h | 7 +++ arch/sh/include/{ => uapi}/asm/posix_types_32.h | 0 arch/sh/include/{ => uapi}/asm/posix_types_64.h | 0 arch/sh/include/uapi/asm/ptrace.h | 34 +++ arch/sh/include/uapi/asm/ptrace_32.h| 77 + arch/sh/include/uapi/asm/ptrace_64.h| 14 + arch/sh/include/uapi/asm/setup.h| 1 + arch/sh/include/{ => uapi}/asm/sigcontext.h | 0 arch/sh/include/{ => uapi}/asm/signal.h | 0 arch/sh/include/{ => uapi}/asm/sockios.h| 0 arch/sh/include/{ => uapi}/asm/stat.h | 0 arch/sh/include/{ => uapi}/asm/swab.h | 0 arch/sh/include/uapi/asm/types.h| 1 + arch/sh/include/uapi/asm/unistd.h | 7 +++ arch/sh/include/{ => uapi}/asm/unistd_32.h | 0 arch/sh/include/{ => uapi}/asm/unistd_64.h | 0 31 files changed, 173 insertions(+), 153 deletions(-) rename arch/sh/include/{ => uapi}/asm/auxvec.h (100%) rename arch/sh/include/{ => uapi}/asm/byteorder.h (100%) rename arch/sh/include/{ => uapi}/asm/cachectl.h (100%) rename arch/sh/include/{ => uapi}/asm/cpu-features.h (100%) create mode 100644 arch/sh/include/uapi/asm/hw_breakpoint.h rename arch/sh/include/{ => uapi}/asm/ioctls.h (100%) create mode 100644 arch/sh/include/uapi/asm/posix_types.h rename arch/sh/include/{ => uapi}/asm/posix_types_32.h (100%) rename arch/sh/include/{ => uapi}/asm/posix_types_64.h (100%) create mode 100644 arch/sh/include/uapi/asm/ptrace.h create mode 100644 arch/sh/include/uapi/asm/ptrace_32.h create mode 100644 arch/sh/include/uapi/asm/ptrace_64.h create mode 100644 arch/sh/include/uapi/asm/setup.h rename arch/sh/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/sh/include/{ => uapi}/asm/signal.h (100%) rename arch/sh/include/{ => uapi}/asm/sockios.h (100%) rename arch/sh/include/{ => uapi}/asm/stat.h (100%) rename arch/sh/include/{ => uapi}/asm/swab.h (100%) create mode 100644 arch/sh/include/uapi/asm/types.h create mode 100644 arch/sh/include/uapi/asm/unistd.h rename arch/sh/include/{ => uapi}/asm/unistd_32.h (100%) rename arch/sh/include/{ => uapi}/asm/unistd_64.h (100%) . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
[CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Best regards Philippe On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: > Hi Philippe, > > On 05/10/12 01:03, Philippe De Muyter wrote: >> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: >>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: My biggest concern is the amount of MCD/DMA support code. And it is all done quite differently to everything else in the kernel. We may get a bit of push back from kernel folk who look after DMA. >>> >>> Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm >>> (also from freescale, maybe an identical part, but I did not find any >>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc >>> tree, instead of installing it in drivers/dma. >> >> The MCD DMA or DMA FEC code from freescale has a comment implying that >> this >> was first used in the MPC8220 part. And Montavista has a MPC8220 port, >> but >> I did not find it, so I do not know where they installed the MCD DMA >> driver. > > Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIFO_STATUSFECRFSR 18C RFIFO_CONTROL FECRFCR 190 RFIFO_LRF_PTR FECRLRFP 194 RFIFO_LWF_PTR FECRLWFP 198 RFIFO_ALARM FECRFAR 19C RFIFO_RDPTR FECRFRP 1A0 RFIFO_WRPTR FECRFWP 1A4 TFIFO_DATA FECTFDR 1A8 TFIFO_STATUSFECTFSR 1AC TFIFO_CONTROL FECTFCR 1B0 TFIFO_LRF_PTR FECTLRFP 1B4 TFIFO_LWF_PTR FECTLWFP 1B8 TFIFO_ALARM FECTFAR 1BC TFIFO_RDPTR FECTFRP 1C0 TFIFO_WRPTR FECTFWP 1C4 RESET_CNTRL FECFRST 1C8 XMIT_FSMFECCTCWR > Probably the best thing to do is post the patches on the linux kernel > mailing list then, asking for direction on a dma driver. > > I have no problem with it going into the arch/m68k area. So that is > always an option. For the dma engines, the similarity is also obvious. For example, find below side by side mpc52xx and m54xx definitions for the main DMA registers : from mpc52x
[GIT PULL] Disintegrate UAPI for sparc [ver #2]
Can you merge the following branch into the sparc tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-sparc-20121009 for you to fetch changes up to 5457982641fb3f5fb08ce22a853dd5474645c66d: UAPI: (Scripted) Disintegrate arch/sparc/include/asm (2012-10-09 09:47:43 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/sparc/include/asm arch/sparc/include/asm/Kbuild | 16 - arch/sparc/include/asm/fbio.h | 260 +-- arch/sparc/include/asm/ioctls.h | 129 +--- arch/sparc/include/asm/mman.h | 25 +- arch/sparc/include/asm/psr.h| 36 +- arch/sparc/include/asm/ptrace.h | 347 +-- arch/sparc/include/asm/setup.h | 10 +- arch/sparc/include/asm/sigcontext.h | 4 +- arch/sparc/include/asm/siginfo.h| 23 +- arch/sparc/include/asm/signal.h | 185 +-- arch/sparc/include/asm/termbits.h | 260 +-- arch/sparc/include/asm/termios.h| 41 +-- arch/sparc/include/asm/traps.h | 111 +-- arch/sparc/include/asm/unistd.h | 412 +-- arch/sparc/include/uapi/asm/Kbuild | 46 +++ arch/sparc/include/{ => uapi}/asm/apc.h | 0 arch/sparc/include/{ => uapi}/asm/asi.h | 0 arch/sparc/include/{ => uapi}/asm/auxvec.h | 0 arch/sparc/include/{ => uapi}/asm/bitsperlong.h | 0 arch/sparc/include/{ => uapi}/asm/byteorder.h | 0 arch/sparc/include/{ => uapi}/asm/display7seg.h | 0 arch/sparc/include/{ => uapi}/asm/envctrl.h | 0 arch/sparc/include/{ => uapi}/asm/errno.h | 0 arch/sparc/include/uapi/asm/fbio.h | 259 +++ arch/sparc/include/{ => uapi}/asm/fcntl.h | 0 arch/sparc/include/{ => uapi}/asm/ioctl.h | 0 arch/sparc/include/uapi/asm/ioctls.h| 131 arch/sparc/include/{ => uapi}/asm/ipcbuf.h | 0 arch/sparc/include/{ => uapi}/asm/jsflash.h | 0 arch/sparc/include/{ => uapi}/asm/kvm_para.h| 0 arch/sparc/include/uapi/asm/mman.h | 27 ++ arch/sparc/include/{ => uapi}/asm/msgbuf.h | 0 arch/sparc/include/{ => uapi}/asm/openpromio.h | 0 arch/sparc/include/{ => uapi}/asm/param.h | 0 arch/sparc/include/{ => uapi}/asm/perfctr.h | 0 arch/sparc/include/{ => uapi}/asm/poll.h| 0 arch/sparc/include/{ => uapi}/asm/posix_types.h | 0 arch/sparc/include/uapi/asm/psr.h | 47 +++ arch/sparc/include/{ => uapi}/asm/psrcompat.h | 0 arch/sparc/include/{ => uapi}/asm/pstate.h | 0 arch/sparc/include/uapi/asm/ptrace.h| 352 arch/sparc/include/{ => uapi}/asm/resource.h| 0 arch/sparc/include/{ => uapi}/asm/sembuf.h | 0 arch/sparc/include/uapi/asm/setup.h | 15 + arch/sparc/include/{ => uapi}/asm/shmbuf.h | 0 arch/sparc/include/uapi/asm/siginfo.h | 25 ++ arch/sparc/include/uapi/asm/signal.h| 185 +++ arch/sparc/include/{ => uapi}/asm/socket.h | 0 arch/sparc/include/{ => uapi}/asm/sockios.h | 0 arch/sparc/include/{ => uapi}/asm/stat.h| 0 arch/sparc/include/{ => uapi}/asm/statfs.h | 0 arch/sparc/include/{ => uapi}/asm/swab.h| 0 arch/sparc/include/uapi/asm/termbits.h | 263 +++ arch/sparc/include/uapi/asm/termios.h | 43 +++ arch/sparc/include/uapi/asm/traps.h | 120 +++ arch/sparc/include/{ => uapi}/asm/types.h | 0 arch/sparc/include/{ => uapi}/asm/uctx.h| 0 arch/sparc/include/uapi/asm/unistd.h| 422 arch/sparc/include/{ => uapi}/asm/utrap.h | 0 arch/sparc/include/{ => uapi}/asm/watchdog.h| 0 60 files changed, 1951 insertions(+), 1843 deletions(-) rename arch/sparc/include/{ => uapi}/asm/apc.h (100%) rename arch/sparc/include/{ =&g
[GIT PULL] Disintegrate UAPI for mips [ver #2]
Can you merge the following branch into the mips tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-mips-20121009 for you to fetch changes up to 61730c538f8281efa7ac12596da9f3f9a31b9272: UAPI: (Scripted) Disintegrate arch/mips/include/asm (2012-10-09 09:47:14 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/mips/include/asm arch/mips/include/asm/Kbuild |5 - arch/mips/include/asm/errno.h | 120 +-- arch/mips/include/asm/ptrace.h | 107 +-- arch/mips/include/asm/setup.h |5 +- arch/mips/include/asm/sigcontext.h | 66 +- arch/mips/include/asm/siginfo.h| 104 +-- arch/mips/include/asm/signal.h | 115 +-- arch/mips/include/asm/socket.h | 83 +- arch/mips/include/asm/termios.h| 73 +- arch/mips/include/asm/types.h | 16 +- arch/mips/include/asm/unistd.h | 1022 +-- arch/mips/include/uapi/asm/Kbuild | 34 + arch/mips/include/{ => uapi}/asm/auxvec.h |0 arch/mips/include/{ => uapi}/asm/bitsperlong.h |0 arch/mips/include/{ => uapi}/asm/byteorder.h |0 arch/mips/include/{ => uapi}/asm/cachectl.h|0 arch/mips/include/uapi/asm/errno.h | 129 +++ arch/mips/include/{ => uapi}/asm/fcntl.h |0 arch/mips/include/{ => uapi}/asm/ioctl.h |0 arch/mips/include/{ => uapi}/asm/ioctls.h |0 arch/mips/include/{ => uapi}/asm/ipcbuf.h |0 arch/mips/include/{ => uapi}/asm/kvm_para.h|0 arch/mips/include/{ => uapi}/asm/mman.h|0 arch/mips/include/{ => uapi}/asm/msgbuf.h |0 arch/mips/include/{ => uapi}/asm/param.h |0 arch/mips/include/{ => uapi}/asm/poll.h|0 arch/mips/include/{ => uapi}/asm/posix_types.h |0 arch/mips/include/uapi/asm/ptrace.h| 116 +++ arch/mips/include/{ => uapi}/asm/resource.h|0 arch/mips/include/{ => uapi}/asm/sembuf.h |0 arch/mips/include/uapi/asm/setup.h |7 + arch/mips/include/{ => uapi}/asm/sgidefs.h |0 arch/mips/include/{ => uapi}/asm/shmbuf.h |0 arch/mips/include/uapi/asm/sigcontext.h| 78 ++ arch/mips/include/uapi/asm/siginfo.h | 114 +++ arch/mips/include/uapi/asm/signal.h| 123 +++ arch/mips/include/uapi/asm/socket.h| 93 +++ arch/mips/include/{ => uapi}/asm/sockios.h |0 arch/mips/include/{ => uapi}/asm/stat.h|0 arch/mips/include/{ => uapi}/asm/statfs.h |0 arch/mips/include/{ => uapi}/asm/swab.h|0 arch/mips/include/{ => uapi}/asm/sysmips.h |0 arch/mips/include/{ => uapi}/asm/termbits.h|0 arch/mips/include/uapi/asm/termios.h | 80 ++ arch/mips/include/uapi/asm/types.h | 27 + arch/mips/include/uapi/asm/unistd.h| 1035 46 files changed, 1846 insertions(+), 1706 deletions(-) rename arch/mips/include/{ => uapi}/asm/auxvec.h (100%) rename arch/mips/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/mips/include/{ => uapi}/asm/byteorder.h (100%) rename arch/mips/include/{ => uapi}/asm/cachectl.h (100%) create mode 100644 arch/mips/include/uapi/asm/errno.h rename arch/mips/include/{ => uapi}/asm/fcntl.h (100%) rename arch/mips/include/{ => uapi}/asm/ioctl.h (100%) rename arch/mips/include/{ => uapi}/asm/ioctls.h (100%) rename arch/mips/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/mips/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/mips/include/{ => uapi}/asm/mman.h (100%) rename arch/mips/include/{ => uapi}/asm/msgbuf.h (100%) rename arch/mips/include/{ => uapi}/asm/param.h (100%) rename arch/mips/include/{ => uapi}/asm/poll.h (100%) rename arch/mips/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/mips/include/uapi/asm/ptrace.h rename arch/mips/include/{ => uapi}/asm/resource.h (100%) rename ar
[GIT PULL] Disintegrate UAPI for arm64 [ver #2]
Can you merge the following branch into the arm64 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-arm64-20121009 for you to fetch changes up to a24b2da6de9a44f395c67219d300de21f66d0da3: UAPI: (Scripted) Disintegrate arch/arm64/include/asm (2012-10-09 09:46:34 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/arm64/include/asm arch/arm64/include/asm/Kbuild | 2 - arch/arm64/include/asm/hwcap.h | 22 + arch/arm64/include/asm/ptrace.h | 88 +-- arch/arm64/include/asm/sigcontext.h | 40 + arch/arm64/include/asm/stat.h | 5 +- arch/arm64/include/asm/unistd.h | 8 +- arch/arm64/include/uapi/asm/Kbuild | 14 +++ arch/arm64/include/{ => uapi}/asm/auxvec.h | 0 arch/arm64/include/{ => uapi}/asm/bitsperlong.h | 0 arch/arm64/include/{ => uapi}/asm/byteorder.h | 0 arch/arm64/include/{ => uapi}/asm/fcntl.h | 0 arch/arm64/include/uapi/asm/hwcap.h | 39 + arch/arm64/include/{ => uapi}/asm/param.h | 0 arch/arm64/include/uapi/asm/ptrace.h| 110 arch/arm64/include/{ => uapi}/asm/setup.h | 0 arch/arm64/include/uapi/asm/sigcontext.h| 57 arch/arm64/include/{ => uapi}/asm/siginfo.h | 0 arch/arm64/include/{ => uapi}/asm/signal.h | 0 arch/arm64/include/uapi/asm/stat.h | 16 arch/arm64/include/{ => uapi}/asm/statfs.h | 0 arch/arm64/include/uapi/asm/unistd.h| 16 21 files changed, 257 insertions(+), 160 deletions(-) rename arch/arm64/include/{ => uapi}/asm/auxvec.h (100%) rename arch/arm64/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/arm64/include/{ => uapi}/asm/byteorder.h (100%) rename arch/arm64/include/{ => uapi}/asm/fcntl.h (100%) create mode 100644 arch/arm64/include/uapi/asm/hwcap.h rename arch/arm64/include/{ => uapi}/asm/param.h (100%) create mode 100644 arch/arm64/include/uapi/asm/ptrace.h rename arch/arm64/include/{ => uapi}/asm/setup.h (100%) create mode 100644 arch/arm64/include/uapi/asm/sigcontext.h rename arch/arm64/include/{ => uapi}/asm/siginfo.h (100%) rename arch/arm64/include/{ => uapi}/asm/signal.h (100%) create mode 100644 arch/arm64/include/uapi/asm/stat.h rename arch/arm64/include/{ => uapi}/asm/statfs.h (100%) create mode 100644 arch/arm64/include/uapi/asm/unistd.h . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Can you merge the following branch into the avr32 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-avr32-20121009 for you to fetch changes up to b9ba6b52cfb7f564c205bc42fed3297d623fc50f: UAPI: (Scripted) Disintegrate arch/avr32/include/asm (2012-10-09 09:46:37 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/avr32/include/asm arch/avr32/include/asm/Kbuild | 3 - arch/avr32/include/asm/param.h | 18 +- arch/avr32/include/asm/ptrace.h | 115 + arch/avr32/include/asm/setup.h | 5 +- arch/avr32/include/asm/signal.h | 121 +- arch/avr32/include/asm/termios.h| 41 +--- arch/avr32/include/asm/types.h | 6 +- arch/avr32/include/asm/unistd.h | 296 +-- arch/avr32/include/uapi/asm/Kbuild | 32 +++ arch/avr32/include/{ => uapi}/asm/auxvec.h | 0 arch/avr32/include/{ => uapi}/asm/bitsperlong.h | 0 arch/avr32/include/{ => uapi}/asm/byteorder.h | 0 arch/avr32/include/{ => uapi}/asm/cachectl.h| 0 arch/avr32/include/{ => uapi}/asm/errno.h | 0 arch/avr32/include/{ => uapi}/asm/fcntl.h | 0 arch/avr32/include/{ => uapi}/asm/ioctl.h | 0 arch/avr32/include/{ => uapi}/asm/ioctls.h | 0 arch/avr32/include/{ => uapi}/asm/ipcbuf.h | 0 arch/avr32/include/{ => uapi}/asm/kvm_para.h| 0 arch/avr32/include/{ => uapi}/asm/mman.h| 0 arch/avr32/include/{ => uapi}/asm/msgbuf.h | 0 arch/avr32/include/uapi/asm/param.h | 18 ++ arch/avr32/include/{ => uapi}/asm/poll.h| 0 arch/avr32/include/{ => uapi}/asm/posix_types.h | 0 arch/avr32/include/uapi/asm/ptrace.h| 126 ++ arch/avr32/include/{ => uapi}/asm/resource.h| 0 arch/avr32/include/{ => uapi}/asm/sembuf.h | 0 arch/avr32/include/uapi/asm/setup.h | 17 ++ arch/avr32/include/{ => uapi}/asm/shmbuf.h | 0 arch/avr32/include/{ => uapi}/asm/sigcontext.h | 0 arch/avr32/include/{ => uapi}/asm/siginfo.h | 0 arch/avr32/include/uapi/asm/signal.h| 128 ++ arch/avr32/include/{ => uapi}/asm/socket.h | 0 arch/avr32/include/{ => uapi}/asm/sockios.h | 0 arch/avr32/include/{ => uapi}/asm/stat.h| 0 arch/avr32/include/{ => uapi}/asm/statfs.h | 0 arch/avr32/include/{ => uapi}/asm/swab.h| 0 arch/avr32/include/{ => uapi}/asm/termbits.h| 0 arch/avr32/include/uapi/asm/termios.h | 50 arch/avr32/include/uapi/asm/types.h | 8 + arch/avr32/include/uapi/asm/unistd.h| 305 41 files changed, 692 insertions(+), 597 deletions(-) rename arch/avr32/include/{ => uapi}/asm/auxvec.h (100%) rename arch/avr32/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/avr32/include/{ => uapi}/asm/byteorder.h (100%) rename arch/avr32/include/{ => uapi}/asm/cachectl.h (100%) rename arch/avr32/include/{ => uapi}/asm/errno.h (100%) rename arch/avr32/include/{ => uapi}/asm/fcntl.h (100%) rename arch/avr32/include/{ => uapi}/asm/ioctl.h (100%) rename arch/avr32/include/{ => uapi}/asm/ioctls.h (100%) rename arch/avr32/include/{ => uapi}/asm/ipcbuf.h (100%) rename arch/avr32/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/avr32/include/{ => uapi}/asm/mman.h (100%) rename arch/avr32/include/{ => uapi}/asm/msgbuf.h (100%) create mode 100644 arch/avr32/include/uapi/asm/param.h rename arch/avr32/include/{ => uapi}/asm/poll.h (100%) rename arch/avr32/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/avr32/include/uapi/asm/ptrace.h rename arch/avr32/include/{ => uapi}/asm/resource.h (100%) rename arch/avr32/include/{ => uapi}/asm/sembuf.h (100%) create mode 100644 arch/avr32/include/uapi/asm/setup.h rename arch/avr32/include/{ => uapi}/asm/shmbuf.h (100%) rename arch/avr32/include/{ => uapi}/asm/sigcontext.h (100%) rename
[GIT PULL] Disintegrate UAPI for c6x [ver #2]
Can you merge the following branch into the c6x tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-c6x-20121009 for you to fetch changes up to 41e3f8a642842a137833de40cec447d35d6a8196: UAPI: (Scripted) Disintegrate arch/c6x/include/asm (2012-10-09 09:46:40 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/c6x/include/asm arch/c6x/include/asm/Kbuild | 1 - arch/c6x/include/asm/ptrace.h| 146 +--- arch/c6x/include/uapi/asm/Kbuild | 7 ++ arch/c6x/include/{ => uapi}/asm/byteorder.h | 0 arch/c6x/include/{ => uapi}/asm/kvm_para.h | 0 arch/c6x/include/uapi/asm/ptrace.h | 163 +++ arch/c6x/include/{ => uapi}/asm/setup.h | 0 arch/c6x/include/{ => uapi}/asm/sigcontext.h | 0 arch/c6x/include/{ => uapi}/asm/swab.h | 0 arch/c6x/include/{ => uapi}/asm/unistd.h | 0 10 files changed, 171 insertions(+), 146 deletions(-) rename arch/c6x/include/{ => uapi}/asm/byteorder.h (100%) rename arch/c6x/include/{ => uapi}/asm/kvm_para.h (100%) create mode 100644 arch/c6x/include/uapi/asm/ptrace.h rename arch/c6x/include/{ => uapi}/asm/setup.h (100%) rename arch/c6x/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/c6x/include/{ => uapi}/asm/swab.h (100%) rename arch/c6x/include/{ => uapi}/asm/unistd.h (100%) . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for arm [ver #2]
Can you merge the following branch into the arm tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-arm-20121009 for you to fetch changes up to 86418cab1bb1aa591d48ea51d67aeb54f30732d1: UAPI: (Scripted) Disintegrate arch/arm/include/asm (2012-10-09 09:46:32 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/arm/include/asm arch/arm/include/asm/Kbuild | 2 - arch/arm/include/asm/hwcap.h | 27 +- arch/arm/include/asm/ptrace.h | 126 +--- arch/arm/include/asm/setup.h | 172 +- arch/arm/include/asm/signal.h | 127 +--- arch/arm/include/asm/swab.h | 37 +-- arch/arm/include/asm/unistd.h | 440 + arch/arm/include/uapi/asm/Kbuild | 16 + arch/arm/include/{ => uapi}/asm/a.out.h | 0 arch/arm/include/{ => uapi}/asm/byteorder.h | 0 arch/arm/include/{ => uapi}/asm/fcntl.h | 0 arch/arm/include/uapi/asm/hwcap.h | 29 ++ arch/arm/include/{ => uapi}/asm/ioctls.h | 0 arch/arm/include/{ => uapi}/asm/kvm_para.h| 0 arch/arm/include/{ => uapi}/asm/mman.h| 0 arch/arm/include/{ => uapi}/asm/posix_types.h | 0 arch/arm/include/uapi/asm/ptrace.h| 137 arch/arm/include/uapi/asm/setup.h | 187 +++ arch/arm/include/{ => uapi}/asm/sigcontext.h | 0 arch/arm/include/uapi/asm/signal.h| 127 arch/arm/include/{ => uapi}/asm/stat.h| 0 arch/arm/include/{ => uapi}/asm/statfs.h | 0 arch/arm/include/uapi/asm/swab.h | 53 +++ arch/arm/include/uapi/asm/unistd.h| 450 ++ 24 files changed, 1005 insertions(+), 925 deletions(-) rename arch/arm/include/{ => uapi}/asm/a.out.h (100%) rename arch/arm/include/{ => uapi}/asm/byteorder.h (100%) rename arch/arm/include/{ => uapi}/asm/fcntl.h (100%) create mode 100644 arch/arm/include/uapi/asm/hwcap.h rename arch/arm/include/{ => uapi}/asm/ioctls.h (100%) rename arch/arm/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/arm/include/{ => uapi}/asm/mman.h (100%) rename arch/arm/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/arm/include/uapi/asm/ptrace.h create mode 100644 arch/arm/include/uapi/asm/setup.h rename arch/arm/include/{ => uapi}/asm/sigcontext.h (100%) create mode 100644 arch/arm/include/uapi/asm/signal.h rename arch/arm/include/{ => uapi}/asm/stat.h (100%) rename arch/arm/include/{ => uapi}/asm/statfs.h (100%) create mode 100644 arch/arm/include/uapi/asm/swab.h create mode 100644 arch/arm/include/uapi/asm/unistd.h . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for hexagon [ver #2]
Can you merge the following branch into the hexagon tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-hexagon-20121009 for you to fetch changes up to 044819a598469f603df5cfc8abfed766c9a9444a: UAPI: (Scripted) Disintegrate arch/hexagon/include/asm (2012-10-09 09:46:55 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/hexagon/include/asm arch/hexagon/include/asm/Kbuild | 3 --- arch/hexagon/include/uapi/asm/Kbuild | 12 arch/hexagon/include/{ => uapi}/asm/bitsperlong.h | 0 arch/hexagon/include/{ => uapi}/asm/byteorder.h | 0 arch/hexagon/include/{ => uapi}/asm/kvm_para.h| 0 arch/hexagon/include/{ => uapi}/asm/param.h | 0 arch/hexagon/include/{ => uapi}/asm/ptrace.h | 0 arch/hexagon/include/{ => uapi}/asm/registers.h | 0 arch/hexagon/include/{ => uapi}/asm/setup.h | 0 arch/hexagon/include/{ => uapi}/asm/sigcontext.h | 0 arch/hexagon/include/{ => uapi}/asm/signal.h | 0 arch/hexagon/include/{ => uapi}/asm/swab.h| 0 arch/hexagon/include/{ => uapi}/asm/unistd.h | 0 arch/hexagon/include/{ => uapi}/asm/user.h| 0 14 files changed, 12 insertions(+), 3 deletions(-) rename arch/hexagon/include/{ => uapi}/asm/bitsperlong.h (100%) rename arch/hexagon/include/{ => uapi}/asm/byteorder.h (100%) rename arch/hexagon/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/hexagon/include/{ => uapi}/asm/param.h (100%) rename arch/hexagon/include/{ => uapi}/asm/ptrace.h (100%) rename arch/hexagon/include/{ => uapi}/asm/registers.h (100%) rename arch/hexagon/include/{ => uapi}/asm/setup.h (100%) rename arch/hexagon/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/hexagon/include/{ => uapi}/asm/signal.h (100%) rename arch/hexagon/include/{ => uapi}/asm/swab.h (100%) rename arch/hexagon/include/{ => uapi}/asm/unistd.h (100%) rename arch/hexagon/include/{ => uapi}/asm/user.h (100%) . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Disintegrate UAPI for cris [ver #2]
Can you merge the following branch into the cris tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-cris-20121009 for you to fetch changes up to e717abac8a9f65eee6de3bb37e10c6916bced483: UAPI: (Scripted) Disintegrate arch/cris/include/asm (2012-10-09 09:46:45 +0100) UAPI Disintegration 2012-10-09 David Howells (3): UAPI: (Scripted) Disintegrate arch/cris/include/arch-v10/arch UAPI: (Scripted) Disintegrate arch/cris/include/arch-v32/arch UAPI: (Scripted) Disintegrate arch/cris/include/asm arch/cris/include/arch-v10/arch/Kbuild | 4 - arch/cris/include/arch-v32/arch/Kbuild | 2 - arch/cris/include/arch-v32/arch/cryptocop.h| 116 +-- arch/cris/include/asm/Kbuild | 5 - arch/cris/include/asm/ptrace.h | 5 +- arch/cris/include/asm/signal.h | 122 +--- arch/cris/include/asm/swab.h | 3 +- arch/cris/include/asm/termios.h| 43 +-- arch/cris/include/asm/types.h | 5 +- arch/cris/include/asm/unistd.h | 342 +--- arch/cris/include/uapi/arch-v10/arch/Kbuild| 4 + .../include/{ => uapi}/arch-v10/arch/sv_addr.agh | 0 .../include/{ => uapi}/arch-v10/arch/sv_addr_ag.h | 0 .../cris/include/{ => uapi}/arch-v10/arch/svinto.h | 0 arch/cris/include/{ => uapi}/arch-v10/arch/user.h | 0 arch/cris/include/uapi/arch-v32/arch/Kbuild| 2 + arch/cris/include/uapi/arch-v32/arch/cryptocop.h | 122 arch/cris/include/{ => uapi}/arch-v32/arch/user.h | 0 arch/cris/include/uapi/asm/Kbuild | 34 ++ arch/cris/include/{ => uapi}/asm/auxvec.h | 0 arch/cris/include/{ => uapi}/asm/bitsperlong.h | 0 arch/cris/include/{ => uapi}/asm/byteorder.h | 0 arch/cris/include/{ => uapi}/asm/errno.h | 0 arch/cris/include/{ => uapi}/asm/ethernet.h| 0 arch/cris/include/{ => uapi}/asm/etraxgpio.h | 0 arch/cris/include/{ => uapi}/asm/fcntl.h | 0 arch/cris/include/{ => uapi}/asm/ioctl.h | 0 arch/cris/include/{ => uapi}/asm/ioctls.h | 0 arch/cris/include/{ => uapi}/asm/ipcbuf.h | 0 arch/cris/include/{ => uapi}/asm/mman.h| 0 arch/cris/include/{ => uapi}/asm/msgbuf.h | 0 arch/cris/include/{ => uapi}/asm/param.h | 0 arch/cris/include/{ => uapi}/asm/poll.h| 0 arch/cris/include/{ => uapi}/asm/posix_types.h | 0 arch/cris/include/uapi/asm/ptrace.h| 1 + arch/cris/include/{ => uapi}/asm/resource.h| 0 arch/cris/include/{ => uapi}/asm/rs485.h | 0 arch/cris/include/{ => uapi}/asm/sembuf.h | 0 arch/cris/include/{ => uapi}/asm/setup.h | 0 arch/cris/include/{ => uapi}/asm/shmbuf.h | 0 arch/cris/include/{ => uapi}/asm/sigcontext.h | 0 arch/cris/include/{ => uapi}/asm/siginfo.h | 0 arch/cris/include/uapi/asm/signal.h| 122 arch/cris/include/{ => uapi}/asm/socket.h | 0 arch/cris/include/{ => uapi}/asm/sockios.h | 0 arch/cris/include/{ => uapi}/asm/stat.h| 0 arch/cris/include/{ => uapi}/asm/statfs.h | 0 arch/cris/include/{ => uapi}/asm/sync_serial.h | 0 arch/cris/include/{ => uapi}/asm/termbits.h| 0 arch/cris/include/uapi/asm/termios.h | 45 +++ arch/cris/include/uapi/asm/types.h | 1 + arch/cris/include/uapi/asm/unistd.h| 344 + 52 files changed, 682 insertions(+), 640 deletions(-) rename arch/cris/include/{ => uapi}/arch-v10/arch/sv_addr.agh (100%) rename arch/cris/include/{ => uapi}/arch-v10/arch/sv_addr_ag.h (100%) rename arch/cris/include/{ => uapi}/arch-v10/arch/svinto.h (100%) rename arch/cris/include/{ => uapi}/arch-v10/arch/user.h (100%) create mode 100644 arch/cris/include/uapi/arch-v32/arch/cryptocop.h rename arch/cris/include/{ =&g
[GIT PULL] Disintegrate UAPI for blackfin [ver #2]
Can you merge the following branch into the blackfin tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-blackfin-20121009 for you to fetch changes up to ac3a050e89f2e6b8025e4176a36ed34de470fcad: UAPI: (Scripted) Disintegrate arch/blackfin/include/asm (2012-10-09 09:46:39 +0100) UAPI Disintegration 2012-10-09 David Howells (1): UAPI: (Scripted) Disintegrate arch/blackfin/include/asm arch/blackfin/include/asm/Kbuild | 5 - arch/blackfin/include/asm/bfin_sport.h | 128 +- arch/blackfin/include/asm/fixed_code.h | 30 +- arch/blackfin/include/asm/ptrace.h | 161 +--- arch/blackfin/include/asm/unistd.h | 430 +--- arch/blackfin/include/uapi/asm/Kbuild | 16 + arch/blackfin/include/uapi/asm/bfin_sport.h| 136 +++ arch/blackfin/include/{ => uapi}/asm/byteorder.h | 0 arch/blackfin/include/{ => uapi}/asm/cachectl.h| 0 arch/blackfin/include/{ => uapi}/asm/fcntl.h | 0 arch/blackfin/include/uapi/asm/fixed_code.h| 38 ++ arch/blackfin/include/{ => uapi}/asm/ioctls.h | 0 arch/blackfin/include/{ => uapi}/asm/kvm_para.h| 0 arch/blackfin/include/{ => uapi}/asm/poll.h| 0 arch/blackfin/include/{ => uapi}/asm/posix_types.h | 0 arch/blackfin/include/uapi/asm/ptrace.h| 170 arch/blackfin/include/{ => uapi}/asm/sigcontext.h | 0 arch/blackfin/include/{ => uapi}/asm/siginfo.h | 0 arch/blackfin/include/{ => uapi}/asm/signal.h | 0 arch/blackfin/include/{ => uapi}/asm/stat.h| 0 arch/blackfin/include/{ => uapi}/asm/swab.h| 0 arch/blackfin/include/uapi/asm/unistd.h| 437 + 22 files changed, 802 insertions(+), 749 deletions(-) create mode 100644 arch/blackfin/include/uapi/asm/bfin_sport.h rename arch/blackfin/include/{ => uapi}/asm/byteorder.h (100%) rename arch/blackfin/include/{ => uapi}/asm/cachectl.h (100%) rename arch/blackfin/include/{ => uapi}/asm/fcntl.h (100%) create mode 100644 arch/blackfin/include/uapi/asm/fixed_code.h rename arch/blackfin/include/{ => uapi}/asm/ioctls.h (100%) rename arch/blackfin/include/{ => uapi}/asm/kvm_para.h (100%) rename arch/blackfin/include/{ => uapi}/asm/poll.h (100%) rename arch/blackfin/include/{ => uapi}/asm/posix_types.h (100%) create mode 100644 arch/blackfin/include/uapi/asm/ptrace.h rename arch/blackfin/include/{ => uapi}/asm/sigcontext.h (100%) rename arch/blackfin/include/{ => uapi}/asm/siginfo.h (100%) rename arch/blackfin/include/{ => uapi}/asm/signal.h (100%) rename arch/blackfin/include/{ => uapi}/asm/stat.h (100%) rename arch/blackfin/include/{ => uapi}/asm/swab.h (100%) create mode 100644 arch/blackfin/include/uapi/asm/unistd.h . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: busses: i2c-ocores: switch to devm_request_and_ioremap
> "Maxin" == Maxin B John writes: Maxin> Hi Peter, Maxin> This drops a few lines of code and allows common APIs to handle Maxin> those for us. Maxin> Signed-off-by: Maxin B. John >> Acked-by: Peter Korsgaard Maxin> Is there any update on this ? I'm expecting Wolfram to pick it up. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 05/06] input/rmi4: F01 - device control
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote: > RMI Function 01 implements basic device control and power management > behaviors for the RMI4 sensor. Since the last patch, we've decoupled > rmi_f01.c > implementation from rmi_driver.c, so rmi_f01.c acts as a standard driver > module to handle F01 devices on the RMI bus. > > Like other modules, a number of attributes have been moved from sysfs to > debugfs, depending on their expected use. > > > rmi_f01.h exports definitions that we expect to be used by other functionality > in the future (such as firmware reflash). > > > Signed-off-by: Christopher Heiny > > Cc: Dmitry Torokhov > Cc: Linus Walleij > Cc: Naveen Kumar Gaddipati > Cc: Joeri de Gram > > --- There is liberal whitespacing above. (No big deal, but anyway.) (...) > +/** > + * @reset - set this bit to force a firmware reset of the sensor. > + */ > +union f01_device_commands { > + struct { > + bool reset:1; > + u8 reserved:7; > + } __attribute__((__packed__)); > + u8 reg; > +}; I'm still scared by these unions. I see what you're doing but my preferred style of driver writing is to use a simple u8 if you just treat it the right way with some |= and &= ... #include #define F01_RESET BIT(0) u8 my_command = F01_RESET; send(&my_command); I will not insist on this because it's a bit about programming style. For memory-mapped devices we usually do it my way, but this is more like some protocol and I know protocols like to do things with structs and stuff so no big deal. > +#ifdef CONFIG_RMI4_DEBUG > +struct f01_debugfs_data { > + bool done; > + struct rmi_function_container *fc; > +}; > + > +static int f01_debug_open(struct inode *inodep, struct file *filp) > +{ > + struct f01_debugfs_data *data; > + struct rmi_function_container *fc = inodep->i_private; > + > + data = devm_kzalloc(&fc->dev, sizeof(struct f01_debugfs_data), > + GFP_KERNEL); Wait, you probably did this because I requested it, but I was maybe wrong? Will this not re-allocate a chunk every time you look at a debugfs file? So it leaks memory? In that case common kzalloc() and kfree() is the way to go, as it is for dynamic buffers. Sorry for screwing things up for you. :-( > + for (i = 0; i < f01->irq_count && *local_buf != 0; > +i++, local_buf += 2) { > + int irq_shift; > + int interrupt_enable; > + int result; > + > + irq_reg = i / 8; > + irq_shift = i % 8; Please stop doing these arithmetics-turned-maths things. irq_reg = i >> 8; irq_shift = i & 0xFF; (...) > +static ssize_t rmi_fn_01_interrupt_enable_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct rmi_function_container *fc; > + struct f01_data *data; > + int i, len, total_len = 0; > + char *current_buf = buf; > + > + fc = to_rmi_function_container(dev); > + data = fc->data; > + /* loop through each irq value and copy its > +* string representation into buf */ > + for (i = 0; i < data->irq_count; i++) { > + int irq_reg; > + int irq_shift; > + int interrupt_enable; > + > + irq_reg = i / 8; > + irq_shift = i % 8; Dito. (...) > +static int f01_probe(struct device *dev); Do you really need to forward-declare this? (...) > +static struct rmi_function_handler function_handler = { > + .driver = { > + .owner = THIS_MODULE, > + .name = "rmi_f01", > + .bus = &rmi_bus_type, > + .probe = f01_probe, > + .remove = f01_remove_device, > + }, > + .func = 0x01, > + .config = rmi_f01_config, > + .attention = rmi_f01_attention, > + > +#ifdef CONFIG_PM > + .suspend = rmi_f01_suspend, > + .resume = rmi_f01_resume, > +#endif /* CONFIG_PM */ > +}; Just move this block of struct *below* the probe function... > +static __devinit int f01_probe(struct device *dev) Header file looks OK (if these unions is the way to go...) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Fix XFS oops due to dirty pages without buffers on s390
On Mon, Oct 08, 2012 at 09:24:40PM -0700, Hugh Dickins wrote: > > > > CC: Mel Gorman > > and I'm grateful to Mel's ack for reawakening me to it... > > > CC: linux-s...@vger.kernel.org > > Signed-off-by: Jan Kara > > but I think it's wrong. > Dang. > > --- > > mm/rmap.c | 16 ++-- > > 1 files changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/mm/rmap.c b/mm/rmap.c > > index 0f3b7cd..6ce8ddb 100644 > > --- a/mm/rmap.c > > +++ b/mm/rmap.c > > @@ -973,7 +973,15 @@ int page_mkclean(struct page *page) > > struct address_space *mapping = page_mapping(page); > > if (mapping) { > > ret = page_mkclean_file(mapping, page); > > - if (page_test_and_clear_dirty(page_to_pfn(page), 1)) > > + /* > > +* We ignore dirty bit for pagecache pages. It is safe > > +* as page is marked dirty iff it is writeable (page is > > +* marked as dirty when it is made writeable and > > +* clear_page_dirty_for_io() writeprotects the page > > +* again). > > +*/ > > + if (PageSwapCache(page) && > > + page_test_and_clear_dirty(page_to_pfn(page), 1)) > > ret = 1; > > This part you could cut out: page_mkclean() is not used on SwapCache pages. > I believe you are safe to remove the page_test_and_clear_dirty() from here. > > > } > > } > > @@ -1183,8 +1191,12 @@ void page_remove_rmap(struct page *page) > > * this if the page is anon, so about to be freed; but perhaps > > * not if it's in swapcache - there might be another pte slot > > * containing the swap entry, but page not yet written to swap. > > +* For pagecache pages, we don't care about dirty bit in storage > > +* key because the page is writeable iff it is dirty (page is marked > > +* as dirty when it is made writeable and clear_page_dirty_for_io() > > +* writeprotects the page again). > > */ > > - if ((!anon || PageSwapCache(page)) && > > + if (PageSwapCache(page) && > > page_test_and_clear_dirty(page_to_pfn(page), 1)) > > set_page_dirty(page); > > But here's where I think the problem is. You're assuming that all > filesystems go the same mapping_cap_account_writeback_dirty() (yeah, > there's no such function, just a confusing maze of three) route as XFS. > > But filesystems like tmpfs and ramfs (perhaps they're the only two > that matter here) don't participate in that, and wait for an mmap'ed > page to be seen modified by the user (usually via pte_dirty, but that's > a no-op on s390) before page is marked dirty; and page reclaim throws > away undirtied pages. > > So, if I'm understanding right, with this change s390 would be in danger > of discarding shm, and mmap'ed tmpfs and ramfs pages - whereas pages > written with the write system call would already be PageDirty and secure. > In the case of ramfs, what marks the page clean so it could be discarded? It does not participate in dirty accounting so it's not going to clear the dirty flag in clear_page_dirty_for_io(). It doesn't have a writepage handler that would use an end_io handler to clear the page after "IO" completes. I am not seeing how a ramfs page can get discarded at the moment. shm and tmpfs are indeed different and I did not take them into account (ba dum tisch) when reviewing. For those pages would it be sufficient to check the following? PageSwapCache(page) || (page->mapping && !bdi_cap_account_dirty(page->mapping) The problem the patch dealt with involved buffers associated with the page and that shouldn't be a problem for tmpfs, right? I recognise that this might work just because of co-incidence and set off your "Yuck" detector and you'll prefer the proposed solution below. > You mention above that even the kernel writing to the page would mark > the s390 storage key dirty. I think that means that these shm and > tmpfs and ramfs pages would all have dirty storage keys just from the > clear_highpage() used to prepare them originally, and so would have > been found dirty anyway by the existing code here in page_remove_rmap(), > even though other architectures would regard them as clean and removable. > > If that's the case, then maybe we'd do better just to mark them dirty > when faulted in the s390 case. Then your patch above should (I think) > be safe. Though I'd then be VERY tempted to adjust the SwapCache case > too (I've not thought through exactly what that patch would be, just > one or two suitably placed SetPageDirtys, I think), and eliminate > page_test_and_clear_dirty() altogether - no tears shed by any of us! > Do you mean something like this? diff --git a/mm/memory.c b/mm/memory.c index 5736170..c66166f 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3316,7 +3316,20 @@ static int __do_fault(struct mm_struct *mm, struct
[PATCH] driver/char/tpm: fix regression causesd by ppi
From: Gang Wei This patch try to fix the S3 regression https://lkml.org/lkml/2012/10/5/433, which includes below line: [ 1554.684638] sysfs: cannot create duplicate filename '/devices/pnp0/00:0c/ppi' The root cause is that ppi sysfs teardown code is MIA, so while S3 resume, the ppi kobject will be created again upon existing one. To make the tear down code simple, change the ppi subfolder creation from using kobject_create_and_add to just using a named ppi attribute_group. Then ppi sysfs teardown could be done with a simple sysfs_remove_group call. Adjusted the name & return type for ppi sysfs init function. Reported-by: Ben Guthro Signed-off-by: Gang Wei --- drivers/char/tpm/tpm.c |3 ++- drivers/char/tpm/tpm.h |9 +++-- drivers/char/tpm/tpm_ppi.c | 18 ++ 3 files changed, 19 insertions(+), 11 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index f26afdb..b429f1e 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -1259,6 +1259,7 @@ void tpm_remove_hardware(struct device *dev) misc_deregister(&chip->vendor.miscdev); sysfs_remove_group(&dev->kobj, chip->vendor.attr_group); + tpm_remove_ppi(&dev->kobj); tpm_bios_log_teardown(chip->bios_dir); /* write it this way to be explicit (chip->dev == dev) */ @@ -1476,7 +1477,7 @@ struct tpm_chip *tpm_register_hardware(struct device *dev, goto put_device; } - if (sys_add_ppi(&dev->kobj)) { + if (tpm_add_ppi(&dev->kobj)) { misc_deregister(&chip->vendor.miscdev); goto put_device; } diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index 02c266a..8ef7649 100644 --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -329,10 +329,15 @@ extern int wait_for_tpm_stat(struct tpm_chip *, u8, unsigned long, wait_queue_head_t *); #ifdef CONFIG_ACPI -extern ssize_t sys_add_ppi(struct kobject *parent); +extern int tpm_add_ppi(struct kobject *); +extern void tpm_remove_ppi(struct kobject *); #else -static inline ssize_t sys_add_ppi(struct kobject *parent) +static inline int tpm_add_ppi(struct kobject *parent) { return 0; } + +static inline void tpm_remove_ppi(struct kobject *parent) +{ +} #endif diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c index f27b58c..720ebcf 100644 --- a/drivers/char/tpm/tpm_ppi.c +++ b/drivers/char/tpm/tpm_ppi.c @@ -444,18 +444,20 @@ static struct attribute *ppi_attrs[] = { &dev_attr_vs_operations.attr, NULL, }; static struct attribute_group ppi_attr_grp = { + .name = "ppi", .attrs = ppi_attrs }; -ssize_t sys_add_ppi(struct kobject *parent) +int tpm_add_ppi(struct kobject *parent) { - struct kobject *ppi; - ppi = kobject_create_and_add("ppi", parent); - if (sysfs_create_group(ppi, &ppi_attr_grp)) - return -EFAULT; - else - return 0; + return sysfs_create_group(parent, &ppi_attr_grp); +} +EXPORT_SYMBOL_GPL(tpm_add_ppi); + +void tpm_remove_ppi(struct kobject *parent) +{ + sysfs_remove_group(parent, &ppi_attr_grp); } -EXPORT_SYMBOL_GPL(sys_add_ppi); +EXPORT_SYMBOL_GPL(tpm_remove_ppi); MODULE_LICENSE("GPL"); -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Hans-Christian Egtvedt wrote: > Neither Haavard or me have a GIT tree at kernel.org anymore, I hope to get my > key signed in Barcelona during ELCE. Could you ask Linus to pull directly, or > pass it through Andrew. I can ask Linus directly. Can I add your Acked-by to it? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Disintegrate UAPI for microblaze
Michal Simek wrote: > I expect your intention is to merge this to mainline in current merge > window, right? It is preferred that it go through the maintainer's tree if possible. Note that I've posted a new version that doesn't have the dependencies any more as they've been merged upstream. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] Add a V4L2 driver for SI476X MFD
Note: I'm CC-ing Halli. Halli, can you take a look at the proposed controls? On Mon 8 October 2012 19:57:17 Andrey Smirnov wrote: > On 10/08/2012 02:30 AM, Hans Verkuil wrote: > > On Sat October 6 2012 03:55:01 Andrey Smirnov wrote: > >> This commit adds a driver that exposes all the radio related > >> functionality of the Si476x series of chips via the V4L2 subsystem. > >> > >> Signed-off-by: Andrey Smirnov > >> --- > >> drivers/media/radio/Kconfig| 17 + > >> drivers/media/radio/Makefile |1 + > >> drivers/media/radio/radio-si476x.c | 1153 > >> > >> 3 files changed, 1171 insertions(+) > >> create mode 100644 drivers/media/radio/radio-si476x.c > >> > >> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig > >> index 8090b87..3c79d09 100644 > >> --- a/drivers/media/radio/Kconfig > >> +++ b/drivers/media/radio/Kconfig > >> +static const struct v4l2_ctrl_config si476x_ctrls[] = { > >> + /* > >> + Tuning parameters > >> + 'max tune errors' is shared for both AM/FM mode of operation > >> + */ > >> + { > >> + .ops= &si476x_ctrl_ops, > >> + .id = SI476X_CID_RSSI_THRESHOLD, > >> + .name = "valid rssi threshold", > >> + .type = V4L2_CTRL_TYPE_INTEGER, > >> + .min= -128, > >> + .max= 127, > >> + .step = 1, > >> + }, > >> + { > >> + .ops= &si476x_ctrl_ops, > >> + .id = SI476X_CID_SNR_THRESHOLD, > >> + .type = V4L2_CTRL_TYPE_INTEGER, > >> + .name = "valid snr threshold", > >> + .min= -128, > >> + .max= 127, > >> + .step = 1, > >> + }, > >> + { > >> + .ops= &si476x_ctrl_ops, > >> + .id = SI476X_CID_MAX_TUNE_ERROR, > >> + .type = V4L2_CTRL_TYPE_INTEGER, > >> + .name = "max tune errors", > >> + .min= 0, > >> + .max= 126 * 2, > >> + .step = 2, > >> + }, > >> + /* > >> + Region specific parameters > >> + */ > >> + { > >> + .ops= &si476x_ctrl_ops, > >> + .id = SI476X_CID_HARMONICS_COUNT, > >> + .type = V4L2_CTRL_TYPE_INTEGER, > >> + .name = "count of harmonics to reject", > >> + .min= 0, > >> + .max= 20, > >> + .step = 1, > >> + }, > >> + { > >> + .ops= &si476x_ctrl_ops, > >> + .id = SI476X_CID_DEEMPHASIS, > >> + .type = V4L2_CTRL_TYPE_MENU, > >> + .name = "de-emphassis", > >> + .qmenu = deemphasis, > >> + .min= 0, > >> + .max= ARRAY_SIZE(deemphasis) - 1, > >> + .def= 0, > >> + }, > > I think most if not all of the controls above are candidates for turning > > into > > standardized controls. I recommend that you make a proposal (RFC) for this. > > > > This may be useful as well: > > > > http://lists-archives.com/linux-kernel/27641304-radio-fixes-and-new-features-for-fm.html > > > > This patch series contains a standardized DEEMPHASIS control. > > Note that this patch series is outdated, but patch 2/5 is OK. > > So do you want me to take that patch and make it the part of this patch > set or do you want me to create a separate RFC with a patch set that > contains all those controls? No, that was just FYI. I've asked Halli Manjunatha, the author of that patch series to make a new version that can be upstreamed. The reason it was stalled was due to a long discussion at the time how to implement multiple frequency bands, but now that that has been resolved this patch series can move forward as well. > > Just to give some description: > > SI476X_CID_RSSI_THRESHOLD, SI476X_CID_SNR_THRESHOLD, > SI476X_CID_MAX_TUNE_ERROR are used to determine at which level of SNR, > RSSI the station station should be considered valid and what margin of > error is to be used(SI476X_CID_MAX_TUNE_ERROR) for those parameters. I know that other devices (wl128x) also have similar SNR, RSSI functionality. Halli, can you check if it would make sense to have generic controls for this? > SI476X_CID_HARMONICS_COUNT is the amount of AC grid noise harmonics > build-in hardware(or maybe FW) will try to filter out in AM mode. I don't really know whether this is chip specific or not. Halli, do you have any input on this? > It seems to me that the controls described above are quite chip specific > should I also include them in the RFC? Let's wait what Halli says, but yes, it should be included in the RFC: we want to know if this should be standardized or not, so it's good to mention it so people are aware of this. > >> + { > >> + .ops= &si476x_ctrl_ops, > >> + .id = SI476X_CID_RDS_RECEPTION, > >> + .type = V4L2_CTRL_TYPE_BOOLEAN, > >> + .name = "rds", > >> + .min= 0, > >> + .max= 1, > >> + .step = 1, > >> + }, > > If this control
Re: [PATCH v2 3/6] Add commands abstraction layer for SI476X MFD
On Mon 8 October 2012 22:06:29 Andrey Smirnov wrote: > On 10/08/2012 01:56 AM, Hans Verkuil wrote: > > On Sat October 6 2012 03:54:59 Andrey Smirnov wrote: > >> This patch adds all the functions used for exchanging commands with > >> the chip. > >> > >> Signed-off-by: Andrey Smirnov > >> --- > >> drivers/mfd/si476x-cmd.c | 1493 > >> ++ > >> 1 file changed, 1493 insertions(+) > >> create mode 100644 drivers/mfd/si476x-cmd.c > >> > >> diff --git a/drivers/mfd/si476x-cmd.c b/drivers/mfd/si476x-cmd.c > >> new file mode 100644 > >> index 000..f11cf58 > >> --- /dev/null > >> +++ b/drivers/mfd/si476x-cmd.c > >> +/** > >> + * si476x_cmd_am_rsq_status - send 'FM_TUNE_FREQ' command to the > >> + * device > >> + * @core - device to send the command to > >> + * @rsqack - if set command clears RSQINT, SNRINT, SNRLINT, RSSIHINT, > >> + * RSSSILINT, BLENDINT, MULTHINT and MULTLINT > >> + * @attune - when set the values in the status report are the values > >> + * that were calculated at tune > >> + * @cancel - abort ongoing seek/tune opertation > >> + * @stcack - clear the STCINT bin in status register > >> + * @report - all signal quality information retured by the command > >> + * (if NULL then the output of the command is ignored) I've just noticed that this comment block does not correspond at all to the code. It's a good idea to check the other comment blocks for similar copy/paste errors. > >> + * > >> + * Function returns 0 on success and negative error code on failure > >> + */ > >> +int si476x_core_cmd_am_rsq_status(struct si476x_core *core, > >> +struct si476x_rsq_status_args *rsqargs, > >> +struct si476x_rsq_status_report *report) > >> +{ > >> + int err; > >> + u8 resp[CMD_AM_RSQ_STATUS_NRESP]; > >> + const u8 args[CMD_AM_RSQ_STATUS_NARGS] = { > >> + rsqargs->rsqack << 3 | rsqargs->attune << 2 | > >> + rsqargs->cancel << 1 | rsqargs->stcack, > >> + }; > >> + > >> + err = CORE_SEND_COMMAND(core, CMD_AM_RSQ_STATUS, > >> + args, resp, > >> + atomic_read(&core->timeouts.command)); > >> + > >> + if (report) { > > Do you really need to test 'report'? Does it ever make sense if this is > > called with a NULL report pointer? > > Unfortunately yes. This command is also used to acknowledge and > STC(seek-tune completed) > interrupt. A comment would be welcome here, and in similar cases. It's not obvious. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.32.60
I've just released Linux 2.6.32.60. This release contains, among others, a number of fixes for random and NTP, including for the NTP leap second bug. Users should upgrade. The patch and changelog will appear soon at the following locations: ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.60.bz2 ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.60.xz ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.60.gz ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.32.60 The updated 2.6.32.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-2.6.32.y http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-2.6.32.y The tree can be browsed on the gitweb interface: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=refs/heads/linux-2.6.32.y Testing status (build/boot, OK/FAIL, otherwise not tested) : ARCH | CONFIGURATION +--- | allmodconfig other-config arm |build:OK- x86_64 |build:OK- i386 |build:OK boot:OK Thanks to all reviewers, especially Ben for his long careful review, and to Greg for the final packaging. Willy - Documentation/kernel-parameters.txt | 5 + Documentation/stable_kernel_rules.txt | 6 + MAINTAINERS | 2 +- Makefile| 2 +- arch/arm/kernel/sys_arm.c | 2 +- arch/ia64/include/asm/unistd.h | 3 +- arch/ia64/kernel/entry.S| 13 ++ arch/ia64/kernel/irq_ia64.c | 1 - arch/ia64/kvm/kvm-ia64.c| 5 + arch/mips/include/asm/thread_info.h | 4 +- arch/mips/kernel/vmlinux.lds.S | 3 +- arch/parisc/include/asm/atomic.h| 4 +- arch/powerpc/include/asm/reg.h | 3 +- arch/powerpc/kernel/ftrace.c| 12 +- arch/powerpc/kernel/module_32.c | 11 +- arch/powerpc/platforms/powermac/smp.c | 2 +- arch/sparc/Makefile | 2 +- arch/sparc/kernel/ds.c | 2 +- arch/sparc/kernel/rtrap_64.S| 7 - arch/x86/Kconfig| 9 + arch/x86/include/asm/archrandom.h | 75 +++ arch/x86/include/asm/cpufeature.h | 2 + arch/x86/include/asm/k8.h | 2 + arch/x86/include/asm/kvm_emulate.h | 15 ++ arch/x86/include/asm/timer.h| 8 +- arch/x86/kernel/cpu/Makefile| 1 + arch/x86/kernel/cpu/common.c| 2 + arch/x86/kernel/cpu/rdrand.c| 73 +++ arch/x86/kernel/k8.c| 31 +++ arch/x86/kernel/tls.c | 4 +- arch/x86/kernel/tsc.c | 3 +- arch/x86/kvm/emulate.c | 57 - arch/x86/kvm/i8254.c| 10 +- arch/x86/kvm/irq.h | 6 +- arch/x86/kvm/x86.c | 61 +- arch/x86/lib/delay.c| 4 +- arch/x86/mm/fault.c | 10 +- arch/x86/mm/pageattr.c | 18 +- arch/x86/mm/pgtable.c | 11 +- arch/x86/oprofile/backtrace.c | 4 +- arch/x86/pci/amd_bus.c | 43 +--- arch/x86/xen/enlighten.c| 3 + arch/x86/xen/mmu.c | 10 +- arch/x86/xen/xen-asm.S | 2 +- block/blk-ioc.c | 12 +- crypto/sha512_generic.c | 2 +- drivers/acpi/ac.c | 4 +- drivers/block/cciss_scsi.c | 12 +- drivers/block/sx8.c | 2 +- drivers/bluetooth/btusb.c | 9 +- drivers/bluetooth/hci_ldisc.c | 6 +- drivers/char/random.c | 375 +--- drivers/char/tty_audit.c| 4 +- drivers/dma/ioat/dma_v2.c | 34 +-- drivers/dma/ioat/dma_v2.h | 2 - drivers/firmware/dmi_scan.c | 3 + drivers/firmware/pcdp.c | 4 +- drivers/gpu/drm/i915/intel_display.c| 11 +- drivers/mfd/wm831x-otp.c| 8 + drivers/mtd/nand/cafe_nand.c| 2 +- drivers/net/atlx/atl1.c | 12 +- drivers/net/atlx/atl1.h | 3 +- drivers/net/atlx/atlx.c | 2 +- drivers/net/bonding/bond_3ad.c | 7 +- drivers/net/dl2k.c | 157 + drivers/net/dl2k.h | 117 +- drivers/net/ks8851_mll.c| 2 +- drivers/net/netxen/netxen_nic.h | 7 +- drivers/net/netxen/netxen_nic_ctx.c |
Re: [GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Around Tue 09 Oct 2012 10:15:15 +0100 or thereabout, David Howells wrote: > Can you merge the following branch into the avr32 tree please. > Neither Haavard or me have a GIT tree at kernel.org anymore, I hope to get my key signed in Barcelona during ELCE. Could you ask Linus to pull directly, or pass it through Andrew. > This is to complete part of the UAPI disintegration for which the preparatory > patches were pulled recently. > > Now that the fixups and the asm-generic chunk have been merged, I've > regenerated the patches to get rid of those dependencies and to take account > of > any changes made so far in the merge window. If you have already pulled the > older version of the branch aimed at you, then please feel free to ignore this > request. > > The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: > > Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) > > are available in the git repository at: > > > git://git.infradead.org/users/dhowells/linux-headers.git > tags/disintegrate-avr32-20121009 > > for you to fetch changes up to b9ba6b52cfb7f564c205bc42fed3297d623fc50f: > > UAPI: (Scripted) Disintegrate arch/avr32/include/asm (2012-10-09 09:46:37 > +0100) > > > UAPI Disintegration 2012-10-09 > > > David Howells (1): > UAPI: (Scripted) Disintegrate arch/avr32/include/asm > > arch/avr32/include/asm/Kbuild | 3 - > arch/avr32/include/asm/param.h | 18 +- > arch/avr32/include/asm/ptrace.h | 115 + > arch/avr32/include/asm/setup.h | 5 +- > arch/avr32/include/asm/signal.h | 121 +- > arch/avr32/include/asm/termios.h| 41 +--- > arch/avr32/include/asm/types.h | 6 +- > arch/avr32/include/asm/unistd.h | 296 +-- > arch/avr32/include/uapi/asm/Kbuild | 32 +++ > arch/avr32/include/{ => uapi}/asm/auxvec.h | 0 > arch/avr32/include/{ => uapi}/asm/bitsperlong.h | 0 > arch/avr32/include/{ => uapi}/asm/byteorder.h | 0 > arch/avr32/include/{ => uapi}/asm/cachectl.h| 0 > arch/avr32/include/{ => uapi}/asm/errno.h | 0 > arch/avr32/include/{ => uapi}/asm/fcntl.h | 0 > arch/avr32/include/{ => uapi}/asm/ioctl.h | 0 > arch/avr32/include/{ => uapi}/asm/ioctls.h | 0 > arch/avr32/include/{ => uapi}/asm/ipcbuf.h | 0 > arch/avr32/include/{ => uapi}/asm/kvm_para.h| 0 > arch/avr32/include/{ => uapi}/asm/mman.h| 0 > arch/avr32/include/{ => uapi}/asm/msgbuf.h | 0 > arch/avr32/include/uapi/asm/param.h | 18 ++ > arch/avr32/include/{ => uapi}/asm/poll.h| 0 > arch/avr32/include/{ => uapi}/asm/posix_types.h | 0 > arch/avr32/include/uapi/asm/ptrace.h| 126 ++ > arch/avr32/include/{ => uapi}/asm/resource.h| 0 > arch/avr32/include/{ => uapi}/asm/sembuf.h | 0 > arch/avr32/include/uapi/asm/setup.h | 17 ++ > arch/avr32/include/{ => uapi}/asm/shmbuf.h | 0 > arch/avr32/include/{ => uapi}/asm/sigcontext.h | 0 > arch/avr32/include/{ => uapi}/asm/siginfo.h | 0 > arch/avr32/include/uapi/asm/signal.h| 128 ++ > arch/avr32/include/{ => uapi}/asm/socket.h | 0 > arch/avr32/include/{ => uapi}/asm/sockios.h | 0 > arch/avr32/include/{ => uapi}/asm/stat.h| 0 > arch/avr32/include/{ => uapi}/asm/statfs.h | 0 > arch/avr32/include/{ => uapi}/asm/swab.h| 0 > arch/avr32/include/{ => uapi}/asm/termbits.h| 0 > arch/avr32/include/uapi/asm/termios.h | 50 > arch/avr32/include/uapi/asm/types.h | 8 + > arch/avr32/include/uapi/asm/unistd.h| 305 > > 41 files changed, 692 insertions(+), 597 deletions(-) > rename arch/avr32/include/{ => uapi}/asm/auxvec.h (100%) > rename arch/avr32/include/{ => uapi}/asm/bitsperlong.h (100%) > rename arch/avr32/include/{ => uapi}/asm/byteorder.h (100%) > rename arch/avr32/include/{ => uapi}/asm/cachectl.h (100%) > rename arch/avr32/include/{ => uapi}/asm/errno.h (100%) > rename arch/avr32/include/{ => uapi}/asm/fcntl.h (100%) > rename arch/avr32/include/{ => uapi}/asm/ioctl.h (100%) > rename arch/avr32/include/{ => uapi}/asm/ioctls.h (100%) > rename arch/avr32/include/{ => uapi}/asm/ipcbuf.h (100%) > rename arch/avr32/include/{ => uapi}/asm
[PATCH] pch_gbe: Fix build error by selecting all the possible dependencies.
Fengguang reported a kernel build failure as following: drivers/built-in.o: In function `pch_gbe_ioctl': pch_gbe_main.c:(.text+0x510370): undefined reference to `pch_ch_control_write' pch_gbe_main.c:(.text+0x510393): undefined reference to `pch_ch_control_write' pch_gbe_main.c:(.text+0x5103b3): undefined reference to `pch_ch_control_write' ... It's a regression by commit da1586461. The root cause is that the CONFIG_PPS is not set there, consequently CONFIG_PTP_1588_CLOCK can not be set anyway, which finally causes ptp_pch and pch_gbe_main build failures. As David prefers to use *select* to fix such module co-dependency issues, this patch explicitly selects all the possible dependencies of PCH_PTP. Reported-by: Fengguang Wu Reviewed-by: David S. Miller Signed-off-by: Haicheng Li --- drivers/net/ethernet/oki-semi/pch_gbe/Kconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig index 9730241..5296cc8 100644 --- a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig +++ b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig @@ -26,6 +26,9 @@ if PCH_GBE config PCH_PTP bool "PCH PTP clock support" default n + depends on EXPERIMENTAL + select PPS + select PTP_1588_CLOCK select PTP_1588_CLOCK_PCH ---help--- Say Y here if you want to use Precision Time Protocol (PTP) in the -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.0+ Disk performance problem - wrong pdflush behaviour
Hello, Since Kernel version 3.0 pdflush blocks writes even the dirty bytes are well below /proc/sys/vm/dirty_bytes or /proc/sys/vm/dirty_ratio. The kernel 2.6.39 works nice. How this hurt us in the real life: We have a very high performance game server where the MySQL have to do many writes along the reads. All writes and reads are very simple and have to be very quick. If we run the system with Linux 3.2 we get unacceptable performance. Now we are stuck with 2.6.32 kernel here because this problem. I attach the test program wrote by me which shows the problem. The program just writes blocks continously to random position to a given big file. The write rate limited to 100 MByte/s. In a well-working kernel it have to run with constant 100 MBit/s speed for indefinite long. The test have to be run on a simple HDD. Test steps: 1. You have to use an XFS, EXT2 or ReiserFS partition for the test, Ext4 forces flushes periodically. I recommend to use XFS. 2. create a big file on the test partiton. For 8 GByte RAM you can create a 2 GByte file. For 2 GB RAM I recommend to create 500MByte file. File creation can be done with this command: dd if=/dev/zero of=bigfile2048M.bin bs=1M count=2048 3. compile pdflushtest.c: (gcc -o pdflushtest pdflushtest.c) 4. run pdflushtest: ./pdflushtest --file=/where/is/the/bigfile2048M.bin In the beginning there can be some slowness even on well-working kernels. If you create the bigfile in the same run then it runs usually smootly from the beginning. I don't know a setting of /proc/sys/vm variables which runs this test smootly on a 3.2.29 (3.0+) kernel. I think this is a kernel bug, because if I have much more "/proc/sys/vm/dirty_bytes" than the testfile size the test program should never be blocked. A sample result: 11:20:05: speed: 99.994 MiB/s, time usage: 4.60 %, avg. block time:1.8 us, max. block time: 18 us 11:20:06: speed: 99.994 MiB/s, time usage: 4.60 %, avg. block time:1.8 us, max. block time: 10 us 11:20:07: speed: 99.994 MiB/s, time usage: 4.62 %, avg. block time:1.8 us, max. block time: 11 us 11:20:08: speed: 99.989 MiB/s, time usage: 4.59 %, avg. block time:1.8 us, max. block time: 58 us 11:20:09: speed: 99.997 MiB/s, time usage: 4.55 %, avg. block time:1.8 us, max. block time: 13 us 11:20:10: speed: 28.840 MiB/s, time usage: 96.47 %, avg. block time: 130.7 us, max. block time: 114076 us 11:20:11: speed: 30.505 MiB/s, time usage: 98.14 %, avg. block time: 125.7 us, max. block time: 135008 us 11:20:12: speed: 25.956 MiB/s, time usage: 99.71 %, avg. block time: 150.1 us, max. block time: 129839 us 11:20:13: speed: 25.088 MiB/s, time usage: 96.43 %, avg. block time: 150.1 us, max. block time: 149649 us 11:20:14: speed: 32.438 MiB/s, time usage: 98.64 %, avg. block time: 118.8 us, max. block time: 145649 us 11:20:15: speed: 22.765 MiB/s, time usage: 99.11 %, avg. block time: 170.1 us, max. block time: 159749 us At 11:20:10 the pdflush started its work, based on the "dirty_expire_centisecs". The test file was 2GByte, the /proc/sys/vm/dirty_bytes/dirty_bytes was 40. The system (i5-3.4 GHz, 8G RAM, Kernel 3.2.29-amd64) was booted to run this test only so it had 2,2 GByte RAM for cache, and 5.1 GByte RAM free (totally unused). Sorry if I not found the right place to report this, please advise me were to send. Best regards Viktor Nagy #include #include #include #include #include #include #include #include #include #include // parameters char * filename = NULL; enum testermode {READ, WRITE} mode = WRITE; float speedlimit = 100; // MiB / s int burstcount = 10; // internals int blocksize = 4096; int blockcount = 0; int fh = 0; char filebuffer[65536]; static struct option long_options[] = { {"mode", required_argument, 0, 0 }, {"m", required_argument, 0, 0 }, {"file",required_argument, 0, 0 }, {"f",required_argument, 0, 0 }, {"limit",required_argument, 0, 0 }, {"l",required_argument, 0, 0 }, {"burst",required_argument, 0, 0 }, {"b",required_argument, 0, 0 }, {0, 0, 0, 0 } }; void parse_commandline(int argc, char **argv) { int r; int option_index = 0; while (0 <= (r = getopt_long_only(argc, argv, "", long_options, &option_index))) { const char * optname = long_options[option_index].name; if (r == 0) { if (strcmp("file", optname) == 0 || strcmp("f", optname) == 0) { filename = strdup(optarg); } else if (strcmp("mode", optname) == 0 || strcmp("m", optname) == 0) { if (strcmp("reader", optarg) == 0 || strcmp("read", optarg) == 0) { mode = READ; } else if (strcmp("writer", optarg) == 0 || strcmp("write", optarg) == 0) { mode = WRITE; } else { printf("Invalid mode: \"%s\"\n", optarg); } } else if (strcmp("burst", optname) == 0 || strcmp("b", optname) == 0) { burstcount = a
Re: [PATCH v2 1/6] Add header files and Kbuild plumbing for SI476x MFD core
On Mon 8 October 2012 20:38:01 Andrey Smirnov wrote: > On 10/08/2012 01:43 AM, Hans Verkuil wrote: > > On Sat October 6 2012 03:54:57 Andrey Smirnov wrote: > >> This patch adds all necessary header files and Kbuild plumbing for the > >> core driver for Silicon Laboratories Si476x series of AM/FM tuner > >> chips. > >> > >> The driver as a whole is implemented as an MFD device and this patch > >> adds a core portion of it that provides all the necessary > >> functionality to the two other drivers that represent radio and audio > >> codec subsystems of the chip. > >> > >> Signed-off-by: Andrey Smirnov > >> --- > >> drivers/mfd/Kconfig | 14 ++ > >> drivers/mfd/Makefile|3 + > >> include/linux/mfd/si476x-core.h | 529 > >> +++ > >> include/media/si476x.h | 449 + > >> 4 files changed, 995 insertions(+) > >> create mode 100644 include/linux/mfd/si476x-core.h > >> create mode 100644 include/media/si476x.h > >> > >> diff --git a/include/linux/mfd/si476x-core.h > >> b/include/linux/mfd/si476x-core.h > >> new file mode 100644 > >> index 000..eb6f52a > >> --- /dev/null > >> +++ b/include/linux/mfd/si476x-core.h > >> +#define SI476X_IOC_GET_RSQ_IOWR('V', BASE_VIDIOC_PRIVATE > >> + 0, \ > >> +struct si476x_rsq_status_report) > >> + > >> +#define SI476X_IOC_SET_PHDIV_MODE _IOW('V', BASE_VIDIOC_PRIVATE + 1, \ > >> + enum si476x_phase_diversity_mode) > >> + > >> +#define SI476X_IOC_GET_PHDIV_STATUS _IOWR('V', BASE_VIDIOC_PRIVATE > >> + 2, \ > >> +int) > >> + > >> +#define SI476X_IOC_GET_RSQ_PRIMARY_IOWR('V', BASE_VIDIOC_PRIVATE > >> + 3, \ > >> +struct si476x_rsq_status_report) > >> + > >> +#define SI476X_IOC_GET_ACF_IOWR('V', BASE_VIDIOC_PRIVATE > >> + 4, \ > >> +struct si476x_acf_status_report) > >> + > >> +#define SI476X_IOC_GET_AGC_IOWR('V', BASE_VIDIOC_PRIVATE > >> + 5, \ > >> +struct si476x_agc_status_report) > >> + > >> +#define SI476X_IOC_GET_RDS_BLKCNT _IOWR('V', BASE_VIDIOC_PRIVATE + 6, \ > >> + struct si476x_rds_blockcount_report) > > There is no documentation at all for these private ioctls. At the very least > > these should be documentated (both the ioctl and the structs they receive). > > > > More importantly, are these ioctls really needed? > > I apologize for not writing the documentation for those ioctls. I > thought I at least did so for all data structures returned by those > calls, I guess I never got around to doing it. I'll document all the > ioctls in the next version of the patch. > > SI476X_IOC_SET_PHDIV_MODE, SI476X_IOC_GET_PHDIV_STATUS are definitely > needed since they are used to control antenna phase diversity modes of > the tuners. In that mode two Si4764 chips connected to different > antennas can act as a single tuner and use both signal to improve > sensibility. Interesting. But I wonder if this can be implemented as controls? That seems to me to be a better fit. > The rest is useful to get different radio signal parameters from the > chip. We used it for during RF performance evaluation of the > boards(probably using it in EOL testing). > > > If the purpose is to return > > status information for debugging, then you should consider implementing > > VIDIOC_LOG_STATUS instead. > > For me, the problem with using VIDIOC_LOG_STATUS is that it dumps all > the debugging information in kernel log buffer, meaning that if one > wants to pass that information to some other application they would have > to resort to screen-scraping of the output of dmesg. Unfortunately the > people who were using this driver/as a part of a software suite during > aforementioned RF performance testing are not Linux-savvy enough to be > asked to use dmesg and they want a GUI solution. That small test utility > was written and it uses those those ioctls to gather and display all > signal related information. I guess the other solution for that problem > would be to create corresponding files in sysfs, but I'm not sure if > creating multitude of files in sysfs tree is a better option. Definitely not, although using debugfs might be a good idea. > Since this version of the driver has not been integrated into our > software package the we install on laptops to do all the board testing I > guess I can remove those 'ioctl', but I would love to find acceptable > solution so that later I would be able to integrate upstream driver int > our package and not use "special" version of the driver for our purposes. Can you split off the implementation of these ioctls from the rest of the driver? And I think you should look into debugfs to see if that isn't a be
Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'
Hi Sjur, On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen wrote: > On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu wrote: >> Hi Ohad, >> >> FYI, kernel build failed on >> >> tree: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git >> for-next >> head: bec109a430e8c67bae1743f7e71898283234a77f >> commit: ec4d02d9180f407c41f8310a13b34e473c671fbb [6/9] remoteproc: Add STE >> modem driver >> config: i386-randconfig-b102 (attached as .config) >> >> It should be an old bug. The commit happen to be the one to trigger >> the errors because it selects CONFIG_EMOTEPROC. > > Thanks Fengguang. > > This should be fixed by a patch I pushed today to remoteproc's for-next > branch. > > Though I wonder, Sjur, do we want to limit the architectures/platforms > where the STE modem driver can be selected on ? Is it ARM only perhaps ? Can you please address the above question ? Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 10/10] mm: kill vma flag VM_RESERVED and mm->reserved_vm counter
On Tue, 2012-07-31 at 14:42 +0400, Konstantin Khlebnikov wrote: > A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA, > currently it lost original meaning but still has some effects: > > | effect | alternative flags > -++- > 1| account as reserved_vm | VM_IO > 2| skip in core dump | VM_IO, VM_DONTDUMP > 3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP > 4| do not mlock | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP > > This patch removes reserved_vm counter from mm_struct. > Seems like nobody cares about it, it does not exported into userspace > directly, > it only reduces total_vm showed in proc. > > Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | > VM_DONTDUMP. > > remap_pfn_range() and io_remap_pfn_range() set > VM_IO|VM_DONTEXPAND|VM_DONTDUMP. > remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP. > > Signed-off-by: Konstantin Khlebnikov > Cc: Nick Piggin > Cc: Hugh Dickins > --- > Documentation/vm/unevictable-lru.txt |4 ++-- > arch/alpha/kernel/pci-sysfs.c|2 +- > arch/ia64/kernel/perfmon.c |2 +- > arch/ia64/mm/init.c |3 ++- > arch/powerpc/kvm/book3s_hv.c |2 +- > arch/sparc/kernel/pci.c |2 +- > arch/unicore32/kernel/process.c |2 +- > arch/x86/xen/mmu.c |3 +-- > drivers/char/mbcs.c |2 +- > drivers/char/mem.c |2 +- > drivers/char/mspec.c |2 +- > drivers/gpu/drm/drm_gem.c|2 +- > drivers/gpu/drm/drm_vm.c | 10 ++ > drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- > drivers/gpu/drm/gma500/framebuffer.c |3 +-- > drivers/gpu/drm/ttm/ttm_bo_vm.c |4 ++-- > drivers/gpu/drm/udl/udl_fb.c |2 +- > drivers/infiniband/hw/ehca/ehca_uverbs.c |4 ++-- > drivers/infiniband/hw/ipath/ipath_file_ops.c |2 +- > drivers/infiniband/hw/qib/qib_file_ops.c |2 +- > drivers/media/video/meye.c |2 +- > drivers/media/video/omap/omap_vout.c |2 +- > drivers/media/video/sn9c102/sn9c102_core.c |3 +-- > drivers/media/video/usbvision/usbvision-video.c |3 +-- > drivers/media/video/videobuf-dma-sg.c|2 +- > drivers/media/video/videobuf-vmalloc.c |2 +- > drivers/media/video/videobuf2-memops.c |2 +- > drivers/media/video/vino.c |2 +- > drivers/misc/carma/carma-fpga.c |2 -- > drivers/misc/sgi-gru/grufile.c |5 ++--- > drivers/mtd/mtdchar.c|2 +- > drivers/scsi/sg.c|2 +- > drivers/staging/media/easycap/easycap_main.c |2 +- > drivers/staging/omapdrm/omap_gem_dmabuf.c|2 +- > drivers/staging/tidspbridge/rmgr/drv_interface.c |2 +- > drivers/uio/uio.c|4 +--- > drivers/usb/mon/mon_bin.c|2 +- > drivers/video/68328fb.c |2 +- > drivers/video/aty/atyfb_base.c |3 +-- > drivers/video/fb-puv3.c |3 +-- > drivers/video/fb_defio.c |2 +- > drivers/video/fbmem.c|3 +-- > drivers/video/gbefb.c|2 +- > drivers/video/omap2/omapfb/omapfb-main.c |2 +- > drivers/video/sbuslib.c |5 ++--- > drivers/video/smscufx.c |1 - > drivers/video/udlfb.c|1 - > drivers/video/vermilion/vermilion.c |1 - > drivers/video/vfb.c |1 - > drivers/xen/gntalloc.c |2 +- > drivers/xen/gntdev.c |2 +- > drivers/xen/privcmd.c|3 ++- > fs/binfmt_elf.c |2 +- > fs/binfmt_elf_fdpic.c|2 +- > fs/hugetlbfs/inode.c |2 +- > fs/proc/task_mmu.c |2 +- > include/linux/mempolicy.h|2 +- > include/linux/mm.h |3 +-- > include/linux/mm_types.h |1 - > kernel/events/core.c |2 +- > mm/ksm.c |3 +-- > mm/memory.c | 11 +-- > mm/mlock.c
Re: [RFC PATCH 06/06] input/rmi4: F11 - 2D touch interface
On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny wrote: So looking closer at this one since we will use it. Maybe it's in such a good shape now that I should be able to actually test it with the hardware? (...) > diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c (...) > +#ifdef CONFIG_RMI4_DEBUG > +#include > +#include > +#include > +#endif Skip the #ifdef > +#define F11_CTRL_SENSOR_MAX_X_POS_OFFSET 6 > +#define F11_CTRL_SENSOR_MAX_Y_POS_OFFSET 8 > + > +#define F11_CEIL(x, y) (((x) + ((y)-1)) / (y)) Use existing kernel macros in In this case: #define F11_CEIL(x, y) DIV_ROUND_UP(x, y) Or just use DIV_ROUND_UP() directly in the code, your choice. > +#define MAX_NAME_LENGTH 256 Really? Are you sure there is not a null terminator or length byte included so it's actually 255? (...) > +static int sensor_debug_open(struct inode *inodep, struct file *filp) > +{ > + struct sensor_debugfs_data *data; > + struct f11_2d_sensor *sensor = inodep->i_private; > + struct rmi_function_container *fc = sensor->fc; > + > + data = devm_kzalloc(&fc->dev, sizeof(struct sensor_debugfs_data), > + GFP_KERNEL); Again I may have lead you astray. Check if this leaks memory, in that case use kzalloc()/kfree(). Sorry :-( (...) > +static int f11_debug_open(struct inode *inodep, struct file *filp) > +{ > + struct f11_debugfs_data *data; > + struct rmi_function_container *fc = inodep->i_private; > + > + data = devm_kzalloc(&fc->dev, sizeof(struct f11_debugfs_data), > + GFP_KERNEL); Dito. :-( (...) > +static void rmi_f11_abs_pos_report(struct f11_data *f11, > + struct f11_2d_sensor *sensor, > + u8 finger_state, u8 n_finger) (...) > + if (axis_align->flip_y) > + y = max(sensor->max_y - y, 0); > + > + /* > + ** here checking if X offset or y offset are specified is > + ** redundant. We just add the offsets or, clip the values > + ** > + ** note: offsets need to be done before clipping occurs, > + ** or we could get funny values that are outside > + ** clipping boundaries. > + */ This is a weird commenting style, what's wrong with a single star? (No big deal but it stands out...) (...) > +static int f11_allocate_control_regs(struct rmi_device *rmi_dev, > + struct f11_2d_device_query *device_query, > + struct f11_2d_sensor_query *sensor_query, > + struct f11_2d_ctrl *ctrl, > + u16 ctrl_base_addr) { > + > + struct rmi_driver_data *driver_data = dev_get_drvdata(&rmi_dev->dev); > + struct rmi_function_container *fc = driver_data->f01_container; > + > + ctrl->ctrl0_9 = devm_kzalloc(&fc->dev, sizeof(union f11_2d_ctrl0_9), > + GFP_KERNEL); If this is called from .probe() only, this is correct. So the rule is: use devm_* for anything that is allocated at .probe() and released on .remove(). Any other dynamic buffers etc need to use common kzalloc()/kfree(). > + if (!ctrl->ctrl0_9) > + return -ENOMEM; > + if (sensor_query->f11_2d_query7__8[0]) { > + ctrl->ctrl10 = devm_kzalloc(&fc->dev, > + sizeof(union f11_2d_ctrl10), GFP_KERNEL); > + if (!ctrl->ctrl10) > + return -ENOMEM; > + } > + > + if (sensor_query->f11_2d_query7__8[1]) { > + ctrl->ctrl11 = devm_kzalloc(&fc->dev, > + sizeof(union f11_2d_ctrl11), GFP_KERNEL); > + if (!ctrl->ctrl11) > + return -ENOMEM; > + } > + > + if (device_query->has_query9 && sensor_query->query9.has_pen) { > + ctrl->ctrl20_21 = devm_kzalloc(&fc->dev, > + sizeof(union f11_2d_ctrl20_21), GFP_KERNEL); > + if (!ctrl->ctrl20_21) > + return -ENOMEM; > + } > + > + if (device_query->has_query9 && sensor_query->query9.has_proximity) { > + ctrl->ctrl22_26 = devm_kzalloc(&fc->dev, > + sizeof(union f11_2d_ctrl22_26), GFP_KERNEL); > + if (!ctrl->ctrl22_26) > + return -ENOMEM; > + } > + > + if (device_query->has_query9 && > + (sensor_query->query9.has_palm_det_sensitivity || > + sensor_query->query9.has_suppress_on_palm_detect)) { > + ctrl->ctrl27 = devm_kzalloc(&fc->dev, > + sizeof(union f11_2d_ctrl27), GFP_KERNEL); > + if (!ctrl->ctrl27) > + return -ENOMEM; > + } > + > + if (sensor_query->has_multi_finger_scroll) { > + ctrl->ctrl28 = devm_kzalloc(&fc
Re: [3.6-rc7] switcheroo race with Intel HDA...
At Tue, 9 Oct 2012 00:34:09 +0800, Daniel J Blueman wrote: > > On 8 October 2012 20:58, Takashi Iwai wrote: > > At Tue, 25 Sep 2012 13:20:05 +0800, > > Daniel J Blueman wrote: > >> On my Macbook with a discrete Nvidia GPU, there is a race between > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], > >> reliably causing a kernel oops [2]. > >> > >> Introducing a delay of ~1s between the calls prevents this. When the > >> second 'OFF' write path executes, it looks like struct azx at > >> card->private_data hasn't yet been allocated yet [3], so there is > >> likely some locking missing. > > > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus > > card->private_data causes Oops). Could you check the patch like below > > and see whether you get a kernel warning (but no Oops) or the problem > > gets fixed by shifting the assignment of pci drvdata? > [...] > > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, > though we see unexpected 0x0 responses in the response ring buffer > [1], which we don't see when there's a >~1.5s delay between IGD and > OFF. If the previous patch fixed, it means that the switching occurred during the device was being probed. Maybe a better approach to register the VGA switcheroo after the proper initialization. The patch below is a revised one. Please give it a try. Takashi --- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f09ff6c..dcbfd29 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -501,6 +501,7 @@ struct azx { /* VGA-switcheroo setup */ unsigned int use_vga_switcheroo:1; + unsigned int vga_switcheroo_registered:1; unsigned int init_failed:1; /* delayed init failed */ unsigned int disabled:1; /* disabled by VGA-switcher */ @@ -2684,14 +2685,20 @@ static const struct vga_switcheroo_client_ops azx_vs_ops = { static int __devinit register_vga_switcheroo(struct azx *chip) { + int err; + if (!chip->use_vga_switcheroo) return 0; /* FIXME: currently only handling DIS controller * is there any machine with two switchable HDMI audio controllers? */ - return vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, + err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, VGA_SWITCHEROO_DIS, chip->bus != NULL); + if (err < 0) + return err; + chip->vga_switcheroo_registered = 1; + return 0; } #else #define init_vga_switcheroo(chip) /* NOP */ @@ -2713,7 +2720,8 @@ static int azx_free(struct azx *chip) if (use_vga_switcheroo(chip)) { if (chip->disabled && chip->bus) snd_hda_unlock_devices(chip->bus); - vga_switcheroo_unregister_client(chip->pci); + if (chip->vga_switcheroo_registered) + vga_switcheroo_unregister_client(chip->pci); } if (chip->initialized) { @@ -3067,14 +3075,6 @@ static int __devinit azx_create(struct snd_card *card, struct pci_dev *pci, } ok: - err = register_vga_switcheroo(chip); - if (err < 0) { - snd_printk(KERN_ERR SFX - "Error registering VGA-switcheroo client\n"); - azx_free(chip); - return err; - } - err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops); if (err < 0) { snd_printk(KERN_ERR SFX "Error creating device [card]!\n"); @@ -3345,6 +3345,13 @@ static int __devinit azx_probe(struct pci_dev *pci, if (pci_dev_run_wake(pci)) pm_runtime_put_noidle(&pci->dev); + err = register_vga_switcheroo(chip); + if (err < 0) { + snd_printk(KERN_ERR SFX + "Error registering VGA-switcheroo client\n"); + goto out_free; + } + dev++; return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
On Tue, 9 Oct 2012, Tang Chen wrote: > > > Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this > > > should be called at CPU_DYING level and migrate_tasks() still sees a valid > > > cpu. > > As Wen said below, nid is now set to -1 when cpu is hotremoved. > I reproduce this problem in this situation: > > all cpus are online, and hot remove a system board directorily, without > offlining any cpu. > > As a result, the removed cpu's nid is set to -1, and this causes > problems. > Let's add Andrew to the cc list then, because I'm nacking cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch in the -mm tree for this reason. We can only clear a cpu-to-node mapping when the cpu is completely offline, not before or during the CPU_DYING stage. Kernel code, such as the sched code that you are now trying to "fix", depends on this mapping to work correctly; obviously no audit was done of cpu hotplug code depending on it before the patch was proposed. I say "fix" because even this workaround isn't a good solution since it would be much better to pick another cpu on the same node as the offlining cpu for the runqueue before falling back to the set of all allowed nodes. We lose all NUMA affinity information with that patch. There's no reason why we shouldn't know the node of a cpu that is being offlined. So nack to cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch. After it's removed because it's buggy, this "fix" will no longer be necessary. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Disintegrate UAPI for avr32 [ver #2]
Around Tue 09 Oct 2012 10:37:20 +0100 or thereabout, David Howells wrote: > Hans-Christian Egtvedt wrote: > >> Neither Haavard or me have a GIT tree at kernel.org anymore, I hope to get my >> key signed in Barcelona during ELCE. Could you ask Linus to pull directly, or >> pass it through Andrew. > > I can ask Linus directly. Can I add your Acked-by to it? > Acked-by: Hans-Christian Egtvedt -- mvh Hans-Christian Egtvedt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6-rc7] switcheroo race with Intel HDA...
At Tue, 09 Oct 2012 12:04:08 +0200, Takashi Iwai wrote: > > At Tue, 9 Oct 2012 00:34:09 +0800, > Daniel J Blueman wrote: > > > > On 8 October 2012 20:58, Takashi Iwai wrote: > > > At Tue, 25 Sep 2012 13:20:05 +0800, > > > Daniel J Blueman wrote: > > >> On my Macbook with a discrete Nvidia GPU, there is a race between > > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], > > >> reliably causing a kernel oops [2]. > > >> > > >> Introducing a delay of ~1s between the calls prevents this. When the > > >> second 'OFF' write path executes, it looks like struct azx at > > >> card->private_data hasn't yet been allocated yet [3], so there is > > >> likely some locking missing. > > > > > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus > > > card->private_data causes Oops). Could you check the patch like below > > > and see whether you get a kernel warning (but no Oops) or the problem > > > gets fixed by shifting the assignment of pci drvdata? > > [...] > > > > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, > > though we see unexpected 0x0 responses in the response ring buffer > > [1], which we don't see when there's a >~1.5s delay between IGD and > > OFF. > > If the previous patch fixed, it means that the switching occurred > during the device was being probed. Maybe a better approach to > register the VGA switcheroo after the proper initialization. > > The patch below is a revised one. Please give it a try. Also, it's not clear which card spews the spurious response. Apply the patch below in addition. thanks, Takashi --- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f09ff6c..9a0a29d 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -829,8 +829,9 @@ static void azx_update_rirb(struct azx *chip) smp_wmb(); chip->rirb.cmds[addr]--; } else - snd_printk(KERN_ERR SFX "spurious response %#x:%#x, " + snd_printk(KERN_ERR SFX "%s: spurious response %#x:%#x, " "last cmd=%#08x\n", + pci_name(chip->pci), res, res_ex, chip->last_cmd[addr]); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CMA broken in next-20120926
On Tue, Oct 09, 2012 at 10:40:10AM +0200, Bartlomiej Zolnierkiewicz wrote: > I also need following patch to make CONFIG_CMA=y && CONFIG_COMPACTION=y case > work: > > From: Bartlomiej Zolnierkiewicz > Subject: [PATCH] mm: compaction: cache if a pageblock was scanned and no > pages were isolated - cma fix > > Patch "mm: compaction: cache if a pageblock was scanned and no pages > were isolated" needs a following fix to successfully boot next-20121002 > kernel (same with next-20121008) with CONFIG_CMA=y and CONFIG_COMPACTION=y > (with applied -fix1, -fix2, -fix3 patches from Mel Gorman and also with > cmatest module from Thierry Reding compiled in). > Why is it needed to make it boot? CMA should not care about the PG_migrate_skip hint being set because it should always ignore it in alloc_contig_range() due to cc->ignore_skip_hint. It's not obvious to me why this fixes a boot failure and I wonder if it's papering over some underlying problem. Can you provide more details please? > Signed-off-by: Bartlomiej Zolnierkiewicz > Signed-off-by: Kyungmin Park > --- > mm/compaction.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: b/mm/compaction.c > === > --- a/mm/compaction.c 2012-10-08 18:10:53.491679716 +0200 > +++ b/mm/compaction.c 2012-10-08 18:11:33.615679713 +0200 > @@ -117,7 +117,8 @@ static void update_pageblock_skip(struct > bool migrate_scanner) > { > struct zone *zone = cc->zone; > - if (!page) > + > + if (!page || cc->ignore_skip_hint) > return; > > if (!nr_isolated) { -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uclinux-dist-devel] [GIT PULL] Disintegrate UAPI for blackfin [ver #2]
On Tue, Oct 9, 2012 at 5:15 PM, David Howells wrote: > Can you merge the following branch into the blackfin tree please. > Merged into my git tree: git://git.kernel.org/pub/scm/linux/kernel/git/lliubbo/blackfin.git for-linus And what time i need to ask linus to pull? Next merge window? > This is to complete part of the UAPI disintegration for which the preparatory > patches were pulled recently. > > Now that the fixups and the asm-generic chunk have been merged, I've > regenerated the patches to get rid of those dependencies and to take account > of > any changes made so far in the merge window. If you have already pulled the > older version of the branch aimed at you, then please feel free to ignore this > request. > > The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: > > Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) > > are available in the git repository at: > > > git://git.infradead.org/users/dhowells/linux-headers.git > tags/disintegrate-blackfin-20121009 > > for you to fetch changes up to ac3a050e89f2e6b8025e4176a36ed34de470fcad: > > UAPI: (Scripted) Disintegrate arch/blackfin/include/asm (2012-10-09 > 09:46:39 +0100) > > > UAPI Disintegration 2012-10-09 > > > David Howells (1): > UAPI: (Scripted) Disintegrate arch/blackfin/include/asm > > arch/blackfin/include/asm/Kbuild | 5 - > arch/blackfin/include/asm/bfin_sport.h | 128 +- > arch/blackfin/include/asm/fixed_code.h | 30 +- > arch/blackfin/include/asm/ptrace.h | 161 +--- > arch/blackfin/include/asm/unistd.h | 430 +--- > arch/blackfin/include/uapi/asm/Kbuild | 16 + > arch/blackfin/include/uapi/asm/bfin_sport.h| 136 +++ > arch/blackfin/include/{ => uapi}/asm/byteorder.h | 0 > arch/blackfin/include/{ => uapi}/asm/cachectl.h| 0 > arch/blackfin/include/{ => uapi}/asm/fcntl.h | 0 > arch/blackfin/include/uapi/asm/fixed_code.h| 38 ++ > arch/blackfin/include/{ => uapi}/asm/ioctls.h | 0 > arch/blackfin/include/{ => uapi}/asm/kvm_para.h| 0 > arch/blackfin/include/{ => uapi}/asm/poll.h| 0 > arch/blackfin/include/{ => uapi}/asm/posix_types.h | 0 > arch/blackfin/include/uapi/asm/ptrace.h| 170 > arch/blackfin/include/{ => uapi}/asm/sigcontext.h | 0 > arch/blackfin/include/{ => uapi}/asm/siginfo.h | 0 > arch/blackfin/include/{ => uapi}/asm/signal.h | 0 > arch/blackfin/include/{ => uapi}/asm/stat.h| 0 > arch/blackfin/include/{ => uapi}/asm/swab.h| 0 > arch/blackfin/include/uapi/asm/unistd.h| 437 > + > 22 files changed, 802 insertions(+), 749 deletions(-) > create mode 100644 arch/blackfin/include/uapi/asm/bfin_sport.h > rename arch/blackfin/include/{ => uapi}/asm/byteorder.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/cachectl.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/fcntl.h (100%) > create mode 100644 arch/blackfin/include/uapi/asm/fixed_code.h > rename arch/blackfin/include/{ => uapi}/asm/ioctls.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/kvm_para.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/poll.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/posix_types.h (100%) > create mode 100644 arch/blackfin/include/uapi/asm/ptrace.h > rename arch/blackfin/include/{ => uapi}/asm/sigcontext.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/siginfo.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/signal.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/stat.h (100%) > rename arch/blackfin/include/{ => uapi}/asm/swab.h (100%) > create mode 100644 arch/blackfin/include/uapi/asm/unistd.h > . > ___ > Uclinux-dist-devel mailing list > uclinux-dist-de...@blackfin.uclinux.org > https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel -- Regards, --Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] HID: Fix missing Unifying device issue
Hello Apostolos, Your problem is unrelated to hid-logitech-dj. This seems an usb driver issue. It seems that your motherboard has different usb controllers for the rear and front ports. There may be an issue with the usb drivers for the xhci controllers. Cheers, Nestor. On Mon, Oct 8, 2012 at 9:42 PM, Apostolos Bartziokas wrote: > > Nestor hello > > Sorry for bringing this up again but i tested the patch now that it > reached the stable kernels and when i connect it to the rear panel of my > motherboard i get: > > Oct 08 22:11:43 mainland kernel: usb 3-2: >USB disconnect, device number 2 > Oct 08 22:12:04 mainland kernel: usb 1-2: >new full-speed USB device > number 3 using xhci_hcd > Oct 08 22:12:05 mainland kernel: logitech-djreceiver 0003:046D:C52B.0009: > >hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on > usb-:00:14.0-2/input2 > Oct 08 22:12:05 mainland kernel: logitech-djreceiver 0003:046D:C52B.0009: > >logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 > Oct 08 22:12:05 mainland kernel: logitech-djreceiver: probe of > 0003:046D:C52B.0009 failed with error -32 > Oct 08 22:13:50 mainland kernel: usb 1-2: >USB disconnect, device number 3 > Oct 08 22:13:57 mainland kernel: usb 5-1.6: >new full-speed USB device > number 3 using ehci_hcd > Oct 08 22:13:58 mainland kernel: logitech-djreceiver 0003:046D:C52B.000C: > >hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on > usb-:00:1a.0-1.6/input2 > Oct 08 22:14:01 mainland kernel: input: Logitech Unifying Device. Wireless > PID:101a as > /devices/pci:00/:00:1a.0/usb5/5-1/5-1.6/5-1.6:1.2/0003:046D:C52B.000C/input/input15 > Oct 08 22:14:01 mainland kernel: logitech-djdevice 0003:046D:C52B.000D: > >input,hidraw3: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless > PID:101a] on usb-:00:1a.0-1.6:1 > Oct 08 22:14:17 mainland kernel: usb 5-1.6: >USB disconnect, device number > 3 > Oct 08 22:14:20 mainland kernel: usb 1-2: >new full-speed USB device > number 4 using xhci_hcd > Oct 08 22:14:20 mainland kernel: logitech-djreceiver 0003:046D:C52B.0010: > >hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on > usb-:00:14.0-2/input2 > Oct 08 22:14:20 mainland kernel: logitech-djreceiver 0003:046D:C52B.0010: > >logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 > Oct 08 22:14:20 mainland kernel: logitech-djreceiver: probe of > 0003:046D:C52B.0010 failed with error -32 > > When i use a usb3 port it doesn't move at all and if i use a usb2 port its > slow. When i use the front panel it works flawlessly. Could this be related > to my POS Intel motherboard? > > Kind regards and apologies if i raise a false alarm. > > Apostolos B. > On 09/28/2012 10:57 AM, Nestor Lopez Casado wrote: > > Hello Josip, > > This really looks like a different problem from the one addressed with > this patch. > > I'll try to work on it as soon as I find some time for that. > > Thanks, > Nestor. > > On Thu, Sep 27, 2012 at 8:56 PM, Josip Rodin > wrote: >> >> On Thu, Sep 27, 2012 at 09:04:26AM +0200, Josip Rodin wrote: >> > On Mon, Sep 24, 2012 at 11:30:28AM +0200, Nestor Lopez Casado wrote: >> > > Josip, this is a different issue from the one addressed with the >> > > patch. >> > > >> > > 1) Can you try it on a 3.2 kernel ? >> > >> > I can try that too, I'll let you know how it went. >> >> Same thing, it doesn't work. >> >> -- >> 2. That which causes joy or happiness. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] vmevent: Implement pressure attribute
On Mon, Oct 08, 2012 at 06:42:16PM -0700, John Stultz wrote: > On 10/08/2012 02:46 AM, Mel Gorman wrote: > >On Sun, Oct 07, 2012 at 01:14:17AM -0700, Anton Vorontsov wrote: > >>And here we just try to let userland to assist, userland can tell "oh, > >>don't bother with swapping or draining caches, I can just free some > >>memory". > >> > >>Quite interesting, this also very much resembles volatile mmap ranges > >>(i.e. the work that John Stultz is leading in parallel). > >> > >Agreed. I haven't been paying close attention to those patches but it > >seems to me that one possiblity is that a listener for a vmevent would > >set volatile ranges in response. > > I don't have too much to comment on the rest of this mail, but just > wanted to pipe in here, as the volatile ranges have caused some > confusion. > > While your suggestion would be possible, with volatile ranges, I've > been promoting a more hands off-approach from the application > perspective, where the application always would mark data that could > be regenerated as volatile, unmarking it when accessing it. > > This way the application doesn't need to be responsive to memory > pressure, the kernel just takes what it needs from what the > application made available. > > Only when the application needs the data again, would it mark it > non-volatile (or alternatively with the new SIGBUS semantics, access > the purged volatile data and catch a SIGBUS), find the data was > purged and regenerate it. > Ok understood. > That said, hybrid approaches like you suggested would be possible, > but at a certain point, if we're waiting for a notification to take > action, it might be better just to directly free that memory, rather > then just setting it as volatile, and leaving it to the kernel then > reclaim it for you. > That's fine. I did not mean to suggest that volatile and vmevents on memory pressure should be related or depending on each other in any way. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
At 10/09/2012 06:04 PM, David Rientjes Wrote: > On Tue, 9 Oct 2012, Tang Chen wrote: > Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this should be called at CPU_DYING level and migrate_tasks() still sees a valid cpu. >> >> As Wen said below, nid is now set to -1 when cpu is hotremoved. >> I reproduce this problem in this situation: >> >> all cpus are online, and hot remove a system board directorily, without >> offlining any cpu. >> >> As a result, the removed cpu's nid is set to -1, and this causes >> problems. >> > > Let's add Andrew to the cc list then, because I'm nacking > cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch in the -mm > tree for this reason. > > We can only clear a cpu-to-node mapping when the cpu is completely > offline, not before or during the CPU_DYING stage. Kernel code, such as I clear cpu-to-node mapping when the cpu is hotremoved. If the cpu is onlined, it will be offlined before clearing cpu-to-node mapping. Here is the code in driver/acpi/processor_driver.c: = static int acpi_processor_handle_eject(struct acpi_processor *pr) { if (cpu_online(pr->id)) cpu_down(pr->id); <== cpu is offlined here. arch_unregister_cpu(pr->id); acpi_unmap_lsapic(pr->id); <== I clear the mapping here. return (0); } = The real problem is that: we don't migrate this task to another cpu when the cpu is offlined. I guess this task is not in running state, and it is not in the cpu's runqueue. Thanks Wen Congyang > the sched code that you are now trying to "fix", depends on this mapping > to work correctly; obviously no audit was done of cpu hotplug code > depending on it before the patch was proposed. > > I say "fix" because even this workaround isn't a good solution since it > would be much better to pick another cpu on the same node as the offlining > cpu for the runqueue before falling back to the set of all allowed nodes. > We lose all NUMA affinity information with that patch. There's no reason > why we shouldn't know the node of a cpu that is being offlined. > > So nack to cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch. > After it's removed because it's buggy, this "fix" will no longer be > necessary. > This patch is try to fix a bug: the kernel will be panicked after removing a node. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] umc-bus.c: fix usage of device_trylock
Hi all. I've not received any feedback about this patch, so I'm resending just to check if someone is going to take care of it. The patch fixes the usage of device_trylock inside the driver umc-bus.c: device_trylock has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Best regards, Claudio Subject: umc-bus.c: fix usage of device_trylock From: Claudio Scordino Fix usage of device_trylock. It has the same semantics of mutex_trylock, so it returns 1 if the lock has been acquired successfully. Signed-off-by: Claudio Scordino Signed-off-by: Bruno Morelli --- drivers/uwb/umc-bus.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/uwb/umc-bus.c b/drivers/uwb/umc-bus.c index 82a84d5..5c5b3fc 100644 --- a/drivers/uwb/umc-bus.c +++ b/drivers/uwb/umc-bus.c @@ -63,7 +63,7 @@ int umc_controller_reset(struct umc_dev *umc) struct device *parent = umc->dev.parent; int ret = 0; - if (device_trylock(parent)) + if (!device_trylock(parent)) return -EAGAIN; ret = device_for_each_child(parent, parent, umc_bus_pre_reset_helper); if (ret >= 0) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/