RE: drivers/mfd/tps65090.c: duplicated TPS65090_INT_STS tests
Thanks for catching typo.
Plz push a patch with fix.
Thanks,
Venu
-Original Message-
From: Fengguang Wu [mailto:fengguang...@intel.com]
Sent: Saturday, July 28, 2012 6:05 PM
To: Venu Byravarasu
Cc: Samuel Ortiz; Axel Lin; kernel-janit...@vger.kernel.org; LKML
Subject: drivers/mfd/tps65090.c: duplicated TPS65090_INT_STS tests
Hi Venu,
Is this coccinelle warning a trivial one, or indicates some copypaste
error? It's introduced by commit 3c33be06 (mfd: Add support for
TPS65090).
drivers/mfd/tps65090.c:239:5-30: duplicated argument to or ||
vim +239 drivers/mfd/tps65090.c
236
237static bool is_volatile_reg(struct device *dev, unsigned int
reg)
238{
239if ((reg == TPS65090_INT_STS) || (reg ==
TPS65090_INT_STS))
240return true;
241else
242return false;
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu w...@linux.intel.com Intel Corporation
--
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: [REPOST #3 PATCH v2] Input: atkbd - make repeat period more accurate.
On Thu, Jul 26, 2012 at 11:15:24AM -0400, George Spelvin wrote: Thanks for the response! I'd been checking mailing list archive sites to see if my submissions were making it out to the list. In addition to a slightly inaccurate lookup table, the old code would round up to the next repeat period. E.g. to get a period of 9/60 = 0.15 seconds, you had to ask for no more than 149 ms; if you asked for 150, it would round up to 167. This works as intended - it was designed to never have faster than requested. The old code didn't do *that* correctly, either. If you asked for 370 or 470 ms, it would give you 366.66 or 466.66 ms, respectively. I can amend the code to do the same, but this leads to some questions: Should the reported values be rounded down so that setting the repeat period to the reported value is always safe? Or should it allow rounding down by = 0.5 ms, so that asking for 117 ms will give you 166.66 without complaint? And what do you do if the requested delay or period is longer than can be supported (1000 and 500 ms, respectively)? Finally, is this rounding documented clearly anywhere? I thought rounding to nearest gave the least surprising results for someone using various slightly-inaccurate lists of the repeatable keyboard rates. Including, particularly, the previous code's values. I do not believe rounding is documented anywhere; the rates are mentioned in kbdrate manpage. Frankly at this time I'd just leave this all as is since there were no complaints from users about repeat rates on keyboards and most clients (X) implement their own, software-based, rate control. Signed-off-by: George Spelvin li...@horizon.com I am sorry but I have to ask - is this your real name? Well, it's meant to be an obvious pen name, I do not think it is that obvious to anyone who is not living in the US. The only reason I paid attention to the name is I recognized your e-mail from LKML as one never signing your name. but since I use it consistently and live in a common-law country, it's a real as any other. I am not sure whether common law countries allow anyone pick any name of their choosing and use it as their legal name; I know that we had to refuse submission from another developer wishing to use a pen name (HDAPS driver). One possible bug I observed in the code that calls this: Users of the KDKBDREP ioctl seem to assume that it returns the actual values set, but I'm not sure it really works that way; I don't think the command to change the parameters makes its way through the event queue and atkbd's schedule_delayed_work() to actually set dev-rep[] to the rounded values before kbd_rate_helper returns them to userspace. If desired, the fix that's most obvious to me would be to split this function in two: perform the conversion to a command byte synchronously, and only defer the actual ps2_command(). Yes, I agree, this is a problem. I was trying to start simple, since this is a separate issue, but I could make an attempt at this fix, too. The *big* problsm is what if there's a peripheral that actually requires a USB transaction to set the rate before being able to determine what the rounded rate to report is, it'll require a major overhaul of the in-kernel interfaces. Luckily we are using software based repeat on USB (and most other input devices). Another thing that would be possible is supporting an arbitrary repeat rate, as long as it's slower than the maximum autorepeat rate. Just set the hardware repeat slightly faster than the software repeat rate and buffer the autorepeat reports until the correct software-repeat time. I don't know if it's worth bothering, though. No, I do not think it's worth it as we have software-based repeat implementation that allows arbitrary rates. Thanks. -- Dmitry -- 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] MMC/omap_hsmmc: handle failure of regulator_get better.
On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayak rna...@ti.com wrote:
On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
1/ if regulator_get fails, return an error. This is important
if it failed with EPROBE_DEFER, as the probe needs to be
deferred.
2/ Don't set .set_power until the regulator has been found, or
the deferred probe will not bother calling omap_hsmmc_reg_get().
I am not very sure, but aren't the data structures re-allocated on a
re-probe (after it was deferred) causing .set_power to be lost anyway?
Apparently not - as I needed to make that change before the re-probe would
work.
Looking at the code to remind myself:
#define mmc_slot(host) (host-pdata-slots[host-slot_id])
so the slot is inside the platform data which is allocated in
omap_hsmmc_init_one, called from omap_hsmmc_init.
This is all prior to the probing of the device.
So no: once set_power is set, it stays set.
Thanks,
NeilBrown
Signed-off-by: NeilBrownne...@suse.de
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 389a3ee..f052c29 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -299,12 +299,12 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
struct regulator *reg;
int ocr_value = 0;
- mmc_slot(host).set_power = omap_hsmmc_set_power;
-
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
+ return PTR_ERR(reg);
} else {
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
signature.asc
Description: PGP signature
Re: [PATCH V4 3/3] virtio-blk: Add bio-based IO path for virtio-blk
Hello Sasha, On 07/28/2012 02:35 PM, Sasha Levin wrote: On 07/28/2012 04:21 AM, Asias He wrote: This patch introduces bio-based IO path for virtio-blk. Compared to request-based IO path, bio-based IO path uses driver provided -make_request_fn() method to bypasses the IO scheduler. It handles the bio to device directly without allocating a request in block layer. This reduces the IO path in guest kernel to achieve high IOPS and lower latency. The downside is that guest can not use the IO scheduler to merge and sort requests. However, this is not a big problem if the backend disk in host side uses faster disk device. When the bio-based IO path is not enabled, virtio-blk still uses the original request-based IO path, no performance difference is observed. Performance evaluation: - 1) Fio test is performed in a 8 vcpu guest with ramdisk based guest using kvm tool. Short version: With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%, 17%, 21%, 16% Long version: With bio-based IO path: seq-read : io=2048.0MB, bw=116996KB/s, iops=233991 , runt= 17925msec seq-write : io=2048.0MB, bw=100829KB/s, iops=201658 , runt= 20799msec rand-read : io=3095.7MB, bw=112134KB/s, iops=224268 , runt= 28269msec rand-write: io=3095.7MB, bw=96198KB/s, iops=192396 , runt= 32952msec clat (usec): min=0 , max=2631.6K, avg=58716.99, stdev=191377.30 clat (usec): min=0 , max=1753.2K, avg=66423.25, stdev=81774.35 clat (usec): min=0 , max=2915.5K, avg=61685.70, stdev=120598.39 clat (usec): min=0 , max=1933.4K, avg=76935.12, stdev=96603.45 cpu : usr=74.08%, sys=703.84%, ctx=29661403, majf=21354, minf=22460954 cpu : usr=70.92%, sys=702.81%, ctx=77219828, majf=13980, minf=27713137 cpu : usr=72.23%, sys=695.37%, ctx=88081059, majf=18475, minf=28177648 cpu : usr=69.69%, sys=654.13%, ctx=145476035, majf=15867, minf=26176375 With request-based IO path: seq-read : io=2048.0MB, bw=91074KB/s, iops=182147 , runt= 23027msec seq-write : io=2048.0MB, bw=80725KB/s, iops=161449 , runt= 25979msec rand-read : io=3095.7MB, bw=92106KB/s, iops=184211 , runt= 34416msec rand-write: io=3095.7MB, bw=82815KB/s, iops=165630 , runt= 38277msec clat (usec): min=0 , max=1932.4K, avg=77824.17, stdev=170339.49 clat (usec): min=0 , max=2510.2K, avg=78023.96, stdev=146949.15 clat (usec): min=0 , max=3037.2K, avg=74746.53, stdev=128498.27 clat (usec): min=0 , max=1363.4K, avg=89830.75, stdev=114279.68 cpu : usr=53.28%, sys=724.19%, ctx=37988895, majf=17531, minf=23577622 cpu : usr=49.03%, sys=633.20%, ctx=205935380, majf=18197, minf=27288959 cpu : usr=55.78%, sys=722.40%, ctx=101525058, majf=19273, minf=28067082 cpu : usr=56.55%, sys=690.83%, ctx=228205022, majf=18039, minf=26551985 2) Fio test is performed in a 8 vcpu guest with Fusion-IO based guest using kvm tool. Short version: With bio-based IO path, sequential read/write, random read/write IOPS boost : 11%, 11%, 13%, 10% Latency improvement: 10%, 10%, 12%, 10% Long Version: With bio-based IO path: read : io=2048.0MB, bw=58920KB/s, iops=117840 , runt= 35593msec write: io=2048.0MB, bw=64308KB/s, iops=128616 , runt= 32611msec read : io=3095.7MB, bw=59633KB/s, iops=119266 , runt= 53157msec write: io=3095.7MB, bw=62993KB/s, iops=125985 , runt= 50322msec clat (usec): min=0 , max=1284.3K, avg=128109.01, stdev=71513.29 clat (usec): min=94 , max=962339 , avg=116832.95, stdev=65836.80 clat (usec): min=0 , max=1846.6K, avg=128509.99, stdev=89575.07 clat (usec): min=0 , max=2256.4K, avg=121361.84, stdev=82747.25 cpu : usr=56.79%, sys=421.70%, ctx=147335118, majf=21080, minf=19852517 cpu : usr=61.81%, sys=455.53%, ctx=143269950, majf=16027, minf=24800604 cpu : usr=63.10%, sys=455.38%, ctx=178373538, majf=16958, minf=24822612 cpu : usr=62.04%, sys=453.58%, ctx=226902362, majf=16089, minf=23278105 With request-based IO path: read : io=2048.0MB, bw=52896KB/s, iops=105791 , runt= 39647msec write: io=2048.0MB, bw=57856KB/s, iops=115711 , runt= 36248msec read : io=3095.7MB, bw=52387KB/s, iops=104773 , runt= 60510msec write: io=3095.7MB, bw=57310KB/s, iops=114619 , runt= 55312msec clat (usec): min=0 , max=1532.6K, avg=142085.62, stdev=109196.84 clat (usec): min=0 , max=1487.4K, avg=129110.71, stdev=114973.64 clat (usec): min=0 , max=1388.6K, avg=145049.22, stdev=107232.55 clat (usec): min=0 , max=1465.9K, avg=133585.67, stdev=110322.95 cpu : usr=44.08%, sys=590.71%, ctx=451812322, majf=14841, minf=17648641 cpu : usr=48.73%, sys=610.78%, ctx=418953997, majf=22164, minf=26850689 cpu : usr=45.58%, sys=581.16%, ctx=714079216, majf=21497, minf=22558223 cpu : usr=48.40%, sys=599.65%, ctx=656089423, majf=16393, minf=23824409 What are the cases where we'll see a performance degradation with using the bio path? Could we measure
[PATCH v3] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. But if there are some HighMem pages in table-sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) may return NULL value. This will cause QEMU exit when virtqueue_map_sg is called in QEMU because an invalid GPA is passed by virtqueue. Two solutions are discussed here: http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/00675.html Finally, value assignment approach was adopted because: Value assignment creates a well-formed scatterlist, because the termination marker in source sg_list has been set in blk_rq_map_sg(). The last entry of the source sg_list is just copied to the the last entry in destination list. Note that, for now, virtio_ring does not care about the form of the scatterlist and simply processes the first out_num + in_num consecutive elements of the sg[] array. I have tested the patch on my workstation. QEMU would not crash any more. Cc: sta...@vger.kernel.org # 3.4: 4fe74b1: [SCSI] virtio-scsi: SCSI driver Signed-off-by: Wang Sen senw...@linux.vnet.ibm.com --- drivers/scsi/virtio_scsi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 1b38431..6661610 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -198,7 +198,7 @@ static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx, int i; for_each_sg(table-sgl, sg_elem, table-nents, i) - sg_set_buf(sg[idx++], sg_virt(sg_elem), sg_elem-length); + sg[idx++] = *sg_elem; *p_idx = idx; } -- 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: [net-next RFC V5 3/5] virtio: intorduce an API to set affinity for a virtqueue
Il 29/07/2012 22:40, Michael S. Tsirkin ha scritto: Did you set the affinity manually in your experiments, or perhaps there is a difference between scsi and networking... (interrupt mitigation?) You need to run irqbalancer in guest to make it actually work. Do you? Yes, of course, now on to debugging that one. I just wanted to ask before the weekend if I was missing something as obvious as that. 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: kernel BUG at fs/buffer.c:2886! Linux 3.5.0
On Sat, Jul 28, 2012 at 12:18:30AM +0200, Vincent ETIENNE wrote: Hello Get this on first write made ( by deliver sending mail to inform of the restart of services ) Home partition (the one receiving the mail) is based on ocfs2 created from drbd block device in primary/primary mode These drbd devices are based on lvm. system is running linux-3.5.0, identical symptom with linux 3.3 and 3.2 but working with linux 3.0 kernel reproduced on two machines ( so different hardware involved on this one software md raid on SATA, on second one areca hardware raid card ) but the 2 machines are the one sharing this partition ( so share the same data ) Hmm. Any chance you can bisect this further? Jul 27 23:41:41 jupiter2 kernel: [ 351.169213] [ cut here ] Jul 27 23:41:41 jupiter2 kernel: [ 351.169261] kernel BUG at fs/buffer.c:2886! This is: BUG_ON(!buffer_mapped(bh)); in submit_bh(). Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] Call Trace: Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81327546] ? ocfs2_read_blocks+0x176/0x6c0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8114e541] ? T.1552+0x91/0x2b0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81346ad0] ? ocfs2_find_actor+0x120/0x120 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813464f7] ? ocfs2_read_inode_block_full+0x37/0x60 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813964ff] ? ocfs2_fast_symlink_readpage+0x2f/0x160 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8585] ? do_read_cache_page+0x85/0x180 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813964d0] ? ocfs2_fill_super+0x2500/0x2500 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [86d9] ? read_cache_page+0x9/0x20 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115c705] ? page_getlink+0x25/0x80 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115c77b] ? page_follow_link_light+0x1b/0x30 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8116099b] ? path_lookupat+0x38b/0x720 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81160d5c] ? do_path_lookup+0x2c/0xd0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81346f31] ? ocfs2_inode_revalidate+0x71/0x160 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81161c0c] ? user_path_at_empty+0x5c/0xb0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8106714a] ? do_page_fault+0x1aa/0x3c0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81156f2d] ? cp_new_stat+0x10d/0x120 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81157021] ? vfs_fstatat+0x41/0x80 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115715f] ? sys_newstat+0x1f/0x50 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [817ecee2] ? system_call_fastpath+0x16/0x1b This stack trace is from 3.5, because of the location of the BUG. The call path in the trace suggests the code added by Al's ea022d, but you say it breaks in 3.2 and 3.3 as well. Can you give me a trace from 3.2? Joel -- Life's Little Instruction Book #139 Never deprive someone of hope; it might be all they have. http://www.jlbec.org/ jl...@evilplan.org -- 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] power_supply: Add new power supply properties CHARGE_CURRENT/VOLTAGE_MAX
There are different types of chargers avalibale like AC, Solar, USB, etc..
Even in USB we have different types SDP/DCP/CDP/ACA and all these
chargers have different o/p ratings. For example SDP supports only 500mA of
charge current whereas AC charger can support upto 8A or more.
Similarly batteries also come with charge current and voltage ratings and
these ratings vary depending on its capacity and the technology used.
This patch adds two new power supply properties CONSTANT_CHARGE_CURRENT_MAX and
CONSTANT_CHARGE_CURRENT_MAX.
Signed-off-by: Ramakrishna Pallala ramakrishna.pall...@intel.com
---
Documentation/power/power_supply_class.txt |4
drivers/power/power_supply_sysfs.c |2 ++
include/linux/power_supply.h |2 ++
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 272b122..db11122 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -115,8 +115,12 @@ be negative; there is no empty or full value. It is only
useful for
relative, time-based measurements.
CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
+CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
+power supply object.
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
+CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
+power supply object.
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 797639e..f10a402 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -161,7 +161,9 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(charge_avg),
POWER_SUPPLY_ATTR(charge_counter),
POWER_SUPPLY_ATTR(constant_charge_current),
+ POWER_SUPPLY_ATTR(constant_charge_current_max),
POWER_SUPPLY_ATTR(constant_charge_voltage),
+ POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index e7edcb3..0c40c62 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -111,7 +111,9 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CHARGE_AVG,
POWER_SUPPLY_PROP_CHARGE_COUNTER,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
--
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/
[GIT] security subsystem bugfixes
Please pull these fixes for your curren tree. The following changes since commit f7da9cdf45cbbad5029d4858dcbc0134e06084ed: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/net are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Al Viro (1): selinux: fix selinux_inode_setxattr oops Alan Cox (1): smack: off by one error David Howells (1): KEYS: linux/key-type.h needs linux/errno.h include/linux/key-type.h |1 + security/selinux/hooks.c | 15 ++- security/smack/smackfs.c |8 3 files changed, 15 insertions(+), 9 deletions(-) -- 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] MMC/omap_hsmmc: handle failure of regulator_get better.
On Monday 30 July 2012 11:54 AM, NeilBrown wrote:
On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayakrna...@ti.com wrote:
On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
1/ if regulator_get fails, return an error. This is important
if it failed with EPROBE_DEFER, as the probe needs to be
deferred.
2/ Don't set .set_power until the regulator has been found, or
the deferred probe will not bother calling omap_hsmmc_reg_get().
I am not very sure, but aren't the data structures re-allocated on a
re-probe (after it was deferred) causing .set_power to be lost anyway?
Apparently not - as I needed to make that change before the re-probe would
work.
Looking at the code to remind myself:
#define mmc_slot(host) (host-pdata-slots[host-slot_id])
so the slot is inside the platform data which is allocated in
omap_hsmmc_init_one, called from omap_hsmmc_init.
This is all prior to the probing of the device.
So no: once set_power is set, it stays set.
Thanks for the explanation, makes sense.
Acked-by: Rajendra Nayak rna...@ti.com
Btw, is the support for re-probe/deferred probe already merged
now? or are you testing this with some out of tree patches.
Thanks,
NeilBrown
Signed-off-by: NeilBrownne...@suse.de
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 389a3ee..f052c29 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -299,12 +299,12 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
struct regulator *reg;
int ocr_value = 0;
- mmc_slot(host).set_power = omap_hsmmc_set_power;
-
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
+ return PTR_ERR(reg);
} else {
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
--
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] drivers: net: irda: bfin_sir: fix compile error
From: Sonic Zhang sonic.zh...@analog.com Bit IREN is replaced by UMOD_IRDA and UMOD_MASK since blackfin 60x added, but this driver didn't update which will cause bfin_sir build error: drivers/net/irda/bfin_sir.c:161:9: error: 'IREN' undeclared (first use in this function) drivers/net/irda/bfin_sir.c:435:18: error: 'IREN' undeclared (first use in this function) drivers/net/irda/bfin_sir.c:521:11: error: 'IREN' undeclared (first use in this function) This patch fix it. Signed-off-by: Sonic Zhang sonic.zh...@analog.com Signed-off-by: Bob Liu lliu...@gmail.com --- drivers/net/irda/bfin_sir.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/irda/bfin_sir.c b/drivers/net/irda/bfin_sir.c index a561ae4..c6a0299 100644 --- a/drivers/net/irda/bfin_sir.c +++ b/drivers/net/irda/bfin_sir.c @@ -158,7 +158,7 @@ static int bfin_sir_set_speed(struct bfin_sir_port *port, int speed) /* If not add the 'RPOLC', we can't catch the receive interrupt. * It's related with the HW layout and the IR transiver. */ - val |= IREN | RPOLC; + val |= UMOD_IRDA | RPOLC; UART_PUT_GCTL(port, val); return ret; } @@ -432,7 +432,7 @@ static void bfin_sir_shutdown(struct bfin_sir_port *port, struct net_device *dev bfin_sir_stop_rx(port); val = UART_GET_GCTL(port); - val = ~(UCEN | IREN | RPOLC); + val = ~(UCEN | UMOD_MASK | RPOLC); UART_PUT_GCTL(port, val); #ifdef CONFIG_SIR_BFIN_DMA @@ -518,10 +518,10 @@ static void bfin_sir_send_work(struct work_struct *work) * reset all the UART. */ val = UART_GET_GCTL(port); - val = ~(IREN | RPOLC); + val = ~(UMOD_MASK | RPOLC); UART_PUT_GCTL(port, val); SSYNC(); - val |= IREN | RPOLC; + val |= UMOD_IRDA | RPOLC; UART_PUT_GCTL(port, val); SSYNC(); /* bfin_sir_set_speed(port, self-speed); */ -- 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] MMC/omap_hsmmc: handle failure of regulator_get better.
On Mon, 30 Jul 2012 12:07:09 +0530 Rajendra Nayak rna...@ti.com wrote:
On Monday 30 July 2012 11:54 AM, NeilBrown wrote:
On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayakrna...@ti.com wrote:
On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
1/ if regulator_get fails, return an error. This is important
if it failed with EPROBE_DEFER, as the probe needs to be
deferred.
2/ Don't set .set_power until the regulator has been found, or
the deferred probe will not bother calling omap_hsmmc_reg_get().
I am not very sure, but aren't the data structures re-allocated on a
re-probe (after it was deferred) causing .set_power to be lost anyway?
Apparently not - as I needed to make that change before the re-probe would
work.
Looking at the code to remind myself:
#define mmc_slot(host) (host-pdata-slots[host-slot_id])
so the slot is inside the platform data which is allocated in
omap_hsmmc_init_one, called from omap_hsmmc_init.
This is all prior to the probing of the device.
So no: once set_power is set, it stays set.
Thanks for the explanation, makes sense.
Acked-by: Rajendra Nayak rna...@ti.com
Thanks.
Btw, is the support for re-probe/deferred probe already merged
now? or are you testing this with some out of tree patches.
deferred-probe works in 3.5.
commit 04bf30115f4ba2beda1efb6cfbae49cdc757f3a9
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Sun Mar 11 13:07:56 2012 +
regulator: Support driver probe deferral
makes it work for regulators.
commit d1c3414c2a9d10ef7f0f7665f5d2947cd088c093
Author: Grant Likely grant.lik...@secretlab.ca
Date: Mon Mar 5 08:47:41 2012 -0700
drivercore: Add driver probe deferral mechanism
added the basic mechanism.
GPIOs are also supported in 3.6-rc thanks to
commit e93545763021988def06fbda28fe5da133589a96
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Mon Jul 9 12:22:56 2012 +0100
gpiolib: Defer failed gpio requests by default
so the omap_hsmmc_late_init() stuff can probably be removed, though I haven't
tried and there might be some subtlety in there that isn't covered by
EPROBE_DEFER
NeilBrown
Thanks,
NeilBrown
Signed-off-by: NeilBrownne...@suse.de
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 389a3ee..f052c29 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -299,12 +299,12 @@ static int omap_hsmmc_reg_get(struct
omap_hsmmc_host *host)
struct regulator *reg;
int ocr_value = 0;
- mmc_slot(host).set_power = omap_hsmmc_set_power;
-
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
+ return PTR_ERR(reg);
} else {
+ mmc_slot(host).set_power = omap_hsmmc_set_power;
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
signature.asc
Description: PGP signature
Re: [Bisected] commit 71574865 (vfs: do_last(): common slow lookup) breaks CUPS printing
On Sat, Jul 28, 2012 at 12:43:16PM +0200, Markus Trippelsdorf wrote:
Printing with CUPS is broken on the current git tree. Whenever I print a page
the job just sits in the CUPS queue showing processing. But it never reaches
the printer. (My CUPS version is 1.5.2. Filesystem is xfs.)
I've bisected this issue to:
commit 7157486541bffc0dfec912e21ae639b029dae3d3
Author: Miklos Szeredi mszer...@suse.cz
Date: Tue Jun 5 15:10:14 2012 +0200
vfs: do_last(): common slow lookup
Make the slow lookup part of O_CREAT and non-O_CREAT opens common.
This allows atomic_open to be hooked into the slow lookup part.
Signed-off-by: Miklos Szeredi mszer...@suse.cz
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
Hmm... Looking at that commit, we seem to have one change introduced by it.
Namely,
behaviour of open(path, O_EXCL) (note that O_EXCL without O_CREAT is an
undefined
by POSIX and makes no damn sense anyway).
Could you try the patch below, just to make sure that I'm not misreading the
situation? If that's really happening that way, it should spew a warning,
restore the old behaviour by removing that stray O_EXCL and, if it comes
from open(2)/openat(2), print the syscall arguments.
We'll need to restore the original behaviour anyway, undefined or no undefined,
but if we really catch CUPS doing that, we ought to report that as a bug to
whatever bugtracking system CUPS uses; at the very least, it's a portability
headache waiting to happen.
diff --git a/fs/open.c b/fs/open.c
index 8d2c897..20a3ceb 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -893,6 +893,9 @@ static inline int build_open_flags(int flags, umode_t mode,
struct open_flags *o
op-intent |= LOOKUP_CREATE;
if (flags O_EXCL)
op-intent |= LOOKUP_EXCL;
+ } else {
+ WARN_ON(flags O_EXCL);
+ op-open_flag = ~O_EXCL;
}
if (flags O_DIRECTORY)
@@ -943,6 +946,10 @@ long do_sys_open(int dfd, const char __user *filename, int
flags, umode_t mode)
int fd = PTR_ERR(tmp);
if (!IS_ERR(tmp)) {
+ if ((flags O_EXCL) !(flags O_CREAT)) {
+ printk(KERN_ERR WTF: open(\%s\, %d), filename,
flags);
+ }
+
fd = get_unused_fd_flags(flags);
if (fd = 0) {
struct file *f = do_filp_open(dfd, tmp, op, lookup);
--
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 05/18] ASoC: Ux500: Enable ux500 MSP driver for Device Tree
On 29/07/12 21:42, Mark Brown wrote: On Fri, Jul 27, 2012 at 01:45:49PM +0100, Lee Jones wrote: + if (of_get_property(np, stericsson,use-pinctrl, NULL)) + msp-use_pinctrl = true; + else + msp-use_pinctrl = false; I don't recall seeing any response to my query about this on the first iteration. Please don't just ignore review comments. It wasn't intentional. I must have missed it before. This doesn't seem particularly sane... why is this conditional? It's conditional because only MSP1 and MSP3 have pinctrl support. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 10/18] ARM: ux500: Enable HIGHMEM on all mop500 platforms
On 29/07/12 21:45, Mark Brown wrote: On Fri, Jul 27, 2012 at 01:45:54PM +0100, Lee Jones wrote: The current kernel commandline for ux500 based devices includes hard-coded allocations for things like mali and hwmem, which actually run over lowmem. Here we enable highmem in order to avoid memory corruption errors. This appears to be at best tangentially related to the rest of the series, are you sure it shouldn't be being sent separately as a bugfix? Yes, it should. I'll shift it. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] GPIO changes for v3.6
On Thu, 26 Jul 2012 00:48:57 +0200 Linus Walleij linus.wall...@linaro.org
wrote:
Hi Linus,
in Grants absence, these are my queued and -next-tested changes
for v3.6, please pull them in. Grants merge branch prior to his
absence was merged in as a base for this patch series.
The following is the same information as found in the tag:
GPIO changes for v3.6:
- New driver for AMD-8111 southbridge GPIOs
- New driver for Wolfson Micro Arizona devices
- Propagate device tree parse errors
- Probe deferral finalizations - all expected calls to
GPIO will now hopefully request deferral where apropriate
- Misc updates to TCA6424, WM8994, LPC32xx, PCF857x, Samsung
MXC, OMAP and PCA953X drivers.
..
Mark Brown (5):
gpiolib: Defer failed gpio requests by default
Hi,
this doesn't look quite right to me.
it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER
which isn't right (an invalid gpio number will never become valid).
If a driver happened to use gpio_request to check the validity of the gpio
rather than doing it itself, it would defer the probe, rather than assume
that the GPIO doesn't exist.
I would suggest the following. Reasonable?
NeilBrown
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index de0213c..259233b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1186,13 +1186,14 @@ int gpio_request(unsigned gpio, const char *label)
{
struct gpio_desc*desc;
struct gpio_chip*chip;
- int status = -EPROBE_DEFER;
+ int status = -EINVAL;
unsigned long flags;
spin_lock_irqsave(gpio_lock, flags);
if (!gpio_is_valid(gpio))
goto done;
+ status = -EPROBE_DEFER;
desc = gpio_desc[gpio];
chip = desc-chip;
if (chip == NULL)
signature.asc
Description: PGP signature
Re: [PATCH] pwm_backlight: Add device tree support for Low Threshold Brightness
On Wed, Jul 25, 2012 at 05:54:02PM +0530, Philip, Avinash wrote:
Low Threshold Brightness should be configured to have a linear relation
in brightness scale. This patch adds device tree support for low
threshold brightness as optional one for pwm_backlight.
I think this should be more explicit as to why this is required, perhaps
something like this:
Some backlights perform poorly when driven by a PWM with a short
duty-cycle. For such devices, the low threshold can be used to
specify a lower bound for the duty-cycle and should be chosen to
exclude the problematic range.
This patch adds support for an optional low-threshold-brightness
property.
Perhaps a similar explanation should be given somewhere else instead of
just the changelog. It took me some time to understand what exactly this
low threshold means and I think it'd make sense to write this kind of
information down somewhere. I'll see if I can make time to add a bit of
documentation somewhere below Documentation/backlight perhaps.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 1e4fc72... 5c54380... M
Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
:100644 100644 995f016... 4965408... Mdrivers/video/backlight/pwm_bl.c
.../bindings/video/backlight/pwm-backlight.txt | 21
drivers/video/backlight/pwm_bl.c |5
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..5c54380 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -14,6 +14,8 @@ Required properties:
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
pwms property (see PWM binding[0])
+ - low_threshold_brightness: brightness threshold low level. (get linear
+ scales in brightness in low end of brightness levels)
The convention is to use dashes, not underscores, in device tree
property names, so this should be low-threshold-brightness. I'd also
omit the comment in parentheses because the DT binding document
shouldn't specify any particular use-case. However I think it'd make
sense to add some information about the number space of the low
threshold value.
Maybe we should also rethink how the low threshold is handled in cases
where the brightness levels are used. I'm not sure it makes sense to
specify the low threshold as a value relative to the range given by the
levels. Perhaps it is more meaningful to specify it as relative to the
period/duty-cycle.
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -26,3 +28,22 @@ Example:
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
};
+
+Example for brightness_threshold_level:
+
+ backlight {
+ compatible = pwm-backlight;
+ pwms = pwm 0 5;
+
+ brightness-levels = 0 4 8 16 32 64 128 255;
+ default-brightness-level = 6;
+ low_threshold_brightness = 50;
+ };
+};
I think you can just merge the low-threshold-brightness with the
previous example.
+Note:
+Low threshold support is required to have linear brightness scale from
+0 to max. For some panels, backlight absent on low end of brightness
+scale. So support for Low Threshold been required. So that the scale of
+brightness changed from Low Threshold to Max in scales defined in
+brightness-levels. In this example 20% maximum brightness scale should
+be required to turn on panel backlight.
I think this kind of documentation doesn't belong in the device tree
binding. I'll work something like that into the proper documentation.
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
index 995f016..4965408 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -143,6 +143,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
data-dft_brightness = value;
data-max_brightness--;
+
+ ret = of_property_read_u32(node, low_threshold_brightness,
+value);
+ if (!ret)
+ data-lth_brightness = value;
}
This obviously should also be low-threshold-brightness.
Thierry
pgpY2d1iagQwa.pgp
Description: PGP signature
Re: drbd-8.3 fixes
On 07/24/2012 04:24 PM, Philipp Reisner wrote: Hi Jens, Please consider to pull these changes for the 3.6 merge window. I did not found a for-3.6/drivers branch, so I based the patches on the 3.5 release. Best, Phil The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92: Linux 3.5 (2012-07-21 13:58:29 -0700) are available in the git repository at: git://git.drbd.org/linux-drbd.git for-jens for you to fetch changes up to a73ff3231df59a4b92ccd0dd4e73897c5822489b: drbd: announce FLUSH/FUA capability to upper layers (2012-07-24 15:14:28 +0200) Lars Ellenberg (10): drbd: cleanup, remove two unused global flags drbd: differentiate between normal and forced detach drbd: report congestion if we are waiting for some userland callback drbd: reset congestion information before reporting it in /proc/drbd drbd: do not reset rs_pending_cnt too early drbd: call local-io-error handler early drbd: fix potential access after free drbd: flush drbd work queue before invalidate/invalidate remote drbd: fix max_bio_size to be unsigned drbd: announce FLUSH/FUA capability to upper layers drivers/block/drbd/drbd_actlog.c |8 +++-- drivers/block/drbd/drbd_bitmap.c |4 +-- drivers/block/drbd/drbd_int.h | 44 drivers/block/drbd/drbd_main.c | 65 +++- drivers/block/drbd/drbd_nl.c | 36 +++- drivers/block/drbd/drbd_proc.c |3 ++ drivers/block/drbd/drbd_receiver.c | 38 +++-- drivers/block/drbd/drbd_req.c |9 +++-- drivers/block/drbd/drbd_worker.c | 12 ++- 9 files changed, 153 insertions(+), 66 deletions(-) Pulled, thanks. -- Jens Axboe -- 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: [Xen-devel] [PATCH 1/2] xen/swiotlb: If iommu=soft was not passed in on 4GB, don't turn it on.
On 27.07.12 at 19:54, Konrad Rzeszutek Wilk kon...@darnok.org wrote:
On Fri, Jul 27, 2012 at 08:27:39AM +0100, Jan Beulich wrote:
On 26.07.12 at 22:43, Konrad Rzeszutek Wilk konrad.w...@oracle.com
wrote:
+ /* Check if the user supplied the e820_hole parameter
+ * which would create a machine looking E820 region. */
+ for (i = 0; i e820.nr_map; i++) {
+ if ((e820.map[i].type == E820_ACPI) ||
+ (e820.map[i].type == E820_NVS))
+ return true;
Tying this decision to the presence of ACPI regions in E820 is
problematic for two reasons imo: For one, it precludes cleaning
up this (bogus!) construct where it gets produced (PV DomU-s
really shouldn't ever see such E820 entries, they should get
converted to simple reserved entries, to wipe any notion of
ACPI presence). And second it ties you to running on systems
that actually have ACPI, whereas it is my rudimentary
understanding that systems with e.g. SFI would not have any
ACPI).
Right. The other idea was to check the XenBus for the existence
of vpci backend. But at this stage it is not up yet.
Perhaps what I should check for is the existence of two E820_RSV
and two E820_RAM regions - and that would be a normal PV guest.
Anything that is outside of that scope would be considered
a PCI PV guest?
I'd limit this to two RAM and at least one reserved regions (after
all it could happen that all the reserved ones can be folded into
one). But beyond this minor detail that's the approach I'd prefer.
All the ones below look more or less fragile.
Jan
The other thought I had was to skip this check altogether and
either do:
1). initialize SWIOTLB when xen-pcifront start up and detects
that it has devices (so later on initialization - similar to
how IA64 does it) - but I am not sure how the PCI-DMA works
with these late bloomers (especially as one could just make
xen-pcifront be a module).
2). If xen-pcifront starts and does not detect any backends
it calls swiotlb_free. But that also requires the PCI-DMA
to swap in the dma_ops, and I am not entirely sure how
that would work out.
3). Have an early_init xen-pcifront components that does a
a quick XenBus init (similar to how hvmloader checks for
DMI overwrites) and if it finds vpci then declare its
time to turn SWIOTLB on.
4). The other thing is to wrap this code with something like
this:
#ifdef CONFIG_SWIOTLB
#ifdef CONFIG_XEN_PCI_FRONTEND
if (.. blah balh) do the check as outlined in 3).
#else // PCI_FRONTEND is not present, so we won't need SWIOTLB
swiotlb = 0;
iommu = 1;
#endif
#endif
That would take care of the built-in issues.
--
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: [Xen-devel] [PATCH 5/7] xen/p2m: Add logic to revector a P2M tree to use __va leafs.
On 27.07.12 at 19:34, Konrad Rzeszutek Wilk kon...@darnok.org wrote: On Fri, Jul 27, 2012 at 12:47:47PM +0100, Jan Beulich wrote: On 27.07.12 at 13:18, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote: 1) All P2M lookups instead of using the __ka address would use the __va address. This means we can safely erase from __ka space the PMD pointers that point to the PFNs for P2M array and be OK. 2). Allocate a new array, copy the existing P2M into it, revector the P2M tree to use that, and return the old P2M to the memory allocate. This has the advantage that it sets the stage for using XEN_ELF_NOTE_INIT_P2M feature. That feature allows us to set the exact virtual address space we want for the P2M - and allows us to boot as initial domain on large machines. So we pick option 2). 1) looks like a decent option that requires less code. Is the problem with 1) that we might want to access the P2M before we have __va addresses ready? AIUI 1) has no easy way of subsequently accommodating support for XEN_ELF_NOTE_INIT_P2M (where you almost definitely will want/need to reclaim the originally used VA space - if nothing else, then for forward compatibility with the rest of the kernel). nods That was my thinking - this way we can boot dom0 (since the hypervisor is the only one that implements the XEN_ELF_NOTE_INIT_P2M) with large amount of memory. Granted booting with more than 500GB would require adding another layer to the P2M tree. But somehow I thought that we are limited in the hypervisor to 500GB? The only limitation is that kexec (with the current specification) would not work beyond 512Gb, but that's a non-issue for upstream since kexec doesn't work there yet anyway. Our kernels come up fine even on 5Tb now (which is the current limit in the hypervisor). Jan -- 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: [Bisected] commit 71574865 (vfs: do_last(): common slow lookup) breaks CUPS printing
On 2012.07.30 at 07:50 +0100, Al Viro wrote: On Sat, Jul 28, 2012 at 12:43:16PM +0200, Markus Trippelsdorf wrote: Printing with CUPS is broken on the current git tree. Whenever I print a page the job just sits in the CUPS queue showing processing. But it never reaches the printer. (My CUPS version is 1.5.2. Filesystem is xfs.) I've bisected this issue to: commit 7157486541bffc0dfec912e21ae639b029dae3d3 Author: Miklos Szeredi mszer...@suse.cz Date: Tue Jun 5 15:10:14 2012 +0200 vfs: do_last(): common slow lookup Make the slow lookup part of O_CREAT and non-O_CREAT opens common. This allows atomic_open to be hooked into the slow lookup part. Signed-off-by: Miklos Szeredi mszer...@suse.cz Signed-off-by: Al Viro v...@zeniv.linux.org.uk Hmm... Looking at that commit, we seem to have one change introduced by it. Namely, behaviour of open(path, O_EXCL) (note that O_EXCL without O_CREAT is an undefined by POSIX and makes no damn sense anyway). Could you try the patch below, just to make sure that I'm not misreading the situation? If that's really happening that way, it should spew a warning, restore the old behaviour by removing that stray O_EXCL and, if it comes from open(2)/openat(2), print the syscall arguments. We'll need to restore the original behaviour anyway, undefined or no undefined, but if we really catch CUPS doing that, we ought to report that as a bug to whatever bugtracking system CUPS uses; at the very least, it's a portability headache waiting to happen. Looks like you're right. The first warning happens during startup. The last one when I print a test page (which now succeeds). Thanks Al. [ cut here ] WARNING: at fs/open.c:899 do_sys_open+0x1e5/0x220() Hardware name: System Product Name Pid: 207, comm: X Not tainted 3.5.0-07078-gf7da9cd-dirty #199 Call Trace: [810555a4] ? warn_slowpath_common+0x74/0xb0 [810dd405] ? do_sys_open+0x1e5/0x220 [814a64a2] ? system_call_fastpath+0x16/0x1b ---[ end trace 9a333bfb6a9cbe80 ]--- [ cut here ] WARNING: at fs/open.c:899 do_sys_open+0x1e5/0x220() Hardware name: System Product Name Pid: 384, comm: usb Tainted: GW3.5.0-07078-gf7da9cd-dirty #199 Call Trace: WTF: open(/dev/input/mice, 34946) [810555a4] ? warn_slowpath_common+0x74/0xb0 [810dd405] ? do_sys_open+0x1e5/0x220 [814a64a2] ? system_call_fastpath+0x16/0x1b ---[ end trace 9a333bfb6a9cbe81 ]--- WTF: open(/dev/usblp0, 32898) [ cut here ] WARNING: at fs/open.c:899 do_sys_open+0x1e5/0x220() Hardware name: System Product Name Pid: 384, comm: usb Tainted: GW3.5.0-07078-gf7da9cd-dirty #199 Call Trace: [810555a4] ? warn_slowpath_common+0x74/0xb0 [810dd405] ? do_sys_open+0x1e5/0x220 [814a64a2] ? system_call_fastpath+0x16/0x1b ---[ end trace 9a333bfb6a9cbe82 ]--- [ cut here ] WARNING: at fs/open.c:899 do_sys_open+0x1e5/0x220() Hardware name: System Product Name Pid: 87, comm: cupsd Tainted: GW3.5.0-07078-gf7da9cd-dirty #199 Call Trace: WTF: open(/dev/usb/lp0, 32898) [810555a4] ? warn_slowpath_common+0x74/0xb0 [810dd405] ? do_sys_open+0x1e5/0x220 [814a64a2] ? system_call_fastpath+0x16/0x1b ---[ end trace 9a333bfb6a9cbe83 ]--- -- Markus -- 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: virtio(-scsi) vs. chained sg_lists (was Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list)
Il 30/07/2012 01:50, Rusty Russell ha scritto: Also, being the first user of chained scatterlist doesn't exactly give me warm fuzzies. We're far from the first user: they've been in the kernel for well over 7 years. They were introduced for the block layer, but they tended to ignore private uses of scatterlists like this one. Yeah, but sg_chain has no users in drivers, only a private one in lib/scatterlist.c. The internal API could be changed to something else and leave virtio-scsi screwed... Yes, we should do this. But note that this means an iteration, so we might as well combine the loops :) I'm really bad at posting pseudo-code, but you can count the number of physically-contiguous entries at the beginning of the list only. So if everything is contiguous, you use a single non-indirect buffer and save a kmalloc. If you use indirect buffers, I suspect it's much less effective to collapse physically-contiguous entries. More elaborate heuristics do need a loop, though. 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 V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk
Il 30/07/2012 06:43, Asias He ha scritto: Yes. Something like this: qemu -drive file=foo.img,cache=writeback/unsafe is not safe against power losses also? cache=writeback and cache=none are safe, cache=unsafe isn't. I think we can add REQ_FLUSH REQ_FUA support to bio path and that deserves another patch. You only need to add REQ_FLUSH support. The virtio-blk protocol does not support REQ_FUA, because there's no easy way to do it in userspace. 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 13/18] ARM: ux500: Add ux500 PCM to DB8500 Device Tree
On 29/07/12 21:50, Mark Brown wrote:
On Fri, Jul 27, 2012 at 01:45:57PM +0100, Lee Jones wrote:
Nothing special here. We're only providing a compatible string
to ensure the driver is probed using a Device Tree boot.
+ pcm: ux500-pcm {
+ compatible = stericsson,ux500-pcm;
+ };
+
One of two things is wrong here. Either you've not provided any
information about the hardware so the driver won't be able to work out
what to talk to or you've not provided any data so you're registering a
purely virtual Linux-internal device via the device tree.
Once more, the idea here is to describe the hardware not to dump Linux's
internal data structures into the device tree.
We use it register the driver for probe()ing. In the same way we do for
the PMU and Regulators. All three of which actually belong to a
different hardware block. Do you know of a better way to register those
devices?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 17/18] ARM: ux500: Add all encompassing Sound node to DB8500 Device Tree
On 29/07/12 21:52, Mark Brown wrote:
On Fri, Jul 27, 2012 at 01:46:01PM +0100, Lee Jones wrote:
arch/arm/boot/dts/db8500.dtsi |8
This is a generic DT include file but...
+ sound {
+ compatible = stericsson,snd-soc-mop500;
+
+ stericsson,platform-pcm-dma = pcm;
+ stericsson,cpu-dai = msp1 msp3;
+ stericsson,audio-codec = codec;
+ };
...this is clearly the board-specific setup for the system, showing how
the CPU and CODEC are hooked up. This should therefore be in the DT for
whatever board this is you're working on.
I don't think it's board specific. I believe this is the setup on all
db8500 platforms. I'm happy to be told I'm wrong here, in which case I
can move it to the board specific files.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 1/2] lis3: add generic DT matching code
This patch adds logic to parse lis3 properties from a device tree node
and store them in a freshly allocated lis3lv02d_platform_data.
Note that the actual match tables are left out here. This part should
happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
Also adds some DT bindinds documentation.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Changes from v2:
- kzalloc braino
Changes from v1:
- some typos in properties fixed
Documentation/devicetree/bindings/misc/lis302.txt | 74
drivers/misc/lis3lv02d/lis3lv02d.c| 137 ++
drivers/misc/lis3lv02d/lis3lv02d.h| 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
b/Documentation/devicetree/bindings/misc/lis302.txt
new file mode 100644
index 000..66230fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/lis302.txt
@@ -0,0 +1,74 @@
+LIS302 accelerometer devicetree bindings
+
+This device is matched via its bus drivers, and has a number of properties
+that apply in on the generic device (independent from the bus).
+
+
+Required properties for the SPI bindings:
+ - compatible: should be set to st,lis3lv02d_spi
+ - reg:the chipselect index
+ - spi-max-frequency: maximal bus speed, should be set to 100 unless
+ constrained by external circuitry
+ - interrupts: the interrupt generated by the device
+
+
+Optional properties for all bus drivers:
+
+ - st,click-single-{x,y,z}:if present, tells the device to issue an
+ interrupt on single click events on the
+ x/y/z axis.
+ - st,click-double-{x,y,z}:if present, tells the device to issue an
+ interrupt on double click events on the
+ x/y/z axis.
+ - st,click-thresh-{x,y,z}:set the x/y/z axis threshold
+ - st,click-click-time-limit: click time limit, from 0 to 127.5msec
+ with step of 0.5 msec
+ - st,click-latency: click latency, from 0 to 255 msec with
+ step of 1 msec.
+ - st,click-window:click window, from 0 to 255 msec with
+ step of 1 msec.
+ - st,irq{1,2}-disable:disable IRQ 1/2
+ - st,irq{1,2}-ff-wu-1:raise IRQ 1/2 on FF_WU_1 condition
+ - st,irq{1,2}-ff-wu-2:raise IRQ 1/2 on FF_WU_2 condition
+ - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
+ - st,irq{1,2}-click: raise IRQ 1/2 on click condition
+ - st,irq-open-drain: consider IRQ lines open-drain
+ - st,irq-active-low: make IRQ lines active low
+ - st,wu-duration-1: duration register for Free-Fall/Wake-Up
+ interrupt 1
+ - st,wu-duration-2: duration register for Free-Fall/Wake-Up
+ interrupt 2
+ - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
+ upper/lower limit
+ - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
+ highpass cut-off frequency
+ - st,hipass{1,2}-disable: disable highpass 1/2.
+ - st,default-rate=: set the default rate
+ - st,axis-{x,y,z}=: set the axis to map to the three coordinates
+
+
+Example for a SPI device node:
+
+ lis302@0 {
+ compatible = st,lis302dl-spi;
+ reg = 0;
+ spi-max-frequency = 100;
+ interrupt-parent = gpio;
+ interrupts = 104 0;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ };
+
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index a981e2a..1411fdc 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -39,6 +39,7 @@
#include linux/miscdevice.h
#include linux/pm_runtime.h
#include linux/atomic.h
+#include linux/of_device.h
#include lis3lv02d.h
#define DRIVER_NAME lis3lv02d
@@ -912,6 +913,138 @@ static void lis3lv02d_8b_configure(struct lis3lv02d *lis3,
}
}
+#ifdef CONFIG_OF
+static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+{
+ struct lis3lv02d_platform_data *pdata;
+ struct device_node *np = lis3-of_node;
+ u32 tmp;
+
+ if (!lis3-of_node)
+
[PATCH v3 2/2] lis3-spi: add DT matching table passthru code
If probed from a device tree, this driver now passes the node
information to the generic part, so the runtime information can be
derived.
Successfully tested on a PXA3xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
---
No changes from v1 and v2
drivers/misc/lis3lv02d/lis3lv02d_spi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
index 80880e9..8616054 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
@@ -17,6 +17,7 @@
#include linux/workqueue.h
#include linux/spi/spi.h
#include linux/pm.h
+#include linux/of_platform.h
#include lis3lv02d.h
@@ -58,6 +59,12 @@ static int lis3_spi_init(struct lis3lv02d *lis3)
static union axis_conversion lis3lv02d_axis_normal =
{ .as_array = { 1, 2, 3 } };
+static struct of_device_id lis302dl_spi_dt_ids[] = {
+ { .compatible = st,lis302dl-spi },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis302dl_spi_dt_ids);
+
static int __devinit lis302dl_spi_probe(struct spi_device *spi)
{
int ret;
@@ -75,6 +82,12 @@ static int __devinit lis302dl_spi_probe(struct spi_device
*spi)
lis3_dev.irq= spi-irq;
lis3_dev.ac = lis3lv02d_axis_normal;
lis3_dev.pdata = spi-dev.platform_data;
+
+#ifdef CONFIG_OF
+ if (of_match_device(lis302dl_spi_dt_ids, spi-dev))
+ lis3_dev.of_node = spi-dev.of_node;
+#endif
+
spi_set_drvdata(spi, lis3_dev);
return lis3lv02d_init_device(lis3_dev);
@@ -121,6 +134,7 @@ static struct spi_driver lis302dl_spi_driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
.pm = lis3lv02d_spi_pm,
+ .of_match_table = of_match_ptr(lis302dl_spi_dt_ids),
},
.probe = lis302dl_spi_probe,
.remove = __devexit_p(lis302dl_spi_remove),
--
1.7.11.2
--
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 01/18] Documentation: Describe the ux500 realated audio related DT nodes
On 29/07/12 21:31, Mark Brown wrote: On Fri, Jul 27, 2012 at 01:45:45PM +0100, Lee Jones wrote: +++ b/Documentation/devicetree/bindings/sound/ux500.txt @@ -0,0 +1,62 @@ +* ux500 Audio Driver and ab8500 Audio CODEC + +Required properties: + - compatible: + - Machine Driver : stericsson,snd-soc-mop500 + - CPU-side DAI : stericsson,ux500-msp-i2s + - DMA (platform) : stericsson,ux500-pcm + - Audio CODEC: stericsson,ab8500-codec What is this a binding document for? It looks like the binding for a machine driver... No, it's a binding document for all of the ux500 driver and CODEC blocks. Do you really want me to split it all up? I think the only component which could be sanely split-out is the ab8500-codec, which could (should?) live in [1]. +Optional properties: + - reg : Physical base address and length of the device's registers. + - interrupts : The interrupt outputs from the device. + - interrupt-parent : The parent interrupt controller. + - name-supply: Phandle to the regulator name supply ...but these don't look anything like machine driver properties. These properties are relevant for some, but not all of the components above, hence why the are listed at 'optional properties'. [1] Documentation/devicetree/bindings/mfd/ab8500. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Hello,
On Thursday, July 26, 2012 1:13 PM Hideki EIRAKU wrote:
Previously the vb2_dma_contig_mmap() function was using a dma_addr_t as a
physical address. The two addressses are not necessarily the same.
For example, when using the IOMMU funtion on certain platforms, dma_addr_t
addresses are not directly mappable physical address.
dma_mmap_coherent() maps the address correctly.
It is available on ARM platforms.
Signed-off-by: Hideki EIRAKU h...@igel.co.jp
---
drivers/media/video/videobuf2-dma-contig.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-
contig.c
index 4b71326..4dc85ab 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -101,14 +101,32 @@ static unsigned int vb2_dma_contig_num_users(void
*buf_priv)
static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ int ret;
+#endif
if (!buf) {
printk(KERN_ERR No buffer to map\n);
return -EINVAL;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
The above line is not needed. It is up to dma_mmap_coherent() /
dma_mmap_attrs() to set page
protection bits which match requested type of dma buffer mapping.
+ ret = dma_mmap_coherent(buf-conf-dev, vma, buf-vaddr, buf-dma_addr,
+ buf-size);
+ if (ret) {
+ pr_err(Remapping memory failed, error: %d\n, ret);
+ return ret;
+ }
+ vma-vm_flags |= VM_DONTEXPAND | VM_RESERVED;
+ vma-vm_private_data = buf-handler;
+ vma-vm_ops = vb2_common_vm_ops;
+ vma-vm_ops-open(vma);
+ return 0;
+#else
return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
vb2_common_vm_ops, buf-handler);
+#endif
}
static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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: kernel BUG at fs/buffer.c:2886! Linux 3.5.0
HI, Le 30/07/2012 08:30, Joel Becker a écrit : On Sat, Jul 28, 2012 at 12:18:30AM +0200, Vincent ETIENNE wrote: Hello Get this on first write made ( by deliver sending mail to inform of the restart of services ) Home partition (the one receiving the mail) is based on ocfs2 created from drbd block device in primary/primary mode These drbd devices are based on lvm. system is running linux-3.5.0, identical symptom with linux 3.3 and 3.2 but working with linux 3.0 kernel reproduced on two machines ( so different hardware involved on this one software md raid on SATA, on second one areca hardware raid card ) but the 2 machines are the one sharing this partition ( so share the same data ) Hmm. Any chance you can bisect this further? Will try to. Will take a few days as the server is in production ( but used as backup so...) Jul 27 23:41:41 jupiter2 kernel: [ 351.169213] [ cut here ] Jul 27 23:41:41 jupiter2 kernel: [ 351.169261] kernel BUG at fs/buffer.c:2886! This is: BUG_ON(!buffer_mapped(bh)); in submit_bh(). Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] Call Trace: Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81327546] ? ocfs2_read_blocks+0x176/0x6c0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8114e541] ? T.1552+0x91/0x2b0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81346ad0] ? ocfs2_find_actor+0x120/0x120 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813464f7] ? ocfs2_read_inode_block_full+0x37/0x60 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813964ff] ? ocfs2_fast_symlink_readpage+0x2f/0x160 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8585] ? do_read_cache_page+0x85/0x180 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813964d0] ? ocfs2_fill_super+0x2500/0x2500 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [86d9] ? read_cache_page+0x9/0x20 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115c705] ? page_getlink+0x25/0x80 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115c77b] ? page_follow_link_light+0x1b/0x30 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8116099b] ? path_lookupat+0x38b/0x720 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81160d5c] ? do_path_lookup+0x2c/0xd0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81346f31] ? ocfs2_inode_revalidate+0x71/0x160 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81161c0c] ? user_path_at_empty+0x5c/0xb0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8106714a] ? do_page_fault+0x1aa/0x3c0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81156f2d] ? cp_new_stat+0x10d/0x120 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81157021] ? vfs_fstatat+0x41/0x80 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115715f] ? sys_newstat+0x1f/0x50 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [817ecee2] ? system_call_fastpath+0x16/0x1b This stack trace is from 3.5, because of the location of the BUG. The call path in the trace suggests the code added by Al's ea022d, but you say it breaks in 3.2 and 3.3 as well. Can you give me a trace from 3.2? For a 3.2 kernel i get this stack trace. Different trace form 3.5 but exactly at the same moment. and for the same reasons. Seems to be less immmediate than with 3.5 but more a subjective imrpession than something based on fact. ( it takes a few seconds after deliver is started to have the bug ) [ 716.402833] o2dlm: Joining domain B43153ED20B942E291251F2C138ADA9E ( 0 1 ) 2 nodes [ 716.501511] ocfs2: Mounting device (147,2) on (node 1, slot 0) with ordered data mode. [ 716.505744] mount.ocfs2 used greatest stack depth: 2936 bytes left [ 727.133743] deliver used greatest stack depth: 2632 bytes left [ 764.167029] deliver used greatest stack depth: 1896 bytes left [ 764.778872] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 764.778897] IP: [8133c51a] __ocfs2_change_file_space+0x75a/0x1690 [ 764.778922] PGD 62697067 PUD 67a81067 PMD 0 [ 764.778939] Oops: [#1] SMP [ 764.778953] CPU 0 [ 764.778959] Modules linked in: drbd lru_cache ipv6 [last unloaded: drbd] [ 764.778986] [ 764.778993] Pid: 5909, comm: deliver Not tainted 3.2.12-gentoo #2 HP ProLiant ML150 G3/ML150 G3 [ 764.779017] RIP: 0010:[8133c51a] [8133c51a] __ocfs2_change_file_space+0x75a/0x1690 [ 764.779041] RSP: 0018:880067b2dd98 EFLAGS: 00010246 [ 764.779053] RAX: RBX: 880067f82000 RCX: 880063d11000 [ 764.779069] RDX: RSI: 0001 RDI: 88007ae83288 [ 764.779085] RBP: 880055d1f138 R08: 0010 R09: 880063d11000 [ 764.779100] R10: R11: R12: 88007ae83288 [ 764.779115] R13: R14: R15: 00df [
Re: [PATCH v3] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Il 30/07/2012 08:25, Wang Sen ha scritto: When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. But if there are some HighMem pages in table-sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) may return NULL value. This will cause QEMU exit when virtqueue_map_sg is called in QEMU because an invalid GPA is passed by virtqueue. Two solutions are discussed here: http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/00675.html Finally, value assignment approach was adopted because: Value assignment creates a well-formed scatterlist, because the termination marker in source sg_list has been set in blk_rq_map_sg(). The last entry of the source sg_list is just copied to the the last entry in destination list. Note that, for now, virtio_ring does not care about the form of the scatterlist and simply processes the first out_num + in_num consecutive elements of the sg[] array. I have tested the patch on my workstation. QEMU would not crash any more. Cc: sta...@vger.kernel.org # 3.4: 4fe74b1: [SCSI] virtio-scsi: SCSI driver Signed-off-by: Wang Sen senw...@linux.vnet.ibm.com Acked-by: Paolo Bonzini pbonz...@redhat.com -- 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] gpio: Add Avionic Design N-bit GPIO expander support
On Sun, Jul 29, 2012 at 07:13:57PM +0200, Linus Walleij wrote: On Mon, Jul 23, 2012 at 1:59 PM, Thierry Reding thierry.red...@avionic-design.de wrote: This commit adds a driver for the Avionic Design N-bit GPIO expander. The expander provides a variable number of GPIO pins with interrupt support. (...) diff --git a/Documentation/devicetree/bindings/gpio/gpio-adnp.txt b/Documentation/devicetree/bindings/gpio/gpio-adnp.txt new file mode 100644 index 000..513a18e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-adnp.txt @@ -0,0 +1,38 @@ +Avionic Design N-bit GPIO expander bindings + +Required properties: +- compatible: should be ad,gpio-adnp +- reg: The I2C slave address for this device. +- interrupt-parent: phandle of the parent interrupt controller. +- interrupts: Interrupt specifier for the controllers interrupt. +- #gpio-cells: Should be 2. The first cell is the GPIO number and the + second cell is used to specify optional parameters: + - bit 0: polarity (0: normal, 1: inverted) +- gpio-controller: Marks the device as a GPIO controller +- #interrupt-cells: Should be 2. The first cell contains the GPIO number, + whereas the second cell is used to specify flags: +bits[3:0] trigger type and level flags + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive Why on earth would a bunch of flags be an interrupt cell? Maybe there is something about DT bindings I don't get so please educate me. I can see that OMAP is doing this, but is it a good idea? I really need Rob/Grant to comment on this. +- interrupt-controller: Marks the device as an interrupt controller. +- nr-gpios: The number of pins supported by the controller. These two last things look very generic, like something every GPIO driver could want to expose. As Arnd mentioned, interrupt-controller is a generic property required by all interrupt controller nodes. Perhaps it shouldn't be listed in the DT binding for this driver. As to the nr-gpios property, this is actually not only for informational purposes, but it also allows the driver to be configured to handle any number of bits (powers of two). However since this is also a description of the hardware it may be useful to make this into a generic property for GPIO controllers. I'd really like to have Grant's word on GPIO DT bindings and how these should look, I had some discussion with Wolfram (the I2C maintainer) about bindings turning out less generic than they ought to be, so we need some discussion on this. Arnd recently consolidated some MMC props, maybe we need to do the same for GPIO drivers. (...) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 502b5ea..d1b0f7d 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -444,6 +444,24 @@ config GPIO_ADP5588_IRQ Say yes here to enable the adp5588 to be used as an interrupt controller. It requires the driver to be built in the kernel. +config GPIO_ADNP + tristate Avionic Design N-bit GPIO expander + depends on I2C OF + help + This option enables support for N GPIOs found on Avionic Design + I2C GPIO expanders. The register space will be extended by powers + of two, so the controller will need to accomodate for that. For + example: if a controller provides 48 pins, 6 registers will be + enough to represent all pins, but the driver will assume a + register layout for 64 pins (8 registers). + +config GPIO_ADNP_IRQ + tristate Interrupt controller support + depends on GPIO_ADNP + help + Say yes here to enable the Avionic Design N-bit GPIO expander to + be used as an interrupt controller. First: please describe the usecase where the Avionic driver is used without making use of the IRQ, and *why* it should be possible to configure this out. E.g. is there a hardware which isn't using the IRQ portions? If there is no non-irq usecase just drop this config option. This expander is used in a number of Tegra-based boards and handles things like enabling or disabling power to a given IC but on other boards it is also used to handle interrupts from input devices or card-detect for example. The controller is synthesized in a CPLD, which is one of the reasons for the nr-gpios DT property. There is at least one platform that currently doesn't use the interrupt functionality. Mainly I allowed this to be configured out in order to reduce the number of interrupts required for a platform. Another reason was that at the time I first wrote this, IRQ domains hadn't been available, so the driver couldn't be built as a module if interrupt support was required. This also no longer applies. I'm actually fine either way, but I thought it'd be most flexible by
Re: linux-next: Tree for July 2 (crypto/hifn_795x)
On Mon, Jul 09, 2012 at 09:40:22PM +, Randy Dunlap wrote: On 07/09/2012 10:54 AM, Jussi Kivilinna wrote: Quoting Randy Dunlap rdun...@xenotime.net: On 07/02/2012 12:23 AM, Stephen Rothwell wrote: Hi all, Changes since 20120629: on i386: ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined! This is caused by commit feb7b7ab928afa97a79a9c424e4e0691f49d63be. hifn_795x has DIV_ROUND_UP(NSEC_PER_SEC, dev-pk_clk_freq), which should be changed to DIV_ROUND_UP_ULL now that NSEC_PER_SEC is 64bit on 32bit archs. Patch to fix hifn_795x is attached (only compile tested). Acked-by: Randy Dunlap rdun...@xenotime.net Patch applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: kernel BUG at fs/buffer.c:2886! Linux 3.5.0
On Mon, Jul 30, 2012 at 09:45:14AM +0200, Vincent ETIENNE wrote: HI, Le 30/07/2012 08:30, Joel Becker a écrit : On Sat, Jul 28, 2012 at 12:18:30AM +0200, Vincent ETIENNE wrote: Hello Get this on first write made ( by deliver sending mail to inform of the restart of services ) Home partition (the one receiving the mail) is based on ocfs2 created from drbd block device in primary/primary mode These drbd devices are based on lvm. system is running linux-3.5.0, identical symptom with linux 3.3 and 3.2 but working with linux 3.0 kernel reproduced on two machines ( so different hardware involved on this one software md raid on SATA, on second one areca hardware raid card ) but the 2 machines are the one sharing this partition ( so share the same data ) Hmm. Any chance you can bisect this further? Will try to. Will take a few days as the server is in production ( but used as backup so...) Jul 27 23:41:41 jupiter2 kernel: [ 351.169213] [ cut here ] Jul 27 23:41:41 jupiter2 kernel: [ 351.169261] kernel BUG at fs/buffer.c:2886! This is: BUG_ON(!buffer_mapped(bh)); in submit_bh(). Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] Call Trace: Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81327546] ? ocfs2_read_blocks+0x176/0x6c0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8114e541] ? T.1552+0x91/0x2b0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81346ad0] ? ocfs2_find_actor+0x120/0x120 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813464f7] ? ocfs2_read_inode_block_full+0x37/0x60 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813964ff] ? ocfs2_fast_symlink_readpage+0x2f/0x160 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8585] ? do_read_cache_page+0x85/0x180 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [813964d0] ? ocfs2_fill_super+0x2500/0x2500 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [86d9] ? read_cache_page+0x9/0x20 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115c705] ? page_getlink+0x25/0x80 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115c77b] ? page_follow_link_light+0x1b/0x30 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8116099b] ? path_lookupat+0x38b/0x720 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81160d5c] ? do_path_lookup+0x2c/0xd0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81346f31] ? ocfs2_inode_revalidate+0x71/0x160 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81161c0c] ? user_path_at_empty+0x5c/0xb0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8106714a] ? do_page_fault+0x1aa/0x3c0 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81156f2d] ? cp_new_stat+0x10d/0x120 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [81157021] ? vfs_fstatat+0x41/0x80 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [8115715f] ? sys_newstat+0x1f/0x50 Jul 27 23:41:41 jupiter2 kernel: [ 351.170003] [817ecee2] ? system_call_fastpath+0x16/0x1b This stack trace is from 3.5, because of the location of the BUG. The call path in the trace suggests the code added by Al's ea022d, but you say it breaks in 3.2 and 3.3 as well. Can you give me a trace from 3.2? For a 3.2 kernel i get this stack trace. Different trace form 3.5 but exactly at the same moment. and for the same reasons. Seems to be less immmediate than with 3.5 but more a subjective imrpession than something based on fact. ( it takes a few seconds after deliver is started to have the bug ) Totally different stack trace. Not in symlink code, but instead in fallocate. Weird. I wonder if you are hitting two things. Bisection will definitely help. Joel [ 716.402833] o2dlm: Joining domain B43153ED20B942E291251F2C138ADA9E ( 0 1 ) 2 nodes [ 716.501511] ocfs2: Mounting device (147,2) on (node 1, slot 0) with ordered data mode. [ 716.505744] mount.ocfs2 used greatest stack depth: 2936 bytes left [ 727.133743] deliver used greatest stack depth: 2632 bytes left [ 764.167029] deliver used greatest stack depth: 1896 bytes left [ 764.778872] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 764.778897] IP: [8133c51a] __ocfs2_change_file_space+0x75a/0x1690 [ 764.778922] PGD 62697067 PUD 67a81067 PMD 0 [ 764.778939] Oops: [#1] SMP [ 764.778953] CPU 0 [ 764.778959] Modules linked in: drbd lru_cache ipv6 [last unloaded: drbd] [ 764.778986] [ 764.778993] Pid: 5909, comm: deliver Not tainted 3.2.12-gentoo #2 HP ProLiant ML150 G3/ML150 G3 [ 764.779017] RIP: 0010:[8133c51a] [8133c51a] __ocfs2_change_file_space+0x75a/0x1690 [ 764.779041] RSP: 0018:880067b2dd98 EFLAGS: 00010246 [ 764.779053] RAX: RBX: 880067f82000 RCX:
Re: [PATCH 0/6] crypto: add x86_64/avx assembler implementation of cast5 and cast6
On Wed, Jul 11, 2012 at 07:36:46PM +0200, Johannes Goetzfried wrote: This patchset adds x86_64/avx assembler implementations of the Cast5 and the Cast6 cipher. Johannes Goetzfried (6): crypto: cast5 - prepare generic module for optimized implementations crypto: testmgr - add larger cast5 testvectors crypto: cast5 - add x86_64/avx assembler implementation crypto: cast6 - prepare generic module for optimized implementations crypto: testmgr - add larger cast6 testvectors crypto: cast6 - add x86_64/avx assembler implementation Nice work. All applied. Thanks. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: [Bisected] commit 71574865 (vfs: do_last(): common slow lookup) breaks CUPS printing
On Mon, Jul 30, 2012 at 09:10:23AM +0200, Markus Trippelsdorf wrote:
Looks like you're right. The first warning happens during startup. The last
one
when I print a test page (which now succeeds).
Thanks Al.
WTF: open(/dev/input/mice, 34946)
WTF: open(/dev/usblp0, 32898)
WTF: open(/dev/usb/lp0, 32898)
Ahhh... OK, yes - it's the case we had missed (and where the manpage
needs correction, BTW). O_EXCL for *devices* has additional semantics;
it's not fail if exists, it's fail if already opened by somebody.
No need to pester CUPS folks (except that I really hope that this
open of /dev/input/mice does *not* come from them)...
All right, the proper fix is *not* removing O_EXCL from flags; we want
it to reach -f_flags, so that device open would work correctly. I think
we need this, but I wonder if that's all; -atomic_open() instances
might need to be corrected as well. I've pushed this into for-next/for-linus
for now:
commit f8310c59201b183ebee2e3fe0c7242f5729be0af
Author: Al Viro v...@zeniv.linux.org.uk
Date: Mon Jul 30 11:50:30 2012 +0400
fix O_EXCL handling for devices
O_EXCL without O_CREAT has different semantics; it's fail if already
opened,
not fail if already exists. commit 71574865 broke that...
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
diff --git a/fs/namei.c b/fs/namei.c
index 618d353..e133bf3 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2418,7 +2418,7 @@ static int atomic_open(struct nameidata *nd, struct
dentry *dentry,
if ((open_flag O_CREAT) !IS_POSIXACL(dir))
mode = ~current_umask();
- if (open_flag O_EXCL) {
+ if ((open_flag (O_EXCL | O_CREAT)) == (O_EXCL | O_CREAT)) {
open_flag = ~O_TRUNC;
*opened |= FILE_CREATED;
}
@@ -2742,7 +2742,7 @@ retry_lookup:
}
error = -EEXIST;
- if (open_flag O_EXCL)
+ if ((open_flag (O_EXCL | O_CREAT)) == (O_EXCL | O_CREAT))
goto exit_dput;
error = follow_managed(path, nd-flags);
--
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/4] powerpc/crypto: IBM Power7+ in-Nest compression support
On Thu, Jul 19, 2012 at 09:42:37AM -0500, Seth Jennings wrote: This is a continuation of support for the Power7+ in-Nest hardware accelerator. https://lkml.org/lkml/2012/4/12/223 This patchset adds the hardware driver and the cryptographic driver for hardware accelerated compression, which uses a hardware-optimized algorithm named 842. The hardware driver has limits on generic compression and is geared toward compressing units that are of PAGE_SIZE for in-kernel memory compression. Based on linux-next (20120717) Seth Jennings (4): All applied. Thanks Seth. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 3/4] powerpc/crypto: add 842 hardware compression driver
On Fri, 2012-07-20 at 09:01 -0500, Seth Jennings wrote:
On 07/20/2012 12:33 AM, Michael Ellerman wrote:
On Thu, 2012-07-19 at 09:42 -0500, Seth Jennings wrote:
This patch adds the driver for interacting with the 842
compression accelerator on IBM Power7+ systems.
...
+struct nx842_slentry {
+ unsigned long ptr; /* Absolute address (use virt_to_abs()) */
/+ unsigned long len;
+};
These days virt_to_abs() is just __pa() - ie. convert to a real address.
Thanks, I'll make that change.
Is it a blocker to the code being pulled in though? I'm
hoping to get this in ASAP for the 3.6 merge window. As
this isn't a functional defect (I assume __pa() and
virt_to_abs() still achieve the same result), can I get an
OK from you that this isn't a blocker to the code being
accepted?
Sorry I missed your reply. No it's not a blocker, just ugly.
I have sent a series to Ben which removes virt_to_abs() entirely, so
we'll want to make sure we fixup the nx driver before that goes in.
cheers
--
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] block: extends name_to_dev_t() syntax for specifying e.g. root=.
Enables use of GPT partition labels, APM partition labels, and MBR
disk signatures to specify block devices during early boot.
Traditional device names and GPT partition UUIDs are still supported.
This is useful on systems with nondeterministic device ordering.
Signed-off-by: Andy Getzendanner suertr...@gmail.com
---
Tested with an MBR disk, an APM disk, and a GPT disk on ppc32 and
amd64 using qemu.
block/genhd.c | 18 +++---
block/partition-generic.c |3 +-
block/partitions/check.h |1 -
block/partitions/efi.c| 10 +++-
block/partitions/mac.c| 20 +-
block/partitions/msdos.c | 97 ++--
include/linux/genhd.h |2 +
init/do_mounts.c | 153 +++--
8 files changed, 260 insertions(+), 44 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 9cf5583..139ec46 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -743,7 +743,6 @@ void __init printk_all_partitions(void)
struct hd_struct *part;
char name_buf[BDEVNAME_SIZE];
char devt_buf[BDEVT_SIZE];
- char uuid_buf[PARTITION_META_INFO_UUIDLTH * 2 + 5];
/*
* Don't show empty devices or things that have been
@@ -762,16 +761,17 @@ void __init printk_all_partitions(void)
while ((part = disk_part_iter_next(piter))) {
bool is_part0 = part == disk-part0;
- uuid_buf[0] = '\0';
- if (part-info)
- snprintf(uuid_buf, sizeof(uuid_buf), %pU,
-part-info-uuid);
-
- printk(%s%s %10llu %s %s, is_part0 ? : ,
+ printk(%s%s %10llu %s, is_part0 ? : ,
bdevt_str(part_devt(part), devt_buf),
(unsigned long long)part-nr_sects 1,
- disk_name(disk, part-partno, name_buf),
- uuid_buf);
+ disk_name(disk, part-partno, name_buf));
+ if (part-info part-info-has_uuid)
+ printk( PARTUUID=%pUb, part-info-uuid);
+ if (part-info part-info-has_volname)
+ printk( PARTLABEL=%s, part-info-volname);
+ if (part-info part-info-has_diskid)
+ printk( DISKID=%08x/PARTNR=%d,
+ part-info-diskid, part-partno);
if (is_part0) {
if (disk-driverfs_dev != NULL
disk-driverfs_dev-driver != NULL)
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 6df5d69..ff4a10d 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -508,8 +508,7 @@ rescan:
}
}
- if (state-parts[p].has_info)
- info = state-parts[p].info;
+ info = state-parts[p].info;
part = add_partition(disk, p, from, size,
state-parts[p].flags,
state-parts[p].info);
diff --git a/block/partitions/check.h b/block/partitions/check.h
index 52b1003..2cb2378 100644
--- a/block/partitions/check.h
+++ b/block/partitions/check.h
@@ -13,7 +13,6 @@ struct parsed_partitions {
sector_t from;
sector_t size;
int flags;
- bool has_info;
struct partition_meta_info info;
} parts[DISK_MAX_PARTS];
int next;
diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index 6296b40..4cfb646 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -25,6 +25,9 @@
* TODO:
*
* Changelog:
+ * Sun Jul 22 2012 Andy Getzendanner suertr...@gmail.com
+ * - generalized partition_meta_info and populated volname field from GPT
+ *
* Mon Nov 09 2004 Matt Domsch matt_dom...@dell.com
* - test for valid PMBR and valid PGPT before ever reading
* AGPT, allow override with 'gpt' kernel command line option.
@@ -95,6 +98,7 @@
/
#include linux/crc32.h
#include linux/ctype.h
+#include linux/genhd.h
#include linux/math64.h
#include linux/slab.h
#include check.h
@@ -654,19 +658,21 @@ int efi_partition(struct parsed_partitions *state)
*/
efi_guid_unparse(ptes[i].unique_partition_guid, unparsed_guid);
part_pack_uuid(unparsed_guid, info-uuid);
+ info-has_uuid = true;
/* Naively convert UTF16-LE to 7 bits. */
label_max = min(sizeof(info-volname) - 1,
sizeof(ptes[i].partition_name));
info-volname[label_max] = 0;
RE: [PATCH] gpio: samsung: Fix off-by-one bug in gpio addresses
-Original Message-
From: diand...@google.com [mailto:diand...@google.com] On Behalf Of Doug
Anderson
Sent: Saturday, July 21, 2012 6:07 AM
To: Sean Paul
Cc: grant.lik...@secretlab.ca; linus.wall...@stericsson.com;
linux-kernel@vger.kernel.org;
ol...@chromium.org; Sangsu Park; Thomas Abraham; Kukjin Kim
Subject: Re: [PATCH] gpio: samsung: Fix off-by-one bug in gpio addresses
Acked-by: Doug Anderson diand...@chromium.org
---
On Fri, Jul 20, 2012 at 1:58 PM, Sean Paul seanp...@chromium.org wrote:
Move gpc4 to the end of the automatically processed gpio controllers
so we don't taint the automatic offset calculation.
This bug caused all controllers coming after gpc4 to map to the
incorrect address. The result is gpd1 0 0 0 0 would actually map to
GPIO 0 in gpd0.
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpio/gpio-samsung.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index b6453d0..e4599b4 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2454,12 +2454,6 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
},
}, {
.chip = {
- .base = EXYNOS5_GPC4(0),
- .ngpio = EXYNOS5_GPIO_C4_NR,
- .label = GPC4,
- },
- }, {
- .chip = {
.base = EXYNOS5_GPD0(0),
.ngpio = EXYNOS5_GPIO_D0_NR,
.label = GPD0, @@ -2513,6 +2507,12 @@
static struct samsung_gpio_chip exynos5_gpios_1[] = {
.label = GPY6,
},
}, {
+ .chip = {
+ .base = EXYNOS5_GPC4(0),
+ .ngpio = EXYNOS5_GPIO_C4_NR,
+ .label = GPC4,
+ },
+ }, {
.config = samsung_gpio_cfgs[9],
.irq_base = IRQ_EINT(0),
.chip = {
@@ -2833,7 +2833,7 @@ static __init void exynos5_gpiolib_init(void)
}
/* need to set base address for gpc4 */
- exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
+ exynos5_gpios_1[20].base = gpio_base1 + 0x2E0;
/* need to set base address for gpx */
chip = exynos5_gpios_1[21];
--
1.7.7.3
I think that this modification is right.
Thanks.
--
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: [Bisected] commit 71574865 (vfs: do_last(): common slow lookup) breaks CUPS printing
On 2012.07.30 at 08:56 +0100, Al Viro wrote: On Mon, Jul 30, 2012 at 09:10:23AM +0200, Markus Trippelsdorf wrote: Looks like you're right. The first warning happens during startup. The last one when I print a test page (which now succeeds). Thanks Al. WTF: open(/dev/input/mice, 34946) WTF: open(/dev/usblp0, 32898) WTF: open(/dev/usb/lp0, 32898) Ahhh... OK, yes - it's the case we had missed (and where the manpage needs correction, BTW). O_EXCL for *devices* has additional semantics; it's not fail if exists, it's fail if already opened by somebody. No need to pester CUPS folks (except that I really hope that this open of /dev/input/mice does *not* come from them)... I've omitted some WTF's from my former reply, because they happend after I've sent it. Jul 30 09:06:51 x4 kernel: [ cut here ] Jul 30 09:06:51 x4 kernel: WARNING: at fs/open.c:899 do_sys_open+0x1e5/0x220() Jul 30 09:06:51 x4 kernel: Hardware name: System Product Name Jul 30 09:06:51 x4 kernel: Pid: 87, comm: cupsd Tainted: GW 3.5.0-07078-gf7da9cd-dirty #199 Jul 30 09:06:51 x4 kernel: Call Trace: Jul 30 09:06:51 x4 kernel: WTF: open(/dev/usb/lp0, 32898) Jul 30 09:06:51 x4 kernel: [810555a4] ? warn_slowpath_common+0x74/0xb0 Jul 30 09:06:51 x4 kernel: [810dd405] ? do_sys_open+0x1e5/0x220 Jul 30 09:06:51 x4 kernel: [814a64a2] ? system_call_fastpath+0x16/0x1b Jul 30 09:06:51 x4 kernel: ---[ end trace 9a333bfb6a9cbe83 ]--- Jul 30 09:07:19 x4 kernel: WTF: open(/var/spool/cups/a00018, 32897) Jul 30 09:07:19 x4 kernel: [ cut here ] Jul 30 09:07:19 x4 kernel: WARNING: at fs/open.c:899 do_sys_open+0x1e5/0x220() Jul 30 09:07:19 x4 kernel: Hardware name: System Product Name Jul 30 09:07:19 x4 kernel: Pid: 87, comm: cupsd Tainted: GW 3.5.0-07078-gf7da9cd-dirty #199 Jul 30 09:07:19 x4 kernel: Call Trace: Jul 30 09:07:19 x4 kernel: [810555a4] ? warn_slowpath_common+0x74/0xb0 Jul 30 09:07:19 x4 kernel: [810dd405] ? do_sys_open+0x1e5/0x220 Jul 30 09:07:19 x4 kernel: [814a64a2] ? system_call_fastpath+0x16/0x1b Jul 30 09:07:19 x4 kernel: ---[ end trace 9a333bfb6a9cbe84 ]--- Jul 30 09:30:40 x4 kernel: WTF: open(/var/cache/cups/job.cache.O, 32897) Jul 30 09:30:40 x4 kernel: [ cut here ] Jul 30 09:30:40 x4 kernel: WARNING: at fs/open.c:899 do_sys_open+0x1e5/0x220() Jul 30 09:30:40 x4 kernel: Hardware name: System Product Name Jul 30 09:30:40 x4 kernel: Pid: 87, comm: cupsd Tainted: GW 3.5.0-07078-gf7da9cd-dirty #199 Jul 30 09:30:40 x4 kernel: Call Trace: Jul 30 09:30:40 x4 kernel: [810555a4] ? warn_slowpath_common+0x74/0xb0 Jul 30 09:30:40 x4 kernel: [810dd405] ? do_sys_open+0x1e5/0x220 Jul 30 09:30:40 x4 kernel: [814a64a2] ? system_call_fastpath+0x16/0x1b Jul 30 09:30:40 x4 kernel: ---[ end trace 9a333bfb6a9cbe85 ]--- /var/spool/cups/a00018 /var/cache/cups/job.cache.O are not devices AFAICS. -- Markus -- 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 1/1] xfs: check for possible overflow in xfs_ioc_trim
If range.start argument was between ULLONG_MAX - BBSIZE and ULLONG_MAX, BTOBB macro resulted in overflow which caused start to be set to 0. Now, invalid argument error is returned instead. Signed-off-by: Tomas Racek tra...@redhat.com --- fs/xfs/xfs_discard.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/fs/xfs/xfs_discard.c b/fs/xfs/xfs_discard.c index f9c3fe3..0ef7dd4 100644 --- a/fs/xfs/xfs_discard.c +++ b/fs/xfs/xfs_discard.c @@ -179,6 +179,10 @@ xfs_ioc_trim( * used by the fstrim application. In the end it really doesn't * matter as trimming blocks is an advisory interface. */ + + if (range.start ULLONG_MAX - BBSIZE) + return -XFS_ERROR(EINVAL); + start = BTOBB(range.start); end = start + BTOBBT(range.len) - 1; minlen = BTOBB(max_t(u64, granularity, range.minlen)); -- 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/
[patch 1/2] [SCSI] ipr: missing unlock before a return
We recently changed the locking in this function, but this return was
missed. It needs an unlock and the IRQs need to be restored.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Applies to linux-next.
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 07b14ba..7a5ccb2c 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -5874,8 +5874,11 @@ static int ipr_queuecommand(struct Scsi_Host *shost,
goto err_nodev;
}
- if (ipr_is_gata(res) res-sata_port)
- return ata_sas_queuecmd(scsi_cmd, res-sata_port-ap);
+ if (ipr_is_gata(res) res-sata_port) {
+ rc = ata_sas_queuecmd(scsi_cmd, res-sata_port-ap);
+ spin_unlock_irqrestore(shost-host_lock, lock_flags);
+ return rc;
+ }
ipr_cmd = __ipr_get_free_ipr_cmnd(ioa_cfg);
spin_unlock_irqrestore(shost-host_lock, lock_flags);
--
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 2/2] [SCSI] ipr: remove an unneeded check
rc is always zero here, so there is no need to check.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 7a5ccb2c..fc49f17 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -5847,7 +5847,7 @@ static int ipr_queuecommand(struct Scsi_Host *shost,
struct ipr_ioarcb *ioarcb;
struct ipr_cmnd *ipr_cmd;
unsigned long lock_flags;
- int rc = 0;
+ int rc;
ioa_cfg = (struct ipr_ioa_cfg *)shost-hostdata;
@@ -5905,12 +5905,10 @@ static int ipr_queuecommand(struct Scsi_Host *shost,
(!ipr_is_gscsi(res) || scsi_cmd-cmnd[0] == IPR_QUERY_RSRC_STATE))
ioarcb-cmd_pkt.request_type = IPR_RQTYPE_IOACMD;
- if (likely(rc == 0)) {
- if (ioa_cfg-sis64)
- rc = ipr_build_ioadl64(ioa_cfg, ipr_cmd);
- else
- rc = ipr_build_ioadl(ioa_cfg, ipr_cmd);
- }
+ if (ioa_cfg-sis64)
+ rc = ipr_build_ioadl64(ioa_cfg, ipr_cmd);
+ else
+ rc = ipr_build_ioadl(ioa_cfg, ipr_cmd);
spin_lock_irqsave(shost-host_lock, lock_flags);
if (unlikely(rc || (!ioa_cfg-allow_cmds !ioa_cfg-ioa_is_dead))) {
--
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] es1688 - freeup resources on init failure
At Sun, 29 Jul 2012 16:23:08 +0200, Daniel Mack wrote: On 29.07.2012 13:39, Fengguang Wu wrote: err = snd_es1688_init(chip, 1); if (err 0) - return err; + goto exit_release_dma; /* Register device */ return snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, ops); + +exit_release_dma: + free_dma(chip-dma8); +exit_release_irq: + free_irq(chip-irq, chip); +exit_release_region: + release_and_free_resource(chip-res_port); +exit: + return err; You can simply call snd_es1688_free(chip) instead of a bunch of labels. That is, all goto's can be goto exit, and exit: snd_es1688_free(chip); return err; snd_es1688_free() will call snd_es1688_init() which in turn use the uninitialized spin locks and other data. So I end up with the below patch. snd_device_new() could also return errors and will be handled in the same way. I don't have the hardware, however tests show it at least fixed the boot time irq mismatch warnings. Daniel, thanks for your initial implementation and please kindly confirm the below 3rd version :) Looks good to me, but I don't have the hardware either :) I see no obvious problem there so I took the patch now. Thanks! Takashi Daniel --- es1688 - freeup resources on init failure This will fix the following oops: [6.169981] genirq: Flags mismatch irq 5. (ES1688) vs. (ES1688) [6.170851] Pid: 1, comm: swapper Not tainted 3.5.0-4-gceee0e9 #14 [6.170851] Call Trace: [6.170851] [c1062237] ? __setup_irq+0x3c7/0x420 [6.170851] [c1062486] ? request_threaded_irq+0x76/0x140 [6.170851] [c1290220] ? snd_es1688_ioctl+0x10/0x10 [6.170851] [c10624c2] ? request_threaded_irq+0xb2/0x140 [6.170851] [c1291196] ? snd_es1688_create+0x96/0x330 [6.170851] [c138365d] ? snd_gusextreme_probe+0x18d/0x5a2 [6.170851] [c11c9d80] ? __driver_attach+0x80/0x80 [6.170851] [c10db22f] ? sysfs_create_link+0xf/0x20 [6.170851] [c11c9d80] ? __driver_attach+0x80/0x80 [6.170851] [c11d1502] ? isa_bus_probe+0x12/0x20 [6.170851] [c11c9b95] ? driver_probe_device+0x55/0x1c0 [6.170851] [c13ae04f] ? _raw_spin_unlock+0xf/0x30 [6.170851] [c13705ea] ? klist_next+0x6a/0xe0 [6.170851] [c11d15c1] ? isa_bus_match+0x21/0x40 [6.170851] [c11c8a24] ? bus_for_each_drv+0x34/0x70 [6.170851] [c11c9e4b] ? device_attach+0x7b/0x90 [6.170851] [c11c9d80] ? __driver_attach+0x80/0x80 [6.170851] [c11c8bff] ? bus_probe_device+0x5f/0x80 [6.170851] [c11c7493] ? device_add+0x573/0x620 [6.170851] [c1042820] ? complete_all+0x40/0x60 [6.170851] [c13ae08a] ? _raw_spin_unlock_irqrestore+0x1a/0x30 [6.170851] [c11d16c6] ? isa_register_driver+0xb6/0x150 [6.170851] [c15c9002] ? alsa_card_gusmax_init+0xf/0xf [6.170851] [c15a99bc] ? do_one_initcall+0x7f/0x12b [6.170851] [c15a9b7a] ? kernel_init+0x112/0x1a9 [6.170851] [c15a9423] ? do_early_param+0x77/0x77 [6.170851] [c15a9a68] ? do_one_initcall+0x12b/0x12b [6.170851] [c13aefbe] ? kernel_thread_helper+0x6/0xd [6.190170] es1688: can't grab IRQ 5 [6.190613] genirq: Flags mismatch irq 5. (ES1688) vs. (ES1688) [6.191566] Pid: 1, comm: swapper Not tainted 3.5.0-4-gceee0e9 #14 [6.192394] Call Trace: [6.192685] [c1062237] ? __setup_irq+0x3c7/0x420 [6.193342] [c1062486] ? request_threaded_irq+0x76/0x140 [6.194081] [c1290220] ? snd_es1688_ioctl+0x10/0x10 [6.194607] [c10624c2] ? request_threaded_irq+0xb2/0x140 [6.194607] [c1291196] ? snd_es1688_create+0x96/0x330 [6.194607] [c138365d] ? snd_gusextreme_probe+0x18d/0x5a2 [6.194607] [c11c9d80] ? __driver_attach+0x80/0x80 [6.194607] [c10db22f] ? sysfs_create_link+0xf/0x20 [6.194607] [c11c9d80] ? __driver_attach+0x80/0x80 [6.194607] [c11d1502] ? isa_bus_probe+0x12/0x20 [6.194607] [c11c9b95] ? driver_probe_device+0x55/0x1c0 [6.194607] [c13ae04f] ? _raw_spin_unlock+0xf/0x30 [6.194607] [c13705ea] ? klist_next+0x6a/0xe0 [6.194607] [c11d15c1] ? isa_bus_match+0x21/0x40 [6.194607] [c11c8a24] ? bus_for_each_drv+0x34/0x70 [6.194607] [c11c9e4b] ? device_attach+0x7b/0x90 [6.194607] [c11c9d80] ? __driver_attach+0x80/0x80 [6.194607] [c11c8bff] ? bus_probe_device+0x5f/0x80 [6.194607] [c11c7493] ? device_add+0x573/0x620 [6.194607] [c1042820] ? complete_all+0x40/0x60 [6.194607] [c13ae08a] ? _raw_spin_unlock_irqrestore+0x1a/0x30 [6.194607] [c11d16c6] ? isa_register_driver+0xb6/0x150 [6.194607] [c15c9002] ? alsa_card_gusmax_init+0xf/0xf [6.194607] [c15a99bc] ? do_one_initcall+0x7f/0x12b [6.194607] [c15a9b7a] ? kernel_init+0x112/0x1a9 [6.194607] [c15a9423] ? do_early_param+0x77/0x77 [6.194607] [c15a9a68] ?
Re: [Bisected] commit 71574865 (vfs: do_last(): common slow lookup) breaks CUPS printing
On Mon, Jul 30, 2012 at 10:05:36AM +0200, Markus Trippelsdorf wrote: On 2012.07.30 at 08:56 +0100, Al Viro wrote: On Mon, Jul 30, 2012 at 09:10:23AM +0200, Markus Trippelsdorf wrote: Looks like you're right. The first warning happens during startup. The last one when I print a test page (which now succeeds). Thanks Al. WTF: open(/dev/input/mice, 34946) WTF: open(/dev/usblp0, 32898) WTF: open(/dev/usb/lp0, 32898) Ahhh... OK, yes - it's the case we had missed (and where the manpage needs correction, BTW). O_EXCL for *devices* has additional semantics; it's not fail if exists, it's fail if already opened by somebody. No need to pester CUPS folks (except that I really hope that this open of /dev/input/mice does *not* come from them)... I've omitted some WTF's from my former reply, because they happend after I've sent it. Jul 30 09:07:19 x4 kernel: WTF: open(/var/spool/cups/a00018, 32897) Jul 30 09:30:40 x4 kernel: WTF: open(/var/cache/cups/job.cache.O, 32897) /var/spool/cups/a00018 /var/cache/cups/job.cache.O are not devices AFAICS. Yecch... AFAICS, there's a couple of places in CUPS likely to do that - cupsGetFile() and cupsdRemoveFile(); this seems to be the former. In the best case there's enough locking to make that a piece of harmless cargo-cult programming. In the worst... -- 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 0/3] PNP: Allow PNP resources to be disabled (interface)
On Sun, Jul 29, 2012 at 09:31:53PM +0200, Witold Szczeponik wrote: the aim is to select a PNP ACPI option where resources can be disabled (or are not needed). E.g., the parallel port of the 600E can be used with and without IRQ lines. The means to allow for this is to use the sysfs interface to select disabled resources (just like any other resource value). In https://lkml.org/lkml/2011/7/3/41, I used the following example: echo disable /sys/bus/pnp/devices/$device/resources echo clear /sys/bus/pnp/devices/$device/resources echo set irq disabled /sys/bus/pnp/devices/$device/resources echo fill /sys/bus/pnp/devices/$device/resources echo activate /sys/bus/pnp/devices/$device/resources The third line is made possible by the patch series. All other lines are already implemented. Shouldn't this be rather disable_irq or something which is a single word and thus would simplify parsing a lot? Also, Documentation/filesystems/sysfs.txt says Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type. Thanks. -- Regards/Gruss, Boris. -- 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/
[PATCHv6 0/2] ARM: replace custom consistent dma region with vmalloc
Hello! This is yet another quick update on the patchset which replaces custom consistent dma regions usage in dma-mapping framework in favour of generic vmalloc areas created on demand for each allocation. The main purpose for this patchset is to remove 2MiB limit of dma coherent/writecombine allocations. This version addresses a few more cleanups pointed by Minchan Kim. This patch is based on vanilla v3.5 release. Best regards Marek Szyprowski Samsung Poland RD Center Changelog: v6: - more cleanups of minor issues pointed by Minchan Kim, moved arm_dma_mmap() changes into separate patch v5: http://thread.gmane.org/gmane.linux.kernel.mm/83096 - fixed another minor issues pointed by Minchan Kim: added more comments here and there, changed pr_err() + stack_dump() to WARN(), added a fix for no-MMU systems v4: http://thread.gmane.org/gmane.linux.kernel.mm/80906 - replaced arch-independent VM_DMA flag with ARM-specific VM_ARM_DMA_CONSISTENT flag v3: http://thread.gmane.org/gmane.linux.kernel.mm/80028 - rebased onto v3.4-rc2: added support for IOMMU-aware implementation of dma-mapping calls, unified with CMA coherent dma pool - implemented changes requested by Minchan Kim: added more checks for vmarea-flags VM_DMA, renamed some variables, removed obsole locks, squashed find_vm_area() exporting patch into the main redesign patch v2: http://thread.gmane.org/gmane.linux.kernel.mm/78563 - added support for atomic allocations (served from preallocated pool) - minor cleanup here and there - rebased onto v3.4-rc7 v1: http://thread.gmane.org/gmane.linux.kernel.mm/76703 - initial version Patch summary: Marek Szyprowski (2): mm: vmalloc: use const void * for caller argument ARM: dma-mapping: remove custom consistent dma region Documentation/kernel-parameters.txt |2 +- arch/arm/include/asm/dma-mapping.h |2 +- arch/arm/mm/dma-mapping.c | 486 --- arch/arm/mm/mm.h|3 + include/linux/vmalloc.h |9 +- mm/vmalloc.c| 28 ++- 6 files changed, 194 insertions(+), 336 deletions(-) -- 1.7.1.569.g6f426 -- 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/
[PATCHv6 1/2] mm: vmalloc: use const void * for caller argument
'const void *' is a safer type for caller function type. This patch
updates all references to caller function type.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Minchan Kim minc...@kernel.org
---
include/linux/vmalloc.h |8
mm/vmalloc.c| 18 +-
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index dcdfc2b..2e28f4d 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -32,7 +32,7 @@ struct vm_struct {
struct page **pages;
unsigned intnr_pages;
phys_addr_t phys_addr;
- void*caller;
+ const void *caller;
};
/*
@@ -62,7 +62,7 @@ extern void *vmalloc_32_user(unsigned long size);
extern void *__vmalloc(unsigned long size, gfp_t gfp_mask, pgprot_t prot);
extern void *__vmalloc_node_range(unsigned long size, unsigned long align,
unsigned long start, unsigned long end, gfp_t gfp_mask,
- pgprot_t prot, int node, void *caller);
+ pgprot_t prot, int node, const void *caller);
extern void vfree(const void *addr);
extern void *vmap(struct page **pages, unsigned int count,
@@ -85,13 +85,13 @@ static inline size_t get_vm_area_size(const struct
vm_struct *area)
extern struct vm_struct *get_vm_area(unsigned long size, unsigned long flags);
extern struct vm_struct *get_vm_area_caller(unsigned long size,
- unsigned long flags, void *caller);
+ unsigned long flags, const void
*caller);
extern struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags,
unsigned long start, unsigned long end);
extern struct vm_struct *__get_vm_area_caller(unsigned long size,
unsigned long flags,
unsigned long start, unsigned long end,
- void *caller);
+ const void *caller);
extern struct vm_struct *remove_vm_area(const void *addr);
extern int map_vm_area(struct vm_struct *area, pgprot_t prot,
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 2aad499..11308f0 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1280,7 +1280,7 @@ DEFINE_RWLOCK(vmlist_lock);
struct vm_struct *vmlist;
static void setup_vmalloc_vm(struct vm_struct *vm, struct vmap_area *va,
- unsigned long flags, void *caller)
+ unsigned long flags, const void *caller)
{
vm-flags = flags;
vm-addr = (void *)va-va_start;
@@ -1306,7 +1306,7 @@ static void insert_vmalloc_vmlist(struct vm_struct *vm)
}
static void insert_vmalloc_vm(struct vm_struct *vm, struct vmap_area *va,
- unsigned long flags, void *caller)
+ unsigned long flags, const void *caller)
{
setup_vmalloc_vm(vm, va, flags, caller);
insert_vmalloc_vmlist(vm);
@@ -1314,7 +1314,7 @@ static void insert_vmalloc_vm(struct vm_struct *vm,
struct vmap_area *va,
static struct vm_struct *__get_vm_area_node(unsigned long size,
unsigned long align, unsigned long flags, unsigned long start,
- unsigned long end, int node, gfp_t gfp_mask, void *caller)
+ unsigned long end, int node, gfp_t gfp_mask, const void *caller)
{
struct vmap_area *va;
struct vm_struct *area;
@@ -1375,7 +1375,7 @@ EXPORT_SYMBOL_GPL(__get_vm_area);
struct vm_struct *__get_vm_area_caller(unsigned long size, unsigned long flags,
unsigned long start, unsigned long end,
- void *caller)
+ const void *caller)
{
return __get_vm_area_node(size, 1, flags, start, end, -1, GFP_KERNEL,
caller);
@@ -1397,7 +1397,7 @@ struct vm_struct *get_vm_area(unsigned long size,
unsigned long flags)
}
struct vm_struct *get_vm_area_caller(unsigned long size, unsigned long flags,
- void *caller)
+ const void *caller)
{
return __get_vm_area_node(size, 1, flags, VMALLOC_START, VMALLOC_END,
-1, GFP_KERNEL, caller);
@@ -1568,9 +1568,9 @@ EXPORT_SYMBOL(vmap);
static void *__vmalloc_node(unsigned long size, unsigned long align,
gfp_t gfp_mask, pgprot_t prot,
- int node, void *caller);
+ int node, const void *caller);
static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
-pgprot_t prot, int node, void *caller)
+
[PATCHv6 2/2] ARM: dma-mapping: remove custom consistent dma region
This patch changes dma-mapping subsystem to use generic vmalloc areas
for all consistent dma allocations. This increases the total size limit
of the consistent allocations and removes platform hacks and a lot of
duplicated code.
Atomic allocations are served from special pool preallocated on boot,
because vmalloc areas cannot be reliably created in atomic context.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/kernel-parameters.txt |2 +-
arch/arm/include/asm/dma-mapping.h |2 +-
arch/arm/mm/dma-mapping.c | 486 ---
arch/arm/mm/mm.h|3 +
include/linux/vmalloc.h |1 +
mm/vmalloc.c| 10 +-
6 files changed, 181 insertions(+), 323 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index a92c5eb..4ee28f3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -526,7 +526,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
coherent_pool=nn[KMG] [ARM,KNL]
Sets the size of memory pool for coherent, atomic dma
- allocations if Contiguous Memory Allocator (CMA) is
used.
+ allocations, by default set to 256K.
code_bytes [X86] How many bytes of object code to print
in an oops report.
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bbef15d..80777d87 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -226,7 +226,7 @@ static inline int dma_mmap_writecombine(struct device *dev,
struct vm_area_struc
* DMA region above it's default value of 2MB. It must be called before the
* memory allocator is initialised, i.e. before any core_initcall.
*/
-extern void __init init_consistent_dma_size(unsigned long size);
+static inline void init_consistent_dma_size(unsigned long size) { }
/*
* For SA-, IXP425, and ADI systems the dma-mapping functions are magic
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 655878b..f906d5f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -22,6 +22,7 @@
#include linux/memblock.h
#include linux/slab.h
#include linux/iommu.h
+#include linux/io.h
#include linux/vmalloc.h
#include asm/memory.h
@@ -217,115 +218,70 @@ static void __dma_free_buffer(struct page *page, size_t
size)
}
#ifdef CONFIG_MMU
+#ifdef CONFIG_HUGETLB_PAGE
+#error ARM Coherent DMA allocator does not (yet) support huge TLB
+#endif
-#define CONSISTENT_OFFSET(x) (((unsigned long)(x) - consistent_base)
PAGE_SHIFT)
-#define CONSISTENT_PTE_INDEX(x) (((unsigned long)(x) - consistent_base)
PMD_SHIFT)
-
-/*
- * These are the page tables (2MB each) covering uncached, DMA consistent
allocations
- */
-static pte_t **consistent_pte;
-
-#define DEFAULT_CONSISTENT_DMA_SIZE SZ_2M
+static void *__alloc_from_contiguous(struct device *dev, size_t size,
+pgprot_t prot, struct page **ret_page);
-static unsigned long consistent_base = CONSISTENT_END -
DEFAULT_CONSISTENT_DMA_SIZE;
+static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
+pgprot_t prot, struct page **ret_page,
+const void *caller);
-void __init init_consistent_dma_size(unsigned long size)
+static void *
+__dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
+ const void *caller)
{
- unsigned long base = CONSISTENT_END - ALIGN(size, SZ_2M);
+ struct vm_struct *area;
+ unsigned long addr;
- BUG_ON(consistent_pte); /* Check we're called before DMA region init */
- BUG_ON(base VMALLOC_END);
+ /*
+* DMA allocation can be mapped to user space, so lets
+* set VM_USERMAP flags too.
+*/
+ area = get_vm_area_caller(size, VM_ARM_DMA_CONSISTENT | VM_USERMAP,
+ caller);
+ if (!area)
+ return NULL;
+ addr = (unsigned long)area-addr;
+ area-phys_addr = __pfn_to_phys(page_to_pfn(page));
- /* Grow region to accommodate specified size */
- if (base consistent_base)
- consistent_base = base;
+ if (ioremap_page_range(addr, addr + size, area-phys_addr, prot)) {
+ vunmap((void *)addr);
+ return NULL;
+ }
+ return (void *)addr;
}
-#include vmregion.h
-
-static struct arm_vmregion_head consistent_head = {
- .vm_lock= __SPIN_LOCK_UNLOCKED(consistent_head.vm_lock),
- .vm_list= LIST_HEAD_INIT(consistent_head.vm_list),
- .vm_end = CONSISTENT_END,
-};
-
-#ifdef CONFIG_HUGETLB_PAGE
-#error ARM Coherent DMA allocator does not
Re: crash in ocfs2_fast_symlink_readpage in kernel 3.5.0
On Sun, Jul 22, 2012 at 01:16:21PM -0700, Bret Towe wrote: just booted a fresh 3.5 kernel and got the following on login via gdm on the client computer didn't see any crashes yet on any other computer but didn't give it long to try after seeing this let me know if you need more info this client is running debian wheezy 64bit This is a different stack trace than another recent report. Quick question: have you run 3.4 on this system? Joel -- There is no more evil thing on earth than race prejudice, none at all. I write deliberately -- it is the worst single thing in life now. It justifies and holds together more baseness, cruelty and abomination than any other sort of error in the world. - H. G. Wells http://www.jlbec.org/ jl...@evilplan.org -- 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] gpio: samsung: Fix off-by-one bug in gpio addresses
On 30 July 2012 13:34, 박상수 sangsu4u.p...@samsung.com wrote:
-Original Message-
From: diand...@google.com [mailto:diand...@google.com] On Behalf Of Doug
Anderson
Sent: Saturday, July 21, 2012 6:07 AM
To: Sean Paul
Cc: grant.lik...@secretlab.ca; linus.wall...@stericsson.com;
linux-kernel@vger.kernel.org;
ol...@chromium.org; Sangsu Park; Thomas Abraham; Kukjin Kim
Subject: Re: [PATCH] gpio: samsung: Fix off-by-one bug in gpio addresses
Acked-by: Doug Anderson diand...@chromium.org
---
On Fri, Jul 20, 2012 at 1:58 PM, Sean Paul seanp...@chromium.org wrote:
Move gpc4 to the end of the automatically processed gpio controllers
so we don't taint the automatic offset calculation.
This bug caused all controllers coming after gpc4 to map to the
incorrect address. The result is gpd1 0 0 0 0 would actually map to
GPIO 0 in gpd0.
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpio/gpio-samsung.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index b6453d0..e4599b4 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2454,12 +2454,6 @@ static struct samsung_gpio_chip exynos5_gpios_1[] =
{
},
}, {
.chip = {
- .base = EXYNOS5_GPC4(0),
- .ngpio = EXYNOS5_GPIO_C4_NR,
- .label = GPC4,
- },
- }, {
- .chip = {
.base = EXYNOS5_GPD0(0),
.ngpio = EXYNOS5_GPIO_D0_NR,
.label = GPD0, @@ -2513,6 +2507,12 @@
static struct samsung_gpio_chip exynos5_gpios_1[] = {
.label = GPY6,
},
}, {
+ .chip = {
+ .base = EXYNOS5_GPC4(0),
+ .ngpio = EXYNOS5_GPIO_C4_NR,
+ .label = GPC4,
+ },
+ }, {
.config = samsung_gpio_cfgs[9],
.irq_base = IRQ_EINT(0),
.chip = {
@@ -2833,7 +2833,7 @@ static __init void exynos5_gpiolib_init(void)
}
/* need to set base address for gpc4 */
- exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
+ exynos5_gpios_1[20].base = gpio_base1 + 0x2E0;
/* need to set base address for gpx */
chip = exynos5_gpios_1[21];
--
1.7.7.3
I think that this modification is right.
Thanks.
Reviewed-by: Thomas Abraham thomas.abra...@linaro.org
--
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 v2] power_supply: Add new power supply properties CHARGE_CURRENT/VOLTAGE_MAX
There are different types of chargers avalibale like AC, Solar, USB, etc..
Even in USB we have different types SDP/DCP/CDP/ACA and all these
chargers have different o/p ratings. For example SDP supports only 500mA of
charge current whereas AC charger can support upto 8A or more.
Similarly batteries also come with charge current and voltage ratings and
these ratings vary depending on its capacity and the technology used.
This patch adds two new power supply properties CONSTANT_CHARGE_CURRENT_MAX and
CONSTANT_CHARGE_CURRENT_MAX.
Signed-off-by: Ramakrishna Pallala ramakrishna.pall...@intel.com
---
Documentation/power/power_supply_class.txt |4
drivers/power/power_supply_sysfs.c |2 ++
include/linux/power_supply.h |4
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 272b122..db11122 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -115,8 +115,12 @@ be negative; there is no empty or full value. It is only
useful for
relative, time-based measurements.
CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
+CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
+power supply object.
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
+CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
+power supply object.
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 797639e..f10a402 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -161,7 +161,9 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(charge_avg),
POWER_SUPPLY_ATTR(charge_counter),
POWER_SUPPLY_ATTR(constant_charge_current),
+ POWER_SUPPLY_ATTR(constant_charge_current_max),
POWER_SUPPLY_ATTR(constant_charge_voltage),
+ POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index e7edcb3..e77a4df 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -111,7 +111,9 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CHARGE_AVG,
POWER_SUPPLY_PROP_CHARGE_COUNTER,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
@@ -252,6 +254,7 @@ static inline bool power_supply_is_amp_property(enum
power_supply_property psp)
case POWER_SUPPLY_PROP_CHARGE_AVG:
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
case POWER_SUPPLY_PROP_CURRENT_MAX:
case POWER_SUPPLY_PROP_CURRENT_NOW:
case POWER_SUPPLY_PROP_CURRENT_AVG:
@@ -280,6 +283,7 @@ static inline bool power_supply_is_watt_property(enum
power_supply_property psp)
case POWER_SUPPLY_PROP_VOLTAGE_AVG:
case POWER_SUPPLY_PROP_VOLTAGE_OCV:
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
case POWER_SUPPLY_PROP_POWER_NOW:
return 1;
default:
--
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/
[GPIO] Crashed when not using
Hi All, I tried using gpio as an interrupt line for my driver (drivers/staging/iio/light/tsl2x7x_core.c) for omap5. The interrupt line number was directly passed to the driver using device tree. But what I observed is the following crash.. [1.599273] mousedev: PS/2 mouse device common for all mice [1.607513] i2c /dev entries driver [1.613739] Driver for 1-wire Dallas network protocol. [1.622650] usbcore: registered new interface driver usbhid [1.628540] usbhid: USB HID core driver [1.633728] Unhandled fault: imprecise external abort (0x1406) at 0x [1.641113] Internal error: : 1406 [#1] SMP ARM [1.645874] Modules linked in: [1.649078] CPU: 0Not tainted (3.5.0-02045-g0b474d6-dirty #415) [1.655761] PC is at _set_gpio_triggering+0x44/0x264 [1.660980] LR is at gpio_irq_type+0xb8/0x160 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093 [1.665527] sp : dc851df0 ip : c07a8f00 fp : [1.677581] r10: 0081 r9 : r8 : dc8ffc10 [1.683074] r7 : 2093 r6 : r5 : 0001 r4 : fa05b000 [1.689910] r3 : dc8ffc10 r2 : 0002 r1 : 0002 r0 : 0140 [1.696746] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [1.704528] Control: 10c53c7d Table: 8000406a DAC: 0017 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8) [1.716857] Stack: (0xdc851df0 to 0xdc852000) [1.721405] 1de0: 0002 c0731280 dc8ffc6c 2093 [1.730010] 1e00: c02dc224 c0731280 dc8d4980 c07a8e50 0141 0002 c00a37b8 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4 c07312b4 4013 c00a3d7c [1.747161] 1e40: 0141 c06728c0 c0090578 c247f000 c00a2d5c c0412258 0141 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0 2002 c071bed8 c247f000 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0 c04ea344 c06728c0 c247f000 [1.772888] 1ea0: 09090578 c07bf6a0 dc9df004 dc9df000 c04ea194 0091 c071bed8 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8 dc9df054 c07bf60c c03272ac [1.790069] 1ee0: dc9df020 c07bf60c dc9df054 0091 c03274c0 c07bf60c dc851f08 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 c07bf60c c07bcea8 c243d6c0 [1.807220] 1f20: c0326240 c0672958 c02bce08 c07bf5e4 c07bf60c c03e12a0 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4 0007 c07c8c40 [1.824401] 1f60: 0091 c03e1738 dc85 0007 c0008648 c112c9f0 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8 0006 0006 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c 0091 c071bed8 c0700a28 [1.850128] 1fc0: c06d0380 0006 0006 c06d020c c06d028c [1.858703] 1fe0: c001548c 0013 c001548c 3f3f3f3f 3f3f3f3f [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from [c02dc224] (gpio_irq_type+0x0/0x160) [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] (0x2002) [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc) [1.890960] [ cut here ] [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113 l3_interrupt_handler+0x184/0x1bc() [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2 [1.910430] Modules linked in: [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from [c00414c4] (warn_slowpath_common+0x4c/0x64) [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from [c0041570] (warn_slowpath_fmt+0x30/0x40) [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from [c0035de4] (l3_interrupt_handler+0x184/0x1bc) [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from [c00a2adc] (handle_irq_event+0x3c/0x5c) [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from [c00a235c] (generic_handle_irq+0x34/0x44) [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from [c00153a0] (handle_IRQ+0x4c/0xac) [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480] (gic_handle_irq+0x2c/0x60) [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from [c04f26e4] (__irq_svc+0x44/0x60) [2.011718] Exception stack(0xdc851c48 to 0xdc851c90) [2.017028] 1c40: c07a87a0 dc851c80 c0743f80 dc851da8 [2.025604] 1c60: 0001 0001 dc851cd7 c02dbb6a c02dbb6c dc851c90 [2.034179] 1c80: c04f2440 c04f2444 6113 [2.039489] [c04f26e4] (__irq_svc+0x44/0x60) from [c04f2444] (_raw_spin_unlock_irq+0x28/0x2c) [2.048797] [c04f2444]
[Regression][Bisected] tick_broadcast_mask is not restored after a CPU is offline/onlined
Hi All,
[seems the email from my intel email address didn't hit the list,
resend with gmail, sorry for the noise]
When I debugged a suspend/resume bug, I found that tick_broadcast_mask is not
restored for a CPU after it is offline/onlined since kernel 3.4, while it's
fine for 3.3.
Further check show it is caused by the commit 9505626d7bfe
ACPI: Fix unprotected smp_processor_id() in acpi_processor_cst_has_changed()
The acpi_processor_cst_has_changed() function is invoked from a
CPU_ONLINE or CPU_DEAD function, which might well execute on CPU 0
even though the CPU being hotplugged is some other CPU. In addition,
acpi_processor_cst_has_changed() invokes smp_processor_id() without
protection, resulting in splats when onlining CPUs.
This commit therefore changes the smp_processor_id() to pr-id, as is
used elsewhere in the code, for example, in acpi_processor_add().
Signed-off-by: Paul E. McKenney paul.mcken...@linaro.org
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 0e8e2de..9e57b06 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1159,8 +1159,7 @@ int acpi_processor_cst_has_changed(struct
acpi_processor *pr)
* to make the code that updates C-States be called once.
*/
- if (smp_processor_id() == 0
- cpuidle_get_driver() == acpi_idle_driver) {
+ if (pr-id == 0 cpuidle_get_driver() == acpi_idle_driver) {
cpuidle_pause_and_lock();
/* Protect against cpu-hotplug */
The root cause is acpi_processor_cst_has_changed() will also be called when
cpu_up() is run on cpu 0 to boot up other cpu, this commit will prevent the
following code be run for that cpu, which triggers some side effect like the
broadcast_mask is not restored.
I raise this problem up and I don't if revert is a good solution here.
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: drm/nouveau: crash regression in 3.5
Hey, Op 29-07-12 22:15, Marcin Slusarz schreef: On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: On 25.07.2012 20:42, Marcin Slusarz wrote: Good, below patch should fix this panic. Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?). After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached. Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing... No, the real problem is: with noaccel we don't register software engine, but vblank ISR relies on its existance and happily derefences NULL pointer. Now, this patch should fix it for real... --- From: Marcin Slusarz marcin.slus...@gmail.com Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering PDISPLAY ISR Currently, we register vblank IRQ handler and later we disable vblank interrupts. So, for the short amount of time, we rely on vblank ISR to operate correctly, even if vblank interrupts are never going to be used later. In noaccel case, software engine - which is used by vblank ISR - is not registered, so if vblank interrupt triggers in a wrong moment, we can hit NULL pointer dereference in nouveau_software_vblank. To fix it, disable vblank interrupts before registering PDISPLAY ISR. Reported-by: Ortwin Glück o...@odi.ch Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com Cc: sta...@vger.kernel.org [3.5] I can confirm this bug when I was working on adding d0 vblank, but it seems to me like nv*_display_create would be a more logical place to put the disable call. This will make it more clear that vblank is disabled before the irq is registered. Also maybe add a WARN_ON(!nv_engine(dev, NVOBJ_ENGINE_SW)); in nouveau_vblank_enable and/or return -EINVAL in that case? If you add the modification to nouveau_vblank_enable: Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com ~Maarten -- 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] Add Etron XHCI quirk to avoid warning spam
On 28 July 2012 01:10, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Fri, Jul 27, 2012 at 02:40:56PM +0800, Daniel J Blueman wrote: On 27 July 2012 14:14, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Fri, Jul 27, 2012 at 12:03:44PM +0800, Daniel J Blueman wrote: When various USB3 devices with Etron XHCI controllers, we see a bunch of warnings: xhci_hcd :02:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Acknowledge the issue by adding the quirk. Signed-off-by: Daniel J Blueman dan...@quora.org [] I already have a patch in my queue for this. However, it keys off the PCI_DEVICE_ID_ASROCK_P67 PCI device ID. Do you have another Etron device with a different device ID that needs this quirk? Yes, the subsystem ID is different [1] (but Zotac program it the same as the vendor and device IDs here), however what you say suggests the problem is general to this Etron XHCI controller (1b6f:7023), as we'd suspect anyway. Thus the more general patch I posted makes better sense perhaps? I'd really like to keep this quirk specific to the particular PCI vendor and device ID. It's possible that their next chip version will have the opposite issue (short TX completion code and bad untransferred length). Your patch turned it on for all Etron hosts, so I would rather keep my version: http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=commit;h=12751f75720391bb2b607acdb2537f02e313251e [] Ok, the patch is correct since PCI_DEVICE_ID_ASROCK_P67 evaluates to 0x7023, which is the Etron EJ168 device ID. Board-specific IDs (as the definition name suggests) are used for the subsystem IDs, so this name is misleading (and misled me at least). Can you fix this up with a patch to change PCI_DEVICE_ID_ASROCK_P67 to PCI_DEVICE_ID_ETRON_EJ168, else I can cook and test a patch? Thanks, Daniel -- Daniel J Blueman -- 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: virtio(-scsi) vs. chained sg_lists (was Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list)
On 07/30/2012 10:12 AM, Paolo Bonzini wrote: Il 30/07/2012 01:50, Rusty Russell ha scritto: Also, being the first user of chained scatterlist doesn't exactly give me warm fuzzies. We're far from the first user: they've been in the kernel for well over 7 years. They were introduced for the block layer, but they tended to ignore private uses of scatterlists like this one. Yeah, but sg_chain has no users in drivers, only a private one in lib/scatterlist.c. The internal API could be changed to something else and leave virtio-scsi screwed... Yes, we should do this. But note that this means an iteration, so we might as well combine the loops :) I'm really bad at posting pseudo-code, but you can count the number of physically-contiguous entries at the beginning of the list only. So if everything is contiguous, you use a single non-indirect buffer and save a kmalloc. If you use indirect buffers, I suspect it's much less effective to collapse physically-contiguous entries. More elaborate heuristics do need a loop, though. [All the below with a grain of salt, from my senile memory] You must not forget some facts about the scatterlist received here at the LLD. It has already been DMA mapped and locked by the generic layer. Which means that the DMA engine has already collapsed physically-contiguous entries. Those you get here are already unique physically. (There were bugs in the past, where this was not true, please complain if you find them again) A scatterlist is two different lists taking the same space, but with two different length. - One list is the PAGE pointers plus offset length, which is bigger or equal to the 2nd list. The end marker corresponds to this list. This list is the input into the DMA engine. - Second list is the physical DMA addresses list. With their physical-lengths. Offset is not needed because it is incorporated in the DMA address. This list is the output from the DMA engine. The reason 2nd list is shorter is because the DMA engine tries to minimize the physical scatter-list entries which is usually a limited HW resource. This list might follow chains but it's end is determined by the received sg_count from the DMA engine, not by the end marker. At the time my opinion, and I think Rusty agreed, was that the scatterlist should be split in two. The input page-ptr list is just the BIO, and the output of the DMA-engine should just be the physical part of the sg_list, as a separate parameter. But all this was berried under too much APIs and the noise was two strong, for any single brave sole. So I'd just trust blindly the returned sg_count from the DMA engine, it is already optimized. I THINK Paolo Boaz -- 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: [ 13/40] vmscan: shrinker-nr updates race and go wrong
On Sun, Jul 29, 2012 at 09:29:30PM +0100, Ben Hutchings wrote:
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -251,17 +251,29 @@ unsigned long shrink_slab(struct shrink_
unsigned long total_scan;
[...]
+ total_scan += delta;
+ if (total_scan 0) {
[...]
This condition is never true since total_scan is unsigned.
I think 3.0.y needs this as well:
commit 635697c663f38106063d5659f0cf2e45afcd4bb5
Author: Konstantin Khlebnikov khlebni...@openvz.org
Date: Thu Dec 8 14:33:51 2011 -0800
vmscan: fix initial shrinker size handling
You're right, thanks for pointing it out as I missed it. Greg, this commit
is already in 3.2 but can you pick it up for 3.0-stable please?
---8---
vmscan: fix initial shrinker size handling
commit 635697c663f38106063d5659f0cf2e45afcd4bb5 upstream.
Stable note: The commit [acf92b48: vmscan: shrinker-nr updates race and
go wrong] aimed to reduce excessive reclaim of slab objects but
had bug in how it treated shrinker functions that returned -1.
A shrinker function can return -1, means that it cannot do anything
without a risk of deadlock. For example prune_super() does this if it
cannot grab a superblock refrence, even if nr_to_scan=0. Currently we
interpret this -1 as a ULONG_MAX size shrinker and evaluate `total_scan'
according to this. So the next time around this shrinker can cause
really big pressure. Let's skip such shrinkers instead.
Also make total_scan signed, otherwise the check (total_scan 0) below
never works.
Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
Cc: Dave Chinner da...@fromorbit.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/vmscan.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index e0afff3..bd8a540 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -248,12 +248,16 @@ unsigned long shrink_slab(struct shrink_control *shrink,
list_for_each_entry(shrinker, shrinker_list, list) {
unsigned long long delta;
- unsigned long total_scan;
- unsigned long max_pass;
+ long total_scan;
+ long max_pass;
int shrink_ret = 0;
long nr;
long new_nr;
+ max_pass = do_shrinker_shrink(shrinker, shrink, 0);
+ if (max_pass = 0)
+ continue;
+
/*
* copy the current shrinker scan count into a local variable
* and zero it so that other concurrent shrinker invocations
@@ -264,7 +268,6 @@ unsigned long shrink_slab(struct shrink_control *shrink,
} while (cmpxchg(shrinker-nr, nr, 0) != nr);
total_scan = nr;
- max_pass = do_shrinker_shrink(shrinker, shrink, 0);
delta = (4 * nr_pages_scanned) / shrinker-seeks;
delta *= max_pass;
do_div(delta, lru_pages + 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/
[PATCH v6 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 --
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0c610b4 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include plat/usb.h
#include control.h
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err(control module ioremap failed\n);
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
- if (IS_ERR(phyclk)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
- if (IS_ERR(clk48m)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, usb_phy_cm_clk32k);
- if (IS_ERR(clk32k)) {
- dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
-
[PATCH v6 00/11] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v5: minor cleanups like checking for return value in get_sync and few changes in the documentation has been done. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 49 .../devicetree/bindings/usb/twl-usb.txt| 40 +++ arch/arm/boot/dts/omap3-beagle.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3.dtsi |8 + arch/arm/boot/dts/omap4-panda.dts | 10 + arch/arm/boot/dts/omap4-sdp.dts| 10 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/boot/dts/twl4030.dtsi | 21 ++ arch/arm/boot/dts/twl6030.dtsi |5 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 106 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/Kconfig| 10 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/omap-usb2.c| 280 drivers/usb/otg/twl4030-usb.c | 26 +- drivers/usb/otg/twl6030-usb.c | 153 +++ include/linux/usb/omap_usb.h | 45 include/linux/usb/phy_companion.h | 34 +++ 24 files changed, 713 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 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/
[PATCH v6 06/11] arm/dts: Add twl6030-usb data
Add twl6030-usb data node in twl6030 device tree file
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |4
arch/arm/boot/dts/omap4-sdp.dts |4
arch/arm/boot/dts/twl6030.dtsi|5 +
3 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..7052422 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,7 @@
ti,non-removable;
bus-width = 4;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..6326d7c 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,7 @@
bus-width = 4;
ti,non-removable;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..8e3aac9 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -83,4 +83,9 @@
clk32kg: regulator@12 {
compatible = ti,twl6030-clk32kg;
};
+
+ twlusb: twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ };
};
--
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/
[PATCH v6 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 249ff76..775e185 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5934,6 +5934,11 @@ static struct omap_hwmod_addr_space
omap44xx_wd_timer2_addrs[] = {
.pa_end = 0x4a31407f,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
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: [2/3][PATCH][v2] TDM Framework
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
KH
Sent: Friday, July 27, 2012 11:30 PM
To: Singh Sandeep-B37400
Cc: de...@driverdev.osuosl.org; linuxppc-...@lists.ozlabs.org; linux-arm-
ker...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [2/3][PATCH][v2] TDM Framework
On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
+/* Data structures required for sysfs */ static struct tdm_sysfs attr
+= {
+ .attr.name = use_latest_data,
+ .attr.mode = 0664,
+ .cmd_type = TDM_LATEST_DATA,
+};
What is this for?
This knob is to control the behavior of the TDM framework with respect to
handling the received TDM frames.
The framework layer receives the TDM frames from the TDM adapter driver,
de-interleaves the data and sends to respective client modules.
In the case when the TDM client module has not consumed the data and emptied
the Buffer, this flag decides whether to discard the un-fetched data, or
discard the latest received data.
+int tdm_sysfs_init(void)
+{
+ struct kobject *tdm_kobj;
+ int err = 1;
+ tdm_kobj = kzalloc(sizeof(*tdm_kobj), GFP_KERNEL);
+ if (tdm_kobj) {
+ kobject_init(tdm_kobj, tdm_type);
+ if (kobject_add(tdm_kobj, NULL, %s, tdm)) {
+ pr_err(tdm: Sysfs creation failed\n);
+ kobject_put(tdm_kobj);
+ err = -EINVAL;
+ goto out;
+ }
+ } else {
+ pr_err(tdm: Unable to allocate tdm_kobj\n);
+ err = -ENOMEM;
+ goto out;
+ }
+
+out:
+ return err;
+}
You just leaked memory, what are you trying to do here?
And why are you using raw kobjects? That's a sure sign that something
is really wrong.
Will refer the documentation. Not very experienced on this stuff. Thanks for
the comment.
Your code doesn't look like it is tied into the driver model at all, why
not? What are you trying to do here?
This is a framework layer, not associated to a particular device. TDM adapter
drivers will register to this framework.
We got this comment in internal freescale review list also.
Also, when creating new sysfs entries, like you are attempting to do here
(unsuccessfully I might add), you must create Documentation/ABI/ files as
well.
Ok.
And, to top it all off, you do realize you are asking us to do code
review in the middle of the merge window, when we are all busy doing
other things?
Apologize for asking a review in the merge window time frame.
Are there any guidelines when to send something for a review? We will be
careful next time.
Regards
Poonam
greg k-h
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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 v6 02/11] arm/dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29c6243..15f1890 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+ };
};
};
};
--
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/
[PATCH v6 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 +++-
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 52f503b..49a90fb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -15,3 +15,35 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58,
0x4a002300 0x1;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..5db228f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,42 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+ .compatible = ti,omap4-musb
+ },
+ {
+
[PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt |3 +
Documentation/devicetree/bindings/usb/omap-usb.txt | 17 ++
drivers/usb/otg/Kconfig| 10 +
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c| 280
include/linux/usb/omap_usb.h | 45
include/linux/usb/phy_companion.h | 34 +++
7 files changed, 390 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index d2fe064..bb0c7f4 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -8,3 +8,6 @@ properties:
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
+- usb2phy :
+ The binding details of usb2phy can be found in:
+ Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..52f503b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,17 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on OMAP_OCP2SCP
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..026cb3c
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,280 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
[PATCH v6 08/11] arm/dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
+ vusb1v5: regulator-vusb1v5 {
+ compatible = ti,twl4030-vusb1v5;
+ };
+
+ vusb1v8: regulator-vusb1v8 {
+ compatible = ti,twl4030-vusb1v8;
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = ti,twl4030-vusb3v1;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+ };
};
--
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/
[PATCH v6 10/11] arm/dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
mmc3 {
status = disable;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..4b8c142 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,omap3-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 7052422..dd19370 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -93,3 +93,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 6326d7c..0fc10d4 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -162,3 +162,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 15f1890..7886518 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
0x4a002300 0x1;
};
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
--
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/
[PATCH v6 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl4030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 19 ++
drivers/usb/otg/twl4030-usb.c | 26 +++-
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index 930f9ff..36b9aed 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -19,3 +19,22 @@ Board specific device node entry
twl6030-usb {
usb-supply = vusb;
};
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be ti,twl4030-usb
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts
+ and VBUS interrupts. The second interrupt number is optional.
+ - supply-name-supply : phandle to the regulator device tree node.
+ supply-name should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. 1
+ specifies ULPI mode and 2 specifies CEA2011_3PIN mode.
+
+twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..f0d2e75 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb *twl;
int status, err;
struct usb_otg *otg;
-
- if (!pdata) {
- dev_dbg(pdev-dev, platform_data not available\n);
- return -EINVAL;
- }
+ struct device_node *np = pdev-dev.of_node;
twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ if (np)
+ of_property_read_u32(np, usb_mode,
+ (enum twl4030_usb_mode *)twl-usb_mode);
+ else if (pdata)
+ twl-usb_mode = pdata-usb_mode;
+ else {
+ dev_err(pdev-dev, twl4030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
- twl-usb_mode = pdata-usb_mode;
twl-vbus_supplied = false;
twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+ { .compatible = ti,twl4030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#endif
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_usb_id_table),
},
};
--
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: [2/3][PATCH][v2] TDM Framework
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
KH
Sent: Friday, July 27, 2012 11:42 PM
To: Singh Sandeep-B37400
Cc: de...@driverdev.osuosl.org; linuxppc-...@lists.ozlabs.org; linux-arm-
ker...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [2/3][PATCH][v2] TDM Framework
On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
+static struct kobj_type tdm_type = {
+ .sysfs_ops = tdm_ops,
+ .default_attrs = tdm_attr,
+};
Ah, also, as per the documentation in the kernel (go look, it's there), I
now get to publicly mock you for ignoring the error messages that the
kernel is giving you when you try to shut down your code path.
Well, to be fair, you are leaking memory like a sieve, so I doubt you
ever saw those error messages because you never cleaned up after
yourself, so perhaps I can forgive you, but your users can't, sorry.
They like to rely on the fact that Linux is a reliable operating system,
don't cause them to doubt that.
Please fix this code, it's horribly broken. Read
Documentation/kobject.txt for why. That file was written for a reason,
and not just because we like writing documentation (hint, we hate to...)
To be honest we are not sysfs experts. Thanks for pointing to the documentation.
We will rework the stuff.
Regards
Poonam
Ugh,
greg k-h
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks on v3.6
On 07/30/2012 07:36 AM, Avi Kivity wrote: On 07/30/2012 12:05 AM, Sasha Levin wrote: On 07/29/2012 02:48 PM, Avi Kivity wrote: On 07/27/2012 02:27 PM, Sasha Levin wrote: On 07/26/2012 01:42 PM, Avi Kivity wrote: On 07/24/2012 08:10 PM, Sasha Levin wrote: [ 215.026612] NMI backtrace for cpu 1 [ 215.026612] CPU 1 [ 215.026612] Pid: 2395, comm: pageattr-test Tainted: GW 3.5.0-sasha-01644-g824681b #267 [ 215.026612] RIP: 0010:[8109bd5a] [8109bd5a] native_write_msr_safe+0xa/0x10 [ 215.026612] RSP: 0018:88001b803f70 EFLAGS: 0046 [ 215.026612] RAX: RBX: ef80 RCX: 080b [ 215.026612] RDX: RSI: RDI: 080b [ 215.026612] RBP: 88001b803f70 R08: 3000 R09: 8800 [ 215.026612] R10: 0001 R11: R12: [ 215.026612] R13: 880007a98000 R14: 88001fc3a4b8 R15: 8800 [ 215.026612] FS: () GS:88001b80() knlGS: [ 215.026612] CS: 0010 DS: ES: CR0: 8005003b [ 215.026612] CR2: 000c CR3: 19dcf000 CR4: 000406e0 [ 215.026612] DR0: DR1: DR2: [ 215.026612] DR3: DR6: 0ff0 DR7: 0400 [ 215.026612] Process pageattr-test (pid: 2395, threadinfo 88000ced, task 88000d773000) [ 215.026612] Stack: [ 215.026612] 88001b803f88 81095d07 ef80 88001b803fa8 [ 215.026612] 810901c4 88000ced1db0 7a98 88000ced1d00 [ 215.026612] 8369c4af 88000ced1c78 EOI 88000ced1d00 8369aeb4 [ 215.026612] Call Trace: [ 215.026612] IRQ [ 215.026612] [81095d07] native_apic_msr_eoi_write+0x27/0x30 [ 215.026612] [810901c4] smp_apic_timer_interrupt+0x34/0xa0 [ 215.026612] [8369c4af] apic_timer_interrupt+0x6f/0x80 [ 215.026612] EOI [ 215.026612] [8369aeb4] ? retint_restore_args+0x13/0x13 [ 215.026612] [810a2cb2] ? lookup_address+0x112/0x170 [ 215.026612] [810a32ae] print_split+0x7e/0x200 [ 215.026612] [810a4300] pageattr_test+0x80/0x4a0 [ 215.026612] [8114a2f8] ? trace_hardirqs_on_caller+0x118/0x140 [ 215.026612] [83696cbe] ? schedule_timeout+0x2ce/0x370 [ 215.026612] [8369aeb4] ? retint_restore_args+0x13/0x13 [ 215.026612] [810a4720] ? pageattr_test+0x4a0/0x4a0 [ 215.026612] [810a473f] do_pageattr_test+0x1f/0x50 [ 215.026612] [8110607d] kthread+0xad/0xc0 [ 215.026612] [8369cdb4] kernel_thread_helper+0x4/0x10 [ 215.026612] [8369aeb4] ? retint_restore_args+0x13/0x13 [ 215.026612] [81105fd0] ? kthread_flush_work_fn+0x10/0x10 [ 215.026612] [8369cdb0] ? gs_change+0x13/0x13 [ 215.026612] Code: 00 55 89 f9 48 89 e5 0f 32 45 31 c0 89 c7 48 89 d0 44 89 06 48 c1 e0 20 89 f9 5d 48 09 c8 c3 66 90 55 89 f0 89 f9 48 89 e5 0f 30 31 c0 5d c3 66 90 55 89 f9 48 89 e5 0f 33 89 c7 48 89 d0 5d 48 This is immediately after the EOI. It looks like the timer interrupt is stuck somehow. Can you run kvm_stat and confirm? Yup, looks like it. kvm_stats is something like this: kvm_entry142104033 939393 kvm_exit 142104004 939390 kvm_apic 84781115 582714 kvm_msr 84682085 582714 kvm_apic_accept_irq 65219959 522263 kvm_inj_virq 43173709 291385 With everything else at 0 when it happens. Please run a trace and verify that the injected vector is indeed the timer interrupt. Looks like it is. Then work backwards to see the last place it is programmed (APIC_TMICT/APIC_TDCR). This looks like what you're looking for: kvm_apic: apic_write APIC_TMICT = 0x3e Basically it's spinning on the following 4 lines of trace when it happens: 16063.549189: kvm_apic: apic_write APIC_TMICT = 0x3e 16063.549190: kvm_msr: msr_write 838 = 0x3e 16063.549190: kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8115de02 info 0 0 16063.549190: kvm_entry: vcpu 2 What, no kvm_inj_virq? Are you running with pveoi? Try disabling it. I must have looked at a block in the logfile which doesn't represent everything thats going on, sorry. Here's a more complete picture: vm-16567 [000] d..2 16063.549298: kvm_exit: reason PENDING_INTERRUPT rip 0x83625c80 info 0 0 vm-16567 [000] ...1 16063.549299: kvm_inj_virq: irq 239 vm-16567 [000] d..2 16063.549300: kvm_entry: vcpu 0 vm-16567 [000] d..2 16063.549301: kvm_exit: reason MSR_WRITE rip 0x8109fef8 info 0 0 vm-16567 [000] ...1
[PATCH v6 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 52 ---
drivers/usb/musb/omap2430.h |9
drivers/usb/otg/twl6030-usb.c | 114 +
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue-control_otghs)
+ writel(val, glue-control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
- usb_phy_shutdown(musb-xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue =
[PATCH v6 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 21 +++
drivers/usb/otg/twl6030-usb.c | 39 +---
2 files changed, 47 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..930f9ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,21 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ usb interrupt number that raises VBUS interrupts when the controller has to
+ act as device
+ - usb-supply : phandle to the regulator device tree node. It should be vusb
+ if it is twl6030 or ldousb if it is twl6025 subclass.
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+};
+
+Board specific device node entry
+twl6030-usb {
+ usb-supply = vusb;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..f29c9ef 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#definecomparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev = pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev = pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,24 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev= pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
twl-irq2 = platform_get_irq(pdev, 1);
- twl-features = pdata-features;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ twl-regulator = usb;
+ } else if (pdata) {
+ if (pdata-features TWL6025_SUBCLASS)
+ twl-regulator = ldousb;
+ else
+ twl-regulator = vusb;
+ } else {
+ dev_err(pdev-dev, twl6030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -403,12 +407,21 @@ static int __exit twl6030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+ { .compatible = ti,twl6030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#endif
+
static struct platform_driver twl6030_usb_driver = {
.probe = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
.driver = {
.name = twl6030_usb,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl6030_usb_id_table),
Re: [PATCH] rtc: tps65910: Add RTC driver for TPS65910 PMIC RTC
On 7/25/2012 11:35 PM, Venu Byravarasu wrote:
+
+static struct rtc_class_ops tps65910_rtc_ops = {
const?
+ .read_time = tps65910_rtc_read_time,
+ .set_time = tps65910_rtc_set_time,
+ .read_alarm = tps65910_rtc_read_alarm,
+ .set_alarm = tps65910_rtc_set_alarm,
+ .alarm_irq_enable = tps65910_rtc_alarm_irq_enable,
+};
+
+static int __devinit tps65910_rtc_probe(struct platform_device *pdev)
+{
+ struct tps65910 *tps65910 = NULL;
+ struct tps65910_rtc *tps_rtc = NULL;
+ struct tps65910_board *pmic_plat_data;
+ int ret = -EINVAL;
+ int irq = 0;
+ u32 rtc_reg;
It seems like all the above assignments are useless as they're
overwritten later in this function. Can you remove the assignments?
+
+ tps65910 = dev_get_drvdata(pdev-dev.parent);
+
+ tps_rtc = devm_kzalloc(pdev-dev, sizeof(struct tps65910_rtc),
+ GFP_KERNEL);
+ if (!tps_rtc)
+ return -ENOMEM;
+
+ /* Clear pending interrupts */
+ ret = regmap_read(tps65910-regmap, TPS65910_RTC_STATUS, rtc_reg);
+ if (ret 0)
+ return ret;
+
+ ret = regmap_write(tps65910-regmap, TPS65910_RTC_STATUS, rtc_reg);
+ if (ret 0)
+ return ret;
+
+ dev_dbg(pdev-dev, Enabling tps65910-RTC.\n);
Hmph, looks more like stopping the RTC.
+ rtc_reg = TPS65910_RTC_CTRL_STOP_RTC;
+ ret = regmap_write(tps65910-regmap, TPS65910_RTC_CTRL, rtc_reg);
+ if (ret 0)
+ return ret;
+
+ pmic_plat_data = dev_get_platdata(tps65910-dev);
+ irq = pmic_plat_data-irq_base;
+ if (irq = 0) {
+ dev_warn(pdev-dev, Wake up is not possible as irq = %d\n,
+ irq);
+ return ret;
+ }
+
+ irq += TPS65910_IRQ_RTC_ALARM;
+ ret = devm_request_threaded_irq(pdev-dev, irq, NULL,
+ tps65910_rtc_interrupt, IRQF_TRIGGER_LOW,
+ dev_name(tps_rtc-rtc-dev), pdev-dev);
How does this work? It doesn't look like tps_rtc-rtc is assigned until
down there at the rtc_device_register() call.
+ if (ret 0) {
+ dev_err(pdev-dev, IRQ is not free.\n);
+ return ret;
+ }
+ device_init_wakeup(pdev-dev, 1);
+
+ tps_rtc-rtc = rtc_device_register(pdev-name, pdev-dev,
+ tps65910_rtc_ops, THIS_MODULE);
+ if (IS_ERR(tps_rtc-rtc)) {
+ ret = PTR_ERR(tps_rtc-rtc);
+ dev_err(pdev-dev, RTC device register: err %d\n, ret);
+ return ret;
+ }
+
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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: [2/3][PATCH][v2] TDM Framework
-Original Message- From: John Stoffel [mailto:j...@stoffel.org] Sent: 27 July 2012 19:42 To: Singh Sandeep-B37400 Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; ga...@kernel.crashing.org; linux-kernel@vger.kernel.org; de...@driverdev.osuosl.org Subject: Re: [2/3][PATCH][v2] TDM Framework From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. Please don't use TLAs (Three Letter Acronyms) like TDM without explaining the clearly and up front. It makes it hard for anyone else who doens't know your code to look it over without having to spend lots of time poking around to figure it out from either context or somewhere else. [Sandeep] Patch for documentation for TDM is present in this patch set, which explains TDM in detail. Should we do this in commit message too?? Link too documentation patch: http://patchwork.ozlabs.org/patch/173680/ 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/
Re: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks on v3.6
On 07/30/2012 12:13 PM, Sasha Levin wrote: Yup, looks like it. kvm_stats is something like this: kvm_entry142104033 939393 kvm_exit 142104004 939390 kvm_apic 84781115 582714 kvm_msr 84682085 582714 kvm_apic_accept_irq 65219959 522263 kvm_inj_virq 43173709 291385 With everything else at 0 when it happens. Please run a trace and verify that the injected vector is indeed the timer interrupt. Looks like it is. Then work backwards to see the last place it is programmed (APIC_TMICT/APIC_TDCR). This looks like what you're looking for: kvm_apic: apic_write APIC_TMICT = 0x3e What about APIC_TMICT? Might be configured just once on boot. Basically it's spinning on the following 4 lines of trace when it happens: 16063.549189: kvm_apic: apic_write APIC_TMICT = 0x3e 16063.549190: kvm_msr: msr_write 838 = 0x3e 16063.549190: kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8115de02 info 0 0 16063.549190: kvm_entry: vcpu 2 What, no kvm_inj_virq? Are you running with pveoi? Try disabling it. What's the answer to this question? I must have looked at a block in the logfile which doesn't represent everything thats going on, sorry. Here's a more complete picture: vm-16567 [000] d..2 16063.549298: kvm_exit: reason PENDING_INTERRUPT rip 0x83625c80 info 0 0 vm-16567 [000] ...1 16063.549299: kvm_inj_virq: irq 239 vm-16567 [000] d..2 16063.549300: kvm_entry: vcpu 0 vm-16567 [000] d..2 16063.549301: kvm_exit: reason MSR_WRITE rip 0x8109fef8 info 0 0 vm-16567 [000] ...1 16063.549302: kvm_apic: apic_write APIC_EOI = 0x0 vm-16567 [000] ...1 16063.549302: kvm_msr: msr_write 80b = 0x0 vm-16567 [000] d..2 16063.549303: kvm_entry: vcpu 0 vm-16567 [000] d..2 16063.549308: kvm_exit: reason MSR_WRITE rip 0x8109fef8 info 0 0 vm-16567 [000] ...1 16063.549309: kvm_apic: apic_write APIC_TMICT = 0x3e vm-16567 [000] ...1 16063.549310: kvm_msr: msr_write 838 = 0x3e vm-16567 [000] d..2 16063.549311: kvm_entry: vcpu 0 vm-16567 [000] d..2 16063.549312: kvm_exit: reason PENDING_INTERRUPT rip 0x83625c80 info 0 0 This must refer to a lower priority interrupt, since 239 hasn't been injected yet. vm-16567 [000] ...1 16063.549314: kvm_apic_accept_irq: apicid 0 vec 239 (Fixed|edge) And now conveniently the hrtimer fires and injects another interrupt. vm-16567 [000] ...1 16063.549315: kvm_inj_virq: irq 239 vm-16567 [000] d..2 16063.549315: kvm_entry: vcpu 0 vm-16567 [000] d..2 16063.549316: kvm_exit: reason MSR_WRITE rip 0x8109fef8 info 0 0 vm-16567 [000] ...1 16063.549318: kvm_apic: apic_write APIC_EOI = 0x0 vm-16567 [000] ...1 16063.549318: kvm_msr: msr_write 80b = 0x0 Please add hrtimer_start and hrtimer_expire_entry to your traced events. -- error compiling committee.c: too many arguments to function -- 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: [GPIO] Crashed when not using
Sourav, On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote: Hi All, I tried using gpio as an interrupt line for my driver (drivers/staging/iio/light/tsl2x7x_core.c) for omap5. The interrupt line number was directly passed to the driver using device tree. But what I observed is the following crash.. [1.599273] mousedev: PS/2 mouse device common for all mice [1.607513] i2c /dev entries driver [1.613739] Driver for 1-wire Dallas network protocol. [1.622650] usbcore: registered new interface driver usbhid [1.628540] usbhid: USB HID core driver [1.633728] Unhandled fault: imprecise external abort (0x1406) at 0x [1.641113] Internal error: : 1406 [#1] SMP ARM [1.645874] Modules linked in: [1.649078] CPU: 0Not tainted (3.5.0-02045-g0b474d6-dirty #415) [1.655761] PC is at _set_gpio_triggering+0x44/0x264 [1.660980] LR is at gpio_irq_type+0xb8/0x160 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093 [1.665527] sp : dc851df0 ip : c07a8f00 fp : [1.677581] r10: 0081 r9 : r8 : dc8ffc10 [1.683074] r7 : 2093 r6 : r5 : 0001 r4 : fa05b000 [1.689910] r3 : dc8ffc10 r2 : 0002 r1 : 0002 r0 : 0140 [1.696746] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [1.704528] Control: 10c53c7d Table: 8000406a DAC: 0017 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8) [1.716857] Stack: (0xdc851df0 to 0xdc852000) [1.721405] 1de0: 0002 c0731280 dc8ffc6c 2093 [1.730010] 1e00: c02dc224 c0731280 dc8d4980 c07a8e50 0141 0002 c00a37b8 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4 c07312b4 4013 c00a3d7c [1.747161] 1e40: 0141 c06728c0 c0090578 c247f000 c00a2d5c c0412258 0141 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0 2002 c071bed8 c247f000 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0 c04ea344 c06728c0 c247f000 [1.772888] 1ea0: 09090578 c07bf6a0 dc9df004 dc9df000 c04ea194 0091 c071bed8 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8 dc9df054 c07bf60c c03272ac [1.790069] 1ee0: dc9df020 c07bf60c dc9df054 0091 c03274c0 c07bf60c dc851f08 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 c07bf60c c07bcea8 c243d6c0 [1.807220] 1f20: c0326240 c0672958 c02bce08 c07bf5e4 c07bf60c c03e12a0 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4 0007 c07c8c40 [1.824401] 1f60: 0091 c03e1738 dc85 0007 c0008648 c112c9f0 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8 0006 0006 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c 0091 c071bed8 c0700a28 [1.850128] 1fc0: c06d0380 0006 0006 c06d020c c06d028c [1.858703] 1fe0: c001548c 0013 c001548c 3f3f3f3f 3f3f3f3f [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from [c02dc224] (gpio_irq_type+0x0/0x160) [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] (0x2002) [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc) [1.890960] [ cut here ] [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113 l3_interrupt_handler+0x184/0x1bc() [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2 [1.910430] Modules linked in: [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from [c00414c4] (warn_slowpath_common+0x4c/0x64) [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from [c0041570] (warn_slowpath_fmt+0x30/0x40) [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from [c0035de4] (l3_interrupt_handler+0x184/0x1bc) [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from [c00a2adc] (handle_irq_event+0x3c/0x5c) [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from [c00a235c] (generic_handle_irq+0x34/0x44) [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from [c00153a0] (handle_IRQ+0x4c/0xac) [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480] (gic_handle_irq+0x2c/0x60) [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from [c04f26e4] (__irq_svc+0x44/0x60) [2.011718] Exception stack(0xdc851c48 to 0xdc851c90) [2.017028] 1c40: c07a87a0 dc851c80 c0743f80 dc851da8 [2.025604] 1c60: 0001 0001 dc851cd7 c02dbb6a c02dbb6c dc851c90 [2.034179] 1c80:
Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote: + writel(~PHY_PD, phy-control_dev); + /* XXX: add proper documentation for this delay */ + mdelay(200); Do you need this to be busy? -- 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 3/6] OF: pinctrl: MIPS: lantiq: adds support for FALCON SoC
On 28/07/12 01:23, Linus Walleij wrote: On Tue, Jul 24, 2012 at 8:50 AM, John Crispin blo...@openwrt.org wrote: Implement support for pinctrl on lantiq/falcon socs. The FALCON has 5 banks of up to 32 pins. Signed-off-by: John Crispin blo...@openwrt.org Signed-off-by: Thomas Langer thomas.lan...@lantiq.com Cc: Linus Walleij linus.wall...@linaro.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org No big issues and looking really sweet so: Acked-by: Linus Walleij linus.wall...@linaro.org --- a/arch/mips/lantiq/Kconfig +++ b/arch/mips/lantiq/Kconfig @@ -20,6 +20,7 @@ config SOC_XWAY config SOC_FALCON bool FALCON + select PINCTRL_FALCON I think you need to add select PINCTRL above select PINCTRL_FALCON for this to work. Atleast I had to do that in the past to get things working. Hi Linus, config LANTIQ selects PINCTRL globally for all Lantiq SoC so an explicit select can be avoided here Thanks for the review, 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/
Re: /dev/kmem BUG on mmap
On Mon, Jul 30, 2012 at 12:28:35AM +0200, Sasha Levin wrote:
Hi all,
I was poking around /dev/kmem related code, and noticed the following in
mmap_kmem():
/* Turn a kernel-virtual address into a physical page frame */
pfn = __pa((u64)vma-vm_pgoff PAGE_SHIFT) PAGE_SHIFT;
Which looked odd since vm_pgoff is the offset into the mapping, so
I'd assume that PAGE_OFFSET should be added to it as well, otherwise
we get an invalid address.
It's supposed to be used with kernel offsets in the first place,
i.e. vma-vm_pgoff PAGE_SHIFT should actually be a kernel virtual
address. See 6d3154c Revert [PATCH] Fix up mmap_kmem.
I tested it by writing something like this:
int main(void)
{
int fd;
void *addr;
fd = open(/dev/kmem, O_RDONLY);
addr = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, 4096);
return 0;
}
Which indeed triggered a VM_BUG:
[ 32.285431] kernel BUG at arch/x86/mm/physaddr.c:18!
x86's debug-version of __pa() triggers that bug. I'm reluctant to add
a whole lot of error checking to this interface, given that you should
already know what you are doing. OTOH, crashing like this is not very
nice, either.
Is there a portable way to check if an address is a kernel virtual
one? It looks like comparing to PAGE_OFFSET would work on most archs,
but not necessarily on powerpc for example.
Johannes
[ 32.285431] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 32.285431] CPU 0
[ 32.285431] Pid: 5643, comm: a.out Tainted: GW
3.5.0-next-20120727-sasha #504
[ 32.285431] RIP: 0010:[810acd97] [810acd97]
__phys_addr+0x57/0xa0
[ 32.285431] RSP: 0018:88000be67d68 EFLAGS: 00010213
[ 32.285431] RAX: 87ff RBX: 88000d67cb00 RCX:
80d0
[ 32.285431] RDX: 0071 RSI: 88000bfc8dc8 RDI:
1000
[ 32.285431] RBP: 88000be67d68 R08: 0001 R09:
88000bfc8dc8
[ 32.285431] R10: 88000bfc81f8 R11: 0002 R12:
88000bfc8dc8
[ 32.285431] R13: 7f26f80e6000 R14: 88000bf81000 R15:
88000bfc8dc8
[ 32.285431] FS: 7f26f80e8700() GS:88000d80()
knlGS:
[ 32.285431] CS: 0010 DS: ES: CR0: 80050033
[ 32.285431] CR2: 7f26f7c07d50 CR3: 0bfb8000 CR4:
000406f0
[ 32.285431] DR0: DR1: DR2:
[ 32.285431] DR3: DR6: 0ff0 DR7:
0400
[ 32.285431] Process a.out (pid: 5643, threadinfo 88000be66000, task
88000bf2b000)
[ 32.285431] Stack:
[ 32.285431] 88000be67d88 81bb0737 88000bfc95e0
88000bfc95f0
[ 32.285431] 88000be67e48 812163ae 88000d67cb00
0001
[ 32.285431] 88000be67dd8
88000bfc81f8
[ 32.285431] Call Trace:
[ 32.285431] [81bb0737] mmap_kmem+0x27/0x90
[ 32.285431] [812163ae] mmap_region+0x35e/0x5f0
[ 32.285431] [812168f9] do_mmap_pgoff+0x2b9/0x350
[ 32.285431] [8120120c] ? vm_mmap_pgoff+0x6c/0xb0
[ 32.285431] [81201224] vm_mmap_pgoff+0x84/0xb0
[ 32.285431] [8124f280] ? fget_raw+0x260/0x260
[ 32.285431] [81213d9e] sys_mmap_pgoff+0x15e/0x190
[ 32.285431] [8198ab2e] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 32.285431] [8106e4ed] sys_mmap+0x1d/0x20
[ 32.285431] [8361f6f9] system_call_fastpath+0x16/0x1b
[ 32.285431] Code: 00 00 00 00 eb fe 66 0f 1f 44 00 00 48 03 05 91 02 78 03
eb 57 0f 1f 80 00 00 00 00 48 b8 ff ff ff ff ff 87 ff ff 48 39 c7 77 11 0f
0b 0f 1f 80 00 00 00 00 eb fe 66 0f 1f 44 00 00 48 b8 00 00
[ 32.285431] RIP [810acd97] __phys_addr+0x57/0xa0
[ 32.285431] RSP 88000be67d68
I could send a patch to do what I think it's supposed to be doing, but I find
it odd since apparently /dev/kmem has been broken for a while now - which
doesn't make sense.
What am I missing?
--
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: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
Hi, On Mon, Jul 30, 2012 at 3:07 PM, Shubhrajyoti shubhrajy...@ti.com wrote: On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote: + writel(~PHY_PD, phy-control_dev); + /* XXX: add proper documentation for this delay */ + mdelay(200); Do you need this to be busy? This might be called from interrupt context. This delay was initially added in omap_phy_internal.c and I just inherited it. Thanks Kishon -- 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] kbuild fix for v3.6-rc1
Hi Linus, the main kbuild branch ended up with a single commit this time, a fix to send errors to stderr. Please pull from the below repository. Thanks, Michal The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f: Linux 3.5-rc1 (2012-06-02 18:29:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild Michal Marek (1): kbuild: Print errors to stderr Makefile| 24 scripts/link-vmlinux.sh |4 ++-- 2 files changed, 14 insertions(+), 14 deletions(-) -- 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: [2/3][PATCH][v2] TDM Framework
Thanks for your comments. Please find replies inline. Regards, Sandeep -Original Message- From: Francois Romieu [mailto:rom...@fr.zoreil.com] Sent: 27 July 2012 20:56 To: Singh Sandeep-B37400 Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; ga...@kernel.crashing.org; linux-kernel@vger.kernel.org; de...@driverdev.osuosl.org Subject: Re: [2/3][PATCH][v2] TDM Framework sand...@freescale.com sand...@freescale.com : [...] The main functions of this Framework are: - provides interface to TDM clients to access TDM functionalities. - provides standard interface for TDM drivers to hook with the framework. - handles various data handling stuff and buffer management. In future this Framework will be extended to provide Interface for Line control devices also. For example SLIC, E1/T1 Framers etc. Presently the framework supports only Single Port channelised mode. Also the configurability options are limited which will be extended later on. Only kernel mode TDM clients are supported currently. Support for User mode clients will be added later. 1. You should send some kernel mode TDM clients. Without those the framework is pretty useless. [Sandeep] We do have a test client but not good enough to be pushed in open source, should we add it to documentation?? 2. It would probably make sense to Cc: netdev and serial. There may be some kernel client network integration from the start. [Sandeep] Ok. 3. Where is the userspace configuration interface ? [Sandeep] TDM framework right now supports only kernel mode clients. It has been tested with the client module that I mentioned above. Both the framework and test client are a part of Freescale BSP. [...] Based on: git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git [Sandeep] Please try below mentioned link. The above one is Freescale's internal mirror of: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git $ git clone git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git Cloning into 'galak-powerpc'... fatal: Unable to look up git.am.freescale.net (port 9418) (No address associated with hostname) -- Ueimor -- 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] kconfig changes for 3.6-rc1
Hi Linus, Please pull following kconfig changes for v3.6-rc1: * kconfig Makefile portability fixes * menuconfig/nconfig help pager usability fix * .gitignore cleanup * quoting fix in scripts/config * Makefile prints errors to stderr * support for arbitrarily log lines in .config * fix oldnoconfig description in 'make help' Thanks, Michal The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f: Linux 3.5-rc1 (2012-06-02 18:29:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kconfig Benjamin Poirier (2): menuconfig: add u, d, q command keys in text boxes nconf: add u, d command keys in scroll windows Cody Schafer (1): kconfig: allow long lines in config file Michal Marek (1): kconfig: Print errors to stderr in the Makefile Paul Bolle (1): kconfig: remove lkc_defs.h from .gitignore and dontdiff Steven Rostedt (1): kconfig: Document oldnoconfig to what it really does Yaakov Selkowitz (5): kconfig/nconf: fix compile with ncurses reentrant API kconfig: check ncursesw headers first in check-lxdialog kconfig: fix check-lxdialog for DLL platforms xconfig: use pkgconfig to find moc xconfig: add quiet rule for moc Yann E. MORIN (1): scripts/config: fix double-quotes un-escaping Documentation/dontdiff |1 - scripts/config |2 +- scripts/kconfig/.gitignore |1 - scripts/kconfig/Makefile | 41 ++- scripts/kconfig/confdata.c | 61 +++- scripts/kconfig/lxdialog/check-lxdialog.sh |8 ++-- scripts/kconfig/lxdialog/textbox.c |3 + scripts/kconfig/mconf.c|6 +- scripts/kconfig/nconf.c| 10 +++- scripts/kconfig/nconf.gui.c|8 ++- 10 files changed, 104 insertions(+), 37 deletions(-) -- 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 00/15] Lockd: grace period containerization
28.07.2012 01:54, J. Bruce Fields пишет: On Wed, Jul 25, 2012 at 04:55:45PM +0400, Stanislav Kinsbursky wrote: Bruce, I feel this patch set is ready for inclusion. v2: 1) Rebase on Bruce's for-3.6 branch. This patch set makes grace period and hosts reclaiming network namespace aware. On a quick skim--yes, that looks reasonable to me. It doesn't help with active/active cluster exports, because in that case we need some additional coordination between nfsd's. But it looks good enough to handle the case where each filesystem is exported from at most one server at a time, which is more than we currently handle. It's a little late for 3.6. Also I get the impression Al Viro has some lockd rework in progress, which we may want to wait for. So I'll likely look again into queueing this up for 3.7 once 3.6-rc1 is out. Ok. Will Al Viro's lockd rework be a part of 3.6 kernel? --b. Main ideas: 1) moving of unsigned long next_gc; unsigned long nrhosts; struct delayed_work grace_period_end; struct lock_manager lockd_manager; struct list_head grace_list; to per-net Lockd data. 2) moving of struct lock_manager nfsd4_manager; to per-net NFSd data. 3) shutdown + gc of NLM hosts done now network namespace aware. 4) restart_grace() now works only for init_net. The following series implements... --- Stanislav Kinsbursky (15): LockD: mark host per network namespace on garbage collect LockD: make garbage collector network namespace aware. LockD: manage garbage collection timeout per networks namespace LockD: manage used host count per networks namespace Lockd: host complaining function introduced Lockd: add more debug to host shutdown functions LockD: manage grace period per network namespace LockD: make lockd manager allocated per network namespace NFSd: make nfsd4_manager allocated per network namespace context. SUNRPC: service request network namespace helper introduced LockD: manage grace list per network namespace LockD: pass actual network namespace to grace period management functions Lockd: move grace period management from lockd() to per-net functions NFSd: make grace end flag per network namespace NFSd: make boot_time variable per network namespace fs/lockd/grace.c| 16 +-- fs/lockd/host.c | 92 ++ fs/lockd/netns.h|7 +++ fs/lockd/svc.c | 43 ++ fs/lockd/svc4proc.c | 13 +++-- fs/lockd/svclock.c | 16 +++ fs/lockd/svcproc.c | 15 -- fs/lockd/svcsubs.c | 19 +--- fs/nfs/callback_xdr.c |4 +- fs/nfsd/export.c|4 +- fs/nfsd/netns.h |4 ++ fs/nfsd/nfs4idmap.c |4 +- fs/nfsd/nfs4proc.c | 18 --- fs/nfsd/nfs4state.c | 104 --- fs/nfsd/state.h |4 +- include/linux/fs.h |5 +- include/linux/lockd/lockd.h |6 +- include/linux/sunrpc/svc.h |2 + 18 files changed, 231 insertions(+), 145 deletions(-) -- Best regards, Stanislav Kinsbursky -- 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 v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
On Monday 30 July 2012 03:16 PM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Jul 30, 2012 at 3:07 PM, Shubhrajyoti shubhrajy...@ti.com wrote: On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote: + writel(~PHY_PD, phy-control_dev); + /* XXX: add proper documentation for this delay */ + mdelay(200); Do you need this to be busy? This might be called from interrupt context. This delay was initially added in omap_phy_internal.c and I just inherited it. Thanks for the explanation. Thanks Kishon -- 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] rtc: tps65910: Add RTC driver for TPS65910 PMIC RTC
Thanks Stephen for your comments.
Plz see my comments inline.
-Original Message-
From: Stephen Boyd [mailto:sb...@codeaurora.org]
Sent: Monday, July 30, 2012 2:47 PM
To: Venu Byravarasu
Cc: a.zu...@towertech.it; sa...@linux.intel.com;
broo...@opensource.wolfsonmicro.com; Laxman Dewangan;
kyle.ma...@fuel7.com; rtc-li...@googlegroups.com; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH] rtc: tps65910: Add RTC driver for TPS65910 PMIC RTC
On 7/25/2012 11:35 PM, Venu Byravarasu wrote:
+
+static struct rtc_class_ops tps65910_rtc_ops = {
const?
Will add it in my next patch.
+ .read_time = tps65910_rtc_read_time,
+ .set_time = tps65910_rtc_set_time,
+ .read_alarm = tps65910_rtc_read_alarm,
+ .set_alarm = tps65910_rtc_set_alarm,
+ .alarm_irq_enable = tps65910_rtc_alarm_irq_enable,
+};
+
+static int __devinit tps65910_rtc_probe(struct platform_device *pdev)
+{
+ struct tps65910 *tps65910 = NULL;
+ struct tps65910_rtc *tps_rtc = NULL;
+ struct tps65910_board *pmic_plat_data;
+ int ret = -EINVAL;
+ int irq = 0;
+ u32 rtc_reg;
It seems like all the above assignments are useless as they're
overwritten later in this function. Can you remove the assignments?
Some of the non-intelligent compilers/tools complain as variables
may get used uninitialized. Hence to avoid such complaints, initialized
them to some default values.
What harm do you see if I have local variables initialized during their
declaration?
+
+ tps65910 = dev_get_drvdata(pdev-dev.parent);
+
+ tps_rtc = devm_kzalloc(pdev-dev, sizeof(struct tps65910_rtc),
+ GFP_KERNEL);
+ if (!tps_rtc)
+ return -ENOMEM;
+
+ /* Clear pending interrupts */
+ ret = regmap_read(tps65910-regmap, TPS65910_RTC_STATUS,
rtc_reg);
+ if (ret 0)
+ return ret;
+
+ ret = regmap_write(tps65910-regmap, TPS65910_RTC_STATUS,
rtc_reg);
+ if (ret 0)
+ return ret;
+
+ dev_dbg(pdev-dev, Enabling tps65910-RTC.\n);
Hmph, looks more like stopping the RTC.
No, the register is a misnomer here.
As per data sheet of TPS65910, setting this bit will start RTC,
instead of stopping as its name suggests.
+ rtc_reg = TPS65910_RTC_CTRL_STOP_RTC;
+ ret = regmap_write(tps65910-regmap, TPS65910_RTC_CTRL,
rtc_reg);
+ if (ret 0)
+ return ret;
+
+ pmic_plat_data = dev_get_platdata(tps65910-dev);
+ irq = pmic_plat_data-irq_base;
+ if (irq = 0) {
+ dev_warn(pdev-dev, Wake up is not possible as irq =
%d\n,
+ irq);
+ return ret;
+ }
+
+ irq += TPS65910_IRQ_RTC_ALARM;
+ ret = devm_request_threaded_irq(pdev-dev, irq, NULL,
+ tps65910_rtc_interrupt, IRQF_TRIGGER_LOW,
+ dev_name(tps_rtc-rtc-dev), pdev-dev);
How does this work? It doesn't look like tps_rtc-rtc is assigned until
down there at the rtc_device_register() call.
Somehow this got skipped. Thanks for pointing out.
Will fix and push as part of next patch.
+ if (ret 0) {
+ dev_err(pdev-dev, IRQ is not free.\n);
+ return ret;
+ }
+ device_init_wakeup(pdev-dev, 1);
+
+ tps_rtc-rtc = rtc_device_register(pdev-name, pdev-dev,
+ tps65910_rtc_ops, THIS_MODULE);
+ if (IS_ERR(tps_rtc-rtc)) {
+ ret = PTR_ERR(tps_rtc-rtc);
+ dev_err(pdev-dev, RTC device register: err %d\n, ret);
+ return ret;
+ }
+
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
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 TRIVIAL] mm: Fix build warning in kmem_cache_create()
On Sat, Jul 14, 2012 at 2:12 AM, Shuah Khan shuah.k...@hp.com wrote: The label oops is used in CONFIG_DEBUG_VM ifdef block and is defined outside ifdef CONFIG_DEBUG_VM block. This results in the following build warning when built with CONFIG_DEBUG_VM disabled. Fix to move label oops definition to inside a CONFIG_DEBUG_VM block. mm/slab_common.c: In function ‘kmem_cache_create’: mm/slab_common.c:101:1: warning: label ‘oops’ defined but not used [-Wunused-label] Signed-off-by: Shuah Khan shuah.k...@hp.com I merged this as an obvious and safe fix for current merge window. We need to clean this up properly for v3.7. --- mm/slab_common.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/slab_common.c b/mm/slab_common.c index 12637ce..aa3ca5b 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -98,7 +98,9 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size, size_t align s = __kmem_cache_create(name, size, align, flags, ctor); +#ifdef CONFIG_DEBUG_VM oops: +#endif mutex_unlock(slab_mutex); put_online_cpus(); -- 1.7.9.5 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- 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 v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote: We don't call __add_pages() directly in the function add_memory() because some other architecture related things need to be done before or after calling __add_pages(). So we should introduce a new function arch_remove_memory() to revert the things done in arch_add_memory(). Note: the function for s390 is not implemented(I don't know how to implement it for s390). There is no hardware or firmware interface which could trigger a hot memory remove on s390. So there is nothing that needs to be implemented. -- 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 V2 2/2] lp8727_charger: unregister power supply at error path of lp8727_register_psy
if usb power supply registration fails, we wont unregister the ac power supply if battery power supply registration fails, we wont unregister the usb, and ac supply, take care of those things and also no need of goto -err_mem: at the fail case of kzalloc simply can have return -ENOMEM Signed-off-by: Devendra Naga develkernel412...@gmail.com --- Changes since V2: * fix the comments from the Ramakrishna (ramakrishna.pall...@intel.com) quoting his comments: if (power_supply_register(pchg-dev, psy-usb)) - goto err_psy; + goto err_psy_ac; err_psy_ac label name is confusing. Why can't you use err_psy_usb if (power_supply_register(pchg-dev, psy-batt)) - goto err_psy; + goto err_psy_usb; Same here, why don't you use err_psy_batt drivers/power/lp8727_charger.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/power/lp8727_charger.c b/drivers/power/lp8727_charger.c index 6c0e0f9..8fb1c0f 100644 --- a/drivers/power/lp8727_charger.c +++ b/drivers/power/lp8727_charger.c @@ -362,7 +362,7 @@ static int lp8727_register_psy(struct lp8727_chg *pchg) psy = kzalloc(sizeof(*psy), GFP_KERNEL); if (!psy) - goto err_mem; + return -ENOMEM; pchg-psy = psy; @@ -386,7 +386,7 @@ static int lp8727_register_psy(struct lp8727_chg *pchg) psy-usb.num_supplicants = ARRAY_SIZE(battery_supplied_to); if (power_supply_register(pchg-dev, psy-usb)) - goto err_psy; + goto err_psy_usb; psy-batt.name = main_batt; psy-batt.type = POWER_SUPPLY_TYPE_BATTERY; @@ -396,12 +396,14 @@ static int lp8727_register_psy(struct lp8727_chg *pchg) psy-batt.external_power_changed = lp8727_charger_changed; if (power_supply_register(pchg-dev, psy-batt)) - goto err_psy; + goto err_psy_batt; return 0; -err_mem: - return -ENOMEM; +err_psy_batt: + power_supply_unregister(psy-usb); +err_psy_usb: + power_supply_unregister(psy-ac); err_psy: kfree(psy); return -EPERM; -- 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: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
At 07/30/2012 06:23 PM, Heiko Carstens Wrote: On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote: We don't call __add_pages() directly in the function add_memory() because some other architecture related things need to be done before or after calling __add_pages(). So we should introduce a new function arch_remove_memory() to revert the things done in arch_add_memory(). Note: the function for s390 is not implemented(I don't know how to implement it for s390). There is no hardware or firmware interface which could trigger a hot memory remove on s390. So there is nothing that needs to be implemented. Thanks for providing this information. According to this, arch_remove_memory() for s390 can just return -EBUSY. Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe linux-acpi 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/
[GIT] kbuild misc changes for v3.6-rc1
Hi Linus, this is the non-critical part of kbuild for v3.6-rc1: * Two new coccinelle semantic patches * New scripts/tags.sh regexp * scripts/config improvements that I mistakenly applied here instead of in the kconfig branch (but there are no conflicts) * Debian packaging fixes Thanks, Michal The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f: Linux 3.5-rc1 (2012-06-02 18:29:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git misc Julia Lawall (1): scripts/coccinelle: list iterator variable semantic patch Lars-Peter Clausen (1): scripts/coccinelle: Find threaded IRQs requests which are missing IRQF_ONESHOT Namhyung Kim (1): scripts/tags.sh: Teach [ce]tags about libtraceeevent error codes Yann E. MORIN (3): scripts/config: add option to not upper-case symbols scripts/config: allow alternate prefix to config option symbol scripts/config: add option to undef a symbol maximilian attems (2): deb-pkg: Install linux-firmware-image in versioned dir deb-pkg: Add all Makefiles to header package scripts/coccinelle/iterators/use_after_iter.cocci | 147 + scripts/coccinelle/misc/irqf_oneshot.cocci| 65 + scripts/config| 60 ++--- scripts/package/builddeb |7 +- scripts/tags.sh |6 +- 5 files changed, 264 insertions(+), 21 deletions(-) create mode 100644 scripts/coccinelle/iterators/use_after_iter.cocci create mode 100644 scripts/coccinelle/misc/irqf_oneshot.cocci -- 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: [Announce] Checkpoint-restore tool v0.1
On Mon, Jul 23, 2012 at 10:53 AM, Pavel Emelyanov xe...@parallels.com wrote: This project is an attempt to implement the checkpoint-restore functionality for processes and containers without driving too much code into the kernel tree, but putting there various oddball helper code instead. Is CRIU able to checkpoint a process tree where one or more processes are traced using ptrace()? crtools seem to use ptrace() to execute parasite system calls. AFAIK this will only work if the target process is currently not ptraced() by another process. -- Thanks, //richard -- 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 1/2] ds2781_battery: convert to module_platform_driver
module_platform_driver can be used to replace the
platform_driver register and unregister functions,
with the calls to module_init and module_exit,
i.e. all the code that is doing like the below
static int __init mymod_init(void)
{
return platform_driver_register(drv_operations);
}
static void __exit mymod_exit(void)
{
platform_driver_unregister(drv_operations);
}
module_init(mymod_init);
module_exit(mymod_exit);
can be replaced with
module_platform_driver(drv_operations)...
Signed-off-by: Devendra Naga develkernel412...@gmail.com
---
drivers/power/ds2781_battery.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/power/ds2781_battery.c b/drivers/power/ds2781_battery.c
index 7a1ff4e..8f84ab7 100644
--- a/drivers/power/ds2781_battery.c
+++ b/drivers/power/ds2781_battery.c
@@ -835,19 +835,7 @@ static struct platform_driver ds2781_battery_driver = {
.remove = __devexit_p(ds2781_battery_remove),
};
-static int __init ds2781_battery_init(void)
-{
- return platform_driver_register(ds2781_battery_driver);
-}
-
-static void __exit ds2781_battery_exit(void)
-{
- platform_driver_unregister(ds2781_battery_driver);
-}
-
-module_init(ds2781_battery_init);
-module_exit(ds2781_battery_exit);
-
+module_platform_driver(ds2781_battery_driver);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Renata Sayakhova ren...@oktetlabs.ru);
--
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/
[PATCH 2/2] ds2781_battery: replace call to kzalloc with devm_kzalloc
with devm_kzalloc there is no need of freeing at the errorpath
and also at unregister it.
Signed-off-by: Devendra Naga develkernel412...@gmail.com
---
drivers/power/ds2781_battery.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/power/ds2781_battery.c b/drivers/power/ds2781_battery.c
index 8f84ab7..1b5e4a1 100644
--- a/drivers/power/ds2781_battery.c
+++ b/drivers/power/ds2781_battery.c
@@ -755,11 +755,9 @@ static int __devinit ds2781_battery_probe(struct
platform_device *pdev)
int ret = 0;
struct ds2781_device_info *dev_info;
- dev_info = kzalloc(sizeof(*dev_info), GFP_KERNEL);
- if (!dev_info) {
- ret = -ENOMEM;
- goto fail;
- }
+ dev_info = devm_kzalloc(pdev-dev, sizeof(*dev_info), GFP_KERNEL);
+ if (!dev_info)
+ return -ENOMEM;
platform_set_drvdata(pdev, dev_info);
@@ -774,7 +772,7 @@ static int __devinit ds2781_battery_probe(struct
platform_device *pdev)
ret = power_supply_register(pdev-dev, dev_info-bat);
if (ret) {
dev_err(dev_info-dev, failed to register battery\n);
- goto fail_free_info;
+ goto fail;
}
ret = sysfs_create_group(dev_info-bat.dev-kobj, ds2781_attr_group);
@@ -808,8 +806,6 @@ fail_remove_group:
sysfs_remove_group(dev_info-bat.dev-kobj, ds2781_attr_group);
fail_unregister:
power_supply_unregister(dev_info-bat);
-fail_free_info:
- kfree(dev_info);
fail:
return ret;
}
@@ -823,7 +819,6 @@ static int __devexit ds2781_battery_remove(struct
platform_device *pdev)
power_supply_unregister(dev_info-bat);
- kfree(dev_info);
return 0;
}
--
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/
[GIT] kbuild treewide cleanup
Hi Linus, Paul Bolle did a cleanup of asm/*.h headers in various architectures. Because the patch touch several architectures at once, it was easiest for me to apply them to the kbuild tree. Thanks, Michal The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f: Linux 3.5-rc1 (2012-06-02 18:29:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git trivial Paul Bolle (3): Remove useless wrappers of asm-generic/cpumask.h Remove useless wrappers of asm-generic/ipc.h Remove useless wrappers of asm-generic/rmap.h arch/frv/include/asm/cpumask.h|6 -- arch/hexagon/include/asm/Kbuild |2 -- arch/mn10300/include/asm/ipc.h|1 - arch/openrisc/include/asm/Kbuild |2 -- arch/tile/include/asm/Kbuild |1 - arch/xtensa/include/asm/cpumask.h | 16 arch/xtensa/include/asm/rmap.h| 16 7 files changed, 0 insertions(+), 44 deletions(-) delete mode 100644 arch/frv/include/asm/cpumask.h delete mode 100644 arch/mn10300/include/asm/ipc.h delete mode 100644 arch/xtensa/include/asm/cpumask.h delete mode 100644 arch/xtensa/include/asm/rmap.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] Support UEFI variable append and deleting authenticated variables.
On Mon, 2012-06-25 at 09:12 -0400, Peter Jones wrote:
This adds support for appending to all UEFI variables, and also for
deleting authentication variables.
Signed-off-by: Peter Jones pjo...@redhat.com
---
drivers/firmware/efivars.c | 99
+---
1 file changed, 94 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 47408e8..b12a2f0 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -108,6 +108,27 @@ struct efi_variable {
__u32 Attributes;
} __attribute__((packed));
+struct win_certificate {
+ __u32 dwLength;
+ __u16 wRevision;
+ __u16 wCertificateType;
+ __u8wCertificate[];
+};
+
+struct win_certificate_uefi_guid {
+ struct win_certificate Hdr;
+ efi_guid_t CertType;
+};
+
+struct efi_variable_authentication {
+ __u64 MonotonicCount;
+ struct win_certificate_uefi_guidAuthInfo;
+};
+
+struct efi_variable_authentication_2 {
+ efi_time_t TimeStamp;
+ struct win_certificate_uefi_guidAuthInfo;
+};
struct efivar_entry {
struct efivars *efivars;
@@ -802,6 +823,54 @@ static struct pstore_info efi_pstore_info = {
.erase = efi_pstore_erase,
};
+static int is_authenticated_delete(struct efi_variable *new_var)
+{
+ /* If we get a set_variable() call that's got an authenticated
+ * variable attribute set, and its DataSize is the same size as
+ * the AuthInfo descriptor, then it's really a delete. */
Just FYI, the multi-line comment format used throughout this file is,
/*
* This is a multi-line comment
*/
and it would be better to not break that convention. Deleting entries in
this way seems counter-intuitive to me. Is there a reason that you can't
just delete authenticated variables with efivar_delete()?
+ if (new_var-Attributes EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) {
+ struct efi_variable_authentication *eva;
+ __u32 size;
+
+ if (new_var-DataSize
+ sizeof(struct efi_variable_authentication))
+ return 0;
You could write this as,
if (new_var-DataSize sizeof(*eva))
which would mean that you wouldn't have to split it across two lines
like this.
+ eva = (struct efi_variable_authentication *)new_var-Data;
+
+ /* 27.2.4 says:
+ * dwLength: The length of the entire certificate, including
+ * the length of the header, in bytes.
+ */
+ size = sizeof(eva-AuthInfo.CertType) +
+eva-AuthInfo.Hdr.dwLength;
+
+ if (size == new_var-DataSize)
+ return 1;
+ } else if (new_var-Attributes
+ EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) {
+ struct efi_variable_authentication_2 *eva;
+ __u32 size;
+
+ if (new_var-DataSize
+ sizeof(struct efi_variable_authentication_2))
+ return 0;
+
+ eva = (struct efi_variable_authentication_2 *)new_var-Data;
+
+ /* 27.2.4 says:
+ * dwLength: The length of the entire certificate, including
+ * the length of the header, in bytes.
+ */
+ size = sizeof(eva-AuthInfo.CertType) +
+eva-AuthInfo.Hdr.dwLength;
+
+ if (size == new_var-DataSize)
+ return 1;
+ }
+ return 0;
+}
+
static ssize_t efivar_create(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buf, loff_t pos, size_t count)
@@ -812,6 +881,8 @@ static ssize_t efivar_create(struct file *filp, struct
kobject *kobj,
unsigned long strsize1, strsize2;
efi_status_t status = EFI_NOT_FOUND;
int found = 0;
+ int is_append = 0;
+ int is_delete = 0;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
@@ -839,11 +910,20 @@ static ssize_t efivar_create(struct file *filp, struct
kobject *kobj,
break;
}
}
- if (found) {
+ if (new_var-Attributes EFI_VARIABLE_APPEND_WRITE) {
+ if (!found) {
+ spin_unlock(efivars-lock);
+ return -EINVAL;
+ }
+ is_append = 1;
+ } else if (is_authenticated_delete(new_var)) {
+ is_delete = 1;
+ } else if (found) {
spin_unlock(efivars-lock);
return -EINVAL;
}
+
Stray newline introduced?
/* now *really* create the variable via EFI */
status =
Re: [PATCH V3 0/3] PNP: Allow PNP resources to be disabled (interface)
On Sun, Jul 29, 2012 at 09:31:53PM +0200, Witold Szczeponik wrote: the aim is to select a PNP ACPI option where resources can be disabled (or are not needed). E.g., the parallel port of the 600E can be used with and without IRQ lines. The means to allow for this is to use the sysfs interface to select disabled resources (just like any other resource value). In https://lkml.org/lkml/2011/7/3/41, I used the following example: echo disable /sys/bus/pnp/devices/$device/resources echo clear /sys/bus/pnp/devices/$device/resources echo set irq disabled /sys/bus/pnp/devices/$device/resources echo fill /sys/bus/pnp/devices/$device/resources echo activate /sys/bus/pnp/devices/$device/resources The third line is made possible by the patch series. All other lines are already implemented. Shouldn't this be rather disable_irq or something which is a single word and thus would simplify parsing a lot? Also, Documentation/filesystems/sysfs.txt says Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type. Thanks. -- Regards/Gruss, Boris. Hi Boris, the patch series is about adding the term disabled (or none) to the list of possible values for resources. The current state of the kernel ABI already allows to use the following statement (cf. DSDT excerpt from https://lkml.org/lkml/2011/7/3/41): echo set irq 7 /sys/bus/pnp/devices/$device/resources i.e., the resources file can already parse all the values necessary for setting PNP values. The patch series is not about adding a new ABI or changing an existing ABI. It is about extending the existing one to be able to handle the term disabled (or none) as a special for a resource value. --- Witold -- 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 v3 1/3] runtime interpreted power sequences
Hi,
On Fri, Jul 27, 2012 at 1:05 PM, Alexandre Courbot acour...@nvidia.com wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between each steps.
These sequences are board-specific, and do not belong to a particular
driver - therefore they have been performed by board-specific hook
functions to far.
With the advent of the device tree and of ARM kernels that are not
board-tied, we cannot rely on these board-specific hooks anymore but
need a way to implement these sequences in a portable manner. This patch
introduces a simple interpreter that can execute such power sequences
encoded either as platform data or within the device tree.
This all looks very reasonable to me, just a few comments.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Documentation/power/power_seq.txt | 120 +++
drivers/base/Kconfig | 4 +
drivers/base/Makefile | 1 +
drivers/base/power_seq.c | 300
++
include/linux/power_seq.h | 139 ++
5 files changed, 564 insertions(+)
create mode 100644 Documentation/power/power_seq.txt
create mode 100644 drivers/base/power_seq.c
create mode 100644 include/linux/power_seq.h
diff --git a/Documentation/power/power_seq.txt
b/Documentation/power/power_seq.txt
new file mode 100644
index 000..aa2ceb5
--- /dev/null
+++ b/Documentation/power/power_seq.txt
@@ -0,0 +1,120 @@
+Runtime Interpreted Power Sequences
+---
+
+Problem
+---
+One very common board-dependent code is the out-of-driver code that is used
to
+turn a device on or off. For instance, SoC boards very commonly use a GPIO
+(abstracted to a regulator or not) to control the power supply of a
backlight,
+disabling it when the backlight is not used in order to save power. The GPIO
+that should be used, however, as well as the exact power sequence that may
+involve different resources, is board-dependent and thus unknown of the
driver.
+
+This has been addressed so far by using hooks in the device's platform data
that
+are called whenever the state of the device might reflect a power change.
This
+approach, however, introduces board-dependant code into the kernel and is not
+compatible with the device tree.
+
+The Runtime Interpreted Power Sequences (or power sequences for short) aim at
+turning this code into platform data or device tree nodes. Power sequences
are
+described using a simple format and run by a simple interpreter whenever
needed.
+This allows to remove the callback mechanism and makes the kernel less
+board-dependant.
+
+Sequences Format
+
+Power sequences are a series of sequential steps during which an action is
+performed on a resource. The supported resources so far are:
+- GPIOs
+- Regulators
+- PWMs
+
+Each step designates a resource and the following parameters:
+- Whether the step should enable or disable the resource,
+- Delay to wait before performing the action,
+- Delay to wait after performing the action.
+
+Both new resources and parameters can be introduced, but the goal is of
course
+to keep things as simple and compact as possible.
+
+The platform data is a simple array of platform_power_seq_step instances,
each
+instance describing a step. The type as well as one of id or gpio members
+(depending on the type) must be specified. The last step must be of type
+POWER_SEQ_STOP. Regulator and PWM resources are identified by name. GPIO are
+identified by number. For example, the following sequence will turn on the
+power regulator of the device, wait 10ms, and set GPIO number 110 to 1:
For the delay, I think milliseconds is reasonable. I suppose there is
no reasonable need for microseconds?
+
+struct platform_power_seq_step power_on_seq[] = {
+ {
+ .type = POWER_SEQ_REGULATOR,
+ .id = power,
+ .params = {
+ .enable = 1,
+ .post_delay = 10,
+ },
+ },
+ {
+ .type = POWER_SEQ_GPIO,
+ .gpio = 110,
+ .params = {
+ .enable = 1,
+ },
+ },
+ {
+ .type = POWER_SEQ_STOP,
+ },
+};
+
+Usage by Drivers and Resources Management
+-
+Power sequences make use of resources that must be properly allocated and
+managed. The power_seq_build() function takes care of resolving the
resources as
+they are met in the sequence and to allocate them if needed:
+
+power_seq *power_seq_build(struct device *dev, power_seq_resources *ress,
+ platform_power_seq *pseq);
+
+You will need an instance of
