Re: writev error codes
On Thu 19-01-17 15:09:52, Michael Kerrisk wrote:
> Hello Michal,
>
> On 19 January 2017 at 04:44, Michal Hocko wrote:
> > Hi,
> > we have noticed that one of the LTP tests started to fail after
> > 99526912c934 ("fix iov_iter_fault_in_readable()"). The code has expected
> > EINVAL while it gets EFAULT. I believe the new behavior is reasonable,
> > but checking the man 2 writev, there is no mention about EFAULT,
> > and other errnos for that matter, so it seems this is rather under
> > documented and it can confuse users. LTP has been fixed in the meantime
> > [1] but this might come unexpected to others.
> >
> > In principle writev as a write
> > "multiplier" should be allowed all the error codes that write(2) allows,
> > right? I am not sure how we should reflect that. Either c&p what we have
> > in man 2 write or put a reference to it and only describe writev
> > specific, if there are any (I haven't checked that).
> >
> > [1]
> > https://github.com/linux-test-project/ltp/commit/db19194527060a962955a7db54a2f5710e69bec9
>
> Perhaps I am misunderstanding you, but in the writev(2) page there is the
> text:
>
> ERRORS
>The errors are as given for read(2) and write(2). Furthermore,
>preadv(), preadv2(), pwritev(), and pwritev2() can also fail for
>the same reasons as lseek(2).
This has hit right to the blind spot. Sorry about the noise!
>
> And in the write(2) page, we have:
>
>EFAULT buf is outside your accessible address space.
>
> Does this not cover the case you describe?
Yes
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA
On Wed 2017-01-18 17:29:05, Laura Abbott wrote: > > Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option > provides key security features that are to be expected on a modern > system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more > accurately describes what this option is intended to do. I think this is bad change. CONFIG_DEBUG_RODATA is describing what it does, CONFIG_HARDENED_PAGE_MAPPINGS is advertising. We don't do advertising, and we don't force people to re-answer the config questions without good reason. CONFIG_HARDENED_RODATA might fix the first problem, but not the second one. Pavel > Signed-off-by: Laura Abbott > --- > Documentation/DocBook/kgdb.tmpl| 8 > Documentation/security/self-protection.txt | 2 +- > arch/arm/Kconfig | 1 + > arch/arm/configs/aspeed_g4_defconfig | 2 +- > arch/arm/configs/aspeed_g5_defconfig | 2 +- > arch/arm/include/asm/cacheflush.h | 2 +- > arch/arm/kernel/patch.c| 2 +- > arch/arm/kernel/vmlinux.lds.S | 8 > arch/arm/mm/Kconfig| 14 +- > arch/arm/mm/init.c | 4 ++-- > arch/arm64/Kconfig | 4 +--- > arch/arm64/Kconfig.debug | 2 +- > arch/parisc/Kconfig| 1 + > arch/parisc/Kconfig.debug | 11 --- > arch/parisc/configs/712_defconfig | 2 +- > arch/parisc/configs/c3000_defconfig| 2 +- > arch/parisc/mm/init.c | 2 +- > arch/s390/Kconfig | 4 +--- > arch/x86/Kconfig | 4 +--- > include/linux/init.h | 4 ++-- > init/main.c| 4 ++-- > kernel/configs/android-recommended.config | 2 +- > kernel/power/hibernate.c | 2 +- > kernel/power/power.h | 4 ++-- > kernel/power/snapshot.c| 4 ++-- > security/Kconfig | 16 > 26 files changed, 51 insertions(+), 62 deletions(-) > > diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl > index f3abca7..a79b638 100644 > --- a/Documentation/DocBook/kgdb.tmpl > +++ b/Documentation/DocBook/kgdb.tmpl > @@ -115,12 +115,12 @@ > > > If the architecture that you are using supports the kernel option > -CONFIG_DEBUG_RODATA, you should consider turning it off. This > +CONFIG_HARDENED_PAGE_MAPPINGS, you should consider turning it off. This > option will prevent the use of software breakpoints because it > marks certain regions of the kernel's memory space as read-only. > If kgdb supports it for the architecture you are using, you can > use hardware breakpoints if you desire to run with the > -CONFIG_DEBUG_RODATA option turned on, else you need to turn off > +CONFIG_HARDENED_PAGE_MAPPINGS option turned on, else you need to turn off > this option. > > > @@ -135,7 +135,7 @@ > Here is an example set of .config symbols to enable or > disable for kgdb: > > -# CONFIG_DEBUG_RODATA is not set > +# CONFIG_HARDENED_PAGE_MAPPINGS is not > set > CONFIG_FRAME_POINTER=y > CONFIG_KGDB=y > CONFIG_KGDB_SERIAL_CONSOLE=y > @@ -166,7 +166,7 @@ > > Here is an example set of .config symbols to enable/disable kdb: > > -# CONFIG_DEBUG_RODATA is not set > +# CONFIG_HARDENED_PAGE_MAPPINGS is not > set > CONFIG_FRAME_POINTER=y > CONFIG_KGDB=y > CONFIG_KGDB_SERIAL_CONSOLE=y > diff --git a/Documentation/security/self-protection.txt > b/Documentation/security/self-protection.txt > index 3010576..da8cb36 100644 > --- a/Documentation/security/self-protection.txt > +++ b/Documentation/security/self-protection.txt > @@ -51,7 +51,7 @@ kernel, they are implemented in a way where the memory is > temporarily > made writable during the update, and then returned to the original > permissions.) > > -In support of this are (the poorly named) CONFIG_DEBUG_RODATA and > +In support of this are CONFIG_HARDENED_PAGE_MAPPINGS and > CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not > writable, data is not executable, and read-only data is neither writable > nor executable. > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 186c4c2..09aff28 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -7,6 +7,7 @@ config ARM > select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST > select ARCH_HAVE_CUSTOM_GPIO_H > select ARCH_HAS_GCOV_PROFILE_ALL > + select ARCH_HAS_HARDENED_MAPPINGS if MMU && !XIP_KERNEL > select ARCH_MIGHT_HAVE_PC_PARPORT > select ARCH_SUPPORTS
Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
On Wed, 18 Jan 2017 16:20:10 -0600 Rob Herring wrote: > On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote: > > Hello, > > > > (Side note: you guys should learn about stripping irrelevant parts of > > an e-mail when replying!) > > > > On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote: > > > > > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor" > > > > as the oldest supported compatible and be done with it, no ? It looks a > > > > bit crappy though, I admit that ... > > > > > > Let's stop bikeshedding and wait for DT maintainers feedback > > > before taking a decision ;-). > > > > > > Rob, Mark, any opinion? > > > > Sigh, is how to do compatibles really not yet understood? Apparently not, and I fear this is not the last misunderstanding on my side ;-). > > > I agree that a clarification would be good. There are really two > > options: > > > > 1. Have two compatible strings in the DT, the one that matches the > > exact SoC where the IP is found (first compatible string) and the > > one that matches some other SoC where the same IP is found (second > > compatible string). Originally, Linux only supports the second > > compatible string in its device driver, but if it happens that a > > difference is found between two IPs that we thought were the same, > > we can add support for the first compatible string in the driver, > > with a slightly different behavior. > > This. And no wildcards in the compatible string. > > > 2. Have a single compatible string in the DT, matching the exact SoC > > where the IP is found. This involves adding immediately this > > compatible string in the corresponding driver. > > I wouldn't object to this from a DT perspective as I have no clue > generally if IP blocks are "the same" or not. Subsystem maintainers will > object though. > > > I've not really been able to figure out which of the two options is the > > most future-proof/appropriate. > > They are both future-proof. #2 has the disadvantage of requiring a > kernel update for a new SoC. > > Rob
[GIT PULL] xen: fix for 4.10 rc4
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.10-rc4-tag It contains a fix for Xen running in nested virtualization environment. Thanks. Juergen drivers/xen/platform-pci.c | 71 ++ 1 file changed, 71 insertions(+) Stefano Stabellini (1): partially revert "xen: Remove event channel notification through Xen PCI platform device"
Re: [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses
On 18/01/17 21:14, Boris Ostrovsky wrote:
> On 01/16/2017 09:15 AM, Juergen Gross wrote:
>> +
>> +static uint32_t xs_request_enter(struct xb_req_data *req)
>> +{
>> +uint32_t rq_id;
>> +
>> +req->type = req->msg.type;
>> +
>> +spin_lock(&xs_state_lock);
>> +for (;;) {
>> +if (req->msg.tx_id != 0)
>> +break;
>> +if (xs_suspend_active) {
>> +spin_unlock(&xs_state_lock);
>> +wait_event(xs_state_enter_wq, xs_suspend_active == 0);
>> +spin_lock(&xs_state_lock);
>> +continue;
>> +}
>> +if (req->type == XS_TRANSACTION_START)
>> +xs_state_users++;
>> +break;
>> +}
>> +xs_state_users++;
>> +rq_id = xs_request_id++;
>> +spin_unlock(&xs_state_lock);
>> +
>> +return rq_id;
>> +}
>
> I should have noticed this last time but I've been looking at this code
> again and I don't think I understand why you are incrementing count for
> XS_TRANSACTION_START inside the loop.
>
> In fact, why not just 'while(xs_suspend_active) {}' loop?
That's a valid question.
I'll change it. The reason to have the larger loop body isn't existing
any longer.
Juergen
Re: [PATCH V2 00/18] *** SUBJECT HERE ***
On Wed, Jan 18, 2017 at 04:44:32PM -0700, k...@exchange.microsoft.com wrote: > From: K. Y. Srinivasan "interesting" subject :(
Re: [PATCH v6 03/25] usb: ulpi: Support device discovery via DT
On Thu, Jan 19, 2017 at 02:33:49PM +0800, Peter Chen wrote: > On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote: > > The qcom HSIC ULPI phy doesn't have any bits set in the vendor or > > product ID registers. This makes it impossible to make a ULPI > > driver match against the ID registers. Add support to discover > > the ULPI phys via DT help alleviate this problem. In the DT case, > > we'll look for a ULPI bus node underneath the device registering > > the ULPI viewport (or the parent of that device to support > > chipidea's device layout) and then match up the phy node > > underneath that with the ULPI device that's created. > > > > The side benefit of this is that we can use standard properties > > in the phy node like clks, regulators, gpios, etc. because we > > don't have firmware like ACPI to turn these things on for us. And > > we can use the DT phy binding to point our phy consumer to the > > phy provider. > > > > The ULPI bus code supports native enumeration by reading the > > vendor ID and product ID registers at device creation time, but > > we can't be certain that those register reads will succeed if the > > phy is not powered up. To avoid any problems with reading the ID > > registers before the phy is powered we fallback to DT matching > > when the ID reads fail. > > > > If the ULPI spec had some generic power sequencing for these > > registers we could put that into the ULPI bus layer and power up > > the device before reading the ID registers. Unfortunately this > > doesn't exist and the power sequence is usually device specific. > > By having the device matched up with DT we can avoid this > > problem. > > > > Cc: Greg Kroah-Hartman > > Acked-by: Heikki Krogerus > > Cc: > > Acked-by: Rob Herring > > Signed-off-by: Stephen Boyd > > Greg, is it ok I pick up this patch, and send it with chipidea > changes together for 4.11-rc1 later? No objection from me. thanks, greg k-h
Re: [PATCH 0/6 v4] adv7511 EDID probing improvements
On Wed, Jan 18, 2017 at 9:22 PM, Archit Taneja wrote: > > > On 01/19/2017 04:34 AM, Laurent Pinchart wrote: >> >> Hi John, >> >> Thank you for the patches. >> >> On Monday 16 Jan 2017 16:52:46 John Stultz wrote: >>> >>> Wanted to re-send out v4 of this patch set, integrating some >>> changes suggested by Laurent, for consideration for merging for >>> v4.11 >>> >>> The first three patches are fixups that are hopefully straight >>> forward, integrating feedback I got from Laurant, with minimal >>> change from the previous versions. >>> >>> The last three patches try to clean up and rework the EDID >>> probing code, to avoid issues seen on HiKey. I've reworked these >>> more significantly since v3 to address feedback from Laurent. >>> >>> Thoughts and feedback would be appreciated! >> >> >> For the whole series, >> >> Tested-by: Laurent Pinchart > > > Queued to drm-misc-next. Updated the commit messages for patches 5 > and 6 as suggested by Laurent. Ah! Many thanks Archit! I was going to respin the patches tomorrow but you beat me to it. :) The help is much appreciated! -john
tip.today - scheduler bam boom crash (cpu hotplug)
Mindless testing only, too sick to work, not sick enough to be immune to boredom. Was verifying first warning wasn't somehow rt inspired, but while doing so, plain nopreempt (and no rt patch set) went boom. [ 203.088255] smpboot: CPU 1 is now offline [ 203.168181] smpboot: CPU 2 is now offline [ 203.221461] x86: Booting SMP configuration: [ 203.221464] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 203.221728] [ cut here ] [ 203.221733] WARNING: CPU: 1 PID: 0 at kernel/sched/clock.c:149 set_sched_clock_stable+0x43/0x50 [ 203.221733] Modules linked in: nls_utf8(E) isofs(E) ebtable_filter(E) ebtables(E) fuse(E) nf_log_ipv6(E) xt_pkttype(E) xt_physdev(E) br_netfilter(E) nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) af_packet(E) bridge(E) stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) xt_tcpudp(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) ipt_REJECT(E) iptable_raw(E) xt_CT(E) iptable_filter(E) ip6table_mangle(E) nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) ip6table_filter(E) ip6_tables(E) x_tables(E) nls_iso8859_1(E) snd_hda_codec_hdmi(E) nls_cp437(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) kvm(E) snd_hda_intel(E) [ 203.221748] snd_hda_codec(E) irqbypass(E) crct10dif_pclmul(E) snd_hda_core(E) snd_hwdep(E) nfsd(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) pcbc(E) snd_pcm(E) auth_rpcgss(E) aesni_intel(E) aes_x86_64(E) snd_timer(E) nfs_acl(E) joydev(E) crypto_simd(E) snd(E) lockd(E) grace(E) iTCO_wdt(E) iTCO_vendor_support(E) lpc_ich(E) mei_me(E) i2c_i801(E) mei(E) pcspkr(E) glue_helper(E) mfd_core(E) shpchp(E) intel_smartconnect(E) sunrpc(E) soundcore(E) tpm_infineon(E) fan(E) thermal(E) battery(E) cryptd(E) efivarfs(E) sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_logitech_dj(E) uas(E) usb_storage(E) hid_generic(E) usbhid(E) nouveau(E) wmi(E) i2c_algo_bit(E) drm_kms_helper(E) ahci(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) libahci(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) [ 203.221765] ttm(E) libata(E) r8169(E) mii(E) drm(E) usbcore(E) fjes(E) video(E) button(E) sd_mod(E) vfat(E) fat(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mod(E) loop(E) sg(E) scsi_mod(E) autofs4(E) [ 203.221773] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GE 4.10.0-tip-default #29 [ 203.221774] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 203.221774] Call Trace: [ 203.221778] dump_stack+0x63/0x90 [ 203.221780] __warn+0xd1/0xf0 [ 203.221782] warn_slowpath_null+0x1d/0x20 [ 203.221782] set_sched_clock_stable+0x43/0x50 [ 203.221784] early_init_intel+0x225/0x360 [ 203.221785] init_intel+0x18/0x2d0 [ 203.221786] identify_cpu+0x2d1/0x4d0 [ 203.221786] identify_secondary_cpu+0x18/0x80 [ 203.221789] smp_store_cpu_info+0x3e/0x40 [ 203.221790] start_secondary+0x53/0x180 [ 203.221791] start_cpu+0x14/0x14 [ 203.221792] ---[ end trace 262c7e4b746d5a76 ]--- [ 207.525918] smpboot: CPU 2 is now offline [ 207.586516] smpboot: CPU 4 is now offline [ 207.642988] smpboot: CPU 6 is now offline [ 207.682207] x86: Booting SMP configuration: [ 207.682210] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 207.682505] sched_clock: Marking stable (207412639708, 0)->(207410993286, 1646422) [ 207.706220] smpboot: Booting Node 0 Processor 2 APIC 0x4 [ 207.706502] sched_clock: Marking stable (207524564558, 0)->(207522917721, 1646837) [ 207.730376] smpboot: Booting Node 0 Processor 4 APIC 0x1 [ 207.730644] sched_clock: Marking stable (207585448402, 0)->(207583801309, 1647093) [ 207.754593] smpboot: Booting Node 0 Processor 6 APIC 0x5 [ 207.754881] sched_clock: Marking stable (207641939733, 0)->(207640292394, 1647339) [ 207.802195] smpboot: CPU 3 is now offline [ 207.862396] smpboot: CPU 4 is now offline [ 207.927159] [ cut here ] [ 207.927163] WARNING: CPU: 6 PID: 45 at kernel/sched/sched.h:807 assert_clock_updated.isra.62.part.63+0x25/0x27 [ 207.927164] rq->clock_update_flags < RQCF_ACT_SKIP [ 207.927164] Modules linked in: nls_utf8(E) isofs(E) ebtable_filter(E) ebtables(E) fuse(E) nf_log_ipv6(E) xt_pkttype(E) xt_physdev(E) br_netfilter(E) nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) af_packet(E) bridge(E) stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) xt_tcpudp(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) ipt_REJECT(E) iptable_raw(E) xt_CT(E) iptable_filter(E) ip6table_mangle(E) nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) ip6table_filter(E) ip6_tables(E) x_tables(E) nls_iso8859_1(E) snd_hda_codec_hdmi(E) nls_cp437(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) snd_hda_co
linux-next 20170117 - lockdep whines and BUGs in ata_scsi_rbuf_fill()
linux-next 20170110 didn't exhibit this.
Am seeing at boot a lockdep whine, followed by 3 BUGs. ata_scsi_rbuf_fill() is
in the traceback for all of them.'git log' hints that it's one of 6 commits
against drivers/ata/libata-scsi.c by Christoph, but none of them spring out
as being the guilty party. This ring any bells, or should I start
cherrypicking reverts and bisecting?
(-dirty due to a local patch to net/ipv6/addrconf.c for a VPN issue)
Lockdep:
[3.359133] =
[3.359162] [ INFO: inconsistent lock state ]
[3.359192] 4.10.0-rc4-next-20170117-dirty #375 Not tainted
[3.359229] -
[3.359258] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[3.359299] kworker/u8:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes:
[3.359334] (&(&host->lock)->rlock){?.}, at: []
ata_scsi_queuecmd+0x4f/0x420
[3.359398] {IN-HARDIRQ-W} state was registered at:
[3.359431]
[3.359434] [] __lock_acquire+0x636/0x18b0
[3.359484]
[3.359486] [] lock_acquire+0x119/0x2d0
[3.359533]
[3.359535] [] _raw_spin_lock+0x41/0x80
[3.359582]
[3.359584] [] ahci_single_level_irq_intr+0x44/0x90
[3.359638]
[3.359640] [] __handle_irq_event_percpu+0x127/0x690
[3.359694]
[3.359696] [] handle_irq_event_percpu+0x34/0xb0
[3.359747]
[3.359749] [] handle_irq_event+0x4b/0xc0
[3.359797]
[3.359799] [] handle_edge_irq+0xb5/0x3d0
[3.359847]
[3.359849] [] handle_irq+0xa6/0x2c0
[3.359895]
[3.359897] [] do_IRQ+0x83/0x1b0
[3.359940]
[3.359942] [] ret_from_intr+0x0/0x19
[3.359989]
[3.359992] [] cpuidle_enter_state+0xe4/0x660
[3.360043]
[3.360045] [] cpuidle_enter+0x17/0x20
[3.360092]
[3.360095] [] do_idle+0x2f7/0x3d0
[3.360139]
[3.360142] [] cpu_startup_entry+0x7c/0x90
[3.360190]
[3.360193] [] rest_init+0x15c/0x170
[3.360239]
[3.360242] [] start_kernel+0x747/0x788
[3.360288]
[3.360291] [] x86_64_start_reservations+0x4f/0x70
[3.360344]
[3.360346] [] x86_64_start_kernel+0x344/0x38b
[3.360397]
[3.360400] [] verify_cpu+0x0/0xf1
[3.360445] irq event stamp: 160102
[3.360470] hardirqs last enabled at (160101): []
_raw_spin_unlock_irq+0x2e/0x80
[3.360529] hardirqs last disabled at (160102): []
_raw_spin_lock_irqsave+0x1e/0x90
[3.360589] softirqs last enabled at (159762): []
__do_softirq+0x55d/0xa39
[3.360644] softirqs last disabled at (159741): []
irq_exit+0x111/0x170
[3.360695]
other info that might help us debug this:
[3.360737] Possible unsafe locking scenario:
[3.360775]CPU0
[3.360793]
[3.360810] lock(&(&host->lock)->rlock);
[3.360839]
[3.360857] lock(&(&host->lock)->rlock);
[3.360887]
*** DEADLOCK ***
[3.360926] 4 locks held by kworker/u8:0/5:
[3.360954] #0: ("events_unbound"){.+.+.+}, at: []
process_one_work+0x347/0xe10
[3.361015] #1: ((&entry->work)){+.+.+.}, at: []
process_one_work+0x347/0xe10
[3.361075] #2: (&shost->scan_mutex){+.+.+.}, at: []
__scsi_add_device+0xac/0x150
[3.361137] #3: (&(&host->lock)->rlock){?.}, at: []
ata_scsi_queuecmd+0x4f/0x420
[3.362428] usbcore: registered new interface driver uvcvideo
[3.362429] USB Video Class driver (1.1.1)
[3.367023]
stack backtrace:
[3.370918] CPU: 1 PID: 5 Comm: kworker/u8:0 Not tainted
4.10.0-rc4-next-20170117-dirty #375
[3.372913] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A17
08/19/2015
[3.374918] Workqueue: events_unbound async_run_entry_fn
[3.376925] Call Trace:
[3.378912] dump_stack+0x7b/0xd1
[3.380888] print_usage_bug+0x27b/0x330
[3.382850] mark_lock+0x6ea/0x8a0
[3.384787] ? print_shortest_lock_dependencies+0x380/0x380
[3.386726] mark_held_locks+0x93/0x160
[3.388651] ? add_lock_to_list.isra.17.constprop.33+0xa7/0x160
[3.390591] ? cache_alloc_refill+0x9dd/0x1360
[3.392533] trace_hardirqs_on_caller+0x103/0x2c0
[3.394464] trace_hardirqs_on+0xd/0x10
[3.396390] cache_alloc_refill+0x9dd/0x1360
[3.398301] ? ___might_sleep+0x1e2/0x300
[3.400203] ? __might_sleep+0x66/0x1f0
[3.402091] kmem_cache_alloc_trace+0xf3/0x4f0
[3.403976] ? ata_scsiop_inq_00+0x160/0x160
[3.405854] ata_scsi_rbuf_fill+0x39/0x110
[3.407696] ata_scsi_simulate+0x2e8/0x4b0
[3.409533] ata_scsi_queuecmd+0x303/0x420
[3.411350] scsi_dispatch_cmd+0x188/0x690
[3.413154] scsi_request_fn+0x709/0xd00
[3.414958] __blk_run_queue+0x7e/0xb0
[3.416733] blk_execute_rq_nowait+0x1c5/0x210
[3.418515] ? blk_execute_rq_nowait+0x210/0x210
[3.420304] blk_execute_rq+0x14b/0x210
[3.422088] ? blk_rq_append_bio+0x9d/0x100
[3.423864] ? blk_rq_map_kern+0x11b/0x200
[3.425584] ? blk_get_request+0x149/0x290
[3.427285] __scsi_execute+0x148/0x210
[3.429035] scsi_execute_req_flags+0x98/0x110
[3.
Re: [patch -mm] mm, page_alloc: warn_alloc nodemask is NULL when cpusets are disabled
On 01/18/2017 10:51 PM, David Rientjes wrote:
> The patch "mm, page_alloc: warn_alloc print nodemask" implicitly sets the
> allocation nodemask to cpuset_current_mems_allowed when there is no
> effective mempolicy. cpuset_current_mems_allowed is only effective when
> cpusets are enabled, which is also printed by warn_alloc(), so setting
> the nodemask to cpuset_current_mems_allowed is redundant and prevents
> debugging issues where ac->nodemask is not set properly in the page
> allocator.
>
> This provides better debugging output since
> cpuset_print_current_mems_allowed() is already provided.
>
> Signed-off-by: David Rientjes
Yes, with my current cpuset vs mempolicy debugging experience, this is
more useful (except how both nodemask and mems_allowed can change under
us, so what we print here is not necessarily the same that what
get_page_from_freelist() has seen, but that's another thing...).
But I would suggest you change the oom killer's dump_header() the same
way than warn_alloc().
Thanks,
Vlastimil
> ---
> mm/page_alloc.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3037,7 +3037,6 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask,
> const char *fmt, ...)
> va_list args;
> static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST);
> - nodemask_t *nm = (nodemask) ? nodemask : &cpuset_current_mems_allowed;
>
> if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs) ||
> debug_guardpage_minorder() > 0)
> @@ -3051,11 +3050,16 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask,
> const char *fmt, ...)
> pr_cont("%pV", &vaf);
> va_end(args);
>
> - pr_cont(", mode:%#x(%pGg), nodemask=%*pbl\n", gfp_mask, &gfp_mask,
> nodemask_pr_args(nm));
> + pr_cont(", mode:%#x(%pGg), nodemask=", gfp_mask, &gfp_mask);
> + if (nodemask)
> + pr_cont("%*pbl\n", nodemask_pr_args(nodemask));
> + else
> + pr_cont("(null)\n");
> +
> cpuset_print_current_mems_allowed();
>
> dump_stack();
> - warn_alloc_show_mem(gfp_mask, nm);
> + warn_alloc_show_mem(gfp_mask, nodemask);
> }
>
> static inline struct page *
>
Re: [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2
On Thu, Jan 19, 2017 at 12:47 AM, Dmitry Torokhov wrote: > On Tue, Jan 17, 2017 at 08:10:56PM +0200, Krzysztof Kozlowski wrote: >> On Tue, Jan 17, 2017 at 10:06:27AM -0800, Dmitry Torokhov wrote: >> > On Tue, Jan 17, 2017 at 9:20 AM, Krzysztof Kozlowski >> > wrote: >> > > On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote: >> > >> This patch adds support for the TM2 touch key and led >> > >> functionality. >> > >> >> > >> The driver interfaces with userspace through an input device and >> > >> reports KEY_PHONE and KEY_BACK event types. LED brightness can be >> > >> controlled by "/sys/class/leds/tm2-touchkey/brightness". >> > >> >> > >> Signed-off-by: Beomho Seo >> > >> Signed-off-by: Jaechul Lee >> > >> Reviewed-by: Javier Martinez Canillas >> > >> Reviewed-by: Andi Shyti >> > >> Reviewed-by: Chanwoo Choi >> > >> Tested-by: Chanwoo Choi >> > >> Acked-by: Krzysztof Kozlowski >> > >> Signed-off-by: Dmitry Torokhov >> > > >> > > This looks unusual. How did Dmitry's Sob end here? >> > >> > I sent Jaechul a version of the patch to try out. >> >> Ah, makes sense then. > > I picked up (and folded) the binding doc and driver patches, DTS should > go through some other tree I believe. Yes, I will take it. I waited for driver and bindings to be accepted. Thanks, Krzysztof
[PATCH 4/6] media: ti-vpe: cal: use of_graph_get_remote_endpoint()
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/media/platform/ti-vpe/cal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/cal.c
b/drivers/media/platform/ti-vpe/cal.c
index 7a058b6..ebf11b4 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1701,7 +1701,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx,
int inst)
asd->match_type = V4L2_ASYNC_MATCH_OF;
asd->match.of.node = sensor_node;
- remote_ep = of_parse_phandle(ep_node, "remote-endpoint", 0);
+ remote_ep = of_graph_get_remote_endpoint(ep_node);
if (!remote_ep) {
ctx_dbg(3, ctx, "can't get remote-endpoint\n");
goto cleanup_exit;
--
1.9.1
[PATCH 2/6] drm/omapdrm: use of_graph_get_remote_endpoint()
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e96..f49f2ba 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include "omapdss.h"
@@ -127,7 +128,7 @@ static struct device_node *omapdss_of_get_remote_port(const
struct device_node *
{
struct device_node *np;
- np = of_parse_phandle(node, "remote-endpoint", 0);
+ np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
--
1.9.1
Re: [PATCH] kprobes: move kprobe declarations to asm-generic/kprobes.h
On Thu, 19 Jan 2017 10:38:12 +0900 Masami Hiramatsu wrote: > Hi Luis, > > On Wed, 18 Jan 2017 09:48:40 -0800 > "Luis R. Rodriguez" wrote: > > > Often all is needed is these small helpers, instead of compiler.h > > or a full kprobes.h. This is important for asm helpers, in fact even > > some asm/kprobes.h make use of these helpers... instead just keep a > > generic asm file with helpers useful for asm code with the least amount > > of clutter as possible. > > > > Likewise we need now to also address what to do about this file for both > > when architectures have CONFIG_HAVE_KPROBES, and when they do not. Then > > for when architectures have CONFIG_HAVE_KPROBES but have disabled > > CONFIG_KPROBES. > > > > Right now most asm/kprobes.h do not have guards against CONFIG_KPROBES, > > this means most architecture code cannot include asm/kprobes.h safely. > > Just from curiosity, would you have any actual issue (like compile error) > about that? > > > Correct this and add guards for architectures missing them. Additionally > > provide architectures that not have kprobes support with the default > > asm-generic solution. This lets us force asm/kprobes.h on the header > > include/linux/kprobes.h always, but most importantly we can now safely > > include just asm/kprobes.h on architecture code without bringing > > the full kitchen sink of header files. > > It is fine to me to separate it into asm-generic/kprobes.h. > > > Two architectures already provided a guard against CONFIG_KPROBES on > > its kprobes.h: sh, arch. The rest of the architectures needed gaurds > > added. We avoid including any not-needed headers on asm/kprobes.h > > unless kprobes have been enabled. > > > > In a subsequent atomic change we can try now to remove compiler.h from > > include/linux/kprobes.h. > > Nice :) > > > > > During this sweep I've also identified a few architectures defining > > a common macro needed for both kprobes and ftrace, that of the > > definition of the breakput instruction up. Some refer to this as > > BREAKPOINT_INSTRUCTION. This must be kept outside of the #ifdef > > CONFIG_KPROBES guard. > > Hmm, since it depends on ftrace arch-depend implementation, I would > like to ask you to split this part into other patches for each arch, > with a build failure log. Ah, I understand. This becomes new issue when you make the #ifdef guards on asm/kprobes.h. OK, then it is OK to me. Acked-by: Masami Hiramatsu Thank you, > > Thank you, > > > > > v5: > > > > o fix BREAKPOINT_INSTRUCTION dependency with kernel architecture > > ftrace implementations: Although its correct to #ifdef CONFIG_KPROBES > > on the architecture arch/$(ARCH)/include/asm/kprobes.h when > > architectures support ftrace they will rely on the > > BREAKPOINT_INSTRUCTION definition, this needs to be kept out from > > CONFIG_KPROBES as ftrace can be enabled without kprobes. This > > fixes compilation on x86 where kprobes is disabled but ftrace is > > left enabled. > > > > o include on arch/arm64/kernel/probes/decode-insn.h > > > > Signed-off-by: Luis R. Rodriguez > > --- > > > > This was part of the linker table series [0], but I'm going to split up > > patches further there. This is an atomic change which is independent > > so sending this separately now. > > > > [0] https://lkml.kernel.org/r/20170115211057.17167-1-mcg...@kernel.org > > > > MAINTAINERS| 1 + > > arch/alpha/include/asm/Kbuild | 1 + > > arch/arc/include/asm/kprobes.h | 6 -- > > arch/arm/include/asm/kprobes.h | 4 > > arch/arm/probes/decode.h | 1 + > > arch/arm64/include/asm/kprobes.h | 4 > > arch/arm64/kernel/insn.c | 1 + > > arch/arm64/kernel/probes/decode-insn.h | 2 ++ > > arch/avr32/include/asm/kprobes.h | 7 ++- > > arch/blackfin/include/asm/Kbuild | 1 + > > arch/c6x/include/asm/Kbuild| 1 + > > arch/cris/include/asm/Kbuild | 1 + > > arch/frv/include/asm/Kbuild| 1 + > > arch/h8300/include/asm/Kbuild | 1 + > > arch/hexagon/include/asm/Kbuild| 1 + > > arch/ia64/include/asm/kprobes.h| 12 +--- > > arch/m32r/include/asm/Kbuild | 1 + > > arch/m68k/include/asm/Kbuild | 1 + > > arch/metag/include/asm/Kbuild | 1 + > > arch/microblaze/include/asm/Kbuild | 1 + > > arch/mips/include/asm/kprobes.h| 6 +- > > arch/mn10300/include/asm/kprobes.h | 7 ++- > > arch/nios2/include/asm/Kbuild | 1 + > > arch/openrisc/include/asm/Kbuild | 1 + > > arch/parisc/include/asm/Kbuild | 1 + > > arch/powerpc/include/asm/kprobes.h | 3 +++ > > arch/s390/include/asm/kprobes.h| 7 ++- > > arch/score/include/asm/Kbuild | 1 + > > arch/sh/include/asm/kprobes.h | 5 - > > arch/sparc/include/asm/kprobes.h | 10 -- > > arch/tile/inclu
[PATCH 5/6] v4l: of: use of_graph_get_remote_endpoint()
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/media/v4l2-core/v4l2-of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 93b3368..b2ed4b3 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -284,7 +285,7 @@ int v4l2_of_parse_link(const struct device_node *node,
np = of_get_next_parent(np);
link->local_node = np;
- np = of_parse_phandle(node, "remote-endpoint", 0);
+ np = of_graph_get_remote_endpoint(node);
if (!np) {
of_node_put(link->local_node);
return -ENOLINK;
--
1.9.1
Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote: > On Tue, 17 Jan 2017, Shivappa Vikas wrote: >> On Tue, 17 Jan 2017, Thomas Gleixner wrote: >> > On Fri, 6 Jan 2017, Vikas Shivappa wrote: >> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints >> > > zeros or arbitrary numbers. >> > > >> > > Fix: Patches fix this by just throwing an error if the mode is not >> > > supported. >> > > The modes supported is task monitoring and cgroup monitoring. >> > > Also the per package >> > > data for say socket x is returned with the -C -G cgrpy >> > > option. >> > > The systemwide data can be looked up by monitoring root cgroup. >> > >> > Fine. That just lacks any comment in the implementation. Otherwise I would >> > not have asked the question about cpu monitoring. Though I fundamentaly >> > hate the idea of requiring cgroups for this to work. >> > >> > If I just want to look at CPU X why on earth do I have to set up all that >> > cgroup muck? Just because your main focus is cgroups? >> >> The upstream per cpu data is broken because its not overriding the other task >> event RMIDs on that cpu with the cpu event RMID. >> >> Can be fixed by adding a percpu struct to hold the RMID thats affinitized >> to the cpu, however then we miss all the task llc_occupancy in that - still >> evaluating it. > > The point here is that CQM is closely connected to the cache allocation > technology. After a lengthy discussion we ended up having > > - per cpu CLOSID > - per task CLOSID > > where all tasks which do not have a CLOSID assigned use the CLOSID which is > assigned to the CPU they are running on. > > So if I configure a system by simply partitioning the cache per cpu, which > is the proper way to do it for HPC and RT usecases where workloads are > partitioned on CPUs as well, then I really want to have an equaly simple > way to monitor the occupancy for that reservation. > Your use case is specific to HPC and not Web workloads we run. Jobs run in cgroups which may span all the CPUs of the machine. CAT may be used to partition the cache. Cgroups would run inside a partition. There may be multiple cgroups running in the same partition. I can understand the value of tracking occupancy per CLOSID, however that granularity is not enough for our use case. Inside a partition, we want to know the occupancy of each cgroup to be able to assign blame to the top consumer. Thus, there needs to be a way to monitor occupancy per cgroup. I'd like to understand how your proposal would cover this use case. Another important aspect is that CQM measures new allocations, thus to get total occupancy you need to be able to monitor the thread, CPU, CLOSid or cgroup from the beginning of execution. In the case of a cgroup from the moment where the first thread is scheduled into the cgroup. To do this a RMID needs to be assigned from the beginning to the entity to be monitored. It could be by creating a CQM event just to cause an RMID to be assigned as discussed earlier on this thread. And then if a perf stat is launched later it will get the same RMID and report full occupancy. But that requires the first event to remain alive, i.e., some process must keep the file descriptor open, i.e., need some daemon or a perf stat running in the background. There are also use cases where you want CQM without necessarily enabling CAT, for instance, if you want to know the cache footprint of a workload to estimate how if it could be co-located with others. I think any viable proposal needs to be able to support your use case as well as the ones I described above. > And looking at that from the CAT point of view, which is the proper way to > do it, makes it obvious that CQM should be modeled to match CAT. > > So lets assume the following: > >CPU 0-3 default CLOSID 0 >CPU 4 CLOSID 1 >CPU 5 CLOSID 2 >CPU 6 CLOSID 3 >CPU 7 CLOSID 3 > >T1 CLOSID 4 >T2 CLOSID 5 >T3 CLOSID 6 >T4 CLOSID 6 > >All other tasks use the per cpu defaults, i.e. the CLOSID of the CPU >they run on. > > then the obvious basic monitoring requirement is to have a RMID for each > CLOSID. > > So when I monitor CPU4, i.e. CLOSID 1 and T1 runs on CPU4, then I do not > care at all about the occupancy of T1 simply because that is running on a > seperate reservation. Trying to make that an aggregated value in the first > place is completely wrong. If you want an aggregate, which is pretty much > useless, then user space tools can generate it easily. > > The whole approach you and David have taken is to whack some desired cgroup > functionality and whatever into CQM without rethinking the overall > design. And that's fundamentaly broken because it does not take cache (and > memory bandwidth) allocation into account. > > I seriously doubt, that the existing CQM/MBM code can be refactored in any > useful
Re: [PATCH v6 03/25] usb: ulpi: Support device discovery via DT
On Wed, Dec 28, 2016 at 02:56:49PM -0800, Stephen Boyd wrote:
> The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
> product ID registers. This makes it impossible to make a ULPI
> driver match against the ID registers. Add support to discover
> the ULPI phys via DT help alleviate this problem. In the DT case,
> we'll look for a ULPI bus node underneath the device registering
> the ULPI viewport (or the parent of that device to support
> chipidea's device layout) and then match up the phy node
> underneath that with the ULPI device that's created.
>
> The side benefit of this is that we can use standard properties
> in the phy node like clks, regulators, gpios, etc. because we
> don't have firmware like ACPI to turn these things on for us. And
> we can use the DT phy binding to point our phy consumer to the
> phy provider.
>
> The ULPI bus code supports native enumeration by reading the
> vendor ID and product ID registers at device creation time, but
> we can't be certain that those register reads will succeed if the
> phy is not powered up. To avoid any problems with reading the ID
> registers before the phy is powered we fallback to DT matching
> when the ID reads fail.
>
> If the ULPI spec had some generic power sequencing for these
> registers we could put that into the ULPI bus layer and power up
> the device before reading the ID registers. Unfortunately this
> doesn't exist and the power sequence is usually device specific.
> By having the device matched up with DT we can avoid this
> problem.
>
> Cc: Greg Kroah-Hartman
> Acked-by: Heikki Krogerus
> Cc:
> Acked-by: Rob Herring
> Signed-off-by: Stephen Boyd
Greg, is it ok I pick up this patch, and send it with chipidea
changes together for 4.11-rc1 later?
Peter
> ---
> Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++
> drivers/usb/common/ulpi.c | 79
> --
> 2 files changed, 93 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt
> b/Documentation/devicetree/bindings/usb/ulpi.txt
> new file mode 100644
> index ..ca179dc4bd50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ulpi.txt
> @@ -0,0 +1,20 @@
> +ULPI bus binding
> +
> +
> +Phys that are behind a ULPI connection can be described with the following
> +binding. The host controller shall have a "ulpi" named node as a child, and
> +that node shall have one enabled node underneath it representing the ulpi
> +device on the bus.
> +
> +EXAMPLE
> +---
> +
> +usb {
> + compatible = "vendor,usb-controller";
> +
> + ulpi {
> + phy {
> + compatible = "vendor,phy";
> + };
> + };
> +};
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 8b317702d761..c9480d77810c 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -16,6 +16,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> /*
> -- */
>
> @@ -39,6 +42,10 @@ static int ulpi_match(struct device *dev, struct
> device_driver *driver)
> struct ulpi *ulpi = to_ulpi_dev(dev);
> const struct ulpi_device_id *id;
>
> + /* Some ULPI devices don't have a vendor id so rely on OF match */
> + if (ulpi->id.vendor == 0)
> + return of_driver_match_device(dev, driver);
> +
> for (id = drv->id_table; id->vendor; id++)
> if (id->vendor == ulpi->id.vendor &&
> id->product == ulpi->id.product)
> @@ -50,6 +57,11 @@ static int ulpi_match(struct device *dev, struct
> device_driver *driver)
> static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
> struct ulpi *ulpi = to_ulpi_dev(dev);
> + int ret;
> +
> + ret = of_device_uevent_modalias(dev, env);
> + if (ret != -ENODEV)
> + return ret;
>
> if (add_uevent_var(env, "MODALIAS=ulpi:v%04xp%04x",
> ulpi->id.vendor, ulpi->id.product))
> @@ -60,6 +72,11 @@ static int ulpi_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> static int ulpi_probe(struct device *dev)
> {
> struct ulpi_driver *drv = to_ulpi_driver(dev->driver);
> + int ret;
> +
> + ret = of_clk_set_defaults(dev->of_node, false);
> + if (ret < 0)
> + return ret;
>
> return drv->probe(to_ulpi_dev(dev));
> }
> @@ -87,8 +104,13 @@ static struct bus_type ulpi_bus = {
> static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
>char *buf)
> {
> + int len;
> struct ulpi *ulpi = to_ulpi_dev(dev);
>
> + len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
> + if (len != -ENODEV)
> + return len;
> +
> return sprintf(buf, "ulpi:v%
[PATCH 6/6] omapfb: use of_graph_get_remote_endpoint()
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index d356a25..f1eb8b0 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -128,7 +129,7 @@ static struct device_node *omapdss_of_get_remote_port(const
struct device_node *
{
struct device_node *np;
- np = of_parse_phandle(node, "remote-endpoint", 0);
+ np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
--
1.9.1
Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver
On Wed, Jan 18, 2017 at 12:14 AM, Paul Cercueil wrote: > One problem still unresolved: the pinctrl framework does not allow us to > configure each pin on demand (someone please prove me wrong), when the > various PWM channels are requested or released. For instance, the PWM > channels can be configured from sysfs, which would require all PWM pins > to be configured properly beforehand for the PWM function, eventually > causing conflicts with other platform or board drivers. Why do you think this? - Pincontrol handles can be obtained at runtime. - Pincontrol states can be changed at runtime. The fact that a the handle is retrived by the device core and set to the states named "init" or "default" during boot is just a convenience. You can have as many and as fine-grained states as you want. They can pertain to just one pin too. Linus Walleij
[PATCH 2/6] drm/omapdrm: use of_graph_get_remote_endpoint()
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e96..f49f2ba 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include "omapdss.h"
@@ -127,7 +128,7 @@ static struct device_node *omapdss_of_get_remote_port(const
struct device_node *
{
struct device_node *np;
- np = of_parse_phandle(node, "remote-endpoint", 0);
+ np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
--
1.9.1
[PATCH 3/6] drm: rcar-du: use of_graph_get_remote_endpoint()
From: Kuninori Morimoto
Now, we can use of_graph_get_remote_endpoint(). Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 7a6bd8b..2ba728b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -391,7 +391,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
return -ENODEV;
}
- entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
+ entity_ep_node = of_graph_get_remote_endpoint(ep->local_node);
for_each_endpoint_of_node(entity, ep_node) {
if (ep_node == entity_ep_node)
--
1.9.1
[PATCH 1/6] of_graph: add of_graph_get_remote_endpoint()
From: Kuninori Morimoto
It should use same method to get same result.
To getting remote-endpoint node,
let's use of_graph_get_remote_endpoint()
Signed-off-by: Kuninori Morimoto
---
drivers/of/base.c| 18 --
include/linux/of_graph.h | 8
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c..5391a9b5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2426,6 +2426,20 @@ struct device_node *of_graph_get_endpoint_by_regs(
EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
/**
+ * of_graph_get_remote_endpoint() - get remote endpoint node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: Remote endpoint node associated with remote endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_remote_endpoint(const struct device_node
*node)
+{
+ /* Get remote endpoint node. */
+ return of_parse_phandle(node, "remote-endpoint", 0);
+}
+EXPORT_SYMBOL(of_graph_get_remote_endpoint);
+
+/**
* of_graph_get_remote_port_parent() - get remote port's parent node
* @node: pointer to a local endpoint device_node
*
@@ -2439,7 +2453,7 @@ struct device_node *of_graph_get_remote_port_parent(
unsigned int depth;
/* Get remote endpoint node. */
- np = of_parse_phandle(node, "remote-endpoint", 0);
+ np = of_graph_get_remote_endpoint(node);
/* Walk 3 levels up only if there is 'ports' node. */
for (depth = 3; depth && np; depth--) {
@@ -2463,7 +2477,7 @@ struct device_node *of_graph_get_remote_port(const struct
device_node *node)
struct device_node *np;
/* Get remote endpoint node. */
- np = of_parse_phandle(node, "remote-endpoint", 0);
+ np = of_graph_get_remote_endpoint(node);
if (!np)
return NULL;
return of_get_next_parent(np);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index bb3a5a2..d9d6d9c 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -48,6 +48,8 @@ struct device_node *of_graph_get_next_endpoint(const struct
device_node *parent,
struct device_node *previous);
struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg);
+struct device_node *of_graph_get_remote_endpoint(
+ const struct device_node *node);
struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -78,6 +80,12 @@ static inline struct device_node
*of_graph_get_endpoint_by_regs(
return NULL;
}
+static inline struct device_node *of_graph_get_remote_endpoint(
+ const struct device_node *node)
+{
+ return NULL;
+}
+
static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
{
--
1.9.1
[PATCH 0/6] of_graph_get_remote_endpoint()
Hi Rob Now many driver is getting remote-endpoint by manually, but we should use same method to get same result IMO. Thus this patch adds of_graph_get_remote_endpoint() for this purpose. And use it on several drivers Kuninori Morimoto (6): of_graph: add of_graph_get_remote_endpoint() drm/omapdrm: use of_graph_get_remote_endpoint() drm: rcar-du: use of_graph_get_remote_endpoint() media: ti-vpe: cal: use of_graph_get_remote_endpoint() v4l: of: use of_graph_get_remote_endpoint() omapfb: use of_graph_get_remote_endpoint() drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +- drivers/media/platform/ti-vpe/cal.c | 2 +- drivers/media/v4l2-core/v4l2-of.c | 3 ++- drivers/of/base.c | 18 -- drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 3 ++- include/linux/of_graph.h | 8 7 files changed, 32 insertions(+), 7 deletions(-) -- 1.9.1
Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
On Wed, Jan 18, 2017 at 02:57:27PM -0600, Rob Herring wrote: > On Wed, Jan 18, 2017 at 2:54 PM, Stephen Boyd wrote: > > Quoting Peter Chen (2017-01-17 23:34:32) > >> On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote: > >> > Quoting Peter Chen (2017-01-15 19:45:51) > >> > > > >> > > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need > >> > > to port it to generic phy framework. > >> > > > >> > > >> > Ok. I'll look into that. Can the other patches in this series be picked > >> > up? Otherwise I can resend them all again once I fix the phy_set_mode() > >> > call location and introduce a new phy op. > >> > >> I can pick up chipidea patches after you test the patch I supplied at: > >> > >> [PATCH v6 11/25] usb: chipidea: vbus event may exist before > >> starting > >> gadget > > > > Ok. I've confirmed that this updated patch works fine for me. You can > > have my Tested-by and Reviewed-by there. > > > >> > >> You may ping other maintainers to pick up other patches. > >> > > > > I was hoping you could pick the beginning of the series up until the PHY > > drivers, which can go via Kishon's tree. That would mean applying the > > drivers/of/ part. Rob is that ok? > > Peter, If there's a dependency then please take the patches I've > acked. That's why I acked them. > Ok, I will do it. -- Best Regards, Peter Chen
Re: [PATCH] stmmac: adding EEE to GMAC4
On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto wrote:
> This patch adds Energy Efficiency Ethernet to GMAC4.
>
> Signed-off-by: Joao Pinto
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +
> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59
> +++
> 2 files changed, 71 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> index b524598..73d1dab 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> @@ -90,6 +90,18 @@ enum power_event {
> power_down = 0x0001,
> };
>
> +/* Energy Efficient Ethernet (EEE) for GMAC4
> + *
> + * LPI status, timer and control register offset
> + */
> +#define GMAC4_LPI_CTRL_STATUS 0xd0
> +#define GMAC4_LPI_TIMER_CTRL 0xd4
> +
> +/* LPI control and status defines */
> +#define GMAC4_LPI_CTRL_STATUS_LPITXA BIT(19) /* Enable LPI TX Automate */
> +#define GMAC4_LPI_CTRL_STATUS_PLS BIT(17) /* PHY Link Status */
> +#define GMAC4_LPI_CTRL_STATUS_LPIENBIT(16) /* LPI Enable */
> +
> /* MAC Debug bitmap */
> #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
> #define GMAC_DEBUG_TFCSTS_SHIFT17
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index ecfbf57..02eab79 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info
> *hw,
>GMAC_ADDR_LOW(reg_n));
> }
>
> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
> +{
> + void __iomem *ioaddr = hw->pcsr;
> + u32 value;
> +
> + /* Enable the link status receive on RGMII, SGMII ore SMII
> +* receive path and instruct the transmit to enter in LPI
> +* state.
> +*/
> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> + value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
> +
> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
> +{
> + void __iomem *ioaddr = hw->pcsr;
> + u32 value;
> +
> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> + value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN |
> GMAC4_LPI_CTRL_STATUS_LPITXA);
> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
> +{
> + void __iomem *ioaddr = hw->pcsr;
> + u32 value;
> +
> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +
> + if (link)
> + value |= GMAC4_LPI_CTRL_STATUS_PLS;
> + else
> + value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
> +
> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
> +{
> + void __iomem *ioaddr = hw->pcsr;
> + int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);
If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
should AND 0x3ff.
int value = ((tw & 0x)) | ((ls & 0x3ff) << 16);
> +
> + /* Program the timers in the LPI timer control register:
> +* LS: minimum time (ms) for which the link
> +* status from PHY should be ok before transmitting
> +* the LPI pattern.
> +* TW: minimum time (us) for which the core waits
> +* after it has stopped transmitting the LPI pattern.
> +*/
> + writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
> +}
> +
> static void dwmac4_set_filter(struct mac_device_info *hw,
> struct net_device *dev)
> {
> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
> .pmt = dwmac4_pmt,
> .set_umac_addr = dwmac4_set_umac_addr,
> .get_umac_addr = dwmac4_get_umac_addr,
> + .set_eee_mode = dwmac4_set_eee_mode,
> + .reset_eee_mode = dwmac4_reset_eee_mode,
> + .set_eee_timer = dwmac4_set_eee_timer,
> + .set_eee_pls = dwmac4_set_eee_pls,
> .pcs_ctrl_ane = dwmac4_ctrl_ane,
> .pcs_rane = dwmac4_rane,
> .pcs_get_adv_lp = dwmac4_get_adv_lp,
> --
> 2.9.3
>
--
wwr
Rayagond
Re: How to improve PCI bug tracking?
On Wed, Jan 18, 2017 at 06:29:15PM -0500, Sinan Kaya wrote: > On 1/18/2017 5:53 PM, Bjorn Helgaas wrote: > > I want to improve PCI bug tracking. It feels like our bugs don't get > > the attention they need, and I'm soliciting ideas for how to improve > > this. > > > > Current situation: > > > > - People often report bugs via email to linux-pci. I think this > > is good because everybody can see it. > > > > - Even after an email report, I often request a bugzilla because > > (1) it helps keep things from being forgotten, (2) it's a > > convenient place to store bulky data, and (3) I like to have a > > bugzilla URL to include in the changelog of a patch that fixes the > > bug. > > > > - Sometimes people open a bugzilla directly. I get email about > > these (along with one or two other people), but this is sort of a > > problem because linux-pci never sees it, sometimes I miss it, and > > things tend to languish. > > > > - Discussion on a bugzilla is only seen by people listed in the > > bugzilla, not on linux-pci. > > > > I'm contemplating changing this so the bugzilla mail would also go to > > linux-pci. > > I have seen this happening on linux-scsi. > > http://www.spinics.net/lists/linux-scsi/msg103272.html Same for dri-devel@ / nouv...@lists.freedesktop.org. Go for it. Lukas
Re: [PATCH perf/core 1/6] tools lib bpf: Fix map offsets in relocation
On 2017/1/19 7:57, Joe Stringer wrote:
Commit 4708bbda5cb2 ("tools lib bpf: Fix maps resolution") attempted to
fix map resolution by identifying the number of symbols that point to
maps, and using this number to resolve each of the maps.
However, during relocation the original definition of the map size was
still in use.
Oops... Didn't realize that.
For up to two maps, the calculation was correct if there
was a small difference in size between the map definition in libbpf and
the one that the client library uses. However if the difference was
large, particularly if more than two maps were used in the BPF program,
the relocation would fail.
For example, when using a map definition with size 28, with three maps,
map relocation would count
(sym_offset / sizeof(struct bpf_map_def) => map_idx)
(0 / 16 => 0), ie map_idx = 0
(28 / 16 => 1), ie map_idx = 1
(56 / 16 => 3), ie map_idx = 3
So, libbpf reports:
libbpf: bpf relocation: map_idx 3 large than 2
Understand.
Fix map relocation by tracking the size of the map definition during
map counting, then reuse this instead of the size of the libbpf map
structure.
Then we add a restriction that map size is fixed
in one object, but we don't have to. During relocating,
we can get exact map positioning information from
sym.st_value. I think finding a map with exact offset
from the map array would be better.
I'll write a patch to replace this one.
Thank you.
With this patch applied, libbpf will accept such ELFs.
Fixes: 4708bbda5cb2 ("tools lib bpf: Fix maps resolution")
Signed-off-by: Joe Stringer
---
tools/lib/bpf/libbpf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 84e6b35da4bd..350ee4c59f85 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -201,6 +201,7 @@ struct bpf_object {
size_t nr_programs;
struct bpf_map *maps;
size_t nr_maps;
+ size_t map_len;
bool loaded;
@@ -379,6 +380,7 @@ static struct bpf_object *bpf_object__new(const char *path,
obj->efile.maps_shndx = -1;
obj->loaded = false;
+ obj->map_len = sizeof(struct bpf_map_def);
INIT_LIST_HEAD(&obj->list);
list_add(&obj->list, &bpf_objects_list);
@@ -602,6 +604,7 @@ bpf_object__init_maps(struct bpf_object *obj)
return -ENOMEM;
}
obj->nr_maps = nr_maps;
+ obj->map_len = data->d_size / nr_maps;
/*
* fill all fd with -1 so won't close incorrect
@@ -829,7 +832,7 @@ bpf_program__collect_reloc(struct bpf_program *prog,
return -LIBBPF_ERRNO__RELOC;
}
- map_idx = sym.st_value / sizeof(struct bpf_map_def);
+ map_idx = sym.st_value / prog->obj->map_len;
if (map_idx >= nr_maps) {
pr_warning("bpf relocation: map_idx %d large than %d\n",
(int)map_idx, (int)nr_maps - 1);
linux-next: Tree for Jan 19
Hi all, Changes since 20170118: The audit tree gained a conflict against Linus' tree. The tip tree gained a conflict against the security tree. The rcu tree gained a semantic conflict against the net-next tree for which I applied a merge fix patch. I dropped 4 patches from the akpm tree that turned up in the tip tree. Non-merge commits (relative to Linus' tree): 3931 4740 files changed, 146960 insertions(+), 87918 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 and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 251 trees (counting Linus' and 36 trees of bug fix patches pending for the current merge release). 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 (fa19a769f82f Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP defines before declaring the functions) Merging arc-current/for-curr (eb1357d942e5 ARC: module: Fix !CONFIG_ARC_DW2_UNWIND builds) Merging arm-current/fixes (90f92c631b21 ARM: 8613/1: Fix the uaccess crash on PB11MPCore) Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in atari_get_hardware_list()) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (27593d72c4ad powerpc/perf: Use MSR to report privilege level on P9 DD1) Merging sparc/master (5d0e7705774d sparc: Fixed typo in sstate.c. Replaced panicing with panicking) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (d407bd25a204 bpf: don't trigger OOM killer under pressure with map alloc) Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in mpls-sysctl) Merging netfilter/master (3fd0b634de7d netfilter: ipt_CLUSTERIP: fix build error without procfs) Merging ipvs/master (045169816b31 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging wireless-drivers/master (7195439d1d71 Revert "bcma: init serial console directly from ChipCommon code") Merging mac80211/master (dbef53621116 mac80211: prevent skb/txq mismatch) Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (ea2a7fb12093 Revert "PCI: Add runtime PM support for PCIe ports") Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4) Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4) Merging usb.current/usb-linus (833674a45ec7 Merge tag 'fixes-for-v4.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix Wmaybe-uninitialized warning) Merging usb-serial-fixes/usb-linus (49def1853334 Linux 4.10-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1) Merging staging.current/staging-linus (a121103c9228 Linux 4.10-rc3) Merging char-misc.current/char-misc-linus (49def1853334 Linux 4.10-rc4) Merging input-current/for-linus (1c3415a06b10 Input: elants_i2c -
Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role
Hi John, On 19 January 2017 at 11:31, John Youn wrote: > On 1/18/2017 7:12 PM, Baolin Wang wrote: >> Hi John, >> >> On 19 January 2017 at 09:33, John Youn wrote: >>> On 1/16/2017 2:38 AM, Felipe Balbi wrote: Hi, John Youn writes: >> Baolin Wang writes: Baolin Wang writes: > When dwc3 controller acts as host role with attaching slow speed > device > (like mouse or keypad). Then if we plugged out the slow speed device, > it will timeout to run the deconfiguration endpoint command to drop > the > endpoint's resources. Some xHCI command timeout log as below when > disconnecting one slow device: > > [ 99.807739] c0 xhci-hcd.0.auto: Port Status Change Event for port 1 > [ 99.814699] c0 xhci-hcd.0.auto: resume root hub > [ 99.819992] c0 xhci-hcd.0.auto: handle_port_status: starting port > polling. > [ 99.827808] c0 xhci-hcd.0.auto: get port status, actual port 0 > status > = 0x202a0 > [ 99.835903] c0 xhci-hcd.0.auto: Get port status returned 0x10100 > [ 99.850052] c0 xhci-hcd.0.auto: clear port connect change, actual > port 0 status = 0x2a0 > [ 99.859313] c0 xhci-hcd.0.auto: Cancel URB ffc01ed6cd00, dev 1, > ep 0x81, starting at offset > 0xc406d210 > [ 99.869645] c0 xhci-hcd.0.auto: // Ding dong! > [ 99.874776] c0 xhci-hcd.0.auto: Stopped on Transfer TRB > [ 99.880713] c0 xhci-hcd.0.auto: Removing canceled TD starting at > 0xc406d210 (dma). > [ 99.889012] c0 xhci-hcd.0.auto: Finding endpoint context > [ 99.895069] c0 xhci-hcd.0.auto: Cycle state = 0x1 > [ 99.900519] c0 xhci-hcd.0.auto: New dequeue segment = > ffc1112f0880 (virtual) > [ 99.908655] c0 xhci-hcd.0.auto: New dequeue pointer = 0xc406d220 > (DMA) > [ 99.915927] c0 xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg = > ffc1112f0880 (0xc406d000 dma), > new deq ptr = ff8002175220 > (0xc406d220 dma), new cycle = 1 > [ 99.931242] c0 xhci-hcd.0.auto: // Ding dong! > [ 99.936360] c0 xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd, > deq = @c406d220 > [ 99.944458] c0 xhci-hcd.0.auto: xhci_hub_status_data: stopping port > polling. > [ 100.047619] c0 xhci-hcd.0.auto: xhci_drop_endpoint called for udev > ffc01ae08800 > [ 100.057002] c0 xhci-hcd.0.auto: drop ep 0x81, slot id 1, new drop > flags = 0x8, new add flags = 0x0 > [ 100.067878] c0 xhci-hcd.0.auto: xhci_check_bandwidth called for > udev > ffc01ae08800 > [ 100.076868] c0 xhci-hcd.0.auto: New Input Control Context: > > .. > > [ 100.427252] c0 xhci-hcd.0.auto: // Ding dong! > [ 105.430728] c0 xhci-hcd.0.auto: Command timeout > [ 105.436029] c0 xhci-hcd.0.auto: Abort command ring > [ 113.558223] c0 xhci-hcd.0.auto: Command completion event does not > match > command > [ 113.569778] c0 xhci-hcd.0.auto: Timeout while waiting for configure > endpoint command > > The reason is it will suspend USB phy to disable phy clock when > disconnecting the slow USB decice, that will hang on the xHCI commands > executing which depends on the phy clock. > > Thus we should disable USB2.0 phy suspend feature when dwc3 acts as > host > role. > > Signed-off-by: Baolin Wang > --- > drivers/usb/dwc3/core.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index 9a4a5e4..0b646cf 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -565,6 +565,20 @@ static int dwc3_phy_setup(struct dwc3 *dwc) > if (dwc->revision > DWC3_REVISION_194A) > reg |= DWC3_GUSB2PHYCFG_SUSPHY; > > + /* > + * When dwc3 controller acts as host role with attaching one > slow speed > + * device (like mouse or keypad). Then if we plugged out the > slow speed > + * device, it will timeout to run the deconfigurat
Re: [PATCH v11 12/12] drm/mediatek: add support for Mediatek SoC MT2701
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen
Acked-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 7 +++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29
> +
> drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 6 ++
> 7 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 4552178..a14d7d6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -35,6 +35,7 @@
> #define DISP_REG_OVL_PITCH(n)(0x0044 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_CTRL(n)(0x00c0 + 0x20 * (n))
> #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> +#define DISP_REG_OVL_ADDR_MT2701 0x0040
> #define DISP_REG_OVL_ADDR_MT8173 0x0f40
> #define DISP_REG_OVL_ADDR(ovl, n)((ovl)->data->addr + 0x20 * (n))
>
> @@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT2701,
> + .fmt_rgb565_is_0 = false,
> +};
> +
> static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> .addr = DISP_REG_OVL_ADDR_MT8173,
> .fmt_rgb565_is_0 = true,
> };
>
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> + .data = &mt2701_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index e5e5318..b68a513 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
> + .fifo_size = SZ_4K,
> +};
> +
> static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
> .fifo_size = SZ_8K,
> };
>
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> + .data = &mt2701_rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = &mt8173_rdma_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a9b209c..8130f3d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -60,6 +60,13 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
> #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>
> +#define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLSBIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
> +
> #define MUTEX_SOF_SINGLE_MODE0
> #define MUTEX_SOF_DSI0 1
> #define MUTEX_SOF_DSI1 2
> @@ -92,6 +99,15 @@ struct mtk_ddp {
> const unsigned int *mutex_mod;
> };
>
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id ddp_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> {},
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index f6e853a..8b52416 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm
Re: [PATCH 0/6 v4] adv7511 EDID probing improvements
On 01/19/2017 04:34 AM, Laurent Pinchart wrote: Hi John, Thank you for the patches. On Monday 16 Jan 2017 16:52:46 John Stultz wrote: Wanted to re-send out v4 of this patch set, integrating some changes suggested by Laurent, for consideration for merging for v4.11 The first three patches are fixups that are hopefully straight forward, integrating feedback I got from Laurant, with minimal change from the previous versions. The last three patches try to clean up and rework the EDID probing code, to avoid issues seen on HiKey. I've reworked these more significantly since v3 to address feedback from Laurent. Thoughts and feedback would be appreciated! For the whole series, Tested-by: Laurent Pinchart Queued to drm-misc-next. Updated the commit messages for patches 5 and 6 as suggested by Laurent. Thanks, Archit New in v4: * Tweaked connector.status assignment to avoid race, as suggested by Laurent * Reworked the __adv7511_power_on helpers to avoid calling regcache_sync in the EDID probe path * Added new patch to set EDID_I2C_ADDR register before doing EDID read. Cc: David Airlie Cc: Archit Taneja Cc: Wolfram Sang Cc: Lars-Peter Clausen Cc: Laurent Pinchart Cc: dri-de...@lists.freedesktop.org Archit Taneja (1): drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection John Stultz (5): drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event() drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID drm/bridge: adv7511: Re-write the i2c address before EDID probing drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 67 2 files changed, 51 insertions(+), 18 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy
On 01/19/2017 06:10 AM, Stephen Boyd wrote: On 01/18, Bjorn Andersson wrote: On Tue 17 Jan 22:54 PST 2017, Vivek Gautam wrote: On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote: On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote: [..] + reset-names = "phy", "common", "cfg", + "lane0", "lane1", "lane2"; Each lane has a separate clock, separate reset.. why not create sub-nodes for each lane? Yes, each lane has separate pipe clock and resets. I can have a binding such as written below. +1 Does it makes sense to pull in the tx, rx and pcs offsets as well to the child node, and iomap the entire address space of the phy ? Note that you don't have to follow the same structure in your device driver as you describe your hardware in devicetree. I would suggest that you replace the lane-offset and various lane specific resources with subnodes, but keep the driver "as is". Didn't we already move away from subnodes for lanes in an earlier revision of these patches? I seem to recall we did that because lanes are not devices and the whole "phy as a bus" concept not making sense. Yea, we started out without having any sub-nodes and we argued that we don't require them since the qmp device is represented by the qmp node itself. The lanes otoh are representative of gen_phys and related properties. In the driver - "struct qmp_phy " represents the lanes and holds "struct phy", "struct qcom_qmp" represents the qmp block as a whole and holds "struct device" Does this make lanes qualify to be childs of qmp ? "phy as a bus" (just trying to understand here) - let's say a usb phy controller has one HSIC phy port and one USB2 phy port. So, should this phy controller be a bus providing two ports (and so we will have couple of child nodes to the phy controller) ? Regards Vivek -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2] PCI: pciehp: Optimize PCIe root resume time
On Thu, Jan 19, 2017 at 02:57:26AM +, Shankar, Vaibhav wrote:
> > From: Lukas Wunner [mailto:lu...@wunner.de]
> > Sent: Tuesday, January 17, 2017 9:14 PM
> > On Wed, Jan 18, 2017 at 01:32:13AM +, Shankar, Vaibhav wrote:
> > > > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > > > Sent: Wednesday, January 11, 2017 10:37 AM On Mon, Dec 12, 2016 at
> > > > 04:32:25PM -0800, Vaibhav Shankar wrote:
> > > > > On Apollolake platforms, PCIe rootport takes a long time to resume
> > > > > from S3. With 100ms delay before read pci conf, rootport takes
> > > > > ~200ms during resume.
> > > > >
> > > > > commit 2f5d8e4ff947 ("PCI: pciehp: replace unconditional sleep
> > > > > with config space access check") is the one that added the 100ms
> > > > > delay before reading pci conf.
> > > > >
> > > > > This patch includes a condition check for 100ms dealy before
> > > > > reading PCIe conf. This delay in included only when PCIe
> > > > > max_bus_speed > 5.0 GT/s. Root port takes ~16ms during resume.
> > > >
> > > > This patch reduces the delay by 100ms for devices that don't support
> > > > 5.0 GT/s. Please include references to the specs about the
> > > > necessary delays and explain why we don't need this 100ms delay.
> > > >
> > > > Presumably there's something in the spec about needing extra delay
> > > > when supporting 5.0 GT/s.
> > > >
> > > > This is generic code, so we can't make changes based on specific
> > > > devices like Apollolake. We have to make the code follow the spec
> > > > so it works for everybody.
> > > >
> > > > > With 100ms delay:
> > > > > [ 155.102713] calling :00:14.0+ @ 70, parent: pci:00, cb:
> > > > > pci_pm_resume_noirq [ 155.119337] call :00:14.0+ returned 0
> > > > > after
> > > > > 16231 usecs [ 155.119467] calling :01:00.0+ @ 5845, parent:
> > > > > :00:14.0, cb: pci_pm_resume_noirq [ 155.321670] call
> > > > > :00:14.0+ returned 0 after 185327 usecs [ 155.321743] calling
> > > > > :01:00.0+ @ 5849, parent: :00:14.0, cb: pci_pm_resume
> > > > >
> > > > > With Condition check:
> > > > > [ 36.624709] calling :00:14.0+ @ 4434, parent: pci:00, cb:
> > > > pci_pm_resume_noirq
> > > > > [ 36.641367] call :00:14.0+ returned 0 after 16263 usecs
> > > > > [ 36.652458] calling :00:14.0+ @ 4443, parent: pci:00, cb:
> > > > pci_pm_resume
> > > > > [ 36.652673] call :00:14.0+ returned 0 after 208 usecs
> > > > > [ 36.652863] calling :01:00.0+ @ 4442, parent: :00:14.0,
> > > > > cb:
> > > > pci_pm_resume
> > > > >
> > > > > Signed-off-by: Vaibhav Shankar
> > > > > ---
> > > > > changes in v2:
> > > > > - Modify patch description.
> > > > > - Add condition check for 100ms delay before read pci conf as
> > > > > suggested by Yinghai.
> > > > >
> > > > > drivers/pci/hotplug/pciehp_hpc.c | 11 +--
> > > > > 1 file changed, 9 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> > > > > b/drivers/pci/hotplug/pciehp_hpc.c
> > > > > index b57fc6d..2b10e5f 100644
> > > > > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > > > > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > > > > @@ -311,8 +311,15 @@ int pciehp_check_link_status(struct
> > > > > controller
> > > > *ctrl)
> > > > > else
> > > > > msleep(1000);
> > > > >
> > > > > - /* wait 100ms before read pci conf, and try in 1s */
> > > > > - msleep(100);
> > > > > + /*
> > > > > + * If the port supports Link speeds greater than 5.0 GT/s, we
> > > > > + * must wait for 100 ms after Link training completes before
> > > > > + * sending configuration request.
> > > > > + */
> > > > > + if (ctrl->pcie->port->subordinate->max_bus_speed >
> > > > PCIE_SPEED_5_0GT)
> > > > > + msleep(100);
> > > > > +
> > > > > + /* try in 1s */
> > > > > found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
> > > > > PCI_DEVFN(0, 0));
> > > > >
> > >
> > > Please find the details from regarding delays from PCIe spec 3.0:
> > >
> > > 1) With a Downstream Port that does not support Link speeds greater
> > > than 5.0 GT/s, software must wait a minimum of 100 ms before sending
> > > a Configuration Request to the device immediately below that Port.
> > >
> > > 2) With a Downstream Port that supports Link speeds greater than 5.0
> > > GT/s, software must wait a minimum of 100 ms after Link training
> > > completes before sending a Configuration Request to the device
> > > immediately below that Port. Software can determine when Link training
> > > completes by polling the Data Link Layer Link Active bit or by setting up
> > > an
> > associated interrupt (see Section 6.7.3.3).
> > >
> > > 3) A system must guarantee that all components intended to be software
> > > visible at boot time are ready to receive Configuration Requests
> > > within the applicable minimum period based on the end of Conventio
Re: [PATCH 00/33] Input: Automated coccinelle cleanup
On Wed, 2017-01-18 at 21:04 -0800, Guenter Roeck wrote: > On 01/18/2017 05:42 PM, Joe Perches wrote: > > On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote: > > > The conversion was done automatically with coccinelle using several > > > semantic > > > patches. The semantic patches and the scripts used to generate this commit > > > log are available at https://github.com/groeck/coccinelle-patches. > > > > It'd be better to include the script in this 0/n patch > > so that if github entry changes, the 0/n patch is useful. > > > For this set it would have been possible, though even the rules used here add > up to more than 1,000 lines. How many errors do you think are in the script? 1000+ lines, likely there 10+ errors/defects.
Re: [PATCH 00/33] Input: Automated coccinelle cleanup
On 01/18/2017 05:42 PM, Joe Perches wrote: On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote: The conversion was done automatically with coccinelle using several semantic patches. The semantic patches and the scripts used to generate this commit log are available at https://github.com/groeck/coccinelle-patches. It'd be better to include the script in this 0/n patch so that if github entry changes, the 0/n patch is useful. For this set it would have been possible, though even the rules used here add up to more than 1,000 lines. The underlying larger set (the one I am using to generate devm transformations) currently has ~5,000 lines of coccinelle rules. Are you sure you want to see that in an e-mail ? It might make more sense if I add the reference SHA from the repository. Thanks, Guenter
Re: [PATCH 2/5] dmaengine: Add support for custom data mapping
On Mon, Jan 02, 2017 at 10:12:33AM -0600, Andy Gross wrote:
> On Mon, Jan 02, 2017 at 07:55:37PM +0530, Abhishek Sahu wrote:
> > >>> So a couple of thoughts on how to deal with this:
> > >>>
> > >>> 1) Define a virtual channel for the command descriptors vs a normal
> > >>> DMA
> > >>> transaction. This lets you use the same hardware channel, but lets
> > >>> you discern
> > >>> which descriptor format you need to use. The only issue I see with
> > >>> this is the
> > >>> required change in device tree binding to target the right type of
> > >>> channel (cmd
> > >>> vs normal).
> > >>
> > >>Or mark the descriptor is cmd and write accordingly...
> > >
> > >The only issue i see with that is knowing how much to pre-allocate
> > >during
> > >the
> > >prep call. The flag set API would be called on the allocated tx
> > >descriptor. So
> > >you'd have to know up front and be able to specify it.
> > >
> > >>
> > >>>
> > >>> 2) Provide an API to set flags for the descriptor on a whole
> > >>> descriptor basis.
> > >>>
> > >>> 3) If you have a set of transactions described by an sgl that has
> > >>> disparate use
> > >>> of flags, you split the list and use a separate transaction. In
> > >>> other words, we
> > >>> need to enforce that the flag set API will be applied to all
> > >>> descriptors
> > >>> described by an sgl. This means that the whole transaction may be
> > >>> comprised of
> > >>> multiple async TX descriptors.
> >
> > Each async TX descriptor will generate the BAM interrupt so we are
> > deviating
> > from main purpose of DMA where ideally we should get the interrupt at
> > the
> > end
> > of transfer. This is the main reason for going for this patch.
> > >>>
> > >>>If the client queues 1 descriptor or 5 descriptors, it doesn't matter
> > >>>that
> > >>>much.
> > >>>The client knows when it is done by waiting for the descriptors to
> > >>>complete. It
> > >>>is less efficient than grouping them all, but it should still work.
> > >>>
> > >>Yes. client will wait for final descriptor completion. But these
> > >>interrupts
> > >>will be overhead for CPU. For 1-2 page it won't matter much I guess it
> > >>will
> > >>be
> > >>significant for complete chip read/write(during boot and FS i.e JFFS
> > >>operations).
> >
> > With the submitted patch, only 1 interrupt per channel is required for
> > complete NAND page and it solves the setting of BAM specific flags also.
> > Only issue with this patch is adding new API in DMA framework itself.
> > But
> > this API can be used by other DMA engines in future for which mapping
> > cannot
> > be done with available APIs and if this mapping is vendor specific.
> > >>>
> > >>>I guess the key point in all of this is that the DMA operation being done
> > >>>is not
> > >>>a normal data flow to/from the device. It's direct remote register
> > >>>access
> > >>>to
> > >>>the device using address information contained in the sgl. And you are
> > >>>collating the standard data access along with the special command access
> > >>>in the
> > >>>same API call.
> > >>Yes. Normally DMA engine (QCA ADM DMA engine also) allows to read/write
> > >>memory mapped
> > >>registers just like data. But BAM is different (Since it is not a global
> > >>DMA
> > >>Engine
> > >>and coupled with peripheral). Also, this different flag requirement is
> > >>not
> > >>just
> > >>for command descriptors but for data descriptors also.
> > >>
> > >>BAM data access and command access differs only with flag and register
> > >>read/write
> > >>list. The register read and write list will be simply array of
> > >>struct bam_cmd_element added in patch
> > >>struct bam_cmd_element {
> > >>__le32 addr:24;
> > >>__le32 command:8;
> > >>__le32 data;
> > >>__le32 mask;
> > >>__le32 reserved;
> > >>};
> > >>
> > >>The address and size of the array will be passed in data and size field
> > >>of
> > >>SGL.
> > >>If we want to form the SGL for mentioned list then we will have SGL of
> > >>size
> > >>15
> > >>with just one descriptor.
> > >>
> > >>Now we require different flag for each SG entry. currently SG does not
> > >>have
> > >>flag parameter and we can't add flag parameter just for our requirement
> > >>in
> > >>generic SG. So we have added the custom mapping function and passed
> > >>modified
> > >>SG
> > >>as parameter which is generic SG and flag.
> > >
> > >I really think that we need some additional API that allows for the flag
> > >munging
> > >for the descriptors instead of overriding the prep_slave_sg. We already
> > >needed
> > >to change the way the flags are passed anyway. And instead of building up
> > >a
> > >special sg list, the API should take a structure that has a 1:1 mapping of
> > >the
> > >flags to the descriptors. And you would ca
Re: [PATCH 13/33] Input: bfin_rotary - Use 'dev' instead of dereferencing it and other changes
On Wed, 2017-01-18 at 12:35 -0800, Guenter Roeck wrote:
> On Wed, Jan 18, 2017 at 11:39:52AM -0800, Dmitry Torokhov wrote:
> > On Wed, Jan 18, 2017 at 09:46:34AM -0800, Guenter Roeck wrote:
[]
> > > diff --git a/drivers/input/misc/bfin_rotary.c
> > > b/drivers/input/misc/bfin_rotary.c
[]
> > > @@ -141,25 +141,23 @@ static int bfin_rotary_probe(struct platform_device
> > > *pdev)
> > >
> > > /* Basic validation */
> > > if ((pdata->rotary_up_key && !pdata->rotary_down_key) ||
> > > - (!pdata->rotary_up_key && pdata->rotary_down_key)) {
> > > + (!pdata->rotary_up_key && pdata->rotary_down_key))
maybe just use ^
if (!pdata->rotary_up_key ^ !pdata->rotary_down_key)
Re: [PATCH net-next] macb: Common code to enable ptp support for SAMA5Dx platforms.
On Wed, Jan 18, 2017 at 11:02 PM, Nicolas Ferre wrote: > Le 18/01/2017 à 09:57, Andrei Pistirica a écrit : >> This patch does the following: >> - add GEM-PTP interface >> - registers and bitfields for TSU are named according to SAMA5Dx data sheet >> - PTP support based on platform capability > > The $subject will certainly never match reality, sadly "enable ptp > support for SAMA5Dx platforms". So, you'd better change it. > (no "." at the end BTW). > >> Signed-off-by: Andrei Pistirica >> --- >> This is just the common code for GEM-PTP support. Code is based on the >> comments >> related to the following patch series: >> - [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM. >> - [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx >> platforms. >> >> Note: Patch on net-next: January 18. >> >> Rafal/Harini, you can continue the work for GME-GXL. Thanks Andrei. > > Otherwise, I'm okay with the rest. > > I suggest to people that will keep the ball rolling on this topic to > take advantage of the chunks of code that Andrei developed with the help > of Richard and the best practices discussed. I think particularly, if it > makes sense with HW, about: > - gem_ptp_do_[rt]xstamp(bp, skb) dereference scheme > - gem_ptp_adjfine() rationale > - gem_get_ptp_peer() if needed > Sure, will patch on top of this. Regards, Harini > Regards, > -- > Nicolas Ferre
Re: [RFC PATCH v3] crypto: Add IV generation algorithms
Hi Gilad, On 18 January 2017 at 20:51, Gilad Ben-Yossef wrote: > I have some review comments and a bug report - Thank you very much for testing this on ARM and for the comments. > I'm pretty sure this needs to be > > n2 = bio_segments(ctx->bio_out); Yes you are right, that was a typo :) >> + >> + rinfo.is_write = bio_data_dir(ctx->bio_in) == WRITE; > > Please consider wrapping the above boolean expression in parenthesis. Well, I can do that to enhance the clarity. >> + rinfo.iv_sector = ctx->cc_sector; >> + rinfo.nents = nents; >> + rinfo.iv = iv; >> + >> + skcipher_request_set_crypt(req, dmreq->sg_in, dmreq->sg_out, > > Also, where do the scatterlist src2 and dst2 that you use > sg_set_page() get sg_init_table() called on? > I couldn't figure it out... Thank you pointing this out. I missed out to add sg_init_table(src2, 1) and sg_init_table(dst2, 1), but sg_set_page is used in geniv_iter_block. This is probably the reason for the panic on ARM platform. However it ran fine under qemu-x86. May be I should setup an arm platform too for testing. Regards, Binoy
Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
Andreas Färber writes:
> Am 19.01.2017 um 01:20 schrieb Andreas Färber:
>> Hi,
>>
>> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds these reserved zones.
>>>
>>> Without such reserved memory zones, running the following stress command :
>>> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
>>> multiple times:
>>>
>>> Could lead to the following kernel crashes :
>>> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf00
>>> -- SError
>>> ...
>>> [ 47.058536] Internal error: Attempting to execute userspace memory:
>>> 860f [#3] PREEMPT SMP
>>> ...
>>> Instead of the OOM killer.
>>>
>>
>> I miss a Fixes: or Cc: here for the backport you desired. To have it
>> fixed back to my very introduction:
>>
>> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>>
>> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
>> transition for 4.9 down to 4.6, which seems fairly straightforward.
>>
>>> Signed-off-by: Neil Armstrong
>>> ---
>>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++
>>> 1 file changed, 18 insertions(+)
>>>
>>> Changes since v4 at [5]:
>>> - Move start of ddr memory to reserved-memory node
>>> - Drop memory node move
>>> - Fix typo in sizes
>>>
>>> Changes since resent v2 at [4]:
>>> - Fix invalid comment of useable memory attributes
>>>
>>> Changes since original v2 at [3]:
>>> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>>>
>>> Changes since v2 at [2]:
>>> - Moved all memory node out of dtsi
>>> - Added comment about useable memory
>>> - Fixed comment about secmon reserved zone
>>>
>>> Changes since v1 at [1] :
>>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>>> - only kept secmon memory zone
>>>
>>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstr...@baylibre.com
>>> [2]
>>> http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstr...@baylibre.com
>>> [3]
>>> http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstr...@baylibre.com
>>> [4]
>>> http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstr...@baylibre.com
>>> [5]
>>> http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstr...@baylibre.com
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> index eada0b5..63d52b7 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> @@ -55,6 +55,24 @@
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>>
>>> + reserved-memory {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + /* 16 MiB reserved for Hardware ROM Firmware */
>>> + hwrom: hwrom {
>>
>> Both sub-nodes get a label that is unused, but reserved-memory itself
>> does not (my v4 remark). Intentional?
>>
>>> + reg = <0x0 0x0 0x0 0x100>;
>>> + no-map;
>>> + };
>>> +
>>> + /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
>>> + secmon: secmon {
>>
>> I note that this .dtsi further down has a node /firmware/secure-monitor
>> with label sm.
>> a) Is there any naming convention such as secmon_mem to adopt here to
>> avoid mixups with sm?
>> b) Should this secmon node be referenced in the secure-monitor node via
>> memory-node = <&secmon>; to model their connection, thereby giving the
>> label a use? Or should we maybe merge the two nodes by moving the
>> compatible string here?
>>
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> Answering my own question: the example labels use _reserved suffix.
>
>>> + reg = <0x0 0x1000 0x0 0x20>;
>
> And since we use a reg property here, the node name should get a unit
> address to avoid future dtc warnings/errors. Ditto for hwrom.
OK, I added Fixes:, your Reviewed-by, added the _reserved suffix and
unit address and applied to v4.10/fixes.
Update patch below for reference.
Other cleanups/fixups (like adding a phandle from secure monitor) can be
done as add-ons, as they are not strictly related to this fix.
Kevin
>From ecb88f3001ed9ee8c53450d971de8c18bcbf7925 Mon Sep 17 00:00:00 2001
From: Neil Armstrong
Date: Wed, 18 Jan 2017 17:50:45 +0100
Subject: [PATCH] ARM64: dts: meson-gx: Add firmware reserved memory zones
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds these reserved zones.
Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:
Could lead to the following kernel crashes :
[ 46.937975] Bad mode in Error handl
Re: [PATCH 4/6] PM / domain: Register for PM QOS performance notifier
On 03-01-17, 16:36, Viresh Kumar wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> This patch registers the power domain framework for PM QOS performance
> notifier in order to manage performance state of power domains.
>
> This also allows the power domain drivers to implement a
> ->set_performance_state() callback, which will be called by the power
> domain core from the notifier routine.
Rajendra helped me testing this stuff on his Qualcomm board and this patch has
received some updates to support the hierarchy of power domains, i.e. subdomains
withing power domains. Below is the new patch which worked for him.
--
viresh
-8<-
From: Viresh Kumar
Date: Wed, 23 Nov 2016 11:00:41 +0530
Subject: [PATCH] PM / domain: Register for PM QOS performance notifier
Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.
This patch registers the power domain framework for PM QOS performance
notifier in order to manage performance state of power domains.
This also allows the power domain drivers to implement a
->set_performance_state() callback, which will be called by the power
domain core from the notifier routine.
Signed-off-by: Viresh Kumar
---
drivers/base/power/domain.c | 99 -
include/linux/pm_domain.h | 5 +++
2 files changed, 102 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 12f16d9b6b55..12ec1f8c42ed 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -367,6 +367,88 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block
*nb,
return NOTIFY_DONE;
}
+static void update_domain_performance_state(struct generic_pm_domain *genpd,
+ int depth)
+{
+ struct generic_pm_domain_data *pd_data;
+ struct generic_pm_domain *subdomain;
+ struct pm_domain_data *pdd;
+ unsigned int state = 0;
+ struct gpd_link *link;
+
+ /* Traverse all devices within the domain */
+ list_for_each_entry(pdd, &genpd->dev_list, list_node) {
+ pd_data = to_gpd_data(pdd);
+
+ if (pd_data->performance_state > state)
+ state = pd_data->performance_state;
+ }
+
+ /* Traverse all subdomains within the domain */
+ list_for_each_entry(link, &genpd->master_links, master_node) {
+ subdomain = link->slave;
+
+ if (subdomain->performance_state > state)
+ state = subdomain->performance_state;
+ }
+
+ if (genpd->performance_state == state)
+ return;
+
+ genpd->performance_state = state;
+
+ if (genpd->set_performance_state) {
+ genpd->set_performance_state(genpd, state);
+ return;
+ }
+
+ /* Propagate only if this domain has a single parent */
+ if (list_is_singular(&genpd->slave_links)) {
+ /* Performance levels are managed by parent power domain */
+
+ struct generic_pm_domain *master;
+
+ link = list_first_entry(&genpd->slave_links, struct gpd_link,
slave_node);
+ master = link->master;
+
+ genpd_lock_nested(master, depth + 1);
+ update_domain_performance_state(master, depth + 1);
+ genpd_unlock(master);
+ }
+}
+
+static int genpd_dev_pm_qos_perf_notifier(struct notifier_block *nb,
+ unsigned long val, void *ptr)
+{
+ struct generic_pm_domain_data *gpd_data;
+ struct generic_pm_domain *genpd = ERR_PTR(-ENODATA);
+ struct pm_domain_data *pdd;
+ struct device *dev;
+
+ gpd_data = container_of(nb, struct generic_pm_domain_data, perf_nb);
+ dev = gpd_data->base.dev;
+
+ spin_lock_irq(&dev->power.lock);
+
+ pdd = dev->power.subsys_data ?
+ dev->power.subsys_data->domain_data : NULL;
+
+ if (pdd && pdd->dev)
+ genpd = dev_to_genpd(dev);
+
+ spin_unlock_irq(&dev->power.lock);
+
+ if (IS_ERR(genpd))
+ return NOTIFY_DONE;
+
+ genpd_lock(genpd);
+ gpd_data->performance_state = val;
+ update_domain_performance_state(genpd, 0);
+ genpd_unlock(genpd);
+
+ return NOTIFY_DONE;
+}
+
/**
* genpd_poweroff - Remove power from a given PM domain.
* @genpd: PM domain to power down.
@@ -578,6 +660,7 @@ static int genpd_runtime_suspend(struct device *dev)
return 0;
genpd_lock(genpd);
+
genpd_poweroff(genpd, false);
genpd_unlock(genpd);
@
Re: linux-next: manual merge of the audit tree with Linus' tree
On 2017-01-19 13:51, Stephen Rothwell wrote:
> Hi Paul,
Hi Stephen,
> Today's linux-next merge of the audit tree got a conflict in:
>
> include/uapi/linux/audit.h
>
> between commits:
>
> 7ff89ac608d9 ("audit: add exclude filter extension to feature bitmap")
> dcdaa2f9480c ("Merge branch 'stable-4.10' of
> git://git.infradead.org/users/pcmoore/audit")
>
> from Linus' tree and commit:
>
> 92c82e8a322b ("audit: add feature audit_lost reset")
>
> from the audit tree.
This merge conflict was expected.
Your fix below looks as expected.
Thanks! Sorry for the trouble.
> 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 include/uapi/linux/audit.h
> index 1c107cb1c83f,3f24110ae63c..
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@@ -330,13 -331,14 +331,16 @@@ enum
> #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT 0x0001
> #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x0002
> #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH0x0004
> +#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x0008
> #define AUDIT_FEATURE_BITMAP_SESSIONID_FILTER 0x0010
> + #define AUDIT_FEATURE_BITMAP_LOST_RESET 0x0020
> +
> #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
> AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
> AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
> + AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
> - AUDIT_FEATURE_BITMAP_SESSIONID_FILTER)
> + AUDIT_FEATURE_BITMAP_SESSIONID_FILTER | \
> + AUDIT_FEATURE_BITMAP_LOST_RESET)
>
> /* deprecated: AUDIT_VERSION_* */
> #define AUDIT_VERSION_LATESTAUDIT_FEATURE_BITMAP_ALL
- RGB
--
Richard Guy Briggs
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
[PATCH v2] tools build: add tools tree support for 'make -s'
When doing a kernel build with 'make -s', everything is silenced except the objtool build. That's because the tools tree support for silent builds is some combination of missing and broken. Three changes are needed to fix it: - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the tools Makefiles can see it. - tools/scripts/Makefile.include: fix the tools Makefiles' ability to recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences the "DESCEND objtool" message. - tools/build/Makefile.build: add support to the tools Build files for recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences all the object compile/link messages. Reported-by: Peter Zijlstra Signed-off-by: Josh Poimboeuf --- v2: - add 'ifndef' indent level and 'make-3.8x' comment in Makefile.include Makefile | 6 -- tools/build/Makefile.build | 10 ++ tools/scripts/Makefile.include | 12 +++- 3 files changed, 25 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 96e2352..b10e794 100644 --- a/Makefile +++ b/Makefile @@ -87,10 +87,12 @@ endif ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) quiet=silent_ + tools_silent=s endif else # make-3.8x ifneq ($(filter s% -s%,$(MAKEFLAGS)),) quiet=silent_ + tools_silent=-s endif endif @@ -1607,11 +1609,11 @@ image_name: # Clear a bunch of variables before executing the submake tools/: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ + $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ tools/%: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $* + $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $* # Single targets # --- diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build index 99c0ccd..e279a71 100644 --- a/tools/build/Makefile.build +++ b/tools/build/Makefile.build @@ -19,6 +19,16 @@ else Q=@ endif +ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 +ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) + quiet=silent_ +endif +else # make-3.8x +ifneq ($(filter s% -s%,$(MAKEFLAGS)),) + quiet=silent_ +endif +endif + build-dir := $(srctree)/tools/build # Define $(fixdep) for dep-cmd function diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include index 8abbef1..19edc1a 100644 --- a/tools/scripts/Makefile.include +++ b/tools/scripts/Makefile.include @@ -46,6 +46,16 @@ else NO_SUBDIR = : endif +ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 +ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) + silent=1 +endif +else # make-3.8x +ifneq ($(filter s% -s%,$(MAKEFLAGS)),) + silent=1 +endif +endif + # # Define a callable command for descending to a new directory # @@ -58,7 +68,7 @@ descend = \ QUIET_SUBDIR0 = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir QUIET_SUBDIR1 = -ifneq ($(findstring $(MAKEFLAGS),s),s) +ifneq ($(silent),1) ifneq ($(V),1) QUIET_CC = @echo ' CC '$@; QUIET_CC_FPIC = @echo ' CC FPIC '$@; -- 2.7.4
linux-next: build failure after merge of the rcu tree
Hi Paul,
After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here (not in a
function)
.slab_flags = SLAB_DESTROY_BY_RCU,
^
Caused by commit
c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
interacting with commit
ac7138746e14 ("smc: establish new socket family")
from the net-next tree.
I have applied the following merge fix patch (someone will need to
remember to mention this to Linus):
From: Stephen Rothwell
Date: Thu, 19 Jan 2017 14:29:12 +1100
Subject: [PATCH] smc: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to
SLAB_TYPESAFE_BY_RCU"
Signed-off-by: Stephen Rothwell
---
net/smc/af_smc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 4875e65f0c4a..a48260f9ebb7 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -99,7 +99,7 @@ struct proto smc_proto = {
.unhash = smc_unhash_sk,
.obj_size = sizeof(struct smc_sock),
.h.smc_hash = &smc_v4_hashinfo,
- .slab_flags = SLAB_DESTROY_BY_RCU,
+ .slab_flags = SLAB_TYPESAFE_BY_RCU,
};
EXPORT_SYMBOL_GPL(smc_proto);
--
2.10.2
--
Cheers,
Stephen Rothwell
[PATCH] arm64: dts: msm8996: Add ADSP PIL node
Add ADSP node required for Qualcomm ADSP Peripheral Image Loader.
Signed-off-by: Sarangdhar Joshi
---
This patch uses "xo_board" clock for now. We would have to move to
rpmcc once it is available.
arch/arm64/boot/dts/qcom/msm8996.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index c9c7fd7..7cebf63 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -181,6 +181,26 @@
method = "smc";
};
+ adsp-pil {
+ compatible = "qcom,msm8996-adsp-pil";
+
+ interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = <&xo_board>;
+ clock-names = "xo";
+
+ memory-region = <&adsp_region>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+ };
+
adsp-smp2p {
compatible = "qcom,smp2p";
qcom,smem = <443>, <429>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 08/33] Input: spear-keyboard - Drop unnecessary error messages and other changes
On Wed, Jan 18, 2017 at 11:16 PM, Guenter Roeck wrote: > Error messages after memory allocation failures are unnecessary and > can be dropped. > > This conversion was done automatically with coccinelle using the > following semantic patches. The semantic patches and the scripts > used to generate this commit log are available at > https://github.com/groeck/coccinelle-patches > > - Drop unnecessary braces around conditional return statements > - Drop error message after devm_kzalloc() failure > > Signed-off-by: Guenter Roeck > --- > drivers/input/keyboard/spear-keyboard.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Acked-by: Viresh Kumar
Re: [PATCH RFC] powerpc/32: fix handling of stack protector with recent GCC
On Mon, 16 Jan 2017, Christophe Leroy wrote: > Christian, can you test it ? OK, so with that applied to v4.10-rc4, compilation still fails with GCC 4.9.2 and CC_STACKPROTECTOR_STRONG=y, see below. But it compiles just fine with CC_STACKPROTECTOR_REGULAR=y and boots to! Cross-compiling the same with GCC 5.2.0 works, even for CC_STACKPROTECTOR_STRONG=y and the system boots just fine. So, with that limitation, feel free to add: Tested-by: Christian Kujau Thanks for the fix! Christian. $ gcc --version | head -1 gcc-4.9.real (Debian 4.9.2-10) 4.9.2 $ grep CC_STACKPROTECTOR_STRONG $DIR/.config CONFIG_CC_STACKPROTECTOR_STRONG=y $ make O=$DIR V=1 bindeb-pkg [...] + ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o arch/powerpc/kernel/prom_init.o init/built-in.o --start-group usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o --end-group arch/powerpc/platforms/built-in.o: In function `bootx_printf': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined reference to `__stack_chk_fail_local' arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined reference to `__stack_chk_fail_local' arch/powerpc/platforms/built-in.o: In function `bootx_scan_dt_build_struct': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined reference to `__stack_chk_fail_local' arch/powerpc/platforms/built-in.o: In function `bootx_init': /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined reference to `__stack_chk_fail_local' /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' isn't defined /usr/bin/ld.bfd.real: final link failed: Bad value -- BOFH excuse #66: bit bucket overflow
[PATCH] tools build: add tools tree support for 'make -s'
When doing a kernel build with 'make -s', everything is silenced except the objtool build. That's because the tools tree support for silent builds is some combination of missing and broken. Three changes are needed to fix it: - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the tools Makefiles can see it. - tools/scripts/Makefile.include: fix the tools Makefiles' ability to recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences the "DESCEND objtool" message. - tools/build/Makefile.build: add support to the tools Build files for recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences all the object compile/link messages. Reported-by: Peter Zijlstra Signed-off-by: Josh Poimboeuf --- Makefile | 6 -- tools/build/Makefile.build | 10 ++ tools/scripts/Makefile.include | 12 +++- 3 files changed, 25 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 96e2352..b10e794 100644 --- a/Makefile +++ b/Makefile @@ -87,10 +87,12 @@ endif ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) quiet=silent_ + tools_silent=s endif else # make-3.8x ifneq ($(filter s% -s%,$(MAKEFLAGS)),) quiet=silent_ + tools_silent=-s endif endif @@ -1607,11 +1609,11 @@ image_name: # Clear a bunch of variables before executing the submake tools/: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ + $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ tools/%: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $* + $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $* # Single targets # --- diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build index 99c0ccd..e279a71 100644 --- a/tools/build/Makefile.build +++ b/tools/build/Makefile.build @@ -19,6 +19,16 @@ else Q=@ endif +ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 +ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) + quiet=silent_ +endif +else # make-3.8x +ifneq ($(filter s% -s%,$(MAKEFLAGS)),) + quiet=silent_ +endif +endif + build-dir := $(srctree)/tools/build # Define $(fixdep) for dep-cmd function diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include index 8abbef1..08f81f4 100644 --- a/tools/scripts/Makefile.include +++ b/tools/scripts/Makefile.include @@ -46,6 +46,16 @@ else NO_SUBDIR = : endif +ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 +ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) +silent=1 +endif +else +ifneq ($(filter s% -s%,$(MAKEFLAGS)),) +silent=1 +endif +endif + # # Define a callable command for descending to a new directory # @@ -58,7 +68,7 @@ descend = \ QUIET_SUBDIR0 = +$(MAKE) $(COMMAND_O) -C # space to separate -C and subdir QUIET_SUBDIR1 = -ifneq ($(findstring $(MAKEFLAGS),s),s) +ifneq ($(silent),1) ifneq ($(V),1) QUIET_CC = @echo ' CC '$@; QUIET_CC_FPIC = @echo ' CC FPIC '$@; -- 2.7.4
Re: [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
On 19/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
>> index 46c742d3bd41..59be3ca0464f 100644
>> --- a/arch/arm/mach-mvebu/platsmp.c
>> +++ b/arch/arm/mach-mvebu/platsmp.c
>> @@ -184,3 +184,89 @@ const struct smp_operations armada_xp_smp_ops
>> __initconst = {
>>
>> CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
>>&armada_xp_smp_ops);
>> +
>> +struct resume_controller {
>> +u32 resume_control;
>> +u32 resume_boot_addr;
>> +};
>> +
>> +static const struct resume_controller mv98dx3336_resume_controller = {
>> +.resume_control = 0x08,
>> +.resume_boot_addr = 0x04,
>> +};
>> +
>> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
>> +{
>> +.compatible = "marvell,98dx3336-resume-ctrl",
>> +.data = (void *)&mv98dx3336_resume_controller,
>
> Useless cast?
>
>> +},
>> +{ /* end of list */ },
>> +};
>> +
>> +static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
>> +{
>> +const struct of_device_id *match;
>> +struct device_node *np;
>> +void __iomem *base;
>> +struct resume_controller *rc;
>> +
>> +WARN_ON(hw_cpu != 1);
>> +
>> +np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
>> + &match);
>> +if (!np)
>> +return -ENODEV;
>> +
>> +base = of_io_request_and_map(np, 0, of_node_full_name(np));
>> +rc = (struct resume_controller *)match->data;
>
> Useless cast?
>
>> +of_node_put(np);
>> +if (IS_ERR(base))
>> +return PTR_ERR(base);
>> +
>> +writel(0, base + rc->resume_control);
>> +writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
>> +
>
> Otherwise
>
> Reviewed-by: Stephen Boyd
>
Thanks for the review. Changes will be in v5.
Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role
On 1/18/2017 7:12 PM, Baolin Wang wrote: > Hi John, > > On 19 January 2017 at 09:33, John Youn wrote: >> On 1/16/2017 2:38 AM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> John Youn writes: > Baolin Wang writes: >>> Baolin Wang writes: When dwc3 controller acts as host role with attaching slow speed device (like mouse or keypad). Then if we plugged out the slow speed device, it will timeout to run the deconfiguration endpoint command to drop the endpoint's resources. Some xHCI command timeout log as below when disconnecting one slow device: [ 99.807739] c0 xhci-hcd.0.auto: Port Status Change Event for port 1 [ 99.814699] c0 xhci-hcd.0.auto: resume root hub [ 99.819992] c0 xhci-hcd.0.auto: handle_port_status: starting port polling. [ 99.827808] c0 xhci-hcd.0.auto: get port status, actual port 0 status = 0x202a0 [ 99.835903] c0 xhci-hcd.0.auto: Get port status returned 0x10100 [ 99.850052] c0 xhci-hcd.0.auto: clear port connect change, actual port 0 status = 0x2a0 [ 99.859313] c0 xhci-hcd.0.auto: Cancel URB ffc01ed6cd00, dev 1, ep 0x81, starting at offset 0xc406d210 [ 99.869645] c0 xhci-hcd.0.auto: // Ding dong! [ 99.874776] c0 xhci-hcd.0.auto: Stopped on Transfer TRB [ 99.880713] c0 xhci-hcd.0.auto: Removing canceled TD starting at 0xc406d210 (dma). [ 99.889012] c0 xhci-hcd.0.auto: Finding endpoint context [ 99.895069] c0 xhci-hcd.0.auto: Cycle state = 0x1 [ 99.900519] c0 xhci-hcd.0.auto: New dequeue segment = ffc1112f0880 (virtual) [ 99.908655] c0 xhci-hcd.0.auto: New dequeue pointer = 0xc406d220 (DMA) [ 99.915927] c0 xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg = ffc1112f0880 (0xc406d000 dma), new deq ptr = ff8002175220 (0xc406d220 dma), new cycle = 1 [ 99.931242] c0 xhci-hcd.0.auto: // Ding dong! [ 99.936360] c0 xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd, deq = @c406d220 [ 99.944458] c0 xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. [ 100.047619] c0 xhci-hcd.0.auto: xhci_drop_endpoint called for udev ffc01ae08800 [ 100.057002] c0 xhci-hcd.0.auto: drop ep 0x81, slot id 1, new drop flags = 0x8, new add flags = 0x0 [ 100.067878] c0 xhci-hcd.0.auto: xhci_check_bandwidth called for udev ffc01ae08800 [ 100.076868] c0 xhci-hcd.0.auto: New Input Control Context: .. [ 100.427252] c0 xhci-hcd.0.auto: // Ding dong! [ 105.430728] c0 xhci-hcd.0.auto: Command timeout [ 105.436029] c0 xhci-hcd.0.auto: Abort command ring [ 113.558223] c0 xhci-hcd.0.auto: Command completion event does not match command [ 113.569778] c0 xhci-hcd.0.auto: Timeout while waiting for configure endpoint command The reason is it will suspend USB phy to disable phy clock when disconnecting the slow USB decice, that will hang on the xHCI commands executing which depends on the phy clock. Thus we should disable USB2.0 phy suspend feature when dwc3 acts as host role. Signed-off-by: Baolin Wang --- drivers/usb/dwc3/core.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 9a4a5e4..0b646cf 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -565,6 +565,20 @@ static int dwc3_phy_setup(struct dwc3 *dwc) if (dwc->revision > DWC3_REVISION_194A) reg |= DWC3_GUSB2PHYCFG_SUSPHY; + /* + * When dwc3 controller acts as host role with attaching one slow speed + * device (like mouse or keypad). Then if we plugged out the slow speed + * device, it will timeout to run the deconfiguration endpoint command. + * The reason is it will suspend USB phy to disable phy clock when + * disconnecting slow speed decice, which will affect the
linux-next: manual merge of the tip tree with the security tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
security/apparmor/include/apparmor.h
between commit:
12557dcba21b ("apparmor: move lib definitions into separate lib include")
from the security tree and commit:
6b1ffa06e59d ("locking/atomic, kref: Use kref_get_unless_zero() more")
from the tip tree.
I fixed it up (the former moved the code to another file, so I applied the
below patch there) 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.
From: Stephen Rothwell
Date: Thu, 19 Jan 2017 14:01:15 +1100
Subject: [PATCH] locking/atomic, kref: merge fixup for code movement
Signed-off-by: Stephen Rothwell
---
security/apparmor/include/lib.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/security/apparmor/include/lib.h b/security/apparmor/include/lib.h
index fa281c272970..65ff492a9807 100644
--- a/security/apparmor/include/lib.h
+++ b/security/apparmor/include/lib.h
@@ -76,12 +76,6 @@ static inline void *kvzalloc(size_t size)
return __aa_kvmalloc(size, __GFP_ZERO);
}
-/* returns 0 if kref not incremented */
-static inline int kref_get_not0(struct kref *kref)
-{
- return atomic_inc_not_zero(&kref->refcount);
-}
-
/**
* aa_strneq - compare null terminated @str to a non null terminated substring
* @str: a null terminated string
--
2.10.2
--
Cheers,
Stephen Rothwell
Re: module: fix failed to rmmod kernel module when it's name is too long
+++ Xie XiuQi [13/01/17 17:19 +0800]:
When the name of kernel module is more than 56 chars (include 56),
the module could be insmod successfully, but failed to rmmod.
$ strace rmmod tst_112233445566
...
open("/sys/module/tst_112233445566/initstate",
O_RDONLY|O_CLOEXEC) = 3
read(3, "live\n", 31) = 5
read(3, "", 26) = 0
close(3)= 0
openat(AT_FDCWD,
"/sys/module/tst_112233445566/holders",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 2 entries */, 32768) = 48
getdents(3, /* 0 entries */, 32768) = 0
close(3)= 0
open("/sys/module/tst_112233445566/refcnt",
O_RDONLY|O_CLOEXEC) = 3
read(3, "0\n", 31) = 2
read(3, "", 29) = 0
close(3)= 0
delete_module("tst_112233445566",
O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
write(2, "rmmod: ERROR: could not remove '"..., 117rmmod: ERROR: could not
remove 'tst_112233445566': No such file or
directory
) = 117
write(2, "rmmod: ERROR: could not remove m"..., 122rmmod: ERROR: could not
remove module tst_112233445566: No such file or
directory
) = 122
exit_group(1) = ?
+++ exited with 1 +++
In this patch, we just set the last char to '\0', to make sure
the name has the tailing '\0'.
Reported-by: Zhang Liguang
Signed-off-by: Xie XiuQi
---
kernel/module.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/module.c b/kernel/module.c
index 0e54d5b..3eac266 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2928,6 +2928,7 @@ static struct module *setup_load_info(struct load_info
*info, int flags)
}
/* This is temporary: point mod into copy of data. */
mod = (void *)info->sechdrs[info->index.mod].sh_addr;
+ mod->name[MODULE_NAME_LEN - 1] = '\0';
Does the patch actually fix the rmmod issue you're describing?
I tested it and rmmod still had issues finding the module because userspace
doesn't know its in-kernel name got truncated by one character. So kmod (rmmod)
would look for
/sys/module/tst_112233445566/initstate
instead of
/sys/module/tst_11223344556/initstate
and subsequently fail with "module not loaded"
So, unfortunately this patch probably isn't enough fix this problem. When a
module's name is >= MODULE_NAME_LEN, it gets silently truncated in-kernel on
module load. Moreover, (1) userspace won't know about that happening and (2) the
module name found in .gnu.linkonce.this_module would also diverge from its name
in-kernel.
What might be nice to have is to have a compile-time assertion that breaks the
build if KBUILD_MODNAME exceeds MODULE_NAME_LEN, that way the error is clearly
user-visible, and we won't run into this problem in the first place. Plus
problems 1 and 2 mentioned above go away. Maybe we can have modpost insert a
BUILD_BUG_ON when KBUILD_MODNAME > MODULE_NAME_LEN?
Jessica
Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC
On 19/01/17 11:25, Rob Herring wrote: > On Fri, Jan 13, 2017 at 10:12:16PM +1300, Chris Packham wrote: >> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from >> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz. >> >> The clock gating options are a subset of those on the Armada XP. >> >> The core clock divider is different to the Armada XP also. >> >> Signed-off-by: Chris Packham >> --- >> >> Notes: >> Changes in v2: >> - Update devicetree binding documentation for new compatible string >> Changes in v3: >> - Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new >> driver. >> - Document mv98dx3236-corediv-clock binding >> Changes in v4: >> - None >> >> .../bindings/clock/mvebu-corediv-clock.txt | 1 + >> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 + > > Please add acks when posting new versions. > > Acked-by: Rob Herring > Thanks Rob. I must have missed the earlier ack. Will be in v5.
Re: [PATCH v4 1/2] mailbox: Add driver for Broadcom FlexRM ring manager
Hi All, Any comments on this patch ?? Regards, Anup
Re: [PATCH v11 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel
Hi, YT:
one comment inline.
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 89
> +++---
> 1 file changed, 74 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 85f22d2..21392c4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_ENBIT(0)
> +#define TS_VFP_ENBIT(5)
> +
> #define DSI_CMDQ00x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -365,16 +369,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -512,6 +523,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -570,6 +591,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32
> t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -578,6 +612,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> + mtk_dsi_stop(dsi);
> + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel)) {
Why drm_panel_unprepare() in mtk_dsi_poweroff() but drm_panel_prepare()
in mtk_output_dsi_enable()? This asymmetric design would easily cause
some bugs.
Regards,
CK
> + DRM_ERROR("failed to unprepare the panel\n");
> + return;
> + }
> + }
> + }
> +
> + mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
>
> @@ -596,13 +641,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> @@ -610,22 +648,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> }
>
> mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>
> mtk_dsi_clk_ulp_mode_leave(dsi);
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
> -
Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role
Hi John, On 19 January 2017 at 09:33, John Youn wrote: > On 1/16/2017 2:38 AM, Felipe Balbi wrote: >> >> Hi, >> >> John Youn writes: Baolin Wang writes: >> Baolin Wang writes: >>> When dwc3 controller acts as host role with attaching slow speed device >>> (like mouse or keypad). Then if we plugged out the slow speed device, >>> it will timeout to run the deconfiguration endpoint command to drop the >>> endpoint's resources. Some xHCI command timeout log as below when >>> disconnecting one slow device: >>> >>> [ 99.807739] c0 xhci-hcd.0.auto: Port Status Change Event for port 1 >>> [ 99.814699] c0 xhci-hcd.0.auto: resume root hub >>> [ 99.819992] c0 xhci-hcd.0.auto: handle_port_status: starting port >>> polling. >>> [ 99.827808] c0 xhci-hcd.0.auto: get port status, actual port 0 status >>> = 0x202a0 >>> [ 99.835903] c0 xhci-hcd.0.auto: Get port status returned 0x10100 >>> [ 99.850052] c0 xhci-hcd.0.auto: clear port connect change, actual >>> port 0 status = 0x2a0 >>> [ 99.859313] c0 xhci-hcd.0.auto: Cancel URB ffc01ed6cd00, dev 1, >>> ep 0x81, starting at offset 0xc406d210 >>> [ 99.869645] c0 xhci-hcd.0.auto: // Ding dong! >>> [ 99.874776] c0 xhci-hcd.0.auto: Stopped on Transfer TRB >>> [ 99.880713] c0 xhci-hcd.0.auto: Removing canceled TD starting at >>> 0xc406d210 (dma). >>> [ 99.889012] c0 xhci-hcd.0.auto: Finding endpoint context >>> [ 99.895069] c0 xhci-hcd.0.auto: Cycle state = 0x1 >>> [ 99.900519] c0 xhci-hcd.0.auto: New dequeue segment = >>> ffc1112f0880 (virtual) >>> [ 99.908655] c0 xhci-hcd.0.auto: New dequeue pointer = 0xc406d220 >>> (DMA) >>> [ 99.915927] c0 xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg = >>> ffc1112f0880 (0xc406d000 dma), >>> new deq ptr = ff8002175220 >>> (0xc406d220 dma), new cycle = 1 >>> [ 99.931242] c0 xhci-hcd.0.auto: // Ding dong! >>> [ 99.936360] c0 xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd, >>> deq = @c406d220 >>> [ 99.944458] c0 xhci-hcd.0.auto: xhci_hub_status_data: stopping port >>> polling. >>> [ 100.047619] c0 xhci-hcd.0.auto: xhci_drop_endpoint called for udev >>> ffc01ae08800 >>> [ 100.057002] c0 xhci-hcd.0.auto: drop ep 0x81, slot id 1, new drop >>> flags = 0x8, new add flags = 0x0 >>> [ 100.067878] c0 xhci-hcd.0.auto: xhci_check_bandwidth called for udev >>> ffc01ae08800 >>> [ 100.076868] c0 xhci-hcd.0.auto: New Input Control Context: >>> >>> .. >>> >>> [ 100.427252] c0 xhci-hcd.0.auto: // Ding dong! >>> [ 105.430728] c0 xhci-hcd.0.auto: Command timeout >>> [ 105.436029] c0 xhci-hcd.0.auto: Abort command ring >>> [ 113.558223] c0 xhci-hcd.0.auto: Command completion event does not >>> match >>> command >>> [ 113.569778] c0 xhci-hcd.0.auto: Timeout while waiting for configure >>> endpoint command >>> >>> The reason is it will suspend USB phy to disable phy clock when >>> disconnecting the slow USB decice, that will hang on the xHCI commands >>> executing which depends on the phy clock. >>> >>> Thus we should disable USB2.0 phy suspend feature when dwc3 acts as host >>> role. >>> >>> Signed-off-by: Baolin Wang >>> --- >>> drivers/usb/dwc3/core.c | 14 ++ >>> 1 file changed, 14 insertions(+) >>> >>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >>> index 9a4a5e4..0b646cf 100644 >>> --- a/drivers/usb/dwc3/core.c >>> +++ b/drivers/usb/dwc3/core.c >>> @@ -565,6 +565,20 @@ static int dwc3_phy_setup(struct dwc3 *dwc) >>> if (dwc->revision > DWC3_REVISION_194A) >>> reg |= DWC3_GUSB2PHYCFG_SUSPHY; >>> >>> + /* >>> + * When dwc3 controller acts as host role with attaching one slow >>> speed >>> + * device (like mouse or keypad). Then if we plugged out the slow >>> speed >>> + * device, it will timeout to run the deconfiguration endpoint >>> command. >>> + * The reason is it will suspend USB phy to disable phy clock when >>> + * disconnecting slow speed decice, which will affect the xHCI >>> commands >>> + * executing. >>> + * >>> + * Thus we should disable USB 2.0 phy suspend feature when dwc3 >>> acts as >>>
Re: [PATCH v4 05/15] lockdep: Make check_prev_add can use a separate stack_trace
On Wed, Jan 18, 2017 at 04:10:53PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 18, 2017 at 11:04:32AM +0900, Byungchul Park wrote:
> > On Tue, Jan 17, 2017 at 04:54:31PM +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 13, 2017 at 07:11:43PM +0900, Byungchul Park wrote:
> > > > What do you think about the following patches doing it?
> > >
> > > I was more thinking about something like so...
> > >
> > > Also, I think I want to muck with struct stack_trace; the members:
> > > max_nr_entries and skip are input arguments to save_stack_trace() and
> > > bloat the structure for no reason.
> >
> > With your approach, save_trace() must be called whenever check_prevs_add()
> > is called, which might be unnecessary.
>
> True.. but since we hold the graph_lock this is a slow path anyway, so I
> didn't care much.
If we don't need to care it, the problem becomes easy to solve. But IMHO,
it'd be better to care it as original lockdep code did, because
save_trace() might have bigger overhead than we expect and
check_prevs_add() can be called frequently, so it'd be better to avoid it
when possible.
> Then again, I forgot to clean up in a bunch of paths.
>
> > Frankly speaking, I think what I proposed resolved it neatly. Don't you
> > think so?
>
> My initial reaction was to your patches being radically different to
> what I had proposed. But after fixing mine I don't particularly like
> either one of them.
>
> Also, I think yours has a hole in, you check nr_stack_trace_entries
> against an older copy to check we did save_stack(), this is not accurate
> as check_prev_add() can drop graph_lock in the verbose case and then
> someone else could have done save_stack().
Right. My mistake..
Then.. The following patch on top of my patch 2/2 can solve it. Right?
---
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 49b9386..0f5bded 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1892,7 +1892,7 @@ static inline void inc_chains(void)
if (entry->class == hlock_class(next)) {
if (distance == 1)
entry->distance = 1;
- return 2;
+ return 1;
}
}
@@ -1927,9 +1927,10 @@ static inline void inc_chains(void)
print_lock_name(hlock_class(next));
printk(KERN_CONT "\n");
dump_stack();
- return graph_lock();
+ if (!graph_lock())
+ return 0;
}
- return 1;
+ return 2;
}
/*
@@ -1975,15 +1976,16 @@ static inline void inc_chains(void)
* added:
*/
if (hlock->read != 2 && hlock->check) {
- if (!check_prev_add(curr, hlock, next,
- distance, &trace, save))
+ int ret = check_prev_add(curr, hlock, next,
+ distance, &trace, save);
+ if (!ret)
return 0;
/*
* Stop saving stack_trace if save_trace() was
* called at least once:
*/
- if (save && start_nr != nr_stack_trace_entries)
+ if (save && ret == 2)
save = NULL;
/*
Re: writev error codes
On Wed, Jan 18, 2017 at 04:44:31PM +0100, Michal Hocko wrote:
> Hi,
> we have noticed that one of the LTP tests started to fail after
> 99526912c934 ("fix iov_iter_fault_in_readable()"). The code has expected
> EINVAL while it gets EFAULT. I believe the new behavior is reasonable,
> but checking the man 2 writev, there is no mention about EFAULT,
> and other errnos for that matter, so it seems this is rather under
> documented and it can confuse users. LTP has been fixed in the meantime
> [1] but this might come unexpected to others.
>
> In principle writev as a write
> "multiplier" should be allowed all the error codes that write(2) allows,
> right? I am not sure how we should reflect that. Either c&p what we have
> in man 2 write or put a reference to it and only describe writev
> specific, if there are any (I haven't checked that).
FWIW, EFAULT-related parts in POSIX are very weak.
2.3 Error Numbers:
[EFAULT]
Bad address. The system detected an invalid address in attempting to
use an argument of a call. The reliable detection of this error cannot
be guaranteed, and when not detected may result in the generation of a
signal, indicating an address violation, which is sent to the process.
B.2.3 Error Numbers:
POSIX.1 requires (in the ERRORS sections of function descriptions)
certain error values to be set in certain conditions because many
existing applications depend on them. Some error numbers, such as
[EFAULT], are entirely implementation-defined and are noted as such in
their description in the ERRORS section. This section otherwise allows
wide latitude to the implementation in handling error reporting.
idem:
[EFAULT]
Most historical implementations do not catch an error and set errno
when an invalid address is given to the functions wait(), time(),
or times(). Some implementations cannot reliably detect an invalid
address. And most systems that detect invalid addresses will do so
only for a system call, not for a library routine.
idem, in discussion of thread IDs:
As with other interfaces that take pointer parameters, the outcome of
passing an invalid parameter can result in an invalid memory reference
or an attempt to access an undefined portion of a memory object, cause
signals to be sent (SIGSEGV or SIGBUS) and possible termination of the
process. This is a similar case to passing an invalid buffer pointer to
read(). Some implementations might implement read() as a system call and
set an [EFAULT] error condition. Other implementations might contain
parts of read() at user level and the first attempt to access data at
an invalid reference will cause a signal to be sent instead.
and for execve(2) et.al. there's
[EFAULT]
Some historical systems return [EFAULT] rather than [ENOEXEC] when
the new process image file is corrupted. They are non-conforming.
And that's it - this is the only syscall page that explicitly mentions
EFAULT (and that - as "don't return it for that case"). read(2),
write(2), writev(2), etc. all get EFAULT implicitly from 2.3.
In particular, how far would e.g. writev(2) get in case when some parts of
the source buffer(s) are at invalid address is not guaranteed at all.
We get either a short write or EFAULT; it is not (and never had been)
guaranteed that ever byte prior to the first invalid address will be
written out. Moreover, the amount of potentially fetchable bytes _not_
written is (and always had been) file-dependent. Generally we try to
keep it bounded by page size, but even that is not guarateed - e.g. a driver
might very well take "all or nothing" policy and treat everything short of
successfully reading all the source buffer as "fail with EFAULT, nothing
gets written". For regular files on more or less normal filesystems the
actual rule is "discard anything starting at the last covered file offset
divisible by page size" - IOW, two writev() to the same file with identical
iovec array can result in short writes of different lengths if the latter call
is preceded by lseek(). Again, details of behaviour depend upon the file
you are writing to, and that's just for Linux - other Unices have rules of
their own. No userland code should ever rely upon the specific rules here;
if you have an invalid address anywhere in the source buffers, you can
(on Linux) count upon a short write of some length or EFAULT. Anything
more specific depends upon a lot of factors.
Re: [PATCH v2] vfio/pci: Support error recovery
On 01/19/2017 05:32 AM, Alex Williamson wrote:
> On Tue, 10 Jan 2017 17:11:01 +0200
> "Michael S. Tsirkin" wrote:
>
>> On Tue, Jan 10, 2017 at 07:46:17PM +0800, Cao jin wrote:
>>>
>>>
>>> On 01/10/2017 07:04 AM, Michael S. Tsirkin wrote:
On Sat, Dec 31, 2016 at 05:15:36PM +0800, Cao jin wrote:
> Support serious device error recovery
serious?
>>>
>>> Sorry for my poor vocabulary if it confuses people. I wanted to express
>>> the meaning that: vfio-pci actually cannot do a real recovery for device
>>> even if it provides the callbacks, it relies on the user to do a
>>> effective(or word "serious"?) recovery.
>>>
>>> Welcome the amendment on the commit log.
>>
>> It's up to Alex, maybe he's able to figure it all out from
>> code, but the rest of us could benefit from a description
>> of what the patch does from userspace point of view.
>>
>> Also, is it a pre-requisite of the userspace patches you posted?
>
> This is the same blocking user accesses while the device is in recovery
> that you thought was ineffective/wrong before. Why do we still need it
> if QEMU isn't trying to handle fatal errors? If the kernel is doing a
> reset shouldn't the user consider the device dead? A commit log
> explaining this is absolutely necessary. Thanks,
>
> Alex
>
Yes, it is the same blocking user access as before, and I did said it is
not effective as we expected, and I drew the figure to illustrate my
analysis. I think the blocking is right, maybe just not enough to work
fine, because it is possible that vfio's blocking is over, while
hardware reset is not done, results in inaccessible device.
Leave the blocking here is no harm for now, and could be useful in
future(when we handle fatal error).
We don't forward fatal error events to guest, why would guest kernel do
a reset? Or do you mean some device driver would do hardware reset on
non-fatal error?
--
Sincerely,
Cao jin
>
> Signed-off-by: Cao jin
> ---
> drivers/vfio/pci/vfio_pci.c | 70
> +++--
> drivers/vfio/pci/vfio_pci_private.h | 2 ++
> 2 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 712a849..752af20 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -534,6 +534,15 @@ static long vfio_pci_ioctl(void *device_data,
> {
> struct vfio_pci_device *vdev = device_data;
> unsigned long minsz;
> + int ret;
> +
> + if (vdev->aer_recovering && (cmd == VFIO_DEVICE_SET_IRQS ||
> + cmd == VFIO_DEVICE_RESET || cmd == VFIO_DEVICE_PCI_HOT_RESET)) {
> + ret = wait_for_completion_interruptible(
> + &vdev->aer_completion);
don't split it like that.
> + if (ret)
> + return ret;
> + }
>
> if (cmd == VFIO_DEVICE_GET_INFO) {
> struct vfio_device_info info;
> @@ -953,6 +962,15 @@ static ssize_t vfio_pci_rw(void *device_data, char
> __user *buf,
> {
> unsigned int index = VFIO_PCI_OFFSET_TO_INDEX(*ppos);
> struct vfio_pci_device *vdev = device_data;
> + int ret;
> +
> + /* block all kinds of access during host recovery */
> + if (vdev->aer_recovering) {
> + ret = wait_for_completion_interruptible(
> + &vdev->aer_completion);
> + if (ret)
> + return ret;
> + }
>
> if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions)
> return -EINVAL;
> @@ -1117,6 +1135,7 @@ static int vfio_pci_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> vdev->irq_type = VFIO_PCI_NUM_IRQS;
> mutex_init(&vdev->igate);
> spin_lock_init(&vdev->irqlock);
> + init_completion(&vdev->aer_completion);
>
> ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
> if (ret) {
> @@ -1176,6 +1195,9 @@ static pci_ers_result_t
> vfio_pci_aer_err_detected(struct pci_dev *pdev,
> {
> struct vfio_pci_device *vdev;
> struct vfio_device *device;
> + u32 uncor_status;
> + unsigned int aer_cap_offset;
> + int ret;
>
> device = vfio_device_get_from_dev(&pdev->dev);
> if (device == NULL)
> @@ -1187,10 +1209,29 @@ static pci_ers_result_t
> vfio_pci_aer_err_detected(struct pci_dev *pdev,
> return PCI_ERS_RESULT_DISCONNECT;
> }
>
> + /*
> + * get device's uncorrectable error status as soon as possible,
should be "Get".
> + * and signal it to user space. The later we read it, the possibility
> + * the register value is mangled grows.
> + */
> + aer_cap_offset = pci_find_ext_capability(vdev->pdev,
> PCI_EXT_CAP_ID_ERR);
> + ret = pci_read_config_dword(vdev->pdev, aer_cap_offset +
> +
Re: [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
On Wed, 2017-01-18 at 16:42 -0600, Rob Herring wrote: > On Wed, Jan 18, 2017 at 4:23 PM, Rob Herring wrote: > > On Fri, Jan 13, 2017 at 03:35:38PM +0800, sean.w...@mediatek.com wrote: > >> From: Sean Wang > >> > >> This patch adds documentation for devicetree bindings for > >> consumer Mediatek IR controller. > >> > >> Signed-off-by: Sean Wang > >> --- > >> .../devicetree/bindings/media/mtk-cir.txt | 24 > >> ++ > >> 1 file changed, 24 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt > > > > Acked-by: Rob Herring > > I guess I rescind my ack if this email doesn't work: > > "The response from the remote server was: > > 550 Relaying mail to sean.w...@mediatek.com is not allowed" sorry for causing you inconvenience. it should be able to work because i almost use this daily maybe that's just a sudden problem from internal server (?) but if the problem still continues, please let me know and i will try to fix this.
Re: [GIT PULL] ARM: aspeed: devicetree for 4.11
On Thu, Jan 19, 2017 at 11:27 AM, Olof Johansson wrote: > On Wed, Jan 18, 2017 at 09:50:02AM +1100, Joel Stanley wrote: >> These commits also add newly upstreamed drivers to the Palmetto BMC and >> ast2500 >> eval board. We now have working network, ipmi bt, gpio and pinmux on >> all platforms. >> >> ARM: dts: aspeed: Add Romulus BMC platform >> ARM: dts: aspeed: Add ftgmac100 to g4 and g5 platforms >> ARM: dts: aspeed: Correct palmetto device tree >> ARM: dts: aspeed: Reserve framebuffer memory >> ARM: dts: aspeed-g5: Add gpio controller to devicetree >> ARM: dts: aspeed-g5: Add syscon and pin controller nodes >> ARM: dts: aspeed-g5: Add LPC Controller node >> ARM: dts: aspeed-g5: Add SoC Display Controller node >> ARM: dts: aspeed-g4: Add gpio controller to devicetree >> ARM: dts: aspeed-g4: Add syscon and pin controller nodes > > Hi, > > Merged, but for the future there's no need for you to list the patches in the > tag message, git inserts a list when we merge (--log), and git request-pull > already provides the shortlog. Thanks for the heads up. I've made a note of that for next time. > (512MB RAM on a BMC? That's just insane :). Yep :) It was 1GB in the first spin of the board. Cheers, Joel
RE: [PATCH v2] PCI: pciehp: Optimize PCIe root resume time
> -Original Message-
> From: Lukas Wunner [mailto:lu...@wunner.de]
> Sent: Tuesday, January 17, 2017 9:14 PM
> To: Shankar, Vaibhav
> Cc: Bjorn Helgaas ; Patel, Mayurkumar
> ; Busch, Keith ;
> ying...@kernel.org; yhlu.ker...@gmail.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Vinjamuri, Venkateswarlu V
> ; Pandruvada, Srinivas
>
> Subject: Re: [PATCH v2] PCI: pciehp: Optimize PCIe root resume time
>
> On Wed, Jan 18, 2017 at 01:32:13AM +, Shankar, Vaibhav wrote:
> > > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > > Sent: Wednesday, January 11, 2017 10:37 AM On Mon, Dec 12, 2016 at
> > > 04:32:25PM -0800, Vaibhav Shankar wrote:
> > > > On Apollolake platforms, PCIe rootport takes a long time to resume
> > > > from S3. With 100ms delay before read pci conf, rootport takes
> > > > ~200ms during resume.
> > > >
> > > > commit 2f5d8e4ff947 ("PCI: pciehp: replace unconditional sleep
> > > > with config space access check") is the one that added the 100ms
> > > > delay before reading pci conf.
> > > >
> > > > This patch includes a condition check for 100ms dealy before
> > > > reading PCIe conf. This delay in included only when PCIe
> > > > max_bus_speed > 5.0 GT/s. Root port takes ~16ms during resume.
> > >
> > > This patch reduces the delay by 100ms for devices that don't support
> > > 5.0 GT/s. Please include references to the specs about the
> > > necessary delays and explain why we don't need this 100ms delay.
> > >
> > > Presumably there's something in the spec about needing extra delay
> > > when supporting 5.0 GT/s.
> > >
> > > This is generic code, so we can't make changes based on specific
> > > devices like Apollolake. We have to make the code follow the spec
> > > so it works for everybody.
> > >
> > > > With 100ms delay:
> > > > [ 155.102713] calling :00:14.0+ @ 70, parent: pci:00, cb:
> > > > pci_pm_resume_noirq [ 155.119337] call :00:14.0+ returned 0
> > > > after
> > > > 16231 usecs [ 155.119467] calling :01:00.0+ @ 5845, parent:
> > > > :00:14.0, cb: pci_pm_resume_noirq [ 155.321670] call
> > > > :00:14.0+ returned 0 after 185327 usecs [ 155.321743] calling
> > > > :01:00.0+ @ 5849, parent: :00:14.0, cb: pci_pm_resume
> > > >
> > > > With Condition check:
> > > > [ 36.624709] calling :00:14.0+ @ 4434, parent: pci:00, cb:
> > > pci_pm_resume_noirq
> > > > [ 36.641367] call :00:14.0+ returned 0 after 16263 usecs
> > > > [ 36.652458] calling :00:14.0+ @ 4443, parent: pci:00, cb:
> > > pci_pm_resume
> > > > [ 36.652673] call :00:14.0+ returned 0 after 208 usecs
> > > > [ 36.652863] calling :01:00.0+ @ 4442, parent: :00:14.0, cb:
> > > pci_pm_resume
> > > >
> > > > Signed-off-by: Vaibhav Shankar
> > > > ---
> > > > changes in v2:
> > > > - Modify patch description.
> > > > - Add condition check for 100ms delay before read pci conf as
> > > > suggested by Yinghai.
> > > >
> > > > drivers/pci/hotplug/pciehp_hpc.c | 11 +--
> > > > 1 file changed, 9 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> > > > b/drivers/pci/hotplug/pciehp_hpc.c
> > > > index b57fc6d..2b10e5f 100644
> > > > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > > > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > > > @@ -311,8 +311,15 @@ int pciehp_check_link_status(struct
> > > > controller
> > > *ctrl)
> > > > else
> > > > msleep(1000);
> > > >
> > > > - /* wait 100ms before read pci conf, and try in 1s */
> > > > - msleep(100);
> > > > + /*
> > > > +* If the port supports Link speeds greater than 5.0 GT/s, we
> > > > +* must wait for 100 ms after Link training completes before
> > > > +* sending configuration request.
> > > > +*/
> > > > + if (ctrl->pcie->port->subordinate->max_bus_speed >
> > > PCIE_SPEED_5_0GT)
> > > > + msleep(100);
> > > > +
> > > > + /* try in 1s */
> > > > found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
> > > > PCI_DEVFN(0, 0));
> > > >
> >
> > Please find the details from regarding delays from PCIe spec 3.0:
> >
> > 1) With a Downstream Port that does not support Link speeds greater
> > than 5.0 GT/s, software must wait a minimum of 100 ms before sending
> > a Configuration Request to the device immediately below that Port.
> >
> > 2) With a Downstream Port that supports Link speeds greater than 5.0
> > GT/s, software must wait a minimum of 100 ms after Link training
> > completes before sending a Configuration Request to the device
> > immediately below that Port. Software can determine when Link training
> > completes by polling the Data Link Layer Link Active bit or by setting up an
> associated interrupt (see Section 6.7.3.3).
> >
> > 3) A system must guarantee that all components intended to be software
> > visible at boot time are ready to receive Configu
Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni wrote: > Hello, > > On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote: > >> > > Rob, Mark, any opinion? >> > >> >> Sigh, is how to do compatibles really not yet understood? > > Well, it seems like not everyone necessarily understands what is the > best strategy to adopt (me included). > >> > I agree that a clarification would be good. There are really two >> > options: >> > >> > 1. Have two compatible strings in the DT, the one that matches the >> > exact SoC where the IP is found (first compatible string) and the >> > one that matches some other SoC where the same IP is found (second >> > compatible string). Originally, Linux only supports the second >> > compatible string in its device driver, but if it happens that a >> > difference is found between two IPs that we thought were the same, >> > we can add support for the first compatible string in the driver, >> > with a slightly different behavior. >> >> This. And no wildcards in the compatible string. > > OK. So it means that today we do something like: > > compatible = "baz,foo-12", "baz,foo-00"; > > and support only baz,foo-00 in the driver. If tomorrow we discover > that there is in fact a difference between the two IP blocks, we can > add support for baz,foo-12 in the driver, and handle the differences. > > But then, the DT still contains: > > compatible = "baz,foo-12", "baz,foo-00"; > > and therefore pretends that the IP block is compatible with > "baz,foo-00" which is in fact *not* the case. It was a mistake to > consider it as compatible. So we keep living with a DT that has > incorrect information. I wouldn't say it's a mistake necessarily. The old compatible would probably work to some extent. I'd assume it was tested to some level. Or it could be other changes exposing a difference. >> > 2. Have a single compatible string in the DT, matching the exact SoC >> > where the IP is found. This involves adding immediately this >> > compatible string in the corresponding driver. >> >> I wouldn't object to this from a DT perspective as I have no clue >> generally if IP blocks are "the same" or not. Subsystem maintainers will >> object though. > > Knowing if IP blocks are "the same" is in fact not necessarily trivial. > What appears to be identical IP blocks today might be discovered later > as actually having subtle differences (sometimes not even visible in > the datasheet). Yes, I know. That's exactly when you should have multiple compatibles. Trying to guarantee things are the same is just going to get you in trouble. You only need to figure out if blocks are obviously different and only drop the old compatible in that case. >> > I've not really been able to figure out which of the two options is the >> > most future-proof/appropriate. >> >> They are both future-proof. #2 has the disadvantage of requiring a >> kernel update for a new SoC. > > Which is generally anyway needed because a new SoC will almost always > require some new drivers, adjusting pin-muxing or clock drivers, etc. Yes, but you don't want to have to update every single driver. Rob
[PATCH v1] PM / Domains: Keep the pd status during system PM phases
If a PM domain is powered off before system suspend,
we hope do nothing in system runtime suspend noirq phase
and system runtime resume noirq phase.
This modify is to slove system resume issue for RK3399.
RK3399 SOC pd_gpu have voltage domain vdd_gpu,
so we must follow open vdd_gpu and power on pd_gpu,
power off pd_gpu and disable vdd_gpu.
Fix up in runtime resume noirq phase power on all PDs.
Signed-off-by: Elaine Zhang
---
drivers/base/power/domain.c | 10 +++---
include/linux/pm_domain.h | 1 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 5711708532db..d1ee63e9ee23 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -842,8 +842,10 @@ static int pm_genpd_prepare(struct device *dev)
genpd_lock(genpd);
- if (genpd->prepared_count++ == 0)
+ if (genpd->prepared_count++ == 0) {
genpd->suspended_count = 0;
+ genpd->suspend_power_off = genpd->status == GPD_STATE_POWER_OFF;
+ }
genpd_unlock(genpd);
@@ -877,7 +879,8 @@ static int pm_genpd_suspend_noirq(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+ if (genpd->suspend_power_off ||
+ dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
return 0;
if (genpd->dev_ops.stop && genpd->dev_ops.start) {
@@ -914,7 +917,8 @@ static int pm_genpd_resume_noirq(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+ if (genpd->suspend_power_off ||
+ dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
return 0;
/*
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 81ece61075df..9c0dc364f089 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -62,6 +62,7 @@ struct generic_pm_domain {
unsigned int device_count; /* Number of devices */
unsigned int suspended_count; /* System suspend device counter */
unsigned int prepared_count;/* Suspend counter of prepared devices
*/
+ bool suspend_power_off; /* Power status before system suspend */
int (*power_off)(struct generic_pm_domain *domain);
int (*power_on)(struct generic_pm_domain *domain);
struct gpd_dev_ops dev_ops;
--
1.9.1
linux-next: manual merge of the audit tree with Linus' tree
Hi Paul,
Today's linux-next merge of the audit tree got a conflict in:
include/uapi/linux/audit.h
between commits:
7ff89ac608d9 ("audit: add exclude filter extension to feature bitmap")
dcdaa2f9480c ("Merge branch 'stable-4.10' of
git://git.infradead.org/users/pcmoore/audit")
from Linus' tree and commit:
92c82e8a322b ("audit: add feature audit_lost reset")
from the audit 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 include/uapi/linux/audit.h
index 1c107cb1c83f,3f24110ae63c..
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@@ -330,13 -331,14 +331,16 @@@ enum
#define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT0x0001
#define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME0x0002
#define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x0004
+#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x0008
#define AUDIT_FEATURE_BITMAP_SESSIONID_FILTER 0x0010
+ #define AUDIT_FEATURE_BITMAP_LOST_RESET 0x0020
+
#define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
+AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
- AUDIT_FEATURE_BITMAP_SESSIONID_FILTER)
+ AUDIT_FEATURE_BITMAP_SESSIONID_FILTER | \
+ AUDIT_FEATURE_BITMAP_LOST_RESET)
/* deprecated: AUDIT_VERSION_* */
#define AUDIT_VERSION_LATEST AUDIT_FEATURE_BITMAP_ALL
[PATCH net-next v4] bridge: multicast to unicast
From: Felix Fietkau
Implements an optional, per bridge port flag and feature to deliver
multicast packets to any host on the according port via unicast
individually. This is done by copying the packet per host and
changing the multicast destination MAC to a unicast one accordingly.
multicast-to-unicast works on top of the multicast snooping feature of
the bridge. Which means unicast copies are only delivered to hosts which
are interested in it and signalized this via IGMP/MLD reports
previously.
This feature is intended for interface types which have a more reliable
and/or efficient way to deliver unicast packets than broadcast ones
(e.g. wifi).
However, it should only be enabled on interfaces where no IGMPv2/MLDv1
report suppression takes place. This feature is disabled by default.
The initial patch and idea is from Felix Fietkau.
Signed-off-by: Felix Fietkau
[linus.luess...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust multicast
delivery and multicast at higher rates (e.g. multicast streaming).
In OpenWRT/LEDE the IGMP/MLD report suppression issue is overcome by
the network daemon enabling AP isolation and by that separating all STAs.
Delivery of STA-to-STA IP mulitcast is made possible again by
enabling and utilizing the bridge hairpin mode, which considers the
incoming port as a potential outgoing port, too.
Hairpin-mode is performed after multicast snooping, therefore leading to
only deliver reports to STAs running a multicast router.
Changes in v4:
* readd "From: Felix Fietkau [...]" (missed it again in v3)
Changes in v3:
* fix an uninitialized variable bug introduced in br_multicast_flood()
in v2, found by kbuild test bot
Changes in v2:
* netlink support (thanks Nik!)
* fixed switching between multicast_to_unicast on/off
-> even after toggling an already existing entry would
stale in its mode and would never be replaced
-> new extra check in br_port_group_equal)
* reduced checks in br_multicast_flood() from two to one
to address fast-path concerns (thanks Nik!)
* rev-christmas tree ordering (thanks Nik!)
* removed "net_bridge_port_group::unicast", using
::flags instead (thanks Nik!)
* BR_MULTICAST_TO_UCAST -> BR_MULTICAST_TO_UNICAST
(BR_MULTICAST_FLAST_LEAVE has the same length anyway)
* simplified maybe_deliver_addr()
(no return, no "prev" paramater -> was a NOP anyway)
* added "From: Felix Fietkau [...]"
* added "Signed-off-by: Felix Fietkau [...]"
---
include/linux/if_bridge.h| 1 +
include/uapi/linux/if_link.h | 1 +
net/bridge/br_forward.c | 37 -
net/bridge/br_mdb.c | 2 +-
net/bridge/br_multicast.c| 96
net/bridge/br_netlink.c | 5 +++
net/bridge/br_private.h | 8 ++--
net/bridge/br_sysfs_if.c | 2 +
8 files changed, 121 insertions(+), 31 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index c6587c0..debc9d5 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -46,6 +46,7 @@ struct br_ip_list {
#define BR_LEARNING_SYNC BIT(9)
#define BR_PROXYARP_WIFI BIT(10)
#define BR_MCAST_FLOOD BIT(11)
+#define BR_MULTICAST_TO_UNICASTBIT(12)
#define BR_DEFAULT_AGEING_TIME (300 * HZ)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 6b13e59..4e59565 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -321,6 +321,7 @@ enum {
IFLA_BRPORT_MULTICAST_ROUTER,
IFLA_BRPORT_PAD,
IFLA_BRPORT_MCAST_FLOOD,
+ IFLA_BRPORT_MCAST_TO_UCAST,
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 7cb41ae..a6c8a27 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -174,6 +174,29 @@ static struct net_bridge_port *maybe_deliver(
return p;
}
+static void maybe_deliver_addr(struct net_bridge_port *p, struct sk_buff *skb,
+ const unsigned char *addr, bool local_orig)
+{
+ struct net_device *dev = BR_INPUT_SKB_CB(skb)->brdev;
+ const unsigned char *src = eth_hdr(skb)->h_source;
+
+ if (!should_deliver(p, skb))
+ return;
+
+ /* Even with hairpin, no soliloquies - prevent breaking IPv6 DAD */
+ if (skb->dev == p->dev && ether_addr_equal(src, addr))
+ return;
+
+ skb = skb_copy(skb, GFP_ATOMIC);
+ if (!skb) {
+ dev->stats.tx_dropped++;
+ return;
+ }
+
+ memcpy(eth_hdr(skb)->h_dest, addr, ETH_ALEN);
+ __br_forward(p, skb, local_orig);
+}
+
/* called under rcu_read_lock */
void br_flood(struct net_bridge *br, struct sk_buff *skb,
enum br_pkt_type pkt_type, bool local_rcv, bool
Re: kvm: use-after-free in process_srcu
On Wed, Jan 18, 2017 at 09:53:19AM +0100, Paolo Bonzini wrote: > > > On 17/01/2017 21:34, Paul E. McKenney wrote: > > Do any of your callback functions invoke call_srcu()? (Hey, I have to ask!) > > No, we only use synchronize_srcu and synchronize_srcu_expedited, so our > only callback comes from there. OK, so the next question is whether your code makes sure that all of its synchronize_srcu() and synchronize_srcu_expedited() calls return before the call to cleanup_srcu_struct(). > From: Paolo Bonzini > Subject: [PATCH] srcu: wait for all callbacks before deeming SRCU > "cleaned up" > > Even though there are no concurrent readers, it is possible that the > work item is queued for delayed processing when cleanup_srcu_struct is > called. The work item needs to be flushed before returning, or a > use-after-free can ensue. > > Furthermore, because of SRCU's two-phase algorithm it may take up to > two executions of srcu_advance_batches before all callbacks are invoked. > This can happen if the first flush_delayed_work happens as follows > > srcu_read_lock > process_srcu > srcu_advance_batches > ... > if (!try_check_zero(sp, idx^1, trycount)) > // there is a reader > return; > srcu_invoke_callbacks > ... > > srcu_read_unlock > > cleanup_srcu_struct > > flush_delayed_work > srcu_reschedule > queue_delayed_work > > Now flush_delayed_work returns but srcu_reschedule will *not* have > cleared > sp->running to false. > > > > But srcu_reschedule() sets sp->running to false if there are no callbacks. > > And at that point, there had better be no callbacks. > > There must be no callbacks in batch_queue and in batch_check0, and of > course srcu_invoke_callbacks will have emptied batch_done as well. > > However, I'm not sure that batch_check1 is always empty after the first > flush_delayed_work *if there's no srcu_barrier* in the caller. > srcu_advance_batches's second call to try_check_zero could have failed, > and then srcu_reschedule will requeue the work item to advance > batch_check1 into batch_done. You should only need srcu_barrier() if there were calls to call_srcu(). Given that you only have synchronize_srcu() and synchronize_srcu_expedited(), you -don't- need srcu_barrier(). What you need instead is to make sure that all synchronize_srcu() and synchronize_srcu_expedited() have returned before the call to cleanup_srcu_struct(). > If this is incorrect, then one flush_delayed_work is enough. If it is > correct, the possible alternatives are: > > * srcu_barrier in the caller, flush_delayed_work+WARN_ON(sp->running) in > cleanup_srcu_struct. I strongly dislike this one---because we don't use > call_srcu at all, there should be no reason to use srcu_barrier in KVM > code. Plus I think all other users have the same issue. > > * srcu_barrier+flush_delayed_work+WARN_ON(sp->running) in > cleanup_srcu_struct > > * flush_delayed_work+flush_delayed_work+WARN_ON(sp->running) in > cleanup_srcu_struct > > * while(flush_delayed_work) in cleanup_srcu_struct > > * "while(sp->running) flush_delayed_work" in cleanup_srcu_struct My current thought is flush_delayed_work() followed by a warning if there are any callbacks still posted, and also as you say sp->running. Thoughts? Thanx, Paul
Re: [PATCH v2] LSM: Add /sys/kernel/security/lsm
On Wed, 18 Jan 2017, Casey Schaufler wrote: > Subject: [PATCH v2] LSM: Add /sys/kernel/security/lsm > > I am still tired of having to find indirect ways to determine > what security modules are active on a system. I have added > /sys/kernel/security/lsm, which contains a comma separated > list of the active security modules. No more groping around > in /proc/filesystems or other clever hacks. > > Unchanged from previous versions except for being updated > to the latest security next branch. > > Signed-off-by: Casey Schaufler > Acked-by: John Johansen > Acked-by: Paul Moore > Acked-by: Kees Cook Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris
Re: Potential issues (security and otherwise) with the current cgroup-bpf API
On Wed, Jan 18, 2017 at 4:59 PM, Tejun Heo wrote: > Hello, Andy. > > On Wed, Jan 18, 2017 at 04:18:04PM -0800, Andy Lutomirski wrote: >> To map cgroup -> hook, a simple array in each cgroup structure works. >> To map (cgroup, netns) -> hook function, the natural approach would be >> to have some kind of hash, and that would be slower. This code is >> intended to be *fast*. > > Updating these programs isn't a frequent operation. We can easily > calculate a perfect (or acceptable) hash per-cgroup and rcu swap the > new hashtable. > Fair enough. > >> I think it's currently a broken cgroup feature. I think it could be >> made into a properly working cgroup feature (which I favor) or a >> properly working net feature. Can you articulate why you prefer >> having it be a net feature instead of a cgroup feature? I tend to > > I thought that's what I was doing in the previous message. > >> favor making it be a working cgroup feature (by giving it a file or >> files in cgroupfs and maybe even a controller) because the result >> would have very obvious semantics. > > I'm fine with both directions but one seems far out. I thought you were saying why you thought it wasn't a cgroup feature, but I'm not sure I understand why you thought it shouldn't be a cgroup feature. When I chatted with Alexei, I had the impression that you and he had wanted it to be a cgroup controller but thought it wouldn't work well. I think it could work by making a single socket cgroup controller that handles all cgroup things that are bound to a socket. Using individual files would play nicer with cgroup delegation within a single netns. > >> But maybe this is just a false dichotomy. Could this feature be a >> per-netns configuration where you can give instructions like "run this >> hook if you're in such-and-such netns and in a given cgroup or one of >> its descendents"? This would prevent it from being a direct analogue >> to systemd's RestrictAddressFamilies= option, but that may be okay. >> This would side-step issues in the current code where a hook can't >> rely on ifindex meaning what the hook thinks it means. > > How is this different from making the current code netns aware? The descendents part is important. > >> Actually, I think I like that approach. What if it we had a "socket" >> controller and files like "socket.create_socket", "socket.ingress" and >> "socket.egress"? You could use the bpf() syscall to install a bpf >> filter into "socket.egress" and that filter would filter egress for >> the target cgroup and its descendents on the current netns. As a >> first pass, the netns issue could be sidestepped by making it only >> work in the root netns (i.e. the bpf() call would fail if you're not >> in the root netns and the hooks wouldn't run if you're not in the root >> netns.) It *might* even be possible to retrofit in the socket >> controller by saying that the default hierarchy is used if the socket >> controller isn't mounted. > > I don't know. You're throwing out too many ideas too fast and it's > difficult to keep up with what the differences are between those > ideas. But if we're doing cgroup controllers, shouldn't cgroup ns > support be sufficient? We can consider the product of cgroup and net > namespaces but that doesn't seem necessary given that people usually > set up these namespaces in conjunction. Fair enough. See way below. > >> What *isn't* possible to cleanly fix after the fact is the current >> semantics that cgroup hooks override the hooks in their ancestors. >> IMO that is simply broken. The example you gave (perf_event) is very >> careful not to have this problem. > > That's like saying installing an iptables rule for a more specific > target is broken. As a cgroup controller, it is not an acceptable > behavior given how delegation works. As something similar to > iptables, it is completely fine. Even the xt_cgroup code checks cgroup_is_descendent(). > >> > * My impression with bpf is that while delegation is something >> > theoretically possible it is not something which is gonna take place >> > in any immediate time frame. If I'm wrong on this, please feel free >> > to correct me. >> >> But the issue isn't *BPF* delegation. It's cgroup delegation or netns >> creation, both of which exist today. > > No, the issue is bpf delegation. If bpf were fully delegatable in > practical sense, we could just do straight forward cgroup bpf > controller. Well, we'll have to think about how to chain the programs > which would differ on program type but that shouldn't be too hard. What do you mean by "if bpf were fully delegatable"? I don't know what it would even mean to delegate bpf. I do know what it means to allow programs to create new network namespaces and for cgroup sub-hierarchies to be delegated. > >> > * There are a lot of use cases which can immediately take advantage of >> > cgroup-aware bpf programs operating as proposed. The model is >> > semantically equivalen
Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
Based on Thomas and Peterz feedback Can think of two variants which target:
-Support monitoring and allocating using the same resctrl group.
user can use a resctrl group to allocate resources and also monitor
them (with respect to tasks or cpu)
-allows 'task only' monitoring outside of resctrl. This mode can be used
when user wants to override the RMIDs in the resctrl or when he wants
to monitor more than just the resctrl groups.
option 1> without modifying the resctrl
In this design everything in resctrl interface works like
before (the info, resource group files like task schemata all remain the
same) but the resctrl groups are mapped to one RMID as well as a CLOSID.
But we need a user interface for the user to read the counters. We can
create one file to set monitoring and one
file in resctrl directory which will reflect the counts but may not be
efficient as a lot of times user reads the counts frequently.
For the user interface there may be two options to do this:
1.a> Build a new user mode interface resmon
Since modifying the existing perf to
suit the different h/w architecture seems to not follow the CAT
interface model, it may well be better to have a different and dedicated
interface for the RDT monitoring (just like we had a new fs for CAT)
$resmon -r -s -I
"resctrl group": is the resctrl directory.
"mon_mask: is a bit mask of logical packages which indicates which packages
user is
interested in monitoring.
"time in ms": The time for which the monitoring takes place
(this can potentially be changed to start and stop/read options)
Example 1 (Some examples modeled from resctrl ui documentation)
-
A single socket system which has real-time tasks running on core 4-7 and
non real-time workload assigned to core 0-3. The real-time tasks share
text and data, so a per task association is not required and due to
interaction with the kernel it's desired that the kernel on these cores shares
L3
with the tasks.
# cd /sys/fs/resctrl
# echo "L3:0=3ff" > schemata
core 0-1 are assigned to the new group and make sure that the
kernel and the tasks running there get 50% of the cache.
# echo 03 > p0/cpus
monitor the cpus 0-1 for 5s
# resmon -r p0 -s 1 -I 5000
Example 2
-
A real time task running on cpu 2-3(socket 0) is allocated a dedicated 25% of
the
cache.
# cd /sys/fs/resctrl
# mkdir p1
# echo "L3:0=0f00;1=" > p1/schemata
# echo 5678 > p1/tasks
# taskset -cp 2-3 5678
Monitor the task for 5s on socket zero
# resmon -r p0 -s 1 -I 5000
Example 3
-
sometimes user may just want to profile the cache occupancy first before
assigning any CLOSids. Also this provides an override option where user
can monitor some tasks which have say CLOS 0 that he is about to place
in a CLOSId based on the amount of cache occupancy. This could apply to
the same real time tasks above where user is caliberating the % of cache
thats needed.
monitor a task PIDx on socket 0 for 10s
# resmon -t PIDx -s 1 -I 1
1.b> Add a new option to perf apart from supporting the task monitoring
in perf.
- Monitor a resctrl group.
Introduce a new option for perf "-R" which indicates to monitor a
resctrl group.
$mkdir /sys/fs/resctrl/p1
$echo PID1 > /sys/fs/resctrl/p1/tasks
$echo PID2 > /sys/fs/resctrl/p1/tasks
$perf stat -e llc_occupancy -R p1
would return the count for the resctrl group p1.
- Monitor a task outside of resctrl group ('task only')
In this case , the perf can also monitor individual tasks using the -t
option just like before.
$perf stat -e llc_occupancy -t p1
- Monitor CPUs.
For the example 1 above , perf can be used to monitor the resctrl group
p0
$perf stat -e llc_occupancy -t p0
The issue with both options may be what happens when we run out of
RMIDs. For the resctrl groups , since we know the max groups that can be
created and the # of CLOSIds is very less compared to # of RMIDs we
reserve an RMID for each resctrl group so there is never a case that
RMID is not available for resctrl group.
For task monitoring , it can use the rest of the RMIDs.
Why do we need seperate 'task only' monitoring ?
-
The seperate task monitoring option lets
the user use the RMIDs effectively and not be restricted to # of
CLOSids. Also deal with the scenarios of example 3.
RMID allocation/init
resctrl monitoring:
RMIDs are allocated when CLOSIds are allocated during mkdir. One RMId is
allocated per socket just like CLOSid.
task monitoring:
When task events are created, RMIDs are allocated. Can also do a lazy
allocation of RMIDs when the tasks are actually scheduled in on a
socket.
Kernel Scheduling
-
During ctx switch cqm choses the RMID in the following priority (1-
highest priority)
1. if cpu has a RMID , choose that
2. if the task has a RMID directly tied to it choose that
3. choose the RMID of the task's resctrl
Read
When user calls cqm to retrieve the mo
Re: [PATCH v3 2/2] nsfs: Add an ioctl() to return owner UID of a userns
On 17 January 2017 at 14:19, W. Trevor King wrote: > On Tue, Jan 17, 2017 at 02:03:29PM +1300, Michael Kerrisk (man-pages) wrote: >> + case NS_GET_OWNER_UID: >> + if (ns->ops->type != CLONE_NEWUSER) >> + return -EINVAL; >> + user_ns = container_of(ns, struct user_namespace, ns); >> + argp = (unsigned int __user *) arg; >> + uid = from_kuid_munged(current_user_ns(), user_ns->owner); >> + return put_user(uid, argp); >> … >> +/* Get owner UID for a user namespace */ >> +#define NS_GET_OWNER_UID _IO(NSIO, 0x4) > > The comment here should probably be: > > Get owner UID (in the current user namespace) for a user namespace > > or some such, to convey that current_user_ns is being passed to > from_kuid_munged. Thanks, Trevor. I'll fix that. From a user-space perspective though "in the current user namespace" should be "in the caller's user namespace". Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Kworker with high cpu usage (~80%)
Hello, It has been a while that I noticed that kworker/0:1 eats a lot of CPU on my computer, about ~80%. I never found the real problem, but googling the solution was to disable some GPE interrupt, in my case it is /sys/firmware/acpi/interrupts/gpe13. This is a dirty solution, actually, it hides the problem I think. I have no idea what is the real problem and I would like to understand what is. I'm using kernel 4.9.0-2 now, but it was present on older versions too. I'm running OpenSuse on a Samsung laptop (Intel i5 3rd gen). If someone could point me in the right direction I'll be happy to share more info. Regards, Alexandre Vicenzi
[PATCH 0/2] Add support for RK3288 Tinker board
This patch set add support for RK3288 Tinker board. Tinker board is a credit card size develop board powered by RK3288. Eddie Cai (2): dt-bindings: add Asus Tinker board ARM: dts: rockchip: add dts for RK3288-Tinker board Documentation/devicetree/bindings/arm/rockchip.txt | 3 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-tinker.dts| 556 + 3 files changed, 560 insertions(+) create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts -- 2.7.4
[PATCH 1/2] dt-bindings: add Asus Tinker board
Tinker board is a credit card size develop board designed by Asus. Powered by RK3288. Signed-off-by: Eddie Cai --- Documentation/devicetree/bindings/arm/rockchip.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index cc4ace6..ce1f04a 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -1,5 +1,8 @@ Rockchip platforms device tree bindings --- +- Asus Tinker board +Required root node properties: + - compatible = "rockchip,rk3288-tinker", "rockchip,rk3288"; - Kylin RK3036 board: Required root node properties: -- 2.7.4
[PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board
This patch add basic support for RK3288-Tinker board. We can boot in to rootfs
with this patch.
Signed-off-by: Eddie Cai
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3288-tinker.dts | 556
2 files changed, 557 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..4fc05b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-popmetal.dtb \
rk3288-r89.dtb \
rk3288-rock2-square.dtb \
+ rk3288-tinker.dtb \
rk3288-veyron-brain.dtb \
rk3288-veyron-jaq.dtb \
rk3288-veyron-jerry.dtb \
diff --git a/arch/arm/boot/dts/rk3288-tinker.dts
b/arch/arm/boot/dts/rk3288-tinker.dts
new file mode 100644
index 000..37cb431
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-tinker.dts
@@ -0,0 +1,556 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3288.dtsi"
+
+/ {
+ model = "Rockchip RK3288 Tinker Board";
+ compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
+
+ memory {
+ reg = <0x0 0x8000>;
+ device_type = "memory";
+ };
+
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12500>;
+ clock-output-names = "ext_gmac";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwrbtn>;
+
+ button@0 {
+ gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+ linux,code = <116>;
+ label = "GPIO Key Power";
+ linux,input-type = <1>;
+ gpio-key,wakeup = <1>;
+ debounce-interval = <100>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ pwr-led {
+ gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ act-led {
+ gpios=<&gpio2 3 GPIO_ACTIVE_LOW>;
+ linux,default-trigger="mmc0";
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "rockchip,tinker-codec";
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,cpu {
+ sound-dai = <&i2s>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&hdmi>;
+ };
+ };
+
+
Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master
Hi Chris,
>From this:
>> +
>> +The standard FSI master node
>> +
>> +This node describes a FSI master implmemented fully in hardware
>> +with dedicated input/output pins required for its function (i.e.
>> +not using generic GPIO pins).
>> +Required property:
>> +compatible = "ibm,fsi-master"
and this:
>> +Example:
>> +
>> +fsi-master {
>> +compatible = "ibm,fsi-master-gpio", "ibm,fsi-master";
>
> From the description, these should be mutually exclusive.
I agree with Rob here. The intention is for "ibm,fsi-master" to be an
abstract master -- simply indicating that this node describes a master,
with no specific implementation, and "ibm,fsi-master-gpio" to be a
GPIO-based implementation. A hardware-based FSI master would have a
different compatible value, based on the hardware.
We should remove references to implementations in the "The standard FSI
master node" section, because this is independent of implementation.
>> +clk-gpios = <&gpio 0>, <&gpio 6>;
>> +data-gpios = <&gpio 1>, <&gpio 7>;
>> +enable-gpios = <&gpio 2>, <&gpio 8>;
>> +trans-gpios = <&gpio 3>, <&gpio 9>;
>> +mux-gpios = <&gpio 4>, <&gpio 10>;
Do we support multiple-link masters? This example implies a 2-link
master.
Cheers,
Jeremy
Re: [PATCH v4 15/15] lockdep: Crossrelease feature documentation
On Wed, Jan 18, 2017 at 03:12:55PM +0100, Peter Zijlstra wrote: > On Wed, Jan 18, 2017 at 09:14:59PM +0900, byungchul.park wrote: > > > +Example 3: > > + > > + CONTEXT X CONTEXT Y > > + - - > > + mutex_lock A > > + mutex_lock A > > + mutex_unlock A > > + wait_for_complete B /* DEADLOCK */ > > Each line (across both columns) is a distinct point in time after the > line before. > > Therefore, this states that "mutex_unlock A" happens before > "wait_for_completion B", which is clearly impossible. I meant that all statements below mutex_lock A in X are already impossible. So the order of those are meaningless. But.. I got what you mean. > You don't have to remove everything after mutex_lock A, but the unlock > must not happen before context Y does the unlock. I will apply what you and boqun recommanded, from the next spin. Thank you, Byungchul
Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote: > On Tue, 17 Jan 2017, Shivappa Vikas wrote: >> On Tue, 17 Jan 2017, Thomas Gleixner wrote: >> > On Fri, 6 Jan 2017, Vikas Shivappa wrote: >> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints >> > > zeros or arbitrary numbers. >> > > >> > > Fix: Patches fix this by just throwing an error if the mode is not >> > > supported. >> > > The modes supported is task monitoring and cgroup monitoring. >> > > Also the per package >> > > data for say socket x is returned with the -C -G cgrpy >> > > option. >> > > The systemwide data can be looked up by monitoring root cgroup. >> > >> > Fine. That just lacks any comment in the implementation. Otherwise I would >> > not have asked the question about cpu monitoring. Though I fundamentaly >> > hate the idea of requiring cgroups for this to work. >> > >> > If I just want to look at CPU X why on earth do I have to set up all that >> > cgroup muck? Just because your main focus is cgroups? >> >> The upstream per cpu data is broken because its not overriding the other task >> event RMIDs on that cpu with the cpu event RMID. >> >> Can be fixed by adding a percpu struct to hold the RMID thats affinitized >> to the cpu, however then we miss all the task llc_occupancy in that - still >> evaluating it. > > The point here is that CQM is closely connected to the cache allocation > technology. After a lengthy discussion we ended up having > > - per cpu CLOSID > - per task CLOSID > > where all tasks which do not have a CLOSID assigned use the CLOSID which is > assigned to the CPU they are running on. > > So if I configure a system by simply partitioning the cache per cpu, which > is the proper way to do it for HPC and RT usecases where workloads are > partitioned on CPUs as well, then I really want to have an equaly simple > way to monitor the occupancy for that reservation. > > And looking at that from the CAT point of view, which is the proper way to > do it, makes it obvious that CQM should be modeled to match CAT. > > So lets assume the following: > >CPU 0-3 default CLOSID 0 >CPU 4 CLOSID 1 >CPU 5 CLOSID 2 >CPU 6 CLOSID 3 >CPU 7 CLOSID 3 > >T1 CLOSID 4 >T2 CLOSID 5 >T3 CLOSID 6 >T4 CLOSID 6 > >All other tasks use the per cpu defaults, i.e. the CLOSID of the CPU >they run on. > > then the obvious basic monitoring requirement is to have a RMID for each > CLOSID. > > So when I monitor CPU4, i.e. CLOSID 1 and T1 runs on CPU4, then I do not > care at all about the occupancy of T1 simply because that is running on a > seperate reservation. Trying to make that an aggregated value in the first > place is completely wrong. If you want an aggregate, which is pretty much > useless, then user space tools can generate it easily. > > The whole approach you and David have taken is to whack some desired cgroup > functionality and whatever into CQM without rethinking the overall > design. And that's fundamentaly broken because it does not take cache (and > memory bandwidth) allocation into account. > > I seriously doubt, that the existing CQM/MBM code can be refactored in any > useful way. As Peter Zijlstra said before: Remove the existing cruft > completely and start with completely new design from scratch. > > And this new design should start from the allocation angle and then add the > whole other muck on top so far its possible. Allocation related monitoring > must be the primary focus, everything else is just tinkering. > If in this email you meant "Resource group" where you wrote "CLOSID", then please disregard my previous email. It seems like a good idea to me to have a 1:1 mapping between RMIDs and "Resource groups". The distinction matter because changing the schemata in the resource group would likely trigger a change of CLOSID, which is useful. Thanks, David
Re: writev error codes
Hello Michal,
On 19 January 2017 at 04:44, Michal Hocko wrote:
> Hi,
> we have noticed that one of the LTP tests started to fail after
> 99526912c934 ("fix iov_iter_fault_in_readable()"). The code has expected
> EINVAL while it gets EFAULT. I believe the new behavior is reasonable,
> but checking the man 2 writev, there is no mention about EFAULT,
> and other errnos for that matter, so it seems this is rather under
> documented and it can confuse users. LTP has been fixed in the meantime
> [1] but this might come unexpected to others.
>
> In principle writev as a write
> "multiplier" should be allowed all the error codes that write(2) allows,
> right? I am not sure how we should reflect that. Either c&p what we have
> in man 2 write or put a reference to it and only describe writev
> specific, if there are any (I haven't checked that).
>
> [1]
> https://github.com/linux-test-project/ltp/commit/db19194527060a962955a7db54a2f5710e69bec9
Perhaps I am misunderstanding you, but in the writev(2) page there is the text:
ERRORS
The errors are as given for read(2) and write(2). Furthermore,
preadv(), preadv2(), pwritev(), and pwritev2() can also fail for
the same reasons as lseek(2).
And in the write(2) page, we have:
EFAULT buf is outside your accessible address space.
Does this not cover the case you describe?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
[PATCH v2 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
This patch adds watchdog controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/zx2967_wdt.c | 383 ++
3 files changed, 394 insertions(+)
create mode 100644 drivers/watchdog/zx2967_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b5..05093a2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called aspeed_wdt.
+config ZX2967_WATCHDOG
+ tristate "ZTE zx2967 SoCs watchdog support"
+ depends on ARCH_ZX
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer
+ in ZTE zx2967 SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called zx2967_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e..bf2d296 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
+obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
new file mode 100644
index 000..35eaecd
--- /dev/null
+++ b/drivers/watchdog/zx2967_wdt.c
@@ -0,0 +1,383 @@
+/*
+ * watchdog driver for ZTE's zx2967 family
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ZX2967_WDT_CFG_REG 0x4
+#define ZX2967_WDT_LOAD_REG0x8
+#define ZX2967_WDT_REFRESH_REG 0x18
+#define ZX2967_WDT_START_REG 0x1c
+
+#define ZX2967_WDT_REFRESH_MASK0x3f
+
+#define ZX2967_WDT_CFG_DIV(n) n) & 0xff) - 1) << 8)
+#define ZX2967_WDT_START_EN0x1
+
+#define ZX2967_WDT_WRITEKEY0x1234
+
+#define ZX2967_WDT_DIV_DEFAULT 16
+#define ZX2967_WDT_DEFAULT_TIMEOUT 32
+#define ZX2967_WDT_MIN_TIMEOUT 1
+#define ZX2967_WDT_MAX_TIMEOUT 500
+#define ZX2967_WDT_MAX_COUNT 0x
+
+#define ZX2967_WDT_FLAG_REBOOT_MON (1 << 0)
+
+#define ZX2967_RESET_MASK_REG 0xb0
+
+struct zx2967_wdt {
+ struct device *dev;
+ struct clk *clock;
+ void __iomem*reg_base;
+ unsigned intconf;
+ unsigned intload;
+ unsigned intflags;
+ struct watchdog_device wdt_device;
+ struct notifier_block restart_handler;
+ struct notifier_block reboot_handler;
+};
+
+#define zx2967_wdt_read_reg(r) readl_relaxed(r)
+
+static inline void
+zx2967_wdt_write_reg(u32 val, void __iomem *addr)
+{
+ writel_relaxed(val | ZX2967_WDT_WRITEKEY, addr);
+}
+
+static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_REFRESH_REG);
+ val ^= ZX2967_WDT_REFRESH_MASK;
+ zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_REFRESH_REG);
+}
+
+static unsigned int
+__zx2967_wdt_set_timeout(struct zx2967_wdt *wdt, unsigned int timeout)
+{
+ unsigned int freq = clk_get_rate(wdt->clock);
+ unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
+ unsigned int count;
+
+ count = timeout * freq;
+ if (count > divisor * ZX2967_WDT_MAX_COUNT)
+ divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
+ count = DIV_ROUND_UP(count, divisor);
+ zx2967_wdt_write_reg(ZX2967_WDT_CFG_DIV(divisor),
+wdt->reg_base + ZX2967_WDT_CFG_REG);
+ zx2967_wdt_write_reg(count, wdt->reg_base + ZX2967_WDT_LOAD_REG);
+ zx2967_wdt_refresh(wdt);
+ wdt->load = count;
+
+ return (count * divisor) / freq;
+}
+
+static int zx2967_wdt_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ if (watchdog_timeout_invalid(&wdt->wdt_device, timeout)) {
+ dev_err(wdt->dev, "timeout %d is invalid\n", timeout);
+ return -EINVAL;
+ }
+
+ wdd->timeout = __zx2967_wdt_set_timeout(wdt, timeout);
+
+ return 0;
+}
+
+static void __zx2967_wdt_start(struct zx2967_wdt *wdt
[PATCH v2 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
Add the zx2967 watchdog controller driver as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index edfdea3..275c434 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1990,11 +1990,13 @@ F: drivers/clk/zte/ F: drivers/reset/reset-zx2967.c F: drivers/soc/zte/ F: drivers/thermal/zx* +F: drivers/watchdog/zx2967_wdt.c F: Documentation/devicetree/bindings/arm/zte.txt F: Documentation/devicetree/bindings/clock/zx296702-clk.txt F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt F: Documentation/devicetree/bindings/soc/zte/ F: Documentation/devicetree/bindings/thermal/zx* +F: Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt F: include/dt-bindings/soc/zx*.h ARM/ZYNQ ARCHITECTURE -- 2.7.4
[PATCH v2 1/3] dt: bindings: add documentation for zx2967 family watchdog controller
This patch adds dt-binding documentation for zx2967 family
watchdog controller.
Signed-off-by: Baoyou Xie
---
.../bindings/watchdog/zte,zx2967-wdt.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
new file mode 100644
index 000..6e35ce7
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
@@ -0,0 +1,32 @@
+ZTE zx2967 Watchdog timer
+
+Required properties:
+
+- compatible : should be one of the following.
+ * zte,zx296718-wdt
+- reg : Specifies base physical address and size of the registers.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "wdtclk" for the watchdog clock.
+- resets : Reference to the reset controller controlling the watchdog
+ controller.
+- reset-names : Must include the following entries:
+ * wdtrst
+
+Optional properties:
+
+- wdt-reset-sysctrl : should include following fields.
+ * phandle of aon-sysctrl.
+ * configuare value that be wrote to aon-sysctrl.
+ * bit mask, corresponding bits will be affected.
+
+Example:
+
+wdt_ares: watchdog@1465000 {
+ compatible = "zte,zx296718-wdt";
+ reg = <0x1465000 0x1000>;
+ clocks = <&topcrm WDT_WCLK>;
+ clock-names = "wdtclk";
+ resets = <&toprst 35>;
+ reset-names = "wdtrst";
+ wdt-reset-sysctrl = <&aon_sysctrl 1 0x115>;
+};
--
2.7.4
Re: [PATCH v3 16/24] media: Add i.MX media core driver
On 01/14/2017 02:42 PM, Steve Longerbeam wrote:
+/* parse inputs property from a sensor node */
+static void of_parse_sensor_inputs(struct imx_media_dev *imxmd,
+ struct imx_media_subdev *sensor,
+ struct device_node *sensor_np)
+{
+ struct imx_media_sensor_input *sinput = &sensor->input;
+ int ret, i;
+
+ for (i = 0; i < IMX_MEDIA_MAX_SENSOR_INPUTS; i++) {
+ const char *input_name;
+ u32 val;
+
+ ret = of_property_read_u32_index(sensor_np, "inputs", i, &val);
+ if (ret)
+ break;
+
+ sinput->value[i] = val;
+
+ ret = of_property_read_string_index(sensor_np, "input-names",
+ i, &input_name);
+ /*
+* if input-names not provided, they will be set using
+* the subdev name once the sensor is known during
+* async bind
+*/
+ if (!ret)
+ strncpy(sinput->name[i], input_name,
+ sizeof(sinput->name[i]));
+ }
+
+ sinput->num = i;
+
+ /* if no inputs provided just assume a single input */
+ if (sinput->num == 0)
+ sinput->num = 1;
+}
This should be parsed by the sensor driver, not imx-media.
you're probably right. I'll submit a patch for adv7180.c.
Actually, the problem here is that this parses an input routing value to
pass to s_routing, and an input name string. There would need to be
another subdev callback, maybe enum_imput, that would return this
information for the bridge driver, if this info were to be parsed and
maintained by the sensor.
But this info should really be known and parsed by the bridge anyway,
because as the header for s_routing states,
"An i2c device shouldn't know about whether an input pin is connected
to a Composite connector, because on another board or platform it
might be connected to something else entirely. The calling driver is
responsible for mapping a user-level input to the right pins on the i2c
device."
Steve
RE: [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process
> On Wed, Jan 18, 2017 at 04:56:58AM +, Li, Liang Z wrote:
> > > > - virtqueue_add_outbuf(vq, &sg, 1, vb, GFP_KERNEL);
> > > > - virtqueue_kick(vq);
> > > > +static void do_set_resp_bitmap(struct virtio_balloon *vb,
> > > > + unsigned long base_pfn, int pages)
> > > >
> > > > - /* When host has read buffer, this completes via balloon_ack */
> > > > - wait_event(vb->acked, virtqueue_get_buf(vq, &len));
> > > > +{
> > > > + __le64 *range = vb->resp_data + vb->resp_pos;
> > > >
> > > > + if (pages > (1 << VIRTIO_BALLOON_NR_PFN_BITS)) {
> > > > + /* when the length field can't contain pages, set it to
> > > > 0 to
> > >
> > > /*
> > > * Multi-line
> > > * comments
> > > * should look like this.
> > > */
> > >
> > > Also, pls start sentences with an upper-case letter.
> > >
> >
> > Sorry for that.
> >
> > > > +* indicate the actual length is in the next __le64;
> > > > +*/
> > >
> > > This is part of the interface so should be documented as such.
> > >
> > > > + *range = cpu_to_le64((base_pfn <<
> > > > + VIRTIO_BALLOON_NR_PFN_BITS) | 0);
> > > > + *(range + 1) = cpu_to_le64(pages);
> > > > + vb->resp_pos += 2;
> > >
> > > Pls use structs for this kind of stuff.
> >
> > I am not sure if you mean to use
> >
> > struct range {
> > __le64 pfn: 52;
> > __le64 nr_page: 12
> > }
> > Instead of the shift operation?
>
> Not just that. You want to add a pages field as well.
>
pages field? Could you give more hints?
> Generally describe the format in the header in some way so host and guest
> can easily stay in sync.
'VIRTIO_BALLOON_NR_PFN_BITS' is for this purpose and it will be passed to the
related function in page_alloc.c as a parameter.
Thanks!
Liang
> All the pointer math and void * means we get zero type safety and I'm not
> happy about it.
>
> It's not good that virtio format seeps out to page_alloc anyway.
> If unavoidable it is not a good idea to try to hide this fact, people will
> assume
> they can change the format at will.
>
> --
> MST
New attempt at adding an disassembler to perf
A native disassembler in perf is very useful, in particular with perf script to trace instruction streams, but also for other analysis. Previously I attempted to do this using the udis86 library, but that was rejected because: - udis86 was not maintained anymore and lacking recent instructions - udis86 is dynamically linked and gives a runtime dependency. Doing this needs a full disassembler, not just a decoder, so the existing instruction decoder cannot be used without major changes. This patchkit addresses these issues. Intel recently released an open source version of the XED disassembler library, which is used in many other Intel software. It is very well maintained, uptodate, and supports static linking, so there is no runtime dependency. This version adds XED support to perf, and uses it to implement assembler output in perf script. It also fixes a range of issues in the previous version, see the individual change logs. Available in git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git perf/xed-6 v1: First post of XED version v2: Change probing to not be default and support XED_DIR. Other cleanups based on review. v3: Use FEATURE_FLAGS_BASIC for probing -Andi
[PATCH 5/5] perf, tools, script: Add brstackasm output for branch stacks
From: Andi Kleen Implement printing full disassembled sequences for branch stacks in perf script. This allows to directly print hot paths for individual samples, together with branch misprediction and cycle count / IPC information if available (on Skylake systems). This only works when no special branch filters are specified. % perf record -b ... % perf script -F brstackasm ... 55b55d1147d0pushq %rbp 55b55d1147d1pushq %r15 55b55d1147d3pushq %r14 55b55d1147d5pushq %r13 55b55d1147d7pushq %r12 55b55d1147d9pushq %rbx 55b55d1147dasub $0x18, %rsp 55b55d1147demov %r8, %r13 55b55d1147e1mov %rcx, %rbp 55b55d1147e4mov %rdx, %r14 55b55d1147e7mov %rsi, %r15 55b55d1147eamov %rdi, %rbx 55b55d1147edmovl $0x0, 0xc(%rsp) 55b55d1147f5movq (%rbp), %rax 55b55d1147f9test $0x1, %al 55b55d1147fbjnz 0x55b55d114890 # PRED 4 cycles 3.75 IPC 55b55d114890mov %eax, %ecx 55b55d114892and $0x3, %ecx 55b55d114895cmp $0x1, %rcx 55b55d114899jnz 0x55b55d1148f8 55b55d11489bmovq -0x1(%rax), %rcx 55b55d11489fcmpb $0x81, 0xb(%rcx) 55b55d1148a3jnz 0x55b55d1148fe # PRED 1 cycles 6.00 IPC ... Occasionally the path does not reach up to the sample IP, as the LBRs may be frozen before executing a final jump. In this case we print a special message. v2: Use low level abstracted disassembler interface. Print symbols and source lines as labels. Print first jump in LBR too. Patch up blocks with filtered ring transfers. Show IPC Lots of cleanups and improvements. v3: Print special message for branches frozen early. Signed-off-by: Andi Kleen --- tools/perf/Documentation/perf-script.txt | 13 +- tools/perf/builtin-script.c | 267 +++ 2 files changed, 278 insertions(+), 2 deletions(-) diff --git a/tools/perf/Documentation/perf-script.txt b/tools/perf/Documentation/perf-script.txt index 497989ea9768..15a80815941e 100644 --- a/tools/perf/Documentation/perf-script.txt +++ b/tools/perf/Documentation/perf-script.txt @@ -116,7 +116,7 @@ OPTIONS --fields:: Comma separated list of fields to print. Options are: comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff, -srcline, period, iregs, brstack, brstacksym, flags, bpf-output, asm. +srcline, period, iregs, brstack, brstacksym, flags, bpf-output, asm, brstackasm, callindent, insn, insnlen. Field list can be prepended with the type, trace, sw or hw, to indicate to which event type the field list applies. e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace @@ -189,17 +189,22 @@ OPTIONS i.e., -F "" is not allowed. The brstack output includes branch related information with raw addresses using the - /v/v/v/v/ syntax in the following order: + /v/v/v/v/cycles syntax in the following order: FROM: branch source instruction TO : branch target instruction M/P/-: M=branch target mispredicted or branch direction was mispredicted, P=target predicted or direction predicted, -=not supported X/- : X=branch inside a transactional region, -=not in transaction region or not supported A/- : A=TSX abort entry, -=not aborted region or not supported + cycles The brstacksym is identical to brstack, except that the FROM and TO addresses are printed in a symbolic form if possible. When asm is specified the assembler instruction of each sample is printed in disassembled form. + When brstackasm is specified the full assembler sequences of branch sequences for each sample + is printed. This is the full execution path leading to the sample. This is only supported when the + sample was recorded with perf record -b or -j any. + -k:: --vmlinux=:: vmlinux pathname @@ -301,6 +306,10 @@ include::itrace.txt[] stop time is not given (i.e, time string is 'x.y,') then analysis goes to end of file. +--max-blocks:: + Set the maximum number of program blocks to print with brstackasm for + each sample. + SEE ALSO linkperf:perf-record[1], linkperf:perf-script-perl[1], diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c index 7a09c4f7df3f..01097e12162d 100644 --- a/tools/perf/builtin-script.c +++ b/tools/perf/builtin-script.c @@ -43,6 +43,7 @@ static bool nanosecs; static const char *cpu_list; static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS); static struct perf_stat_config stat_config; +static int
[PATCH 4/5] perf, tools, script: Add support for printing assembler
From: Andi Kleen
When dumping PT traces with perf script it is very useful to see the
assembler for each sample, so that it is easily possible to follow
the control flow.
As using objdump is difficult and inefficient from perf script this
patch uses the Intel xed library to implement assembler output.
The library can be downloaded from http://github.com/intelxed/xed
The previous version of this patch used udis86, but was
rejected because udis86 was unmaintained and a runtime dependency.
Using the recently released xed avoids both of these problems:
- XED is well maintained and used by many Intel tools
- XED is linked statically so there is no runtime dependency.
The library is probed as an external dependency in the usual way. Then perf
script calls into it when needed, and handles callbacks to resolve
symbols.
% perf record -e intel_pt//u true
% perf script -F sym,symoff,ip,asm --itrace=i0ns | head
7fc7188b4190 _start+0x0mov %rsp, %rdi
7fc7188b4193 _start+0x3call _dl_start
7fc7188b7710 _dl_start+0x0 push %rbp
7fc7188b7711 _dl_start+0x1 mov %rsp, %rbp
7fc7188b7714 _dl_start+0x4 push %r15
7fc7188b7716 _dl_start+0x6 push %r14
7fc7188b7718 _dl_start+0x8 push %r13
7fc7188b771a _dl_start+0xa push %r12
7fc7188b771c _dl_start+0xc mov %rdi, %r12
7fc7188b771f _dl_start+0xf push %rbx
v2:
Converted to use XED instead of udis86.
Separate disassembler interface into separate arch specific file.
Lots of cleanups and improvements.
Cc: adrian.hun...@intel.com
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-script.txt | 4 +-
tools/perf/builtin-script.c | 72 +++-
2 files changed, 64 insertions(+), 12 deletions(-)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index 4ed5f239ba7d..497989ea9768 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -116,7 +116,7 @@ OPTIONS
--fields::
Comma separated list of fields to print. Options are:
comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
-srcline, period, iregs, brstack, brstacksym, flags, bpf-output,
+srcline, period, iregs, brstack, brstacksym, flags, bpf-output, asm.
callindent, insn, insnlen. Field list can be prepended with the type,
trace, sw or hw,
to indicate to which event type the field list applies.
e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace
@@ -198,6 +198,8 @@ OPTIONS
The brstacksym is identical to brstack, except that the FROM and TO
addresses are printed in a symbolic form if possible.
+ When asm is specified the assembler instruction of each sample is
printed in disassembled form.
+
-k::
--vmlinux=::
vmlinux pathname
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index c0783b4f7b6c..7a09c4f7df3f 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -28,6 +28,7 @@
#include
#include "asm/bug.h"
#include "util/mem-events.h"
+#include "util/dis.h"
static char const *script_name;
static char const *generate_script_lang;
@@ -69,6 +70,7 @@ enum perf_output_field {
PERF_OUTPUT_CALLINDENT = 1U << 20,
PERF_OUTPUT_INSN= 1U << 21,
PERF_OUTPUT_INSNLEN = 1U << 22,
+ PERF_OUTPUT_ASM = 1U << 23,
};
struct output_option {
@@ -98,6 +100,7 @@ struct output_option {
{.str = "callindent", .field = PERF_OUTPUT_CALLINDENT},
{.str = "insn", .field = PERF_OUTPUT_INSN},
{.str = "insnlen", .field = PERF_OUTPUT_INSNLEN},
+ {.str = "asm", .field = PERF_OUTPUT_ASM},
};
/* default set to maintain compatibility with current format */
@@ -292,7 +295,11 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
"selected. Hence, no address to lookup the source line
number.\n");
return -EINVAL;
}
-
+ if (PRINT_FIELD(ASM) && !PRINT_FIELD(IP)) {
+ pr_err("Display of assembler requested but sample IP is not\n"
+ "selected.\n");
+ return -EINVAL;
+ }
if ((PRINT_FIELD(PID) || PRINT_FIELD(TID)) &&
perf_evsel__check_stype(evsel, PERF_SAMPLE_TID, "TID",
PERF_OUTPUT_TID|PERF_OUTPUT_PID))
@@ -436,6 +443,39 @@ static void print_sample_iregs(struct perf_sample *sample,
}
}
+static void print_sample_asm(union perf_event *event,
+struct perf_sample *sample,
+struct thread *thread,
+struct addr_location *al,
+struct machine *machine)
+{
+ struct perf_dis x;
+ u8 buffer[32];
+ int len;
+ u64 offset;
+
+ x.thread = thread;
+ x.cpumode = event->header.m
Re: [PATCH 00/33] Input: Automated coccinelle cleanup
On Wed, 2017-01-18 at 09:46 -0800, Guenter Roeck wrote: > The conversion was done automatically with coccinelle using several semantic > patches. The semantic patches and the scripts used to generate this commit > log are available at https://github.com/groeck/coccinelle-patches. It'd be better to include the script in this 0/n patch so that if github entry changes, the 0/n patch is useful.
Re: [PATCH v11 10/12] drm/mediatek: add non-continuous clock mode and EOT packet control
Hi, YT: On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote: > This patch will update dsi clock control method. > 1. dsi non-continue clock mode will enhance antistatic effect for panel > 2. EOT packet control will judge whether dsi send end of packet or not > by customize > > Signed-off-by: shaoming chen > Signed-off-by: YT Shen Acked-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index b3c7fd8..85f22d2 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c > @@ -431,6 +431,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi) > break; > } > > + tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6; > + tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3; > + > writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL); > } >
[PATCH 1/5] perf, tools: Add probing for xed
From: Andi Kleen
Add autoprobing for the xed disassembler library.
Can be downloaded from https://github.com/intelxed/xed
v2: Hide. Require XED=1 to enable. Add XED_DIR
v3: Remove -lxed from probe all. Don't touch FEATURE_DISPLAY.
v4: Move to FEATURE_FLAGS_BASIC
Signed-off-by: Andi Kleen
---
tools/build/Makefile.feature | 4 +++-
tools/build/feature/Makefile | 6 +-
tools/build/feature/test-all.c | 5 +
tools/build/feature/test-xed.c | 9 +
tools/perf/Makefile.config | 16
tools/perf/Makefile.perf | 3 +++
6 files changed, 41 insertions(+), 2 deletions(-)
create mode 100644 tools/build/feature/test-xed.c
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index e3fb5ecbdcb6..c5012b8a49fe 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -63,7 +63,8 @@ FEATURE_TESTS_BASIC := \
lzma\
get_cpuid \
bpf \
-sdt
+sdt\
+xed
# FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list
# of all feature tests
@@ -140,6 +141,7 @@ ifeq ($(feature-all), 1)
$(call feature_check,compile-x32)
$(call feature_check,bionic)
$(call feature_check,libbabeltrace)
+ $(call feature_check,xed)
else
$(foreach feat,$(FEATURE_TESTS),$(call feature_check,$(feat)))
endif
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index b564a2eea039..4f1aa82b867a 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -48,7 +48,8 @@ FILES= \
test-get_cpuid.bin \
test-sdt.bin \
test-cxx.bin \
- test-jvmti.bin
+ test-jvmti.bin\
+ test-xed.bin
FILES := $(addprefix $(OUTPUT),$(FILES))
@@ -123,6 +124,9 @@ $(OUTPUT)test-numa_num_possible_cpus.bin:
$(OUTPUT)test-libunwind.bin:
$(BUILD) -lelf
+$(OUTPUT)test-xed.bin:
+ $(BUILD) -lxed
+
$(OUTPUT)test-libunwind-debug-frame.bin:
$(BUILD) -lelf
$(OUTPUT)test-libunwind-x86.bin:
diff --git a/tools/build/feature/test-all.c b/tools/build/feature/test-all.c
index 699e43627397..4a6dd1d1ff49 100644
--- a/tools/build/feature/test-all.c
+++ b/tools/build/feature/test-all.c
@@ -149,6 +149,10 @@
# include "test-sdt.c"
#undef main
+#define main main_test_xed
+# include "test-xed.c"
+#endif
+
int main(int argc, char *argv[])
{
main_test_libpython();
@@ -183,6 +187,7 @@ int main(int argc, char *argv[])
main_test_bpf();
main_test_libcrypto();
main_test_sdt();
+ main_test_xed();
return 0;
}
diff --git a/tools/build/feature/test-xed.c b/tools/build/feature/test-xed.c
new file mode 100644
index ..ef9aebf1559d
--- /dev/null
+++ b/tools/build/feature/test-xed.c
@@ -0,0 +1,9 @@
+#include
+#include
+#include
+
+int main(void)
+{
+ xed_tables_init();
+ return 0;
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 03cf947755b9..9996027e7a52 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -684,6 +684,22 @@ ifndef NO_ZLIB
endif
endif
+ifdef XED
+ ifdef XED_DIR
+FEATURE_CHECK_CFLAGS-xed := -I $(XED_DIR)/include
+# override for lib64?
+FEATURE_CHECK_LDFLAGS-xed := -L $(XED_DIR)/lib -lxed
+ else
+FEATURE_CHECK_CFLAGS-xed :=
+FEATURE_CHECK_LDFLAGS-xed := -lxed
+ endif
+ $(call feature_check,xed)
+ ifeq ($(feature-xed), 1)
+EXTLIBS += -lxed
+$(call detected,CONFIG_XED)
+ endif
+endif
+
ifndef NO_LZMA
ifeq ($(feature-lzma), 1)
CFLAGS += -DHAVE_LZMA_SUPPORT
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 4da19b6ba94a..f6760309edd3 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -84,6 +84,9 @@ include ../scripts/utilities.mak
# Define NO_SDT if you do not want to define SDT event in perf tools,
# note that it doesn't disable SDT scanning support.
#
+# Define XED=1 to build WITH the XED disassembler for perf script
+# Can also set XED_DIR=/path to set XED directory.
+#
# Define FEATURES_DUMP to provide features detection dump file
# and bypass the feature detection
#
--
2.9.3
[PATCH 2/5] perf, tools: Add one liner warning for disabled features
From: Andi Kleen Add a one liner warning for perf features that need to be enabled explicitly by the user, so that they know they are missing something. Currently enabled for XED and BABELTRACE. Signed-off-by: Andi Kleen --- tools/perf/Makefile.config | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index 9996027e7a52..39b90ffd9412 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -65,6 +65,8 @@ ifneq ($(ARCH),$(filter $(ARCH),x86 arm)) NO_LIBDW_DWARF_UNWIND := 1 endif +DISABLED_FEATURES = + ifeq ($(LIBUNWIND_LIBS),) NO_LIBUNWIND := 1 endif @@ -698,6 +700,8 @@ ifdef XED EXTLIBS += -lxed $(call detected,CONFIG_XED) endif +else + DISABLED_FEATURES += XED endif ifndef NO_LZMA @@ -772,6 +776,8 @@ ifdef LIBBABELTRACE else msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev); endif +else + DISABLED_FEATURES += LIBBABELTRACE endif ifndef NO_AUXTRACE @@ -843,6 +849,10 @@ ifdef LIBCLANGLLVM endif endif +ifneq ($(DISABLED_FEATURES),) + $(warning Disabled features, need explicit enabling by user: $(DISABLED_FEATURES)) +endif + # Among the variables below, these: # perfexecdir # template_dir -- 2.9.3
[PATCH 3/5] perf, tools: Add disassembler for x86 using the XED library
From: Andi Kleen
Add a generic disassembler function for x86 using the XED library,
and a fallback function for architectures that don't implement one.
Other architectures can implement their own disassembler functions.
The previous version of this patch used udis86, but was
rejected because udis86 was unmaintained and a runtime dependency.
Using the recently released xed avoids both of these problems:
- XED is well maintained, uptodate, and used by many Intel tools
- XED is linked statically so there is no runtime dependency.
The XED library can be downloaded from http://github.com/intelxed/xed
v2: Clean up includes.
Signed-off-by: Andi Kleen
---
tools/perf/arch/x86/util/Build | 1 +
tools/perf/arch/x86/util/dis.c | 86 ++
tools/perf/util/Build | 1 +
tools/perf/util/dis.c | 15
tools/perf/util/dis.h | 20 ++
5 files changed, 123 insertions(+)
create mode 100644 tools/perf/arch/x86/util/dis.c
create mode 100644 tools/perf/util/dis.c
create mode 100644 tools/perf/util/dis.h
diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index f95e6f46ef0d..93490009ea6a 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -14,3 +14,4 @@ libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
libperf-$(CONFIG_AUXTRACE) += auxtrace.o
libperf-$(CONFIG_AUXTRACE) += intel-pt.o
libperf-$(CONFIG_AUXTRACE) += intel-bts.o
+libperf-$(CONFIG_XED) += dis.o
diff --git a/tools/perf/arch/x86/util/dis.c b/tools/perf/arch/x86/util/dis.c
new file mode 100644
index ..39703512fe17
--- /dev/null
+++ b/tools/perf/arch/x86/util/dis.c
@@ -0,0 +1,86 @@
+/* Disassembler using the XED library */
+#include "perf.h"
+#include "util/session.h"
+#include "util/symbol.h"
+#include "util/thread.h"
+#include "util/dis.h"
+
+#include
+#include
+#include
+
+static int dis_resolve(xed_uint64_t addr, char *buf, xed_uint32_t buflen,
+ xed_uint64_t *off, void *data)
+{
+ struct perf_dis *x = data;
+ struct addr_location al;
+
+ memset(&al, 0, sizeof(struct addr_location));
+
+ thread__find_addr_map(x->thread, x->cpumode, MAP__FUNCTION, addr, &al);
+ if (!al.map)
+ thread__find_addr_map(x->thread, x->cpumode, MAP__VARIABLE,
+ addr, &al);
+ al.cpu = x->cpu;
+ al.sym = NULL;
+
+ if (al.map)
+ al.sym = map__find_symbol(al.map, al.addr);
+
+ if (!al.sym)
+ return 0;
+
+ if (al.addr < al.sym->end)
+ *off = al.addr - al.sym->start;
+ else
+ *off = al.addr - al.map->start - al.sym->start;
+ snprintf(buf, buflen, "%s", al.sym->name);
+ return 1;
+}
+
+/* x must be set up earlier */
+char *disas_inst(struct perf_dis *x, uint64_t ip, u8 *inbuf, int inlen,
+int *lenp)
+{
+ xed_decoded_inst_t inst;
+ xed_print_info_t info;
+ xed_error_enum_t err;
+ static bool init;
+
+ if (!init) {
+ xed_tables_init();
+ init = true;
+ }
+
+ if (lenp)
+ *lenp = 0;
+
+ xed_init_print_info(&info);
+ info.syntax = XED_SYNTAX_ATT;
+ info.disassembly_callback = dis_resolve;
+ info.context = x;
+
+ xed_decoded_inst_zero(&inst);
+ if (x->is64bit)
+ xed_decoded_inst_set_mode(&inst, XED_MACHINE_MODE_LONG_64,
+ XED_ADDRESS_WIDTH_64b);
+ else
+ xed_decoded_inst_set_mode(&inst, XED_MACHINE_MODE_LEGACY_32,
+ XED_ADDRESS_WIDTH_32b);
+
+ err = xed_decode(&inst, (uint8_t *)inbuf, inlen);
+ if (err != XED_ERROR_NONE) {
+ snprintf(x->out, sizeof(x->out), "err: %s for %d bytes",
+ xed_error_enum_t2str(err), inlen);
+ return x->out;
+ }
+ if (lenp)
+ *lenp = xed_decoded_inst_get_length(&inst);
+ info.p = &inst;
+ info.buf = x->out;
+ info.blen = sizeof(x->out);
+ info.runtime_address = ip;
+ if (!xed_format_generic(&info))
+ strcpy(x->out, "err: cannot format");
+ return x->out;
+}
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 5da376bc1afc..cdaeb4764fee 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -88,6 +88,7 @@ libperf-y += mem-events.o
libperf-y += vsprintf.o
libperf-y += drv_configs.o
libperf-y += time-utils.o
+libperf-y += dis.o
libperf-$(CONFIG_LIBBPF) += bpf-loader.o
libperf-$(CONFIG_BPF_PROLOGUE) += bpf-prologue.o
diff --git a/tools/perf/util/dis.c b/tools/perf/util/dis.c
new file mode 100644
index ..89c9b84051b8
--- /dev/null
+++ b/tools/perf/util/dis.c
@@ -0,0 +1,15 @@
+#include "perf.h"
+#include "dis.h"
+#include "util.h"
+
+/* Fallback for architectures with no disassembler */
+
+__weak char *disas_inst(s
Re: [PATCH] kprobes: move kprobe declarations to asm-generic/kprobes.h
Hi Luis, On Wed, 18 Jan 2017 09:48:40 -0800 "Luis R. Rodriguez" wrote: > Often all is needed is these small helpers, instead of compiler.h > or a full kprobes.h. This is important for asm helpers, in fact even > some asm/kprobes.h make use of these helpers... instead just keep a > generic asm file with helpers useful for asm code with the least amount > of clutter as possible. > > Likewise we need now to also address what to do about this file for both > when architectures have CONFIG_HAVE_KPROBES, and when they do not. Then > for when architectures have CONFIG_HAVE_KPROBES but have disabled > CONFIG_KPROBES. > > Right now most asm/kprobes.h do not have guards against CONFIG_KPROBES, > this means most architecture code cannot include asm/kprobes.h safely. Just from curiosity, would you have any actual issue (like compile error) about that? > Correct this and add guards for architectures missing them. Additionally > provide architectures that not have kprobes support with the default > asm-generic solution. This lets us force asm/kprobes.h on the header > include/linux/kprobes.h always, but most importantly we can now safely > include just asm/kprobes.h on architecture code without bringing > the full kitchen sink of header files. It is fine to me to separate it into asm-generic/kprobes.h. > Two architectures already provided a guard against CONFIG_KPROBES on > its kprobes.h: sh, arch. The rest of the architectures needed gaurds > added. We avoid including any not-needed headers on asm/kprobes.h > unless kprobes have been enabled. > > In a subsequent atomic change we can try now to remove compiler.h from > include/linux/kprobes.h. Nice :) > > During this sweep I've also identified a few architectures defining > a common macro needed for both kprobes and ftrace, that of the > definition of the breakput instruction up. Some refer to this as > BREAKPOINT_INSTRUCTION. This must be kept outside of the #ifdef > CONFIG_KPROBES guard. Hmm, since it depends on ftrace arch-depend implementation, I would like to ask you to split this part into other patches for each arch, with a build failure log. Thank you, > > v5: > > o fix BREAKPOINT_INSTRUCTION dependency with kernel architecture > ftrace implementations: Although its correct to #ifdef CONFIG_KPROBES > on the architecture arch/$(ARCH)/include/asm/kprobes.h when > architectures support ftrace they will rely on the > BREAKPOINT_INSTRUCTION definition, this needs to be kept out from > CONFIG_KPROBES as ftrace can be enabled without kprobes. This > fixes compilation on x86 where kprobes is disabled but ftrace is > left enabled. > > o include on arch/arm64/kernel/probes/decode-insn.h > > Signed-off-by: Luis R. Rodriguez > --- > > This was part of the linker table series [0], but I'm going to split up > patches further there. This is an atomic change which is independent > so sending this separately now. > > [0] https://lkml.kernel.org/r/20170115211057.17167-1-mcg...@kernel.org > > MAINTAINERS| 1 + > arch/alpha/include/asm/Kbuild | 1 + > arch/arc/include/asm/kprobes.h | 6 -- > arch/arm/include/asm/kprobes.h | 4 > arch/arm/probes/decode.h | 1 + > arch/arm64/include/asm/kprobes.h | 4 > arch/arm64/kernel/insn.c | 1 + > arch/arm64/kernel/probes/decode-insn.h | 2 ++ > arch/avr32/include/asm/kprobes.h | 7 ++- > arch/blackfin/include/asm/Kbuild | 1 + > arch/c6x/include/asm/Kbuild| 1 + > arch/cris/include/asm/Kbuild | 1 + > arch/frv/include/asm/Kbuild| 1 + > arch/h8300/include/asm/Kbuild | 1 + > arch/hexagon/include/asm/Kbuild| 1 + > arch/ia64/include/asm/kprobes.h| 12 +--- > arch/m32r/include/asm/Kbuild | 1 + > arch/m68k/include/asm/Kbuild | 1 + > arch/metag/include/asm/Kbuild | 1 + > arch/microblaze/include/asm/Kbuild | 1 + > arch/mips/include/asm/kprobes.h| 6 +- > arch/mn10300/include/asm/kprobes.h | 7 ++- > arch/nios2/include/asm/Kbuild | 1 + > arch/openrisc/include/asm/Kbuild | 1 + > arch/parisc/include/asm/Kbuild | 1 + > arch/powerpc/include/asm/kprobes.h | 3 +++ > arch/s390/include/asm/kprobes.h| 7 ++- > arch/score/include/asm/Kbuild | 1 + > arch/sh/include/asm/kprobes.h | 5 - > arch/sparc/include/asm/kprobes.h | 10 -- > arch/tile/include/asm/kprobes.h| 6 +- > arch/um/include/asm/Kbuild | 1 + > arch/unicore32/include/asm/Kbuild | 1 + > arch/x86/include/asm/kprobes.h | 9 - > arch/xtensa/include/asm/Kbuild | 1 + > include/asm-generic/kprobes.h | 25 + > include/linux/compiler.h | 8 > include/linux/kprobes.h| 19 +++ > 3
Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role
On 1/16/2017 2:38 AM, Felipe Balbi wrote: > > Hi, > > John Youn writes: >>> Baolin Wang writes: > Baolin Wang writes: >> When dwc3 controller acts as host role with attaching slow speed device >> (like mouse or keypad). Then if we plugged out the slow speed device, >> it will timeout to run the deconfiguration endpoint command to drop the >> endpoint's resources. Some xHCI command timeout log as below when >> disconnecting one slow device: >> >> [ 99.807739] c0 xhci-hcd.0.auto: Port Status Change Event for port 1 >> [ 99.814699] c0 xhci-hcd.0.auto: resume root hub >> [ 99.819992] c0 xhci-hcd.0.auto: handle_port_status: starting port >> polling. >> [ 99.827808] c0 xhci-hcd.0.auto: get port status, actual port 0 status >> = 0x202a0 >> [ 99.835903] c0 xhci-hcd.0.auto: Get port status returned 0x10100 >> [ 99.850052] c0 xhci-hcd.0.auto: clear port connect change, actual >> port 0 status = 0x2a0 >> [ 99.859313] c0 xhci-hcd.0.auto: Cancel URB ffc01ed6cd00, dev 1, >> ep 0x81, starting at offset 0xc406d210 >> [ 99.869645] c0 xhci-hcd.0.auto: // Ding dong! >> [ 99.874776] c0 xhci-hcd.0.auto: Stopped on Transfer TRB >> [ 99.880713] c0 xhci-hcd.0.auto: Removing canceled TD starting at >> 0xc406d210 (dma). >> [ 99.889012] c0 xhci-hcd.0.auto: Finding endpoint context >> [ 99.895069] c0 xhci-hcd.0.auto: Cycle state = 0x1 >> [ 99.900519] c0 xhci-hcd.0.auto: New dequeue segment = >> ffc1112f0880 (virtual) >> [ 99.908655] c0 xhci-hcd.0.auto: New dequeue pointer = 0xc406d220 (DMA) >> [ 99.915927] c0 xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg = >> ffc1112f0880 (0xc406d000 dma), >> new deq ptr = ff8002175220 >> (0xc406d220 dma), new cycle = 1 >> [ 99.931242] c0 xhci-hcd.0.auto: // Ding dong! >> [ 99.936360] c0 xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd, >> deq = @c406d220 >> [ 99.944458] c0 xhci-hcd.0.auto: xhci_hub_status_data: stopping port >> polling. >> [ 100.047619] c0 xhci-hcd.0.auto: xhci_drop_endpoint called for udev >> ffc01ae08800 >> [ 100.057002] c0 xhci-hcd.0.auto: drop ep 0x81, slot id 1, new drop >> flags = 0x8, new add flags = 0x0 >> [ 100.067878] c0 xhci-hcd.0.auto: xhci_check_bandwidth called for udev >> ffc01ae08800 >> [ 100.076868] c0 xhci-hcd.0.auto: New Input Control Context: >> >> .. >> >> [ 100.427252] c0 xhci-hcd.0.auto: // Ding dong! >> [ 105.430728] c0 xhci-hcd.0.auto: Command timeout >> [ 105.436029] c0 xhci-hcd.0.auto: Abort command ring >> [ 113.558223] c0 xhci-hcd.0.auto: Command completion event does not >> match >> command >> [ 113.569778] c0 xhci-hcd.0.auto: Timeout while waiting for configure >> endpoint command >> >> The reason is it will suspend USB phy to disable phy clock when >> disconnecting the slow USB decice, that will hang on the xHCI commands >> executing which depends on the phy clock. >> >> Thus we should disable USB2.0 phy suspend feature when dwc3 acts as host >> role. >> >> Signed-off-by: Baolin Wang >> --- >> drivers/usb/dwc3/core.c | 14 ++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index 9a4a5e4..0b646cf 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -565,6 +565,20 @@ static int dwc3_phy_setup(struct dwc3 *dwc) >> if (dwc->revision > DWC3_REVISION_194A) >> reg |= DWC3_GUSB2PHYCFG_SUSPHY; >> >> + /* >> + * When dwc3 controller acts as host role with attaching one slow >> speed >> + * device (like mouse or keypad). Then if we plugged out the slow >> speed >> + * device, it will timeout to run the deconfiguration endpoint >> command. >> + * The reason is it will suspend USB phy to disable phy clock when >> + * disconnecting slow speed decice, which will affect the xHCI >> commands >> + * executing. >> + * >> + * Thus we should disable USB 2.0 phy suspend feature when dwc3 >> acts as >> + * host role. >> + */ >> + if (dwc->dr_mode == USB_DR_MODE_HOST || dwc->dr_mode == >> USB_DR_MODE_OTG) >> + reg &=
RE: [virtio-dev] Re: [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct
> > > > > > Signed-off-by: Liang Li
> > > > > > Cc: Michael S. Tsirkin
> > > > > > Cc: Paolo Bonzini
> > > > > > Cc: Cornelia Huck
> > > > > > Cc: Amit Shah
> > > > > > Cc: Dave Hansen
> > > > > > Cc: Andrea Arcangeli
> > > > > > Cc: David Hildenbrand
> > > > > > ---
> > > > > > include/uapi/linux/virtio_balloon.h | 12
> > > > > > 1 file changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/include/uapi/linux/virtio_balloon.h
> > > > > > b/include/uapi/linux/virtio_balloon.h
> > > > > > index 343d7dd..2f850bf 100644
> > > > > > --- a/include/uapi/linux/virtio_balloon.h
> > > > > > +++ b/include/uapi/linux/virtio_balloon.h
> > > > > > @@ -34,10 +34,14 @@
> > > > > > #define VIRTIO_BALLOON_F_MUST_TELL_HOST0 /* Tell
> before
> > > > > reclaiming pages */
> > > > > > #define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats
> virtqueue
> > > > > */
> > > > > > #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate
> > > balloon
> > > > > on OOM */
> > > > > > +#define VIRTIO_BALLOON_F_PAGE_RANGE3 /* Send page info
> > > > > with ranges */
> > > > > >
> > > > > > /* Size of a PFN in the balloon interface. */ #define
> > > > > > VIRTIO_BALLOON_PFN_SHIFT 12
> > > > > >
> > > > > > +/* Bits width for the length of the pfn range */
> > > > >
> > > > > What does this mean? Couldn't figure it out.
> > > > >
> > > > > > +#define VIRTIO_BALLOON_NR_PFN_BITS 12
> > > > > > +
> > > > > > struct virtio_balloon_config {
> > > > > > /* Number of pages host wants Guest to give up. */
> > > > > > __u32 num_pages;
> > > > > > @@ -82,4 +86,12 @@ struct virtio_balloon_stat {
> > > > > > __virtio64 val;
> > > > > > } __attribute__((packed));
> > > > > >
> > > > > > +/* Response header structure */ struct
> > > > > > +virtio_balloon_resp_hdr {
> > > > > > + __le64 cmd : 8; /* Distinguish different requests type */
> > > > > > + __le64 flag: 8; /* Mark status for a specific request type */
> > > > > > + __le64 id : 16; /* Distinguish requests of a specific type */
> > > > > > + __le64 data_len: 32; /* Length of the following data, in
> > > > > > +bytes */
> > > > >
> > > > > This use of __le64 makes no sense. Just use u8/le16/le32 pls.
> > > > >
> > > >
> > > > Got it, will change in the next version.
> > > >
> > > > And could help take a look at other parts? as well as the QEMU part.
> > > >
> > > > Thanks!
> > > > Liang
> > >
> > > Yes but first I would like to understand how come no fields in this
> > > new structure come up if I search for them in the following patch. I
> > > don't see why
> >
> > It's not true, all of the field will be referenced in the following
> > patches except the 'reserved' filed.
>
> But none of these are used in the following patch 3.
Yes. Only 'data_len' is used in patch 3, and for expansibility maybe at least
'cmd' is needed to. I should set it in patch 3 to some default value even
it's not currently useful. 'flag' and 'id' are for patch 4. I just want to
reuse the 'struct virtio_balloon_resp_hdr' and make the code simpler.
Thanks!
Liang
[PATCH 2/2] security: Change name of CONFIG_DEBUG_SET_MODULE_RONX
Despite the word 'debug' in CONFIG_DEBUG_SET_MODULE_RONX, this kernel option provides key security features that are to be expected on a modern system. Change the name to CONFIG_HARDENED_MODULE_MAPPINGS which more accurately describes what this option is intended to do. Signed-off-by: Laura Abbott --- Documentation/security/self-protection.txt | 2 +- arch/arm/Kconfig | 1 + arch/arm/Kconfig.debug | 11 --- arch/arm/configs/aspeed_g4_defconfig | 2 +- arch/arm/configs/aspeed_g5_defconfig | 2 +- arch/arm/kernel/patch.c| 2 +- arch/arm64/Kconfig | 1 + arch/arm64/Kconfig.debug | 11 --- arch/arm64/kernel/insn.c | 2 +- arch/s390/Kconfig | 1 + arch/s390/Kconfig.debug| 3 --- arch/x86/Kconfig | 1 + arch/x86/Kconfig.debug | 11 --- include/linux/filter.h | 4 ++-- include/linux/init.h | 2 +- include/linux/module.h | 2 +- init/main.c| 2 +- kernel/module.c| 6 +++--- security/Kconfig | 16 19 files changed, 33 insertions(+), 49 deletions(-) diff --git a/Documentation/security/self-protection.txt b/Documentation/security/self-protection.txt index da8cb36..eb018a1 100644 --- a/Documentation/security/self-protection.txt +++ b/Documentation/security/self-protection.txt @@ -52,7 +52,7 @@ made writable during the update, and then returned to the original permissions.) In support of this are CONFIG_HARDENED_PAGE_MAPPINGS and -CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not +CONFIG_HARDENED_MODULE_MAPPINGS, which seek to make sure that code is not writable, data is not executable, and read-only data is neither writable nor executable. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 09aff28..ef852e4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -8,6 +8,7 @@ config ARM select ARCH_HAVE_CUSTOM_GPIO_H select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_HAS_HARDENED_MAPPINGS if MMU && !XIP_KERNEL + select ARCH_HAS_HARDENED_MODULE_MAPPINGS if MMU select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_SUPPORTS_ATOMIC_RMW select ARCH_USE_BUILTIN_BSWAP diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index d83f7c3..426d271 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1738,17 +1738,6 @@ config PID_IN_CONTEXTIDR additional instructions during context switch. Say Y here only if you are planning to use hardware trace tools with this kernel. -config DEBUG_SET_MODULE_RONX - bool "Set loadable kernel module data as NX and text as RO" - depends on MODULES && MMU - ---help--- - This option helps catch unintended modifications to loadable - kernel module's text and read-only data. It also prevents execution - of module data. Such protection may interfere with run-time code - patching and dynamic kernel tracing - and they might also protect - against certain classes of kernel exploits. - If in doubt, say "N". - source "drivers/hwtracing/coresight/Kconfig" endmenu diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index 8ccc216..ffe2656 100644 --- a/arch/arm/configs/aspeed_g4_defconfig +++ b/arch/arm/configs/aspeed_g4_defconfig @@ -79,7 +79,7 @@ CONFIG_DEBUG_LL_UART_8250=y CONFIG_DEBUG_UART_PHYS=0x1e784000 CONFIG_DEBUG_UART_VIRT=0xe8784000 CONFIG_EARLY_PRINTK=y -CONFIG_DEBUG_SET_MODULE_RONX=y +CONFIG_HARDENED_MODULE_MAPPINGS=y # CONFIG_XZ_DEC_X86 is not set # CONFIG_XZ_DEC_POWERPC is not set # CONFIG_XZ_DEC_IA64 is not set diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig index 90c5ce4..2ea444e 100644 --- a/arch/arm/configs/aspeed_g5_defconfig +++ b/arch/arm/configs/aspeed_g5_defconfig @@ -81,7 +81,7 @@ CONFIG_DEBUG_LL_UART_8250=y CONFIG_DEBUG_UART_PHYS=0x1e784000 CONFIG_DEBUG_UART_VIRT=0xe8784000 CONFIG_EARLY_PRINTK=y -CONFIG_DEBUG_SET_MODULE_RONX=y +CONFIG_HARDENED_MODULE_MAPPINGS=y # CONFIG_XZ_DEC_X86 is not set # CONFIG_XZ_DEC_POWERPC is not set # CONFIG_XZ_DEC_IA64 is not set diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c index 9da1bf5..eb73a76 100644 --- a/arch/arm/kernel/patch.c +++ b/arch/arm/kernel/patch.c @@ -24,7 +24,7 @@ static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags) bool module = !core_kernel_text(uintaddr); struct page *page; - if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX)) + if (module && IS_ENABLED(CONFIG_HARDENED_MODULE_MAPPINGS)) page = vmalloc_to_page(addr); else if (!module &
[PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA
Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option provides key security features that are to be expected on a modern system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more accurately describes what this option is intended to do. Signed-off-by: Laura Abbott --- Documentation/DocBook/kgdb.tmpl| 8 Documentation/security/self-protection.txt | 2 +- arch/arm/Kconfig | 1 + arch/arm/configs/aspeed_g4_defconfig | 2 +- arch/arm/configs/aspeed_g5_defconfig | 2 +- arch/arm/include/asm/cacheflush.h | 2 +- arch/arm/kernel/patch.c| 2 +- arch/arm/kernel/vmlinux.lds.S | 8 arch/arm/mm/Kconfig| 14 +- arch/arm/mm/init.c | 4 ++-- arch/arm64/Kconfig | 4 +--- arch/arm64/Kconfig.debug | 2 +- arch/parisc/Kconfig| 1 + arch/parisc/Kconfig.debug | 11 --- arch/parisc/configs/712_defconfig | 2 +- arch/parisc/configs/c3000_defconfig| 2 +- arch/parisc/mm/init.c | 2 +- arch/s390/Kconfig | 4 +--- arch/x86/Kconfig | 4 +--- include/linux/init.h | 4 ++-- init/main.c| 4 ++-- kernel/configs/android-recommended.config | 2 +- kernel/power/hibernate.c | 2 +- kernel/power/power.h | 4 ++-- kernel/power/snapshot.c| 4 ++-- security/Kconfig | 16 26 files changed, 51 insertions(+), 62 deletions(-) diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index f3abca7..a79b638 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl @@ -115,12 +115,12 @@ If the architecture that you are using supports the kernel option -CONFIG_DEBUG_RODATA, you should consider turning it off. This +CONFIG_HARDENED_PAGE_MAPPINGS, you should consider turning it off. This option will prevent the use of software breakpoints because it marks certain regions of the kernel's memory space as read-only. If kgdb supports it for the architecture you are using, you can use hardware breakpoints if you desire to run with the -CONFIG_DEBUG_RODATA option turned on, else you need to turn off +CONFIG_HARDENED_PAGE_MAPPINGS option turned on, else you need to turn off this option. @@ -135,7 +135,7 @@ Here is an example set of .config symbols to enable or disable for kgdb: -# CONFIG_DEBUG_RODATA is not set +# CONFIG_HARDENED_PAGE_MAPPINGS is not set CONFIG_FRAME_POINTER=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y @@ -166,7 +166,7 @@ Here is an example set of .config symbols to enable/disable kdb: -# CONFIG_DEBUG_RODATA is not set +# CONFIG_HARDENED_PAGE_MAPPINGS is not set CONFIG_FRAME_POINTER=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y diff --git a/Documentation/security/self-protection.txt b/Documentation/security/self-protection.txt index 3010576..da8cb36 100644 --- a/Documentation/security/self-protection.txt +++ b/Documentation/security/self-protection.txt @@ -51,7 +51,7 @@ kernel, they are implemented in a way where the memory is temporarily made writable during the update, and then returned to the original permissions.) -In support of this are (the poorly named) CONFIG_DEBUG_RODATA and +In support of this are CONFIG_HARDENED_PAGE_MAPPINGS and CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not writable, data is not executable, and read-only data is neither writable nor executable. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 186c4c2..09aff28 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -7,6 +7,7 @@ config ARM select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAVE_CUSTOM_GPIO_H select ARCH_HAS_GCOV_PROFILE_ALL + select ARCH_HAS_HARDENED_MAPPINGS if MMU && !XIP_KERNEL select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_SUPPORTS_ATOMIC_RMW select ARCH_USE_BUILTIN_BSWAP diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index ca39c04..8ccc216 100644 --- a/arch/arm/configs/aspeed_g4_defconfig +++ b/arch/arm/configs/aspeed_g4_defconfig @@ -25,7 +25,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_ARCH_MULTI_V7 is not set CONFIG_ARCH_ASPEED=y CONFIG_MACH_ASPEED_G4=y -CONFIG_DEBUG_RODATA=y +CONFIG_HARDENED_PAGE_MAPPINGS=y CONFIG_AEABI=y CONFIG_UACCESS_WITH_MEMCPY=y CONFIG_SECCOMP=y diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig index 4f366b0..90c5ce4 100644 --- a/arch/arm/configs/aspeed_g5_defconfig +++ b/arch/arm/co
[RFC][PATCH 0/2] Better hardening names
Hi, It's come up previously that CONFIG_DEBUG_SET_MODULE_RONX and CONFIG_DEBUG_RODATA are not accurate names, mostly they should not have the word 'debug' in them. This series attempts to change the names to something a bit more descriptive and indicative of what they are actually used for these days. I marked this RFC for - Bike shedding purposes. - A discussion of what defaults should be. The way I did the refactoring, both options are default y. I'd appreciate comments if there is a better approach. - Approach to split this up into more sub patches to make review/merging easier? Or maybe it's fine. Quickly tested on arm/arm64/x86. Thanks, Laura Laura Abbott (2): security: Change name of CONFIG_DEBUG_RODATA security: Change name of CONFIG_DEBUG_SET_MODULE_RONX Documentation/DocBook/kgdb.tmpl| 8 Documentation/security/self-protection.txt | 4 ++-- arch/arm/Kconfig | 2 ++ arch/arm/Kconfig.debug | 11 -- arch/arm/configs/aspeed_g4_defconfig | 4 ++-- arch/arm/configs/aspeed_g5_defconfig | 4 ++-- arch/arm/include/asm/cacheflush.h | 2 +- arch/arm/kernel/patch.c| 4 ++-- arch/arm/kernel/vmlinux.lds.S | 8 arch/arm/mm/Kconfig| 14 + arch/arm/mm/init.c | 4 ++-- arch/arm64/Kconfig | 5 ++--- arch/arm64/Kconfig.debug | 13 +--- arch/arm64/kernel/insn.c | 2 +- arch/parisc/Kconfig| 1 + arch/parisc/Kconfig.debug | 11 -- arch/parisc/configs/712_defconfig | 2 +- arch/parisc/configs/c3000_defconfig| 2 +- arch/parisc/mm/init.c | 2 +- arch/s390/Kconfig | 5 ++--- arch/s390/Kconfig.debug| 3 --- arch/x86/Kconfig | 5 ++--- arch/x86/Kconfig.debug | 11 -- include/linux/filter.h | 4 ++-- include/linux/init.h | 4 ++-- include/linux/module.h | 2 +- init/main.c| 4 ++-- kernel/configs/android-recommended.config | 2 +- kernel/module.c| 6 +++--- kernel/power/hibernate.c | 2 +- kernel/power/power.h | 4 ++-- kernel/power/snapshot.c| 4 ++-- security/Kconfig | 32 ++ 33 files changed, 82 insertions(+), 109 deletions(-) -- 2.7.4
Re: [RFC] HWPOISON: soft offlining for non-lru movable page
On 2017/1/18 17:51, Michal Hocko wrote:
> On Wed 18-01-17 12:00:54, Yisheng Xie wrote:
>> This patch is to extends soft offlining framework to support
>> non-lru page, which already support migration after
>> commit bda807d44454 ("mm: migrate: support non-lru movable page
>> migration")
>>
>> When memory corrected errors occur on a non-lru movable page,
>> we can choose to stop using it by migrating data onto another
>> page and disable the original (maybe half-broken) one.
>
> soft_offline_movable_page duplicates quite a lot from
> __soft_offline_page. Would it be better to handle both cases in
> __soft_offline_page?
>
Hi Michal,
Thanks for reviewing.
Yes, the most code of soft_offline_movable_page is duplicates with
__soft_offline_page, I use a single function to make code looks clear,
just as what soft_offline_hugetlb_page do.
I will try to make a v2 as your suggestion.
Thanks
Yisheng Xie.
