Re: [RFC] mm/migrate: Add new migration reason MR_HUGETLB
On 01/30/2018 08:37 AM, Anshuman Khandual wrote: > @@ -7621,8 +7622,13 @@ static int __alloc_contig_migrate_range(struct > compact_control *cc, > &cc->migratepages); > cc->nr_migratepages -= nr_reclaimed; > > + if (migratetype == MIGRATE_CMA) > + migrate_reason = MR_CMA; > + else > + migrate_reason = MR_HUGETLB; > + > ret = migrate_pages(&cc->migratepages, new_page_alloc_contig, Oops, this is on top of the changes from the other RFC regarding migration helper functions.
linux-next: Tree for Jan 30
Hi all,
Please do not add any v4.17 material to your linux-next included branches
until after v4.16-rc1 has been released.
Changes since 20180129:
The userns tree still had its build failure for which I added a patch.
Non-merge commits (relative to Linus' tree): 10187
10050 files changed, 426072 insertions(+), 280932 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, an allmodconfig 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. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 256 trees (counting Linus' and 44 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 (0a4b6e2f80aa Merge branch 'for-4.16/block' of
git://git.kernel.dk/linux-block)
Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging kbuild-current/fixes (36c1681678b5 genksyms: drop *.hash.c from
.gitignore)
Merging arc-current/for-curr (a46f24acf8bc ARC: boot log: Fix trailing
semicolon)
Merging arm-current/fixes (091f02483df7 ARM: net: bpf: clarify tail_call index)
Merging m68k-current/for-linus (2334b1ac1235 MAINTAINERS: Add NuBus subsystem
entry)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (1b689a95ce74 powerpc/pseries: include
linux/types.h in asm/hvcall.h)
Merging sparc/master (aebb48f5e465 sparc64: fix typo in
CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (ba804bb4b72e Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging bpf/master (ba804bb4b72e Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (545d8ae7afff xfrm: fix boolean assignment in
xfrm_get_type_offload)
Merging netfilter/master (da17c73b6eb7 netfilter: x_tables: avoid out-of-bounds
reads in xt_request_find_{match|target})
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook
mask only if set)
Merging wireless-drivers/master (a9e6d44ddecc ssb: Do not disable PCI host on
non-Mips)
Merging mac80211/master (e58edaa48635 net/mlx5e: Fix fixpoint divide exception
in mlx5e_am_stats_compare)
Merging rdma-fixes/for-rc (ae59c3f0b6cf RDMA/mlx5: Fix out-of-bound access
while querying AH)
Merging sound-current/for-linus (1c9609e3a8cf ALSA: hda - Reduce the suspend
time consumption for ALC256)
Merging pci-current/for-linus (838cda369707 x86/PCI: Enable AMD 64-bit window
on resume)
Merging driver-core.current/driver-core-linus (30a7acd57389 Linux 4.15-rc6)
Merging tty.current/tty-linus (30a7acd57389 Linux 4.15-rc6)
Merging usb.current/usb-linus (a8750ddca918 Linux 4.15-rc8)
Merging usb-gadget-fixes/fixes (b2cd1df66037 Linux 4.15-rc7)
Merging usb-serial-fixes/usb-linus (d14ac576d10f USB: serial: cp210x: add new
device ID ELV ALC 8xxx)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm:
fix ulpi-node lookup)
Merging phy/fixes (2b88212c4cc6 phy: rcar-gen3-usb2: select USB_COMMON)
Merging staging.current/staging-linus (a8750ddca918 Linux 4.15-rc8)
Merging char-misc.current/char-misc-linus (a8750ddca918 Linux 4.15-rc8)
Merging input-current/for-linus (060403f34008 Revert "Input: synaptics_rmi4 -
use devm_device_add_group() for attributes in F01")
Merging crypto-current/master (2d55807b7f7b crypto:
Re: [Qemu-devel] [RFC PATCH 0/3] vfio: ccw: basic channel path event handling
Halil Pasic writes: --text follows this line-- Hi Halil, --text follows this line-- AS you may noticed, Conny replied to this thread on my mail. Some of her comments there could answer your questions. If that applies, I will just say "See Conny's mail" in the following, and you can reply to that mail, so we can consolidate further discussion. >>> * When a channel path malfunctions a CRW is generated and a machine >>> check channel report pending is generated. Same goes for >>> channel paths popping up (on HW level). Should not these get >>> propagated? >> AFAIR, channel path related CRW is not that reliable. I mean it seems >> that it's not mandatory to generate CRWs for channel path malfunctions. >> AFAIU, it depneds on machine models. For example, we won't get >> CRW_ERC_INIT for a "path has come" event on many models I believe. And >> that's why nobody noticed the misuse of CRW_ERC_IPARM and CRW_ERC_INIT >> in the CRW handling logic for channel path CRWs. >> Ref: >> 2daace78a8c9 s390: chp: handle CRW_ERC_INIT for channel-path status change >> > > Honestly, I forgot about this discussion. I've refreshed my memories by > now, but I could not find why is it supposed to be architecturally OK > to loose CRWs when for instance a chp goes away. > >> So my understanding for this is: it really a design decision for us to >> propagate all of the channel path CRWs, or we just use other ways (like >> using PNO and PNOM as this series shows). > > From what I read, CRWs did not seem optional. > I wonder what should I read in order to change my mind. I'm not > talking about the hardware in the wild -- but that could be buggy > hardware. > Ah, can you point out the chapter that says CRWs is mandatory? AFAIU, PoP doesn't say, for example, chp gone will lead to a CRW, but it only says when we got a chp gone CRW it means a chp has been gone. [See Conny's mail pls, and we can discuss there.] >> >> Of course, CRW propagation is good to have. But as a discussion result >> of a former thread, that is something we can consider only after we have >> a good channel path re-modelling. That is the problem. We can try to >> trigger CRW event in some work of machine checks handling enhancement >> later. >> >>> * Kind of instead of the CRW you introduce a per device interrupt >>> for channel path events on the qemu/kvm boundary. AFAIU for a chp >>> event you do an STSCH for each (affected?) subchannel >> Until here, yes and right. >> >>> and generate an irq. Right? Why is this a good idea. >> This is not right. This series does not generate an irq for the guest. > > You misunderstood this. The word 'irq' this sentence is a short version > of 'per device interrupt for channel path events on the qemu/kvm boundary' > form the previous sentence. It's not an irq injected into the guest but > a notification (which you call irq in '[RFC PATCH 2/3] vfio: ccw: > introduce channel path irq') for QEMU. > I see now. I misunderstood. >> In QEMU, when it gets the notification of a channel path status change >> event, it read the newest SCHIB from the schib region, and update the >> SCHIB (patch related parts) for the virtual subchannel. The guest will >> get the new SCHIB whenever it calls STSCH then. > > We are in agreement. I just wanted to say, if let's say 42 vfio-ccw devices > are using the same chp and it goes away, you will generate 42 notifications. See reply below #LabelA. > >> >> I think this is a good idea, because: >> 1. This is complies the Linux implementation. Path status change could >>be noticed by Linux. >> 2. This provides enhancement with a small work. On the contrary, channel >>path re-modelling needs a lot of work. > > I thing your answer is based on the misunderstanding explained above. I see now. > > My idea was to be lazy in a different way. Instead of being lazy about > reading the subsection, I was wondering why not do an STSCH in the host > as a response to one being done in the guest. > > That means: if there is no activity on the passed trough devices, nothing > needs to be done. (Except maybe the CRWs). > #LabelA: I see your point. This is an interesting idea. Pros: - code simplification - no chp event notification and handling Cons: - have to read schib region (or issue STSCH on host) for each STSCH request from a guest I think code siplification is very acctractive, and performance is not the most important issue. Any comments? @Conny > The things aren't observable by the guest if it does not do STSCH anyway. Nod. This is the idea that this series is based on. > > >> >>> * SCHIB.PMCW provides path information relevant for a given device. >>> This information is retrieved using store subchannel. Is your series >>> sufficient for making store subchannel work properly (correct and >>> reasonably up to date)? >> Introducing a SCHIB region is the basis of further STSCH hanlding work. >> This series depends on it, and only focuses on the update of the channel >> path related parts of it. And
[PATCH 0/2] perf trace: Two trivial fixes
Two independent fixes: First adds 'generated' directory into .gitignore Second fixes call-graph output with perf trace Ravi Bangoria (2): perf tools: Add trace/beauty/generated/ into .gitignore perf trace: Fix call-graph output tools/perf/.gitignore | 1 + tools/perf/builtin-trace.c | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) -- 1.8.3.1
[PATCH 1/2] perf tools: Add trace/beauty/generated/ into .gitignore
No functionality changes. Signed-off-by: Ravi Bangoria --- tools/perf/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore index 643cc4ba..3e5135d 100644 --- a/tools/perf/.gitignore +++ b/tools/perf/.gitignore @@ -31,5 +31,6 @@ config.mak.autogen .config-detected util/intel-pt-decoder/inat-tables.c arch/*/include/generated/ +trace/beauty/generated/ pmu-events/pmu-events.c pmu-events/jevents -- 1.8.3.1
[PATCH 2/2] perf trace: Fix call-graph output
Recently, Arnaldo fixed global vs event specific --max-stack usage
with commit bd3dda9ab0fb ("perf trace: Allow overriding global
--max-stack per event"). This commit is having a regression when
we don't use --max-stack at all with perf trace. Ex,
$ ./perf trace record -g ls
$ ./perf trace -i perf.data
0.076 ( 0.002 ms): ls/9109 brk(
0.196 ( 0.008 ms): ls/9109 access(filename: 0x9f998b70, mode: R
0.209 ( 0.031 ms): ls/9109 open(filename: 0x9f998978, flags: CLOEXEC
This is missing call-traces.
After patch:
$ ./perf trace -i perf.data
0.076 ( 0.002 ms): ls/9109 brk(
do_syscall_trace_leave ([kernel.kallsyms])
[0] ([unknown])
syscall_exit_work ([kernel.kallsyms])
brk (/usr/lib64/ld-2.17.so)
_dl_sysdep_start (/usr/lib64/ld-2.17.so)
_dl_start_final (/usr/lib64/ld-2.17.so)
_dl_start (/usr/lib64/ld-2.17.so)
_start (/usr/lib64/ld-2.17.so)
0.196 ( 0.008 ms): ls/9109 access(filename: 0x9f998b70, mode: R
do_syscall_trace_leave ([kernel.kallsyms])
[0] ([unknown])
Fixes: bd3dda9ab0fb ("perf trace: Allow overriding global --max-stack per
event")
Signed-off-by: Ravi Bangoria
---
tools/perf/builtin-trace.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 17d11de..e90f5c3 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1661,9 +1661,12 @@ static int trace__resolve_callchain(struct trace *trace,
struct perf_evsel *evse
struct callchain_cursor *cursor)
{
struct addr_location al;
+ int max_stack = evsel->attr.sample_max_stack ?
+ evsel->attr.sample_max_stack :
+ trace->max_stack;
if (machine__resolve(trace->host, &al, sample) < 0 ||
- thread__resolve_callchain(al.thread, cursor, evsel, sample, NULL,
NULL, evsel->attr.sample_max_stack))
+ thread__resolve_callchain(al.thread, cursor, evsel, sample, NULL,
NULL, max_stack))
return -1;
return 0;
--
1.8.3.1
Re: [PATCH] macintosh: Add module license to ans-lcd
Hi,
That matches the SPDX identifier from the top of the file, so:
Reviewed-by: Daniel Axtens
Regards,
Daniel
Larry Finger writes:
> In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that
> there was no module license for ans-lcd.
>
> Signed-off-by: Larry Finger
> ---
> drivers/macintosh/ans-lcd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/macintosh/ans-lcd.c b/drivers/macintosh/ans-lcd.c
> index 1de81d922d8a..c8e078b911c7 100644
> --- a/drivers/macintosh/ans-lcd.c
> +++ b/drivers/macintosh/ans-lcd.c
> @@ -201,3 +201,4 @@ anslcd_exit(void)
>
> module_init(anslcd_init);
> module_exit(anslcd_exit);
> +MODULE_LICENSE("GPL v2");
> --
> 2.16.1
RE: [PATCH RFC 01/16] prcu: Add PRCU implementation
-Original Message-
>From: Boqun Feng [mailto:boqun.f...@gmail.com]
>Sent: 2018年1月25日 15:31
>To: Paul E. McKenney
>Cc: liangli...@huawei.com; Guohanjun (Hanjun Guo) ;
>zhangheng (AC) ; Chenhaibo (Haibo, OS Lab)
>; lihao.li...@gmail.com; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH RFC 01/16] prcu: Add PRCU implementation
>
>On Wed, Jan 24, 2018 at 10:16:18PM -0800, Paul E. McKenney wrote:
>> On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote:
>> > From: Heng Zhang
>> >
>> > This RCU implementation (PRCU) is based on a fast consensus protocol
>> > published in the following paper:
>> >
>> > Fast Consensus Using Bounded Staleness for Scalable Read-mostly
>> > Synchronization.
>> > Haibo Chen, Heng Zhang, Ran Liu, Binyu Zang, and Haibing Guan.
>> > IEEE Transactions on Parallel and Distributed Systems (TPDS), 2016.
>> > https://dl.acm.org/citation.cfm?id=3024114.3024143
>> >
>> > Signed-off-by: Heng Zhang
>> > Signed-off-by: Lihao Liang
>>
>> A few comments and questions interspersed.
>>
>> Thanx, Paul
>>
>> > ---
>> > include/linux/prcu.h | 37 +++
>> > kernel/rcu/Makefile | 2 +-
>> > kernel/rcu/prcu.c| 125
>> > +++
>> > kernel/sched/core.c | 2 +
>> > 4 files changed, 165 insertions(+), 1 deletion(-) create mode
>> > 100644 include/linux/prcu.h create mode 100644 kernel/rcu/prcu.c
>> >
>> > diff --git a/include/linux/prcu.h b/include/linux/prcu.h new file
>> > mode 100644 index ..653b4633
>> > --- /dev/null
>> > +++ b/include/linux/prcu.h
>> > @@ -0,0 +1,37 @@
>> > +#ifndef __LINUX_PRCU_H
>> > +#define __LINUX_PRCU_H
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#define CONFIG_PRCU
>> > +
>> > +struct prcu_local_struct {
>> > + unsigned int locked;
>> > + unsigned int online;
>> > + unsigned long long version;
>> > +};
>> > +
>> > +struct prcu_struct {
>> > + atomic64_t global_version;
>> > + atomic_t active_ctr;
>> > + struct mutex mtx;
>> > + wait_queue_head_t wait_q;
>> > +};
>> > +
>> > +#ifdef CONFIG_PRCU
>> > +void prcu_read_lock(void);
>> > +void prcu_read_unlock(void);
>> > +void synchronize_prcu(void);
>> > +void prcu_note_context_switch(void);
>> > +
>> > +#else /* #ifdef CONFIG_PRCU */
>> > +
>> > +#define prcu_read_lock() do {} while (0) #define prcu_read_unlock()
>> > +do {} while (0) #define synchronize_prcu() do {} while (0) #define
>> > +prcu_note_context_switch() do {} while (0)
>>
>> If CONFIG_PRCU=n and some code is built that uses PRCU, shouldn't you
>> get a build error rather than an error-free but inoperative PRCU?
>>
>> Of course, Peter's question about purpose of the patch set applies
>> here as well.
>>
>> > +
>> > +#endif /* #ifdef CONFIG_PRCU */
>> > +#endif /* __LINUX_PRCU_H */
>> > diff --git a/kernel/rcu/Makefile b/kernel/rcu/Makefile index
>> > 23803c7d..8791419c 100644
>> > --- a/kernel/rcu/Makefile
>> > +++ b/kernel/rcu/Makefile
>> > @@ -2,7 +2,7 @@
>> > # and is generally not a function of system call inputs.
>> > KCOV_INSTRUMENT := n
>> >
>> > -obj-y += update.o sync.o
>> > +obj-y += update.o sync.o prcu.o
>> > obj-$(CONFIG_CLASSIC_SRCU) += srcu.o
>> > obj-$(CONFIG_TREE_SRCU) += srcutree.o
>> > obj-$(CONFIG_TINY_SRCU) += srcutiny.o diff --git
>> > a/kernel/rcu/prcu.c b/kernel/rcu/prcu.c new file mode 100644 index
>> > ..a00b9420
>> > --- /dev/null
>> > +++ b/kernel/rcu/prcu.c
>> > @@ -0,0 +1,125 @@
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#include
>> > +
>> > +DEFINE_PER_CPU_SHARED_ALIGNED(struct prcu_local_struct,
>> > +prcu_local);
>> > +
>> > +struct prcu_struct global_prcu = {
>> > + .global_version = ATOMIC64_INIT(0),
>> > + .active_ctr = ATOMIC_INIT(0),
>> > + .mtx = __MUTEX_INITIALIZER(global_prcu.mtx),
>> > + .wait_q = __WAIT_QUEUE_HEAD_INITIALIZER(global_prcu.wait_q)
>> > +};
>> > +struct prcu_struct *prcu = &global_prcu;
>> > +
>> > +static inline void prcu_report(struct prcu_local_struct *local) {
>> > + unsigned long long global_version;
>> > + unsigned long long local_version;
>> > +
>> > + global_version = atomic64_read(&prcu->global_version);
>> > + local_version = local->version;
>> > + if (global_version > local_version)
>> > + cmpxchg(&local->version, local_version, global_version); }
>> > +
>> > +void prcu_read_lock(void)
>> > +{
>> > + struct prcu_local_struct *local;
>> > +
>> > + local = get_cpu_ptr(&prcu_local);
>> > + if (!local->online) {
>> > + WRITE_ONCE(local->online, 1);
>> > + smp_mb();
>> > + }
>> > +
>> > + local->locked++;
>> > + put_cpu_ptr(&prcu_local);
>> > +}
>> > +EXPORT_SYMBOL(prcu_read_lock);
>> > +
>> > +void prcu_read_unlock(void)
>> > +{
>> > + int locked;
>> > + struct prcu_local_struct *local;
>> > +
>> > + barrier();
>> > + local = get_cpu_ptr(&prcu_local);
>> > + locked = local->locked;
>> >
Re: [perf] perf probe fails sometimes on 4.9
On Mon, 29 Jan 2018 22:00:52 +0530 Pintu Kumar wrote: > Dear Masami, > > Thank you so much for your reply. > Please find some of my answers inline. > > > On Mon, Jan 29, 2018 at 7:47 PM, Masami Hiramatsu wrote: > > On Mon, 29 Jan 2018 13:40:34 +0530 > > Pintu Kumar wrote: > > > >> Hi All, > >> > >> 'perf probe' is failing sometimes on 4.9.20 with AMD-64. > >> # perf probe --add schedule > >> schedule is out of .text, skip it. > >> Error: Failed to add events. > >> > >> If any one have come across this problem please let me know the cause. > > > > Hi Pintu, > > > > Could you run it with --vv? > > > Ok, I will send verbose output by tomorrow. > > >> > >> Note: I don't have CONFIG_DEBUG_INFO enabled in kernel. Is this the > >> problem? > > > > Without it, you can not probe source-level probe nor trace local variable. > > > > Currently I am facing problem in enabling DEBUG_INFO in our kernel 4.9.20 > However, I will try to manually include "-g" option during compilation. > > >> However, I manually copied the vmlinux file to /boot/ directory, but > >> still it does not work. > > > > That doesn't work. > > CONFIG_DEBUG_INFO option enables gcc to compile kernel with extra debuginfo. > > Without that option, debuginfo is not generated with vmlinux. > > > >> > >> I checked upstream patches until 4.15 but could not find any clue. > >> Please let me know if there is any fixes available for this. > > > > Could you also ensure that you run perf by root user? > > > > Yes I am running with root user. > > My concern is sometimes it works but sometimes it fails. What I thought was that your kernel enables kptr_strict(but maybe not.) Can you also try to find "schedule" and "_etext" functions in /proc/kallsyms? > I still needs to figure out, in which condition it works and which > condition it fails. Yeah, it is important. > Usually I noticed that in fresh reboot case it works. So, after a while, it doesn't work again? If so, it sounds like a daemon process changes settings in background. Thank you, > > > > Thank you, > > > > > >> > >> > >> Thank You! > >> Regards, > >> Pintu > >> > >> > >> On Thu, Jan 25, 2018 at 7:09 PM, Pintu Kumar wrote: > >> > Hi, > >> > > >> > ** Changed the subject now, since these issues are related to general > >> > perf commands. > >> > > >> > Following are the issues: > >> > > >> > 1) perf probe --add schedule - FAILED > >> > output: > >> > schedule is out of .text, skip it. > >> > Error: Failed to add events. > >> > > >> > what is the issue here? > >> > Sometimes it pass and sometimes it fails... > >> > Similar is the case of 'perf inject' as well. > >> > > >> > 2) perf test - 1 FAILURE > >> > 37.1: Test basic BPF filtering : FAILED! > >> > 37.2: Test BPF prologue generation : Skip > >> > 37.3: Test BPF relocation checker: Skip > >> > > >> > bpf: config program 'func=SyS_epoll_wait' > >> > symbol:SyS_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null) > >> > bpf: config 'func=SyS_epoll_wait' is ok > >> > Looking at the vmlinux_path (8 entries long) > >> > Using /boot/vmlinux for symbols > >> > Could not open debuginfo. Try to use symbols. > >> > SyS_epoll_wait is out of .text, skip it. > >> > bpf_probe: failed to convert perf probe eventsFailed to add events > >> > selected by BPF > >> > test child finished with -1 > >> > end > >> > Test BPF filter subtest 0: FAILED! > >> > > >> > Looks like both 1,2 are related. > >> > Since, CONFIG_DEBUG_INFO is not enabled, I manually copied the vmlinux > >> > to /boot/ folder. > >> > > >> > --- > >> > Some more info: > >> > > >> > Kernel build dir is set to /lib/modules/4.9.20-sc-amd-x86-64/build > >> > set env: KBUILD_DIR=/lib/modules/4.9.20-sc-amd-x86-64/build > >> > unset env: KBUILD_OPTS > >> > include option is set to -nostdinc -isystem > >> > /usr/lib/gcc/x86_64-linux-gnu/5/include -I./arch/x86/include > >> > -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated > >> > -I./include -I./arch/x86/include/uapi -I./include/uapi > >> > -I./include/generated/uapi -include ./include/linux/kconfig.h > >> > set env: NR_CPUS=8 > >> > set env: LINUX_VERSION_CODE=0x40914 > >> > set env: CLANG_EXEC=/usr/bin/clang > >> > set env: CLANG_OPTIONS=-xc > >> > set env: KERNEL_INC_OPTIONS= -nostdinc -isystem > >> > /usr/lib/gcc/x86_64-linux-gnu/5/include -I./arch/x86/include > >> > -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated > >> > -I./include -I./arch/x86/include/uapi -I./include/uapi > >> > -I./include/generated/uapi -include ./include/linux/kconfig.h > >> > set env: WORKING_DIR=/lib/modules/4.9.20-sc-amd-x86-64/build > >> > > >> > > >> > If you have any clue about these failure please help me. > >> > > >> > > >> > Thanks, > >> > Pintu > >> > > >> > > >> > On Wed, Jan 24, 2018 at 8:23 PM, Pintu Kumar > >> > wrote: > >> >> Hi, > >> >> > >> >> Thanks for your help. > >> >> Yes it was a sub version issue. >
[PATCH 0/2] fsi: add property to avoid scanning at boot
These two patches from Chris add an optional property that says the FSI attached hardware cannot cope with being probed unless the state of that hardware is known. This allows the driver to eg. defer to userspace which can make this decision. I am collecting patches for a FSI tree to send to Greg, so I am just after review from the device tree people. Christopher Bostic (2): dt-bindings: fsi: Add optional property no-scan-on-init fsi: core: Add check for master property no-scan-on-init Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++ drivers/fsi/fsi-core.c| 5 - 2 files changed, 11 insertions(+), 1 deletion(-) -- 2.15.1
[PATCH 1/2] dt-bindings: fsi: Add optional property no-scan-on-init
From: Christopher Bostic Add an optional FSI master property 'no-scan-on-init. This can be specified to indicate that a master should not be automatically scanned at init time. This is required in cases where a scan could interfere with another FSI master on the same bus. Signed-off-by: Christopher Bostic Acked-by: Jeremy Kerr Signed-off-by: Joel Stanley --- Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt index 4eaf488d4015..ab516c673a4b 100644 --- a/Documentation/devicetree/bindings/fsi/fsi.txt +++ b/Documentation/devicetree/bindings/fsi/fsi.txt @@ -56,6 +56,13 @@ addresses (link index and slave ID), and no size: #address-cells = <2>; #size-cells = <0>; +An optional boolean property can be added to indicate that a particular master +should not scan for connected devices at initialization time. This is +necessary in cases where a scan could cause arbitration issues with other +masters that may be present on the bus. + +no-scan-on-init; + FSI slaves -- -- 2.15.1
[PATCH 2/2] fsi: core: Add check for master property no-scan-on-init
From: Christopher Bostic
Prior to scanning a master check if the optional property
no-scan-on-init is present. If it is then avoid scanning. This is
necessary in cases where a master scan could interfere with another
FSI master on the same bus.
Signed-off-by: Christopher Bostic
Acked-by: Jeremy Kerr
Signed-off-by: Joel Stanley
---
drivers/fsi/fsi-core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 8d8b25809452..4c03d6933646 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -901,6 +901,7 @@ static DEVICE_ATTR(break, 0200, NULL, master_break_store);
int fsi_master_register(struct fsi_master *master)
{
int rc;
+ struct device_node *np;
if (!master)
return -EINVAL;
@@ -928,7 +929,9 @@ int fsi_master_register(struct fsi_master *master)
return rc;
}
- fsi_master_scan(master);
+ np = dev_of_node(&master->dev);
+ if (!of_property_read_bool(np, "no-scan-on-init"))
+ fsi_master_scan(master);
return 0;
}
--
2.15.1
Re: [PATCH 1/1] scsi: ufs-qcom: remove broken hci version quirk
Hi Asutosh,
On 1/30/2018 10:11 AM, Asutosh Das wrote:
From: Subhash Jadavani
UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host
controller version 2.x.y and this has been fixed from version 3.x.y
onwards, hence this change removes this quirk for version 3.x.y onwards.
Signed-off-by: Subhash Jadavani
Signed-off-by: Asutosh Das
---
This patch and all other ufs patches that you have posted recently,
do they all fall under one 'ufs-qcom fixes' patch series for fixes that
we would want to do?
If it is so, then please club them together in a series, so that
it's easy for reviewers and maintainers to review, and keep track
of all the patches that can get-in after the reviews.
If they belong to two or more separate patch-series then please
create such patch series.
It's difficult to read through a lot of [PATCH 1/1] ... patch.
Regards
Vivek
drivers/scsi/ufs/ufs-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2b38db2..221820a 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1098,7 +1098,7 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC;
}
- if (host->hw_ver.major >= 0x2) {
+ if (host->hw_ver.major == 0x2) {
hba->quirks |= UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION;
if (!ufs_qcom_cap_qunipro(host))
[PATCH] ACPI: Parse entire table as a term_list for Dell XPS 9570 and Precision M5530
The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out
of box.
The touchpad relies on its _INI method to update its _HID value from
to SYNA2393.
Also, the _STA relies on value of I2CN to report correct status.
Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
correctly set up, and _INI can get run. The ACPI table in this machine
is designed to get parsed this way.
Also, change the quirk table to a more generic name.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198515
Cc: Mario Limonciello
Signed-off-by: Kai-Heng Feng
---
v2: Andy's suggestion, merge to a single quirk table.
drivers/acpi/bus.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e02a28..3999e175b6f4 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -65,9 +65,38 @@ static int set_copy_dsdt(const struct dmi_system_id *id)
acpi_gbl_copy_dsdt_locally = 1;
return 0;
}
+
+static int set_gbl_term_list(const struct dmi_system_id *id)
+{
+ pr_notice("%s detected - parse the entire table as a term_list\n",
+ id->ident);
+ acpi_gbl_parse_table_as_term_list = 1;
+ return 0;
+}
#endif
-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
+static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = {
+ /*
+* Touchpad on Dell XPS 9570/Precision M5530 doesn't work under I2C
+* mode.
+* https://bugzilla.kernel.org/show_bug.cgi?id=198515
+*/
+ {
+ .callback = set_gbl_term_list,
+ .ident = "Dell Precision M5530",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Precision M5530"),
+ },
+ },
+ {
+ .callback = set_gbl_term_list,
+ .ident = "Dell XPS 15 9570",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"),
+ },
+ },
/*
* Invoke DSDT corruption work-around on all Toshiba Satellite.
* https://bugzilla.kernel.org/show_bug.cgi?id=14679
@@ -83,7 +112,7 @@ static const struct dmi_system_id dsdt_dmi_table[]
__initconst = {
{}
};
#else
-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
+static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = {
{}
};
#endif
@@ -1005,7 +1034,7 @@ void __init acpi_early_init(void)
* If the machine falls into the DMI check table,
* DSDT will be copied to memory
*/
- dmi_check_system(dsdt_dmi_table);
+ dmi_check_system(acpi_quirks_dmi_table);
status = acpi_reallocate_root_table();
if (ACPI_FAILURE(status)) {
--
2.15.1
Re: Question about dmesg/sysfs output when retpoline config is disabled
Hi Misono-san, At 01/30/2018 12:52 PM, Misono, Tomohiro wrote: Hello, I think dmesg/sysfs output messages are not suitable if retpoline config is off: I intentionally compiled the kernel 4.15.0 with CONFIG_RETPOLINE=n for test and boot it with the following kernel command line option to check dmesg/sysfs: (a) no command line option or "spectre_v2=on" or "spectre_v2=auto" $ dmesg | grep -i spectre [0.017714] Spectre V2 mitigation: Vulnerable: Minimal generic ASM retpoline $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Minimal generic ASM retpoline (b) "spectre_v2=off" $ dmesg | grep -i spectre [0.017002] Spectre V2 mitigation: disabled on command line. $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Vulnerable (c) "spectre_v2=retpoline" $ dmesg | grep -i spectre [0.018002] Spectre V2 mitigation: kernel not compiled with retpoline; no mitigation available! $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Vulnerable I think the output of (c) is correct for this case, or are these outputs actually right? Also, the output of (a) is the same with following condition: (1) CONFIG_RETPOLINE=n, and (2) CONFIG_RETPOLINE=y but the compiler did not support retpoline These cannot be distinguished unless option of (c) is explicitly used. +Cc maintainers and x86 mail list... first. IMO, Selecting 'on' or 'auto' to "spectre_v2=" should also consider the setting of the CONFIG_RETPOLINE configuration option. So, check if CONFIG_RETPOLINE is y before setup CPU capability. Thanks, dou. --8<- diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 390b3dc3d438..10188f856099 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -193,8 +193,9 @@ static void __init spectre_v2_select_mitigation(void) case SPECTRE_V2_CMD_FORCE: /* FALLTRHU */ case SPECTRE_V2_CMD_AUTO: - goto retpoline_auto; - + if (IS_ENABLED(CONFIG_RETPOLINE)) + goto retpoline_auto; + break; case SPECTRE_V2_CMD_RETPOLINE_AMD: if (IS_ENABLED(CONFIG_RETPOLINE)) goto retpoline_amd; Regards, Tomohiro Misono
RE: [PATCH RFC 01/16] prcu: Add PRCU implementation
>-Original Message-
>From: jiangshan...@gmail.com [mailto:jiangshan...@gmail.com] On Behalf Of Lai
>Jiangshan
>Sent: 2018年1月29日 17:11
>To: liangli...@huawei.com
>Cc: Paul E. McKenney ; Guohanjun (Hanjun Guo)
>; zhangheng (AC) ; Chenhaibo (Haibo,
>OS Lab) ; lihao.li...@gmail.com; LKML
>
>Subject: Re: [PATCH RFC 01/16] prcu: Add PRCU implementation
>
>On Tue, Jan 23, 2018 at 3:59 PM, wrote:
>> From: Heng Zhang
>>
>> This RCU implementation (PRCU) is based on a fast consensus protocol
>> published in the following paper:
>>
>> Fast Consensus Using Bounded Staleness for Scalable Read-mostly
>> Synchronization.
>> Haibo Chen, Heng Zhang, Ran Liu, Binyu Zang, and Haibing Guan.
>> IEEE Transactions on Parallel and Distributed Systems (TPDS), 2016.
>> https://dl.acm.org/citation.cfm?id=3024114.3024143
>>
>> Signed-off-by: Heng Zhang
>> Signed-off-by: Lihao Liang
>> ---
>> include/linux/prcu.h | 37 +++
>> kernel/rcu/Makefile | 2 +-
>> kernel/rcu/prcu.c| 125
>> +++
>> kernel/sched/core.c | 2 +
>> 4 files changed, 165 insertions(+), 1 deletion(-) create mode 100644
>> include/linux/prcu.h create mode 100644 kernel/rcu/prcu.c
>>
>> diff --git a/include/linux/prcu.h b/include/linux/prcu.h new file mode
>> 100644 index ..653b4633
>> --- /dev/null
>> +++ b/include/linux/prcu.h
>> @@ -0,0 +1,37 @@
>> +#ifndef __LINUX_PRCU_H
>> +#define __LINUX_PRCU_H
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#define CONFIG_PRCU
>> +
>> +struct prcu_local_struct {
>> + unsigned int locked;
>> + unsigned int online;
>> + unsigned long long version;
>> +};
>> +
>> +struct prcu_struct {
>> + atomic64_t global_version;
>> + atomic_t active_ctr;
>> + struct mutex mtx;
>> + wait_queue_head_t wait_q;
>> +};
>> +
>> +#ifdef CONFIG_PRCU
>> +void prcu_read_lock(void);
>> +void prcu_read_unlock(void);
>> +void synchronize_prcu(void);
>> +void prcu_note_context_switch(void);
>> +
>> +#else /* #ifdef CONFIG_PRCU */
>> +
>> +#define prcu_read_lock() do {} while (0) #define prcu_read_unlock()
>> +do {} while (0) #define synchronize_prcu() do {} while (0) #define
>> +prcu_note_context_switch() do {} while (0)
>> +
>> +#endif /* #ifdef CONFIG_PRCU */
>> +#endif /* __LINUX_PRCU_H */
>> diff --git a/kernel/rcu/Makefile b/kernel/rcu/Makefile index
>> 23803c7d..8791419c 100644
>> --- a/kernel/rcu/Makefile
>> +++ b/kernel/rcu/Makefile
>> @@ -2,7 +2,7 @@
>> # and is generally not a function of system call inputs.
>> KCOV_INSTRUMENT := n
>>
>> -obj-y += update.o sync.o
>> +obj-y += update.o sync.o prcu.o
>> obj-$(CONFIG_CLASSIC_SRCU) += srcu.o
>> obj-$(CONFIG_TREE_SRCU) += srcutree.o
>> obj-$(CONFIG_TINY_SRCU) += srcutiny.o diff --git a/kernel/rcu/prcu.c
>> b/kernel/rcu/prcu.c new file mode 100644 index ..a00b9420
>> --- /dev/null
>> +++ b/kernel/rcu/prcu.c
>> @@ -0,0 +1,125 @@
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +DEFINE_PER_CPU_SHARED_ALIGNED(struct prcu_local_struct, prcu_local);
>> +
>> +struct prcu_struct global_prcu = {
>> + .global_version = ATOMIC64_INIT(0),
>> + .active_ctr = ATOMIC_INIT(0),
>> + .mtx = __MUTEX_INITIALIZER(global_prcu.mtx),
>> + .wait_q = __WAIT_QUEUE_HEAD_INITIALIZER(global_prcu.wait_q)
>> +};
>> +struct prcu_struct *prcu = &global_prcu;
>> +
>> +static inline void prcu_report(struct prcu_local_struct *local) {
>> + unsigned long long global_version;
>> + unsigned long long local_version;
>> +
>> + global_version = atomic64_read(&prcu->global_version);
>> + local_version = local->version;
>> + if (global_version > local_version)
>> + cmpxchg(&local->version, local_version,
>> + global_version);
>
>It is called with irq-disabled, and local->version can't be modified on other
>cpu. why cmpxchg is needed?
No, it will also be called by prcu_read_unlock in this implementation.
>> +}
>> +
>> +void prcu_read_lock(void)
>> +{
>> + struct prcu_local_struct *local;
>> +
>> + local = get_cpu_ptr(&prcu_local);
>> + if (!local->online) {
>> + WRITE_ONCE(local->online, 1);
>> + smp_mb();
>
>What's is the paired code?
It is paired with the mutex_lock in synchronize_prcu.
It is used to ensure that if writer see the online is false, there must be no
online reader on this core.
>
>> + }
>> +
>> + local->locked++;
>> + put_cpu_ptr(&prcu_local);
>> +}
>> +EXPORT_SYMBOL(prcu_read_lock);
>> +
>> +void prcu_read_unlock(void)
>> +{
>> + int locked;
>> + struct prcu_local_struct *local;
>> +
>> + barrier();
>> + local = get_cpu_ptr(&prcu_local);
>> + locked = local->locked;
>> + if (locked) {
>> + local->locked--;
>> + if (locked == 1)
>> + prcu_report(local);
>> + put_cpu_ptr(&prcu_local);
Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references
On Sun, Jan 28, 2018 at 10:36 AM, Thomas Gleixner wrote:
> On Sun, 28 Jan 2018, Dan Williams wrote:
>> On Sun, Jan 28, 2018 at 12:55 AM, Ingo Molnar wrote:
>> >> + */
>> >> +#define array_idx(idx, sz) \
>> >> +({ \
>> >> + typeof(idx) _i = (idx); \
>> >> + typeof(sz) _s = (sz); \
>> >> + unsigned long _mask = array_idx_mask(_i, _s); \
>> >> + \
>> >> + BUILD_BUG_ON(sizeof(_i) > sizeof(long));\
>> >> + BUILD_BUG_ON(sizeof(_s) > sizeof(long));\
>> >> + \
>> >> + _i &= _mask;\
>> >> + _i; \
>> >> +})
>> >> +#endif /* __NOSPEC_H__ */
>> >
>> > For heaven's sake, please name a size variable as 'size', not 'sz'. We
>> > don't have
>> > a shortage of characters and can deobfuscate common primitives, can we?
>> >
>> > Also, beyond the nits, I also hate the namespace here. We have a new
>> > generic
>> > header providing two new methods:
>> >
>> > #include
>> >
>> > array_idx_mask()
>> > array_idx()
>> >
>> > which is then optimized for x86 in asm/barrier.h. That's already a
>> > non-sequitor.
>> >
>> > Then we introduce uaccess API variants with a _nospec() postfix.
>> >
>> > Then we add ifence() to x86.
>> >
>> > There's no naming coherency to this.
>>
>> Ingo, I love you, but please take the incredulity down a bit,
>> especially when I had 'nospec' in all the names in v1. Thomas, Peter,
>> and Alexei wanted s/nospec_barrier/ifence/ and
>
> Sorry, I never was involved in that discussion.
>
>> s/array_idx_nospec/array_idx/. You can always follow on with a patch
>> to fix up the names and placements to your liking. While they'll pick
>> on my name choices, they won't pick on yours, because I simply can't
>> be bothered to care about a bikeshed color at this point after being
>> bounced around for 5 revisions of this patch set.
>
> Oh well, we really need this kind of attitude right now. We are all fed up
> with that mess, but Ingo and I care about the details, consistency and
> general code quality beyond the current rush to get stuff solved. It's our
> damned job as maintainers.
Of course, and everything about the technical feedback and suggestions
was completely valid, on point, and made the patches that much better.
What wasn't appreciated and what I am tired of grinning and bearing is
the idea that it's only the maintainer that can show emotion, that
it's only the maintainer that can be exasperated and burnt out.
For example, I would have spun v6 the same day (same hour?) had the
mail started, "hey I'm late to the party, why aren't all these helpers
in a new _nospec namespace?". I might have pointed to the mails from
Peter about ifence being his preferred name for a speculation barrier
and Alexei's request to drop nospec [1] and moved on because naming is
a maintainer's prerogative.
> If you decide you don't care anymore, please let me know, so I can try to
> free up some cycles to pick up the stuff from where you decided to dump it.
Care is a two way street. I respect yours and Ingo's workload, please
respect mine.
[1]: https://lkml.org/lkml/2018/1/9/1232
Re: [GIT pull] Timer core updates for 4.16
* Linus Torvalds wrote: > On Mon, Jan 29, 2018 at 12:48 AM, Thomas Gleixner wrote: > > > > - A rather large rework of the hrtimer infrastructure which introduces > > softirq based hrtimers to replace the spread of hrtimer/tasklet combos > > which force the actual callback execution into softirq context. > > I really would have liked to see more of the rationale for this - now > I'm left with just two example drivers, and a "you'll see the cleanups > this allows in future driver pulls". > > But pulled, since the code doesn't look disgusting. Sorry, this is my fault: from Anna-Maria's original, full softirq-hrtimers series I didn't apply many of the usecases, because we didn't get any review feedback from the networking folks: can/bcm: Replace hrtimer_tasklet with softirq based hrtimer net/can/bcm.c | 156 -- 1 file changed, 52 insertions(+), 104 deletions(-) mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer drivers/net/wireless/mac80211_hwsim.c | 44 --- 1 file changed, 20 insertions(+), 24 deletions(-) xfrm: Replace hrtimer tasklet with softirq hrtimer include/net/xfrm.h| 2 +- net/xfrm/xfrm_state.c | 30 ++ 2 files changed, 19 insertions(+), 13 deletions(-) net/mvpp2: Replace tasklet with softirq hrtimer drivers/net/ethernet/marvell/mvpp2.c | 62 +++- 1 file changed, 25 insertions(+), 37 deletions(-) And I felt uneasy about applying this in one go, so we decided to apply it in two phases. These are in cases significant driver simplifications, but they also enable the real deal, the elimination of the hrtimer tasklet: softirq: Remove tasklet_hrtimer include/linux/interrupt.h | 25 --- kernel/softirq.c | 51 --- 2 files changed, 76 deletions(-) ... which is a pretty nice thing in itself even without the driver simplifications! Plus the _real_ secret motivation behind it all is the -rt kernel and CONFIG_PREEMPT_RT=y and the ability to push most of the hrtimer processing into softirq context - while it still keeps the main hrtimer machinery capable to run in hard-RT hardirq domain. Turns out it was possible to implement this duality via the softirq-hrtimers, with a good chunk of benefits to non-rt upstream as well. Thanks, Ingo
Re: [RFC PATCH 0/8] [media] Request API, take three
Hi Hans, On Mon, Jan 29, 2018 at 8:21 PM, Hans Verkuil wrote: > On 01/26/2018 07:02 AM, Alexandre Courbot wrote: >> Howdy. Here is your bi-weekly request API redesign! ;) >> >> Again, this is a simple version that only implements the flow of requests, >> without applying controls. The intent is to get an agreement on a base to >> work >> on, since the previous versions went straight back to the redesign board. >> >> Highlights of this version: >> >> * As requested by Hans, request-bound buffers are now passed earlier to >> drivers, >> as early as the request itself is submitted. Doing it earlier is not be >> useful >> since the driver would not know the state of the request, and thus cannot do >> anything with the buffer. Drivers are now responsible for applying request >> parameters themselves. >> >> * As a consequence, there is no such thing as a "request queue" anymore. The >> flow of buffers decides the order in which requests are processed. Individual >> devices of the same pipeline can implement synchronization if needed, but >> this >> is beyond this first version. >> >> * VB2 code is still a bit shady. Some of it will interfere with the fences >> series, so I am waiting for the latter to land to do it properly. >> >> * Requests that are not yet submitted effectively act as fences on the >> buffers >> they own, resulting in the buffer queue being blocked until the request is >> submitted. An alternate design would be to only block the >> not-submitted-request's buffer and let further buffers pass before it, but >> since >> buffer order is becoming increasingly important I have decided to just block >> the >> queue. This is open to discussion though. > > I don't think we should mess with the order. Agreed, let's keep it that way then. > >> >> * Documentation! Also described usecases for codec and simple (i.e. not part >> of >> a complex pipeline) capture device. > > I'll concentrate on reviewing that. > >> >> Still remaining to do: >> >> * As pointed out by Hans on the previous revision, do not assume that drivers >> using v4l2_fh have a per-handle state. I have not yet found a good way to >> differenciate both usages. > > I suspect we need to add a flag or something for this. I hope we don't need to, let's see if I can find a pattern... > >> * Integrate Hans' patchset for control handling: as said above, this is >> futile >> unless we can agree on the basic design, which I hope we can do this time. >> Chrome OS needs this really badly now and will have to move forward no matter >> what, so I hope this will be considered good enough for a common base of >> work. > > I am not sure there is any reason to not move forward with the control > handling. > You need this anyway IMHO, regardless of any public API considerations. Only reasons are my lazyness and because I wanted to focus on the request flow first. But you're right. I have a version with your control framework changes integrated (they worked on the first attempt btw! :)), let me create a clean patchset from this and send another RFC. > >> A few thoughts/questions that emerged when writing this patchset: >> >> * Since requests are exposed as file descriptors, we could easily move the >> MEDIA_REQ_CMD_SUBMIT and MEDIA_REQ_CMD_REININT commands as ioctls on the >> requests themselves, instead of having to perform them on the media device >> that >> provided the request in the first place. That would add a bit more >> flexibility >> if/when passing requests around and means the media device only needs to >> handle >> MEDIA_REQ_CMD_ALLOC. Conceptually speaking, this seems to make sense to me. >> Any comment for/against that? > > Makes sense IMHO. Glad to hear it, that was my preferred design. :) > >> * For the codec usecase, I have experimented a bit marking CAPTURE buffers >> with >> the request FD that produced them (vim2m acts that way). This seems to work >> well, however FDs are process-local and could be closed before the CAPTURE >> buffer is dequeued, rendering that information less meaningful, if not >> dangerous. > > I don't follow this. Once the fd is passed to the kernel its refcount should > be > increased so the data it represents won't be released if userspace closes the > fd. The refcount of the request is increased. The refcount of the FD is not, since it is only a userspace reference to the request. > > Obviously if userspace closes the fd it cannot do anything with it anymore, > but > it shouldn't be 'dangerous' AFAICT. It userspace later gets that closed FD back from a DQBUF call, and decides to use it again, then we would have a problem. I agree that it is userspace responsibility to be careful here, but making things foolproof never hurts. > >> Wouldn't it be better/safer to use a global request ID for >> such information instead? That ID would be returned upon MEDIA_REQ_CMD_ALLOC >> so >> user-space knows which request ID a FD refers to. > > I think it is not a good idea to have both an fd and an
Re: [RFC PATCH 6/8] v4l2: document the request API interface
On Tue, Jan 30, 2018 at 1:03 AM, Hans Verkuil wrote:
> On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
>> Document how the request API can be used along with the existing V4L2
>> interface.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> Documentation/media/uapi/v4l/buffer.rst | 10 +-
>> Documentation/media/uapi/v4l/common.rst | 1 +
>> Documentation/media/uapi/v4l/request-api.rst | 194
>> +++
>> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 21 +++
>> 4 files changed, 223 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/media/uapi/v4l/request-api.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/buffer.rst
>> b/Documentation/media/uapi/v4l/buffer.rst
>> index ae6ee73f151c..9d082784081d 100644
>> --- a/Documentation/media/uapi/v4l/buffer.rst
>> +++ b/Documentation/media/uapi/v4l/buffer.rst
>> @@ -301,10 +301,14 @@ struct v4l2_buffer
>> elements in the ``planes`` array. The driver will fill in the
>> actual number of valid elements in that array.
>> * - __u32
>> - - ``reserved2``
>> + - ``request_fd``
>>-
>> - - A place holder for future extensions. Drivers and applications
>> - must set this to 0.
>> + - The file descriptor of the request associated with this buffer.
>> + user-space can set this when calling :ref:`VIDIOC_QBUF`, and drivers
>> + will return the request used when processing a buffer (if any) upon
>> + :ref:`VIDIOC_DQBUF`.
>> +
>> + A value of 0 means the buffer is not associated with any request.
>> * - __u32
>>- ``reserved``
>>-
>> diff --git a/Documentation/media/uapi/v4l/common.rst
>> b/Documentation/media/uapi/v4l/common.rst
>> index 13f2ed3fc5a6..a4aa0059d45a 100644
>> --- a/Documentation/media/uapi/v4l/common.rst
>> +++ b/Documentation/media/uapi/v4l/common.rst
>> @@ -44,3 +44,4 @@ applicable to all devices.
>> crop
>> selection-api
>> streaming-par
>> +request-api
>> diff --git a/Documentation/media/uapi/v4l/request-api.rst
>> b/Documentation/media/uapi/v4l/request-api.rst
>> new file mode 100644
>> index ..a758a5fd3ca0
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/request-api.rst
>> @@ -0,0 +1,194 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _media-request-api:
>> +
>> +Request API
>> +===
>> +
>> +The Request API has been designed to allow V4L2 to deal with requirements of
>> +modern IPs (stateless codecs, MIPI cameras, ...) and APIs (Android Codec
>> v2).
>> +One such requirement is the ability for devices belonging to the same
>> pipeline
>> +to reconfigure and collaborate closely on a per-frame basis. Another is
>> +efficient support of stateless codecs, which need per-frame controls to be
>> set
>> +asynchronously in order to be efficiently used.
>> +
>> +Supporting these features without the Request API is possible but terribly
>> +inefficient: user-space would have to flush all activity on the media
>> pipeline,
>> +reconfigure it for the next frame, queue the buffers to be processed with
>> that
>> +configuration, and wait until they are all available for dequeing before
>> +considering the next frame. This defeats the purpose of having buffer queues
>> +since in practice only one buffer would be queued at a time.
>> +
>> +The Request API allows a specific configuration of the pipeline (media
>> +controller topology + controls for each device) to be associated with
>> specific
>> +buffers. The parameters are applied by each participating device as buffers
>> +associated to a request flow in. This allows user-space to schedule several
>> +tasks ("requests") with different parameters in advance, knowing that the
>> +parameters will be applied when needed to get the expected result. Controls
>> +values at the time of request completion are also available for reading.
>> +
>> +Usage
>> +=
>> +
>> +The Request API is used on top of standard media controller and V4L2 calls,
>> +which are augmented with an extra ``request_fd`` parameter. All operations
>> on
>> +requests themselves are performed using the command parameter of the
>> +:c:func:`MEDIA_IOC_REQUEST_CMD` ioctl.
>> +
>> +Allocation
>> +--
>> +
>> +User-space allocates requests using the ``MEDIA_REQ_CMD_ALLOC`` command on
>> +an opened media device. This returns a file descriptor representing the
>> +request. Typically, several such requests will be allocated.
>> +
>> +Request Preparation
>> +---
>> +
>> +Standard V4L2 ioctls can then receive a request file descriptor to express
>> the
>> +fact that the ioctl is part of said request, and is not to be applied
>> +immediately. V4L2 ioctls supporting this are :c:func:`VIDIOC_S_EXT_CTRLS`
>> and
>> +:c:func:`VIDIOC_QBUF`. Controls set with a request parameter are stored
>> instead
>> +of being immediately applied, and queued buffers will block the buffer queue
>> +until the request becomes active.
>> +
>> +RFC Note: currently seve
Re: [RFC PATCH 5/8] media: Document the media request API
On Tue, Jan 30, 2018 at 1:04 AM, Hans Verkuil wrote: > On 01/26/2018 07:02 AM, Alexandre Courbot wrote: >> From: Laurent Pinchart >> >> The media request API is made of a new ioctl to implement request >> management. Document it. >> >> Signed-off-by: Laurent Pinchart >> [acour...@chromium.org: adapt for newest API] >> Signed-off-by: Alexandre Courbot >> --- >> Documentation/media/uapi/mediactl/media-funcs.rst | 1 + >> .../media/uapi/mediactl/media-ioc-request-cmd.rst | 140 >> + >> 2 files changed, 141 insertions(+) >> create mode 100644 >> Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst >> >> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst >> b/Documentation/media/uapi/mediactl/media-funcs.rst >> index 076856501cdb..e3a45d82ffcb 100644 >> --- a/Documentation/media/uapi/mediactl/media-funcs.rst >> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst >> @@ -15,4 +15,5 @@ Function Reference >> media-ioc-g-topology >> media-ioc-enum-entities >> media-ioc-enum-links >> +media-ioc-request-cmd >> media-ioc-setup-link >> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst >> b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst >> new file mode 100644 >> index ..17223e8170e9 >> --- /dev/null >> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst >> @@ -0,0 +1,140 @@ >> +.. -*- coding: utf-8; mode: rst -*- >> + >> +.. _media_ioc_request_cmd: >> + >> +*** >> +ioctl MEDIA_IOC_REQUEST_CMD >> +*** >> + >> +Name >> + >> + >> +MEDIA_IOC_REQUEST_CMD - Manage media device requests >> + >> + >> +Synopsis >> + >> + >> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_CMD, struct >> media_request_cmd *argp ) >> +:name: MEDIA_IOC_REQUEST_CMD >> + >> + >> +Arguments >> += >> + >> +``fd`` >> +File descriptor returned by :ref:`open() `. >> + >> +``argp`` >> + >> + >> +Description >> +=== >> + >> +The MEDIA_IOC_REQUEST_CMD ioctl allow applications to manage media device >> +requests. A request is an object that can group media device configuration >> +parameters, including subsystem-specific parameters, in order to apply all >> the >> +parameters atomically. Applications are responsible for allocating and >> +deleting requests, filling them with configuration parameters submitting >> them. >> + >> +Request operations are performed by calling the MEDIA_IOC_REQUEST_CMD ioctl >> +with a pointer to a struct :c:type:`media_request_cmd` with the cmd field >> set >> +to the appropriate command. :ref:`media-request-command` lists the commands >> +supported by the ioctl. >> + >> +The struct :c:type:`media_request_cmd` request field contains the file >> +descriptorof the request on which the command operates. For the >> +``MEDIA_REQ_CMD_ALLOC`` command the field is set to zero by applications and >> +filled by the driver. For all other commands the field is set by >> applications >> +and left untouched by the driver. >> + >> +To allocate a new request applications use the ``MEDIA_REQ_CMD_ALLOC`` >> +command. The driver will allocate a new request and return its ID in the > > ID -> FD Indeed, this is a leftover from the original documentation. > >> +request field. >> + >> +Requests are reference-counted. A newly allocated request is referenced >> +by the returned file descriptor, and can be later referenced by >> +subsystem-specific operations. Requests will thus be automatically deleted >> +when they're not longer used after the returned file descriptor is closed. >> + >> +If a request isn't needed applications can delete it by calling ``close()`` >> +on it. The driver will drop the file handle reference. The request will not >> +be usable through the MEDIA_IOC_REQUEST_CMD ioctl anymore, but will only be >> +deleted when the last reference is released. If no other reference exists >> when >> +``close()`` is invoked the request will be deleted immediately. >> + >> +After creating a request applications should fill it with configuration >> +parameters. This is performed through subsystem-specific request APIs >> outside >> +the scope of the media controller API. See the appropriate subsystem APIs >> for >> +more information, including how they interact with the MEDIA_IOC_REQUEST_CMD >> +ioctl. >> + >> +Once a request contains all the desired configuration parameters it can be >> +submitted using the ``MEDIA_REQ_CMD_SUBMIT`` command. This will let the >> +buffers queued for the request be passed to their respective drivers, which >> +will then apply the request's parameters before processing them. >> + >> +Once a request has been queued applications are not allowed to modify its >> +configuration parameters until the request has been fully processed. Any >> +attempt to do so will result in the related subsystem API returning an >> error. >> +The application that submitted the request can wait for its com
Re: [PATCH RFC 01/16] prcu: Add PRCU implementation
On Tue, Jan 30, 2018 at 05:34:03AM +, zhangheng (AC) wrote:
[...]
> >> > +static void prcu_handler(void *info) {
> >> > +struct prcu_local_struct *local;
> >> > +
> >> > +local = this_cpu_ptr(&prcu_local);
> >> > +if (!local->locked)
> >
> >And I think a smp_mb() is needed here, because in the following case:
> >
> > CPU 0 CPU 1
> > == ==
> > {X is initially 0}
> >
> > WRITE_ONCE(X, 1);
> >
> > prcu_read_unlock(void):
> > if (locked) {
> > synchronize_prcu(void):
> > ...
> >
> > local->locked--;
> > # switch to IPI
> > WRITE_ONCE(local->version,)
> > > latest>
> >
> >
> > r1 = READ_ONCE(X);
> >
> >r1 could be 0, which breaks RCU guarantees.
> >
>
> Thank you.
> As I know,
> it guarantees that the interrupt to be handled after all write instructions
> issued before have complete in x86 arch.
> So the smp_mb is meaningless in x86 arch.
Sure. x86 is TSO, and we are talking about reordering of two stores
here, and that can not happen on TSO.
> But I am not sure whether other archs guarantee this feature. If not, we do
> need a smp_mb here.
>
I think most of the weak memory model don't have this gaurantee, so you
need a smp_mb() or use smp_store_release().
> >> > +WRITE_ONCE(local->version,
> >> > atomic64_read(&prcu->global_version));
> >> > +}
> >> > +
> >> > +void synchronize_prcu(void)
> >> > +{
> >> > +int cpu;
> >> > +cpumask_t cpus;
> >> > +unsigned long long version;
> >> > +struct prcu_local_struct *local;
> >> > +
> >> > +version = atomic64_add_return(1, &prcu->global_version);
> >> > +mutex_lock(&prcu->mtx);
> >> > +
> >> > +local = get_cpu_ptr(&prcu_local);
> >> > +local->version = version;
> >> > +put_cpu_ptr(&prcu_local);
> >> > +
> >> > +cpumask_clear(&cpus);
> >> > +for_each_possible_cpu(cpu) {
> >> > +local = per_cpu_ptr(&prcu_local, cpu);
> >> > +if (!READ_ONCE(local->online))
> >> > +continue;
> >> > +if (READ_ONCE(local->version) < version) {
> >>
> >> On 32-bit systems, given that ->version is long long, you might see
> >> load tearing. And on some 32-bit systems, the cmpxchg() in
> >> prcu_hander() might not build.
> >>
> >
> >/me curious about why an atomic64_t is used here for global version. I think
> >maybe 32bit global version still suffices.
> >
> >Regards,
> >Boqun
>
> Because the synchronization latency is low, it can have higher gp frequency.
> It seems that 32bit can only correctly work for several years if there are
> 20+ gps per second.
>
Because PRCU doesn't handle gp number overflow? May I ask why this is
difficult? Currently RCU could tolerate counter wrap for grace period:
https://lwn.net/Articles/652677/ (Details in "Parallelism facts of
life")
Is there any subtle difference I'm missing?
Regards,
Boqun
> >
> >> Or is the idea that only prcu_handler() updates ->version? But in
> >> that case, you wouldn't need the READ_ONCE() above. What am I missing
> >> here?
> >>
> >> > +smp_call_function_single(cpu, prcu_handler,
> >> > NULL, 0);
> >> > +cpumask_set_cpu(cpu, &cpus);
> >> > +}
> >> > +}
> >> > +
> >> > +for_each_cpu(cpu, &cpus) {
> >> > +local = per_cpu_ptr(&prcu_local, cpu);
> >> > +while (READ_ONCE(local->version) < version)
> >>
> >> This ->version read can also tear on some 32-bit systems, and this one
> >> most definitely can race with the prcu_handler() above. Does the
> >> algorithm operate correctly in that case? (It doesn't look that way
> >> to me, but I might be missing something.) Or are 32-bit systems excluded?
> >>
> >> > +cpu_relax();
> >> > +}
> >>
> >> I might be missing something, but I believe we need a memory barrier
> >> here on non-TSO systems. Without that, couldn't we miss a preemption?
> >>
> >> > +
> >> > +if (atomic_read(&prcu->active_ctr))
> >> > +wait_event(prcu->wait_q,
> >> > !atomic_read(&prcu->active_ctr));
> >> > +
> >> > +mutex_unlock(&prcu->mtx);
> >> > +}
> >> > +EXPORT_SYMBOL(synchronize_prcu);
> >> > +
> >> > +void prcu_note_context_switch(void) {
> >> > +struct prcu_local_struct *local;
> >> > +
> >> > +local = get_cpu_ptr(&prcu_local);
> >> > +if (local->locked) {
> >> > +atomic_add(
[PATCH 2/2] x86/mm/64: Add vsyscall page to /proc/kcore conditionally
The vsyscall page should be visible only if vsyscall=emulate/native when dumping /proc/kcore. Signed-off-by: Jia Zhang --- arch/x86/mm/init_64.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index dab78f6..3d4cf33 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -1186,8 +1186,9 @@ void __init mem_init(void) register_page_bootmem_info(); /* Register memory areas for /proc/kcore */ - kclist_add(&kcore_vsyscall, (void *)VSYSCALL_ADDR, - PAGE_SIZE, KCORE_USER); + if (get_gate_vma(&init_mm)) + kclist_add(&kcore_vsyscall, (void *)VSYSCALL_ADDR, + PAGE_SIZE, KCORE_USER); mem_init_print_info(NULL); } -- 1.8.3.1
[PATCH 1/2] /proc/kcore: Fix SMAP violation when dumping vsyscall user page
The commit df04abfd181a
("fs/proc/kcore.c: Add bounce buffer for ktext data") introduces a
bounce buffer to work around CONFIG_HARDENED_USERCOPY=y. However,
accessing vsyscall user page will cause SMAP violation in this way.
In order to fix this issue, simply replace memcpy() with copy_from_user()
may work, but using a common way to handle this sort of user page may be
useful for future.
Currently, only vsyscall page requires KCORE_USER.
Signed-off-by: Jia Zhang
---
arch/x86/mm/init_64.c | 2 +-
fs/proc/kcore.c | 4
include/linux/kcore.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 4a83728..dab78f6 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1187,7 +1187,7 @@ void __init mem_init(void)
/* Register memory areas for /proc/kcore */
kclist_add(&kcore_vsyscall, (void *)VSYSCALL_ADDR,
-PAGE_SIZE, KCORE_OTHER);
+ PAGE_SIZE, KCORE_USER);
mem_init_print_info(NULL);
}
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 4bc85cb..e4b0204 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -510,6 +510,10 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr, int
dataoff)
/* we have to zero-fill user buffer even if no read */
if (copy_to_user(buffer, buf, tsz))
return -EFAULT;
+ } else if (m->type == KCORE_USER) {
+ /* user page is handled prior to normal kernel page */
+ if (copy_to_user(buffer, (char *)start, tsz))
+ return -EFAULT;
} else {
if (kern_addr_valid(start)) {
unsigned long n;
diff --git a/include/linux/kcore.h b/include/linux/kcore.h
index 7ff25a8..80db19d 100644
--- a/include/linux/kcore.h
+++ b/include/linux/kcore.h
@@ -10,6 +10,7 @@ enum kcore_type {
KCORE_VMALLOC,
KCORE_RAM,
KCORE_VMEMMAP,
+ KCORE_USER,
KCORE_OTHER,
};
--
1.8.3.1
Re: [PATCH v2] dmaengine: dmatest: fix container_of member in dmatest_callback
On Mon, Jan 29, 2018 at 02:40:11PM +0800, Yang Shunyong wrote: > The type of arg passed to dmatest_callback is struct dmatest_done. > It refers to test_done in struct dmatest_thread, not done_wait. Applied, thanks -- ~Vinod
Re: [PATCH 1/1] scsi: ufs-qcom: remove broken hci version quirk
On 1/30/2018 11:33 AM, Vivek Gautam wrote:
Hi Asutosh,
On 1/30/2018 10:11 AM, Asutosh Das wrote:
From: Subhash Jadavani
UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host
controller version 2.x.y and this has been fixed from version 3.x.y
onwards, hence this change removes this quirk for version 3.x.y onwards.
Signed-off-by: Subhash Jadavani
Signed-off-by: Asutosh Das
---
This patch and all other ufs patches that you have posted recently,
do they all fall under one 'ufs-qcom fixes' patch series for fixes that
we would want to do?
If it is so, then please club them together in a series, so that
it's easy for reviewers and maintainers to review, and keep track
of all the patches that can get-in after the reviews.
If they belong to two or more separate patch-series then please
create such patch series.
It's difficult to read through a lot of [PATCH 1/1] ... patch.
Sure Vivek - Makes sense. Will resend it.
Regards
Vivek
drivers/scsi/ufs/ufs-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2b38db2..221820a 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1098,7 +1098,7 @@ static void ufs_qcom_advertise_quirks(struct
ufs_hba *hba)
hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC;
}
- if (host->hw_ver.major >= 0x2) {
+ if (host->hw_ver.major == 0x2) {
hba->quirks |= UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION;
if (!ufs_qcom_cap_qunipro(host))
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: [PATCH net-next] ptr_ring: fix integer overflow
On 2018年01月30日 01:01, David Miller wrote:
From: Jason Wang
Date: Thu, 25 Jan 2018 15:31:42 +0800
We try to allocate one more entry for lockless peeking. The adding
operation may overflow which causes zero to be passed to kmalloc().
In this case, it returns ZERO_SIZE_PTR without any notice by ptr
ring. Try to do producing or consuming on such ring will lead NULL
dereference. Fix this detect and fail early.
Fixes: bcecb4bbf88a ("net: ptr_ring: otherwise safe empty checks can overrun array
bounds")
Reported-by: syzbot+87678bcf753b44c39...@syzkaller.appspotmail.com
Cc: John Fastabend
Signed-off-by: Jason Wang
I'm dropping this because I am to understand that Michael Tsirkin's patch
series covers this issue.
Yes.
Let me know if I still need to apply this.
Thanks.
No need for this.
Thanks
Re: [PATCH v5 04/12] x86: introduce __uaccess_begin_nospec and ifence
* Dan Williams wrote: > > The flip side is that if the MFENCE stalls the STAC that is ahead of it > > could be > > processed for 'free' - while it's always post barrier with my suggestion. > > This 'for free' aspect is what I aiming for. Ok. > > > > But in any case it would be nice to see a discussion of this aspect in the > > changelog, even if the patch does not change. > > I'll add a note to the changelog that having the fence after the > 'stac' hopefully allows some overlap of the cost of 'stac' and the > flushing of the instruction pipeline. Perfect! Thanks, Ingo
Re: [PATCH] PCI: Add SPDX GPL-2.0+ to replace implicit GPL v2 or later statement
On Mon, Jan 29, 2018 at 06:40:52PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> 7441b0627e22 ("s390/pci: PCI hotplug support via SCLP") added
> s390_pci_hpc.c, which included this license information:
>
> +MODULE_LICENSE("GPL");
>
> Based on "git show 7441b0627e22:include/linux/module.h", that "GPL" string
> means "GPL v2 or later":
>
>* "GPL" [GNU Public License v2 or later]
>
> 0729dcf24832 ("s390: hotplug: make pci_hpc explicitly non-modular")
> subsequently replaced the MODULE_LICENSE() with a "License: GPL" comment.
>
> Add SPDX GPL-2.0+ and remove the "License: GPL" comment, relying on the
> assertion in b24413180f56 ("License cleanup: add SPDX GPL-2.0 license
> identifier to files with no license") that the SPDX identifier may be used
> instead of the full boilerplate text.
>
> Signed-off-by: Bjorn Helgaas
Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 8/8] platform: vivid-cec: fix potential integer overflow in vivid_cec_pin_adap_events
Hi Gustavo,
On 01/30/2018 01:33 AM, Gustavo A. R. Silva wrote:
> Cast len to const u64 in order to avoid a potential integer
> overflow. This variable is being used in a context that expects
> an expression of type const u64.
>
> Addresses-Coverity-ID: 1454996 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/media/platform/vivid/vivid-cec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vivid/vivid-cec.c
> b/drivers/media/platform/vivid/vivid-cec.c
> index b55d278..30240ab 100644
> --- a/drivers/media/platform/vivid/vivid-cec.c
> +++ b/drivers/media/platform/vivid/vivid-cec.c
> @@ -83,7 +83,7 @@ static void vivid_cec_pin_adap_events(struct cec_adapter
> *adap, ktime_t ts,
> if (adap == NULL)
> return;
> ts = ktime_sub_us(ts, (CEC_TIM_START_BIT_TOTAL +
> -len * 10 * CEC_TIM_DATA_BIT_TOTAL));
> +(const u64)len * 10 * CEC_TIM_DATA_BIT_TOTAL));
This makes no sense. Certainly the const part is pointless. And given that
len is always <= 16 there definitely is no overflow.
I don't really want this cast in the code.
Sorry,
Hans
> cec_queue_pin_cec_event(adap, false, ts);
> ts = ktime_add_us(ts, CEC_TIM_START_BIT_LOW);
> cec_queue_pin_cec_event(adap, true, ts);
>
Re: [PATCH 4.4 00/74] 4.4.114-stable review
On Mon, Jan 29, 2018 at 02:30:53PM -0700, Nathan Chancellor wrote: > On Mon, Jan 29, 2018 at 01:56:05PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.114 release. > > There are 74 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jan 31 12:38:21 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.114-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.4.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. > > No conflicts, no initial issues noticed in dmesg or general usage. > > Reference trees for Android: https://github.com/android-linux-stable Very nice, thanks for testing and letting me know. greg k-h
Re: [PATCH 3.18 00/52] 3.18.93-stable review
On Mon, Jan 29, 2018 at 04:58:05PM -0700, Shuah Khan wrote: > On 01/29/2018 05:56 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.93 release. > > There are 52 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jan 31 12:36:07 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.93-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-3.18.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 3.18 00/52] 3.18.93-stable review
On Tue, Jan 30, 2018 at 05:09:07AM +, Harsh Shandilya wrote: > On Tue 30 Jan, 2018, 2:20 AM Greg Kroah-Hartman, > wrote: > > > This is the start of the stable review cycle for the 3.18.93 release. > > There are 52 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Jan 31 12:36:07 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.93-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-3.18.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Builds and boots on the OnePlus 3, no dmesg or userspace regressions. Yeah, it's still working! :) thanks for testing and letting me know. greg k-h
Re: [PATCHv1] Add Intel Stratix10 service layer driver
On Mon, Jan 29, 2018 at 08:08:11PM -0600, Richard Gong wrote: > Hi Greg, > > Many thanks for your reviews. > > > On 01/25/2018 10:53 AM, Greg KH wrote: > > On Thu, Jan 25, 2018 at 10:39:03AM -0600, richard.g...@linux.intel.com > > wrote: > > > From: Richard Gong > > > > > > Intel Stratix10 SoC is composed of a 64 bit quad-core ARM Cortex A53 hard > > > processor system (HPS) and Secure Device Manager (SDM). SDM is the > > > hardware > > > which does the FPGA configuration, QSPI, Crypto and warm reset. > > > > > > When the FPGA is configured from HPS, there needs to be a way for HPS to > > > notify SDM the location and size of the configuration data. Then SDM will > > > get the configuration data from that location and perform the FPGA > > > configuration. > > > > > > To meet the whole system security needs and support virtual machine > > > requesting communication with SDM, only the secure world of software (EL3, > > > Exception Level 3) can interface with SDM. All software entities running > > > on other exception levels must channel through the EL3 software whenever > > > it > > > needs service from SDM. > > > > > > Intel Stratix10 service layer driver is added to provide the service for > > > FPGA configuration. Running at privileged exception level (EL1, Exception > > > Level 1), Intel Stratix10 service layer driver interfaces with the service > > > provider at EL1 (Intel Stratix10 FPGA Manager) and manages secure monitor > > > call (SMC) to communicate with secure monitor software at secure monitor > > > exception level (EL3). > > > > > > Later the Intel Stratix10 service layer driver will be extended to provide > > > services for QSPI, Crypto and warm reset. > > > > > > Richard Gong (1): > > >driver: misc: add Intel Stratix10 service layer driver > > > > > > drivers/misc/Kconfig | 3 +- > > > drivers/misc/Makefile | 3 +- > > > drivers/misc/intel-service/Kconfig | 9 + > > > drivers/misc/intel-service/Makefile| 2 + > > > drivers/misc/intel-service/intel_service.c | 703 > > > + > > > include/linux/intel-service-client.h | 227 ++ > > > include/linux/intel-service.h | 122 + > > > include/linux/intel-smc.h | 246 ++ > > Simple questions first: > > - why do you have 3 different .h files for a single .c file? > This is because service layer driver interface with both the service > provider and secure monitor SW. > intel-service-client.h is created to define interface between service > providers (FPGA manager is one of them) and service layer. Alan Tull's FPGA > manager .c file includes this header file > intel-smc.h defines the secure monitor call (SMC) message protocols used for > service layer driver in normal world (EL1) to communicate with secure > monitor SW in secure monitor exception level 3 (EL3). Also this header file > is shared with firmware since both (FW, service layer) utilizes the same SMC > message protocol. > intel-sevice.h is created to define service layer's own data structures > (service controller, channel for communicating with service provider, shared > memory region, private data etc) That's very complex for a single patch submission, don't you think? Please do not add new apis / interfaces for code that is not part of your patch series, otherwise we don't know what the future is going to hold :) This feels like it should be a series of patches, to properly explain this and hook up all of the new interfaces you are adding, right? thanks, greg k-h
[PATCH] RISC-V: Enable IRQ during exception handling
Interrupt is allowed during exception handling. There are warning messages if the kernel enables the configuration 'CONFIG_DEBUG_ATOMIC_SLEEP=y'. BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:23 in_atomic(): 0, irqs_disabled(): 1, pid: 43, name: ash CPU: 0 PID: 43 Comm: ash Tainted: GW 4.15.0-rc8-00089-g89ffdae-dirty #17 Call Trace: [<9abb1587>] walk_stackframe+0x0/0x7a [] ___might_sleep+0x102/0x11a [ ] down_read+0x18/0x28 [<0289ec01>] do_page_fault+0x86/0x2f6 [<012441f6>] _do_fork+0x1b4/0x1e0 [ ] ret_from_syscall+0xa/0xe Signed-off-by: Zong Li --- arch/riscv/kernel/entry.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 7404ec2..61f063e 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -169,6 +169,9 @@ ENTRY(handle_exception) move a1, sp /* pt_regs */ tail do_IRQ 1: + /* Exceptions run with interrupts enabled */ + csrs sstatus, SR_SIE + /* Handle syscalls */ li t0, EXC_SYSCALL beq s4, t0, handle_syscall @@ -195,8 +198,6 @@ handle_syscall: */ addi s2, s2, 0x4 REG_S s2, PT_SEPC(sp) - /* System calls run with interrupts enabled */ - csrs sstatus, SR_SIE /* Trace syscalls, but only if requested by the user. */ REG_L t0, TASK_TI_FLAGS(tp) andi t0, t0, _TIF_SYSCALL_TRACE -- 2.9.3
Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)
On Mon 29-01-18 23:35:22, Florian Westphal wrote: > Kirill A. Shutemov wrote: [...] > > I hate what I'm saying, but I guess we need some tunable here. > > Not sure what exactly. > > Would memcg help? That really depends. I would have to check whether vmalloc path obeys __GFP_ACCOUNT (I suspect it does except for page tables allocations but that shouldn't be a big deal). But then the other potential problem is the life time of the xt_table_info (or other potentially large) data structures. Are they bound to any process life time. Because if they are not then the OOM killer will not help. The OOM panic earlier in this thread suggests it doesn't because the test case managed to eat all the available memory and killed all the eligible tasks which didn't help. So in some sense the memcg would help to stop the excessive allocation, but it wouldn't resolve it other than kill all tasks in the affected memcg/container. Whether this is sufficient or not, I dunno. It sounds quite suboptimal to me. But it is true this would be less tricky then adding a global knob... -- Michal Hocko SUSE Labs
Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.
Hi, On Mon, Jan 29, 2018 at 03:34:02PM +0100, Arnd Bergmann wrote: > On Mon, Jan 29, 2018 at 10:25 AM, Linus Walleij > wrote: > > On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard > > wrote: > >> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote: > >> However, in DT systems, that > >> field is filled only with the parent's node dma-ranges property. In > >> our case, and since the DT parenthood is based on the "control" bus, > >> and not the "data" bus, our parent node would be the AXI bus, and not > >> the memory bus that enforce those constraints. > >> > >> And other devices doing DMA through regular DMA accesses won't have > >> that mapping, so we definitely shouldn't enforce it for all the > >> devices there, but only the one connected to the separate memory bus. > >> > >> tl; dr: the DT is not really an option to store that info. > >> > >> I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too > >> fond of that approach either at the time. > >> > >> So, well, I guess we could do better. We just have no idea how :) > > > > Usually of Arnd cannot suggest something smart, neither can I :( > > > > If some aspect of the memory layout of the system *really* doesn't > > fit into DT because of the assumptions that DT is doing about > > how systems work, we have a problem. > > > > Is the problem that DT's model assumes that devices have one and > > only one data port to the system memory, and that is how it > > populates the Linux devices? > > > > I guess, if nothing else works, I would use auxdata in the board file. > > It is our definitive last resort when DT doesn't hold. > > > > I.e. I would go into struct of_dev_auxdata > > (from ) and add a > > dma_pfn_offset field that gets set into the device's dma_pfn_offset > > in drivers/of/platform.c overriding anything else and use that to hammer > > it down in the boardfile. > > > > But I bet some DT people are going to have other ideas. > > At one point we had discussed adding a 'dma-masters' property that > lists all the buses on which a device can be a dma master, and > the respective properties of those masters (iommu, coherency, > offset, ...). > > IIRC at the time we decided that we could live without that complexity, > but perhaps we cannot. Are you talking about this ? https://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/dma/dma.txt#L41 It doesn't seem to be related to that issue to me. And in our particular cases, all the devices are DMA masters, the RAM is just mapped to another address. > Another local hack that we can do here is to have two separate > device nodes and let the device driver bind to one device and then > look up the other one through a phandle to look up a platform_device > for it, which it can then use with the DMA mapping interface. We have multiple devices doing that, a couple of them already merged (mostly on the display side). I'd rather not do that. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages
On Tue 30-01-18 02:56:51, He, Roger wrote: > Hi Michal: > > We need a API to tell TTM module the system totally has how many swap > cache. Then TTM module can use it to restrict how many the swap cache > it can use to prevent triggering OOM. For Now we set the threshold of > swap size TTM used as 1/2 * total size and leave the rest for others > use. Why do you so much memory? Are you going to use TB of memory on large systems? What about memory hotplug when the memory is added/released? > But get_nr_swap_pages is the only API we can accessed from other > module now. It can't cover the case of the dynamic swap size > increment. I mean: user can use "swapon" to enable new swap file or > swap disk dynamically or "swapoff" to disable swap space. Exactly. Your scaling configuration based on get_nr_swap_pages or the available memory simply sounds wrong. -- Michal Hocko SUSE Labs
Re: [perf] perf probe fails sometimes on 4.9
Hi All, 'perf probe' is failing sometimes on 4.9.20 with AMD-64. # perf probe --add schedule schedule is out of .text, skip it. Error: Failed to add events. If any one have come across this problem please let me know the cause. Note: I don't have CONFIG_DEBUG_INFO enabled in kernel. Is this the problem? However, I manually copied the vmlinux file to /boot/ directory, but still it does not work. I checked upstream patches until 4.15 but could not find any clue. Please let me know if there is any fixes available for this. Thank You! Regards, Pintu On Thu, Jan 25, 2018 at 7:09 PM, Pintu Kumar wrote: > Hi, > > ** Changed the subject now, since these issues are related to general > perf commands. > > Following are the issues: > > 1) perf probe --add schedule - FAILED > output: > schedule is out of .text, skip it. > Error: Failed to add events. > > what is the issue here? > Sometimes it pass and sometimes it fails... > Similar is the case of 'perf inject' as well. > > 2) perf test - 1 FAILURE > 37.1: Test basic BPF filtering : FAILED! > 37.2: Test BPF prologue generation : Skip > 37.3: Test BPF relocation checker: Skip > > bpf: config program 'func=SyS_epoll_wait' > symbol:SyS_epoll_wait file:(null) line:0 offset:0 return:0 lazy:(null) > bpf: config 'func=SyS_epoll_wait' is ok > Looking at the vmlinux_path (8 entries long) > Using /boot/vmlinux for symbols > Could not open debuginfo. Try to use symbols. > SyS_epoll_wait is out of .text, skip it. > bpf_probe: failed to convert perf probe eventsFailed to add events > selected by BPF > test child finished with -1 > end > Test BPF filter subtest 0: FAILED! > > Looks like both 1,2 are related. > Since, CONFIG_DEBUG_INFO is not enabled, I manually copied the vmlinux > to /boot/ folder. > > --- > Some more info: > > Kernel build dir is set to /lib/modules/4.9.20-sc-amd-x86-64/build > set env: KBUILD_DIR=/lib/modules/4.9.20-sc-amd-x86-64/build > unset env: KBUILD_OPTS > include option is set to -nostdinc -isystem > /usr/lib/gcc/x86_64-linux-gnu/5/include -I./arch/x86/include > -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated > -I./include -I./arch/x86/include/uapi -I./include/uapi > -I./include/generated/uapi -include ./include/linux/kconfig.h > set env: NR_CPUS=8 > set env: LINUX_VERSION_CODE=0x40914 > set env: CLANG_EXEC=/usr/bin/clang > set env: CLANG_OPTIONS=-xc > set env: KERNEL_INC_OPTIONS= -nostdinc -isystem > /usr/lib/gcc/x86_64-linux-gnu/5/include -I./arch/x86/include > -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated > -I./include -I./arch/x86/include/uapi -I./include/uapi > -I./include/generated/uapi -include ./include/linux/kconfig.h > set env: WORKING_DIR=/lib/modules/4.9.20-sc-amd-x86-64/build > > > If you have any clue about these failure please help me. > > > Thanks, > Pintu > > > On Wed, Jan 24, 2018 at 8:23 PM, Pintu Kumar wrote: >> Hi, >> >> Thanks for your help. >> Yes it was a sub version issue. >> >> Earlier, while building the kernel I left the SUBLEVEL as blank. >> >> make -j8 bindeb-pkg SUBLEVEL=20 >> >> After passing the correct sublevel now the test is working. >> >> But still following are failing: >> >> 16: Try 'import perf' in python, checking link problems : FAILED! >> 37.2: Test BPF prologue generation : FAILED! >> >> >> This is the error I get: >> >> 16: Try 'import perf' in python, checking link problems : >> --- start --- >> test child forked, pid 7637 >> Traceback (most recent call last): >> File "", line 1, in >> ImportError: No module named perf >> test child finished with -1 >> end >> Try 'import perf' in python, checking link problems: FAILED! >> >> >> Looking at the vmlinux_path (8 entries long) >> symsrc__init: cannot get elf header. >> Failed to find the path for kernel: Invalid ELF file >> bpf_probe: failed to convert perf probe eventsFailed to add events >> selected by BPF >> test child finished with -1 >> end >> Test BPF filter subtest 1: FAILED! >> >> >> >> Thanks, >> Pintu >> >> >> On Wed, Jan 24, 2018 at 6:39 AM, Wangnan (F) wrote: >>> >>> >>> On 2018/1/23 20:37, Pintu Kumar wrote: Hi All, I am verifying all perf tests on Ubuntu-16 x86-64 platform using the kernel version 4.9.20. I have installed several others packages including: clang, llvm But, when I run 'perf test' I get some FAILURE. Specially, 'perf test LLVM' is failing. Please check the below error logs: # perf test LLVM 35: Test LLVM searching and compiling: 35.1: Basic BPF llvm compiling test : FAILED! 35.2: Test kbuild searching : Skip 35.3: Compile source for BPF prologue generation test: Skip 35.4: Compile source for BP
Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT
On 01/28/18 19:21, Masahiro Yamada wrote: > Hi Frank, > > 2018-01-29 11:53 GMT+09:00 : >> From: Frank Rowand >> diff --git a/drivers/of/unittest-data/Makefile >> b/drivers/of/unittest-data/Makefile >> index df697976740a..2b7ee68c908e 100644 >> --- a/drivers/of/unittest-data/Makefile >> +++ b/drivers/of/unittest-data/Makefile >> @@ -3,6 +3,21 @@ DTC_FLAGS_testcases := -Wno-interrupts_property >> obj-y += testcases.dtb.o >> >> obj-$(CONFIG_OF_OVERLAY) += overlay.dtb.o \ >> + overlay_0.dtb.o \ >> + overlay_1.dtb.o \ >> + overlay_2.dtb.o \ >> + overlay_3.dtb.o \ >> + overlay_4.dtb.o \ >> + overlay_5.dtb.o \ >> + overlay_6.dtb.o \ >> + overlay_7.dtb.o \ >> + overlay_8.dtb.o \ >> + overlay_9.dtb.o \ >> + overlay_10.dtb.o \ >> + overlay_11.dtb.o \ >> + overlay_12.dtb.o \ >> + overlay_13.dtb.o \ >> + overlay_15.dtb.o \ >> overlay_bad_phandle.dtb.o \ >> overlay_bad_symbol.dtb.o \ >> overlay_base.dtb.o >> @@ -14,6 +29,7 @@ DTC_FLAGS_overlay := -@ >> DTC_FLAGS_overlay_bad_phandle := -@ >> DTC_FLAGS_overlay_bad_symbol := -@ >> DTC_FLAGS_overlay_base := -@ >> +DTC_FLAGS_testcases := -@ >> > > This overwrites '-Wno-interrupts_property' a few lines above. > > Perhaps, do you want to do like this? > > DTC_FLAGS_testcases += -@ > > or > > DTC_FLAGS_testcases := -Wno-interrupts_property -@ Yes, thanks for catching that! I'll fix it. -Frank
Re: [PATCH] f2fs: fix heap mode to reset it back
Hi Yunlong,
On 2018/1/29 11:37, Yunlong Song wrote:
> Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
> and hot data in the beginning of partition") introduces another mount
> option, heap, to reset it back. But it does not do anything for heap
> mode, so fix it.
I think Jaegeuk did three things in that patch:
a) add missing heap mount option handling in ->show_options.
b) set noheap by default.
c) change allocation policy to the one that allocate hotdata & nodes in the
front of main are intensively.
They could be separated, independent, and I don't see such intention that
we can only use c) the new introduced allocation policy in noheap mode.
Anyway, I think Jaegeuk can help to double check that.
Thanks,
>
> Signed-off-by: Yunlong Song
> ---
> fs/f2fs/gc.c | 5 +++--
> fs/f2fs/segment.c | 3 ++-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index aa720cc..b9d93fd 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -191,8 +191,9 @@ static void select_policy(struct f2fs_sb_info *sbi, int
> gc_type,
> if (gc_type != FG_GC && p->max_search > sbi->max_victim_search)
> p->max_search = sbi->max_victim_search;
>
> - /* let's select beginning hot/small space first */
> - if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
> + /* let's select beginning hot/small space first in no_heap mode*/
> + if (test_opt(sbi, NOHEAP) &&
> + (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
> p->offset = 0;
> else
> p->offset = SIT_I(sbi)->last_victim[p->gc_mode];
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index e5739ce..77a48c4 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -2167,7 +2167,8 @@ static unsigned int __get_next_segno(struct
> f2fs_sb_info *sbi, int type)
> if (sbi->segs_per_sec != 1)
> return CURSEG_I(sbi, type)->segno;
>
> - if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
> + if (test_opt(sbi, NOHEAP) &&
> + (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
> return 0;
>
> if (SIT_I(sbi)->last_victim[ALLOC_NEXT])
>
Re: [PATCH 1/2] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP
On 01/27/2018 03:45 AM, Stephen Boyd wrote:
> On 01/25, Rajendra Nayak wrote:
>> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-mtp.dtsi
>
> Do we really need two files? Maybe collapse the two?
will do. Not sure why, but this is how all other qualcomm
boards are structured with an almost empty .dts file.
>
>> create mode 100644 arch/arm64/boot/dts/qcom/sdm845.dtsi
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> new file mode 100644
>> index ..a21f4912b3e2
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -0,0 +1,308 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +#include
>> +
>> +/ {
>> +model = "Qualcomm Technologies, Inc. SDM845";
>> +
>> +interrupt-parent = <&intc>;
>> +
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +
>> +chosen { };
>> +
>> +memory {
>> +device_type = "memory";
>> +/* We expect the bootloader to fill in the reg */
>> +reg = <0 0 0 0>;
>> +};
>> +
>> +cpus {
>> +#address-cells = <2>;
>> +#size-cells = <0>;
>> +
>> +CPU0: cpu@0 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x0>;
>> +enable-method = "psci";
>> +next-level-cache = <&L2_0>;
>> +L2_0: l2-cache {
>> +compatible = "cache";
>> +next-level-cache = <&L3_0>;
>> +L3_0: l3-cache {
>> + compatible = "cache";
>> +};
>> +};
>> +};
>> +
>> +CPU1: cpu@100 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x100>;
>> +enable-method = "psci";
>> +next-level-cache = <&L2_100>;
>> +L2_100: l2-cache {
>> +compatible = "cache";
>> +next-level-cache = <&L3_0>;
>> +};
>> +};
>> +
>> +CPU2: cpu@200 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x200>;
>> +enable-method = "psci";
>> +next-level-cache = <&L2_200>;
>> +L2_200: l2-cache {
>> +compatible = "cache";
>> +next-level-cache = <&L3_0>;
>> +};
>> +};
>> +
>> +CPU3: cpu@300 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x300>;
>> +enable-method = "psci";
>> +next-level-cache = <&L2_300>;
>> +L2_300: l2-cache {
>> +compatible = "cache";
>> +next-level-cache = <&L3_0>;
>> +};
>> +};
>> +
>> +CPU4: cpu@400 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x400>;
>> +enable-method = "psci";
>> +next-level-cache = <&L2_400>;
>> +L2_400: l2-cache {
>> +compatible = "cache";
>> +next-level-cache = <&L3_0>;
>> +};
>> +};
>> +
>> +CPU5: cpu@500 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x500>;
>> +enable-method = "psci";
>> +next-level-cache = <&L2_500>;
>> +L2_500: l2-cache {
>> +compatible = "cache";
>> +next-level-cache = <&L3_0>;
>> +};
>> +};
>> +
>> +CPU6: cpu@600 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x600>;
>> +enable-method = "psci";
>> +next-level-cache = <&L2_600>;
>> +L2_600: l2-cache {
>> +compatible = "cache";
>> +next-level-cache = <&L3_0>;
>> +};
>> +};
>> +
>> +CPU7: cpu@700 {
>> +device_type = "cpu";
>> +compatible = "qcom,kryo";
>> +reg = <0x0 0x700>;
>> +enable-method = "p
Re: [PATCH] nvme-pci: use NOWAIT flag for nvme_set_host_mem
On 01/29/2018 11:07 AM, Jianchao Wang wrote: > nvme_set_host_mem will invoke nvme_alloc_request without NOWAIT > flag, it is unsafe for nvme_dev_disable. The adminq driver tags > may have been used up when the previous outstanding adminq requests > cannot be completed due to some hardware error. We have to depend > on the timeout path to complete the previous outstanding adminq > requests and free the tags. > However, nvme_timeout will invoke nvme_dev_disable and try to > get the shutdown_lock which is held by another context who is > sleeping to wait for the tags to be freed by timeout path. A > deadlock comes up. > > To fix it, let nvme_set_host_mem use NOWAIT flag. In fact, this is the only case about nvme_set_host_mem in nvme_dev_disable. Consider the following case: A adminq request expired. timeout_work context nvme_timeout -> nvme_dev_disable -> nvme_set_host_mem if this adminq request expires again, the timeout_work cannot handle this case, because it is waiting for the result of nvme_set_host_mem. Thanks Jianchao
Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.
Hi, On Sun, Jan 28, 2018 at 10:19:03AM +0800, Yong wrote: > Hi Maxime, > > On Fri, 26 Jan 2018 09:10:00 +0100 > Maxime Ripard wrote: > > > On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote: > > > Hi Maxime, > > > > > > On Fri, 26 Jan 2018 09:46:58 +0800 > > > Yong wrote: > > > > > > > Hi Maxime, > > > > > > > > Do you have any experience in solving this problem? > > > > It seems the PHYS_OFFSET maybe undeclared when the ARCH is not arm. > > > > > > Got it. > > > Should I add 'depends on ARM' in Kconfig? > > > > Yes, or even better a depends on MACH_SUNXI :) > > Do you mean ARCH_SUNXI? Yeah, sorry :) > ARCH_SUNXI is alreay there. In the early version, my Kconfig is like this: > > depends on ARCH_SUNXI > > But Hans suggest me to change this to: > > depends on ARCH_SUNXI || COMPILE_TEST > > to allow this driver to be compiled on e.g. Intel for compile testing. > > Should we get rid of COMPILE_TEST? Yes, it cannot be compiled as is on anything but ARM and a few architectures. Or maybe something like || (COMPILE_TEST && ARM) if that makes sense? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v2 2/4] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL
On Mon, 2018-01-29 at 01:58 +0100, KarimAllah Ahmed wrote:
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
> guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
> be using a retpoline+IBPB based approach.
>
> To avoid the overhead of atomically saving and restoring the
> MSR_IA32_SPEC_CTRL for guests that do not actually use the MSR, only
> add_atomic_switch_msr when a non-zero is written to it.
>
> Cc: Asit Mallick
> Cc: Arjan Van De Ven
> Cc: Dave Hansen
> Cc: Andi Kleen
> Cc: Andrea Arcangeli
> Cc: Linus Torvalds
> Cc: Tim Chen
> Cc: Thomas Gleixner
> Cc: Dan Williams
> Cc: Jun Nakajima
> Cc: Paolo Bonzini
> Cc: David Woodhouse
> Cc: Greg KH
> Cc: Andy Lutomirski
> Cc: Ashok Raj
> Signed-off-by: KarimAllah Ahmed
>
> ---
> v2:
> - remove 'host_spec_ctrl' in favor of only a comment (dwmw@).
> - special case writing '0' in SPEC_CTRL to avoid confusing live-migration
> when the instance never used the MSR (dwmw@).
Possibly wants a comment in the code explaining this in slightly more
detail. The point being that if we migrate a guest which has never used
the MSR, we don't want the act of setting it to zero on resume to flip
it into the auto-saved mode.
> - depend on X86_FEATURE_IBRS instead of X86_FEATURE_SPEC_CTRL (dwmw@).
> - add MSR_IA32_SPEC_CTRL to the list of MSRs to save (dropped it by accident).
> ---
> arch/x86/kvm/cpuid.c | 4 +++-
> arch/x86/kvm/vmx.c | 65
>
> arch/x86/kvm/x86.c | 1 +
> 3 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 0099e10..32c0c14 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -70,6 +70,7 @@ u64 kvm_supported_xcr0(void)
> /* These are scattered features in cpufeatures.h. */
> #define KVM_CPUID_BIT_AVX512_4VNNIW 2
> #define KVM_CPUID_BIT_AVX512_4FMAPS 3
> +#define KVM_CPUID_BIT_IBRS 26
> #define KF(x) bit(KVM_CPUID_BIT_##x)
>
> int kvm_update_cpuid(struct kvm_vcpu *vcpu)
> @@ -392,7 +393,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
> *entry, u32 function,
>
> /* cpuid 7.0.edx*/
> const u32 kvm_cpuid_7_0_edx_x86_features =
> - KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS);
> + KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS) | \
> + (boot_cpu_has(X86_FEATURE_IBRS) ? KF(IBRS) : 0);
> /* all calls to cpuid_count() should be made on the same cpu */
> get_cpu();
I think we need to expose more feature bits than that. See
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/pti&id=2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2
There are three AMD bits for IBRS, IBPB & STIBP which are the user-
visible ones in /proc/cpuinfo, and the ones we use within the kernel to
indicate the hardware availability (there are separate feature bits for
when we're *using* IBPB etc., but that's only because feature bits are
the only thing that ALTERNATIVEs can work from).
In addition to those bits, Intel has its own. The Intel SPEC_CTRL CPUID
bit (which you're setting above) indicates *both* IBRS and IBPB
capability. The kernel sets the corresponding AMD bits when it sees
SPEC_CTRL. Likewise Intel has a different bit for STIBP.
You could construct a set of CPUID bits for the guest based on what the
host has. So all three of the AMD IBRS/IBPB/STIBP bits in 8008/EBX
should just be passed through, and you could set the Intel SPEC_CTRL
bit (7/EDX bit 26 that you're looking at above) only when you have
X86_FEATURE_IBPB && X86_FEATURE_IBRS. And the Intel STIBP when you have
X86_FEATURE_STIBP.
The Intel ARCH_CAPABILITIES CPUID bit is separate. Pass that through if
you have it, and expose the corresponding MSR read-only.
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index aa8638a..dac564d 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -920,6 +920,8 @@ static void vmx_set_nmi_mask(struct kvm_vcpu *vcpu, bool
> masked);
> static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
> u16 error_code);
> static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
> +static void __always_inline vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> + u32 msr, int type);
>
> static DEFINE_PER_CPU(struct vmcs *, vmxarea);
> static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
Perhaps move that whole function further up?
> static bool update_transition_efer(struct vcpu_vmx *vmx, int efer_offset)
> {
> u64 guest_efer = vmx->vcpu.arch.efer;
> @@ -3203,7 +3227,9 @@ static inline bool vmx_feature_control_msr_valid(struct
> kvm_vcpu *vcpu,
> */
> static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> {
> + u64 spec_ctrl = 0;
Could you ditch this additional variable and...
> struct shared_msr_entry *msr;
Re: [PATCH 2/2] arm64: dts: sdm845: Add serial console support
On 01/27/2018 03:48 AM, Stephen Boyd wrote:
> On 01/25, Rajendra Nayak wrote:
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-pins.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845-pins.dtsi
>> new file mode 100644
>> index ..b97f99e6f4b4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-pins.dtsi
>> @@ -0,0 +1,32 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +&tlmm {
>
> I'm not the maintainer, but I find this approach to the pins
> really annoying. I have to flip to another file to figure out how
> a board has configured the pins. And we may bring in a bunch of
> settings that we don't ever use on some board too. Why can't we
> put the settings in the board file directly?
I was just keeping it consistent with how things are for other
qualcomm platforms. I can move this to the board dts if no one else
sees any issues.
>
>> +qup_uart2_default: qup_uart2_default {
>> +pinmux {
>> +function = "qup9";
>> +pins = "gpio4", "gpio5";
>> +};
>> +
>> +pinconf {
>> +pins = "gpio4", "gpio5";
>> +drive-strength = <2>;
>> +bias-disable;
>> +};
>> +};
>> +
>> +qup_uart2_sleep: qup_uart2_sleep {
>> +pinmux {
>> +function = "gpio";
>> +pins = "gpio4", "gpio5";
>> +};
>> +
>> +pinconf {
>> +pins = "gpio4", "gpio5";
>> +drive-strength = <2>;
>> +bias-disable;
>> +};
>> +};
>> +};
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index a21f4912b3e2..529f4ba3a1db 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -4,6 +4,7 @@
>> */
>>
>> #include
>> +#include
>>
>> / {
>> model = "Qualcomm Technologies, Inc. SDM845";
>
> I'd expect some sort of serial alias node stuff here too.
yes, will add.
>
>> @@ -304,5 +305,26 @@
>> cell-index = <0>;
>> };
>>
>> +qup_1: qcom,geni_se@ac {
>> +compatible = "qcom,geni-se-qup";
>> +reg = <0xac 0x6000>;
>> +};
>> +
>> +qup_uart2: serial@a84000 {
>> +compatible = "qcom,geni-console", "qcom,geni-uart";
>> +reg = <0xa84000 0x4000>;
>> +reg-names = "se_phys";
>> +clock-names = "se-clk", "m-ahb", "s-ahb";
>> +clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>,
>> + <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
>> + <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
>> +pinctrl-names = "default", "sleep";
>> +pinctrl-0 = <&qup_uart2_default>;
>> +pinctrl-1 = <&qup_uart2_sleep>;
>> +interrupts = ;
>> +qcom,wrapper-core = <&qup_1>;
>
> Is this binding still being reviewed? Ugly.
yes, its still being reviewed
>
>> +status = "disabled";
>> +};
>> };
>> };
>> +#include "sdm845-pins.dtsi"
>
> Why at the bottom?
Again keeping it consistent with how things are in msm8916/msm8992/msm8996 dtsi
files.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
Re: [PATCH] hrtimer: Reset hrtimer cpu base proper on CPU hotplug
On 2018-01-26 14:09:17 [-0800], Paul E. McKenney wrote: > find this one. ;-) But it did pass rcutorture testing for a great many > years, didn't it? :-/ It started to trigger better (or at all) on our test box with modprobe kvm_intel preemption_timer=n on the host kernel so maybe a completely unrelated change helped to trigger this. Sebastian
Re: [PATCH] ARM: dts: imx6ul: remove unnecessary clocks for cpu-freq
On Wed, Jan 03, 2018 at 07:22:14PM +0800, Anson Huang wrote: > Remove unnecessary clocks for cpu-freq driver to > avoid confusion. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH 2/2] usb: chipidea: imx: Fix ULPI on imx53
On Wed, Jan 24, 2018 at 06:14:39PM +0100, Sebastian Reichel wrote:
> Traditionally, PORTSC should be set before initializing ULPI phys. But
> setting PORTSC before powering on the phy results in a kernel freeze
> on imx53 based GE PPD. As a workaround this initializes the phy early
> in the imx platform code and disables phy power management from the
> core.
>
> Signed-off-by: Fabien Lahoudere
> Signed-off-by: Sebastian Reichel
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index de155c80eb70..e431c5aafe35 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
> struct clk *clk;
> struct imx_usbmisc_data *usbmisc_data;
> bool supports_runtime_pm;
> + bool override_phy_control;
> bool in_lpm;
> /* SoC before i.mx6 (except imx23/imx28) needs three clks */
> bool need_three_clks;
> @@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> int ret;
> const struct of_device_id *of_id;
> const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
> + struct device_node *np = pdev->dev.of_node;
>
> of_id = of_match_device(ci_hdrc_imx_dt_ids, &pdev->dev);
> if (!of_id)
> @@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device
> *pdev)
> }
>
> pdata.usb_phy = data->phy;
> +
> + if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
> + of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
> + pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
> + data->override_phy_control = true;
> + usb_phy_init(pdata.usb_phy);
> + }
> +
> pdata.flags |= imx_platform_flag->flags;
> if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
> data->supports_runtime_pm = true;
> @@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device
> *pdev)
> pm_runtime_put_noidle(&pdev->dev);
> }
> ci_hdrc_remove_device(data->ci_pdev);
> + if (data->override_phy_control)
> + usb_phy_shutdown(data->phy);
> imx_disable_unprepare_clks(&pdev->dev);
>
Sebastian, I have a question, do you have any USB or generic PHY drivers
for ULPI bus, any power controls are needed for your ULPI peripheral?
--
Best Regards,
Peter Chen
Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.
Hi Linus,
On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote:
> > +void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
> > +{
> > + struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
> > + /* transform physical address to bus address */
> > + dma_addr_t bus_addr = addr - PHYS_OFFSET;
>
> I am sorry if this is an unjustified drive-by comment. Maybe you
> have already investigate other ways to do this.
It's definitely not unjustified :)
> Accessing PHYS_OFFSET directly seems unintuitive and not good
> practice.
>
> But normally an dma_addr_t only comes from some function inside
> such as: dma_alloc_coherent() for a contigous
> buffer which is coherent in physical memory, or from some buffer <=
> 64KB that is switching ownership between device and CPU explicitly
> with dma_map* or so. Did you check with Documentation/DMA-API.txt?
So, I've discussed this with Arnd a month ago or so, because I'm not
really fond of the current approach but we haven't found better way to
do it yet.
The issue is that all the DMA accesses are done not through the main
AXI bus, but through a separate bus dedicated for memory accesses,
where the RAM is mapped at the address 0. So the CPU and DMA devices
have a different mapping for the RAM.
I guess we could address this by using the field dma_pfn_offset that
seems to be used in similar situations. However, in DT systems, that
field is filled only with the parent's node dma-ranges property. In
our case, and since the DT parenthood is based on the "control" bus,
and not the "data" bus, our parent node would be the AXI bus, and not
the memory bus that enforce those constraints.
And other devices doing DMA through regular DMA accesses won't have
that mapping, so we definitely shouldn't enforce it for all the
devices there, but only the one connected to the separate memory bus.
tl; dr: the DT is not really an option to store that info.
I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too
fond of that approach either at the time.
So, well, I guess we could do better. We just have no idea how :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v3] ARM: dts: imx6: RDU2: disable internal watchdog
On Wed, Jan 03, 2018 at 11:32:37AM -0800, Andrey Smirnov wrote: > From: Lucas Stach > > The system has an external watchdog in the environment processor > so the internal watchdog is of no use. > > Cc: Sascha Hauer > Cc: Fabio Estevam > Cc: Rob Herring > Cc: Mark Rutland > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: cphe...@gmail.com > Reviewed-by: Fabio Estevam > Signed-off-by: Lucas Stach > Signed-off-by: Andrey Smirnov Applied, thanks.
Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)
On Mon, Jan 29, 2018 at 08:23:57AM +0100, Florian Westphal wrote:
> > vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: back
> > off when the current task is killed") but then became unkillable by commit
> > b8c8a338f75e052d ("Revert "vmalloc: back off when the current task is
> > killed""). Therefore, we can't handle this problem from MM side.
> > Please consider adding some limit from networking side.
>
> I don't know what "some limit" would be. I would prefer if there was
> a way to supress OOM Killer in first place so we can just -ENOMEM user.
Just supressing OOM kill is a bad idea. We still leave a way to allocate
arbitrary large buffer in kernel.
--
Kirill A. Shutemov
[PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages
ttm module needs it to determine its internal parameter setting.
Signed-off-by: Roger He
---
include/linux/swap.h | 6 ++
mm/swapfile.c| 15 +++
2 files changed, 21 insertions(+)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index c2b8128..708d66f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);
struct backing_dev_info;
extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
extern void exit_swap_address_space(unsigned int type);
+extern long get_total_swap_pages(void);
#else /* CONFIG_SWAP */
@@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)
{
}
+long get_total_swap_pages(void)
+{
+ return 0;
+}
+
#define free_swap_and_cache(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
#define swapcache_prepare(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 3074b02..a0062eb 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
atomic_t nr_rotate_swap = ATOMIC_INIT(0);
+/*
+ * expose this value for others use
+ */
+long get_total_swap_pages(void)
+{
+ long ret;
+
+ spin_lock(&swap_lock);
+ ret = total_swap_pages;
+ spin_unlock(&swap_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(get_total_swap_pages);
+
static inline unsigned char swap_count(unsigned char ent)
{
return ent & ~SWAP_HAS_CACHE; /* may include SWAP_HAS_CONT flag */
--
2.7.4
Re: [ANNOUNCE] v4.14.15-rt12
On 2018-01-28 16:10:51 [+0100], Salvatore Bonaccorso wrote: > Hi Hi, > Just a small heads-up: Whilst ping-sysrq.patch was dropped the > included series file still contains: > > # NETWORK DEBUGGING AID > ping-sysrq.patch so 'quilt push -a' aborts once it gets to it while 'git quiltimport' continues: | net-Have-__napi_schedule_irqoff-disable-interrupts-o.patch | ping-sysrq.patch doesn't exist. Skipping. | irqwork-push_most_work_into_softirq_context.patch not sure if this is a bug or not. Thanks for the report, will try to fix this soon. > Regards, > Salvatore Sebastian
[PATCH] f2fs: add sanity check for quota sysfile ino
Add missing sanity check for quota sysfile ino.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 368f63d7bad2..6011071688ca 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -2116,6 +2116,25 @@ static int sanity_check_raw_super(struct f2fs_sb_info
*sbi,
return 1;
}
+ /* check quota sysfile ino info */
+ if (raw_super->feature & cpu_to_le32(F2FS_FEATURE_QUOTA_INO)) {
+ if (le32_to_cpu(raw_super->qf_ino[0]) != 4 ||
+ le32_to_cpu(raw_super->qf_ino[1]) != 5) {
+ f2fs_msg(sb, KERN_INFO,
+ "Invalid Quota Ino: user_ino(%u), grp_ino(%u)",
+ le32_to_cpu(raw_super->qf_ino[0]),
+ le32_to_cpu(raw_super->qf_ino[1]));
+ return 1;
+ }
+ if (raw_super->feature & cpu_to_le32(F2FS_FEATURE_PRJQUOTA) &&
+ le32_to_cpu(raw_super->qf_ino[2]) != 6) {
+ f2fs_msg(sb, KERN_INFO,
+ "Invalid Quota Ino: prj_ino(%u)",
+ le32_to_cpu(raw_super->qf_ino[2]));
+ return 1;
+ }
+ }
+
if (le32_to_cpu(raw_super->segment_count) > F2FS_MAX_SEGMENT) {
f2fs_msg(sb, KERN_INFO,
"Invalid segment count (%u)",
--
2.15.0.55.gc2ece9dc4de6
[PATCH 0/3] perf trace powerpc: Remove libaudit dependency for syscalls
This is almost identical set of patches recently done for s390. With this, user can run perf trace without libaudit on powerpc as well. Ex, $ make ... libaudit: [ OFF ] $ ./perf trace ls 0.221 ( 0.005 ms): ls/43330 open(filename: 0xac1e2778, flags: CLOEXEC ) = 3 0.227 ( 0.003 ms): ls/43330 read(fd: 3, buf: 0x39c4d678, count: 832 ) = 832 0.233 ( 0.002 ms): ls/43330 fstat(fd: 3, statbuf: 0x39c4d4b0) = 0 ... $ ./perf trace -e "open*" ls 0.000 ( 0.014 ms): ls/43342 open(filename: 0x793d8978, flags: CLOEXEC ) = 3 0.038 ( 0.006 ms): ls/43342 open(filename: 0x793f2778, flags: CLOEXEC ) = 3 ... Ravi Bangoria (3): tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h perf powerpc: Generate system call table from asm/unistd.h perf trace powerpc: Use generated syscall table tools/arch/powerpc/include/uapi/asm/unistd.h | 399 + tools/perf/Makefile.config | 2 + tools/perf/arch/powerpc/Makefile | 21 ++ .../perf/arch/powerpc/entry/syscalls/mksyscalltbl | 35 ++ tools/perf/check-headers.sh| 1 + tools/perf/util/syscalltbl.c | 4 + 6 files changed, 462 insertions(+) create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h create mode 100755 tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl -- 1.8.3.1
[PATCH 2/3] perf powerpc: Generate system call table from asm/unistd.h
This should speed up accessing new system calls introduced with
the kernel rather than waiting for libaudit updates to include
them.
Signed-off-by: Ravi Bangoria
---
tools/perf/arch/powerpc/Makefile | 21 +
.../perf/arch/powerpc/entry/syscalls/mksyscalltbl | 35 ++
2 files changed, 56 insertions(+)
create mode 100755 tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 42dab7c..c93e8f4 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -6,3 +6,24 @@ endif
HAVE_KVM_STAT_SUPPORT := 1
PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
PERF_HAVE_JITDUMP := 1
+
+#
+# Syscall table generation for perf
+#
+
+out:= $(OUTPUT)arch/powerpc/include/generated/asm
+header := $(out)/syscalls_64.c
+sysdef := $(srctree)/tools/arch/powerpc/include/uapi/asm/unistd.h
+sysprf := $(srctree)/tools/perf/arch/powerpc/entry/syscalls/
+systbl := $(sysprf)/mksyscalltbl
+
+# Create output directory if not already present
+_dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)')
+
+$(header): $(sysdef) $(systbl)
+ $(Q)$(SHELL) '$(systbl)' '$(CC)' $(sysdef) > $@
+
+clean::
+ $(call QUIET_CLEAN, powerpc) $(RM) $(header)
+
+archheaders: $(header)
diff --git a/tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl
b/tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl
new file mode 100755
index 000..975947c
--- /dev/null
+++ b/tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl
@@ -0,0 +1,35 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Generate system call table for perf. Derived from
+# s390 script.
+#
+# Copyright IBM Corp. 2017
+# Author(s): Hendrik Brueckner
+# Changed by: Ravi Bangoria
+
+gcc=$1
+input=$2
+
+if ! test -r $input; then
+ echo "Could not read input file" >&2
+ exit 1
+fi
+
+create_table()
+{
+ local max_nr
+
+ echo 'static const char *syscalltbl_powerpc_64[] = {'
+ while read sc nr; do
+ printf '\t[%d] = "%s",\n' $nr $sc
+ max_nr=$nr
+ done
+ echo '};'
+ echo "#define SYSCALLTBL_POWERPC_64_MAX_ID $max_nr"
+}
+
+$gcc -m64 -E -dM -x c $input \
+ |sed -ne 's/^#define __NR_//p' \
+ |sort -t' ' -k2 -nu\
+ |create_table
--
1.8.3.1
[PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h
Will be used for generating the syscall id/string translation table. Signed-off-by: Ravi Bangoria --- tools/arch/powerpc/include/uapi/asm/unistd.h | 399 +++ tools/perf/check-headers.sh | 1 + 2 files changed, 400 insertions(+) create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h diff --git a/tools/arch/powerpc/include/uapi/asm/unistd.h b/tools/arch/powerpc/include/uapi/asm/unistd.h new file mode 100644 index 000..df8684f3 --- /dev/null +++ b/tools/arch/powerpc/include/uapi/asm/unistd.h @@ -0,0 +1,399 @@ +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ +/* + * This file contains the system call numbers. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ +#ifndef _UAPI_ASM_POWERPC_UNISTD_H_ +#define _UAPI_ASM_POWERPC_UNISTD_H_ + + +#define __NR_restart_syscall 0 +#define __NR_exit1 +#define __NR_fork2 +#define __NR_read3 +#define __NR_write 4 +#define __NR_open5 +#define __NR_close 6 +#define __NR_waitpid 7 +#define __NR_creat 8 +#define __NR_link9 +#define __NR_unlink 10 +#define __NR_execve 11 +#define __NR_chdir 12 +#define __NR_time 13 +#define __NR_mknod 14 +#define __NR_chmod 15 +#define __NR_lchown 16 +#define __NR_break 17 +#define __NR_oldstat18 +#define __NR_lseek 19 +#define __NR_getpid 20 +#define __NR_mount 21 +#define __NR_umount 22 +#define __NR_setuid 23 +#define __NR_getuid 24 +#define __NR_stime 25 +#define __NR_ptrace 26 +#define __NR_alarm 27 +#define __NR_oldfstat 28 +#define __NR_pause 29 +#define __NR_utime 30 +#define __NR_stty 31 +#define __NR_gtty 32 +#define __NR_access 33 +#define __NR_nice 34 +#define __NR_ftime 35 +#define __NR_sync 36 +#define __NR_kill 37 +#define __NR_rename 38 +#define __NR_mkdir 39 +#define __NR_rmdir 40 +#define __NR_dup41 +#define __NR_pipe 42 +#define __NR_times 43 +#define __NR_prof 44 +#define __NR_brk45 +#define __NR_setgid 46 +#define __NR_getgid 47 +#define __NR_signal 48 +#define __NR_geteuid49 +#define __NR_getegid50 +#define __NR_acct 51 +#define __NR_umount252 +#define __NR_lock 53 +#define __NR_ioctl 54 +#define __NR_fcntl 55 +#define __NR_mpx56 +#define __NR_setpgid57 +#define __NR_ulimit 58 +#define __NR_oldolduname59 +#define __NR_umask 60 +#define __NR_chroot 61 +#define __NR_ustat 62 +#define __NR_dup2 63 +#define __NR_getppid64 +#define __NR_getpgrp65 +#define __NR_setsid 66 +#define __NR_sigaction 67 +#define __NR_sgetmask 68 +#define __NR_ssetmask 69 +#define __NR_setreuid 70 +#define __NR_setregid 71 +#define __NR_sigsuspend 72 +#define __NR_sigpending 73 +#define __NR_sethostname74 +#define __NR_setrlimit 75 +#define __NR_getrlimit 76 +#define __NR_getrusage 77 +#define __NR_gettimeofday 78 +#define __NR_settimeofday 79 +#define __NR_getgroups 80 +#define __NR_setgroups 81 +#define __NR_select 82 +#define __NR_symlink83 +#define __NR_oldlstat 84 +#define __NR_readlink 85 +#define __NR_uselib 86 +#define __NR_swapon 87 +#define __NR_reboot 88 +#define __NR_readdir89 +#define __NR_mmap 90 +#define __NR_munmap 91 +#define __NR_truncate 92 +#define __NR_ftruncate 93 +#define __NR_fchmod 94 +#define __NR_fchown 95 +#define __NR_getpriority96 +#define __NR_setpriority97 +#define __NR_profil 98 +#define __NR_statfs 99 +#define __NR_fstatfs 100 +#define __NR_ioperm101 +#define __NR_socketcall102 +#define __NR_syslog103 +#define __NR_setitimer 104 +#define __NR_getitimer 105 +#define __NR_stat 106 +#define __NR_lstat 107 +#define __NR_fstat 108 +#define __NR_old
[PATCH 3/3] perf trace powerpc: Use generated syscall table
This should speed up accessing new system calls introduced with the
kernel rather than waiting for libaudit updates to include them.
It also enables users to specify wildcards, for example, perf trace -e
'open*', just like was already possible on x86 and s390.
Signed-off-by: Ravi Bangoria
---
tools/perf/Makefile.config | 2 ++
tools/perf/util/syscalltbl.c | 4
2 files changed, 6 insertions(+)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 0dfdaa9..577a5d2 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -27,6 +27,8 @@ NO_SYSCALL_TABLE := 1
# Additional ARCH settings for ppc
ifeq ($(SRCARCH),powerpc)
NO_PERF_REGS := 0
+ NO_SYSCALL_TABLE := 0
+ CFLAGS += -I$(OUTPUT)arch/powerpc/include/generated
LIBUNWIND_LIBS := -lunwind -lunwind-ppc64
endif
diff --git a/tools/perf/util/syscalltbl.c b/tools/perf/util/syscalltbl.c
index 303bdb8..b12c5f5 100644
--- a/tools/perf/util/syscalltbl.c
+++ b/tools/perf/util/syscalltbl.c
@@ -30,6 +30,10 @@
#include
const int syscalltbl_native_max_id = SYSCALLTBL_S390_64_MAX_ID;
static const char **syscalltbl_native = syscalltbl_s390_64;
+#elif defined(__powerpc64__)
+#include
+const int syscalltbl_native_max_id = SYSCALLTBL_POWERPC_64_MAX_ID;
+static const char **syscalltbl_native = syscalltbl_powerpc_64;
#endif
struct syscall {
--
1.8.3.1
[GIT pull] Generic interrupt subsystem updates for 4.16
Linus, please pull the latest irq-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus A rather small set of irq updates this time: - Removal of the old and now obsolete irq domain debugging code - The new Goldfish PIC driver - The usual pile of small fixes and updates Thanks, tglx --> Bartosz Golaszewski (1): irq/work: Improve the flag definitions Marc Zyngier (1): irqdomain: Kill CONFIG_IRQ_DOMAIN_DEBUG Miodrag Dinic (2): dt-bindings/goldfish-pic: Add device tree binding for Goldfish PIC driver irqchip/irq-goldfish-pic: Add Goldfish PIC driver Shanker Donthineni (1): irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry Stefan Wahren (3): dt-bindings/bcm2836-l1-intc: Add interrupt polarity support irqchip/irq-bcm2836: Add support for DT interrupt polarity dt-bindings/bcm283x: Define polarity of per-cpu interrupts Wei Yongjun (1): irqchip/ompic: fix return value check in ompic_of_init() Documentation/IRQ-domain.txt | 36 +- .../interrupt-controller/brcm,bcm2836-l1-intc.txt | 4 +- .../interrupt-controller/google,goldfish-pic.txt | 30 + MAINTAINERS| 6 + arch/arm/boot/dts/bcm2836.dtsi | 14 +-- arch/arm/boot/dts/bcm2837.dtsi | 12 +- arch/arm/boot/dts/bcm283x.dtsi | 1 + arch/arm/configs/aspeed_g4_defconfig | 1 - arch/arm/configs/aspeed_g5_defconfig | 1 - arch/arm/configs/hisi_defconfig| 1 - arch/arm/configs/multi_v7_defconfig| 1 - arch/arm/configs/mvebu_v7_defconfig| 1 - arch/arm/configs/pxa_defconfig | 1 - arch/arm/configs/sama5_defconfig | 1 - arch/arm/configs/tegra_defconfig | 1 - arch/arm/configs/vt8500_v6_v7_defconfig| 1 - arch/powerpc/configs/fsl-emb-nonhw.config | 1 - arch/powerpc/configs/powernv_defconfig | 1 - arch/powerpc/configs/ppc64_defconfig | 1 - arch/powerpc/configs/pseries_defconfig | 1 - arch/xtensa/configs/audio_kc705_defconfig | 1 - arch/xtensa/configs/cadence_csp_defconfig | 1 - arch/xtensa/configs/generic_kc705_defconfig| 1 - arch/xtensa/configs/nommu_kc705_defconfig | 1 - arch/xtensa/configs/smp_lx200_defconfig| 1 - drivers/irqchip/Kconfig| 8 ++ drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-bcm2836.c | 46 --- drivers/irqchip/irq-gic-v3.c | 11 ++ drivers/irqchip/irq-goldfish-pic.c | 139 + drivers/irqchip/irq-ompic.c| 4 +- include/linux/irq_work.h | 11 +- kernel/irq/Kconfig | 10 -- kernel/irq/irqdomain.c | 118 - kernel/irq_work.c | 2 +- 35 files changed, 251 insertions(+), 220 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt create mode 100644 drivers/irqchip/irq-goldfish-pic.c diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 4a1cd7645d85..507775cce753 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -265,37 +265,5 @@ support other architectures, such as ARM, ARM64 etc. === Debugging === -If you switch on CONFIG_IRQ_DOMAIN_DEBUG (which depends on -CONFIG_IRQ_DOMAIN and CONFIG_DEBUG_FS), you will find a new file in -your debugfs mount point, called irq_domain_mapping. This file -contains a live snapshot of all the IRQ domains in the system: - - name mapped linear-max direct-max devtree-node - pl061 8 8 0 /smb/gpio@e008 - pl061 8 8 0 /smb/gpio@e105 - pMSI 0 0 0 /interrupt-controller@e1101000/v2m@e008 - MSI 37 0 0 /interrupt-controller@e1101000/v2m@e008 - GICv2m37 0 0 /interrupt-controller@e1101000/v2m@e008 - GICv2448 448 0 /interrupt-controller@e1101000 - -it also iterates over the interrupts to display their mapping in the -domains, and makes the domain stacking visible: - - -irqhwirqchip namechip data active type domain -1 0x00019 GICv20x0916bfd8 *LINEAR GICv2 -2 0x0001d GICv20x0916bfd8 LINEAR GICv2 -3 0x0001e GICv20x0916bf
Re: [PATCH] f2fs: fix heap mode to reset it back
The old commit allocates hot data & nodes in the beginning of partition
both for heap and
noheap mode. But from the commit message, the heap mode should be like
before, i.e.,
allocate hot data & nodes from curseg to left.
On 2018/1/29 16:12, Chao Yu wrote:
Hi Yunlong,
On 2018/1/29 11:37, Yunlong Song wrote:
Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
and hot data in the beginning of partition") introduces another mount
option, heap, to reset it back. But it does not do anything for heap
mode, so fix it.
I think Jaegeuk did three things in that patch:
a) add missing heap mount option handling in ->show_options.
b) set noheap by default.
c) change allocation policy to the one that allocate hotdata & nodes in the
front of main are intensively.
They could be separated, independent, and I don't see such intention that
we can only use c) the new introduced allocation policy in noheap mode.
Anyway, I think Jaegeuk can help to double check that.
Thanks,
Signed-off-by: Yunlong Song
---
fs/f2fs/gc.c | 5 +++--
fs/f2fs/segment.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index aa720cc..b9d93fd 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -191,8 +191,9 @@ static void select_policy(struct f2fs_sb_info *sbi, int
gc_type,
if (gc_type != FG_GC && p->max_search > sbi->max_victim_search)
p->max_search = sbi->max_victim_search;
- /* let's select beginning hot/small space first */
- if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
+ /* let's select beginning hot/small space first in no_heap mode*/
+ if (test_opt(sbi, NOHEAP) &&
+ (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
p->offset = 0;
else
p->offset = SIT_I(sbi)->last_victim[p->gc_mode];
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index e5739ce..77a48c4 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2167,7 +2167,8 @@ static unsigned int __get_next_segno(struct f2fs_sb_info
*sbi, int type)
if (sbi->segs_per_sec != 1)
return CURSEG_I(sbi, type)->segno;
- if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
+ if (test_opt(sbi, NOHEAP) &&
+ (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
return 0;
if (SIT_I(sbi)->last_victim[ALLOC_NEXT])
.
--
Thanks,
Yunlong Song
Re: [PATCH] power: reset: Add Spreadtrum SC27xx PMIC power off support
Hi Sebastian,
On 15 January 2018 at 15:58, Baolin Wang wrote:
> On Spreadtrum platform, we need power off system through external SC27xx
> series PMICs including the SC2720, SC2721, SC2723, SC2730 and SC2731 chips.
> Thus this patch adds SC27xx series PMICs power-off support.
>
> Signed-off-by: Baolin Wang
Do you have any comments for this patch? Thanks.
> ---
> drivers/power/reset/Kconfig |9 +
> drivers/power/reset/Makefile |1 +
> drivers/power/reset/sc27xx-poweroff.c | 65
> +
> 3 files changed, 75 insertions(+)
> create mode 100644 drivers/power/reset/sc27xx-poweroff.c
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index ca0de1a..611ae56 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -227,5 +227,14 @@ config SYSCON_REBOOT_MODE
> register, then the bootloader can read it to take different
> action according to the mode.
>
> +config POWER_RESET_SC27XX
> + tristate "Spreadtrum SC27xx PMIC power-off driver"
> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
> + help
> + This driver supports powering off a system through
> + Spreadtrum SC27xx series PMICs. The SC27xx series
> + PMICs includes the SC2720, SC2721, SC2723, SC2730
> + and SC2731 chips.
> +
> endif
>
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index aeb65ed..225d645 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -27,3 +27,4 @@ obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
> obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
> obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
> obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
> +obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
> diff --git a/drivers/power/reset/sc27xx-poweroff.c
> b/drivers/power/reset/sc27xx-poweroff.c
> new file mode 100644
> index 000..8e4b6a0
> --- /dev/null
> +++ b/drivers/power/reset/sc27xx-poweroff.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Spreadtrum Communications Inc.
> + * Copyright (c) 2017 Linaro Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SC27XX_PWR_PD_HW 0xc2c
> +#define SC27XX_PWR_OFF_EN BIT(0)
> +
> +static struct regmap *regmap;
> +
> +/*
> + * On Spreadtrum platform, we need power off system through external SC27xx
> + * series PMICs, and it is one similar SPI bus mapped by regmap to access
> PMIC,
> + * which is not fast io access.
> + *
> + * So before stopping other cores, we need release other cores' resource by
> + * taking cpus down to avoid racing regmap or spi mutex lock when poweroff
> + * system through PMIC.
> + */
> +void sc27xx_poweroff_shutdown(void)
> +{
> + int cpu = smp_processor_id();
> +
> + freeze_secondary_cpus(cpu);
> +}
> +
> +static struct syscore_ops poweroff_syscore_ops = {
> + .shutdown = sc27xx_poweroff_shutdown,
> +};
> +
> +static void sc27xx_poweroff_do_poweroff(void)
> +{
> + regmap_write(regmap, SC27XX_PWR_PD_HW, SC27XX_PWR_OFF_EN);
> +}
> +
> +static int sc27xx_poweroff_probe(struct platform_device *pdev)
> +{
> + regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + if (!regmap)
> + return -ENODEV;
> +
> + pm_power_off = sc27xx_poweroff_do_poweroff;
> + register_syscore_ops(&poweroff_syscore_ops);
> + return 0;
> +}
> +
> +static struct platform_driver sc27xx_poweroff_driver = {
> + .probe = sc27xx_poweroff_probe,
> + .driver = {
> + .name = "sc27xx-poweroff",
> + },
> +};
> +module_platform_driver(sc27xx_poweroff_driver);
> +
> +MODULE_DESCRIPTION("Spreadtrum SC27xx PMIC Poweroff Driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>
--
Baolin.wang
Best Regards
Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality
On Mon, Jan 29, 2018 at 03:38:40PM +0800, Chen-Yu Tsai wrote:
> On Mon, Jan 29, 2018 at 3:34 PM, Code Kipper wrote:
> > On 29 January 2018 at 02:50, Chen-Yu Tsai wrote:
> >> On Wed, Jan 24, 2018 at 10:10 PM, wrote:
> >>> From: Marcus Cooper
> >>>
> >>> Some codecs require a different amount of a bit clocks per frame than
> >>> what is calculated by the sample width. Use the tdm slot bindings to
> >>> provide this mechanism.
> >>>
> >>> Signed-off-by: Marcus Cooper
> >>> ---
> >>> sound/soc/sunxi/sun4i-i2s.c | 23 +--
> >>> 1 file changed, 21 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> >>> index dca1143c1150..d7a9141514cf 100644
> >>> --- a/sound/soc/sunxi/sun4i-i2s.c
> >>> +++ b/sound/soc/sunxi/sun4i-i2s.c
> >>> @@ -96,6 +96,7 @@
> >>> #define SUN8I_I2S_CTRL_BCLK_OUTBIT(18)
> >>> #define SUN8I_I2S_CTRL_LRCK_OUTBIT(17)
> >>>
> >>> +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8)
> >>> #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASKGENMASK(17, 8)
> >>> #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)
> >>>
> >>> @@ -193,6 +194,9 @@ struct sun4i_i2s {
> >>> struct regmap_field *field_rxchansel;
> >>>
> >>> const struct sun4i_i2s_quirks *variant;
> >>> +
> >>> + unsigned inttdm_slots;
> >>> + unsigned intslot_width;
> >>> };
> >>>
> >>> struct sun4i_i2s_clk_div {
> >>> @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai
> >>> *dai,
> >>> if (i2s->variant->has_fmt_set_lrck_period)
> >>> regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
> >>>SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
> >>> - SUN8I_I2S_FMT0_LRCK_PERIOD(32));
> >>> + SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));
> >>>
> >>> return 0;
> >>> }
> >>> @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct
> >>> snd_pcm_substream *substream,
> >>>sr + i2s->variant->fmt_offset);
> >>>
> >>> return sun4i_i2s_set_clk_rate(dai, params_rate(params),
> >>> - params_width(params));
> >>> + i2s->tdm_slots ?
> >>> + i2s->slot_width :
> >>> params_width(params));
> >>> }
> >>>
> >>> static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> >>> @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai
> >>> *dai, int clk_id,
> >>> return 0;
> >>> }
> >>>
> >>> +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
> >>> + unsigned int tx_mask, unsigned int rx_mask,
> >>> + int slots, int width)
> >>> +{
> >>> + struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
> >>> +
> >>> + i2s->tdm_slots = slots;
> >>> +
> >>> + i2s->slot_width = width;
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>
> >> IIRC some of the DAI controllers actually support TDM. Would this
> >> change conflict with that in the future?
> >
> > Hi Wens,
> > I'm not sure..I was looking for a clean example of being able to
> > override the number of bclks in the lrclk width and some other
> > devices(Rpi) were doing it this way. I open to suggestions,
>
> I'm not familiar with the issue either. If Mark doesn't have any
> objections, we could merge it for now, and fix it later if there
> are any complications.
>
> BTW, you didn't provide a device tree example (if any) for how
> to use this.
Could it be that it's just not i2s but some other format?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 2/3] tpm: separate cmd_ready/go_idle from runtime_pm
On Tue, Jan 23, 2018 at 08:33:22AM -0700, Jason Gunthorpe wrote: > On Tue, Jan 23, 2018 at 03:08:41PM +0200, Jarkko Sakkinen wrote: > > On Tue, Jan 23, 2018 at 01:27:30PM +0200, Tomas Winkler wrote: > > > We cannot use go_idle cmd_ready commands via runtime_pm handles > > > as with the introduction of localities this is no longer an optional > > > feature, while runtime pm can be not enabled. > > > Though cmd_ready/go_idle provides power saving feature, it's also part of > > > TPM2 protocol and should be called explicitly. > > > This patch exposes cmd_read/go_idle via tpm class ops and removes > > > runtime pm support as it is not used by any driver. > > > > > > Signed-off-by: Tomas Winkler > > > > Thank you. > > > > LGTM > > > > Jason, what do you think? > > The PM stuff has been the source of confusion for a while, seems > reasonable to get rid of it. I'll test this ASAP. /Jarkk
Re: [PATCH 1/3] tpm: cmd_ready command can be issued only after granting locality
On Wed, Jan 24, 2018 at 06:33:53PM +, Winkler, Tomas wrote: > > > - pm_runtime_put(dev); > > > + pm_runtime_put_sync(dev); > > > > Change to put_sync is needed so that the idle handshake gets completed? > > Right. Since we seem to agree that your change to get rid of the use of PM runtime should that be actually the first change in the patch set? Or are you looking forward to get these backported to stable kernels? /Jarkko
Re: linux-next: Tree for Jan 26 (gpu/drm/i915/)
On Fri, 26 Jan 2018, Randy Dunlap wrote: > On 01/25/2018 06:58 PM, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20180119: >> > > on x86_64: > drivers/gpu/drm/i915/intel_panel.o: In function > `intel_backlight_device_register': > intel_panel.c:(.text+0x28d4): undefined reference to > `backlight_device_register' > drivers/gpu/drm/i915/intel_panel.o: In function > `intel_backlight_device_unregister': > intel_panel.c:(.text+0x2991): undefined reference to > `backlight_device_unregister' > > when CONFIG_BACKLIGHT_CLASS_DEVICE=m > and CONFIG_DRM_I915=y I don't deny there's an issue with i915 selecting CONFIG_BACKLIGHT_CLASS_DEVICE. I'm afraid previous attempts at fixing that have been a rabbit hole; new config errors pop up elsewhere. [citation needed]. That said, I thought we had enough duct tape in the Kconfig to keep the issues at bay. Since you're replying to linux-next, are you saying this is new? I wonder if something's changed elsewhere. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL
On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote:
>
> Windows use IBRS and Microsoft don't have any plans to switch to retpoline.
> Running a Windows guest should be a pretty common use-case no?
>
> In addition, your handle of the first WRMSR intercept could be different.
> It could signal you to start doing the following:
> 1. Disable intercept on SPEC_CTRL MSR.
> 2. On VMEntry, Write vCPU SPEC_CTRL value into physical MSR.
> 3. On VMExit, read physical MSR into vCPU SPEC_CTRL value.
> (And if IBRS is used at host, also set physical SPEC_CTRL MSR here to 1)
>
> That way, you will both have fastest option as long as guest don't use IBRS
> and also won't have the 3% performance hit compared to Konrad's proposal.
>
> Am I missing something?
Reads from the SPEC_CTRL MSR are strangely slow. I suspect a large part
of the 3% speedup you observe is because in the above, the vmentry path
doesn't need to *read* the host's value and store it; the host is
expected to restore it for itself anyway?
I'd actually quite like to repeat the benchmark on the new fixed
microcode, if anyone has it yet, to see if that read/swap slowness is
still quite as excessive. I'm certainly not ruling this out, but I'm
just a little wary of premature optimisation, and I'd like to make sure
we have everything *else* in the KVM patches right first.
The fact that the save-and-restrict macros I have in the tip of my
working tree at the moment are horrid and causing 0-day nastygrams,
probably doesn't help persuade me to favour the approach ;)
... hm, the CPU actually has separate MSR save/restore lists for
entry/exit, doesn't it? Is there any way to sanely make use of that and
do the restoration manually on vmentry but let it be automatic on
vmexit, by having it *only* in the guest's MSR-store area to be saved
on exit and restored on exit, but *not* in the host's MSR-store area?
Reading the code and comparing with the SDM, I can't see where we're
ever setting VM_EXIT_MSR_STORE_{ADDR,COUNT} except in the nested
case...
smime.p7s
Description: S/MIME cryptographic signature
Re: [4/4] hwmon: (dell-smm) Measure time duration of SMM call around inlined asm
On Saturday 27 January 2018 09:51:45 Guenter Roeck wrote:
> On Sat, Jan 27, 2018 at 05:23:51PM +0100, Pali Rohár wrote:
> > Measure only inlined asm code, not other functions to have as precise as
> > possible measured time.
> >
> > Signed-off-by: Pali Rohár
> > ---
> > drivers/hwmon/dell-smm-hwmon.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
> > index bf3bb7e1adab..e001afd53f46 100644
> > --- a/drivers/hwmon/dell-smm-hwmon.c
> > +++ b/drivers/hwmon/dell-smm-hwmon.c
> > @@ -147,14 +147,16 @@ static int i8k_smm_func(void *par)
> > int ebx = regs->ebx;
> > unsigned long duration;
> > ktime_t calltime, delta, rettime;
> > -
> > - calltime = ktime_get();
> > #endif
> >
> > /* SMM requires CPU 0 */
> > if (smp_processor_id() != 0)
> > return -EBUSY;
> >
> > +#ifdef DEBUG
> > + calltime = ktime_get();
> > +#endif
> > +
> > #if defined(CONFIG_X86_64)
> > asm volatile("pushq %%rax\n\t"
> > "movl 0(%%rax),%%edx\n\t"
> > @@ -208,13 +210,17 @@ static int i8k_smm_func(void *par)
> > :"a"(regs)
> > :"%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
> > #endif
> > - if (rc != 0 || (regs->eax & 0x) == 0x || regs->eax == eax)
> > - rc = -EINVAL;
> >
> > #ifdef DEBUG
> > rettime = ktime_get();
> > delta = ktime_sub(rettime, calltime);
> > duration = ktime_to_ns(delta) >> 10;
> > +#endif
> > +
> > + if (rc != 0 || (regs->eax & 0x) == 0x || regs->eax == eax)
> > + rc = -EINVAL;
> > +
> > +#ifdef DEBUG
>
> FWIW, the error introduced by dividing nS by 1,024 instead of 1,000 is
> much worse than the improvements from moving the calls around. Using
> specific numbers, the current code reports 500 mS as 488,281 uS.
> So why bother ?
Ah, I have not noticed this yet :-(
> I would have suggested to use ktime_us_delta(ktime_get(), calltime)
> instead to make the results more accurate. Sure, you get the offset from
> the additional divide operation, but at least that would be a constant
> and not a systematic error.
>
> I'll hold this patch off for a bit. Please confirm that you want it
> applied as-is. I applied the other patches from the series.
Ok, I will fix this patch and resend just new version of this one.
Anyway, if 2/4 is targeting stable, then 3/4 should too. But now I see
that I added Cc only to patch 2/4.
--
Pali Rohár
pali.ro...@gmail.com
[GIT pull] Timer core updates for 4.16
Linus, please pull the latest timers-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-core-for-linus The timer departement presents: - A rather large rework of the hrtimer infrastructure which introduces softirq based hrtimers to replace the spread of hrtimer/tasklet combos which force the actual callback execution into softirq context. The approach is completely different from the initial implementation which you cursed at 10 years ago rightfully. The softirq based timers have their own queues and there is no nasty indirection and list reshuffling in the hard interrupt anymore. This comes with conversion of some of the hrtimer/tasklet users, the rest and the final removal of that horrible interface will come towards the end of the merge window or go through the relevant maintainer trees. Note: The top commit merged the last minute bugfix for the 10 years old CPU hotplug bug as I wanted to make sure that I fatfinger the merge conflict resolution myself. - The overhaul of the STM32 clocksource/clockevents driver - A new driver for the Spreadtrum SC9860 timer - A new driver dor the Actions Semi S700 timer - The usual set of fixes and updates all over the place Thanks, tglx --> Andreas Färber (3): dt-bindings/clocksource: Add Actions Semi S700 timer clocksource/drivers/owl: Adopt TIMER_OF_DECLARE() clocksource/drivers/owl: Add the S700 timer Anna-Maria Gleixner (27): hrtimer: Fix kerneldoc syntax for 'struct hrtimer_cpu_base' hrtimer: Clean up the 'int clock' parameter of schedule_hrtimeout_range_clock() hrtimer: Fix hrtimer_start[_range_ns]() function descriptions hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers) hrtimer: Clean up 'enum hrtimer_mode' tracing/hrtimer: Fix tracing bugs by taking all clock bases and modes into account tracing/hrtimer: Print the hrtimer mode in the 'hrtimer_start' tracepoint hrtimer: Switch 'for' loop to _ffs() evaluation hrtimer: Store running timer in hrtimer_clock_base hrtimer: Make room in 'struct hrtimer_cpu_base' hrtimer: Make the hrtimer_cpu_base::hres_active field unconditional, to simplify the code hrtimer: Use accesor functions instead of direct access hrtimer: Make the remote enqueue check unconditional hrtimer: Make hrtimer_cpu_base.next_timer handling unconditional hrtimer: Make hrtimer_reprogramm() unconditional hrtimer: Make hrtimer_force_reprogramm() unconditionally available hrtimer: Unify hrtimer removal handling hrtimer: Unify remote enqueue handling hrtimer: Make remote enqueue decision less restrictive hrtimer: Remove the 'base' parameter from hrtimer_reprogram() hrtimer: Factor out __hrtimer_start_range_ns() hrtimer: Factor out __hrtimer_next_event_base() hrtimer: Use irqsave/irqrestore around __run_hrtimer() hrtimer: Add clock bases and hrtimer mode for softirq context hrtimer: Prepare handling of hard and softirq based hrtimers hrtimer: Implement support for softirq based hrtimers hrtimer: Implement SOFT/HARD clock base selection Baolin Wang (2): dt-bindings/clocksource: Add Spreadtrum SC9860 timer documentation clocksource/drivers/spreadtrum: Add timer driver for the Spreadtrum SC9860 platform Benjamin Gaignard (4): clocksource/drivers/stm32: Convert the driver to timer_of primitives clocksource/drivers/stm32: Compute a prescaler value with a targeted rate clocksource/drivers/stm32: Add oneshot mode clocksource/drivers/stm32: Add clocksource functionality Daniel Lezcano (10): clocksource/drivers/timer-of: Fix function names clocksource/drivers/timer-of: Add kernel documentation clocksource/drivers/timer-of: Store the device node pointer in 'struct timer_of' clocksource/drivers/timer-of: Don't request the resource by name clocksource/drivers/stm32: Fix kernel panic with multiple timers clocksource/drivers/stm32: Use the node name as timer name clocksource/drivers/stm32: Factor out the timer width sorting code clocksource/drivers/stm32: Factor out more of the clockevent code clocksource/drivers/stm32: Add the timer delay callback clocksource/drivers/stm32: Start the timer's counter sooner Max R. P. Grossmann (1): posix-cpu-timers: Make set_process_cpu_timer() more robust Nick Desaulniers (1): posix-timers: Prevent UB from shifting negative signed value Romain Izard (1): clocksource/drivers/tcb_clksrc: Fix clock speed message Thomas Gleixner (4): hrtimer: Optimize the hrtimer code by using static keys for migration_enable/nohz_active hrtimer: Correct blatantly incorrect comment ALSA/dummy: Replace tasklet with softirq hrtimer usb/gadget/NCM: Replace tasklet with softirq hr
[GIT pull] x86/cache updates for 4.16
Linus,
please pull the latest x86-cache-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cache-for-linus
A set of patches which add support for L2 cache partitioning to the Intel
RDT facility.
Thanks,
tglx
-->
Fenghua Yu (6):
x86/intel_rdt: Update documentation
x86/intel_rdt: Add L2CDP support in documentation
x86/intel_rdt: Enumerate L2 Code and Data Prioritization (CDP) feature
x86/intel_rdt: Add two new resources for L2 Code and Data Prioritization
(CDP)
x86/intel_rdt: Enable L2 CDP in MSR IA32_L2_QOS_CFG
x86/intel_rdt: Add command line parameter to control L2_CDP
Documentation/admin-guide/kernel-parameters.txt | 3 +-
Documentation/x86/intel_rdt_ui.txt | 13 ++-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/intel_rdt.c | 68 --
arch/x86/kernel/cpu/intel_rdt.h | 5 +
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c| 117 ++--
arch/x86/kernel/cpu/scattered.c | 1 +
7 files changed, 169 insertions(+), 39 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 46b26bfee27b..fde058ca8419 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3682,7 +3682,8 @@
rdt=[HW,X86,RDT]
Turn on/off individual RDT features. List is:
- cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, mba.
+ cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
+ mba.
E.g. to turn on cmt and turn off mba use:
rdt=cmt,!mba
diff --git a/Documentation/x86/intel_rdt_ui.txt
b/Documentation/x86/intel_rdt_ui.txt
index 6851854cf69d..756fd76b78a6 100644
--- a/Documentation/x86/intel_rdt_ui.txt
+++ b/Documentation/x86/intel_rdt_ui.txt
@@ -7,15 +7,24 @@ Tony Luck
Vikas Shivappa
This feature is enabled by the CONFIG_INTEL_RDT Kconfig and the
-X86 /proc/cpuinfo flag bits "rdt", "cqm", "cat_l3" and "cdp_l3".
+X86 /proc/cpuinfo flag bits:
+RDT (Resource Director Technology) Allocation - "rdt_a"
+CAT (Cache Allocation Technology) - "cat_l3", "cat_l2"
+CDP (Code and Data Prioritization ) - "cdp_l3", "cdp_l2"
+CQM (Cache QoS Monitoring) - "cqm_llc", "cqm_occup_llc"
+MBM (Memory Bandwidth Monitoring) - "cqm_mbm_total", "cqm_mbm_local"
+MBA (Memory Bandwidth Allocation) - "mba"
To use the feature mount the file system:
- # mount -t resctrl resctrl [-o cdp] /sys/fs/resctrl
+ # mount -t resctrl resctrl [-o cdp[,cdpl2]] /sys/fs/resctrl
mount options are:
"cdp": Enable code/data prioritization in L3 cache allocations.
+"cdpl2": Enable code/data prioritization in L2 cache allocations.
+
+L2 and L3 CDP are controlled seperately.
RDT features are orthogonal. A particular system may support only
monitoring, only control, or both monitoring and control.
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 25b9375c1484..67bbfaa1448b 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -206,6 +206,7 @@
#define X86_FEATURE_RETPOLINE ( 7*32+12) /* Generic Retpoline
mitigation for Spectre variant 2 */
#define X86_FEATURE_RETPOLINE_AMD ( 7*32+13) /* AMD Retpoline mitigation
for Spectre variant 2 */
#define X86_FEATURE_INTEL_PPIN ( 7*32+14) /* Intel Processor Inventory
Number */
+#define X86_FEATURE_CDP_L2 ( 7*32+15) /* Code and Data
Prioritization L2 */
#define X86_FEATURE_AVX512_4VNNIW ( 7*32+16) /* AVX-512 Neural Network
Instructions */
#define X86_FEATURE_AVX512_4FMAPS ( 7*32+17) /* AVX-512 Multiply
Accumulation Single precision */
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu/intel_rdt.c
index 99442370de40..410629f10ad3 100644
--- a/arch/x86/kernel/cpu/intel_rdt.c
+++ b/arch/x86/kernel/cpu/intel_rdt.c
@@ -135,6 +135,40 @@ struct rdt_resource rdt_resources_all[] = {
.format_str = "%d=%0*x",
.fflags = RFTYPE_RES_CACHE,
},
+ [RDT_RESOURCE_L2DATA] =
+ {
+ .rid= RDT_RESOURCE_L2DATA,
+ .name = "L2DATA",
+ .domains= domain_init(RDT_RESOURCE_L2DATA),
+ .msr_base = IA32_L2_CBM_BASE,
+ .msr_update = cat_wrmsr,
+ .cache_level= 2,
+ .cache = {
+ .min_cbm_bits = 1,
+ .cbm_idx_mult = 2,
+ .cbm_idx_offset = 0,
+ },
+ .parse_ctrlval = parse_cbm,
+ .format_str = "%d=%0*x",
+
Re: [PATCH] m68k/mac: Enable PDMA support for PowerBook 190
Hi Finn,
On Sun, Jan 28, 2018 at 12:51 AM, Finn Thain wrote:
> Stan's tests showed that PDMA improves sequential read performance by
> a factor of 5 on a PowerBook 190. Last time I tried this on a
> PowerBook 520 it didn't work, so let's not enable it there until
> it can be tested with the present mac_scsi driver.
>
> Tested-by: Stan Johnson
> Signed-off-by: Finn Thain
Thanks for your patch!
Anyone with a PB520 who can check if it works now with scsi_type =
MAC_SCSI_OLD?
> ---
> arch/m68k/mac/config.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
> index 16cd5cea5207..95d548d8cc8a 100644
> --- a/arch/m68k/mac/config.c
> +++ b/arch/m68k/mac/config.c
> @@ -713,7 +713,7 @@ static struct mac_model mac_data_table[] = {
> .name = "PowerBook 190",
> .adb_type = MAC_ADB_PB2,
> .via_type = MAC_VIA_QUADRA,
> - .scsi_type = MAC_SCSI_LATE,
> + .scsi_type = MAC_SCSI_OLD,
> .ide_type = MAC_IDE_BABOON,
> .scc_type = MAC_SCC_QUADRA,
> .nubus_type = MAC_NUBUS,
> @@ -1077,9 +1077,7 @@ int __init mac_platform_init(void)
> mac_scsi_old_rsrc, ARRAY_SIZE(mac_scsi_old_rsrc));
> break;
> case MAC_SCSI_LATE:
> - /* PDMA logic in 68040 PowerBooks is somehow different to
> -* '030 models. It's probably more like Quadras (see mac_esp).
> -*/
> + /* XXX PDMA support for PowerBook 500 series needs testing */
> platform_device_register_simple("mac_scsi", 0,
> mac_scsi_late_rsrc, ARRAY_SIZE(mac_scsi_late_rsrc));
> break;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[GIT pull] x86/platform updates for 4.16
Linus,
please pull the latest x86-platform-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-platform-for-linus
The platform support for x86 contains the following updates:
- A set of updates for the UV platform to support new CPUs and to fix
some of the UV4A BAU MRRs
- The initial platform support for the jailhouse hypervisor to allow
native Linux guests (inmates) in non-root cells.
- A fix for the PCI initialization on Intel MID platforms
Thanks,
tglx
-->
Andrew Banman (1):
x86/platform/uv/BAU: Replace hard-coded values with MMR definitions
Andy Shevchenko (1):
x86/platform/intel-mid: Move PCI initialization to arch_init()
Arnd Bergmann (1):
x86/jailhouse: Add PCI dependency
Jan Kiszka (14):
x86/apic: Install an empty physflat_init_apic_ldr
x86/platform: Control warm reset setup via legacy feature flag
x86: Introduce and use MP IRQ trigger and polarity defines
x86/jailhouse: Add infrastructure for running in non-root cell
x86/jailhouse: Enable APIC and SMP support
x86/jailhouse: Enable PMTIMER
x86/jailhouse: Set up timekeeping
x86/jailhouse: Avoid access of unsupported platform resources
x86/jailhouse: Silence ACPI warning
x86/jailhouse: Halt instead of failing to restart
x86/jailhouse: Wire up IOAPIC for legacy UART ports
x86/jailhouse: Initialize PCI support
x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ
x86/jailhouse: Respect pci=lastbus command line settings
Mike Travis (6):
x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes
x86/platform/UV: Fix UV4A support on new Intel Processors
x86/platform/UV: Add references to access fixed UV4A HUB MMRs
x86/platform/UV: Fix GAM MMR changes in UV4A
x86/platform/UV: Fix GAM MMR references in the UV x2apic code
x86/platform/UV: Fix UV4A BAU MMRs
Thomas Gleixner (1):
x86/jailhouse: Hide x2apic code when CONFIG_X86_X2APIC=n
arch/x86/Kconfig| 9 +
arch/x86/include/asm/hypervisor.h | 1 +
arch/x86/include/asm/jailhouse_para.h | 26 ++
arch/x86/include/asm/mpspec_def.h | 14 +-
arch/x86/include/asm/uv/uv_bau.h| 1 -
arch/x86/include/asm/uv/uv_hub.h| 14 +
arch/x86/include/asm/uv/uv_mmrs.h | 749 +++-
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/include/uapi/asm/bootparam.h | 22 +
arch/x86/kernel/Makefile| 2 +
arch/x86/kernel/apic/apic_flat_64.c | 16 +-
arch/x86/kernel/apic/io_apic.c | 20 +-
arch/x86/kernel/apic/x2apic_uv_x.c | 84 ++--
arch/x86/kernel/cpu/hypervisor.c| 4 +
arch/x86/kernel/jailhouse.c | 211 +
arch/x86/kernel/mpparse.c | 23 +-
arch/x86/kernel/platform-quirks.c | 1 +
arch/x86/kernel/smpboot.c | 4 +-
arch/x86/pci/intel_mid_pci.c| 1 +
arch/x86/platform/intel-mid/intel-mid.c | 2 +-
arch/x86/platform/intel-mid/sfi.c | 5 +-
arch/x86/platform/uv/tlb_uv.c | 3 +-
drivers/acpi/Kconfig| 32 +-
23 files changed, 1052 insertions(+), 193 deletions(-)
create mode 100644 arch/x86/include/asm/jailhouse_para.h
create mode 100644 arch/x86/kernel/jailhouse.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ff4e9cd99854..390be2eb153d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -796,6 +796,15 @@ config PARAVIRT_TIME_ACCOUNTING
config PARAVIRT_CLOCK
bool
+config JAILHOUSE_GUEST
+ bool "Jailhouse non-root cell support"
+ depends on X86_64 && PCI
+ select X86_PM_TIMER
+ ---help---
+ This option allows to run Linux as guest in a Jailhouse non-root
+ cell. You can leave this option disabled if you only want to start
+ Jailhouse and run Linux afterwards in the root cell.
+
endif #HYPERVISOR_GUEST
config NO_BOOTMEM
diff --git a/arch/x86/include/asm/hypervisor.h
b/arch/x86/include/asm/hypervisor.h
index 96aa6b9884dc..8c5aaba6633f 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -28,6 +28,7 @@ enum x86_hypervisor_type {
X86_HYPER_XEN_PV,
X86_HYPER_XEN_HVM,
X86_HYPER_KVM,
+ X86_HYPER_JAILHOUSE,
};
#ifdef CONFIG_HYPERVISOR_GUEST
diff --git a/arch/x86/include/asm/jailhouse_para.h
b/arch/x86/include/asm/jailhouse_para.h
new file mode 100644
index ..875b54376689
--- /dev/null
+++ b/arch/x86/include/asm/jailhouse_para.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL2.0 */
+
+/*
+ * Jailhouse paravirt_ops implementation
+ *
+ * Copyright (c) Siemens AG, 2015-2017
+ *
+ * Authors:
+ * Jan Kiszka
+ */
+
+#ifndef _ASM_X86_JAILHOUSE_PARA_H
+#define _ASM_X86_JAILHOUSE_PARA_H
+
+#include
+
+#ifdef CONFIG_JAILHOUSE_GUEST
+bool jailhouse_paravirt(void);
+#else
+static inline bool jailhouse_parav
linux-next: Tree for Jan 29
Hi all,
Please do not add any v4.17 material to your linux-next included branches
until after v4.16-rc1 has been released.
Changes since 20180126:
The f2fs tree still had its build failure due to an interaction with
the btrfs tree for which I reverted a commit.
The pci tree lost its build failure, but gained conflicts against the
powerpc tree one of which required a merge fix patch.
The net-next tree gained a build failure due to an interaction with the
net tree for which I applied a merge fix patch.
The rmda tree lost its build failure.
The mfd tree gained a conflict against the powerpc tree.
The tip tree gained a conflict against the i2c tree.
The userns tree still had its build failure for which I added a patch.
The nvdimm tree gained conflicts against the powerpc tree.
Non-merge commits (relative to Linus' tree): 11048
10670 files changed, 464578 insertions(+), 295943 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, an allmodconfig 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. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 256 trees (counting Linus' and 44 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 (c4e0ca7fa241 Merge tag
'riscv-for-linus-4.15-maintainers' of
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux)
Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging kbuild-current/fixes (36c1681678b5 genksyms: drop *.hash.c from
.gitignore)
Merging arc-current/for-curr (a46f24acf8bc ARC: boot log: Fix trailing
semicolon)
Merging arm-current/fixes (091f02483df7 ARM: net: bpf: clarify tail_call index)
Merging m68k-current/for-linus (5e387199c17c m68k/defconfig: Update defconfigs
for v4.14-rc7)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (1b689a95ce74 powerpc/pseries: include
linux/types.h in asm/hvcall.h)
Merging sparc/master (aebb48f5e465 sparc64: fix typo in
CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (ba804bb4b72e Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging bpf/master (e58edaa48635 net/mlx5e: Fix fixpoint divide exception in
mlx5e_am_stats_compare)
Merging ipsec/master (545d8ae7afff xfrm: fix boolean assignment in
xfrm_get_type_offload)
Merging netfilter/master (da17c73b6eb7 netfilter: x_tables: avoid out-of-bounds
reads in xt_request_find_{match|target})
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook
mask only if set)
Merging wireless-drivers/master (a9e6d44ddecc ssb: Do not disable PCI host on
non-Mips)
Merging mac80211/master (e58edaa48635 net/mlx5e: Fix fixpoint divide exception
in mlx5e_am_stats_compare)
Merging rdma-fixes/for-rc (ae59c3f0b6cf RDMA/mlx5: Fix out-of-bound access
while querying AH)
Merging sound-current/for-linus (1c9609e3a8cf ALSA: hda - Reduce the suspend
time consumption for ALC256)
Merging pci-current/for-linus (838cda369707 x86/PCI: Enable AMD 64-bit window
on resume)
Merging driver-core.current/driver-core-linus (30a7acd57389 Linux 4.15-rc6)
Merging tty.current/tty-linus (30a7acd57389 Linux 4.15-rc6)
Merging usb.current/usb-linus (a8750ddca918 Linux 4.15-rc8)
Merging usb-gadget-fixes/fixes (b2cd1df66037 Linux 4.15-rc7)
Merging usb-serial-fixes/usb-linus (d
[GIT pull] x86/timer updates for 4.16
Linus,
please pull the latest x86-timers-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-timers-for-linus
A small set of updates for x86 specific timers:
- Mark TSC invariant on a subset of Centaur CPUs
- Allow TSC calibration without PIT on mobile platforms which lack legacy
devices.
Thanks,
tglx
-->
Peter Zijlstra (3):
x86/tsc: Allow TSC calibration without PIT
x86/time: Unconditionally register legacy timer interrupt
x86/tsc: Introduce early tsc clocksource
davidwang (1):
x86/centaur: Mark TSC invariant
arch/x86/include/asm/i8259.h | 5
arch/x86/kernel/cpu/centaur.c | 4 +++
arch/x86/kernel/time.c| 9 ---
arch/x86/kernel/tsc.c | 61 ---
drivers/acpi/processor_idle.c | 1 +
5 files changed, 67 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/i8259.h b/arch/x86/include/asm/i8259.h
index c8376b40e882..5cdcdbd4d892 100644
--- a/arch/x86/include/asm/i8259.h
+++ b/arch/x86/include/asm/i8259.h
@@ -69,6 +69,11 @@ struct legacy_pic {
extern struct legacy_pic *legacy_pic;
extern struct legacy_pic null_legacy_pic;
+static inline bool has_legacy_pic(void)
+{
+ return legacy_pic != &null_legacy_pic;
+}
+
static inline int nr_legacy_irqs(void)
{
return legacy_pic->nr_legacy_irqs;
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 68bc6d9b3132..c578cd29c2d2 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -106,6 +106,10 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
#ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_SYSENTER32);
#endif
+ if (c->x86_power & (1 << 8)) {
+ set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
+ set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
+ }
}
static void init_centaur(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
index 749d189f8cd4..774ebafa97c4 100644
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -69,9 +69,12 @@ static struct irqaction irq0 = {
static void __init setup_default_timer_irq(void)
{
- if (!nr_legacy_irqs())
- return;
- setup_irq(0, &irq0);
+ /*
+* Unconditionally register the legacy timer; even without legacy
+* PIC/PIT we need this for the HPET0 in legacy replacement mode.
+*/
+ if (setup_irq(0, &irq0))
+ pr_info("Failed to register legacy timer interrupt\n");
}
/* Default timer init function */
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index e169e85db434..fb4302738410 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
unsigned int __read_mostly cpu_khz;/* TSC clocks / usec, not used here */
EXPORT_SYMBOL(cpu_khz);
@@ -363,6 +364,20 @@ static unsigned long pit_calibrate_tsc(u32 latch, unsigned
long ms, int loopmin)
unsigned long tscmin, tscmax;
int pitcnt;
+ if (!has_legacy_pic()) {
+ /*
+* Relies on tsc_early_delay_calibrate() to have given us semi
+* usable udelay(), wait for the same 50ms we would have with
+* the PIT loop below.
+*/
+ udelay(10 * USEC_PER_MSEC);
+ udelay(10 * USEC_PER_MSEC);
+ udelay(10 * USEC_PER_MSEC);
+ udelay(10 * USEC_PER_MSEC);
+ udelay(10 * USEC_PER_MSEC);
+ return ULONG_MAX;
+ }
+
/* Set the Gate high, disable speaker */
outb((inb(0x61) & ~0x02) | 0x01, 0x61);
@@ -487,6 +502,9 @@ static unsigned long quick_pit_calibrate(void)
u64 tsc, delta;
unsigned long d1, d2;
+ if (!has_legacy_pic())
+ return 0;
+
/* Set the Gate high, disable speaker */
outb((inb(0x61) & ~0x02) | 0x01, 0x61);
@@ -988,8 +1006,6 @@ static void __init detect_art(void)
/* clocksource code */
-static struct clocksource clocksource_tsc;
-
static void tsc_resume(struct clocksource *cs)
{
tsc_verify_tsc_adjust(true);
@@ -1040,12 +1056,31 @@ static void tsc_cs_tick_stable(struct clocksource *cs)
/*
* .mask MUST be CLOCKSOURCE_MASK(64). See comment above read_tsc()
*/
+static struct clocksource clocksource_tsc_early = {
+ .name = "tsc-early",
+ .rating = 299,
+ .read = read_tsc,
+ .mask = CLOCKSOURCE_MASK(64),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS |
+ CLOCK_SOURCE_MUST_VERIFY,
+ .archdata = { .vclock_mode = VCLOCK_TSC },
+ .resume = tsc_resume,
+ .mark_unstable = tsc_cs_mark_unstable,
+ .tick_stable= tsc_cs_tick_stable,
+};
+
+/*
Re: [PATCH v3 4/5] powerpc/mm: Allow up to 64 low slices
Le 29/01/2018 à 07:29, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single u64 low_slices_psize
element in struct mm_context_t
On the 8xx, the minimum slice size is the size of the area
covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
16K pages mode. This means we could have at least 64 slices.
In order to override this limitation, this patch switches the
handling of low_slices_psize to char array as done already for
high_slices_psize. This allows to increase the number of low
slices to 64 on the 8xx.
Maybe update the subject to "make low slice also a bitmap".Also indicate
that the bitmap functions optimize the operation if the bitmapsize les
<= long ?
v3 doesn't use bitmap functions anymore for low_slices. In this version,
only low_slices_psize has been reworked to allow up to 64 slices instead
of 16. I have kept low_slices as is (ie as a u64), hence allowing up to
64 slices, which is big enough.
Also switch the 8xx to higher value in the another patch?
One separate patch just for changing the value of SLICE_LOW_SHIFT from
28 to 26 on the 8xx ?
Signed-off-by: Christophe Leroy
---
v2: Usign slice_bitmap_xxx() macros instead of bitmap_xxx() functions.
v3: keep low_slices as a u64, this allows 64 slices which is enough.
arch/powerpc/include/asm/book3s/64/mmu.h | 3 +-
arch/powerpc/include/asm/mmu-8xx.h | 7 +++-
arch/powerpc/include/asm/paca.h | 2 +-
arch/powerpc/include/asm/slice.h | 1 -
arch/powerpc/include/asm/slice_32.h | 2 ++
arch/powerpc/include/asm/slice_64.h | 2 ++
arch/powerpc/kernel/paca.c | 3 +-
arch/powerpc/mm/hash_utils_64.c | 13
arch/powerpc/mm/slb_low.S| 8 +++--
arch/powerpc/mm/slice.c | 57 +---
10 files changed, 56 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
b/arch/powerpc/include/asm/book3s/64/mmu.h
index c9448e19847a..b076a2d74c69 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -91,7 +91,8 @@ typedef struct {
struct npu_context *npu_context;
#ifdef CONFIG_PPC_MM_SLICES
- u64 low_slices_psize; /* SLB page size encodings */
+/* SLB page size encodings*/
+ unsigned char low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
unsigned char high_slices_psize[SLICE_ARRAY_SIZE];
unsigned long slb_addr_limit;
#else
diff --git a/arch/powerpc/include/asm/mmu-8xx.h
b/arch/powerpc/include/asm/mmu-8xx.h
index 5f89b6010453..5f37ba06b56c 100644
--- a/arch/powerpc/include/asm/mmu-8xx.h
+++ b/arch/powerpc/include/asm/mmu-8xx.h
@@ -164,6 +164,11 @@
*/
#define SPRN_M_TW 799
+#ifdef CONFIG_PPC_MM_SLICES
+#include
+#define SLICE_ARRAY_SIZE (1 << (32 - SLICE_LOW_SHIFT - 1))
+#endif
+
#ifndef __ASSEMBLY__
typedef struct {
unsigned int id;
@@ -171,7 +176,7 @@ typedef struct {
unsigned long vdso_base;
#ifdef CONFIG_PPC_MM_SLICES
u16 user_psize; /* page size index */
- u64 low_slices_psize; /* page size encodings */
+ unsigned char low_slices_psize[SLICE_ARRAY_SIZE];
unsigned char high_slices_psize[0];
unsigned long slb_addr_limit;
#endif
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 23ac7fc0af23..a3e531fe9ac7 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -141,7 +141,7 @@ struct paca_struct {
#ifdef CONFIG_PPC_BOOK3S
mm_context_id_t mm_ctx_id;
#ifdef CONFIG_PPC_MM_SLICES
- u64 mm_ctx_low_slices_psize;
+ unsigned char mm_ctx_low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
unsigned char mm_ctx_high_slices_psize[SLICE_ARRAY_SIZE];
unsigned long mm_ctx_slb_addr_limit;
#else
diff --git a/arch/powerpc/include/asm/slice.h b/arch/powerpc/include/asm/slice.h
index 2b4b70de7e71..b67ba8faa507 100644
--- a/arch/powerpc/include/asm/slice.h
+++ b/arch/powerpc/include/asm/slice.h
@@ -16,7 +16,6 @@
#define HAVE_ARCH_UNMAPPED_AREA
#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
-#define SLICE_LOW_SHIFT 28
#define SLICE_LOW_TOP (0x1ull)
#define SLICE_NUM_LOW (SLICE_LOW_TOP >> SLICE_LOW_SHIFT)
#define GET_LOW_SLICE_INDEX(addr) ((addr) >> SLICE_LOW_SHIFT)
diff --git a/arch/powerpc/include/asm/slice_32.h
b/arch/powerpc/include/asm/slice_32.h
index 7e27c0dfb913..349187c20100 100644
--- a/arch/powerpc/include/asm/slice_32.h
+++ b/arch/powerpc/include/asm/slice_32.h
@@ -2,6 +2,8 @@
#ifndef _ASM_POWERPC_SLICE_32_H
#define _ASM_POWERPC_SLICE_32_H
+#define SLICE_LOW_SHIFT 26 /* 64 slices */
+
#define SLICE_HIGH_SHIFT 0
#define SLICE_NUM_HIGH0ul
#defin
Re: [PATCH] f2fs: fix heap mode to reset it back
On 2018/1/29 16:31, Yunlong Song wrote:
> The old commit allocates hot data & nodes in the beginning of partition
> both for heap and
> noheap mode. But from the commit message, the heap mode should be like
> before, i.e.,
> allocate hot data & nodes from curseg to left.
Let's ping Jaegeuk to check that, :)
Thanks,
>
> On 2018/1/29 16:12, Chao Yu wrote:
>> Hi Yunlong,
>>
>> On 2018/1/29 11:37, Yunlong Song wrote:
>>> Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
>>> and hot data in the beginning of partition") introduces another mount
>>> option, heap, to reset it back. But it does not do anything for heap
>>> mode, so fix it.
>> I think Jaegeuk did three things in that patch:
>> a) add missing heap mount option handling in ->show_options.
>> b) set noheap by default.
>> c) change allocation policy to the one that allocate hotdata & nodes in the
>> front of main are intensively.
>>
>> They could be separated, independent, and I don't see such intention that
>> we can only use c) the new introduced allocation policy in noheap mode.
>>
>> Anyway, I think Jaegeuk can help to double check that.
>>
>> Thanks,
>>
>>> Signed-off-by: Yunlong Song
>>> ---
>>> fs/f2fs/gc.c | 5 +++--
>>> fs/f2fs/segment.c | 3 ++-
>>> 2 files changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index aa720cc..b9d93fd 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -191,8 +191,9 @@ static void select_policy(struct f2fs_sb_info *sbi, int
>>> gc_type,
>>> if (gc_type != FG_GC && p->max_search > sbi->max_victim_search)
>>> p->max_search = sbi->max_victim_search;
>>>
>>> - /* let's select beginning hot/small space first */
>>> - if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
>>> + /* let's select beginning hot/small space first in no_heap mode*/
>>> + if (test_opt(sbi, NOHEAP) &&
>>> + (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
>>> p->offset = 0;
>>> else
>>> p->offset = SIT_I(sbi)->last_victim[p->gc_mode];
>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>> index e5739ce..77a48c4 100644
>>> --- a/fs/f2fs/segment.c
>>> +++ b/fs/f2fs/segment.c
>>> @@ -2167,7 +2167,8 @@ static unsigned int __get_next_segno(struct
>>> f2fs_sb_info *sbi, int type)
>>> if (sbi->segs_per_sec != 1)
>>> return CURSEG_I(sbi, type)->segno;
>>>
>>> - if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
>>> + if (test_opt(sbi, NOHEAP) &&
>>> + (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
>>> return 0;
>>>
>>> if (SIT_I(sbi)->last_victim[ALLOC_NEXT])
>>>
>>
>> .
>>
>
Re: [PATCH] tracing: Block comments should align the * on each line
Yes but still Cc me. -- Steve On January 29, 2018 6:55:26 AM GMT+01:00, Rohit Visavalia wrote: >Hi Steve, > >Thanks for the review. > >Do you want me to resend the patch with v2 version to >triv...@kernel.org ? > >Thanks, >Rohit > >> > >> From: Rohit Visavalia >> Sent: Monday, January 29, 2018 11:10 AM >> To: Steven Rostedt >> Cc: mi...@redhat.com; linux-kernel@vger.kernel.org; >triv...@kernel.org >> Subject: Re: [PATCH] tracing: Block comments should align the * on >each line >> > >> Hi Steve, > >> > >> Thanks for the review. > >> > >> Do you want me to resend the patch with v2 version to >triv...@kernel.org ? > >> > >> Thanks, > >> Rohit > >> >> >> > >> From: Steven Rostedt >> Sent: Thursday, January 25, 2018 10:44 PM >> To: Rohit Visavalia >> Cc: mi...@redhat.com; linux-kernel@vger.kernel.org; >triv...@kernel.org >> Subject: Re: [PATCH] tracing: Block comments should align the * on >each line >> >> >> Bah, this was suppose to go to triv...@kernel.org, not >> triv...@vger.kernel.org. >> >> -- Steve >> >> >> On Thu, 25 Jan 2018 12:05:52 -0500 >> Steven Rostedt wrote: >> >> > On Thu, 25 Jan 2018 18:01:36 +0530 >> > Rohit Visavalia wrote: >> > >> > > Resolved Block comments use * on subsequent lines checkpatch >warning. >> > > Issue found by checkpatch. >> > > >> > >> > This should go through the trivial tree. >> > >> > Acked-by: Steven Rostedt (VMware) >> > >> > -- Steve >> > >> > > Signed-off-by: Rohit Visavalia >> > > --- >> > > kernel/trace/trace.c | 2 +- >> > > 1 file changed, 1 insertion(+), 1 deletion(-) >> > > >> > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c >> > > index 8e3f20a18a06..ad718932ff32 100644 >> > > --- a/kernel/trace/trace.c >> > > +++ b/kernel/trace/trace.c >> > > @@ -2380,7 +2380,7 @@ >EXPORT_SYMBOL_GPL(trace_event_buffer_commit); >> > > * trace_buffer_unlock_commit_regs() >> > > * trace_event_buffer_commit() >> > > * trace_event_raw_event_xxx() >> > > -*/ >> > > + */ >> > > # define STACK_SKIP 3 >> > > >> > > void trace_buffer_unlock_commit_regs(struct trace_array *tr, >> > >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH v19 03/10] video: backlight: Add of_find_backlight helper in backlight.c
On Fri, 26 Jan 2018, Randy Dunlap wrote: > On 01/26/2018 01:48 AM, Lee Jones wrote: > > On Wed, 24 Jan 2018, Meghana Madhyastha wrote: > > > >> Add of_find_backlight, a helper function which is a generic version > >> of tinydrm_of_find_backlight that can be used by other drivers to avoid > >> repetition of code and simplify things. > >> > >> Acked-by: Daniel Thompson > >> Reviewed-by: Noralf Trønnes > >> Reviewed-by: Sean Paul > >> Signed-off-by: Meghana Madhyastha > > > > Nit: These should be in chronological order. > > Where does that tidbit of information come from? > I have never heard or read that. Not sure it is documented anywhere. It appeared to be the widely used, most sensible approach, so I adopted it a few years ago. This method provides us with information which would otherwise be absent; including description of the patch submission/acceptance path and an idea of who did what, when. For example: Original Author sign-off Original Co-author sign-off [Additional contributions: rebase, API changes, fix-ups] Re-worker's sign-off Tester's tested-by Reviewer's acked-by/reviewed-by Level-2 Maintainer sign-off Level-1 Maintainer sign-off Are you aware of a more functional/practical/useful method? -- Lee Jones Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH RFC 01/16] prcu: Add PRCU implementation
On Tue, Jan 23, 2018 at 3:59 PM, wrote:
> From: Heng Zhang
>
> This RCU implementation (PRCU) is based on a fast consensus protocol
> published in the following paper:
>
> Fast Consensus Using Bounded Staleness for Scalable Read-mostly
> Synchronization.
> Haibo Chen, Heng Zhang, Ran Liu, Binyu Zang, and Haibing Guan.
> IEEE Transactions on Parallel and Distributed Systems (TPDS), 2016.
> https://dl.acm.org/citation.cfm?id=3024114.3024143
>
> Signed-off-by: Heng Zhang
> Signed-off-by: Lihao Liang
> ---
> include/linux/prcu.h | 37 +++
> kernel/rcu/Makefile | 2 +-
> kernel/rcu/prcu.c| 125
> +++
> kernel/sched/core.c | 2 +
> 4 files changed, 165 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/prcu.h
> create mode 100644 kernel/rcu/prcu.c
>
> diff --git a/include/linux/prcu.h b/include/linux/prcu.h
> new file mode 100644
> index ..653b4633
> --- /dev/null
> +++ b/include/linux/prcu.h
> @@ -0,0 +1,37 @@
> +#ifndef __LINUX_PRCU_H
> +#define __LINUX_PRCU_H
> +
> +#include
> +#include
> +#include
> +
> +#define CONFIG_PRCU
> +
> +struct prcu_local_struct {
> + unsigned int locked;
> + unsigned int online;
> + unsigned long long version;
> +};
> +
> +struct prcu_struct {
> + atomic64_t global_version;
> + atomic_t active_ctr;
> + struct mutex mtx;
> + wait_queue_head_t wait_q;
> +};
> +
> +#ifdef CONFIG_PRCU
> +void prcu_read_lock(void);
> +void prcu_read_unlock(void);
> +void synchronize_prcu(void);
> +void prcu_note_context_switch(void);
> +
> +#else /* #ifdef CONFIG_PRCU */
> +
> +#define prcu_read_lock() do {} while (0)
> +#define prcu_read_unlock() do {} while (0)
> +#define synchronize_prcu() do {} while (0)
> +#define prcu_note_context_switch() do {} while (0)
> +
> +#endif /* #ifdef CONFIG_PRCU */
> +#endif /* __LINUX_PRCU_H */
> diff --git a/kernel/rcu/Makefile b/kernel/rcu/Makefile
> index 23803c7d..8791419c 100644
> --- a/kernel/rcu/Makefile
> +++ b/kernel/rcu/Makefile
> @@ -2,7 +2,7 @@
> # and is generally not a function of system call inputs.
> KCOV_INSTRUMENT := n
>
> -obj-y += update.o sync.o
> +obj-y += update.o sync.o prcu.o
> obj-$(CONFIG_CLASSIC_SRCU) += srcu.o
> obj-$(CONFIG_TREE_SRCU) += srcutree.o
> obj-$(CONFIG_TINY_SRCU) += srcutiny.o
> diff --git a/kernel/rcu/prcu.c b/kernel/rcu/prcu.c
> new file mode 100644
> index ..a00b9420
> --- /dev/null
> +++ b/kernel/rcu/prcu.c
> @@ -0,0 +1,125 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +DEFINE_PER_CPU_SHARED_ALIGNED(struct prcu_local_struct, prcu_local);
> +
> +struct prcu_struct global_prcu = {
> + .global_version = ATOMIC64_INIT(0),
> + .active_ctr = ATOMIC_INIT(0),
> + .mtx = __MUTEX_INITIALIZER(global_prcu.mtx),
> + .wait_q = __WAIT_QUEUE_HEAD_INITIALIZER(global_prcu.wait_q)
> +};
> +struct prcu_struct *prcu = &global_prcu;
> +
> +static inline void prcu_report(struct prcu_local_struct *local)
> +{
> + unsigned long long global_version;
> + unsigned long long local_version;
> +
> + global_version = atomic64_read(&prcu->global_version);
> + local_version = local->version;
> + if (global_version > local_version)
> + cmpxchg(&local->version, local_version, global_version);
It is called with irq-disabled, and local->version can't be modified on
other cpu. why cmpxchg is needed?
> +}
> +
> +void prcu_read_lock(void)
> +{
> + struct prcu_local_struct *local;
> +
> + local = get_cpu_ptr(&prcu_local);
> + if (!local->online) {
> + WRITE_ONCE(local->online, 1);
> + smp_mb();
What's is the paired code?
> + }
> +
> + local->locked++;
> + put_cpu_ptr(&prcu_local);
> +}
> +EXPORT_SYMBOL(prcu_read_lock);
> +
> +void prcu_read_unlock(void)
> +{
> + int locked;
> + struct prcu_local_struct *local;
> +
> + barrier();
> + local = get_cpu_ptr(&prcu_local);
> + locked = local->locked;
> + if (locked) {
> + local->locked--;
> + if (locked == 1)
> + prcu_report(local);
> + put_cpu_ptr(&prcu_local);
> + } else {
> + put_cpu_ptr(&prcu_local);
> + if (!atomic_dec_return(&prcu->active_ctr))
> + wake_up(&prcu->wait_q);
> + }
> +}
> +EXPORT_SYMBOL(prcu_read_unlock);
> +
> +static void prcu_handler(void *info)
> +{
> + struct prcu_local_struct *local;
> +
> + local = this_cpu_ptr(&prcu_local);
> + if (!local->locked)
> + WRITE_ONCE(local->version,
> atomic64_read(&prcu->global_version));
> +}
> +
> +void synchronize_prcu(void)
> +{
> + int cpu;
> + cpumask_t cpus;
It might overflow the stack if the cpumask is large, please move it to
struct prcu.
> + unsigned long long version;
> + struct prcu_local_struct *local
[PATCH v7 0/2] Initial Allwinner V3s CSI Support
This patchset add initial support for Allwinner V3s CSI. Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 interface and CSI1 is used for parallel interface. This is not documented in datasheet but by test and guess. This patchset implement a v4l2 framework driver and add a binding documentation for it. Currently, the driver only support the parallel interface. And has been tested with a BT1120 signal which generating from FPGA. The following fetures are not support with this patchset: - ISP - MIPI-CSI2 - Master clock for camera sensor - Power regulator for the front end IC Changes in v7: * Add 'depends on ARM' in Kconfig to avoid built with non-ARM arch. Changes in v6: * Add Rob Herring's review tag. * Fix a NULL pointer dereference by picking Maxime Ripard's patch. * Add Maxime Ripard's test tag. Changes in v5: * Using the new SPDX tags. * Fix MODULE_LICENSE. * Add many default cases and warning messages. * Detail the parallel bus properties * Fix some spelling and syntax mistakes. Changes in v4: * Deal with the CSI 'INNER QUEUE'. CSI will lookup the next dma buffer for next frame before the the current frame done IRQ triggered. This is not documented but reported by Ondřej Jirman. The BSP code has workaround for this too. It skip to mark the first buffer as frame done for VB2 and pass the second buffer to CSI in the first frame done ISR call. Then in second frame done ISR call, it mark the first buffer as frame done for VB2 and pass the third buffer to CSI. And so on. The bad thing is that the first buffer will be written twice and the first frame is dropped even the queued buffer is sufficient. So, I make some improvement here. Pass the next buffer to CSI just follow starting the CSI. In this case, the first frame will be stored in first buffer, second frame in second buffer. This mothed is used to avoid dropping the first frame, it would also drop frame when lacking of queued buffer. * Fix: using a wrong mbus_code when getting the supported formats * Change all fourcc to pixformat * Change some function names Changes in v3: * Get rid of struct sun6i_csi_ops * Move sun6i-csi to new directory drivers/media/platform/sunxi * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c * Use generic fwnode endpoints parser * Only support a single subdev to make things simple * Many complaintion fix Changes in v2: * Change sunxi-csi to sun6i-csi * Rebase to media_tree master branch Following is the 'v4l2-compliance -s -f' output, I have test this with both interlaced and progressive signal: # ./v4l2-compliance -s -f v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1 Driver Info: Driver name : sun6i-video Card type : sun6i-csi Bus info : platform:csi Driver version: 4.15.0 Capabilities : 0x8421 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x0421 Video Capture Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Test input 0: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (No
Re: selftests/x86/fsgsbase_64 test problem
On 01/28/18 11:21, Andy Lutomirski wrote:
>>
>> I think the bug is here. I think that, when writing a NULL selector
>> to DS, ES, FS, or GS, Intel CPUs incorrectly set DPL == RPL, whereas
>> they should set DPL to 3.
>
> As an experiment, I did this:
>
> DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = {
> + [0] = { .dpl = 3, },
> +
>
> This had no apparent effect. I was hoping that maybe loading NULL
> into a selector would copy DPL from from gdt[0], but it seems like it
> doesn't.
>
GDT[0] doesn't actually exist. It is pretty much scratch space (I have
suggested using it for the gsbase once all those issues get sorted out,
because it lets the paranoid code do something like:
rdgsbase %rax
push %rax /* Save old gsbase */
push %rax /* Reserve space on stack */
sgdt -2(%rsp) /* We don't care about the limit */
pop %rax/* %rax <- gdtbase */
mov (%rax),%rax /* GDT[0] holds the gsbase for this cpu */
wrgsbase %rax
[PATCH v7 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
Add binding documentation for Allwinner V3s CSI.
Reviewed-by: Rob Herring
Signed-off-by: Yong Deng
---
.../devicetree/bindings/media/sun6i-csi.txt| 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 000..2ff47a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,59 @@
+Allwinner V3s Camera Sensor Interface
+-
+
+Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
+interface and CSI1 is used for parallel interface.
+
+Required properties:
+ - compatible: value must be "allwinner,sun8i-v3s-csi"
+ - reg: base address and size of the memory-mapped region.
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the CSI
+* bus: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset line driving the CSI
+
+Each CSI node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. As mentioned
+above, the endpoint's bus type should be MIPI CSI-2 for CSI0 and parallel or
+Bt656 for CSI1.
+
+Endpoint node properties for CSI1
+-
+
+- remote-endpoint : (required) a phandle to the bus receiver's endpoint
+ node
+- bus-width: : (required) must be 8, 10, 12 or 16
+- pclk-sample : (optional) (default: sample on falling edge)
+- hsync-active : (only required for parallel)
+- vsync-active : (only required for parallel)
+
+Example:
+
+csi1: csi@1cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+
+ port {
+ /* Parallel bus endpoint */
+ csi1_ep: endpoint {
+ remote-endpoint = <&adv7611_ep>;
+ bus-width = <16>;
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+};
--
1.8.3.1
Re: [PATCH v2 01/16] dt-bindings: update the Allwinner GPADC device tree binding for H3 & A83T
Hi Philipp,
On Mon, Jan 29, 2018 at 12:29:04AM +0100, Philipp Rossak wrote:
> Allwinner H3 features a thermal sensor like the one in A33, but has its
> register re-arranged, the clock divider moved to CCU (originally the
> clock divider is in ADC) and added a pair of bus clock and reset.
>
> Allwinner A83T features a thermal sensor similar to the H3, the ths clock,
> the bus clock and the reset was removed from the CCU. The THS in A83T
> has a clock that is directly connected and runs with 24 MHz.
>
> Update the binding document to cover H3 and A83T.
>
> Signed-off-by: Philipp Rossak
Thanks a lot for tackling this.
> ---
> .../devicetree/bindings/mfd/sun4i-gpadc.txt| 50
> --
> 1 file changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> index 86dd8191b04c..22df0c5c23d4 100644
> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -4,12 +4,35 @@ The Allwinner SoCs all have an ADC that can also act as a
> thermal sensor
> and sometimes as a touchscreen controller.
>
> Required properties:
> - - compatible: "allwinner,sun8i-a33-ths",
> + - compatible: must contain one of the following compatibles:
> + - "allwinner,sun8i-a33-ths"
> + - "allwinner,sun8i-h3-ths"
> + - "allwinner,sun8i-a83t-ths"
>- reg: mmio address range of the chip,
> - - #thermal-sensor-cells: shall be 0,
> + - #thermal-sensor-cells: shall be 0 or 1,
>- #io-channel-cells: shall be 0,
>
> -Example:
> +Required properties for the following compatibles:
> + - "allwinner,sun8i-h3-ths"
> + - "allwinner,sun8i-a83t-ths"
> + - interrupts: the sampling interrupt of the ADC,
> +
> +Required properties for the following compatibles:
> + - "allwinner,sun8i-h3-ths"
> + - clocks: the bus clock and the input clock of the ADC,
> + - clock-names: should be "bus" and "mod",
> + - resets: the bus reset of the ADC,
> +
> +Optional properties for the following compatibles:
> + - "allwinner,sun8i-h3-ths"
> + - nvmem-cells: A phandle to the calibration data provided by a nvmem
> device.
> + If unspecified default values shall be used. The size should
> + be 0x2 * sensorcount.
> + - nvmem-cell-names: Should be "calibration".
> +
> +Details see: bindings/nvmem/nvmem.txt
> +
> +Example for A33:
> ths: ths@1c25000 {
> compatible = "allwinner,sun8i-a33-ths";
> reg = <0x01c25000 0x100>;
> @@ -17,6 +40,27 @@ Example:
> #io-channel-cells = <0>;
> };
>
> +Example for H3:
> + ths: thermal-sensor@1c25000 {
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x400>;
> + clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
> + clock-names = "bus", "mod";
> + resets = <&ccu RST_BUS_THS>;
> + interrupts = ;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
> +Example for A83T:
> + ths: thermal-sensor@1f04000 {
> + compatible = "allwinner,sun8i-a83t-ths";
> + reg = <0x01f04000 0x100>;
> + interrupts = ;
> + #thermal-sensor-cells = <1>;
> + #io-channel-cells = <0>;
> + };
> +
I'm wondering if this is actually needed. We've used this convoluted
constructs to be compatible with the old driver, but I'm not sure this
is actually worth it now, and this is causing several issues, among
which:
- We need to have a bunch of quirks to handle all the DT cases.
- We need to have an MFD, which isn't really optimal
So I'd rather introduce a new compatible for the old SoCs, keep the
old driver around, and simplify a lot that driver code that will ease
further developments. And we can also get rid of the MFD in the
process. I discussed it with Quentin, and he was ok with it, what do
you think?
(and that would involve creating a new file for the bindings you
introduce here).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v2 02/16] arm: config: sunxi_defconfig: enable SUN4I_GPADC
Hi, On Mon, Jan 29, 2018 at 12:29:05AM +0100, Philipp Rossak wrote: > This commit enables the SUN4I_GPADC config option and > sets the value to yes. This is needed to enable the ths sensors. > > Signed-off-by: Philipp Rossak > --- > arch/arm/configs/sunxi_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/sunxi_defconfig > b/arch/arm/configs/sunxi_defconfig > index 5caaf971fb50..52c3990b9d91 100644 > --- a/arch/arm/configs/sunxi_defconfig > +++ b/arch/arm/configs/sunxi_defconfig > @@ -131,6 +131,7 @@ CONFIG_DMA_SUN6I=y > CONFIG_EXTCON=y > CONFIG_IIO=y > CONFIG_AXP20X_ADC=y > +CONFIG_SUN4I_GPADC=y Unfortunately, we can't do that since TOUCHSCREEN_SUN4I is already enabled and we have a depends on !TOUCHSCREEN_SUN4I. One more reason to stop worrying about replacing that driver DT binding. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.
Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
interface and CSI1 is used for parallel interface. This is not
documented in datasheet but by test and guess.
This patch implement a v4l2 framework driver for it.
Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.
Tested-by: Maxime Ripard
Signed-off-by: Yong Deng
---
MAINTAINERS| 8 +
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile| 2 +
drivers/media/platform/sunxi/sun6i-csi/Kconfig | 10 +
drivers/media/platform/sunxi/sun6i-csi/Makefile| 3 +
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 908 +
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 143
.../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 196 +
.../media/platform/sunxi/sun6i-csi/sun6i_video.c | 753 +
.../media/platform/sunxi/sun6i-csi/sun6i_video.h | 53 ++
10 files changed, 2077 insertions(+)
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
diff --git a/MAINTAINERS b/MAINTAINERS
index aee793b..1c9f296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,6 +3774,14 @@ M: Jaya Kumar
S: Maintained
F: sound/pci/cs5535audio/
+CSI DRIVERS FOR ALLWINNER V3s
+M: Yong Deng
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/sunxi/sun6i-csi/
+F: Documentation/devicetree/bindings/media/sun6i-csi.txt
+
CW1200 WLAN driver
M: Solomon Peachy
S: Maintained
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 614fbef..82c9e00 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -150,6 +150,7 @@ source "drivers/media/platform/am437x/Kconfig"
source "drivers/media/platform/xilinx/Kconfig"
source "drivers/media/platform/rcar-vin/Kconfig"
source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 7f30804..ace8628 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -95,3 +95,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
obj-y += meson/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sunxi/sun6i-csi/
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig
b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
new file mode 100644
index 000..f80c965
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
@@ -0,0 +1,10 @@
+config VIDEO_SUN6I_CSI
+ tristate "Allwinner V3s Camera Sensor Interface driver"
+ depends on ARM
+ depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select VIDEOBUF2_DMA_CONTIG
+ select REGMAP_MMIO
+ select V4L2_FWNODE
+ ---help---
+ Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Makefile
b/drivers/media/platform/sunxi/sun6i-csi/Makefile
new file mode 100644
index 000..213cb6b
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_video.o sun6i_csi.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
new file mode 100644
index 000..9c341f0
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,908 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2011-2018 Magewell Electronics Co., Ltd. (Nanjing)
+ * All rights reserved.
+ * Author: Yong Deng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sun6i_csi.h"
+#include "sun6i_csi_reg.h"
+
+#define MODULE_NAME"sun6i-csi"
+
+struct sun6i_csi_dev {
+ struct sun6i_csicsi;
+ struct device *dev;
+
+ struct regmap *regmap;
+ struct clk *clk_mod;
+
Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism
On Thu, 2017-12-21 at 18:15 -0800, Stephen Boyd wrote: > On 12/19, Michael Turquette wrote: > > Quoting Jerome Brunet (2017-12-01 13:51:50) > > > This Patchset is related the RFC [0] and the discussion around > > > CLK_SET_RATE_GATE available here [1] > > > > > > This patchset introduce clock protection to the CCF core. This can then > > > be used for: > > > > > > * Provide a way for a consumer to claim exclusivity over the rate control > > > of a provider. Some clock consumers require that a clock rate must not > > > deviate from its selected frequency. There can be several reasons for > > > this, not least of which is that some hardware may not be able to > > > handle or recover from a glitch caused by changing the clock rate while > > > the hardware is in operation. For such HW, The ability to get exclusive > > > control of a clock's rate, and release that exclusivity, could be seen > > > as a fundamental clock rate control primitive. The exclusivity is not > > > preemptible, so when claimed more than once, is rate is effectively > > > locked. > > > > > > * Provide a similar functionality to providers themselves, fixing > > > CLK_SET_RATE_GATE flag (enforce clock gating along the tree). While > > > there might still be a few platforms relying the broken implementation, > > > tests done has shown this change to be pretty safe. > > > > Applied to clk-protect-rate, with the exception that I did not apply > > "clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks > > qcom clk code. > > > > Stephen, do you plan to fix up the qcom clock code so that the > > SET_RATE_GATE improvement can go in? > > > > I started working on it a while back. Let's see if I can finish > it off this weekend. > Hi Stephen, Have you been able find something to fix the qcom code regarding this issue ? Cheers Jerome
[PATCH v4 0/2] perf stat: Add interval-count and time support
From: yuzhoujian Introduce two new options for perf stat and update perf-stat documentation accordingly. The interval-count option can be used to print counts for fixed number of times, and it should be used specifically with "-I" option. Show below is the output of the interval-count option for perf stat. $ perf stat -I 1000 --interval-count 2 -e cycles -a # time counts unit events 1.002827089 93,884,870 cycles 2.004231506 56,573,446 cycles The time option can be used to print counts after a period of time, and it should not be used with "-I" option. Show below is the output of the time option for perf stat. $ perf stat --time 2000 -e cycles -a Performance counter stats for 'system wide': 157,260,423 cycles 2.003060766 seconds time elapsed yuzhoujian (2): perf stat: Add support to print counts for fixed times perf stat: Add support to print counts after a period of time Changes since v3: - merge interval_count check and times check to one line. - fix the wrong indent in stat.h - use stat_config.times instead of 'times' in cmd_stat function. Changes since v2: - modify the time check in __run_perf_stat func to keep some consistency with the workload case. - add the warning when the time is set between 10ms to 100ms. - add the pr_err when the time is set below 10ms. Changes since v1: - change the name of the new option "times-print" to "interval-count". - keep the interval-count option interval specifically. tools/perf/Documentation/perf-stat.txt | 10 +++ tools/perf/builtin-stat.c | 53 -- tools/perf/util/stat.h | 2 ++ 3 files changed, 62 insertions(+), 3 deletions(-) -- 2.14.1
Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.
On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard
wrote:
> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote:
>> > +void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
>> > +{
>> > + struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
>> > + /* transform physical address to bus address */
>> > + dma_addr_t bus_addr = addr - PHYS_OFFSET;
>>
>> I am sorry if this is an unjustified drive-by comment. Maybe you
>> have already investigate other ways to do this.
>
> It's definitely not unjustified :)
>
>> Accessing PHYS_OFFSET directly seems unintuitive and not good
>> practice.
>>
>> But normally an dma_addr_t only comes from some function inside
>> such as: dma_alloc_coherent() for a contigous
>> buffer which is coherent in physical memory, or from some buffer <=
>> 64KB that is switching ownership between device and CPU explicitly
>> with dma_map* or so. Did you check with Documentation/DMA-API.txt?
>
> So, I've discussed this with Arnd a month ago or so, because I'm not
> really fond of the current approach but we haven't found better way to
> do it yet.
>
> The issue is that all the DMA accesses are done not through the main
> AXI bus, but through a separate bus dedicated for memory accesses,
> where the RAM is mapped at the address 0. So the CPU and DMA devices
> have a different mapping for the RAM.
Aha, I see the problem ... but since the dma_addr_t is supposed
to actually be the address the DMA controller sees, something is
apparently broken.
> I guess we could address this by using the field dma_pfn_offset that
> seems to be used in similar situations.
That does seem like the right thing to do (to me).
> However, in DT systems, that
> field is filled only with the parent's node dma-ranges property. In
> our case, and since the DT parenthood is based on the "control" bus,
> and not the "data" bus, our parent node would be the AXI bus, and not
> the memory bus that enforce those constraints.
>
> And other devices doing DMA through regular DMA accesses won't have
> that mapping, so we definitely shouldn't enforce it for all the
> devices there, but only the one connected to the separate memory bus.
>
> tl; dr: the DT is not really an option to store that info.
>
> I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too
> fond of that approach either at the time.
>
> So, well, I guess we could do better. We just have no idea how :)
Usually of Arnd cannot suggest something smart, neither can I :(
If some aspect of the memory layout of the system *really* doesn't
fit into DT because of the assumptions that DT is doing about
how systems work, we have a problem.
Is the problem that DT's model assumes that devices have one and
only one data port to the system memory, and that is how it
populates the Linux devices?
I guess, if nothing else works, I would use auxdata in the board file.
It is our definitive last resort when DT doesn't hold.
I.e. I would go into struct of_dev_auxdata
(from ) and add a
dma_pfn_offset field that gets set into the device's dma_pfn_offset
in drivers/of/platform.c overriding anything else and use that to hammer
it down in the boardfile.
But I bet some DT people are going to have other ideas.
Yours,
Linus Walleij
[PATCH v4 2/2] perf stat: Add support to print counts after a period of time
From: yuzhoujian
Introduce a new option to print counts after N milliseconds
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$ perf stat --time 2000 -e cycles -a
Performance counter stats for 'system wide':
157,260,423 cycles
2.003060766 seconds time elapsed
We can print the count deltas after N milliseconds with this new
introduced option. This option is not supported with "-I" option.
In addition, according to Kangliang's patch(19afd10410957), the
monitoring overhead for system-wide core event could be very high
if the interval-print parameter was below 100ms, and the limitation
value is 10ms. So the same warning will be displayed when the time
is set between 10ms to 100ms, and the minimal time is limited to
10ms. Users can make a decision according to their spcific cases.
Changes since v3:
- none.
Changes since v2:
- modify the time check in __run_perf_stat func to keep some consistency
with the workload case.
- add the warning when the time is set between 10ms to 100ms.
- add the pr_err when the time is set below 10ms.
Changes since v1:
- none.
Signed-off-by: yuzhoujian
---
tools/perf/Documentation/perf-stat.txt | 5 +
tools/perf/builtin-stat.c | 33 +++--
tools/perf/util/stat.h | 1 +
3 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 47a21645f60c..c822f374c99a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -151,6 +151,11 @@ Print count deltas for fixed number of times.
This option should be used together with "-I" option.
example: 'perf stat -I 1000 --interval-count 2 -e cycles -a'
+--time msecs::
+Print count deltas after N milliseconds (minimum: 10 ms).
+This option is not supported with "-I" option.
+ example: 'perf stat --time 2000 -e cycles -a'
+
--metric-only::
Only print computed metrics. Print them in a single line.
Don't show any raw values. Not supported with --per-thread.
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 7d1d7613bf56..582db3897374 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -573,6 +573,7 @@ static int __run_perf_stat(int argc, const char **argv)
{
int interval = stat_config.interval;
int times = stat_config.times;
+ int time = stat_config.time;
char msg[BUFSIZ];
unsigned long long t0, t1;
struct perf_evsel *counter;
@@ -586,6 +587,9 @@ static int __run_perf_stat(int argc, const char **argv)
if (interval) {
ts.tv_sec = interval / USEC_PER_MSEC;
ts.tv_nsec = (interval % USEC_PER_MSEC) * NSEC_PER_MSEC;
+ } else if (time) {
+ ts.tv_sec = time / USEC_PER_MSEC;
+ ts.tv_nsec = (time % USEC_PER_MSEC) * NSEC_PER_MSEC;
} else {
ts.tv_sec = 1;
ts.tv_nsec = 0;
@@ -698,9 +702,11 @@ static int __run_perf_stat(int argc, const char **argv)
perf_evlist__start_workload(evsel_list);
enable_counters();
- if (interval) {
+ if (interval || time) {
while (!waitpid(child_pid, &status, WNOHANG)) {
nanosleep(&ts, NULL);
+ if (time)
+ break;
process_interval();
if (interval_count && !(--times))
break;
@@ -720,6 +726,8 @@ static int __run_perf_stat(int argc, const char **argv)
enable_counters();
while (!done) {
nanosleep(&ts, NULL);
+ if (time)
+ break;
if (interval) {
process_interval();
if (interval_count && !(--times))
@@ -1900,6 +1908,8 @@ static const struct option stat_options[] = {
"print counts at regular interval in ms (>= 10)"),
OPT_INTEGER(0, "interval-count", &stat_config.times,
"print counts for fixed number of times"),
+ OPT_UINTEGER(0, "time", &stat_config.time,
+ "print counts after a period of time in ms (>= 10)"),
OPT_SET_UINT(0, "per-socket", &stat_config.aggr_mode,
"aggregate counts per processor socket", AGGR_SOCKET),
OPT_SET_UINT(0, "per-core", &stat_config.aggr_mode,
@@ -2697,7 +2707,7 @@ int cmd_stat(int argc, const char **argv)
int status = -EINVAL, run_idx;
const char *mode;
FILE *output = stderr;
- unsigned int interval;
+ unsigned int interval, time;
const char * const stat_subc
[PATCH v4 1/2] perf stat: Add support to print counts for fixed times
From: yuzhoujian
Introduce a new option to print counts for fixed number of times
and update perf-stat documentation accordingly.
Show below is the output of the new option for perf stat.
$ perf stat -I 1000 --interval-count 2 -e cycles -a
# time counts unit events
1.002827089 93,884,870 cycles
2.004231506 56,573,446 cycles
We can just print the counts for several times with this newly introduced
option. The usage of it is a little like vmstat, and it should be used
together with "-I" option.
$ vmstat -n 1 2
procs ---memory-- ---swap-- -io -system-- --cpu-
r b swpd free buff cache si sobibo in cs us sy id wa st
0 0 0 78270544 547484 5173207600 02011 1 0 99
0 0
0 0 0 78270512 547484 5173208000 016 477 1555 0 0 100
0 0
Changes since v3:
- merge interval_count check and times check to one line.
- fix the wrong indent in stat.h
- use stat_config.times instead of 'times' in cmd_stat function.
Changes since v2:
- none.
Changes since v1:
- change the name of the new option "times-print" to "interval-count".
- keep the new option interval specifically.
Signed-off-by: yuzhoujian
---
tools/perf/Documentation/perf-stat.txt | 5 +
tools/perf/builtin-stat.c | 20 +++-
tools/perf/util/stat.h | 1 +
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 823fce7674bb..47a21645f60c 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -146,6 +146,11 @@ Print count deltas every N milliseconds (minimum: 10ms)
The overhead percentage could be high in some cases, for instance with small,
sub 100ms intervals. Use with caution.
example: 'perf stat -I 1000 -e cycles -a sleep 5'
+--interval-count times::
+Print count deltas for fixed number of times.
+This option should be used together with "-I" option.
+ example: 'perf stat -I 1000 --interval-count 2 -e cycles -a'
+
--metric-only::
Only print computed metrics. Print them in a single line.
Don't show any raw values. Not supported with --per-thread.
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 98bf9d32f222..7d1d7613bf56 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -168,6 +168,7 @@ static struct timespec ref_time;
static struct cpu_map *aggr_map;
static aggr_get_id_t aggr_get_id;
static boolappend_file;
+static boolinterval_count;
static const char *output_name;
static int output_fd;
static int print_free_counters_hint;
@@ -571,6 +572,7 @@ static struct perf_evsel
*perf_evsel__reset_weak_group(struct perf_evsel *evsel)
static int __run_perf_stat(int argc, const char **argv)
{
int interval = stat_config.interval;
+ int times = stat_config.times;
char msg[BUFSIZ];
unsigned long long t0, t1;
struct perf_evsel *counter;
@@ -700,6 +702,8 @@ static int __run_perf_stat(int argc, const char **argv)
while (!waitpid(child_pid, &status, WNOHANG)) {
nanosleep(&ts, NULL);
process_interval();
+ if (interval_count && !(--times))
+ break;
}
}
waitpid(child_pid, &status, 0);
@@ -716,8 +720,11 @@ static int __run_perf_stat(int argc, const char **argv)
enable_counters();
while (!done) {
nanosleep(&ts, NULL);
- if (interval)
+ if (interval) {
process_interval();
+ if (interval_count && !(--times))
+ break;
+ }
}
}
@@ -1891,6 +1898,8 @@ static const struct option stat_options[] = {
"command to run after to the measured command"),
OPT_UINTEGER('I', "interval-print", &stat_config.interval,
"print counts at regular interval in ms (>= 10)"),
+ OPT_INTEGER(0, "interval-count", &stat_config.times,
+ "print counts for fixed number of times"),
OPT_SET_UINT(0, "per-socket", &stat_config.aggr_mode,
"aggregate counts per processor socket", AGGR_SOCKET),
OPT_SET_UINT(0, "per-core", &stat_config.aggr_mode,
@@ -2870,6 +2879,15 @@ int cmd_stat(int argc, const char **argv)
"The overhead percentage could be high in
some cases. "
Re: [PATCH v2 04/16] iio: adc: sun4i-gpadc-iio: rework: sampling start/end code readout reg
Hi,
On Mon, Jan 29, 2018 at 12:29:07AM +0100, Philipp Rossak wrote:
> For adding newer sensor some basic rework of the code is necessary.
>
> This commit reworks the code and allows the sampling start/end code and
> the position of value readout register to be altered. Later the start/end
> functions will be used to configure the ths and start/stop the
> sampling.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Philipp Rossak
That signed-off-by chain doesn't really make much sense. If Icenowy is
the author, she should be reported as such in the commit, and if
you're the author, you shouldn't have her Signed-off-by.
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 44
> ++-
> 1 file changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 03804ff9c006..db57d9fffe48 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -49,6 +49,15 @@ static unsigned int sun6i_gpadc_chan_select(unsigned int
> chan)
> return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
> }
>
> +struct sun4i_gpadc_iio;
> +
> +/*
> + * Prototypes for these functions, which enable these functions to be
> + * referenced in gpadc_data structures.
> + */
> +static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
> +static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
> +
> struct gpadc_data {
> int temp_offset;
> int temp_scale;
> @@ -56,6 +65,9 @@ struct gpadc_data {
> unsigned inttp_adc_select;
> unsigned int(*adc_chan_select)(unsigned int chan);
> unsigned intadc_chan_mask;
> + unsigned inttemp_data;
> + int (*sample_start)(struct sun4i_gpadc_iio *info);
> + int (*sample_end)(struct sun4i_gpadc_iio *info);
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -65,6 +77,9 @@ static const struct gpadc_data sun4i_gpadc_data = {
> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun4i_gpadc_chan_select,
> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> + .temp_data = SUN4I_GPADC_TEMP_DATA,
You can use a regmap_field there.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v2 05/16] iio: adc: sun4i-gpadc-iio: rework: support clocks and reset
On Mon, Jan 29, 2018 at 12:29:08AM +0100, Philipp Rossak wrote:
> For adding newer sensor some basic rework of the code is necessary.
>
> The SoCs after H3 has newer thermal sensor ADCs, which have two clock
> inputs (bus clock and sampling clock) and a reset. The registers are
> also re-arranged.
>
> This commit reworks the code, adds the process of the clocks and
> resets.
>
> Signed-off-by: Philipp Rossak
> Signed-off-by: Icenowy Zheng
Same remark for the SoB
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 71
> +++
> 1 file changed, 71 insertions(+)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index db57d9fffe48..51ec0104d678 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -22,6 +22,7 @@
> * shutdown for not being used.
> */
>
> +#include
> #include
> #include
> #include
> @@ -31,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -68,6 +70,9 @@ struct gpadc_data {
> unsigned inttemp_data;
> int (*sample_start)(struct sun4i_gpadc_iio *info);
> int (*sample_end)(struct sun4i_gpadc_iio *info);
> + boolhas_bus_clk;
> + boolhas_bus_rst;
> + boolhas_mod_clk;
Is there SoCs where this insn't all true, or all false?
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -127,6 +132,9 @@ struct sun4i_gpadc_iio {
> atomic_tignore_temp_data_irq;
> const struct gpadc_data *data;
> boolno_irq;
> + struct clk *bus_clk;
> + struct clk *mod_clk;
> + struct reset_control*reset;
> /* prevents concurrent reads of temperature and ADC */
> struct mutexmutex;
> struct thermal_zone_device *tzd;
> @@ -420,6 +428,10 @@ static int sun4i_gpadc_runtime_suspend(struct device
> *dev)
> {
> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>
> + clk_disable(info->mod_clk);
> +
Why clk_disable?
> + clk_disable(info->bus_clk);
> +
You can tie the bus_clk to the regmap directly, instead of having to
maintain it yourself here.
And you can probably put the device in reset and out of reset here as
well.
> return info->data->sample_end(info);
> }
>
> @@ -446,6 +458,10 @@ static int sun4i_gpadc_runtime_resume(struct device *dev)
> {
> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>
> + clk_enable(info->mod_clk);
> +
> + clk_enable(info->bus_clk);
> +
> return info->data->sample_start(info);
> }
>
> @@ -560,10 +576,59 @@ static int sun4i_gpadc_probe_dt(struct platform_device
> *pdev,
> return ret;
> }
>
> + if (info->data->has_bus_rst) {
> + info->reset = devm_reset_control_get(&pdev->dev, NULL);
> + if (IS_ERR(info->reset)) {
> + ret = PTR_ERR(info->reset);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(info->reset);
> + if (ret)
> + return ret;
> + }
> +
> + if (info->data->has_bus_clk) {
> + info->bus_clk = devm_clk_get(&pdev->dev, "bus");
> + if (IS_ERR(info->bus_clk)) {
> + ret = PTR_ERR(info->bus_clk);
> + goto assert_reset;
> + }
> +
> + ret = clk_prepare_enable(info->bus_clk);
> + if (ret)
> + goto assert_reset;
> + }
> +
> + if (info->data->has_mod_clk) {
> + info->mod_clk = devm_clk_get(&pdev->dev, "mod");
> + if (IS_ERR(info->mod_clk)) {
> + ret = PTR_ERR(info->mod_clk);
> + goto disable_bus_clk;
> + }
> +
> + /* Running at 6MHz */
> + ret = clk_set_rate(info->mod_clk, 400);
Your comment and the line below doesn't really make much sense :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [0/2] RDMA/bnxt_re: Adjustments for bnxt_qplib_alloc_dpi_tbl()
> You don't need 2 patches when changing same lines of code. Are these really the same? > Could you squash both and send your changes in a single patch. I prefer to keep the deletion of questionable error messages separate from the refactoring for a bit of exception handling. > The patches look good to me otherwise. Thanks for your constructive feedback. Regards, Markus
Re: mfd: Patch management?
On Fri, 26 Jan 2018, SF Markus Elfring wrote: > >> I am curious if more positive feedback could evolve till then. > >> I would appreciate if a potentially needed resend for my selection > >> of update suggestions could become smaller (when reviewed steps > >> could be already integrated for example). > > > > I'm not entirely sure what you're trying to say, > > in any of your responses. > > I imagine that acceptance for these changes could be influenced > also by review comments from other contributors. Influenced yes, but I will also need to review them. You can't 'go around' me, if that's what you're thinking. > > If you want to rebase your patches, to see what has been applied and > > what hasn't, you can use the MFD repo and its next-next branch. > > https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next-next > > How are the chances that further update suggestions will be integrated > just because I sent them as small patch series in the threaded way? > > Examples: > * tps65910: Adjustments for four function implementations > https://lkml.org/lkml/2018/1/16/313 > > * abx500-core: Adjustments for eight function implementations > https://lkml.org/lkml/2018/1/16/186 In order to not make my life difficult, I've kindly requested that you gather all of your MFD patches and send them as one single set. Is there a good reason why you're not willing to do so? -- Lee Jones Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[GIT PULL] mtd: Changes for 4.16
Hi Linus,
Here is the MTD PR for 4.16.
Regards,
Boris
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.infradead.org/linux-mtd.git tags/mtd/for-4.16
for you to fetch changes up to 571cb17b23eccc22f18c4fc0a0fc34cf0abca7ef:
Merge tag 'nand/for-4.16' of git://git.infradead.org/linux-mtd into mtd/next
(2018-01-29 09:58:36 +0100)
MTD changes:
Core changes:
* Rework core functions to avoid duplicating generic checks in
NAND/OneNAND sub-layers
* Update the MAINTAINERS entry to reflect the fact that MTD
maintainers now use a single git tree
Driver changes:
* CFI: use macros instead of inline functions to limit stack
usage and make KASAN happy
NAND changes:
Core changes:
* Fix NAND_CMD_NONE handling in nand_command[_lp]() hooks
* Introduce the ->exec_op() infrastructure
* Rework NAND buffers handling
* Fix ECC requirements for K9F4G08U0D
* Fix nand_do_read_oob() to return the number of bitflips
* Mark K9F1G08U0E as not supporting subpage writes
Driver changes:
* MTK: Rework the driver to support new IP versions
* OMAP OneNAND: Full rework to use new APIs (libgpio, dmaengine) and fix
DT support
* Marvell: Add a new driver to replace the pxa3xx one
SPI NOR changes:
Core changes:
* Add support to new ISSI and Cypress/Spansion memory parts.
* Fix support of Micron memories by checking error bits in the FSR.
* Fix update of block-protection bits by reading back the SR.
* Restore the internal state of the SPI flash memory when removing the
device.
Driver changes:
* Maintenance for Freescale, Intel and Metiatek drivers.
* Add support of the direct access mode for the Cadence QSPI controller.
Aaron Sierra (1):
mtd: spi-nor: Check that BP bits are set properly
Angelo Dureghello (1):
mtd: spi-nor: add support for ISSI is25lp128
Antonio Borneo (1):
mtd: mchp23k256: propagate return value of spi_sync()
Arnd Bergmann (2):
mtd: cfi: convert inline functions to macros
mtd: onenand: omap2: print resource using %pR format string
Bean Huo (beanhuo) (1):
mtd: spi-nor: check FSR error bits for Micron memories
Boris Brezillon (15):
mtd: nand: hynix: Don't wait after applying new read-retry params
mtd: nand: provide several helpers to do common NAND operations
mtd: nand: force drivers to explicitly send READ/PROG commands
mtd: nand: denali: Avoid using ecc->code_buf as a temporary buffer
mtd: nand: Only allocate ecc->{calc, code}_buf when actually needed
MAINTAINERS: Move all MTD related branches to a single repo
mtd: Do not allow MTD devices with inconsistent erase properties
mtd: Add an helper to make erase request aligned on ->erasesize
Merge tag 'gpmc-omap-for-v4.16-immutable' of
https://github.com/rogerq/linux into nand/next
mtd: mtdpart: Make ECC stat handling consistent
mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
mtd: Remove duplicate checks on mtd_oob_ops parameter
mtd: nand: gpmi: Fix subpage reads
Merge tag 'spi-nor/for-4.16' of git://git.infradead.org/linux-mtd into
mtd/next
Merge tag 'nand/for-4.16' of git://git.infradead.org/linux-mtd into
mtd/next
Christophe JAILLET (5):
mtd: onenand: samsung: use devm_ function to simplify code and fix some
leaks
mtd: onenand: samsung: return an error if 'mtd_device_parse_register()'
fails
mtd: onenand: samsung: Propagate the error returned by 'onenand_scan()'
mtd: onenand: samsung: Remove a useless include
mtd: onenand: samsung: remove incorrect __iomem annotation
Colin Ian King (4):
mtd: mtdswap: make array 'name' static const, shrinks object size
mtd: sharpslpart: fix overflow on block_adr calculation
mtd: nand: marvell: fix spelling mistake: "suceed"-> "succeed"
mtd: nand: marvell: remove redundant variable 'oob_len'
Fabio Estevam (3):
dt-bindings: mtd: fsl-quadspi: Pass the qspi clock names
mtd: nand: brcmnand: Add a NULL check for devm_kasprintf()
mtd: nand: qcom: Add a NULL check for devm_kasprintf()
Guochun Mao (1):
mtd: mtk-nor: modify functions' name more generally
Gustavo A. R. Silva (1):
mtd: nand: gpmi: replace _manual_ swap with swap macro
Hou Zhiqiang (2):
mtd: spi-nor: add an API to restore the status of SPI flash chip
mtd: m25p80: restore the status of SPI flash when exiting
Jagdish Gediya (1):
mtd: nand: ifc: update bufnum mask for ver >= 2.0.0
Jesse Chan (1):
mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Julia Lawall (1):
mtd: fsl-quadspi: account for const type of of_device_id.data
Kamal Dasu (1):
mtd: nand: brcmnand: Disable
Re: [PATCH 14/14] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
On 28/01/18 23:08, Ard Biesheuvel wrote:
> On 26 January 2018 at 14:28, Marc Zyngier wrote:
>> Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.
>> It is lovely. Really.
>>
>> Signed-off-by: Marc Zyngier
>> ---
>> arch/arm64/kernel/bpi.S| 20
>> arch/arm64/kernel/cpu_errata.c | 71
>> +-
>> 2 files changed, 90 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
>> index 76225c2611ea..add7e08a018d 100644
>> --- a/arch/arm64/kernel/bpi.S
>> +++ b/arch/arm64/kernel/bpi.S
>> @@ -17,6 +17,7 @@
>> */
>>
>> #include
>> +#include
>>
>> .macro ventry target
>> .rept 31
>> @@ -85,3 +86,22 @@ ENTRY(__qcom_hyp_sanitize_link_stack_start)
>> .endr
>> ldp x29, x30, [sp], #16
>> ENTRY(__qcom_hyp_sanitize_link_stack_end)
>> +
>> +.macro smccc_workaround_1 inst
>> + sub sp, sp, #(8 * 4)
>> + stp x2, x3, [sp, #(16 * 0)]
>> + stp x0, x1, [sp, #(16 * 1)]
>> + orr w0, wzr, #ARM_SMCCC_ARCH_WORKAROUND_1
>> + \inst #0
>> + ldp x2, x3, [sp, #(16 * 0)]
>> + ldp x0, x1, [sp, #(16 * 1)]
>> + add sp, sp, #(8 * 4)
>> +.endm
>> +
>> +ENTRY(__smccc_workaround_1_smc_start)
>> + smccc_workaround_1 smc
>> +ENTRY(__smccc_workaround_1_smc_end)
>> +
>> +ENTRY(__smccc_workaround_1_hvc_start)
>> + smccc_workaround_1 hvc
>> +ENTRY(__smccc_workaround_1_hvc_end)
>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>> index ed6881882231..f1501873f2e4 100644
>> --- a/arch/arm64/kernel/cpu_errata.c
>> +++ b/arch/arm64/kernel/cpu_errata.c
>> @@ -70,6 +70,10 @@ DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data,
>> bp_hardening_data);
>> extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
>> extern char __qcom_hyp_sanitize_link_stack_start[];
>> extern char __qcom_hyp_sanitize_link_stack_end[];
>> +extern char __smccc_workaround_1_smc_start[];
>> +extern char __smccc_workaround_1_smc_end[];
>> +extern char __smccc_workaround_1_hvc_start[];
>> +extern char __smccc_workaround_1_hvc_end[];
>>
>> static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
>> const char *hyp_vecs_end)
>> @@ -116,6 +120,10 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t
>> fn,
>> #define __psci_hyp_bp_inval_endNULL
>> #define __qcom_hyp_sanitize_link_stack_start NULL
>> #define __qcom_hyp_sanitize_link_stack_end NULL
>> +#define __smccc_workaround_1_smc_start NULL
>> +#define __smccc_workaround_1_smc_end NULL
>> +#define __smccc_workaround_1_hvc_start NULL
>> +#define __smccc_workaround_1_hvc_end NULL
>>
>> static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
>> const char *hyp_vecs_start,
>> @@ -142,17 +150,78 @@ static void install_bp_hardening_cb(const struct
>> arm64_cpu_capabilities *entry,
>> __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
>> }
>>
>> +#include
>> +#include
>> #include
>>
>> +static void call_smc_arch_workaround_1(void)
>> +{
>> + register int w0 asm("w0") = ARM_SMCCC_ARCH_WORKAROUND_1;
>> + asm volatile("smc #0\n"
>> +: "+r" (w0));
>> +}
>> +
>> +static void call_hvc_arch_workaround_1(void)
>> +{
>> + register int w0 asm("w0") = ARM_SMCCC_ARCH_WORKAROUND_1;
>> + asm volatile("hvc #0\n"
>> +: "+r" (w0));
>> +}
>> +
>> +static bool check_smccc_arch_workaround_1(const struct
>> arm64_cpu_capabilities *entry)
>> +{
>> + bp_hardening_cb_t cb;
>> + void *smccc_start, *smccc_end;
>> + struct arm_smccc_res res;
>> +
>> + if (psci_ops.variant == SMCCC_VARIANT_1_0)
>> + return false;
>> +
>> + switch (psci_ops.conduit) {
>> + case PSCI_CONDUIT_HVC:
>> + arm_smccc_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>> + ARM_SMCCC_ARCH_WORKAROUND_1, 0, 0, 0, 0, 0, 0,
>> + &res);
>> + if (res.a0)
>> + return false;
>> + cb = call_hvc_arch_workaround_1;
>> + smccc_start = __smccc_workaround_1_hvc_start;
>> + smccc_end = __smccc_workaround_1_hvc_end;
>> + break;
>> +
>> + case PSCI_CONDUIT_SMC:
>> + arm_smccc_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>> + ARM_SMCCC_ARCH_WORKAROUND_1, 0, 0, 0, 0, 0, 0,
>> + &res);
>
> This compiles to
>
> 4a8: 928fffe1mov x1, #0x8000 // #-32768
> 4ac: b26187e0mov x0, #0x8001 //
> #-2147483647
> 4b0: d287mov x7, #0x0// #0
> 4b4: d286mov x6, #0x0
Re: [PATCH v2 06/16] iio: adc: sun4i-gpadc-iio: rework: support multiple sensors
Hi,
On Mon, Jan 29, 2018 at 12:29:09AM +0100, Philipp Rossak wrote:
> For adding newer sensor some basic rework of the code is necessary.
>
> This patch reworks the driver to be able to handle more than one
> thermal sensor. Newer SoC like the A80 have 4 thermal sensors.
> Because of this the maximal sensor count value was set to 4.
>
> The sensor_id value is set during sensor registration and is for each
> registered sensor indiviual. This makes it able to differntiate the
> sensors when the value is read from the register.
>
> In function sun4i_gpadc_read_raw(), the sensor number of the ths sensor
> was directly set to 0 (sun4i_gpadc_temp_read(x,x,0)). This selects
> in the temp_read function automatically sensor 0. A check for the
> sensor_id is here not required since the old sensors only have one
> thermal sensor. In addition to that is the sun4i_gpadc_read_raw()
> function only used by the "older" sensors (before A33) where the
> thermal sensor was a cobination of an adc and a thermal sensor.
>
> Signed-off-by: Philipp Rossak
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 36 +++-
> include/linux/mfd/sun4i-gpadc.h | 3 +++
> 2 files changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 51ec0104d678..ac9ad2f8232f 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -67,12 +67,13 @@ struct gpadc_data {
> unsigned inttp_adc_select;
> unsigned int(*adc_chan_select)(unsigned int chan);
> unsigned intadc_chan_mask;
> - unsigned inttemp_data;
> + unsigned inttemp_data[MAX_SENSOR_COUNT];
> int (*sample_start)(struct sun4i_gpadc_iio *info);
> int (*sample_end)(struct sun4i_gpadc_iio *info);
> boolhas_bus_clk;
> boolhas_bus_rst;
> boolhas_mod_clk;
> + int sensor_count;
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -82,9 +83,10 @@ static const struct gpadc_data sun4i_gpadc_data = {
> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun4i_gpadc_chan_select,
> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> static const struct gpadc_data sun5i_gpadc_data = {
> @@ -94,9 +96,10 @@ static const struct gpadc_data sun5i_gpadc_data = {
> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun4i_gpadc_chan_select,
> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> static const struct gpadc_data sun6i_gpadc_data = {
> @@ -106,18 +109,20 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun6i_gpadc_chan_select,
> .adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> .temp_offset = -1662,
> .temp_scale = 162,
> .tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> struct sun4i_gpadc_iio {
> @@ -135,6 +140,7 @@ struct sun4i_gpadc_iio {
> struct clk *bus_clk;
> struct clk *mod_clk;
> struct reset_control*reset;
> + int sensor_id;
> /* prevents concurrent reads of temperature and ADC */
> struct mutexmutex;
> struct thermal_zone_device *tzd;
> @@ -302,14 +308,15 @@ static int sun4i_gpadc_adc_read(struct iio_dev
> *indio_dev, int channel,
> return sun4i_gpadc_read(indio_dev, channel, val, info->fifo_data_irq);
> }
>
> -static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> +static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val,
> + int sensor)
> {
> struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>
> if (info->no_irq) {
> pm_runtime_get_sync(indio_dev->dev.parent);
>
> -
Re: [PATCH v2 07/16] iio: adc: sun4i-gpadc-iio: rework: support nvmem calibration data
On Mon, Jan 29, 2018 at 12:29:10AM +0100, Philipp Rossak wrote:
> This patch reworks the driver to support nvmem calibration cells.
> The driver checks if the nvmem calibration is supported and reads out
> the nvmem.
>
> Signed-off-by: Philipp Rossak
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 44
> +++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index ac9ad2f8232f..74eeb5cd5218 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -74,6 +75,7 @@ struct gpadc_data {
> boolhas_bus_rst;
> boolhas_mod_clk;
> int sensor_count;
> + boolsupports_nvmem;
I think you should add some documentation along with all the fields
you're adding.
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -87,6 +89,7 @@ static const struct gpadc_data sun4i_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
That's already its value if you leave it out.
> };
>
> static const struct gpadc_data sun5i_gpadc_data = {
> @@ -100,6 +103,7 @@ static const struct gpadc_data sun5i_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
> };
>
> static const struct gpadc_data sun6i_gpadc_data = {
> @@ -113,6 +117,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
> };
>
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> @@ -123,6 +128,7 @@ static const struct gpadc_data sun8i_a33_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
> };
>
> struct sun4i_gpadc_iio {
> @@ -141,6 +147,8 @@ struct sun4i_gpadc_iio {
> struct clk *mod_clk;
> struct reset_control*reset;
> int sensor_id;
> + u32 calibration_data[2];
> + boolhas_calibration_data[2];
Why do you have two different values here?
> /* prevents concurrent reads of temperature and ADC */
> struct mutexmutex;
> struct thermal_zone_device *tzd;
> @@ -561,6 +569,9 @@ static int sun4i_gpadc_probe_dt(struct platform_device
> *pdev,
> struct resource *mem;
> void __iomem *base;
> int ret;
> + struct nvmem_cell *cell;
> + ssize_t cell_size;
> + u64 *cell_data;
>
> info->data = of_device_get_match_data(&pdev->dev);
> if (!info->data)
> @@ -575,6 +586,39 @@ static int sun4i_gpadc_probe_dt(struct platform_device
> *pdev,
> if (IS_ERR(base))
> return PTR_ERR(base);
>
> + info->has_calibration_data[0] = false;
> + info->has_calibration_data[1] = false;
> +
> + if (!info->data->supports_nvmem)
> + goto no_nvmem;
> +
> + cell = nvmem_cell_get(&pdev->dev, "calibration");
> + if (IS_ERR(cell)) {
> + if (PTR_ERR(cell) == -EPROBE_DEFER)
> + return PTR_ERR(cell);
> + goto no_nvmem;
goto considered evil ? :)
> + }
> +
> + cell_data = (u64 *)nvmem_cell_read(cell, &cell_size);
> + nvmem_cell_put(cell);
> + switch (cell_size) {
> + case 8:
> + case 6:
> + info->has_calibration_data[1] = true;
> + info->calibration_data[1] = be32_to_cpu(
> + upper_32_bits(cell_data[0]));
> + case 4:
> + case 2:
> + info->has_calibration_data[0] = true;
> + info->calibration_data[0] = be32_to_cpu(
> + lower_32_bits(cell_data[0]));
Why do you need that switch?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 14/14] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
On 29 January 2018 at 09:36, Marc Zyngier wrote:
> On 28/01/18 23:08, Ard Biesheuvel wrote:
>> On 26 January 2018 at 14:28, Marc Zyngier wrote:
>>> Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.
>>> It is lovely. Really.
>>>
>>> Signed-off-by: Marc Zyngier
>>> ---
>>> arch/arm64/kernel/bpi.S| 20
>>> arch/arm64/kernel/cpu_errata.c | 71
>>> +-
>>> 2 files changed, 90 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
>>> index 76225c2611ea..add7e08a018d 100644
>>> --- a/arch/arm64/kernel/bpi.S
>>> +++ b/arch/arm64/kernel/bpi.S
>>> @@ -17,6 +17,7 @@
>>> */
>>>
>>> #include
>>> +#include
>>>
>>> .macro ventry target
>>> .rept 31
>>> @@ -85,3 +86,22 @@ ENTRY(__qcom_hyp_sanitize_link_stack_start)
>>> .endr
>>> ldp x29, x30, [sp], #16
>>> ENTRY(__qcom_hyp_sanitize_link_stack_end)
>>> +
>>> +.macro smccc_workaround_1 inst
>>> + sub sp, sp, #(8 * 4)
>>> + stp x2, x3, [sp, #(16 * 0)]
>>> + stp x0, x1, [sp, #(16 * 1)]
>>> + orr w0, wzr, #ARM_SMCCC_ARCH_WORKAROUND_1
>>> + \inst #0
>>> + ldp x2, x3, [sp, #(16 * 0)]
>>> + ldp x0, x1, [sp, #(16 * 1)]
>>> + add sp, sp, #(8 * 4)
>>> +.endm
>>> +
>>> +ENTRY(__smccc_workaround_1_smc_start)
>>> + smccc_workaround_1 smc
>>> +ENTRY(__smccc_workaround_1_smc_end)
>>> +
>>> +ENTRY(__smccc_workaround_1_hvc_start)
>>> + smccc_workaround_1 hvc
>>> +ENTRY(__smccc_workaround_1_hvc_end)
>>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>>> index ed6881882231..f1501873f2e4 100644
>>> --- a/arch/arm64/kernel/cpu_errata.c
>>> +++ b/arch/arm64/kernel/cpu_errata.c
>>> @@ -70,6 +70,10 @@ DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data,
>>> bp_hardening_data);
>>> extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
>>> extern char __qcom_hyp_sanitize_link_stack_start[];
>>> extern char __qcom_hyp_sanitize_link_stack_end[];
>>> +extern char __smccc_workaround_1_smc_start[];
>>> +extern char __smccc_workaround_1_smc_end[];
>>> +extern char __smccc_workaround_1_hvc_start[];
>>> +extern char __smccc_workaround_1_hvc_end[];
>>>
>>> static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
>>> const char *hyp_vecs_end)
>>> @@ -116,6 +120,10 @@ static void
>>> __install_bp_hardening_cb(bp_hardening_cb_t fn,
>>> #define __psci_hyp_bp_inval_endNULL
>>> #define __qcom_hyp_sanitize_link_stack_start NULL
>>> #define __qcom_hyp_sanitize_link_stack_end NULL
>>> +#define __smccc_workaround_1_smc_start NULL
>>> +#define __smccc_workaround_1_smc_end NULL
>>> +#define __smccc_workaround_1_hvc_start NULL
>>> +#define __smccc_workaround_1_hvc_end NULL
>>>
>>> static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
>>> const char *hyp_vecs_start,
>>> @@ -142,17 +150,78 @@ static void install_bp_hardening_cb(const struct
>>> arm64_cpu_capabilities *entry,
>>> __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
>>> }
>>>
>>> +#include
>>> +#include
>>> #include
>>>
>>> +static void call_smc_arch_workaround_1(void)
>>> +{
>>> + register int w0 asm("w0") = ARM_SMCCC_ARCH_WORKAROUND_1;
>>> + asm volatile("smc #0\n"
>>> +: "+r" (w0));
>>> +}
>>> +
>>> +static void call_hvc_arch_workaround_1(void)
>>> +{
>>> + register int w0 asm("w0") = ARM_SMCCC_ARCH_WORKAROUND_1;
>>> + asm volatile("hvc #0\n"
>>> +: "+r" (w0));
>>> +}
>>> +
>>> +static bool check_smccc_arch_workaround_1(const struct
>>> arm64_cpu_capabilities *entry)
>>> +{
>>> + bp_hardening_cb_t cb;
>>> + void *smccc_start, *smccc_end;
>>> + struct arm_smccc_res res;
>>> +
>>> + if (psci_ops.variant == SMCCC_VARIANT_1_0)
>>> + return false;
>>> +
>>> + switch (psci_ops.conduit) {
>>> + case PSCI_CONDUIT_HVC:
>>> + arm_smccc_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>>> + ARM_SMCCC_ARCH_WORKAROUND_1, 0, 0, 0, 0, 0, 0,
>>> + &res);
>>> + if (res.a0)
>>> + return false;
>>> + cb = call_hvc_arch_workaround_1;
>>> + smccc_start = __smccc_workaround_1_hvc_start;
>>> + smccc_end = __smccc_workaround_1_hvc_end;
>>> + break;
>>> +
>>> + case PSCI_CONDUIT_SMC:
>>> + arm_smccc_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>>> + ARM_SMCCC_ARCH_WORKAROUND_1, 0, 0, 0, 0, 0, 0,
>>> + &res);
>>
>> This compiles to
>>
>> 4a8: 928fffe1mov x1, #0x8000 // #-32768
>> 4ac: b26187e0mov x0, #0xff
Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL
On 01/29/2018 09:46 AM, David Woodhouse wrote:
On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote:
Windows use IBRS and Microsoft don't have any plans to switch to retpoline.
Running a Windows guest should be a pretty common use-case no?
In addition, your handle of the first WRMSR intercept could be different.
It could signal you to start doing the following:
1. Disable intercept on SPEC_CTRL MSR.
2. On VMEntry, Write vCPU SPEC_CTRL value into physical MSR.
3. On VMExit, read physical MSR into vCPU SPEC_CTRL value.
(And if IBRS is used at host, also set physical SPEC_CTRL MSR here to 1)
That way, you will both have fastest option as long as guest don't use IBRS
and also won't have the 3% performance hit compared to Konrad's proposal.
Am I missing something?
Reads from the SPEC_CTRL MSR are strangely slow. I suspect a large part
of the 3% speedup you observe is because in the above, the vmentry path
doesn't need to *read* the host's value and store it; the host is
expected to restore it for itself anyway?
I'd actually quite like to repeat the benchmark on the new fixed
microcode, if anyone has it yet, to see if that read/swap slowness is
still quite as excessive. I'm certainly not ruling this out, but I'm
just a little wary of premature optimisation, and I'd like to make sure
we have everything *else* in the KVM patches right first.
The fact that the save-and-restrict macros I have in the tip of my
working tree at the moment are horrid and causing 0-day nastygrams,
probably doesn't help persuade me to favour the approach ;)
... hm, the CPU actually has separate MSR save/restore lists for
entry/exit, doesn't it? Is there any way to sanely make use of that and
do the restoration manually on vmentry but let it be automatic on
vmexit, by having it *only* in the guest's MSR-store area to be saved
on exit and restored on exit, but *not* in the host's MSR-store area?
Reading the code and comparing with the SDM, I can't see where we're
ever setting VM_EXIT_MSR_STORE_{ADDR,COUNT} except in the nested
case...
Hmmm ... you are probably right! I think all users of this interface
always trap + update save area and never passthrough the MSR. That is
why only LOAD is needed *so far*.
Okay, let me sort this out in v3 then.
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
