Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs
On 09.02.19 at 11:35, Andy Shevchenko wrote: On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton wrote: On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko wrote: On Tue, Oct 30, 2018 at 5:22 PM David Engraf wrote: Unpacking an external initrd may fail e.g. not enough memory. This leads to an incomplete rootfs because some files might be extracted already. Fixed by cleaning the rootfs so the kernel is not using an incomplete rootfs. This breaks my setup where I have U-boot provided more size of initramfs than needed. This allows a bit of flexibility to increase or decrease initramfs compressed image without taking care of bootloader. The proper solution is to do this if we sure that we didn't get enough memory, otherwise I can't consider the error fatal to clean up rootfs. OK, thanks. Maybe David can suggest a fix - I'll queue up a revert meanwhile. I don't really understand the failure. Why does an oversized initramfs cause unpack_to_rootfs() to fail? In my case I have got "Junk in compressed archive". I don't know (I would check if needed) which exact condition I got since there are three places with this message. The file itself smaller than the size passed through bootparam. So, when decomression is finished (successfully!) we still have a garbarge in the memory which is not related to archive. Message per se is okay to have, though I consider this non-fatal. I can reproduce this special case. The unpacking decompresses the whole size instead of checking the archive size. I will have a look how to get the real archive size. Best regards - David
Re: [PATCH v3 1/7] dump_stack: Support adding to the dump stack arch description
On (02/08/19 13:55), Steven Rostedt wrote:
[..]
> > + if (len) {
> > + /*
> > +* Order the stores above in vsnprintf() vs the store of the
> > +* space below which joins the two strings. Note this doesn't
> > +* make the code truly race free because there is no barrier on
> > +* the read side. ie. Another CPU might load the uninitialised
> > +* tail of the buffer first and then the space below (rather
> > +* than the NULL that was there previously), and so print the
> > +* uninitialised tail. But the whole string lives in BSS so in
> > +* practice it should just see NULLs.
> > +*/
> > + smp_wmb();
>
> This shows me that this can be called at a time when more than one CPU is
> active. What happens if we have two CPUs calling dump_stack_add_arch_desc() at
> the same time? Can't that corrupt the dump_stack_arch_desc_str?
Can overwrite part of it, I guess (but it seems that Michael
is OK with this). The string is still NULL terminated.
The worst case scenario I can think of is not the one when
two CPUs call dump_stack_add_arch_desc(), but when CPUA calls
dump_stack_add_arch_desc() to append some data and at the
same time CPUB calls dump_stack_set_arch_desc() and simply
overwrites dump_stack_arch_desc_str. Not sure if this is
critical (or possible).
-ss
Re: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to aid Intel PT tracing
On 9/02/19 1:29 AM, Alexei Starovoitov wrote:
> On Thu, Feb 07, 2019 at 01:19:01PM +0200, Adrian Hunter wrote:
>> Subject to memory pressure and other limits, retain executable code, such
>> as JIT-compiled bpf, in memory instead of freeing it immediately it is no
>> longer needed for execution.
>>
>> While perf is primarily aimed at statistical analysis, tools like Intel
>> PT can aim to provide a trace of exactly what happened. As such, corner
>> cases that can be overlooked statistically need to be addressed. For
>> example, there is a gap where JIT-compiled bpf can be freed from memory
>> before a tracer has a chance to read it out through the bpf syscall.
>> While that can be ignored statistically, it contributes to a death by
>> 1000 cuts for tracers attempting to assemble exactly what happened. This is
>> a bit gratuitous given that retaining the executable code is relatively
>> simple, and the amount of memory involved relatively small. The retained
>> executable code is then available in memory images such as /proc/kcore.
>>
>> This facility could perhaps be extended also to init sections.
>>
>> Note that this patch is compile tested only and, at present, is missing
>> the ability to retain symbols.
>>
>> Signed-off-by: Adrian Hunter
>> ---
>> arch/x86/Kconfig.cpu | 1 +
>> include/linux/filter.h | 4 +
>> include/linux/xc_retain.h | 49 ++
>> init/Kconfig | 6 ++
>> kernel/Makefile| 1 +
>> kernel/bpf/core.c | 44 -
>> kernel/xc_retain.c | 183 +
>> net/core/sysctl_net_core.c | 62 +
>> 8 files changed, 349 insertions(+), 1 deletion(-)
>> create mode 100644 include/linux/xc_retain.h
>> create mode 100644 kernel/xc_retain.c
>>
>> diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
>> index 6adce15268bd..21dcd064c272 100644
>> --- a/arch/x86/Kconfig.cpu
>> +++ b/arch/x86/Kconfig.cpu
>> @@ -389,6 +389,7 @@ menuconfig PROCESSOR_SELECT
>> config CPU_SUP_INTEL
>> default y
>> bool "Support Intel processors" if PROCESSOR_SELECT
>> +select XC_RETAIN if PERF_EVENTS && BPF_JIT
>> ---help---
>>This enables detection, tunings and quirks for Intel processors
>>
>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>> index d531d4250bff..40b9f601e18f 100644
>> --- a/include/linux/filter.h
>> +++ b/include/linux/filter.h
>> @@ -851,6 +851,10 @@ extern int bpf_jit_enable;
>> extern int bpf_jit_harden;
>> extern int bpf_jit_kallsyms;
>> extern long bpf_jit_limit;
>> +extern unsigned int bpf_jit_retain_min;
>> +extern unsigned int bpf_jit_retain_max;
>> +
>> +void bpf_jit_retain_update_sz(void);
>>
>> typedef void (*bpf_jit_fill_hole_t)(void *area, unsigned int size);
>>
>> diff --git a/include/linux/xc_retain.h b/include/linux/xc_retain.h
>> new file mode 100644
>> index ..e79dc138bab8
>> --- /dev/null
>> +++ b/include/linux/xc_retain.h
>> @@ -0,0 +1,49 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (C) 2019 Intel Corporation.
>> + */
>> +#ifndef _LINUX_XC_RETAIN_H
>> +#define _LINUX_XC_RETAIN_H
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +struct xc_retain_ops {
>> +void (*free)(void *addr);
>> +};
>> +
>> +struct xc_retain {
>> +struct list_head list;
>> +struct list_head items;
>> +const struct xc_retain_ops ops;
>> +unsigned int min_pages;
>> +unsigned int max_pages;
>> +unsigned int current_pages;
>> +unsigned int item_cnt;
>> +spinlock_t lock;
>> +struct shrinker shrinker;
>> +};
>> +
>> +#ifdef CONFIG_XC_RETAIN
>> +int xc_retain_register(struct xc_retain *xr);
>> +void xc_retain_binary(struct xc_retain *xr, void *addr, unsigned int pages);
>> +void xc_retain_set_min_pages(struct xc_retain *xr, unsigned int min_pages);
>> +void xc_retain_set_max_pages(struct xc_retain *xr, unsigned int max_pages);
>> +#else
>> +static inline int xc_retain_register(struct xc_retain *xr)
>> +{
>> +return 0;
>> +}
>> +static inline void xc_retain_binary(struct xc_retain *xr, void *addr,
>> +unsigned int pages)
>> +{
>> +xr->ops.free(addr);
>> +}
>> +static inline void xc_retain_set_max_pages(struct xc_retain *xr,
>> + unsigned int max_pages)
>> +{
>> +}
>> +#endif
>> +
>> +#endif
>> diff --git a/init/Kconfig b/init/Kconfig
>> index c9386a365eea..954c288cabdc 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -1550,6 +1550,12 @@ config EMBEDDED
>>an embedded system so certain expert options are available
>>for configuration.
>>
>> +config XC_RETAIN
>> +bool
>> +help
>> + Retain kernel executable code (e.g. jitted BPF) in memory after it
>> + would normally be freed.
>> +
>> config HAVE_PERF_EVENTS
>> bool
>> help
>> diff --git a/kernel/Makefile b/kernel/Makefile
>> index 6aa7543bcdb2..5df40e2a934e 100644
>> --- a/kernel/Makefile
>> +
Re: [PATCH v2] crypto: caam - add missing put_device() call
On 2/9/2019 8:31 AM, Wen Yang wrote:
> The of_find_device_by_node() takes a reference to the underlying device
> structure, we should release that reference.
>
> Fixes: 35af64038623 ("crypto: caam - Check for CAAM block presence before
> registering with crypto layer")
> Signed-off-by: Wen Yang
> ---
> v2->v1: This patch also fixes caamalg.c, caampkc.c and caamrng.c.
>
caamalg_qi.c is also affected, could you please include it?
Thanks,
Horia
Re: [PATCH] tty: pty: Fix race condition between release_one_tty and pty_write
On Mon, Feb 11, 2019 at 11:09:15AM +0400, kpark3...@gmail.com wrote:
> From: Sahara
I need a "real" name here, one you use to sign legal documents please.
> Especially when a linked tty is used such as pty, the linked tty
> port's buf works have not been cancelled while master tty port's
> buf work has been cancelled. Since release_one_tty and flush_to_ldisc
> run in workqueue threads separately, when pty_cleanup happens and
> link tty port is freed, flush_to_ldisc tries to access freed port
> and port->itty, eventually it causes a panic.
> This patch utilizes the magic value with holding the tty_mutex to
> check if the tty->link is valid.
>
> Fixes: 2b022ab7542d ("pty: cancel pty slave port buf's work in tty_release")
> Signed-off-by: Sahara
> ---
> drivers/tty/pty.c| 7 +++
> drivers/tty/tty_io.c | 3 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> index 00099a84..ef72031 100644
> --- a/drivers/tty/pty.c
> +++ b/drivers/tty/pty.c
> @@ -116,6 +116,12 @@ static int pty_write(struct tty_struct *tty, const
> unsigned char *buf, int c)
> if (tty->stopped)
> return 0;
>
> + mutex_lock(&tty_mutex);
> + if (to->magic != TTY_MAGIC) {
Checking the "magic" field is odd, are you sure about this? Usually
this means that memory that is already freed is still being used, right?
And have you tried the 5.0-rc6 release? I thought I fixed much this
same issue there already, but for a serial port, not a pty. Is the same
problem still present?
> + mutex_unlock(&tty_mutex);
> + return -EIO;
> + }
> +
> if (c > 0) {
> spin_lock_irqsave(&to->port->lock, flags);
> /* Stuff the data into the input queue of the other end */
> @@ -125,6 +131,7 @@ static int pty_write(struct tty_struct *tty, const
> unsigned char *buf, int c)
> tty_flip_buffer_push(to->port);
> spin_unlock_irqrestore(&to->port->lock, flags);
> }
> + mutex_unlock(&tty_mutex);
> return c;
> }
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 23c6fd2..6c4a206 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -1446,10 +1446,13 @@ static void release_one_tty(struct work_struct *work)
> struct tty_driver *driver = tty->driver;
> struct module *owner = driver->owner;
>
> + mutex_lock(&tty_mutex);
> if (tty->ops->cleanup)
> tty->ops->cleanup(tty);
>
> tty->magic = 0;
Using the "magic" field as a flag isn't the best thing for us to rely
on, because this structure should be freed now, right?
thanks,
greg k-h
Re: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to aid Intel PT tracing
* Peter Zijlstra wrote: > On Thu, Feb 07, 2019 at 01:19:01PM +0200, Adrian Hunter wrote: > > Subject to memory pressure and other limits, retain executable code, such > > as JIT-compiled bpf, in memory instead of freeing it immediately it is no > > longer needed for execution. > > > > While perf is primarily aimed at statistical analysis, tools like Intel > > PT can aim to provide a trace of exactly what happened. As such, corner > > cases that can be overlooked statistically need to be addressed. For > > example, there is a gap where JIT-compiled bpf can be freed from memory > > before a tracer has a chance to read it out through the bpf syscall. > > While that can be ignored statistically, it contributes to a death by > > 1000 cuts for tracers attempting to assemble exactly what happened. This is > > a bit gratuitous given that retaining the executable code is relatively > > simple, and the amount of memory involved relatively small. The retained > > executable code is then available in memory images such as /proc/kcore. > > > > This facility could perhaps be extended also to init sections. > > > > Note that this patch is compile tested only and, at present, is missing > > the ability to retain symbols. > > You don't need the symbols; you already have them through > PERF_RECORD_KSYMBOL. > > Also; afaict this patch guarantees exactly nothing. It registers a > shrinker which will (given enough memory pressure) happily free your > text before we get around to copying it out. > > Did you read this proposal? > > > https://lkml.kernel.org/r/20190109101808.gg1...@hirez.programming.kicks-ass.net > > (also: s/KCORE_QC/KCORE_QS/ for quiescent state) > > That would create an RCU like interface to /proc/kcore and give you the > guarantees you need, while also allowing the memory to get freed once > you've obtained a copy. Yeah, adding a proper change-notification interface to /proc/kcore sounds like a superior solution to trying to shoehorn this down perf's throat. It's not like any of this is useful without having opened /proc/kcore. Also, /proc/kcore is privileged, so the indefinite resource allocation side effect in case user-space doesn't drain the lists is OK. Thanks, Ingo
Re: [PATCH net-next v2 00/10] net: phy: Add support for 2.5GBASET PHYs
Hello Heiner, >Hi Maxime, > >Andrew and me are working on Aquantia PHY support and he handed over >to me a patch series which includes parts of the first version of your >series. Having said that I'm especially interested in your patches >5 and 6. Because your series is somewhat bigger and there are a few >review comments, preparing the next round may take time. > >I'd propose that you extract generic patches being submission-ready >and split the patch series into two. I think the following patches >would be candidates for the first series: 2, 3, 5, 6 >(provided they have no dependency on the other patches) >Based on that both of us can go on with our work. Sure, I'll sent that shortly. Thanks for the help, Maxime
Re: linux-next: Fixes tag needs some work in the driver-core tree
On Mon, Feb 11, 2019 at 07:40:52AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> In commit
>
> 344c0152d878 ("selftests: firmware: fix verify_reqs() return value")
>
> Fixes tag
>
> Fixes: a6a9be9270c87 ("selftests: firmware: return Kselftest Skip code for
> for skipped tests")
>
> has these problem(s):
>
> - Subject does not match target commit subject
I don't understand, what is wrong with the fixes: tag here?
$ git show -s --abbrev-commit --abbrev=12 --pretty=format:"%h (\"%s\")%n"
a6a9be9270c87
a6a9be9270c8 ("selftests: firmware: return Kselftest Skip code for skipped
tests")
How does that not match up?
Ah, an extra "for" in there. Luis, you need to fix up your scripts, and
not be forced to manually type in those lines :)
thanks,
greg k-h
Re: [PATCH] Documentation: fix vm/slub.rst warning
On (02/11/19 09:35), Mike Rapoport wrote: > On Sun, Feb 10, 2019 at 10:34:11PM -0800, Randy Dunlap wrote: > > From: Randy Dunlap > > > > Fix markup warning by quoting the '*' character with a backslash. > > > > Documentation/vm/slub.rst:71: WARNING: Inline emphasis start-string without > > end-string. > > > > Signed-off-by: Randy Dunlap > > Cc: Christoph Lameter > > Cc: Sergey Senozhatsky > > Acked-by: Mike Rapoport FWIW, Reviewed-by: Sergey Senozhatsky -ss
Re: [PATCH v2] PCI: Fixup the RTIT_BAR of Intel TH on Denverton
* Alexander Shishkin wrote: > On Denverton's integration of the Intel(R) Trace Hub (for a reference > and overview see Documentation/trace/intel_th.txt) the reported size of > one of its resources (RTIT_BAR) doesn't match its actual size, which > leads to overlaps with other devices' resources. Note that in the latest kernels it's Documentation/trace/intel_th.rst, not .txt. Thanks, Ingo
[PATCH v2 1/3] x86/boot: Add xloadflags bits for 5-level kernel checking
Add two bits XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel. Bit XLF_5LEVEL indicates if 5-level related code is contained in this kernel. Bit XLF_5LEVEL_ENABLED indicates if CONFIG_X86_5LEVEL=y is set. They are being used in later patch to check if kexec/kdump kernel is loaded in right place. Signed-off-by: Baoquan He --- v1->v2: Change the wrong term in subject pointed out by tglx. arch/x86/boot/header.S| 12 +++- arch/x86/include/uapi/asm/bootparam.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..be19f4199727 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -419,7 +419,17 @@ xloadflags: # define XLF4 0 #endif - .word XLF0 | XLF1 | XLF23 | XLF4 +#ifdef CONFIG_X86_64 +#ifdef CONFIG_X86_5LEVEL +#define XLF56 (XLF_5LEVEL|XLF_5LEVEL_ENABLED) +#else +#define XLF56 XLF_5LEVEL +#endif +#else +#define XLF56 0 +#endif + + .word XLF0 | XLF1 | XLF23 | XLF4 | XLF56 cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line, #added with boot protocol diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h index 60733f137e9a..c895df5482c5 100644 --- a/arch/x86/include/uapi/asm/bootparam.h +++ b/arch/x86/include/uapi/asm/bootparam.h @@ -29,6 +29,8 @@ #define XLF_EFI_HANDOVER_32(1<<2) #define XLF_EFI_HANDOVER_64(1<<3) #define XLF_EFI_KEXEC (1<<4) +#define XLF_5LEVEL (1<<5) +#define XLF_5LEVEL_ENABLED (1<<6) #ifndef __ASSEMBLY__ -- 2.17.2
Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
* Waiman Long wrote: > On 02/07/2019 02:51 PM, Davidlohr Bueso wrote: > > On Thu, 07 Feb 2019, Waiman Long wrote: > >> 30 files changed, 1197 insertions(+), 1594 deletions(-) > > > > Performance numbers on numerous workloads, pretty please. > > > > I'll go and throw this at my mmap_sem intensive workloads > > I've collected. > > > > Thanks, > > Davidlohr > > Thanks for getting some of the performance numbers. This is the initial > draft after more than 1 years of hibernation. I will also get other > performance numbers in subsequent revision of the patch. If you could sort all the invariant preparatory patches to the head of the series I can merge them to reduce overall complexity and simplify performance testing and review of the rest. Thanks, Ingo
linux-next: Tree for Feb 11
Hi all, Changes since 20190208: The drm-misc tree still has its build failure so I used a supplied merge fix patch. The apparmor tree lost its build failure. The phy-next tree gained conflicts against the net-next tree. The scsi-mkp tree gained conflicts against Linus' and the block trees. The rtc tree lost its build failure, but gained a conflict against the clk tree and another build failure for which I reverted a commit. The akpm tree gained a conflict against the mips tree, but I removed the pconflicting patch in the akpm tree. Also several patches turned up elsewhere and so were also removed form the akpm tree. Non-merge commits (relative to Linus' tree): 6895 7515 files changed, 289761 insertions(+), 186398 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 296 trees (counting Linus' and 69 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 (68d94a842435 Merge tag 'dmaengine-fix-5.0-rc6' of git://git.infradead.org/users/vkoul/slave-dma) Merging fixes/master (0dd62c042779 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (6db2983cd806 kallsyms: Handle too long symbols in kallsyms.c) Merging arc-current/for-curr (3e45ea2a074f ARCv2: entry: exception prologue freeing up reg improvement) Merging arm-current/fixes (1b5ba3507842 ARM: 8824/1: fix a migrating irq bug when hotplug cpu) Merging arm64-fixes/for-next/fixes (ea5736805190 arm64: kexec_file: handle empty command-line) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (5a3840a470c4 powerpc/papr_scm: Use the correct bind address) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (ccc8ca9b90ac net/smc: fix byte_order for rx_curs_confirmed) Merging bpf/master (d623876646be bpf: Fix narrow load on a bpf_sock returned from sk_lookup()) Merging ipsec/master (f75a2804da39 xfrm: destroy xfrm_state synchronously on net exit path) Merging netfilter/master (bdcc5bc25548 mISDN: fix a race in dev_expire_timer()) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (d04ca383860b mt76x0u: fix suspend/resume) Merging mac80211/master (73350424bec9 cfg80211: pmsr: fix abort locking) Merging rdma-fixes/for-rc (48396e80fb65 RDMA/srp: Rework SCSI device reset handling) Merging sound-current/for-linus (0a5cf9e88b51 Merge tag 'asoc-fix-v5.0-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (bb62989dccca Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (a71f59222522 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (a4a9ebe8cb0f Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f57a98e1b713 PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX)) Merging driver-core.current/driver-core-linus (46c291e277f9 Merge tag 'armsoc-fixes-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc) Merging tty.current/tty-linus
Re: possible deadlock in pipe_lock (2)
On Sun, Feb 10, 2019 at 8:23 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:74e96711e337 Merge tag 'platform-drivers-x86-v5.0-2' of gi..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11225b2740
> kernel config: https://syzkaller.appspot.com/x/.config?x=8f00801d7b7c4fe6
> dashboard link: https://syzkaller.appspot.com/bug?extid=31d8b84465a7cbfd8515
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+31d8b84465a7cbfd8...@syzkaller.appspotmail.com
>
> kvm [15406]: vcpu0, guest rIP: 0xfff0 kvm_set_msr_common:
> MSR_IA32_DEBUGCTLMSR 0x3, nop
> ==
> WARNING: possible circular locking dependency detected
> 5.0.0-rc5+ #63 Not tainted
> --
> overlayfs: filesystem on './file0' not supported as upperdir
> syz-executor.2/15417 is trying to acquire lock:
> dcbcd11f (&pipe->mutex/1){+.+.}, at: pipe_lock_nested fs/pipe.c:62
> [inline]
> dcbcd11f (&pipe->mutex/1){+.+.}, at: pipe_lock+0x6e/0x80
> fs/pipe.c:70
>
> but task is already holding lock:
> kobject: 'loop0' (d9cc93a0): kobject_uevent_env
> c13db9a0 (sb_writers#3){.+.+}, at: file_start_write
> include/linux/fs.h:2816 [inline]
> c13db9a0 (sb_writers#3){.+.+}, at: do_splice+0xceb/0x1330
> fs/splice.c:1151
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
> kobject: 'loop0' (d9cc93a0): fill_kobj_path: path
> = '/devices/virtual/block/loop0'
>
> -> #2 (sb_writers#3){.+.+}:
> percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
> percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> __sb_start_write+0x20b/0x360 fs/super.c:1389
> sb_start_write include/linux/fs.h:1603 [inline]
> mnt_want_write+0x3f/0xc0 fs/namespace.c:357
> ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> ovl_setattr+0xdd/0x950 fs/overlayfs/inode.c:30
> notify_change+0xad9/0xfb0 fs/attr.c:334
> kobject: 'loop5' (a501efc5): kobject_uevent_env
> do_truncate+0x158/0x220 fs/open.c:63
> handle_truncate fs/namei.c:3008 [inline]
> do_last fs/namei.c:3424 [inline]
> path_openat+0x2cc6/0x4690 fs/namei.c:3534
> do_filp_open+0x1a1/0x280 fs/namei.c:3564
> do_sys_open+0x3fe/0x5d0 fs/open.c:1063
> __do_sys_openat fs/open.c:1090 [inline]
> __se_sys_openat fs/open.c:1084 [inline]
> __x64_sys_openat+0x9d/0x100 fs/open.c:1084
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> kobject: 'loop5' (a501efc5): fill_kobj_path: path
> = '/devices/virtual/block/loop5'
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (&ovl_i_mutex_key[depth]){+.+.}:
> down_write+0x38/0x90 kernel/locking/rwsem.c:70
> inode_lock include/linux/fs.h:757 [inline]
> ovl_write_iter+0x148/0xc20 fs/overlayfs/file.c:231
> call_write_iter include/linux/fs.h:1863 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x613/0x8e0 fs/read_write.c:487
> kobject: 'loop4' (9e2b886d): kobject_uevent_env
> __kernel_write+0x110/0x3b0 fs/read_write.c:506
> write_pipe_buf+0x15d/0x1f0 fs/splice.c:797
> splice_from_pipe_feed fs/splice.c:503 [inline]
> __splice_from_pipe+0x39a/0x7e0 fs/splice.c:627
> splice_from_pipe+0x108/0x170 fs/splice.c:662
> default_file_splice_write+0x3c/0x90 fs/splice.c:809
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x644/0x1330 fs/splice.c:1152
> __do_sys_splice fs/splice.c:1419 [inline]
> __se_sys_splice fs/splice.c:1399 [inline]
> __x64_sys_splice+0x2c6/0x330 fs/splice.c:1399
> kobject: 'loop4' (9e2b886d): fill_kobj_path: path
> = '/devices/virtual/block/loop4'
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 (&pipe->mutex/1){+.+.}:
> lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> __mutex_lock+0xf7/0x1310 kernel/locking/mutex.c:1072
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> pipe_lock_nested fs/pipe.c:62 [inline]
> pipe_lock+0x6e/0x80 fs/pipe.c:70
> iter_file_splice_write+0x18b/0xbe0 fs/splice.c:700
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x644/0x1330 fs/splice.c:1152
> __do_sys_splice fs/splice.c:1419 [inline]
> __se_sys_splice fs/splice.c:1399 [inline]
> __x64_sys_splice+0x2c6/0x330 fs/splice.c:1399
> do_syscall_64+0x103/0x610 arch
Re: use generic DMA mapping code in powerpc V4
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
> I tested the whole series today. The kernels boot and the P.A. Semi
> Ethernet works! :-) Thanks a lot!
>
> I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
> kernel crashes.
This looks like a patch I fixed in mainline a while ago, but which
the powerpc tree didn't have yet.
I've cherry picked this commit
("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
and added it to the powerpc-dma.6 tree, please retry with that one.
Re: [PATCH] Documentation: fix vm/slub.rst warning
On Sun, Feb 10, 2019 at 10:34:11PM -0800, Randy Dunlap wrote: > From: Randy Dunlap > > Fix markup warning by quoting the '*' character with a backslash. > > Documentation/vm/slub.rst:71: WARNING: Inline emphasis start-string without > end-string. > > Signed-off-by: Randy Dunlap > Cc: Christoph Lameter > Cc: Sergey Senozhatsky Acked-by: Mike Rapoport > --- > Documentation/vm/slub.rst |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- lnx-50-rc6.orig/Documentation/vm/slub.rst > +++ lnx-50-rc6/Documentation/vm/slub.rst > @@ -68,7 +68,7 @@ end of the slab name, in order to cover > example, here's how you can poison the dentry cache as well as all kmalloc > slabs: > > - slub_debug=P,kmalloc-*,dentry > + slub_debug=P,kmalloc-\*,dentry > > Red zoning and tracking may realign the slab. We can just apply sanity > checks > to the dentry cache with:: > > -- Sincerely yours, Mike.
Re: [Qemu-devel] security implications of caching with virtio pmem (was Re: [PATCH v3 0/5] kvm "virtio pmem" device)
Hi Michael, Thanks for looking into this and summarizing in detail. > > This patch series has implementation for "virtio pmem". > > "virtio pmem" is fake persistent memory(nvdimm) in guest > > which allows to bypass the guest page cache. This also > > implements a VIRTIO based asynchronous flush mechanism. > > > At Pankaj's request I looked at information leak implications of virtio > pmem in light of the recent page cache side channels paper > (https://arxiv.org/pdf/1901.01161.pdf) - to see what > kind of side channels it might create if any. TLDR - I think that > depending on the host side implementation there could be some, but this > might be addressable by better documentation in both code and spec. > The fake dax approach backing the guest memory by a host page cache > does seem to have potential issues. > > For clarity: we are talking about leaking information either to a VM, or > within a VM (I did not look into leaks to hypervisor in configurations > such as SEV) through host page cache. > > Leaks into a VM: It seems clear that while pmem allows memory accesses > versus read/write with e.g. a block device, from host page cache point > of view this doesn't matter much: reads populate cache in the same way > as memory faults. Thus ignoring presence of information leaks (which is > an interesting question e.g. in light of recent discard support) pmem > doesn't seem to be any better or worse for leaking information into a > VM. > > Leaks within VM: Right now pmem seems to bypass the guest page cache > completely. Whether pmem memory is then resident in a page cache would > be up to the device/host. Assuming that it is, the "Preventing > Efficient Eviction while Increasing the System Performance" > countermeasure for the page cache side channel attack would appear to > become ineffective with pmem. What is suggested is a per-process > management of the page cache, and host does not have visibility of > processes within a VM. Another possible countermeasure - not discussed > in the paper - could be modify the applications to lock the security > relevant pages in memory. Again this becomes impractical with pmem as > host does not have visibility into that. However note that as long > as the only countermeasure linux uses is "Privileged Access" > (i.e. blocking mincore) nothing can be done as guest page cache > remains as vulnerable as host page cache. > > > Countermeasures: which host-side countermeasures can be designed would > depend on which countermeasures are used guest-side - we would need to > make sure they are not broken by pmem. For "Preventing Efficient > Eviction while Increasing the System Performance" modifying the host > implementation to ensure that pmem device bypasses the host page cache > would seem to address the security problem.Similarly, ensuring that a > real memory device (e.g. DAX, RAM such as hugetlbfs, pmem for nested > virt) is used for pmem would make the memory locking countermeasure > work. Whether with such limitations the device is still useful > performance wise is an open question. These questions probably should > be addressed in the documentation, spec and possible qemu code. > > > > Severity of the security implications: some people argue that the > security implications of the page cache leaks are minor. I do not have > an opinion on this: the severity would seem to depend on the specific > configuration. > > > Other security implications: recent discussion seems to suggest there > are other concerns around e.g. resource management and thus DOS > potential. If that's so, it's a matter for a separate discussion > as I didn't look into that in depth. > > Some or all of the above might be based on a misunderstanding of the > current pmem code, the whitepaper and linux page cache in general. > If so I apologise, do not hesitate to call out any mistakes. I agree similar to any guest VM(without virtio-pmem) or any host userspace process, virtio-pmem may also have some security implications. We need to document these in virtio-pmem host device specification and in qemu code. This is to make sure while creating virtio-pmem device, we are aware of these implications and create/use host side device backing file accordingly as per the use-case described by David here [1]. I will document these in next version of my patch series. Hello Dave, Are we okay with this? Thank you everyone for the discussion. [1] https://marc.info/?l=linux-kernel&m=154946989419403&w=2 Best regards, Pankaj
Re: [PATCH v2 1/2] sched/wait: introduce wait_event_freezable_hrtimeout
* Hugo Lefeuvre wrote:
> introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> version of wait_event_hrtimeout.
>
> This helper will allow for simplifications in staging/android/vsoc.c, among
> others.
>
> Signed-off-by: Hugo Lefeuvre
> ---
> Changes in v2:
> - No change.
>
> include/linux/wait.h | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index 5f3efabc36f4..c4cf5113f58a 100644
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
> @@ -483,7 +483,7 @@ do {
> \
> __ret;
> \
> })
>
> -#define __wait_event_hrtimeout(wq_head, condition, timeout, state)
> \
> +#define __wait_event_hrtimeout(wq_head, condition, timeout, state, cmd)
> \
> ({
> \
> int __ret = 0;
> \
> struct hrtimer_sleeper __t;
> \
> @@ -500,7 +500,7 @@ do {
> \
> __ret = -ETIME;
> \
> break;
> \
> }
> \
> - schedule());
> \
> + cmd);
> \
>
> \
> hrtimer_cancel(&__t.timer);
> \
> destroy_hrtimer_on_stack(&__t.timer);
> \
> @@ -529,7 +529,23 @@ do {
> \
> might_sleep();
> \
> if (!(condition))
> \
> __ret = __wait_event_hrtimeout(wq_head, condition, timeout,
> \
> -TASK_UNINTERRUPTIBLE);
> \
> +TASK_UNINTERRUPTIBLE,
> \
> +schedule());
> \
> + __ret;
> \
> +})
> +
> +/*
> + * like wait_event_hrtimeout() -- except it uses TASK_INTERRUPTIBLE to avoid
> + * increasing load and is freezable.
> + */
> +#define wait_event_freezable_hrtimeout(wq_head, condition, timeout)
> \
> +({
> \
> + int __ret = 0;
> \
> + might_sleep();
> \
> + if (!(condition))
> \
> + __ret = __wait_event_hrtimeout(wq_head, condition, timeout,
> \
> +TASK_INTERRUPTIBLE,
> \
> +freezable_schedule());
> \
> __ret;
> \
> })
>
> @@ -555,7 +571,8 @@ do {
> \
> might_sleep();
> \
> if (!(condition))
> \
> __ret = __wait_event_hrtimeout(wq, condition, timeout,
> \
> -TASK_INTERRUPTIBLE);
> \
> +TASK_INTERRUPTIBLE,
> \
> +schedule());
> \
> __ret;
> \
> })
Looks good to me - unless PeterZ objects I suspect this wants to go
upstream via the driver tree, not the scheduler tree:
Acked-by: Ingo Molnar
Thanks,
Ingo
Re: [PATCH v3 1/2] PCI: altera: Add Stratix 10 PCIe support
On Sat, Feb 9, 2019 at 12:29 AM Lorenzo Pieralisi
wrote:
>
> Apologies, I have dropped the ball on this one.
>
> On Wed, Jan 02, 2019 at 02:16:48PM +0800, Ley Foon Tan wrote:
> > Add PCIe Root Port support for Stratix 10 device.
> >
> > Main differences:
> > - HIP interface to access Root Port configuration register.
> > - TLP programming flow:
> > - One REG0 register
> > - Don't need to check alignment
> >
> > Signed-off-by: Ley Foon Tan
> > ---
> > drivers/pci/controller/Kconfig |2 +-
> > drivers/pci/controller/pcie-altera.c | 246
> > ++
> > 2 files changed, 223 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> > index 6671946..6012f30 100644
> > --- a/drivers/pci/controller/Kconfig
> > +++ b/drivers/pci/controller/Kconfig
> > @@ -175,7 +175,7 @@ config PCIE_IPROC_MSI
> >
> > config PCIE_ALTERA
> > bool "Altera PCIe controller"
> > - depends on ARM || NIOS2 || COMPILE_TEST
> > + depends on ARM || NIOS2 || ARM64 || COMPILE_TEST
>
> This is an unrelated change and should be a separate patch.
Noted.
>
> > help
> > Say Y here if you want to enable PCIe controller support on Altera
> > FPGA.
> > diff --git a/drivers/pci/controller/pcie-altera.c
> > b/drivers/pci/controller/pcie-altera.c
> > index 7d05e51..4c3b61b 100644
> > --- a/drivers/pci/controller/pcie-altera.c
> > +++ b/drivers/pci/controller/pcie-altera.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -37,7 +38,12 @@
> > #define RP_LTSSM_MASK0x1f
> > #define LTSSM_L0 0xf
> >
> > -#define PCIE_CAP_OFFSET 0x80
> > +#define S10_RP_TX_CNTRL 0x2004
> > +#define S10_RP_RXCPL_REG 0x2008
> > +#define S10_RP_RXCPL_STATUS 0x200C
> > +#define S10_RP_CFG_ADDR(pcie, reg) \
> > + (((pcie)->hip_base) + (reg) + (1 << 20))
> > +
> > /* TLP configuration type 0 and 1 */
> > #define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0
> > */
> > #define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0
> > */
> > @@ -49,18 +55,19 @@
> > #define RP_DEVFN 0
> > #define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
> > #define TLP_CFGRD_DW0(pcie, bus) \
> > -bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGRD0
> > \
> > - : TLP_FMTTYPE_CFGRD1) << 24) | \
> > - TLP_PAYLOAD_SIZE)
> > + bus == pcie->root_bus_nr) ? pcie->pcie_data->cfgrd0 \
> > + : pcie->pcie_data->cfgrd1) << 24) | \
> > + TLP_PAYLOAD_SIZE)
> > #define TLP_CFGWR_DW0(pcie, bus) \
> > -bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGWR0
> > \
> > - : TLP_FMTTYPE_CFGWR1) << 24) | \
> > - TLP_PAYLOAD_SIZE)
> > + bus == pcie->root_bus_nr) ? pcie->pcie_data->cfgwr0 \
> > + : pcie->pcie_data->cfgwr1) << 24) | \
> > + TLP_PAYLOAD_SIZE)
> > #define TLP_CFG_DW1(pcie, tag, be) \
> > -(((TLP_REQ_ID(pcie->root_bus_nr, RP_DEVFN)) << 16) | (tag << 8) |
> > (be))
> > + (((TLP_REQ_ID(pcie->root_bus_nr, RP_DEVFN)) << 16) | (tag << 8) |
> > (be))
> > #define TLP_CFG_DW2(bus, devfn, offset) \
> > (((bus) << 24) | ((devfn) << 16) | (offset))
> > #define TLP_COMP_STATUS(s) (((s) >> 13) & 7)
> > +#define TLP_BYTE_COUNT(s)(((s) >> 0) & 0xfff)
> > #define TLP_HDR_SIZE 3
> > #define TLP_LOOP 500
> >
> > @@ -69,14 +76,43 @@
> >
> > #define DWORD_MASK 3
> >
> > +#define S10_TLP_FMTTYPE_CFGRD0 0x05
> > +#define S10_TLP_FMTTYPE_CFGRD1 0x04
> > +#define S10_TLP_FMTTYPE_CFGWR0 0x45
> > +#define S10_TLP_FMTTYPE_CFGWR1 0x44
> > +
> > +enum altera_pcie_version {
> > + ALTERA_PCIE_V1 = 0,
> > + ALTERA_PCIE_V2,
> > +};
> > +
> > struct altera_pcie {
> > struct platform_device *pdev;
> > - void __iomem*cra_base; /* DT Cra */
> > + void __iomem*cra_base;
> > + void __iomem*hip_base;
> > int irq;
> > u8 root_bus_nr;
> > struct irq_domain *irq_domain;
> > struct resource bus_range;
> > struct list_headresources;
> > + const struct altera_pcie_data *pcie_data;
> > +};
> > +
> > +struct altera_pcie_data {
> > + int (*tlp_read_pkt)(struct altera_pcie *pcie, u32 *value);
> > + void (*tlp_write_pkt)(struct altera_pcie *pc
Re: [PATCH] auxdisplay: ht16k33: fix potential user-after-free on module unload
On Sat, 9 Feb 2019 01:15:22 +0100 Miguel Ojeda wrote: > On module unload/remove, we need to ensure that work does not run > after we have freed resources. Concretely, cancel_delayed_work() > may return while the callback function is still running. > > From kernel/workqueue.c: > > The work callback function may still be running on return, > unless it returns true and the work doesn't re-arm itself. > Explicitly flush or use cancel_delayed_work_sync() to wait on it. > > Link: > https://lore.kernel.org/lkml/20190204220952.30761-1-thesve...@googlemail.com/ > Reported-by: Sven Van Asbroeck > Signed-off-by: Miguel Ojeda > --- > drivers/auxdisplay/ht16k33.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c > index a43276c76fc6..21393ec3b9a4 100644 > --- a/drivers/auxdisplay/ht16k33.c > +++ b/drivers/auxdisplay/ht16k33.c > @@ -509,7 +509,7 @@ static int ht16k33_remove(struct i2c_client *client) > struct ht16k33_priv *priv = i2c_get_clientdata(client); > struct ht16k33_fbdev *fbdev = &priv->fbdev; > > - cancel_delayed_work(&fbdev->work); > + cancel_delayed_work_sync(&fbdev->work); > unregister_framebuffer(fbdev->info); > framebuffer_release(fbdev->info); > free_page((unsigned long) fbdev->buffer); Looks good Acked-by: Robin van der Gracht
Re: Licensing of include/linux/hash.h
On Mon, Feb 11, 2019 at 12:08:32AM +0100, Kristian Fiskerstrand wrote: > On 1/23/19 9:50 AM, Domenico Andreoli wrote: > > Ben Finney writes: > >> Domenico Andreoli writes: [...] > >>> the only knot left is now the license of hash.h > >>> > >>> This file is also present in the kernel [0] with an updated copyright > >>> but still without license. [...] > >> To know that work (that file) is free software, we need a clear grant of > >> some specific license, for that work. > >> > >> If the work is not free, it would be incorrect to have the work in Debian. > > > > Is it possible that for the kernel it is instead correct because it is, > > as whole, covered by its COPYING? > > > >> Alternatives, for complying with the Debian Free Software Guidelines with > >> this package, include: > >> > >> * Find a credible grant of license under some GPL-compatible free > >> license to that exact file. Document that explicit grant in the Debian > >> package. This demonstrates the work is DFSG-free. > >> > >> * Convince ???dwarves-dfsg??? upstream to replace that file with a > >> different > >> implementation (I don't know whether such an implementation exists) > >> under a license compatible with the same version of GNU GPL. Document > >> that explicit grant in the Debian package. This demonstrates the > >> modified work is DFSG-free. > >> > >> * Replace that file in Debian only, with a different implementation as > >> above. Document that explicit grant in the Debian package. This > >> demonstrates the modified Debian package is DFSG-free. > >> > >> * Move the work to the ???non-free??? area. > >> > >> * Remove the work altogether. > >> > >> Those are in descending order of (my recommended) preference. [...] > It was [pointed out] by one of our license group that [hash.h] is the > same that has a GPL-2+ in [fio] which has a signed-off-by. > > References: > [pointed out] > https://bugs.gentoo.org/677586#c1 > > [hash.h] > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c Yes, the Signed-off-by is from Jens Axboe (in CC) but he's not the original author, I guess he just copied the file as Arnaldo did. The file he committed has not any reference to the license. > [fio] > https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright I'm afraid that this entry in wrong. I'll seek confirmation with Martin Steigerwald. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, Mario successfully tested a kernel from your Git [1] on his T2080rdb today. Link to the log: https://gitlab.com/oshw-powerpc-notebook/T2080customizations/blob/master/kernel/dma_fix/kernel_dma_fix_log.txt He wrote: Please, note that all of the above kernel runs just fine with the T2080rdb, however did not had the time to test extensively (tested: login into MATE graphical desktop environment, used ArctiFox for opening couple of websites, then played Neverball). —— Cheers, Christian [1] http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
[PATCH v1 2/2] clk: mediatek: correct cpu clock name for MT8173 SoC
Change cpu clock name from ca57 to ca72 since MT8173 does use cortex-a72.
Signed-off-by: Seiya Wang
---
drivers/clk/mediatek/clk-mt8173.c | 4 ++--
include/dt-bindings/clock/mt8173-clk.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 96c292c3e440..deedeb3ea33b 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -533,7 +533,7 @@ static const char * const ca53_parents[] __initconst = {
"univpll"
};
-static const char * const ca57_parents[] __initconst = {
+static const char * const ca72_parents[] __initconst = {
"clk26m",
"armca15pll",
"mainpll",
@@ -542,7 +542,7 @@ static const char * const ca57_parents[] __initconst = {
static const struct mtk_composite cpu_muxes[] __initconst = {
MUX(CLK_INFRA_CA53SEL, "infra_ca53_sel", ca53_parents, 0x, 0, 2),
- MUX(CLK_INFRA_CA57SEL, "infra_ca57_sel", ca57_parents, 0x, 2, 2),
+ MUX(CLK_INFRA_CA72SEL, "infra_ca72_sel", ca72_parents, 0x, 2, 2),
};
static const struct mtk_composite top_muxes[] __initconst = {
diff --git a/include/dt-bindings/clock/mt8173-clk.h
b/include/dt-bindings/clock/mt8173-clk.h
index 8aea623dd518..f7e5356fd602 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -194,7 +194,7 @@
#define CLK_INFRA_PMICWRAP 11
#define CLK_INFRA_CLK_13M 12
#define CLK_INFRA_CA53SEL 13
-#define CLK_INFRA_CA57SEL 14
+#define CLK_INFRA_CA72SEL 14
#define CLK_INFRA_NR_CLK15
/* PERI_SYS */
--
2.14.1
Re: linux-next: Fixes tag needs some work in the tip tree
* Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> f6783319737f ("sched/fair: Fix insertion in rq->leaf_cfs_rq_list")
>
> Fixes tag
>
> Fixes: 9c2791f936ef ("Fix hierarchical order in rq->leaf_cfs_rq_list")
>
> has these problem(s):
>
> - Subject does not match target commit subject
It's still a unique substring of the original subject, so not a big deal
IMO.
Thanks,
Ingo
[PATCH v1 1/2] arm64: dts: mt8173: correct cpu type of cpu2 and cpu3 to cortex-a72
The cpu type of cpu2 and cpu3 should be cortex-a72, not cortex-a57.
Signed-off-by: Seiya Wang
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 44374c506a1c..99675c51577a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -178,12 +178,12 @@
cpu2: cpu@100 {
device_type = "cpu";
- compatible = "arm,cortex-a57";
+ compatible = "arm,cortex-a72";
reg = <0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
#cooling-cells = <2>;
- clocks = <&infracfg CLK_INFRA_CA57SEL>,
+ clocks = <&infracfg CLK_INFRA_CA72SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cluster1_opp>;
@@ -191,12 +191,12 @@
cpu3: cpu@101 {
device_type = "cpu";
- compatible = "arm,cortex-a57";
+ compatible = "arm,cortex-a72";
reg = <0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
#cooling-cells = <2>;
- clocks = <&infracfg CLK_INFRA_CA57SEL>,
+ clocks = <&infracfg CLK_INFRA_CA72SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cluster1_opp>;
--
2.14.1
Re: [PATCH 0/2] Subject: [PATCH 0/2] clocksource: exynos_mct: Clear timer interrupt when shutting down
Hi Stuart On 2019-02-10 23:51, Stuart Menefy wrote: > When debugging suspend problems on Exynos 5260, I had a large number > of debugging prints going to the serial port after interrupts > had been disabled but before the timer interrupt was shutdown. This > was long enough for a timer tick to occur, but as interrupts were > disabled the ISR didn't run, and so the interrupt wasn't cleared. > Later when the timer was shutdown the interrupt was left asserted and > so the wfi at the heart of the suspend code didn't wait, causing > the suspend to fail. > > Currently the code which stops the timer when it is on one-shot mode > and the interrupt occurs is in exynos4_mct_tick_clear(), meaning if we > called this from the shutdown code exynos4_mct_tick_stop() could be > called twice. So first restructure the existing code, so the check for > one-shot mode and stopping the timer is moved to the ISR, leaving > exynos4_mct_tick_clear() just clearing the interrupt flag. > > Once this has been done simply call exynos4_mct_tick_clear() from > set_state_shutdown(). This also fixes mysterious suspend failures on Odroid XU3/XU4/HC1 :) Tested-by: Marek Szyprowski > Stuart Menefy (2): > clocksource: exynos_mct: Move one-shot check from tick clear to ISR > clocksource: exynos_mct: Clear timer interrupt when shutdown > > drivers/clocksource/exynos_mct.c | 23 --- > 1 file changed, 12 insertions(+), 11 deletions(-) > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
* Waiman Long wrote: > On 02/10/2019 09:00 PM, Waiman Long wrote: > > As the generic rwsem-xadd code is using the appropriate acquire and > > release versions of the atomic operations, the arch specific rwsem.h > > files will not be that much faster than the generic code as long as the > > atomic functions are properly implemented. So we can remove those arch > > specific rwsem.h and stop building asm/rwsem.h to reduce maintenance > > effort. > > > > Currently, only x86, alpha and ia64 have implemented architecture > > specific fast paths. I don't have access to alpha and ia64 systems for > > testing, but they are legacy systems that are not likely to be updated > > to the latest kernel anyway. > > > > By using a rwsem microbenchmark, the total locking rates on a 4-socket > > 56-core 112-thread x86-64 system before and after the patch were as > > follows (mixed means equal # of read and write locks): > > > > Before Patch After Patch > ># of Threads wlock rlock mixed wlock rlock mixed > > - - - - - - > > 127,373 29,409 28,17028,773 30,164 29,276 > > 2 7,697 14,922 1,703 7,435 15,167 1,729 > > 4 6,987 14,285 1,490 7,181 14,438 1,330 > > 8 6,650 13,652 761 6,918 13,796 718 > >16 6,434 15,729 713 6,554 16,030 625 > >32 5,590 15,312 552 6,124 15,344 471 > >64 5,980 15,478 61 5,668 15,509 58 > > > > There were some run-to-run variations for the multi-thread tests. For > > x86-64, using the generic C code fast path seems to be a liitle bit > > faster than the assembly version especially for read-lock and when lock > > contention is low. Looking at the assembly version of the fast paths, > > there are assembly to/from C code wrappers that save and restore all > > the callee-clobbered registers (7 registers on x86-64). The assembly > > generated from the generic C code doesn't need to do that. That may > > explain the slight performance gain here. > > > > The generic asm rwsem.h can also be merged into kernel/locking/rwsem.h > > as no other code other than those under kernel/locking needs to access > > the internal rwsem macros and functions. > > > > Signed-off-by: Waiman Long > > I have decided to break the rwsem patchset that I sent out on last > Thursday into 3 parts. This patch is part 0 as it touches a number of > arch specific files and so have the widest distribution. I would like to > get it merged first. Part 1 will be patches 1-10 (except 4) of my > original rwsem patchset. This part moves things around, adds more > debugging capability and lays the ground work for the next part. Part 2 > will contains the remaining patches which are the real beef of the whole > patchset. Sounds good to me - I've merged this patch, will push it out after testing. Thanks, Ingo
[PATCH] tty: pty: Fix race condition between release_one_tty and pty_write
From: Sahara
Especially when a linked tty is used such as pty, the linked tty
port's buf works have not been cancelled while master tty port's
buf work has been cancelled. Since release_one_tty and flush_to_ldisc
run in workqueue threads separately, when pty_cleanup happens and
link tty port is freed, flush_to_ldisc tries to access freed port
and port->itty, eventually it causes a panic.
This patch utilizes the magic value with holding the tty_mutex to
check if the tty->link is valid.
Fixes: 2b022ab7542d ("pty: cancel pty slave port buf's work in tty_release")
Signed-off-by: Sahara
---
drivers/tty/pty.c| 7 +++
drivers/tty/tty_io.c | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 00099a84..ef72031 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -116,6 +116,12 @@ static int pty_write(struct tty_struct *tty, const
unsigned char *buf, int c)
if (tty->stopped)
return 0;
+ mutex_lock(&tty_mutex);
+ if (to->magic != TTY_MAGIC) {
+ mutex_unlock(&tty_mutex);
+ return -EIO;
+ }
+
if (c > 0) {
spin_lock_irqsave(&to->port->lock, flags);
/* Stuff the data into the input queue of the other end */
@@ -125,6 +131,7 @@ static int pty_write(struct tty_struct *tty, const unsigned
char *buf, int c)
tty_flip_buffer_push(to->port);
spin_unlock_irqrestore(&to->port->lock, flags);
}
+ mutex_unlock(&tty_mutex);
return c;
}
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 23c6fd2..6c4a206 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1446,10 +1446,13 @@ static void release_one_tty(struct work_struct *work)
struct tty_driver *driver = tty->driver;
struct module *owner = driver->owner;
+ mutex_lock(&tty_mutex);
if (tty->ops->cleanup)
tty->ops->cleanup(tty);
tty->magic = 0;
+ mutex_unlock(&tty_mutex);
+
tty_driver_kref_put(driver);
module_put(owner);
--
2.7.4
[GIT PULL] s390 patches for 5.0 #3
Hi Linus,
please pull s390 fixes for 5.0-rc7
The following changes since commit f17b5f06cb92ef2250513a1e154c47b78df07d40:
Linux 5.0-rc4 (2019-01-27 15:18:05 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.0-3
for you to fetch changes up to 614db26954ff08fa8e92b04100e31ebc04b817cf:
Revert "s390/pci: remove bit_lock usage in interrupt handler" (2019-02-07
11:56:29 +0100)
s390 update with bug fixes for 5.0-rc6
- Fix specification exception on z196 during ap probe
- A fix for suspend-to-disk, the VMAP stack patch broke the
swsusp_arch_suspend function
- The EMC CKD ioctl of the dasd driver needs an additional size
check for user space data
- Revert an incorrect patch for the PCI base code that removed
a bit lock that turned out to be required after all
Harald Freudenberger (1):
s390/zcrypt: fix specification exception on z196 during ap probe
Martin Schwidefsky (1):
s390/suspend: fix stack setup in swsusp_arch_suspend
Sebastian Ott (1):
Revert "s390/pci: remove bit_lock usage in interrupt handler"
Stefan Haberland (1):
s390/dasd: fix using offset into zero size array error
arch/s390/kernel/swsusp.S | 4 ++--
arch/s390/pci/pci.c| 4 +++-
drivers/s390/block/dasd_eckd.c | 8
drivers/s390/crypto/ap_bus.c | 3 ++-
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kernel/swsusp.S b/arch/s390/kernel/swsusp.S
index 537f97f..b6796e6 100644
--- a/arch/s390/kernel/swsusp.S
+++ b/arch/s390/kernel/swsusp.S
@@ -30,10 +30,10 @@
.section .text
ENTRY(swsusp_arch_suspend)
lg %r1,__LC_NODAT_STACK
- aghi%r1,-STACK_FRAME_OVERHEAD
stmg%r6,%r15,__SF_GPRS(%r1)
+ aghi%r1,-STACK_FRAME_OVERHEAD
stg %r15,__SF_BACKCHAIN(%r1)
- lgr %r1,%r15
+ lgr %r15,%r1
/* Store FPU registers */
brasl %r14,save_fpu_regs
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index a966d7b..4266a4d 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -382,7 +382,9 @@ static void zpci_irq_handler(struct airq_struct *airq)
if (ai == -1UL)
break;
inc_irq_stat(IRQIO_MSI);
+ airq_iv_lock(aibv, ai);
generic_handle_irq(airq_iv_get_data(aibv, ai));
+ airq_iv_unlock(aibv, ai);
}
}
}
@@ -408,7 +410,7 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int
type)
zdev->aisb = aisb;
/* Create adapter interrupt vector */
- zdev->aibv = airq_iv_create(msi_vecs, AIRQ_IV_DATA);
+ zdev->aibv = airq_iv_create(msi_vecs, AIRQ_IV_DATA | AIRQ_IV_BITLOCK);
if (!zdev->aibv)
return -ENOMEM;
diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
index 4e7b55a..6e294b4 100644
--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -4469,6 +4469,14 @@ static int dasd_symm_io(struct dasd_device *device, void
__user *argp)
usrparm.psf_data &= 0x7fffULL;
usrparm.rssd_result &= 0x7fffULL;
}
+ /* at least 2 bytes are accessed and should be allocated */
+ if (usrparm.psf_data_len < 2) {
+ DBF_DEV_EVENT(DBF_WARNING, device,
+ "Symmetrix ioctl invalid data length %d",
+ usrparm.psf_data_len);
+ rc = -EINVAL;
+ goto out;
+ }
/* alloc I/O data area */
psf_data = kzalloc(usrparm.psf_data_len, GFP_KERNEL | GFP_DMA);
rssd_result = kzalloc(usrparm.rssd_result_len, GFP_KERNEL | GFP_DMA);
diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index 48ea000..5a69974 100644
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -248,7 +248,8 @@ static inline int ap_test_config(unsigned int *field,
unsigned int nr)
static inline int ap_test_config_card_id(unsigned int id)
{
if (!ap_configuration) /* QCI not supported */
- return 1;
+ /* only ids 0...3F may be probed */
+ return id < 0x40 ? 1 : 0;
return ap_test_config(ap_configuration->apm, id);
}
Re: [PATCH RESEND 1/3] x86/boot: Add bit fields into xloadflags for 5-level kernel checking
Thanks for reviewing. I was in vacation, sorry for late reply.
On 01/29/19 at 09:05pm, Thomas Gleixner wrote:
> On Fri, 25 Jan 2019, Baoquan He wrote:
>
> > Add two bit fields XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel.
>
> These are not bit fields. These are simple bits.
Indeed, they are only xloadflags bits, will change. Thanks.
>
> > Bit XLF_5LEVEL indicates if 5-level related code is contained
> > in this kernel.
> > Bit XLF_5LEVEL_ENABLED indicates if CONFIG_X86_5LEVEL=y is set.
>
> I'm confused.
>
> > - .word XLF0 | XLF1 | XLF23 | XLF4
> > +#ifdef CONFIG_X86_64
> > +#ifdef CONFIG_X86_5LEVEL
> > +#define XLF56 (XLF_5LEVEL|XLF_5LEVEL_ENABLED)
> > +#else
> > +#define XLF56 XLF_5LEVEL
> > +#endif
> > +#else
> > +#define XLF56 0
> > +#endif
> > +
> > + .word XLF0 | XLF1 | XLF23 | XLF4 | XLF56
>
> So this actually stores the bits, but looking at the following patch which
> fixes the real issue:
>
> > + if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
> > + pr_err("Can not jump to old 4-level kernel from 5-level
> > kernel.\n");
> > + return ret;
> > + }
>
> So what is XLF_5LEVEL_ENABLED used for and why does it exist at all?
Yes, this is a little bit confusing. I explained it in the v1 cover
letter:
http://lists.infradead.org/pipermail/kexec/2018-August/021419.html
As told at above, XLF_5LEVEL marks the new kernel containing 5level
code, while XLF_5LEVEL_ENABLED marking the CONFIG_X86_5LEVEL option
enabling. Hence if XLF_5LEVEL is set, XLF_5LEVEL_ENABLED not, means it's
new kernel but can't be switched into 5-level.
For kexec_load and kexec_file_load, there's difference in loading
behaviour. kexec_load will search available area top down to put
kernel in system RAM, we need check if the kexec-ed kernel is in
leve-5 paging mode, and limit the loading postion below 64 TB if
not. But for kexec_file_load, it's searching area bottom up to put
kernel, most of time area found below 4G. We don't have worry about the
kexec_file_load interface which implements the loading functionality in
kernel. That's why the XLF_5LEVEL_ENABLED bit is not used in this kernel
patch set, I would like to post patch to kexec-tools for kexec_load
after these patches have been accepted.
I ever tried to unify the behavious of these two interfaces on loading
kernel, to make both kexec_load and kexec_file_load search and put
kernel top to down, but that involves many lines of code change, seems
people are worried about it and hesitated to offere ack, I just gave up.
Please check below link:
https://lore.kernel.org/lkml/20180718024944.577-1-...@redhat.com/T/#u
Sorry for the inconvenience because of my missing explanation.
Thanks
Baoquan
[PATCH] Fix resume for ELAN2097 touchscreen.
Commit 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system resume")
fixes the resume behavior of several devices. However, this breaks the
resume on the ELAN2097, used on Dell Inspiron laptops, with the same flood
of messages:
[27009.817110] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report
(67/65535)
[27009.818867] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report
(67/65535)
[27009.820623] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report
(67/65535)
This change adds a new I2C_HID_QUIRK_RESET_AFTER_RESUME and replaces the
original reset behavior for this device.
Signed-off-by: Jim Broadus
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/i2c-hid/i2c-hid-core.c | 20 ++--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 24f846d67478..38cc7033712a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -387,6 +387,7 @@
#define USB_DEVICE_ID_TOSHIBA_CLICK_L9W0x0401
#define USB_DEVICE_ID_HP_X20x074d
#define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
+#define USB_DEVICE_ID_ELAN2097 0x2504
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
b/drivers/hid/i2c-hid/i2c-hid-core.c
index c5edfa966343..fdbad29b4406 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -50,6 +50,7 @@
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
#define I2C_HID_QUIRK_NO_RUNTIME_PMBIT(2)
#define I2C_HID_QUIRK_DELAY_AFTER_SLEEPBIT(3)
+#define I2C_HID_QUIRK_RESET_AFTER_RESUME BIT(4)
/* flags */
#define I2C_HID_STARTED0
@@ -181,6 +182,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_NO_RUNTIME_PM },
{ I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
I2C_HID_QUIRK_NO_RUNTIME_PM },
+ { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN2097,
+I2C_HID_QUIRK_RESET_AFTER_RESUME },
{ 0, 0 }
};
@@ -1279,12 +1282,17 @@ static int i2c_hid_resume(struct device *dev)
enable_irq(client->irq);
- /* Instead of resetting device, simply powers the device on. This
-* solves "incomplete reports" on Raydium devices 2386:3118 and
-* 2386:4B33 and fixes various SIS touchscreens no longer sending
-* data after a suspend/resume.
-*/
- ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
+ if (ihid->quirks & I2C_HID_QUIRK_RESET_AFTER_RESUME) {
+ ret = i2c_hid_hwreset(client);
+ } else {
+ /* Instead of resetting device, simply powers the device on.
+* This solves "incomplete reports" on Raydium devices 2386:3118
+* and 2386:4B33 and fixes various SIS touchscreens no longer
+* sending data after a suspend/resume.
+*/
+ ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
+ }
+
if (ret)
return ret;
--
2.20.1
Re: [PATCHv12 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
Hi Hean-Loong, Ong
Patch looks good to me, but there is a few trivial
things I spotted while browsing the code.
See below.
Sam
> +++ b/drivers/gpu/drm/ivip/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the drm device driver. This driver provides support for the
> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> +
> +obj-$(CONFIG_DRM_IVIP) += ivip.o
> +ivip-objs := intel_vip_of.o intel_vip_core.o \
> + intel_vip_conn.o
You could use:
ivip-y := intel_vip_of.o intel_vip_core.o
ivip-y += intel_vip_conn.o
Using "ivip-y" is the recommend syntax today.
And using "+=" you get rid of the ugly "\" to continue a line.
(Some people prefer "\" in makefiles, but there are not needed)
> +++ b/drivers/gpu/drm/ivip/intel_vip_core.c
> @@ -0,0 +1,189 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * intel_vip_core.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * Authors:
> + * Walter Goossens
> + * Thomas Chou
> + * Chris Rauer
> + * Ong, Hean-Loong
> + *
> + */
> +
> +#include
Please do not use drmP.h in new drivers, we try to get rid of this file.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Sort the list of include files.
(Looks like this was properly done before, and only one file is out of palce)
> +static void intelvipfb_enable(struct drm_simple_display_pipe *pipe,
> +struct drm_crtc_state *crtc_state, struct drm_plane_state *
> +plane_state)
Fix indent. The parameters on second line and following should be aligned
below the opening paranthesis.
Use tab(s) + spaces to align properly.
> +void intelvipfb_display_pipe_update(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *old_state)
Align parameter
> +}
> +EXPORT_SYMBOL(intelvipfb_display_pipe_update);
> +
> +static struct drm_simple_display_pipe_funcs fbpriv_funcs = {
> + .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
> + .update = intelvipfb_display_pipe_update,
> + .enable = intelvipfb_enable,
> + .disable = intelvipfb_disable,
> +};
> +
> +
> +int intelvipfb_probe(struct device *dev)
> +{
> + int retval;
> + struct drm_device *drm;
> + struct intelvipfb_priv *fbpriv = dev_get_drvdata(dev);
> +
> + struct drm_connector *connector;
> + u32 formats[] = {DRM_FORMAT_XRGB};
> +
> + drm = fbpriv->drm;
> +
> + drm->dev_private = fbpriv;
It would be simpler to just pass fbpriv as a parameter.
There is only one user of intelvipfb_probe() so no need
to avoid it.
Also it would be more logical to set drm = fbpriv->drm; where memory are
allocated.
> +
> + intelvipfb_setup_mode_config(drm);
> +
> + connector = intelvipfb_conn_setup(drm);
> + if (!connector) {
> + dev_err(drm->dev, "Connector setup failed\n");
> + goto err_mode_config;
> + }
> +
> + retval = drm_simple_display_pipe_init(drm,
> + &fbpriv->pipe,
> + &fbpriv_funcs,
> + formats,
> + ARRAY_SIZE(formats),
> + NULL, connector);
Consider indent, where subsequent parameters are aligned right after the
opening '('.
> +
> + if (retval < 0) {
> + dev_err(drm->dev, "Cannot setup simple display pipe\n");
> + goto err_mode_config;
> + }
> +
> + drm_mode_config_reset(drm);
> +
> + drm_dev_register(drm, 0);
> +
> + drm_fbdev_generic_setup(drm, 32);
> +
> + dev_info(drm->dev, "ivip: Successfully created fb\n");
> +
> + return retval;
> +
> +err_mode_config:
> +
> + drm_mode_config_cleanup(drm);
> + return -ENODEV;
> +}
> +
> diff --git a/drivers/gpu/drm/ivip/intel_vip_of.c
> b/drivers/gpu/drm/ivip/intel_vip_of.c
> new file mode 100644
> index 000..c899e30
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_of.c
> @@ -0,0 +1,181 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * intel_vip_of.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
The need for this file confuses me.
It does not include only "of" related stuff, but also generic device driver
stuff.
Maybe merge with intel_vip_core.c?
And rename that file to intel_vip_drv.c?
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * Authors:
> + * Ong, Hean-Loong
> + *
> + */
> +#include
Drop use of drm
[PATCH 1/2] ASoC: pcm3060: Add soft reset on probe
Softly reset registers values on module probe
Signed-off-by: Kirill Marinushkin
---
sound/soc/codecs/pcm3060.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/codecs/pcm3060.c b/sound/soc/codecs/pcm3060.c
index 6714aa8d9026..543cb86fd764 100644
--- a/sound/soc/codecs/pcm3060.c
+++ b/sound/soc/codecs/pcm3060.c
@@ -287,6 +287,14 @@ int pcm3060_probe(struct device *dev)
int rc;
struct pcm3060_priv *priv = dev_get_drvdata(dev);
+ /* soft reset */
+ rc = regmap_update_bits(priv->regmap, PCM3060_REG64,
+ PCM3060_REG_MRST, 0);
+ if (rc) {
+ dev_err(dev, "failed to reset component, rc=%d\n", rc);
+ return rc;
+ }
+
if (dev->of_node)
pcm3060_parse_dt(dev->of_node, priv);
--
2.13.6
[PATCH 2/2] ASoC: pcm3060: Add clock select
ADC and DAC can be clocked from separate or same sources CLK1 and CLK2.
By default, ADC is clocked from CLK1, and DAC - from CLK2.
This commits allows sound cards to selest a proper clock source during
`hw_params()` via `snd_soc_dai_set_sysclk()`. It makes possible to have a
single clock source for both ADC and DAC.
Signed-off-by: Kirill Marinushkin
---
sound/soc/codecs/pcm3060.c | 27 +++
sound/soc/codecs/pcm3060.h | 5 +
2 files changed, 32 insertions(+)
diff --git a/sound/soc/codecs/pcm3060.c b/sound/soc/codecs/pcm3060.c
index 543cb86fd764..32b26f1c2282 100644
--- a/sound/soc/codecs/pcm3060.c
+++ b/sound/soc/codecs/pcm3060.c
@@ -18,12 +18,39 @@ static int pcm3060_set_sysclk(struct snd_soc_dai *dai, int
clk_id,
{
struct snd_soc_component *comp = dai->component;
struct pcm3060_priv *priv = snd_soc_component_get_drvdata(comp);
+ unsigned int reg;
+ unsigned int val;
if (dir != SND_SOC_CLOCK_IN) {
dev_err(comp->dev, "unsupported sysclock dir: %d\n", dir);
return -EINVAL;
}
+ switch (clk_id) {
+ case PCM3060_CLK_DEF:
+ val = 0;
+ break;
+
+ case PCM3060_CLK1:
+ val = (dai->id == PCM3060_DAI_ID_DAC ? PCM3060_REG_CSEL : 0);
+ break;
+
+ case PCM3060_CLK2:
+ val = (dai->id == PCM3060_DAI_ID_DAC ? 0 : PCM3060_REG_CSEL);
+ break;
+
+ default:
+ dev_err(comp->dev, "unsupported sysclock id: %d\n", clk_id);
+ return -EINVAL;
+ }
+
+ if (dai->id == PCM3060_DAI_ID_DAC)
+ reg = PCM3060_REG67;
+ else
+ reg = PCM3060_REG72;
+
+ regmap_update_bits(priv->regmap, reg, PCM3060_REG_CSEL, val);
+
priv->dai[dai->id].sclk_freq = freq;
return 0;
diff --git a/sound/soc/codecs/pcm3060.h b/sound/soc/codecs/pcm3060.h
index 6a027b4a845d..75931c9a9d85 100644
--- a/sound/soc/codecs/pcm3060.h
+++ b/sound/soc/codecs/pcm3060.h
@@ -17,6 +17,11 @@ extern const struct regmap_config pcm3060_regmap;
#define PCM3060_DAI_ID_ADC 1
#define PCM3060_DAI_IDS_NUM2
+/* ADC and DAC can be clocked from separate or same sources CLK1 and CLK2 */
+#define PCM3060_CLK_DEF0 /* default: CLK1->ADC, CLK2->DAC */
+#define PCM3060_CLK1 1
+#define PCM3060_CLK2 2
+
struct pcm3060_priv_dai {
bool is_master;
unsigned int sclk_freq;
--
2.13.6
RE: [v5 2/2] arm64: dts: lx2160a: add sata node support
>-Original Message-
>From: Shawn Guo
>Sent: 2019年2月11日 13:39
>To: Peng Ma
>Cc: ax...@kernel.dk; mark.rutl...@arm.com; Andy Tang
>; devicet...@vger.kernel.org;
>linux-kernel@vger.kernel.org; Leo Li ;
>linux-...@vger.kernel.org; robh...@kernel.org;
>linux-arm-ker...@lists.infradead.org
>Subject: Re: [v5 2/2] arm64: dts: lx2160a: add sata node support
>
>On Mon, Feb 11, 2019 at 02:53:18AM +, Peng Ma wrote:
>>
>>
>> >-Original Message-
>> >From: Shawn Guo
>> >Sent: 2019年2月1日 14:30
>> >To: Peng Ma
>> >Cc: ax...@kernel.dk; robh...@kernel.org; mark.rutl...@arm.com; Leo Li
>> >; linux-...@vger.kernel.org;
>> >devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >linux-arm-ker...@lists.infradead.org; Andy Tang
>> >Subject: Re: [v5 2/2] arm64: dts: lx2160a: add sata node support
>> >
>> >On Fri, Jan 25, 2019 at 08:10:13AM +, Peng Ma wrote:
>> >> Add SATA device nodes for fsl-lx2160a and enable support for QDS
>> >> and RDB boards.
>> >>
>> >> Signed-off-by: Peng Ma
>> >> ---
>> >> changed for V5:
>> >> - no change
>> >>
>> >> arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts | 16 +++
>> >> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 16 +++
>> >> arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 44
>> >+
>> >> 3 files changed, 76 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> >> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> >> index 99a22ab..1a5acf6 100644
>> >> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> >> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> >> @@ -95,6 +95,22 @@
>> >> };
>> >> };
>> >>
>> >> +&sata0 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&sata1 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&sata2 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&sata3 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> &uart0 {
>> >> status = "okay";
>> >> };
>> >> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> >> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> >> index 6481e5f..5b6799e 100644
>> >> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> >> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> >> @@ -102,6 +102,22 @@
>> >> };
>> >> };
>> >>
>> >> +&sata0 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&sata1 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&sata2 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&sata3 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> &uart0 {
>> >> status = "okay";
>> >> };
>> >> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> >> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> >> index a79f5c1..592034b 100644
>> >> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> >> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> >> @@ -671,6 +671,50 @@
>> >> status = "disabled";
>> >> };
>> >>
>> >> + sata0: sata@320 {
>> >> + compatible = "fsl,lx2160a-ahci";
>> >
>> >Has the kernel driver been patched to probe the compatible?
>> >
>> >Shawn
>> Yes, the driver patch is
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
>>
>hwork.ozlabs.org%2Fpatch%2F1034083%2F&data=02%7C01%7Cpeng.ma
>%40nxp
>> .com%7C8daea4e4b2ea419cb2a008d68fe34f51%7C686ea1d3bc2b4c6fa92c
>d99c5c30
>>
>1635%7C0%7C0%7C636854603794170576&sdata=z3ic8%2FAS10NcFjdP
>eJFpnFoo
>> R2Yo4oYO%2FAASr7r2Lhg%3D&reserved=0
>
>Ping me when the driver patch is accepted. Ideally, we only accept dts
>changes after the driver counterpart lands on mainline.
>
>Shawn
[Peng Ma] got it, thanks.
BR
Peng
RE: [External] Re: [PATCH v3 0/5] Optimize writecache when using pmem as cache
> From: Mikulas Patocka
> Sent: Monday, February 04, 2019 7:28 PM
> On Thu, 31 Jan 2019, Huaisheng Ye wrote:
>
> > From: Huaisheng Ye
> >
> > This patch set could be used for dm-writecache when use persistent
> > memory as cache data device.
> >
> > Patch 1 and 2 go towards removing unused parameter and codes which
> > actually doesn't really work.
>
> I agree that there is some unused variables and code, but I would let it
> be as it is. The processors can write data to persistent memory either by
> using non-temporal stores (the movnti instruction) or by normal stores
> followed by the clwb instruction.
>
> Currently, the movnti instruction is faster - however, it may be possible
> that with some newer processors, the clwb instruction could be faster -
> and in that case, we need the code that you have removed.
>
> I would like to keep both flush strategies around (movnti and clwb), so
> that we can test how do they perform on various processors.
> Unfortunatelly, some upstream developers hate code with #ifdefs :-(
>
> Note that compiler optimizations already remove the unused parameter and
> the impossible code behind "if (WC_MODE_PMEM(wc)) if (!WC_MODE_PMEM(wc))".
Hi Mikulas,
Thanks for your reply, now I could understand the code flow of dm-writecache
better
than before.
In the process of playing around the code, I found that writecache_flush would
try
to free earlier committed entry with lower seq-count. More seriously is that,
writecache_flush
must check it for all entries which hasn't been committed. That's a lot of work
to do when
there are many entries need to be flushed.
I have a plan for writecache_map to avoid using free entry when the committed
writecache
has been hit. Does it make sense to simple the code flow, especially for saving
additional rb-tree
node insertion and free steps?
Cheers,
Huaisheng Ye
> > Patch 3 and 4 are targeted at solving problem fn ctr failed to work
> > due to invalid magic or version, which is caused by the super block
> > of pmem has messy data stored.
>
> LVM zeros the beginning of new logical volumes, so there should be no
> problem with it. If the user wants to use the writecache target without
> LVM, he should zero the superblock with dd if=/dev/zero of=/dev/pmem0
> bs=4k count=1
>
> Note that other device mapper targets also follow this policy - for
> example see drivers/md/dm-snap-persistent.c:
> if (le32_to_cpu(dh->magic) == 0) {
> *new_snapshot = 1;
> return 0;
> }
>
> if (le32_to_cpu(dh->magic) != SNAP_MAGIC) {
> DMWARN("Invalid or corrupt snapshot");
> r = -ENXIO;
> goto bad;
> }
>
> So, I think there is no need for these patches - dm-writecache just does
> what others targets do.
>
> > Patch 5 is used for getting the status of seq_count.
>
> It may be accepted if other LVM team members find some use for this value.
>
> Mikulas
>
> > Changes Since v2:
> > - seq_count is important for flush operations, output it within
> > status
> > for debugging and analyzing code behavior.
> > [1]: https://lkml.org/lkml/2019/1/3/43
> > [2]: https://lkml.org/lkml/2019/1/9/6
> >
> > Huaisheng Ye (5):
> > dm-writecache: remove unused size to writecache_flush_region
> > dm-writecache: get rid of memory_data flush to writecache_flush_entry
> > dm-writecache: expand pmem_reinit for struct dm_writecache
> > Documentation/device-mapper: add optional parameter reinit
> > dm-writecache: output seq_count within status
> >
> > Documentation/device-mapper/writecache.txt | 4
> > drivers/md/dm-writecache.c | 23 +--
> > 2 files changed, 17 insertions(+), 10 deletions(-)
> >
> > --
> > 1.8.3.1
> >
> >
linux-next: manual merge of the akpm tree with the mips tree
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/mips/mm/c-r4k.c
between commit:
3315b6b336c8 ("MIPS: Delete unused flush_cache_sigtramp()")
from the mips tree and commit:
"arch/mips/mm/c-r4k.c: do not use mmap_sem for gup_fast()"
from the akpm tree.
I fixed it up (the former removed the function modified by the latter, so
I just dropped the latter patch) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
pgpqSnjQDfuMs.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH 4/4] mm: Add merge page notifier
On 2019/2/5 2:15, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Because the implementation was limiting itself to only providing hints on
> pages huge TLB order sized or larger we introduced the possibility for free
> pages to slip past us because they are freed as something less then
> huge TLB in size and aggregated with buddies later.
>
> To address that I am adding a new call arch_merge_page which is called
> after __free_one_page has merged a pair of pages to create a higher order
> page. By doing this I am able to fill the gap and provide full coverage for
> all of the pages huge TLB order or larger.
>
> Signed-off-by: Alexander Duyck
> ---
> arch/x86/include/asm/page.h | 12
> arch/x86/kernel/kvm.c | 28
> include/linux/gfp.h |4
> mm/page_alloc.c |2 ++
> 4 files changed, 46 insertions(+)
>
> diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
> index 4487ad7a3385..9540a97c9997 100644
> --- a/arch/x86/include/asm/page.h
> +++ b/arch/x86/include/asm/page.h
> @@ -29,6 +29,18 @@ static inline void arch_free_page(struct page *page,
> unsigned int order)
> if (static_branch_unlikely(&pv_free_page_hint_enabled))
> __arch_free_page(page, order);
> }
> +
> +struct zone;
> +
> +#define HAVE_ARCH_MERGE_PAGE
> +void __arch_merge_page(struct zone *zone, struct page *page,
> +unsigned int order);
> +static inline void arch_merge_page(struct zone *zone, struct page *page,
> +unsigned int order)
> +{
> + if (static_branch_unlikely(&pv_free_page_hint_enabled))
> + __arch_merge_page(zone, page, order);
> +}
> #endif
>
> #include
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 09c91641c36c..957bb4f427bb 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -785,6 +785,34 @@ void __arch_free_page(struct page *page, unsigned int
> order)
> PAGE_SIZE << order);
> }
>
> +void __arch_merge_page(struct zone *zone, struct page *page,
> +unsigned int order)
> +{
> + /*
> + * The merging logic has merged a set of buddies up to the
> + * KVM_PV_UNUSED_PAGE_HINT_MIN_ORDER. Since that is the case, take
> + * advantage of this moment to notify the hypervisor of the free
> + * memory.
> + */
> + if (order != KVM_PV_UNUSED_PAGE_HINT_MIN_ORDER)
> + return;
> +
> + /*
> + * Drop zone lock while processing the hypercall. This
> + * should be safe as the page has not yet been added
> + * to the buddy list as of yet and all the pages that
> + * were merged have had their buddy/guard flags cleared
> + * and their order reset to 0.
> + */
> + spin_unlock(&zone->lock);
> +
> + kvm_hypercall2(KVM_HC_UNUSED_PAGE_HINT, page_to_phys(page),
> +PAGE_SIZE << order);
> +
> + /* reacquire lock and resume freeing memory */
> + spin_lock(&zone->lock);
> +}
> +
> #ifdef CONFIG_PARAVIRT_SPINLOCKS
>
> /* Kick a cpu by its apicid. Used to wake up a halted vcpu */
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index fdab7de7490d..4746d5560193 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -459,6 +459,10 @@ static inline struct zonelist *node_zonelist(int nid,
> gfp_t flags)
> #ifndef HAVE_ARCH_FREE_PAGE
> static inline void arch_free_page(struct page *page, int order) { }
> #endif
> +#ifndef HAVE_ARCH_MERGE_PAGE
> +static inline void
> +arch_merge_page(struct zone *zone, struct page *page, int order) { }
> +#endif
> #ifndef HAVE_ARCH_ALLOC_PAGE
> static inline void arch_alloc_page(struct page *page, int order) { }
> #endif
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c954f8c1fbc4..7a1309b0b7c5 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -913,6 +913,8 @@ static inline void __free_one_page(struct page *page,
> page = page + (combined_pfn - pfn);
> pfn = combined_pfn;
> order++;
> +
> + arch_merge_page(zone, page, order);
Not a proper place AFAICS.
Assume we have an order-8 page being sent here for merge and its order-8
buddy is also free, then order++ became 9 and arch_merge_page() will do
the hint to host on this page as an order-9 page, no problem so far.
Then the next round, assume the now order-9 page's buddy is also free,
order++ will become 10 and arch_merge_page() will again hint to host on
this page as an order-10 page. The first hint to host became redundant.
I think the proper place is after the done_merging tag.
BTW, with arch_merge_page() at the proper place, I don't think patch3/4
is necessary - any freed page will go through merge anyway, we won't
lose any hint opportunity. Or do I miss anything?
> }
> if (max_order < MAX_ORDER) {
> /* If we are here, it means order is >= pageblock_orde
Re: [PATCH v2 15/28] thunderbolt: Deactivate all paths before restarting them
On Wed, Feb 06, 2019 at 04:17:25PM +0300, Mika Westerberg wrote: > We can't be sure the paths are actually properly deactivated when a > tunnel is restarted after resume. Why can't we be sure? Please provide proper reasoning. > So instead of marking all paths as > inactive we go ahead and deactivate them explicitly. This seems like a bad idea if the root partition is on a Thunderbolt- attached drive, the system is waking from hibernate and the EFI NHI driver has already established a tunnel to that drive. It would seem more appropriate to discover tunnels already existing on resume from system sleep and then attempt to establish any others that might be missing. > @@ -183,8 +183,15 @@ int tb_tunnel_restart(struct tb_tunnel *tunnel) > > tb_tunnel_info(tunnel, "activating\n"); > > + /* Make sure all paths are properly disabled before enable them again */ This isn't proper English, s/enable/enabling/. Thanks, Lukas
Re: [PATCH v6 1/6] irqchip/mtk-sysirq: support 4 interrupt parameters for sysirq
On Thu, 2019-02-07 at 15:52 +, Marc Zyngier wrote:
> On 07/02/2019 15:47, Marc Zyngier wrote:
> > On 07/02/2019 15:20, Matthias Brugger wrote:
> >>
> >>
> >> On 24/01/2019 09:07, Erin Lo wrote:
> >>> From: Seiya Wang
> >>>
> >>> To support partitioned PPIs, 4 interrupt parameters should be valid
> >>> for sysirq.
> >>>
> >>> Signed-off-by: Seiya Wang
> >>> Signed-off-by: Erin Lo
> >>> ---
> >>> drivers/irqchip/irq-mtk-sysirq.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/irqchip/irq-mtk-sysirq.c
> >>> b/drivers/irqchip/irq-mtk-sysirq.c
> >>> index 90aaf19..282736a 100644
> >>> --- a/drivers/irqchip/irq-mtk-sysirq.c
> >>> +++ b/drivers/irqchip/irq-mtk-sysirq.c
> >>> @@ -81,7 +81,7 @@ static int mtk_sysirq_domain_translate(struct
> >>> irq_domain *d,
> >>> unsigned int *type)
> >>> {
> >>> if (is_of_node(fwspec->fwnode)) {
> >>> - if (fwspec->param_count != 3)
> >>> + if (fwspec->param_count != 3 && fwspec->param_count != 4)
> >>
> >> Where is this 4th parameter used?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt#n14
> Sorry, I fired Send way too early.
>
> What I wanted to add is that it is not clear to me why this change would
> be required here, as this driver only supports SPIs. It could be fixed
> by just relaxing the binding itself.
>
> Thanks,
>
> M.
Do you mean that we should change #interrupt-cells back to 3 for sysirq
and remove the 4th parameters of every spi interrupts in mt8183.dtsi
(i.e. 3 parameters for spi, 4 for ppi) such that we can discard this
patch?
If yes, we may need some time to verify the change before resending the
patch.
Thanks.
[PATCH] Documentation: fix vm/slub.rst warning
From: Randy Dunlap Fix markup warning by quoting the '*' character with a backslash. Documentation/vm/slub.rst:71: WARNING: Inline emphasis start-string without end-string. Signed-off-by: Randy Dunlap Cc: Christoph Lameter Cc: Sergey Senozhatsky --- Documentation/vm/slub.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-50-rc6.orig/Documentation/vm/slub.rst +++ lnx-50-rc6/Documentation/vm/slub.rst @@ -68,7 +68,7 @@ end of the slab name, in order to cover example, here's how you can poison the dentry cache as well as all kmalloc slabs: - slub_debug=P,kmalloc-*,dentry + slub_debug=P,kmalloc-\*,dentry Red zoning and tracking may realign the slab. We can just apply sanity checks to the dentry cache with::
[PATCH] Documentation: fix lg-laptop.rst warnings
From: Randy Dunlap Fix markup warnings by inserting blank lines. Also correct one typo. Documentation/laptops/lg-laptop.rst:2: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/laptops/lg-laptop.rst:16: WARNING: Unexpected indentation. Documentation/laptops/lg-laptop.rst:17: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Randy Dunlap Cc: Matan Ziv-Av Cc: platform-driver-...@vger.kernel.org --- Documentation/laptops/lg-laptop.rst |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- lnx-50-rc6.orig/Documentation/laptops/lg-laptop.rst +++ lnx-50-rc6/Documentation/laptops/lg-laptop.rst @@ -1,4 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0+ + LG Gram laptop extra features = @@ -9,6 +10,7 @@ Hotkeys --- The following FN keys are ignored by the kernel without this driver: + - FN-F1 (LG control panel) - Generates F15 - FN-F5 (Touchpad toggle)- Generates F13 - FN-F6 (Airplane mode) - Generates RFKILL @@ -16,7 +18,7 @@ The following FN keys are ignored by the This key also changes keyboard backlight mode. - FN-F9 (Reader mode)- Generates F14 -The rest of the FN key work without a need for a special driver. +The rest of the FN keys work without a need for a special driver. Reader mode
[PATCH] Documenation: driver-api: fix gpio/board.rst warning
From: Randy Dunlap Fix markup warning: insert a blank line before the list. Documentation/driver-api/gpio/board.rst:209: WARNING: Unexpected indentation. Signed-off-by: Randy Dunlap Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: linux-g...@vger.kernel.org --- Documentation/driver-api/gpio/board.rst |1 + 1 file changed, 1 insertion(+) --- lnx-50-rc6.orig/Documentation/driver-api/gpio/board.rst +++ lnx-50-rc6/Documentation/driver-api/gpio/board.rst @@ -204,6 +204,7 @@ between a caller and a respective .get/s In order to qualify for fast bitmap processing, the array must meet the following requirements: + - pin hardware number of array member 0 must also be 0, - pin hardware numbers of consecutive array members which belong to the same chip as member 0 does must also match their array indexes.
Re: [PATCH v2 0/6] Fixmap support and MM cleanups
Hi All, Any comments on this series ?? Regards, Anup
Re: [PATCH v1 03/16] powerpc/32: move LOAD_MSR_KERNEL() into head_32.h and use it
Le 11/02/2019 à 01:21, Benjamin Herrenschmidt a écrit : On Fri, 2019-02-08 at 12:52 +, Christophe Leroy wrote: /* + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE. + */ +.macro __LOAD_MSR_KERNEL r, x +.if \x >= 0x8000 + lis \r, (\x)@h + ori \r, \r, (\x)@l +.else + li \r, (\x) +.endif +.endm +#define LOAD_MSR_KERNEL(r, x) __LOAD_MSR_KERNEL r, x + You changed the limit from >= 0x1 to >= 0x8000 without a corresponding explanation as to why... Yes, the existing LOAD_MSR_KERNEL() was buggy because 'li' takes a signed u16, ie between -0x8000 and 0x7999. By chance it was working because until now nobody was trying to set MSR_KERNEL | MSR_EE. Christophe
[PATCH] Documentation: driver-api: fix dmatest.rst warning
From: Randy Dunlap Fix markup warning: insert a blank line before the hint. Documentation/driver-api/dmaengine/dmatest.rst:63: WARNING: Unexpected indentation. Signed-off-by: Randy Dunlap Cc: Andy Shevchenko Cc: Vinod Koul Cc: dmaeng...@vger.kernel.org --- Documentation/driver-api/dmaengine/dmatest.rst |1 + 1 file changed, 1 insertion(+) --- lnx-50-rc6.orig/Documentation/driver-api/dmaengine/dmatest.rst +++ lnx-50-rc6/Documentation/driver-api/dmaengine/dmatest.rst @@ -59,6 +59,7 @@ parameter, that specific channel is requ is created with the existing parameters. This thread is set as pending and will be executed once run is set to 1. Any parameters set after the thread is created are not applied. + .. hint:: available channel list could be extracted by running the following command::
Re: [PATCH v2 13/28] thunderbolt: Add helper function to iterate from one port to another
On Wed, Feb 06, 2019 at 04:17:23PM +0300, Mika Westerberg wrote:
> We need to be able to walk from one port to another when we are creating
> paths where there are multiple switches between two ports. For this
> reason introduce a new function tb_port_get_next() and a new macro
> tb_for_each_port().
These names seem fairly generic, they might as well refer to the next port
on a switch or iterate over the ports on a switch. E.g. I've proposed a
tb_sw_for_each_port() macro in this patch:
https://lore.kernel.org/patchwork/patch/983863/
I'd suggest renaming tb_port_get_next() to something like
tb_next_port_on_path() or tb_path_next_port() or tb_path_walk().
And I'd suggest dropping tb_for_each_port() because there are only
two occurrences where it's used, one calculates the path length,
and I think that's simply the route string length plus 2, and the
other one in patch 17 isn't even interested in the ports along a path,
but rather in the switches between the root switch and the end of a path.
It seems simpler to just iterate from the switch at the end upwards to
the root switch by following the parent pointer in the switch's
struct device, or alternatively by bytewise iterating over the route
string and calling get_switch_at_route() each time.
> +/**
> + * tb_port_get_next() - Return next port for given port
> + * @start: Start port of the walk
> + * @end: End port of the walk
> + * @prev: Previous port (%NULL if this is the first)
> + *
> + * This function can be used to walk from one port to another if they
> + * are connected through zero or more switches. If the @prev is dual
> + * link port, the function follows that link and returns another end on
> + * that same link.
> + *
> + * If the walk cannot be continued, returns %NULL.
This sounds as if NULL is returned if an error occurs but that doesn't
seem to be what the function does. I'd suggest:
"If the @end port has been reached, return %NULL."
> +struct tb_port *tb_port_get_next(struct tb_port *start, struct tb_port *end,
> + struct tb_port *prev)
> +{
> + struct tb_port *port, *next;
> +
> + if (!prev)
> + return start;
> +
> + if (prev->sw == end->sw) {
> + if (prev != end)
> + return end;
> + return NULL;
> + }
> +
> + /* Switch back to use primary links for walking */
"Switch back" requires that you switched to something else before,
which you didn't. I'd suggest something like:
"use primary link to discover next port"
Why is it necessary to use the primary link anyway? Is the
->remote member not set on the secondary link port? The reason
should probably be spelled out in the code comment.
> + if (prev->dual_link_port && prev->link_nr)
> + port = prev->dual_link_port;
> + else
> + port = prev;
> +
> + if (start->sw->config.depth < end->sw->config.depth) {
> + if (port->remote &&
> + port->remote->sw->config.depth > port->sw->config.depth)
Can we use "if (!tb_is_upstream_port(port))" for consistency with the
if-clause below?
> + next = port->remote;
> + else
> + next = tb_port_at(tb_route(end->sw), port->sw);
> + } else if (start->sw->config.depth > end->sw->config.depth) {
> + if (tb_is_upstream_port(port))
> + next = port->remote;
> + else
> + next = tb_upstream_port(port->sw);
> + } else {
> + /* Must be the same switch then */
> + if (start->sw != end->sw)
> + return NULL;
> + return end;
> + }
The else-clause here appears to be dead code, you've already checked
further up whether prev and end are on the same switch.
> +
> + /* If prev was dual link return another end of that link then */
*Here* a "switch back" comment would be appropriate. Nit: Please either
end code comments with a period or don't start them with an upper case
letter.
> + if (next->dual_link_port && next->link_nr != prev->link_nr)
> + return next->dual_link_port;
> +
> + return next;
> +}
Thanks,
Lukas
Re: linux-next: Signed-off-by missing for commit in the wireless-drivers-next tree
+ ath10k
Stephen Rothwell writes:
> Hi all,
>
> Commit
>
> 768ec4c012ac ("ath10k: update HOST capability qmi message")
>
> is missing a Signed-off-by from its author.
Oh, I had missed that. Thanks for reporting.
Unfortunately it would be difficult to rebase wireless-drivers-next so I
can't (easily) fix this. But v1 had s-o-b so at least we have the sign
off publically available:
https://patchwork.kernel.org/patch/10688563/
--
Kalle Valo
Re: [PATCH V3] ARM: dts: imx: Add support for Logic PD i.MX6QD EVM
On Sun, Feb 10, 2019 at 02:57:23PM -0600, Adam Ford wrote: > The EVM consists of a system on module (SOM) and baseboard, and LCD. > This patch adds a DTSI file for the SOM and baseboard separately, > then a wrapper to combine them and specify processor type and a > LCD information. > > Signed-off-by: Adam Ford > Reviewed-by: Fabio Estevam Applied, thanks.
[PATCHv12 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Device tree binding for Intel FPGA Video and Image Processing Suite.
The bindings would set the max width, max height,
bits per pixel and memory port width.
The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
V12:
Wrap comments and fix commit message
V11:
No change
V10:
No change
V9:
Remove Display port node
V8:
*Add port to Display port decoder
V7:
*Fix OF graph for better description
*Add description for encoder
V6:
*Description have not describe DT device in general
V5:
*remove bindings for bits per symbol as it has only one value which is 8
V4:
*fix properties that does not describe the values
V3:
*OF graph not in accordance to graph.txt
V2:
*Remove Linux driver description
V1:
*Missing vendor prefix
Signed-off-by: Ong, Hean Loong
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 63
1 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..89a3b9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,63 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+ on the frame reader
+
+Optional sub-nodes:
+- ports: The connection to the encoder
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+ Port 0 Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Required Properties Example:
+
+
+framebuffer@10280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x0001 0x0280 0x0040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,mem-port-width = <128>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ fb_output: endpoint {
+ remote-endpoint =
<&dp_encoder_input>;
+ };
+ };
+ };
+};
--
1.7.1
[PATCHv12 0/3] Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the Sodt IP FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the Framebuffer 2 Soft IP and displayed on the Display Port Monitor. Ong Hean Loong (1): ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite Ong, Hean Loong (2): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 63 +++ arch/arm/configs/socfpga_defconfig |5 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivip/Kconfig | 14 ++ drivers/gpu/drm/ivip/Makefile |7 + drivers/gpu/drm/ivip/intel_vip_conn.c | 91 ++ drivers/gpu/drm/ivip/intel_vip_core.c | 189 drivers/gpu/drm/ivip/intel_vip_drv.h | 73 drivers/gpu/drm/ivip/intel_vip_of.c| 181 +++ 10 files changed, 626 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
[PATCHv12 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 371fca4..21d8d2b 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -112,6 +112,11 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 1.7.1
[PATCHv12 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Signed-off-by: Ong, Hean Loong
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile |7 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 91
drivers/gpu/drm/ivip/intel_vip_core.c | 189 +
drivers/gpu/drm/ivip/intel_vip_drv.h | 73 +
drivers/gpu/drm/ivip/intel_vip_of.c | 181 +++
8 files changed, 558 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4385f00..0251a9f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -235,6 +235,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ce8d1d3..85a5694 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_V3D) += v3d/
obj-$(CONFIG_DRM_VC4) += vc4/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only
single
+ frame buffer is supported. Note that ACPI and X_86
architecture
+ is not supported for Arria10. If M is selected the module
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..3fd2e75
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..93ce0b3
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * Authors:
+ * Walter Goossens
+ * Thomas Chou
+ * Chris Rauer
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .detect = intelvipfb_drm_connector_detect,
+ .reset = drm_atomic_helper_connector_reset,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+ .destroy = intelvipfb_drm_connector_destroy,
+};
+
+static int intelvipfb_drm_connector_get_modes(struct drm_connector *connector)
+{
+ struct drm_device *drm = connector->dev;
+ int count;
+
+ count = drm_add_modes_noedid(connector, drm->mode_config.max_width,
+ drm->mode_config.max_height);
+ drm_set_preferred_mode(connector, drm->mode_config.m
Re: [PATCH v2] PCI: endpoint: functions: Use kmemdup instead of duplicating its function
Hi Lorenzo,
On 08/02/19 5:50 PM, Lorenzo Pieralisi wrote:
> On Thu, Dec 06, 2018 at 08:52:25PM +0800, Wen Yang wrote:
>> kmemdup has implemented the function that kmalloc() + memcpy().
>> We prefer to kmemdup rather than code opened implementation.
>>
>> This issue was detected with the help of coccinelle.
>>
>> Signed-off-by: Wen Yang
>> CC: Kishon Vijay Abraham I
>> CC: Lorenzo Pieralisi
>> CC: Bjorn Helgaas
>> CC: Gustavo Pimentel
>> CC: Niklas Cassel
>> CC: Greg Kroah-Hartman
>> CC: Cyrille Pitchen
>> CC: linux-...@vger.kernel.org (open list:PCI ENDPOINT SUBSYSTEM)
>> CC: linux-kernel@vger.kernel.org (open list)
>> ---
>> drivers/pci/endpoint/functions/pci-epf-test.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> Kishon,
>
> this looks OK to me, anything I am missing ?
For the existing code this might seem the right thing to do but ideally the
memcpy here should be changed to memcpy_fromio/memcpy_toio.
Also later when we plan to use DMA (on the endpoint) for data transfer, we have
to use kzalloc and dma_map_single APIs.
So maybe the right thing would be to just fix it to use memcpy_fromio here.
Thanks
Kishon
>
> Lorenzo
>
>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
>> b/drivers/pci/endpoint/functions/pci-epf-test.c
>> index 3e86fa3c7da3..8df6c019f8a2 100644
>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
>> @@ -169,14 +169,12 @@ static int pci_epf_test_read(struct pci_epf_test
>> *epf_test)
>> goto err_addr;
>> }
>>
>> -buf = kzalloc(reg->size, GFP_KERNEL);
>> +buf = kmemdup(src_addr, reg->size, GFP_KERNEL);
>> if (!buf) {
>> ret = -ENOMEM;
>> goto err_map_addr;
>> }
>>
>> -memcpy(buf, src_addr, reg->size);
>> -
>> crc32 = crc32_le(~0, buf, reg->size);
>> if (crc32 != reg->checksum)
>> ret = -EIO;
>> --
>> 2.19.1
>>
Re: [PATCH 0/3] drivers: Frequency constraint infrastructure
On 08-02-19, 11:35, Rafael J. Wysocki wrote: > At least some of the underlying mechanics seem to be very similar. > You have priority lists, addition and removal of requests etc. > > Arguably, PM QoS may be regarded as a bit overly complicated, but > maybe they both can use a common library underneath? > As I said I like the idea of replacing cpufreq notifiers with > something nicer, so if you can avoid doing almost-the-same-ting in two > different frameworks, it would be fine by me. Ok, will try to move to PM QoS. Thanks. -- viresh
[PATCH] blk-mq: insert rq with DONTPREP to hctx dispatch list when requeue
When requeue, if RQF_DONTPREP, rq has contained some driver
specific data, so insert it to hctx dispatch list to avoid any
merge. Take scsi as example, here is the trace event log (no
io scheduler, because RQF_STARTED would prevent merging),
kworker/0:1H-339 [000] ...1 2037.209289: block_rq_insert: 8,0 R 4096 ()
32768 + 8 [kworker/0:1H]
scsi_inert_test-1987 [000] 2037.220465: block_bio_queue: 8,0 R 32776 + 8
[scsi_inert_test]
scsi_inert_test-1987 [000] ...2 2037.220466: block_bio_backmerge: 8,0 R 32776
+ 8 [scsi_inert_test]
kworker/0:1H-339 [000] 2047.220913: block_rq_issue: 8,0 R 8192 ()
32768 + 16 [kworker/0:1H]
scsi_inert_test-1996 [000] ..s1 2047.221007: block_rq_complete: 8,0 R ()
32768 + 8 [0]
scsi_inert_test-1996 [000] .Ns1 2047.221045: block_rq_requeue: 8,0 R () 32776
+ 8 [0]
kworker/0:1H-339 [000] ...1 2047.221054: block_rq_insert: 8,0 R 4096 ()
32776 + 8 [kworker/0:1H]
kworker/0:1H-339 [000] ...1 2047.221056: block_rq_issue: 8,0 R 4096 ()
32776 + 8 [kworker/0:1H]
scsi_inert_test-1986 [000] ..s1 2047.221119: block_rq_complete: 8,0 R ()
32776 + 8 [0]
(32768 + 8) was requeued by scsi_queue_insert and had RQF_DONTPREP.
Then it was merged with (32776 + 8) and issued. Due to RQF_DONTPREP,
the sdb only contained the part of (32768 + 8), then only that part
was completed. The lucky thing was that scsi_io_completion detected
it and requeued the remaining part. So we didn't get corrupted data.
However, the requeue of (32776 + 8) is not expected.
Signed-off-by: Jianchao Wang
---
block/blk-mq.c | 12
1 file changed, 12 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 8f5b533..2d93eb5 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -737,6 +737,18 @@ static void blk_mq_requeue_work(struct work_struct *work)
spin_unlock_irq(&q->requeue_lock);
list_for_each_entry_safe(rq, next, &rq_list, queuelist) {
+ /*
+* If RQF_DONTPREP, rq has contained some driver specific
+* data, so insert it to hctx dispatch list to avoid any
+* merge.
+*/
+ if (rq->rq_flags & RQF_DONTPREP) {
+ rq->rq_flags &= ~RQF_SOFTBARRIER;
+ list_del_init(&rq->queuelist);
+ blk_mq_request_bypass_insert(rq, false);
+ continue;
+ }
+
if (!(rq->rq_flags & RQF_SOFTBARRIER))
continue;
--
2.7.4
Re: [PATCH v2] dt-bindings: input: ti-tsc-adc: Add new compatible for AM654 SoCs
Hi Dmitry, On 08/01/19 10:56 AM, Vignesh R wrote: > AM654 SoCs has ADC IP which is similar to AM335x, but without the > touchscreen part. Add new compatible to handle AM654 SoCs. Also, it > seems that existing compatible strings used in the kernel DTs were never > documented. So, document them now. > > Signed-off-by: Vignesh R > Reviewed-by: Rob Herring > --- If there are no comments, could you queue this bindings patch? This will help me in getting ADC DT nodes to be merged into ARM SoC tree. Regards Vignesh > v2: > Fix subject line to include subsystem name > Rebase onto v5.0-rc1 > v1: https://lkml.org/lkml/2018/11/19/313 > > .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > index b1163bf97146..aad5e34965eb 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > @@ -2,7 +2,12 @@ > ~~ > > Required properties: > +- mfd > + compatible: Should be > + "ti,am3359-tscadc" for AM335x/AM437x SoCs > + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs > - child "tsc" > + compatible: Should be "ti,am3359-tsc". > ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen > support on the platform. > ti,x-plate-resistance: X plate resistance > @@ -25,6 +30,9 @@ Required properties: > AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > XP = 0, XN = 1, YP = 2, YN = 3. > - child "adc" > + compatible: Should be > + "ti,am3359-adc" for AM335x/AM437x SoCs > + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs > ti,adc-channels: List of analog inputs available for ADC. >AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > > -- Regards Vignesh
Re: [v5 2/2] arm64: dts: lx2160a: add sata node support
On Mon, Feb 11, 2019 at 02:53:18AM +, Peng Ma wrote:
>
>
> >-Original Message-
> >From: Shawn Guo
> >Sent: 2019年2月1日 14:30
> >To: Peng Ma
> >Cc: ax...@kernel.dk; robh...@kernel.org; mark.rutl...@arm.com; Leo Li
> >; linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> >linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Andy Tang
> >
> >Subject: Re: [v5 2/2] arm64: dts: lx2160a: add sata node support
> >
> >On Fri, Jan 25, 2019 at 08:10:13AM +, Peng Ma wrote:
> >> Add SATA device nodes for fsl-lx2160a and enable support for QDS and
> >> RDB boards.
> >>
> >> Signed-off-by: Peng Ma
> >> ---
> >> changed for V5:
> >>- no change
> >>
> >> arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts | 16 +++
> >> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 16 +++
> >> arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 44
> >+
> >> 3 files changed, 76 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> >> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> >> index 99a22ab..1a5acf6 100644
> >> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> >> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> >> @@ -95,6 +95,22 @@
> >>};
> >> };
> >>
> >> +&sata0 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&sata1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&sata2 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&sata3 {
> >> + status = "okay";
> >> +};
> >> +
> >> &uart0 {
> >>status = "okay";
> >> };
> >> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> >> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> >> index 6481e5f..5b6799e 100644
> >> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> >> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> >> @@ -102,6 +102,22 @@
> >>};
> >> };
> >>
> >> +&sata0 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&sata1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&sata2 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&sata3 {
> >> + status = "okay";
> >> +};
> >> +
> >> &uart0 {
> >>status = "okay";
> >> };
> >> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >> index a79f5c1..592034b 100644
> >> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >> @@ -671,6 +671,50 @@
> >>status = "disabled";
> >>};
> >>
> >> + sata0: sata@320 {
> >> + compatible = "fsl,lx2160a-ahci";
> >
> >Has the kernel driver been patched to probe the compatible?
> >
> >Shawn
> Yes, the driver patch is http://patchwork.ozlabs.org/patch/1034083/
Ping me when the driver patch is accepted. Ideally, we only accept dts
changes after the driver counterpart lands on mainline.
Shawn
Re: [PATCH] autofs: clear O_NONBLOCK on the pipe.
On Mon, 2019-02-11 at 10:37 +1100, NeilBrown wrote: > autofs does not expect the pipe it is given > to have O_NONBLOCK set - specifically if __kernel_write() > in autofs_write() returns -EAGAIN, this is treated > as a fatal error and the pipe is closed. > > For safety autofs should, therefore, clear the O_NONBLOCK flag. > > Releases of systemd prior to 8th February 2019 used > pipe2(p, O_NONBLOCK|O_CLOEXEC) > and thus (inadvertently) set this flag. Thanks Neil, this does look like an obvious problem. > > Signed-off-by: NeilBrown > --- > fs/autofs/autofs_i.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h > index 3e59f0ed777b..331192bed0d5 100644 > --- a/fs/autofs/autofs_i.h > +++ b/fs/autofs/autofs_i.h > @@ -215,6 +215,8 @@ static inline int autofs_prepare_pipe(struct file *pipe) > return -EINVAL; > /* We want a packet pipe */ > pipe->f_flags |= O_DIRECT; > + /* We don't expect -EAGAIN */ > + pipe->f_flags &= ~O_NONBLOCK; > return 0; > } >
linux-next: build failure after merge of the rtc tree
Hi all,
After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: "rtc_nvmem_unregister" [drivers/rtc/rtc-meson.ko] undefined!
Caused by commit
21358403bb29 ("rtc: support for the Amlogic Meson RTC")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpcPBnHCIsdT.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 05/20] x86/alternative: initializing temporary mm for patching
On Feb 10, 2019, at 4:39 PM, Nadav Amit wrote:
>> On Jan 28, 2019, at 4:34 PM, Rick Edgecombe
>> wrote:
>>
>> From: Nadav Amit
>>
>> To prevent improper use of the PTEs that are used for text patching, we
>> want to use a temporary mm struct. We initailize it by copying the init
>> mm.
>>
>> The address that will be used for patching is taken from the lower area
>> that is usually used for the task memory. Doing so prevents the need to
>> frequently synchronize the temporary-mm (e.g., when BPF programs are
>> installed), since different PGDs are used for the task memory.
>>
>> Finally, we randomize the address of the PTEs to harden against exploits
>> that use these PTEs.
>>
>> Cc: Kees Cook
>> Cc: Dave Hansen
>> Acked-by: Peter Zijlstra (Intel)
>> Reviewed-by: Masami Hiramatsu
>> Tested-by: Masami Hiramatsu
>> Suggested-by: Andy Lutomirski
>> Signed-off-by: Nadav Amit
>> Signed-off-by: Rick Edgecombe
>> ---
>> arch/x86/include/asm/pgtable.h | 3 +++
>> arch/x86/include/asm/text-patching.h | 2 ++
>> arch/x86/kernel/alternative.c| 3 +++
>> arch/x86/mm/init_64.c| 36
>> init/main.c | 3 +++
>> 5 files changed, 47 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
>> index 40616e805292..e8f630d9a2ed 100644
>> --- a/arch/x86/include/asm/pgtable.h
>> +++ b/arch/x86/include/asm/pgtable.h
>> @@ -1021,6 +1021,9 @@ static inline void __meminit
>> init_trampoline_default(void)
>>/* Default trampoline pgd value */
>>trampoline_pgd_entry = init_top_pgt[pgd_index(__PAGE_OFFSET)];
>> }
>> +
>> +void __init poking_init(void);
>> +
>> # ifdef CONFIG_RANDOMIZE_MEMORY
>> void __meminit init_trampoline(void);
>> # else
>> diff --git a/arch/x86/include/asm/text-patching.h
>> b/arch/x86/include/asm/text-patching.h
>> index f8fc8e86cf01..a75eed841eed 100644
>> --- a/arch/x86/include/asm/text-patching.h
>> +++ b/arch/x86/include/asm/text-patching.h
>> @@ -39,5 +39,7 @@ extern void *text_poke_kgdb(void *addr, const void
>> *opcode, size_t len);
>> extern int poke_int3_handler(struct pt_regs *regs);
>> extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void
>> *handler);
>> extern int after_bootmem;
>> +extern __ro_after_init struct mm_struct *poking_mm;
>> +extern __ro_after_init unsigned long poking_addr;
>>
>> #endif /* _ASM_X86_TEXT_PATCHING_H */
>> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
>> index 12fddbc8c55b..ae05fbb50171 100644
>> --- a/arch/x86/kernel/alternative.c
>> +++ b/arch/x86/kernel/alternative.c
>> @@ -678,6 +678,9 @@ void *__init_or_module text_poke_early(void *addr, const
>> void *opcode,
>>return addr;
>> }
>>
>> +__ro_after_init struct mm_struct *poking_mm;
>> +__ro_after_init unsigned long poking_addr;
>> +
>> static void *__text_poke(void *addr, const void *opcode, size_t len)
>> {
>>unsigned long flags;
>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>> index bccff68e3267..125c8c48aa24 100644
>> --- a/arch/x86/mm/init_64.c
>> +++ b/arch/x86/mm/init_64.c
>> @@ -53,6 +53,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "mm_internal.h"
>>
>> @@ -1383,6 +1384,41 @@ unsigned long memory_block_size_bytes(void)
>>return memory_block_size_probed;
>> }
>>
>> +/*
>> + * Initialize an mm_struct to be used during poking and a pointer to be used
>> + * during patching.
>> + */
>> +void __init poking_init(void)
>> +{
>> +spinlock_t *ptl;
>> +pte_t *ptep;
>> +
>> +poking_mm = copy_init_mm();
>> +BUG_ON(!poking_mm);
>> +
>> +/*
>> + * Randomize the poking address, but make sure that the following page
>> + * will be mapped at the same PMD. We need 2 pages, so find space for 3,
>> + * and adjust the address if the PMD ends after the first one.
>> + */
>> +poking_addr = TASK_UNMAPPED_BASE;
>> +if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
>> +poking_addr += (kaslr_get_random_long("Poking") & PAGE_MASK) %
>> +(TASK_SIZE - TASK_UNMAPPED_BASE - 3 * PAGE_SIZE);
>> +
>> +if (((poking_addr + PAGE_SIZE) & ~PMD_MASK) == 0)
>> +poking_addr += PAGE_SIZE;
>
> Further thinking about it, I think that allocating the virtual address for
> poking from user address-range is problematic. The user can set watchpoints
> on different addresses, cause some static-keys to be enabled/disabled, and
> monitor the signals to derandomize the poking address.
>
Hmm, I hadn’t thought about watchpoints. I’m not sure how much we care about
possible derandomization like this, but we certainly don’t want to send signals
or otherwise malfunction.
> Andy, I think you were pushing this change. Can I go back to use a vmalloc’d
> address instead, or do you have a better solution?
Hmm. If we use a vmalloc address, we have to make sure it’s not actually
allocated. I suppose we could allocate one once at boot and use that.
Re: [PATCH] misc: aspeed-lpc-ctrl: Correct return values
On Fri, 25 Jan 2019, at 05:59, Vijay Khemka wrote:
>
>
> On 1/24/19, 12:16 AM, "Greg Kroah-Hartman"
> wrote:
>
> On Wed, Jan 23, 2019 at 03:06:34PM -0800, Vijay Khemka wrote:
> > Corrected some of return values with appropriate meanings.
> >
> > Signed-off-by: Vijay Khemka
> > ---
> > drivers/misc/aspeed-lpc-ctrl.c | 15 +++
> > 1 file changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-
> lpc-ctrl.c
> > index 332210e06e98..97ae341109d5 100644
> > --- a/drivers/misc/aspeed-lpc-ctrl.c
> > +++ b/drivers/misc/aspeed-lpc-ctrl.c
> > @@ -68,7 +68,6 @@ static long aspeed_lpc_ctrl_ioctl(struct file
> *file, unsigned int cmd,
> > unsigned long param)
> > {
> > struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
> > - struct device *dev = file->private_data;
> > void __user *p = (void __user *)param;
> > struct aspeed_lpc_ctrl_mapping map;
> > u32 addr;
> > @@ -93,8 +92,8 @@ static long aspeed_lpc_ctrl_ioctl(struct file
> *file, unsigned int cmd,
> >
> > /* If memory-region is not described in device tree */
> > if (!lpc_ctrl->mem_size) {
> > - dev_err(dev, "Didn't find reserved memory\n");
> > - return -EINVAL;
> > + pr_err("aspeed_lpc_ctrl: ioctl: Didn't find
> reserved memory\n");
>
> Why did you change from dev_err() to pr_err()? You just lost a lot of
> information that the user previously was getting from dev_err() :(
>
> I did this as per review comment from Andrew Jeffery, as we don't want
> to put this error for driver. It has to be handled by userspace. But I
> am still reporting some error here.
Sorry? What I was trying to suggest was removing the logging altogether and
just returning the error code. Not simply changing how the logging is done.
Andrew
Re: [PATCH v1 1/1] arm64: dts: mt8173: add pmu nodes for mt8173
On Fri, 2019-02-08 at 16:04 +0100, Matthias Brugger wrote:
>
> On 09/01/2019 09:21, Seiya Wang wrote:
> > This patch adds the device nodes of ARM Performance Monitor Uint
> > for mt8173.
> >
> > Signed-off-by: Seiya Wang
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index 412ffd4d426b..44374c506a1c 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -216,6 +216,20 @@
> > };
> > };
> >
> > + pmu_a53 {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts = ,
> > +;
> > + interrupt-affinity = <&cpu0>, <&cpu1>;
> > + };
> > +
> > + pmu_a72 {
> > + compatible = "arm,cortex-a72-pmu";
> > + interrupts = ,
> > +;
> > + interrupt-affinity = <&cpu2>, <&cpu3>;
> > + };
>
> There is no a72 but a a57 CPU present.
> Typo?
>
> Regards,
> Matthias
MT8173 is actually using a72, not a57.
I will submit another patch for fixing it.
Thanks.
> > +
> > psci {
> > compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
> > method = "smc";
> >
Re: [PATCH v1] clk: qcom: Make common clk_hw registrations
On 10-02-19, 13:14, Jeffrey Hugo wrote:
> Several clock controller drivers define a list of clk_hw devices, and then
> register those devices in probe() before using common code to process the
> rest of initialization. Extend the common code to accept a list of clk_hw
> devices to process, thus eliminating many duplicate implementations.
Thanks, this looks nice to me. I verfified this on couple of devices.
Reviewed-by: Vinod Koul
Tested-by: Vinod Koul
> Signed-off-by: Jeffrey Hugo
> ---
> drivers/clk/qcom/common.c | 8
> drivers/clk/qcom/common.h | 2 ++
> drivers/clk/qcom/gcc-ipq8074.c | 10 ++
> drivers/clk/qcom/gcc-mdm9615.c | 11 ++-
> drivers/clk/qcom/gcc-msm8996.c | 10 ++
> drivers/clk/qcom/gcc-msm8998.c | 10 ++
> drivers/clk/qcom/gcc-qcs404.c | 9 ++---
> drivers/clk/qcom/gcc-sdm660.c | 11 +++
> drivers/clk/qcom/mmcc-msm8996.c | 10 ++
> 9 files changed, 29 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> index 0a48ed5..a6b2f861 100644
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
> @@ -231,6 +231,8 @@ int qcom_cc_really_probe(struct platform_device *pdev,
> struct gdsc_desc *scd;
> size_t num_clks = desc->num_clks;
> struct clk_regmap **rclks = desc->clks;
> + size_t num_clk_hws = desc->num_clk_hws;
> + struct clk_hw **clk_hws = desc->clk_hws;
>
> cc = devm_kzalloc(dev, sizeof(*cc), GFP_KERNEL);
> if (!cc)
> @@ -269,6 +271,12 @@ int qcom_cc_really_probe(struct platform_device *pdev,
>
> qcom_cc_drop_protected(dev, cc);
>
> + for (i = 0; i < num_clk_hws; i++) {
> + ret = devm_clk_hw_register(dev, clk_hws[i]);
> + if (ret)
> + return ret;
> + }
> +
> for (i = 0; i < num_clks; i++) {
> if (!rclks[i])
> continue;
> diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
> index 4aa33ee..1e2a8bd 100644
> --- a/drivers/clk/qcom/common.h
> +++ b/drivers/clk/qcom/common.h
> @@ -27,6 +27,8 @@ struct qcom_cc_desc {
> size_t num_resets;
> struct gdsc **gdscs;
> size_t num_gdscs;
> + struct clk_hw **clk_hws;
> + size_t num_clk_hws;
> };
>
> /**
> diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/drivers/clk/qcom/gcc-ipq8074.c
> index 505c626..0e32892 100644
> --- a/drivers/clk/qcom/gcc-ipq8074.c
> +++ b/drivers/clk/qcom/gcc-ipq8074.c
> @@ -4715,18 +4715,12 @@ enum {
> .num_clks = ARRAY_SIZE(gcc_ipq8074_clks),
> .resets = gcc_ipq8074_resets,
> .num_resets = ARRAY_SIZE(gcc_ipq8074_resets),
> + .clk_hws = gcc_ipq8074_hws,
> + .num_clk_hws = ARRAY_SIZE(gcc_ipq8074_hws),
> };
>
> static int gcc_ipq8074_probe(struct platform_device *pdev)
> {
> - int ret, i;
> -
> - for (i = 0; i < ARRAY_SIZE(gcc_ipq8074_hws); i++) {
> - ret = devm_clk_hw_register(&pdev->dev, gcc_ipq8074_hws[i]);
> - if (ret)
> - return ret;
> - }
> -
> return qcom_cc_probe(pdev, &gcc_ipq8074_desc);
> }
>
> diff --git a/drivers/clk/qcom/gcc-mdm9615.c b/drivers/clk/qcom/gcc-mdm9615.c
> index 849046f..8c6d931 100644
> --- a/drivers/clk/qcom/gcc-mdm9615.c
> +++ b/drivers/clk/qcom/gcc-mdm9615.c
> @@ -1702,6 +1702,8 @@ enum {
> .num_clks = ARRAY_SIZE(gcc_mdm9615_clks),
> .resets = gcc_mdm9615_resets,
> .num_resets = ARRAY_SIZE(gcc_mdm9615_resets),
> + .clk_hws = gcc_mdm9615_hws,
> + .num_clk_hws = ARRAY_SIZE(gcc_mdm9615_hws),
> };
>
> static const struct of_device_id gcc_mdm9615_match_table[] = {
> @@ -1712,21 +1714,12 @@ enum {
>
> static int gcc_mdm9615_probe(struct platform_device *pdev)
> {
> - struct device *dev = &pdev->dev;
> struct regmap *regmap;
> - int ret;
> - int i;
>
> regmap = qcom_cc_map(pdev, &gcc_mdm9615_desc);
> if (IS_ERR(regmap))
> return PTR_ERR(regmap);
>
> - for (i = 0; i < ARRAY_SIZE(gcc_mdm9615_hws); i++) {
> - ret = devm_clk_hw_register(dev, gcc_mdm9615_hws[i]);
> - if (ret)
> - return ret;
> - }
> -
> return qcom_cc_really_probe(pdev, &gcc_mdm9615_desc, regmap);
> }
>
> diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
> index 9d13617..4632b92 100644
> --- a/drivers/clk/qcom/gcc-msm8996.c
> +++ b/drivers/clk/qcom/gcc-msm8996.c
> @@ -3656,6 +3656,8 @@ enum {
> .num_resets = ARRAY_SIZE(gcc_msm8996_resets),
> .gdscs = gcc_msm8996_gdscs,
> .num_gdscs = ARRAY_SIZE(gcc_msm8996_gdscs),
> + .clk_hws = gcc_msm8996_hws,
> + .num_clk_hws = ARRAY_SIZE(gcc_msm8996_hws),
> };
>
> static const struct of_device_id gcc_msm8996_match_table[] = {
> @@ -3666,8 +3668,6 @@ enum {
>
> static int gcc_msm8996_probe(struct platform_device *pdev)
> {
> - struct device *dev = &pdev->dev;
> - int i, ret;
linux-next: manual merge of the rtc tree with the clk tree
Hi all,
Today's linux-next merge of the rtc tree got a conflict in:
drivers/clk/at91/sama5d2.c
between commit:
77977b800451 ("clk: at91: enable AUDIOPLL as source for PCKx on SAMA5D2")
from the clk tree and commit:
34d2ff2a6019 ("clk: at91: fix masterck name")
from the rtc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/clk/at91/sama5d2.c
index ade063622531,cd0ef7274fdb..
--- a/drivers/clk/at91/sama5d2.c
+++ b/drivers/clk/at91/sama5d2.c
@@@ -240,8 -240,7 +240,8 @@@ static void __init sama5d2_pmc_setup(st
parent_names[1] = "mainck";
parent_names[2] = "plladivck";
parent_names[3] = "utmick";
- parent_names[4] = "mck";
+ parent_names[4] = "masterck";
+ parent_names[5] = "audiopll_pmcck";
for (i = 0; i < 3; i++) {
char name[6];
pgpHs7lZbz4Le.pgp
Description: OpenPGP digital signature
[GIT PULL] csky fixes for v5.0-rc6
The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:
Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)
are available in the git repository at:
g...@github.com:c-sky/csky-linux.git tags/csky-for-linus-5.0-rc6
for you to fetch changes up to 757dc82a87669b1967faf89c6586c20a9aea2f6b:
csky: Fixup dead loop in show_stack (2019-02-11 10:47:27 +0800)
arch/csky patches for 5.0-rc6
Here is some fixup patches for 5.0-rc6:
Guo Ren (12):
irqchip/csky: Support csky,dh7k SOC intc driver
dt-bindings: csky,apb-intc: Add dh7k SOC support
csky: Fixup _PAGE_GLOBAL bit for 610 tlb entry
irqchip/csky: Optimize remove unnecessary loop irq handle
irqchip/irq-csky-mpintc: Add triger type and priority
dt-bindings: interrupt-controller: Update csky mpintc
csky: Fixup wrong pt_regs size
csky: coding convention: Use task_stack_page
dt-bindings: csky,apb-intc: Add vector irq mode
irqchip/csky: Add support-vector-irq for apb-intc
csky: Fixup io-range page attribute for mmap("/dev/mem")
csky: Fixup dead loop in show_stack
Signed-off-by: Guo Ren
Guo Ren (12):
irqchip/csky: Support csky,dh7k SOC intc driver
dt-bindings: csky,apb-intc: Add dh7k SOC support
csky: Fixup _PAGE_GLOBAL bit for 610 tlb entry
irqchip/csky: Optimize remove unnecessary loop irq handle
irqchip/irq-csky-mpintc: Add triger type and priority
dt-bindings: interrupt-controller: Update csky mpintc
csky: Fixup wrong pt_regs size
csky: coding convention: Use task_stack_page
dt-bindings: csky,apb-intc: Add vector irq mode
irqchip/csky: Add support-vector-irq for apb-intc
csky: Fixup io-range page attribute for mmap("/dev/mem")
csky: Fixup dead loop in show_stack
.../interrupt-controller/csky,apb-intc.txt | 4 +
.../bindings/interrupt-controller/csky,mpintc.txt | 21 ++-
arch/csky/include/asm/pgtable.h| 9 +-
arch/csky/include/asm/processor.h | 4 +-
arch/csky/kernel/dumpstack.c | 4 +
arch/csky/kernel/ptrace.c | 3 +-
arch/csky/kernel/smp.c | 3 +-
arch/csky/mm/ioremap.c | 14 ++
drivers/irqchip/irq-csky-apb-intc.c| 151 +
drivers/irqchip/irq-csky-mpintc.c | 113 ++-
10 files changed, 279 insertions(+), 47 deletions(-)
Re: [PATCH v5 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
On 10/02/19 6:49 PM, Boris Brezillon wrote:
> On Tue, 5 Feb 2019 11:43:46 +0530
> Vignesh R wrote:
>
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node
*np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = &pdev->dev;
+ const struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = of_device_get_match_data(dev);
+ if (!ddata)
+ hwcaps.mask = CQSPI_BASE_HWCAPS_MASK;
>>>
>>> Now that .data is set in all cqspi_dt_ids[], maybe it's better to print a
>>> message and return an error here. But I guess it's a matter of taste, so
>>> not a
>>> show stopper.
>>
>> Since, driver data is kernel internal field, I guess there is little
>> help in printing out the error to the user when its missing. I prefer to
>> keep this as is, as basic Quad mode is supported by all versions of the IP.
>
> Well, if all compat entries have an associated platdata instance we
> don't need to support the !ddata case, right? I think enforcing the
> presence of such a platdata is actually is a sane thing to do (which
> implies returning an error when ddata is NULL).
>
Ok, will respin with a dev_err() and return -EINVAL when ddata is NULL.
--
Regards
Vignesh
[PATCH] drm/mediatek: add mt8183 dpi support
MT8183 sample on rising and falling edge. It can reduce half data io.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 62a9d47df948..610c23334047 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -117,6 +117,7 @@ struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
u32 reg_h_fre_con;
bool edge_sel_en;
+ bool dual_edge;
};
static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -353,6 +354,13 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi
*dpi)
mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
}
+static void mtk_dpi_enable_dual_edge(struct mtk_dpi *dpi)
+{
+ mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
+DDR_EN | DDR_4PHASE);
+ mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
+}
+
static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
enum mtk_dpi_out_color_format format)
{
@@ -509,6 +517,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
mtk_dpi_config_color_format(dpi, dpi->color_format);
mtk_dpi_config_2n_h_fre(dpi);
mtk_dpi_config_disable_edge(dpi);
+ if (dpi->conf->dual_edge)
+ mtk_dpi_enable_dual_edge(dpi);
mtk_dpi_sw_reset(dpi, false);
return 0;
@@ -671,6 +681,16 @@ static unsigned int mt2701_calculate_factor(int clock)
return 2;
}
+static unsigned int mt8183_calculate_factor(int clock)
+{
+ if (clock <= 27000)
+ return 8;
+ else if (clock <= 167000)
+ return 4;
+ else
+ return 2;
+}
+
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -682,6 +702,12 @@ static const struct mtk_dpi_conf mt2701_conf = {
.edge_sel_en = true,
};
+static const struct mtk_dpi_conf mt8183_conf = {
+ .cal_factor = mt8183_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+ .dual_edge = true,
+};
+
static int mtk_dpi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -777,6 +803,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8173-dpi",
.data = &mt8173_conf,
},
+ { .compatible = "mediatek,mt8183-dpi",
+ .data = &mt8183_conf,
+ },
{ },
};
--
2.12.5
[PULL] alpha.git
Hi Linus, Please pull a few changes for alpha, including a build fix, a fix for the Eiger platform, and a fix for a tricky bug uncovered by the strace test suite that has existed since at least 1997 (v2.1.32)! Thanks, Matt The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus for you to fetch changes up to 491af60ffb848b59e82f7c9145833222e0bf27a5: alpha: fix page fault handling for r16-r18 targets (2019-02-10 20:42:23 -0800) Bob Tracy (1): tools uapi: fix Alpha support Meelis Roos (1): alpha: Fix Eiger NR_IRQS to 128 Sergei Trofimovich (1): alpha: fix page fault handling for r16-r18 targets arch/alpha/include/asm/irq.h | 6 +++--- arch/alpha/mm/fault.c| 2 +- tools/include/uapi/asm/bitsperlong.h | 2 ++ 3 files changed, 6 insertions(+), 4 deletions(-) signature.asc Description: PGP signature
Cannot read payload of an encrypted key rooted in a trusted key
In the file Documentation/security/keys-trusted-encrypted, an example is shown for to create an encrypted key rooted in trusted key. Basically, the following should work: KMK_KEY=$(keyctl add trusted kmk "new 32" @u) keyctl pipe $KMK_KEY > ~/kmk-trusted.blob EVM_KEY=$(keyctl add encrypted evm "new default trusted:kmk 32" @u) keyctl pipe $EVM_KEY > ~/evm-trusted.blob But the last command does not work. It reports "keyctl_read_alloc: Operation not supported" strace shows this: keyctl(KEYCTL_READ, 404204492, NULL, 0) = 185 keyctl(KEYCTL_READ, 404204492, 0x557a43f66260, 185) = -1 EOPNOTSUPP (Operation not supported) I've tried this on kernel 4.4.163, 4.14.83, and 4.20.6, on a machine with real TPM, and a virtual TPM in a VM, both versions 1.2 and 2.0 and none of the cases work. However, an encrypted key rooted in a (random) user key DOES work: KMK_USER=$(dd if=/dev/urandom bs=1 count=32 2>/dev/null | keyctl padd user kmk-user @u) keyctl pipe $KMK_USER > ~/kmk-user.blob EVM_USER=$(keyctl add encrypted evm-user "new default user:kmk-user 32" @u) keyctl pipe $EVM_USER > ~/evm-user.blob I'm not sure if there is a missing step in the examples, if have I hit a kernel bug, or if I'm doing something wrong.
linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
between commit:
7bb25a89aad2 ("scsi: hisi_sas: Set protection parameters prior to adding SCSI
host")
from Linus' tree and commit:
b3cce125cb1e ("scsi: hisi_sas: Add support for DIX feature for v3 hw")
from the scsi-mkp tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 8481c5795e1f,00738d0673fe..
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@@ -2698,12 -2805,6 +2806,15 @@@ hisi_sas_v3_probe(struct pci_dev *pdev
if (hisi_sas_debugfs_enable)
hisi_sas_debugfs_init(hisi_hba);
+ if (hisi_hba->prot_mask) {
+ dev_info(dev, "Registering for DIF/DIX prot_mask=0x%x\n",
+ prot_mask);
+ scsi_host_set_prot(hisi_hba->shost, prot_mask);
++ if (hisi_hba->prot_mask & HISI_SAS_DIX_PROT_MASK)
++ scsi_host_set_guard(hisi_hba->shost,
++ SHOST_DIX_GUARD_CRC);
+ }
+
rc = scsi_add_host(shost, dev);
if (rc)
goto err_out_ha;
pgpCKf9rbvnuJ.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the scsi-mkp tree with the block tree
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
include/linux/blkdev.h
between commit:
eca7abf31abb ("block: queue flag cleanup")
from the block tree and commit:
8b3238cabd50 ("scsi: block: remove bidi support")
from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/blkdev.h
index 3603270cb82d,21beb456b97a..
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -572,33 -567,37 +567,32 @@@ struct request_queue
u64 write_hints[BLK_MAX_WRITE_HINTS];
};
-#define QUEUE_FLAG_STOPPED1 /* queue is stopped */
-#define QUEUE_FLAG_DYING 2 /* queue being torn down */
-#define QUEUE_FLAG_NOMERGES 5 /* disable merge attempts */
-#define QUEUE_FLAG_SAME_COMP 6 /* complete on same CPU-group */
-#define QUEUE_FLAG_FAIL_IO7 /* fake timeout */
-#define QUEUE_FLAG_NONROT 9 /* non-rotational device (SSD) */
-#define QUEUE_FLAG_VIRTQUEUE_FLAG_NONROT /* paravirt device */
-#define QUEUE_FLAG_IO_STAT 10 /* do disk/partitions IO accounting */
-#define QUEUE_FLAG_DISCARD 11 /* supports DISCARD */
-#define QUEUE_FLAG_NOXMERGES 12 /* No extended merges */
-#define QUEUE_FLAG_ADD_RANDOM 13 /* Contributes to random pool */
-#define QUEUE_FLAG_SECERASE14 /* supports secure erase */
-#define QUEUE_FLAG_SAME_FORCE 15 /* force complete on same CPU */
-#define QUEUE_FLAG_DEAD16 /* queue tear-down finished */
-#define QUEUE_FLAG_INIT_DONE 17 /* queue is initialized */
-#define QUEUE_FLAG_NO_SG_MERGE 18 /* don't attempt to merge SG segments*/
-#define QUEUE_FLAG_POLL 19 /* IO polling enabled if set */
-#define QUEUE_FLAG_WC20 /* Write back caching */
-#define QUEUE_FLAG_FUA 21 /* device supports FUA writes */
-#define QUEUE_FLAG_FLUSH_NQ22 /* flush not queueuable */
-#define QUEUE_FLAG_DAX 23 /* device supports DAX */
-#define QUEUE_FLAG_STATS 24 /* track IO start and completion times
*/
-#define QUEUE_FLAG_POLL_STATS 25 /* collecting stats for hybrid polling
*/
-#define QUEUE_FLAG_REGISTERED 26 /* queue has been registered to a disk
*/
-#define QUEUE_FLAG_SCSI_PASSTHROUGH 27/* queue supports SCSI commands
*/
-#define QUEUE_FLAG_QUIESCED28 /* queue has been quiesced */
-#define QUEUE_FLAG_PCI_P2PDMA 29 /* device supports PCI p2p requests */
-
-#define QUEUE_FLAG_DEFAULT((1 << QUEUE_FLAG_IO_STAT) |\
- (1 << QUEUE_FLAG_SAME_COMP)| \
- (1 << QUEUE_FLAG_ADD_RANDOM))
+#define QUEUE_FLAG_STOPPED0 /* queue is stopped */
+#define QUEUE_FLAG_DYING 1 /* queue being torn down */
- #define QUEUE_FLAG_BIDI 2 /* queue supports bidi requests
*/
+#define QUEUE_FLAG_NOMERGES 3 /* disable merge attempts */
+#define QUEUE_FLAG_SAME_COMP 4 /* complete on same CPU-group */
+#define QUEUE_FLAG_FAIL_IO5 /* fake timeout */
+#define QUEUE_FLAG_NONROT 6 /* non-rotational device (SSD) */
+#define QUEUE_FLAG_VIRT QUEUE_FLAG_NONROT /* paravirt device */
+#define QUEUE_FLAG_IO_STAT7 /* do disk/partitions IO accounting */
+#define QUEUE_FLAG_DISCARD8 /* supports DISCARD */
+#define QUEUE_FLAG_NOXMERGES 9 /* No extended merges */
+#define QUEUE_FLAG_ADD_RANDOM 10 /* Contributes to random pool */
+#define QUEUE_FLAG_SECERASE 11 /* supports secure erase */
+#define QUEUE_FLAG_SAME_FORCE 12 /* force complete on same CPU */
+#define QUEUE_FLAG_DEAD 13 /* queue tear-down finished */
+#define QUEUE_FLAG_INIT_DONE 14 /* queue is initialized */
+#define QUEUE_FLAG_NO_SG_MERGE15 /* don't attempt to merge SG
segments*/
+#define QUEUE_FLAG_POLL 16 /* IO polling enabled if set */
+#define QUEUE_FLAG_WC 17 /* Write back caching */
+#define QUEUE_FLAG_FUA18 /* device supports FUA writes */
+#define QUEUE_FLAG_DAX19 /* device supports DAX */
+#define QUEUE_FLAG_STATS 20 /* track IO start and completion times
*/
+#define QUEUE_FLAG_POLL_STATS 21 /* collecting stats for hybrid polling
*/
+#define QUEUE_FLAG_REGISTERED 22 /* queue has been registered to a disk
*/
+#define QUEUE_FLAG_SCSI_PASSTHROUGH 23/* queue supports SCSI commands
*/
+#define QUEUE_FLAG_QUIESC
Re: [PATCH 0/3] generic asm: mman cleanup
On Fri, Feb 08, 2019 at 01:02:51AM -0500, Michael S. Tsirkin wrote: > Now that we have MAP_SHARED, MAP_PRIVATE and MAP_SHARED_VALIDATE on all > architectures, it probably makes sense to de-duplicate these > and put them into a common header. > > Please review and consider merging though the generic tree. > > Build tested on x86 only. Has been in linux-next for a while now. Arnd, would you consider merging at least the cleanups 2/3 and 3/3? In linux-next they had no ill effects and make things slightly cleaner IMO. > Michael S. Tsirkin (3): > x86/mpx: tweak header name > drm: tweak header name > arch: move common mmap flags to linux/mman.h > > arch/alpha/include/uapi/asm/mman.h | 4 +--- > arch/mips/include/uapi/asm/mman.h | 4 +--- > arch/parisc/include/uapi/asm/mman.h| 4 +--- > arch/x86/mm/mpx.c | 2 +- > arch/xtensa/include/uapi/asm/mman.h| 4 +--- > include/drm/drmP.h | 3 +-- > include/uapi/asm-generic/mman-common.h | 4 +--- > include/uapi/linux/mman.h | 4 > 8 files changed, 11 insertions(+), 18 deletions(-) > > -- > MST >
Re: 答复: [PATCH] XArray tests: allocation has to be GFP_ATOMIC under rcu_read_lock
On Mon, Feb 11, 2019 at 03:55:53AM +, Li,Rongqing wrote: > Could you send this patch? I put it in http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray which is included in linux-next.
答复: [PATCH] XArray tests: allocation has to be GFP_ATOMIC under rcu_read_lock
> -邮件原件- > 发件人: Matthew Wilcox [mailto:wi...@infradead.org] > 发送时间: 2019年2月3日 7:20 > 收件人: Li,Rongqing > 抄送: linux-kernel@vger.kernel.org > 主题: Re: [PATCH] XArray tests: allocation has to be GFP_ATOMIC under > rcu_read_lock > > On Tue, Jan 29, 2019 at 07:08:42PM +0800, Li RongQing wrote: > > - XA_BUG_ON(xa, xa_store_index(xa, 1, GFP_KERNEL) != NULL); > > + XA_BUG_ON(xa, xa_store_index(xa, 1, GFP_ATOMIC) != NULL); > > Did you try running this change in userspace too? I don't think it'll work. > > I think the right change would be: > Could you send this patch? Thanks -Li RongQing > +++ b/lib/test_xarray.c > @@ -107,8 +107,11 @@ static noinline void check_xas_retry(struct xarray > *xa) > XA_BUG_ON(xa, xas.xa_node != XAS_RESTART); > XA_BUG_ON(xa, xas_next_entry(&xas, ULONG_MAX) != > xa_mk_value(0)); > XA_BUG_ON(xa, xas.xa_node != NULL); > + rcu_read_unlock(); > > XA_BUG_ON(xa, xa_store_index(xa, 1, GFP_KERNEL) != NULL); > + > + rcu_read_lock(); > XA_BUG_ON(xa, !xa_is_internal(xas_reload(&xas))); > xas.xa_node = XAS_RESTART; > XA_BUG_ON(xa, xas_next_entry(&xas, ULONG_MAX) != > xa_mk_value(0));
Re: [PATCH 4/5] nvme-pci: simplify nvme_setup_irqs() via .setup_affinity callback
On Sun, Feb 10, 2019 at 07:49:12PM +0100, Thomas Gleixner wrote:
> On Fri, 25 Jan 2019, Ming Lei wrote:
> > +static int nvme_setup_affinity(const struct irq_affinity *affd,
> > + struct irq_affinity_desc *masks,
> > + unsigned int nmasks)
> > +{
> > + struct nvme_dev *dev = affd->priv;
> > + int affvecs = nmasks - affd->pre_vectors - affd->post_vectors;
> > + int curvec, usedvecs;
> > + int i;
> > +
> > + nvme_calc_io_queues(dev, nmasks);
>
> So this is the only NVME specific information. Everything else can be done
> in generic code. So what you really want is:
>
> struct affd {
> ...
> + calc_sets(struct affd *, unsigned int nvecs);
> ...
> }
>
> And sets want to be actually inside of the affinity descriptor structure:
>
> unsigned int num_sets;
> unsigned int set_vectors[MAX_SETS];
>
> We surely can define a sensible maximum of sets for now. If that ever turns
> out to be insufficient, then struct affd might become to large for the
> stack, but for now, using e.g. 8, there is no need to do so.
>
> So then the logic in the generic code becomes exactly the same as what you
> added to nvme_setup_affinity():
>
> if (affd->calc_sets) {
> affd->calc_sets(affd, nvecs);
> } else if (!affd->num_sets) {
> affd->num_sets = 1;
> affd->set_vectors[0] = affvecs;
> }
>
> for (i = 0; i < affd->num_sets; i++) {
>
> }
>
> See?
OK, will do this way in V2, then we can avoid drivers to abuse
the callback.
Thanks,
Ming
Re: [PATCH 4/5] nvme-pci: simplify nvme_setup_irqs() via .setup_affinity callback
On Sun, Feb 10, 2019 at 05:39:20PM +0100, Thomas Gleixner wrote: > On Fri, 25 Jan 2019, Ming Lei wrote: > > > Use the callback of .setup_affinity() to re-caculate number > > of queues, and build irqs affinity with help of irq_build_affinity(). > > > > Then nvme_setup_irqs() gets simplified a lot. > > I'm pretty sure you can achieve the same by reworking the core code without > that callback. Could you share the idea a bit? As I mentioned, the re-distribution needs driver's knowledge. > > > + /* Fill out vectors at the beginning that don't need affinity */ > > + for (curvec = 0; curvec < affd->pre_vectors; curvec++) > > + cpumask_copy(&masks[curvec].mask, cpu_possible_mask); > > cpu_possible_mask is wrong. Why are you deliberately trying to make this > special? There is absolutely no reason to do so. It is just for avoiding to export 'irq_default_affinity'. > > These interrupts are not managed and therefore the initial affinity has to > be irq_default_affinity. Setting them to cpu_possible_mask can and probably > will evade a well thought out default affinity mask, which was set to > isolate a set of cores from general purpose interrupts. > > This is exactly the thing which happens with driver special stuff and which > needs to be avoided. There is nothing special about this NVME setup and > yes, I can see why the current core code is a bit tedious to work with, but > that does not justify that extra driver magic by any means. OK, thanks for your explanation. Thanks, Ming
[PATCH net-next v3] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
Created a way to clear the multicast forwarding cache on a socket without having to either remove the entries manually using the delete entry socket option or destroy and recreate the multicast socket. Calling the socket option MRT_FLUSH will allow any combination of the four flag options to be cleared. MRT_FLUSH_MFC will clear all non static mfc entries MRT_FLUSH_MFC_STATIC will clear all static mfc entries MRT_FLUSH_VIFS will clear all non static interfaces MRT_FLUSH_VIFS_STATIC will clear all static interfaces. Callum Sinclair (1): ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs include/uapi/linux/mroute.h | 9 - include/uapi/linux/mroute6.h | 9 - net/ipv4/ipmr.c | 73 - net/ipv6/ip6mr.c | 78 +++- 4 files changed, 112 insertions(+), 57 deletions(-) -- 2.20.1
Re: [PATCH 2/5] genirq/affinity: allow driver to setup managed IRQ's affinity
Hello Thomas,
On Sun, Feb 10, 2019 at 05:30:41PM +0100, Thomas Gleixner wrote:
> Ming,
>
> On Fri, 25 Jan 2019, Ming Lei wrote:
>
> > This patch introduces callback of .setup_affinity into 'struct
> > irq_affinity', so that:
>
> Please see Documentation/process/submitting-patches.rst. Search for 'This
> patch'
Sorry for that, because I am not a native English speaker and it looks a bit
difficult for me to understand the subtle difference.
>
> >
> > 1) allow drivers to customize the affinity for managed IRQ, for
> > example, now NVMe has special requirement for read queues & poll
> > queues
>
> That's nothing new and already handled today.
>
> > 2) 6da4b3ab9a6e9 ("genirq/affinity: Add support for allocating interrupt
> > sets")
> > makes pci_alloc_irq_vectors_affinity() a bit difficult to use for
> > allocating interrupt sets: 'max_vecs' is required to same with 'min_vecs'.
>
> So it's a bit difficult, but you fail to explain why it's not sufficient.
The introduced limit is that 'max_vecs' has to be same with 'min_vecs' for
pci_alloc_irq_vectors_affinity() wrt. NVMe's use case since commit
6da4b3ab9a6e9, then NVMe has to deal with irq vectors allocation failure in
the awkward way of retrying.
And the topic has been discussed in the following links:
https://marc.info/?l=linux-pci&m=154655595615575&w=2
https://marc.info/?l=linux-pci&m=154646930922174&w=2
Bjorn and Keith thought this usage/interface is a bit awkward because the passed
'min_vecs' should have avoided driver's retrying.
For NVMe, when irq vectors are run out of from pci_alloc_irq_vectors_affinity(),
the requested number has to be decreased and retry until it succeeds, then the
allocated irq vectors has to be re-distributed among the whole irq sets. Turns
out the re-distribution need driver's knowledge, that is why the callback is
introduced.
>
> > With this patch, driver can implement their own .setup_affinity to
> > customize the affinity, then the above thing can be solved easily.
>
> Well, I don't really understand what is solved easily and you are merily
> describing the fact that the new callback allows drivers to customize
> something. What's the rationale? If it's just the 'bit difficult' part,
> then what is the reason for not making the core functionality easier to use
> instead of moving stuff into driver space again?
Another solution mentioned in previous discussion is to split building &
setting up
affinities from allocating irq vectors, but one big problem is that allocating
'irq_desc' needs the affinity mask for figuring out 'node', see alloc_descs().
>
> NVME is not special and all this achieves is that all drivers writers will
I mean that NVMe is the only user of irq sets.
> claim that their device is special and needs its own affinity setter
> routine. The whole point of having the generic code is to exactly avoid
> that. If it has shortcomings, then they need to be addressed, but not
> worked around with random driver callbacks.
Understood.
Thanks,
Ming
[PATCH net-next v3] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
v1 -> v2:
Implemented additional flags for static entries
v2 -> v3:
Cleaned up flag logic so any combination of routes can be cleared.
Fixed style errors
Fixed incorrect flag values
Currently the only way to clear the forwarding cache was to delete the
entries one by one using the MRT_DEL_MFC socket option or to destroy and
recreate the socket.
Create a new socket option which with the use of optional flags can
clear any combination of multicast entries (static or not static) and
multicast vifs (static or not static).
Calling the new socket option MRT_FLUSH with the flags MRT_FLUSH_MFC and
MRT_FLUSH_VIFS will clear all entries and vifs on the socket except for
static entries.
Signed-off-by: Callum Sinclair
---
include/uapi/linux/mroute.h | 9 -
include/uapi/linux/mroute6.h | 9 -
net/ipv4/ipmr.c | 73 -
net/ipv6/ip6mr.c | 78 +++-
4 files changed, 112 insertions(+), 57 deletions(-)
diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
index 5d37a9ccce63..11c8c1fc1124 100644
--- a/include/uapi/linux/mroute.h
+++ b/include/uapi/linux/mroute.h
@@ -28,12 +28,19 @@
#define MRT_TABLE (MRT_BASE+9)/* Specify mroute table ID
*/
#define MRT_ADD_MFC_PROXY (MRT_BASE+10) /* Add a (*,*|G) mfc entry
*/
#define MRT_DEL_MFC_PROXY (MRT_BASE+11) /* Del a (*,*|G) mfc entry
*/
-#define MRT_MAX(MRT_BASE+11)
+#define MRT_FLUSH (MRT_BASE+12) /* Flush all mfc entries and/or vifs
*/
+#define MRT_MAX(MRT_BASE+12)
#define SIOCGETVIFCNT SIOCPROTOPRIVATE/* IP protocol privates */
#define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT_FLUSH optional flags */
+#define MRT_FLUSH_MFC 1 /* Flush multicast entries */
+#define MRT_FLUSH_MFC_STATIC 2 /* Flush static multicast entries */
+#define MRT_FLUSH_VIFS 4 /* Flush multicast vifs */
+#define MRT_FLUSH_VIFS_STATIC 8 /* Flush static multicast vifs */
+
#define MAXVIFS32
typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short vifi_t;
diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
index cc006390..ac84ef11b29c 100644
--- a/include/uapi/linux/mroute6.h
+++ b/include/uapi/linux/mroute6.h
@@ -31,12 +31,19 @@
#define MRT6_TABLE (MRT6_BASE+9) /* Specify mroute table ID
*/
#define MRT6_ADD_MFC_PROXY (MRT6_BASE+10) /* Add a (*,*|G) mfc entry
*/
#define MRT6_DEL_MFC_PROXY (MRT6_BASE+11) /* Del a (*,*|G) mfc entry
*/
-#define MRT6_MAX (MRT6_BASE+11)
+#define MRT6_FLUSH (MRT6_BASE+12) /* Flush all mfc entries and/or vifs
*/
+#define MRT6_MAX (MRT6_BASE+12)
#define SIOCGETMIFCNT_IN6 SIOCPROTOPRIVATE/* IP protocol privates
*/
#define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT6_FLUSH optional flags */
+#define MRT6_FLUSH_MFC 1 /* Flush multicast entries */
+#define MRT6_FLUSH_MFC_STATIC 2 /* Flush static multicast entries */
+#define MRT6_FLUSH_VIFS4 /* Flushing multicast vifs */
+#define MRT6_FLUSH_VIFS_STATIC 8 /* Flush static multicast vifs */
+
#define MAXMIFS32
typedef unsigned long mifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short mifi_t;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index e536970557dd..2c95ef8cf224 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -110,7 +110,7 @@ static int ipmr_cache_report(struct mr_table *mrt,
static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
int cmd);
static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
-static void mroute_clean_tables(struct mr_table *mrt, bool all);
+static void mroute_clean_tables(struct mr_table *mrt, int flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
@@ -415,7 +415,8 @@ static struct mr_table *ipmr_new_table(struct net *net, u32
id)
static void ipmr_free_table(struct mr_table *mrt)
{
del_timer_sync(&mrt->ipmr_expire_timer);
- mroute_clean_tables(mrt, true);
+ mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC |
+ MRT_FLUSH_MFC |
MRT_FLUSH_MFC_STATIC);
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
@@ -1296,7 +1297,7 @@ static int ipmr_mfc_add(struct net *net, struct mr_table
*mrt,
}
/* Close the multicast socket, and clear the vif tables etc */
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+static void mroute_clean_tables(struct mr_table *mrt, int flags)
{
struct net *net = read_pnet(&mrt->net);
struct mr_mfc *c, *tmp;
@@ -1305,35 +1306,4
Re: [PATCH] PCI: Probe bridge window attributes once at enumeration-time
On Mon, Feb 11, 2019 at 01:57:20AM +, Xuyandong (Yandong Xu, Euler5) wrote:
> > On Tue, Jan 29, 2019 at 05:02:26PM -0600, Bjorn Helgaas wrote:
> > > On Tue, Jan 29, 2019 at 05:47:32PM -0500, Michael S. Tsirkin wrote:
> > > > On Tue, Jan 29, 2019 at 04:43:33PM -0600, Bjorn Helgaas wrote:
> > > > > On Tue, Jan 22, 2019 at 01:02:54PM -0600, Bjorn Helgaas wrote:
> > > > > > From: Bjorn Helgaas
> > > > > >
> > > > > > pci_bridge_check_ranges() determines whether a bridge supports
> > > > > > the optional I/O and prefetchable memory windows and sets the
> > > > > > flag bits in the bridge resources. This *could* be done once
> > > > > > during enumeration except that the resource allocation code
> > > > > > completely clears the flag bits, e.g., in the
> > > > > > pci_assign_unassigned_bridge_resources() path.
> > > > > >
> > > > > > The problem with pci_bridge_check_ranges() in the resource
> > > > > > allocation path is that we may allocate resources after devices
> > > > > > have been claimed by drivers, and pci_bridge_check_ranges()
> > > > > > *changes* the window registers to determine whether they're
> > > > > > writable. This may break concurrent accesses to devices behind the
> > bridge.
> > > > > >
> > > > > > Add a new pci_read_bridge_windows() to determine whether a
> > > > > > bridge supports the optional windows, call it once during
> > > > > > enumeration, remember the results, and change
> > > > > > pci_bridge_check_ranges() so it doesn't touch the bridge windows but
> > sets the flag bits based on those remembered results.
> > > > > >
> > > > > > Link:
> > > > > > https://lore.kernel.org/linux-pci/1506151482-113560-1-git-send-e
> > > > > > mail-wangzh...@hisilicon.com
> > > > > > Link:
> > > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02082.h
> > > > > > tml
> > > > > > Reported-by: xuyandong
> > > > > > Tested-by: xuyandong
> > > > > > Cc: Sagi Grimberg
> > > > > > Cc: Ofer Hayut
> > > > > > Cc: Roy Shterman
> > > > > > Cc: Keith Busch
> > > > > > Cc: Zhou Wang
> > > > >
> > > > > Applied to pci/enumeration for v5.1.
> > > > >
> > > > > This is fairly simple in concept, but doesn't meet the letter of
> > > > > the restrictions in Documentation/process/stable-kernel-rules.rst,
> > > > > so I didn't tag it for stable.
> > > > >
> > > > > Is there a compelling argument to mark it for stable?
> > > >
> > > > Well it's needed downstream.
> > > > It's a bit above 100 lines with context. Is this what you mean?
> > >
> > > Yep, I should have been explicit about that.
> > >
> > > > If yes how about using my patch for stable as an alternative?
> > > > The rules allow for equivalent patches.
> > >
> > > Well, yes, that would be a possibility.
> > >
> > > I would rather develop an argument for marking *this* patch for
> > > stable. Even though it is technically too large, I think we could
> > > make it work if we have compelling reasons.
> > >
> > > Those would need to be fleshed out a little more than "needed
> > > downstream" -- something about the scenarios where this happens, what
> > > the serious problem is, etc.
> > >
> > > The *ideal* thing would be to have an actual bugzilla.kernel.org
> > > report of the problem with a way to reproduce it and dmesg
> > > illustrating the problem.
> >
> > xuyandong would you like to take a stub at creating the bugzilla entry?
> > If not let me know and I'll do it.
> > Thanks!
> >
> Thanks, but I do not want to create the bugzilla entry.
OK that's fair, you did quite a lot already.
Xuyandong thanks a lot for your contribution in reporting the problem,
proposing fixes and then testing patches, it is very much appreciated!
>
> >
> > > > > > ---
> > > > > > drivers/pci/probe.c | 52
> > +++
> > > > > > drivers/pci/setup-bus.c | 45
> > > > > > -
> > > > > > include/linux/pci.h |3 +++
> > > > > > 3 files changed, 59 insertions(+), 41 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index
> > > > > > 257b9f6f2ebb..2ef8b954c65a 100644
> > > > > > --- a/drivers/pci/probe.c
> > > > > > +++ b/drivers/pci/probe.c
> > > > > > @@ -348,6 +348,57 @@ static void pci_read_bases(struct pci_dev *dev,
> > unsigned int howmany, int rom)
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > +static void pci_read_bridge_windows(struct pci_dev *bridge) {
> > > > > > + u16 io;
> > > > > > + u32 pmem, tmp;
> > > > > > +
> > > > > > + pci_read_config_word(bridge, PCI_IO_BASE, &io);
> > > > > > + if (!io) {
> > > > > > + pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
> > > > > > + pci_read_config_word(bridge, PCI_IO_BASE, &io);
> > > > > > + pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
> > > > > > + }
> > > > > > + if (io)
> > > > > > + bridge->io_window = 1;
> > > > > > +
> > > > > > + /*
> > > > > > +* DECchip 21050 pass 2 errata: the
Re: [PATCH v1 4/7] iommu/vt-d: Remove unnecessary local variable initializations
Hi,
On 2/11/19 11:33 AM, Bjorn Helgaas wrote:
On Sun, Feb 10, 2019 at 8:00 PM Lu Baolu wrote:
Hi,
On 2/9/19 6:06 AM, Bjorn Helgaas wrote:
From: Bjorn Helgaas
A local variable initialization is a hint that the variable will be used in
an unusual way. If the initialization is unnecessary, that hint becomes a
distraction.
Remove unnecessary initializations. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/intel-iommu.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 81077803880f..2acd08c82cdc 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -865,7 +865,7 @@ static void free_context_table(struct intel_iommu *iommu)
static struct dma_pte *pfn_to_dma_pte(struct dmar_domain *domain,
unsigned long pfn, int *target_level)
{
- struct dma_pte *parent, *pte = NULL;
+ struct dma_pte *parent, *pte;
int level = agaw_to_level(domain->agaw);
int offset;
@@ -922,7 +922,7 @@ static struct dma_pte *dma_pfn_level_pte(struct dmar_domain
*domain,
unsigned long pfn,
int level, int *large_page)
{
- struct dma_pte *parent, *pte = NULL;
+ struct dma_pte *parent, *pte;
int total = agaw_to_level(domain->agaw);
int offset;
@@ -954,7 +954,7 @@ static void dma_pte_clear_range(struct dmar_domain *domain,
unsigned long start_pfn,
unsigned long last_pfn)
{
- unsigned int large_page = 1;
+ unsigned int large_page;
struct dma_pte *first_pte, *pte;
BUG_ON(!domain_pfn_supported(domain, start_pfn));
@@ -1132,7 +1132,7 @@ static struct page *domain_unmap(struct dmar_domain
*domain,
unsigned long start_pfn,
unsigned long last_pfn)
{
- struct page *freelist = NULL;
+ struct page *freelist;
I am afraid this change might cause problem. "freelist" might go through
dma_pte_clear_level() without any touches.
Thanks for your review! Can you clarify your concern? "freelist"
isn't passed into dma_pte_clear_level(). Here's the existing code
Oh!
Yes, you are right. I confused it with another function. Sorry about it.
Best regards,
Lu Baolu
linux-next: manual merge of the phy-next tree with the net-next tree
Hi all,
Today's linux-next merge of the phy-next tree got conflicts in:
drivers/phy/marvell/Kconfig
drivers/phy/marvell/Makefile
between commit:
14dc100b4411 ("phy: armada38x: add common phy support")
from the net-next tree and commit:
9695375a3f4a ("phy: add A3700 COMPHY support")
cc8b7a0ae866 ("phy: add A3700 UTMI PHY driver")
from the phy-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/phy/marvell/Kconfig
index 224ea4e6a46d,b8e9dd38ad0d..
--- a/drivers/phy/marvell/Kconfig
+++ b/drivers/phy/marvell/Kconfig
@@@ -21,16 -21,27 +21,37 @@@ config PHY_BERLIN_US
help
Enable this to support the USB PHY on Marvell Berlin SoCs.
+ config PHY_MVEBU_A3700_COMPHY
+ tristate "Marvell A3700 comphy driver"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ depends on HAVE_ARM_SMCCC
+ default y
+ select GENERIC_PHY
+ help
+ This driver allows to control the comphy, a hardware block providing
+ shared serdes PHYs on Marvell Armada 3700. Its serdes lanes can be
+ used by various controllers: Ethernet, SATA, USB3, PCIe.
+
+ config PHY_MVEBU_A3700_UTMI
+ tristate "Marvell A3700 UTMI driver"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ default y
+ select GENERIC_PHY
+ help
+ Enable this to support Marvell A3700 UTMI PHY driver.
+
+config PHY_MVEBU_A38X_COMPHY
+ tristate "Marvell Armada 38x comphy driver"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ select GENERIC_PHY
+ help
+This driver allows to control the comphy, an hardware block providing
+shared serdes PHYs on Marvell Armada 38x. Its serdes lanes can be
+used by various controllers (Ethernet, sata, usb, PCIe...).
+
config PHY_MVEBU_CP110_COMPHY
tristate "Marvell CP110 comphy driver"
depends on ARCH_MVEBU || COMPILE_TEST
diff --cc drivers/phy/marvell/Makefile
index 59b6c03ef756,82f291cf59ee..
--- a/drivers/phy/marvell/Makefile
+++ b/drivers/phy/marvell/Makefile
@@@ -2,7 -2,8 +2,9 @@@
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+= phy-armada375-usb2.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
+ obj-$(CONFIG_PHY_MVEBU_A3700_COMPHY) += phy-mvebu-a3700-comphy.o
+ obj-$(CONFIG_PHY_MVEBU_A3700_UTMI)+= phy-mvebu-a3700-utmi.o
+obj-$(CONFIG_PHY_MVEBU_A38X_COMPHY) += phy-armada38x-comphy.o
obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_PXA_28NM_HSIC) += phy-pxa-28nm-hsic.o
pgp2AIawa9JUu.pgp
Description: OpenPGP digital signature
[PATCH v2] i2c: core-smbus: don't trace smbus_reply data on errors
If an smbus transfer fails, there's no guarantee that the output buffer was written. So, avoid trying to show the output buffer when tracing after an error. This was 'mostly harmless', but would trip up kasan checking if left-over cruft in byte 0 is a large length, causing us to read from unwritten memory. Signed-off-by: John Sperbeck --- drivers/i2c/i2c-core-smbus.c | 2 +- include/trace/events/smbus.h | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c index 9cd66cabb84f..132119112596 100644 --- a/drivers/i2c/i2c-core-smbus.c +++ b/drivers/i2c/i2c-core-smbus.c @@ -585,7 +585,7 @@ s32 __i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, trace: /* If enabled, the reply tracepoint is conditional on read_write. */ trace_smbus_reply(adapter, addr, flags, read_write, - command, protocol, data); + command, protocol, data, res); trace_smbus_result(adapter, addr, flags, read_write, command, protocol, res); diff --git a/include/trace/events/smbus.h b/include/trace/events/smbus.h index d2fb6e1d3e10..a4892a187842 100644 --- a/include/trace/events/smbus.h +++ b/include/trace/events/smbus.h @@ -138,9 +138,9 @@ TRACE_EVENT_CONDITION(smbus_reply, TP_PROTO(const struct i2c_adapter *adap, u16 addr, unsigned short flags, char read_write, u8 command, int protocol, -const union i2c_smbus_data *data), - TP_ARGS(adap, addr, flags, read_write, command, protocol, data), - TP_CONDITION(read_write == I2C_SMBUS_READ), +const union i2c_smbus_data *data, int res), + TP_ARGS(adap, addr, flags, read_write, command, protocol, data, res), + TP_CONDITION(res >= 0 && read_write == I2C_SMBUS_READ), TP_STRUCT__entry( __field(int,adapter_nr ) __field(__u16, addr) -- 2.20.1.791.gb4d0f1c61a-goog
Re: [PATCH v1 4/7] iommu/vt-d: Remove unnecessary local variable initializations
On Sun, Feb 10, 2019 at 8:00 PM Lu Baolu wrote:
>
> Hi,
>
> On 2/9/19 6:06 AM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > A local variable initialization is a hint that the variable will be used in
> > an unusual way. If the initialization is unnecessary, that hint becomes a
> > distraction.
> >
> > Remove unnecessary initializations. No functional change intended.
> >
> > Signed-off-by: Bjorn Helgaas
> > ---
> > drivers/iommu/intel-iommu.c | 27 +--
> > 1 file changed, 13 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index 81077803880f..2acd08c82cdc 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -865,7 +865,7 @@ static void free_context_table(struct intel_iommu
> > *iommu)
> > static struct dma_pte *pfn_to_dma_pte(struct dmar_domain *domain,
> > unsigned long pfn, int *target_level)
> > {
> > - struct dma_pte *parent, *pte = NULL;
> > + struct dma_pte *parent, *pte;
> > int level = agaw_to_level(domain->agaw);
> > int offset;
> >
> > @@ -922,7 +922,7 @@ static struct dma_pte *dma_pfn_level_pte(struct
> > dmar_domain *domain,
> >unsigned long pfn,
> >int level, int *large_page)
> > {
> > - struct dma_pte *parent, *pte = NULL;
> > + struct dma_pte *parent, *pte;
> > int total = agaw_to_level(domain->agaw);
> > int offset;
> >
> > @@ -954,7 +954,7 @@ static void dma_pte_clear_range(struct dmar_domain
> > *domain,
> > unsigned long start_pfn,
> > unsigned long last_pfn)
> > {
> > - unsigned int large_page = 1;
> > + unsigned int large_page;
> > struct dma_pte *first_pte, *pte;
> >
> > BUG_ON(!domain_pfn_supported(domain, start_pfn));
> > @@ -1132,7 +1132,7 @@ static struct page *domain_unmap(struct dmar_domain
> > *domain,
> >unsigned long start_pfn,
> >unsigned long last_pfn)
> > {
> > - struct page *freelist = NULL;
> > + struct page *freelist;
>
> I am afraid this change might cause problem. "freelist" might go through
> dma_pte_clear_level() without any touches.
Thanks for your review! Can you clarify your concern? "freelist"
isn't passed into dma_pte_clear_level(). Here's the existing code
(before this patch). I don't see a use of "freelist" before we assign
the result of dma_pte_clear_level() to it. But maybe I'm overlooking
something.
static struct page *domain_unmap(struct dmar_domain *domain,
unsigned long start_pfn,
unsigned long last_pfn)
{
struct page *freelist = NULL;
BUG_ON(!domain_pfn_supported(domain, start_pfn));
BUG_ON(!domain_pfn_supported(domain, last_pfn));
BUG_ON(start_pfn > last_pfn);
/* we don't need lock here; nobody else touches the iova range */
freelist = dma_pte_clear_level(domain, agaw_to_level(domain->agaw),
domain->pgd, 0, start_pfn,
last_pfn, NULL);
Re: [PATCH net-next v5 09/12] socket: Add SO_TIMESTAMPING_NEW
On Feb 10, 2019, at 7:43 AM, Ran Rozenstein wrote:
>> Subject: [PATCH net-next v5 09/12] socket: Add SO_TIMESTAMPING_NEW
>>
>> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
>> This is the y2038 safe versions of the SO_TIMESTAMPING_OLD for all
>> architectures.
>>
>> Signed-off-by: Deepa Dinamani
>> Acked-by: Willem de Bruijn
>
>
> Hi,
>
> I have app that include:
>#include
>
> It now fail with this error:
>In file included from timestamping.c:6:0:
>/usr/include/linux/errqueue.h:46:27: error: array type has incomplete
> element type 'struct __kernel_timespec'
> struct __kernel_timespec ts[3];
> ^~
> I tried to do the trivial fix, to include time.h:
> In include/uapi/linux/errqueue.h
>#include
>#include
>
> But it just add some other noises:
>In file included from /usr/include/linux/errqueue.h:5:0,
> from timestamping.c:6:
>/usr/include/linux/time.h:10:8: error: redefinition of ?struct
> timespec?
> struct timespec {
>^~~~
>In file included from /usr/include/sys/select.h:39:0,
> from /usr/include/sys/types.h:197,
> from /usr/include/stdlib.h:279,
> from timestamping.c:2:
>/usr/include/bits/types/struct_timespec.h:8:8: note:
> originally defined here
> struct timespec
>^~~~
>In file included from /usr/include/linux/errqueue.h:5:0,
> from timestamping.c:6:
>/usr/include/linux/time.h:16:8: error: redefinition of ?struct
> timeval?
> struct timeval {
>^~~
>In file included from /usr/include/sys/select.h:37:0,
> from /usr/include/sys/types.h:197,
> from /usr/include/stdlib.h:279,
> from timestamping.c:2:
>/usr/include/bits/types/struct_timeval.h:8:8: note: originally
> defined here
> struct timeval
>^~~
>
>
> Can you please advise how to solve it?
>
> Thanks,
> Ran
The errqueue.h already had the same issue reported previously:
https://lore.kernel.org/netdev/CAF=yd-l2ntuh54j_swn9wcpbmgkv_v0e-q2pu2mrq3+1roz...@mail.gmail.com/
Earlier when I tested this with kernel selftests such as
tools/testing/selftests/networking/timestamping/rxtimestamp(the test
was broken to begin with because of missing include of unistd.h), I
was using make.cross to build.
This does not put the headers in the right place
(obj-$ARCH/usr/include instead of usr/include). Hence, I did not
realize that this breaks the inclusion of errqueue.h due to the
missing __kernel_timespec definition.
I forgot that nobody seems to be using linux/time.h.
But, if I include guards( #ifndef __KERNEL__) for struct timespec,
struct timeval etc for linux/time.h, then we can include it from
userspace/ errqueue.h for __kernel_timespec:
--- a/include/uapi/linux/errqueue.h
+++ b/include/uapi/linux/errqueue.h
@@ -2,7 +2,7 @@
#ifndef _UAPI_LINUX_ERRQUEUE_H
#define _UAPI_LINUX_ERRQUEUE_H
-#include
+#include
struct sock_extended_err {
__u32 ee_errno;
diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
index a6aca9aaab80..40913d9a5bc8 100644
--- a/include/uapi/linux/time.h
+++ b/include/uapi/linux/time.h
@@ -5,6 +5,8 @@
#include
+#ifdef __KERNEL__
+
#ifndef _STRUCT_TIMESPEC
#define _STRUCT_TIMESPEC
struct timespec {
@@ -42,6 +44,8 @@ struct itimerval {
struct timeval it_value;/* current value */
};
+#endif /* __KERNEL__ */
Arnd,
I forgot how we plan to include the definition for __kernel_timespec
for libc or userspace. Does this seem right to you?
Also these changes to errqueue.h needs to be reverted probably as this
breaks userspace.
Thanks,
-Deepa
-Deepa
Re: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6
Hey,
Thanks for the note, but..
On Sun, Feb 10, 2019 at 04:25:16AM +, pr-tracker-...@kernel.org wrote:
> The pull request you sent on Sat, 9 Feb 2019 20:17:23 -0800:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
> > fixes
>
> has been merged into torvalds/linux.git:
> https://git.kernel.org/torvalds/c/7ad915f5ebf5b9e7ca98a7048d8f84a631fe388b
I think the bot is off here because the above commit is about a merge
from the linux-omap tree from Tony.
7ad915f5ebf5 ("Merge tag 'omap-for-v3.10-rc1/fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes")
not the above pull. In fact, this pull was not merged so far, as per the log
of v5.0-rc6. I mean, this is a very late fixes pull anyways and I can always
resend the pull, but I believe the bot got confused this time.
>
> Thank you!
>
> --
> Deet-doot-dot, I am a bot.
> https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 1/4] ARM: dts: imx6qdl-sabresd: add regulator control for isl29023 sensor
On Thu, Feb 07, 2019 at 03:18:30PM +, Anson Huang wrote: > The isl29023 light sensor driver has supported regulator control, > assign the power supply for isl29023 to enable the control. > > Signed-off-by: Anson Huang Applied all, thanks.
RE: [v5 2/2] arm64: dts: lx2160a: add sata node support
>-Original Message-
>From: Shawn Guo
>Sent: 2019年2月1日 14:30
>To: Peng Ma
>Cc: ax...@kernel.dk; robh...@kernel.org; mark.rutl...@arm.com; Leo Li
>; linux-...@vger.kernel.org; devicet...@vger.kernel.org;
>linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Andy Tang
>
>Subject: Re: [v5 2/2] arm64: dts: lx2160a: add sata node support
>
>On Fri, Jan 25, 2019 at 08:10:13AM +, Peng Ma wrote:
>> Add SATA device nodes for fsl-lx2160a and enable support for QDS and
>> RDB boards.
>>
>> Signed-off-by: Peng Ma
>> ---
>> changed for V5:
>> - no change
>>
>> arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts | 16 +++
>> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 16 +++
>> arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 44
>+
>> 3 files changed, 76 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> index 99a22ab..1a5acf6 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>> @@ -95,6 +95,22 @@
>> };
>> };
>>
>> +&sata0 {
>> +status = "okay";
>> +};
>> +
>> +&sata1 {
>> +status = "okay";
>> +};
>> +
>> +&sata2 {
>> +status = "okay";
>> +};
>> +
>> +&sata3 {
>> +status = "okay";
>> +};
>> +
>> &uart0 {
>> status = "okay";
>> };
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> index 6481e5f..5b6799e 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>> @@ -102,6 +102,22 @@
>> };
>> };
>>
>> +&sata0 {
>> +status = "okay";
>> +};
>> +
>> +&sata1 {
>> +status = "okay";
>> +};
>> +
>> +&sata2 {
>> +status = "okay";
>> +};
>> +
>> +&sata3 {
>> +status = "okay";
>> +};
>> +
>> &uart0 {
>> status = "okay";
>> };
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> index a79f5c1..592034b 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>> @@ -671,6 +671,50 @@
>> status = "disabled";
>> };
>>
>> +sata0: sata@320 {
>> +compatible = "fsl,lx2160a-ahci";
>
>Has the kernel driver been patched to probe the compatible?
>
>Shawn
Yes, the driver patch is http://patchwork.ozlabs.org/patch/1034083/
BR
Peng
>
>> +reg = <0x0 0x320 0x0 0x1>,
>> + <0x7 0x100520 0x0 0x4>;
>> +reg-names = "ahci", "sata-ecc";
>> +interrupts = ;
>> +clocks = <&clockgen 4 3>;
>> +dma-coherent;
>> +status = "disabled";
>> +};
>> +
>> +sata1: sata@321 {
>> +compatible = "fsl,lx2160a-ahci";
>> +reg = <0x0 0x321 0x0 0x1>,
>> + <0x7 0x100520 0x0 0x4>;
>> +reg-names = "ahci", "sata-ecc";
>> +interrupts = ;
>> +clocks = <&clockgen 4 3>;
>> +dma-coherent;
>> +status = "disabled";
>> +};
>> +
>> +sata2: sata@322 {
>> +compatible = "fsl,lx2160a-ahci";
>> +reg = <0x0 0x322 0x0 0x1>,
>> + <0x7 0x100520 0x0 0x4>;
>> +reg-names = "ahci", "sata-ecc";
>> +interrupts = ;
>> +clocks = <&clockgen 4 3>;
>> +dma-coherent;
>> +status = "disabled";
>> +};
>> +
>> +sata3: sata@323 {
>> +compatible = "fsl,lx2160a-ahci";
>> +reg = <0x0 0x323 0x0 0x1>,
>> + <0x7 0x100520 0x0 0x4>;
>> +reg-names = "ahci", "sata-ecc";
>> +interrupts = ;
>> +clocks = <&clockgen 4 3>;
>> +dma-coherent;
>> +status = "disabled";
>> +};
>> +
>> smmu: iommu@500 {
>> compatible = "arm,mmu-500";
>> reg = <0 0x500 0 0x80>;
>> --
>> 1.7.1
>>
Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group
Hi Peter
> The problem I have with this is that it will make schedstats even more
expensive :/
I think the overhead for accounting hierarchy wait time is just the
same as cpuacct.usage. If the performance overhead is low enough(<
1%), is it acceptable?
Thanks
Yuzhoujian
Peter Zijlstra 于2019年2月7日周四 上午1:19写道：
>
> On Wed, Jan 23, 2019 at 05:46:56PM +0800, ufo19890...@gmail.com wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index e2ff4b6..35e89ca 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -858,6 +858,19 @@ static void update_curr_fair(struct rq *rq)
> > }
> >
> > static inline void
> > +update_hierarchy_wait_sum(struct sched_entity *se,
> > + u64 delta_wait)
> > +{
> > + for_each_sched_entity(se) {
> > + struct cfs_rq *cfs_rq = cfs_rq_of(se);
> > +
> > + if (cfs_rq->tg != &root_task_group)
> > + __schedstat_add(cfs_rq->hierarchy_wait_sum,
> > + delta_wait);
> > + }
> > +}
> > +
> > +static inline void
> > update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > {
> > struct task_struct *p;
> > @@ -880,6 +893,7 @@ static void update_curr_fair(struct rq *rq)
> > return;
> > }
> > trace_sched_stat_wait(p, delta);
> > + update_hierarchy_wait_sum(se, delta);
> > }
> >
> > __schedstat_set(se->statistics.wait_max,
>
> The problem I have with this is that it will make schedstats even more
> expensive :/
[PATCH] Input: qt2160 - remove redundant spinlock
From: Sven Van Asbroeck
Remove a spinlock which prevents schedule_delayed_work() and
mod_delayed_work() from executing concurrently.
This was required back when mod_delayed_work() did not exist,
and had to be implemented with a cancel + schedule. See
commit e7c2f967445d ("workqueue: use mod_delayed_work() instead of
__cancel + queue")
schedule_delayed_work() and mod_delayed_work() can now be used
concurrently. So the spinlock is no longer needed.
Cc: Tejun Heo
Signed-off-by: Sven Van Asbroeck
---
drivers/input/keyboard/qt2160.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/input/keyboard/qt2160.c b/drivers/input/keyboard/qt2160.c
index 43b86482dda0..23dc7c0c7d78 100644
--- a/drivers/input/keyboard/qt2160.c
+++ b/drivers/input/keyboard/qt2160.c
@@ -69,7 +69,6 @@ struct qt2160_data {
struct i2c_client *client;
struct input_dev *input;
struct delayed_work dwork;
- spinlock_t lock;/* Protects canceling/rescheduling of dwork */
unsigned short keycodes[ARRAY_SIZE(qt2160_key2code)];
u16 key_matrix;
#ifdef CONFIG_LEDS_CLASS
@@ -221,22 +220,15 @@ static int qt2160_get_key_matrix(struct qt2160_data
*qt2160)
static irqreturn_t qt2160_irq(int irq, void *_qt2160)
{
struct qt2160_data *qt2160 = _qt2160;
- unsigned long flags;
-
- spin_lock_irqsave(&qt2160->lock, flags);
mod_delayed_work(system_wq, &qt2160->dwork, 0);
- spin_unlock_irqrestore(&qt2160->lock, flags);
-
return IRQ_HANDLED;
}
static void qt2160_schedule_read(struct qt2160_data *qt2160)
{
- spin_lock_irq(&qt2160->lock);
schedule_delayed_work(&qt2160->dwork, QT2160_CYCLE_INTERVAL);
- spin_unlock_irq(&qt2160->lock);
}
static void qt2160_worker(struct work_struct *work)
@@ -406,7 +398,6 @@ static int qt2160_probe(struct i2c_client *client,
qt2160->client = client;
qt2160->input = input;
INIT_DELAYED_WORK(&qt2160->dwork, qt2160_worker);
- spin_lock_init(&qt2160->lock);
input->name = "AT42QT2160 Touch Sense Keyboard";
input->id.bustype = BUS_I2C;
--
2.17.1
Re: [PATCH] MAINTAINERS: use tab instead of spaces
On Sun, 2019-02-10 at 10:25 -0800, James Bottomley wrote:
> On Sun, 2019-02-10 at 19:10 +0100, Lukas Bulwahn wrote:
> > Mimi Zohar used spaces instead of a tab when adding Jarkko Sakkinen
> > as
> > further maintainer to the KEYS-TRUSTED section entry. So, we rectify
> > this
> > with this commit.
> >
> > The issue was detected when writing a script that parses MAINTAINERS.
> >
> > Fixes: 34bccd61b139 ("MAINTAINERS: add Jarkko as maintainer for
> > trusted keys")
> > Signed-off-by: Lukas Bulwahn
>
> This isn't really a bug, is it?
No, it's a style defect.
> We have no formatting requirements for the MAINTAINERS file and the
> section owner is free to align with tabs, spaces or nothing as they see
> fit. Most use a single tab, but a couple don't. The only real thing
> that cares is get_maintainers.pl and it uses \s* as the parse regexp,
> so it doesn't care either.
Not really.
It doesn't 'care' because get_maintainer is designed
to work with badly formatted entries.
checkpatch does emit warnings for MAINTAINER entries
that use anything other than a single tab.
Re: [PATCH] arm64: dts: imx8mq: Add RTC support
On Thu, Jan 31, 2019 at 03:01:22PM +, Abel Vesa wrote: > Add RTC support for i.MX8MQ. > > Signed-off-by: Abel Vesa Applied, thanks.
[PATCH] mt76: change the retun type of mt76_dma_attach()
There is no need to retun 0 in mt76_dma_attach(), so switch it to void.
Signed-off-by: Ryder Lee
---
drivers/net/wireless/mediatek/mt76/dma.c | 3 +--
drivers/net/wireless/mediatek/mt76/dma.h | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c
b/drivers/net/wireless/mediatek/mt76/dma.c
index e2ba263..d934d72 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -522,10 +522,9 @@ int mt76_dma_tx_queue_skb(struct mt76_dev *dev, struct
mt76_queue *q,
.kick = mt76_dma_kick_queue,
};
-int mt76_dma_attach(struct mt76_dev *dev)
+void mt76_dma_attach(struct mt76_dev *dev)
{
dev->queue_ops = &mt76_dma_ops;
- return 0;
}
EXPORT_SYMBOL_GPL(mt76_dma_attach);
diff --git a/drivers/net/wireless/mediatek/mt76/dma.h
b/drivers/net/wireless/mediatek/mt76/dma.h
index 357cc35..e3292df 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.h
+++ b/drivers/net/wireless/mediatek/mt76/dma.h
@@ -54,7 +54,7 @@ enum mt76_mcu_evt_type {
EVT_EVENT_DFS_DETECT_RSP,
};
-int mt76_dma_attach(struct mt76_dev *dev);
+void mt76_dma_attach(struct mt76_dev *dev);
void mt76_dma_cleanup(struct mt76_dev *dev);
#endif
--
1.9.1
Re: [PATCHv2] media: videobuf2: Return error after allocation failure
On Mon, Feb 4, 2019 at 8:27 PM Souptick Joarder wrote:
>
> There is no point to continuing assignment after memory allocation
> failed, rather throw error immediately.
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> v1 -> v2:
> Corrected typo in change log.
>
> drivers/media/common/videobuf2/videobuf2-vmalloc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 6dfbd5b..d3f71e2 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -46,16 +46,16 @@ static void *vb2_vmalloc_alloc(struct device *dev,
> unsigned long attrs,
>
> buf->size = size;
> buf->vaddr = vmalloc_user(buf->size);
> - buf->dma_dir = dma_dir;
> - buf->handler.refcount = &buf->refcount;
> - buf->handler.put = vb2_vmalloc_put;
> - buf->handler.arg = buf;
>
> if (!buf->vaddr) {
> pr_debug("vmalloc of size %ld failed\n", buf->size);
> kfree(buf);
> return ERR_PTR(-ENOMEM);
> }
> + buf->dma_dir = dma_dir;
> + buf->handler.refcount = &buf->refcount;
> + buf->handler.put = vb2_vmalloc_put;
> + buf->handler.arg = buf;
>
> refcount_set(&buf->refcount, 1);
> return buf;
> --
> 1.9.1
>
[PATCHv11 0/3] Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the FPGA FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the FPGA framebuffer IP and displayed on the Display Port Monitor. Ong Hean Loong (2): ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite Ong, Hean Loong (1): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 63 +++ arch/arm/configs/socfpga_defconfig |5 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivip/Kconfig | 14 ++ drivers/gpu/drm/ivip/Makefile |7 + drivers/gpu/drm/ivip/intel_vip_conn.c | 87 ++ drivers/gpu/drm/ivip/intel_vip_core.c | 152 + drivers/gpu/drm/ivip/intel_vip_drv.h | 40 + drivers/gpu/drm/ivip/intel_vip_of.c| 177 10 files changed, 548 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
[PATCHv11 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 371fca4..21d8d2b 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -112,6 +112,11 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 1.7.1
[PATCHv11 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Device tree binding for Intel FPGA Video and Image Processing Suite. The
binding involved would be generated from the Altera (Intel) Qsys system. The
bindings would set the max width, max height, buts per pixel and memory port
width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
V8:
*Add port to Display port decoder
V7:
*Fix OF graph for better description
*Add description for encoder
V6:
*Description have not describe DT device in general
V5:
*remove bindings for bits per symbol as it has only one value which is 8
V4:
*fix properties that does not describe the values
V3:
*OF graph not in accordance to graph.txt
V2:
*Remove Linux driver description
V1:
*Missing vendor prefix
Signed-off-by: Ong, Hean Loong
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 63
1 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..89a3b9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,63 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+ on the frame reader
+
+Optional sub-nodes:
+- ports: The connection to the encoder
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+ Port 0 Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Required Properties Example:
+
+
+framebuffer@10280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x0001 0x0280 0x0040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,mem-port-width = <128>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ fb_output: endpoint {
+ remote-endpoint =
<&dp_encoder_input>;
+ };
+ };
+ };
+};
--
1.7.1
[PATCHv11 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Signed-off-by: Ong, Hean Loong
---
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile |7 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 91
drivers/gpu/drm/ivip/intel_vip_core.c | 189 +
drivers/gpu/drm/ivip/intel_vip_drv.h | 73 +
drivers/gpu/drm/ivip/intel_vip_of.c | 181 +++
6 files changed, 555 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only
single
+ frame buffer is supported. Note that ACPI and X_86
architecture
+ is not supported for Arria10. If M is selected the module
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..3fd2e75
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..93ce0b3
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * Authors:
+ * Walter Goossens
+ * Thomas Chou
+ * Chris Rauer
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .detect = intelvipfb_drm_connector_detect,
+ .reset = drm_atomic_helper_connector_reset,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+ .destroy = intelvipfb_drm_connector_destroy,
+};
+
+static int intelvipfb_drm_connector_get_modes(struct drm_connector *connector)
+{
+ struct drm_device *drm = connector->dev;
+ int count;
+
+ count = drm_add_modes_noedid(connector, drm->mode_config.max_width,
+ drm->mode_config.max_height);
+ drm_set_preferred_mode(connector, drm->mode_config.max_width,
+ drm->mode_config.max_height);
+ return count;
+}
+
+static const struct drm_connector_helper_funcs
+intelvipfb_drm_connector_helper_funcs = {
+ .get_modes = intelvipfb_drm_connector_get_modes,
+};
+
+struct drm_connector *
+intelvipfb_conn_setup(struct drm_device *drm)
+{
+ struct drm_connector *conn;
+ int ret;
+
+ conn = devm_kzalloc(drm->dev, sizeof(*conn), GFP_KERNEL);
+ if (IS_ERR(conn))
+ return NULL;
+
+ drm_connector_helper_add(conn, &intelvipfb_drm_connector_helper_funcs);
+ ret = drm_connector_init(drm, conn, &intelvipfb_drm_connector_funcs,
+ DRM_MODE_CONNECTOR_DisplayPort);
+ if (ret < 0) {
+ dev_err(drm->dev, "failed to initialize drm connector\n");
+ ret = -ENOMEM;
+ goto error_connector_cleanup;
+ }
+
+ return conn;
+
+
Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
On 02/10/2019 09:00 PM, Waiman Long wrote: > As the generic rwsem-xadd code is using the appropriate acquire and > release versions of the atomic operations, the arch specific rwsem.h > files will not be that much faster than the generic code as long as the > atomic functions are properly implemented. So we can remove those arch > specific rwsem.h and stop building asm/rwsem.h to reduce maintenance > effort. > > Currently, only x86, alpha and ia64 have implemented architecture > specific fast paths. I don't have access to alpha and ia64 systems for > testing, but they are legacy systems that are not likely to be updated > to the latest kernel anyway. > > By using a rwsem microbenchmark, the total locking rates on a 4-socket > 56-core 112-thread x86-64 system before and after the patch were as > follows (mixed means equal # of read and write locks): > > Before Patch After Patch ># of Threads wlock rlock mixed wlock rlock mixed > - - - - - - > 127,373 29,409 28,17028,773 30,164 29,276 > 2 7,697 14,922 1,703 7,435 15,167 1,729 > 4 6,987 14,285 1,490 7,181 14,438 1,330 > 8 6,650 13,652 761 6,918 13,796 718 >16 6,434 15,729 713 6,554 16,030 625 >32 5,590 15,312 552 6,124 15,344 471 >64 5,980 15,478 61 5,668 15,509 58 > > There were some run-to-run variations for the multi-thread tests. For > x86-64, using the generic C code fast path seems to be a liitle bit > faster than the assembly version especially for read-lock and when lock > contention is low. Looking at the assembly version of the fast paths, > there are assembly to/from C code wrappers that save and restore all > the callee-clobbered registers (7 registers on x86-64). The assembly > generated from the generic C code doesn't need to do that. That may > explain the slight performance gain here. > > The generic asm rwsem.h can also be merged into kernel/locking/rwsem.h > as no other code other than those under kernel/locking needs to access > the internal rwsem macros and functions. > > Signed-off-by: Waiman Long I have decided to break the rwsem patchset that I sent out on last Thursday into 3 parts. This patch is part 0 as it touches a number of arch specific files and so have the widest distribution. I would like to get it merged first. Part 1 will be patches 1-10 (except 4) of my original rwsem patchset. This part moves things around, adds more debugging capability and lays the ground work for the next part. Part 2 will contains the remaining patches which are the real beef of the whole patchset. Cheers, Longman
