Re: [PATCH] userspace API definitions for auto-focus coil
On Tue 2016-07-12 20:32:01, Mauro Carvalho Chehab wrote: 1;2802;0c> Em Sat, 18 Jun 2016 17:38:46 +0200 > Pavel Machek escreveu: > > > Hi! > > > > > > Not V4L2_CID_USER_AD5820...? > > > > > > The rest of the controls have no USER as part of the macro name, so I > > > wouldn't use it here either. > > > > Ok. > > > > > > Ok, separate header file for 2 lines seemed like a bit of overkill, > > > > but why not. > > > > > > That follows an existing pattern of how controls have been implemented in > > > other drivers. > > > > Ok. > > > > > Could you merge this with the driver patch? I've dropped that from my > > > ad5820 > > > branch as it does not compile. > > > > Yes, merged patch should be in your inbox now. > > The V4L2 core changes should be on a separate patch. Btw, you'll also > need to patch documentation to reflect such changes. We're right now > moving from DocBook to ReST markup language. The patches for it are > right now on a separate topic branch (docs-next), to be merged for > Kernel 4.8 on the next merge window. > > You should either base the patch on such branch or wait for it to be > merged back mainstream to write such documentation additions. So how many iterations and how many releases does it take to get trivial driver into the tree? I did what Sakari asked me to do. The driver is trivial. You can see pretty easily what I'm changing in the core... and it is not much. Can you just add your acked-by to it, merge it and me done with it? If some more docs is required, I can do the docs, but stalling patch for months and then claiming "hey, we have these new rules you have to follow" is not a nice thing. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] capabilities: audit capability use
On 07/12/16 14:59, Tejun Heo wrote: > On Mon, Jul 11, 2016 at 07:47:44PM +, Topi Miettinen wrote: >> It's really critical to be able to associate a task in the logs to >> cgroups which were valid that time. Or can we infer somehow what cgroups > > When is "that time"? Without logging all operations, this is > meaningless. > >> a task was taking part, long time after task exit? Perhaps task cgroup >> membership changes and changes in available cgroups should be logged too? >> >> Some kind of cgroup IDs could be logged instead of long paths. Then >> these IDs should be reliably resolvable to paths offline somehow. > > I don't think that's doable. That pretty much requires the kernel to > remember paths of all past cgroups. That's a show stopper for audit approach for getting helpful information for configuration. I'll try something different, probably cgroupstats. -Topi > >> How usual migrations between cgroups are? Why would a task ever move >> from (say) systemd/system.slice/smartd.service to anywhere else? > > In most cases, they won't move once set up initially but that's not > the point of audit subsystem. Logging this once one exit isn't gonna > help anything for auditing the system. > > Thanks. >
Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
Prarit Bhargava writes: >> We implement thermal zone because we do support it, but the problem is >> that we need the firmware to be loaded for that. So you can argue that >> we should register *later* when the firmware is loaded. But this is >> really not helping all that much because the firmware can also be >> stopped at any time. So you'd want us to register / unregister the >> thermal zone anytime the firmware is loaded / unloaded? > > You might have to do that. I think that if the firmware enables a feature > then > the act of loading the firmware should run the code that enables the feature. > IMO of course. But I suspect that the iwlwifi firmware is loaded during interface up (and unloaded during interface down) and in that case register/unregister would be happening all the time. That doesn't sound like a good idea. I would rather try to fix the thermal interface to handle the cases when the measurement is not available. -- Kalle Valo
Loan Offer
Instant cash Loan with same day payout on all kinds of Loan are available at Quick Financial Home were loan is offered at 2% per annul. Email: quickloa...@foxmail.com
linux-next: Tree for Jul 13
Hi all, Changes since 20160712: Dropped tree: hid (too many conflicts) The hid tree gained quite a few conflicts due to a large revert, so I dropped it for today. The drm tree gained a conflict against the v4l-dvb tree. The akpm-current tree gained a conflict against the block tree. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 8633 8133 files changed, 459742 insertions(+), 154417 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 238 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (63bab2203d54 Merge tag 'qcom-smd-list-voltage' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging fixes/master (5edb56491d48 Linux 4.7-rc3) Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported variables) Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if DW2_UNWIND is disabled) Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 errata initialization) Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic ) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (eb584b3ee4d3 powerpc/tm: Fix stack pointer corruption in __tm_recheckpoint()) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (6b15d6650c53 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (136ab0d0e10f net: nps_enet: Fix PCS reset) Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.) Merging netfilter/master (590b52e10d41 netfilter: conntrack: skip clash resolution if nat is in place) Merging ipvs/master (3777ed688fba ipvs: fix bind to link-local mcast IPv6 address in backup) Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git) Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation) Merging sound-current/for-linus (d716fb03f764 ALSA: hda: add AMD Stoney PCI ID with proper driver caps) Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC code) Merging driver-core.current/driver-core-linus (33688abb2802 Linux 4.7-rc4) Merging tty.current/tty-linus (a99cde438de0 Linux 4.7-rc6) Merging usb.current/usb-linus (a99cde438de0 Linux 4.7-rc6) Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command) Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: otg-fsm: add license to usb-otg-fsm) Merging staging.current/staging-linus (a99cde438de0 Linux 4.7-rc6) Merging char-misc.current/char-misc-linus (33688abb2802 Linux 4.7-rc4) Merging input-current/for-linus (caca925fca4f Input: xpad - validate USB endpoint count during probe) Merging crypto-current/master (055ddaace035 crypto: user - re-add size check for CRYPTO_MSG_GETALG) Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.) Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read) Merging kselftest-fixes/fixes (f80eb4289491 selftests/e
Re: [PATCH] [RFC V1]s390/perf: fix 'start' address of module's map
在 7/11/2016 8:01 PM, Jiri Olsa 写道:
On Mon, Jul 11, 2016 at 07:06:14PM +0800, Songshan Gong wrote:
SNIP
we have following functions in tools/lib/api/fs to read
single number from file, which I assume you do above:
int sysfs__read_int(const char *entry, int *value);
int sysfs__read_ull(const char *entry, unsigned long long *value);
please check if you could use some of them,
we could add some more generic one if needed
It seems infeasible.
Each value in /sys/module/[module name]/sections/.text is a string like
"0x03ff8130078\n".
But the core function 'strtoull(line, NULL, 10)' in sysfs__read_ull is based
on decimal.
Maybe you can introduce a new argument indicating the value is based on hex
or decimal, or binary?
yea we could specify it directly and add something like:
int filename__read_ull(const char *filename, unsigned long long *value, int
base)
plus some other higher layer helpers..
but I wonder if we could use the base 0 (like in the attached patch),
the man page says it should be able to detect the base
we'd need to check all the current usage to make sure nothing gets broken
jirka
Since your patch havn't pushed to devel branch, my next version patch
will still use the origin method to parse value from /sys/.
Thanks.
---
diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
index 08556cf2c70d..d18ae548468a 100644
--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -292,7 +292,7 @@ int filename__read_ull(const char *filename, unsigned long
long *value)
return -1;
if (read(fd, line, sizeof(line)) > 0) {
- *value = strtoull(line, NULL, 10);
+ *value = strtoull(line, NULL, 0);
if (*value != ULLONG_MAX)
err = 0;
}
--
SongShan Gong
RE: [lkp] [usb] 9696ef14de: WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36 __list_add+0x104/0x188
>-Original Message-
>From: lkp-requ...@eclists.intel.com [mailto:lkp-requ...@eclists.intel.com] On
>Behalf
>Of kernel test robot
>Sent: Wednesday, July 13, 2016 9:28 AM
>To: Peter Chen
>Cc: 0day robot ; LKML ;
>l...@01.org
>Subject: [lkp] [usb] 9696ef14de: WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36
>__list_add+0x104/0x188
>
>
>FYI, we noticed the following commit:
>
>https://github.com/0day-ci/linux Peter-Chen/usb-udc-core-fix-error-
>handling/20160711-100832
>commit 9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2 ("usb: udc: core: fix error
>handling")
>
Thanks, but I really can't find the relationship between my patch and dump.
Can you reproduce it after running again or without my patch?
Peter
>in testcase: boot
>
>on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Nehalem with
>320M memory
>
>caused below changes:
>
>[ 22.076363] WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36
>__list_add+0x104/0x188
>[ 22.079911] list_add double add: new=88000e422e10,
>prev=88000e422e10,
>next=8800135e9168.
>[ 22.086059] CPU: 0 PID: 1 Comm: swapper Tainted: GW 4.7.0-rc4-
>00110-g9696ef1 #1
>[ 22.087856] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>Debian-1.8.2-1 04/01/2014
>[ 22.097535] 88001345fc00 8190c8e2
>88001345fc40
>[ 22.099469] 81175453 00240009 88000e422e10
>8800135e9168
>[ 22.101220] 88000e422e10 0001
>88001345fca8
>[ 22.103291] Call Trace:
>[ 22.109166] [] dump_stack+0x19/0x1b
>[ 22.110520] [] __warn+0x10a/0x125
>[ 22.111632] [] warn_slowpath_fmt+0x46/0x4e
>[ 22.112939] [] ? klist_add_tail+0x29/0x62
>[ 22.114418] [] __list_add+0x104/0x188
>[ 22.115600] [] klist_add_tail+0x53/0x62
>[ 22.118742] [] device_add+0xb03/0xcca
>[ 22.121931] [] device_create_groups_vargs+0xfe/0x133
>[ 22.123390] [] device_create_with_groups+0x2b/0x2d
>[ 22.130047] [] ? __mutex_unlock_slowpath+0x1cb/0x1d8
>[ 22.131513] [] misc_register+0x1e0/0x2ec
>[ 22.132751] [] mousedev_init+0x55/0x81
>[ 22.134198] [] ? input_leds_init+0x12/0x12
>[ 22.135442] [] do_one_initcall+0xdc/0x16a
>[ 22.139131] [] kernel_init_freeable+0x387/0x419
>[ 22.142059] [] kernel_init+0xa/0x103
>[ 22.144618] [] ret_from_fork+0x1f/0x40
>[ 22.148576] [] ? rest_init+0xb8/0xb8
>[ 22.150009] ---[ end trace 75873bca450a4fe4 ]---
>[ 22.151559] mousedev: PS/2 mouse device common for all mice
>[ 22.155003] evbug: Connected device: input0 (Power Button at
>LNXPWRBN/button/input0)
>
>
>FYI, raw QEMU command line is:
>
> qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel /pkg/linux/x86_64-
>randconfig-s0-07121340/gcc-
>6/9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2/vmlinuz-4.7.0-rc4-00110-g9696ef1
>-append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-intel12-yocto-x86_64-
>3/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-s0-07121340-
>9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2-20160712-19858-1j3k6zi-0.yaml
>ARCH=x86_64 kconfig=x86_64-randconfig-s0-07121340 branch=linux-devel/devel-
>hourly-2016071211 commit=9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2
>BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s0-07121340/gcc-
>6/9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2/vmlinuz-4.7.0-rc4-00110-g9696ef1
>max_uptime=600 RESULT_ROOT=/result/boot/1/vm-intel12-yocto-x86_64/yocto-
>minimal-x86_64.cgz/x86_64-randconfig-s0-07121340/gcc-
>6/9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2/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-
>intel12-yocto-x86_64-3::dhcp drbd.minor_count=8' -initrd
>/fs/KVM/initrd-vm-intel12-
>yocto-x86_64-3 -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/KVM/disk0-vm-intel12-yocto-x86_64-3,media=disk,if=virtio -drive
>file=/fs/KVM/disk1-vm-intel12-yocto-x86_64-3,media=disk,if=virtio -pidfile
>/dev/shm/kboot/pid-vm-intel12-yocto-x86_64-3 -serial
>file:/dev/shm/kboot/serial-vm-
>intel12-yocto-x86_64-3 -daemonize -display none -monitor null
>
>
>
>
>
>Thanks,
>Xiaolong
RE: PCIe MSI address is not written at pci_enable_msi_range call
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call > > On 11/07/16 10:33, Bharat Kumar Gogada wrote: > > Hi Marc, > > > > Thanks for the reply. > > > > From PCIe Spec: > > MSI Enable Bit: > > If 1 and the MSI-X Enable bit in the MSI-X Message Control register > > (see Section 6.8.2.3) is 0, the function is permitted to use MSI to > > request service and is prohibited from using its INTx# pin. > > > > From Endpoint perspective, MSI Enable = 1 indicates MSI can be used > which means MSI address and data fields are available/programmed. > > > > In our SoC whenever MSI Enable goes from 0 --> 1 the hardware latches > onto MSI address and MSI data values. > > > > With current MSI implementation in kernel, our SoC is latching on to > > incorrect address and data values, as address/data are updated much later > than MSI Enable bit. > > As a side question, how does setting the affinity work on this end-point if > this > involves changing the address programmed in the MSI registers? > Do you expect the enabled bit to be toggled to around the write? > Yes, Would anybody change MSI address in between wouldn't it cause race condition ? Thanks & Regards, Bharat This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Re: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD
> So in order to hit this hypothetical corner case today you would > need to be using a real world type-C device something such as a > Dell WD15 on another OEM's machine that has type-C and the exact > same ACPI object name that does $BADSTUFF other than return a > buffer. Exactly what I meant. > If that situation arises please alert me and I'll send a follow up > patch that whitelists this to match DMI vendor of only Dell > systems. I'm not sure if it's the most responsible way to approach this problem. There were cases of laptops bricking (as in - they would never power on ever again) just because Linux made some bad BIOS/ACPI calls. Also, see the famous Samsung UEFI NVRAM fiasco or the recent pains with EFIVARS. Regards, MP
linux-next: manual merge of the akpm-current tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
drivers/nvme/host/core.c
between commit:
f80ec966c19b ("nvme: Limit command retries")
from the block tree and commit:
8cc07e463b0c ("NVMe: don't allocate unused nvme_major")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/nvme/host/core.c
index 86a0c661e74c,3dc259e7bf2a..
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@@ -48,14 -47,6 +48,11 @@@ unsigned char shutdown_timeout = 5
module_param(shutdown_timeout, byte, 0644);
MODULE_PARM_DESC(shutdown_timeout, "timeout in seconds for controller
shutdown");
+unsigned int nvme_max_retries = 5;
+module_param_named(max_retries, nvme_max_retries, uint, 0644);
+MODULE_PARM_DESC(max_retries, "max number of retries a command may have");
+EXPORT_SYMBOL_GPL(nvme_max_retries);
+
- static int nvme_major;
- module_param(nvme_major, int, 0);
-
static int nvme_char_major;
module_param(nvme_char_major, int, 0);
Re: [PATCH 3/3] Add name fields in shrinker tracepoint definitions
> On Jul 13, 2016, at 6:05 AM, Tony Jones wrote:
>
> On 07/11/2016 07:18 AM, Vlastimil Babka wrote:
>> On 07/09/2016 11:05 AM, Janani Ravichandran wrote:
>>>
>>> TP_fast_assign(
>>> + __entry->name = shr->name;
>>> __entry->shr = shr;
>>> __entry->shrink = shr->scan_objects;
>>> __entry->nid = sc->nid;
>>> @@ -214,7 +216,8 @@ TRACE_EVENT(mm_shrink_slab_start,
>>> __entry->total_scan = total_scan;
>>> ),
>>>
>>> - TP_printk("%pF %p: nid: %d objects to shrink %ld gfp_flags %s
>>> pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
>>> + TP_printk("name: %s %pF %p: nid: %d objects to shrink %ld gfp_flags %s
>>> pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
>>> + __entry->name,
>>
>> Is this legal to do when printing is not done via the /sys ... file
>> itself, but raw data is collected and then printed by e.g. trace-cmd?
>> How can it possibly interpret the "char *" kernel pointer?
>
> I actually had a similar patch set to this, I was going to post it but
> Janani beat me to it ;-)
>
> Vlastimil is correct, I'll attach my patch below so you can see the
> difference. Otherwise you won't get correct behavior passing through perf.
Thanks for that! I will have a look at it.
>
>
> I also have a patch which adds a similar latency script (python) but
> interfaces it into the perf script setup.
I’m looking for pointers for writing latency scripts using tracepoints as I’m
new to it. Can I have a look at yours, please?
Thanks :)
Janani.
>
> Tony
>
> ---
>
> Pass shrinker name in shrink slab tracepoints
>
> Signed-off-by: Tony Jones
> ---
> include/trace/events/vmscan.h | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
> index 0101ef3..0a15948 100644
> --- a/include/trace/events/vmscan.h
> +++ b/include/trace/events/vmscan.h
> @@ -16,6 +16,8 @@
> #define RECLAIM_WB_SYNC 0x0004u /* Unused, all reclaim async */
> #define RECLAIM_WB_ASYNC 0x0008u
>
> +#define SHRINKER_NAME_LEN(size_t)32
> +
> #define show_reclaim_flags(flags) \
> (flags) ? __print_flags(flags, "|", \
> {RECLAIM_WB_ANON, "RECLAIM_WB_ANON"}, \
> @@ -190,6 +192,7 @@ TRACE_EVENT(mm_shrink_slab_start,
>
> TP_STRUCT__entry(
> __field(struct shrinker *, shr)
> + __array(char, name, SHRINKER_NAME_LEN)
> __field(void *, shrink)
> __field(int, nid)
> __field(long, nr_objects_to_shrink)
> @@ -203,6 +206,7 @@ TRACE_EVENT(mm_shrink_slab_start,
>
> TP_fast_assign(
> __entry->shr = shr;
> + strlcpy(__entry->name, shr->name, SHRINKER_NAME_LEN);
> __entry->shrink = shr->scan_objects;
> __entry->nid = sc->nid;
> __entry->nr_objects_to_shrink = nr_objects_to_shrink;
> @@ -214,9 +218,10 @@ TRACE_EVENT(mm_shrink_slab_start,
> __entry->total_scan = total_scan;
> ),
>
> - TP_printk("%pF %p: nid: %d objects to shrink %ld gfp_flags %s
> pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
> + TP_printk("%pF %p(%s): nid: %d objects to shrink %ld gfp_flags %s
> pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
> __entry->shrink,
> __entry->shr,
> + __entry->name,
> __entry->nid,
> __entry->nr_objects_to_shrink,
> show_gfp_flags(__entry->gfp_flags),
> @@ -236,6 +241,7 @@ TRACE_EVENT(mm_shrink_slab_end,
>
> TP_STRUCT__entry(
> __field(struct shrinker *, shr)
> + __array(char, name, SHRINKER_NAME_LEN)
> __field(int, nid)
> __field(void *, shrink)
> __field(long, unused_scan)
> @@ -246,6 +252,7 @@ TRACE_EVENT(mm_shrink_slab_end,
>
> TP_fast_assign(
> __entry->shr = shr;
> + strlcpy(__entry->name, shr->name, SHRINKER_NAME_LEN);
> __entry->nid = nid;
> __entry->shrink = shr->scan_objects;
> __entry->unused_scan = unused_scan_cnt;
> @@ -254,9 +261,10 @@ TRACE_EVENT(mm_shrink_slab_end,
> __entry->total_scan = total_scan;
> ),
>
> - TP_printk("%pF %p: nid: %d unused scan count %ld new scan count %ld
> total_scan %ld last shrinker return val %d",
> + TP_printk("%pF %p(%s): nid: %d unused scan count %ld new scan count %ld
> total_scan %ld last shrinker return val %d",
> __entry->shrink,
> __entry->shr,
> + __entry->name,
> __entry->nid,
> __entry->unused_scan,
> __entry->new_scan,
>
>
RE: [PATCH v2 0/8] thunderbolt: Introducing Thunderbolt(TM) networking
On Wed, Jul 13 2016, 01:19 AM, Andreas Noever wrote: > Since this is now a separate driver I would prefer if it was in a different > (sub)directory (maybe thunderbolt/icm?). > Thanks Andreas for the comment, will change it in the next patch. Any more comments?
Re: [PATCH v3 1/2] drivers: led: is31fl319x: 1/3/6/9-channel light effect led driver
Hi Jacek,
Andrey already has worked in your comments but there is one topic
for discussion (see below) before we submit v4.
> Am 12.07.2016 um 22:14 schrieb Jacek Anaszewski :
>
> Hi Nikolaus,
>
> Thanks for the update.
>
> On 07/08/2016 09:49 PM, H. Nikolaus Schaller wrote:
>> This is a driver for the Integrated Silicon Solution Inc. LED driver
>> chips series IS31FL319x. They can drive 1, 3, 6 or up to 9
>> LEDs.
>>
>> Each LED is individually controllable in brightness (through pwm)
>> in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors.
>>
>> The maximum current of the LEDs can be programmed and limited to
>> 5 .. 40mA through a device tree property.
>>
>> The chip is connected through I2C and can have one of 4 addresses
>> in the range 0x64 .. 0x67 depending on how the AD pin is connected. The
>> address is defined by the reg property as usual.
>>
>> The chip also has a shutdown input which could be connected to a GPIO,
>> but this driver uses software shutdown if all LEDs are inactivated.
>>
>> The chip also has breathing and audio features which are not fully
>> supported by this driver.
>>
>> Tested-on: OMAP5 based Pyra handheld prototype.
>> Signed-off-by: H. Nikolaus Schaller
>> Signed-off-by: Andrey Utkin
>> ---
>> drivers/leds/Kconfig | 12 ++
>> drivers/leds/Makefile | 1 +
>> drivers/leds/leds-is31fl319x.c | 405
>> +
>> 3 files changed, 418 insertions(+)
>> create mode 100644 drivers/leds/leds-is31fl319x.c
>>
>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>> index 5ae2834..6439a7d 100644
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -570,6 +570,18 @@ config LEDS_SEAD3
>>This driver can also be built as a module. If so the module
>>will be called leds-sead3.
>>
>> +config LEDS_IS31FL319X
>> +tristate "LED Support for ISSI IS31FL319x I2C LED controller family"
>> +depends on LEDS_CLASS && I2C && OF
>> +select REGMAP_I2C
>> +help
>> + This option enables support for LEDs connected to ISSI IS31FL319x
>> + fancy LED driver chips accessed via the I2C bus.
>> + Driver supports individual PWM brightness control for each channel.
>> +
>> + This driver can also be built as a module. If so the module will be
>> + called leds-is31fl319x.
>> +
>> config LEDS_IS31FL32XX
>> tristate "LED support for ISSI IS31FL32XX I2C LED controller family"
>> depends on LEDS_CLASS && I2C && OF
>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>> index cb2013d..b6ce9f9 100644
>> --- a/drivers/leds/Makefile
>> +++ b/drivers/leds/Makefile
>> @@ -66,6 +66,7 @@ obj-$(CONFIG_LEDS_MENF21BMC) +=
>> leds-menf21bmc.o
>> obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
>> obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
>> obj-$(CONFIG_LEDS_SEAD3)+= leds-sead3.o
>> +obj-$(CONFIG_LEDS_IS31FL319X) += leds-is31fl319x.o
>> obj-$(CONFIG_LEDS_IS31FL32XX) += leds-is31fl32xx.o
>>
>> # LED SPI Drivers
>> diff --git a/drivers/leds/leds-is31fl319x.c b/drivers/leds/leds-is31fl319x.c
>> new file mode 100644
>> index 000..7fc5c6ab
>> --- /dev/null
>> +++ b/drivers/leds/leds-is31fl319x.c
>> @@ -0,0 +1,405 @@
>> +/*
>> + * Copyright 2015-16 Golden Delicious Computers
>> + *
>> + * Author: Nikolaus Schaller
>> + *
>> + * Based on leds-tca6507.c
>> + *
>> + * This file is subject to the terms and conditions of version 2 of
>> + * the GNU General Public License. See the file COPYING in the main
>> + * directory of this archive for more details.
>> + *
>> + * LED driver for the IS31FL319{0,1,3,6,9} to drive 1, 3, 6 or 9 light
>> + * effect LEDs.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/* register numbers */
>> +#define IS31FL319X_SHUTDOWN 0x00
>> +#define IS31FL319X_CTRL10x01
>> +#define IS31FL319X_CTRL20x02
>> +#define IS31FL319X_CONFIG1 0x03
>> +#define IS31FL319X_CONFIG2 0x04
>> +#define IS31FL319X_RAMP_MODE0x05
>> +#define IS31FL319X_BREATH_MASK 0x06
>> +#define IS31FL319X_PWM(channel) (0x07 + channel)
>> +#define IS31FL319X_DATA_UPDATE 0x10
>> +#define IS31FL319X_T0(channel) (0x11 + channel)
>> +#define IS31FL319X_T123_1 0x1a
>> +#define IS31FL319X_T123_2 0x1b
>> +#define IS31FL319X_T123_3 0x1c
>> +#define IS31FL319X_T4(channel) (0x1d + channel)
>> +#define IS31FL319X_TIME_UPDATE 0x26
>> +#define IS31FL319X_RESET0xff
>> +
>> +#define IS31FL319X_REG_CNT (IS31FL319X_RESET + 1)
>> +
>> +#define NUM_LEDS 9 /* max for 3199 chip */
>
> Add namespacing prefix also to this macro.
>
>> +
>> +#define LED_MAX_MICROAMP_UPPER_LIMIT ((u32) 4)
>> +#define LED_MAX_MICROAMP_LOWER_LIMIT ((u32) 5000)
>> +#define LED_MAX_MICROAMP_DEFAULT ((u32) 2)
>> +#define LED_MAX_MICROAMP_STEP ((u32) 5000)
>
> Ditto.
>
>> +
>> +#define
Re: [GIT PULL] extcon next for 4.8
Dear Greg, Please pull this extcon request. This pull request includes missing patches[1] for v4.7. [1] https://lkml.org/lkml/2016/5/16/268 Best Regards, Chanwoo Choi On 2016년 07월 05일 20:04, Chanwoo Choi wrote: > Dear Greg, > > This is extcon-next pull request for v4.8. I add detailed description of > this pull request on below. Please pull extcon with following updates. > > Best Regards, > Chanwoo Choi > > The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e: > > Linux 4.7-rc4 (2016-06-19 21:30:02 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-next-for-4.8 > > for you to fetch changes up to 1b6cf310103799f371066453f55755088b008be0: > > extcon: adc-jack: add suspend/resume support (2016-07-02 14:31:34 +0900) > > > Update extcon for 4.8 > > Detailed description for patchset: > 1. Update the extcon-gpio.c driver > - Use PM wakeirq APIs and support to check the state of external connector > when wake-up from suspend state if the interrupt of external connector is > not used as wakeup source. > - Support for ACPI gpio interface > > 2. Remove deprecated extcon APIs using the legacy cable name > - The extcon framework handle the external connector only by unique id > instead of legacy cable name to prevent the problem. > - Removed functions > : extcon_get_cable_state() > : extcon_set_cable_state() > : extcon_register_interest() > : extcon_unregister_interest() > - It has the dependency on the axp288_charger.c driver. > So, this pull request includes the 'ib-extcon-powersupply-4.8' > immutable branch to protect the merge conflict. > > 3. Support the resource-managed function for extcon_register_notifier > - Add the devm_extcon_register/unregister_notifier() funticon to handle > the resource automatically by resource managed functions and split out > the resource-managed function from extcon core to seprate file(devres.c). > > 4. Supprot the suspend/resume for extcon-adc-jack.c driver > - Add the support the suspend/resume function to use extcon-adc-jack.c > as wakeup source. > > 5. Fix the minor issue > - Check the return value of find_cable_index_by_id() > - Move the struct extcon_cable to extcon core from header file > because it should be only handled on extcon core. > - Add the missing of_node_put() after calling of_parse_phandle() > to decrement the reference count. > > > Arnd Bergmann (1): > extcon: link devres into core module > > Chanwoo Choi (7): > power: axp288_charger: Replace deprecatd API of extcon > extcon: Remove the deprecated extcon functions > Merge branch 'ib-extcon-powersupply-4.8' into extcon-next > extcon: Move struct extcon_cable from header file to core > extcon: Split out the resource-managed functions from extcon core > extcon: Add resource-managed functions to register extcon notifier > extcon: Fix the wrong description about extcon_set/get_cable_state_() > > Charles Keepax (1): > extcon: arizona: Update binding docs to mention new defines for GPSW > > Grygorii Strashko (1): > extcon: usb-gpio: switch to use pm wakeirq apis > > Lu Baolu (2): > extcon: usb-gpio: add device binding for platform device > extcon: usb-gpio: add support for ACPI gpio interface > > Peter Chen (1): > extcon: add missing of_node_put after calling of_parse_phandle > > Roger Quadros (1): > extcon: usb-gpio: Don't miss event during suspend/resume > > Stephen Boyd (1): > extcon: Check for incorrect connection type in notifier register > > Venkat Reddy Talla (1): > extcon: adc-jack: add suspend/resume support > > .../devicetree/bindings/extcon/extcon-arizona.txt | 3 +- > drivers/extcon/Makefile| 3 +- > drivers/extcon/devres.c| 216 + > drivers/extcon/extcon-adc-jack.c | 34 ++ > drivers/extcon/extcon-usb-gpio.c | 32 +- > drivers/extcon/extcon.c| 344 > +++-- > drivers/power/axp288_charger.c | 77 +++-- > include/linux/extcon.h | 115 +++ > include/linux/extcon/extcon-adc-jack.h | 2 + > 9 files changed, 416 insertions(+), 410 deletions(-) > create mode 100644 drivers/extcon/devres.c > > >
[PATCH v2 12/15] net: thunderx: Use skb_add_rx_frag() for split buffer Rx pkts
From: Sunil Goutham
Instead of a round about way of converting buffers to SKBs and
combining them into a frag list, use standard skb_add_rx_frag()
API to merge page fragments. This code is useful when incoming
packets are of size more than RCV_FRAG_LEN which is currently
set to 2048bytes.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 24 ++
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index ca223aa..ed2fe72 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -1184,8 +1184,8 @@ struct sk_buff *nicvf_get_rcv_skb(struct nicvf *nic,
struct cqe_rx_t *cqe_rx)
int frag;
int payload_len = 0;
struct sk_buff *skb = NULL;
- struct sk_buff *skb_frag = NULL;
- struct sk_buff *prev_frag = NULL;
+ struct page *page;
+ int offset;
u16 *rb_lens = NULL;
u64 *rb_ptrs = NULL;
@@ -1218,22 +1218,10 @@ struct sk_buff *nicvf_get_rcv_skb(struct nicvf *nic,
struct cqe_rx_t *cqe_rx)
skb_put(skb, payload_len);
} else {
/* Add fragments */
- skb_frag = nicvf_rb_ptr_to_skb(nic, *rb_ptrs,
- payload_len);
- if (!skb_frag) {
- dev_kfree_skb(skb);
- return NULL;
- }
-
- if (!skb_shinfo(skb)->frag_list)
- skb_shinfo(skb)->frag_list = skb_frag;
- else
- prev_frag->next = skb_frag;
-
- prev_frag = skb_frag;
- skb->len += payload_len;
- skb->data_len += payload_len;
- skb_frag->len = payload_len;
+ page = virt_to_page(phys_to_virt(*rb_ptrs));
+ offset = phys_to_virt(*rb_ptrs) - page_address(page);
+ skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page,
+ offset, payload_len, RCV_FRAG_LEN);
}
/* Next buffer pointer */
rb_ptrs++;
--
2.7.4
[PATCH v2 01/15] net: thunderx: Moved HW capability info from macros to structure
From: Sunil Goutham
Current driver has most of the HW maximums info like no of channels,
traffic limiters, RSS indices e.t.c in the form of macros. These have
been moved into a 'hw_info' structure so that support for VNIC on
newer chips with different set of HW maximums can be added.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic.h | 41 ++-
drivers/net/ethernet/cavium/thunder/nic_main.c | 96 +-
2 files changed, 85 insertions(+), 52 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
b/drivers/net/ethernet/cavium/thunder/nic.h
index 83025bb..66b499b 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -20,6 +20,9 @@
#definePCI_DEVICE_ID_THUNDER_NIC_VF0xA034
#definePCI_DEVICE_ID_THUNDER_BGX 0xA026
+/* Subsystem device IDs */
+#define PCI_SUBSYS_DEVID_88XX_NIC_PF 0xA11E
+
/* PCI BAR nos */
#definePCI_CFG_REG_BAR_NUM 0
#definePCI_MSIX_REG_BAR_NUM4
@@ -41,40 +44,8 @@
/* Max pkinds */
#defineNIC_MAX_PKIND 16
-/* Rx Channels */
-/* Receive channel configuration in TNS bypass mode
- * Below is configuration in TNS bypass mode
- * BGX0-LMAC0-CHAN0 - VNIC CHAN0
- * BGX0-LMAC1-CHAN0 - VNIC CHAN16
- * ...
- * BGX1-LMAC0-CHAN0 - VNIC CHAN128
- * ...
- * BGX1-LMAC3-CHAN0 - VNIC CHAN174
- */
-#defineNIC_INTF_COUNT 2 /* Interfaces btw VNIC and
TNS/BGX */
-#defineNIC_CHANS_PER_INF 128
-#defineNIC_MAX_CHANS (NIC_INTF_COUNT *
NIC_CHANS_PER_INF)
-#defineNIC_CPI_COUNT 2048 /* No of channel parse
indices */
-
-/* TNS bypass mode: 1-1 mapping between VNIC and BGX:LMAC */
-#define NIC_MAX_BGXMAX_BGX_PER_CN88XX
-#defineNIC_CPI_PER_BGX (NIC_CPI_COUNT / NIC_MAX_BGX)
-#defineNIC_MAX_CPI_PER_LMAC64 /* Max when CPI_ALG is IP
diffserv */
-#defineNIC_RSSI_PER_BGX(NIC_RSSI_COUNT / NIC_MAX_BGX)
-
-/* Tx scheduling */
-#defineNIC_MAX_TL4 1024
-#defineNIC_MAX_TL4_SHAPERS 256 /* 1 shaper for 4 TL4s */
-#defineNIC_MAX_TL3 256
-#defineNIC_MAX_TL3_SHAPERS 64 /* 1 shaper for 4 TL3s */
-#defineNIC_MAX_TL2 64
-#defineNIC_MAX_TL2_SHAPERS 2 /* 1 shaper for 32 TL2s */
-#defineNIC_MAX_TL1 2
-
-/* TNS bypass mode */
-#defineNIC_TL2_PER_BGX 32
-#defineNIC_TL4_PER_BGX (NIC_MAX_TL4 / NIC_MAX_BGX)
-#defineNIC_TL4_PER_LMAC(NIC_MAX_TL4 /
NIC_CHANS_PER_INF)
+/* Max when CPI_ALG is IP diffserv */
+#defineNIC_MAX_CPI_PER_LMAC64
/* NIC VF Interrupts */
#defineNICVF_INTR_CQ 0
@@ -148,7 +119,6 @@ struct nicvf_cq_poll {
struct napi_struct napi;
};
-#defineNIC_RSSI_COUNT 4096 /* Total no of RSS indices
*/
#define NIC_MAX_RSS_HASH_BITS 8
#define NIC_MAX_RSS_IDR_TBL_SIZE (1 << NIC_MAX_RSS_HASH_BITS)
#define RSS_HASH_KEY_SIZE 5 /* 320 bit key */
@@ -273,6 +243,7 @@ struct nicvf {
struct net_device *netdev;
struct pci_dev *pdev;
void __iomem*reg_base;
+#defineMAX_QUEUES_PER_QSET 8
struct queue_set*qs;
struct nicvf_cq_poll*napi[8];
u8 vf_id;
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 16ed203..dc845a0 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -20,8 +20,23 @@
#define DRV_NAME "thunder-nic"
#define DRV_VERSION"1.0"
+struct hw_info {
+ u8 bgx_cnt;
+ u8 chans_per_lmac;
+ u8 chans_per_bgx; /* Rx/Tx chans */
+ u16 cpi_cnt;
+ u16 rssi_cnt;
+ u16 rss_ind_tbl_size;
+ u16 tl4_cnt;
+ u16 tl3_cnt;
+ u8 tl2_cnt;
+ u8 tl1_cnt;
+ booltl1_per_bgx; /* TL1 per BGX or per LMAC */
+};
+
struct nicpf {
struct pci_dev *pdev;
+ struct hw_info *hw;
u8 node;
unsigned intflags;
u8 num_vf_en; /* No of VF enabled */
@@ -44,7 +59,6 @@ struct nicpf {
u32 speed[MAX_LMAC];
u16 cpi_base[MAX_NUM_VFS_SUPPORTED];
u16 rssi_base[MAX_NUM_VFS_SUPPORTED];
- u16 rss_ind_tbl_size;
bo
[PATCH v2 07/15] net: thunderx: Support for different LMAC types within BGX
From: Sunil Goutham
On 88xx all LMACs in a BGX will be in same mode but on 81xx
BGX can be split as two and there can be LMACs configured in
different modes.
These changes move lmac_type, lane2serdes fields into per lmac
struct from BGX struct. Got rid of qlm_mode field which has become
redundant with these changes. And now no of valid LMACs is read
from CSRs configured by low level firmware and figuring out the
same based on QLM mode is discarded
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 224 ++
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 10 -
2 files changed, 98 insertions(+), 136 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 63a39ac..4497427 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -28,6 +28,9 @@ struct lmac {
struct bgx *bgx;
int dmac;
u8 mac[ETH_ALEN];
+ u8 lmac_type;
+ u8 lane_to_sds;
+ booluse_training;
boollink_up;
int lmacid; /* ID within BGX */
int lmacid_bd; /* ID on board */
@@ -43,12 +46,8 @@ struct lmac {
struct bgx {
u8 bgx_id;
- u8 qlm_mode;
struct lmaclmac[MAX_LMAC_PER_BGX];
int lmac_count;
- int lmac_type;
- int lane_to_sds;
- int use_training;
void __iomem*reg_base;
struct pci_dev *pdev;
};
@@ -418,9 +417,10 @@ static int bgx_lmac_sgmii_init(struct bgx *bgx, int lmacid)
return 0;
}
-static int bgx_lmac_xaui_init(struct bgx *bgx, int lmacid, int lmac_type)
+static int bgx_lmac_xaui_init(struct bgx *bgx, struct lmac *lmac)
{
u64 cfg;
+ int lmacid = lmac->lmacid;
/* Reset SPU */
bgx_reg_modify(bgx, lmacid, BGX_SPUX_CONTROL1, SPU_CTL_RESET);
@@ -436,7 +436,7 @@ static int bgx_lmac_xaui_init(struct bgx *bgx, int lmacid,
int lmac_type)
bgx_reg_modify(bgx, lmacid, BGX_SPUX_CONTROL1, SPU_CTL_LOW_POWER);
/* Set interleaved running disparity for RXAUI */
- if (bgx->lmac_type != BGX_MODE_RXAUI)
+ if (lmac->lmac_type != BGX_MODE_RXAUI)
bgx_reg_modify(bgx, lmacid,
BGX_SPUX_MISC_CONTROL, SPU_MISC_CTL_RX_DIS);
else
@@ -451,7 +451,7 @@ static int bgx_lmac_xaui_init(struct bgx *bgx, int lmacid,
int lmac_type)
cfg = bgx_reg_read(bgx, lmacid, BGX_SPUX_INT);
bgx_reg_write(bgx, lmacid, BGX_SPUX_INT, cfg);
- if (bgx->use_training) {
+ if (lmac->use_training) {
bgx_reg_write(bgx, lmacid, BGX_SPUX_BR_PMD_LP_CUP, 0x00);
bgx_reg_write(bgx, lmacid, BGX_SPUX_BR_PMD_LD_CUP, 0x00);
bgx_reg_write(bgx, lmacid, BGX_SPUX_BR_PMD_LD_REP, 0x00);
@@ -474,9 +474,9 @@ static int bgx_lmac_xaui_init(struct bgx *bgx, int lmacid,
int lmac_type)
bgx_reg_write(bgx, lmacid, BGX_SPUX_AN_CONTROL, cfg);
cfg = bgx_reg_read(bgx, lmacid, BGX_SPUX_AN_ADV);
- if (bgx->lmac_type == BGX_MODE_10G_KR)
+ if (lmac->lmac_type == BGX_MODE_10G_KR)
cfg |= (1 << 23);
- else if (bgx->lmac_type == BGX_MODE_40G_KR)
+ else if (lmac->lmac_type == BGX_MODE_40G_KR)
cfg |= (1 << 24);
else
cfg &= ~((1 << 23) | (1 << 24));
@@ -511,11 +511,11 @@ static int bgx_xaui_check_link(struct lmac *lmac)
{
struct bgx *bgx = lmac->bgx;
int lmacid = lmac->lmacid;
- int lmac_type = bgx->lmac_type;
+ int lmac_type = lmac->lmac_type;
u64 cfg;
bgx_reg_modify(bgx, lmacid, BGX_SPUX_MISC_CONTROL, SPU_MISC_CTL_RX_DIS);
- if (bgx->use_training) {
+ if (lmac->use_training) {
cfg = bgx_reg_read(bgx, lmacid, BGX_SPUX_INT);
if (!(cfg & (1ull << 13))) {
cfg = (1ull << 13) | (1ull << 14);
@@ -556,7 +556,7 @@ static int bgx_xaui_check_link(struct lmac *lmac)
BGX_SPUX_STATUS2, SPU_STATUS2_RCVFLT);
if (bgx_reg_read(bgx, lmacid, BGX_SPUX_STATUS2) & SPU_STATUS2_RCVFLT) {
dev_err(&bgx->pdev->dev, "Receive fault, retry training\n");
- if (bgx->use_training) {
+ if (lmac->use_training) {
cfg = bgx_reg_read(bgx, lmacid, BGX_SPUX_INT);
if (!(cfg & (1ull << 13))) {
cfg = (1ull << 13) | (1ull << 14);
@@ -599,7 +599,7 @@ static int bgx_xaui_check_link(struct lmac *lmac)
/* Rx local/remote fault seen.
* Do lma
[PATCH v2 02/15] net: thunderx: Add VNIC's PCI devid on future chips
From: Sunil Goutham
This patch adds PCI device IDs of VNIC on newer chips and also
registers VF driver with them. Device id remains same for all
versions of chips but subsystem device id changes.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic.h| 10 +-
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 14 --
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
b/drivers/net/ethernet/cavium/thunder/nic.h
index 66b499b..6b0b240 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -21,7 +21,15 @@
#definePCI_DEVICE_ID_THUNDER_BGX 0xA026
/* Subsystem device IDs */
-#define PCI_SUBSYS_DEVID_88XX_NIC_PF 0xA11E
+#define PCI_SUBSYS_DEVID_88XX_NIC_PF 0xA11E
+#define PCI_SUBSYS_DEVID_81XX_NIC_PF 0xA21E
+#define PCI_SUBSYS_DEVID_83XX_NIC_PF 0xA31E
+
+#define PCI_SUBSYS_DEVID_88XX_PASS1_NIC_VF 0xA11E
+#define PCI_SUBSYS_DEVID_88XX_NIC_VF 0xA134
+#define PCI_SUBSYS_DEVID_81XX_NIC_VF 0xA234
+#define PCI_SUBSYS_DEVID_83XX_NIC_VF 0xA334
+
/* PCI BAR nos */
#definePCI_CFG_REG_BAR_NUM 0
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index a19e73f..0c10635 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -29,10 +29,20 @@
static const struct pci_device_id nicvf_id_table[] = {
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_CAVIUM,
PCI_DEVICE_ID_THUNDER_NIC_VF,
-PCI_VENDOR_ID_CAVIUM, 0xA134) },
+PCI_VENDOR_ID_CAVIUM,
+PCI_SUBSYS_DEVID_88XX_NIC_VF) },
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_CAVIUM,
PCI_DEVICE_ID_THUNDER_PASS1_NIC_VF,
-PCI_VENDOR_ID_CAVIUM, 0xA11E) },
+PCI_VENDOR_ID_CAVIUM,
+PCI_SUBSYS_DEVID_88XX_PASS1_NIC_VF) },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_CAVIUM,
+PCI_DEVICE_ID_THUNDER_NIC_VF,
+PCI_VENDOR_ID_CAVIUM,
+PCI_SUBSYS_DEVID_81XX_NIC_VF) },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_CAVIUM,
+PCI_DEVICE_ID_THUNDER_NIC_VF,
+PCI_VENDOR_ID_CAVIUM,
+PCI_SUBSYS_DEVID_83XX_NIC_VF) },
{ 0, } /* end of table */
};
--
2.7.4
[PATCH v2 13/15] net: thunderx: Improvement for MBX interface debug messages
From: Radoslaw Biernacki
Adding debug messages in case of NACK for a mailbox message, also
did small cleanups.
Signed-off-by: Radoslaw Biernacki
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 16 ++--
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 8 ++--
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index cd642f3..e17f58a 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -809,7 +809,7 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int vf)
mbx_addr += sizeof(u64);
}
- dev_dbg(&nic->pdev->dev, "%s: Mailbox msg %d from VF%d\n",
+ dev_dbg(&nic->pdev->dev, "%s: Mailbox msg 0x%02x from VF%d\n",
__func__, mbx.msg.msg, vf);
switch (mbx.msg.msg) {
case NIC_MBOX_MSG_READY:
@@ -819,8 +819,7 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int vf)
nic->duplex[vf] = 0;
nic->speed[vf] = 0;
}
- ret = 1;
- break;
+ goto unlock;
case NIC_MBOX_MSG_QS_CFG:
reg_addr = NIC_PF_QSET_0_127_CFG |
(mbx.qs.num << NIC_QS_ID_SHIFT);
@@ -869,8 +868,10 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int vf)
nic_tx_channel_cfg(nic, mbx.qs.num, &mbx.sq);
break;
case NIC_MBOX_MSG_SET_MAC:
- if (vf >= nic->num_vf_en)
+ if (vf >= nic->num_vf_en) {
+ ret = -1; /* NACK */
break;
+ }
lmac = mbx.mac.vf_id;
bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[lmac]);
lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[lmac]);
@@ -925,10 +926,13 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int vf)
break;
}
- if (!ret)
+ if (!ret) {
nic_mbx_send_ack(nic, vf);
- else if (mbx.msg.msg != NIC_MBOX_MSG_READY)
+ } else if (mbx.msg.msg != NIC_MBOX_MSG_READY) {
+ dev_err(&nic->pdev->dev, "NACK for MBOX 0x%02x from VF %d\n",
+ mbx.msg.msg, vf);
nic_mbx_send_nack(nic, vf);
+ }
unlock:
nic->mbx_lock[vf] = false;
}
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index dbb61a8..300416a 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -144,15 +144,19 @@ int nicvf_send_msg_to_pf(struct nicvf *nic, union nic_mbx
*mbx)
/* Wait for previous message to be acked, timeout 2sec */
while (!nic->pf_acked) {
- if (nic->pf_nacked)
+ if (nic->pf_nacked) {
+ netdev_err(nic->netdev,
+ "PF NACK to mbox msg 0x%02x from VF%d\n",
+ (mbx->msg.msg & 0xFF), nic->vf_id);
return -EINVAL;
+ }
msleep(sleep);
if (nic->pf_acked)
break;
timeout -= sleep;
if (!timeout) {
netdev_err(nic->netdev,
- "PF didn't ack to mbox msg %d from VF%d\n",
+ "PF didn't ACK to mbox msg 0x%02x from
VF%d\n",
(mbx->msg.msg & 0xFF), nic->vf_id);
return -EBUSY;
}
--
2.7.4
[PATCH v2 09/15] net: thunderx: Add QSGMII interface type support
From: Sunil Goutham
This patch adds support for QSGMII interface type to
the BGX driver. This type of interface is supported by
81xx SOC.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 55 ++-
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 1 +
2 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 9c3c273..3274430 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -379,8 +379,9 @@ void bgx_lmac_internal_loopback(int node, int bgx_idx,
}
EXPORT_SYMBOL(bgx_lmac_internal_loopback);
-static int bgx_lmac_sgmii_init(struct bgx *bgx, int lmacid)
+static int bgx_lmac_sgmii_init(struct bgx *bgx, struct lmac *lmac)
{
+ int lmacid = lmac->lmacid;
u64 cfg;
bgx_reg_modify(bgx, lmacid, BGX_GMP_GMI_TXX_THRESH, 0x30);
@@ -409,6 +410,14 @@ static int bgx_lmac_sgmii_init(struct bgx *bgx, int lmacid)
cfg |= (PCS_MRX_CTL_RST_AN | PCS_MRX_CTL_AN_EN);
bgx_reg_write(bgx, lmacid, BGX_GMP_PCS_MRX_CTL, cfg);
+ if (lmac->lmac_type == BGX_MODE_QSGMII) {
+ /* Disable disparity check for QSGMII */
+ cfg = bgx_reg_read(bgx, lmacid, BGX_GMP_PCS_MISCX_CTL);
+ cfg &= ~PCS_MISC_CTL_DISP_EN;
+ bgx_reg_write(bgx, lmacid, BGX_GMP_PCS_MISCX_CTL, cfg);
+ return 0;
+ }
+
if (bgx_poll_reg(bgx, lmacid, BGX_GMP_PCS_MRX_STATUS,
PCS_MRX_STATUS_AN_CPT, false)) {
dev_err(&bgx->pdev->dev, "BGX AN_CPT not completed\n");
@@ -658,9 +667,10 @@ static int bgx_lmac_enable(struct bgx *bgx, u8 lmacid)
lmac = &bgx->lmac[lmacid];
lmac->bgx = bgx;
- if (lmac->lmac_type == BGX_MODE_SGMII) {
+ if ((lmac->lmac_type == BGX_MODE_SGMII) ||
+ (lmac->lmac_type == BGX_MODE_QSGMII)) {
lmac->is_sgmii = 1;
- if (bgx_lmac_sgmii_init(bgx, lmacid))
+ if (bgx_lmac_sgmii_init(bgx, lmac))
return -1;
} else {
lmac->is_sgmii = 0;
@@ -799,6 +809,11 @@ static void bgx_init_hw(struct bgx *bgx)
bgx_reg_write(bgx, 0, BGX_CMR_RX_STREERING + (i * 8), 0x00);
}
+static u8 bgx_get_lane2sds_cfg(struct bgx *bgx, struct lmac *lmac)
+{
+ return (u8)(bgx_reg_read(bgx, lmac->lmacid, BGX_CMRX_CFG) & 0xFF);
+}
+
static void bgx_print_qlm_mode(struct bgx *bgx, u8 lmacid)
{
struct device *dev = &bgx->pdev->dev;
@@ -838,12 +853,22 @@ static void bgx_print_qlm_mode(struct bgx *bgx, u8 lmacid)
else
dev_info(dev, "%s: 40G_KR4\n", (char *)str);
break;
- default:
- dev_info(dev, "%s: INVALID\n", (char *)str);
+ case BGX_MODE_QSGMII:
+ if ((lmacid == 0) &&
+ (bgx_get_lane2sds_cfg(bgx, lmac) != lmacid))
+ return;
+ if ((lmacid == 2) &&
+ (bgx_get_lane2sds_cfg(bgx, lmac) == lmacid))
+ return;
+ dev_info(dev, "%s: QSGMII\n", (char *)str);
+ break;
+ case BGX_MODE_INVALID:
+ /* Nothing to do */
+ break;
}
}
-static void lmac_set_lane2sds(struct lmac *lmac)
+static void lmac_set_lane2sds(struct bgx *bgx, struct lmac *lmac)
{
switch (lmac->lmac_type) {
case BGX_MODE_SGMII:
@@ -857,6 +882,14 @@ static void lmac_set_lane2sds(struct lmac *lmac)
case BGX_MODE_RXAUI:
lmac->lane_to_sds = (lmac->lmacid) ? 0xE : 0x4;
break;
+ case BGX_MODE_QSGMII:
+ /* There is no way to determine if DLM0/2 is QSGMII or
+* DLM1/3 is configured to QSGMII as bootloader will
+* configure all LMACs, so take whatever is configured
+* by low level firmware.
+*/
+ lmac->lane_to_sds = bgx_get_lane2sds_cfg(bgx, lmac);
+ break;
default:
lmac->lane_to_sds = 0;
break;
@@ -882,7 +915,7 @@ static void bgx_set_lmac_config(struct bgx *bgx, u8 idx)
lmac->use_training =
bgx_reg_read(bgx, 0, BGX_SPUX_BR_PMD_CRTL) &
SPU_PMD_CRTL_TRAIN_EN;
- lmac_set_lane2sds(lmac);
+ lmac_set_lane2sds(bgx, lmac);
return;
}
@@ -901,7 +934,7 @@ static void bgx_set_lmac_config(struct bgx *bgx, u8 idx)
lmac->use_training =
bgx_reg_read(bgx, idx, BGX_SPUX_BR_PMD_CRTL) &
SPU_PMD_CRTL_TRAIN_EN;
- lmac_set_lane2sds(lmac);
+ lmac_set_lane2sds(bgx, lmac);
/* Set LMAC type of other lmac on sam
[PATCH v2 14/15] net: thunderx: Reset RXQ HW stats when interface is brought down
From: Jerin Jacob
When SQ/TXQ is reclaimed i.e reset it's stats also automatically reset
by HW. This is not the case with RQ. Also VF doesn't have write access
to statistics counter registers. Hence a new Mbox msg is introduced which
supports resetting RQ, SQ and full Qset stats. Currently only RQ stats
are being reset using this mbox message.
Signed-off-by: Jerin Jacob
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic.h | 27 +
drivers/net/ethernet/cavium/thunder/nic_main.c | 45 ++
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 15
3 files changed, 87 insertions(+)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
b/drivers/net/ethernet/cavium/thunder/nic.h
index 136db2a..dd63f96 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -347,6 +347,7 @@ struct nicvf {
#defineNIC_MBOX_MSG_PNICVF_PTR 0x14/* Get primary qset
nicvf ptr */
#defineNIC_MBOX_MSG_SNICVF_PTR 0x15/* Send sqet nicvf ptr
to PVF */
#defineNIC_MBOX_MSG_LOOPBACK 0x16/* Set interface in
loopback */
+#defineNIC_MBOX_MSG_RESET_STAT_COUNTER 0x17/* Reset statistics
counters */
#defineNIC_MBOX_MSG_CFG_DONE 0xF0/* VF configuration
done */
#defineNIC_MBOX_MSG_SHUTDOWN 0xF1/* VF is being shutdown
*/
@@ -463,6 +464,31 @@ struct set_loopback {
bool enable;
};
+/* Reset statistics counters */
+struct reset_stat_cfg {
+ u8msg;
+ /* Bitmap to select NIC_PF_VNIC(vf_id)_RX_STAT(0..13) */
+ u16 rx_stat_mask;
+ /* Bitmap to select NIC_PF_VNIC(vf_id)_TX_STAT(0..4) */
+ u8tx_stat_mask;
+ /* Bitmap to select NIC_PF_QS(0..127)_RQ(0..7)_STAT(0..1)
+* bit14, bit15 NIC_PF_QS(vf_id)_RQ7_STAT(0..1)
+* bit12, bit13 NIC_PF_QS(vf_id)_RQ6_STAT(0..1)
+* ..
+* bit2, bit3 NIC_PF_QS(vf_id)_RQ1_STAT(0..1)
+* bit0, bit1 NIC_PF_QS(vf_id)_RQ0_STAT(0..1)
+*/
+ u16 rq_stat_mask;
+ /* Bitmap to select NIC_PF_QS(0..127)_SQ(0..7)_STAT(0..1)
+* bit14, bit15 NIC_PF_QS(vf_id)_SQ7_STAT(0..1)
+* bit12, bit13 NIC_PF_QS(vf_id)_SQ6_STAT(0..1)
+* ..
+* bit2, bit3 NIC_PF_QS(vf_id)_SQ1_STAT(0..1)
+* bit0, bit1 NIC_PF_QS(vf_id)_SQ0_STAT(0..1)
+*/
+ u16 sq_stat_mask;
+};
+
/* 128 bit shared memory between PF and each VF */
union nic_mbx {
struct { u8 msg; } msg;
@@ -480,6 +506,7 @@ union nic_mbx {
struct sqs_allocsqs_alloc;
struct nicvf_ptrnicvf;
struct set_loopback lbk;
+ struct reset_stat_cfg reset_stat;
};
#define NIC_NODE_ID_MASK 0x03
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index e17f58a..255821d 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -771,6 +771,48 @@ static int nic_config_loopback(struct nicpf *nic, struct
set_loopback *lbk)
return 0;
}
+/* Reset statistics counters */
+static int nic_reset_stat_counters(struct nicpf *nic,
+ int vf, struct reset_stat_cfg *cfg)
+{
+ int i, stat, qnum;
+ u64 reg_addr;
+
+ for (i = 0; i < RX_STATS_ENUM_LAST; i++) {
+ if (cfg->rx_stat_mask & BIT(i)) {
+ reg_addr = NIC_PF_VNIC_0_127_RX_STAT_0_13 |
+ (vf << NIC_QS_ID_SHIFT) |
+ (i << 3);
+ nic_reg_write(nic, reg_addr, 0);
+ }
+ }
+
+ for (i = 0; i < TX_STATS_ENUM_LAST; i++) {
+ if (cfg->tx_stat_mask & BIT(i)) {
+ reg_addr = NIC_PF_VNIC_0_127_TX_STAT_0_4 |
+ (vf << NIC_QS_ID_SHIFT) |
+ (i << 3);
+ nic_reg_write(nic, reg_addr, 0);
+ }
+ }
+
+ for (i = 0; i <= 15; i++) {
+ qnum = i >> 1;
+ stat = i & 1 ? 1 : 0;
+ reg_addr = (vf << NIC_QS_ID_SHIFT) |
+ (qnum << NIC_Q_NUM_SHIFT) | (stat << 3);
+ if (cfg->rq_stat_mask & BIT(i)) {
+ reg_addr |= NIC_PF_QSET_0_127_RQ_0_7_STAT_0_1;
+ nic_reg_write(nic, reg_addr, 0);
+ }
+ if (cfg->sq_stat_mask & BIT(i)) {
+ reg_addr |= NIC_PF_QSET_0_127_SQ_0_7_STAT_0_1;
+ nic_reg_write(nic, reg_addr, 0);
+ }
+ }
+ return 0;
+}
+
static void nic_enable_vf(struct nicpf *nic, int vf, bool enable)
{
int bgx, lmac;
@@ -920,6 +962,9 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int vf)
case NIC_MBOX_MSG_LOOPBACK:
[PATCH v2 03/15] net: thunderx: Add support for 81xx and 83xx chips
From: Sunil Goutham
This patch adds info on HW maximums of 81xx/83xx and also
configures receive and transmit datapaths accordingly.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic_main.c| 87 ++-
drivers/net/ethernet/cavium/thunder/nic_reg.h | 1 +
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 2 +
3 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index dc845a0..4974923 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -24,6 +24,8 @@ struct hw_info {
u8 bgx_cnt;
u8 chans_per_lmac;
u8 chans_per_bgx; /* Rx/Tx chans */
+ u8 chans_per_rgx;
+ u8 chans_per_lbk;
u16 cpi_cnt;
u16 rssi_cnt;
u16 rss_ind_tbl_size;
@@ -332,6 +334,33 @@ static void nic_get_hw_info(struct nicpf *nic)
hw->tl1_cnt = 2;
hw->tl1_per_bgx = true;
break;
+ case PCI_SUBSYS_DEVID_81XX_NIC_PF:
+ hw->bgx_cnt = MAX_BGX_PER_CN81XX;
+ hw->chans_per_lmac = 8;
+ hw->chans_per_bgx = 32;
+ hw->chans_per_rgx = 8;
+ hw->chans_per_lbk = 24;
+ hw->cpi_cnt = 512;
+ hw->rssi_cnt = 256;
+ hw->rss_ind_tbl_size = 32; /* Max RSSI / Max interfaces */
+ hw->tl3_cnt = 64;
+ hw->tl2_cnt = 16;
+ hw->tl1_cnt = 10;
+ hw->tl1_per_bgx = false;
+ break;
+ case PCI_SUBSYS_DEVID_83XX_NIC_PF:
+ hw->bgx_cnt = MAX_BGX_PER_CN83XX;
+ hw->chans_per_lmac = 8;
+ hw->chans_per_bgx = 32;
+ hw->chans_per_lbk = 64;
+ hw->cpi_cnt = 2048;
+ hw->rssi_cnt = 1024;
+ hw->rss_ind_tbl_size = 64; /* Max RSSI / Max interfaces */
+ hw->tl3_cnt = 256;
+ hw->tl2_cnt = 64;
+ hw->tl1_cnt = 18;
+ hw->tl1_per_bgx = false;
+ break;
}
hw->tl4_cnt = MAX_QUEUES_PER_QSET * pci_sriov_get_totalvfs(nic->pdev);
}
@@ -353,11 +382,15 @@ static void nic_init_hw(struct nicpf *nic)
/* Enable backpressure */
nic_reg_write(nic, NIC_PF_BP_CFG, (1ULL << 6) | 0x03);
- /* Disable TNS mode on both interfaces */
- nic_reg_write(nic, NIC_PF_INTF_0_1_SEND_CFG,
- (NIC_TNS_BYPASS_MODE << 7) | BGX0_BLOCK);
- nic_reg_write(nic, NIC_PF_INTF_0_1_SEND_CFG | (1 << 8),
- (NIC_TNS_BYPASS_MODE << 7) | BGX1_BLOCK);
+ /* TNS and TNS bypass modes are present only on 88xx */
+ if (nic->pdev->subsystem_device == PCI_SUBSYS_DEVID_88XX_NIC_PF) {
+ /* Disable TNS mode on both interfaces */
+ nic_reg_write(nic, NIC_PF_INTF_0_1_SEND_CFG,
+ (NIC_TNS_BYPASS_MODE << 7) | BGX0_BLOCK);
+ nic_reg_write(nic, NIC_PF_INTF_0_1_SEND_CFG | (1 << 8),
+ (NIC_TNS_BYPASS_MODE << 7) | BGX1_BLOCK);
+ }
+
nic_reg_write(nic, NIC_PF_INTF_0_1_BP_CFG,
(1ULL << 63) | BGX0_BLOCK);
nic_reg_write(nic, NIC_PF_INTF_0_1_BP_CFG + (1 << 8),
@@ -525,7 +558,7 @@ static void nic_config_rss(struct nicpf *nic, struct
rss_cfg_msg *cfg)
/* 4 level transmit side scheduler configutation
* for TNS bypass mode
*
- * Sample configuration for SQ0
+ * Sample configuration for SQ0 on 88xx
* VNIC0-SQ0 -> TL4(0) -> TL3[0] -> TL2[0] -> TL1[0] -> BGX0
* VNIC1-SQ0 -> TL4(8) -> TL3[2] -> TL2[0] -> TL1[0] -> BGX0
* VNIC2-SQ0 -> TL4(16) -> TL3[4] -> TL2[1] -> TL1[0] -> BGX0
@@ -560,17 +593,21 @@ static void nic_tx_channel_cfg(struct nicpf *nic, u8 vnic,
/* For 88xx 0-511 TL4 transmits via BGX0 and
* 512-1023 TL4s transmit via BGX1.
*/
- tl4 = bgx * (hw->tl4_cnt / hw->bgx_cnt);
- if (!sq->sqs_mode) {
- tl4 += (lmac * MAX_QUEUES_PER_QSET);
- } else {
- for (svf = 0; svf < MAX_SQS_PER_VF; svf++) {
- if (nic->vf_sqs[pqs_vnic][svf] == vnic)
- break;
+ if (hw->tl1_per_bgx) {
+ tl4 = bgx * (hw->tl4_cnt / hw->bgx_cnt);
+ if (!sq->sqs_mode) {
+ tl4 += (lmac * MAX_QUEUES_PER_QSET);
+ } else {
+ for (svf = 0; svf < MAX_SQS_PER_VF; svf++) {
+ if (nic->vf_sqs[pqs_vnic][svf] == vnic)
+ break;
+ }
+ tl4 += (MAX_LMAC_PER_BGX * MAX_QUEUES_PER_QSET);
+ tl4 += (lmac * MAX_QUEUES_PER_QSET * MAX_SQS_PER_VF);
+
[PATCH][RFC v2] PM / hibernate: Introduce snapshot test mode for hibernation
This mode is used to verify if the snapshot data written to
the swap device can be successfully restored to the memory. It
is useful to ease the debugging process on hibernation,
since this mode can not only bypass the BIOSen/bootloader,
but also the system re-initialization.
For example:
$ sudo echo snapshot > /sys/power/pm_test
$ sudo echo disk > /sys/power/state
[ 267.959784] PM: Image saving progress: 80%
[ 268.038669] PM: Image saving progress: 90%
[ 268.111745] PM: Image saving progress: 100%
[ 268.129269] PM: Image saving done.
[ 268.133485] PM: Wrote 518612 kbytes in 0.75 seconds (691.48 MB/s)
[ 268.140564] PM: S|
[ 268.160067] hibernation debug: Waiting for 5 seconds.
...
[ 273.508638] PM: Looking for hibernation image.
[ 273.516583] PM: Image signature found, resuming
[ 273.926547] PM: Loading and decompressing image data (129653 pages)...
[ 274.122452] PM: Image loading progress: 0%
[ 274.322127] PM: Image loading progress: 10%
...
Rebased on top of linux-next.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Chen Yu
---
kernel/power/hibernate.c | 10 --
kernel/power/main.c | 3 +++
kernel/power/power.h | 3 +++
kernel/power/swap.c | 7 +++
4 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 51441d8..30cc5b4 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -43,6 +43,7 @@ static char resume_file[256] = CONFIG_PM_STD_PARTITION;
dev_t swsusp_resume_device;
sector_t swsusp_resume_block;
__visible int in_suspend __nosavedata;
+static int software_resume(void);
enum {
HIBERNATION_INVALID,
@@ -647,7 +648,7 @@ static void power_down(void)
*/
int hibernate(void)
{
- int error, nr_calls = 0;
+ int error, nr_calls = 0, snapshot_test = 0;
if (!hibernation_available()) {
pr_debug("PM: Hibernation not available.\n");
@@ -699,7 +700,9 @@ int hibernate(void)
pr_debug("PM: writing image.\n");
error = swsusp_write(flags);
swsusp_free();
- if (!error)
+ if (hibernation_test(TEST_SNAPSHOT))
+ snapshot_test = 1;
+ if (!error && !snapshot_test)
power_down();
in_suspend = 0;
pm_restore_gfp_mask();
@@ -721,6 +724,9 @@ int hibernate(void)
atomic_inc(&snapshot_device_available);
Unlock:
unlock_system_sleep();
+ if (snapshot_test)
+ software_resume();
+
return error;
}
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 5ea50b1..80fe48e 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -83,6 +83,9 @@ int pm_test_level = TEST_NONE;
static const char * const pm_tests[__TEST_AFTER_LAST] = {
[TEST_NONE] = "none",
+#ifdef CONFIG_HIBERNATION
+ [TEST_SNAPSHOT] = "snapshot",
+#endif
[TEST_CORE] = "core",
[TEST_CPUS] = "processors",
[TEST_PLATFORM] = "platform",
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 064963e..101d636 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -225,6 +225,9 @@ static inline int restore_highmem(void) { return 0; }
enum {
/* keep first */
TEST_NONE,
+#ifdef CONFIG_HIBERNATION
+ TEST_SNAPSHOT,
+#endif
TEST_CORE,
TEST_CPUS,
TEST_PLATFORM,
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index 160e100..facd71b 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -348,6 +348,13 @@ static int swsusp_swap_check(void)
if (res < 0)
blkdev_put(hib_resume_bdev, FMODE_WRITE);
+ /*
+* Update the resume device to the one actually used,
+* so software_resume() can use it in case it is invoked
+* from hibernate() to test the snapshot.
+*/
+ swsusp_resume_device = hib_resume_bdev->bd_dev;
+
return res;
}
--
2.7.4
[PATCH v2 10/15] net: thunderx: Add RGMII interface type support
From: Sunil Goutham
This patch adds RGX/RGMII interface type support to BGX
driver. This type of interface is supported by 81xx SOC.
CN81XX VNIC has 8 VFs and max possible LMAC interfaces are 9,
hence RGMII interface will not work if all DLMs are in BGX mode
and all 8 LMACs are enabled.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/Kconfig | 10 +
drivers/net/ethernet/cavium/thunder/Makefile | 1 +
drivers/net/ethernet/cavium/thunder/nic_main.c| 35 +++-
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 95 ++---
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 6 +-
drivers/net/ethernet/cavium/thunder/thunder_xcv.c | 237 ++
6 files changed, 350 insertions(+), 34 deletions(-)
create mode 100644 drivers/net/ethernet/cavium/thunder/thunder_xcv.c
diff --git a/drivers/net/ethernet/cavium/Kconfig
b/drivers/net/ethernet/cavium/Kconfig
index 0ef232d..e1b78b5 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -36,10 +36,20 @@ config THUNDER_NIC_BGX
depends on 64BIT
select PHYLIB
select MDIO_THUNDER
+ select THUNDER_NIC_RGX
---help---
This driver supports programming and controlling of MAC
interface from NIC physical function driver.
+config THUNDER_NIC_RGX
+ tristate "Thunder MAC interface driver (RGX)"
+ depends on 64BIT
+ select PHYLIB
+ select MDIO_THUNDER
+ ---help---
+ This driver supports configuring XCV block of RGX interface
+ present on CN81XX chip.
+
config LIQUIDIO
tristate "Cavium LiquidIO support"
depends on 64BIT
diff --git a/drivers/net/ethernet/cavium/thunder/Makefile
b/drivers/net/ethernet/cavium/thunder/Makefile
index 5c4615c..6b4d4ad 100644
--- a/drivers/net/ethernet/cavium/thunder/Makefile
+++ b/drivers/net/ethernet/cavium/thunder/Makefile
@@ -2,6 +2,7 @@
# Makefile for Cavium's Thunder ethernet device
#
+obj-$(CONFIG_THUNDER_NIC_RGX) += thunder_xcv.o
obj-$(CONFIG_THUNDER_NIC_BGX) += thunder_bgx.o
obj-$(CONFIG_THUNDER_NIC_PF) += nicpf.o
obj-$(CONFIG_THUNDER_NIC_VF) += nicvf.o
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 955c522..cd642f3 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -325,6 +325,14 @@ static void nic_set_lmac_vf_mapping(struct nicpf *nic)
nic_reg_write(nic,
NIC_PF_LMAC_0_7_CREDIT + (lmac * 8),
lmac_credit);
+
+ /* On CN81XX there are only 8 VFs but max possible no of
+* interfaces are 9.
+*/
+ if (nic->num_vf_en >= pci_sriov_get_totalvfs(nic->pdev)) {
+ nic->num_vf_en = pci_sriov_get_totalvfs(nic->pdev);
+ break;
+ }
}
}
@@ -444,16 +452,25 @@ static void nic_config_cpi(struct nicpf *nic, struct
cpi_cfg_msg *cfg)
u32 padd, cpi_count = 0;
u64 cpi_base, cpi, rssi_base, rssi;
u8 qset, rq_idx = 0;
+ u16 sdevid;
+
+ pci_read_config_word(nic->pdev, PCI_SUBSYSTEM_ID, &sdevid);
vnic = cfg->vf_id;
bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vnic]);
lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vnic]);
chan = (lmac * hw->chans_per_lmac) + (bgx * hw->chans_per_bgx);
- cpi_base = (lmac * NIC_MAX_CPI_PER_LMAC) +
- (bgx * (hw->cpi_cnt / hw->bgx_cnt));
- rssi_base = (lmac * hw->rss_ind_tbl_size) +
- (bgx * (hw->rssi_cnt / hw->bgx_cnt));
+ /* Check for RGX interface on CN81XX */
+ if ((sdevid == PCI_SUBSYS_DEVID_81XX_NIC_PF) && (bgx == 2)) {
+ cpi_base = (3 * NIC_MAX_CPI_PER_LMAC) + (hw->cpi_cnt / 2);
+ rssi_base = (3 * hw->rss_ind_tbl_size) + (hw->rssi_cnt / 2);
+ } else {
+ cpi_base = (lmac * NIC_MAX_CPI_PER_LMAC) +
+ (bgx * (hw->cpi_cnt / hw->bgx_cnt));
+ rssi_base = (lmac * hw->rss_ind_tbl_size) +
+ (bgx * (hw->rssi_cnt / hw->bgx_cnt));
+ }
/* Rx channel configuration */
nic_reg_write(nic, NIC_PF_CHAN_0_255_RX_BP_CFG | (chan << 3),
@@ -592,6 +609,9 @@ static void nic_tx_channel_cfg(struct nicpf *nic, u8 vnic,
u8 sq_idx = sq->sq_num;
u8 pqs_vnic;
int svf;
+ u16 sdevid;
+
+ pci_read_config_word(nic->pdev, PCI_SUBSYSTEM_ID, &sdevid);
if (sq->sqs_mode)
pqs_vnic = nic->pqs_vf[vnic];
@@ -608,7 +628,12 @@ static void nic_tx_channel_cfg(struct nicpf *nic, u8 vnic,
* 512-1023 TL4s transmit via BGX1.
*/
if (hw->tl1_per_bgx) {
- tl4 = bgx * (hw->tl4_cnt / hw->bgx_cnt);
+ /* Check for RGX
[PATCH v2 15/15] net: thunderx: Don't set mac address for secondary Qset VFs
From: Sunil Goutham
Set MAC addresses only for primary VF's and don't for
secondary VFs.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 2 +-
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 255821d..dfa27de 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -174,7 +174,7 @@ static void nic_mbx_send_ready(struct nicpf *nic, int vf)
mbx.nic_cfg.tns_mode = NIC_TNS_BYPASS_MODE;
- if (vf < MAX_LMAC) {
+ if (vf < nic->num_vf_en) {
bgx_idx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 300416a..4a084ab 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1209,7 +1209,7 @@ int nicvf_open(struct net_device *netdev)
}
/* Check if we got MAC address from PF or else generate a radom MAC */
- if (is_zero_ether_addr(netdev->dev_addr)) {
+ if (!nic->sqs_mode && is_zero_ether_addr(netdev->dev_addr)) {
eth_hw_addr_random(netdev);
nicvf_hw_set_mac_addr(nic, netdev);
}
--
2.7.4
[PATCH v2 00/15] net: thunderx: Add support for 81xx and 83xx
From: Sunil Goutham This patch series adds support for VNIC on 81xx and 83xx SOCs. 81xx/83xx is different from 88xx in terms of capabilities and different types of interfaces supported (eg: QSGMII, RGMII) and have DLMs instead of QLMs which allows single BGX to have interfaces of different LMAC types. Also included some patches which are common for all 88xx/81xx/83xx SOCs like using netdev's name while registering irqs, reset receive queue stats and some cleanup changes. Changes from v1: Fixed warning reported by kbuild test robot in patch "Enable mailbox interrupts on 81xx/83xx" Jerin Jacob (1): net: thunderx: Reset RXQ HW stats when interface is brought down Radoslaw Biernacki (1): net: thunderx: Improvement for MBX interface debug messages Sunil Goutham (13): net: thunderx: Moved HW capability info from macros to structure net: thunderx: Add VNIC's PCI devid on future chips net: thunderx: Add support for 81xx and 83xx chips net: thunderx: Set queue count based on number of CPUs net: thunderx: Enable CQE_RX desc's extension fields net: thunderx: Enable mailbox interrupts on 81xx/83xx net: thunderx: Support for different LMAC types within BGX net: thunderx: Add 81xx support to BGX driver net: thunderx: Add QSGMII interface type support net: thunderx: Add RGMII interface type support net: thunderx: Use netdev's name for naming VF's interrupts net: thunderx: Use skb_add_rx_frag() for split buffer Rx pkts net: thunderx: Don't set mac address for secondary Qset VFs drivers/net/ethernet/cavium/Kconfig| 10 + drivers/net/ethernet/cavium/thunder/Makefile | 1 + drivers/net/ethernet/cavium/thunder/nic.h | 85 +++-- drivers/net/ethernet/cavium/thunder/nic_main.c | 362 ++ drivers/net/ethernet/cavium/thunder/nic_reg.h | 2 + drivers/net/ethernet/cavium/thunder/nicvf_main.c | 51 ++- drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 59 +-- drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 5 +- drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 410 ++--- drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 28 +- drivers/net/ethernet/cavium/thunder/thunder_xcv.c | 237 11 files changed, 949 insertions(+), 301 deletions(-) create mode 100644 drivers/net/ethernet/cavium/thunder/thunder_xcv.c -- 2.7.4
[PATCH v2 11/15] net: thunderx: Use netdev's name for naming VF's interrupts
From: Sunil Goutham
This patch changes the way VF's irqs are visible in /proc/interrupts.
Instead of VF id, logical interface's netdev name is used for IRQ
naming and also all secondary VF's interrupts in multiqset config
use primary VF's netdev name.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index af04d9f..dbb61a8 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -938,16 +938,19 @@ static int nicvf_register_interrupts(struct nicvf *nic)
int vector;
for_each_cq_irq(irq)
- sprintf(nic->irq_name[irq], "NICVF%d CQ%d",
- nic->vf_id, irq);
+ sprintf(nic->irq_name[irq], "%s-rxtx-%d",
+ nic->pnicvf->netdev->name,
+ nicvf_netdev_qidx(nic, irq));
for_each_sq_irq(irq)
- sprintf(nic->irq_name[irq], "NICVF%d SQ%d",
- nic->vf_id, irq - NICVF_INTR_ID_SQ);
+ sprintf(nic->irq_name[irq], "%s-sq-%d",
+ nic->pnicvf->netdev->name,
+ nicvf_netdev_qidx(nic, irq - NICVF_INTR_ID_SQ));
for_each_rbdr_irq(irq)
- sprintf(nic->irq_name[irq], "NICVF%d RBDR%d",
- nic->vf_id, irq - NICVF_INTR_ID_RBDR);
+ sprintf(nic->irq_name[irq], "%s-rbdr-%d",
+ nic->pnicvf->netdev->name,
+ nic->sqs_mode ? (nic->sqs_id + 1) : 0);
/* Register CQ interrupts */
for (irq = 0; irq < nic->qs->cq_cnt; irq++) {
@@ -971,8 +974,9 @@ static int nicvf_register_interrupts(struct nicvf *nic)
}
/* Register QS error interrupt */
- sprintf(nic->irq_name[NICVF_INTR_ID_QS_ERR],
- "NICVF%d Qset error", nic->vf_id);
+ sprintf(nic->irq_name[NICVF_INTR_ID_QS_ERR], "%s-qset-err-%d",
+ nic->pnicvf->netdev->name,
+ nic->sqs_mode ? (nic->sqs_id + 1) : 0);
irq = NICVF_INTR_ID_QS_ERR;
ret = request_irq(nic->msix_entries[irq].vector,
nicvf_qs_err_intr_handler,
--
2.7.4
[PATCH v2 08/15] net: thunderx: Add 81xx support to BGX driver
From: Sunil Goutham
This patch adds support for BGX module on 81xx where a BGX
can be split and have different LMACs configured in
different modes.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 112 --
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 11 +++
2 files changed, 113 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 4497427..9c3c273 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -50,6 +50,7 @@ struct bgx {
int lmac_count;
void __iomem*reg_base;
struct pci_dev *pdev;
+ boolis_81xx;
};
static struct bgx *bgx_vnic[MAX_BGX_THUNDER];
@@ -803,9 +804,17 @@ static void bgx_print_qlm_mode(struct bgx *bgx, u8 lmacid)
struct device *dev = &bgx->pdev->dev;
struct lmac *lmac;
char str[20];
+ u8 dlm;
+
+ if (lmacid > MAX_LMAC_PER_BGX)
+ return;
lmac = &bgx->lmac[lmacid];
- sprintf(str, "BGX%d QLM mode", bgx->bgx_id);
+ dlm = (lmacid / 2) + (bgx->bgx_id * 2);
+ if (!bgx->is_81xx)
+ sprintf(str, "BGX%d QLM mode", bgx->bgx_id);
+ else
+ sprintf(str, "BGX%d DLM%d mode", bgx->bgx_id, dlm);
switch (lmac->lmac_type) {
case BGX_MODE_SGMII:
@@ -857,26 +866,81 @@ static void lmac_set_lane2sds(struct lmac *lmac)
static void bgx_set_lmac_config(struct bgx *bgx, u8 idx)
{
struct lmac *lmac;
+ struct lmac *olmac;
u64 cmr_cfg;
+ u8 lmac_type;
+ u8 lane_to_sds;
lmac = &bgx->lmac[idx];
- lmac->lmacid = idx;
- /* Read LMAC0 type to figure out QLM mode
-* This is configured by low level firmware
+ if (!bgx->is_81xx) {
+ /* Read LMAC0 type to figure out QLM mode
+* This is configured by low level firmware
+*/
+ cmr_cfg = bgx_reg_read(bgx, 0, BGX_CMRX_CFG);
+ lmac->lmac_type = (cmr_cfg >> 8) & 0x07;
+ lmac->use_training =
+ bgx_reg_read(bgx, 0, BGX_SPUX_BR_PMD_CRTL) &
+ SPU_PMD_CRTL_TRAIN_EN;
+ lmac_set_lane2sds(lmac);
+ return;
+ }
+
+ /* On 81xx BGX can be split across 2 DLMs
+* firmware programs lmac_type of LMAC0 and LMAC2
*/
- cmr_cfg = bgx_reg_read(bgx, 0, BGX_CMRX_CFG);
- lmac->lmac_type = (cmr_cfg >> 8) & 0x07;
- lmac->use_training =
- bgx_reg_read(bgx, 0, BGX_SPUX_BR_PMD_CRTL) &
+ if ((idx == 0) || (idx == 2)) {
+ cmr_cfg = bgx_reg_read(bgx, idx, BGX_CMRX_CFG);
+ lmac_type = (u8)((cmr_cfg >> 8) & 0x07);
+ lane_to_sds = (u8)(cmr_cfg & 0xFF);
+ /* Check if config is not reset value */
+ if ((lmac_type == 0) && (lane_to_sds == 0xE4))
+ lmac->lmac_type = BGX_MODE_INVALID;
+ else
+ lmac->lmac_type = lmac_type;
+ lmac->use_training =
+ bgx_reg_read(bgx, idx, BGX_SPUX_BR_PMD_CRTL) &
+ SPU_PMD_CRTL_TRAIN_EN;
+ lmac_set_lane2sds(lmac);
+
+ /* Set LMAC type of other lmac on same DLM i.e LMAC 1/3 */
+ olmac = &bgx->lmac[idx + 1];
+ olmac->lmac_type = lmac->lmac_type;
+ olmac->use_training =
+ bgx_reg_read(bgx, idx + 1, BGX_SPUX_BR_PMD_CRTL) &
SPU_PMD_CRTL_TRAIN_EN;
- lmac_set_lane2sds(lmac);
+ lmac_set_lane2sds(olmac);
+ }
+}
+
+static bool is_dlm0_in_bgx_mode(struct bgx *bgx)
+{
+ struct lmac *lmac;
+
+ if (!bgx->is_81xx)
+ return true;
+
+ lmac = &bgx->lmac[1];
+ if (lmac->lmac_type == BGX_MODE_INVALID)
+ return false;
+
+ return true;
}
static void bgx_get_qlm_mode(struct bgx *bgx)
{
+ struct lmac *lmac;
+ struct lmac *lmac01;
+ struct lmac *lmac23;
u8 idx;
+ /* Init all LMAC's type to invalid */
+ for (idx = 0; idx < MAX_LMAC_PER_BGX; idx++) {
+ lmac = &bgx->lmac[idx];
+ lmac->lmac_type = BGX_MODE_INVALID;
+ lmac->lmacid = idx;
+ }
+
/* It is assumed that low level firmware sets this value */
bgx->lmac_count = bgx_reg_read(bgx, 0, BGX_CMR_RX_LMACS) & 0x7;
if (bgx->lmac_count > MAX_LMAC_PER_BGX)
@@ -884,7 +948,28 @@ static void bgx_get_qlm_mode(struct bgx *bgx)
for (idx = 0; idx < bgx->lmac_count; idx++)
bgx_set_lmac_config(bgx, idx);
- bgx_print_qlm_mode(bgx, 0);
+
+ if (!bgx->is_81xx) {
+ bgx_print_qlm_mode(bgx, 0)
[PATCH v2 05/15] net: thunderx: Enable CQE_RX desc's extension fields
From: Sunil Goutham
Unlike 88xx, CQE_RX descriptor's tunnelling extension i.e CQE_RX2_S
is always enabled on 81xx/83xx and HW does insert these fields into
CQE_RX. As a result receive buffer addresses will now be present at
7th word of CQE_RX instead of 6th.
Enable CQE_RX2_S on 88xx pass 2.x as well.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic.h | 9 -
drivers/net/ethernet/cavium/thunder/nic_main.c | 7 +++
drivers/net/ethernet/cavium/thunder/nic_reg.h | 1 +
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 12 +++-
4 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
b/drivers/net/ethernet/cavium/thunder/nic.h
index 6b0b240..136db2a 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -493,7 +493,14 @@ static inline int nic_get_node_id(struct pci_dev *pdev)
static inline bool pass1_silicon(struct pci_dev *pdev)
{
- return pdev->revision < 8;
+ return (pdev->revision < 8) &&
+ (pdev->subsystem_device == PCI_SUBSYS_DEVID_88XX_NIC_PF);
+}
+
+static inline bool pass2_silicon(struct pci_dev *pdev)
+{
+ return (pdev->revision >= 8) &&
+ (pdev->subsystem_device == PCI_SUBSYS_DEVID_88XX_NIC_PF);
}
int nicvf_set_real_num_queues(struct net_device *netdev,
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 0d81117..3f52b36 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -799,6 +799,13 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int vf)
(mbx.rq.qs_num << NIC_QS_ID_SHIFT) |
(mbx.rq.rq_num << NIC_Q_NUM_SHIFT);
nic_reg_write(nic, reg_addr, mbx.rq.cfg);
+ /* Enable CQE_RX2_S extension in CQE_RX descriptor.
+* This gets appended by default on 81xx/83xx chips,
+* for consistency enabling the same on 88xx pass2
+* where this is introduced.
+*/
+ if (pass2_silicon(nic->pdev))
+ nic_reg_write(nic, NIC_PF_RX_CFG, 0x01);
break;
case NIC_MBOX_MSG_RQ_BP_CFG:
reg_addr = NIC_PF_QSET_0_127_RQ_0_7_BP_CFG |
diff --git a/drivers/net/ethernet/cavium/thunder/nic_reg.h
b/drivers/net/ethernet/cavium/thunder/nic_reg.h
index 833cf3d..b4a7953 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_reg.h
+++ b/drivers/net/ethernet/cavium/thunder/nic_reg.h
@@ -36,6 +36,7 @@
#define NIC_PF_MAILBOX_ENA_W1C (0x0450)
#define NIC_PF_MAILBOX_ENA_W1S (0x0470)
#define NIC_PF_RX_ETYPE_0_7 (0x0500)
+#define NIC_PF_RX_CFG(0x05D0)
#define NIC_PF_PKIND_0_15_CFG(0x0600)
#define NIC_PF_ECC0_FLIP0(0x1000)
#define NIC_PF_ECC1_FLIP0(0x1008)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index e521a94..ca223aa 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -1190,7 +1190,17 @@ struct sk_buff *nicvf_get_rcv_skb(struct nicvf *nic,
struct cqe_rx_t *cqe_rx)
u64 *rb_ptrs = NULL;
rb_lens = (void *)cqe_rx + (3 * sizeof(u64));
- rb_ptrs = (void *)cqe_rx + (6 * sizeof(u64));
+ /* Except 88xx pass1 on all other chips CQE_RX2_S is added to
+* CQE_RX at word6, hence buffer pointers move by word
+*
+* Use existing 'hw_tso' flag which will be set for all chips
+* except 88xx pass1 instead of a additional cache line
+* access (or miss) by using pci dev's revision.
+*/
+ if (!nic->hw_tso)
+ rb_ptrs = (void *)cqe_rx + (6 * sizeof(u64));
+ else
+ rb_ptrs = (void *)cqe_rx + (7 * sizeof(u64));
netdev_dbg(nic->netdev, "%s rb_cnt %d rb0_ptr %llx rb0_sz %d\n",
__func__, cqe_rx->rb_cnt, cqe_rx->rb0_ptr, cqe_rx->rb0_sz);
--
2.7.4
[PATCH v2 06/15] net: thunderx: Enable mailbox interrupts on 81xx/83xx
From: Sunil Goutham
88xx has 128 VFs, 81xx has 8 VFs and 83xx will have 32VFs.
Made changes to PF driver such that mailbox interrupt enable
registers are configuired based on number of VFs HW supports.
Also cleanedup mailbox irq handler registration code.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 88 +++---
1 file changed, 50 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 3f52b36..955c522 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -66,8 +66,9 @@ struct nicpf {
/* MSI-X */
boolmsix_enabled;
u8 num_vec;
- struct msix_entry msix_entries[NIC_PF_MSIX_VECTORS];
+ struct msix_entry *msix_entries;
boolirq_allocated[NIC_PF_MSIX_VECTORS];
+ charirq_name[NIC_PF_MSIX_VECTORS][20];
};
/* Supported devices */
@@ -105,9 +106,22 @@ static u64 nic_reg_read(struct nicpf *nic, u64 offset)
/* PF -> VF mailbox communication APIs */
static void nic_enable_mbx_intr(struct nicpf *nic)
{
- /* Enable mailbox interrupt for all 128 VFs */
- nic_reg_write(nic, NIC_PF_MAILBOX_ENA_W1S, ~0ull);
- nic_reg_write(nic, NIC_PF_MAILBOX_ENA_W1S + sizeof(u64), ~0ull);
+ int vf_cnt = pci_sriov_get_totalvfs(nic->pdev);
+
+#define INTR_MASK(vfs) ((vfs < 64) ? (BIT_ULL(vfs) - 1) : (~0ull))
+
+ /* Clear it, to avoid spurious interrupts (if any) */
+ nic_reg_write(nic, NIC_PF_MAILBOX_INT, INTR_MASK(vf_cnt));
+
+ /* Enable mailbox interrupt for all VFs */
+ nic_reg_write(nic, NIC_PF_MAILBOX_ENA_W1S, INTR_MASK(vf_cnt));
+ /* One mailbox intr enable reg per 64 VFs */
+ if (vf_cnt > 64) {
+ nic_reg_write(nic, NIC_PF_MAILBOX_INT + sizeof(u64),
+ INTR_MASK(vf_cnt - 64));
+ nic_reg_write(nic, NIC_PF_MAILBOX_ENA_W1S + sizeof(u64),
+ INTR_MASK(vf_cnt - 64));
+ }
}
static void nic_clear_mbx_intr(struct nicpf *nic, int vf, int mbx_reg)
@@ -894,11 +908,18 @@ unlock:
nic->mbx_lock[vf] = false;
}
-static void nic_mbx_intr_handler (struct nicpf *nic, int mbx)
+static irqreturn_t nic_mbx_intr_handler(int irq, void *nic_irq)
{
+ struct nicpf *nic = (struct nicpf *)nic_irq;
+ int mbx;
u64 intr;
u8 vf, vf_per_mbx_reg = 64;
+ if (irq == nic->msix_entries[NIC_PF_INTR_ID_MBOX0].vector)
+ mbx = 0;
+ else
+ mbx = 1;
+
intr = nic_reg_read(nic, NIC_PF_MAILBOX_INT + (mbx << 3));
dev_dbg(&nic->pdev->dev, "PF interrupt Mbox%d 0x%llx\n", mbx, intr);
for (vf = 0; vf < vf_per_mbx_reg; vf++) {
@@ -910,23 +931,6 @@ static void nic_mbx_intr_handler (struct nicpf *nic, int
mbx)
nic_clear_mbx_intr(nic, vf, mbx);
}
}
-}
-
-static irqreturn_t nic_mbx0_intr_handler (int irq, void *nic_irq)
-{
- struct nicpf *nic = (struct nicpf *)nic_irq;
-
- nic_mbx_intr_handler(nic, 0);
-
- return IRQ_HANDLED;
-}
-
-static irqreturn_t nic_mbx1_intr_handler (int irq, void *nic_irq)
-{
- struct nicpf *nic = (struct nicpf *)nic_irq;
-
- nic_mbx_intr_handler(nic, 1);
-
return IRQ_HANDLED;
}
@@ -934,7 +938,13 @@ static int nic_enable_msix(struct nicpf *nic)
{
int i, ret;
- nic->num_vec = NIC_PF_MSIX_VECTORS;
+ nic->num_vec = pci_msix_vec_count(nic->pdev);
+
+ nic->msix_entries = kmalloc_array(nic->num_vec,
+ sizeof(struct msix_entry),
+ GFP_KERNEL);
+ if (!nic->msix_entries)
+ return -ENOMEM;
for (i = 0; i < nic->num_vec; i++)
nic->msix_entries[i].entry = i;
@@ -942,8 +952,9 @@ static int nic_enable_msix(struct nicpf *nic)
ret = pci_enable_msix(nic->pdev, nic->msix_entries, nic->num_vec);
if (ret) {
dev_err(&nic->pdev->dev,
- "Request for #%d msix vectors failed\n",
- nic->num_vec);
+ "Request for #%d msix vectors failed, returned %d\n",
+ nic->num_vec, ret);
+ kfree(nic->msix_entries);
return ret;
}
@@ -955,6 +966,7 @@ static void nic_disable_msix(struct nicpf *nic)
{
if (nic->msix_enabled) {
pci_disable_msix(nic->pdev);
+ kfree(nic->msix_entries);
nic->msix_enabled = 0;
nic->num_vec = 0;
}
@@ -973,27 +985,26 @@ static void nic_free_all_interrupts(struct nicpf *nic)
static int nic_register_interrupts(struct nicpf *nic)
{
- int ret;
+ int i, ret;
/* Enable MSI-X */
[PATCH v2 04/15] net: thunderx: Set queue count based on number of CPUs
From: Sunil Goutham
81xx has only 4 CPUs, so it doesn't make sense to initialize
entire Qset i.e 8 queues by default. Made changes to queue
initialization to init queues equal to number of CPUs or
8 queues whichever is lesser. Also this will be applicable to
VMs with VNIC VF attached and having less VCPUs
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 6 ++
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 7 +++
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 8
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 5 +
4 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 4974923..0d81117 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -1009,6 +1009,12 @@ static int nic_num_sqs_en(struct nicpf *nic, int vf_en)
int pos, sqs_per_vf = MAX_SQS_PER_VF_SINGLE_NODE;
u16 total_vf;
+ /* Secondary Qsets are needed only if CPU count is
+* morethan MAX_QUEUES_PER_QSET.
+*/
+ if (num_online_cpus() <= MAX_QUEUES_PER_QSET)
+ return 0;
+
/* Check if its a multi-node environment */
if (nr_node_ids > 1)
sqs_per_vf = MAX_SQS_PER_VF;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 0c10635..af04d9f 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1537,14 +1537,13 @@ static int nicvf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
goto err_release_regions;
}
- qcount = MAX_CMP_QUEUES_PER_QS;
+ qcount = min_t(int, MAX_CMP_QUEUES_PER_QS, num_online_cpus());
/* Restrict multiqset support only for host bound VFs */
if (pdev->is_virtfn) {
/* Set max number of queues per VF */
- qcount = roundup(num_online_cpus(), MAX_CMP_QUEUES_PER_QS);
- qcount = min(qcount,
-(MAX_SQS_PER_VF + 1) * MAX_CMP_QUEUES_PER_QS);
+ qcount = min_t(int, num_online_cpus(),
+ (MAX_SQS_PER_VF + 1) * MAX_CMP_QUEUES_PER_QS);
}
netdev = alloc_etherdev_mqs(sizeof(struct nicvf), qcount, qcount);
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 0ff8e60..e521a94 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -762,10 +762,10 @@ int nicvf_set_qset_resources(struct nicvf *nic)
nic->qs = qs;
/* Set count of each queue */
- qs->rbdr_cnt = RBDR_CNT;
- qs->rq_cnt = RCV_QUEUE_CNT;
- qs->sq_cnt = SND_QUEUE_CNT;
- qs->cq_cnt = CMP_QUEUE_CNT;
+ qs->rbdr_cnt = DEFAULT_RBDR_CNT;
+ qs->rq_cnt = min_t(u8, MAX_RCV_QUEUES_PER_QS, num_online_cpus());
+ qs->sq_cnt = min_t(u8, MAX_SND_QUEUES_PER_QS, num_online_cpus());
+ qs->cq_cnt = max_t(u8, qs->rq_cnt, qs->sq_cnt);
/* Set queue lengths */
qs->rbdr_len = RCV_BUF_COUNT;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index 6673e11..869f338 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -57,10 +57,7 @@
#define CMP_QUEUE_SIZE66ULL /* 64K entries */
/* Default queue count per QS, its lengths and threshold values */
-#define RBDR_CNT 1
-#define RCV_QUEUE_CNT 8
-#define SND_QUEUE_CNT 8
-#define CMP_QUEUE_CNT 8 /* Max of RCV and SND qcount */
+#define DEFAULT_RBDR_CNT 1
#define SND_QSIZE SND_QUEUE_SIZE2
#define SND_QUEUE_LEN (1ULL << (SND_QSIZE + 10))
--
2.7.4
Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported
On Wed, 2016-07-13 at 15:47 +1000, alast...@au1.ibm.com wrote: > From: Alastair D'Silva > > This series allows the vmx_crypto module to be detected and > automatically > loaded via UDEV if the CPU supports the vector crypto feature. > > Alastair D'Silva (2): > powerpc: Add module autoloading based on CPU features > crypto: vmx - Convert to CPU feature based module autoloading > > arch/powerpc/Kconfig | 1 + > arch/powerpc/include/asm/cpufeature.h | 70 > +++ > drivers/crypto/vmx/Kconfig| 2 +- > drivers/crypto/vmx/vmx.c | 6 +-- > 4 files changed, 74 insertions(+), 5 deletions(-) > create mode 100644 arch/powerpc/include/asm/cpufeature.h Please ignore the following: [PATCH 1/2] Allow drivers to be autoloaded. [PATCH 2/2] Automatically load the vmx_crypto module if supported. -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australia mob: 0423 762 819
[PATCH 0/2] Automatically load the vmx_crypto module if supported
From: Alastair D'Silva This series allows the vmx_crypto module to be detected and automatically loaded via UDEV if the CPU supports the vector crypto feature. Alastair D'Silva (2): powerpc: Add module autoloading based on CPU features crypto: vmx - Convert to CPU feature based module autoloading arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/cpufeature.h | 70 +++ drivers/crypto/vmx/Kconfig| 2 +- drivers/crypto/vmx/vmx.c | 6 +-- 4 files changed, 74 insertions(+), 5 deletions(-) create mode 100644 arch/powerpc/include/asm/cpufeature.h -- 2.7.4
[PATCH 2/2] Automatically load the vmx_crypto module if supported.
From: Alastair D'Silva
This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
to automatically load the vmx_crypto module if the CPU supports
it.
Signed-off-by: Alastair D'Silva
---
drivers/crypto/vmx/Kconfig | 2 +-
drivers/crypto/vmx/vmx.c | 6 ++
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/vmx/Kconfig b/drivers/crypto/vmx/Kconfig
index 89d8208..a83ead1 100644
--- a/drivers/crypto/vmx/Kconfig
+++ b/drivers/crypto/vmx/Kconfig
@@ -1,7 +1,7 @@
config CRYPTO_DEV_VMX_ENCRYPT
tristate "Encryption acceleration support on P8 CPU"
depends on CRYPTO_DEV_VMX
- default y
+ default m
help
Support for VMX cryptographic acceleration instructions on Power8 CPU.
This module supports acceleration for AES and GHASH in hardware. If
you
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index e163d57..5a40f2f 100644
--- a/drivers/crypto/vmx/vmx.c
+++ b/drivers/crypto/vmx/vmx.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,9 +44,6 @@ int __init p8_init(void)
int ret = 0;
struct crypto_alg **alg_it;
- if (!(cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_VEC_CRYPTO))
- return -ENODEV;
-
for (alg_it = algs; *alg_it; alg_it++) {
ret = crypto_register_alg(*alg_it);
printk(KERN_INFO "crypto_register_alg '%s' = %d\n",
@@ -78,7 +76,7 @@ void __exit p8_exit(void)
crypto_unregister_shash(&p8_ghash_alg);
}
-module_init(p8_init);
+module_cpu_feature_match(PPC_MODULE_FEATURE_VEC_CRYPTO, p8_init);
module_exit(p8_exit);
MODULE_AUTHOR("Marcelo Cerri");
--
2.7.4
Re: [PATCH 02/34] mm, vmscan: move lru_lock to the node
On Tue, Jul 12, 2016 at 12:18:05PM +0100, Mel Gorman wrote:
> On Tue, Jul 12, 2016 at 09:06:04PM +1000, Balbir Singh wrote:
> > > diff --git a/Documentation/cgroup-v1/memory.txt
> > > b/Documentation/cgroup-v1/memory.txt
> > > index b14abf217239..946e69103cdd 100644
> > > --- a/Documentation/cgroup-v1/memory.txt
> > > +++ b/Documentation/cgroup-v1/memory.txt
> > > @@ -267,11 +267,11 @@ When oom event notifier is registered, event will
> > > be delivered.
> > > Other lock order is following:
> > > PG_locked.
> > > mm->page_table_lock
> > > - zone->lru_lock
> > > + zone_lru_lock
> >
> > zone_lru_lock is a little confusing, can't we just call it
> > node_lru_lock?
> >
>
> It's a matter of perspective. People familiar with the VM already expect
> a zone lock so will be looking for it. I can do a rename if you insist
> but it may not actually help.
I don't want to insist, but zone_ in the name can be confusing, as to
leading us to think that the lru_lock is still in the zone
If the rest of the reviewers are fine with, we don't need to rename
>
> > > @@ -496,7 +496,6 @@ struct zone {
> > > /* Write-intensive fields used by page reclaim */
> > >
> > > /* Fields commonly accessed by the page reclaim scanner */
> > > - spinlock_t lru_lock;
> > > struct lruvec lruvec;
> > >
> > > /*
> > > @@ -690,6 +689,9 @@ typedef struct pglist_data {
> > > /* Number of pages migrated during the rate limiting time interval */
> > > unsigned long numabalancing_migrate_nr_pages;
> > > #endif
> > > + /* Write-intensive fields used by page reclaim */
> > > + ZONE_PADDING(_pad1_)a
> >
> > I thought this was to have zone->lock and zone->lru_lock in different
> > cachelines, do we still need the padding here?
> >
>
> The zone padding current keeps the page lock wait tables, page allocator
> lists, compaction and vmstats on separate cache lines. They're still
> fine.
>
> The node padding may not be necessary. It currently ensures that zonelists
> and numa balancing are separate from the LRU lock but there is no guarantee
> the current arrangement is optimal. It would depend on both the kernel
> config and the workload but it may be necessary in the future to split
> node into read-mostly sections and then different write-intensive sections
> similar to what has happened to struct zone in the past.
>
Fair enough
Balbir Singh.
[PATCH 2/2] crypto: vmx - Convert to CPU feature based module autoloading
From: Alastair D'Silva
This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
to automatically load the vmx_crypto module if the CPU supports
it.
Signed-off-by: Alastair D'Silva
---
drivers/crypto/vmx/Kconfig | 2 +-
drivers/crypto/vmx/vmx.c | 6 ++
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/vmx/Kconfig b/drivers/crypto/vmx/Kconfig
index 89d8208..a83ead1 100644
--- a/drivers/crypto/vmx/Kconfig
+++ b/drivers/crypto/vmx/Kconfig
@@ -1,7 +1,7 @@
config CRYPTO_DEV_VMX_ENCRYPT
tristate "Encryption acceleration support on P8 CPU"
depends on CRYPTO_DEV_VMX
- default y
+ default m
help
Support for VMX cryptographic acceleration instructions on Power8 CPU.
This module supports acceleration for AES and GHASH in hardware. If
you
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index e163d57..5a40f2f 100644
--- a/drivers/crypto/vmx/vmx.c
+++ b/drivers/crypto/vmx/vmx.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,9 +44,6 @@ int __init p8_init(void)
int ret = 0;
struct crypto_alg **alg_it;
- if (!(cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_VEC_CRYPTO))
- return -ENODEV;
-
for (alg_it = algs; *alg_it; alg_it++) {
ret = crypto_register_alg(*alg_it);
printk(KERN_INFO "crypto_register_alg '%s' = %d\n",
@@ -78,7 +76,7 @@ void __exit p8_exit(void)
crypto_unregister_shash(&p8_ghash_alg);
}
-module_init(p8_init);
+module_cpu_feature_match(PPC_MODULE_FEATURE_VEC_CRYPTO, p8_init);
module_exit(p8_exit);
MODULE_AUTHOR("Marcelo Cerri");
--
2.7.4
[PATCH 1/2] Allow drivers to be autoloaded.
From: Alastair D'Silva This patch provides the necessary infrastructure to allow drivers to be automatically loaded via UDEV. It implements the minimum required to be able to use module_cpu_feature_match to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed are a mirror of the cpu_user_features (converted to an offset from a mask). This decision was made to ensure that the behavior between features for module loading and userspace are consistent. Signed-off-by: Alastair D'Silva --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/cpufeature.h | 68 +++ 2 files changed, 69 insertions(+) create mode 100644 arch/powerpc/include/asm/cpufeature.h diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 0a9d439..a6e49db 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -164,6 +164,7 @@ config PPC select ARCH_HAS_UBSAN_SANITIZE_ALL select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS + select GENERIC_CPU_AUTOPROBE config GENERIC_CSUM def_bool CPU_LITTLE_ENDIAN diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h new file mode 100644 index 000..6d52527 --- /dev/null +++ b/arch/powerpc/include/asm/cpufeature.h @@ -0,0 +1,68 @@ +/* + * Copyright 2016 Alastair D'Silva, IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#ifndef __ASM_CPUFEATURE_H +#define __ASM_CPUFEATURE_H + +#include + +/* Keep these in step with powerpc/include/asm/cputable.h */ +#define MAX_CPU_FEATURES (2 * 32) + +#define PPC_MODULE_FEATURE_32 (ilog2(PPC_FEATURE_32)) +#define PPC_MODULE_FEATURE_64 (ilog2(PPC_FEATURE_64)) +#define PPC_MODULE_FEATURE_601_INSTR (ilog2(PPC_FEATURE_601_INSTR)) +#define PPC_MODULE_FEATURE_HAS_ALTIVEC (ilog2(PPC_FEATURE_HAS_ALTIVEC)) +#define PPC_MODULE_FEATURE_HAS_FPU (ilog2(PPC_FEATURE_HAS_FPU)) +#define PPC_MODULE_FEATURE_HAS_MMU (ilog2(PPC_FEATURE_HAS_MMU)) +#define PPC_MODULE_FEATURE_HAS_4xxMAC (ilog2(PPC_FEATURE_HAS_4xxMAC)) +#define PPC_MODULE_FEATURE_UNIFIED_CACHE ilog2(PPC_FEATURE_UNIFIED_CACHE)) +#define PPC_MODULE_FEATURE_HAS_SPE (ilog2(PPC_FEATURE_HAS_SPE)) +#define PPC_MODULE_FEATURE_HAS_EFP_SINGLE (ilog2(PPC_FEATURE_HAS_EFP_SINGLE)) +#define PPC_MODULE_FEATURE_HAS_EFP_DOUBLE (ilog2(PPC_FEATURE_HAS_EFP_DOUBLE)) +#define PPC_MODULE_FEATURE_NO_TB (ilog2(PPC_FEATURE_NO_TB)) +#define PPC_MODULE_FEATURE_POWER4 (ilog2(PPC_FEATURE_POWER4)) +#define PPC_MODULE_FEATURE_POWER5 (ilog2(PPC_FEATURE_POWER5)) +#define PPC_MODULE_FEATURE_POWER5_PLUS (ilog2(PPC_FEATURE_POWER5_PLUS)) +#define PPC_MODULE_FEATURE_CELL (ilog2(PPC_FEATURE_CELL)) +#define PPC_MODULE_FEATURE_BOOKE (ilog2(PPC_FEATURE_BOOKE)) +#define PPC_MODULE_FEATURE_SMT (ilog2(PPC_FEATURE_SMT)) +#define PPC_MODULE_FEATURE_ICACHE_SNOOP (ilog2(PPC_FEATURE_ICACHE_SNOOP)) +#define PPC_MODULE_FEATURE_ARCH_2_05 (ilog2(PPC_FEATURE_ARCH_2_05)) +#define PPC_MODULE_FEATURE_PA6T (ilog2(PPC_FEATURE_PA6T)) +#define PPC_MODULE_FEATURE_HAS_DFP (ilog2(PPC_FEATURE_HAS_DFP)) +#define PPC_MODULE_FEATURE_POWER6_EXT (ilog2(PPC_FEATURE_POWER6_EXT)) +#define PPC_MODULE_FEATURE_ARCH_2_06 (ilog2(PPC_FEATURE_ARCH_2_06)) +#define PPC_MODULE_FEATURE_HAS_VSX (ilog2(PPC_FEATURE_HAS_VSX)) +#define PPC_MODULE_FEATURE_PSERIES_PERFMON_COMPAT (ilog2(PPC_FEATURE_PSERIES_PERFMON_COMPAT)) +#define PPC_MODULE_FEATURE_TRUE_LE (ilog2(PPC_FEATURE_TRUE_LE)) +#define PPC_MODULE_FEATURE_PPC_LE (ilog2(PPC_FEATURE_PPC_LE)) + +#define PPC_MODULE_FEATURE_ARCH_2_07 (32 + ilog2(PPC_FEATURE2_ARCH_2_07)) +#define PPC_MODULE_FEATURE_HTM (32 + ilog2(PPC_FEATURE2_HTM)) +#define PPC_MODULE_FEATURE_DSCR(32 + ilog2(PPC_FEATURE2_DSCR)) +#define PPC_MODULE_FEATURE_EBB (32 + ilog2(PPC_FEATURE2_EBB)) +#define PPC_MODULE_FEATURE_ISEL(32 + ilog2(PPC_FEATURE2_ISEL)) +#define PPC_MODULE_FEATURE_TAR (32 + ilog2(PPC_FEATURE2_TAR)) +#define PPC_MODULE_FEATURE_VEC_CRYPTO (32 + ilog2(PPC_FEATURE2_VEC_CRYPTO)) +#define PPC_MODULE_FEATURE
[PATCH 1/2] powerpc: Add module autoloading based on CPU features
From: Alastair D'Silva This patch provides the necessary infrastructure to allow drivers to be automatically loaded via UDEV. It implements the minimum required to be able to use module_cpu_feature_match to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed are a mirror of the cpu_user_features (converted to an offset from a mask). This decision was made to ensure that the behavior between features for module loading and userspace are consistent. Signed-off-by: Alastair D'Silva --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/cpufeature.h | 70 +++ 2 files changed, 71 insertions(+) create mode 100644 arch/powerpc/include/asm/cpufeature.h diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 0a9d439..a6e49db 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -164,6 +164,7 @@ config PPC select ARCH_HAS_UBSAN_SANITIZE_ALL select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS + select GENERIC_CPU_AUTOPROBE config GENERIC_CSUM def_bool CPU_LITTLE_ENDIAN diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h new file mode 100644 index 000..df31627 --- /dev/null +++ b/arch/powerpc/include/asm/cpufeature.h @@ -0,0 +1,70 @@ +/* CPU feature definitions for module loading, used by + * module_cpu_feature_match(), see asm/cputable.h for powerpc CPU features + * + * Copyright 2016 Alastair D'Silva, IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#ifndef __ASM_CPUFEATURE_H +#define __ASM_POWERPC_CPUFEATURE_H + +#include + +/* Keep these in step with powerpc/include/asm/cputable.h */ +#define MAX_CPU_FEATURES (2 * 32) + +#define PPC_MODULE_FEATURE_32 (ilog2(PPC_FEATURE_32)) +#define PPC_MODULE_FEATURE_64 (ilog2(PPC_FEATURE_64)) +#define PPC_MODULE_FEATURE_601_INSTR (ilog2(PPC_FEATURE_601_INSTR)) +#define PPC_MODULE_FEATURE_HAS_ALTIVEC (ilog2(PPC_FEATURE_HAS_ALTIVEC)) +#define PPC_MODULE_FEATURE_HAS_FPU (ilog2(PPC_FEATURE_HAS_FPU)) +#define PPC_MODULE_FEATURE_HAS_MMU (ilog2(PPC_FEATURE_HAS_MMU)) +#define PPC_MODULE_FEATURE_HAS_4xxMAC (ilog2(PPC_FEATURE_HAS_4xxMAC)) +#define PPC_MODULE_FEATURE_UNIFIED_CACHE ilog2(PPC_FEATURE_UNIFIED_CACHE)) +#define PPC_MODULE_FEATURE_HAS_SPE (ilog2(PPC_FEATURE_HAS_SPE)) +#define PPC_MODULE_FEATURE_HAS_EFP_SINGLE (ilog2(PPC_FEATURE_HAS_EFP_SINGLE)) +#define PPC_MODULE_FEATURE_HAS_EFP_DOUBLE (ilog2(PPC_FEATURE_HAS_EFP_DOUBLE)) +#define PPC_MODULE_FEATURE_NO_TB (ilog2(PPC_FEATURE_NO_TB)) +#define PPC_MODULE_FEATURE_POWER4 (ilog2(PPC_FEATURE_POWER4)) +#define PPC_MODULE_FEATURE_POWER5 (ilog2(PPC_FEATURE_POWER5)) +#define PPC_MODULE_FEATURE_POWER5_PLUS (ilog2(PPC_FEATURE_POWER5_PLUS)) +#define PPC_MODULE_FEATURE_CELL (ilog2(PPC_FEATURE_CELL)) +#define PPC_MODULE_FEATURE_BOOKE (ilog2(PPC_FEATURE_BOOKE)) +#define PPC_MODULE_FEATURE_SMT (ilog2(PPC_FEATURE_SMT)) +#define PPC_MODULE_FEATURE_ICACHE_SNOOP (ilog2(PPC_FEATURE_ICACHE_SNOOP)) +#define PPC_MODULE_FEATURE_ARCH_2_05 (ilog2(PPC_FEATURE_ARCH_2_05)) +#define PPC_MODULE_FEATURE_PA6T (ilog2(PPC_FEATURE_PA6T)) +#define PPC_MODULE_FEATURE_HAS_DFP (ilog2(PPC_FEATURE_HAS_DFP)) +#define PPC_MODULE_FEATURE_POWER6_EXT (ilog2(PPC_FEATURE_POWER6_EXT)) +#define PPC_MODULE_FEATURE_ARCH_2_06 (ilog2(PPC_FEATURE_ARCH_2_06)) +#define PPC_MODULE_FEATURE_HAS_VSX (ilog2(PPC_FEATURE_HAS_VSX)) +#define PPC_MODULE_FEATURE_PSERIES_PERFMON_COMPAT (ilog2(PPC_FEATURE_PSERIES_PERFMON_COMPAT)) +#define PPC_MODULE_FEATURE_TRUE_LE (ilog2(PPC_FEATURE_TRUE_LE)) +#define PPC_MODULE_FEATURE_PPC_LE (ilog2(PPC_FEATURE_PPC_LE)) + +#define PPC_MODULE_FEATURE_ARCH_2_07 (32 + ilog2(PPC_FEATURE2_ARCH_2_07)) +#define PPC_MODULE_FEATURE_HTM (32 + ilog2(PPC_FEATURE2_HTM)) +#define PPC_MODULE_FEATURE_DSCR(32 + ilog2(PPC_FEATURE2_DSCR)) +#define PPC_MODULE_FEATURE_EBB (32 + ilog2(PPC_FEATURE2_EBB)) +#define PPC_MODULE_FEATURE_ISEL(32 + ilog2(PPC_FEATURE2_ISEL)) +#define PPC_MODULE_FEATURE_TAR (32 + ilog2(P
Re: Add MediaTek USB3 DRD Driver
Hi Felipe: Could you please give me some suggestions if you have already reviewed some codes. Thanks a lot. On Wed, 2016-06-15 at 11:07 +0800, Chunfeng Yun wrote: > From 48552e96e4e33f8830cb6a59154fe148425532fd Mon Sep 17 00:00:00 2001 > From: Chunfeng Yun > Date: Wed, 15 Jun 2016 10:58:10 +0800 > Subject: [PATCH v4,0/5] Add MediaTek USB3 DRD Driver > > These patches introduce the MediaTek USB3 dual-role controller > driver. > > The driver can be configured as Dual-Role Device (DRD), > Peripheral Only and Host Only (xHCI) modes. It works well > with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is > tested on MT8173 platform which only contains USB2.0 device IP, > and on MT6290 platform which contains USB3.0 device IP. > > Change in v4: > 1. fix build errors on non-mediatek platforms > 2. provide manual dual-role switch via debugfs instead of sysfs > > -- > 1.7.9.5 > >
Re: [Query] Preemption (hogging) of the work handler
Cc Petr Mladek.
On (07/12/16 16:19), Viresh Kumar wrote:
[..]
> Okay, we have tracked this BUG and its really interesting.
good find!
> I hacked the platform's serial driver to implement a putchar() routine
> that simply writes to the FIFO in polling mode, that helped us in
> tracing on where we are going wrong.
>
> The problem is that we are running asynchronous printks and we call
> wake_up_process() from the last running CPU which has disabled
> interrupts. That takes us to: try_to_wake_up().
>
> In our case the CPU gets deadlocked on this line in try_to_wake_up().
>
> raw_spin_lock_irqsave(&p->pi_lock, flags);
yeah, printk() can't handle these types of recursion. it can prevent
printk() calls issued from within the logbuf_lock spinlock section,
with some limitations:
if (unlikely(logbuf_cpu == smp_processor_id())) {
recursion_bug = true;
return;
}
raw_spin_lock(&logbuf_lock);
logbuf_cpu = this_cpu;
...
logbuf_cpu = UINT_MAX;
raw_spin_unlock(&logbuf_lock);
so should, for instance, raw_spin_unlock() generate spin_dump(), printk()
will blow up (both sync and async), because logbuf_cpu is already reset.
it may look that async printk added another source of recursion - wake_up().
but, apparently, this is not exactly correct. because there is already a
wake_up() call in console_unlock() - up().
printk()
if (logbuf_cpu == smp_processor_id())
return;
raw_spin_lock(&logbuf_lock);
logbuf_cpu = this_cpu;
...
logbuf_cpu = UINT_MAX;
raw_spin_unlock(&logbuf_lock);
console_trylock()
raw_spin_lock_irqsave(&sem->lock) << ***
raw_spin_unlock_irqsave(&sem->lock)<< ***
console_unlock()
up()
raw_spin_lock_irqsave(&sem->lock) << ***
__up()
wake_up_process()
try_to_wake_up() << *** in may places
*** a printk() call from here will kill the system. either it will
recurse printk(), or spin forever in 'nested' printk() on one of
the already taken spin locks.
I had an idea of waking up a printk_kthread under logbuf_lock,
so `logbuf_cpu == smp_processor_id()' test would help here. But
it turned out to introduce a regression in printk() behaviour.
apart from that, it didn't fix any of the existing recursion
printks.
there is printk_deferred() printk that is supposed to be used for
printing under scheduler locks, but it won't help in all of the cases.
printk() has many issues.
> I will explain how:
>
> The try_to_wake_up() function takes us through the scheduler code (RT
> sched), to the hrtimer code, where we eventually call ktime_get() (for
> the MONOTONIC clock used for hrtimer). And this function has this:
>
> WARN_ON(timekeeping_suspended);
>
> This starts another printk while we are in the middle of
> wake_up_process() and the CPU tries to take the above lock again and
> gets stuck there :)
>
> This doesn't happen everytime because we don't always call ktime_get()
> and it is called only if hrtimer_active() returns false.
>
> This happened because of a WARN_ON() but it can happen anyway. Think
> about this case:
>
> - offline all CPUs, except 0
> - call any routine that prints messages after disabling interrupts,
> etc.
> - If any of the function within wake_up_process() does a print, we are
> screwed.
>
> So the thing is that we can't really call wake_up_process() in cases
> where the last CPU disables interrupts. And that's why my fixup patch
> (which moved to synchronous prints after suspend) really works.
>
> @Jan and Sergey: I would expect a patch from you guys to fix this
> properly :)
>
> Maybe something more in can_print_async() routine, like:
>
> only-one-cpu-online + irqs_disabled()
>
right. adding only (num_online_cpus() > 1) check to can_printk_async()
*in theory* can break some cases. for example, SMP system, with only
one online CPU, active rt_sched throttling (not necessarily because of
printk kthread, any other task will do), and some of interrupts services
by CPU0 keep calling printk(), so deferred printk IRQ will stay busy:
echo 0 > /sys//cpu{1..NR_CPUS}/online # only CPU0 is active
CPU0
sched()
printk_deferred()
IRQ
wake_up_klogd_work_func()
console_trylock()
console_unlock()
IRQ
printk()
IRQ
printk()
IRQ
Re: [PATCH 1/2] HID: logitech-hidpp: add battery support for HID++ 2.0 devices
On Fri, Jul 08, 2016 at 04:35:45PM +0200, Bastien Nocera wrote:
> On Wed, 2016-06-29 at 19:28 +1000, Peter Hutterer wrote:
> > +static int hidpp_battery_get_property(struct power_supply *psy,
> > + enum power_supply_property psp,
> > + union power_supply_propval
> > *val)
> > +{
> > + struct hidpp_device *hidpp = power_supply_get_drvdata(psy);
> > + int ret = 0;
> > +
> > + switch(psp) {
> > + case POWER_SUPPLY_PROP_STATUS:
> > + val->intval = hidpp->battery.status;
> > + break;
> > + case POWER_SUPPLY_PROP_CAPACITY:
> > + val->intval = hidpp->battery.level;
> > + break;
> > + default:
>
> You forgot to handle POWER_SUPPLY_PROP_SCOPE. This means that UPower
> thinks it's supplying power to the computer to which it is connected.
>
> Should be set to "POWER_SUPPLY_SCOPE_DEVICE". This should fix it.
>
> From 8fbfcfd411a4b2c55ec24adc8b8ecc0bca2db5e3 Mon Sep 17 00:00:00 2001
> From: Bastien Nocera
> Date: Fri, 8 Jul 2016 16:34:18 +0200
> Subject: [PATCH] HID: logitech-hidpp: Add scope to battery
>
> Without a scope defined, UPower assumes that the battery is provide
> power to the computer it's connected to, like a laptop battery or a UPS.
>
> Signed-off-by: Bastien Nocera
Tested-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/hid/hid-logitech-hidpp.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 4eeb550..4aaf237 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -761,6 +761,7 @@ static int hidpp20_battery_event(struct hidpp_device
> *hidpp,
> static enum power_supply_property hidpp_battery_props[] = {
> POWER_SUPPLY_PROP_STATUS,
> POWER_SUPPLY_PROP_CAPACITY,
> + POWER_SUPPLY_PROP_SCOPE,
> };
>
> static int hidpp_battery_get_property(struct power_supply *psy,
> @@ -777,6 +778,9 @@ static int hidpp_battery_get_property(struct power_supply
> *psy,
> case POWER_SUPPLY_PROP_CAPACITY:
> val->intval = hidpp->battery.level;
> break;
> + case POWER_SUPPLY_PROP_SCOPE:
> + val->intval = POWER_SUPPLY_SCOPE_DEVICE;
> + break;
> default:
> ret = -EINVAL;
> break;
> --
> 2.7.4
>
[PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race
Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a
race:
sem_lock has a fast path that allows parallel simple operations.
There are two reasons why a simple operation cannot run in parallel:
- a non-simple operations is ongoing (sma->sem_perm.lock held)
- a complex operation is sleeping (sma->complex_count != 0)
As both facts are stored independently, a thread can bypass the current
checks by sleeping in the right positions. See below for more details
(or kernel bugzilla 105651).
The patch fixes that by creating one variable (complex_mode)
that tracks both reasons why parallel operations are not possible.
The patch also updates stale documentation regarding the locking.
With regards to stable kernels:
The patch is required for all kernels that include the
commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") (3.10?)
The alternative is to revert the patch that introduced the race.
The patch is safe for backporting, i.e. it makes no assumptions
about memory barriers in spin_unlock_wait() or that the acquire
within spin_lock() is after setting the lock variable.
Background:
Here is the race of the current implementation:
Thread A: (simple op)
- does the first "sma->complex_count == 0" test
Thread B: (complex op)
- does sem_lock(): This includes an array scan. But the scan can't
find Thread A, because Thread A does not own sem->lock yet.
- the thread does the operation, increases complex_count,
drops sem_lock, sleeps
Thread A:
- spin_lock(&sem->lock), spin_is_locked(sma->sem_perm.lock)
- sleeps before the complex_count test
Thread C: (complex op)
- does sem_lock (no array scan, complex_count==1)
- wakes up Thread B.
- decrements complex_count
Thread A:
- does the complex_count test
Bug:
Now both thread A and thread C operate on the same array, without
any synchronization.
Full memory barrier are required to synchronize changes of
complex_mode and the lock operations.
Fixes: 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()")
Reported-by: fel...@informatik.uni-bremen.de
Signed-off-by: Manfred Spraul
Cc:
---
include/linux/sem.h | 1 +
ipc/sem.c | 130 +++-
2 files changed, 79 insertions(+), 52 deletions(-)
diff --git a/include/linux/sem.h b/include/linux/sem.h
index 976ce3a..d0efd6e 100644
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@ -21,6 +21,7 @@ struct sem_array {
struct list_headlist_id;/* undo requests on this array
*/
int sem_nsems; /* no. of semaphores in array */
int complex_count; /* pending complex operations */
+ boolcomplex_mode; /* no parallel simple ops */
};
#ifdef CONFIG_SYSVIPC
diff --git a/ipc/sem.c b/ipc/sem.c
index ae72b3c..0da63c8 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -162,14 +162,21 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void
*it);
/*
* Locking:
+ * a) global sem_lock() for read/write
* sem_undo.id_next,
* sem_array.complex_count,
- * sem_array.pending{_alter,_cont},
- * sem_array.sem_undo: global sem_lock() for read/write
- * sem_undo.proc_next: only "current" is allowed to read/write that field.
+ * sem_array.complex_mode
+ * sem_array.pending{_alter,_const},
+ * sem_array.sem_undo
*
+ * b) global or semaphore sem_lock() for read/write:
* sem_array.sem_base[i].pending_{const,alter}:
- * global or semaphore sem_lock() for read/write
+ * sem_array.complex_mode (for read)
+ *
+ * c) special:
+ * sem_undo_list.list_proc:
+ * * undo_list->lock for write
+ * * rcu for read
*/
#define sc_semmsl sem_ctls[0]
@@ -260,28 +267,59 @@ static void sem_rcu_free(struct rcu_head *head)
}
/*
- * Wait until all currently ongoing simple ops have completed.
+ * Enter the mode suitable for non-simple operations:
* Caller must own sem_perm.lock.
- * New simple ops cannot start, because simple ops first check
- * that sem_perm.lock is free.
- * that a) sem_perm.lock is free and b) complex_count is 0.
*/
-static void sem_wait_array(struct sem_array *sma)
+static void complexmode_enter(struct sem_array *sma)
{
int i;
struct sem *sem;
- if (sma->complex_count) {
- /* The thread that increased sma->complex_count waited on
-* all sem->lock locks. Thus we don't need to wait again.
-*/
+ if (sma->complex_mode) {
+ /* We are already in complex_mode. Nothing to do */
return;
}
+ WRITE_ONCE(sma->complex_mode, true);
+
+ /* We need a full barrier:
+* The write to complex_mode must be visible
+* before we read the first sem->lock spinlock state.
+*/
+ smp_mb();
for (i = 0; i < sma->sem_nsems; i++) {
sem = sma->sem_base + i;
spin_unlock_wait(&sem->lock);
}
+ /*
+* spin_
[PATCH 2/2] ipc/sem.c: Remove duplicated memory barriers.
With 2c610022711 (locking/qspinlock: Fix spin_unlock_wait() some more),
memory barriers were added into spin_unlock_wait().
Thus another barrier is not required.
And as explained in 055ce0fd1b8 (locking/qspinlock: Add comments),
spin_lock() provides a barrier so that reads within the critical
section cannot happen before the write for the lock is visible.
i.e. spin_lock provides an acquire barrier after the write of the lock
variable, this barrier pairs with the smp_mb() in complexmode_enter().
Please review!
For x86, the patch is safe. But I don't know enough about all archs
that support SMP.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 0da63c8..d7b4212 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -291,14 +291,6 @@ static void complexmode_enter(struct sem_array *sma)
sem = sma->sem_base + i;
spin_unlock_wait(&sem->lock);
}
- /*
-* spin_unlock_wait() is not a memory barriers, it is only a
-* control barrier. The code must pair with spin_unlock(&sem->lock),
-* thus just the control barrier is insufficient.
-*
-* smp_rmb() is sufficient, as writes cannot pass the control barrier.
-*/
- smp_rmb();
}
/*
@@ -363,12 +355,6 @@ static inline int sem_lock(struct sem_array *sma, struct
sembuf *sops,
*/
spin_lock(&sem->lock);
- /*
-* A full barrier is required: the write of sem->lock
-* must be visible before the read is executed
-*/
- smp_mb();
-
if (!smp_load_acquire(&sma->complex_mode)) {
/* fast path successful! */
return sops->sem_num;
--
2.5.5
[PATCH 0/2] ipc/sem.c: sem_lock fixes
Hi Andrew, Hi Peter, next version of the sem_lock() fixes: The patches are again vs. tip. Patch 1 is ready for merging, Patch 2 is for review. - Patch 1 is the patch as in -next since January It fixes the race that was found by Felix. - Patch 2 removes the memory barriers that are part of the qspinlock code. - (The hysteresis patch would be patch 3. The risk of regressions can't be ruled out, thus it must wait for benchmarks from real workload tests) Patch 1+2 were one patch, I've split patches so that review and backporting are simpler. -- Manfred
Re: [RFC 0/3] extend kexec_file_load system call
Russell King - ARM Linux writes: > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> I'm not an expert on DTB, so I can't provide an example of code >> execution, but you have already mentioned the /chosen/linux,stdout-path >> property. If an attacker redirects the bootloader to an insecure >> console, they may get access to the system that would otherwise be >> impossible. > > I fail to see how kexec connects with the boot loader - the DTB image > that's being talked about is one which is passed from the currently > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect > also ARM64) that's a direct call chain which doesn't involve any > boot loader or firmware, and certainly none that would involve the > passed DTB image. For OpenPOWER machines, kexec is the bootloader. Our bootloader is a linux kernel and initramfs with a UI (petitboot) - this means we never have to write a device driver twice: write a kernel one and you're done (for booting from the device and using it in your OS). -- Stewart Smith OPAL Architect, IBM.
Loan Offer
Instant cash Loan with same day payout on all kinds of Loan are available at Quick Financial Home were loan is offered at 2% per annul. Email: quickloa...@foxmail.com
Re: [PATCH v3] Input: synaptics-rmi4: Support regulator supplies
On Fri, Jun 24, 2016 at 5:40 PM, Andrew Duggan wrote:
> On 06/10/2016 10:25 PM, Bjorn Andersson wrote:
>>
>> From: Bjorn Andersson
>>
>> Support the two supplies - vdd and vio - to make it possible to control
>> power to the Synaptics chip.
>>
>> Signed-off-by: Bjorn Andersson
>> Signed-off-by: Bjorn Andersson
>
>
> Reviewed-by: Andrew Duggan
Dmitry, do you have any comments or would you mind pick this up?
Regards,
Bjorn
>
>
>> ---
>> .../devicetree/bindings/input/rmi4/rmi_i2c.txt | 9 +
>> drivers/input/rmi4/rmi_i2c.c | 41
>> ++
>> 2 files changed, 50 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
>> b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
>> index 95fa715c6046..ec908b91fd90 100644
>> --- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
>> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
>> @@ -22,6 +22,15 @@ See
>> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>> - syna,reset-delay-ms: The number of milliseconds to wait after
>> resetting the
>> device.
>> +- syna,startup-delay-ms: The number of milliseconds to wait after
>> powering on
>> +the device.
>> +
>> +- vdd-supply: VDD power supply.
>> +See ../regulator/regulator.txt
>> +
>> +- vio-supply: VIO power supply
>> +See ../regulator/regulator.txt
>> +
>> Function Parameters:
>> Parameters specific to RMI functions are contained in child nodes of the
>> rmi device
>>node. Documentation for the parameters of each function can be found
>> in:
>> diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
>> index a96a326b53bd..71dc6cdde8ac 100644
>> --- a/drivers/input/rmi4/rmi_i2c.c
>> +++ b/drivers/input/rmi4/rmi_i2c.c
>> @@ -11,6 +11,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include "rmi_driver.h"
>> #define BUFFER_SIZE_INCREMENT 32
>> @@ -37,6 +39,9 @@ struct rmi_i2c_xport {
>> u8 *tx_buf;
>> size_t tx_buf_size;
>> +
>> + struct regulator_bulk_data supplies[2];
>> + u32 startup_delay;
>> };
>> #define RMI_PAGE_SELECT_REGISTER 0xff
>> @@ -246,6 +251,24 @@ static int rmi_i2c_probe(struct i2c_client *client,
>> return -ENODEV;
>> }
>> + rmi_i2c->supplies[0].supply = "vdd";
>> + rmi_i2c->supplies[1].supply = "vio";
>> + retval = devm_regulator_bulk_get(&client->dev,
>> +ARRAY_SIZE(rmi_i2c->supplies),
>> +rmi_i2c->supplies);
>> + if (retval < 0)
>> + return retval;
>> +
>> + retval = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
>> + rmi_i2c->supplies);
>> + if (retval < 0)
>> + return retval;
>> +
>> + of_property_read_u32(client->dev.of_node, "syna,startup-delay-ms",
>> +&rmi_i2c->startup_delay);
>> +
>> + msleep(rmi_i2c->startup_delay);
>> +
>> rmi_i2c->client = client;
>> mutex_init(&rmi_i2c->page_mutex);
>> @@ -286,6 +309,7 @@ static int rmi_i2c_remove(struct i2c_client *client)
>> struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
>> rmi_unregister_transport_device(&rmi_i2c->xport);
>> + regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies),
>> rmi_i2c->supplies);
>> return 0;
>> }
>> @@ -308,6 +332,9 @@ static int rmi_i2c_suspend(struct device *dev)
>> dev_warn(dev, "Failed to enable irq for wake:
>> %d\n",
>> ret);
>> }
>> +
>> + regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies),
>> rmi_i2c->supplies);
>> +
>> return ret;
>> }
>> @@ -317,6 +344,12 @@ static int rmi_i2c_resume(struct device *dev)
>> struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
>> int ret;
>> + ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
>> rmi_i2c->supplies);
>> + if (ret)
>> + return ret;
>> +
>> + msleep(rmi_i2c->startup_delay);
>> +
>> enable_irq(rmi_i2c->irq);
>> if (device_may_wakeup(&client->dev)) {
>> ret = disable_irq_wake(rmi_i2c->irq);
>> @@ -346,6 +379,8 @@ static int rmi_i2c_runtime_suspend(struct device *dev)
>> disable_irq(rmi_i2c->irq);
>> + regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies),
>> rmi_i2c->supplies);
>> +
>> return 0;
>> }
>> @@ -355,6 +390,12 @@ static int rmi_i2c_runtime_resume(struct device
>> *dev)
>> struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
>> int ret;
>> + ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
>> rmi_i2c->supplies);
>> + if (ret)
>> + return ret;
>> +
>> + msleep(rmi_i2c->startup_delay);
>> +
>> enable_irq(r
xen: migration: guest kernel gets stuck because of too-early-swappness
Hi all: We found that guests such as RHEL6, they occasionally got stuck after migration. The stack of the stuck guest kernel is as follows: PID: 18 TASK: 88007de61500 CPU: 1 COMMAND: "xenwatch" #0 [88007de62e40] schedule at 8150d692 #1 [88007de62f08] io_schedule at 8150de73 #2 [88007de62f28] get_request_wait at 8125e4c8 #3 [88007de62fb8] blk_queue_bio at 8125e60d #4 [88007de63038] generic_make_request at 8125ccce #5 [88007de63108] submit_bio at 8125d02d #6 [88007de63158] swap_writepage at 81154374 #7 [88007de63188] pageout.clone.2 at 8113205b #8 [88007de63238] shrink_page_list.clone.3 at 811326e5 #9 [88007de63388] shrink_inactive_list at 81133263 #10 [88007de63538] shrink_mem_cgroup_zone at 81133afe #11 [88007de63608] shrink_zone at 81133dc3 #12 [88007de63678] do_try_to_free_pages at 81133f25 #13 [88007de63718] try_to_free_pages at 811345f2 #14 [88007de637b8] __alloc_pages_nodemask at 8112be48 #15 [88007de638f8] kmem_getpages at 811669d2 #16 [88007de63928] fallback_alloc at 811675ea #17 [88007de639a8] cache_alloc_node at 81167369 #18 [88007de63a08] kmem_cache_alloc at 811682eb #19 [88007de63a48] idr_pre_get at 812786c0 #20 [88007de63a78] ida_pre_get at 8127870c #21 [88007de63a98] proc_register at 811efc71 #22 [88007de63ae8] proc_mkdir_mode at 811f0082 #23 [88007de63b18] proc_mkdir at 811f00b6 #24 [88007de63b28] register_handler_proc at 810e54fb #25 [88007de63bf8] __setup_irq at 810e2594 #26 [88007de63c48] request_threaded_irq at 810e2e43 #27 [88007de63ca8] serial8250_startup at 81356fac #28 [88007de63cf8] uart_resume_port at 813547be #29 [88007de63d78] serial8250_resume_port at 813567b6 #30 [88007de63d98] serial_pnp_resume at 81358a58 #31 [88007de63da8] pnp_bus_resume at 81311853 #32 [88007de63dc8] dpm_resume_end at 813648a8 #33 [88007de63e28] shutdown_handler at 81319351 #34 [88007de63e68] xenwatch_thread at 8131ab1a #35 [88007de63ee8] kthread at 81096916 #36 [88007de63f48] kernel_thread at 8100c0ca The reason we guess is that: 1 Guests with kernel of 3.*, such as RHEL6, when they are not configured with CONFIG_PREEMPT , they do NOT call FREEZE/THAW before resuming disks, thus, kernel threads maybe active before the disks are available. We know that kernel threads may require/allocate memories, which may occasionally cause swappness. Swappness before disks get ready may cause kernel stuck. this problem is fixed at: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.16.y&id=2edbf3c6af0f5f1f9d2ef00a15339c10beaff405 2 However, even the kernel thread xenwatch itself needs to allocate memories, any attempt to acquire memory before the disk is resumed may cause deadlock shown above. So, how to fix the kernel stuck problem caused by too-early-swappness? Thanks in advance. ZhangBo(Oscar)
Re: [PATCH v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation
Dear Rob, On 2016/7/11 23:13, Rob Herring wrote: On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote: This patch adds the devicetree documentation required for Rockchip USB3.0 core wrapper consisting of USB3.0 IP from Synopsys. It supports DRD mode, and could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). Signed-off-by: William Wu --- Changes in v6: - rename bus_clk, and add usbdrd3_1 node as an example (Heiko) Changes in v5: - rename clock-names, and remove unnecessary clocks (Heiko) Changes in v4: - modify commit log, and add phy documentation location (Sergei) Changes in v3: - add dwc3 address (balbi) Changes in v2: - add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (balbi, Brian) .../devicetree/bindings/usb/rockchip,dwc3.txt | 59 ++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt Acked-by: Rob Herring Thanks a lot. I'll add Acked-by next patch.
Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk
Dear Rob, On 2016/7/11 22:58, Rob Herring wrote: On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote: Add a quirk to configure the core to support the UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY interface is hardware property, and it's platform dependent. Normall, the PHYIf can be configured s/Normall/Normally/ Yeah，I'll fix it.:-) s/PHYIf/PHYIF/ Refer to DWC3 controller databook, "PHY Interface" called "PHYIf", so I describe "PHYIf" here. However， "PHYIF”seems more the norm, I'll fix it.:-) during coreconsultant. But for some specific usb s/usb/USB/ Thanks, I'll fix it.:-) cores(e.g. rk3399 soc dwc3), the default PHYIf configuration value is fault, so we need to reconfigure it by software. And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM s/dwc3/DWC3/ Thanks, I'll fix it too. must be set to the corresponding value according to the UTMI+ PHY interface. And wrap your lines at 70-74 characters. Thanks for your suggestion, I'll pay attention to this problem next patch.:-) Best Regards， William Wu Rob
[PATCH] [linux-next] input: Fix a double word "is is" in include/linux/input.h
This patch fix a double word "is is" found in in
Documentation/DocBook/device-drivers.xml.
It is because the file was created from comments in sources,
so I have to fix the double words in include/linux/input.h
Signed-off-by: Masanari Iida
---
include/linux/input.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index 1e967694e9a5..a65e3b24fb18 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -95,7 +95,7 @@ struct input_value {
* @grab: input handle that currently has the device grabbed (via
* EVIOCGRAB ioctl). When a handle grabs a device it becomes sole
* recipient for all input events coming from the device
- * @event_lock: this spinlock is is taken when input core receives
+ * @event_lock: this spinlock is taken when input core receives
* and processes a new event for the device (in input_event()).
* Code that accesses and/or modifies parameters of a device
* (such as keymap or absmin, absmax, absfuzz, etc.) after device
--
2.9.1.200.gb1ec08f
Re: [CRIU] Introspecting userns relationships to other namespaces?
On Tue, Jul 12, 2016 at 05:08:43PM -0700, Andrew Vagin wrote: > Here is a patch to get an owning user namespace: > https://github.com/avagin/linux-task-diag/commit/7fad8ff3fc4110bebf0920cec2388390b3bd2238 > https://github.com/avagin/linux-task-diag/commit/2663bc803d324785e328261f3c07a0fef37d2088 > > Here is an example how it looks from user-space: > https://github.com/avagin/linux-task-diag/blob/namespaces/tools/testing/selftests/nsfs/owner.c#L49 Overall this looks good to me (I left a handful of uninformed comments inline ;). It doesn't make it easy to walk leafward, but it doesn't look like the kernel has a convenient way to list child namespaces either. Something like /proc//task//children (with CONFIG_PROC_CHILDREN) for namespaces would make it easier to get a complete system overview (as far as your credentials and position in the namespace hierarchies allow). But looking at the CONFIG_PROC_CHILDREN implementation doesn't make me all that excited about mimicking it for namespaces ;). You can still brute-force it in userspace by walking the root-most procfs's you can find and peeking at all the /proc//ns/… entries (but yuck ;). With mount and other namespaces not being hierarchical, the “leafword” idea may not be all that useful anyway, but having a more compact collection of mount namepaces (say) that you know about would be nice. Where “know about” should probably means “know it exists” but not necessarily “have permission to enter”. Still, getting that figured out can happen independently to this parent/owner work. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [CRIU] Introspecting userns relationships to other namespaces?
On Sat, Jul 09, 2016 at 01:29:20PM -0500, Eric W. Biederman wrote: > ebied...@xmission.com (Eric W. Biederman) writes: > > > Andrew Vagin writes: > > > >> All these thoughts about security make me thinking that kcmp is what we > >> should use here. It's maybe something like this: > >> > >> kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2) > >> > >> - to check if userns of the fd1 namepsace is equal to the fd2 userns > >> > >> kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2) > >> > >> - to check if a parent namespace of the fd1 pidns is equal to fd pidns. > >> > >> fd1 and fd2 is file descriptors to namespace files. > >> > >> So if we want to build a hierarchy, we need to collect all namespaces > >> and then enumerate them to check dependencies with help of kcmp. > > > > That is certainly one way to go. > > > > There is a funny case where we would want to compare a user namespace > > file descriptor to a parent user namespace file descriptor. > > > > > > Grumble, Grumble. I think this may actually a case for creating ioctls > > for these two cases. Now that random nsfs file descriptors are bind > > mountable the original reason for using proc files is not as pressing. > > > > One ioctl for the user namespace that owns a file descriptor. > > One ioctl for the parent namespace of a namespace file descriptor. > > > > We also need some way to get a command file descriptor for a file system > > super block. Al Viro has a pet project for cleaning up the mount API > > and this might be the idea excuse to start looking at that. > > > > (In principle we might be able to run commands through the namespace > > file descriptor and using an ioctl feels dirty. But an ioctl that > > only uses the fd and request argument does not suffer from the same > > problems that ioctls that have to pass additional arguments suffer > > from.) > > Of course it should be an error perhaps -EINVAL to get a user > namespace owner or parent namespace that is outside of a processes > current user namespace or pid namespace. That way thing stay bounded > within the current namespaces the process is in. Which prevents any > leak possibilities, and keeps CRIU working. I prepared patches with ioctl-s to understand how it looks like. Here is a whole series: https://github.com/avagin/linux-task-diag/commits/namespaces Here is a patch to get an owning user namespace: https://github.com/avagin/linux-task-diag/commit/7fad8ff3fc4110bebf0920cec2388390b3bd2238 https://github.com/avagin/linux-task-diag/commit/2663bc803d324785e328261f3c07a0fef37d2088 Here is an example how it looks from user-space: https://github.com/avagin/linux-task-diag/blob/namespaces/tools/testing/selftests/nsfs/owner.c#L49 I like the idea with ioctl-s. James, Michael, Trevor, what is your opinion about this? > > Eric
Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk
Dear Rob, On 2016/7/11 22:54, Rob Herring wrote: On Fri, Jul 08, 2016 at 02:33:09PM +0200, Heiko Stuebner wrote: Hi William, Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu: Add a quirk to configure the core to support the UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY interface is hardware property, and it's platform dependent. Normall, the PHYIf can be configured during coreconsultant. But for some specific usb cores(e.g. rk3399 soc dwc3), the default PHYIf configuration value is fault, so we need to reconfigure it by software. And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM must be set to the corresponding value according to the UTMI+ PHY interface. Signed-off-by: William Wu --- [...] diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 020b0e9..8d7317d 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -42,6 +42,10 @@ Optional properties: - snps,dis-u2-freeclk-exists-quirk: when set, clear the u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't provide a free-running PHY clock. + - snps,phyif-utmi-quirk: when set core will set phyif UTMI+ interface. + - snps,phyif-utmi: the value to configure the core to support a UTMI+ PHY + with an 8- or 16-bit interface. Value 0 select 8-bit + interface, value 1 select 16-bit interface. maybe snps,phyif-utmi-width = <8> or <16>; Seems like this could be common. Any other bindings have something similar already? If not "utmi-width" is fine. It seems that there's not any dwc3 binding similar to this. So I prefer to use “utmi-width”. :-) devicetree is about describing the hardware, not the things that get written to registers :-) . The conversion from the described width to the register value can easily be done in the driver. Also I don't think you need two properties for this. If the snps,phyif-utmi property is specified it indicates that you want to manually set the width and if it is absent you want to use the IC default. All functions reading property-values indicate if the property is missing. Agreed. Rob
[RESEND PATCH] soc: mediatek: PMIC wrap: Extend the waiting time to 10ms.
Read data fails sometimes because of a timeout that PMIC cannot transfer data
to PMIC wrap on time, extend the waiting time to 10ms to reduce the failed
rate.
Signed-off-by: Henry Chen
---
Resend to fixed the typo on commit message
---
drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index a003ba2..a5f1093 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -583,7 +583,7 @@ static int pwrap_wait_for_state(struct pmic_wrapper *wrp,
{
unsigned long timeout;
- timeout = jiffies + usecs_to_jiffies(255);
+ timeout = jiffies + usecs_to_jiffies(1);
do {
if (time_after(jiffies, timeout))
--
1.8.1.1.dirty
Re: [PATCH v3 2/4] drm/rockchip: add an common abstracted PSR driver
Daniel,
On 07/12/2016 08:38 PM, Daniel Vetter wrote:
On Fri, Jul 01, 2016 at 02:00:00PM -0400, Sean Paul wrote:
On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang wrote:
The PSR driver have exported four symbols for specific device driver:
- rockchip_drm_psr_register()
- rockchip_drm_psr_unregister()
- rockchip_drm_psr_enable()
- rockchip_drm_psr_disable()
- rockchip_drm_psr_flush()
Encoder driver should call the register/unregister interfaces to hook
itself into common PSR driver, encoder have implement the 'psr_set'
callback which use the set PSR state in hardware side.
Crtc driver would call the enable/disable interfaces when vblank is
enable/disable, after that the common PSR driver would call the encoder
registered callback to set the PSR state.
This feels overly complicated. It seems like you could cut out a bunch
of code by just coding the psr functions into vop and
analogix_dp-rockchip. I suppose the only reason to keep it abstracted
would be if you plan on supporting psr in a different encoder or crtc
in rockchip, or if you're planning on moving this into drm core.
Agreed on the layers of indirection. Also, you end up with 3 delayed
timers in total:
- defio timer from fbdev emulation
- timer in this abstraction
- delayed work in the psr backend driver
I'd cut out at least the middle one.
But since this seems to correctly use the ->dirty callback it gets my Ack
either way ;-)
Aha, thanks :-D
- Yakir
Cheers, Daniel
Perhaps others will disagree with this sentiment and this is the right
thing to do.
Fb driver would call the flush interface in 'fb->dirty' callback, this
helper function would force all PSR enabled encoders to exit from PSR
for 3 seconds.
Signed-off-by: Yakir Yang
---
Changes in v3:
- split the psr flow into an common abstracted PSR driver
- implement the 'fb->dirty' callback function (Daniel)
- avoid to use notify to acqiure for vact event (Daniel)
- remove psr_active() callback which introduce in v2
Changes in v2: None
drivers/gpu/drm/rockchip/Makefile | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 12 ++
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 200
drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 12 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24
5 files changed, 249 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..9746365 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,7 +3,7 @@
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
- rockchip_drm_gem.o rockchip_drm_vop.o
+ rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 20f12bc..0fec18f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -21,6 +21,7 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
+#include "rockchip_drm_psr.h"
#define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
@@ -66,9 +67,20 @@ static int rockchip_drm_fb_create_handle(struct
drm_framebuffer *fb,
rockchip_fb->obj[0], handle);
}
+static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+ rockchip_drm_psr_flush();
+ return 0;
+}
+
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.destroy= rockchip_drm_fb_destroy,
.create_handle = rockchip_drm_fb_create_handle,
+ .dirty = rockchip_drm_fb_dirty,
};
static struct rockchip_drm_fb *
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
new file mode 100644
index 000..c03
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -0,0 +1,200 @@
+#include
+
+#include "rockchip_drm_psr.h"
+
+#define PSR_FLUSH_TIMEOUT msecs_to_jiffies(3000) /* 3 seconds */
+
+static LIST_HEAD(psr_list);
+static DEFINE_MUTEX(psr_list_mutex);
I'm not crazy about these globals. Perhaps you can initialize them
with the rockchip driver and tuck them in a driver-level struct
(rockchip_drm_private or something).
+
+enum psr_state {
+ PSR_FLUSH,
+ PSR_ENABLE,
+ PSR_DISABLE,
+};
+
+struct psr_drv {
+ str
Re: [PATCH] [RFC V1]s390/perf: fix 'start' address of module's map
I send this email to test the connection to linux-kernel maillist. Just
ignore.
在 7/11/2016 4:11 PM, Songshan Gong 写道:
在 7/8/2016 11:18 PM, Jiri Olsa 写道:
On Thu, Jul 07, 2016 at 09:49:36AM +0800, Song Shan Gong wrote:
At preset, when creating module's map, perf gets 'start' address by
parsing
'proc/modules', but it's module base address, isn't the start address of
'.text' section. In most archs, it's OK. But for s390, it places
'GOT' and
'PLT' relocations before '.text' section. So there exists an offset
between
module base address and '.text' section, which will incur wrong symbol
resolution for modules.
Fix this bug by getting 'start' address of module's map from parsing
'/sys/module/[module name]/sections/.text', not from '/proc/modules'.
cool, does this fix the 'perf test 1' for s390? that'd be great
I've checked, 'perf test 1' is still failed. But the test is for testing
whether 'vmlinux symtab matches kallsyms'. For vmlinux, it's built when
compiling linux-kernel, so there's no any symbol info about module. For
kallsyms, when loading, it also splits kernel symbols with module
symbols. But this patch is intended to fix wrong symbol resolution for
modules, so I think there's no relationship between this patch and the
testcase 'perf test 1'.
I also debuged the reason why 'perf test 1' fails, there are two reasons
at least:
1. perf gets kernel start address by finding the first no-zero value of
symbols {'_text', '_stext'} in /proc/kallsyms; for s390, it's always
'_stext', but actually, '_stext' is not the first symbol in s390, there
are other symbols before '_stext', for example 'iplstart'.
2. In addition, when loading by parsing /proc/kallsyms, if the kernel
map start value is a non-zero value getting from '_stext', because
'_text' is zero, it will not be included in kernel map; but for vmlinux,
it always add '_text' to kernel map whether '_text' is zero or not. So
if '_text' is zero, whether adding '_text' to kernel map, it's
non-consistent for loading by /proc/kallsyms and vmlinux.
I'll try to fix this bug later.
Thanks for your comments.
I'll send few coments shortly
thanks,
jirka
--
SongShan Gong
Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk
Dear Heiko,
On 2016/7/10 7:47, Heiko Stuebner wrote:
Am Samstag, 9. Juli 2016, 11:38:00 schrieb William.wu:
Dear Heiko & Balbi，
On 2016/7/8 21:29, Felipe Balbi wrote:
Hi,
Heiko Stuebner writes:
Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:
Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can be configured
during coreconsultant. But for some specific usb
cores(e.g. rk3399 soc dwc3), the default PHYIf
configuration value is fault, so we need to
reconfigure it by software.
And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
must be set to the corresponding value according to
the UTMI+ PHY interface.
Signed-off-by: William Wu
---
[...]
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt index
020b0e9..8d7317d
100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -42,6 +42,10 @@ Optional properties:
- snps,dis-u2-freeclk-exists-quirk: when set, clear the
u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't
provide
a free-running PHY clock.
+ - snps,phyif-utmi-quirk: when set core will set phyif UTMI+
interface.
+ - snps,phyif-utmi: the value to configure the core to support a
UTMI+
PHY + with an 8- or 16-bit interface. Value 0
select 8-bit
+ interface, value 1 select 16-bit interface.
maybe
snps,phyif-utmi-width = <8> or <16>;
devicetree is about describing the hardware, not the things that get
written to registers :-) . The conversion from the described width to
the register value can easily be done in the driver.
Thanks for your suggestion:-)
Yes， “snps,phyif-utmi-width = <8> or <16>” is much clearer and easier to
understand.
And I have considered the same dts property for phyif-utmi, but I have
no good idea about
the conversion from described width to the registers value for the time
being.
About phyif utmi width configuration， we need to set two places in
GUSB2PHYCFG register，
according to DWC3 USB3.0 controller databook version3.00a，6.3.46
GUSB2PHYCFG
--
Bits | Name | Description
--
13:10 | USBTRDTIM | Sets the turnaround
time in PHY clocks.
|| 4'h5: When the MAC
interface is 16-bit UTMI+
|| 4'h9: When the MAC
interface is 8-bit UTMI+/ULPI.
--
3| PHYIF|If UTMI+ is
selected, the application uses this bit to configure
||core to support a UTMI+
PHY with an 8- or 16-bit interface.
||1'b0: 8 bits
||1'b1: 16 bits
--
And I think maybe I can try to do this:
change it in dts:
snps,phyif-utmi-width = <8> or <16>;
Then convert to register value like this：
device_property_read_u8(dev, "snps,phyif-utmi-width",
&phyif_utmi_width);
dwc->phyif_utmi = phyif_utmi_width >> 4;
Ater the conversion， dwc->phyif_utmi value 0 means 8 bits, value 1
means 16 bits,
and it's easier for us to config GUSB2PHYCFG.
Is it OK?
or you could just store the actual width value read from the dts and make
the core handle accordingly, making everything a bit more explicit.
I guess personally I'd do something like:
make dwc->phyif_utmi a regular unsigned int
in probe:
ret = device_property_read_u8(dev, "snps,phyif-utmi-width",
&dwc->phyif_utmi);
if (ret < 0) {
dwc->phyif_utmi = 0;
else if (dwc->phyif_utmi != 16 && dwc->phyif_utmi != 8) {
dev_err(dev, "unsupported utmi interface width %d\n",
dwc->phyif_utmi);
return -EINVAL;
}
when setting your GUSB2PHYCFG register:
if (dwc->phyif_utmi > 0) {
reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
usbtrdtim = (dwc->phyif_utmi == 16) ? USBTRDTIM_UTMI_16_BIT :
USBTRDTIM_UTMI_8_BIT;
phyif = (dwc->phyif_utmi == 16) ? 1 : 0;
reg |= DWC3_GUSB2PHYCFG_PHYIF(phyif) |
DWC3_GUSB2PHYCFG_USBTRDTIM(usbtrdtim) |
}
Ah yes， it seems very good to me, very explicit.
I'l
[PATCH] lockdep: fix warning in case of no_validate lock
Now there are several locks which are marked as no_validate, so name of the lock class can be different with the no_validate lock. This patch avoids this warning for this case, and fix the following warning: [ 14.413292] [ cut here ] [ 14.413297] WARNING: CPU: 1 PID: 1434 at kernel/locking/lockdep.c:704 register_lock_class+0x44a/0x4f0 [ 14.413298] Modules linked in: bcache raid1 psmouse dax_pmem dax nd_pmem serio_raw nvme nd_btt nvme_core floppy null_blk configs autofs4 [ 14.413309] CPU: 1 PID: 1434 Comm: bcache-register Tainted: G W 4.7.0-rc6-next-20160708+ #2069 [ 14.413310] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.9.0-0-g01a84be-prebuilt.qemu-project.org 04/01/2014 [ 14.413311] 880076973900 ba459dec [ 14.413313] 880076973940 ba08af71 02c0ba1312a2 [ 14.413316] bb9fd1e0 880074d078d0 [ 14.413318] Call Trace: [ 14.413321] [] dump_stack+0x85/0xc9 [ 14.413323] [] __warn+0xd1/0xf0 [ 14.413324] [] warn_slowpath_null+0x1d/0x20 [ 14.413326] [] register_lock_class+0x44a/0x4f0 [ 14.413328] [] __lock_acquire+0x85/0x1920 [ 14.413330] [] ? kvm_clock_read+0x23/0x40 [ 14.413332] [] ? sched_clock+0x9/0x10 [ 14.413334] [] ? sched_clock_local+0x18/0x80 [ 14.413336] [] lock_acquire+0xd4/0x240 [ 14.413342] [] ? mca_reap+0x54/0x180 [bcache] [ 14.413343] [] down_write_trylock+0x67/0x80 [ 14.413347] [] ? mca_reap+0x54/0x180 [bcache] [ 14.413351] [] mca_reap+0x54/0x180 [bcache] [ 14.413354] [] mca_alloc+0xc2/0x5a0 [bcache] [ 14.413358] [] bch_btree_node_get+0x143/0x290 [bcache] [ 14.413364] [] run_cache_set+0x239/0x8f0 [bcache] [ 14.413368] [] register_bcache+0x14d2/0x1a30 [bcache] [ 14.413370] [] ? mutex_lock_nested+0x2db/0x460 [ 14.413372] [] kobj_attr_store+0xf/0x20 [ 14.413374] [] sysfs_kf_write+0x44/0x60 [ 14.413376] [] kernfs_fop_write+0x144/0x1e0 [ 14.413378] [] __vfs_write+0x28/0x120 [ 14.413380] [] ? percpu_down_read+0x57/0x90 [ 14.413381] [] ? __sb_start_write+0xca/0xe0 [ 14.413382] [] ? __sb_start_write+0xca/0xe0 [ 14.413383] [] vfs_write+0xb5/0x1b0 [ 14.413385] [] ? trace_hardirqs_on_caller+0xef/0x210 [ 14.413386] [] SyS_write+0x49/0xa0 [ 14.413388] [] entry_SYSCALL_64_fastpath+0x23/0xc1 [ 14.413391] [] ? __this_cpu_preempt_check+0x13/0x20 [ 14.413392] ---[ end trace 16710c495b4dbf2f ]--- Signed-off-by: Ming Lei --- kernel/locking/lockdep.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 589d763..cf071ec 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -701,7 +701,8 @@ look_up_lock_class(struct lockdep_map *lock, unsigned int subclass) * Huh! same key, different name? Did someone trample * on some memory? We're most confused. */ - WARN_ON_ONCE(class->name != lock->name); + WARN_ON_ONCE(lock->key != &__lockdep_no_validate__ && + class->name != lock->name); return class; } } -- 1.9.1
Re: [PULL] lkdtm update (next)
On Tue, Jul 12, 2016 at 9:00 PM, Greg KH wrote: > On Tue, Jul 12, 2016 at 02:42:22PM -0400, Kees Cook wrote: >> On Thu, Jul 7, 2016 at 2:14 PM, Kees Cook wrote: >> > Hi, >> > >> > Please pull these lkdtm changes for next. >> >> Friendly ping... I'd like this refactor to make it in time for the 4.8 >> merge window. :) > > Sorry, was on vacation last week, and am at LinuxCon Japan this week, > will get to it in a day or so. Don't worry, it will make 4.8 :) Awesome, thanks! -Kees -- Kees Cook Chrome OS & Brillo Security
Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS
Stephen Rothwell writes: > On Mon, 11 Jul 2016 16:07:39 -0300 Paulo Flabiano Smorigo > wrote: >> >> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl >> b/drivers/crypto/vmx/aesp8-ppc.pl >> index 2280539..813ffcc 100644 >> --- a/drivers/crypto/vmx/aesp8-ppc.pl >> +++ b/drivers/crypto/vmx/aesp8-ppc.pl >> @@ -1,4 +1,11 @@ >> -#!/usr/bin/env perl >> +#! /usr/bin/env perl >> +# Copyright 2014-2016 The OpenSSL Project Authors. All Rights Reserved. >> +# >> +# Licensed under the OpenSSL license (the "License"). You may not use >> +# this file except in compliance with the License. You can obtain a copy >> +# in the file LICENSE in the source distribution or at >> +# https://www.openssl.org/source/license.html > > So, I assume that this license is compatible with the GPLv2? https://people.gnome.org/~markmc/openssl-and-the-gpl.html has an explanation and points to: https://www.openssl.org/docs/faq.html#LEGAL2 which makes it anything but clearer. it appears the answer is "probably not, unless you have an explicit exemption in your license" -- Stewart Smith OPAL Architect, IBM.
Re: [lkp] [usb] 9696ef14de: WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36 __list_add+0x104/0x188
On Wed, Jul 13, 2016 at 01:55:26AM +, Peter Chen wrote:
>
>
>>-Original Message-
>>From: lkp-requ...@eclists.intel.com [mailto:lkp-requ...@eclists.intel.com] On
>>Behalf
>>Of kernel test robot
>>Sent: Wednesday, July 13, 2016 9:28 AM
>>To: Peter Chen
>>Cc: 0day robot ; LKML ;
>>l...@01.org
>>Subject: [lkp] [usb] 9696ef14de: WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36
>>__list_add+0x104/0x188
>>
>>
>>FYI, we noticed the following commit:
>>
>>https://github.com/0day-ci/linux Peter-Chen/usb-udc-core-fix-error-
>>handling/20160711-100832
>>commit 9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2 ("usb: udc: core: fix error
>>handling")
>>
>
>Thanks, but I really can't find the relationship between my patch and dump.
>Can you reproduce it after running again or without my patch?
>
Sorry, it's a false report, the error dump also showed in parent commit,
please ignore the report and sorry for the noise.
Thanks,
Xiaolong
>Peter
>
>>in testcase: boot
>>
>>on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Nehalem with
>>320M memory
>>
>>caused below changes:
>>
>>[ 22.076363] WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36
>>__list_add+0x104/0x188
>>[ 22.079911] list_add double add: new=88000e422e10,
>>prev=88000e422e10,
>>next=8800135e9168.
>>[ 22.086059] CPU: 0 PID: 1 Comm: swapper Tainted: GW
>>4.7.0-rc4-
>>00110-g9696ef1 #1
>>[ 22.087856] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>Debian-1.8.2-1 04/01/2014
>>[ 22.097535] 88001345fc00 8190c8e2
>>88001345fc40
>>[ 22.099469] 81175453 00240009 88000e422e10
>>8800135e9168
>>[ 22.101220] 88000e422e10 0001
>>88001345fca8
>>[ 22.103291] Call Trace:
>>[ 22.109166] [] dump_stack+0x19/0x1b
>>[ 22.110520] [] __warn+0x10a/0x125
>>[ 22.111632] [] warn_slowpath_fmt+0x46/0x4e
>>[ 22.112939] [] ? klist_add_tail+0x29/0x62
>>[ 22.114418] [] __list_add+0x104/0x188
>>[ 22.115600] [] klist_add_tail+0x53/0x62
>>[ 22.118742] [] device_add+0xb03/0xcca
>>[ 22.121931] [] device_create_groups_vargs+0xfe/0x133
>>[ 22.123390] [] device_create_with_groups+0x2b/0x2d
>>[ 22.130047] [] ? __mutex_unlock_slowpath+0x1cb/0x1d8
>>[ 22.131513] [] misc_register+0x1e0/0x2ec
>>[ 22.132751] [] mousedev_init+0x55/0x81
>>[ 22.134198] [] ? input_leds_init+0x12/0x12
>>[ 22.135442] [] do_one_initcall+0xdc/0x16a
>>[ 22.139131] [] kernel_init_freeable+0x387/0x419
>>[ 22.142059] [] kernel_init+0xa/0x103
>>[ 22.144618] [] ret_from_fork+0x1f/0x40
>>[ 22.148576] [] ? rest_init+0xb8/0xb8
>>[ 22.150009] ---[ end trace 75873bca450a4fe4 ]---
>>[ 22.151559] mousedev: PS/2 mouse device common for all mice
>>[ 22.155003] evbug: Connected device: input0 (Power Button at
>>LNXPWRBN/button/input0)
>>
>>
>>FYI, raw QEMU command line is:
>>
>> qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel /pkg/linux/x86_64-
>>randconfig-s0-07121340/gcc-
>>6/9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2/vmlinuz-4.7.0-rc4-00110-g9696ef1
>>-append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-intel12-yocto-x86_64-
>>3/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-s0-07121340-
>>9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2-20160712-19858-1j3k6zi-0.yaml
>>ARCH=x86_64 kconfig=x86_64-randconfig-s0-07121340 branch=linux-devel/devel-
>>hourly-2016071211 commit=9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2
>>BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s0-07121340/gcc-
>>6/9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2/vmlinuz-4.7.0-rc4-00110-g9696ef1
>>max_uptime=600 RESULT_ROOT=/result/boot/1/vm-intel12-yocto-x86_64/yocto-
>>minimal-x86_64.cgz/x86_64-randconfig-s0-07121340/gcc-
>>6/9696ef14ded07fb0847f8e1cdda6d98a89ecd4f2/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-
>>intel12-yocto-x86_64-3::dhcp drbd.minor_count=8' -initrd
>>/fs/KVM/initrd-vm-intel12-
>>yocto-x86_64-3 -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/KVM/disk0-vm-intel12-yocto-x86_64-3,media=disk,if=virtio -drive
>>file=/fs/KVM/disk1-vm-intel12-yocto-x86_64-3,media=disk,if=virtio -pidfile
>>/dev/shm/kboot/pid-vm-intel12-yocto-x86_64-3 -serial
>>file:/dev/shm/kboot/serial-vm-
>>intel12-yocto-x86_64-3 -daemonize -display none -monitor null
>>
>>
>>
>>
>>
>>Thanks,
>>Xiaolong
Re: [v5 PATCH 1/5] extcon: Add Type-C and DP support
Hi Chanwoo Choi
On 07/13/2016 10:05 AM, Chanwoo Choi wrote:
Hi Chris,
On 2016년 07월 13일 10:39, Chris Zhong wrote:
Hi Chanwoo Choi
On 07/13/2016 09:11 AM, Chanwoo Choi wrote:
Hi Chris,
I'm now developing the extcon property on extcon-test branch.
But, it has not been completed.
On next version, I'll remove the notification about extcon property
and only support the following two functions.
- extcon_set_cable_property()
- extcon_get_cable_property()
Because the number of properties would be risen and the all properties
depend on the specific external connector(e.g., EXTCON_PROP_USB_VBUS
depend on the EXTCON_TYPE_USB type). When the specific external connector
is detached, extcon framework should make the property state as default state.
Yes, I think getting the notification from cable state is enough, actually I am
using it like you said.
OK.
It may send the too many notification for extcon property.
For example, Assume that EXTCON_TYPE_USB has the over 20 properties,
when EXTCON_USB or EXTCON_USB_HOST is detached, extcon should send
the notification for the over 20 properties and one more notificaiton
for state of external connector.
So, I'll send the RFC patchset without the notification of proerty.
Lastly,
I have a comment on below.
Thanks,
Chanwoo Choi
On 2016년 07월 13일 00:09, Chris Zhong wrote:
Add EXTCON_DISP_DP for the Display external connector. For Type-C
connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
Alt Mode on USB Type-C Standard). The Type-C support both normal and
flipped orientation, so add a property to extcon.
Signe-off-by: Chris Zhong
Signed-off-by: Chris Zhong
---
Changes in v5:
- support get property
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
drivers/extcon/extcon.c | 28
include/linux/extcon.h | 13 +
2 files changed, 41 insertions(+)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index a1117db..2591b28 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -157,6 +157,11 @@ struct __extcon_info {
.id = EXTCON_DISP_VGA,
.name = "VGA",
},
+[EXTCON_DISP_DP] = {
+.type = EXTCON_TYPE_DISP,
+.id = EXTCON_DISP_DP,
+.name = "DP",
+},
/* Miscellaneous external connector */
[EXTCON_DOCK] = {
@@ -270,6 +275,7 @@ static bool is_extcon_property_supported(unsigned int id,
switch (prop) {
case EXTCON_PROP_USB_ID:
case EXTCON_PROP_USB_VBUS:
+case EXTCON_PROP_TYPEC_POLARITY:
return true;
default:
break;
@@ -286,6 +292,8 @@ static bool is_extcon_property_supported(unsigned int id,
}
case EXTCON_TYPE_DISP:
switch (prop) {
+case EXTCON_PROP_TYPEC_POLARITY:
Should EXTCON_PROP_TYPEC_POLARITY property add to both EXTCON_TYPE_USB and
EXTCON_TYP_DISP?
EXTCON_PROP_TYPEC_POLARITY is the property of USB C-type?
it is for USB Type-C, But at Display Port alt mode, both EXTCON_USB and
EXTCON_USB_HOST may be detached. Does it support set the property to a detached
cable, if so, I think move this case to EXTCON_USB is fine.
One external connector can set the state of one more external connector
if the one connector support the various functions.
For example, EXTCON_USB and EXTCON_CHG_USB_SDP
The existing extcon driver[1](e.g., max14577/max77693 etc.) set the state of
both EXTCON_USB and EXTCON_CHG_USB_SDP connector at the same time
when usb cable is attached. Because in this case, the usb connector uses as
both power supply(EXTCON_CHG_USB_SDP) and data transfer(EXTCON_USB).
[1]
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next&id=8b45b6a0741678902810d7be95e635c210fbb198
So, DP Alt mode uses the USB Type-C. So, When USB C-type connector is attached
for DP Alt mode,
Maybe, you can set the following two state of connector and one property:
- extcon_set_cable_state(edev, [EXTCON_USB or EXTCON_USB_HOST], 1);
- extcon_set_cable_state(edev, EXTCON_DISP_DP, 1);
- extcon_set_cable_state(edev, [EXTCON_USB or EXTCON_USB_HOST],
EXTCON_PROP_TYPEC_POLARITY, 0 or 1);
Thanks,
Chanwoo Choi
There are 4 modes for Type-C DP alt mode:
1) USB host only :
extcon_set_cable_state(edev, EXTCON_USB_HOST, 1);
extcon_set_cable_state(edev, EXTCON_USB, 0);
extcon_set_cable_state(edev, EXTCON_DISP_DP, 0);
2) USB device only
extcon_set_cable_state(edev, EXTCON_USB_HOST, 0);
extcon_set_cable_state(edev, EXTCON_USB, 1);
extcon_set_cable_state(edev, EXTCON_DISP_DP, 0);
3) DP only
extcon_set_cable_state(edev, EXTCON_USB_HOST, 0);
extcon_set_cable_state(edev, EXTCON_USB, 0);
extcon_set_cable_state(edev, EXTCON_DISP_DP, 1);
4) USB + DP
extcon_set_cable_state(edev, EXTCON_USB_HOST, 1);
extcon_set_cable_state(edev, EXTCON_USB, 0);
extcon_set_cable_state(edev, EXTCON_DISP_DP, 1);
for 3rd mode: DP only, there is only EXTCON_DISP_DP is attache
Re: [RFC 0/3] extend kexec_file_load system call
On 07/12/16 at 03:50pm, Mark Rutland wrote: > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > > into dynamically allocated data structures. After a kexec, the runtime > > > > interface to the firmware is not available, so the flattened DT format > > > > was created as a way to pass the same data in a binary blob to the new > > > > kernel in a format that can be read from the kernel by walking the > > > > directories in /proc/device-tree/*. > > > > > > So this DT is available inside kernel and running kernel can still > > > retrieve it and pass it to second kernel? > > > > The kernel only uses the flattened DT blob at boot time and converts > > it into the runtime data structures (struct device_node). The original > > dtb is typically overwritten later. > > On arm64 we deliberately preserved the DTB, so we can take that and > build a new DTB from that kernel-side. > > > > > - we typically ship devicetree sources for embedded machines with the > > > > kernel sources. As more hardware of the system gets enabled, the > > > > devicetree gains extra nodes and properties that describe the hardware > > > > more completely, so we need to use the latest DT blob to use all > > > > the drivers > > > > > > > > - in some cases, kernels will fail to boot at all with an older version > > > > of the DT, or fail to use the devices that were working on the > > > > earlier kernel. This is usually considered a bug, but it's not rare > > > > > > > > - In some cases, the kernel can update its DT at runtime, and the new > > > > settings are expected to be available in the new kernel too, though > > > > there are cases where you actually don't want the modified contents. > > > > > > I am assuming that modified DT and unmodifed one both are accessible to > > > kernel. And if user space can make decisions which modfied fields to use > > > for new kernels and which ones not, then same can be done in kernel too? > > > > The unmodified DT can typically be found on disk next to the kernel binary. > > The option you have is to either read it from /proc/devicetree or to > > read it from from /boot/*.dtb. > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived > from the raw DTB (which is exposed at /sys/firmware/fdt). > > The blob that was handed to the kernel at boot time is exposed at > /sys/firmware/fdt. I believe the blob can be read and passed to kexec kernel in kernel code without the extra fd. But consider we can kexec to a different kernel and a different initrd so there will be use cases to pass a total different dtb as well. From my understanding it is reasonable but yes I think we should think carefully about the design. Thanks Dave > Thanks, > Mark. > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
linux-next: manual merge of the drm-misc tree with the arm tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c
between commit:
062993b15e8e ("drm: convert DT component matching to
component_match_add_release()")
from the arm tree and commit:
6d5fa28c13b9 ("gpu: drm: rockchip_drm_drv: add missing of_node_put after
calling of_parse_phandle")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 7fd20c0e1fc8,f0bd1ee8b128..
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@@ -438,9 -433,8 +438,10 @@@ static int rockchip_drm_platform_probe(
is_support_iommu = false;
}
+ of_node_put(iommu);
- component_match_add(dev, &match, compare_of, port->parent);
+ of_node_get(port->parent);
+ component_match_add_release(dev, &match, release_of,
+ compare_of, port->parent);
of_node_put(port);
}
Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
On Tue, Jul 12 2016 at 10:18pm -0400,
Eric Wheeler wrote:
> On Tue, 12 Jul 2016, NeilBrown wrote:
>
> > On Tue, Jul 12 2016, Lars Ellenberg wrote:
> >
> > >
> > > Instead, I suggest to distinguish between recursive calls to
> > > generic_make_request(), and pushing back the remainder part in
> > > blk_queue_split(), by pointing current->bio_lists to a
> > > struct recursion_to_iteration_bio_lists {
> > > struct bio_list recursion;
> > > struct bio_list queue;
> > > }
> > >
> > > By providing each q->make_request_fn() with an empty "recursion"
> > > bio_list, then merging any recursively submitted bios to the
> > > head of the "queue" list, we can make the recursion-to-iteration
> > > logic in generic_make_request() process deepest level bios first,
> > > and "sibling" bios of the same level in "natural" order.
> > >
> > > Signed-off-by: Lars Ellenberg
> > > Signed-off-by: Roland Kammerer
> >
> > Reviewed-by: NeilBrown
> >
> > Thanks again for doing this - I think this is a very significant
> > improvement and could allow other simplifications.
>
> Thank you Lars for all of this work!
>
> It seems like there have been many 4.3+ blockdev stacking issues and this
> will certainly address some of those (maybe all of them?). (I think we
> hit this while trying drbd in 4.4 so we dropped back to 4.1 without
> issue.) It would be great to hear 4.4.y stable pick this up if
> compatible.
>
>
> Do you believe that this patch would solve any of the proposals by others
> since 4.3 related to bio splitting/large bios? I've been collecting a
> list, none of which appear have landed yet as of 4.7-rc7 (but correct me
> if I'm wrong):
>
> A. [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs
> by Ming Lei: https://patchwork.kernel.org/patch/9169483/
>
> B. block: don't make BLK_DEF_MAX_SECTORS too big
> by Shaohua Li: http://www.spinics.net/lists/linux-bcache/msg03525.html
>
> C. [1/3] block: flush queued bios when process blocks to avoid deadlock
> by Mikulas Patocka: https://patchwork.kernel.org/patch/9204125/
> (was https://patchwork.kernel.org/patch/7398411/)
>
> D. dm-crypt: Fix error with too large bios
> by Mikulas Patocka: https://patchwork.kernel.org/patch/9138595/
>
> The A,B,D are known to fix large bio issues when stacking dm+bcache
> (though the B,D are trivial and probably necessary even with your patch).
>
> Patch C was mentioned earlier in this thread by Mike Snitzer and you
> commented briefly that his patch might solve the issue; given that, and in
> the interest of minimizing duplicate effort, which of the following best
> describes the situation?
>
> 1. Your patch could supersede Mikulas's patch; they address the same
> issue.
>
> 2. Mikulas's patch addresses different issues such and both patches
> should be applied.
>
> 3. There is overlap between both your patch and Mikulas's such that both
> #1,#2 are true and effort to solve this has been duplicated.
>
>
> If #3, then what might be done to resolve the overlap?
Mikulas confirmed to me that he believes Lars' v2 patch will fix the
dm-snapshot problem, which is being tracked with this BZ:
https://bugzilla.kernel.org/show_bug.cgi?id=119841
We'll see how testing goes (currently underway).
[PATCH] mm: fix calculation accounting dirtyable highmem
When I tested vmscale in mmtest in 32bit, I found the benchmark
was slow down 0.5 times.
basenode
1global-1
User 12.98 16.04
System147.61 166.42
Elapsed26.48 38.08
With vmstat, I found IO wait avg is much increased compared to
base.
The reason was highmem_dirtyable_memory accumulates free pages
and highmem_file_pages from HIGHMEM to MOVABLE zones which was
wrong. With that, dirth_thresh in throtlle_vm_write is always
0 so that it calls congestion_wait frequently if writeback
starts.
With this patch, it is much recovered.
basenode fi
1global-1 fix
User 12.98 16.04 13.78
System147.61 166.42 143.92
Elapsed26.48 38.08 29.64
Signed-off-by: Minchan Kim
---
mm/page-writeback.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 8db1db2..bf27594 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -307,27 +307,31 @@ static unsigned long highmem_dirtyable_memory(unsigned
long total)
{
#ifdef CONFIG_HIGHMEM
int node;
- unsigned long x = 0;
+ unsigned long x;
int i;
- unsigned long dirtyable = highmem_file_pages;
+ unsigned long dirtyable = 0;
for_each_node_state(node, N_HIGH_MEMORY) {
for (i = ZONE_NORMAL + 1; i < MAX_NR_ZONES; i++) {
struct zone *z;
+ unsigned long nr_pages;
if (!is_highmem_idx(i))
continue;
z = &NODE_DATA(node)->node_zones[i];
- dirtyable += zone_page_state(z, NR_FREE_PAGES);
+ if (!populated_zone(z))
+ continue;
+ nr_pages = zone_page_state(z, NR_FREE_PAGES);
/* watch for underflows */
- dirtyable -= min(dirtyable, high_wmark_pages(z));
-
- x += dirtyable;
+ nr_pages -= min(nr_pages, high_wmark_pages(z));
+ dirtyable += nr_pages;
}
}
+ x = dirtyable + highmem_file_pages;
+
/*
* Unreclaimable memory (kernel memory or anonymous memory
* without swap) can bring down the dirtyable pages below
--
1.9.1
[PATCH] mm: fix pgalloc_stall on unpopulated zone
If we use sc->reclaim_idx for accounting pgstall, it can increase
the count on unpopulated zone, for example, movable zone(but
my system doesn't have movable zone) if allocation request were
GFP_HIGHUSER_MOVABLE. It doesn't make no sense.
This patch fixes it so that it can account it on first populated
zone at or below highest_zoneidx of the request.
Signed-off-by: Minchan Kim
---
fs/buffer.c | 2 +-
include/linux/swap.h | 3 ++-
mm/page_alloc.c | 3 ++-
mm/vmscan.c | 5 +++--
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 46b3568..69841f4 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -268,7 +268,7 @@ static void free_more_memory(void)
gfp_zone(GFP_NOFS), NULL);
if (z->zone)
try_to_free_pages(node_zonelist(nid, GFP_NOFS), 0,
- GFP_NOFS, NULL);
+ GFP_NOFS, NULL, gfp_zone(GFP_NOFS));
}
}
diff --git a/include/linux/swap.h b/include/linux/swap.h
index cc753c6..935f7e1 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -309,7 +309,8 @@ extern void lru_cache_add_active_or_unevictable(struct page
*page,
/* linux/mm/vmscan.c */
extern unsigned long pgdat_reclaimable_pages(struct pglist_data *pgdat);
extern unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
- gfp_t gfp_mask, nodemask_t *mask);
+ gfp_t gfp_mask, nodemask_t *mask,
+ enum zone_type classzone_idx);
extern int __isolate_lru_page(struct page *page, isolate_mode_t mode);
extern unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg,
unsigned long nr_pages,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 80c9b9a..5f20d4b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3305,7 +3305,8 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order,
current->reclaim_state = &reclaim_state;
progress = try_to_free_pages(ac->zonelist, order, gfp_mask,
- ac->nodemask);
+ ac->nodemask,
+ zonelist_zone_idx(ac->preferred_zoneref));
current->reclaim_state = NULL;
lockdep_clear_current_reclaim_state();
diff --git a/mm/vmscan.c b/mm/vmscan.c
index c538a8c..1f91e2e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2855,13 +2855,14 @@ static bool throttle_direct_reclaim(gfp_t gfp_mask,
struct zonelist *zonelist,
}
unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
- gfp_t gfp_mask, nodemask_t *nodemask)
+ gfp_t gfp_mask, nodemask_t *nodemask,
+ enum zone_type classzone_idx)
{
unsigned long nr_reclaimed;
struct scan_control sc = {
.nr_to_reclaim = SWAP_CLUSTER_MAX,
.gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)),
- .reclaim_idx = gfp_zone(gfp_mask),
+ .reclaim_idx = classzone_idx,
.order = order,
.nodemask = nodemask,
.priority = DEF_PRIORITY,
--
1.9.1
Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver
On Wed, Jul 13, 2016 at 3:14 AM, Nicolas Dufresne wrote: > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : >> Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : >> > Decoder hardware produces MT21 (compressed). Image processor can >> > convert it to a format that can be input of display driver. >> > Tiffany. >> > When do you plan to upstream image processor (mtk-mdp)? >> > > >> > > It can be as input format for encoder, MDP and display drivers in >> > our >> > > platform. >> > I remember display driver can only accept uncompressed MT21. Right? >> > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque >> > format. It's not usable until it's decompressed and converted by >> > image >> > processor. >> >> Previously it was described as MediaTek block mode, and now as a >> MediaTek compressed format. It makes me think you have no idea what >> this pixel format really is. Is that right ? >> >> The main reason why I keep asking, is that we often find similarities >> between what vendor like to call their proprietary formats. Doing the >> proper research helps not creating a mess like in Android where you >> have a lot of formats that all point to the same format. I believe >> there was the same concern when Samsung wanted to introduce their Z- >> flip-Z NV12 tile format. In the end they simply provided sufficient >> documentation so we could document it and implement software >> converters >> for test and validation purpose. > > Here's the kind of information we want in the documentation. > > https://chromium.googlesource.com/chromium/src/media/+/master/base/vide > o_types.h#40 That is the documentation of decompressed MT21. Originally MT21 was meant to be a YUV format and we can map it in CPU to use it. The name was changed to mean a compressed format. The current design is only MTK image processor can convert it. Software cannot decompress it. I'm not sure if we should document the format inside if we cannot decompress in software. For chromium, I'll update the code to explain MT21 is an opaque compressed format. > > // MediaTek proprietary format. MT21 is similar to NV21 except the memory > // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2 > // interleaved VU plane. Each image contains two buffers -- Y plane and VU > // plane. Two planes can be non-contiguous in memory. The starting addresses > // of Y plane and VU plane are 4KB alignment. > // Suppose image dimension is (width, height). For both Y plane and VU > plane: > // Row pitch = ((width+15)/16) * 16. > // Plane size = Row pitch * (((height+31)/32)*32) > > Now obviously this is incomplete, as the swizzling need to be documented of > course. > >> >> regards, >> Nicolas
linux-next: manual merge of the drm tree with the v4l-dvb tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/media/platform/omap/omap_voutdef.h
between commit:
77430f0396af ("[media] omap_vout: use control framework")
from the v4l-dvb tree and commit:
781a162244a2 ("[media] omap_vout: Switch to use the video/omapfb_dss.h header
file")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/media/platform/omap/omap_voutdef.h
index 49de1475e473,94b5d65afb19..
--- a/drivers/media/platform/omap/omap_voutdef.h
+++ b/drivers/media/platform/omap/omap_voutdef.h
@@@ -11,8 -11,7 +11,8 @@@
#ifndef OMAP_VOUTDEF_H
#define OMAP_VOUTDEF_H
+#include
- #include
+ #include
#include
#define YUYV_BPP2
Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
On Tue, 12 Jul 2016, NeilBrown wrote:
> On Tue, Jul 12 2016, Lars Ellenberg wrote:
>
> >
> > Instead, I suggest to distinguish between recursive calls to
> > generic_make_request(), and pushing back the remainder part in
> > blk_queue_split(), by pointing current->bio_lists to a
> > struct recursion_to_iteration_bio_lists {
> > struct bio_list recursion;
> > struct bio_list queue;
> > }
> >
> > By providing each q->make_request_fn() with an empty "recursion"
> > bio_list, then merging any recursively submitted bios to the
> > head of the "queue" list, we can make the recursion-to-iteration
> > logic in generic_make_request() process deepest level bios first,
> > and "sibling" bios of the same level in "natural" order.
> >
> > Signed-off-by: Lars Ellenberg
> > Signed-off-by: Roland Kammerer
>
> Reviewed-by: NeilBrown
>
> Thanks again for doing this - I think this is a very significant
> improvement and could allow other simplifications.
Thank you Lars for all of this work!
It seems like there have been many 4.3+ blockdev stacking issues and this
will certainly address some of those (maybe all of them?). (I think we
hit this while trying drbd in 4.4 so we dropped back to 4.1 without
issue.) It would be great to hear 4.4.y stable pick this up if
compatible.
Do you believe that this patch would solve any of the proposals by others
since 4.3 related to bio splitting/large bios? I've been collecting a
list, none of which appear have landed yet as of 4.7-rc7 (but correct me
if I'm wrong):
A. [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs
by Ming Lei: https://patchwork.kernel.org/patch/9169483/
B. block: don't make BLK_DEF_MAX_SECTORS too big
by Shaohua Li: http://www.spinics.net/lists/linux-bcache/msg03525.html
C. [1/3] block: flush queued bios when process blocks to avoid deadlock
by Mikulas Patocka: https://patchwork.kernel.org/patch/9204125/
(was https://patchwork.kernel.org/patch/7398411/)
D. dm-crypt: Fix error with too large bios
by Mikulas Patocka: https://patchwork.kernel.org/patch/9138595/
The A,B,D are known to fix large bio issues when stacking dm+bcache
(though the B,D are trivial and probably necessary even with your patch).
Patch C was mentioned earlier in this thread by Mike Snitzer and you
commented briefly that his patch might solve the issue; given that, and in
the interest of minimizing duplicate effort, which of the following best
describes the situation?
1. Your patch could supersede Mikulas's patch; they address the same
issue.
2. Mikulas's patch addresses different issues such and both patches
should be applied.
3. There is overlap between both your patch and Mikulas's such that both
#1,#2 are true and effort to solve this has been duplicated.
If #3, then what might be done to resolve the overlap?
What are the opinions of the authors and can a consensus be reached so we
can see these pushed upstream with the appropriate stable Cc tags and
ultimately fix 4.4.y?
--
Eric Wheeler
Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair
2016-07-13 9:58 GMT+08:00 Xunlei Pang : > On 2016/07/13 at 09:50, Wanpeng Li wrote: >> 2016-07-13 1:25 GMT+08:00 : >>> Konstantin Khlebnikov writes: >>> On 11.07.2016 15:12, Xunlei Pang wrote: > On 2016/07/11 at 17:54, Wanpeng Li wrote: >> Hi Konstantin, Xunlei, >> 2016-07-11 16:42 GMT+08:00 Xunlei Pang : >>> On 2016/07/11 at 16:22, Xunlei Pang wrote: On 2016/07/11 at 15:25, Wanpeng Li wrote: > 2016-06-16 20:57 GMT+08:00 Konstantin Khlebnikov > : >> Hierarchy could be already throttled at this point. Throttled next >> buddy could trigger null pointer dereference in >> pick_next_task_fair(). > There is cfs_rq->next check in pick_next_entity(), so how can null > pointer dereference happen? I guess it's the following code leading to a NULL se returned: >>> s/NULL/empty-entity cfs_rq se/ >>> pick_next_entity(): if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) >> ^ >> I think this will return false. > With the wrong throttled_hierarchy(), I think this can happen. But after > we have the > corrected throttled_hierarchy() patch, I can't see how it is possible. > > dequeue_task_fair(): > if (task_sleep && parent_entity(se)) > set_next_buddy(parent_entity(se)); > > How does dequeue_task_fair() with DEQUEUE_SLEEP set(true task_sleep) > happen to a throttled hierarchy? > IOW, a task belongs to a throttled hierarchy is running? > > Maybe Konstantin knows the reason. This function (dequeue_task_fair) check throttling but at point it could skip several levels and announce as next buddy actually throttled entry. Probably this bug hadn't happened but this's really hard to prove that this is impossible. ->set_curr_task(), PI-boost or some tricky migration in balancer could break this easily. >>> sched_setscheduler can call put_prev_task, which then can cause a >>> throttle outside of __schedule(), then the task blocks normally and >>> deactivate_task(DEQUEUE_SLEEP) happens and you lose. >> The cfs_rq_throttled() check in dequeue_task_fair() will capture the >> cfs_rq which is throttled in sched_setscheduler::put_prev_task path, >> so nothing lost, where I miss? > > cfs_rq_throttled() returns false for child cgroups in the throttled > hierarchy, so > throttled_hierarchy() should be relied on in such cases. Yes, so what's lost in bsegall's reply? Regards, Wanpeng Li
[PATCH V2] iommu: arm-smmu: drop devm_free_irq when driver detach
There is no need to call devm_free_irq when driver detach.
devres_release_all which is called after 'drv->remove' will
release all managed resources.
Signed-off-by: Peng Fan
Reviewed-by: Robin Murphy
Cc: Will Deacon
---
V2:
Fix compile warning. Add Robin's Reviewed-by TAG.
drivers/iommu/arm-smmu.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 860652e..b7ef1d8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2018,7 +2018,6 @@ out_put_masters:
static int arm_smmu_device_remove(struct platform_device *pdev)
{
- int i;
struct device *dev = &pdev->dev;
struct arm_smmu_device *curr, *smmu = NULL;
struct rb_node *node;
@@ -2045,9 +2044,6 @@ static int arm_smmu_device_remove(struct platform_device
*pdev)
if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
dev_err(dev, "removing device with active domains!\n");
- for (i = 0; i < smmu->num_global_irqs; ++i)
- devm_free_irq(smmu->dev, smmu->irqs[i], smmu);
-
/* Turn the thing off */
writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
return 0;
--
2.6.2
Re: dm stripe: add DAX support
On Tue, Jul 12 2016 at 6:22pm -0400, Kani, Toshimitsu wrote: > On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote: > > > > BTW, if in your testing you could evaluate/quantify any extra overhead > > from DM that'd be useful to share. It could be there are bottlenecks > > that need to be fixed, etc. > > Here are some results from fio benchmark. The test is single-threaded and is > bound to one CPU. > > DAX LVM IOPS NOTE > --- > Y N 790K > Y Y 754K 5% overhead with LVM > N N 567K > N Y 457K 20% overhead with LVM > > DAX: Y: mount -o dax,noatime, N: mount -o noatime > LVM: Y: dm-linear on pmem0 device, N: pmem0 device > fio: bs=4k, size=2G, direct=1, rw=randread, numjobs=1 > > Among the 5% overhead with DAX/LVM, the new DM direct_access interfaces > account for less than 0.5%. > > dm_blk_direct_access 0.28% > linear_direct_access 0.17% > > The average latency increases slightly from 0.93us to 0.95us. I think most of > the overhead comes from the submit_bio() path, which is used only for > accessing metadata with DAX. I believe this is due to cloning bio for each > request in DM. There is 12% more L2 miss in total. > > Without DAX, 20% overhead is observed with LVM. Average latency increases > from 1.39us to 1.82us. Without DAX, bio is cloned for both data and metadata. Thanks for putting this summary together. Unfortunately none of the DM changes can be queued for 4.8 until Jens takes the 2 block core patches: https://patchwork.kernel.org/patch/9196021/ https://patchwork.kernel.org/patch/9196019/ Not sure what the hold up and/or issue is with them. But I've asked twice (and implicilty a 3rd time here). Hopefully they land in time for 4.8. Mike
Re: [PATCH v4] [media] pci: Add tw5864 driver - fixed few style nits, going to resubmit soon
Found and fixed few very minor coding style nits, will resubmit in few days, now still waiting for comments to v4. https://github.com/bluecherrydvr/linux/commits/tw5864 commit 31f7c98a144cb3fb8a94662f002d9b6142d1f390 Author: Andrey Utkin Date: Wed Jul 13 05:00:28 2016 +0300 Fix checkpatch --strict issue CHECK: Alignment should match open parenthesis #3599: FILE: drivers/media/pci/tw5864/tw5864-video.c:539: +static int tw5864_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_format *f) commit 11a09a1048af597ecf374507b08c809eed91b86d Author: Andrey Utkin Date: Wed Jul 13 04:59:34 2016 +0300 Fix checkpatch --strict issue CHECK: Please don't use multiple blank lines #3244: FILE: drivers/media/pci/tw5864/tw5864-video.c:184: commit 861b2ba8593db7abe89291a4ba85976519783f4a Author: Andrey Utkin Date: Wed Jul 13 04:58:37 2016 +0300 Fix checkpatch --strict issue CHECK: No space is necessary after a cast #3053: FILE: drivers/media/pci/tw5864/tw5864-util.c:36: + return (u8) tw_readl(TW5864_IND_DATA);
Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version
On 07/12/16 at 02:49am, 河合英宏 / KAWAI，HIDEHIRO wrote: > Hi Dave, > > Thanks for the comments. > > > From: Dave Young [mailto:dyo...@redhat.com] > > Sent: Monday, July 11, 2016 5:35 PM > > > > On 07/05/16 at 08:33pm, Hidehiro Kawai wrote: > > > This patch fixes one of the problems reported by Daniel Walker > > > (https://lkml.org/lkml/2015/6/24/44). > > > > > > If crash_kexec_post_notifiers boot option is specified, other CPUs > > > are stopped by smp_send_stop() instead of machine_crash_shutdown() > > > in crash_kexec() path. This behavior change leads two problems. > > > > > > Problem 1: > > > octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs are > > > still online and try to stop their watchdog timer. If > > > smp_send_stop() is called before octeon_generic_shutdown(), stopping > > > watchdog timer will fail because other CPUs have been offlined by > > > smp_send_stop(). > > > > > >panic() > > > if crash_kexec_post_notifiers == 1 > > >smp_send_stop() > > >atomic_notifier_call_chain() > > >kmsg_dump() > > > crash_kexec() > > >machine_crash_shutdown() > > > octeon_generic_shutdown() // shutdown watchdog for ONLINE CPUs > > > > > > Problem 2: > > > Most of architectures stop other CPUs in machine_crash_shutdown() > > > path, and they also do something needed for kdump. For example, > > > they save registers, disable virtualization extensions, and so on. > > > However, if smp_send_stop() stops other CPUs before > > > machine_crash_shutdown(), we miss those operations. > > > > > > How do we fix these problems? In the first place, we should stop > > > other CPUs as soon as possible when panic() was called, otherwise > > > other CPUs may wipe out a clue to the cause of the failure. So, we > > > replace smp_send_stop() with more suitable one for kdump. > > > > We have been avoiding extra things in panic path, but unfortunately > > crash_kexec_post_notifiers were added. I tend to agree the best place > > for this stuff is in 2nd kernel or purgatory instead of in 1st kernel. > > Several months ago, I posted a patch set which writes regs to SEL, generate > an event to send SNMP message, and start/stop BMC's watchdog timer in > purgatory. This feature requires BMC with KCS (Keyboard Controller Style) > I/F, but the most of enterprise grade server would have it. > (http://thread.gmane.org/gmane.linux.kernel.kexec/15382) > > Doing kmsg_dump things in purgatory wouldn't be suitable (should be done > in the 2nd kernel before enabling devices and IRQs?) In theory it is doable maybe do something like oldmem_kmsg_dump while /proc/vmcore initializing? > > > As for this patch I'm not sure it is safe to replace the smp_send_stop > > with the kdump friendly function. I'm also not sure if the kdump friendly > > function is safe for kdump. Will glad to hear opinions from other > > arch experts. > > This stuff depends on architectures, so I speak only about > x86 (the logic doesn't change on other architectures at this time). > > kdump path with crash_kexec_post_notifiers disabled: > panic() >__crash_kexec() > crash_setup_regs() > crash_save_vmcoreinfo() > machine_crash_shutdown() >native_machine_crash_shutdown() > panic_smp_send_stop() /* mostly same as original > * kdump_nmi_shootdown_cpus() > */ > > kdump path with crash_kexec_post_notifiers enabled: > panic() >panic_smp_send_stop() >__crash_kexec() > crash_setup_regs() > crash_save_vmcoreinfo() > machine_crash_shutdown() >native_machine_crash_shutdown() > panic_smp_send_stop() // do nothing > > The difference is that stopping other CPUs before crash_setup_regs() > and crash_save_vmcoreinfo() or not. Since crash_setup_regs() and > crash_save_vmcoreinfo() just save information to some memory area, > they wouldn't be affected by panic_smp_send_stop(). This means > placing panic_smp_send_stop before __crash_kexec is safe. > > BTW, I noticed my patch breaks Xen kernel. I'll fix it in the > next version. But it does breaks stuff which depends on cpu not being disabled like problem 1 you mentioned in patch log. > > > BTW, if one want to use crash_kexec_post_notifiers he should take the > > risk of unreliable kdump. How about only call smp_send_stop in case no > > crash_kexec_post_notifiers being used. > > Unlike panic_smp_send_stop()/kdump_nmi_shootdown_cpus(), smp_send_stop() > for x86 tries to stop other CPUs with normal IPI before issuing NMI IPI. > This would be because NMI IPI has a risk of deadlock. We checked if > the kdump path has a risk of deadlock in the case of NMI panic and fixed > it. But I'm not sure about normal panic path. I agree with that use > smp_send_stop if crash_kexec_post_notifiers or kdump is disabled. What I mean is like below, problem 1 will not exist in this way, but kdump will be unreliable: if (!cr
Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair
On 2016/07/13 at 09:50, Wanpeng Li wrote: > 2016-07-13 1:25 GMT+08:00 : >> Konstantin Khlebnikov writes: >> >>> On 11.07.2016 15:12, Xunlei Pang wrote: On 2016/07/11 at 17:54, Wanpeng Li wrote: > Hi Konstantin, Xunlei, > 2016-07-11 16:42 GMT+08:00 Xunlei Pang : >> On 2016/07/11 at 16:22, Xunlei Pang wrote: >>> On 2016/07/11 at 15:25, Wanpeng Li wrote: 2016-06-16 20:57 GMT+08:00 Konstantin Khlebnikov : > Hierarchy could be already throttled at this point. Throttled next > buddy could trigger null pointer dereference in pick_next_task_fair(). There is cfs_rq->next check in pick_next_entity(), so how can null pointer dereference happen? >>> I guess it's the following code leading to a NULL se returned: >> s/NULL/empty-entity cfs_rq se/ >> >>> pick_next_entity(): >>> if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) > ^ > I think this will return false. With the wrong throttled_hierarchy(), I think this can happen. But after we have the corrected throttled_hierarchy() patch, I can't see how it is possible. dequeue_task_fair(): if (task_sleep && parent_entity(se)) set_next_buddy(parent_entity(se)); How does dequeue_task_fair() with DEQUEUE_SLEEP set(true task_sleep) happen to a throttled hierarchy? IOW, a task belongs to a throttled hierarchy is running? Maybe Konstantin knows the reason. >>> This function (dequeue_task_fair) check throttling but at point it could >>> skip several >>> levels and announce as next buddy actually throttled entry. >>> Probably this bug hadn't happened but this's really hard to prove that this >>> is impossible. >>> ->set_curr_task(), PI-boost or some tricky migration in balancer could >>> break this easily. >> sched_setscheduler can call put_prev_task, which then can cause a >> throttle outside of __schedule(), then the task blocks normally and >> deactivate_task(DEQUEUE_SLEEP) happens and you lose. > The cfs_rq_throttled() check in dequeue_task_fair() will capture the > cfs_rq which is throttled in sched_setscheduler::put_prev_task path, > so nothing lost, where I miss? cfs_rq_throttled() returns false for child cgroups in the throttled hierarchy, so throttled_hierarchy() should be relied on in such cases. Regards, Xunlei
Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver
Hi Nicolas, On Tue, 2016-07-12 at 15:14 -0400, Nicolas Dufresne wrote: > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > > > Decoder hardware produces MT21 (compressed). Image processor can > > > convert it to a format that can be input of display driver. > > > Tiffany. > > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > > > It can be as input format for encoder, MDP and display drivers in > > > our > > > > platform. > > > I remember display driver can only accept uncompressed MT21. Right? > > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > > format. It's not usable until it's decompressed and converted by > > > image > > > processor. > > > > Previously it was described as MediaTek block mode, and now as a > > MediaTek compressed format. It makes me think you have no idea what > > this pixel format really is. Is that right ? > > > > The main reason why I keep asking, is that we often find similarities > > between what vendor like to call their proprietary formats. Doing the > > proper research helps not creating a mess like in Android where you > > have a lot of formats that all point to the same format. I believe > > there was the same concern when Samsung wanted to introduce their Z- > > flip-Z NV12 tile format. In the end they simply provided sufficient > > documentation so we could document it and implement software > > converters > > for test and validation purpose. > > Here's the kind of information we want in the documentation. > > https://chromium.googlesource.com/chromium/src/media/+/master/base/vide > o_types.h#40 > > // MediaTek proprietary format. MT21 is similar to NV21 except the memory > // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2 > // interleaved VU plane. Each image contains two buffers -- Y plane and VU > // plane. Two planes can be non-contiguous in memory. The starting addresses > // of Y plane and VU plane are 4KB alignment. > // Suppose image dimension is (width, height). For both Y plane and VU > plane: > // Row pitch = ((width+15)/16) * 16. > // Plane size = Row pitch * (((height+31)/32)*32) > > Now obviously this is incomplete, as the swizzling need to be documented of > course. > Because it's finally a compressed format from our codec hw, we cannot describe its swizzling. best regards, Tiffany > > > > regards, > > Nicolas
Re: [v5 PATCH 1/5] extcon: Add Type-C and DP support
Hi Chris,
On 2016년 07월 13일 10:39, Chris Zhong wrote:
> Hi Chanwoo Choi
>
>
> On 07/13/2016 09:11 AM, Chanwoo Choi wrote:
>> Hi Chris,
>>
>> I'm now developing the extcon property on extcon-test branch.
>> But, it has not been completed.
>>
>> On next version, I'll remove the notification about extcon property
>> and only support the following two functions.
>> - extcon_set_cable_property()
>> - extcon_get_cable_property()
>>
>> Because the number of properties would be risen and the all properties
>> depend on the specific external connector(e.g., EXTCON_PROP_USB_VBUS
>> depend on the EXTCON_TYPE_USB type). When the specific external connector
>> is detached, extcon framework should make the property state as default
>> state.
>
> Yes, I think getting the notification from cable state is enough, actually I
> am using it like you said.
OK.
>
>>
>> It may send the too many notification for extcon property.
>> For example, Assume that EXTCON_TYPE_USB has the over 20 properties,
>> when EXTCON_USB or EXTCON_USB_HOST is detached, extcon should send
>> the notification for the over 20 properties and one more notificaiton
>> for state of external connector.
>>
>> So, I'll send the RFC patchset without the notification of proerty.
>>
>> Lastly,
>> I have a comment on below.
>>
>> Thanks,
>> Chanwoo Choi
>>
>> On 2016년 07월 13일 00:09, Chris Zhong wrote:
>>> Add EXTCON_DISP_DP for the Display external connector. For Type-C
>>> connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
>>> Alt Mode on USB Type-C Standard). The Type-C support both normal and
>>> flipped orientation, so add a property to extcon.
>>>
>>> Signe-off-by: Chris Zhong
>>>
>>> Signed-off-by: Chris Zhong
>>> ---
>>>
>>> Changes in v5:
>>> - support get property
>>>
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2: None
>>> Changes in v1: None
>>>
>>> drivers/extcon/extcon.c | 28
>>> include/linux/extcon.h | 13 +
>>> 2 files changed, 41 insertions(+)
>>>
>>> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
>>> index a1117db..2591b28 100644
>>> --- a/drivers/extcon/extcon.c
>>> +++ b/drivers/extcon/extcon.c
>>> @@ -157,6 +157,11 @@ struct __extcon_info {
>>> .id = EXTCON_DISP_VGA,
>>> .name = "VGA",
>>> },
>>> +[EXTCON_DISP_DP] = {
>>> +.type = EXTCON_TYPE_DISP,
>>> +.id = EXTCON_DISP_DP,
>>> +.name = "DP",
>>> +},
>>> /* Miscellaneous external connector */
>>> [EXTCON_DOCK] = {
>>> @@ -270,6 +275,7 @@ static bool is_extcon_property_supported(unsigned int
>>> id,
>>> switch (prop) {
>>> case EXTCON_PROP_USB_ID:
>>> case EXTCON_PROP_USB_VBUS:
>>> +case EXTCON_PROP_TYPEC_POLARITY:
>>> return true;
>>> default:
>>> break;
>>> @@ -286,6 +292,8 @@ static bool is_extcon_property_supported(unsigned int
>>> id,
>>> }
>>> case EXTCON_TYPE_DISP:
>>> switch (prop) {
>>> +case EXTCON_PROP_TYPEC_POLARITY:
>> Should EXTCON_PROP_TYPEC_POLARITY property add to both EXTCON_TYPE_USB and
>> EXTCON_TYP_DISP?
>> EXTCON_PROP_TYPEC_POLARITY is the property of USB C-type?
>
> it is for USB Type-C, But at Display Port alt mode, both EXTCON_USB and
> EXTCON_USB_HOST may be detached. Does it support set the property to a
> detached cable, if so, I think move this case to EXTCON_USB is fine.
One external connector can set the state of one more external connector
if the one connector support the various functions.
For example, EXTCON_USB and EXTCON_CHG_USB_SDP
The existing extcon driver[1](e.g., max14577/max77693 etc.) set the state of
both EXTCON_USB and EXTCON_CHG_USB_SDP connector at the same time
when usb cable is attached. Because in this case, the usb connector uses as
both power supply(EXTCON_CHG_USB_SDP) and data transfer(EXTCON_USB).
[1]
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next&id=8b45b6a0741678902810d7be95e635c210fbb198
So, DP Alt mode uses the USB Type-C. So, When USB C-type connector is attached
for DP Alt mode,
Maybe, you can set the following two state of connector and one property:
- extcon_set_cable_state(edev, [EXTCON_USB or EXTCON_USB_HOST], 1);
- extcon_set_cable_state(edev, EXTCON_DISP_DP, 1);
- extcon_set_cable_state(edev, [EXTCON_USB or EXTCON_USB_HOST],
EXTCON_PROP_TYPEC_POLARITY, 0 or 1);
Thanks,
Chanwoo Choi
Re: [PATCH v6 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller
Hi, On Wed, Jul 13, 2016 at 09:45:43AM +0800, Shawn Lin wrote: > 在 2016/7/13 9:31, Brian Norris 写道: > >On Wed, Jul 13, 2016 at 09:10:15AM +0800, Shawn Lin wrote: > >At some level, it's a matter of preference. But when you're talking > >about the rk3399 PCIe "interrupt controller" domain, it seems that you > >should be talking about HW bits in the controller -- i.e., you have a > >4-bit interrupt status bitfield, that we typically call [0:3]. If you > >use [1:4], then you have to remember to subtract 1 mentally when mapping > >to the actual HW bit. I believe that confusion (since bitfields normally > >count from 0) might have helped cause the infinite loop bug I noticed > >too. And I also think that counting from 0 helps clarify the fact that > >your interrupt controller indexing is an independent numbering from the > >PCI interrupt numbering, even though they happen to map 1:1. > > If that's the fact of how we should numbering our index base, we should > probably start if from 5 as the layout of INTx is > PCIE_CLIENT_INT_STATUS[5:8]... ? Possibly better than starting from 1, but IMO also doesn't make sense, because the other bits aren't interrupts you want to translate on behalf of other devices (are they?) -- they're interrupt bits consumed by the host controller itself. (If they are possibly needed for translation, then sure, index the entire status register and handle it in the driver, and start the INTx mapping from 5 here.) [...] > >If you still think it makes more sense to count from 1, then I won't > >stop you. > > I don't have a hard opinion for the index base as I think it's trivial. It's simple, but I think it influenced code understanding and bugginess. > So if it's more sensible to you, I will apply your suggestion. Well, I was just offering my opinion. I think it makes more sense, but maybe it doesn't to you. Brian
Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver
On Tue, 2016-07-12 at 16:16 +0800, Wu-Cheng Li (李務誠) wrote: > On Mon, Jul 11, 2016 at 10:56 AM, tiffany lin > wrote: > > Hi Hans, > > > > On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote: > >> On 05/30/2016 02:29 PM, Tiffany Lin wrote: > >> > Add V4L2_PIX_FMT_MT21 documentation > >> > > >> > Signed-off-by: Tiffany Lin > >> > --- > >> > Documentation/DocBook/media/v4l/pixfmt.xml |6 ++ > >> > 1 file changed, 6 insertions(+) > >> > > >> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml > >> > b/Documentation/DocBook/media/v4l/pixfmt.xml > >> > index 5a08aee..d40e0ce 100644 > >> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > >> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > >> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines > >> > is JPEG data and should be > >> > concatenated to form the JPEG stream. > >> > > >> > > >> > + > >> > + V4L2_PIX_FMT_MT21 > >> > + 'MT21' > >> > + Compressed two-planar YVU420 format used by Mediatek > >> > MT8173 > >> > + codec driver. > >> > >> Can you give a few more details? The encoder driver doesn't seem to > >> produce this > >> format, so who is creating this? Where is this format documented? > Decoder hardware produces MT21 (compressed). Image processor can > convert it to a format that can be input of display driver. Tiffany. > When do you plan to upstream image processor (mtk-mdp)? > > We are working on this. Will upstream soon. > > It can be as input format for encoder, MDP and display drivers in our > > platform. > I remember display driver can only accept uncompressed MT21. Right? > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > format. It's not usable until it's decompressed and converted by image > processor. That's right in MT8173 platform. best regards, Tiffany > > This private format is only available in our platform. > > So I put it in "Reserved Format Identifiers" sections. > > > > > > best regards, > > Tiffany > > > >> Regards, > >> > >> Hans > >> > >> > + > >> > > >> > > >> > > >> > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver
Hi Nicolas, On Tue, 2016-07-12 at 15:08 -0400, Nicolas Dufresne wrote: > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > > Decoder hardware produces MT21 (compressed). Image processor can > > convert it to a format that can be input of display driver. Tiffany. > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > It can be as input format for encoder, MDP and display drivers in > > our > > > platform. > > I remember display driver can only accept uncompressed MT21. Right? > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > format. It's not usable until it's decompressed and converted by > > image > > processor. > > Previously it was described as MediaTek block mode, and now as a > MediaTek compressed format. It makes me think you have no idea what > this pixel format really is. Is that right ? > That's not right. Its a compressed format as I document in "[PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver." In MT8173 platform, when using this format, we need Image Processor to cover it to standard format as wucheng mentioned. To prevent this ambiguous, I will change it to V4L2_PIX_FMT_M21C, it means its compressed data. Is it ok? best regards, Tiffany > The main reason why I keep asking, is that we often find similarities > between what vendor like to call their proprietary formats. Doing the > proper research helps not creating a mess like in Android where you > have a lot of formats that all point to the same format. I believe > there was the same concern when Samsung wanted to introduce their Z- > flip-Z NV12 tile format. In the end they simply provided sufficient > documentation so we could document it and implement software converters > for test and validation purpose. > > regards, > Nicolas
Re: [PATCH v4] [media] pci: Add tw5864 driver
On Mon, Jul 11, 2016 at 09:40:53AM -0700, Joe Perches wrote: > Each of these blocks will start with the dev_ prefix > and the subsequent lines will not have the same prefix Yes. I have checked how it looks before submitting, but I didn't see this as a problem. I don't mind changing that (anyway I have found few micro-issues with checkpatch --strict and would like to resubmit), but would like to hear some second opinion. > It also might be better to issue something like a single > line dev_warn referring to the driver code and just leave > this comment in the driver sources. > > Something like: > > dev_warn(&pci_dev->dev, > "This driver has known defects in video quality\n"); Things get complicated if you consider mainstream distros and their years-behind kernels. The simplest way to preserve correspondence between state of driver and such notice is to contain the notice in the compiled driver. I hope the state of affairs will change to better someday :)
Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair
2016-07-13 1:25 GMT+08:00 : > Konstantin Khlebnikov writes: > >> On 11.07.2016 15:12, Xunlei Pang wrote: >>> On 2016/07/11 at 17:54, Wanpeng Li wrote: Hi Konstantin, Xunlei, 2016-07-11 16:42 GMT+08:00 Xunlei Pang : > On 2016/07/11 at 16:22, Xunlei Pang wrote: >> On 2016/07/11 at 15:25, Wanpeng Li wrote: >>> 2016-06-16 20:57 GMT+08:00 Konstantin Khlebnikov >>> : Hierarchy could be already throttled at this point. Throttled next buddy could trigger null pointer dereference in pick_next_task_fair(). >>> There is cfs_rq->next check in pick_next_entity(), so how can null >>> pointer dereference happen? >> I guess it's the following code leading to a NULL se returned: > s/NULL/empty-entity cfs_rq se/ > >> pick_next_entity(): >> if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) ^ I think this will return false. >>> >>> With the wrong throttled_hierarchy(), I think this can happen. But after we >>> have the >>> corrected throttled_hierarchy() patch, I can't see how it is possible. >>> >>> dequeue_task_fair(): >>> if (task_sleep && parent_entity(se)) >>> set_next_buddy(parent_entity(se)); >>> >>> How does dequeue_task_fair() with DEQUEUE_SLEEP set(true task_sleep) happen >>> to a throttled hierarchy? >>> IOW, a task belongs to a throttled hierarchy is running? >>> >>> Maybe Konstantin knows the reason. >> >> This function (dequeue_task_fair) check throttling but at point it could >> skip several >> levels and announce as next buddy actually throttled entry. >> Probably this bug hadn't happened but this's really hard to prove that this >> is impossible. >> ->set_curr_task(), PI-boost or some tricky migration in balancer could break >> this easily. > > sched_setscheduler can call put_prev_task, which then can cause a > throttle outside of __schedule(), then the task blocks normally and > deactivate_task(DEQUEUE_SLEEP) happens and you lose. The cfs_rq_throttled() check in dequeue_task_fair() will capture the cfs_rq which is throttled in sched_setscheduler::put_prev_task path, so nothing lost, where I miss? Regards, Wanpeng Li
Re: [PATCH v6 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller
在 2016/7/13 9:31, Brian Norris 写道: Hi Shawn, On Wed, Jul 13, 2016 at 09:10:15AM +0800, Shawn Lin wrote: 在 2016/7/7 8:39, Brian Norris 写道: On Wed, Jul 06, 2016 at 03:16:37PM +0800, Shawn Lin wrote: + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie0_intc 1>, + <0 0 0 2 &pcie0_intc 2>, + <0 0 0 3 &pcie0_intc 3>, + <0 0 0 4 &pcie0_intc 4>; I'm a little lost on this one, so forgive my ignorance; how did you determine the last value in each entry (i.e., the 1, 2, 3, and 4 IRQ numbers for pcie0_intc)? IIUC, those are supposed to represent indeces into the IRQ status register found in the PCIe interrupt status register, and so they should be 0-based (i.e., 0, 1, 2, 3). And then you'd have: interrupt-map = <0 0 0 1 &pcie0_intc 0>, <0 0 0 2 &pcie0_intc 1>, <0 0 0 3 &pcie0_intc 2>, <0 0 0 4 &pcie0_intc 3>; But then, I never got this sub-node binding to work quite right, so I may be missing something. EDIT: ooh, I see what's going on! I'll comment on the driver as well, but it looks like you're translating the register status to a HW IRQ number with 'ffs(reg)', which yields a 1-based index. I think it is most sensible to use a 0-based index (i.e., 'ffs(reg) - 1'). Now, that only will work if you get the whole interrupt-map + interrupt-controller thing right (i.e., using a subnode for the interrupt controller) -- otherwise, IRQ mapping might not work right. I suspect that's one reason the original driver writer might have used 1-based indexing in the first place. yes, I got it but.what's the difference? At some level, it's a matter of preference. But when you're talking about the rk3399 PCIe "interrupt controller" domain, it seems that you should be talking about HW bits in the controller -- i.e., you have a 4-bit interrupt status bitfield, that we typically call [0:3]. If you use [1:4], then you have to remember to subtract 1 mentally when mapping to the actual HW bit. I believe that confusion (since bitfields normally count from 0) might have helped cause the infinite loop bug I noticed too. And I also think that counting from 0 helps clarify the fact that your interrupt controller indexing is an independent numbering from the PCI interrupt numbering, even though they happen to map 1:1. If that's the fact of how we should numbering our index base, we should probably start if from 5 as the layout of INTx is PCIE_CLIENT_INT_STATUS[5:8]... ? But then, PCI INTx numbering is kinda weird already, as it starts from 1. So maybe it's just as valid to say our domain starts from 1 as well. You still need to get the whole interrupt-map + interrupt-controller things right and the code(ffs(reg) - 1)if applied your suggestion. Yes, of course. And I already sent you patches that do that. Look at most of the docs for pcie bindings, I saw they also take 0-base index, how about? I don't know which ones you're referring to. I see that altera-pcie.txt supports interrupt indeces counting from 1, but that's probably because they're using the same broken binding that was in your ~v3 patches (where the pcie node has both 'interrupt-controller' and 'interrupt-map', with phandles to itself), so they had no other choice. If you still think it makes more sense to count from 1, then I won't stop you. I don't have a hard opinion for the index base as I think it's trivial. So if it's more sensible to you, I will apply your suggestion. Regards, Brian -- Best Regards Shawn Lin
Re: [v5 PATCH 1/5] extcon: Add Type-C and DP support
Hi Chanwoo Choi
On 07/13/2016 09:11 AM, Chanwoo Choi wrote:
Hi Chris,
I'm now developing the extcon property on extcon-test branch.
But, it has not been completed.
On next version, I'll remove the notification about extcon property
and only support the following two functions.
- extcon_set_cable_property()
- extcon_get_cable_property()
Because the number of properties would be risen and the all properties
depend on the specific external connector(e.g., EXTCON_PROP_USB_VBUS
depend on the EXTCON_TYPE_USB type). When the specific external connector
is detached, extcon framework should make the property state as default state.
Yes, I think getting the notification from cable state is enough,
actually I am using it like you said.
It may send the too many notification for extcon property.
For example, Assume that EXTCON_TYPE_USB has the over 20 properties,
when EXTCON_USB or EXTCON_USB_HOST is detached, extcon should send
the notification for the over 20 properties and one more notificaiton
for state of external connector.
So, I'll send the RFC patchset without the notification of proerty.
Lastly,
I have a comment on below.
Thanks,
Chanwoo Choi
On 2016년 07월 13일 00:09, Chris Zhong wrote:
Add EXTCON_DISP_DP for the Display external connector. For Type-C
connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
Alt Mode on USB Type-C Standard). The Type-C support both normal and
flipped orientation, so add a property to extcon.
Signe-off-by: Chris Zhong
Signed-off-by: Chris Zhong
---
Changes in v5:
- support get property
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
drivers/extcon/extcon.c | 28
include/linux/extcon.h | 13 +
2 files changed, 41 insertions(+)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index a1117db..2591b28 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -157,6 +157,11 @@ struct __extcon_info {
.id = EXTCON_DISP_VGA,
.name = "VGA",
},
+ [EXTCON_DISP_DP] = {
+ .type = EXTCON_TYPE_DISP,
+ .id = EXTCON_DISP_DP,
+ .name = "DP",
+ },
/* Miscellaneous external connector */
[EXTCON_DOCK] = {
@@ -270,6 +275,7 @@ static bool is_extcon_property_supported(unsigned int id,
switch (prop) {
case EXTCON_PROP_USB_ID:
case EXTCON_PROP_USB_VBUS:
+ case EXTCON_PROP_TYPEC_POLARITY:
return true;
default:
break;
@@ -286,6 +292,8 @@ static bool is_extcon_property_supported(unsigned int id,
}
case EXTCON_TYPE_DISP:
switch (prop) {
+ case EXTCON_PROP_TYPEC_POLARITY:
Should EXTCON_PROP_TYPEC_POLARITY property add to both EXTCON_TYPE_USB and
EXTCON_TYP_DISP?
EXTCON_PROP_TYPEC_POLARITY is the property of USB C-type?
it is for USB Type-C, But at Display Port alt mode, both EXTCON_USB and
EXTCON_USB_HOST may be detached. Does it support set the property to a
detached cable, if so, I think move this case to EXTCON_USB is fine.
Thanks
Chris
+ return true;
default:
break;
}
@@ -547,6 +555,26 @@ int extcon_get_cable_property(struct extcon_dev *edev,
unsigned int id,
enum extcon_property prop,
union extcon_property_value *val)
{
+ struct extcon_cable *cable;
+ int index;
+
+ if (!edev)
+ return -EINVAL;
+
+ /* Check the property whether is supported or not */
+ if (!is_extcon_property_supported(id, prop))
+ return -EINVAL;
+
+ /* Find the cable index of external connector by using id */
+ index = find_cable_index_by_id(edev, id);
+ if (index < 0)
+ return index;
+
+ /* Store the property value */
+ cable = &edev->cables[index];
+
+ val->intval = cable->propval[prop].intval;
+
return 0;
}
After I develop it about get_cable_property, I'll send RFC patchset.
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index f6f0a8d..50ef87f 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -77,6 +77,7 @@ enum extcon_type {
#define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link
*/
#define EXTCON_DISP_DVI 42 /* Digital Visual Interface */
#define EXTCON_DISP_VGA 43 /* Video Graphics Array */
+#define EXTCON_DISP_DP 44 /* DisplayPort */
/* Miscellaneous external connector */
#define EXTCON_DOCK 60
@@ -108,9 +109,13 @@ enum extcon_property {
* - EXTCON_PROP_USB_USB
* @type: integer (int value)
* @value: 0 (low) or 1 (high)
+* - EXTCON_PROP_TYPEC_POLARITY,
+
[lkp] [mm, kasan] 7392becb25: BUG: KASAN: slab-out-of-bounds in bucket_table_alloc+0x79/0x1a0 at addr ffff88003e400000
+0xb0/0xb0 [ 22.807662] [] ? __kthread_parkme+0xb0/0xb0 [ 22.810556] Object at 88003e40, in cache kmalloc-4194304 [ 22.810556] Object at 88003e40, in cache kmalloc-4194304 [ 22.813231] Memory state around the buggy address: FYI, raw QEMU command line is: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -kernel /pkg/linux/x86_64-randconfig-s2-07120443/gcc-6/7392becb255cd6c0e7bedaabd58f638b732772f2/vmlinuz-4.7.0-rc6-1-g7392bec -append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-kbuild-1G-5/bisect_boot-1-debian-x86_64-2015-02-07.cgz-x86_64-randconfig-s2-07120443-7392becb255cd6c0e7bedaabd58f638b732772f2-20160712-21427-xipcnl-0.yaml ARCH=x86_64 kconfig=x86_64-randconfig-s2-07120443 branch=linux-devel/devel-spot-201607120350 commit=7392becb255cd6c0e7bedaabd58f638b732772f2 BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s2-07120443/gcc-6/7392becb255cd6c0e7bedaabd58f638b732772f2/vmlinuz-4.7.0-rc6-1-g7392bec max_uptime=600 RESULT_ROOT=/result/boot/1/vm-kbuild-1G/debian-x86_64-2015-02-07.cgz/x86_64-randconfig-s2-07120443/gcc-6/7392becb255cd6c0e7bedaabd58f638b732772f2/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-1G-5::dhcp' -initrd /fs/sdg1/initrd-vm-kbuild-1G-5 -m 1024 -smp 2 -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::23004-:22 -boot order=nc -no-reboot -watchdog i6300esb -rtc base=localtime -device virtio-scsi-pci,id=scsi0 -drive file=/fs/sdg1/disk0-vm-kbuild-1G-5,if=none,id=hd0,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd0,scsi-id=1,lun=0 -drive file=/fs/sdg1/disk1-vm-kbuild-1G-5,if=none,id=hd1,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd1,scsi-id=1,lun=1 -drive file=/fs/sdg1/disk2-vm-kbuild-1G-5,if=none,id=hd2,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd2,scsi-id=1,lun=2 -drive file=/fs/sdg1/disk3-vm-kbuild-1G-5,if=none,id=hd3,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd3,scsi-id=1,lun=3 -drive file=/fs/sdg1/disk4-vm-kbuild-1G-5,if=none,id=hd4,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd4,scsi-id=1,lun=4 -pidfile /dev/shm/kboot/pid-vm-kbuild-1G-5 -serial file:/dev/shm/kboot/serial-vm-kbuild-1G-5 -daemonize -display none -monitor null Thanks, Xiaolong # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.7.0-rc6 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=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_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_KASAN_SHADOW_OFFSET=0xdc00 CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEBUG_RODATA=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y 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 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y # 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=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENE
Re: [PATCH 2/2] mmc: dw_mmc: Print proper voltage on error
Hi Krzysztof,
On 07/12/2016 11:08 PM, Krzysztof Kozlowski wrote:
> The commit 97f659a2e972 ("mmc: dw_mmc: prevent to set the wrong
> value") reordered the code so the 'uhs' variable used in
> mmc_regulator_set_vqmmc() error message is always 0 at that time thus
> always printing 3.3 voltage. Instead use value obtained from ios in
> printed error message.
The commit 97f659a2e972 was dropped because some board didn't work fine.
Some boards didn't use the vqmmc suppy and not defined into device-tree.
It's short time to fix. I will re-send the patch on next.
At that time, i will check this patch.
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/mmc/host/dw_mmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index c2a128628b31..7de561065003 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1416,8 +1416,8 @@ static int dw_mci_switch_voltage(struct mmc_host *mmc,
> struct mmc_ios *ios)
> ret = mmc_regulator_set_vqmmc(mmc, ios);
> if (ret) {
> dev_err(&mmc->class_dev,
> - "Regulator set error %d - %s V\n",
> - ret, uhs & v18 ? "1.8" : "3.3");
> + "Regulator set error %d - %s\n",
> + ret, mmc_voltage_to_str(ios));
> return ret;
> }
>
>
Re: [PATCH v6 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller
Hi Shawn, On Wed, Jul 13, 2016 at 09:10:15AM +0800, Shawn Lin wrote: > 在 2016/7/7 8:39, Brian Norris 写道: > >On Wed, Jul 06, 2016 at 03:16:37PM +0800, Shawn Lin wrote: > >>+ #interrupt-cells = <1>; > >>+ interrupt-map-mask = <0 0 0 7>; > >>+ interrupt-map = <0 0 0 1 &pcie0_intc 1>, > >>+ <0 0 0 2 &pcie0_intc 2>, > >>+ <0 0 0 3 &pcie0_intc 3>, > >>+ <0 0 0 4 &pcie0_intc 4>; > > > >I'm a little lost on this one, so forgive my ignorance; how did you > >determine the last value in each entry (i.e., the 1, 2, 3, and 4 IRQ > >numbers for pcie0_intc)? IIUC, those are supposed to represent indeces > >into the IRQ status register found in the PCIe interrupt status > >register, and so they should be 0-based (i.e., 0, 1, 2, 3). And then > >you'd have: > > > > interrupt-map = <0 0 0 1 &pcie0_intc 0>, > > <0 0 0 2 &pcie0_intc 1>, > > <0 0 0 3 &pcie0_intc 2>, > > <0 0 0 4 &pcie0_intc 3>; > > > >But then, I never got this sub-node binding to work quite right, so I > >may be missing something. > > > >EDIT: ooh, I see what's going on! I'll comment on the driver as well, > >but it looks like you're translating the register status to a HW IRQ > >number with 'ffs(reg)', which yields a 1-based index. I think it is most > >sensible to use a 0-based index (i.e., 'ffs(reg) - 1'). Now, that only > >will work if you get the whole interrupt-map + interrupt-controller > >thing right (i.e., using a subnode for the interrupt controller) -- > >otherwise, IRQ mapping might not work right. I suspect that's one reason > >the original driver writer might have used 1-based indexing in the first > >place. > > yes, I got it but.what's the difference? At some level, it's a matter of preference. But when you're talking about the rk3399 PCIe "interrupt controller" domain, it seems that you should be talking about HW bits in the controller -- i.e., you have a 4-bit interrupt status bitfield, that we typically call [0:3]. If you use [1:4], then you have to remember to subtract 1 mentally when mapping to the actual HW bit. I believe that confusion (since bitfields normally count from 0) might have helped cause the infinite loop bug I noticed too. And I also think that counting from 0 helps clarify the fact that your interrupt controller indexing is an independent numbering from the PCI interrupt numbering, even though they happen to map 1:1. But then, PCI INTx numbering is kinda weird already, as it starts from 1. So maybe it's just as valid to say our domain starts from 1 as well. > You still need to get the whole interrupt-map + interrupt-controller > things right and the code(ffs(reg) - 1)if applied your suggestion. Yes, of course. And I already sent you patches that do that. > Look at most of the docs for pcie bindings, I saw they also take > 0-base index, how about? I don't know which ones you're referring to. I see that altera-pcie.txt supports interrupt indeces counting from 1, but that's probably because they're using the same broken binding that was in your ~v3 patches (where the pcie node has both 'interrupt-controller' and 'interrupt-map', with phandles to itself), so they had no other choice. If you still think it makes more sense to count from 1, then I won't stop you. Regards, Brian
[PATCH v4] f2fs: fix to avoid data update racing between GC and DIO
Datas in file can be operated by GC and DIO simultaneously, so we will
face race case as below:
For write case:
Thread AThread B
- generic_file_direct_write
- invalidate_inode_pages2_range
- f2fs_direct_IO
- do_blockdev_direct_IO
- do_direct_IO
- get_more_blocks
- f2fs_gc
- do_garbage_collect
- gc_data_segment
- move_data_page
- do_write_data_page
migrate data block to new block
address
- dio_bio_submit
update user data to old block address
For read case:
Thread AThread B
- generic_file_direct_write
- invalidate_inode_pages2_range
- f2fs_direct_IO
- do_blockdev_direct_IO
- do_direct_IO
- get_more_blocks
- f2fs_balance_fs
- f2fs_gc
- do_garbage_collect
- gc_data_segment
- move_data_page
- do_write_data_page
migrate data block to new block
address
- write_checkpoint
- do_checkpoint
- clear_prefree_segments
- f2fs_issue_discard
discard old block adress
- dio_bio_submit
update user buffer from obsolete block address
In order to fix this, for one file, we should let DIO and GC getting exclusion
against with each other.
Signed-off-by: Chao Yu
---
v4: split rwsem to avoid deadlock between dio reader and dio writer.
fs/f2fs/data.c | 6 +-
fs/f2fs/f2fs.h | 1 +
fs/f2fs/gc.c| 20
fs/f2fs/super.c | 2 ++
4 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 20b3016..62947c30 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1714,6 +1714,7 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct
iov_iter *iter)
struct inode *inode = mapping->host;
size_t count = iov_iter_count(iter);
loff_t offset = iocb->ki_pos;
+ int rw = iov_iter_rw(iter);
int err;
err = check_direct_IO(inode, iter, offset);
@@ -1727,8 +1728,11 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct
iov_iter *iter)
trace_f2fs_direct_IO_enter(inode, offset, count, iov_iter_rw(iter));
+ down_read(&F2FS_I(inode)->dio_rwsem[rw]);
err = blockdev_direct_IO(iocb, inode, iter, get_data_block_dio);
- if (iov_iter_rw(iter) == WRITE) {
+ up_read(&F2FS_I(inode)->dio_rwsem[rw]);
+
+ if (rw == WRITE) {
if (err > 0)
set_inode_flag(inode, FI_UPDATE_WRITE);
else if (err < 0)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 1190c04..5973759 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -474,6 +474,7 @@ struct f2fs_inode_info {
struct list_head inmem_pages; /* inmemory pages managed by f2fs */
struct mutex inmem_lock;/* lock for inmemory pages */
struct extent_tree *extent_tree;/* cached extent_tree entry */
+ struct rw_semaphore dio_rwsem[2];/* avoid racing between dio and gc */
};
static inline void get_extent_info(struct extent_info *ext,
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index c612137..5c8acf7 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -755,12 +755,32 @@ next_step:
/* phase 3 */
inode = find_gc_inode(gc_list, dni.ino);
if (inode) {
+ struct f2fs_inode_info *fi = F2FS_I(inode);
+ bool locked = false;
+
+ if (S_ISREG(inode->i_mode)) {
+ if (!down_write_trylock(&fi->dio_rwsem[READ]))
+ continue;
+ if (!down_write_trylock(
+ &fi->dio_rwsem[WRITE])) {
+ up_write(&fi->dio_rwsem[READ]);
+ continue;
+ }
+ locked = true;
+ }
+
start_bidx = start_bidx_of_node(nofs, inode)
+ ofs_in_node;
if (f2fs_encrypted_inode(inode) &&
S_ISREG(inode->i_mode))
move_encrypted_block(inode, start_bidx);
else
move_data
Re: Fix issue with alternatives/paravirt patches
+++ Josh Poimboeuf [12/07/16 09:01 -0500]:
On Tue, Jul 12, 2016 at 01:55:54PM +0200, Miroslav Benes wrote:
On Thu, 7 Jul 2016, Josh Poimboeuf wrote:
> On Thu, Jul 07, 2016 at 05:56:33PM +0200, Petr Mladek wrote:
> > On Tue 2016-07-05 22:34:58, Jessica Yu wrote:
> > > Hi,
> > >
> > > A few months ago, Chris Arges reported a bug involving
alternatives/paravirt
> > > patching that was discussed here [1] and here [2]. To briefly summarize
the
> > > bug, patch modules that contained .altinstructions or .parainstructions
> > > sections would break because these alternative/paravirt patches would be
> > > applied first by the module loader (see x86 module_finalize()), then
> > > livepatch would later clobber these patches when applying per-object
> > > relocations. This lead to crashes and unpredictable behavior.
> > >
> > > One conclusion we reached from our last discussion was that we will
> > > need to introduce some arch-specific code to address this problem.
> > > This patchset presents a possible fix for the bug by adding a new
> > > arch-specific arch_klp_init_object_loaded() function that by default
> > > does nothing but can be overridden by different arches.
> > >
> > > To fix this issue for x86, since we can access a patch module's Elf
> > > sections through mod->klp_info, we can simply delay the calls to
> > > apply_paravirt() and apply_alternatives() to
arch_klp_init_object_loaded(),
> > > which is called after relocations have been written for an object.
> > > In addition, for patch modules, .parainstructions and .altinstructions are
> > > prefixed by ".klp.arch.${objname}" so that the module loader ignores them
> > > and livepatch can apply them manually.
> >
> > The solution looks correct to me. The fun will be how to generate
> > the sections. If I get this correctly, it is not enough to rename
> > the existing ones. Instead, we need to split .parainstructions
> > and .altinstructions sections into per-object ones.
> >
> > I wonder if there is a plan for this. Especially I am interested
> > into the patches created from sources ;-) I wonder if we could add
> > a tag somewhere and improve the build infrastructure.
>
> Yeah. I'd like to reiterate[1] that this would all be a lot easier if
> we weren't circumventing module dependencies.
>
> [1]
https://lkml.kernel.org/r/20160404161428.3qap2i4vpgda6...@treble.redhat.com
Oh, we haven't come to any conclusion. I think it would be a great topic
for Plumbers conf. It is always better to discuss such things personally.
What do you think? Any volunteer to propose it? :)
Well, it's somewhat related to my "Livepatch module creation tooling"
proposed talk, because I suspect the tooling could be *much* simpler if
we didn't circumvent module dependencies. So I'll probably talk about
that aspect of it.
But it would be great if somebody wanted to submit a separate talk to
explore the pros and cons of our current "load patches to modules before
the modules themselves have been loaded" approach and if there are any
viable alternatives.
In addition to Josh's linked discussion, we also once talked about the
idea of forcing module dependencies (exactly!) one year ago today:
http://www.spinics.net/lists/live-patching/msg00946.html
I've forgotten a lot of what I was blabbering about back then (and
this was way before we talked about the .klp.rela stuff), but I do
remember we talked a bit about forcing module dependencies and
potentially forcing to-be-patched modules to be loaded first before
loading the patch module. I still don't think we should do that but
instead we could potentially implement something more palatable like
enforcing maybe one patch module per object (so maybe depmod could
record dependencies for us) or something like that.
It would be interesting to revisit the problem again, esp. in the
context of recent changes. If I end up collecting enough talking
points, I can submit a proposal.
Jessica
Re: linux-next: please clean up the hid tree
Hi Jiri, On Wed, 13 Jul 2016 09:28:09 +1000 Stephen Rothwell wrote: > > The hid tree > (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git#for-next) > seems to be based on v3.19 and constists of a large number of merges > (of stuff that is now in Linus' tree) and ends with one particulary > large revert (of a merge). What I forgot to say is that that last revert creates lots of conflicts when I merge your tree: CONFLICT (content): Merge conflict in sound/pci/hda/patch_realtek.c CONFLICT (content): Merge conflict in mm/shmem.c CONFLICT (content): Merge conflict in fs/dcache.c CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/powerplay/inc/smu74_discrete.h CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c CONFLICT (content): Merge conflict in arch/powerpc/Kconfig CONFLICT (content): Merge conflict in arch/arm/mach-omap2/omap-smp.c CONFLICT (content): Merge conflict in Makefile So I have just dropped the hid tree until it is cleaned up. -- Cheers, Stephen Rothwell
RE: [f2fs-dev] [PATCH 3/7] f2fs: drop any block plugging
Hi, Kim,
You are right. If file system can merge bios as much as possible. It's
very helpful to block layer. But plugging mechanism has a precognition of IO
stream except merging bios. For example, we can out the low-power mode in
advance when you start a plug and we can in the low-power mode only when you
end a plug to avoid in-out low-power mode frequently. So I want to know if
there is any side effect in F2FS to reserve the plug mechanism ?
-Original Message-
From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
Sent: 2016年7月13日 1:08
To: Yuchao (T)
Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net; CHEN CHUN YEN (IAN)
; hebiao (G)
Subject: Re: [f2fs-dev] [PATCH 3/7] f2fs: drop any block plugging
Hi Chao,
On Tue, Jul 12, 2016 at 09:38:11AM +0800, Chao Yu wrote:
> On 2016/7/10 0:32, Jaegeuk Kim wrote:
> > On Sat, Jul 09, 2016 at 10:28:49AM +0800, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2016/6/9 1:24, Jaegeuk Kim wrote:
> >>> In f2fs, we don't need to keep block plugging for NODE and DATA
> >>> writes, since we already merged bios as much as possible.
> >>
> >> IMO, we can not remove block plug, this is because there are still
> >> many conditions which stops us merging r/w IOs into one bio as we
> >> expect, theoretically, block plug can hold bios as much as
> >> possible, then submitting them into queue in batch, it will reduce
> >> racing of grabbing queue->lock during bio submitting, if we drop
> >> them, when syncing nodes or flushing datas, we will suffer more lock
> >> racing.
> >>
> >> Or there are something I am missing, do you suffer any performance
> >> issue on block plug?
> >
> > In the latest patch, I've turned off plugging forcefully, only if
> > the underlying device is SMR drive.
>
> Got it.
>
> > And, still I removed other block plugging, since I couldn't see any
> > performance regression.
>
> I suspect that in low-end machine with single-queue which is used in
> block layer, we will suffer regression.
>
> > Even in some workloads, I could have seen some inverted IOs due to
> > race condition between plugged and unplugged IOs.
>
> For data path, what about enabling block plug for IPU/SSR ?
Not sure. IPU and SSR will produce small (likely random) writes.
What I'm seeing here is that we already try to merge bios as much as possible.
Thus, I'm in doubt why we need to wait for merging them by block layer.
If possible, could you check this in android?
Thanks,
> >>>
> >>> Signed-off-by: Jaegeuk Kim
> >>> ---
> >>> fs/f2fs/checkpoint.c | 4
> >>> fs/f2fs/data.c | 17 ++---
> >>> fs/f2fs/gc.c | 5 -
> >>> fs/f2fs/segment.c| 7 +--
> >>> 4 files changed, 11 insertions(+), 22 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index
> >>> 5ddd15c..4179c7b 100644
> >>> --- a/fs/f2fs/checkpoint.c
> >>> +++ b/fs/f2fs/checkpoint.c
> >>> @@ -897,11 +897,8 @@ static int block_operations(struct f2fs_sb_info *sbi)
> >>> .nr_to_write = LONG_MAX,
> >>> .for_reclaim = 0,
> >>> };
> >>> - struct blk_plug plug;
> >>> int err = 0;
> >>>
> >>> - blk_start_plug(&plug);
> >>> -
> >>> retry_flush_dents:
> >>> f2fs_lock_all(sbi);
> >>> /* write all the dirty dentry pages */ @@ -938,7 +935,6 @@
> >>> retry_flush_nodes:
> >>> goto retry_flush_nodes;
> >>> }
> >>> out:
> >>> - blk_finish_plug(&plug);
> >>> return err;
> >>> }
> >>>
> >>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index
> >>> 30dc448..5f655d0 100644
> >>> --- a/fs/f2fs/data.c
> >>> +++ b/fs/f2fs/data.c
> >>> @@ -98,10 +98,13 @@ static struct bio *__bio_alloc(struct
> >>> f2fs_sb_info *sbi, block_t blk_addr, }
> >>>
> >>> static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
> >>> - struct bio *bio)
> >>> + struct bio *bio, enum page_type type)
> >>> {
> >>> - if (!is_read_io(rw))
> >>> + if (!is_read_io(rw)) {
> >>> atomic_inc(&sbi->nr_wb_bios);
> >>> + if (current->plug && (type == DATA || type == NODE))
> >>> + blk_finish_plug(current->plug);
> >>> + }
> >>> submit_bio(rw, bio);
> >>> }
> >>>
> >>> @@ -117,7 +120,7 @@ static void __submit_merged_bio(struct f2fs_bio_info
> >>> *io)
> >>> else
> >>> trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
> >>>
> >>> - __submit_bio(io->sbi, fio->rw, io->bio);
> >>> + __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
> >>> io->bio = NULL;
> >>> }
> >>>
> >>> @@ -235,7 +238,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
> >>> return -EFAULT;
> >>> }
> >>>
> >>> - __submit_bio(fio->sbi, fio->rw, bio);
> >>> + __submit_bio(fio->sbi, fio->rw, bio, fio->type);
> >>> return 0;
> >>> }
> >>>
> >>> @@ -1040,7 +1043,7 @@ got_it:
> >>>*/
> >>> if (bio && (last_block_in_bio != block_nr - 1)) {
> >>> subm
Re: [PATCH v6 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller
在 2016/7/7 8:39, Brian Norris 写道:
Hi Shawn,
On Wed, Jul 06, 2016 at 03:16:37PM +0800, Shawn Lin wrote:
This patch adds a binding that describes the Rockchip PCIe controller
found on Rockchip SoCs PCIe interface.
Signed-off-by: Shawn Lin
Acked-by: Rob Herring
---
Changes in v6:
- add ack tag from Rob
Changes in v5:
- fix wrong example reported by Marc
- add seperate section to describe the interrupt controller child
node
Changes in v4:
- fix example of adding intermediate interrupt controller for pcie
legacy interrrupt
Changes in v3:
- fix example dts code suggested by Rob and Marc
- remove driver's behaviour of regulator
Changes in v2:
- fix lots clk/reset stuff suggested by Heiko
- remove msi-parent and add msi-map suggested by Marc
- drop phy related stuff
- some others minor fixes
.../devicetree/bindings/pci/rockchip-pcie.txt | 104 +
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/rockchip-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
new file mode 100644
index 000..7616ecc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -0,0 +1,104 @@
+* Rockchip AXI PCIe Root Port Bridge DT description
+
+Required properties:
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- compatible: Should contain "rockchip,rk3399-pcie"
+- reg: Two register ranges as listed in the reg-names property
+- reg-names: Must include the following names
+ - "axi-base"
+ - "apb-base"
+- clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+ - "aclk"
+ - "aclk-perf"
+ - "hclk"
+ - "pm"
+- msi-map: Maps a Requester ID to an MSI controller and associated.
+ See ./pci-msi.txt
+- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
+- phy-names: MUST be "pcie-phy".
+- interrupts: Three interrupt entries must be specified.
+- interrupt-names: Must include the following names
+ - "sys"
+ - "legacy"
+ - "client"
+- resets: Must contain five entries for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the following names
+ - "core"
+ - "mgmt"
+ - "mgmt-sticky"
+ - "pipe"
+- pinctrl-names : The pin control state names
+- pinctrl-0: The "default" pinctrl state
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- interrupt-map-mask and interrupt-map: standard PCI properties
+
+*Interrupt controller child node*
+The core controller provides a single interrupt for legacy INTx. So,
+pcie node should create a interrupt controller node to support 'interrupt-map'
+DT functionality. The driver will create an IRQ domain for this map, decode
+the four INTx interrupts in ISR and route them to this domain.
Where in your driver do you actually handle this child node? I don't see
anything, but perhaps I'm missing something. I see how your earlier
revisions of this driver used of_get_next_child() to acquire the child
node, for use with irq_domain_add_linear(). But that's not in this
version...
+
+Required properties for Interrupt controller child node:
+- interrupt-controller: identifies the node as an interrupt controller
+- #address-cells: specifies the number of cells needed to encode an
+ address. The value must be 0.
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+
+Optional Property:
These optional properties apply to the pcie node, not the interrupt
controller child, right? Seems like the subnode and its properties
should be last (i.e., the 'Optional Property' section should be above
'Interrupt controller child node').
okay, i will move it ahead.
+- ep-gpios: contain the entry for pre-reset gpio
+- num-lanes: number of lanes to use
+- vpcie3v3-supply: The phandle to the 3.3v regulator to use for pcie.
+- vpcie1v8-supply: The phandle to the 1.8v regulator to use for pcie.
+- vpcie0v9-supply: The phandle to the 0.9v regulator to use for pcie.
+
+Example:
+
+pcie0: pcie@f800 {
+ compatible = "rockchip,rk3399-pcie";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
+<&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
+ clock-names = "aclk", "aclk-perf",
+ "hclk", "pm";
+ bus-range = <0x0 0x1>;
+ interrupts = , ,
+;
+ interrupt-names = "sys", "legacy", "client";
+ assigne
Re: Build regressions/improvements in v4.7-rc7
On Wed, Jul 13, 2016 at 2:57 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.7-rc7[1] to v4.7-rc6[3], the summaries are:
> - build errors: +7/-6
+ error: main.c: undefined reference to `__stack_chk_guard': =>
.init.text+0x166), .init.text+0x1d6)
x86_64-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/10595/ (261 out of 263 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/10562/ (260 out of 263 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [v5 PATCH 1/5] extcon: Add Type-C and DP support
Hi Chris,
I'm now developing the extcon property on extcon-test branch.
But, it has not been completed.
On next version, I'll remove the notification about extcon property
and only support the following two functions.
- extcon_set_cable_property()
- extcon_get_cable_property()
Because the number of properties would be risen and the all properties
depend on the specific external connector(e.g., EXTCON_PROP_USB_VBUS
depend on the EXTCON_TYPE_USB type). When the specific external connector
is detached, extcon framework should make the property state as default state.
It may send the too many notification for extcon property.
For example, Assume that EXTCON_TYPE_USB has the over 20 properties,
when EXTCON_USB or EXTCON_USB_HOST is detached, extcon should send
the notification for the over 20 properties and one more notificaiton
for state of external connector.
So, I'll send the RFC patchset without the notification of proerty.
Lastly,
I have a comment on below.
Thanks,
Chanwoo Choi
On 2016년 07월 13일 00:09, Chris Zhong wrote:
> Add EXTCON_DISP_DP for the Display external connector. For Type-C
> connector the DisplayPort can work as an Alternate Mode(VESA DisplayPort
> Alt Mode on USB Type-C Standard). The Type-C support both normal and
> flipped orientation, so add a property to extcon.
>
> Signe-off-by: Chris Zhong
>
> Signed-off-by: Chris Zhong
> ---
>
> Changes in v5:
> - support get property
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> Changes in v1: None
>
> drivers/extcon/extcon.c | 28
> include/linux/extcon.h | 13 +
> 2 files changed, 41 insertions(+)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index a1117db..2591b28 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -157,6 +157,11 @@ struct __extcon_info {
> .id = EXTCON_DISP_VGA,
> .name = "VGA",
> },
> + [EXTCON_DISP_DP] = {
> + .type = EXTCON_TYPE_DISP,
> + .id = EXTCON_DISP_DP,
> + .name = "DP",
> + },
>
> /* Miscellaneous external connector */
> [EXTCON_DOCK] = {
> @@ -270,6 +275,7 @@ static bool is_extcon_property_supported(unsigned int id,
> switch (prop) {
> case EXTCON_PROP_USB_ID:
> case EXTCON_PROP_USB_VBUS:
> + case EXTCON_PROP_TYPEC_POLARITY:
> return true;
> default:
> break;
> @@ -286,6 +292,8 @@ static bool is_extcon_property_supported(unsigned int id,
> }
> case EXTCON_TYPE_DISP:
> switch (prop) {
> + case EXTCON_PROP_TYPEC_POLARITY:
Should EXTCON_PROP_TYPEC_POLARITY property add to both EXTCON_TYPE_USB and
EXTCON_TYP_DISP?
EXTCON_PROP_TYPEC_POLARITY is the property of USB C-type?
> + return true;
> default:
> break;
> }
> @@ -547,6 +555,26 @@ int extcon_get_cable_property(struct extcon_dev *edev,
> unsigned int id,
> enum extcon_property prop,
> union extcon_property_value *val)
> {
> + struct extcon_cable *cable;
> + int index;
> +
> + if (!edev)
> + return -EINVAL;
> +
> + /* Check the property whether is supported or not */
> + if (!is_extcon_property_supported(id, prop))
> + return -EINVAL;
> +
> + /* Find the cable index of external connector by using id */
> + index = find_cable_index_by_id(edev, id);
> + if (index < 0)
> + return index;
> +
> + /* Store the property value */
> + cable = &edev->cables[index];
> +
> + val->intval = cable->propval[prop].intval;
> +
> return 0;
> }
After I develop it about get_cable_property, I'll send RFC patchset.
>
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index f6f0a8d..50ef87f 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -77,6 +77,7 @@ enum extcon_type {
> #define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link
> */
> #define EXTCON_DISP_DVI 42 /* Digital Visual Interface */
> #define EXTCON_DISP_VGA 43 /* Video Graphics Array */
> +#define EXTCON_DISP_DP 44 /* DisplayPort */
>
> /* Miscellaneous external connector */
> #define EXTCON_DOCK 60
> @@ -108,9 +109,13 @@ enum extcon_property {
>* - EXTCON_PROP_USB_USB
>* @type: integer (int value)
>* @value: 0 (low) or 1 (high)
> + * - EXTCON_PROP_TYPEC_POLARITY,
> + * @type: integer (int value)
> + * @value: 0 (normal) or 1 (flip)
>*/
> EXTCON_PROP_USB_ID = 0,
> EXTCON_PROP_USB_VBUS,
> + EXTCON_PROP_TYPEC_POLARITY,
>
> /* Properties of EXTCON_TYPE_CHG. */
> /* Properties of EXTCON_TYPE_JACK. */
> @@ -225,6 +230,
[PATCH 1/3] Documentation: dt: Intersil isl12057 is not a trivial device
The ISL12057 has a documentation file, remove it from trivial-devices.txt Signed-off-by: Alexandre Belloni --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index 539874490492..a397d39ea741 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -50,7 +50,6 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) -isil,isl12057 Intersil ISL12057 I2C RTC Chip isil,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs -- 2.8.1
[PATCH 2/3] rtc: ds1307: add Intersil ISL12057 support
Intersil ISL12057 is a drop-in replacement for DS1337. It can be supported
by the ds1307 driver.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/Kconfig | 8
drivers/rtc/rtc-ds1307.c | 6 ++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index f47c2f5ff70d..ba0b3e7ce4c5 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -198,14 +198,14 @@ config RTC_DRV_AS3722
will be called rtc-as3722.
config RTC_DRV_DS1307
- tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
+ tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025,
ISL12057"
help
If you say yes here you get support for various compatible RTC
chips (often with battery backup) connected with I2C. This driver
should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
- EPSON RX-8025 and probably other chips. In some cases the RTC
- must already have been initialized (by manufacturing or a
- bootloader).
+ EPSON RX-8025, Intersil ISL12057 and probably other chips. In some
+ cases the RTC must already have been initialized (by manufacturing or
+ a bootloader).
The first seven registers on these chips hold an RTC, and other
registers may add features such as NVRAM, a trickle charger for
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 4c5890864d9c..52be48f2e3c0 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -186,6 +186,7 @@ static const struct i2c_device_id ds1307_id[] = {
{ "mcp7941x", mcp794xx },
{ "pt7c4338", ds_1307 },
{ "rx8025", rx_8025 },
+ { "isl1207", ds_1337 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ds1307_id);
@@ -1333,6 +1334,11 @@ static int ds1307_probe(struct i2c_client *client,
if (of_property_read_bool(client->dev.of_node, "wakeup-source")) {
ds1307_can_wakeup_device = true;
}
+ /* Intersil ISL12057 DT backward compatibility */
+ if (of_property_read_bool(client->dev.of_node,
+ "isil,irq2-can-wakeup-machine")) {
+ ds1307_can_wakeup_device = true;
+ }
#endif
switch (ds1307->type) {
--
2.8.1
Re:Re: [f2fs-dev] [PATCH] f2fs: return proper error code
At 2016-07-12 09:45:43, "Chao Yu" wrote: >On 2016/7/11 7:20, Tiezhu Yang wrote: >> When the length of file name is more than F2FS_NAME_LEN, > >Seem @name indicates a xattr/key name, not a file name. Yes, you are right. Sorry for the noise. Thanks,
Re: [PULL] lkdtm update (next)
On Tue, Jul 12, 2016 at 02:42:22PM -0400, Kees Cook wrote: > On Thu, Jul 7, 2016 at 2:14 PM, Kees Cook wrote: > > Hi, > > > > Please pull these lkdtm changes for next. > > Friendly ping... I'd like this refactor to make it in time for the 4.8 > merge window. :) Sorry, was on vacation last week, and am at LinuxCon Japan this week, will get to it in a day or so. Don't worry, it will make 4.8 :) greg k-h
