Re: [PATCH 02/10] merge_config.sh: print warnings on stderr
On Wed, Oct 28, 2015 at 09:42:03AM +0900, Olof Johansson wrote: > Makes it easier to grab just errors/warnings in a build log. > > Signed-off-by: Olof Johansson I think this is the right change, I just want to make sure Bruce (Cc'd) sees it for linux-yocto. Reviewed-by: Darren Hart > --- > scripts/kconfig/merge_config.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh > index d8cd913..0e98619 100755 > --- a/scripts/kconfig/merge_config.sh > +++ b/scripts/kconfig/merge_config.sh > @@ -131,7 +131,7 @@ for MERGE_FILE in $MERGE_LIST ; do > echo Value of $CFG is redundant by fragment $MERGE_FILE: > fi > sed -i "/$CFG[ =]/d" $TMP_FILE > - done > + done >&2 > cat $MERGE_FILE >> $TMP_FILE > done > > @@ -168,7 +168,7 @@ for CFG in $(sed -n "$SED_CONFIG_EXP" $TMP_FILE); do > echo "Requested value: $REQUESTED_VAL" > echo "Actual value: $ACTUAL_VAL" > echo "" > - fi > + fi >&2 > done > > clean_up > -- > 2.1.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/ > -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Staging: android: uapi: fixed comment block coding style error in ion.h
On Tue, Oct 27, 2015 at 02:04:54PM +0200, Dzonatans Melgalvis wrote:
> Fixed checkpatch.pl warning about comment block coding style.
>
> Signed-off-by: Dzonatans Melgalvis '.
This change has already been done by:
7e4161747bc6 ("staging: android: Fix checkpatch block comments warnings")
which tree you are using?
regards
sudip
--
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/3] virtio_ring: Support DMA APIs
Am 28.10.2015 um 14:30 schrieb Andy Lutomirski:
> +static void vring_unmap_one(const struct vring_virtqueue *vq,
> + struct vring_desc *desc)
> +{
> + u16 flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
> +
> + if (flags & VRING_DESC_F_INDIRECT) {
> + dma_unmap_single(vring_dma_dev(vq),
> + virtio64_to_cpu(vq->vq.vdev, desc->addr),
> + virtio32_to_cpu(vq->vq.vdev, desc->len),
> + (flags & VRING_DESC_F_WRITE) ?
> + DMA_FROM_DEVICE : DMA_TO_DEVICE);
> + } else {
> + dma_unmap_page(vring_dma_dev(vq),
> +virtio64_to_cpu(vq->vq.vdev, desc->addr),
> +virtio32_to_cpu(vq->vq.vdev, desc->len),
> +(flags & VRING_DESC_F_WRITE) ?
> +DMA_FROM_DEVICE : DMA_TO_DEVICE);
> + }
> +}
> +
I still have a failure in this:
[1.913040] Unable to handle kernel pointer dereference in virtual kernel
address space
[1.913044] failing address: 0c80 TEID: 0c800803
[1.913045] Fault in home space mode while using kernel ASCE.
[1.913048] AS:00d56007 R3:0c7f0007 S:0020
[1.913099] Oops: 0010 ilc:2 [#1] SMP
[1.913142] Modules linked in:
[1.913144] CPU: 4 PID: 50 Comm: kworker/u18:1 Not tainted 4.3.0-rc3+ #252
[1.913150] Workqueue: events_unbound call_usermodehelper_exec_work
[1.913152] task: 0bb8b310 ti: 0bba8000 task.ti:
0bba8000
[1.913154] Krnl PSW : 0404e0018000 0059b266
(vring_unmap_one+0x46/0x8d0)
[1.913158]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0
EA:3
Krnl GPRS: 0c80 0c036800 0c80
[1.913161]005a21a8
[1.913162]0704c0018000 04000bdbfce8 0c082000
0bdbf6e8
[1.913164]0400 0bdbf988
0bdbf6e8
[1.913170] Krnl Code: 0059b254: e310b0a80004lg
%r1,168(%r11)
0059b25a: e3201024 lg %r2,32(%r1)
#0059b260: e310b0a4 lg %r1,160(%r11)
>0059b266: 4810100c lh %r1,12(%r1)
0059b26a: e320b2a80024 stg %r2,680(%r11)
0059b270: 4010b2a6 sth %r1,678(%r11)
0059b274: e310b2a80004 lg %r1,680(%r11)
0059b27a: e310b2980024 stg %r1,664(%r11)
[1.913183] Call Trace:
[1.913185] ([<0059b74c>] vring_unmap_one+0x52c/0x8d0)
[1.913187] [<005a21a8>] detach_buf+0x720/0x788
[1.913188] [<005a2830>] virtqueue_get_buf+0x620/0x908
[1.913191] [<005e5336>] virtblk_done+0xa6/0x120
[1.913192] [<005a3e46>] vring_interrupt+0x2a6/0x2c0
[1.913224] [<006c9bdc>] virtio_airq_handler+0x7c/0x120
[1.913226] [<0065f88c>] do_airq_interrupt+0xa4/0xc8
[1.913229] [<001b79a0>] handle_irq_event_percpu+0x60/0x1f0
[1.913230] [<001bbbea>] handle_percpu_irq+0x72/0xa0
[1.913232] [<001b6fa4>] generic_handle_irq+0x4c/0x78
[1.913234] [<0010cc7c>] do_IRQ+0x64/0x88
[1.913236] [<00815d42>] io_int_handler+0x10a/0x218
[1.913238] [<00104268>] copy_thread+0x78/0x1a0
[1.913240] ([<001548f8>] copy_process.isra.11+0x750/0x1a80)
[1.913242] [<00156122>] _do_fork+0x9a/0x338
[1.913243] [<0015644e>] kernel_thread+0x4e/0x60
[1.913245] [<0016da7a>] call_usermodehelper_exec_work+0x7a/0xf0
[1.913247] [<00171c06>] process_one_work+0x1b6/0x490
[1.913248] [<00171f38>] worker_thread+0x58/0x588
[1.913250] [<001788fa>] kthread+0x10a/0x110
[1.913252] [<00815a8e>] kernel_thread_starter+0x6/0xc
[1.913254] [<00815a88>] kernel_thread_starter+0x0/0xc
[1.913255] Last Breaking-Event-Address:
[1.913256] [<005a21a2>] detach_buf+0x71a/0x788
[1.913258]
[1.913263] Kernel panic - not syncing: Fatal exception in interrupt
--
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] Input: tsc2005 - Add support for tsc2004
On Tue, Oct 27, 2015 at 10:41:52PM -0700, Dmitry Torokhov wrote: > On Wed, Oct 28, 2015 at 12:23:34AM -0500, Michael Welling wrote: > > On Tue, Oct 27, 2015 at 06:51:41PM -0700, Dmitry Torokhov wrote: > > > Hi Michael, > > > On Tue, Oct 27, 2015 at 07:17:01PM -0500, Michael Welling wrote: > > > > Adds support for the i2c based tsc2004. Support was added to the > > > > tsc2005 driver > > > > due to the similarity of the devices. > > > > > > > > Signed-off-by: Michael Welling > > > > --- > > > > v2: Fixes Kconfig based on report for 0-day build bot. > > > > > > > > .../bindings/input/touchscreen/tsc2004.txt | 38 > > > > drivers/input/touchscreen/Kconfig | 7 +- > > > > drivers/input/touchscreen/tsc2005.c| 206 > > > > - > > > > > > Could we maybe split the code into core, spi and i2c drivers instead of > > > keeping everything together and rely on #ifdefs? > > > > > Dmitry, > > > > So then we have three files? > > Perhaps: > > drivers/input/touchscreen/tsc2004.c > > drivers/input/touchscreen/tsc2005.c > > drivers/input/touchscreen/tsc200x-core.c > > > > Please ellaborate exactly how you want things to be structured and named so > > that I don't waste time in revision. > > Sure, the naming above is fine. You'd have to export the > tsc_common_probe() and put I2C and SPI bits into tsc2005.c/tsc2004.c > > I'd probably have separate Kconfig entries for TSC2004 and TSC2005 and > have the core be invisible module that the former 2 explicitly "select". > > Does this make sense? Yes it does. I have been told that using wildcard names is bad in other subsystems. Perhaps tsc200x-core.c should be called something else because it has nothing to do with the tsc2007 but it is covered by the wildcard. You you think this is a big deal? > > Thanks. > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[lkp] [sched/fair] 1746babbb1: +2.3% unixbench.score
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 1746babbb15594ba2d8d8196589bbbc2b5ff51c9 ("sched/fair: Have
task_move_group_fair() also detach entity load from the old runqueue")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/test:
lituya/unixbench/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/shell8
commit:
50a2a3b246149d041065a67ccb3e98145f780a2f
1746babbb15594ba2d8d8196589bbbc2b5ff51c9
50a2a3b246149d04 1746babbb15594ba2d8d819658
--
%stddev %change %stddev
\ |\
25166 ± 0% +2.3% 25756 ± 0% unixbench.score
9026404 ± 0% +3.9%9376242 ± 0%
unixbench.time.involuntary_context_switches
4.683e+08 ± 0% +1.8% 4.765e+08 ± 0% unixbench.time.minor_page_faults
949.00 ± 0% +3.0% 977.25 ± 0%
unixbench.time.percent_of_cpu_this_job_got
2286 ± 0% +2.8% 2349 ± 0% unixbench.time.system_time
1305 ± 0% +3.3% 1348 ± 0% unixbench.time.user_time
31346 ± 8% -10.7% 27987 ± 1% cpuidle.POLL.time
2679 ± 8%+179.4% 7486 ± 40%
latency_stats.max.wait_on_page_bit.filemap_fdatawait_range.filemap_fdatawait.sync_inodes_sb.sync_inodes_one_sb.iterate_supers.sys_sync.entry_SYSCALL_64_fastpath
107334 ± 22%+251.7% 377450 ± 37%
latency_stats.sum.walk_component.path_lookupat.filename_lookup.user_path_at_empty.vfs_fstatat.SYSC_newstat.SyS_newstat.entry_SYSCALL_64_fastpath
979.25 ± 1% +17.5% 1150 ± 2% slabinfo.files_cache.active_objs
979.25 ± 1% +17.5% 1150 ± 2% slabinfo.files_cache.num_objs
33.25 ± 1% +14.3% 38.00 ± 0% vmstat.procs.r
25287 ± 0% +5.2% 26600 ± 0% vmstat.system.in
61.09 ± 0% +2.9% 62.85 ± 0% turbostat.%Busy
2011 ± 0% +2.9% 2069 ± 0% turbostat.Avg_MHz
2.58 ± 2% -10.4% 2.32 ± 4% turbostat.CPU%c3
1.16 ± 28% +30.9% 1.52 ± 0% turbostat.RAMWatt
1363139 ± 2%+390.2%6682436 ± 5%
sched_debug.cfs_rq[0]:/.min_vruntime
508.25 ± 35% -30.8% 351.50 ± 8%
sched_debug.cfs_rq[0]:/.tg_load_avg_contrib
1483779 ± 3%+248.1%5164998 ± 0%
sched_debug.cfs_rq[10]:/.min_vruntime
120613 ± 52% -1358.2% -1517619 ±-26% sched_debug.cfs_rq[10]:/.spread0
1481440 ± 3%+243.7%5092246 ± 2%
sched_debug.cfs_rq[11]:/.min_vruntime
118271 ± 54% -1444.7% -1590395 ±-26% sched_debug.cfs_rq[11]:/.spread0
1455329 ± 0%+252.8%5133998 ± 1%
sched_debug.cfs_rq[12]:/.min_vruntime
92159 ± 30% -1780.4% -1548645 ±-27% sched_debug.cfs_rq[12]:/.spread0
536.00 ± 18% -24.9% 402.50 ± 18% sched_debug.cfs_rq[13]:/.load_avg
1451734 ± 0%+254.5%5146739 ± 0%
sched_debug.cfs_rq[13]:/.min_vruntime
88561 ± 34% -1834.3% -1535905 ±-24% sched_debug.cfs_rq[13]:/.spread0
326.25 ± 21% +73.2% 565.00 ± 20% sched_debug.cfs_rq[14]:/.load_avg
1479346 ± 3%+246.9%5132386 ± 0%
sched_debug.cfs_rq[14]:/.min_vruntime
47.67 ±141%+472.7% 273.00 ± 42%
sched_debug.cfs_rq[14]:/.removed_load_avg
46.00 ±141%+467.9% 261.25 ± 47%
sched_debug.cfs_rq[14]:/.removed_util_avg
116171 ± 55% -1434.5% -1550271 ±-25% sched_debug.cfs_rq[14]:/.spread0
777.75 ± 9% +35.8% 1056 ± 14% sched_debug.cfs_rq[14]:/.util_avg
1451847 ± 0%+252.2%5113656 ± 1%
sched_debug.cfs_rq[15]:/.min_vruntime
88669 ± 29% -1869.5% -1569030 ±-28% sched_debug.cfs_rq[15]:/.spread0
1346003 ± 0%+413.1%6906332 ± 0%
sched_debug.cfs_rq[1]:/.min_vruntime
347.50 ± 3% -10.0% 312.75 ± 4%
sched_debug.cfs_rq[1]:/.tg_load_avg_contrib
1362040 ± 2%+408.4%6924492 ± 0%
sched_debug.cfs_rq[2]:/.min_vruntime
1363305 ± 2%+394.7%6744667 ± 4%
sched_debug.cfs_rq[3]:/.min_vruntime
1.50 ±100%+400.0% 7.50 ± 22%
sched_debug.cfs_rq[3]:/.nr_spread_over
1346931 ± 0%+398.4%6712511 ± 5%
sched_debug.cfs_rq[4]:/.min_vruntime
1345064 ± 0%+416.2%6942624 ± 0%
sched_debug.cfs_rq[5]:/.min_vruntime
36.00 ± 9% -36.1% 23.00 ± 21%
sched_debug.cfs_rq[5]:/.runnable_load_avg
-18089 ±-155% -1537.8% 260083 ±142% sched_debug.cfs_rq[5]:/.spread0
1362865 ± 2%+405.4%6887733 ± 0%
sched_debug.cfs_rq[6]:/.min_vruntime
1343531 ± 0%+397.9%6689576 ± 5%
sched_debug.cfs_rq[7]:/.min_vruntime
45.75 ± 22% -51.9% 22.00 ± 50% sched_debug.cfs_rq[8]:/.load
1479661 ± 3%+246.4%5125934 ± 0%
sched_debug.cfs_rq[8]:/.min_vruntime
116500 ± 18% -1436.2% -1556673 ±-22% sched_debug.cfs_rq[8]:/.spread0
37.50 ±
Re: [PATCH v2] Input: tsc2005 - Add support for tsc2004
On Wed, Oct 28, 2015 at 12:38:31AM -0500, Michael Welling wrote: > On Wed, Oct 28, 2015 at 12:37:35PM +0800, kbuild test robot wrote: > > Hi Michael, > > > > [auto build test ERROR on input/next -- if it's inappropriate base, please > > suggest rules for selecting the more suitable base] > > > > url: > > https://github.com/0day-ci/linux/commits/Michael-Welling/Input-tsc2005-Add-support-for-tsc2004/20151028-082017 > > config: x86_64-randconfig-s1-10281141 (attached as .config) > > reproduce: > > # save the attached .config to linux build tree > > make ARCH=x86_64 > > > > All errors (new ones prefixed by >>): > > > >drivers/built-in.o: In function `tsc2005_cmd': > >tsc2005.c:(.text+0x21a352): undefined reference to `i2c_smbus_write_byte' > >drivers/built-in.o: In function `tsc200x_probe_common': > > >> tsc2005.c:(.text+0x21b554): undefined reference to > > >> `__devm_regmap_init_i2c' > >drivers/built-in.o: In function `tsc2005_modinit': > >tsc2005.c:(.init.text+0xe2b2): undefined reference to > > `i2c_register_driver' > >drivers/built-in.o: In function `tsc2005_exit': > >tsc2005.c:(.exit.text+0xf4c): undefined reference to `i2c_del_driver' > > > > Sorry Mr. Robot but this configuration does not make sense. > > How is CONFIG_REGMAP_I2C=m set without CONFIG_I2C being selected? > CONFIG_REGMAP_I2C depends on CONFIG_I2C. The call to devm_regmap_init_i2c() in tsc200x_probe_common() is not protected by #ifdef guard and we do not have stub for it in case of !CONFIG_I2C. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[lkp] [x86/setup] f5f3497cad: BUG: kernel boot crashed
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit f5f3497cad8c8416a74b9aaceb127908755d020a ("x86/setup: Extend low
identity map to cover whole kernel range")
++++
|| 8a53554e12 | f5f3497cad |
++++
| boot_successes | 19 | 10 |
| boot_failures | 2 | 9 |
| IP-Config:Auto-configuration_of_network_failed | 2 | 2 |
| BUG:kernel_boot_crashed| 0 | 7 |
++++
[0.053410] smpboot: CPU0: GenuineIntel GenuineIntel QEMU Virtual CPU
version 2.4.0QEMU Virtual CPU version 2.4.0 (family: 0x6, model: 0x6 (family:
0x6, model: 0x6, stepping: 0x3)
, stepping: 0x3)
[0.05] Performance Events:
[0.05] Performance Events: no PMU driver, software events only.
no PMU driver, software events only.
[0.060520] CPU 1 irqstacks, hard=8a832000 soft=8a834000
[0.060520] CPU 1 irqstacks, hard=8a832000 soft=8a834000
[0.061605] x86: Booting SMP configuration:
[0.061605] x86: Booting SMP configuration:
[0.062445] node #0, CPUs:
[0.062445] node #0, CPUs: #1 #1
Elapsed time: 10
BUG: kernel boot crashed
qemu-system-i386 -enable-kvm -kernel
/pkg/linux/i386-randconfig-i1-201543/gcc-4.9/f5f3497cad8c8416a74b9aaceb127908755d020a/vmlinuz-4.3.0-rc5-00039-gf5f3497
-append 'root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-kbuild-yocto-i386-64/bisect_boot-1-yocto-minimal-i386.cgz-i386-randconfig-i1-201543-f5f3497cad8c8416a74b9aaceb127908755d020a-20151028-63408-uxh2ow-0.yaml
ARCH=i386 kconfig=i386-randconfig-i1-201543 branch=linus/master
commit=f5f3497cad8c8416a74b9aaceb127908755d020a
BOOT_IMAGE=/pkg/linux/i386-randconfig-i1-201543/gcc-4.9/f5f3497cad8c8416a74b9aaceb127908755d020a/vmlinuz-4.3.0-rc5-00039-gf5f3497
max_uptime=600
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-i386/yocto-minimal-i386.cgz/i386-randconfig-i1-201543/gcc-4.9/f5f3497cad8c8416a74b9aaceb127908755d020a/0
LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw
ip=vm-kbuild-yocto-i386-64::dhcp drbd.minor_count=8' -initrd
/fs/sdh1/initrd-vm-kbuild-yocto-i386-64 -m 320 -smp 2 -device e1000,netdev=net0
-netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc
base=localtime -drive
file=/fs/sdh1/disk0-vm-kbuild-yocto-i386-64,media=disk,if=virtio -pidfile
/dev/shm/kboot/pid-vm-kbuild-yocto-i386-64 -serial
file:/dev/shm/kboot/serial-vm-kbuild-yocto-i386-64 -daemonize -display none
-monitor null
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.3.0-rc5 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
#
Re: [PATCH v2] Input: tsc2005 - Add support for tsc2004
On Wed, Oct 28, 2015 at 12:23:34AM -0500, Michael Welling wrote: > On Tue, Oct 27, 2015 at 06:51:41PM -0700, Dmitry Torokhov wrote: > > Hi Michael, > > On Tue, Oct 27, 2015 at 07:17:01PM -0500, Michael Welling wrote: > > > Adds support for the i2c based tsc2004. Support was added to the tsc2005 > > > driver > > > due to the similarity of the devices. > > > > > > Signed-off-by: Michael Welling > > > --- > > > v2: Fixes Kconfig based on report for 0-day build bot. > > > > > > .../bindings/input/touchscreen/tsc2004.txt | 38 > > > drivers/input/touchscreen/Kconfig | 7 +- > > > drivers/input/touchscreen/tsc2005.c| 206 > > > - > > > > Could we maybe split the code into core, spi and i2c drivers instead of > > keeping everything together and rely on #ifdefs? > > > Dmitry, > > So then we have three files? > Perhaps: > drivers/input/touchscreen/tsc2004.c > drivers/input/touchscreen/tsc2005.c > drivers/input/touchscreen/tsc200x-core.c > > Please ellaborate exactly how you want things to be structured and named so > that I don't waste time in revision. Sure, the naming above is fine. You'd have to export the tsc_common_probe() and put I2C and SPI bits into tsc2005.c/tsc2004.c I'd probably have separate Kconfig entries for TSC2004 and TSC2005 and have the core be invisible module that the former 2 explicitly "select". Does this make sense? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers:staging:wlan_ng Fix no space is necessary after a cast
On Tue, Oct 27, 2015 at 11:26:48PM +0100, Bogicevic Sasa wrote: > It should be fine, I meant in a sence nothing is accepted from me yet It doesnot generate any warning in my setup. And please donot top post while replying. regards sudip -- 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] Input: tsc2005 - Add support for tsc2004
On Wed, Oct 28, 2015 at 12:37:35PM +0800, kbuild test robot wrote: > Hi Michael, > > [auto build test ERROR on input/next -- if it's inappropriate base, please > suggest rules for selecting the more suitable base] > > url: > https://github.com/0day-ci/linux/commits/Michael-Welling/Input-tsc2005-Add-support-for-tsc2004/20151028-082017 > config: x86_64-randconfig-s1-10281141 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/built-in.o: In function `tsc2005_cmd': >tsc2005.c:(.text+0x21a352): undefined reference to `i2c_smbus_write_byte' >drivers/built-in.o: In function `tsc200x_probe_common': > >> tsc2005.c:(.text+0x21b554): undefined reference to `__devm_regmap_init_i2c' >drivers/built-in.o: In function `tsc2005_modinit': >tsc2005.c:(.init.text+0xe2b2): undefined reference to `i2c_register_driver' >drivers/built-in.o: In function `tsc2005_exit': >tsc2005.c:(.exit.text+0xf4c): undefined reference to `i2c_del_driver' > Sorry Mr. Robot but this configuration does not make sense. How is CONFIG_REGMAP_I2C=m set without CONFIG_I2C being selected? CONFIG_REGMAP_I2C depends on CONFIG_I2C. > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] clk: s2mps15: Add support for S2MPS15 clocks
On 28.10.2015 13:55, Alim Akhtar wrote:
>
>
> On 10/28/2015 10:04 AM, Krzysztof Kozlowski wrote:
>> On 28.10.2015 10:26, Krzysztof Kozlowski wrote:
>>> On 26.10.2015 21:51, Alim Akhtar wrote:
S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
adds supports for the same to the s2mps11 clock driver.
Signed-off-by: Alim Akhtar
---
drivers/clk/Kconfig |5 +++--
drivers/clk/clk-s2mps11.c | 24
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a1fa61159179..037a314b5d76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ This driver supports S2MPS1X/S5M8767 crystal oscillator
clock. These multi-function devices have two (S2MPS14) or three
- (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz
each.
+ (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
+ clocked at 32KHz each.
config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d266299dfdb1..455500dca653 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,24 @@ static struct clk_init_data
s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
},
};
+static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
+[S2MPS11_CLK_AP] = {
+.name = "s2mps15_ap",
+.ops = _clk_ops,
+.flags = CLK_IS_ROOT,
+},
+[S2MPS11_CLK_CP] = {
+.name = "s2mps15_cp",
+.ops = _clk_ops,
+.flags = CLK_IS_ROOT,
+},
+[S2MPS11_CLK_BT] = {
+.name = "s2mps15_bt",
+.ops = _clk_ops,
+.flags = CLK_IS_ROOT,
+},
+};
+
static struct device_node *s2mps11_clk_parse_dt(struct
platform_device *pdev,
struct clk_init_data *clks_init)
{
@@ -207,6 +226,10 @@ static int s2mps11_clk_probe(struct
platform_device *pdev)
s2mps11_reg = S2MPS14_REG_RTCCTRL;
clks_init = s2mps14_clks_init;
break;
+case S2MPS15X:
+s2mps11_reg = S2MPS15_REG_RTC_BUF;
+clks_init = s2mps15_clks_init;
>>>
>>> Another question (after looking at RTC driver):
>>> Is this the same register address as S2MPS14?
>>
>> I found the answer - this is the same address as in S2MPS13 and S2MPS14:
>> 0xc. The S2MPS14 has only two clocks though but S2MPS13 has three.
>> Again, as in RTC, you should re-use existing support.
>>
>> It looks there is no need for this patch at all.
>>
> Yes, checked that, rtc looks same to s2mps14 and clk looks same as
> s2mps13{ not s2mps11}, because of the RTC_BUF address changes.
> Will drop patch 4 and 5 and use the existing names where applicable.
Thanks!
> I think I don't have to change the binding or Kconfig changes?
I think you don't have to. Only the main MFD driver will be updated with
respective child driver names and compatible.
Best regards,
Krzysztof
--
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/
[lkp] [mm, page_alloc] 43993977ba: +88% OOM possibility
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 43993977baecd838d66ccabc7f682342fc6ff635 ("mm, page_alloc: distinguish
between being unable to sleep, unwilling to sleep and avoiding waking kswapd")
We found the OOM possibility increased 88% in a virtual machine with 1G memory.
=
tbox_group/testcase/rootfs/kconfig/compiler/disk/fs/test:
vm-kbuild-1G/xfstests/debian-x86_64-2015-02-07.cgz/x86_64-allyesdebian/gcc-4.9/4HDD/btrfs/generic-mid
commit:
74fad8a3a917b9e0a407af8a4150c61f7b836591
43993977baecd838d66ccabc7f682342fc6ff635
74fad8a3a917b9e0 43993977baecd838d66ccabc7f
--
fail:runs %reproductionfail:runs
| | |
1:24 -4%:24xfstests.generic.192.fail
1:24 -4%:24xfstests.nr_fail
:24 88% 21:24dmesg.Mem-Info
:24 62% 15:24
dmesg.page_allocation_failure:order:#,mode
:24 88% 21:24dmesg.warn_alloc_failed+0x
:24 75% 18:24last_state.is_incomplete_run
1:24 -4%:24last_state.xfstests.exit_code.1
:24 54% 13:24last_state.xfstests.exit_code.143
:24 71% 17:24
kmsg.SLAB:Unable_to_allocate_memory_on_node#(gfp=#)
1:24 -4%:24kmsg.TDH<#>
1:24 -4%:24kmsg.TDH
1:24 -4%:24kmsg.TDT<#>
1:24 -4%:24kmsg.TDT
1:24 -4%:24kmsg.Tx_Queue<#>
1:24 -4%:24kmsg.buffer_info[next_to_clean]
1:24 -4%:24
kmsg.e1000#:#:#eth0:Detected_Tx_Unit_Hang
1:24 -4%:24kmsg.jiffies<#>
1:24 -4%:24kmsg.jiffies<#c5c>
1:24 -4%:24kmsg.next_to_clean<#>
1:24 -4%:24kmsg.next_to_clean
1:24 -4%:24kmsg.next_to_use<#>
1:24 -4%:24kmsg.next_to_use
1:24 -4%:24kmsg.next_to_watch.status<#>
1:24 -4%:24kmsg.next_to_watch<#>
1:24 -4%:24kmsg.next_to_watch
1:24 -4%:24kmsg.time_stamp<#>
1:24 -4%:24kmsg.time_stamp<#afd>
vm-kbuild-1G: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
Memory: 1G
To reproduce:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Ying Huang
---
LKP_SERVER: inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
testcase: xfstests
default-monitors:
wait: activate-monitor
kmsg:
vmstat:
interval: 10
default-watchdogs:
oom-killer:
watchdog:
cpufreq_governor:
model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
nr_vm: 16
nr_cpu: 2
memory: 1G
disk_type: virtio-scsi
rootfs: debian-x86_64-2015-02-07.cgz
hdd_partitions: "/dev/sda /dev/sdb /dev/sdc /dev/sdd"
swap_partitions: "/dev/sde"
ssh_base_port: 23000
category: functional
disk: 4HDD
fs: btrfs
xfstests:
test: generic-mid
enqueue_time: 2015-10-19 23:36:05.806413316 +08:00
branch:
linux-review/Richard-Fitzgerald/Add-support-for-Cirrus-Logic-CS47L24-and-WM1831-codecs/20151019-221754
commit: 70e25d9e15fdae345ae7499131c643db506d08e0
queue: rand
repeat_to: 2
testbox: vm-kbuild-1G-11
tbox_group: vm-kbuild-1G
kconfig: x86_64-allyesdebian
id: 64d645db367175db708ac69d321aa547a7f23900
user: lkp
compiler: gcc-4.9
kernel:
"/pkg/linux/x86_64-allyesdebian/gcc-4.9/70e25d9e15fdae345ae7499131c643db506d08e0/vmlinuz-4.3.0-rc5-next-20151016-3-g70e25d9"
result_root:
"/result/xfstests/4HDD-btrfs-generic-mid/vm-kbuild-1G/debian-x86_64-2015-02-07.cgz/x86_64-allyesdebian/gcc-4.9/70e25d9e15fdae345ae7499131c643db506d08e0/0"
job_file:
"/lkp/scheduled/vm-kbuild-1G-11/rand_xfstests-4HDD-btrfs-generic-mid-debian-x86_64.cgz-x86_64-allyesdebian-70e25d9e15fdae345ae7499131c643db506d08e0-20151019-128924-ut9rnp-0.yaml"
dequeue_time: 2015-10-20 00:24:58.505681006 +08:00
max_uptime: 3600
initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
-
Re: [PATCH V2 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc
Hi Denis, On Monday 26 October 2015 06:47 PM, Denis Kirjanov wrote: On 10/26/15, Anju T wrote: This short patch series add the ability to sample the interrupted machine state for each hardware sample Hi, how can we check your patch series without testing details? I have mentioned about the commands to test this feature in the 3rd patch of this series,but not detailed. To test this patch, Eg: $perf record -I ls // record machine state at interrupt $perf script -D //read the perf.data file Sample output obtained for this patch / output looks like as follows: 179614739048 0xb90 [0x190]: PERF_RECORD_SAMPLE(IP, 0x1): 4130/4130: 0xc01dde88 period: 1 addr: 0 ... intr regs: mask 0xfff ABI 64-bit gpr0 0xc01e6974 gpr1 0xc01e48ad79a0 gpr2 0xc1523400 gpr3 0x1 gpr4 0xc00fd7c76600 gpr5 0x29d1df51d8 gpr6 0x1e00 gpr7 0x0 gpr8 0x0 gpr9 0x0 gpr10 0x1 gpr11 0x0 gpr12 0x24022822 gpr13 0xcfee4c80 gpr14 0x0 gpr15 0xc000fcab3800 gpr16 0x0 gpr17 0xc00ffa445000 gpr18 0xc01e48ad78a0 gpr19 0xc1523400 gpr20 0xc00a09bc gpr21 0xc01e3c11d100 gpr22 0xc01e54a8 gpr23 0xc1523400 gpr24 0xc01e48ad7850 gpr25 0xc01e3c11d100 gpr26 0xc01e48a71790 gpr27 0xfead gpr28 0x0 gpr29 0xc01e3c11d100 gpr30 0x1 gpr31 0x0 nip 0xc000fe8c msr 0x90009032 orig_r3 0xc01e6978 ctr 0xc009e1f0 link 0xc01e697c xer 0x0 ccr 0x84022884 softe 0x1 trap 0xf01 dar 0x0 dsisr 0x30004006004 result 0x0 ... thread: :4130:4130 .. dso: /root/.debug/.build-id/82/8d2c7bac560dc9aac8bf6289f26504e22d6883 :4130 4130 179.614739: 1 cycles: c01dde88 .perf_ctx_unlock (/boot/vmlinux) 0xd20 [0x190]: event: 9 Anju (3): perf/powerpc:add ability to sample intr machine state in power tools/perf:Map the ID values with register names perf/powerpc:add support for sampling intr machine state arch/powerpc/Kconfig| 1 + arch/powerpc/include/uapi/asm/perf_regs.h | 55 + arch/powerpc/perf/Makefile | 1 + arch/powerpc/perf/perf_regs.c | 87 tools/perf/arch/powerpc/include/perf_regs.h | 118 tools/perf/config/Makefile | 5 ++ 6 files changed, 267 insertions(+) create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h create mode 100644 arch/powerpc/perf/perf_regs.c create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h -- 2.1.0 ___ Thanks and regards Anju -- 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/3] virtio_net: Stop doing DMA from the stack
From: Andy Lutomirski
Once virtio starts using the DMA API, we won't be able to safely DMA
from the stack. virtio-net does a couple of config DMA requests
from small stack buffers -- switch to using dynamically-allocated
memory.
This should have no effect on any performance-critical code paths.
Cc: net...@vger.kernel.org
Cc: "Michael S. Tsirkin"
Cc: virtualizat...@lists.linux-foundation.org
Reviewed-by: Joerg Roedel
Signed-off-by: Andy Lutomirski
---
Hi Michael and DaveM-
This is a prerequisite for the virtio DMA fixing project. It works
as a standalone patch, though. Would it make sense to apply it to
an appropriate networking tree now?
drivers/net/virtio_net.c | 53
1 file changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d8838dedb7a4..4f10f8a58811 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -976,31 +976,43 @@ static bool virtnet_send_command(struct virtnet_info *vi,
u8 class, u8 cmd,
struct scatterlist *out)
{
struct scatterlist *sgs[4], hdr, stat;
- struct virtio_net_ctrl_hdr ctrl;
- virtio_net_ctrl_ack status = ~0;
+
+ struct {
+ struct virtio_net_ctrl_hdr ctrl;
+ virtio_net_ctrl_ack status;
+ } *buf;
+
unsigned out_num = 0, tmp;
+ bool ret;
/* Caller should know better */
BUG_ON(!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ));
- ctrl.class = class;
- ctrl.cmd = cmd;
+ buf = kmalloc(sizeof(*buf), GFP_ATOMIC);
+ if (!buf)
+ return false;
+ buf->status = ~0;
+
+ buf->ctrl.class = class;
+ buf->ctrl.cmd = cmd;
/* Add header */
- sg_init_one(, , sizeof(ctrl));
+ sg_init_one(, >ctrl, sizeof(buf->ctrl));
sgs[out_num++] =
if (out)
sgs[out_num++] = out;
/* Add return status. */
- sg_init_one(, , sizeof(status));
+ sg_init_one(, >status, sizeof(buf->status));
sgs[out_num] =
BUG_ON(out_num + 1 > ARRAY_SIZE(sgs));
virtqueue_add_sgs(vi->cvq, sgs, out_num, 1, vi, GFP_ATOMIC);
- if (unlikely(!virtqueue_kick(vi->cvq)))
- return status == VIRTIO_NET_OK;
+ if (unlikely(!virtqueue_kick(vi->cvq))) {
+ ret = (buf->status == VIRTIO_NET_OK);
+ goto out;
+ }
/* Spin for a response, the kick causes an ioport write, trapping
* into the hypervisor, so the request should be handled immediately.
@@ -1009,7 +1021,11 @@ static bool virtnet_send_command(struct virtnet_info
*vi, u8 class, u8 cmd,
!virtqueue_is_broken(vi->cvq))
cpu_relax();
- return status == VIRTIO_NET_OK;
+ ret = (buf->status == VIRTIO_NET_OK);
+
+out:
+ kfree(buf);
+ return ret;
}
static int virtnet_set_mac_address(struct net_device *dev, void *p)
@@ -1151,7 +1167,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
struct scatterlist sg[2];
- u8 promisc, allmulti;
+ u8 *cmdbyte;
struct virtio_net_ctrl_mac *mac_data;
struct netdev_hw_addr *ha;
int uc_count;
@@ -1163,22 +1179,25 @@ static void virtnet_set_rx_mode(struct net_device *dev)
if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_RX))
return;
- promisc = ((dev->flags & IFF_PROMISC) != 0);
- allmulti = ((dev->flags & IFF_ALLMULTI) != 0);
+ cmdbyte = kmalloc(sizeof(*cmdbyte), GFP_ATOMIC);
+ if (!cmdbyte)
+ return;
- sg_init_one(sg, , sizeof(promisc));
+ sg_init_one(sg, cmdbyte, sizeof(*cmdbyte));
+ *cmdbyte = ((dev->flags & IFF_PROMISC) != 0);
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
VIRTIO_NET_CTRL_RX_PROMISC, sg))
dev_warn(>dev, "Failed to %sable promisc mode.\n",
-promisc ? "en" : "dis");
-
- sg_init_one(sg, , sizeof(allmulti));
+*cmdbyte ? "en" : "dis");
+ *cmdbyte = ((dev->flags & IFF_ALLMULTI) != 0);
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RX,
VIRTIO_NET_CTRL_RX_ALLMULTI, sg))
dev_warn(>dev, "Failed to %sable allmulti mode.\n",
-allmulti ? "en" : "dis");
+*cmdbyte ? "en" : "dis");
+
+ kfree(cmdbyte);
uc_count = netdev_uc_count(dev);
mc_count = netdev_mc_count(dev);
--
2.4.3
--
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/3] virtio_pci: Use the DMA API
From: Andy Lutomirski
This fixes virtio-pci on platforms and busses that have IOMMUs. This
will break the experimental QEMU Q35 IOMMU support until QEMU is
fixed. In exchange, it fixes physical virtio hardware as well as
virtio-pci running under Xen.
We should clean up the virtqueue API to do its own allocation and
teach virtqueue_get_avail and virtqueue_get_used to return DMA
addresses directly.
Signed-off-by: Andy Lutomirski
---
drivers/virtio/virtio_pci_common.h | 3 ++-
drivers/virtio/virtio_pci_legacy.c | 19 +++
drivers/virtio/virtio_pci_modern.c | 34 --
3 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index b976d968e793..cd6196b513ad 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -38,8 +38,9 @@ struct virtio_pci_vq_info {
/* the number of entries in the queue */
int num;
- /* the virtual address of the ring queue */
+ /* the ring queue */
void *queue;
+ dma_addr_t queue_dma_addr; /* bus address */
/* the list node for the virtqueues list */
struct list_head node;
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index 48bc9797e530..b5293e5f2af4 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -135,12 +135,14 @@ static struct virtqueue *setup_vq(struct
virtio_pci_device *vp_dev,
info->msix_vector = msix_vec;
size = PAGE_ALIGN(vring_size(num, VIRTIO_PCI_VRING_ALIGN));
- info->queue = alloc_pages_exact(size, GFP_KERNEL|__GFP_ZERO);
+ info->queue = dma_zalloc_coherent(_dev->pci_dev->dev, size,
+ >queue_dma_addr,
+ GFP_KERNEL);
if (info->queue == NULL)
return ERR_PTR(-ENOMEM);
/* activate the queue */
- iowrite32(virt_to_phys(info->queue) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
+ iowrite32(info->queue_dma_addr >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
/* create the vring */
@@ -169,7 +171,8 @@ out_assign:
vring_del_virtqueue(vq);
out_activate_queue:
iowrite32(0, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
- free_pages_exact(info->queue, size);
+ dma_free_coherent(_dev->pci_dev->dev, size,
+ info->queue, info->queue_dma_addr);
return ERR_PTR(err);
}
@@ -194,7 +197,8 @@ static void del_vq(struct virtio_pci_vq_info *info)
iowrite32(0, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
size = PAGE_ALIGN(vring_size(info->num, VIRTIO_PCI_VRING_ALIGN));
- free_pages_exact(info->queue, size);
+ dma_free_coherent(_dev->pci_dev->dev, size,
+ info->queue, info->queue_dma_addr);
}
static const struct virtio_config_ops virtio_pci_config_ops = {
@@ -227,6 +231,13 @@ int virtio_pci_legacy_probe(struct virtio_pci_device
*vp_dev)
return -ENODEV;
}
+ rc = dma_set_mask_and_coherent(_dev->dev, DMA_BIT_MASK(64));
+ if (rc)
+ rc = dma_set_mask_and_coherent(_dev->dev,
+ DMA_BIT_MASK(32));
+ if (rc)
+ dev_warn(_dev->dev, "Failed to enable 64-bit or 32-bit DMA.
Trying to continue, but this might not work.\n");
+
rc = pci_request_region(pci_dev, 0, "virtio-pci-legacy");
if (rc)
return rc;
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index 8e5cf194cc0b..fbe0bd1c4881 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -293,14 +293,16 @@ static size_t vring_pci_size(u16 num)
return PAGE_ALIGN(vring_size(num, SMP_CACHE_BYTES));
}
-static void *alloc_virtqueue_pages(int *num)
+static void *alloc_virtqueue_pages(struct virtio_pci_device *vp_dev,
+ int *num, dma_addr_t *dma_addr)
{
void *pages;
/* TODO: allocate each queue chunk individually */
for (; *num && vring_pci_size(*num) > PAGE_SIZE; *num /= 2) {
- pages = alloc_pages_exact(vring_pci_size(*num),
- GFP_KERNEL|__GFP_ZERO|__GFP_NOWARN);
+ pages = dma_zalloc_coherent(
+ _dev->pci_dev->dev, vring_pci_size(*num),
+ dma_addr, GFP_KERNEL|__GFP_NOWARN);
if (pages)
return pages;
}
@@ -309,7 +311,9 @@ static void *alloc_virtqueue_pages(int *num)
return NULL;
/* Try to get a single page. You are my only hope! */
- return alloc_pages_exact(vring_pci_size(*num), GFP_KERNEL|__GFP_ZERO);
+ return dma_zalloc_coherent(
+ _dev->pci_dev->dev,
[PATCH v2 2/3] virtio_ring: Support DMA APIs
virtio_ring currently sends the device (usually a hypervisor)
physical addresses of its I/O buffers. This is okay when DMA
addresses and physical addresses are the same thing, but this isn't
always the case. For example, this never works on Xen guests, and
it is likely to fail if a physical "virtio" device ever ends up
behind an IOMMU or swiotlb.
The immediate use case for me is to enable virtio on Xen guests.
For that to work, we need vring to support DMA address translation
as well as a corresponding change to virtio_pci or to another
driver.
With this patch, if enabled, virtfs survives kmemleak and
CONFIG_DMA_API_DEBUG.
Signed-off-by: Andy Lutomirski
---
drivers/virtio/Kconfig | 2 +-
drivers/virtio/virtio_ring.c | 187 +++
tools/virtio/linux/dma-mapping.h | 17
3 files changed, 169 insertions(+), 37 deletions(-)
create mode 100644 tools/virtio/linux/dma-mapping.h
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index cab9f3f63a38..77590320d44c 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -60,7 +60,7 @@ config VIRTIO_INPUT
config VIRTIO_MMIO
tristate "Platform bus driver for memory mapped virtio devices"
- depends on HAS_IOMEM
+ depends on HAS_IOMEM && HAS_DMA
select VIRTIO
---help---
This drivers provides support for memory mapped virtio
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 096b857e7b75..e71bf0ca59a2 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#ifdef DEBUG
/* For development, we want to crash whenever the ring is screwed. */
@@ -54,7 +55,14 @@
#define END_USE(vq)
#endif
-struct vring_virtqueue {
+struct vring_desc_state
+{
+ void *data; /* Data for callback. */
+ struct vring_desc *indir_desc; /* Indirect descriptor, if any. */
+};
+
+struct vring_virtqueue
+{
struct virtqueue vq;
/* Actual memory layout for this queue */
@@ -92,12 +100,71 @@ struct vring_virtqueue {
ktime_t last_add_time;
#endif
- /* Tokens for callbacks. */
- void *data[];
+ /* Per-descriptor state. */
+ struct vring_desc_state desc_state[];
};
#define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
+/*
+ * The DMA ops on various arches are rather gnarly right now, and
+ * making all of the arch DMA ops work on the vring device itself
+ * is a mess. For now, we use the parent device for DMA ops.
+ */
+struct device *vring_dma_dev(const struct vring_virtqueue *vq)
+{
+ return vq->vq.vdev->dev.parent;
+}
+
+/* Map one sg entry. */
+static dma_addr_t vring_map_one_sg(const struct vring_virtqueue *vq,
+ struct scatterlist *sg,
+ enum dma_data_direction direction)
+{
+ /*
+* We can't use dma_map_sg, because we don't use scatterlists in
+* the way it expects (we don't guarantee that the scatterlist
+* will exist for the lifetime of the mapping).
+*/
+ return dma_map_page(vring_dma_dev(vq),
+ sg_page(sg), sg->offset, sg->length,
+ direction);
+}
+
+static dma_addr_t vring_map_single(const struct vring_virtqueue *vq,
+ void *cpu_addr, size_t size,
+ enum dma_data_direction direction)
+{
+ return dma_map_single(vring_dma_dev(vq),
+ cpu_addr, size, direction);
+}
+
+static void vring_unmap_one(const struct vring_virtqueue *vq,
+ struct vring_desc *desc)
+{
+ u16 flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
+
+ if (flags & VRING_DESC_F_INDIRECT) {
+ dma_unmap_single(vring_dma_dev(vq),
+virtio64_to_cpu(vq->vq.vdev, desc->addr),
+virtio32_to_cpu(vq->vq.vdev, desc->len),
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ } else {
+ dma_unmap_page(vring_dma_dev(vq),
+ virtio64_to_cpu(vq->vq.vdev, desc->addr),
+ virtio32_to_cpu(vq->vq.vdev, desc->len),
+ (flags & VRING_DESC_F_WRITE) ?
+ DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ }
+}
+
+static int vring_mapping_error(const struct vring_virtqueue *vq,
+ dma_addr_t addr)
+{
+ return dma_mapping_error(vring_dma_dev(vq), addr);
+}
+
static struct vring_desc *alloc_indirect(struct virtqueue *_vq,
unsigned int total_sg, gfp_t gfp)
{
@@ -131,7 +198,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
struct vring_virtqueue *vq
[PATCH v2 0/3] virtio DMA API core stuff
This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. Changes from v1: - Fix an endian conversion error causing a BUG to hit. - Fix a DMA ordering issue (swiotlb=force works now). - Minor cleanups. Andy Lutomirski (3): virtio_net: Stop doing DMA from the stack virtio_ring: Support DMA APIs virtio_pci: Use the DMA API drivers/net/virtio_net.c | 53 +++ drivers/virtio/Kconfig | 2 +- drivers/virtio/virtio_pci_common.h | 3 +- drivers/virtio/virtio_pci_legacy.c | 19 +++- drivers/virtio/virtio_pci_modern.c | 34 +-- drivers/virtio/virtio_ring.c | 187 ++--- tools/virtio/linux/dma-mapping.h | 17 7 files changed, 246 insertions(+), 69 deletions(-) create mode 100644 tools/virtio/linux/dma-mapping.h -- 2.4.3 -- 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] w1: w1_process() is not freezable kthread
On Tue, 27 Oct 2015, Evgeniy Polyakov wrote: > > w1_process() calls try_to_freeze(), but the thread doesn't mark itself > > freezable through set_freezable(), so the try_to_freeze() call is useless. > > I believe it is better to mark it freezable, what do you think? Its task > is useless if anyone else goes sleeping, it should freeze too. I fail to see why this kthread should be freezable at all. There is no way for w1 device to generate new I/O requests that should be written out to filesystem, is it? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/5] cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate()
On Wednesday, October 28, 2015 10:14:51 AM Viresh Kumar wrote: > On 28-10-15, 05:05, Rafael J. Wysocki wrote: > > On Tuesday, October 13, 2015 01:39:01 PM Viresh Kumar wrote: > > > 'timer_mutex' is required to sync work-handlers of policy->cpus. > > > update_sampling_rate() is just canceling the works and queuing them > > > again. This isn't protecting anything at all in update_sampling_rate() > > > and is not gonna be of any use. > > > > > > Even if a work-handler is already running for a CPU, > > > cancel_delayed_work_sync() will wait for it to finish. > > > > > > Drop these unnecessary locks. > > > > > > Reviewed-by: Preeti U Murthy > > > Signed-off-by: Viresh Kumar > > > > I'm queuing this up for 4.4, although I think that the changelog is not > > right. > > > > While at it, what are the race conditions the lock is protecting against? > > In cases where a single policy controls multiple CPUs, a timer is > queued for every cpu present in policy->cpus. When we reach the timer > handler (which can be on multiple CPUs together) on any CPU, we trace > CPU load for all policy->cpus and update the frequency accordingly. That would be in dbs_timer(), right? > The lock is for protecting multiple CPUs to do the same thing > together, as only its required to be done by a single CPU. Once any > CPUs handler has completed, it updates the last update time and drops > the mutex. At that point of time, other blocked handler (if any) check > the last update time and return early. Well, that would mean we only needed to hold the lock around the need_load_eval() evaluation in dbs_timer() if I'm not mistaken. We also should acquire it around updates of the sampling rate, which essentially is set_sampling_rate(). Is there any reason to acquire it in cpufreq_governor_limits(), then, for example? > And then there are enough minute things that can go wrong if multiple > CPUs do the load evaluation and freq-update at the same time, apart > from it being an time wasting effort. > > And so I still think that the commit log isn't that bad. The > timer_mutex lock isn't required in other parts of the governor, they > are just for synchronizing the work-handlers of CPUs belonging to the > same policy. I agree that it doesn't serve any purpose in the piece of code you're removing it from (which is why I agree with the patch), but the changelog is incomplete and confusing. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] merge_config.sh: factor out value parsing
On Wed, Oct 28, 2015 at 09:42:02AM +0900, Olof Johansson wrote:
> Since we want to adjust the line later on to deal with CONFIG_FOO=n,
> let's make a function for it so we have only one place to change it in.
>
> Signed-off-by: Olof Johansson
> ---
> scripts/kconfig/merge_config.sh | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
> index 67d1314..d8cd913 100755
> --- a/scripts/kconfig/merge_config.sh
> +++ b/scripts/kconfig/merge_config.sh
> @@ -35,6 +35,10 @@ usage() {
> echo " -Odir to put generated output files. Consider setting
> \$KCONFIG_CONFIG instead."
> }
>
> +getval() {
> + grep -w -e "$1" "$2"
So the inclusion of -e makes sense from a common-denominator perspective... but
is it necessary at all? It's not a big deal either way though. I believe we are
searching only for whole CONFIG_FEATURE options, not a pattern. However, this is
minimal change and is correct.
Reviewed-by: Darren Hart
> +}
> +
> RUNMAKE=true
> ALLTARGET=alldefconfig
> WARNREDUN=false
> @@ -116,8 +120,8 @@ for MERGE_FILE in $MERGE_LIST ; do
>
> for CFG in $CFG_LIST ; do
> grep -q -w $CFG $TMP_FILE || continue
> - PREV_VAL=$(grep -w $CFG $TMP_FILE)
> - NEW_VAL=$(grep -w $CFG $MERGE_FILE)
> + PREV_VAL=$(getval "$CFG" "$TMP_FILE")
> + NEW_VAL=$(getval "$CFG" "$MERGE_FILE")
> if [ "x$PREV_VAL" != "x$NEW_VAL" ] ; then
> echo Value of $CFG is redefined by fragment $MERGE_FILE:
> echo Previous value: $PREV_VAL
> @@ -157,8 +161,8 @@ make KCONFIG_ALLCONFIG=$TMP_FILE $OUTPUT_ARG $ALLTARGET
> # Check all specified config values took (might have missed-dependency
> issues)
> for CFG in $(sed -n "$SED_CONFIG_EXP" $TMP_FILE); do
>
> - REQUESTED_VAL=$(grep -w -e "$CFG" $TMP_FILE)
> - ACTUAL_VAL=$(grep -w -e "$CFG" "$KCONFIG_CONFIG")
> + REQUESTED_VAL=$(getval "$CFG" "$TMP_FILE")
> + ACTUAL_VAL=$(getval "$CFG" "$KCONFIG_CONFIG")
> if [ "x$REQUESTED_VAL" != "x$ACTUAL_VAL" ] ; then
> echo "Value requested for $CFG not in final .config"
> echo "Requested value: $REQUESTED_VAL"
> --
> 2.1.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/
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Input: tsc2005 - Add support for tsc2004
On Tue, Oct 27, 2015 at 06:51:41PM -0700, Dmitry Torokhov wrote: > Hi Michael, > On Tue, Oct 27, 2015 at 07:17:01PM -0500, Michael Welling wrote: > > Adds support for the i2c based tsc2004. Support was added to the tsc2005 > > driver > > due to the similarity of the devices. > > > > Signed-off-by: Michael Welling > > --- > > v2: Fixes Kconfig based on report for 0-day build bot. > > > > .../bindings/input/touchscreen/tsc2004.txt | 38 > > drivers/input/touchscreen/Kconfig | 7 +- > > drivers/input/touchscreen/tsc2005.c| 206 > > - > > Could we maybe split the code into core, spi and i2c drivers instead of > keeping everything together and rely on #ifdefs? > Dmitry, So then we have three files? Perhaps: drivers/input/touchscreen/tsc2004.c drivers/input/touchscreen/tsc2005.c drivers/input/touchscreen/tsc200x-core.c Please ellaborate exactly how you want things to be structured and named so that I don't waste time in revision. It appears that I can't make the build bot happy the way it is. > Thanks! > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] x86: context_tracking: avoid irq_save/irq_restore on kernel entry and exit
On Tue, Oct 27, 2015 at 6:39 PM, Paolo Bonzini wrote: > x86 always calls user_enter and user_exit with interrupt disabled. > Therefore, it is not necessary to check for exceptions, nor to > save/restore the IRQ state, when context tracking functions are > called by guest_enter and guest_exit. > > Use the previously introduced __context_tracking_entry and > __context_tracking_exit. x86 isn't ready for this yet. We could do a quick-and-dirty fix with explicit IRQs-on-and-off much protected by the static key, or we could just wait until I finish the syscall cleanup. I favor the latter, but you're all welcome to do the former and I'll review it. BTW, Frederic, I have a static key patch coming that I think you'll like. I'll send it tomorrow once I'm in front of a real computer. --Andy -- 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/3] context_tracking: avoid irq_save/irq_restore on guest entry and exit
On Tue, Oct 27, 2015 at 6:39 PM, Paolo Bonzini wrote:
> guest_enter and guest_exit must be called with interrupts disabled,
> since they take the vtime_seqlock with write_seq{lock,unlock}.
> Therefore, it is not necessary to check for exceptions, nor to
> save/restore the IRQ state, when context tracking functions are
> called by guest_enter and guest_exit.
>
> Split the body of context_tracking_entry and context_tracking_exit
> out to __-prefixed functions, and use them from KVM.
>
> Rik van Riel has measured this to speed up a tight vmentry/vmexit
> loop by about 2%.
Looks generally sensible. I'm not familiar enough with the code to
call it reviewed-by while sitting on the airport shuttle.
--Andy
--
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/3] context_tracking: remove duplicate enabled check
On Tue, Oct 27, 2015 at 6:39 PM, Paolo Bonzini wrote: > All calls to context_tracking_enter and context_tracking_exit > are already checking context_tracking_is_enabled, except the > context_tracking_user_enter and context_tracking_user_exit > functions left in for the benefit of assembly calls. > > Pull the check up to those functions, by making them simple > wrappers around the user_enter and user_exit inline functions. This makes my brain hurt. Assuming that this survives a boot with CONFIG_CONTEXT_TRACKING_FORCE=y and CONFIG_PROVE_LOCKING=y (with the implied CONFIG_PROVE_RCU), then: Acked-by: Andy Lutomirski -- 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 v2 2/3] restartable sequences: x86 ABI
On Tue, Oct 27, 2015 at 10:03 PM, Peter Zijlstra wrote:
>
> On Tue, Oct 27, 2015 at 04:57:05PM -0700, Paul Turner wrote:
> > +static void rseq_sched_out(struct preempt_notifier *pn,
> > +struct task_struct *next)
> > +{
> > + set_thread_flag(TIF_NOTIFY_RESUME);
> > +}
> >
> > static __read_mostly struct preempt_ops rseq_preempt_ops = {
> > .sched_in = rseq_sched_in_nop,
> > - .sched_out = rseq_sched_out_nop,
> > + .sched_out = rseq_sched_out,
> > };
>
> Since we're unconditionally setting this TIF flag for these tasks, can't
> we introduce something similar to the (contested) TIF_NOHZ_FULL thing
> which is kept on the task indefinitely.
>
So Andy and I talked about this also, I'm in favor, in particular this
has two nice effects:
a) In exit_to_usermode_loop() we can ensure that this is evaluated
prior to _TIF_SIGPENDING. This removes the current requirement that
we also validate this state in setup_rt_frame() [which can perturb
this state prior to our existing notifier].
b) We avoid spurious interactions with other things that use notify resume.
> That avoids having the preempt notifiers and this atomic op in the
> schedule path.
So we still want something there (although it can be definitely be
inlined as opposed to a preempt_notifier) since this allows us to only
evaluate this check on returns to user-space that might matter as
opposed to every syscall.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 05/11] dt-binding: Add ngpios property to GPIO controller node
Hi Linus,
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: 27 October 2015 15:11
> To: Pramod Kumar
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Ray Jui;
> Scott Branden; Russell King; linux-g...@vger.kernel.org; bcm-kernel-feedback-
> list; Jason Uy; Masahiro Yamada; Thomas Gleixner; Laurent Pinchart;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Jonas Gorski
> Subject: Re: [PATCH 05/11] dt-binding: Add ngpios property to GPIO controller
> node
>
> On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar
> wrote:
>
> > Add ngpios property to the gpio controller's DT node so that
> > controller driver extracts total number of gpio lines present in
> > controller from DT and removes dependency on driver.
> >
> > Signed-off-by: Pramod Kumar
> > Reviewed-by: Ray Jui
> > Reviewed-by: Scott Branden
> (...)
> > +- ngpios:
> > +Total number of GPIOs the controller provides
>
> This description is wrong. The number of GPIOs the controller *provides* is to
> be determined by the compatible-string.
>
> ngpios is used to restrict the number of lines *used* or *routed* from the
> number *available*. (I hope that is what the code does as well.) Such as if 12
> GPIOs are used of the 32 available on 32bits in a register.
>
> Update this description to say what it really means.
>
> Yours,
> Linus Walleij
Thanks for reviewing . Will update the description.
Regards,
Pramod
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 2/3] virtio_ring: Support DMA APIs
On Tue, Oct 27, 2015 at 7:21 PM, Joerg Roedel wrote: > On Tue, Oct 27, 2015 at 07:13:56PM -0700, Andy Lutomirski wrote: >> On Tue, Oct 27, 2015 at 7:06 PM, Joerg Roedel wrote: >> > Hi Andy, >> > >> > On Tue, Oct 27, 2015 at 06:17:09PM -0700, Andy Lutomirski wrote: >> >> From: Andy Lutomirski >> >> >> >> virtio_ring currently sends the device (usually a hypervisor) >> >> physical addresses of its I/O buffers. This is okay when DMA >> >> addresses and physical addresses are the same thing, but this isn't >> >> always the case. For example, this never works on Xen guests, and >> >> it is likely to fail if a physical "virtio" device ever ends up >> >> behind an IOMMU or swiotlb. >> > >> > The overall code looks good, but I havn't seen and dma_sync* calls. >> > When swiotlb=force is in use this would break. >> > >> >> + vq->vring.desc[head].addr = cpu_to_virtio64(_vq->vdev, >> >> vring_map_single( >> >> + vq, >> >> + desc, total_sg * sizeof(struct vring_desc), >> >> + DMA_TO_DEVICE)); >> > >> >> Are you talking about a dma_sync call on the descriptor ring itself? >> Isn't dma_alloc_coherent supposed to make that unnecessary? I should >> move the allocation into the virtqueue code. >> >> The docs suggest that I might need to "flush the processor's write >> buffers before telling devices to read that memory". I'm not sure how >> to do that. > > The write buffers should be flushed by the dma-api functions if > necessary. For dma_alloc_coherent allocations you don't need to call > dma_sync*, but for the map_single/map_page/map_sg ones, as these might > be bounce-buffered. I think that all the necessary barriers are already there. I had a nasty bug that swiotlb=force exposed, though, which I've fixed. --Andy -- 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/3] virtio_ring: Support DMA APIs
On Tue, Oct 27, 2015 at 7:27 PM, Christian Borntraeger
wrote:
> Am 28.10.2015 um 10:17 schrieb Andy Lutomirski:
> @@ -423,27 +522,42 @@ EXPORT_SYMBOL_GPL(virtqueue_kick);
>>
>> static void detach_buf(struct vring_virtqueue *vq, unsigned int head)
>> {
>> - unsigned int i;
>> + unsigned int i, j;
>> + u16 nextflag = cpu_to_virtio16(vq->vq.vdev, VRING_DESC_F_NEXT);
>>
>> /* Clear data ptr. */
>> - vq->data[head] = NULL;
>> + vq->desc_state[head].data = NULL;
>>
>> - /* Put back on free list: find end */
>> + /* Put back on free list: unmap first-level descriptors and find end */
>> i = head;
>>
>> - /* Free the indirect table */
>> - if (vq->vring.desc[i].flags & cpu_to_virtio16(vq->vq.vdev,
>> VRING_DESC_F_INDIRECT))
>> - kfree(phys_to_virt(virtio64_to_cpu(vq->vq.vdev,
>> vq->vring.desc[i].addr)));
>> -
>> - while (vq->vring.desc[i].flags & cpu_to_virtio16(vq->vq.vdev,
>> VRING_DESC_F_NEXT)) {
>> + while (vq->vring.desc[i].flags & nextflag) {
>> + vring_unmap_one(vq, >vring.desc[i]);
>> i = virtio16_to_cpu(vq->vq.vdev, vq->vring.desc[i].next);
>> vq->vq.num_free++;
>> }
>>
>> + vring_unmap_one(vq, >vring.desc[i]);
>> vq->vring.desc[i].next = cpu_to_virtio16(vq->vq.vdev, vq->free_head);
>> vq->free_head = head;
>> +
>> /* Plus final descriptor */
>> vq->vq.num_free++;
>> +
>> + /* Free the indirect table, if any, now that it's unmapped. */
>> + if (vq->desc_state[head].indir_desc) {
>> + struct vring_desc *indir_desc =
>> vq->desc_state[head].indir_desc;
>> + u32 len = vq->vring.desc[head].len;
>> +
>> + BUG_ON(!(vq->vring.desc[head].flags & VRING_DESC_F_INDIRECT));
>> + BUG_ON(len == 0 || len % sizeof(struct vring_desc));
>> +
>> + for (j = 0; j < len / sizeof(struct vring_desc); j++)
>> + vring_unmap_one(vq, _desc[j]);
>> +
>> + kfree(vq->desc_state[head].indir_desc);
>> + vq->desc_state[head].indir_desc = NULL;
>> + }
>> }
>
> something seems to be broken with indirect descriptors with that change
You're big endian, right? I had an endian handling bug, and I'll fix it in v2.
--Andy
--
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 05/10] hwmon: (fam15h_power) Add compute unit accumulated power
On Wed, Oct 28, 2015 at 01:34:18AM +0100, Borislav Petkov wrote:
> On Tue, Oct 27, 2015 at 10:53:40AM +0800, Huang Rui wrote:
> > Preemption must be disabled when calling smp_call_function_many,
> > get_cpu would did that. Will get_online_cpus have the same behavior
> > like that?
>
> Well, get_online_cpus() protects you against CPU hotplug operations in
> general. If you want to protect yourself against CPUs going away only,
> then I guess get_cpu()/put_cpu() is fine.
>
> But since we're going to work with the masks as below, prohibiting any
> changes to cpu_online_mask is probably the better/safe thing to do, i.e.
>
> get_online_cpus();
> preempt_disable();
>
> smp_call_function_many( ... );
>
> preempt_enable();
> put_online_cpus();
>
> > That means "the value(cu_acc_power) of the compute unit", which does
> > not represent the value of one CPU core.
>
> No, I mean this: "This behavior can decrease IPI numbers between the
> unit's."
>
> I'm wondering whether it is really needed at all ...
>
OK, The real words are "This behavior can decrease IPI numbers between
the cores." Actually, the meaning also can be reflected from the
codes. So I could remove this sentence.
> > OK, how about below codes:
> >
> > ---
> > for (i = 0; i <= cores_per_cu / BITS_PER_LONG; i++) {
> > offset = cores_per_cu % BITS_PER_LONG;
> > if (i == cores_per_cu / BITS_PER_LONG) {
> > cpumask_bits(src_mask)[i] = GENMASK(offset -1, 0);
> > break;
> > }
> > cpumask_bits(src_mask)[i] = GENMASK(BITS_PER_LONG - 1, 0);
> > }
> >
> > for (i = 0; i < cu_num; i++) {
> > cpumask_shift_left(dst, src_mask, cores_per_cu * i);
> > cpumask_and(res, dst, cpu_online_mask);
> > cpumask_set_cpu(cpumask_any(res), mask);
> > }
>
> I think you can make it even simpler:
>
> /* prepare CU temp mask */
> for (i = 0; i < cores_per_cu; i++)
> cpumask_set_cpu(i, tmp_mask);
>
> for (i = 0; i < cu_num; i++) {
> /* WARN_ON for empty CU masks */
> WARN_ON(!cpumask_and(res_mask, tmp_mask, cpu_online_mask));
> cpumask_set(cpumask_any(res_mask), call_mask);
> cpumask_shift_right(tmp_mask, tmp_mask, cores_per_cu);
> }
>
> smp_call_function_many(call_mask, );
>
> Something like that...
>
Looks better. :)
Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: power: always set IRQF_ONESHOT if no primary handler is specified
If no primary handler is specified then a default one is assigned which
always returns IRQ_WAKE_THREAD. This handler requires the IRQF_ONESHOT,
because the source of interrupt is not disabled.
Signed-off-by: Saurabh Sengar
---
drivers/power/max8903_charger.c | 9 ++---
drivers/power/wm831x_power.c| 13 ++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index bf2b4b3..0488e74 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -301,7 +301,8 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->dc_valid) {
ret = request_threaded_irq(gpio_to_irq(pdata->dok),
NULL, max8903_dcin,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING
+ | IRQF_ONESHOT,
"MAX8903 DC IN", data);
if (ret) {
dev_err(dev, "Cannot request irq %d for DC (%d)\n",
@@ -313,7 +314,8 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->usb_valid) {
ret = request_threaded_irq(gpio_to_irq(pdata->uok),
NULL, max8903_usbin,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING
+ | IRQF_ONESHOT,
"MAX8903 USB IN", data);
if (ret) {
dev_err(dev, "Cannot request irq %d for USB (%d)\n",
@@ -325,7 +327,8 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->flt) {
ret = request_threaded_irq(gpio_to_irq(pdata->flt),
NULL, max8903_fault,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING
+ | IRQF_ONESHOT,
"MAX8903 Fault", data);
if (ret) {
dev_err(dev, "Cannot request irq %d for Fault (%d)\n",
diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index db11ae6..f2f5bae 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -572,8 +572,8 @@ static int wm831x_power_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "SYSLO"));
ret = request_threaded_irq(irq, NULL, wm831x_syslo_irq,
- IRQF_TRIGGER_RISING, "System power low",
- power);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ "System power low", power);
if (ret != 0) {
dev_err(>dev, "Failed to request SYSLO IRQ %d: %d\n",
irq, ret);
@@ -582,8 +582,8 @@ static int wm831x_power_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "PWR SRC"));
ret = request_threaded_irq(irq, NULL, wm831x_pwr_src_irq,
- IRQF_TRIGGER_RISING, "Power source",
- power);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ "Power source", power);
if (ret != 0) {
dev_err(>dev, "Failed to request PWR SRC IRQ %d: %d\n",
irq, ret);
@@ -595,9 +595,8 @@ static int wm831x_power_probe(struct platform_device *pdev)
platform_get_irq_byname(pdev,
wm831x_bat_irqs[i]));
ret = request_threaded_irq(irq, NULL, wm831x_bat_irq,
- IRQF_TRIGGER_RISING,
- wm831x_bat_irqs[i],
- power);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ wm831x_bat_irqs[i], power);
if (ret != 0) {
dev_err(>dev,
"Failed to request %s IRQ %d: %d\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 v3 4/5] clk: s2mps15: Add support for S2MPS15 clocks
On 10/28/2015 10:04 AM, Krzysztof Kozlowski wrote:
On 28.10.2015 10:26, Krzysztof Kozlowski wrote:
On 26.10.2015 21:51, Alim Akhtar wrote:
S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
adds supports for the same to the s2mps11 clock driver.
Signed-off-by: Alim Akhtar
---
drivers/clk/Kconfig |5 +++--
drivers/clk/clk-s2mps11.c | 24
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a1fa61159179..037a314b5d76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ This driver supports S2MPS1X/S5M8767 crystal oscillator
clock. These multi-function devices have two (S2MPS14) or three
- (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
+ (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
+ clocked at 32KHz each.
config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d266299dfdb1..455500dca653 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,24 @@ static struct clk_init_data
s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
},
};
+static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
+ [S2MPS11_CLK_AP] = {
+ .name = "s2mps15_ap",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_CP] = {
+ .name = "s2mps15_cp",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_BT] = {
+ .name = "s2mps15_bt",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
+
static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
struct clk_init_data *clks_init)
{
@@ -207,6 +226,10 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
s2mps11_reg = S2MPS14_REG_RTCCTRL;
clks_init = s2mps14_clks_init;
break;
+ case S2MPS15X:
+ s2mps11_reg = S2MPS15_REG_RTC_BUF;
+ clks_init = s2mps15_clks_init;
Another question (after looking at RTC driver):
Is this the same register address as S2MPS14?
I found the answer - this is the same address as in S2MPS13 and S2MPS14:
0xc. The S2MPS14 has only two clocks though but S2MPS13 has three.
Again, as in RTC, you should re-use existing support.
It looks there is no need for this patch at all.
Yes, checked that, rtc looks same to s2mps14 and clk looks same as
s2mps13{ not s2mps11}, because of the RTC_BUF address changes.
Will drop patch 4 and 5 and use the existing names where applicable.
I think I don't have to change the binding or Kconfig changes?
Best regards,
Krzysztof
--
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 v2 2/3] restartable sequences: x86 ABI
On Tue, Oct 27, 2015 at 04:57:05PM -0700, Paul Turner wrote:
> +static void rseq_sched_out(struct preempt_notifier *pn,
> +struct task_struct *next)
> +{
> + set_thread_flag(TIF_NOTIFY_RESUME);
> +}
>
> static __read_mostly struct preempt_ops rseq_preempt_ops = {
> .sched_in = rseq_sched_in_nop,
> - .sched_out = rseq_sched_out_nop,
> + .sched_out = rseq_sched_out,
> };
Since we're unconditionally setting this TIF flag for these tasks, can't
we introduce something similar to the (contested) TIF_NOHZ_FULL thing
which is kept on the task indefinitely.
That avoids having the preempt notifiers and this atomic op in the
schedule path.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] merge_config misc reworks and testcases
On Wed, Oct 28, 2015 at 09:42:01AM +0900, Olof Johansson wrote: > Hi, > > Somewhat wide distribution list here, since I've added everyone who's > touched the script, with the presumption that those have been the major > users of it. Please make sure none of these changes break your use cases. +Bruce. I think you were going to test these with the linux-yocto tooling. Did you get a chance to run that test? I'd like your thoughts on the two comments below: > > I've done some reworks of merge_config.sh. I was quite hesitant to start > this since there are no good ways to see if your changes break others > or not, so the first thing I did was to add some tests. I know this is > highly unorthodox so try not to panic. :-) > > As far as what this series does is: > > - Adds a way to pass in CONFIG_FOO= on the command line, it gets > treated as a single-entry fragment file > > - The script now prints the warnings on stderr, and returns non-0 when > something is encountered This one might impact linux-yocto usage, Bruce? That said, it seems like the right thing to do. So I'd still like to see it go in, but we may need to plan to update the dependent tooling to use it. > > - Optionally, it'll also return non-0 when a redundant entry is found. I > presumed people rely on -r not being a failure so I did this separately > > - CONFIG_FOO=n and "# CONFIG_FOO is not set" is now treated the same, > and using the former doesn't cause an invalid warning when the results > are checked at the end > > - Slightly odd things happened if a fragment contains the same option > twice: It'd produce a warning that was malformed. Now just ignore that > and use only the latest value of said option. This one will likely impact usage as well. linux-yocto does want to report when there is an override, not as an error, but for informational purposes - "Where does my option get clobbered?" -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
XMAS LOAN OFFER
Do you need a Business or Personal Loan? If yes then get back via stevebruceloancompany.li...@gmail.com for full details -- 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] sched: fix incorrect wait time and wait count statistics
At present scheduler resets task's wait start timestamp when the task
migrates to another rq. This misleads scheduler itself into reporting
less wait time than actual by omitting time spent for waiting prior to
migration and also more wait count than actual by counting migration as
wait end event which can be seen by trace or /proc//sched with
CONFIG_SCHEDSTATS=y.
Carry forward migrating task's wait time prior to migration and
don't count migration as a wait end event to fix such statistics error.
In order to determine whether fair task is migrating mark task->on_rq with
TASK_ON_RQ_MIGRATING while dequeuing and enqueuing due to migration.
To: Ingo Molnar
To: Peter Zijlstra
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joonwoo Park
---
Changes in v2:
* Set p->on_rq = TASK_ON_RQ_MIGRATING while doing migration dequeue/enqueue
and check whether task's migrating with task_on_rq_migrating().
Changes in v3:
* Fixed "WARNING: CPU: 0 PID: 3 at kernel/sched/fair.c:260
update_stats_wait_end+0x23/0x30()" caught by Intel kernel test robot.
Changes in v4:
* Made __migrate_swap_task() to set p->on_rq = TASK_ON_RQ_MIGRATING.
* Added WARN_ON_ONCE() inside CONFIG_SCHED_DEBUG.
* Added comments.
* Cleanup with ifdefy.
kernel/sched/core.c | 15 +++--
kernel/sched/fair.c | 62 ++---
2 files changed, 58 insertions(+), 19 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bcd214e..1ddbabc 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1069,8 +1069,8 @@ static struct rq *move_queued_task(struct rq *rq, struct
task_struct *p, int new
{
lockdep_assert_held(>lock);
- dequeue_task(rq, p, 0);
p->on_rq = TASK_ON_RQ_MIGRATING;
+ dequeue_task(rq, p, 0);
set_task_cpu(p, new_cpu);
raw_spin_unlock(>lock);
@@ -1078,8 +1078,8 @@ static struct rq *move_queued_task(struct rq *rq, struct
task_struct *p, int new
raw_spin_lock(>lock);
BUG_ON(task_cpu(p) != new_cpu);
- p->on_rq = TASK_ON_RQ_QUEUED;
enqueue_task(rq, p, 0);
+ p->on_rq = TASK_ON_RQ_QUEUED;
check_preempt_curr(rq, p, 0);
return rq;
@@ -1272,6 +1272,15 @@ void set_task_cpu(struct task_struct *p, unsigned int
new_cpu)
WARN_ON_ONCE(p->state != TASK_RUNNING && p->state != TASK_WAKING &&
!p->on_rq);
+ /*
+* Migrating fair class task must have p->on_rq = TASK_ON_RQ_MIGRATING,
+* because schedstat_wait_{start,end} rebase migrating task's wait_start
+* time relying on p->on_rq.
+*/
+ WARN_ON_ONCE(p->state == TASK_RUNNING &&
+p->sched_class == _sched_class &&
+(p->on_rq && !task_on_rq_migrating(p)));
+
#ifdef CONFIG_LOCKDEP
/*
* The caller should hold either p->pi_lock or rq->lock, when changing
@@ -1308,9 +1317,11 @@ static void __migrate_swap_task(struct task_struct *p,
int cpu)
src_rq = task_rq(p);
dst_rq = cpu_rq(cpu);
+ p->on_rq = TASK_ON_RQ_MIGRATING;
deactivate_task(src_rq, p, 0);
set_task_cpu(p, cpu);
activate_task(dst_rq, p, 0);
+ p->on_rq = TASK_ON_RQ_QUEUED;
check_preempt_curr(dst_rq, p, 0);
} else {
/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9a5e60f..ce7e869 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -737,41 +737,69 @@ static void update_curr_fair(struct rq *rq)
update_curr(cfs_rq_of(>curr->se));
}
+#ifdef CONFIG_SCHEDSTATS
static inline void
update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
- schedstat_set(se->statistics.wait_start, rq_clock(rq_of(cfs_rq)));
-}
+ u64 wait_start = rq_clock(rq_of(cfs_rq));
-/*
- * Task is being enqueued - update stats:
- */
-static void update_stats_enqueue(struct cfs_rq *cfs_rq, struct sched_entity
*se)
-{
- /*
-* Are we enqueueing a waiting task? (for current tasks
-* a dequeue/enqueue event is a NOP)
-*/
- if (se != cfs_rq->curr)
- update_stats_wait_start(cfs_rq, se);
+ if (entity_is_task(se) && task_on_rq_migrating(task_of(se)) &&
+ likely(wait_start > se->statistics.wait_start))
+ wait_start -= se->statistics.wait_start;
+
+ schedstat_set(se->statistics.wait_start, wait_start);
}
static void
update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
+ if (entity_is_task(se) && task_on_rq_migrating(task_of(se))) {
+ /*
+* Preserve migrating task's wait time so wait_start time stamp
+* can be adjusted to accumulate wait time prior to migration.
+*/
+ schedstat_set(se->statistics.wait_start,
+ rq_clock(rq_of(cfs_rq)) -
+
Re: [PATCH V3 1/5] cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate()
On 28-10-15, 05:05, Rafael J. Wysocki wrote: > On Tuesday, October 13, 2015 01:39:01 PM Viresh Kumar wrote: > > 'timer_mutex' is required to sync work-handlers of policy->cpus. > > update_sampling_rate() is just canceling the works and queuing them > > again. This isn't protecting anything at all in update_sampling_rate() > > and is not gonna be of any use. > > > > Even if a work-handler is already running for a CPU, > > cancel_delayed_work_sync() will wait for it to finish. > > > > Drop these unnecessary locks. > > > > Reviewed-by: Preeti U Murthy > > Signed-off-by: Viresh Kumar > > I'm queuing this up for 4.4, although I think that the changelog is not right. > > While at it, what are the race conditions the lock is protecting against? In cases where a single policy controls multiple CPUs, a timer is queued for every cpu present in policy->cpus. When we reach the timer handler (which can be on multiple CPUs together) on any CPU, we trace CPU load for all policy->cpus and update the frequency accordingly. The lock is for protecting multiple CPUs to do the same thing together, as only its required to be done by a single CPU. Once any CPUs handler has completed, it updates the last update time and drops the mutex. At that point of time, other blocked handler (if any) check the last update time and return early. And then there are enough minute things that can go wrong if multiple CPUs do the load evaluation and freq-update at the same time, apart from it being an time wasting effort. And so I still think that the commit log isn't that bad. The timer_mutex lock isn't required in other parts of the governor, they are just for synchronizing the work-handlers of CPUs belonging to the same policy. -- viresh -- 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] Input: tsc2005 - Add support for tsc2004
Hi Michael, [auto build test ERROR on input/next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Michael-Welling/Input-tsc2005-Add-support-for-tsc2004/20151028-082017 config: x86_64-randconfig-s1-10281141 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/built-in.o: In function `tsc2005_cmd': tsc2005.c:(.text+0x21a352): undefined reference to `i2c_smbus_write_byte' drivers/built-in.o: In function `tsc200x_probe_common': >> tsc2005.c:(.text+0x21b554): undefined reference to `__devm_regmap_init_i2c' drivers/built-in.o: In function `tsc2005_modinit': tsc2005.c:(.init.text+0xe2b2): undefined reference to `i2c_register_driver' drivers/built-in.o: In function `tsc2005_exit': tsc2005.c:(.exit.text+0xf4c): undefined reference to `i2c_del_driver' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH v3 4/5] clk: s2mps15: Add support for S2MPS15 clocks
On 28.10.2015 10:26, Krzysztof Kozlowski wrote:
> On 26.10.2015 21:51, Alim Akhtar wrote:
>> S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
>> adds supports for the same to the s2mps11 clock driver.
>>
>> Signed-off-by: Alim Akhtar
>> ---
>> drivers/clk/Kconfig |5 +++--
>> drivers/clk/clk-s2mps11.c | 24
>> 2 files changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index a1fa61159179..037a314b5d76 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
>> tristate "Clock driver for S2MPS1X/S5M8767 MFD"
>> depends on MFD_SEC_CORE
>> ---help---
>> - This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
>> + This driver supports S2MPS1X/S5M8767 crystal oscillator
>>clock. These multi-function devices have two (S2MPS14) or three
>> - (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
>> + (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
>> + clocked at 32KHz each.
>>
>> config CLK_TWL6040
>> tristate "External McPDM functional clock from twl6040"
>> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
>> index d266299dfdb1..455500dca653 100644
>> --- a/drivers/clk/clk-s2mps11.c
>> +++ b/drivers/clk/clk-s2mps11.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -148,6 +149,24 @@ static struct clk_init_data
>> s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
>> },
>> };
>>
>> +static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
>> +[S2MPS11_CLK_AP] = {
>> +.name = "s2mps15_ap",
>> +.ops = _clk_ops,
>> +.flags = CLK_IS_ROOT,
>> +},
>> +[S2MPS11_CLK_CP] = {
>> +.name = "s2mps15_cp",
>> +.ops = _clk_ops,
>> +.flags = CLK_IS_ROOT,
>> +},
>> +[S2MPS11_CLK_BT] = {
>> +.name = "s2mps15_bt",
>> +.ops = _clk_ops,
>> +.flags = CLK_IS_ROOT,
>> +},
>> +};
>> +
>> static struct device_node *s2mps11_clk_parse_dt(struct platform_device
>> *pdev,
>> struct clk_init_data *clks_init)
>> {
>> @@ -207,6 +226,10 @@ static int s2mps11_clk_probe(struct platform_device
>> *pdev)
>> s2mps11_reg = S2MPS14_REG_RTCCTRL;
>> clks_init = s2mps14_clks_init;
>> break;
>> +case S2MPS15X:
>> +s2mps11_reg = S2MPS15_REG_RTC_BUF;
>> +clks_init = s2mps15_clks_init;
>
> Another question (after looking at RTC driver):
> Is this the same register address as S2MPS14?
I found the answer - this is the same address as in S2MPS13 and S2MPS14:
0xc. The S2MPS14 has only two clocks though but S2MPS13 has three.
Again, as in RTC, you should re-use existing support.
It looks there is no need for this patch at all.
Best regards,
Krzysztof
--
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] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
> > On Tue, Oct 27, 2015 at 06:56:50PM +, Wan, Kaike wrote: > > > > I do wonder if it is a good idea to call ib_nl_send_msg with a > > > spinlock held though.. Would be nice to see that go away. > > > > We have to hold the lock to protect against a race condition that a > > quick response will try to free the request from the > > ib_nl_request_list before we even put it on the list. > > Put is on the list first? Use a kref? Doesn't look like a big deal to clean > this up. > > Jason Not sure what "Put is on the list first?" means. I think it is valid to build the request, if success, add to the list, then send it. That would solve the problem you mention above. Was that what you hand in mind, Jason? I don't have time to work on this right now, not sure about Kaike. Until we can remove the spinlock the current proposed patch should be applied in the interim. Sorry for the noise before. Reviewed-By: Ira Weiny -- 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] Discard regression fix for 4.3
Hi Linus, This is a fix for a discard performance issues on a particular NVMe device. I originally thought this regression was introduced prior to this merge window and wanted to just make it part of the 4.4 merge window patches and mark it stable, but it has in fact been introduced in this series. So it should have been part of the pull yesterday, but here it is today. It's pretty straight forward and has been tested and reviewed carefully, so I feel fine including it at this point. Please pull to get this single patch. git://git.kernel.dk/linux-block.git for-linus Ming Lin (1): block: re-add discard_granularity and alignment checks block/blk-lib.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- 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/
[PATCH] audit: removing unused variable
variavle rc in not required as it is just used for unchanged for return,
and return is always 0 in the function.
Signed-off-by: Saurabh Sengar
---
kernel/audit.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 662c007..409482f 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -686,23 +686,22 @@ static int audit_netlink_ok(struct sk_buff *skb, u16
msg_type)
static int audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
{
- int rc = 0;
uid_t uid = from_kuid(_user_ns, current_uid());
pid_t pid = task_tgid_nr(current);
if (!audit_enabled && msg_type != AUDIT_USER_AVC) {
*ab = NULL;
- return rc;
+ return 0;
}
*ab = audit_log_start(NULL, GFP_KERNEL, msg_type);
if (unlikely(!*ab))
- return rc;
+ return 0;
audit_log_format(*ab, "pid=%d uid=%u", pid, uid);
audit_log_session_info(*ab);
audit_log_task_context(*ab);
- return rc;
+ return 0;
}
int is_audit_feature_set(int i)
--
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 v8 1/5] Documentation: add sbsa-gwdt driver documentation
Hi Mark Thanks for your rapid feedback, I appreciate your help very much. On 28 October 2015 at 00:22, Mark Rutland wrote: > On Wed, Oct 28, 2015 at 12:06:35AM +0800, fu@linaro.org wrote: >> From: Fu Wei >> >> The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for >> introducing SBSA(Server Base System Architecture) Generic Watchdog >> device node info into FDT. >> >> Also add sbsa-gwdt introduction in watchdog-parameters.txt >> >> Acked-by: Arnd Bergmann >> Signed-off-by: Fu Wei >> --- >> .../devicetree/bindings/watchdog/sbsa-gwdt.txt | 46 >> ++ >> Documentation/watchdog/watchdog-parameters.txt | 6 +++ >> 2 files changed, 52 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt >> b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt >> new file mode 100644 >> index 000..ad8e99a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt >> @@ -0,0 +1,46 @@ >> +* SBSA (Server Base System Architecture) Generic Watchdog >> + >> +The SBSA Generic Watchdog Timer is used to force a reset of the system >> +after two stages of timeout have elapsed. A detailed definition of the >> +watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server >> +Base System Architecture (SBSA) >> + >> +Required properties: >> +- compatible: Should at least contain "arm,sbsa-gwdt". >> + >> +- reg: Each entry specifies the base physical 64-bit address of a register >> + frame and the 64-bit length of that frame; currently, two frames must be > > Remove "64-bit" here. This depends on #address-cells and #size-cells, as > usual. Ah, right, Thanks , will do > >> + defined, in this order: >> + 1: Watchdog control frame >> + 2: Refresh frame. >> + >> +- interrupts: At least one interrupt must be defined that will be used as >> + the WS0 interrupt. A WS1 interrupt definition can be provided, but is >> + optional. The interrupts must be defined in this order: >> + 1: WS0 interrupt >> + 2: WS1 interrupt > > Why is WS1 optional? According to the description of WS1 in SBSA 2.3 (5.2 Watchdog Operation) page 21 - The signal is fed to a higher agent as an interrupt or reset for it to take executive action. So WS1 maybe a interrupt. In a real Hardware, WS1 hooks to a reset signal pin of BMC, if this pin is triggered, BMC will do a real warm reset. In this case, WS1 is a reset, Linux doesn't need to deal with that. For now , I haven't found a hardware use WS1 as interrupt. In 3.2 Interrupt maps Page 22 Table 3-3 Shared peripheral interrupt assignments IRQ ID SPI offset Device 60 28 EL2 Generic Watchdog WS1 But I don't have further info about it. Anyway, because this signal could be interrupt or reset, Linux don't need know this signal sometimes. So I think it should be optional in binding info. Do I miss something? Any suggestion ? Please correct me, thanks. > >> +Optional properties >> +- timeout-sec: To use a timeout value that is different from the driver >> + default values, use this property. > > Either define a default value, or don't state anything about the > behaviour when this is not present. OK, thanks :-) > >>If used, at least one timeout value >> + (in seconds) must be provided. A second optional timeout value (in >> + seconds) may also be provided and will be used as the pre-timeout value, >> + if it is given. >> + >> + There are two possible sources for driver default timeout values: >> + (1) the driver contains hard-coded default values, or >> + (2) module parameters can be given when the module is loaded >> + >> + If timeout/pretimeout values are provided when the module loads, they >> + will take priority. Second priority will be the timeout-sec from DTB, >> + and third the hard-coded driver values. > > The last two paragraphs should go. They describe Linux behaviour rather > than the binding. yes, maybe that should be in the watchdog documentation? > > Thanks, > Mark. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- 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 4/5] mm: simplify reclaim path for MADV_FREE
> On Oct 27, 2015, at 16:52, yalin wang wrote:
>
>
>> On Oct 27, 2015, at 16:10, Minchan Kim wrote:
>>
>> On Tue, Oct 27, 2015 at 03:39:16PM +0800, yalin wang wrote:
>>>
On Oct 27, 2015, at 15:09, Minchan Kim wrote:
Hello Yalin,
Sorry for missing you in Cc list.
IIRC, mails to send your previous mail address(yalin.w...@sonymobile.com)
were returned.
You added comment bottom line so I'm not sure what PageDirty you meant.
> it is wrong here if you only check PageDirty() to decide if the page is
> freezable or not .
> The Anon page are shared by multiple process, _mapcount > 1 ,
> so you must check all pt_dirty bit during page_referenced() function,
> see this mail thread:
> http://ns1.ske-art.com/lists/kernel/msg1934021.html
If one of pte among process sharing the page was dirty, the dirtiness
should
be propagated from pte to PG_dirty by try_to_unmap_one.
IOW, if the page doesn't have PG_dirty flag, it means all of process did
MADV_FREE.
Am I missing something from you question?
If so, could you show exact scenario I am missing?
Thanks for the interest.
>>> oh, yeah , that is right , i miss that , pte_dirty will propagate to
>>> PG_dirty ,
>>> so that is correct .
>>> Generic to say this patch move set_page_dirty() from add_to_swap() to
>>> try_to_unmap(), i think can change a little about this patch:
>>>
>>> @@ -1476,6 +1446,8 @@ static int try_to_unmap_one(struct page *page, struct
>>> vm_area_struct *vma,
>>> ret = SWAP_FAIL;
>>> goto out_unmap;
>>> }
>>> + if (!PageDirty(page))
>>> + SetPageDirty(page);
>>> if (list_empty(>mmlist)) {
>>> spin_lock(_lock);
>>> if (list_empty(>mmlist))
>>>
>>> i think this 2 lines can be removed ,
>>> since pte_dirty have propagated to set_page_dirty() , we don’t need this
>>> line here ,
>>> otherwise you will always dirty a AnonPage, even it is clean,
>>> then we will page out this clean page to swap partition one more , this is
>>> not needed.
>>> am i understanding correctly ?
>>
>> Your understanding is correct.
>> I will fix it in next spin.
>>
>>>
>>> By the way, please change my mail address to yalin.wang2...@gmail.com in CC
>>> list .
>>> Thanks a lot. :)
>>
>> Thanks for the review!
>
> i have a look at the old mail list , i recall the scenario that multiple
> processes share a AnonPage
> special case :
>
> for example Process A have a AnonPage map like this:
> ! pte_dirty() && PageDirty()==1 (this is possible after read fault
> happened on swap entry, and try_to_free_swap() succeed.)
> Process A do a fork() , New process is called B .
> Then A syscall(MADV_FREE) on the page .
> At this time, page table like this:
>
> A ! pte_dirty() && PageDirty() == 0 && PageSwapCache() == 0
>
> B ! pte_dirty() && PageDirty() == 0 && PageSwapCache() == 0
>
> This means this page is freeable , and can be freed during page reclaim.
> This is not fair for Process B . Since B don’t call syscall(MADV_FREE) ,
> its page should not be discard . Will cause some strange behaviour if
> happened .
>
> This is discussed by
> http://www.serverphorums.com/read.php?12,1220840
> but i don’t know why the patch is not merged .
>
> Thanks
oh, i have see 0b502297d1cc26e09b98955b4efa728be1c48921
this commit merged , then this problem should be fixed by this method.
ignore this mail. :)
Thanks a lot .
--
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] serial: support 16-bit register interface for console
Currently, 8-bit (MMIO) and 32-bit (MMIO32) register interfaces are
supported for the 8250 console, but the 16-bit (MMIO16) is not.
The 8250 UART device on my board is connected to a 16-bit bus and
my main motivation is to use earlycon with it.
(Refer to arch/arm/boot/dts/uniphier-support-card.dtsi)
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Rebase on tty-next branch of TTY subsystem
Changes in v3:
- Adjust of_platform_serial_setup(), univ8250_console_match()
for UPIO_MEM16
Changes in v2:
- Do not change userspace-exported macros
Documentation/kernel-parameters.txt | 9 +
drivers/tty/serial/8250/8250_core.c | 7 ---
drivers/tty/serial/8250/8250_early.c | 5 +
drivers/tty/serial/8250/8250_port.c | 20
drivers/tty/serial/earlycon.c| 15 +++
drivers/tty/serial/of_serial.c | 3 +++
drivers/tty/serial/serial_core.c | 9 +++--
include/linux/serial_core.h | 1 +
include/uapi/linux/serial.h | 1 +
9 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 8d9dd53..8b6f6e8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -720,16 +720,17 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
+ uart[8250],mmio16,[,options]
uart[8250],mmio32,[,options]
uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later.
MMIO inter-register address stride is either 8-bit
- (mmio) or 32-bit (mmio32).
- If none of [io|mmio|mmio32], is assumed to be
- equivalent to 'mmio'. 'options' are specified in the
- same format described for ttyS above; if unspecified,
+ (mmio), 16-bit (mmio16), or 32-bit (mmio32).
+ If none of [io|mmio|mmio16|mmio32], is assumed
+ to be equivalent to 'mmio'. 'options' are specified in
+ the same format described for ttyS above; if
unspecified,
the h/w is not re-initialized.
hvc Use the hypervisor console device . This is for
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 3912646..c9720a9 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -620,7 +620,7 @@ static int univ8250_console_setup(struct console *co, char
*options)
* @options: ptr to option string from console command line
*
* Only attempts to match console command lines of the form:
- * console=uart[8250],io|mmio|mmio32,[,]
+ * console=uart[8250],io|mmio|mmio16|mmio32,[,]
* console=uart[8250],0x[,]
* This form is used to register an initial earlycon boot console and
* replace it with the serial8250_console at 8250 driver init.
@@ -650,8 +650,9 @@ static int univ8250_console_match(struct console *co, char
*name, int idx,
if (port->iotype != iotype)
continue;
- if ((iotype == UPIO_MEM || iotype == UPIO_MEM32) &&
- (port->mapbase != addr))
+ if ((iotype == UPIO_MEM || iotype == UPIO_MEM16 ||
+iotype == UPIO_MEM32 || iotype == UPIO_MEM32BE)
+ && (port->mapbase != addr))
continue;
if (iotype == UPIO_PORT && port->iobase != addr)
continue;
diff --git a/drivers/tty/serial/8250/8250_early.c
b/drivers/tty/serial/8250/8250_early.c
index ceb8579..e9d4acb 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -42,6 +42,8 @@ static unsigned int __init serial8250_early_in(struct
uart_port *port, int offse
switch (port->iotype) {
case UPIO_MEM:
return readb(port->membase + offset);
+ case UPIO_MEM16:
+ return readw(port->membase + (offset << 1));
case UPIO_MEM32:
return readl(port->membase + (offset << 2));
case UPIO_MEM32BE:
@@ -59,6 +61,9 @@ static void __init serial8250_early_out(struct uart_port
*port, int offset, int
case UPIO_MEM:
writeb(value, port->membase + offset);
break;
+ case UPIO_MEM16:
+ writew(value, port->membase + (offset << 1));
+ break;
case UPIO_MEM32:
writel(value, port->membase + (offset << 2));
break;
diff --git a/drivers/tty/serial/8250/8250_port.c
Re: [PATCH v3 1/3] leds: rt5033: Add DT binding for RT5033
Hi Jacek,
Oh, I see. I'll add.
Thanks for the review.
On 2015년 10월 26일 19:11, Jacek Anaszewski wrote:
> Hi Ingi,
>
> On 10/23/2015 07:48 AM, Ingi Kim wrote:
>> This patch adds the device tree bindings for RT5033 flash LEDs.
>>
>> Signed-off-by: Ingi Kim
>> Acked-by: Rob Herring
>> ---
>> .../devicetree/bindings/leds/leds-rt5033.txt | 38
>> ++
>> 1 file changed, 38 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-rt5033.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-rt5033.txt
>> b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
>> new file mode 100644
>> index 000..2ef7bdc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
>> @@ -0,0 +1,38 @@
>> +* Richtek Technology Corporation - RT5033 Flash LED Driver
>> +
>> +The RT5033 Flash LED Circuit is designed for one or two LEDs driving
>
> These bindings don't say how to handle two LEDs case.
>
>> +for torch and strobe applications, it provides an I2C software command
>> +to trigger the torch and strobe operation.
>> +
>> +Required properties:
>> +- compatible : Must be "richtek,rt5033-led".
>> +
>> +A discrete LED element connected to the device must be represented by a
>> child
>> +node - see Documentation/devicetree/bindings/leds/common.txt.
>> +
>> +Required properties of the LED child node:
>> + See Documentation/devicetree/bindings/leds/common.txt
>> +- led-max-microamp : Minimum Threshold for Timer protection
>> + is defined internally (Maximum 200mA).
>> +- flash-max-microamp : Flash LED maximum current
>> +- flash-max-timeout-us : Flash LED maximum timeout
>> +
>> +Optional properties of the LED child node:
>> +- label : see Documentation/devicetree/bindings/leds/common.txt
>> +
>> +Example:
>> +
>> +rt5033 {
>> +compatible = "richtek,rt5033";
>> +
>> +led {
>> +compatible = "richtek,rt5033-led";
>> +
>> +flash-led {
>> +label = "rt5033-flash";
>> +led-max-microamp = <20>;
>> +flash-max-microamp = <80>;
>> +flash-max-timeout-us = <1216000>;
>> +};
>> +};
>> +}
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] clk: s2mps15: Add support for S2MPS15 clocks
Hello
On 10/28/2015 06:52 AM, Krzysztof Kozlowski wrote:
On 26.10.2015 21:51, Alim Akhtar wrote:
S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
adds supports for the same to the s2mps11 clock driver.
Signed-off-by: Alim Akhtar
---
drivers/clk/Kconfig |5 +++--
drivers/clk/clk-s2mps11.c | 24
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a1fa61159179..037a314b5d76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ This driver supports S2MPS1X/S5M8767 crystal oscillator
clock. These multi-function devices have two (S2MPS14) or three
- (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
+ (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
+ clocked at 32KHz each.
config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d266299dfdb1..455500dca653 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,24 @@ static struct clk_init_data
s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
},
};
+static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
+ [S2MPS11_CLK_AP] = {
+ .name = "s2mps15_ap",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_CP] = {
+ .name = "s2mps15_cp",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_BT] = {
+ .name = "s2mps15_bt",
+ .ops = _clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
I see that for S2MPS13 we already added similar array which duplicates
the S2MPS11. This actually looks wrong. Just re-use existing
s2mps11_clks_init.
hmm..ok will do.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC
On 10/28/2015 09:01 AM, Krzysztof Kozlowski wrote:
On 28.10.2015 12:14, Alim Akhtar wrote:
Hello,
On 10/28/2015 07:47 AM, Krzysztof Kozlowski wrote:
On 28.10.2015 10:53, Mark Brown wrote:
On Wed, Oct 28, 2015 at 10:29:56AM +0900, Krzysztof Kozlowski wrote:
If that's true, then don't add new compatibles, new names etc. Re-use.
No new code needed, no changes needed. Keep it simple.
Well, it depends - it can be useful to get the information about it
being a different part into DT so that if in future we realise that
there is some difference (perhaps a bug workaround even if the IP is
intended to be the same). Though in the case of a MFD that information
can be obtained from the MFD for the device.
We can always differentiate later and introduce new compatible.
Declaring a compatible right now would be useful only if we really cared
about using the workaround on older DTBs.
Since I cannot judge the difference (I don't have the datasheet of
S2MPS15) then I don't see the need of adding new compatible/name for the
"same device".
Of course maybe there is such need? Alim?
Well I did think of keeping the changes as minimal as possible, like
just have "{ "s2mps15-rtc",S2MPS14X }", since I don't have
access to s2mps14 UM, I could not confirm that s2mps14 and s2mps15 are
exactly the same w.r.t rtc block. So I proposed the current changes.
Well I do agree with Mark here, a name/compatible matching with the pmic
is good to at least avoid confusion while looking at the sysfs.
What kind of confusion in sysfs? I don't see any... and already the
s2mps14-rtc name is used for S2MPS11 and S2MPS14.
The s2mps13 clock driver added new name and compatible... which was
probably totally unneeded (I missed that during review). We don't have
to make this as a rule...
Since we do not have any data about future workarounds and the
differences then just follow Ockham's razor - use the same name and
compatible.
ok, have request s2smp14 UM, will cross check and update accordingly.
Thanks.
Best regards,
Krzysztof
--
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] efi: replace GFP_KERNEL with GFP_ATOMIC
replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
should be atomic
GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
fail but certainly avoids deadlock
Signed-off-by: Saurabh Sengar
---
drivers/firmware/efi/vars.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 70a0fb1..d4eeebf 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -322,10 +322,11 @@ static unsigned long var_name_strnsize(efi_char16_t
*variable_name,
* disable the sysfs workqueue since the firmware is buggy.
*/
static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
-unsigned long len16)
+unsigned long len16, bool atomic)
{
size_t i, len8 = len16 / sizeof(efi_char16_t);
char *str8;
+ int gfp_mask;
/*
* Disable the workqueue since the algorithm it uses for
@@ -334,7 +335,12 @@ static void dup_variable_bug(efi_char16_t *str16,
efi_guid_t *vendor_guid,
*/
efivar_wq_enabled = false;
- str8 = kzalloc(len8, GFP_KERNEL);
+ if (atomic)
+ gfp_mask = GFP_ATOMIC;
+ else
+ gfp_mask = GFP_KERNEL;
+
+ str8 = kzalloc(len8, gfp_mask);
if (!str8)
return;
@@ -408,7 +414,7 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t,
unsigned long, void *),
if (duplicates &&
variable_is_present(variable_name, _guid,
head)) {
dup_variable_bug(variable_name, _guid,
-variable_name_size);
+variable_name_size, atomic);
if (!atomic)
spin_lock_irq(&__efivars->lock);
--
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 3/4] mm/hugetlb: page faults check for fallocate hole punch in progress and wait
On Tue, 20 Oct 2015, Mike Kravetz wrote:
> At page fault time, check i_private which indicates a fallocate hole punch
> is in progress. If the fault falls within the hole, wait for the hole
> punch operation to complete before proceeding with the fault.
>
> Signed-off-by: Mike Kravetz
> ---
> mm/hugetlb.c | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 3c7db92..2a5e9b4 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3580,6 +3580,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> struct page *pagecache_page = NULL;
> struct hstate *h = hstate_vma(vma);
> struct address_space *mapping;
> + struct inode *inode = file_inode(vma->vm_file);
> int need_wait_lock = 0;
>
> address &= huge_page_mask(h);
> @@ -3603,6 +3604,44 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> idx = vma_hugecache_offset(h, vma, address);
>
> /*
> + * page faults could race with fallocate hole punch. If a page
> + * is faulted between unmap and deallocation, it will still remain
> + * in the punched hole. During hole punch operations, a hugetlb_falloc
> + * structure will be pointed to by i_private. If this fault is for
> + * a page in a hole being punched, wait for the operation to finish
> + * before proceeding.
> + *
> + * Even with this strategy, it is still possible for a page fault to
> + * race with hole punch. In this case, remove_inode_hugepages() will
> + * unmap the page and then remove. Checking i_private as below should
> + * catch most of these races as we want to minimize unmapping a page
> + * multiple times.
> + */
> + if (unlikely(inode->i_private)) {
> + struct hugetlb_falloc *hugetlb_falloc;
> +
> + spin_lock(>i_lock);
> + hugetlb_falloc = inode->i_private;
> + if (hugetlb_falloc && hugetlb_falloc->waitq &&
Not important, but that "&& hugetlb_falloc->waitq " is redundant.
> + idx >= hugetlb_falloc->start &&
> + idx <= hugetlb_falloc->end) {
Not important, but "idx < hugetlb_falloc->end" would be better.
> + wait_queue_head_t *hugetlb_falloc_waitq;
> + DEFINE_WAIT(hugetlb_fault_wait);
> +
> + hugetlb_falloc_waitq = hugetlb_falloc->waitq;
> + prepare_to_wait(hugetlb_falloc_waitq,
> + _fault_wait,
> + TASK_UNINTERRUPTIBLE);
> + spin_unlock(>i_lock);
> + schedule();
> +
> + spin_lock(>i_lock);
> + finish_wait(hugetlb_falloc_waitq, _fault_wait);
> + }
> + spin_unlock(>i_lock);
> + }
> +
> + /*
>* Serialize hugepage allocation and instantiation, so that we don't
>* get spurious allocation failures if two CPUs race to instantiate
>* the same page in the page cache.
> --
> 2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/5] cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate()
On Tuesday, October 13, 2015 01:39:01 PM Viresh Kumar wrote: > 'timer_mutex' is required to sync work-handlers of policy->cpus. > update_sampling_rate() is just canceling the works and queuing them > again. This isn't protecting anything at all in update_sampling_rate() > and is not gonna be of any use. > > Even if a work-handler is already running for a CPU, > cancel_delayed_work_sync() will wait for it to finish. > > Drop these unnecessary locks. > > Reviewed-by: Preeti U Murthy > Signed-off-by: Viresh Kumar I'm queuing this up for 4.4, although I think that the changelog is not right. While at it, what are the race conditions the lock is protecting against? Thanks, Rafael -- 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/4] hugetlbfs fallocate hole punch race with page faults
On Tue, 20 Oct 2015, Mike Kravetz wrote: > The hugetlbfs fallocate hole punch code can race with page faults. The > result is that after a hole punch operation, pages may remain within the > hole. No other side effects of this race were observed. > > In preparation for adding userfaultfd support to hugetlbfs, it is desirable > to close the window of this race. This patch set starts by using the same > mechanism employed in shmem (see commit f00cdc6df7). This greatly reduces > the race window. However, it is still possible for the race to occur. > > The current hugetlbfs code to remove pages did not deal with pages that > were mapped (because of such a race). This patch set also adds code to > unmap pages in this rare case. This unmapping of a single page happens > under the hugetlb_fault_mutex, so it can not be faulted again until the > end of the operation. > > v2: > Incorporated Andrew Morton's cleanups and added suggested comments > Added patch 4/4 to unmap single pages in remove_inode_hugepages > > Mike Kravetz (4): > mm/hugetlb: Define hugetlb_falloc structure for hole punch race > mm/hugetlb: Setup hugetlb_falloc during fallocate hole punch > mm/hugetlb: page faults check for fallocate hole punch in progress and > wait > mm/hugetlb: Unmap pages to remove if page fault raced with hole punch > > fs/hugetlbfs/inode.c| 155 > > include/linux/hugetlb.h | 10 > mm/hugetlb.c| 39 > 3 files changed, 141 insertions(+), 63 deletions(-) With the addition of i_mmap_lock_write() around hugetlb_vmdelete_list() in 4/4 (that you already sent a patch for), and two very minor and inessential mods to the test in 3/4 that I'll suggest in reply to that, this all looks correct to me. And yet, and yet... ... I have to say that it looks like a bunch of unnecessary complexity: for which the only justification you give is above, not in any of the patches: "In preparation for adding userfaultfd support to hugetlbfs, it is desirable to close the window of this race" (pages faulted into the hole during holepunch may be left there afterwards). Of course, the code you've sampled from shmem.c is superb ;) and it all should work as you have it (and I wouldn't want to tinker with it, to try and make it simpler here, it's just to easy to get it wrong); but it went into shmem.c for very different reasons. I don't know whether you studied the sequence of 1aac1400319d before, then f00cdc6df7d7 which you cite, then 8e205f779d14 which corrected it, then b1a366500bd5 which plugged the remaining holes: I had to refresh my memory of how it came to be like this. The driving reasons for it in shmem.c were my aversion to making the shmem inode any bigger for such an offbeat case (but hugetlbfs wouldn't expect a large number of tiny files, to justify such space saving); my aversion to adding further locking into the fast path of shmem_fault(); the fact that we already had this fallocate range checking mechanism from the earliest of those commits; and the CVE number that meant that the starvation issue had to be taken more seriously than it deserved. One of the causes of that starvation issue was the fallback unmapping of single pages within the holepunch loop: your 4/4 actually introduces that into hugetlbfs for the first time. Another cause of the starvation issue was the "for ( ; ; )" pincer loop that I reverted in the last of those commits above: whereas hugetlbfs just has a straightforward start to end loop there. It's inherent in the nature of holepunching, that immediately after the holepunch someone may fault into the hole: I wouldn't have bothered to make those changes in shmem.c, if there hadn't been the CVE starvation issue - which I doubt hugetlbfs has before your changes. But I've found some linux-mm mail from you to Andrea on Sep 30, in a 00/12 userfaultfd thread, where you say "I would like a mechanism to catch all new huge page allocations as a result of page faults" and "They would like to 'catch' any tasks that (incorrectly) fault in a page after hole punch". I confess I've not done my userfaultfd homework: perhaps it does give you very good reason for this hugetlbfs holepunch-fault race series, but I'd really like you to explain that in more detail, before I can Ack it. But it sounds to me more as if the holes you want punched are not quite like on other filesystems, and you want to be able to police them afterwards with userfaultfd, to prevent them from being refilled. Can't userfaultfd be used just slightly earlier, to prevent them from being filled while doing the holepunch? Then no need for this patchset? Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC
On 28.10.2015 12:14, Alim Akhtar wrote:
> Hello,
>
> On 10/28/2015 07:47 AM, Krzysztof Kozlowski wrote:
>> On 28.10.2015 10:53, Mark Brown wrote:
>>> On Wed, Oct 28, 2015 at 10:29:56AM +0900, Krzysztof Kozlowski wrote:
>>>
If that's true, then don't add new compatibles, new names etc. Re-use.
No new code needed, no changes needed. Keep it simple.
>>>
>>> Well, it depends - it can be useful to get the information about it
>>> being a different part into DT so that if in future we realise that
>>> there is some difference (perhaps a bug workaround even if the IP is
>>> intended to be the same). Though in the case of a MFD that information
>>> can be obtained from the MFD for the device.
>>
>> We can always differentiate later and introduce new compatible.
>> Declaring a compatible right now would be useful only if we really cared
>> about using the workaround on older DTBs.
>>
>> Since I cannot judge the difference (I don't have the datasheet of
>> S2MPS15) then I don't see the need of adding new compatible/name for the
>> "same device".
>>
>> Of course maybe there is such need? Alim?
>>
> Well I did think of keeping the changes as minimal as possible, like
> just have "{ "s2mps15-rtc",S2MPS14X }", since I don't have
> access to s2mps14 UM, I could not confirm that s2mps14 and s2mps15 are
> exactly the same w.r.t rtc block. So I proposed the current changes.
>
> Well I do agree with Mark here, a name/compatible matching with the pmic
> is good to at least avoid confusion while looking at the sysfs.
What kind of confusion in sysfs? I don't see any... and already the
s2mps14-rtc name is used for S2MPS11 and S2MPS14.
The s2mps13 clock driver added new name and compatible... which was
probably totally unneeded (I missed that during review). We don't have
to make this as a rule...
Since we do not have any data about future workarounds and the
differences then just follow Ockham's razor - use the same name and
compatible.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] serial: support 16-bit register interface for console
Hi Peter, 2015-10-27 22:53 GMT+09:00 Peter Hurley : > Hi Masahiro, > > On 10/26/2015 12:11 AM, Masahiro Yamada wrote: >> Currently, 8-bit (MMIO) and 32-bit (MMIO32) register interfaces are >> supported for the 8250 console, but the 16-bit (MMIO16) is not. >> The 8250 UART device on my board is connected to a 16-bit bus >> and my main motivation is to use earlycon with it. >> (Refer to arch/arm/boot/dts/uniphier-support-card.dtsi) > > As I noted in reviewing v2, the patch hunk below does not apply. > You must rebase your changes on top of Greg's tty-next tree. > Sorry, I missed your comment on v2. I will send v4. -- Best Regards Masahiro Yamada -- 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] phy: core: Get a refcount to phy in devm_of_phy_get_by_index()
On driver detach, devm_phy_release() will put a refcount to
the phy, so gets a refconut to it before return.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-core.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index fc48fac..8c7f27d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -636,8 +636,9 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @np: node containing the phy
* @index: index of the phy
*
- * Gets the phy using _of_phy_get(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
+ * Gets the phy using _of_phy_get(), then gets a refcount to it,
+ * and associates a device with it using devres. On driver detach,
+ * release function is invoked on the devres data,
* then, devres data is freed.
*
*/
@@ -651,13 +652,21 @@ struct phy *devm_of_phy_get_by_index(struct device *dev,
struct device_node *np,
return ERR_PTR(-ENOMEM);
phy = _of_phy_get(np, index);
- if (!IS_ERR(phy)) {
- *ptr = phy;
- devres_add(dev, ptr);
- } else {
+ if (IS_ERR(phy)) {
devres_free(ptr);
+ return phy;
}
+ if (!try_module_get(phy->ops->owner)) {
+ devres_free(ptr);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ get_device(>dev);
+
+ *ptr = phy;
+ devres_add(dev, ptr);
+
return phy;
}
EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
--
1.8.1.1.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/
Re: [PATCH v2 1/2] serial: 8250_early: do not save and restore IER in write callback
Hi Peter,
2015-10-27 22:54 GMT+09:00 Peter Hurley :
> Hi Masahiro,
>
> On 10/24/2015 12:17 AM, Masahiro Yamada wrote:
>> The IER has already been masked in early_serial8250_setup(), there is
>> no reason to save and restore it every time early_serial8250_write()
>> is called.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> drivers/tty/serial/8250/8250_early.c | 12
>> 1 file changed, 12 deletions(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_early.c
>> b/drivers/tty/serial/8250/8250_early.c
>> index 7aff3d8..559b681 100644
>> --- a/drivers/tty/serial/8250/8250_early.c
>> +++ b/drivers/tty/serial/8250/8250_early.c
>> @@ -99,20 +99,8 @@ static void __init early_serial8250_write(struct console
>> *console,
>> {
>> struct earlycon_device *device = console->data;
>> struct uart_port *port = >port;
>> - unsigned int ier;
>> -
>> - /* Save the IER and disable interrupts preserving the UUE bit */
>> - ier = serial8250_early_in(port, UART_IER);
>> - if (ier)
>> - serial8250_early_out(port, UART_IER, ier & UART_IER_UUE);
>>
>> uart_console_write(port, s, count, serial_putc);
>
>
>
>> -
>> - /* Wait for transmitter to become empty and restore the IER */
>> - wait_for_xmitr(port);
>
> This wait_for_xmitr() change needs to be in patch 2/2.
>
Why?
We no longer restore the IER.
We no longer have to wait here, either.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC
Hello,
On 10/28/2015 07:47 AM, Krzysztof Kozlowski wrote:
On 28.10.2015 10:53, Mark Brown wrote:
On Wed, Oct 28, 2015 at 10:29:56AM +0900, Krzysztof Kozlowski wrote:
If that's true, then don't add new compatibles, new names etc. Re-use.
No new code needed, no changes needed. Keep it simple.
Well, it depends - it can be useful to get the information about it
being a different part into DT so that if in future we realise that
there is some difference (perhaps a bug workaround even if the IP is
intended to be the same). Though in the case of a MFD that information
can be obtained from the MFD for the device.
We can always differentiate later and introduce new compatible.
Declaring a compatible right now would be useful only if we really cared
about using the workaround on older DTBs.
Since I cannot judge the difference (I don't have the datasheet of
S2MPS15) then I don't see the need of adding new compatible/name for the
"same device".
Of course maybe there is such need? Alim?
Well I did think of keeping the changes as minimal as possible, like
just have "{ "s2mps15-rtc",S2MPS14X }", since I don't have
access to s2mps14 UM, I could not confirm that s2mps14 and s2mps15 are
exactly the same w.r.t rtc block. So I proposed the current changes.
Well I do agree with Mark here, a name/compatible matching with the pmic
is good to at least avoid confusion while looking at the sysfs.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] PM / suspend: replacing printk
replacing printk(s) with appropriate pr_info and pr_err
in order to fix checkpatch.pl warnings
Signed-off-by: Saurabh Sengar
---
kernel/power/suspend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7e4cda4..7fec885 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -245,7 +245,7 @@ static int suspend_test(int level)
{
#ifdef CONFIG_PM_DEBUG
if (pm_test_level == level) {
- printk(KERN_INFO "suspend debug: Waiting for %d second(s).\n",
+ pr_info("suspend debug: Waiting for %d second(s).\n",
pm_test_delay);
mdelay(pm_test_delay * 1000);
return 1;
@@ -317,7 +317,7 @@ static int suspend_enter(suspend_state_t state, bool
*wakeup)
error = dpm_suspend_late(PMSG_SUSPEND);
if (error) {
- printk(KERN_ERR "PM: late suspend of devices failed\n");
+ pr_err("PM: late suspend of devices failed\n");
goto Platform_finish;
}
error = platform_suspend_prepare_late(state);
@@ -326,7 +326,7 @@ static int suspend_enter(suspend_state_t state, bool
*wakeup)
error = dpm_suspend_noirq(PMSG_SUSPEND);
if (error) {
- printk(KERN_ERR "PM: noirq suspend of devices failed\n");
+ pr_err("PM: noirq suspend of devices failed\n");
goto Platform_early_resume;
}
error = platform_suspend_prepare_noirq(state);
--
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] KVM: x86: fix eflags state following processor init/reset
Ping, :-) On 10/21/15 2:28 PM, Wanpeng Li wrote: Reference SDM 3.4.3: Following initialization of the processor (either by asserting the RESET pin or the INIT pin), the state of the EFLAGS register is 0002H. However, the eflags fixed bit is not set and other bits are also not cleared during the init/reset in kvm. This patch fix it by set eflags register to 0002H following initialization of the processor. Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index b680c2e..326f6ea 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -4935,6 +4935,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) vmx_set_efer(vcpu, 0); vmx_fpu_activate(vcpu); update_exception_bitmap(vcpu); + vmx_set_rflags(vcpu, X86_EFLAGS_FIXED); vpid_sync_context(vmx->vpid); } -- 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/7 v2] powerpc/dma-mapping: override dma_get_page_shift
On Tue, 2015-10-27 at 19:30 -0700, Nishanth Aravamudan wrote: > On 28.10.2015 [11:20:05 +0900], Benjamin Herrenschmidt wrote: > > On Tue, 2015-10-27 at 18:54 -0700, Nishanth Aravamudan wrote: > > > > > > In "bypass" mode, what TCE size is used? Is it guaranteed to be > > > 4K? > > > > None :-) The TCEs are completely bypassed. You get a N:M linear > > mapping > > of all memory starting at 1<<59 PCI side. > > Err, duh, sorry! Ok, so in that case, DMA page shift is PAGE_SHIFT, > then? I think so. Cheers, Ben. -- 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] ARM: perf: ensure the cpu is available to scheduler when set irq affinity
On Wed, Oct 28, 2015 at 12:47 AM, Will Deacon wrote: >> + continue; >> + > > Isn't this all racy against concurrent hotplug events? We're probably > better off requesting the IRQs at PMU probe time, since we no longer have > to worry about sharing the IRQ lines with other subsystems such as oprofile, > which is why it was designed this way originally. Could you write a patch? Thanks -Roy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] PM / suspend: replacing printk
replacing printk(s) with appropriate pr_info and pr_err
in order to fix checkpatch.pl warnings.
Signed-off-by: Saurabh Sengar
---
kernel/power/suspend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7e4cda4..7fec885 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -245,7 +245,7 @@ static int suspend_test(int level)
{
#ifdef CONFIG_PM_DEBUG
if (pm_test_level == level) {
- printk(KERN_INFO "suspend debug: Waiting for %d second(s).\n",
+ pr_info("suspend debug: Waiting for %d second(s).\n",
pm_test_delay);
mdelay(pm_test_delay * 1000);
return 1;
@@ -317,7 +317,7 @@ static int suspend_enter(suspend_state_t state, bool
*wakeup)
error = dpm_suspend_late(PMSG_SUSPEND);
if (error) {
- printk(KERN_ERR "PM: late suspend of devices failed\n");
+ pr_err("PM: late suspend of devices failed\n");
goto Platform_finish;
}
error = platform_suspend_prepare_late(state);
@@ -326,7 +326,7 @@ static int suspend_enter(suspend_state_t state, bool
*wakeup)
error = dpm_suspend_noirq(PMSG_SUSPEND);
if (error) {
- printk(KERN_ERR "PM: noirq suspend of devices failed\n");
+ pr_err("PM: noirq suspend of devices failed\n");
goto Platform_early_resume;
}
error = platform_suspend_prepare_noirq(state);
--
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/
[PATCH] of: simplify arch_find_n_match_cpu_physical_id() function
This commit does not change the function behavior. Signed-off-by: Masahiro Yamada --- drivers/of/base.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index 8b5a187..017dd94 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -375,10 +375,7 @@ bool __weak arch_find_n_match_cpu_physical_id(struct device_node *cpun, cpu, thread)) return true; - if (__of_find_n_match_cpu_property(cpun, "reg", cpu, thread)) - return true; - - return false; + return __of_find_n_match_cpu_property(cpun, "reg", cpu, thread); } /** -- 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 5/8] mm: memcontrol: account socket memory on unified hierarchy
On Tue, Oct 27, 2015 at 05:45:32PM -0700, David Miller wrote: > From: Johannes Weiner > Date: Tue, 27 Oct 2015 09:42:27 -0700 > > > On Tue, Oct 27, 2015 at 05:15:54PM +0100, Michal Hocko wrote: > >> > For now, something like this as a boot commandline? > >> > > >> > cgroup.memory=nosocket > >> > >> That would work for me. > > > > Okay, then I'll go that route for the socket stuff. > > > > Dave is that cool with you? > > Depends upon the default. > > Until the user configures something explicitly into the memory > controller, the networking bits should all evaluate to nothing. Yep, I'll stick them behind a default-off jump label again. This bootflag is only to override an active memory controller configuration and force-off that jump label permanently. -- 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] vmstat: Create our own workqueue
On Wed, 28 Oct 2015, Tejun Heo wrote:
> The only thing necessary here is WQ_MEM_RECLAIM. I don't see how
> WQ_SYSFS and WQ_FREEZABLE make sense here.
Subject: vmstat: Remove WQ_FREEZABLE and WQ_SYSFS
Signed-off-by: Christoph Lameter
Index: linux/mm/vmstat.c
===
--- linux.orig/mm/vmstat.c
+++ linux/mm/vmstat.c
@@ -1546,8 +1546,6 @@ static int __init setup_vmstat(void)
start_shepherd_timer();
cpu_notifier_register_done();
vmstat_wq = alloc_workqueue("vmstat",
- WQ_FREEZABLE|
- WQ_SYSFS|
WQ_MEM_RECLAIM, 0);
#endif
#ifdef CONFIG_PROC_FS
--
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 RESEND v2 net-next] net: hisilicon: updates HNS config and documents
From: huangdaode Date: Tue, 27 Oct 2015 19:16:34 +0800 > From: yankejian > > updates the bindings documents and dtsi file according to the review > comments[https://lkml.org/lkml/2015/9/21/670] from Rob Herring > > > Acked-by: Rob Herring > Signed-off-by: yankejian > Signed-off-by: huangdaode Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vhost: fix performance on LE hosts
From: "Michael S. Tsirkin"
Date: Tue, 27 Oct 2015 11:37:39 +0200
> commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian
> support for legacy devices") introduced a minor regression: even with
> cross-endian disabled, and even on LE host, vhost_is_little_endian is
> checking is_le flag so there's always a branch.
>
> To fix, simply check virtio_legacy_is_little_endian first.
>
> Cc: Greg Kurz
> Signed-off-by: Michael S. Tsirkin
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/70] cpufreq: interactive: New 'interactive' governor
Hi Bálint, On 28-10-15, 01:59, Rafael J. Wysocki wrote: > On Tuesday, October 27, 2015 06:29:49 PM Bálint Czobor wrote: > > From: Mike Chan > > > > This governor is designed for latency-sensitive workloads, such as > > interactive user interfaces. The interactive governor aims to be > > significantly more responsive to ramp CPU quickly up when CPU-intensive > > activity begins. > > > > Existing governors sample CPU load at a particular rate, typically > > every X ms. This can lead to under-powering UI threads for the period of > > time during which the user begins interacting with a previously-idle system > > until the next sample period happens. > > > > The 'interactive' governor uses a different approach. Instead of sampling > > the CPU at a specified rate, the governor will check whether to scale the > > CPU frequency up soon after coming out of idle. When the CPU comes out of > > idle, a timer is configured to fire within 1-2 ticks. If the CPU is very > > busy from exiting idle to when the timer fires then we assume the CPU is > > underpowered and ramp to MAX speed. > > > > If the CPU was not sufficiently busy to immediately ramp to MAX speed, then > > the governor evaluates the CPU load since the last speed adjustment, > > choosing the highest value between that longer-term load or the short-term > > load since idle exit to determine the CPU speed to ramp to. > > > > A realtime thread is used for scaling up, giving the remaining tasks the > > CPU performance benefit, unlike existing governors which are more likely to > > schedule rampup work to occur after your performance starved tasks have > > completed. > > > > The tuneables for this governor are: > > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time: > > The minimum amount of time to spend at the current frequency before > > ramping down. This is to ensure that the governor has seen enough > > historic CPU load data to determine the appropriate workload. > > Default is 8 uS. > > /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load > > The CPU load at which to ramp to max speed. Default is 85. > > > > Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585 > > Signed-off-by: Mike Chan > > Signed-off-by: Todd Poynor > > Bug: 3152864 > > Signed-off-by: Bálint Czobor > > It's good to see that submitted, but it'll have to go through a detailed > review which is going to take some time. These are the last memories I have around upstreaming this governor: http://marc.info/?l=linux-kernel=132867057910479=2 Has anything changed after that? Or we decided to go ahead with it and upstream ? > One my observation after a cursory look at it is that at least some later > patches of the series modify drivers/cpufreq/cpufreq_interactive.c which is > a new file added by the first patch. Is there any particular reason to > avoid folding all of those patches into the first one? Right, not to discourage you from upstreaming stuff, but there were few things that went wrong here: - I don't see the idle_notifier_register thing present in upstream kernel for anything other than x86, and I am sure you were targeting ARM here :) - And I don't see the same stuff present in your patchset as well, sorry if I am wrong. And if I am write, you didn't even base this of a mainline release and compile tested it. - 70 patches in a series are really really huge. I wouldn't expect people to review any of that. Though to be fair enough, I must admit of doing similar things in the past :) - There is something called as a cover-letter (in case you aren't aware about it), which should have been written here to give a really nice summary about what you are trying to do here. There are non-ARM people, who wouldn't have known about this stuff at all until now. - Mainline doesn't care about history of commits that are present in a non-mainline repository, even if it is android. Yeah, you screw up a bit here as people loose their credits for what they have worked on. But it should really have been 1-3 patches ONLY for the governor. And maybe a patchset of 5-7 patches, but it can be much lesser as well. Cc'ing Peter/Ingo for their inputs.. -- viresh -- 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] net: hns: fixes the bug tested XGE by ethtool -p
From: yankejian Date: Tue, 27 Oct 2015 17:17:40 +0800 > From: Li Peng > > delete action of ETHTOOL_ID_ON/ETHTOOL_ID_OFF in XGE ethtool -p, > so Hardware control the LED state instead of software. > > Signed-off-by: Li Peng > Signed-off-by: Yisen Zhuang > Signed-off-by: yankejian Applied. -- 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] intel_pstate, decrease number of "HWP enabled" messages
On Thursday, October 22, 2015 09:43:31 AM Prarit Bhargava wrote: > When booting an HWP enabled system the kernel displays one "HWP enabled" > message for each cpu. The messages are superfluous since HWP is globally > enabled across all CPUs. This patch also adds an informational message > when HWP is disabled via intel_pstate=no_hwp. > > Cc: Kristen Carlson Accardi > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > Signed-off-by: Prarit Bhargava Applied, thanks! Rafael -- 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/5] crypto: add algif_akcipher user space API
Hi Stephan, >> So if a server has public/private key pair, then the first thing that should >> the server do is load this key pair into the kernel and retrieve a key >> serial for it. And then use this key id to derive the session key. That >> session key can then be used with AF_ALG and skcipher for the data >> shoveling. >> >> However that all said, the keys should never leave the kernel. Neither the > > I personally do not fully agree here. For our day-to-day desktops and servers > I would fully and completely agree. But I see other use cases of Linux in > routers or other embedded systems where there may be other checks and > balances > in place where this hard demand is not warranted. actually in embedded devices (especially the tiny IoT stuff I am looking after) I really want keys in a central place and do not have to copy them around all the time. Keeping keys secure is actually a hard job. Doing that multiple places in the kernel and in userspace seems not a good idea. Especially not for an embedded device. The keys subsystem is great since it includes access control to your keys. If you have the right permissions you can get the keys back out if you want to. However if the key is locked down, you will not be able to read it again. I mean the keys subsystem can operate on per user, per process and per thread keys and access rights. So the policy that you are after is already done nicely via the keys subsystem. I really don't think we are limiting anything here. We are actually giving users more choice for policy. > Thus, I feel that this is a policy decision to be made in user space (see my > other email -- please answer on that topic there to keep a single thread). > >> private key nor the session key. There is no point in sending keys through >> userspace. We actually do not want this at all. That is especially >> important if your actual private/public key pair is in hardware. So maybe >> your RSA accelerator might expose secure storage for the keys. Loading them >> over and over again from userspace makes no sense. >> >> As David mentioned, we need to take a deep look at what the userspace API >> for asymmetric cipher suites (and we also have needs for ECDH etc. and not >> just RSA) should look like. Just exposing akcipher via AF_ALG is premature. >> If we expose it now, it is not an API that we can take back. Having two >> userspace APIs for the exactly the same functionality is a bad thing. >> Especially if one is limited to software only keys. > > Do not get me wrong, my patch is shall be there for all to comment. I have no > issues when we find a better solution. And I also do not like multiple > interfaces that would not be needed if we would have thought better. >> >> We also need to look at the larger picture here. And that is TLS support in >> the kernel. Potentially via AF_KCM or something similar. > > With all due respect, I would object here. When we say yes to TLS (even if it > is parts of TLS up to the point where the KDF happens), we invite all higher > level crypto implementations: IKE, SNMP, SSH -- I would not want to go down > that path that started by simply supporting accelerated asymmetric ciphers. Reality is that TLS in the kernel is happening. Reality is also that we do signing and certificate handling in the kernel. How much of the cipher negotiations and key derivation happens in kernel vs userspace is something to be still discussed. And there will be userspace involved for sure. However that does not mean that we keep moving keys through userspace to just load it back into another subsystem. That kind of API really needs to stop. One other note I make is that we are looking at such tiny systems that including OpenSSL or GnuTLS is not an option at all. However we do use secure boot and need to be able to handle certificates and TLS. > Look at user space crypto libs: where is the most fuzz happening? Not in the > cipher implementations, but in the network protocols. Ciphers itself are easy of course. What we are saying here is that we do not have the cipher as the main important input on what to do. We have the key itself. The key decides what options for ciphers or fallback ciphers we have. So let me repeat this, we need to think really hard about supporting hardware keys. We need to see the bigger picture. Just looking at ciphers is not enough. Regards Marcel -- 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 net] macvtap: unbreak receiving of gro skb with frag list
On 10/27/2015 05:05 PM, Michael S. Tsirkin wrote:
> On Tue, Oct 27, 2015 at 10:58:25AM +0800, Jason Wang wrote:
>>
>> On 10/26/2015 04:30 PM, Michael S. Tsirkin wrote:
>>> On Mon, Oct 26, 2015 at 02:53:38PM +0800, Jason Wang wrote:
On 10/26/2015 02:09 PM, Michael S. Tsirkin wrote:
> On Mon, Oct 26, 2015 at 11:15:57AM +0800, Jason Wang wrote:
>> On 10/23/2015 09:37 PM, Michael S. Tsirkin wrote:
>>> On Fri, Oct 23, 2015 at 12:57:05AM -0400, Jason Wang wrote:
We don't have fraglist support in TAP_FEATURES. This will lead
software segmentation of gro skb with frag list. Fixes by having
frag list support in TAP_FEATURES.
With this patch single session of netperf receiving were restored from
about 5Gb/s to about 12Gb/s on mlx4.
Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
Cc: Vlad Yasevich
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
>>> Thanks!
>>> Does this mean we should look at re-adding NETIF_F_FRAGLIST
>>> to virtio-net as well?
>> Not sure I get the point, but probably not. This is for receiving and
>> skb_copy_datagram_iter() can deal with frag list.
> Point is:
> - bridge within guest
> - assigned device creating gro skbs with frag list bridged to virtio
I see, but this problem looks not specific to virtio. Most cards does
not support frag list.
>>> These will be slower when used with a bridge then, won't they?
>> For forwarding, not sure. GRO has latency and cpu overhead anyway.
> Right but that's up to the user. You aren't disabling GRO
> on source, you are just splitting it up.
>
>> Anyway I can try to add the support for this.
> Which reminds me: on modern devices there are commands to control
> offloads, so for these, we should support turning offloads on/off using
> ethtool.
>
Trying to implement frag list but see a problem. Looks like driver need
to scan the possible number of io vectors? (Since vhost support max to
UIO_MAXIOV number of io vectors). Looks like there's no clarification on
this in the spec. (Which only limit the length of descriptor chain to
Queue size).
--
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] virtio_pci: Use the DMA API
On Wed, Oct 28, 2015 at 11:22:52AM +0900, David Woodhouse wrote: > On Wed, 2015-10-28 at 11:15 +0900, Joerg Roedel wrote: > > I think a good test for that is to boot a virtio kvm-guest with > > swiotlb=force and see if it still works. > > That's useful but doesn't cover the cases where dma_wmb() is needed, > right? > > We should make sure we're handling descriptors properly as we would for > real hardware, and ensuring that addresses etc. are written to the > descriptor (and a write barrier occurs) *before* the bit is set which > tells the 'hardware' that it owns that descriptor. Hmm, good question. The virtio code has virtio_rmb/wmb and should already call it in the right places. The virtio-barriers default to rmb()/wmb() unless weak_barriers is set, in which case it calls dma_rmb()/wmb(), just a compiler barrier on x86. And weak_barriers is set by the virtio drivers when creating the queue, and the drivers should know what they are doing. Saying this, I think the virtio-drivers should already get this right. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][v2] Fix incorrect using of acpi irq
On Sunday, October 25, 2015 01:02:07 AM Chen Yu wrote: > This series of patches are trying to convert codes who use > acpi_gbl_FADT.sci_interrupt incorrectly to use the right irq > mapped by acpi_gsi_to_irq. > > Chen Yu (3): > ACPI: Using correct irq when uninstalling acpi irq handler > ACPI: Using correct irq when waiting for events > ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle > > drivers/acpi/osl.c | 14 +- > drivers/acpi/sleep.c | 6 -- > include/linux/acpi.h | 6 ++ > 3 files changed, 19 insertions(+), 7 deletions(-) Series applied (with some minor changes to patch subjects and changelogs). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] perf: we can now read separate debug-info files based on a build ID
Hi. I'd like to get this merged before I forget about it and then I hit this bug again at some point in the future. Any comment would be great. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI/PAD: power_saving_thread() is not freezable
On Monday, October 26, 2015 04:02:01 AM Jiri Kosina wrote:
> From: Jiri Kosina
>
> power_saving_thread() calls try_to_freeze(), but the thread doesn't mark
> itself freezable through set_freezable(), so the try_to_freeze()
> call is useless.
>
> Signed-off-by: Jiri Kosina
> ---
> drivers/acpi/acpi_pad.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index ae307ff..8ea8211 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -148,8 +148,6 @@ static int power_saving_thread(void *data)
> while (!kthread_should_stop()) {
> unsigned long expire_time;
>
> - try_to_freeze();
> -
> /* round robin to cpus */
> expire_time = last_jiffies + round_robin_time * HZ;
> if (time_before(expire_time, jiffies)) {
>
Applied, thanks!
Rafael
--
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] acpi:correctly check failed allocation
On Thursday, October 15, 2015 12:19:30 PM Insu Yun wrote:
> Since kobject_create_and_add can be failed in memory pressure,
> return value need to be checked and return ENOMEM.
>
> Signed-off-by: Insu Yun
> ---
> drivers/acpi/sysfs.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
> index 40a4265..e712a7b 100644
> --- a/drivers/acpi/sysfs.c
> +++ b/drivers/acpi/sysfs.c
> @@ -878,6 +878,8 @@ int __init acpi_sysfs_init(void)
> return result;
>
> hotplug_kobj = kobject_create_and_add("hotplug", acpi_kobj);
> + if (!hotplug_kobj)
> +return -ENOMEM;
> result = sysfs_create_file(hotplug_kobj, _remove_attr.attr);
> if (result)
> return result;
>
Applied (with whitespace fixed), thanks!
Rafael
--
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] hwmon: ina2xx: convert driver to using regmap
On Tue, Oct 27, 2015 at 10:51:07AM +0100, Marc Titinger wrote: > Any sysfs "show" read access from the client app will result in reading > all registers (8 with ina226). Depending on the host this can limit the > best achievable read rate. > > This changeset allows for individual register accesses through regmap. > > Tested with BeagleBone Black (Baylibre-ACME) and ina226. > > Signed-off-by: Marc Titinger > --- > > v2: > - rename 'rv' to 'regval' for clarity > - fix missed smbus_xxx api change to regmap > - rename ina2xx_do_update to ina2xx_read_reg > - fix indentation > > drivers/hwmon/ina2xx.c | 211 > +++-- > 1 file changed, 82 insertions(+), 129 deletions(-) > > diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c > index 4d28150..5e7ada8 100644 > --- a/drivers/hwmon/ina2xx.c > +++ b/drivers/hwmon/ina2xx.c [ ... ] > > - mutex_lock(>update_lock); > data->rshunt = val; > status = ina2xx_calibrate(data); > - mutex_unlock(>update_lock); I think this can result in a race conditon if multiple processes try to update the shunt resistor value at the same time in a multi-core system. There is no guarantee that the value programmed into the chip matches the value that is written into 'rshunt'. So I think we still need the mutex, unless you have a better idea how to avoid the race. Thanks, 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: [PATCH] Documentation: ACPI: add copy_dsdt to ACPI format options.
On Saturday, September 26, 2015 07:27:57 PM Rami Rosen wrote:
> commit aa2110cb1a7510f9b834adfb39b05d4843a35d35
> ("ACPI: add boot option acpi=copy_dsdt to fix corrupt DSDT") added
> copy_dsdt as an ACPI boot option, but did not add it to ACPI format options in
> Documentation/kernel-parameters.txt. This patch fixes it.
>
> Signed-off-by: Rami Rosen
> ---
> Documentation/kernel-parameters.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 22a4b68..bbf4ee6c 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -167,7 +167,8 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
>
> acpi= [HW,ACPI,X86,ARM64]
> Advanced Configuration and Power Interface
> - Format: { force | off | strict | noirq | rsdt }
> + Format: { force | off | strict | noirq | rsdt |
> + copy_dsdt }
> force -- enable ACPI if default was off
> off -- disable ACPI if default was on
> noirq -- do not use ACPI for IRQ routing
>
Applied, thanks!
Rafael
--
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/
spolupráce
Muzete me kontaktovat na e-mailovou adresu nize pro vysvetlení prospesny spoluprace. e-mail: chn.j...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] vmstat: Create our own workqueue
Hello,
On Tue, Oct 27, 2015 at 09:41:17PM -0500, Christoph Lameter wrote:
> + vmstat_wq = alloc_workqueue("vmstat",
> + WQ_FREEZABLE|
> + WQ_SYSFS|
> + WQ_MEM_RECLAIM, 0);
The only thing necessary here is WQ_MEM_RECLAIM. I don't see how
WQ_SYSFS and WQ_FREEZABLE make sense here.
Thanks.
--
tejun
--
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] vmstat: Make pageset processing optional in refresh_cpu_vm_stats
Add a parameter to refresh_cpu_vm_stats() to make pageset expiration
optional. Flushing the pagesets is performed by the page allocator
and thus processing of pagesets may not be wanted when just intending
to fold the differentials.
Signed-of-by: Christoph Lameter
Index: linux/mm/vmstat.c
===
--- linux.orig/mm/vmstat.c
+++ linux/mm/vmstat.c
@@ -460,7 +460,7 @@ static int fold_diff(int *diff)
*
* The function returns the number of global counters updated.
*/
-static int refresh_cpu_vm_stats(void)
+static int refresh_cpu_vm_stats(bool do_pagesets)
{
struct zone *zone;
int i;
@@ -484,33 +484,35 @@ static int refresh_cpu_vm_stats(void)
#endif
}
}
- cond_resched();
#ifdef CONFIG_NUMA
- /*
-* Deal with draining the remote pageset of this
-* processor
-*
-* Check if there are pages remaining in this pageset
-* if not then there is nothing to expire.
-*/
- if (!__this_cpu_read(p->expire) ||
+ if (do_pagesets) {
+ cond_resched();
+ /*
+* Deal with draining the remote pageset of this
+* processor
+*
+* Check if there are pages remaining in this pageset
+* if not then there is nothing to expire.
+*/
+ if (!__this_cpu_read(p->expire) ||
!__this_cpu_read(p->pcp.count))
- continue;
+ continue;
- /*
-* We never drain zones local to this processor.
-*/
- if (zone_to_nid(zone) == numa_node_id()) {
- __this_cpu_write(p->expire, 0);
- continue;
- }
+ /*
+* We never drain zones local to this processor.
+*/
+ if (zone_to_nid(zone) == numa_node_id()) {
+ __this_cpu_write(p->expire, 0);
+ continue;
+ }
- if (__this_cpu_dec_return(p->expire))
- continue;
+ if (__this_cpu_dec_return(p->expire))
+ continue;
- if (__this_cpu_read(p->pcp.count)) {
- drain_zone_pages(zone, this_cpu_ptr(>pcp));
- changes++;
+ if (__this_cpu_read(p->pcp.count)) {
+ drain_zone_pages(zone, this_cpu_ptr(>pcp));
+ changes++;
+ }
}
#endif
}
@@ -1363,7 +1365,7 @@ static cpumask_var_t cpu_stat_off;
static void vmstat_update(struct work_struct *w)
{
- if (refresh_cpu_vm_stats()) {
+ if (refresh_cpu_vm_stats(true)) {
/*
* Counters were updated so we expect more updates
* to occur in the future. Keep on running the
--
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] clocksource: sh_mtu2: Fix multiple shutdown call issue
On 28-10-15, 10:43, Magnus Damm wrote:
> From: Magnus Damm
>
> On the r7s72100 Genmai board the MTU2 driver currently triggers a common
> clock framework WARN_ON(enable_count) when disabling the clock due to
> the MTU2 driver after recent callback rework may call ->set_state_shutdown()
> multiple times. A similar issue was spotted for the TMU driver and fixed in:
> 452b132 clocksource/drivers/sh_tmu: Fix traceback spotted in -next
>
> On r7s72100 Genmai v4.3-rc7 built with shmobile_defconfig spits out the
> following during boot:
>
> sh_mtu2 fcff.timer: ch0: used for clock events
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:675 clk_core_disable+0x2c/0x6c()
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc7 #1
> Hardware name: Generic R7S72100 (Flattened Device Tree)
> Backtrace:
> [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
> r6:c0621fde r5:0009 r4: r3:00200040
> [] (show_stack) from [] (dump_stack+0x74/0x90)
> [] (dump_stack) from [] (warn_slowpath_common+0x88/0xb4)
> r4: r3:
> [] (warn_slowpath_common) from []
> (warn_slowpath_null+0x24/0x2c)
>r8:c78c0400 r7:c7ee8df8 r6: r5:61d3 r4:c7806480
>[] (warn_slowpath_null) from []
> (clk_core_disable+0x2c/0x6c)
>[] (clk_core_disable) from [] (clk_disable+0x40/0x4c)
> r4:c791be40 r3:
> [] (clk_disable) from [] (sh_mtu2_disable+0x24/0x50)
> r5:0001 r4:c7963c00
> [] (sh_mtu2_disable) from []
> (sh_mtu2_clock_event_shutdown+0x14/0x1c)
> r4:c7963c40 r3:c0395d58
> [] (sh_mtu2_clock_event_shutdown) from []
> (clockevents_switch_state+0xc8/0x114)
> [] (clockevents_switch_state) from []
> (clockevents_shutdown+0x18/0x28)
>r5:c7963c40 r4:c7963c40
>[] (clockevents_shutdown) from []
> (clockevents_exchange_device+0x70/0x78)
> r4: r3:
> [] (clockevents_exchange_device) from []
> (tick_check_new_device+0x88/0xe0)
>r5: r4:c7963c40
>[] (tick_check_new_device) from []
> (clockevents_register_device+0xac/0x120)
> r7: r6:a153 r5:c06ffe98 r4:c7963c40
> [] (clockevents_register_device) from []
> (sh_mtu2_probe+0x230/0x350)
> r6: r5:c7963c00 r4:c791b040 r3:c06ff134
> [] (sh_mtu2_probe) from []
> (platform_drv_probe+0x50/0x98)
>
> Reported-by: Chris Brandt
> Fixes: 19a9ffb ("clockevents/drivers/sh_mtu2: Migrate to new 'set-state'
> interface")
> Cc: Viresh Kumar
> Cc: Laurent Pinchart
> Signed-off-by: Magnus Damm
> ---
>
> drivers/clocksource/sh_mtu2.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- 0001/drivers/clocksource/sh_mtu2.c
> +++ work/drivers/clocksource/sh_mtu2.c2015-10-27 16:20:07.350513000
> +0900
> @@ -280,7 +280,9 @@ static int sh_mtu2_clock_event_shutdown(
> {
> struct sh_mtu2_channel *ch = ced_to_sh_mtu2(ced);
>
> - sh_mtu2_disable(ch);
> + if (clockevent_state_periodic(ced))
> + sh_mtu2_disable(ch);
> +
> return 0;
Thanks for doing this :)
Reviewed-by: Viresh Kumar -
--
viresh
--
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] vmstat: Create our own workqueue
Seems that vmstat needs its own workqueue now since the general
workqueue mechanism has been *enhanced* which means that the
vmstat_updates cannot run reliably but are being blocked by
work requests doing memory allocation. Which causes vmstat
to be unable to keep the counters up to date.
Bad. Fix this by creating our own workqueue.
Signed-off-by: Christoph Lameter
Index: linux/mm/vmstat.c
===
--- linux.orig/mm/vmstat.c
+++ linux/mm/vmstat.c
@@ -1359,6 +1359,8 @@ static const struct file_operations proc
#endif /* CONFIG_PROC_FS */
#ifdef CONFIG_SMP
+static struct workqueue_struct *vmstat_wq;
+
static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
int sysctl_stat_interval __read_mostly = HZ;
static cpumask_var_t cpu_stat_off;
@@ -1371,7 +1373,7 @@ static void vmstat_update(struct work_st
* to occur in the future. Keep on running the
* update worker thread.
*/
- schedule_delayed_work_on(smp_processor_id(),
+ queue_delayed_work_on(smp_processor_id(), vmstat_wq,
this_cpu_ptr(_work),
round_jiffies_relative(sysctl_stat_interval));
} else {
@@ -1454,7 +1456,7 @@ static void vmstat_shepherd(struct work_
if (need_update(cpu) &&
cpumask_test_and_clear_cpu(cpu, cpu_stat_off))
- schedule_delayed_work_on(cpu,
+ queue_delayed_work_on(cpu, vmstat_wq,
_cpu(vmstat_work, cpu), 0);
put_online_cpus();
@@ -1543,6 +1545,10 @@ static int __init setup_vmstat(void)
start_shepherd_timer();
cpu_notifier_register_done();
+ vmstat_wq = alloc_workqueue("vmstat",
+ WQ_FREEZABLE|
+ WQ_SYSFS|
+ WQ_MEM_RECLAIM, 0);
#endif
#ifdef CONFIG_PROC_FS
proc_create("buddyinfo", S_IRUGO, NULL, _file_operations);
--
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] vmstat: Various enhancements
This addresses a couple of issues that came up last week in the discussion about issues related to the blocking of the execution of vmstat updates. 1. It makes vmstat updates execution deferrable again so that no special tick is generated for vmstat execution. vmstat is quieted down when a processor enters idle mode. This means that no differentials exist anymore when a processor is in idle mode. 2. Create a separate workqueue so that the vmstat updater is not blocked by other work requeusts. This creates a new kernel thread and avoids the issue of differentials not folded in a timely fashion. -- 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/3] vmstat: make vmstat_updater deferrable again and shut down on idle
Currently the vmstat updater is not deferrable as a result of commit
ba4877b9ca51f80b5d30f304a46762f0509e1635. This in turn can cause multiple
interruptions of the applications because the vmstat updater may run at
different times than tick processing. No good.
Make vmstate_update deferrable again and provide a function that
shuts down the vmstat updater when we go idle by folding the differentials.
Shut it down from the load average calculation logic introduced by nohz.
Note that the shepherd thread will continue scanning the differentials
from another processor and will reenable the vmstat workers if it
detects any changes.
Fixes: ba4877b9ca51f80b5d30f304a46762f0509e1635 (do not use deferrable delay)
Signed-off-by: Christoph Lameter
Index: linux/mm/vmstat.c
===
--- linux.orig/mm/vmstat.c
+++ linux/mm/vmstat.c
@@ -1397,6 +1397,20 @@ static void vmstat_update(struct work_st
}
/*
+ * Switch off vmstat processing and then fold all the remaining differentials
+ * until the diffs stay at zero. The function is used by NOHZ and can only be
+ * invoked when tick processing is not active.
+ */
+void quiet_vmstat(void)
+{
+ do {
+ if (!cpumask_test_and_set_cpu(smp_processor_id(), cpu_stat_off))
+ cancel_delayed_work(this_cpu_ptr(_work));
+
+ } while (refresh_cpu_vm_stats(false));
+}
+
+/*
* Check if the diffs for a certain cpu indicate that
* an update is needed.
*/
@@ -1428,7 +1442,7 @@ static bool need_update(int cpu)
*/
static void vmstat_shepherd(struct work_struct *w);
-static DECLARE_DELAYED_WORK(shepherd, vmstat_shepherd);
+static DECLARE_DEFERRABLE_WORK(shepherd, vmstat_shepherd);
static void vmstat_shepherd(struct work_struct *w)
{
Index: linux/include/linux/vmstat.h
===
--- linux.orig/include/linux/vmstat.h
+++ linux/include/linux/vmstat.h
@@ -211,6 +211,7 @@ extern void __inc_zone_state(struct zone
extern void dec_zone_state(struct zone *, enum zone_stat_item);
extern void __dec_zone_state(struct zone *, enum zone_stat_item);
+void quiet_vmstat(void);
void cpu_vm_stats_fold(int cpu);
void refresh_zone_stat_thresholds(void);
@@ -272,6 +273,7 @@ static inline void __dec_zone_page_state
static inline void refresh_cpu_vm_stats(int cpu) { }
static inline void refresh_zone_stat_thresholds(void) { }
static inline void cpu_vm_stats_fold(int cpu) { }
+static inline void quiet_vmstat(void) { }
static inline void drain_zonestat(struct zone *zone,
struct per_cpu_pageset *pset) { }
Index: linux/kernel/time/tick-sched.c
===
--- linux.orig/kernel/time/tick-sched.c
+++ linux/kernel/time/tick-sched.c
@@ -667,6 +667,7 @@ static ktime_t tick_nohz_stop_sched_tick
*/
if (!ts->tick_stopped) {
nohz_balance_enter_idle(cpu);
+ quiet_vmstat();
calc_load_enter_idle();
ts->last_tick = hrtimer_get_expires(>sched_timer);
--
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] sched: fix incorrect wait time and wait count statistics
On Tue, Oct 27, 2015 at 01:57:28PM +0100, Peter Zijlstra wrote:
>
> (Excessive quoting for Olav)
>
> On Mon, Oct 26, 2015 at 06:44:48PM -0700, Joonwoo Park wrote:
> > On 10/25/2015 03:26 AM, Peter Zijlstra wrote:
>
> > > Also note that on both sites we also set TASK_ON_RQ_MIGRATING -- albeit
> > > late. Can't you simply set that earlier (and back to QUEUED later) and
> > > test for task_on_rq_migrating() instead of blowing up the fastpath like
> > > you did?
> > >
> >
> > Yes it's doable. I also find it's much simpler.
>
> > From 98d615d46211a90482a0f9b7204265c54bba8520 Mon Sep 17 00:00:00 2001
> > From: Joonwoo Park
> > Date: Mon, 26 Oct 2015 16:37:47 -0700
> > Subject: [PATCH v2] sched: fix incorrect wait time and wait count statistics
> >
> > At present scheduler resets task's wait start timestamp when the task
> > migrates to another rq. This misleads scheduler itself into reporting
> > less wait time than actual by omitting time spent for waiting prior to
> > migration and also more wait count than actual by counting migration as
> > wait end event which can be seen by trace or /proc//sched with
> > CONFIG_SCHEDSTATS=y.
> >
> > Carry forward migrating task's wait time prior to migration and
> > don't count migration as a wait end event to fix such statistics error.
> >
> > In order to determine whether task is migrating mark task->on_rq with
> > TASK_ON_RQ_MIGRATING while dequeuing and enqueuing due to migration.
> >
> > To: Ingo Molnar
> > To: Peter Zijlstra
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Joonwoo Park
> > ---
>
> So now that you rely on TASK_ON_RQ_MIGRATING; I think you missed one
> place that can migrate sched_fair tasks and doesn't set it.
>
> Olav recently did a patch adding TASK_ON_RQ_MIGRATING to _every_
> migration path, but that is (still) somewhat overkill. With your changes
> we need it for sched_fair though.
>
> So I think you need to change __migrate_swap_task(), which is used by
> the NUMA scheduling to swap two running tasks.
Oh yes... __migrate_swap_task() can migrate fair class task so I should mark as
TASK_ON_RQ_MIGRATING.
I will fix this in subsequent patch.
>
> Also, it might be prudent to extend the CONFIG_SCHED_DEBUG ifdef in
> set_task_cpu() to test for this new requirement:
>
> WARN_ON_ONCE(p->state == TASK_RUNNING &&
>p->class == _sched_class &&
>p->on_rq != TASK_ON_RQ_MIGRATING);
>
I conceived to argue that if we had Olav's change (with revised marking order)
dummy like myself don't need to worry
about stale on_rq state and probably didn't make mistake like I did with
__migrate_swap_task().
But I don't think I can argue for that reason anymore as my patch will set
TASK_ON_RQ_MIGRATING for all migration paths for
the fair class tasks at least and moreover above macro you suggested would
fortify the new requirement.
I will add that macro.
I recall Olav had some other reason for his patch though.
> > kernel/sched/core.c | 4 ++--
> > kernel/sched/fair.c | 17 ++---
> > 2 files changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index bcd214e..d9e4ad5 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -1069,8 +1069,8 @@ static struct rq *move_queued_task(struct rq *rq,
> > struct task_struct *p, int new
> > {
> > lockdep_assert_held(>lock);
> >
> > - dequeue_task(rq, p, 0);
> > p->on_rq = TASK_ON_RQ_MIGRATING;
> > + dequeue_task(rq, p, 0);
> > set_task_cpu(p, new_cpu);
> > raw_spin_unlock(>lock);
> >
> > @@ -1078,8 +1078,8 @@ static struct rq *move_queued_task(struct rq *rq,
> > struct task_struct *p, int new
> >
> > raw_spin_lock(>lock);
> > BUG_ON(task_cpu(p) != new_cpu);
> > - p->on_rq = TASK_ON_RQ_QUEUED;
> > enqueue_task(rq, p, 0);
> > + p->on_rq = TASK_ON_RQ_QUEUED;
> > check_preempt_curr(rq, p, 0);
> >
> > return rq;
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 9a5e60f..7609576 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -740,7 +740,11 @@ static void update_curr_fair(struct rq *rq)
> > static inline void
> > update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > {
> > - schedstat_set(se->statistics.wait_start, rq_clock(rq_of(cfs_rq)));
> > + schedstat_set(se->statistics.wait_start,
> > + task_on_rq_migrating(task_of(se)) &&
> > + likely(rq_clock(rq_of(cfs_rq)) > se->statistics.wait_start) ?
> > + rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start :
> > + rq_clock(rq_of(cfs_rq)));
>
> So I get that you want to avoid emitting code for !SCHEDSTATS; but that
> is rather unreadable. Either use the GCC stmt-expr or wrap the lot in
> #ifdef.
>
Will do.
> > }
> >
> > /*
> > @@ -759,6 +763,13 @@ static void update_stats_enqueue(struct cfs_rq
> > *cfs_rq, struct sched_entity *se)
> > static void
> >
Re: [PATCH net-next] seccomp, ptrace: add support for dumping seccomp filters
From: Tycho Andersen Date: Tue, 27 Oct 2015 09:23:59 +0900 > This patch adds support for dumping a process' (classic BPF) seccomp > filters via ptrace. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PULL] cpuidle for 4.4
On Friday, October 23, 2015 01:54:08 PM Daniel Lezcano wrote: > > Hi Rafael, > > this pull request contains a couple of changes from Russel King. > > - Disable bind/unbind attribute and use builtin_platform_driver for > mvebu (Russell King) > > - Clean up the code by removing the multiple platform drivers and use > the platform ID instead (Russell King) > > Thanks ! > >-- Daniel > > The following changes since commit 7379047d5585187d1288486d4627873170d0005a: > >Linux 4.3-rc6 (2015-10-18 16:08:42 -0700) > > are available in the git repository at: > >http://git.linaro.org/people/daniel.lezcano/linux.git cpuidle/4.4 > > for you to fetch changes up to ab319939a58678c19a68ff10c8a08cef462a3ba6: > >cpuidle: mvebu: disable the bind/unbind attributes and use > builtin_platform_driver (2015-10-23 12:40:48 +0200) > > > Russell King (2): >cpuidle: mvebu: clean up multiple platform drivers >cpuidle: mvebu: disable the bind/unbind attributes and use > builtin_platform_driver > > drivers/cpuidle/cpuidle-mvebu-v7.c | 46 > +- > 1 file changed, 21 insertions(+), 25 deletions(-) Pulled, thanks! Rafael -- 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] bpf: sample: define aarch64 specific registers
From: Yang Shi Date: Mon, 26 Oct 2015 17:02:19 -0700 > Define aarch64 specific registers for building bpf samples correctly. > > Signed-off-by: Yang Shi Applied. -- 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/7 v2] powerpc/dma-mapping: override dma_get_page_shift
On 28.10.2015 [11:20:05 +0900], Benjamin Herrenschmidt wrote: > On Tue, 2015-10-27 at 18:54 -0700, Nishanth Aravamudan wrote: > > > > In "bypass" mode, what TCE size is used? Is it guaranteed to be 4K? > > None :-) The TCEs are completely bypassed. You get a N:M linear mapping > of all memory starting at 1<<59 PCI side. Err, duh, sorry! Ok, so in that case, DMA page shift is PAGE_SHIFT, then? -Nish -- 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/3] megaraid_sas: Convert dev_printk to dev_
On 2015/10/27 18:33, Kashyap Desai wrote: >>> + dev_dbg(>pdev->dev, "Error copying out >>> cmd_status\n"); >>> error = -EFAULT; >>> } >>> >> >> Reviewed-by: Johannes Thumshirn > > We will consider all three patches for future submission. As of now we have > two patch set pending to be committed. > We are working for few more patch in megaraid_sas which will do clean up in > driver module + proper error handling of DCMD command timeout. It will cover > Patch posted with below subject - > > [PATCH 3/3] megaraid_sas: return -ENOMEM when create DMA pool for cmd frames > failed > Ok. And that, can you add Signed-off-by with me as well? Regards, Weidong > James - We will be resending these patch set on top of latest outstanding > megaraid_sas driver patch, so that we can avoid any conflict in commits. > > -- 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 net] RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv
From: Sowmini Varadhan Date: Mon, 26 Oct 2015 12:46:37 -0400 > Either of pskb_pull() or pskb_trim() may fail under low memory conditions. > If rds_tcp_data_recv() ignores such failures, the application will > receive corrupted data because the skb has not been correctly > carved to the RDS datagram size. > > Avoid this by handling pskb_pull/pskb_trim failure in the same > manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and > retry via the deferred call to rds_send_worker() that gets set up on > ENOMEM from rds_tcp_read_sock() > > Signed-off-by: Sowmini Varadhan Applied and queued up for -stable, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tracing: Only benchmark the time tracepoints take if tracing is on
On Tue, 27 Oct 2015 20:12:13 +0800 Chunyan Zhang wrote: > There's no need to record the time tracepoints take when tracing is off. > This is because: > 1) We cannot see these records since ring_buffer record is off at that > moment. > 2) If tracing is off and benchmark tracepoint is enabled, the time > tracepoint takes is fewer than the same situation when tracing is on, > since the tracepoints need to be wrote into ring_buffer, it would > take more time. If turn on tracing at this moment, the average and > standard deviation cannot exactly present the time that tracepoints > take to write data into ring_buffer. > Thanks! I'll add this when I get back from traveling. -- Steve > Signed-off-by: Chunyan Zhang -- 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/3] virtio_ring: Support DMA APIs
Am 28.10.2015 um 10:17 schrieb Andy Lutomirski:
@@ -423,27 +522,42 @@ EXPORT_SYMBOL_GPL(virtqueue_kick);
>
> static void detach_buf(struct vring_virtqueue *vq, unsigned int head)
> {
> - unsigned int i;
> + unsigned int i, j;
> + u16 nextflag = cpu_to_virtio16(vq->vq.vdev, VRING_DESC_F_NEXT);
>
> /* Clear data ptr. */
> - vq->data[head] = NULL;
> + vq->desc_state[head].data = NULL;
>
> - /* Put back on free list: find end */
> + /* Put back on free list: unmap first-level descriptors and find end */
> i = head;
>
> - /* Free the indirect table */
> - if (vq->vring.desc[i].flags & cpu_to_virtio16(vq->vq.vdev,
> VRING_DESC_F_INDIRECT))
> - kfree(phys_to_virt(virtio64_to_cpu(vq->vq.vdev,
> vq->vring.desc[i].addr)));
> -
> - while (vq->vring.desc[i].flags & cpu_to_virtio16(vq->vq.vdev,
> VRING_DESC_F_NEXT)) {
> + while (vq->vring.desc[i].flags & nextflag) {
> + vring_unmap_one(vq, >vring.desc[i]);
> i = virtio16_to_cpu(vq->vq.vdev, vq->vring.desc[i].next);
> vq->vq.num_free++;
> }
>
> + vring_unmap_one(vq, >vring.desc[i]);
> vq->vring.desc[i].next = cpu_to_virtio16(vq->vq.vdev, vq->free_head);
> vq->free_head = head;
> +
> /* Plus final descriptor */
> vq->vq.num_free++;
> +
> + /* Free the indirect table, if any, now that it's unmapped. */
> + if (vq->desc_state[head].indir_desc) {
> + struct vring_desc *indir_desc = vq->desc_state[head].indir_desc;
> + u32 len = vq->vring.desc[head].len;
> +
> + BUG_ON(!(vq->vring.desc[head].flags & VRING_DESC_F_INDIRECT));
> + BUG_ON(len == 0 || len % sizeof(struct vring_desc));
> +
> + for (j = 0; j < len / sizeof(struct vring_desc); j++)
> + vring_unmap_one(vq, _desc[j]);
> +
> + kfree(vq->desc_state[head].indir_desc);
> + vq->desc_state[head].indir_desc = NULL;
> + }
> }
something seems to be broken with indirect descriptors with that change
[1.885451] [ cut here ]
[1.885454] kernel BUG at drivers/virtio/virtio_ring.c:552!
[1.885487] illegal operation: 0001 ilc:1 [#1] SMP
[1.885489] Modules linked in:
[1.885491] CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.3.0-rc3+ #250
[1.885493] task: 0be49988 ti: 0be54000 task.ti:
0be54000
[1.885514] Krnl PSW : 0404c0018000 0059b9d2
(detach_buf+0x1ca/0x1d0)
[1.885519]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0
EA:3
Krnl GPRS: 3000 0c0c8c00 0a89c000
[1.885522]0059b8fa 0001
[1.885523] 0100
0a89c000
[1.885525]0c082000 0c082000 0059b8fa
0c7fbc88
[1.885531] Krnl Code: 0059b9c6: a7f4ff40brc
15,59b846
0059b9ca: a7f40001 brc 15,59b9cc
#0059b9ce: a7f40001 brc 15,59b9d0
>0059b9d2: 0707 bcr 0,%r7
0059b9d4: 0707 bcr 0,%r7
0059b9d6: 0707 bcr 0,%r7
0059b9d8: c004 brcl0,59b9d8
0059b9de: ebcff0780024 stmg%r12,%r15,120(%r15)
[1.885542] Call Trace:
[1.885544] ([<0059b8fa>] detach_buf+0xf2/0x1d0)
[1.885546] [<0059bbb4>] virtqueue_get_buf+0xcc/0x218
[1.885549] [<005dd8fe>] virtblk_done+0xa6/0x120
[1.885550] [<0059b66e>] vring_interrupt+0x7e/0x108
[1.885552] [<006c21a4>] virtio_airq_handler+0x7c/0x120
[1.885554] [<00657e54>] do_airq_interrupt+0xa4/0xc8
[1.885558] [<001b79a0>] handle_irq_event_percpu+0x60/0x1f0
[1.885560] [<001bbbea>] handle_percpu_irq+0x72/0xa0
[1.885561] [<001b6fa4>] generic_handle_irq+0x4c/0x78
[1.885564] [<0010cc7c>] do_IRQ+0x64/0x88
[1.885566] Btrfs loaded
[1.885600] [<0080e30a>] io_int_handler+0x10a/0x218
[1.885603] [<00186b9e>] wake_up_new_task+0x1be/0x260
[1.885604] ([<00186b6a>] wake_up_new_task+0x18a/0x260)
[1.885606] [<00156182>] _do_fork+0xfa/0x338
[1.885608] [<0015644e>] kernel_thread+0x4e/0x60
[1.885609] [<00179202>] kthreadd+0x1a2/0x238
[1.885611] [<0080e056>] kernel_thread_starter+0x6/0xc
[1.885613] [<0080e050>] kernel_thread_starter+0x0/0xc
[1.885614] Last Breaking-Event-Address:
[1.885615] [<0059b9ce>] detach_buf+0x1c6/0x1d0
[1.885617]
[1.885618] Kernel panic - not syncing: Fatal exception in interrupt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Re: [PATCH v7 11/17] Documentation: phy: add document for rockchip dp phy
On 10/28/2015 07:08 AM, Heiko Stuebner wrote:
Am Samstag, 24. Oktober 2015, 11:06:37 schrieb Yakir Yang:
Add dt binding documentation for rockchip display port PHY.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..505194e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy@ff770274 {
one small thing, I found while playing more ... the node should not have
an address, as it also does not have register property. So just name it
edp_phy: edp-phy {
...
};
There is only one anyway on the rk3288.
With that change the Reviewed-by still applies :-)
Okay,
- Yakir
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <>;
+ clocks = < SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <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 v7 11/17] Documentation: phy: add document for rockchip dp phy
On 10/28/2015 05:24 AM, Heiko Stuebner wrote: Am Samstag, 24. Oktober 2015, 11:06:37 schrieb Yakir Yang: Add dt binding documentation for rockchip display port PHY. Tested-by: Javier Martinez Canillas Signed-off-by: Yakir Yang --- phy binding looks nice and easy Reviewed-by: Heiko Stuebner Thanks, - Yakir -- 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] virtio_pci: Use the DMA API
On Wed, Oct 28, 2015 at 11:15:30AM +0900, Joerg Roedel wrote: > Same here, you need to call the dma_sync* functions when passing data > from/to the virtio-device. Okay, forget about this comment. This patch only converts to dma_coherent allocations, which don't need synchronization. > I think a good test for that is to boot a virtio kvm-guest with > swiotlb=force and see if it still works. But this holds, Its a good way to test if your changes work with bounce-buffering. Together with DMA_API_DEBUG you also see if your specified dma_directions are right. Joerg -- 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] virtio_pci: Use the DMA API
On Wed, 2015-10-28 at 11:15 +0900, Joerg Roedel wrote: > On Tue, Oct 27, 2015 at 06:17:10PM -0700, Andy Lutomirski wrote: > > From: Andy Lutomirski > > > > This fixes virtio-pci on platforms and busses that have IOMMUs. > > This > > will break the experimental QEMU Q35 IOMMU support until QEMU is > > fixed. In exchange, it fixes physical virtio hardware as well as > > virtio-pci running under Xen. > > > > We should clean up the virtqueue API to do its own allocation and > > teach virtqueue_get_avail and virtqueue_get_used to return DMA > > addresses directly. > > > > Signed-off-by: Andy Lutomirski > > --- > > drivers/virtio/virtio_pci_common.h | 3 ++- > > drivers/virtio/virtio_pci_legacy.c | 19 +++ > > drivers/virtio/virtio_pci_modern.c | 34 -- > > > > 3 files changed, 41 insertions(+), 15 deletions(-) > > Same here, you need to call the dma_sync* functions when passing data > from/to the virtio-device. > > I think a good test for that is to boot a virtio kvm-guest with > swiotlb=force and see if it still works. That's useful but doesn't cover the cases where dma_wmb() is needed, right? We should make sure we're handling descriptors properly as we would for real hardware, and ensuring that addresses etc. are written to the descriptor (and a write barrier occurs) *before* the bit is set which tells the 'hardware' that it owns that descriptor. AFAICT we're currently setting the flags *first* in virtqueue_add(), let alone the missing write barrier between the two. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 2/3] virtio_ring: Support DMA APIs
On Tue, Oct 27, 2015 at 07:13:56PM -0700, Andy Lutomirski wrote: > On Tue, Oct 27, 2015 at 7:06 PM, Joerg Roedel wrote: > > Hi Andy, > > > > On Tue, Oct 27, 2015 at 06:17:09PM -0700, Andy Lutomirski wrote: > >> From: Andy Lutomirski > >> > >> virtio_ring currently sends the device (usually a hypervisor) > >> physical addresses of its I/O buffers. This is okay when DMA > >> addresses and physical addresses are the same thing, but this isn't > >> always the case. For example, this never works on Xen guests, and > >> it is likely to fail if a physical "virtio" device ever ends up > >> behind an IOMMU or swiotlb. > > > > The overall code looks good, but I havn't seen and dma_sync* calls. > > When swiotlb=force is in use this would break. > > > >> + vq->vring.desc[head].addr = cpu_to_virtio64(_vq->vdev, > >> vring_map_single( > >> + vq, > >> + desc, total_sg * sizeof(struct vring_desc), > >> + DMA_TO_DEVICE)); > > > > Are you talking about a dma_sync call on the descriptor ring itself? > Isn't dma_alloc_coherent supposed to make that unnecessary? I should > move the allocation into the virtqueue code. > > The docs suggest that I might need to "flush the processor's write > buffers before telling devices to read that memory". I'm not sure how > to do that. The write buffers should be flushed by the dma-api functions if necessary. For dma_alloc_coherent allocations you don't need to call dma_sync*, but for the map_single/map_page/map_sg ones, as these might be bounce-buffered. Joerg -- 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/7 v2] powerpc/dma-mapping: override dma_get_page_shift
On Tue, 2015-10-27 at 18:54 -0700, Nishanth Aravamudan wrote: > > In "bypass" mode, what TCE size is used? Is it guaranteed to be 4K? None :-) The TCEs are completely bypassed. You get a N:M linear mapping of all memory starting at 1<<59 PCI side. > Seems like this would be a different platform implentation I'd put in > for 'powernv', is that right? > > My apologies for missing that, and thank you for the review! Cheers, Ben. -- 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/
