[PATCH] staging rtl8188eu: add a blank line after declarations
fix a coding style issue: Missing a blank line after declarations
Signed-off-by: huanqi chi
---
drivers/staging/rtl8188eu/core/rtw_br_ext.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_br_ext.c
b/drivers/staging/rtl8188eu/core/rtw_br_ext.c
index e843c6b..f97f05f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_br_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_br_ext.c
@@ -442,6 +442,7 @@ static void __nat25_db_print(struct adapter *priv)
void nat25_db_cleanup(struct adapter *priv)
{
int i;
+
spin_lock_bh(>br_ext_lock);
for (i = 0; i < NAT25_HASH_SIZE; i++) {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: msync: require either MS_ASYNC or MS_SYNC
On 04/03/2014 01:51 PM, Christopher Covington wrote: > On 04/03/2014 04:25 AM, Michael Kerrisk (man-pages) wrote: > >> I think the only reasonable solution is to better document existing >> behavior and what the programmer should do. With that in mind, I've >> drafted the following text for the msync(2) man page: >> >> NOTES >>According to POSIX, exactly one of MS_SYNC and MS_ASYNC must be >>specified in flags. However, Linux permits a call to msync() >>that specifies neither of these flags, with semantics that are >>(currently) equivalent to specifying MS_ASYNC. (Since Linux >>2.6.19, MS_ASYNC is in fact a no-op, since the kernel properly >>tracks dirty pages and flushes them to storage as necessary.) >>Notwithstanding the Linux behavior, portable, future-proof appli‐ >>cations should ensure that they specify exactly one of MS_SYNC >>and MS_ASYNC in flags. > > Nit: MS_SYNC or MS_ASYNC Thanks. Reworded. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging rtl8188eu: add a blank line after declarations
On Sat, Apr 05, 2014 at 12:56:43PM +0800, chihuanqi wrote: > fix a coding style issue: Missing a blank line after declarations > > Signed-off-by: chihuanqi I need a "real" name here. Appologies if you only have one word for a name, but most countries that is not the norm. thanks, greg k-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/
[PATCH] staging rtl8188eu: add a blank line after declarations
fix a coding style issue: Missing a blank line after declarations
Signed-off-by: chihuanqi
---
drivers/staging/rtl8188eu/core/rtw_br_ext.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_br_ext.c
b/drivers/staging/rtl8188eu/core/rtw_br_ext.c
index e843c6b..f97f05f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_br_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_br_ext.c
@@ -442,6 +442,7 @@ static void __nat25_db_print(struct adapter *priv)
void nat25_db_cleanup(struct adapter *priv)
{
int i;
+
spin_lock_bh(>br_ext_lock);
for (i = 0; i < NAT25_HASH_SIZE; i++) {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 0 PID: 1935 at kernel/timer.c:1621 migrate_timer_list()
On 04/04/2014 03:52 PM, Viresh Kumar wrote: On 4 April 2014 13:16, Jet Chen wrote: Hi Viresh, I changed your print message as you suggested. diff --git a/kernel/timer.c b/kernel/timer.c index 6c3a371..193101d 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -1617,8 +1617,8 @@ static void migrate_timer_list(struct tvec_base *new_base, struct list_head *hea /* Check if CPU still has pinned timers */ if (unlikely(WARN(is_pinned, - "%s: can't migrate pinned timer: %p, deactivating it\n", - __func__, timer))) + "%s: can't migrate pinned timer: %p, timer->function: %p,deactivating it\n", + __func__, timer, timer->function))) continue; Then I reproduced the issue, and got the dmesg output, [ 37.918406] migrate_timer_list: can't migrate pinned timer: 81f06a60, timer->function: 810d7010,deactivating it We reproduced this issue for several times in our LKP system. The address of timer 81f06a60 is very constant. So is timer->function, I believe. Hope this information will help you. Please feel free to tell me what else I can do to help you. Hi Jet, Thanks a lot. Yes that's pretty helpful.. But I need some more help from you.. I don't have any idea which function has this address in your kernel: 810d7010 :) Can you please debug that a bit more? You need to find which function this address belongs to. You can try that using objdump on your vmlinux. Some help can be found here: Documentation/BUG-HUNTING Thanks in Advance. vmlinuz from our build system doesn't have debug information. It is hard to use objdump to identify which routine is timer->function. But after several times trials, I get below dmesg messages. It is clear to see address of "timer->function" is 0x810d7010. In calling stack, " [] ? clocksource_watchdog_kthread+0x40/0x40 ". So I guess timer->function is clocksource_watchdog_kthread. I manually disable CONFIG_CLOCKSOURCE_WATCHDOG, then I never see this oops again (But see other oops for other reason :( ) [ 37.918345] WARNING: CPU: 0 PID: 1932 at kernel/timer.c:1621 migrate_timer_list+0xdb/0xf0() [ 37.918406] migrate_timer_list: can't migrate pinned timer: 81f06a60, timer->function: 810d7010,deactivating it [ 37.918406] Modules linked in: [ 37.918406] CPU: 0 PID: 1932 Comm: 01-cpu-hotplug Not tainted 3.14.0-rc1-00088-gab3c4fd #4 [ 37.918406] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 37.918406] 0009 88001d407c38 817237bd 88001d407c80 [ 37.918406] 88001d407c70 8106a1dd 0010 81f06a60 [ 37.918406] 88001e04d040 81e3d4c0 88001e04d030 88001d407cd0 [ 37.918406] Call Trace: [ 37.918406] [] dump_stack+0x4d/0x66 [ 37.918406] [] warn_slowpath_common+0x7d/0xa0 [ 37.918406] [] warn_slowpath_fmt+0x4c/0x50 [ 37.918406] [] ? __internal_add_timer+0x113/0x130 [ 37.918406] [] ? clocksource_watchdog_kthread+0x40/0x40 [ 37.918406] [] migrate_timer_list+0xdb/0xf0 [ 37.918406] [] timer_cpu_notify+0xfc/0x1f0 [ 37.918406] [] notifier_call_chain+0x4c/0x70 [ 37.918406] [] __raw_notifier_call_chain+0xe/0x10 [ 37.918406] [] cpu_notify+0x23/0x50 [ 37.918406] [] cpu_notify_nofail+0xe/0x20 [ 37.918406] [] _cpu_down+0x1ad/0x2e0 [ 37.918406] [] cpu_down+0x34/0x50 [ 37.918406] [] cpu_subsys_offline+0x14/0x20 [ 37.918406] [] device_offline+0x95/0xc0 [ 37.918406] [] online_store+0x40/0x90 [ 37.918406] [] dev_attr_store+0x18/0x30 [ 37.918406] [] sysfs_kf_write+0x3d/0x50 early console in setup code Probing EDD (edd=off to disable)... ok early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.14.0-rc1-00088-gab3c4fd (kbuild@xian) (gcc version 4.8.2 (Debian 4.8.2-18) ) #4 SMP Fri Apr 4 14:46:57 CST 2014 [0.00] Command line: hung_task_panic=1 earlyprintk=ttyS0,115200 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=10 softlockup_panic=1 nmi_watchdog=panic load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal ip=nfsroot-lkp-ib04-40::dhcp nfsroot=192.168.1.1:/nfsroot/wfg,tcp,v3,nocto,actimeo=600,nolock,rsize=524288,wsize=524288 rw link=/kernel-tests/run-queue/kvm/x86_64-rhel/tchen:vireshk_test/.vmlinuz-ab3c4fdd657432f23ac1ede2845392c4d4bdb947-20140404144932-2-lkp-ib04 branch=tchen/vireshk_test BOOT_IMAGE=/kernel/x86_64-rhel/ab3c4fdd657432f23ac1ede2845392c4d4bdb947/vmlinuz-3.14.0-rc1-00088-gab3c4fd drbd.minor_count=8 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00]
Re: [PATCH v2] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash
At 2014-04-05 07:05:59,"Jesse Gross" wrote:
>On Tue, Apr 1, 2014 at 5:23 PM, Wei Zhang wrote:
>>
>> v2 -> v1: use the same logic of the gre_rcv() to distinguish which packet is
>> intended to us!
>
>As a tip on kernel process: if you put the version information after
>three dashes below the signed-off-by line then git will automatically
>remove it when the final patch is applied.
Thanks, should I modify it and send a v3 patch?
>
>> diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
>> index a3d6951..f391df1 100644
>> --- a/net/openvswitch/vport-gre.c
>> +++ b/net/openvswitch/vport-gre.c
>> @@ -110,6 +110,21 @@ static int gre_rcv(struct sk_buff *skb,
>> return PACKET_RCVD;
>> }
>>
>> +/* Called with rcu_read_lock and BH disabled. */
>> +static int gre_err(struct sk_buff *skb, u32 info,
>> + const struct tnl_ptk_info *tpi)
>> +{
>> + struct ovs_net *ovs_net;
>> + struct vport *vport;
>> +
>> + ovs_net = net_generic(dev_net(skb->dev), ovs_net_id);
>> + vport = rcu_dereference(ovs_net->vport_net.gre_vport);
>> + if (unlikely(!vport))
>> + return PACKET_REJECT;
>> + else
>> + return PACKET_RCVD;
>
>Sorry, I forgot to say this before - if we receive the packet then we
>should also call consume_skb() on it.
Maybe there is no need to call consume_skb()? The icmp_rcv() would
call kfree_skb() for us. I also checked the ipgre_err(), it return
PACKET_RCVD without call consume_skb() too.
Regards,
Wei Zhang
Re: ext4 performance falloff
On 04/05/2014 04:56 AM, Theodore Ts'o wrote:
On Sat, Apr 05, 2014 at 01:00:55AM +0800, Daniel J Blueman wrote:
On a larger system 1728 cores/4.5TB memory and 3.13.9, I'm seeing very low
600KB/s cached write performance to a local ext4 filesystem:
> Thanks for the heads up. Most (all?) of the ext4 don't have systems
> with thousands of cores, so these issues generally don't come up for
> us, and so we're not likely (hell, very unlikely!) to notice potential
> problems cause by these sorts of uber-large systems.
Hehe. It's not every day we get access to these systems also.
Analysis shows that ext4 is reading from all cores' cpu-local data (thus
expensive off-NUMA-node access) for each block written:
if (free_clusters - (nclusters + rsv + dirty_clusters) <
EXT4_FREECLUSTERS_WATERMARK) {
free_clusters = percpu_counter_sum_positive(fcc);
dirty_clusters = percpu_counter_sum_positive(dcc);
}
This threshold is defined as:
#define EXT4_FREECLUSTERS_WATERMARK (4 * (percpu_counter_batch *
nr_cpu_ids))
...
The problem we are trying to solve here is that when we do delayed
allocation, we're making an implicit promise that there will be space
available
I've done the calculations, and 4 * 32 * 1728 cores = 221184 blocks,
or 864 megabytes. That would mean that the file system is over 98%
full, so that's actually pretty reasonable; most of the time there's
more free space than that.
The filesystem is empty after the mkfs; the approach here may make sense
if we want to allow all cores to write to this FS, but here we have one.
Instrumenting shows that free_clusters=16464621 nclusters=1 rsv=842790
dirty_clusters=0 percpu_counter_batch=3456 nr_cpu_ids=1728; below 91GB
space, we'd hit this issue. It feels more sensible to start this
behaviour when the FS is say 98% full, irrespective of the number of
cores, but that's not why the behaviour is there.
Since these block devices are attached to a single NUMA node's IO link,
there is a scaling limitation there anyway, so there may be rationale in
limiting this to use min(256,nr_cpu_ids) maybe?
It looks like the real problem is that we're using nr_cpu_ids, which
is the maximum possible number of cpu's that the system can support,
which is different from the number of cpu's that you currently have.
For normal kernels nr_cpu_ids is small, so that has never been a
problem, but I bet you have nr_cpu_ids set to something really large,
right?
If you change nr_cpu_ids to total_cpus in the definition of
EXT4_FREECLUSTERS_WATERMARK, does that make things better for your
system?
I have reproduced this with CPU hotplug disabled, so nr_cpu_ids is
nicely at 1728.
Thanks,
Daniel
--
Daniel J Blueman
Principal Software Engineer, Numascale
--
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/
rtc: hang on boot during unregistration
Hi all,
I got the following spew while booting. My VM proceeded to hang and die.
[ 16.620530] =
[ 16.621059] [ INFO: possible recursive locking detected ]
[ 16.622024] 3.14.0-next-20140403-sasha-00019-g7474aa9-dirty #376 Not tainted
[ 16.624145] -
[ 16.625261] kworker/0:1/1069 is trying to acquire lock:
[ 16.626300] ((&(>release)->work)){+.+.+.}, at: flush_work
(kernel/workqueue.c:2880)
[ 16.628258]
[ 16.628258] but task is already holding lock:
[ 16.629415] ((&(>release)->work)){+.+.+.}, at: process_one_work
(include/linux/workqueue.h:186 kernel/workqueue.c:611 kernel/workqueue.c:638
kernel/workqueue.c:2214)
[ 16.630106]
[ 16.630106] other info that might help us debug this:
[ 16.630106] Possible unsafe locking scenario:
[ 16.630106]
[ 16.630106]CPU0
[ 16.630106]
[ 16.630106] lock((&(>release)->work));
[ 16.630106] lock((&(>release)->work));
[ 16.630106]
[ 16.630106] *** DEADLOCK ***
[ 16.630106]
[ 16.630106] May be due to missing lock nesting notation
[ 16.630106]
[ 16.630106] 2 locks held by kworker/0:1/1069:
[ 16.630106] #0: ("events"){.+.+.+}, at: process_one_work
(include/linux/workqueue.h:186 kernel/workqueue.c:611 kernel/workqueue.c:638
kernel/workqueue.c:2214)
[ 16.630106] #1: ((&(>release)->work)){+.+.+.}, at: process_one_work
(include/linux/workqueue.h:186 kernel/workqueue.c:611 kernel/workqueue.c:638
kernel/workqueue.c:2214)
[ 16.630106]
[ 16.630106] stack backtrace:
[ 16.630106] CPU: 0 PID: 1069 Comm: kworker/0:1 Not tainted
3.14.0-next-20140403-sasha-00019-g7474aa9-dirty #376
[ 16.630106] Workqueue: events kobject_delayed_cleanup
[ 16.630106] b59d09d0 88007c6a58d8 b24bfb2f
[ 16.630106] b59d09d0 88007c6a59d8 af1c4c8a
88007c5a3d98
[ 16.630106] 88007c5a3000 8801 af1c0e18
88007c5a3d60
[ 16.630106] Call Trace:
[ 16.630106] dump_stack (lib/dump_stack.c:52)
[ 16.630106] __lock_acquire (kernel/locking/lockdep.c:1740
kernel/locking/lockdep.c:1783 kernel/locking/lockdep.c:2115
kernel/locking/lockdep.c:3182)
[ 16.630106] ? check_irq_usage (kernel/locking/lockdep.c:1638)
[ 16.630106] ? __lock_acquire (kernel/locking/lockdep.c:3189)
[ 16.630106] lock_acquire (arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 16.630106] ? flush_work (kernel/workqueue.c:2880)
[ 16.630106] flush_work (kernel/workqueue.c:2884)
[ 16.630106] ? flush_work (kernel/workqueue.c:2880)
[ 16.630106] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 16.630106] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98
kernel/locking/lockdep.c:254)
[ 16.630106] ? try_to_grab_pending (kernel/workqueue.c:1260
kernel/workqueue.c:1259)
[ 16.630106] ? __cancel_work_timer (arch/x86/include/asm/paravirt.h:809
(discriminator 2) kernel/workqueue.c:2913 (discriminator 2))
[ 16.630106] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 16.630106] __cancel_work_timer (arch/x86/include/asm/bitops.h:313
kernel/workqueue.c:610 kernel/workqueue.c:644 kernel/workqueue.c:2916)
[ 16.630106] cancel_work_sync (kernel/workqueue.c:2941)
[ 16.630106] work_fixup_free (kernel/workqueue.c:479)
[ 16.630106] __debug_check_no_obj_freed (lib/debugobjects.c:277
lib/debugobjects.c:700)
[ 16.630106] debug_check_no_obj_freed (lib/debugobjects.c:726)
[ 16.630106] kfree (mm/slub.c:2679 mm/slub.c:3401)
[ 16.630106] ? rtc_device_release (drivers/rtc/class.c:35)
[ 16.630106] rtc_device_release (drivers/rtc/class.c:35)
[ 16.630106] device_release (drivers/base/core.c:246)
[ 16.630106] kobject_delayed_cleanup (lib/kobject.c:629 lib/kobject.c:638)
[ 16.630106] process_one_work (kernel/workqueue.c:2221
include/linux/jump_label.h:105 include/trace/events/workqueue.h:111
kernel/workqueue.c:2226)
[ 16.630106] ? process_one_work (include/linux/workqueue.h:186
kernel/workqueue.c:611 kernel/workqueue.c:638 kernel/workqueue.c:2214)
[ 16.630106] worker_thread (kernel/workqueue.c:2348)
[ 16.630106] ? rescuer_thread (kernel/workqueue.c:2297)
[ 16.630106] kthread (kernel/kthread.c:219)
[ 16.630106] ? kthread_create_on_node (kernel/kthread.c:185)
[ 16.630106] ret_from_fork (arch/x86/kernel/entry_64.S:555)
[ 16.630106] ? kthread_create_on_node (kernel/kthread.c:185)
Thanks,
Sasha
--
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] Fix bad percpu counter state during suspend
Hi, I got a bug report yesterday from Laszlo Ersek , in which he states that his kvm instance fails to suspend. He Laszlo bisected it down to this commit: commit 1cf7e9c68fe84248174e998922b39e508375e7c1 Author: Jens Axboe Date: Fri Nov 1 10:52:52 2013 -0600 virtio_blk: blk-mq support where virtio-blk is converted to use the blk-mq infrastructure. After digging a bit, it became clear that the issue was with the queue drain. blk-mq tracks queue usage in a percpu counter, which is incremented on request alloc and decremented when the request is freed. The initial hunt was for an inconsistency in blk-mq, but everything seemed fine. In fact, the counter only returned crazy values when suspend was in progress. When a CPU is unplugged, the percpu counters merges that CPU state with the general state. blk-mq takes care to register a hotcpu notifier with the appropriate priority, so we know it runs after the percpu counter notifier. However, the percpu counter notifier only merges the state when the CPU is fully gone. This leaves a state transition where the CPU going away is no longer in the online mask, yet it still holds private values. This means that in this state, percpu_counter_sum() returns invalid results, and the suspend then hangs waiting for abs(dead-cpu-value) requests to complete which of course will never happen. Fix this by clearing the state earlier, so we never have a case where the CPU isn't in online mask but still holds private state. This bug has been there since forever, I guess we don't have a lot of users where percpu counters needs to be reliable during the suspend cycle. Reported-by: Laszlo Ersek Tested-by: Laszlo Ersek Signed-off-by: Jens Axboe diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c index 8280a5dd1727..7dd33577b905 100644 --- a/lib/percpu_counter.c +++ b/lib/percpu_counter.c @@ -169,7 +169,7 @@ static int percpu_counter_hotcpu_callback(struct notifier_block *nb, struct percpu_counter *fbc; compute_batch_value(); - if (action != CPU_DEAD) + if (action != CPU_DEAD && action != CPU_DEAD_FROZEN) return NOTIFY_OK; cpu = (unsigned long)hcpu; -- 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: Bad DMA from Marvell 9230
On 27/03/14 09:19 AM, Tejun Heo wrote: On Thu, Mar 27, 2014 at 05:57:37PM +1100, Benjamin Herrenschmidt wrote: I've contacted Marvell, but I was wondering if anybody here had already experienced something similar or has an idea of what else the chip might be doing wrong so we can try to find a workaround ? No idea. First time to hear such problem. :( There are other Marvell controllers that do DMA requests from the wrong PCI function ID and cause IOMMU issues, so it seems like testing on such systems (or just validating the DMA transactions done by the controller by some other means) isn't something that Marvell likes to do. Presumably reading from address 0 is normally fine without an IOMMU, so this problem wouldn't be noticed otherwise. -- 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] Documentation: spelling error changes
Fixed multiple spelling errors. Acked-by: Randy Dunlap Signed-off-by: Carlos E. Garcia --- Documentation/DMA-attributes.txt | 2 +- Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +- Documentation/devicetree/bindings/bus/mvebu-mbus.txt | 2 +- Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt | 2 +- Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt | 2 +- Documentation/devicetree/bindings/mmc/samsung-sdhci.txt | 2 +- Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 2 +- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 2 +- Documentation/devicetree/bindings/mtd/gpmc-onenand.txt | 2 +- .../devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt| 12 ++-- Documentation/devicetree/bindings/powerpc/4xx/reboot.txt | 2 +- Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt | 2 +- Documentation/devicetree/bindings/regulator/regulator.txt| 2 +- Documentation/devicetree/bindings/spi/spi-bus.txt| 2 +- Documentation/dma-buf-sharing.txt| 2 +- Documentation/dynamic-debug-howto.txt| 2 +- Documentation/edac.txt | 2 +- Documentation/fb/sm501.txt | 2 +- Documentation/fb/sstfb.txt | 2 +- Documentation/filesystems/proc.txt | 4 ++-- Documentation/filesystems/sharedsubtree.txt | 2 +- Documentation/gpio/consumer.txt | 2 +- Documentation/hid/uhid.txt | 2 +- Documentation/input/alps.txt | 2 +- Documentation/input/input.txt| 2 +- Documentation/mtd/nand/pxa3xx-nand.txt | 2 +- Documentation/networking/can.txt | 2 +- Documentation/networking/dccp.txt| 2 +- Documentation/powerpc/transactional_memory.txt | 2 +- Documentation/rbtree.txt | 2 +- Documentation/rfkill.txt | 2 +- Documentation/robust-futexes.txt | 2 +- Documentation/s390/monreader.txt | 2 +- Documentation/security/Yama.txt | 2 +- Documentation/sound/alsa/ALSA-Configuration.txt | 4 ++-- Documentation/trace/events.txt | 2 +- Documentation/usb/mass-storage.txt | 2 +- Documentation/virtual/kvm/api.txt| 2 +- Documentation/vm/transhuge.txt | 4 ++-- Documentation/x86/earlyprintk.txt| 2 +- Documentation/x86/i386/IO-APIC.txt | 2 +- 41 files changed, 49 insertions(+), 49 deletions(-) diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt index cc2450d..18dc52c 100644 --- a/Documentation/DMA-attributes.txt +++ b/Documentation/DMA-attributes.txt @@ -98,5 +98,5 @@ DMA_ATTR_FORCE_CONTIGUOUS By default DMA-mapping subsystem is allowed to assemble the buffer allocated by dma_alloc_attrs() function from individual pages if it can be mapped as contiguous chunk into device dma address space. By -specifing this attribute the allocated buffer is forced to be contiguous +specifying this attribute the allocated buffer is forced to be contiguous also in physical memory. diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index af9b4a0..aa719623 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -114,5 +114,5 @@ Boards: - AM43x EPOS EVM compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43" -- DRA7 EVM: Software Developement Board for DRA7XX +- DRA7 EVM: Software Development Board for DRA7XX compatible = "ti,dra7-evm", "ti,dra7" diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt index 7586fb6..5fa44f5 100644 --- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt +++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt @@ -197,7 +197,7 @@ to be set by the operating system and that are guaranteed to be free of overlaps with one another or with the system memory ranges. Each entry in the property refers to exactly one window. If the operating system -choses to use a different set of mbus windows, it must ensure that any address +chooses to use a different set of mbus windows, it must ensure that any address translations performed from downstream devices are adapted accordingly. The operating system may insert additional mbus windows that do not conflict diff
Re: [RFC PATCH] PCI: Introduce new device binding path using pci_dev.driver_override
On 04/04/2014 06:35 PM, Kim Phillips wrote:
Needed by platform device drivers, such as the vfio-platform driver [1],
in order to bypass the existing OF, ACPI, id_table and name string matches,
and successfully be able to be bound to any device, like so:
echo vfio-platform > /sys/bus/platform/devices/fff51000.ethernet/driver_override
echo fff51000.ethernet >
/sys/bus/platform/devices/fff51000.ethernet/driver/unbind
echo fff51000.ethernet > /sys/bus/platform/drivers_probe
This mimics "PCI: Introduce new device binding path using
pci_dev.driver_override" [2], which is an interface enhancement
for more deterministic PCI device binding, e.g., when in the
presence of hotplug.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1402.1/00177.html
[2] http://thread.gmane.org/gmane.linux.kernel.iommu/4605
Signed-off-by: Kim Phillips
---
if this looks ok, should it be included in the next version of the
vfio-platform submission series, like last time ([1] above)?
Documentation/ABI/testing/sysfs-bus-platform | 17 ++
drivers/base/platform.c | 46
include/linux/platform_device.h | 1 +
3 files changed, 64 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-platform
diff --git a/Documentation/ABI/testing/sysfs-bus-platform
b/Documentation/ABI/testing/sysfs-bus-platform
new file mode 100644
index 000..6b14a6a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -0,0 +1,17 @@
+What: /sys/bus/platform/devices/.../driver_override
+Date: April 2014
+Contact: Kim Phillips
+Description:
+ This file allows the driver for a device to be specified
+ which will override standard OF, ACPI, ID table, and name
+ matching. When specified, only a driver with a name matching
+ the value written to driver_override will have an opportunity
+ to bind to the device. The override may be cleared by
+ writing an empty string (ex. echo > driver_override), returning
+ the device to standard matching rules binding. Writing to
+ driver_override does not automatically unbind the device from
+ its current driver or make any attempt to automatically load
+ the specified driver name. If no driver with a matching name
+ is currently loaded in the kernel, no match will be found.
+ This also allows devices to opt-out of driver binding using
+ a driver_override name such as "none".
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..ded1db1 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -690,8 +691,49 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *a,
}
static DEVICE_ATTR_RO(modalias);
+static ssize_t driver_override_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ char *driver_override, *old = pdev->driver_override;
+
+ if (count > PATH_MAX)
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
+ if (!driver_override)
+ return -ENOMEM;
+
+ while (strlen(driver_override) &&
+ driver_override[strlen(driver_override) - 1] == '\n')
+ driver_override[strlen(driver_override) - 1] = '\0';
+
Seems to me that something like
cp = strchr(driver_override, '\n');
if (cp)
*cp = '\0';
would be much simpler.
Guenter
--
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 PATCHC 3/3] sched/fair: use the idle state info to choose the idlest cpu
On Friday, April 04, 2014 12:56:52 PM Nicolas Pitre wrote:
> On Fri, 4 Apr 2014, Rafael J. Wysocki wrote:
>
> > On Tuesday, April 01, 2014 11:05:49 PM Nicolas Pitre wrote:
> > > On Fri, 28 Mar 2014, Daniel Lezcano wrote:
> > >
> > > > As we know in which idle state the cpu is, we can investigate the
> > > > following:
> > > >
> > > > 1. when did the cpu entered the idle state ? the longer the cpu is
> > > > idle, the
> > > > deeper it is idle
> > > > 2. what exit latency is ? the greater the exit latency is, the deeper
> > > > it is
> > > >
> > > > With both information, when all cpus are idle, we can choose the idlest
> > > > cpu.
> > > >
> > > > When one cpu is not idle, the old check against weighted load applies.
> > > >
> > > > Signed-off-by: Daniel Lezcano
> > >
> > > There seems to be some problems with the implementation.
> > >
> > > > @@ -4336,20 +4337,53 @@ static int
> > > > find_idlest_cpu(struct sched_group *group, struct task_struct *p, int
> > > > this_cpu)
> > > > {
> > > > unsigned long load, min_load = ULONG_MAX;
> > > > - int idlest = -1;
> > > > + unsigned int min_exit_latency = UINT_MAX;
> > > > + u64 idle_stamp, min_idle_stamp = ULONG_MAX;
> > >
> > > I don't think you really meant to assign an u64 variable with ULONG_MAX.
> > > You probably want ULLONG_MAX here. And probably not in fact (more
> > > later).
> > >
> > > > +
> > > > + struct rq *rq;
> > > > + struct cpuidle_power *power;
> > > > +
> > > > + int cpu_idle = -1;
> > > > + int cpu_busy = -1;
> > > > int i;
> > > >
> > > > /* Traverse only the allowed CPUs */
> > > > for_each_cpu_and(i, sched_group_cpus(group),
> > > > tsk_cpus_allowed(p)) {
> > > > - load = weighted_cpuload(i);
> > > >
> > > > - if (load < min_load || (load == min_load && i ==
> > > > this_cpu)) {
> > > > - min_load = load;
> > > > - idlest = i;
> > > > + if (idle_cpu(i)) {
> > > > +
> > > > + rq = cpu_rq(i);
> > > > + power = rq->power;
> > > > + idle_stamp = rq->idle_stamp;
> > > > +
> > > > + /* The cpu is idle since a shorter time */
> > > > + if (idle_stamp < min_idle_stamp) {
> > > > + min_idle_stamp = idle_stamp;
> > > > + cpu_idle = i;
> > > > + continue;
> > >
> > > Don't you want the highest time stamp in order to select the most
> > > recently idled CPU? Favoring the CPU which has been idle the longest
> > > makes little sense.
> >
> > It may make sense if the hardware can auto-promote CPUs to deeper C-states.
>
> If so the promotion will happen over time, no? What I'm saying here is
> that those CPUs which have been idle longer should not be favored when
> it is time to select a CPU for a task to run. More recently idled CPUs
> are more likely to be in a shallower C-state.
>
> > Something like that happens with package C-states that are only entered when
> > all cores have entered a particular core C-state already. In that case the
> > probability of the core being in a deeper state grows with time.
>
> Exactly what I'm saying.
Right, I got that the other way around by mistake.
> Also here it is worth remembering that the scheduling domains should
> represent those packages that share common C-states at a higher level.
> The scheduler can then be told not to balance across domains if it
> doesn't need to in order to favor the conditions for those package
> C-states to be used. That's what the task packing patch series is
> about, independently of this one.
>
> > That said I would just drop this heuristics for the time being. If
> > auto-promotion
> > is disregarded, it doesn't really matter how much time the given CPU has
> > been idle
> > except for one case: When the target residency of its idle state hasn't been
> > reached yet, waking up the CPU may be a mistake (depending on how deep the
> > state
> > actually is, but for the majority of drivers in the tree we don't have any
> > measure
> > of that).
>
> There is one reason for considering the time a CPU has been idle,
> assuming equivalent C-state, and that is cache snooping. The longer a
> CPU is idle, the more likely its cache content will have been claimed
> and migrated by other CPUs. Of course that doesn't make much difference
> for deeper C-states where the cache isn't preserved, but it is probably
> simpler and cheaper to apply this heuristic in all cases.
Yes, that sounds like it might be a reason, but I'd like to see numbers
confirming that to be honest.
> > > > + }
> > > > +
> > > > + /* The cpu is idle but the exit_latency is
> > > > shorter */
> > > > + if (power && power->exit_latency <
> > >
Re: [RFC PATCH] PCI: Introduce new device binding path using pci_dev.driver_override
Needed by platform device drivers, such as the vfio-platform driver [1],
in order to bypass the existing OF, ACPI, id_table and name string matches,
and successfully be able to be bound to any device, like so:
echo vfio-platform > /sys/bus/platform/devices/fff51000.ethernet/driver_override
echo fff51000.ethernet >
/sys/bus/platform/devices/fff51000.ethernet/driver/unbind
echo fff51000.ethernet > /sys/bus/platform/drivers_probe
This mimics "PCI: Introduce new device binding path using
pci_dev.driver_override" [2], which is an interface enhancement
for more deterministic PCI device binding, e.g., when in the
presence of hotplug.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1402.1/00177.html
[2] http://thread.gmane.org/gmane.linux.kernel.iommu/4605
Signed-off-by: Kim Phillips
---
if this looks ok, should it be included in the next version of the
vfio-platform submission series, like last time ([1] above)?
Documentation/ABI/testing/sysfs-bus-platform | 17 ++
drivers/base/platform.c | 46
include/linux/platform_device.h | 1 +
3 files changed, 64 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-platform
diff --git a/Documentation/ABI/testing/sysfs-bus-platform
b/Documentation/ABI/testing/sysfs-bus-platform
new file mode 100644
index 000..6b14a6a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -0,0 +1,17 @@
+What: /sys/bus/platform/devices/.../driver_override
+Date: April 2014
+Contact: Kim Phillips
+Description:
+ This file allows the driver for a device to be specified
+ which will override standard OF, ACPI, ID table, and name
+ matching. When specified, only a driver with a name matching
+ the value written to driver_override will have an opportunity
+ to bind to the device. The override may be cleared by
+ writing an empty string (ex. echo > driver_override), returning
+ the device to standard matching rules binding. Writing to
+ driver_override does not automatically unbind the device from
+ its current driver or make any attempt to automatically load
+ the specified driver name. If no driver with a matching name
+ is currently loaded in the kernel, no match will be found.
+ This also allows devices to opt-out of driver binding using
+ a driver_override name such as "none".
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..ded1db1 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -690,8 +691,49 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *a,
}
static DEVICE_ATTR_RO(modalias);
+static ssize_t driver_override_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ char *driver_override, *old = pdev->driver_override;
+
+ if (count > PATH_MAX)
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
+ if (!driver_override)
+ return -ENOMEM;
+
+ while (strlen(driver_override) &&
+ driver_override[strlen(driver_override) - 1] == '\n')
+ driver_override[strlen(driver_override) - 1] = '\0';
+
+ if (strlen(driver_override)) {
+ pdev->driver_override = driver_override;
+ } else {
+ kfree(driver_override);
+ pdev->driver_override = NULL;
+ }
+
+ kfree(old);
+
+ return count;
+}
+
+static ssize_t driver_override_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ return sprintf(buf, "%s\n", pdev->driver_override);
+}
+static DEVICE_ATTR_RW(driver_override);
+
+
static struct attribute *platform_dev_attrs[] = {
_attr_modalias.attr,
+ _attr_driver_override.attr,
NULL,
};
ATTRIBUTE_GROUPS(platform_dev);
@@ -747,6 +789,10 @@ static int platform_match(struct device *dev, struct
device_driver *drv)
struct platform_device *pdev = to_platform_device(dev);
struct platform_driver *pdrv = to_platform_driver(drv);
+ /* When driver_override is set, only bind to the matching driver */
+ if (pdev->driver_override)
+ return !strcmp(pdev->driver_override, drv->name);
+
/* Attempt an OF style match first */
if (of_driver_match_device(dev, drv))
return 1;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index
Re: [GIT PULL] cgroup changes for v3.15-rc1
On Fri, Apr 4, 2014 at 6:11 PM, Linus Torvalds
wrote:
>
> I'll try to pick kernels away from that, but that makes bisection much
> less effective.
Ok, I think I'm away from the broken region. The problem seems to be in between
good: 8e30e2b8ba0e ("cgroup: restructure locking and error handling in
cgroup_mount()")
bad: 6f30558f37bf ("cgroup: make cgroup hold onto its kernfs_node")
and let's see what bisect says about the rest.. Does that give you any ideas?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.13: disagrees about version of symbol
On Tue, Apr 01, 2014 at 01:38:10AM +0200, Thomas Bächler wrote: > Am 01.04.2014 01:34, schrieb Andi Kleen: > >> This problem persists in v3.14, i.e. I still have to revert > >> 83460ec8dcac14142e7860a01fa59c267ac4657c in order to get a working > >> kernel on i686. I would really appreciate if someone would actually read > >> my original mail from about 3 months ago and write an answer. > > > > Can you resend it please? > > It's available here: https://lkml.org/lkml/2014/1/26/22 > > For convenience, here is a copy-and-paste of the full text: I did some experiments know and I can't find any 32bit modules that do not load with 32bit MODVERSIONS on or off with a current tree. Do you have a specific config? Specific compiler version? Thanks, -Andi -- 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] cgroup changes for v3.15-rc1
On Fri, Apr 4, 2014 at 6:06 PM, Linus Torvalds wrote: > > Will report back soon when I've narrowed it down more. Ok, that may end up being harder than it looked. Commit a755180bab81c038a6989d7ab746c702f1b3ec03 doesn't boot for me at all, so apparently there are some really broken points in that whole development chain. I'll try to pick kernels away from that, but that makes bisection much less effective. Linus -- 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] cgroup changes for v3.15-rc1
On Thu, Apr 3, 2014 at 9:49 AM, Tejun Heo wrote: > > A lot updates for cgroup [...] Btw, just a heads up to let you know: I'm in the middle of bisecting why my machine no longer reboots cleanly, and while I'm a few boots away from pinpointing it exactly, it has now drilled down to the point that the only remaining commits are from your cgroup pull that I pulled yesterday. Maybe I screwed something up in the bisection and it's not 100% reliable, but I don't think so. Will report back soon when I've narrowed it down more. Linus -- 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: [mm] e04ddfd12aa: +9.4% ebizzy.throughput
On Fri, 2014-04-04 at 21:59 +0800, Fengguang Wu wrote:
> Hi Davidlohr,
>
> FYI, there are noticeable ebizzy throughput increases on commit
> e04ddfd12aa03471eff7daf3bc2435c7cea8e21f ("mm: per-thread vma caching")
Cool, thanks for letting me know.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] arch/hexagon changes for 3.15
Hello Linus, Please pull the following changes for Hexagon. They contain mostly cleanups for compilation with allmodconfig and some other miscellaneous fixes. Thanks, Richard Kuo The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel.git for-linus for you to fetch changes up to a9a44fdf329668125042055c569656aa83d8cccb: Hexagon: update CR year for elf.h (2014-04-04 18:20:02 -0500) Chen Gang (12): hexagon: kernel: remove useless variables 'dn', 'r' and 'err' in time_init_deferred() in "time.c" hexagon: kernel: kgdb: include related header for pass compiling. hexagon: include: asm: kgdb: extend DBG_MAX_REG_NUM for "cs0/1" arch: hexagon: kernel: add export symbol function __delay() arch: hexagon: Kconfig: add HAVE_DMA_ATTR in Kconfig and remove "linux/dma-mapping.h" from "asm/dma-mapping.h" arch: hexagon: include: asm: add prefix "hvm[ci]_" for all enum members in "hexagon_vm.h" arch: hexagon: include: uapi: asm: setup.h add swith macro __KERNEL__ arch: hexagon: include: asm: Kbuild: add generic "serial.h" in Kbuild arch: hexagon: include: asm: add "vga.h" in Kbuild arch: hexagon: kernel: reset.c: use function pointer instead of function for pm_power_off and export it arch: hexagon: kernel: hexagon_ksyms.c: export related symbols which various modules need arch: hexagon: include: asm: add generic macro 'mmiowb' in "io.h" Ilia Mirkin (1): hexagon: correct type on pgd copy Jiang Liu (1): smp, hexagon: kill SMP single function call interrupt Richard Kuo (6): Hexagon: add screen_info for VGA_CONSOLE Hexagon: fix atomic_set Hexagon: set the e_flags in user regset view for core dumps Hexagon: set ELF_EXEC_PAGESIZE to PAGE_SIZE Hexagon: remove SP macro Hexagon: update CR year for elf.h arch/hexagon/Kconfig |1 + arch/hexagon/include/asm/Kbuild |4 +- arch/hexagon/include/asm/atomic.h | 15 +- arch/hexagon/include/asm/delay.h |1 + arch/hexagon/include/asm/dma-mapping.h|1 - arch/hexagon/include/asm/elf.h|4 +- arch/hexagon/include/asm/hexagon_vm.h | 72 ++--- arch/hexagon/include/asm/io.h |2 + arch/hexagon/include/asm/kgdb.h |5 +- arch/hexagon/include/asm/pgalloc.h|2 +- arch/hexagon/include/asm/smp.h|1 - arch/hexagon/include/uapi/asm/registers.h |4 +- arch/hexagon/include/uapi/asm/setup.h |5 ++ arch/hexagon/kernel/Makefile |2 + arch/hexagon/kernel/hexagon_ksyms.c | 24 -- arch/hexagon/kernel/kgdb.c|2 + arch/hexagon/kernel/ptrace.c |1 + arch/hexagon/kernel/reset.c |5 +- arch/hexagon/kernel/screen_info.c |3 ++ arch/hexagon/kernel/smp.c |6 +-- arch/hexagon/kernel/time.c| 12 +++-- 21 files changed, 109 insertions(+), 63 deletions(-) create mode 100644 arch/hexagon/kernel/screen_info.c -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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] printk: add sleep time into timestamp
On 03/31/2014 08:20 PM, Neil Zhang wrote:
> Add sleep time into timestamp to reflect the actual time since
> sched_clock will be stopped during suspend.
>
> Thanks John Stultz for suggestion to use monotonic_to_bootbased.
>
> Signed-off-by: Neil Zhang
> ---
> kernel/printk/printk.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 4dae9cb..121f792 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -250,6 +250,18 @@ static char __log_buf[__LOG_BUF_LEN]
> __aligned(LOG_ALIGN);
> static char *log_buf = __log_buf;
> static u32 log_buf_len = __LOG_BUF_LEN;
>
> +static u64 print_clock(void)
> +{
> + struct timespec ts;
> + u64 ts_nsec = local_clock();
> +
> + ts = ns_to_timespec(ts_nsec);
> + monotonic_to_bootbased();
> + ts_nsec = timespec_to_ns();
> +
Note that this is still problematic as monotonic_to_bootbased currently
doesn't take the required locks to ensure it reads the data atomically.
If it were fixed to take the proper locks, this would risk a deadlock
since there are places where the timekeeping code takes a write on the
seqlock and then may call printk (or WARN_ON).
I suspect if this is going to be done, we need to have the timekeeping
provide the print_clock subsystem the boottime offset when it is changed
so the print_clock logic can manage this w/o grabbing timekeeping locks.
But as I mentioned in reply to Lei's similar patches, I'm not a huge fan
of the added complexity that will be required here when userspace like
syslog can timestamps kernel messages already (so additional rational
will be needed to move this forward).
thanks
-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: [GIT PULL] please pull file locking changes for 3.15
On Fri, 4 Apr 2014 14:28:16 -0700
Linus Torvalds wrote:
> On Mon, Mar 31, 2014 at 6:31 AM, Jeff Layton wrote:
> > The following changes since commit 29723adee11804b548903ddb1db666cf4a60f60e:
> >
> > locks: make locks_mandatory_area check for file-private locks (2014-03-31
> > 08:24:43 -0400)
> >
> > are available in the git repository at:
> >
> > git://git.samba.org/jlayton/linux.git locks-3.15
>
> Please please please use the proper scripts (or improve on whatever
> local script you use) that show the diffstat ("git diff -M --stat
> --summary") and shortlog for the pull request too.
>
> I want to know roughly what I'm pulling *before* I pull it, and while
> I can do a two-stage thing where I first fetch-and-inspect it, that's
> annoying. Your human-readable "Highlights" thing is good, and I want
> that too (I put commentary like that into the merge commit itself),
> but I do want that diffstat/shortlog in addition to the human-readable
> summary.
>
> Because having the diffstat in the pull request email not only gets me
> a heasd-up abotu what to expect, it also confirms that I'm on the same
> page as you are. It acts as a sanity-check for me when I can compare
> the diffstat you *claim* I should get with the diffstat I actually get
> after merging. So I really want to get that diffstat and shortlog as a
> sanity check.
>
> I also would prefer signed tags. It's not a must since it's not like
> git.samba.org is some random public site (I do _require_ them for pull
> requests from github etc), but it's definitely a "good thing" to have.
>
> Anyway, I'm going through my pile of filesystem pull requests, and
> I've pulled this into my tree. I'm just going through allmodconfig
> builds etc before pushing my merge out, so assuming that all works
> fine you don't need to resend this one. But for future pull requests,
> please do try to fix the above up.
>
> Linus
Thanks for the feedback and for pulling this in anyway. I'll make sure
to do all of that on subsequent pull requests.
Cheers!
--
Jeff Layton
--
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] arm64: Add missing Kconfig for CONFIG_STRICT_DEVMEM
The Kconfig for CONFIG_STRICT_DEVMEM is missing despite being used in mmap.c. Add it. Signed-off-by: Laura Abbott --- arch/arm64/Kconfig.debug | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug index 835c559..4be4336 100644 --- a/arch/arm64/Kconfig.debug +++ b/arch/arm64/Kconfig.debug @@ -6,6 +6,20 @@ config FRAME_POINTER bool default y +config STRICT_DEVMEM + bool "Filter access to /dev/mem" + depends on MMU +help + If this option is disabled, you allow userspace (root) access to all + of memory, including kernel and userspace memory. Accidental + access to this is obviously disastrous, but specific access can + be used by people debugging the kernel. + + If this option is switched on, the /dev/mem file only allows + userspace access to memory mapped peripherals. + + If in doubt, say Y. + config EARLY_PRINTK bool "Early printk support" default y -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/
[RESEND PATCH v3 8/9] tty: cadence: Document DT binding
Add binding documentation for the Cadence UART.
Signed-off-by: Soren Brinkmann
Acked-by: Peter Crosthwaite
Acked-by: Rob Herring
Tested-by: Michal Simek
---
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/serial/cdns,uart.txt | 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/cdns,uart.txt
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt
b/Documentation/devicetree/bindings/serial/cdns,uart.txt
new file mode 100644
index ..a3eb154c32ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
@@ -0,0 +1,20 @@
+Binding for Cadence UART Controller
+
+Required properties:
+- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
+- reg: Should contain UART controller registers location and length.
+- interrupts: Should contain UART controller interrupts.
+- clocks: Must contain phandles to the UART clocks
+ See ../clocks/clock-bindings.txt for details.
+- clock-names: Tuple to identify input clocks, must contain "uart_clk" and
"pclk"
+ See ../clocks/clock-bindings.txt for details.
+
+
+Example:
+ uart@e000 {
+ compatible = "cdns,uart-r1p8";
+ clocks = < 23>, < 40>;
+ clock-names = "uart_clk", "pclk";
+ reg = <0xE000 0x1000>;
+ interrupts = <0 27 4>;
+ };
--
1.9.1.1.gbb9f595
--
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/
[RESEND PATCH v3 1/9] tty: xuartps: Fix kernel-doc errors in the driver
From: Michal Simek
No functional changes.
Signed-off-by: Michal Simek
---
Changes in v3: None
Changes in v2:
- this patch has been added
---
drivers/tty/serial/xilinx_uartps.c | 109 +
1 file changed, 49 insertions(+), 60 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index f619ad5b5eae..b2f929e48ddd 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -163,11 +163,11 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
/**
* struct xuartps - device data
- * @port Pointer to the UART port
- * @refclk Reference clock
- * @aperclkAPB clock
- * @baud Current baud rate
- * @clk_rate_change_nb Notifier block for clock changes
+ * @port: Pointer to the UART port
+ * @refclk:Reference clock
+ * @aperclk: APB clock
+ * @baud: Current baud rate
+ * @clk_rate_change_nb:Notifier block for clock changes
*/
struct xuartps {
struct uart_port*port;
@@ -183,8 +183,8 @@ struct xuartps {
* @irq: Irq number
* @dev_id: Id of the port
*
- * Returns IRQHANDLED
- **/
+ * Return: IRQHANDLED
+ */
static irqreturn_t xuartps_isr(int irq, void *dev_id)
{
struct uart_port *port = (struct uart_port *)dev_id;
@@ -325,7 +325,7 @@ static irqreturn_t xuartps_isr(int irq, void *dev_id)
* @rbdiv: BDIV value (return value)
* @rcd: CD value (return value)
* @div8: Value for clk_sel bit in mod (return value)
- * Returns baud rate, requested baud when possible, or actual baud when there
+ * Return: baud rate, requested baud when possible, or actual baud when there
* was too much error, zero if no valid divisors are found.
*
* Formula to obtain baud rate is
@@ -384,7 +384,7 @@ static unsigned int xuartps_calc_baud_divs(unsigned int
clk, unsigned int baud,
* xuartps_set_baud_rate - Calculate and set the baud rate
* @port: Handle to the uart port structure
* @baud: Baud rate to set
- * Returns baud rate, requested baud when possible, or actual baud when there
+ * Return: baud rate, requested baud when possible, or actual baud when there
*was too much error, zero if no valid divisors are found.
*/
static unsigned int xuartps_set_baud_rate(struct uart_port *port,
@@ -419,7 +419,7 @@ static unsigned int xuartps_set_baud_rate(struct uart_port
*port,
* @nb:Notifier block
* @event: Notify event
* @data: Notifier data
- * Returns NOTIFY_OK on success, NOTIFY_BAD on error.
+ * Return: NOTIFY_OK on success, NOTIFY_BAD on error.
*/
static int xuartps_clk_notifier_cb(struct notifier_block *nb,
unsigned long event, void *data)
@@ -514,8 +514,7 @@ static int xuartps_clk_notifier_cb(struct notifier_block
*nb,
/**
* xuartps_start_tx - Start transmitting bytes
* @port: Handle to the uart port structure
- *
- **/
+ */
static void xuartps_start_tx(struct uart_port *port)
{
unsigned int status, numbytes = port->fifosize;
@@ -562,8 +561,7 @@ static void xuartps_start_tx(struct uart_port *port)
/**
* xuartps_stop_tx - Stop TX
* @port: Handle to the uart port structure
- *
- **/
+ */
static void xuartps_stop_tx(struct uart_port *port)
{
unsigned int regval;
@@ -577,8 +575,7 @@ static void xuartps_stop_tx(struct uart_port *port)
/**
* xuartps_stop_rx - Stop RX
* @port: Handle to the uart port structure
- *
- **/
+ */
static void xuartps_stop_rx(struct uart_port *port)
{
unsigned int regval;
@@ -593,8 +590,8 @@ static void xuartps_stop_rx(struct uart_port *port)
* xuartps_tx_empty - Check whether TX is empty
* @port: Handle to the uart port structure
*
- * Returns TIOCSER_TEMT on success, 0 otherwise
- **/
+ * Return: TIOCSER_TEMT on success, 0 otherwise
+ */
static unsigned int xuartps_tx_empty(struct uart_port *port)
{
unsigned int status;
@@ -608,8 +605,7 @@ static unsigned int xuartps_tx_empty(struct uart_port *port)
* transmitting char breaks
* @port: Handle to the uart port structure
* @ctl: Value based on which start or stop decision is taken
- *
- **/
+ */
static void xuartps_break_ctl(struct uart_port *port, int ctl)
{
unsigned int status;
@@ -636,8 +632,7 @@ static void xuartps_break_ctl(struct uart_port *port, int
ctl)
* @port: Handle to the uart port structure
* @termios: Handle to the input termios structure
* @old: Values of the previously saved termios structure
- *
- **/
+ */
static void xuartps_set_termios(struct uart_port *port,
struct ktermios *termios, struct ktermios *old)
{
@@ -761,8 +756,8 @@ static void xuartps_set_termios(struct uart_port *port,
* xuartps_startup - Called when an application opens a xuartps port
* @port: Handle to the uart port structure
*
- * Returns 0 on success, negative error otherwise
- **/
+ * Return: 0 on success,
[RESEND PATCH v3 3/9] tty: xuartps: Clean up
This is all white space and comment clean up. Mostly reformatting comments. Signed-off-by: Soren Brinkmann Tested-by: Michal Simek --- Changes in v3: None Changes in v2: None drivers/tty/serial/xilinx_uartps.c | 210 + 1 file changed, 74 insertions(+), 136 deletions(-) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index 2cd0cd456c7a..787a12064fa0 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -1,14 +1,13 @@ /* * Xilinx PS UART driver * - * 2011 - 2013 (C) Xilinx Inc. + * 2011 - 2014 (C) Xilinx Inc. * * 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. - * */ #if defined(CONFIG_SERIAL_XILINX_PS_UART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) @@ -49,39 +48,27 @@ static int rx_timeout = 10; module_param(rx_timeout, uint, S_IRUGO); MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255"); -/Register Map/ -/** UART - * - * Register offsets for the UART. - * - */ -#define XUARTPS_CR_OFFSET 0x00 /* Control Register [8:0] */ -#define XUARTPS_MR_OFFSET 0x04 /* Mode Register [10:0] */ -#define XUARTPS_IER_OFFSET 0x08 /* Interrupt Enable [10:0] */ -#define XUARTPS_IDR_OFFSET 0x0C /* Interrupt Disable [10:0] */ -#define XUARTPS_IMR_OFFSET 0x10 /* Interrupt Mask [10:0] */ -#define XUARTPS_ISR_OFFSET 0x14 /* Interrupt Status [10:0]*/ -#define XUARTPS_BAUDGEN_OFFSET 0x18 /* Baud Rate Generator [15:0] */ -#define XUARTPS_RXTOUT_OFFSET 0x1C /* RX Timeout [7:0] */ -#define XUARTPS_RXWM_OFFSET0x20 /* RX FIFO Trigger Level [5:0] */ -#define XUARTPS_MODEMCR_OFFSET 0x24 /* Modem Control [5:0] */ -#define XUARTPS_MODEMSR_OFFSET 0x28 /* Modem Status [8:0] */ -#define XUARTPS_SR_OFFSET 0x2C /* Channel Status [11:0] */ -#define XUARTPS_FIFO_OFFSET0x30 /* FIFO [15:0] or [7:0] */ -#define XUARTPS_BAUDDIV_OFFSET 0x34 /* Baud Rate Divider [7:0] */ -#define XUARTPS_FLOWDEL_OFFSET 0x38 /* Flow Delay [15:0] */ -#define XUARTPS_IRRX_PWIDTH_OFFSET 0x3C /* IR Minimum Received Pulse - Width [15:0] */ -#define XUARTPS_IRTX_PWIDTH_OFFSET 0x40 /* IR Transmitted pulse - Width [7:0] */ -#define XUARTPS_TXWM_OFFSET0x44 /* TX FIFO Trigger Level [5:0] */ - -/** Control Register - * - * The Control register (CR) controls the major functions of the device. - * - * Control Register Bit Definitions - */ +/* Register offsets for the UART. */ +#define XUARTPS_CR_OFFSET 0x00 /* Control Register */ +#define XUARTPS_MR_OFFSET 0x04 /* Mode Register */ +#define XUARTPS_IER_OFFSET 0x08 /* Interrupt Enable */ +#define XUARTPS_IDR_OFFSET 0x0C /* Interrupt Disable */ +#define XUARTPS_IMR_OFFSET 0x10 /* Interrupt Mask */ +#define XUARTPS_ISR_OFFSET 0x14 /* Interrupt Status */ +#define XUARTPS_BAUDGEN_OFFSET 0x18 /* Baud Rate Generator */ +#define XUARTPS_RXTOUT_OFFSET 0x1C /* RX Timeout */ +#define XUARTPS_RXWM_OFFSET0x20 /* RX FIFO Trigger Level */ +#define XUARTPS_MODEMCR_OFFSET 0x24 /* Modem Control */ +#define XUARTPS_MODEMSR_OFFSET 0x28 /* Modem Status */ +#define XUARTPS_SR_OFFSET 0x2C /* Channel Status */ +#define XUARTPS_FIFO_OFFSET0x30 /* FIFO */ +#define XUARTPS_BAUDDIV_OFFSET 0x34 /* Baud Rate Divider */ +#define XUARTPS_FLOWDEL_OFFSET 0x38 /* Flow Delay */ +#define XUARTPS_IRRX_PWIDTH_OFFSET 0x3C /* IR Minimum Received Pulse Width */ +#define XUARTPS_IRTX_PWIDTH_OFFSET 0x40 /* IR Transmitted pulse Width */ +#define XUARTPS_TXWM_OFFSET0x44 /* TX FIFO Trigger Level */ + +/* Control Register Bit Definitions */ #define XUARTPS_CR_STOPBRK 0x0100 /* Stop TX break */ #define XUARTPS_CR_STARTBRK0x0080 /* Set TX break */ #define XUARTPS_CR_TX_DIS 0x0020 /* TX disabled. */ @@ -92,14 +79,11 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255"); #define XUARTPS_CR_RXRST 0x0001 /* RX logic reset */ #define XUARTPS_CR_RST_TO 0x0040 /* Restart Timeout Counter */ -/** Mode Register - * +/* + * Mode Register: * The mode register (MR) defines the mode of transfer as well as the data * format. If this register is modified during transmission or reception, * data validity cannot be guaranteed. - * - * Mode Register Bit Definitions - * */ #define XUARTPS_MR_CLKSEL 0x0001 /* Pre-scalar selection */ #define XUARTPS_MR_CHMODE_L_LOOP 0x0200 /* Local loop back mode */ @@ -118,8 +102,8 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255"); #define XUARTPS_MR_CHARLEN_7_BIT 0x0004 /* 7 bits data */ #define XUARTPS_MR_CHARLEN_8_BIT 0x /* 8 bits data */
[RESEND PATCH v3 2/9] tty: xuartps: Initialize ports according to aliases
From: Michal Simek
Register port numbers according to order in DT aliases.
If aliases are not defined, order in DT is used.
If aliases are defined, register port id based
on that.
This patch ensures proper ttyPS0/1 assignment.
[soren]: Combined integer declarations in probe(), removed warning message
if no alias is found.
Signed-off-by: Michal Simek
Signed-off-by: Soren Brinkmann
---
The alias is an optional feature. Print a warning if it is not provided
does not seem appropriate.
Changes in v3: None
Changes in v2:
- this patch has been added
---
drivers/tty/serial/xilinx_uartps.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index b2f929e48ddd..2cd0cd456c7a 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1031,17 +1031,21 @@ static struct uart_port xuartps_port[2];
* xuartps_get_port - Configure the port from the platform device resource
* info
*
+ * @id: Port id
+ *
* Return: a pointer to a uart_port or NULL for failure
*/
-static struct uart_port *xuartps_get_port(void)
+static struct uart_port *xuartps_get_port(int id)
{
struct uart_port *port;
- int id;
- /* Find the next unused port */
- for (id = 0; id < XUARTPS_NR_PORTS; id++)
- if (xuartps_port[id].mapbase == 0)
- break;
+ /* Try the given port id if failed use default method */
+ if (xuartps_port[id].mapbase != 0) {
+ /* Find the next unused port */
+ for (id = 0; id < XUARTPS_NR_PORTS; id++)
+ if (xuartps_port[id].mapbase == 0)
+ break;
+ }
if (id >= XUARTPS_NR_PORTS)
return NULL;
@@ -1329,7 +1333,7 @@ static SIMPLE_DEV_PM_OPS(xuartps_dev_pm_ops,
xuartps_suspend, xuartps_resume);
*/
static int xuartps_probe(struct platform_device *pdev)
{
- int rc;
+ int rc, id;
struct uart_port *port;
struct resource *res, *res2;
struct xuartps *xuartps_data;
@@ -1380,9 +1384,13 @@ static int xuartps_probe(struct platform_device *pdev)
_data->clk_rate_change_nb))
dev_warn(>dev, "Unable to register clock notifier.\n");
#endif
+ /* Look for a serialN alias */
+ id = of_alias_get_id(pdev->dev.of_node, "serial");
+ if (id < 0)
+ id = 0;
/* Initialize the port structure */
- port = xuartps_get_port();
+ port = xuartps_get_port(id);
if (!port) {
dev_err(>dev, "Cannot get uart_port structure\n");
--
1.9.1.1.gbb9f595
--
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/
[RESEND PATCH v3 5/9] tty: xuartps: Refactor read-modify-writes
A lot of read-modify-write sequences used a one-line statement which nests a readl() within a writel(). Convert this into code sequences that make the three steps more obvious. Signed-off-by: Soren Brinkmann Tested-by: Michal Simek --- Changes in v3: None Changes in v2: None drivers/tty/serial/xilinx_uartps.c | 52 ++ 1 file changed, 24 insertions(+), 28 deletions(-) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index 814391038abb..b182ab8cfd07 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -437,9 +437,9 @@ static int xuartps_clk_notifier_cb(struct notifier_block *nb, spin_lock_irqsave(>port->lock, flags); /* Disable the TX and RX to set baud rate */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); spin_unlock_irqrestore(>port->lock, flags); @@ -464,9 +464,9 @@ static int xuartps_clk_notifier_cb(struct notifier_block *nb, spin_lock_irqsave(>port->lock, flags); /* Set TX/RX Reset */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TXRST | XUARTPS_CR_RXRST; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); while (xuartps_readl(XUARTPS_CR_OFFSET) & (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST)) @@ -479,10 +479,9 @@ static int xuartps_clk_notifier_cb(struct notifier_block *nb, */ xuartps_writel(rx_timeout, XUARTPS_RXTOUT_OFFSET); ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); - xuartps_writel( - (ctrl_reg & ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS)) | - (XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN), - XUARTPS_CR_OFFSET); + ctrl_reg &= ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS); + ctrl_reg |= XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); spin_unlock_irqrestore(>port->lock, flags); @@ -631,9 +630,9 @@ static void xuartps_set_termios(struct uart_port *port, } /* Disable the TX and RX to set baud rate */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); /* * Min baud rate = 6bps and Max Baud Rate is 10Mbps for 100Mhz clk @@ -651,20 +650,18 @@ static void xuartps_set_termios(struct uart_port *port, uart_update_timeout(port, termios->c_cflag, baud); /* Set TX/RX Reset */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST), - XUARTPS_CR_OFFSET); - ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TXRST | XUARTPS_CR_RXRST; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); /* * Clear the RX disable and TX disable bits and then set the TX enable * bit and RX enable bit to enable the transmitter and receiver. */ - xuartps_writel( - (ctrl_reg & ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS)) - | (XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg &= ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS); + ctrl_reg |= XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); xuartps_writel(rx_timeout, XUARTPS_RXTOUT_OFFSET); @@ -1248,9 +1245,9 @@ static int xuartps_resume(struct device *device) spin_lock_irqsave(>lock, flags); /* Set TX/RX Reset */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TXRST | XUARTPS_CR_RXRST; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); while (xuartps_readl(XUARTPS_CR_OFFSET) &
[RESEND PATCH v3 4/9] tty: xuartps: Print warning in clock notifier
Print a warning if the clock notifier rejects a clock frequency change
to facilitate debugging (see:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/304329/focus=304379)
Signed-off-by: Soren Brinkmann
Tested-by: Michal Simek
---
Changes in v3: None
Changes in v2: None
drivers/tty/serial/xilinx_uartps.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index 787a12064fa0..814391038abb 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -429,8 +429,10 @@ static int xuartps_clk_notifier_cb(struct notifier_block
*nb,
* frequency.
*/
if (!xuartps_calc_baud_divs(ndata->new_rate, xuartps->baud,
- , , ))
+ , , )) {
+ dev_warn(port->dev, "clock rate change rejected\n");
return NOTIFY_BAD;
+ }
spin_lock_irqsave(>port->lock, flags);
--
1.9.1.1.gbb9f595
--
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/
[RESEND PATCH v3 9/9] ARM: zynq: DT: Migrate UART to Cadence binding
The Zynq UART is Cadence IP and the driver has been renamed accordingly.
Migrate the DT to use the new binding for the UART driver.
Signed-off-by: Soren Brinkmann
Acked-by: Peter Crosthwaite
Acked-by: Rob Herring
Tested-by: Michal Simek
---
This change depends on 'tty: xuartps: Rebrand driver as Cadence UART',
which introduces the new clock-names.
Changes in v3: None
Changes in v2: None
Signed-off-by: Soren Brinkmann
---
arch/arm/boot/dts/zynq-7000.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 789d0bacc110..d27eb5c21831 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -73,19 +73,19 @@
};
uart0: uart@e000 {
- compatible = "xlnx,xuartps";
+ compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "disabled";
clocks = < 23>, < 40>;
- clock-names = "ref_clk", "aper_clk";
+ clock-names = "uart_clk", "pclk";
reg = <0xE000 0x1000>;
interrupts = <0 27 4>;
};
uart1: uart@e0001000 {
- compatible = "xlnx,xuartps";
+ compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "disabled";
clocks = < 24>, < 41>;
- clock-names = "ref_clk", "aper_clk";
+ clock-names = "uart_clk", "pclk";
reg = <0xE0001000 0x1000>;
interrupts = <0 50 4>;
};
--
1.9.1.1.gbb9f595
--
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/
[RESEND PATCH v3 6/9] tty: xuartps: Don't write IRQ disable register to enable interrupts
A comment states, that, according to the data sheet, to enable interrupts the disable register should be written, but the enable register could be left untouched. And it suspsects a HW bug requiring to write both. Reviewing the data sheet, these statements seem wrong. Just as one would expect. Writing to the enable/disable register enables/disables interrupts. Hence the misleading comment and needless write to the disable register are removed from the enable sequence. Signed-off-by: Soren Brinkmann Tested-by: Michal Simek --- I added a few lines to comment the change and altered the summary line. In case this causes issues it should show up a little easier as a candidate to revert. Changes in v3: None Changes in v2: None --- drivers/tty/serial/xilinx_uartps.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index b182ab8cfd07..f9a2c2fc03c4 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -1085,11 +1085,7 @@ static void xuartps_console_write(struct console *co, const char *s, xuartps_writel(ctrl, XUARTPS_CR_OFFSET); - /* restore interrupt state, it seems like there may be a h/w bug -* in that the interrupt enable register should not need to be -* written based on the data sheet -*/ - xuartps_writel(~imr, XUARTPS_IDR_OFFSET); + /* restore interrupt state */ xuartps_writel(imr, XUARTPS_IER_OFFSET); if (locked) -- 1.9.1.1.gbb9f595 -- 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/
[mm] e04ddfd12aa: +9.4% ebizzy.throughput
Hi Davidlohr,
FYI, there are noticeable ebizzy throughput increases on commit
e04ddfd12aa03471eff7daf3bc2435c7cea8e21f ("mm: per-thread vma caching")
test case: lkp-st02/micro/ebizzy/200%-100-10
700141f349f2b05 e04ddfd12aa03471eff7daf3b
--- -
23726 ~ 0% +9.4% 25955 ~ 0% TOTAL ebizzy.throughput
1525 ~ 0% +9.3% 1667 ~ 0% TOTAL
ebizzy.throughput.per_thread.max
1428 ~ 0% +9.1% 1558 ~ 0% TOTAL
ebizzy.throughput.per_thread.min
14.42 ~ 0% +8.1% 15.59 ~ 0% TOTAL ebizzy.time.user
65.29 ~ 0% -1.8% 64.12 ~ 0% TOTAL ebizzy.time.sys
4290 ~17% -28.4% 3073 ~22% TOTAL
slabinfo.buffer_head.active_objs
4313 ~17% -28.8% 3073 ~22% TOTAL slabinfo.buffer_head.num_objs
165372 ~ 0% +9.2% 180527 ~ 0% TOTAL vmstat.system.in
1443 ~ 0% +8.1% 1560 ~ 0% TOTAL time.user_time
6529 ~ 0% -1.8% 6413 ~ 0% TOTAL time.system_time
Legend:
~XX%- stddev percent
[+-]XX% - change percent
ebizzy.throughput
26500 ++O---O---O+
O O O O O O O O O O O |
26000 ++ O O O O O |
| O O O |
| |
25500 ++ |
| |
25000 ++ |
| |
24500 ++ |
| |
*.*.*. .*. .*.*.*. .*.*. *.*.*.*.|
24000 ++*.* * *.* *.*.*.**.*.*.*.*.*.|
| *.*.*.*.*.*.*
23500 ++-+
[*] bisect-good sample
[O] bisect-bad sample
Thanks,
Fengguang
--
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/
[loopback] b17c706987f: +197.7% qperf.sctp.bw
Hi Daniel,
We are glad to find big SCTP performance improvements
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git master
commit b17c706987fa6f28bdc1771c8266e7a69e22adcb ("loopback: sctp: add
NETIF_F_SCTP_CSUM to device features")
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
3.848e+08 ~ 6%+197.7% 1.146e+09 ~ 5% bens/micro/qperf/600s
3.848e+08 ~ 6%+197.7% 1.146e+09 ~ 5% TOTAL qperf.sctp.bw
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
39.30 ~ 3% +91.0% 75.06 ~11% lkp-a06/micro/qperf/600s
39.30 ~ 3% +91.0% 75.06 ~11% TOTAL qperf.sctp.bw
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
126 ~ 0% -3.2%122 ~ 0% lkp-a06/micro/qperf/600s
126 ~ 0% -3.2%122 ~ 0% TOTAL qperf.sctp.latency
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
216270 ~ 2% -46.5% 115740 ~ 4% lkp-a06/micro/qperf/600s
216270 ~ 2% -46.5% 115740 ~ 4% TOTAL cpuidle.C4.usage
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
48722971 ~ 5% +45.1% 70681678 ~ 7% lkp-a06/micro/qperf/600s
48722971 ~ 5% +45.1% 70681678 ~ 7% TOTAL cpuidle.C2.time
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
370655 ~ 2% +46.8% 543952 ~ 7% lkp-a06/micro/qperf/600s
370655 ~ 2% +46.8% 543952 ~ 7% TOTAL cpuidle.C2.usage
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
1.00 ~13% -22.8% 0.77 ~15% lkp-a06/micro/qperf/600s
1.00 ~13% -22.8% 0.77 ~15% TOTAL
perf-profile.cpu-cycles.acpi_processor_ffh_cstate_enter.acpi_idle_enter_bm.cpuidle_enter_state.cpuidle_idle_call.arch_cpu_idle
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
18055616 ~ 4% +28.5% 23205101 ~ 2% bens/micro/qperf/600s
18055616 ~ 4% +28.5% 23205101 ~ 2% TOTAL proc-vmstat.numa_local
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
18055616 ~ 4% +28.5% 23205101 ~ 2% bens/micro/qperf/600s
18055616 ~ 4% +28.5% 23205101 ~ 2% TOTAL proc-vmstat.numa_hit
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
51480524 ~ 4% +37.7% 70886229 ~ 2% bens/micro/qperf/600s
15233974 ~ 0% +14.2% 17397187 ~ 3% lkp-a06/micro/qperf/600s
66714498 ~ 3% +32.3% 88283417 ~ 2% TOTAL proc-vmstat.pgalloc_normal
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
2.109e+08 ~ 4% +37.7% 2.904e+08 ~ 2% bens/micro/qperf/600s
24268359 ~ 0% +14.2% 27716949 ~ 3% lkp-a06/micro/qperf/600s
2.352e+08 ~ 3% +35.3% 3.181e+08 ~ 2% TOTAL proc-vmstat.pgfree
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
1.594e+08 ~ 4% +37.7% 2.195e+08 ~ 2% bens/micro/qperf/600s
9034872 ~ 0% +14.2% 10321019 ~ 3% lkp-a06/micro/qperf/600s
1.685e+08 ~ 4% +36.4% 2.299e+08 ~ 2% TOTAL proc-vmstat.pgalloc_dma32
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
51262 ~ 2% -10.0% 46151 ~ 3% lkp-a06/micro/qperf/600s
51262 ~ 2% -10.0% 46151 ~ 3% TOTAL
time.involuntary_context_switches
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
65268 ~ 1% +6.8% 69676 ~ 0% bens/micro/qperf/600s
65268 ~ 1% +6.8% 69676 ~ 0% TOTAL vmstat.system.in
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
33939624 ~29% +22.6% 41609509 ~ 0% bens/micro/qperf/600s
4125867 ~ 1% +3.9%4285302 ~ 0% lkp-a06/micro/qperf/600s
38065492 ~26% +20.6% 45894812 ~ 0% TOTAL
time.voluntary_context_switches
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
129649 ~ 1% +6.8% 138432 ~ 0% bens/micro/qperf/600s
13874 ~ 1% +4.8% 14540 ~ 0% lkp-a06/micro/qperf/600s
143523 ~ 1% +6.6% 152972 ~ 0% TOTAL vmstat.system.cs
72f8e06f3ea022d b17c706987fa6f28bdc1771c8
--- -
739 ~19% +12.0%827 ~ 0% bens/micro/qperf/600s
812 ~ 0% -3.4%784 ~ 1% lkp-a06/micro/qperf/600s
1551 ~ 9% +3.9% 1612 ~ 0% TOTAL time.system_time
Legend:
~XX%- stddev percent
[+-]XX% - change percent
qperf.sctp.bw
1.3e+09 ++---+
1.2e+09 ++O O|
| O O O O O
Re: [PATCH v7 1/6] pci: Introduce pci_register_io_range() helper function.
On Fri, Mar 14, 2014 at 03:34:27PM +, Liviu Dudau wrote:
> Some architectures do not share x86 simple view of the PCI I/O space
> and instead use a range of addresses that map to bus addresses. For
> some architectures these ranges will be expressed by OF bindings
> in a device tree file.
It's true that the current Linux "x86 view of PCI I/O space" is pretty
simple and limited. But I don't think that's a fundamental x86 limitation
(other than the fact that the actual INB/OUTB/etc. CPU instructions
themselves are limited to a single 64K I/O port space).
Host bridges on x86 could have MMIO apertures that turn CPU memory accesses
into PCI port accesses. We could implement any number of I/O port spaces
this way, by making the kernel inb()/outb()/etc. interfaces smart enough to
use the memory-mapped space instead of (or in addition to) the
INB/OUTB/etc. instructions.
ia64 does this (see arch/ia64/include/asm/io.h for a little description)
and I think maybe one or two other arches have something similar.
> Introduce a pci_register_io_range() helper function that can be used
> by the architecture code to keep track of the I/O ranges described by the
> PCI bindings. If the PCI_IOBASE macro is not defined that signals
> lack of support for PCI and we return an error.
I don't quite see how you intend to use this, because this series doesn't
include any non-stub implementation of pci_register_io_range().
Is this anything like the ia64 strategy I mentioned above? If so, it would
be really nice to unify some of this stuff.
> Signed-off-by: Liviu Dudau
> Acked-by: Grant Likely
> Tested-by: Tanmay Inamdar
> ---
> drivers/of/address.c | 9 +
> include/linux/of_address.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 1a54f1f..be958ed 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -619,6 +619,15 @@ const __be32 *of_get_address(struct device_node *dev,
> int index, u64 *size,
> }
> EXPORT_SYMBOL(of_get_address);
>
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +{
> +#ifndef PCI_IOBASE
> + return -EINVAL;
> +#else
> + return 0;
> +#endif
> +}
> +
> unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> if (address > IO_SPACE_LIMIT)
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 5f6ed6b..40c418d 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -56,6 +56,7 @@ extern void __iomem *of_iomap(struct device_node *device,
> int index);
> extern const __be32 *of_get_address(struct device_node *dev, int index,
> u64 *size, unsigned int *flags);
>
> +extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
> extern unsigned long pci_address_to_pio(phys_addr_t addr);
>
> extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
> --
> 1.9.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: spelling error changes
On 03/31/2014 02:56 PM, Carlos Garcia wrote: > Fixed multiple spelling errors. > > Signed-off-by: Carlos E. Garcia > --- > Documentation/DMA-attributes.txt | 2 +- > Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +- > Documentation/devicetree/bindings/bus/mvebu-mbus.txt | 2 +- > Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt | 2 +- > Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt | 2 +- > Documentation/devicetree/bindings/mmc/samsung-sdhci.txt | 2 +- > Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 2 +- > Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 2 +- > Documentation/devicetree/bindings/mtd/gpmc-onenand.txt | 2 +- > .../devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt| 12 > ++-- > Documentation/devicetree/bindings/powerpc/4xx/reboot.txt | 2 +- > Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt | 2 +- > Documentation/devicetree/bindings/regulator/regulator.txt| 2 +- > Documentation/devicetree/bindings/spi/spi-bus.txt| 2 +- > Documentation/dma-buf-sharing.txt| 2 +- > Documentation/dynamic-debug-howto.txt| 2 +- > Documentation/edac.txt | 2 +- > Documentation/fb/sm501.txt | 2 +- > Documentation/fb/sstfb.txt | 2 +- > Documentation/filesystems/proc.txt | 4 ++-- > Documentation/filesystems/sharedsubtree.txt | 2 +- > Documentation/gpio/consumer.txt | 2 +- > Documentation/hid/uhid.txt | 2 +- > Documentation/input/alps.txt | 2 +- > Documentation/input/input.txt| 2 +- > Documentation/mtd/nand/pxa3xx-nand.txt | 2 +- > Documentation/networking/can.txt | 2 +- > Documentation/networking/dccp.txt| 2 +- > Documentation/powerpc/transactional_memory.txt | 2 +- > Documentation/rbtree.txt | 2 +- > Documentation/rfkill.txt | 2 +- > Documentation/robust-futexes.txt | 2 +- > Documentation/s390/monreader.txt | 2 +- > Documentation/security/Yama.txt | 2 +- > Documentation/sound/alsa/ALSA-Configuration.txt | 4 ++-- > Documentation/trace/events.txt | 2 +- > Documentation/usb/mass-storage.txt | 2 +- > Documentation/virtual/kvm/api.txt| 2 +- > Documentation/vm/transhuge.txt | 4 ++-- > Documentation/x86/earlyprintk.txt| 2 +- > Documentation/x86/i386/IO-APIC.txt | 2 +- > 41 files changed, 49 insertions(+), 49 deletions(-) > diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt > b/Documentation/devicetree/bindings/spi/spi-bus.txt > index e5a4d1b..0ff87d1 100644 > --- a/Documentation/devicetree/bindings/spi/spi-bus.txt > +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt > @@ -61,7 +61,7 @@ contain the following properties. >used for MISO. Defaults to 1 if not present. > > Some SPI controllers and devices support Dual and Quad SPI transfer mode. > -It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD). > +It allows data in SPI system transferred in 2 wires(DUAL) or 4 wires(QUAD). The spelling change is correct, but that sentence is still awkward. How about: It allows data in the SPI system to be transferred in 2 wires (DUAL) or 4 wires (QUAD). > Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is > only 1(SINGLE), 2(DUAL) and 4(QUAD). > Dual/Quad mode is not allowed when 3-wire mode is used. > diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt > index 4a63953..aeea1b14 100644 > --- a/Documentation/vm/transhuge.txt > +++ b/Documentation/vm/transhuge.txt > @@ -360,13 +360,13 @@ on any tail page, would mean having to split all > hugepages upfront in > get_user_pages which is unacceptable as too many gup users are > performance critical and they must work natively on hugepages like > they work natively on hugetlbfs already (hugetlbfs is simpler because > -hugetlbfs pages cannot be splitted so there wouldn't be requirement of > +hugetlbfs pages cannot be splitt so there wouldn't be requirement of split > accounting the pins on the tail pages for hugetlbfs). If we wouldn't > account the gup refcounts on the tail pages during gup, we won't know > anymore which tail page is pinned by gup
[PATCH] ASoC: dapm: Add support for multi register mux
1. Modify soc_enum struct to handle pointers for reg and mask
2. Add dapm get and put APIs for multi register one hot encoded mux
3. Update snd_soc_dapm_update struct to support multiple reg update
Signed-off-by: Arun S L
Signed-off-by: Songhee Baek
---
include/sound/soc-dapm.h | 20 -
include/sound/soc.h | 33 +++--
sound/soc/soc-core.c | 12 +--
sound/soc/soc-dapm.c | 181 +++---
4 files changed, 203 insertions(+), 43 deletions(-)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index ef78f56..c255349 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -305,6 +305,12 @@ struct device;
.get = snd_soc_dapm_get_enum_double, \
.put = snd_soc_dapm_put_enum_double, \
.private_value = (unsigned long) }
+#define SOC_DAPM_ENUM_ONEHOT(xname, xenum) \
+{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
+ .info = snd_soc_info_enum_double, \
+ .get = snd_soc_dapm_get_enum_onehot, \
+ .put = snd_soc_dapm_put_enum_onehot, \
+ .private_value = (unsigned long) }
#define SOC_DAPM_ENUM_VIRT(xname, xenum) \
SOC_DAPM_ENUM(xname, xenum)
#define SOC_DAPM_ENUM_EXT(xname, xenum, xget, xput) \
@@ -352,6 +358,9 @@ struct device;
/* regulator widget flags */
#define SND_SOC_DAPM_REGULATOR_BYPASS 0x1 /* bypass when disabled */
+/* maximum registers to update */
+#define SND_SOC_DAPM_UPDATE_MAX_REG3
+
struct snd_soc_dapm_widget;
enum snd_soc_dapm_type;
struct snd_soc_dapm_path;
@@ -378,6 +387,10 @@ int snd_soc_dapm_get_enum_double(struct snd_kcontrol
*kcontrol,
struct snd_ctl_elem_value *ucontrol);
int snd_soc_dapm_put_enum_double(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol);
+int snd_soc_dapm_get_enum_onehot(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol);
+int snd_soc_dapm_put_enum_onehot(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol);
int snd_soc_dapm_info_pin_switch(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo);
int snd_soc_dapm_get_pin_switch(struct snd_kcontrol *kcontrol,
@@ -590,9 +603,10 @@ struct snd_soc_dapm_widget {
struct snd_soc_dapm_update {
struct snd_kcontrol *kcontrol;
- int reg;
- int mask;
- int val;
+ int reg[SND_SOC_DAPM_UPDATE_MAX_REG];
+ int mask[SND_SOC_DAPM_UPDATE_MAX_REG];
+ int val[SND_SOC_DAPM_UPDATE_MAX_REG];
+ unsigned int num_regs;
};
/* DAPM context */
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 0b83168..dcdf1cb 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -177,18 +177,24 @@
{.reg = xreg, .min = xmin, .max = xmax, \
.platform_max = xmax} }
#define SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xitems, xtexts) \
-{ .reg = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
+{ .reg = &(int){(xreg)}, .shift_l = xshift_l, .shift_r = xshift_r, \
.items = xitems, .texts = xtexts, \
- .mask = xitems ? roundup_pow_of_two(xitems) - 1 : 0}
+ .mask = &(unsigned int){(xitems ? roundup_pow_of_two(xitems) - 1 : 0)},
\
+ .num_regs = 1, .type = SND_SOC_ENUM_BINARY }
#define SOC_ENUM_SINGLE(xreg, xshift, xitems, xtexts) \
SOC_ENUM_DOUBLE(xreg, xshift, xshift, xitems, xtexts)
#define SOC_ENUM_SINGLE_EXT(xitems, xtexts) \
{ .items = xitems, .texts = xtexts }
#define SOC_VALUE_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xmask, xitems, xtexts,
xvalues) \
-{ .reg = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
- .mask = xmask, .items = xitems, .texts = xtexts, .values = xvalues}
+{ .reg = &(int){(xreg)}, .shift_l = xshift_l, .shift_r = xshift_r, \
+ .mask = &(unsigned int){(xmask)}, .items = xitems, .texts = xtexts, \
+ .values = xvalues, .num_regs = 1, .type = SND_SOC_ENUM_BINARY }
#define SOC_VALUE_ENUM_SINGLE(xreg, xshift, xmask, xnitmes, xtexts, xvalues) \
SOC_VALUE_ENUM_DOUBLE(xreg, xshift, xshift, xmask, xnitmes, xtexts,
xvalues)
+#define SOC_VALUE_ENUM_ONEHOT(xregs, xmasks, xnum_regs, xitems, xtexts,
xvalues) \
+{ .reg = xregs, .mask = xmasks, .num_regs = xnum_regs, \
+ .items = xitems, .texts = xtexts, .values = xvalues, \
+ .type = SND_SOC_ENUM_ONEHOT }
#define SOC_ENUM_SINGLE_VIRT(xitems, xtexts) \
SOC_ENUM_SINGLE(SND_SOC_NOPM, 0, xitems, xtexts)
#define SOC_ENUM(xname, xenum) \
@@ -293,6 +299,9 @@
#define SOC_VALUE_ENUM_DOUBLE_DECL(name, xreg, xshift_l, xshift_r, xmask,
xtexts, xvalues) \
const struct soc_enum name = SOC_VALUE_ENUM_DOUBLE(xreg, xshift_l,
xshift_r, xmask, \
ARRAY_SIZE(xtexts),
xtexts, xvalues)
+#define SOC_VALUE_ENUM_ONEHOT_DECL(name, xregs, xmasks, xnum_regs, xtexts,
xvalues) \
+ const struct soc_enum name = SOC_VALUE_ENUM_ONEHOT(xregs, xmasks,
xnum_regs, \
+
Re: [PATCH 2/2] ARM: mm: make text and rodata read-only
On Fri, Apr 4, 2014 at 12:58 PM, Rabin Vincent wrote:
> On Thu, Apr 03, 2014 at 07:15:19PM -0700, Kees Cook wrote:
>> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
>> index 34e56647dcee..4ae343c1e2a3 100644
>> --- a/arch/arm/kernel/ftrace.c
>> +++ b/arch/arm/kernel/ftrace.c
>> @@ -14,6 +14,7 @@
>>
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -34,6 +35,22 @@
>>
>> #define OLD_NOP 0xe1a0 /* mov r0, r0 */
>>
>> +static int __ftrace_modify_code(void *data)
>
> This is in the CONFIG_OLD_MCOUNT ifdef, but should be in the outer ifdef
> (CONFIG_DYNAMIC_FTRACE) instead, otherwise it will not get enabled for
> for example Thumb-2 kernels. This was wrong in my example patch too.
Ah! Yes, good point. I've moved this now.
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index 8539eb2a01ad..3baac4ad165f 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -681,30 +716,52 @@ static inline bool arch_has_strict_perms(void)
>> return true;
>> }
>>
>> +#define set_section_perms(perms, field) {
>> \
>> + size_t i; \
>> + unsigned long addr; \
>> + \
>> + if (!arch_has_strict_perms()) \
>> + return; \
>> + \
>> + for (i = 0; i < ARRAY_SIZE(perms); i++) { \
>> + if (!IS_ALIGNED(perms[i].start, SECTION_SIZE) ||\
>> + !IS_ALIGNED(perms[i].end, SECTION_SIZE)) { \
>> + pr_err("BUG: section %lx-%lx not aligned to %lx\n", \
>> + perms[i].start, perms[i].end, \
>> + SECTION_SIZE); \
>> + continue; \
>> + } \
>> + \
>> + for (addr = perms[i].start; \
>> + addr < perms[i].end; \
>> + addr += SECTION_SIZE) \
>> + section_update(addr, perms[i].mask, \
>> +perms[i].field); \
>> + } \
>> +}
>> +
>> static inline void fix_kernmem_perms(void)
>> {
>> - unsigned long addr;
>> - unsigned int i;
>> + set_section_perms(nx_perms, prot);
>> +}
>>
>> - if (!arch_has_strict_perms())
>> - return;
>> +#ifdef CONFIG_DEBUG_RODATA
>> +void mark_rodata_ro(void)
>> +{
>> + set_section_perms(ro_perms, prot);
>> +}
>>
>> - for (i = 0; i < ARRAY_SIZE(section_perms); i++) {
>> - if (!IS_ALIGNED(section_perms[i].start, SECTION_SIZE) ||
>> - !IS_ALIGNED(section_perms[i].end, SECTION_SIZE)) {
>> - pr_err("BUG: section %lx-%lx not aligned to %lx\n",
>> - section_perms[i].start, section_perms[i].end,
>> - SECTION_SIZE);
>> - continue;
>> - }
>> +void set_kernel_text_rw(void)
>> +{
>> + set_section_perms(ro_perms, clear);
>> +}
>
> You need a TLB flush. I had a flush_tlb_all() in my example patch,
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244335.html,
> but the following is probably nicer (on top of this patch):
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 9bea524..a92c45a 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -741,6 +741,8 @@ static inline bool arch_has_strict_perms(void)
> addr += SECTION_SIZE) \
> section_update(addr, perms[i].mask, \
>perms[i].field); \
> + \
> + flush_tlb_kernel_range(perms[i].start, perms[i].end); \
> } \
> }
>
When I do this, I hang the system, and get a WARN due to the tlb call
attempting to flush on all CPUs, I think:
[ 34.246034] WARNING: at
/mnt/host/source/src/third_party/kernel-next/kernel/smp.c:466
smp_call_function_many+0xac/0x26c()
...
[ 34.246617] Backtrace:
[ 34.246697] [] (unwind_backtrace+0x0/0x118) from
[] (dump_stack+0x28/0x30)
[ 34.246765] [] (dump_stack+0x28/0x30) from []
(warn_slowpath_null+0x44/0x5c)
[ 34.246824] [] (warn_slowpath_null+0x44/0x5c)
Re: [PATCH v7 4/6] pci: Introduce a domain number for pci_host_bridge.
On Fri, Mar 14, 2014 at 03:34:30PM +, Liviu Dudau wrote:
> Make it easier to discover the domain number of a bus by storing
> the number in pci_host_bridge for the root bus. Several architectures
> have their own way of storing this information, so it makes sense
> to try to unify the code.
I like the idea of unifying the way we handle the domain number. But
I'd like to see more of the strategy before committing to this approach.
This patch adds struct pci_host_bridge.domain_nr, but of course
pci_domain_nr() doesn't use it. It can't today, because
pci_create_root_bus() relies on pci_domain_nr() to fill in
pci_host_bridge.domain_nr.
But I suppose the intent is that someday we can make pci_domain_nr()
arch-independent somehow. I'd just like to see more of the path to
that happening.
> While at this, add a new function that
> creates a root bus in a given domain and make pci_create_root_bus()
> a wrapper around this function.
I'm a little concerned about adding a new "create root bus" interface,
partly because we have quite a few already, and I'd like to reduce the
number of them instead of adding more. And I think there might be other
similar opportunities for unification, so I could easily see us adding new
functions in the future to unify NUMA node info, ECAM info, etc.
I wonder if we need some sort of descriptor structure that the arch could
fill in and pass to the PCI core. Then we could add new members without
having to create new interfaces each time.
> Signed-off-by: Liviu Dudau
> Tested-by: Tanmay Inamdar
> ---
> drivers/pci/probe.c | 41 +
> include/linux/pci.h | 4
> 2 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index fd11c12..172c615 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1714,8 +1714,9 @@ void __weak pcibios_remove_bus(struct pci_bus *bus)
> {
> }
>
> -struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> - struct pci_ops *ops, void *sysdata, struct list_head *resources)
> +struct pci_bus *pci_create_root_bus_in_domain(struct device *parent,
> + int domain, int bus, struct pci_ops *ops, void *sysdata,
> + struct list_head *resources)
> {
> int error;
> struct pci_host_bridge *bridge;
> @@ -1728,30 +1729,34 @@ struct pci_bus *pci_create_root_bus(struct device
> *parent, int bus,
>
> bridge = pci_alloc_host_bridge();
> if (!bridge)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> bridge->dev.parent = parent;
> bridge->dev.release = pci_release_host_bridge_dev;
> + bridge->domain_nr = domain;
> error = pcibios_root_bridge_prepare(bridge);
> if (error)
> goto err_out;
>
> b = pci_alloc_bus();
> - if (!b)
> + if (!b) {
> + error = -ENOMEM;
> goto err_out;
> + }
>
> b->sysdata = sysdata;
> b->ops = ops;
> b->number = b->busn_res.start = bus;
> - b2 = pci_find_bus(pci_domain_nr(b), bus);
> + b2 = pci_find_bus(bridge->domain_nr, bus);
> if (b2) {
> /* If we already got to this bus through a different bridge,
> ignore it */
> dev_dbg(>dev, "bus already known\n");
> + error = -EEXIST;
> goto err_bus_out;
> }
>
> bridge->bus = b;
> - dev_set_name(>dev, "pci%04x:%02x", pci_domain_nr(b), bus);
> + dev_set_name(>dev, "pci%04x:%02x", bridge->domain_nr, bus);
> error = device_register(>dev);
> if (error) {
> put_device(>dev);
> @@ -1766,7 +1771,7 @@ struct pci_bus *pci_create_root_bus(struct device
> *parent, int bus,
>
> b->dev.class = _class;
> b->dev.parent = b->bridge;
> - dev_set_name(>dev, "%04x:%02x", pci_domain_nr(b), bus);
> + dev_set_name(>dev, "%04x:%02x", bridge->domain_nr, bus);
> error = device_register(>dev);
> if (error)
> goto class_dev_reg_err;
> @@ -1816,7 +1821,27 @@ err_bus_out:
> kfree(b);
> err_out:
> kfree(bridge);
> - return NULL;
> + return ERR_PTR(error);
> +}
> +
> +struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> + struct pci_ops *ops, void *sysdata, struct list_head *resources)
> +{
> + int domain_nr;
> + struct pci_bus *b = pci_alloc_bus();
> + if (!b)
> + return NULL;
> +
> + b->sysdata = sysdata;
> + domain_nr = pci_domain_nr(b);
> + kfree(b);
> +
> + b = pci_create_root_bus_in_domain(parent, domain_nr, bus,
> + ops, sysdata, resources);
> + if (IS_ERR(b))
> + return NULL;
> +
> + return b;
> }
>
> int pci_bus_insert_busn_res(struct pci_bus *b, int bus, int bus_max)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 33aa2ca..1eed009 100644
> --- a/include/linux/pci.h
> +++
Re: [PATCH] arm: ftrace: work with CONFIG_DEBUG_SET_MODULE_RONX
On Wed, Apr 2, 2014 at 3:10 PM, Rabin Vincent wrote:
> Make ftrace work with CONFIG_DEBUG_SET_MODULE_RONX by making module text
> writable around the place where ftrace does its work, like it is done on
> x86 in the patch which introduced CONFIG_DEBUG_SET_MODULE_RONX,
> 84e1c6bb38eb ("x86: Add RO/NX protection for loadable kernel modules").
>
> Signed-off-by: Rabin Vincent
This works for me as well. Thanks!
Tested-by: Kees Cook
-Kees
> ---
> arch/arm/kernel/ftrace.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
> index 34e5664..70ce654 100644
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -14,6 +14,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -63,6 +64,18 @@ static unsigned long adjust_address(struct dyn_ftrace
> *rec, unsigned long addr)
> }
> #endif
>
> +int ftrace_arch_code_modify_prepare(void)
> +{
> + set_all_modules_text_rw();
> + return 0;
> +}
> +
> +int ftrace_arch_code_modify_post_process(void)
> +{
> + set_all_modules_text_ro();
> + return 0;
> +}
> +
> static unsigned long ftrace_call_replace(unsigned long pc, unsigned long
> addr)
> {
> return arm_gen_branch_link(pc, addr);
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Kees Cook
Chrome OS Security
--
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] topology: Fix compilation warning when not in SMP
On Fri, Apr 04, 2014 at 08:43:18AM +0200, Vincent Stehlé wrote: > The topology_##name() macro does not use its argument when CONFIG_SMP is not > set, as it ultimately calls the cpu_data() macro. > > So we avoid maintaining a possibly unused `cpu' variable, to avoid the > following compilation warning: > > drivers/base/topology.c: In function ‘show_physical_package_id’: > drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ > [-Wunused-variable] >define_id_show_func(physical_package_id); > > drivers/base/topology.c: In function ‘show_core_id’: > drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ > [-Wunused-variable] >define_id_show_func(core_id); > > This can be seen with e.g. x86 defconfig and CONFIG_SMP not set. > > Signed-off-by: Vincent Stehlé > Cc: Greg Kroah-Hartman > Cc: # 3.10.x > Cc: # 3.13.x > Cc: # 3.14.x Warnings aren't a stable kernel issue, so why would this be relevant there? thanks, greg k-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 v2 0/9] uprobes/x86: preparations to fix the reprel jmp/call handling.
On Fri, 2014-04-04 at 21:32 +0200, Oleg Nesterov wrote:
> On 04/04, Oleg Nesterov wrote:
> >
> > Now let me send the draft RFC patch which fixes the "call" handling...
>
> Damn. apparently I can't understand lib/insn.c...
>
> Please see the draft below. Lets ignore 32bit tasks, lets ignore jmp's,
> please ignore how the (pseudo) code written, I'll change it anyway.
>
> Questions:
So far, I have answers for just #1 and #2.
>
> 1. Why insn_get_displacement() doesn't work? See "HELP!!!"
> below.
insn->moffset1.value seems to be what you want.
>
> 2. Do I use lib/insn.c correctly (ignoring displacement) ?
insn_get_length() has the side-effect of processing the entire
instruction, so just calling that should be sufficient. Looks OK
otherwise -- but I checked very quickly.
More in a day or two.
Jim
>
>In particular, is 'turn this insn into "1: call 1b;"'
>below correct?
>
> 3. Jim, do you still think it would be better to rewrite the
> call insns using a scratch register ?
>
> 4. Is there other call insns with OPCODE1() != 0xe8 which
> should be fixed too?
>
> Thanks,
>
> Oleg.
>
>
> diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
> index 9f8210b..cca62c5 100644
> --- a/arch/x86/include/asm/uprobes.h
> +++ b/arch/x86/include/asm/uprobes.h
> @@ -44,9 +44,15 @@ struct arch_uprobe {
> u16 fixups;
> const struct uprobe_xol_ops *ops;
>
> + union {
> #ifdef CONFIG_X86_64
> - unsigned long rip_rela_target_address;
> + unsigned long rip_rela_target_address;
> #endif
> + struct {
> + s32 disp;
> + u8 ilen;
> + } ttt;
> + };
> };
>
> struct arch_uprobe_task {
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index b820668..423ae86 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -461,6 +461,52 @@ static struct uprobe_xol_ops default_xol_ops = {
> .post_xol = default_post_xol_op,
> };
>
> +static bool ttt_emulate_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
> +{
> +
> + if (put_user(regs->ip + auprobe->ttt.ilen, (long __user *)(regs->sp -
> 8)))
> + return false;
> +
> + regs->sp -= 8;
> + regs->ip += auprobe->ttt.ilen + auprobe->ttt.disp;
> +
> + return true;
> +}
> +
> +static int ttt_post_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
> +{
> + regs->sp += 8;
> + if (ttt_emulate_op(auprobe, regs))
> + return 0;
> + return -ERESTART;
> +}
> +
> +static struct uprobe_xol_ops ttt_xol_ops = {
> + .emulate = ttt_emulate_op,
> + .post_xol = ttt_post_xol_op,
> +};
> +
> +static int ttt_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
> +{
> + s32 *disp;
> +
> + insn_get_length(insn);
> + auprobe->ttt.ilen = insn->length;
> +
> + insn_get_displacement(insn);
> + auprobe->ttt.disp = insn->displacement.value;
> + // HELP!!! the above doesn't work, ->displacement.value == 0
> + auprobe->ttt.disp = *(s32 *)(auprobe->insn + 1);
> +
> + // turn this insn into "1: call 1b;", we only need to xol it
> + // to expand the stack if ->emulate() fails.
> + disp = (void *)auprobe->insn + insn_offset_displacement(insn);
> + *disp = -(s32)auprobe->ttt.ilen;
> +
> + auprobe->ops = _xol_ops;
> + return 0;
> +}
> +
> /**
> * arch_uprobe_analyze_insn - instruction analysis including validity and
> fixups.
> * @mm: the probed address space.
> @@ -484,6 +530,9 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
> struct mm_struct *mm,
>* is either zero or it reflects rip-related fixups.
>*/
> switch (OPCODE1()) {
> + case 0xe8: /* call relative - has its own xol_ops */
> + return ttt_setup_xol_ops(auprobe, );
> +
> case 0x9d: /* popf */
> auprobe->fixups |= UPROBE_FIX_SETF;
> break;
> @@ -493,9 +542,6 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
> struct mm_struct *mm,
> case 0xca:
> fix_ip = false;
> break;
> - case 0xe8: /* call relative - Fix return addr */
> - fix_call = true;
> - break;
> case 0x9a: /* call absolute - Fix return addr, not ip */
> fix_call = true;
> fix_ip = false;
>
--
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] ext4 changes for 3.15
On Fri, Apr 04, 2014 at 07:16:25PM +0200, Miklos Szeredi wrote: > > http://marc.info/?l=linux-kernel=139523745403081=2 I tried applying this patch on top of xfstests commit 3948694eb1, but running on ext4.git's test branch, which has the your cross-rename patches applied: http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/commit/?h=test=b7bcc46d4f80139930c2e6bd04ff8ebbff121bc9 I see the following: BEGIN TEST: Ext4 4k block Fri Apr 4 23:21:50 UTC 2014 Device: /dev/vdb mk2fs options: -q mount options: -o block_validity FSTYP -- ext4 PLATFORM -- Linux/i686 candygram 3.14.0-00061-gb7bcc46 MKFS_OPTIONS -- -q /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc generic/323 [23:22:03] [23:22:04] [not run] generic/323 -- kernel doesn't support renameat2 syscall generic/324 [23:22:04] [23:22:05] [not run] generic/324 -- kernel doesn't support renameat2 syscall generic/325 [23:22:05] [23:22:06] [not run] generic/325 -- kernel doesn't support renameat2 syscall Not run: generic/323 generic/324 generic/325 Is there anything obvious that I might be doing wrong? Thanks, - Ted -- 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 v7 5/6] pci: Export find_pci_host_bridge() function.
On Fri, Mar 14, 2014 at 03:34:31PM +, Liviu Dudau wrote:
> This is a useful function and we should make it visible outside the
> generic PCI code. Export it as a GPL symbol.
>
> Signed-off-by: Liviu Dudau
> Tested-by: Tanmay Inamdar
> ---
> drivers/pci/host-bridge.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
> index 06ace62..8708b652 100644
> --- a/drivers/pci/host-bridge.c
> +++ b/drivers/pci/host-bridge.c
> @@ -17,12 +17,13 @@ static struct pci_bus *find_pci_root_bus(struct pci_bus
> *bus)
> return bus;
> }
>
> -static struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus)
> +struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus)
> {
> struct pci_bus *root_bus = find_pci_root_bus(bus);
>
> return to_pci_host_bridge(root_bus->bridge);
> }
> +EXPORT_SYMBOL_GPL(find_pci_host_bridge);
Do you have a place where you actually need to use find_pci_host_bridge()?
I'd rather not export it, even as _GPL, unless we have a user.
If we *do* export it, I'd like it to have a more conventional name, e.g.,
something starting with "pci_".
>
> void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
>void (*release_fn)(struct pci_host_bridge *),
> --
> 1.9.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] ARM: zynq: dt: Convert to preprocessor includes
Convert all Zynq DT files to the dtc preprocessor include syntax.
This allows to include header files in the devicetrees like other
SoC-types already do.
Inspired-by: Steffen Trumtrar
(http://www.spinics.net/lists/arm-kernel/msg319832.html)
Signed-off-by: Soren Brinkmann
---
Changes in v2: None
arch/arm/boot/dts/zynq-7000.dtsi | 3 ++-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 20a13cba65a3..66613d04de5d 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -10,7 +10,8 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
-/include/ "skeleton.dtsi"
+
+#include "skeleton.dtsi"
/ {
compatible = "xlnx,zynq-7000";
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index c913f77a21eb..07713d3c716a 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -12,7 +12,7 @@
* GNU General Public License for more details.
*/
/dts-v1/;
-/include/ "zynq-7000.dtsi"
+#include "zynq-7000.dtsi"
/ {
model = "Zynq ZC702 Development Board";
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 88f62c50382e..cf6566cdb02a 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -13,7 +13,7 @@
* GNU General Public License for more details.
*/
/dts-v1/;
-/include/ "zynq-7000.dtsi"
+#include "zynq-7000.dtsi"
/ {
model = "Zynq ZC706 Development Board";
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 82d7ef1a9a9c..1541716e2cfb 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -13,7 +13,7 @@
* GNU General Public License for more details.
*/
/dts-v1/;
-/include/ "zynq-7000.dtsi"
+#include "zynq-7000.dtsi"
/ {
model = "Zynq Zed Development Board";
--
1.9.1.1.gbb9f595
--
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 0/5] ARM: zynq: DT update
Hi, here's the complete series now. One fix for cpufreq from our vendor tree and migration to pre-processor syntax. Thanks, Sören Changes in v2: - Send full series (added patches 1, 4, 5) Soren Brinkmann (5): ARM: zynq: DT: Add 'clock-latency' property ARM: zynq: dt: Convert to preprocessor includes ARM: zynq: dt: Use #defines for interrupt specifiers dt-bindings: clock: Add Zynq-7000 header ARM: zynq: dt: Use #defines for clock specifiers arch/arm/boot/dts/zynq-7000.dtsi | 64 ++- arch/arm/boot/dts/zynq-zc702.dts | 2 +- arch/arm/boot/dts/zynq-zc706.dts | 2 +- arch/arm/boot/dts/zynq-zed.dts| 2 +- include/dt-bindings/clock/zynq-7000.h | 64 +++ 5 files changed, 107 insertions(+), 27 deletions(-) create mode 100644 include/dt-bindings/clock/zynq-7000.h -- 1.9.1.1.gbb9f595 -- 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 3/5] ARM: zynq: dt: Use #defines for interrupt specifiers
Use #defines from the common include file to describe
interrupt specifiers.
Signed-off-by: Soren Brinkmann
---
Changes in v2: None
arch/arm/boot/dts/zynq-7000.dtsi | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 66613d04de5d..36a34ffa30af 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -12,6 +12,7 @@
*/
#include "skeleton.dtsi"
+#include
/ {
compatible = "xlnx,zynq-7000";
@@ -44,7 +45,7 @@
pmu {
compatible = "arm,cortex-a9-pmu";
- interrupts = <0 5 4>, <0 6 4>;
+ interrupts = , ;
interrupt-parent = <>;
reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
};
@@ -80,7 +81,7 @@
clocks = < 23>, < 40>;
clock-names = "ref_clk", "aper_clk";
reg = <0xE000 0x1000>;
- interrupts = <0 27 4>;
+ interrupts = ;
};
uart1: uart@e0001000 {
@@ -89,14 +90,14 @@
clocks = < 24>, < 41>;
clock-names = "ref_clk", "aper_clk";
reg = <0xE0001000 0x1000>;
- interrupts = <0 50 4>;
+ interrupts = ;
};
gem0: ethernet@e000b000 {
compatible = "cdns,gem";
reg = <0xe000b000 0x4000>;
status = "disabled";
- interrupts = <0 22 4>;
+ interrupts = ;
clocks = < 30>, < 30>, < 13>;
clock-names = "pclk", "hclk", "tx_clk";
};
@@ -105,7 +106,7 @@
compatible = "cdns,gem";
reg = <0xe000c000 0x4000>;
status = "disabled";
- interrupts = <0 45 4>;
+ interrupts = ;
clocks = < 31>, < 31>, < 14>;
clock-names = "pclk", "hclk", "tx_clk";
};
@@ -116,7 +117,7 @@
clock-names = "clk_xin", "clk_ahb";
clocks = < 21>, < 32>;
interrupt-parent = <>;
- interrupts = <0 24 4>;
+ interrupts = ;
reg = <0xe010 0x1000>;
} ;
@@ -126,7 +127,7 @@
clock-names = "clk_xin", "clk_ahb";
clocks = < 22>, < 33>;
interrupt-parent = <>;
- interrupts = <0 47 4>;
+ interrupts = ;
reg = <0xe0101000 0x1000>;
} ;
@@ -160,14 +161,16 @@
global_timer: timer@f8f00200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0xf8f00200 0x20>;
- interrupts = <1 11 0x301>;
+ interrupts = ;
interrupt-parent = <>;
clocks = < 4>;
};
ttc0: ttc0@f8001000 {
interrupt-parent = <>;
- interrupts = < 0 10 4 0 11 4 0 12 4 >;
+ interrupts = ,
+,
+;
compatible = "cdns,ttc";
clocks = < 6>;
reg = <0xF8001000 0x1000>;
@@ -175,14 +178,16 @@
ttc1: ttc1@f8002000 {
interrupt-parent = <>;
- interrupts = < 0 37 4 0 38 4 0 39 4 >;
+ interrupts = ,
+,
+;
compatible = "cdns,ttc";
clocks = < 6>;
reg = <0xF8002000 0x1000>;
};
scutimer: scutimer@f8f00600 {
interrupt-parent = <>;
- interrupts = < 1 13 0x301 >;
+ interrupts = ;
compatible = "arm,cortex-a9-twd-timer";
reg = < 0xf8f00600 0x20 >;
clocks = < 4>;
--
1.9.1.1.gbb9f595
--
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 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
On Sat, Apr 5, 2014 at 12:30 AM, Harini Katakam wrote: > Hi, > > On Fri, Apr 4, 2014 at 7:38 PM, Harini Katakam > wrote: >> Hi Mark, >> >> On Fri, Apr 4, 2014 at 6:16 PM, Mark Brown wrote: >>> On Fri, Apr 04, 2014 at 05:44:23PM +0530, Harini Katakam wrote: On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown wrote: > On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote: >>> >> This IP can drive 4 slaves. >> The CS line to be driven is selected in spi device structure and >> that is driven by the software. >>> > So why specify this in the binding at all? If the device always has the > same number of chip selects it's redundant. >>> I'm sorry, I should have explained that better. The IP can support upto 4 chip selects. The num-cs value here is the number of chip selects actually used on the board. Shouldnt it be a property of the controller not the board? How for example do we differentiate between different implementations of cadence SPI controller that only supports up to two CS lines? My thinking is that this property should always be present and = 4 in the Zynq case as the controller always has 4 physical CS lines coming out (before any decoders, pin muxes or slaves etc.). >>> >>> Why does that need to be configured? Surely the presence of slaves is >>> enough information. And presence of slaves / board info is inferable from subnodes. >> >> OK. I understand. >> Can you comment on the case where a decoder is used? >> >> There is support for adding a decoder where extended slaves can be selected >> through the IP's control register. >> (This is not currently implemented in the driver but will be in the future.) >> I think thats seperate information. is-decoded-cs property of something. >> How should the driver know whether it is 4 or 16 select lines for example? >> This has to be written to master->num_chipselect. >> If you only have one property (== 4) how do you tell the difference between 4 un-decoded CS lines vs 2 decoded CS lines? >> Regards, >> Harini > > Just adding to my above comment. > Alternately, I could not use the "num-cs" property and add another > optional property to be used only when required. I think num-cs has validity as the number of CS lines implemented in the controller. For any given SoC, it's constant but could differ between SoCs. Regards, Peter > The driver sets a default value already. > > Regards, > Harini > -- > 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/
[PATCH v2 4/5] dt-bindings: clock: Add Zynq-7000 header
Add header file with symbolic names for Zynq's clocks. Signed-off-by: Soren Brinkmann --- Changes in v2: - this patch has been added --- include/dt-bindings/clock/zynq-7000.h | 64 +++ 1 file changed, 64 insertions(+) create mode 100644 include/dt-bindings/clock/zynq-7000.h diff --git a/include/dt-bindings/clock/zynq-7000.h b/include/dt-bindings/clock/zynq-7000.h new file mode 100644 index ..851f5cffe481 --- /dev/null +++ b/include/dt-bindings/clock/zynq-7000.h @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2014 Xilinx Inc. + * Author: Sören Brinkmann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Device Tree binding constants for Zynq 7000 clock controller. +*/ + +#ifndef _DT_BINDINGS_CLOCK_ZYNQ_7000_H +#define _DT_BINDINGS_CLOCK_ZYNQ_7000_H + +#define ZYNQ_CLK_ARMPLL0 +#define ZYNQ_CLK_DDRPLL1 +#define ZYNQ_CLK_IOPLL 2 +#define ZYNQ_CLK_CPU_6OR4X 3 +#define ZYNQ_CLK_CPU_3OR2X 4 +#define ZYNQ_CLK_CPU_2X5 +#define ZYNQ_CLK_CPU_1X6 +#define ZYNQ_CLK_DDR2X 7 +#define ZYNQ_CLK_DDR3X 8 +#define ZYNQ_CLK_DCI 9 +#define ZYNQ_CLK_LQSPI 10 +#define ZYNQ_CLK_SMC 11 +#define ZYNQ_CLK_PCAP 12 +#define ZYNQ_CLK_GEM0 13 +#define ZYNQ_CLK_GEM1 14 +#define ZYNQ_CLK_FCLK0 15 +#define ZYNQ_CLK_FCLK1 16 +#define ZYNQ_CLK_FCLK2 17 +#define ZYNQ_CLK_FCLK3 18 +#define ZYNQ_CLK_CAN0 19 +#define ZYNQ_CLK_CAN1 20 +#define ZYNQ_CLK_SDIO0 21 +#define ZYNQ_CLK_SDIO1 22 +#define ZYNQ_CLK_UART0 23 +#define ZYNQ_CLK_UART1 24 +#define ZYNQ_CLK_SPI0 25 +#define ZYNQ_CLK_SPI1 26 +#define ZYNQ_CLK_DMA 27 +#define ZYNQ_CLK_USB0_APER 28 +#define ZYNQ_CLK_USB1_APER 29 +#define ZYNQ_CLK_GEM0_APER 30 +#define ZYNQ_CLK_GEM1_APER 31 +#define ZYNQ_CLK_SDIO0_APER32 +#define ZYNQ_CLK_SDIO1_APER33 +#define ZYNQ_CLK_SPI0_APER 34 +#define ZYNQ_CLK_SPI1_APER 35 +#define ZYNQ_CLK_CAN0_APER 36 +#define ZYNQ_CLK_CAN1_APER 37 +#define ZYNQ_CLK_I2C0_APER 38 +#define ZYNQ_CLK_I2C1_APER 39 +#define ZYNQ_CLK_UART0_APER40 +#define ZYNQ_CLK_UART1_APER41 +#define ZYNQ_CLK_GPIO_APER 42 +#define ZYNQ_CLK_LQSPI_APER43 +#define ZYNQ_CLK_SMC_APER 44 +#define ZYNQ_CLK_SWDT 45 +#define ZYNQ_CLK_DBG_TRC 46 +#define ZYNQ_CLK_DBG_APB 47 + +#endif /* _DT_BINDINGS_CLOCK_ZYNQ_7000_H */ -- 1.9.1.1.gbb9f595 -- 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] cmdline: Hide "debug" from /proc/cmdline
On Fri, Apr 04, 2014 at 05:17:09PM -0400, John Stoffel wrote: > > "Linus" == Linus Torvalds writes: > > Linus> On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski > wrote: > >> > >> The other thing I've used /dev/kmsg for is to shove a "I'm starting > >> something now" message in. This is only really necessary because the > >> current kernel log timestamps are unusable crap. (We could fix that, > >> hint hint.) > > Linus> I'd actually love to fix that, but I disagree with the "we could fix > Linus> it". There are tons of people who know how to parse them (admittedly > Linus> often only to ignore them), so changing the format is not likely to > Linus> work. > > Linus> The good news is that "dmesg -H" does help if you're > Linus> human. While at the same time being an example of that very > Linus> "there are tools that know about the current horrid format" > Linus> issue.. D'oh. > > I think you mean "dmesg -T", and unfortunately it seems Debian 6.0.9 > (or older) doesn ship a new enough linux-util since I've only got > 2.17.2-9 install. No, 'dmesg -H' is the right thing, you just need a modern version of util-linux :) > And RHEL/Centos 5.6 and 6.5 don't seem to ship that by default either, > they have got util-linux-2.13-0.56.el5 and > util-linux-ng-2.17.2-12.14.el6.x86_64 respectively. Blech! It's in > Linux Mint 16 at least, haven't checked older versions. util-linux is on version 2.24.1 at the moment: https://www.kernel.org/pub/linux/utils/util-linux/v2.24/ 2.17.2 was from back in 2012, I think it's time to switch to a modern distro... thanks, greg k-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/
[PATCH v2 1/5] ARM: zynq: DT: Add 'clock-latency' property
Specify the 'clock-latency' property to avoid certain cpufreq governors from refusing to work with the following error: ondemand governor failed, too long transition latency of HW, fallback to performance governor Reported-by: Mike Looijmans Signed-off-by: Soren Brinkmann Tested-by: Mike Looijmans Signed-off-by: Michal Simek --- This is a fix from our vendor tree Changes in v2: - This patch has been added --- arch/arm/boot/dts/zynq-7000.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi index 789d0bacc110..20a13cba65a3 100644 --- a/arch/arm/boot/dts/zynq-7000.dtsi +++ b/arch/arm/boot/dts/zynq-7000.dtsi @@ -24,6 +24,7 @@ device_type = "cpu"; reg = <0>; clocks = < 3>; + clock-latency = <1000>; operating-points = < /* kHzuV */ 67 100 -- 1.9.1.1.gbb9f595 -- 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 5/5] ARM: zynq: dt: Use #defines for clock specifiers
Use symbolic names instead of bare numbers to specify clocks.
Signed-off-by: Soren Brinkmann
---
Changes in v2:
- this patch has been added
---
arch/arm/boot/dts/zynq-7000.dtsi | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 36a34ffa30af..9a54b49d0fd2 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -13,6 +13,7 @@
#include "skeleton.dtsi"
#include
+#include
/ {
compatible = "xlnx,zynq-7000";
@@ -25,8 +26,8 @@
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
- clocks = < 3>;
clock-latency = <1000>;
+ clocks = < ZYNQ_CLK_CPU_6OR4X>;
operating-points = <
/* kHzuV */
67 100
@@ -39,7 +40,7 @@
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <1>;
- clocks = < 3>;
+ clocks = < ZYNQ_CLK_CPU_6OR4X>;
};
};
@@ -78,7 +79,8 @@
uart0: uart@e000 {
compatible = "xlnx,xuartps";
status = "disabled";
- clocks = < 23>, < 40>;
+ clocks = < ZYNQ_CLK_UART0>,
+< ZYNQ_CLK_UART0_APER>;
clock-names = "ref_clk", "aper_clk";
reg = <0xE000 0x1000>;
interrupts = ;
@@ -87,7 +89,8 @@
uart1: uart@e0001000 {
compatible = "xlnx,xuartps";
status = "disabled";
- clocks = < 24>, < 41>;
+ clocks = < ZYNQ_CLK_UART1>,
+< ZYNQ_CLK_UART1_APER>;
clock-names = "ref_clk", "aper_clk";
reg = <0xE0001000 0x1000>;
interrupts = ;
@@ -98,7 +101,9 @@
reg = <0xe000b000 0x4000>;
status = "disabled";
interrupts = ;
- clocks = < 30>, < 30>, < 13>;
+ clocks = < ZYNQ_CLK_GEM0_APER>,
+< ZYNQ_CLK_GEM0_APER>,
+< ZYNQ_CLK_GEM0>;
clock-names = "pclk", "hclk", "tx_clk";
};
@@ -107,7 +112,9 @@
reg = <0xe000c000 0x4000>;
status = "disabled";
interrupts = ;
- clocks = < 31>, < 31>, < 14>;
+ clocks = < ZYNQ_CLK_GEM1_APER>,
+< ZYNQ_CLK_GEM1_APER>,
+< ZYNQ_CLK_GEM1>;
clock-names = "pclk", "hclk", "tx_clk";
};
@@ -115,7 +122,8 @@
compatible = "arasan,sdhci-8.9a";
status = "disabled";
clock-names = "clk_xin", "clk_ahb";
- clocks = < 21>, < 32>;
+ clocks = < ZYNQ_CLK_SDIO0>,
+< ZYNQ_CLK_SDIO0_APER>;
interrupt-parent = <>;
interrupts = ;
reg = <0xe010 0x1000>;
@@ -125,7 +133,8 @@
compatible = "arasan,sdhci-8.9a";
status = "disabled";
clock-names = "clk_xin", "clk_ahb";
- clocks = < 22>, < 33>;
+ clocks = < ZYNQ_CLK_SDIO1>,
+< ZYNQ_CLK_SDIO1_APER>;
interrupt-parent = <>;
interrupts = ;
reg = <0xe0101000 0x1000>;
@@ -163,7 +172,7 @@
reg = <0xf8f00200 0x20>;
interrupts = ;
interrupt-parent = <>;
- clocks = < 4>;
+ clocks = < ZYNQ_CLK_CPU_3OR2X>;
};
ttc0: ttc0@f8001000 {
@@ -172,7 +181,7 @@
,
;
compatible = "cdns,ttc";
- clocks = < 6>;
+ clocks = < ZYNQ_CLK_CPU_1X>;
reg = <0xF8001000 0x1000>;
};
@@ -182,7 +191,7 @@
,
;
compatible = "cdns,ttc";
- clocks = < 6>;
+ clocks = < ZYNQ_CLK_CPU_1X>;
reg = <0xF8002000
Re: [PATCH v2] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash
On Tue, Apr 1, 2014 at 5:23 PM, Wei Zhang wrote:
> When use gre vport, openvswitch register a gre_cisco_protocol but does not
> supply a err_handler with it. The gre_cisco_err() in net/ipv4/gre_demux.c
> expect
> err_handler be provided with the gre_cisco_protocol implementation, and call
> ->err_handler() without existence check, cause the kernel crash.
>
> This patch provide a err_handler to fix this bug.
>
> v2 -> v1: use the same logic of the gre_rcv() to distinguish which packet is
> intended to us!
As a tip on kernel process: if you put the version information after
three dashes below the signed-off-by line then git will automatically
remove it when the final patch is applied.
> diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
> index a3d6951..f391df1 100644
> --- a/net/openvswitch/vport-gre.c
> +++ b/net/openvswitch/vport-gre.c
> @@ -110,6 +110,21 @@ static int gre_rcv(struct sk_buff *skb,
> return PACKET_RCVD;
> }
>
> +/* Called with rcu_read_lock and BH disabled. */
> +static int gre_err(struct sk_buff *skb, u32 info,
> + const struct tnl_ptk_info *tpi)
> +{
> + struct ovs_net *ovs_net;
> + struct vport *vport;
> +
> + ovs_net = net_generic(dev_net(skb->dev), ovs_net_id);
> + vport = rcu_dereference(ovs_net->vport_net.gre_vport);
> + if (unlikely(!vport))
> + return PACKET_REJECT;
> + else
> + return PACKET_RCVD;
Sorry, I forgot to say this before - if we receive the packet then we
should also call consume_skb() on it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tools/perf: instead of redirecting flex output, use -o
This gives us a real filename instead of having '' show up all over the place when debugging. Signed-off-by: Cody P Schafer --- tools/perf/Makefile.perf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 7257e7e..d07c7a2 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -187,13 +187,13 @@ endif export PERL_PATH $(OUTPUT)util/parse-events-flex.c: util/parse-events.l $(OUTPUT)util/parse-events-bison.c - $(QUIET_FLEX)$(FLEX) --header-file=$(OUTPUT)util/parse-events-flex.h $(PARSER_DEBUG_FLEX) -t util/parse-events.l > $(OUTPUT)util/parse-events-flex.c + $(QUIET_FLEX)$(FLEX) -o $@ --header-file=$(OUTPUT)util/parse-events-flex.h $(PARSER_DEBUG_FLEX) util/parse-events.l $(OUTPUT)util/parse-events-bison.c: util/parse-events.y $(QUIET_BISON)$(BISON) -v util/parse-events.y -d $(PARSER_DEBUG_BISON) -o $(OUTPUT)util/parse-events-bison.c -p parse_events_ $(OUTPUT)util/pmu-flex.c: util/pmu.l $(OUTPUT)util/pmu-bison.c - $(QUIET_FLEX)$(FLEX) --header-file=$(OUTPUT)util/pmu-flex.h -t util/pmu.l > $(OUTPUT)util/pmu-flex.c + $(QUIET_FLEX)$(FLEX) -o $@ --header-file=$(OUTPUT)util/pmu-flex.h util/pmu.l $(OUTPUT)util/pmu-bison.c: util/pmu.y $(QUIET_BISON)$(BISON) -v util/pmu.y -d -o $(OUTPUT)util/pmu-bison.c -p perf_pmu_ -- 1.9.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/
Re: [PATCH v2 1/2] SPI: Add driver for Cadence SPI controller
On Thu, Apr 3, 2014 at 9:10 PM, Harini Katakam wrote: > Add driver for Cadence SPI controller. This is used in Xilinx Zynq. > > Signed-off-by: Harini Katakam > --- > > v2 changes: > - Use xilinx compatible string too. > - Changes read register and write register functions to static inline. > - Removed unecessary dev_info and dev_dbg prints. > - Return IRQ_HANDLED only when interrupt is handled. > - Use a default num-cs value. > - Do init_hardware before requesting irq. > - Remove unecessary master_put() > - Set master->max_speed_hz > - Check for busy in cdns_setup(). > Retained this function with this check as opposed to removing. > The reason for this is clock configuration needs to be done for > the first time before enable is done in prepare_hardware; > prepare_hardware however, doesn't receive spi_device structure. > - Implememnt transfer_one instead of transfer_one_message. > Remove wait_for_completion as this is done by core. > - Implement set_cs. > - Clock enable/disable in prepare/unprepare respectively. > - In suspend, remove reset of hardware; simply call unprepare_hardware. > - In suspend/resume call master_suspend/resume respectively. > - Check for irq<=0 in probe. > - Remove MODULE_ALIAS. > > --- > drivers/spi/Kconfig |7 + > drivers/spi/Makefile |1 + > drivers/spi/spi-cadence.c | 677 > + > 3 files changed, 685 insertions(+) > create mode 100644 drivers/spi/spi-cadence.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 581ee2a..aeae44a 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -148,6 +148,13 @@ config SPI_BUTTERFLY > inexpensive battery powered microcontroller evaluation board. > This same cable can be used to flash new firmware. > > +config SPI_CADENCE > + tristate "Cadence SPI controller" > + depends on SPI_MASTER > + help > + This selects the Cadence SPI controller master driver > + used by Xilinx Zynq. > + > config SPI_CLPS711X > tristate "CLPS711X host SPI controller" > depends on ARCH_CLPS711X > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 95af48d..1be2ed7 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -22,6 +22,7 @@ obj-$(CONFIG_SPI_BFIN_V3) += spi-bfin-v3.o > obj-$(CONFIG_SPI_BFIN_SPORT) += spi-bfin-sport.o > obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o > obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o > +obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o > obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o > obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o > obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o > diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c > new file mode 100644 > index 000..071642d > --- /dev/null > +++ b/drivers/spi/spi-cadence.c > @@ -0,0 +1,677 @@ > +/* > + * Cadence SPI controller driver (master mode only) > + * > + * Copyright (C) 2008 - 2014 Xilinx, Inc. > + * > + * based on Blackfin On-Chip SPI Driver (spi_bfin5xx.c) > + * > + * This program is free software; you can redistribute it and/or modify it > under > + * the terms of the GNU General Public License version 2 as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Name of this driver */ > +#define CDNS_SPI_NAME "cdns-spi" > + > +/* Register offset definitions */ > +#define CDNS_SPI_CR_OFFSET 0x00 /* Configuration Register, RW */ > +#define CDNS_SPI_ISR_OFFSET0x04 /* Interrupt Status Register, RO */ > +#define CDNS_SPI_IER_OFFSET0x08 /* Interrupt Enable Register, WO */ > +#define CDNS_SPI_IDR_OFFSET0x0c /* Interrupt Disable Register, WO */ > +#define CDNS_SPI_IMR_OFFSET0x10 /* Interrupt Enabled Mask Register, RO */ > +#define CDNS_SPI_ER_OFFSET 0x14 /* Enable/Disable Register, RW */ > +#define CDNS_SPI_DR_OFFSET 0x18 /* Delay Register, RW */ > +#define CDNS_SPI_TXD_OFFSET0x1C /* Data Transmit Register, WO */ > +#define CDNS_SPI_RXD_OFFSET0x20 /* Data Receive Register, RO */ > +#define CDNS_SPI_SICR_OFFSET 0x24 /* Slave Idle Count Register, RW */ > +#define CDNS_SPI_THLD_OFFSET 0x28 /* Transmit FIFO Watermark Register,RW */ > + > +/* > + * SPI Configuration Register bit Masks > + * > + * This register contains various control bits that affect the operation > + * of the SPI controller > + */ > +#define CDNS_SPI_CR_MANSTRT_MASK 0x0001 /* Manual TX Start */ > +#define CDNS_SPI_CR_CPHA_MASK 0x0004 /* Clock Phase Control */ > +#define CDNS_SPI_CR_CPOL_MASK 0x0002 /* Clock Polarity Control > */ > +#define CDNS_SPI_CR_SSCTRL_MASK0x3C00 /* Slave Select
RE: [PATCH 1/1] x86/platform/hyperv: When on Hyper-v use NULL legacy PIC
> -Original Message-
> From: Vivek Goyal [mailto:vgo...@redhat.com]
> Sent: Friday, April 4, 2014 1:32 PM
> To: KY Srinivasan
> Cc: x...@kernel.org; linux-kernel@vger.kernel.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; h...@zytor.com;
> sta...@vger.kernel.org; Dave Young
> Subject: Re: [PATCH 1/1] x86/platform/hyperv: When on Hyper-v use NULL
> legacy PIC
>
> On Fri, Apr 04, 2014 at 08:09:47PM +, KY Srinivasan wrote:
> >
> >
> > > -Original Message-
> > > From: Vivek Goyal [mailto:vgo...@redhat.com]
> > > Sent: Friday, April 4, 2014 8:16 AM
> > > To: KY Srinivasan
> > > Cc: x...@kernel.org; linux-kernel@vger.kernel.org; o...@aepfle.de;
> > > a...@canonical.com; jasow...@redhat.com; h...@zytor.com;
> > > sta...@vger.kernel.org; Dave Young
> > > Subject: Re: [PATCH 1/1] x86/platform/hyperv: When on Hyper-v use
> > > NULL legacy PIC
> > >
> > > On Fri, Apr 04, 2014 at 03:01:51PM +, KY Srinivasan wrote:
> > >
> > > [..]
> > > > The problem we were having is that the initial boot on the EFI
> > > > firmware would succeed as the legacy PIC would be NULL legacy PIC,
> > > > however in the kexeced kernel, the initial boot information is not
> > > > available and so we would not set the legacy PIC to NULL legacy PIC.
> > >
> > > I am curious to know what "initial boot information" is not
> > > available in kexeced kernel and who is supposed to provide that.
> > >
> > > Is it a bug or that's how it is supposed to work.
> >
> > As the name indicates, the dump kernel is not "booted" but it is kexeced.
> > In the address space of this second kernel, the initial boot state is not
> visible.
>
> What do you mean by "initial boot state"? Most of the state we pass to
> second kernel in bootparams and on command line and rest second kernel
> can query from firmware as needed.
Specifically, this check I had:
if (efi_enabled(EFI_BOOT)) {
}
Fails in the kexeced kernel even when running on EFI firmware.
K. Y
--
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] cmdline: Hide "debug" from /proc/cmdline
On Fri, Apr 4, 2014 at 1:17 PM, Theodore Ts'o wrote: > On Fri, Apr 04, 2014 at 03:44:26PM -0400, Steven Rostedt wrote: >> I saw one commenter say that this was a kernel bug because writing to >> kmsg shouldn't cause the system to hang. >> >> The rate-limit patch would go along with that idea, and I honestly >> think it would be good to rate-limit it in case something else breaks >> and starts spamming kmsg. > > I agree; the only question is what is the appropriate rate limits, > which is the question Linus was asking. > > Personally, I like keeping the current limits (no more than ten > messages every 5 seconds) because I don't think dmesg, which is a > circular buffer and deliberately kept simple so that printk is > guaranteed to work even when things go really bad (and if things do go > really bad, there are ways of reading dmesg out from a crash dump, for > example, so we want to keep things simple). > > Peter has argued that it might be cool if the Kernel had a > purpose-built in-kernel syslogd sort of interface, that could accept > arbitrarily large amounts of data, and presumably it would allocate > memory as needed, and since the kernel knows this is log data, if we > are under memory pressure, it could release some of the log data, even > if the userspace hasn't picked it up yet, under extreme memory > pressure. > > I don't know that it makes sense to do this, since IMHO we can just as > easily do this in a user-space process. > > But I *do* think we should keep the facility used by printk to be as > simple and as bulletproof as possible, which means we should really > try to keep users of /dev/kmesg to the simple "I'm starting test > ", or similar messages. And that argues for using things like > the current ratelimit defaults. can there be two bulletproof buffers: one for in kernel printk and another ratelimited one for writes into /dev/kmsg. On the read from /dev/kmsg they're combined by time. -- 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] cmdline: Hide "debug" from /proc/cmdline
On Fri, Apr 4, 2014 at 3:45 PM, Alexei Starovoitov wrote: > > can there be two bulletproof buffers: one for in kernel printk > and another ratelimited one for writes into /dev/kmsg. > On the read from /dev/kmsg they're combined by time. Or, you know, people could just stop spamming /dev/kmsg. Let's not overdesign this. No sane use will be impacted by rate limiting, and insane uses aren't something we should design for. Even the systemd spam was a *bug*, for chrissake. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: zynq: dt: Convert to preprocessor includes
Sorry this accidentally went out too early. I meant to include patches to convert the clocks as well. I'll send a v2 to include those patches. Sören -- 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/
[WIP] [PATCH v2 0/3] remove wrong cast of gfp_t flags
Hi Dan, thanks for your review. Attached second version of this series. Cheers, Silvio Silvio Fricke (3): staging: vt6655: removed incorrect casting in wpactl.c staging: vt6655: removed incorrect casting in ioctl.c staging: vt6655: removed incorrect casting in iwctl.c drivers/staging/vt6655/ioctl.c | 6 -- drivers/staging/vt6655/iwctl.c | 2 +- drivers/staging/vt6655/wpactl.c | 6 +++--- 3 files changed, 8 insertions(+), 6 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 3/3] staging: vt6655: removed incorrect casting in iwctl.c
This patch fixes the following type of sparse warning:
drivers/staging/vt6655/iwctl.c:1846:35: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/iwctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c
index ac3fc16..5e25535 100644
--- a/drivers/staging/vt6655/iwctl.c
+++ b/drivers/staging/vt6655/iwctl.c
@@ -1843,7 +1843,7 @@ int iwctl_siwencodeext(struct net_device *dev,
PRINT_K("SIOCSIWENCODEEXT.. \n");
blen = sizeof(*param);
- buf = kmalloc((int)blen, (int)GFP_KERNEL);
+ buf = kmalloc((int)blen, GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;
memset(buf, 0, blen);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 1/3] staging: vt6655: removed incorrect casting in wpactl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/wpactl.c:596:47: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:638:68: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:860:42: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/wpactl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index d17224f..4745429 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -593,7 +593,7 @@ static int wpa_get_scan(PSDevice pDevice,
unsigned char *ptempBSS;
- ptempBSS = kmalloc(sizeof(KnownBSS), (int)GFP_ATOMIC);
+ ptempBSS = kmalloc(sizeof(KnownBSS), GFP_ATOMIC);
if (ptempBSS == NULL) {
printk(KERN_ERR "bubble sort kmalloc memory fail@@@\n");
@@ -635,7 +635,7 @@ static int wpa_get_scan(PSDevice pDevice,
count++;
}
- pBuf = kcalloc(count, sizeof(struct viawget_scan_result),
(int)GFP_ATOMIC);
+ pBuf = kcalloc(count, sizeof(struct viawget_scan_result), GFP_ATOMIC);
if (pBuf == NULL) {
ret = -ENOMEM;
@@ -857,7 +857,7 @@ int wpa_ioctl(PSDevice pDevice, struct iw_point *p)
p->length > VIAWGET_WPA_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
- param = kmalloc((int)p->length, (int)GFP_KERNEL);
+ param = kmalloc((int)p->length, GFP_KERNEL);
if (param == NULL)
return -ENOMEM;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WIP] [PATCH v2 2/3] staging: vt6655: removed incorrect casting in ioctl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/ioctl.c:308:104: warning: cast from restricted gfp_t
drivers/staging/vt6655/ioctl.c:579:109: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/ioctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/ioctl.c b/drivers/staging/vt6655/ioctl.c
index b5cd2e4..1de5d2c9 100644
--- a/drivers/staging/vt6655/ioctl.c
+++ b/drivers/staging/vt6655/ioctl.c
@@ -305,7 +305,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)), (int)GFP_ATOMIC);
+ pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)),
+GFP_ATOMIC);
if (pList == NULL) {
result = -ENOMEM;
break;
@@ -576,7 +577,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)), (int)GFP_ATOMIC);
+ pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)),
+ GFP_ATOMIC);
if (pNodeList == NULL) {
result = -ENOMEM;
break;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: phy: msm: Select secondary PHY via TCSR
Select the secondary PHY using the TCSR register, if phy-num=1
in the DTS (or phy_number is set in the platform data). The
SOC has 2 PHYs which can be used with the OTG port, and this
code allows configuring the correct one.
Note: This resolves the problem I was seeing where I couldn't
get the USB driver working at all on a dragonboard, from cold
boot. This patch depends on patch 5/14 from Ivan's msm USB
patch set. It does not use DT for the register address, as
there's no evidence that this address changes between SoC
versions.
Signed-off-by: Tim Bird
---
drivers/usb/phy/phy-msm-usb.c| 14 ++
include/linux/usb/msm_hsusb_hw.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index c4820e6..0272489 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1518,6 +1518,7 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
struct resource *res;
struct msm_otg *motg;
struct usb_phy *phy;
+ void __iomem *phy_select;
motg = devm_kzalloc(>dev, sizeof(struct msm_otg), GFP_KERNEL);
if (!motg) {
@@ -1580,6 +1581,19 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
if (IS_ERR(motg->regs))
return PTR_ERR(motg->regs);
+ /*
+* NOTE: The PHYs can be multiplexed between the chipidea controller
+* and the dwc3 controller, using a single bit. It is important that
+* the dwc3 driver does not set this bit in an incompatible way.
+*/
+ if (motg->phy_number) {
+ phy_select = devm_ioremap_nocache(>dev, USB2_PHY_SEL, 4);
+ if (IS_ERR(phy_select))
+ return PTR_ERR(phy_select);
+ /* Enable second PHY with the OTG port */
+ writel_relaxed(0x1, phy_select);
+ }
+
dev_info(>dev, "OTG regs = %p\n", motg->regs);
motg->irq = platform_get_irq(pdev, 0);
diff --git a/include/linux/usb/msm_hsusb_hw.h b/include/linux/usb/msm_hsusb_hw.h
index 575c743..10bf692 100644
--- a/include/linux/usb/msm_hsusb_hw.h
+++ b/include/linux/usb/msm_hsusb_hw.h
@@ -16,6 +16,9 @@
#ifndef __LINUX_USB_GADGET_MSM72K_UDC_H__
#define __LINUX_USB_GADGET_MSM72K_UDC_H__
+/* USB phy selector - in TCSR address range */
+#define USB2_PHY_SEL 0xfd4ab000
+
#define USB_AHBBURST (MSM_USB_BASE + 0x0090)
#define USB_AHBMODE (MSM_USB_BASE + 0x0098)
#define USB_CAPLENGTH(MSM_USB_BASE + 0x0100) /* 8 bit */
--
1.8.2.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/
[PATCH 0/5] ftdi-elan: neatening
Found when looking for invalid vsprintf % types, with some other neatenings done. Joe Perches (5): usb: ftdi-elan: Fix format fragments usb: ftdi-elan: Convert leading spaces to tabs usb: ftdi-elan: Coalesce formats usb: ftdi-elan: Coalesce string fragment usb: ftdi-elan: Use pr_ drivers/usb/misc/ftdi-elan.c | 4878 +- 1 file changed, 2419 insertions(+), 2459 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- 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 5/5] usb: ftdi-elan: Use pr_
Use a more current logging style.
Add pr_fmt to prefix messages appropriately.
Signed-off-by: Joe Perches
---
drivers/usb/misc/ftdi-elan.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 10c54b3..8ab1f8f 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -35,6 +35,9 @@
* via an ELAN U132 adapter.
*
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -623,7 +626,7 @@ static int ftdi_elan_open(struct inode *inode, struct file
*file)
interface = usb_find_interface(_elan_driver, subminor);
if (!interface) {
- printk(KERN_ERR "can't find device for minor %d\n", subminor);
+ pr_err("can't find device for minor %d\n", subminor);
return -ENODEV;
} else {
struct usb_ftdi *ftdi = usb_get_intfdata(interface);
@@ -2722,10 +2725,8 @@ static int ftdi_elan_probe(struct usb_interface
*interface,
struct usb_ftdi *ftdi;
ftdi = kzalloc(sizeof(struct usb_ftdi), GFP_KERNEL);
- if (!ftdi) {
- printk(KERN_ERR "Out of memory\n");
+ if (!ftdi)
return -ENOMEM;
- }
mutex_lock(_module_lock);
list_add_tail(>ftdi_list, _static_list);
@@ -2849,7 +2850,7 @@ static struct usb_driver ftdi_elan_driver = {
static int __init ftdi_elan_init(void)
{
int result;
- printk(KERN_INFO "driver %s\n", ftdi_elan_driver.name);
+ pr_info("driver %s\n", ftdi_elan_driver.name);
mutex_init(_module_lock);
INIT_LIST_HEAD(_static_list);
status_queue = create_singlethread_workqueue("ftdi-status-control");
@@ -2866,8 +2867,7 @@ static int __init ftdi_elan_init(void)
destroy_workqueue(status_queue);
destroy_workqueue(command_queue);
destroy_workqueue(respond_queue);
- printk(KERN_ERR "usb_register failed. Error number %d\n",
- result);
+ pr_err("usb_register failed. Error number %d\n", result);
}
return result;
@@ -2876,7 +2876,7 @@ err_respond_queue:
err_command_queue:
destroy_workqueue(status_queue);
err_status_queue:
- printk(KERN_ERR "%s couldn't create workqueue\n",
ftdi_elan_driver.name);
+ pr_err("%s couldn't create workqueue\n", ftdi_elan_driver.name);
return -ENOMEM;
}
@@ -2885,7 +2885,7 @@ static void __exit ftdi_elan_exit(void)
struct usb_ftdi *ftdi;
struct usb_ftdi *temp;
usb_deregister(_elan_driver);
- printk(KERN_INFO "ftdi_u132 driver deregistered\n");
+ pr_info("ftdi_u132 driver deregistered\n");
list_for_each_entry_safe(ftdi, temp, _static_list, ftdi_list) {
ftdi_status_cancel_work(ftdi);
ftdi_command_cancel_work(ftdi);
--
1.8.1.2.459.gbcd45b4.dirty
--
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 3/5] usb: ftdi-elan: Coalesce formats
Make it easier to find formats.
Realign arguments around these changes.
Signed-off-by: Joe Perches
---
drivers/usb/misc/ftdi-elan.c | 151 ---
1 file changed, 56 insertions(+), 95 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 0487f8e..8cda881 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -545,11 +545,10 @@ static void ftdi_elan_status_work(struct work_struct
*work)
ftdi->stuck_status = 0;
ftdi->synchronized = 0;
} else if ((ftdi->stuck_status++ % 60) == 1) {
- dev_err(>udev->dev, "WRONG type of card inserted "
- "- please remove\n");
+ dev_err(>udev->dev, "WRONG type of card inserted
- please remove\n");
} else
- dev_err(>udev->dev, "WRONG type of card inserted "
- "- checked %d times\n", ftdi->stuck_status);
+ dev_err(>udev->dev, "WRONG type of card inserted
- checked %d times\n",
+ ftdi->stuck_status);
work_delay_in_msec = 100;
} else if (ftdi->enumerated == 0) {
if (ftdi_elan_enumeratePCI(ftdi) == 0) {
@@ -562,8 +561,7 @@ static void ftdi_elan_status_work(struct work_struct *work)
ftdi->initialized = 1;
work_delay_in_msec = 500;
} else {
- dev_err(>udev->dev, "initialized failed - trying "
- "again in 10 seconds\n");
+ dev_err(>udev->dev, "initialized failed - trying
again in 10 seconds\n");
work_delay_in_msec = 1 *1000;
}
} else if (ftdi->registered == 0) {
@@ -578,9 +576,7 @@ static void ftdi_elan_status_work(struct work_struct *work)
work_delay_in_msec = 250;
} else if (ftdi->controlreg & 0x0040) {
if (ftdi->gone_away > 0) {
- dev_err(>udev->dev, "PCI device eject con"
- "firmed platform_dev.dev.parent=%p plat"
- "form_dev.dev=%p\n",
+ dev_err(>udev->dev, "PCI device eject
confirmed platform_dev.dev.parent=%p platform_dev.dev=%p\n",
ftdi->platform_dev.dev.parent,
>platform_dev.dev);
platform_device_unregister(>platform_dev);
@@ -788,17 +784,15 @@ static int ftdi_elan_command_engine(struct usb_ftdi *ftdi)
total_size = ftdi_elan_total_command_size(ftdi, command_size);
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
- dev_err(>udev->dev, "could not get a urb to write %d comm"
- "ands totaling %d bytes to the Uxxx\n", command_size,
- total_size);
+ dev_err(>udev->dev, "could not get a urb to write %d
commands totaling %d bytes to the Uxxx\n",
+ command_size, total_size);
return -ENOMEM;
}
buf = usb_alloc_coherent(ftdi->udev, total_size, GFP_KERNEL,
>transfer_dma);
if (!buf) {
- dev_err(>udev->dev, "could not get a buffer to write %d c"
- "ommands totaling %d bytes to the Uxxx\n", command_size,
- total_size);
+ dev_err(>udev->dev, "could not get a buffer to write %d
commands totaling %d bytes to the Uxxx\n",
+ command_size, total_size);
usb_free_urb(urb);
return -ENOMEM;
}
@@ -824,9 +818,8 @@ static int ftdi_elan_command_engine(struct usb_ftdi *ftdi)
}
retval = usb_submit_urb(urb, GFP_KERNEL);
if (retval) {
- dev_err(>udev->dev, "failed %d to submit urb %p to write "
- "%d commands totaling %d bytes to the Uxxx\n", retval,
- urb, command_size, total_size);
+ dev_err(>udev->dev, "failed %d to submit urb %p to write
%d commands totaling %d bytes to the Uxxx\n",
+ retval, urb, command_size, total_size);
usb_free_coherent(ftdi->udev, total_size, buf,
urb->transfer_dma);
usb_free_urb(urb);
return retval;
@@ -980,8 +973,7 @@ read:{
goto have;
} else if (retval == -ETIMEDOUT) {
if (retry_on_timeout-- > 0) {
- dev_err(>udev->dev, "TIMED OUT with packe"
- "t_bytes = %d with total %d bytes%s\n",
+ dev_err(>udev->dev, "TIMED OUT with
packet_bytes = %d with
[PATCH 1/5] usb: ftdi-elan: Fix format fragments
Breaking formats into fragments with a split
between % and field types should be coalesced.
Signed-off-by: Joe Perches
---
drivers/usb/misc/ftdi-elan.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index a4a3c7c..314e597 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -729,8 +729,8 @@ static void ftdi_elan_write_bulk_callback(struct urb *urb)
if (status && !(status == -ENOENT || status == -ECONNRESET ||
status == -ESHUTDOWN)) {
-dev_err(>udev->dev, "urb=%p write bulk status received:
%"
-"d\n", urb, status);
+ dev_err(>udev->dev,
+ "urb=%p write bulk status received: %d\n", urb, status);
}
usb_free_coherent(urb->dev, urb->transfer_buffer_length,
urb->transfer_buffer, urb->transfer_dma);
@@ -1181,8 +1181,8 @@ static ssize_t ftdi_elan_write(struct file *file,
urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
retval = usb_submit_urb(urb, GFP_KERNEL);
if (retval) {
-dev_err(>udev->dev, "failed submitting write urb, error
%"
-"d\n", retval);
+ dev_err(>udev->dev,
+ "failed submitting write urb, error %d\n", retval);
goto error_3;
}
usb_free_urb(urb);
--
1.8.1.2.459.gbcd45b4.dirty
--
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 4/5] usb: ftdi-elan: Coalesce string fragment
Make it easier to grep for this.
Neaten a trailing statement.
Signed-off-by: Joe Perches
---
drivers/usb/misc/ftdi-elan.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 8cda881..10c54b3 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -55,8 +55,8 @@ MODULE_LICENSE("GPL");
#define INT_MODULE_PARM(n, v) static int n = v;module_param(n, int, 0444)
static bool distrust_firmware = 1;
module_param(distrust_firmware, bool, 0);
-MODULE_PARM_DESC(distrust_firmware, "true to distrust firmware
power/overcurren"
-"t setup");
+MODULE_PARM_DESC(distrust_firmware,
+"true to distrust firmware power/overcurrent setup");
extern struct platform_driver u132_platform_driver;
static struct workqueue_struct *status_queue;
static struct workqueue_struct *command_queue;
@@ -590,8 +590,7 @@ static void ftdi_elan_status_work(struct work_struct *work)
ftdi_elan_flush_targets(ftdi);
work_delay_in_msec = 250;
} else {
- dev_err(>udev->dev, "PCI device has disappeared\n"
- );
+ dev_err(>udev->dev, "PCI device has
disappeared\n");
ftdi_elan_cancel_targets(ftdi);
work_delay_in_msec = 500;
ftdi->enumerated = 0;
--
1.8.1.2.459.gbcd45b4.dirty
--
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/
bdi: lockdep warning in bdi_queue_work
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on the following: [ 323.192041] INFO: trying to register non-static key. [ 323.193083] the code is fine but needs lockdep annotation. [ 323.193949] turning off the locking correctness validator. [ 323.194687] CPU: 15 PID: 21793 Comm: trinity-c94 Not tainted 3.14.0-next-20140403-sasha-00019-g7474aa9-dirty #376 [ 323.196300] 8804d9067cf8 954bfb2f [ 323.197522] 99378b10 8804d9067df8 921c3912 88082bddaeb0 [ 323.198879] 8808 88040001 8804d9067d48 [ 323.200063] Call Trace: [ 323.200487] dump_stack (lib/dump_stack.c:52) [ 323.200581] __lock_acquire (kernel/locking/lockdep.c:743 kernel/locking/lockdep.c:3078) [ 323.200581] ? __slab_alloc (mm/slub.c:2385 (discriminator 2)) [ 323.200581] ? __lock_acquire (kernel/locking/lockdep.c:3189) [ 323.200581] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86) [ 323.200581] lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) [ 323.200581] ? bdi_queue_work (arch/x86/include/asm/bitops.h:313 fs/fs-writeback.c:108) [ 323.200581] _raw_spin_lock_bh (include/linux/spinlock_api_smp.h:136 kernel/locking/spinlock.c:175) [ 323.200581] ? bdi_queue_work (arch/x86/include/asm/bitops.h:313 fs/fs-writeback.c:108) [ 323.200581] bdi_queue_work (arch/x86/include/asm/bitops.h:313 fs/fs-writeback.c:108) [ 323.200581] __bdi_start_writeback (fs/fs-writeback.c:141) [ 323.200581] wakeup_flusher_threads (fs/fs-writeback.c:1077) [ 323.200581] ? wakeup_flusher_threads (include/linux/rcupdate.h:800 fs/fs-writeback.c:1076) [ 323.200581] ? syscall_trace_enter (include/linux/context_tracking.h:27 arch/x86/kernel/ptrace.c:1461) [ 323.200581] sys_sync (fs/sync.c:107) [ 323.200581] tracesys (arch/x86/kernel/entry_64.S:749) Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] crypto: qce: Add register defines
Hi Srini, Thanks for the comments. On 04/04/2014 12:23 PM, Srinivas Kandagatla wrote: > > Minor nitpicks. > > On 03/04/14 17:17, Stanimir Varbanov wrote: >> +#define REQ_SIZE17 /* bit 20-17 */ > > I would have defined macros like this with _SHIFT at the end, something > like this: > > #define REQ_SIZE_SHIFT 17 sure, I will add _SHIFT suffix to all places where it is applicable. > >> +#define REQ_SIZE_MASK(0xf << REQ_SIZE) > You could possibly use GENMASK macro for this, its much readable, in > *some cases* it could reduce few more lines in header too. > > #define REQ_SIZE_MASKGENMASK(20, 17) > > > My comments are equally applicable to most macros in this header file. yes, right will do. Thanks. regards, Stan -- 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] QR encoding for Oops messages
On Fri, Apr 4, 2014 at 7:17 PM, Levente Kurusa wrote: > Hi, > > On 04/04/2014 05:15 PM, Jason Cooper wrote: >> On Thu, Apr 03, 2014 at 01:57:04PM -0700, David Lang wrote: >>> On Tue, 1 Apr 2014, Jason Cooper wrote: >>> > Now I guess we need to think how to make it work without a > framebuffer. I already suggested using the ASCII characters, > but seeing the resolution of this QR code for example (147x147), > made me realize that we can't shuffle that into a 80x25 textmode > display. Any ideas how to fix that or should we just simply depend > on a framebuffer being present? I think depending on the framebuffer being present (via kconfig) is sane. Folks running old systems know what they're in for, like missing shiny new features. ;-) >>> >>> First get it working and into acceptable form, but after that, take >>> a look at the various ASCII-art tools out there. While the display >>> may be limited to 80x25, that's not a hard requirement (and I'd >>> happily run systems with a smaller text console if this was an >>> option), and then you can look at the possibility of using >>> characters that represent more than one pixel per character. While >>> this may not be able to render everything perfectly, remember that >>> qr codes can include redundancy to correct for bad pixels, you may >>> be able to get something working. > > I am not sure depending on the error recovery is good practice. > We also have to take into account that scanners themselves also > create noise and may not be perfect. Better reserve the error > recovery for those details instead of messing the QR code with > characters... You do have the option of error recovery for up to 30% recovery (H level), but that means the space you get for storing is smaller. > >> >> I'm not sure this will work. The screen space allocated to a single >> character isn't square. However, the QR pixels are square. I see a lot >> of fragile complexity ahead... >> > > ... not to mention this as well. > > > IMHO supporting textmode is just not worth the effort. Besides, > what would we gain from it? Supporting those devices without > a framebuffer? Do devices like that even exist anymore? In fact, > even to make this you need a screen, and AFAIK most screens come > with some kind of a framebuffer to drive them. Guys, first things first is cleaning the library up. I haven't managed to do anything yet as I am working on my thesis (bachelor's degree, yay!). I will do some this weekend and that is removing the kanji mode support. So, Levente, pleaso do that parameter thing you mentioned. Merging that with the cleanup shouldn't be a problem. :-) I think writing the QR to the frame buffer is the way to do it for now. Doing a QR in text mode (as in displaying it, not as previously mentioned idea with the link base64 encoding &/ compression) would mean that for each square you get an ASCII character filling up your screen. To get an idea of how the QR looks on the frame buffer I've made a screenshot. That's the whole Oops message being encoded and compressed. [0] The problem with frame buffer is that I currently implemented it using the generic frame buffer API. There are some issues as mentioned in the first post of this RFC [1]. Would making it work with KMS be better? Any opinions? Thanks, -- Teodora [0] http://swarm.cs.pub.ro/~teobaluta/QR_code_fb.jpg [1] https://lkml.org/lkml/2014/3/17/525 > > -- > Regards, > Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] XFS updates for 3.15-rc1
Hi Linus, Please pull the following XFS updates for 3.15-rc1. There are a couple of new fallocate features in this request - it was decided that it was easiest to push them through the XFS tree using topic branches and have the ext4 support be based on those branches. Hence you may see some overlap with the ext4 tree merge depending on how they including those topic branches into their tree. Other than that, there is O_TMPFILE support, some cleanups and bug fixes. I've used a signed tag for this pull like you wanted me to do. I think a few people signed my new gpg key last week at LSFMM so it shouldn't be completely bare. Hopefully I haven't screwed anything up - let me know if there's anything you'd like me to do differently in future. Cheers, Dave. The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) are available in the git repository at: git://oss.sgi.com/xfs/xfs.git tags/xfs-for-linus-3.15-rc1 for you to fetch changes up to a6cf33bc566c5fe888bfa9cf6448037c90661f67: Merge branch 'xfs-bug-fixes-for-3.15-3' into for-next (2014-04-04 08:07:35 +1100) xfs: update for 3.15-rc1 The main changes in the XFS tree for 3.15-rc1 are: - O_TMPFILE support - allowing AIO+DIO writes beyond EOF - FALLOC_FL_COLLAPSE_RANGE support for fallocate syscall and XFS implementation - FALLOC_FL_ZERO_RANGE support for fallocate syscall and XFS implementation - IO verifier cleanup and rework - stack usage reduction changes - vm_map_ram NOIO context fixes to remove lockdep warings - various bug fixes and cleanups Ben Myers (1): MAINTAINERS: SGI no longer maintaining XFS Brian Foster (3): xfs: use tr_growrtalloc for growing rt files xfs: use tr_qm_dqalloc log reservation for dquot alloc xfs: avoid AGI/AGF deadlock scenario for inode chunk allocation Christoph Hellwig (4): direct-io: add flag to allow aio writes beyond i_size xfs: always use unwritten extents for direct I/O writes xfs: allow appending aio writes xfs: ensure correct timestamp updates from truncate Dan Carpenter (1): xfs: extra semi-colon breaks a condition Dave Chinner (16): xfs: ensure correct log item buffer alignment Merge branch 'xfs-fixes-for-3.15' into for-next Merge remote-tracking branch 'xfs-async-aio-extend' into for-next xfs: always do log forces via the workqueue xfs: allocate xfs_da_args to reduce stack footprint xfs: fix directory inode iolock lockdep false positive xfs: don't leak EFSBADCRC to userspace xfs: use NOIO contexts for vm_map_ram xfs: xfs_check_page_type buffer checks need help xfs: inode log reservations are still too small Merge branch 'xfs-collapse-range' into for-next Merge branch 'xfs-stack-fixes' into for-next Merge branch 'xfs-verifier-cleanup' into for-next Merge branch 'xfs-bug-fixes-for-3.15-2' into for-next Merge branch 'xfs-O_TMPFILE-support' into for-next Merge branch 'xfs-bug-fixes-for-3.15-3' into for-next Eric Sandeen (12): xfs: remove unused tr_swrite xfs: sanitize sb_inopblock in xfs_mount_validate_sb xfs: xfs_sb_read_verify() doesn't flag bad crcs on primary sb xfs: skip verification on initial "guess" superblock read xfs: limit superblock corruption errors to actual corruption xfs: skip pointless CRC updates after verifier failures xfs: Use defines for CRC offsets in all cases xfs: add helper for verifying checksums on xfs_bufs xfs: add helper for updating checksums on xfs_bufs xfs: add xfs_verifier_error() xfs: print useful caller information in xfs_error_report xfs: modify verifiers to differentiate CRC from other errors Jie Liu (3): xfs: convert xfs_log_commit_cil() to void xfs: return -E2BIG if hit the maximum size limits of ACLs xfs: remove XFS_TRANS_DEBUG dead code Lukas Czerner (2): fs: Introduce FALLOC_FL_ZERO_RANGE flag for fallocate xfs: Add support for FALLOC_FL_ZERO_RANGE Mark Tinguely (1): xfs: fix directory hash ordering bug Namjae Jeon (2): fs: Add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate xfs: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate Zhi Yong Wu (3): xfs: factor prid related codes into xfs_get_initial_prid() xfs: add O_TMPFILE support xfs: allow linkat() on O_TMPFILE files MAINTAINERS |1 - fs/direct-io.c | 18 ++- fs/open.c | 29 +++- fs/xfs/kmem.c | 21 ++- fs/xfs/xfs_acl.c|2 +- fs/xfs/xfs_ag.h |6 + fs/xfs/xfs_alloc.c | 45 +++--- fs/xfs/xfs_alloc_btree.c| 16 +-
[PATCH v3] Staging: lustre: mark a variable static in workitem.c
This fixes a sparse warning:
warning: symbol 'cfs_wi_data' was not declared. Should it be static?
Signed-off-by: Mike Sampson
---
v3: updated the changelog
drivers/staging/lustre/lustre/libcfs/workitem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/workitem.c
b/drivers/staging/lustre/lustre/libcfs/workitem.c
index ba16fd5..0a03bf7 100644
--- a/drivers/staging/lustre/lustre/libcfs/workitem.c
+++ b/drivers/staging/lustre/lustre/libcfs/workitem.c
@@ -75,7 +75,7 @@ typedef struct cfs_wi_sched {
charws_name[CFS_WS_NAME_LEN];
} cfs_wi_sched_t;
-struct cfs_workitem_data {
+static struct cfs_workitem_data {
/** serialize */
spinlock_t wi_glock;
/** list of all schedulers */
--
1.9.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/
Re: [GIT PULL for v3.15-rc1] media updates
On Thu, Apr 3, 2014 at 9:11 AM, Mauro Carvalho Chehab
wrote:
>
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> v4l_for_linus
Oh, just noticed that this seems to be the cause of a new annoying warning:
usr/include/linux/v4l2-common.h:72: found __[us]{8,16,32,64} type
without #include
which seems to have come in through commits 777f4f85b75f1 and 254a47770163f.
I think the proper fix is to just add that
#include
to include/uapi/linux/v4l2-common.h. Assuming that really is supposed
to be a user-visible API at all?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/hugetlb.c: add NULL check of return value of huge_pte_offset
On Fri, 04 Apr 2014 14:43:33 -0400 Naoya Horiguchi
wrote:
> huge_pte_offset() could return NULL, so we need NULL check to avoid
> potential NULL pointer dereferences.
>
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2662,7 +2662,8 @@ static int hugetlb_cow(struct mm_struct *mm, struct
> vm_area_struct *vma,
> BUG_ON(huge_pte_none(pte));
> spin_lock(ptl);
> ptep = huge_pte_offset(mm, address &
> huge_page_mask(h));
> - if (likely(pte_same(huge_ptep_get(ptep), pte)))
> + if (likely(ptep &&
> +pte_same(huge_ptep_get(ptep), pte)))
> goto retry_avoidcopy;
> /*
>* race occurs while re-acquiring page table
> @@ -2706,7 +2707,7 @@ static int hugetlb_cow(struct mm_struct *mm, struct
> vm_area_struct *vma,
>*/
> spin_lock(ptl);
> ptep = huge_pte_offset(mm, address & huge_page_mask(h));
> - if (likely(pte_same(huge_ptep_get(ptep), pte))) {
> + if (likely(ptep && pte_same(huge_ptep_get(ptep), pte))) {
> ClearPagePrivate(new_page);
>
> /* Break COW */
Has anyone been hitting oopses here or was this from code inspection?
--
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] ARM: zynq: dt: Convert to preprocessor includes
Convert all Zynq DT files to the dtc preprocessor include syntax.
This allows to include header files in the devicetrees like other
SoC-types already do.
Inspired-by: Steffen Trumtrar
(http://www.spinics.net/lists/arm-kernel/msg319832.html)
Signed-off-by: Soren Brinkmann
---
arch/arm/boot/dts/zynq-7000.dtsi | 3 ++-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 789d0bacc110..b028278b7f49 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -10,7 +10,8 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
-/include/ "skeleton.dtsi"
+
+#include "skeleton.dtsi"
/ {
compatible = "xlnx,zynq-7000";
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index c913f77a21eb..07713d3c716a 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -12,7 +12,7 @@
* GNU General Public License for more details.
*/
/dts-v1/;
-/include/ "zynq-7000.dtsi"
+#include "zynq-7000.dtsi"
/ {
model = "Zynq ZC702 Development Board";
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 88f62c50382e..cf6566cdb02a 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -13,7 +13,7 @@
* GNU General Public License for more details.
*/
/dts-v1/;
-/include/ "zynq-7000.dtsi"
+#include "zynq-7000.dtsi"
/ {
model = "Zynq ZC706 Development Board";
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 82d7ef1a9a9c..1541716e2cfb 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -13,7 +13,7 @@
* GNU General Public License for more details.
*/
/dts-v1/;
-/include/ "zynq-7000.dtsi"
+#include "zynq-7000.dtsi"
/ {
model = "Zynq Zed Development Board";
--
1.9.1.1.gbb9f595
--
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] ARM: zynq: dt: Use #defines for interrupt specifiers
Use #defines from the common include file to describe
interrupt specifiers.
Signed-off-by: Soren Brinkmann
---
---
arch/arm/boot/dts/zynq-7000.dtsi | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index b028278b7f49..a219a927c0e4 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -12,6 +12,7 @@
*/
#include "skeleton.dtsi"
+#include
/ {
compatible = "xlnx,zynq-7000";
@@ -43,7 +44,7 @@
pmu {
compatible = "arm,cortex-a9-pmu";
- interrupts = <0 5 4>, <0 6 4>;
+ interrupts = , ;
interrupt-parent = <>;
reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
};
@@ -79,7 +80,7 @@
clocks = < 23>, < 40>;
clock-names = "ref_clk", "aper_clk";
reg = <0xE000 0x1000>;
- interrupts = <0 27 4>;
+ interrupts = ;
};
uart1: uart@e0001000 {
@@ -88,14 +89,14 @@
clocks = < 24>, < 41>;
clock-names = "ref_clk", "aper_clk";
reg = <0xE0001000 0x1000>;
- interrupts = <0 50 4>;
+ interrupts = ;
};
gem0: ethernet@e000b000 {
compatible = "cdns,gem";
reg = <0xe000b000 0x4000>;
status = "disabled";
- interrupts = <0 22 4>;
+ interrupts = ;
clocks = < 30>, < 30>, < 13>;
clock-names = "pclk", "hclk", "tx_clk";
};
@@ -104,7 +105,7 @@
compatible = "cdns,gem";
reg = <0xe000c000 0x4000>;
status = "disabled";
- interrupts = <0 45 4>;
+ interrupts = ;
clocks = < 31>, < 31>, < 14>;
clock-names = "pclk", "hclk", "tx_clk";
};
@@ -115,7 +116,7 @@
clock-names = "clk_xin", "clk_ahb";
clocks = < 21>, < 32>;
interrupt-parent = <>;
- interrupts = <0 24 4>;
+ interrupts = ;
reg = <0xe010 0x1000>;
} ;
@@ -125,7 +126,7 @@
clock-names = "clk_xin", "clk_ahb";
clocks = < 22>, < 33>;
interrupt-parent = <>;
- interrupts = <0 47 4>;
+ interrupts = ;
reg = <0xe0101000 0x1000>;
} ;
@@ -159,14 +160,16 @@
global_timer: timer@f8f00200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0xf8f00200 0x20>;
- interrupts = <1 11 0x301>;
+ interrupts = ;
interrupt-parent = <>;
clocks = < 4>;
};
ttc0: ttc0@f8001000 {
interrupt-parent = <>;
- interrupts = < 0 10 4 0 11 4 0 12 4 >;
+ interrupts = ,
+,
+;
compatible = "cdns,ttc";
clocks = < 6>;
reg = <0xF8001000 0x1000>;
@@ -174,14 +177,16 @@
ttc1: ttc1@f8002000 {
interrupt-parent = <>;
- interrupts = < 0 37 4 0 38 4 0 39 4 >;
+ interrupts = ,
+,
+;
compatible = "cdns,ttc";
clocks = < 6>;
reg = <0xF8002000 0x1000>;
};
scutimer: scutimer@f8f00600 {
interrupt-parent = <>;
- interrupts = < 1 13 0x301 >;
+ interrupts = ;
compatible = "arm,cortex-a9-twd-timer";
reg = < 0xf8f00600 0x20 >;
clocks = < 4>;
--
1.9.1.1.gbb9f595
--
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 9/9] uprobes/x86: Teach arch_uprobe_post_xol() to restart if possible
On Fri, 2014-04-04 at 20:51 +0200, Oleg Nesterov wrote:
> SIGILL after the failed arch_uprobe_post_xol() should only be used as
> a last resort, we should try to restart the probed insn if possible.
>
> Currently only adjust_ret_addr() can fail, and this can only happen if
> another thread unmapped our stack after we executed "call" out-of-line.
> Most probably the application if buggy, but even in this case it can
> have a handler for SIGSEGV/etc. And in theory it can be even correct
> and do something non-trivial with its memory.
>
> Of course we can't restart unconditionally, so arch_uprobe_post_xol()
> does this only if ->post_xol() returns -ERESTART even if currently this
> is the only possible error.
When re-executing the call instruction, I'd think the stack pointer
would be wrong the second time around, unless you pop off the return
address from the first try.
>
> Note: this is not "perfect", we do not want the extra handler_chain()
> after restart, but I think this is the best solution we can realistically
> do without too much uglifications.
>
> Signed-off-by: Oleg Nesterov
> ---
> arch/x86/kernel/uprobes.c | 15 +++
> 1 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index e72903e..b820668 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -443,16 +443,17 @@ static int default_post_xol_op(struct arch_uprobe
> *auprobe, struct pt_regs *regs
> {
> struct uprobe_task *utask = current->utask;
> long correction = (long)(utask->vaddr - utask->xol_vaddr);
> - int ret = 0;
>
> handle_riprel_post_xol(auprobe, regs, );
> if (auprobe->fixups & UPROBE_FIX_IP)
> regs->ip += correction;
>
> - if (auprobe->fixups & UPROBE_FIX_CALL)
> - ret = adjust_ret_addr(regs->sp, correction);
> + if (auprobe->fixups & UPROBE_FIX_CALL) {
> + if (adjust_ret_addr(regs->sp, correction))
> + return -ERESTART;
> + }
>
> - return ret;
> + return 0;
> }
>
> static struct uprobe_xol_ops default_xol_ops = {
> @@ -599,6 +600,12 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe,
> struct pt_regs *regs)
> int err = auprobe->ops->post_xol(auprobe, regs);
> if (err) {
> arch_uprobe_abort_xol(auprobe, regs);
> + /*
> + * Restart the probed insn. ->post_xol() must ensure
> + * this is really possible if it returns -ERESTART.
> + */
> + if (err == -ERESTART)
> + return 0;
> return err;
> }
> }
--
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/3] printk: using booting time as the timestamp
On 04/03/2014 08:18 PM, Lei Wen wrote: > As people may want to align the kernel log with some other processor > running over the same machine but not the same copy of linux, we > need to keep their log aligned, so that it would not make debug > process hard and confused. > > Signed-off-by: Lei Wen > --- > kernel/printk/printk.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index a45b509..af96fbd 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -349,7 +349,7 @@ static void log_store(int facility, int level, > if (ts_nsec > 0) > msg->ts_nsec = ts_nsec; > else > - msg->ts_nsec = local_clock(); > + msg->ts_nsec = ktime_to_ns(ktime_get_boottime()); No no... Since ktime_get_boottime() takes the timekeeping seqlock, this will cause any printk (or WARN_ON, etc) that is done while holding a write in the timekeeping seqlock to deadlock (which I mentioned last time). I think the better solution here is to have the timekeeping code provide the printk logic the offset value whenever the sleep time is updated. That way the printk logic can manage its own values w/o having to take any timekeeping locks. That said, I'm still not really fond of trying to add this functionality. The printk timestamping code was always a little fuzzy, using jiffies or sched_clock in order to give a rough estimate of boot delays (and didn't include ntp freq correction, etc). When it was introduced, I feel like folks were concerned about this, but folks agreed the rough estimates were worth it, and it didn't have to involve the real timekeeping code. Now, trying to raise the bar here to make printk timestamps actually correlate with CLOCK_BOOTTIME/REALTIME/MONOTONIC (which I'll admit, seems quite reasonable given we have timestamps already - but ends up being feature creep) will add quite a bit of complexity due to the fact that printk is supposed to be safe to call from everywhere. And again, syslog can add timestamps to the kernel messages relatively well in userland. So I'm not sure the need is clear. thanks -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: [PATCH] i2c-designware: Mask interrupts during i2c controller enable
>Interrupt masking is done already after each transaction. At end of transfer, the code uses __i2c_dw_enable(dev, false) to disable adapter. This function doesn't mask interrupts. There is another function i2c_dw_disable that masks and clears interrupts. This could be used, but that means we need to fix in 2 places: 1. add interrupt masking to i2c_dw_init(); 2. change call __i2c_dw_enable(dev, false) to i2c_dw_disable; I think simply masking interrupt in i2c_dw_xfer_init is cleaner and safer. >The problem here is that after reset, the interrupt mask register gets 0x8ff >value (HW default), which means that most of the interrupts are left unmasked. >That is the reason why this only happens right after we resume from system >sleep. Masking interrupts on that path fixes the problem. The time out also happened in case of going into suspend and during normal operations. But at much less occurrence at 1-2 per 1000 cycles. -- 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: GFS2: Pull request (merge window)
On Tue, Apr 1, 2014 at 4:15 PM, Steven Whitehouse wrote: > > Please consider pulling the following changes This pull request is also missing shortlog and diffstat, like Jeff Layton's did. Did we have some tooling failure, or is it just coincidence? Please, guys, make sure your pull requests are valid. I've pulled this one too, but.. Linus -- 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] pci: changed '...pci_bus* bus' to '...pci_bus *bus'
On Fri, Apr 04, 2014 at 05:23:34PM -0400, Ryan Desfosses wrote:
> change made to resolve following checkpatch message:
> drivers/pci/pci.c:109: ERROR: "foo* bar" should be "foo *bar"
> branch: Linux 3.14-rc8
>
> Signed-off-by: Ryan Desfosses
Applied (folded into your other patch), thanks!
> ---
> drivers/pci/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index fdbc294..a50d542 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -106,7 +106,7 @@ static bool pcie_ari_disabled;
> * Given a PCI bus, returns the highest PCI bus number present in the set
> * including the given PCI bus and its list of child PCI buses.
> */
> -unsigned char pci_bus_max_busnr(struct pci_bus* bus)
> +unsigned char pci_bus_max_busnr(struct pci_bus *bus)
> {
> struct list_head *tmp;
> unsigned char max, n;
> --
> 1.9.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/
Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline
> "Linus" == Linus Torvalds writes: Linus> On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski wrote: >> >> The other thing I've used /dev/kmsg for is to shove a "I'm starting >> something now" message in. This is only really necessary because the >> current kernel log timestamps are unusable crap. (We could fix that, >> hint hint.) Linus> I'd actually love to fix that, but I disagree with the "we could fix Linus> it". There are tons of people who know how to parse them (admittedly Linus> often only to ignore them), so changing the format is not likely to Linus> work. Linus> The good news is that "dmesg -H" does help if you're Linus> human. While at the same time being an example of that very Linus> "there are tools that know about the current horrid format" Linus> issue.. D'oh. I think you mean "dmesg -T", and unfortunately it seems Debian 6.0.9 (or older) doesn ship a new enough linux-util since I've only got 2.17.2-9 install. And RHEL/Centos 5.6 and 6.5 don't seem to ship that by default either, they have got util-linux-2.13-0.56.el5 and util-linux-ng-2.17.2-12.14.el6.x86_64 respectively. Blech! It's in Linux Mint 16 at least, haven't checked older versions. 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/
[PATCH v5 2/3] i2c: Add driver for Cadence I2C controller
Add a driver for the Cadence I2C controller. This controller is for example found in Xilinx Zynq. Signed-off-by: Soren Brinkmann Tested-by: Michal Simek Reviewed-by: Harini Katakam --- Changes in v5: - change default speed to 100 kHz - report NACK errors with -ENXIO error code Changes in v4: - Addressing Wolfram's feedback - style improvements (e.g. magic numbers, typos,...) - initialize completion in probe and use reinit_completion during transfers - refactor code to let the core handle retries (on xfer error and bus-busy) - use i2c_add_adapter instead of i2c_add_numbered_adapter - use msecs_to_jiffies to specify timeout - revise timeouts - reformat kernel doc - remove CONFIG_PM_SLEEP ifdefs and annotate suspend/resume functions with '__maybe_unsued' - moved DT documentation into separate patch - use (read|write)l_relaxed IO helpers - revise ISR to return IRQ_HANDLED only if an IRQ has actually been handled Changes in v3: - incorporate signal handling changes from Mike Looijmans (https://lkml.org/lkml/2014/3/11/64) Changes in v2: - make driver depend on COMMON_CLK instead of ARCH_ZYNQ --- MAINTAINERS | 1 + drivers/i2c/busses/Kconfig | 7 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-cadence.c | 905 +++ 4 files changed, 914 insertions(+) create mode 100644 drivers/i2c/busses/i2c-cadence.c diff --git a/MAINTAINERS b/MAINTAINERS index 8774f7974d69..539c9410f1a9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1411,6 +1411,7 @@ F:drivers/cpuidle/cpuidle-zynq.c N: zynq N: xilinx F: drivers/clocksource/cadence_ttc_timer.c +F: drivers/i2c/busses/i2c-cadence.c F: drivers/mmc/host/sdhci-of-arasan.c ARM SMMU DRIVER diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index de17c5593d97..66e68e48218f 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -375,6 +375,13 @@ config I2C_BLACKFIN_TWI_CLK_KHZ help The unit of the TWI clock is kHz. +config I2C_CADENCE + tristate "Cadence I2C Controller" + depends on COMMON_CLK + help + Say yes here to select Cadence I2C Host Controller. This controller is + e.g. used by Xilinx Zynq. + config I2C_CBUS_GPIO tristate "CBUS I2C driver" depends on GPIOLIB diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index a08931fe73e1..f9ebb8c6cdc1 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o +obj-$(CONFIG_I2C_CADENCE) += i2c-cadence.o obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o obj-$(CONFIG_I2C_CPM) += i2c-cpm.o obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c new file mode 100644 index ..63f3f03ecc9b --- /dev/null +++ b/drivers/i2c/busses/i2c-cadence.c @@ -0,0 +1,905 @@ +/* + * I2C bus driver for the Cadence I2C controller. + * + * Copyright (C) 2009 - 2014 Xilinx, Inc. + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include + +/* Register offsets for the I2C device. */ +#define CDNS_I2C_CR_OFFSET 0x00 /* Control Register, RW */ +#define CDNS_I2C_SR_OFFSET 0x04 /* Status Register, RO */ +#define CDNS_I2C_ADDR_OFFSET 0x08 /* I2C Address Register, RW */ +#define CDNS_I2C_DATA_OFFSET 0x0C /* I2C Data Register, RW */ +#define CDNS_I2C_ISR_OFFSET0x10 /* IRQ Status Register, RW */ +#define CDNS_I2C_XFER_SIZE_OFFSET 0x14 /* Transfer Size Register, RW */ +#define CDNS_I2C_TIME_OUT_OFFSET 0x1C /* Time Out Register, RW */ +#define CDNS_I2C_IER_OFFSET0x24 /* IRQ Enable Register, WO */ +#define CDNS_I2C_IDR_OFFSET0x28 /* IRQ Disable Register, WO */ + +/* Control Register Bit mask definitions */ +#define CDNS_I2C_CR_HOLD BIT(4) /* Hold Bus bit */ +#define CDNS_I2C_CR_ACK_EN BIT(3) +#define CDNS_I2C_CR_NEABIT(2) +#define CDNS_I2C_CR_MS BIT(1) +/* Read or Write Master transfer 0 = Transmitter, 1 = Receiver */ +#define CDNS_I2C_CR_RW BIT(0) +/* 1 = Auto init FIFO to zeroes */ +#define CDNS_I2C_CR_CLR_FIFO BIT(6) +#define CDNS_I2C_CR_DIVA_SHIFT 14 +#define CDNS_I2C_CR_DIVA_MASK (3 << CDNS_I2C_CR_DIVA_SHIFT) +#define CDNS_I2C_CR_DIVB_SHIFT 8 +#define
RE: [E1000-devel] fail to add 64 VLANs or more when SR-IOV is enabled
You can have more than 64 VLANs, but not for a single VF. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Madoka Komatsubara [mailto:m-komatsub...@ab.jp.nec.com] Sent: Wednesday, April 02, 2014 7:04 PM To: David Miller; Fujinaka, Todd; Skidmore, Donald C; linux-kernel@vger.kernel.org; e1000-de...@lists.sourceforge.net; net...@vger.kernel.org Cc: Hiroshi Shimamoto; Hiroshi Baba Subject: RE: [E1000-devel] fail to add 64 VLANs or more when SR-IOV is enabled > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, April 03, 2014 10:40 AM > To: Komatsubara Madoka(小松原 円) > Cc: todd.fujin...@intel.com; donald.c.skidm...@intel.com; > linux-kernel@vger.kernel.org; e1000-de...@lists.sourceforge.net; > net...@vger.kernel.org; Shimamoto Hiroshi(島本 裕志); Baba Hiroshi(馬場 裕 > 司) > Subject: Re: [E1000-devel] fail to add 64 VLANs or more when SR-IOV is > enabled > > From: Madoka Komatsubara > Date: Thu, 3 Apr 2014 01:12:13 + > > > Thank you for the quick response. > > How can I increase the limit？ > > It's a hardware limit, you cannot increase it. Thank you for your information. Does it mean disabling filter is the only way to use over 64 VLANs and is it possible? Regards, Madoka -- 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] staging: comedi: drivers: pcl812.c: add curly braces for checkpatch
On Fri, Apr 04, 2014 at 06:44:44PM +0300, Kumar Amit Mehta wrote: > Kernel style is that if one side of the if else statement gets has curly > braces then both side should have them. > > Signed-off-by: Kumar Amit Mehta Looks good, thanks. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/3] i2c: cadence: Document device tree bindings
Add device tree binding documentation for the Cadence I2C controller.
Signed-off-by: Soren Brinkmann
---
Changes in v5:
- Document all properties
- list clock-names as optional property (driver doesn't use it, though)
- use lower case hex digits in 'reg' property
- reword description of 'clocks' property
- remove implementation specific notes regarding default speed
- use #defines for interrupt specifier
Changes in v4:
- moved adding DT docs into this dedicated patch
Changes in v3: None
Changes in v2: None
---
.../devicetree/bindings/i2c/i2c-cadence.txt| 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cadence.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
new file mode 100644
index ..7cb0b5608f49
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
@@ -0,0 +1,24 @@
+Binding for the Cadence I2C controller
+
+Required properties:
+ - reg: Physical base address and size of the controller's register area.
+ - compatible: Compatibility string. Must be 'cdns,i2c-r1p10'.
+ - clocks: Input clock specifier. Refer to common clock bindings.
+ - interrupts: Interrupt specifier. Refer to interrupt bindings.
+ - #address-cells: Should be 1.
+ - #size-cells: Should be 0.
+
+Optional properties:
+ - clock-frequency: Desired operating frequency, in Hz, of the bus.
+ - clock-names: Input clock name, should be 'pclk'.
+
+Example:
+ i2c@e0004000 {
+ compatible = "cdns,i2c-r1p10";
+ clocks = < 38>;
+ interrupts = ;
+ reg = <0xe0004000 0x1000>;
+ clock-frequency = <40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
--
1.9.1.1.gbb9f595
--
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 v5 3/3] ARM: zynq: dt: Add I2C nodes to Zynq device tree
Signed-off-by: Soren Brinkmann
Tested-by: Michal Simek
---
Changes in v5:
- use lower case hex digits in 'reg' property
Changes in v4: None
Changes in v3: None
Changes in v2:
- replace 'pmbus' with 'ti' in compatibility strings of UCD devices
---
arch/arm/boot/dts/zynq-7000.dtsi | 22
arch/arm/boot/dts/zynq-zc702.dts | 76
arch/arm/boot/dts/zynq-zc706.dts | 68 +++
3 files changed, 166 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 789d0bacc110..7a7da1d45351 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -54,6 +54,28 @@
interrupt-parent = <>;
ranges;
+ i2c0: zynq-i2c@e0004000 {
+ compatible = "cdns,i2c-r1p10";
+ status = "disabled";
+ clocks = < 38>;
+ interrupt-parent = <>;
+ interrupts = <0 25 4>;
+ reg = <0xe0004000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: zynq-i2c@e0005000 {
+ compatible = "cdns,i2c-r1p10";
+ status = "disabled";
+ clocks = < 39>;
+ interrupt-parent = <>;
+ interrupts = <0 48 4>;
+ reg = <0xe0005000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
intc: interrupt-controller@f8f01000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index c913f77a21eb..5e09cee33d42 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -34,6 +34,82 @@
phy-mode = "rgmii";
};
+ {
+ status = "okay";
+ clock-frequency = <40>;
+
+ i2cswitch@74 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x74>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ si570: clock-generator@5d {
+ #clock-cells = <0>;
+ compatible = "silabs,si570";
+ temperature-stability = <50>;
+ reg = <0x5d>;
+ factory-fout = <15625>;
+ clock-frequency = <14850>;
+ };
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ eeprom@54 {
+ compatible = "at,24c08";
+ reg = <0x54>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ gpio@21 {
+ compatible = "ti,tca6416";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+ };
+
+ i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ hwmon@52 {
+ compatible = "ti,ucd9248";
+ reg = <52>;
+ };
+ hwmon@53 {
+ compatible = "ti,ucd9248";
+ reg = <53>;
+ };
+ hwmon@54 {
+ compatible = "ti,ucd9248";
+ reg = <54>;
+ };
+ };
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 88f62c50382e..4cc9913078cd 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -35,6 +35,74 @@
phy-mode = "rgmii";
};
+ {
+ status = "okay";
+
Re: [PATCH v4 1/1] staging: comedi: Fix checkpatch warning
On Fri, Apr 04, 2014 at 11:10:51PM +0200, Camille Begue wrote: > Wrap lines > 80 columns. > > Signed-off-by: Camille Begue Looks good now. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] arm: fixmap: implement __set_fixmap()
This is used from set_fixmap() and clear_fixmap() via
asm-generic/fixmap.h.
Signed-off-by: Rabin Vincent
---
Needs "arm: use generic fixmap.h", available in linux-next.
arch/arm/include/asm/fixmap.h | 2 ++
arch/arm/mm/mmu.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 68ea615..55ed076 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -23,6 +23,8 @@ enum fixed_addresses {
__end_of_fixed_addresses
};
+void __set_fixmap(enum fixed_addresses idx, unsigned long phys, pgprot_t prot);
+
#include
#endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 3e16307..61bdfb1 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -388,6 +389,12 @@ SET_MEMORY_FN(rw, pte_set_rw)
SET_MEMORY_FN(x, pte_set_x)
SET_MEMORY_FN(nx, pte_set_nx)
+void __set_fixmap(enum fixed_addresses idx, unsigned long phys, pgprot_t prot)
+{
+ BUG_ON(idx >= __end_of_fixed_addresses);
+ set_top_pte(__fix_to_virt(idx), pfn_pte(__phys_to_pfn(phys), prot));
+}
+
/*
* Adjust the PMD section entries according to the CPU in use.
*/
--
1.9.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/
Re: [GIT PULL] please pull file locking changes for 3.15
On Mon, Mar 31, 2014 at 6:31 AM, Jeff Layton wrote:
> The following changes since commit 29723adee11804b548903ddb1db666cf4a60f60e:
>
> locks: make locks_mandatory_area check for file-private locks (2014-03-31
> 08:24:43 -0400)
>
> are available in the git repository at:
>
> git://git.samba.org/jlayton/linux.git locks-3.15
Please please please use the proper scripts (or improve on whatever
local script you use) that show the diffstat ("git diff -M --stat
--summary") and shortlog for the pull request too.
I want to know roughly what I'm pulling *before* I pull it, and while
I can do a two-stage thing where I first fetch-and-inspect it, that's
annoying. Your human-readable "Highlights" thing is good, and I want
that too (I put commentary like that into the merge commit itself),
but I do want that diffstat/shortlog in addition to the human-readable
summary.
Because having the diffstat in the pull request email not only gets me
a heasd-up abotu what to expect, it also confirms that I'm on the same
page as you are. It acts as a sanity-check for me when I can compare
the diffstat you *claim* I should get with the diffstat I actually get
after merging. So I really want to get that diffstat and shortlog as a
sanity check.
I also would prefer signed tags. It's not a must since it's not like
git.samba.org is some random public site (I do _require_ them for pull
requests from github etc), but it's definitely a "good thing" to have.
Anyway, I'm going through my pile of filesystem pull requests, and
I've pulled this into my tree. I'm just going through allmodconfig
builds etc before pushing my merge out, so assuming that all works
fine you don't need to resend this one. But for future pull requests,
please do try to fix the above up.
Linus
--
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] arm: use fixmap for text patching when text is RO
Use fixmaps for text patching when the kernel text is read-only,
inspired by x86. This makes jump labels and kprobes work with the
currently available CONFIG_DEBUG_SET_MODULE_RONX and the upcoming
CONFIG_DEBUG_RODATA options.
Signed-off-by: Rabin Vincent
---
arch/arm/include/asm/fixmap.h | 3 ++
arch/arm/kernel/jump_label.c | 2 +-
arch/arm/kernel/patch.c | 66 ++-
arch/arm/kernel/patch.h | 12 +++-
4 files changed, 74 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 55ed076..79c1719 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -18,6 +18,9 @@
#define FIXADDR_TOP(FIXADDR_END - PAGE_SIZE)
enum fixed_addresses {
+ FIX_TEXT_POKE0,
+ FIX_TEXT_POKE1,
+
FIX_KMAP_BEGIN,
FIX_KMAP_END = (FIXADDR_TOP - FIXADDR_START) >> PAGE_SHIFT,
__end_of_fixed_addresses
diff --git a/arch/arm/kernel/jump_label.c b/arch/arm/kernel/jump_label.c
index 4ce4f78..afeeb9e 100644
--- a/arch/arm/kernel/jump_label.c
+++ b/arch/arm/kernel/jump_label.c
@@ -19,7 +19,7 @@ static void __arch_jump_label_transform(struct jump_entry
*entry,
insn = arm_gen_nop();
if (is_static)
- __patch_text(addr, insn);
+ __patch_text_early(addr, insn);
else
patch_text(addr, insn);
}
diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
index 07314af..761c5b6 100644
--- a/arch/arm/kernel/patch.c
+++ b/arch/arm/kernel/patch.c
@@ -1,8 +1,11 @@
#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -13,21 +16,67 @@ struct patch {
unsigned int insn;
};
-void __kprobes __patch_text(void *addr, unsigned int insn)
+static DEFINE_SPINLOCK(patch_lock);
+
+static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
+{
+ unsigned int uintaddr = (uintptr_t) addr;
+ bool module = !core_kernel_text(uintaddr);
+ struct page *page;
+
+ if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX)) {
+ page = vmalloc_to_page(addr);
+ } else if (!module && IS_ENABLED(CONFIG_ARM_KERNMEM_PERMS)) {
+ page = virt_to_page(addr);
+ } else {
+ return addr;
+ }
+
+ if (flags)
+ spin_lock_irqsave(_lock, *flags);
+
+ set_fixmap(fixmap, page_to_phys(page));
+
+ return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
+}
+
+static void __kprobes patch_unmap(int fixmap, unsigned long *flags)
+{
+ clear_fixmap(fixmap);
+
+ if (flags)
+ spin_unlock_irqrestore(_lock, *flags);
+}
+
+void __kprobes __patch_text_real(void *addr, unsigned int insn, bool remap)
{
bool thumb2 = IS_ENABLED(CONFIG_THUMB2_KERNEL);
+ unsigned int uintaddr = (uintptr_t) addr;
+ unsigned long flags;
+ void *waddr = addr;
int size;
+ if (remap)
+ waddr = patch_map(addr, FIX_TEXT_POKE0, );
+
if (thumb2 && __opcode_is_thumb16(insn)) {
- *(u16 *)addr = __opcode_to_mem_thumb16(insn);
+ *(u16 *)waddr = __opcode_to_mem_thumb16(insn);
size = sizeof(u16);
- } else if (thumb2 && ((uintptr_t)addr & 2)) {
+ } else if (thumb2 && (uintaddr & 2)) {
+ bool twopage = (uintaddr & ~PAGE_MASK) == PAGE_SIZE - 2;
u16 first = __opcode_thumb32_first(insn);
u16 second = __opcode_thumb32_second(insn);
- u16 *addrh = addr;
+ u16 *addrh0 = waddr;
+ u16 *addrh1 = waddr + 2;
+
+ if (remap && twopage)
+ addrh1 = patch_map(addr + 2, FIX_TEXT_POKE1, NULL);
- addrh[0] = __opcode_to_mem_thumb16(first);
- addrh[1] = __opcode_to_mem_thumb16(second);
+ *addrh0 = __opcode_to_mem_thumb16(first);
+ *addrh1 = __opcode_to_mem_thumb16(second);
+
+ if (twopage && addrh1 != addr + 2)
+ patch_unmap(FIX_TEXT_POKE1, NULL);
size = sizeof(u32);
} else {
@@ -36,10 +85,13 @@ void __kprobes __patch_text(void *addr, unsigned int insn)
else
insn = __opcode_to_mem_arm(insn);
- *(u32 *)addr = insn;
+ *(u32 *)waddr = insn;
size = sizeof(u32);
}
+ if (waddr != addr)
+ patch_unmap(FIX_TEXT_POKE0, );
+
flush_icache_range((uintptr_t)(addr),
(uintptr_t)(addr) + size);
}
diff --git a/arch/arm/kernel/patch.h b/arch/arm/kernel/patch.h
index b4731f2..77e054c 100644
--- a/arch/arm/kernel/patch.h
+++ b/arch/arm/kernel/patch.h
@@ -2,6 +2,16 @@
#define _ARM_KERNEL_PATCH_H
void patch_text(void *addr, unsigned int insn);
-void __patch_text(void *addr, unsigned int
[PATCH] pci: changed '...pci_bus* bus' to '...pci_bus *bus'
change made to resolve following checkpatch message:
drivers/pci/pci.c:109: ERROR: "foo* bar" should be "foo *bar"
branch: Linux 3.14-rc8
Signed-off-by: Ryan Desfosses
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index fdbc294..a50d542 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -106,7 +106,7 @@ static bool pcie_ari_disabled;
* Given a PCI bus, returns the highest PCI bus number present in the set
* including the given PCI bus and its list of child PCI buses.
*/
-unsigned char pci_bus_max_busnr(struct pci_bus* bus)
+unsigned char pci_bus_max_busnr(struct pci_bus *bus)
{
struct list_head *tmp;
unsigned char max, n;
--
1.9.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/
Re: [PATCH 1/1] staging: comedi: Fix checkpatch warning
On Fri, Apr 04, 2014 at 09:15:39PM +0200, Camille Begue wrote:
> This patch is part of eudyptula challenge
>
The changelog should mention something about lines over 80 characte
long.
> Signed-off-by: Camille Begue
> ---
> drivers/staging/comedi/comedi_fops.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/comedi/comedi_fops.c
> b/drivers/staging/comedi/comedi_fops.c
> index ea6dc36..0f05e87 100644
> --- a/drivers/staging/comedi/comedi_fops.c
> +++ b/drivers/staging/comedi/comedi_fops.c
> @@ -1435,13 +1435,16 @@ static int __comedi_get_user_cmd(struct comedi_device
> *dev,
> s = >subdevices[cmd->subdev];
>
> if (s->type == COMEDI_SUBD_UNUSED) {
> - dev_dbg(dev->class_dev, "%d not valid subdevice\n",
> cmd->subdev);
> + dev_dbg(dev->class_dev,
> + "%d not valid subdevice\n",
> + cmd->subdev);
Do this instead:
dev_dbg(dev->class_dev, "%d not valid subdevice\n",
cmd->subdev);
> return -EIO;
> }
>
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] readq/writeq: Add explicit lo_hi_[read|write]_q and hi_lo_[read|write]_q
Even on x86-64, I've found the need to break up a readq() into 2 readl()
calls. According to the Intel datasheet for the E3-1200 processor:
"
Software must not access B0/D0/F0 32-bit memory-mapped registers with
requests that cross a DW boundary.
"
(http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html
p. 16)
I can confirm this is true via several hard machine lockups.
Thus, add explicit hi_lo_[readq|write]_q and lo_hi_[read|write]_q so that these
uses are spelled out.
Signed-off-by: Jason Baron
---
include/asm-generic/io-64-nonatomic-hi-lo.h | 14 +-
include/asm-generic/io-64-nonatomic-lo-hi.h | 14 +-
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/asm-generic/io-64-nonatomic-hi-lo.h
b/include/asm-generic/io-64-nonatomic-hi-lo.h
index a6806a9..2e29d13 100644
--- a/include/asm-generic/io-64-nonatomic-hi-lo.h
+++ b/include/asm-generic/io-64-nonatomic-hi-lo.h
@@ -4,8 +4,7 @@
#include
#include
-#ifndef readq
-static inline __u64 readq(const volatile void __iomem *addr)
+static inline __u64 hi_lo_readq(const volatile void __iomem *addr)
{
const volatile u32 __iomem *p = addr;
u32 low, high;
@@ -15,14 +14,19 @@ static inline __u64 readq(const volatile void __iomem *addr)
return low + ((u64)high << 32);
}
-#endif
-#ifndef writeq
-static inline void writeq(__u64 val, volatile void __iomem *addr)
+static inline void hi_lo_writeq(__u64 val, volatile void __iomem *addr)
{
writel(val >> 32, addr + 4);
writel(val, addr);
}
+
+#ifndef readq
+#define readq hi_lo_readq
+#endif
+
+#ifndef writeq
+#define writeq hi_lo_writeq
#endif
#endif /* _ASM_IO_64_NONATOMIC_HI_LO_H_ */
diff --git a/include/asm-generic/io-64-nonatomic-lo-hi.h
b/include/asm-generic/io-64-nonatomic-lo-hi.h
index ca546b1..0efacff 100644
--- a/include/asm-generic/io-64-nonatomic-lo-hi.h
+++ b/include/asm-generic/io-64-nonatomic-lo-hi.h
@@ -4,8 +4,7 @@
#include
#include
-#ifndef readq
-static inline __u64 readq(const volatile void __iomem *addr)
+static inline __u64 lo_hi_readq(const volatile void __iomem *addr)
{
const volatile u32 __iomem *p = addr;
u32 low, high;
@@ -15,14 +14,19 @@ static inline __u64 readq(const volatile void __iomem *addr)
return low + ((u64)high << 32);
}
-#endif
-#ifndef writeq
-static inline void writeq(__u64 val, volatile void __iomem *addr)
+static inline void lo_hi_writeq(__u64 val, volatile void __iomem *addr)
{
writel(val, addr);
writel(val >> 32, addr + 4);
}
+
+#ifndef readq
+#define readq lo_hi_readq
+#endif
+
+#ifndef writeq
+#define writeq lo_hi_writeq
#endif
#endif /* _ASM_IO_64_NONATOMIC_LO_HI_H_ */
--
1.8.2.rc2
--
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: btrfs: lock inversion between delayed_node->mutex and found->groups_sem
On 03/26/2014 01:01 PM, Jeff Mahoney wrote: > On 3/17/14, 9:05 AM, David Sterba wrote: >>> On Fri, Mar 14, 2014 at 08:12:16PM -0400, Sasha Levin wrote: > While fuzzing with trinity inside a KVM tools guest running the latest > -next kernel I've stumbled on the following: > > [ 788.458756]CPU0CPU1 [ 788.459188] > [ 788.459625] lock(>groups_sem); [ > 788.460041] local_irq_disable(); [ 788.460041] > lock(_node->mutex); [ 788.460041] lock(>groups_sem); [ > 788.460041][ 788.460041] lock(_node->mutex); [ > 788.460041] [ 788.460041] *** DEADLOCK *** [ 788.460041] [ > 788.460041] 2 locks held by kswapd3/4199: >>> >>> I've once (3.14-rc5) seen the same warning also caused by >>> xfstests/generic/224 > I think this is from my sysfs patches. We call kobject_add while holding the > group_sem. kobject_add ultimately allocates with GFP_KERNEL, so it can enter > reclaim. This particular case isn't dangerous, but it could hit while > hot-adding a device. The fix should be pretty simple. Is that fix available anywhere? I'm still seeing the issue in -next. Thanks, Sasha -- 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 3/3] ie31200_edac: Add driver
Add 'ie31200_edac' driver for the E3-1200 series of Intel processors. Driver is based on the following E3-1200 specs: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v3-vol-2-datasheet.html I've tested this on bad memory hardware, and observed correlating bad reads and uncorrected memory errors as reported by the driver. Signed-off-by: Jason Baron --- drivers/edac/Kconfig| 7 + drivers/edac/Makefile | 1 + drivers/edac/ie31200_edac.c | 540 3 files changed, 548 insertions(+) create mode 100644 drivers/edac/ie31200_edac.c diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index 878f090..27f44a1 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -186,6 +186,13 @@ config EDAC_I3200 Support for error detection and correction on the Intel 3200 and 3210 server chipsets. +config EDAC_IE31200 + tristate "Intel e312xx" + depends on EDAC_MM_EDAC && PCI && X86 + help + Support for error detection and correction on the Intel + E3-1200 processor. + config EDAC_X38 tristate "Intel X38" depends on EDAC_MM_EDAC && PCI && X86 diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index 4154ed6..c479a24 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -37,6 +37,7 @@ obj-$(CONFIG_EDAC_I82875P)+= i82875p_edac.o obj-$(CONFIG_EDAC_I82975X) += i82975x_edac.o obj-$(CONFIG_EDAC_I3000) += i3000_edac.o obj-$(CONFIG_EDAC_I3200) += i3200_edac.o +obj-$(CONFIG_EDAC_IE31200) += ie31200_edac.o obj-$(CONFIG_EDAC_X38) += x38_edac.o obj-$(CONFIG_EDAC_I82860) += i82860_edac.o obj-$(CONFIG_EDAC_R82600) += r82600_edac.o diff --git a/drivers/edac/ie31200_edac.c b/drivers/edac/ie31200_edac.c new file mode 100644 index 000..ae03d21 --- /dev/null +++ b/drivers/edac/ie31200_edac.c @@ -0,0 +1,540 @@ +/* + * Intel E3-1200 + * Copyright (C) 2014 Jason Baron + * + * Support for the E3-1200 processor family. Heavily based on previous + * Intel EDAC drivers. + * + * Since the DRAM controller is on the cpu chip, we can use its PCI device + * id to identify these processors. + * + * PCI DRAM controller device ids (Taken from The PCI ID Repository - http://pci-ids.ucw.cz/) + * + * 0108: Xeon E3-1200 Processor Family DRAM Controller + * 010c: Xeon E3-1200/2nd Generation Core Processor Family DRAM Controller + * 0150: Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller + * 0158: Xeon E3-1200 v2/Ivy Bridge DRAM Controller + * 015c: Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller + * 0c04: Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller + * 0c08: Xeon E3-1200 v3 Processor DRAM Controller + * + * Based on Intel specification: + * http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-2-datasheet.pdf + * http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html + * + * According to the above datasheet (p.16): + * " + * 6. Software must not access B0/D0/F0 32-bit memory-mapped registers with + * requests that cross a DW boundary. + * " + * + * Thus, we make use of the explicit: lo_hi_readq(), which breaks the readq into + * 2 readl() calls. This restriction may be lifted in subsequent chip releases, + * but lo_hi_readq() ensures that we are safe across all e3-1200 processors. + * + */ + +#include +#include +#include +#include +#include + +#include +#include "edac_core.h" + +#define IE31200_REVISION "1.0" +#define EDAC_MOD_STR "ie31200_edac" + +#define PCI_DEVICE_ID_INTEL_IE31200_HB_1 0x0108 +#define PCI_DEVICE_ID_INTEL_IE31200_HB_2 0x010c +#define PCI_DEVICE_ID_INTEL_IE31200_HB_3 0x0150 +#define PCI_DEVICE_ID_INTEL_IE31200_HB_4 0x0158 +#define PCI_DEVICE_ID_INTEL_IE31200_HB_5 0x015c +#define PCI_DEVICE_ID_INTEL_IE31200_HB_6 0x0c04 +#define PCI_DEVICE_ID_INTEL_IE31200_HB_7 0x0c08 + +#define IE31200_DIMMS 4 +#define IE31200_RANKS 8 +#define IE31200_RANKS_PER_CHANNEL 4 +#define IE31200_DIMMS_PER_CHANNEL 2 +#define IE31200_CHANNELS 2 + +/* Intel IE31200 register addresses - device 0 function 0 - DRAM Controller */ +#define IE31200_MCHBAR_LOW 0x48 +#define IE31200_MCHBAR_HIGH0x4c +#define IE31200_MCHBAR_MASK0xff8000ULL /* bits 38:15 */ +#define IE31200_MMR_WINDOW_SIZE32768 + +/* Error Status Register (16b) + * + * 15reserved + * 14Isochronous TBWRR Run Behind FIFO Full + * (ITCV) + * 13Isochronous TBWRR Run Behind FIFO Put + * (ITSTV) + * 12reserved + * 11MCH Thermal Sensor Event + * for SMI/SCI/SERR (GTSE) + * 10reserved + * 9LOCK to non-DRAM Memory Flag (LCKF) + * 8reserved + * 7DRAM Throttle Flag (DTF) + * 6:2 reserved + *
[PATCH 2/3] x38_edac: make use of lo_hi_readq()
Convert to the generic API.
Signed-off-by: Jason Baron
---
drivers/edac/x38_edac.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/x38_edac.c b/drivers/edac/x38_edac.c
index 4891b45..e644b52 100644
--- a/drivers/edac/x38_edac.c
+++ b/drivers/edac/x38_edac.c
@@ -14,6 +14,8 @@
#include
#include
#include
+
+#include
#include "edac_core.h"
#define X38_REVISION "1.1"
@@ -161,11 +163,6 @@ static void x38_clear_error_info(struct mem_ctl_info *mci)
X38_ERRSTS_BITS);
}
-static u64 x38_readq(const void __iomem *addr)
-{
- return readl(addr) | (((u64)readl(addr + 4)) << 32);
-}
-
static void x38_get_and_clear_error_info(struct mem_ctl_info *mci,
struct x38_error_info *info)
{
@@ -183,9 +180,9 @@ static void x38_get_and_clear_error_info(struct
mem_ctl_info *mci,
if (!(info->errsts & X38_ERRSTS_BITS))
return;
- info->eccerrlog[0] = x38_readq(window + X38_C0ECCERRLOG);
+ info->eccerrlog[0] = lo_hi_readq(window + X38_C0ECCERRLOG);
if (x38_channel_num == 2)
- info->eccerrlog[1] = x38_readq(window + X38_C1ECCERRLOG);
+ info->eccerrlog[1] = lo_hi_readq(window + X38_C1ECCERRLOG);
pci_read_config_word(pdev, X38_ERRSTS, >errsts2);
@@ -196,10 +193,10 @@ static void x38_get_and_clear_error_info(struct
mem_ctl_info *mci,
* should be UE info.
*/
if ((info->errsts ^ info->errsts2) & X38_ERRSTS_BITS) {
- info->eccerrlog[0] = x38_readq(window + X38_C0ECCERRLOG);
+ info->eccerrlog[0] = lo_hi_readq(window + X38_C0ECCERRLOG);
if (x38_channel_num == 2)
info->eccerrlog[1] =
- x38_readq(window + X38_C1ECCERRLOG);
+ lo_hi_readq(window + X38_C1ECCERRLOG);
}
x38_clear_error_info(mci);
--
1.8.2.rc2
--
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 0/3] Add new ie31200_edac driver
Hi, Add support for memory errors for the Intel E3-1200 processors. While testing the driver, I found that doing a readq() on the memory mapped memory controller hub registers caused a hard lockup on my x86_64 system. It turns out that a read across a DW boundary is a no no here. " Software must not access B0/D0/F0 32-bit memory-mapped registers with requests that cross a DW boundary. " (http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html p. 16) Thus, I've added a generic lo_hi_[read|write]_q API, to deal with this issue. I think longer term the right thing is maybe to simply add these definitions to include/asm-generic/io.h, as I didn't see any in tree users of 'io-64-nonatomic-hi-lo.h', and simply remove io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h. But I didn't want to tie that cleanup to this edac driver submission. Thanks, -Jason Jason Baron (3): readq/writeq: Add explicit lo_hi_[read|write]_q and hi_lo_[read|write]_q x38_edac: make use of lo_hi_readq() ie31200_edac: Add driver drivers/edac/Kconfig| 7 + drivers/edac/Makefile | 1 + drivers/edac/ie31200_edac.c | 540 drivers/edac/x38_edac.c | 15 +- include/asm-generic/io-64-nonatomic-hi-lo.h | 14 +- include/asm-generic/io-64-nonatomic-lo-hi.h | 14 +- 6 files changed, 572 insertions(+), 19 deletions(-) create mode 100644 drivers/edac/ie31200_edac.c -- 1.8.2.rc2 -- 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 v4 1/1] staging: comedi: Fix checkpatch warning
Wrap lines > 80 columns.
Signed-off-by: Camille Begue
---
drivers/staging/comedi/comedi_fops.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index ea6dc36..252505b 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -1435,13 +1435,14 @@ static int __comedi_get_user_cmd(struct comedi_device
*dev,
s = >subdevices[cmd->subdev];
if (s->type == COMEDI_SUBD_UNUSED) {
- dev_dbg(dev->class_dev, "%d not valid subdevice\n",
cmd->subdev);
+ dev_dbg(dev->class_dev, "%d not valid subdevice\n",
+ cmd->subdev);
return -EIO;
}
if (!s->do_cmd || !s->do_cmdtest || !s->async) {
- dev_dbg(dev->class_dev,
- "subdevice %d does not support commands\n",
cmd->subdev);
+ dev_dbg(dev->class_dev, "subdevice %d does not support
commands\n",
+ cmd->subdev);
return -EIO;
}
--
1.9.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/
