Re: [PATCH 4.9 00/63] 4.9.126-stable review
On 09/09/2018 11:35 PM, Greg Kroah-Hartman wrote: On Sun, Sep 09, 2018 at 01:53:51PM -0700, Guenter Roeck wrote: On 09/09/2018 11:03 AM, Greg Kroah-Hartman wrote: On Sun, Sep 09, 2018 at 08:54:41AM -0700, Guenter Roeck wrote: On 09/09/2018 01:55 AM, Greg Kroah-Hartman wrote: On Sat, Sep 08, 2018 at 02:14:53PM -0700, Guenter Roeck wrote: On 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 149 fail: 2 Failed builds: powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 301 pass: 285 fail: 16 Failed tests: powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs powerpc:pseries:pseries_defconfig:initrd powerpc:pseries:pseries_defconfig:scsi:rootfs powerpc:pseries:pseries_defconfig:mmc:rootfs powerpc:pseries:pseries_defconfig:nvme:rootfs powerpc:pseries:pseries_defconfig:little:initrd powerpc:pseries:pseries_defconfig:little:scsi:rootfs powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs powerpc:pseries:pseries_defconfig:little:mmc:rootfs powerpc:pseries:pseries_defconfig:little:nvme:rootfs powerpc:powernv:powernv_defconfig:initrd Details are available at https://kerneltests.org/builders/. I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not. For v4.9.125-65-g0f793f1ec4f3: Build results: total: 151 pass: 150 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 301 pass: 301 fail: 0 arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges': arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree' arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges': arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc' Oops, forgot to fix that one. Shoould now be resolved. Did you push your change ? My builders didn't pick it up. Yes, I pushed out the "real" 4.9.125 release with the fix in it. You mean 4.9.126. But you didn't push the update to linux-stable-rc, which is why my builders don't see it. Guenter
Re: [PATCH] uio: convert to vm_fault_t
On Sat, Sep 1, 2018 at 10:25 PM Souptick Joarder wrote:
>
> As part of commit 9b85e95a3080 ("uio: Change return
> type to vm_fault_t") in 4.19-rc1, this conversion
> was missed. Now converted 'ret' to vm_fault_t type.
Greg, this was missed. Yes, this is not a regression fix,
but can we get this patch in 4.19-rc-X else it might go untraced
and later generate compile error when actual vm_fault_t will be
introduced ?
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/uio/uio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 70a7981..8fae1a4 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -668,7 +668,7 @@ static vm_fault_t uio_vma_fault(struct vm_fault *vmf)
> struct page *page;
> unsigned long offset;
> void *addr;
> - int ret = 0;
> + vm_fault_t ret = 0;
> int mi;
>
> mutex_lock(&idev->info_lock);
> --
> 1.9.1
>
Re: Conflict between sparse and commit cafa0010cd51f ("Raise the minimum required gcc version to 4.6")
Le 07/09/2018 à 20:19, Nick Desaulniers a écrit :
On Fri, Sep 7, 2018 at 11:13 AM Luc Van Oostenryck
wrote:
On Fri, Sep 07, 2018 at 10:22:56AM -0700, Nick Desaulniers wrote:
On Fri, Sep 7, 2018 at 7:34 AM Christophe LEROY wrote:
Cc linux-spa...@vger.kernel.org
Le 07/09/2018 à 14:22, Christophe Leroy a écrit :
Since commit cafa0010cd51f ("Raise the minimum required gcc version to
4.6"), sparse check fails as follows:
[root@pc16082vm linux-powerpc]# make C=2 arch/powerpc/kernel/process.o
CALLscripts/checksyscalls.sh
CHECK scripts/mod/empty.c
./include/linux/compiler-gcc.h:14:3: error: Sorry, your compiler is too
old - please upgrade it.
CHECK arch/powerpc/kernel/process.c
./include/linux/compiler-gcc.h:14:3: error: Sorry, your compiler is too
old - please upgrade it.
I have sparse version 0.5.2
What can be done to fix that ?
Christophe
Oof, sorry Christophe. Looks like that's the latest version of sparse:
https://sparse.wiki.kernel.org/index.php/Main_Page#News
I'm curious what sparse expands __GNUC__, __GNUC_MINOR__, and
__GNUC_PATCHLEVEL__ to? Pre commit cafa0010cd51f, it MUST be
expanding them to something, otherwise you'd have seen the error then,
too. The previous check was GCC < 3.3, now it's GCC < 4.6.
Sparse expand these macros to the same version than the compiler used
to compile GCC. I find a bit strange though to have sparse v0.5.2 but
using an old compiler.
So Christophe must have a version of gcc < 4.6 installed somewhere?
Does sparse use `cc`? If so, Christophe, does your `ls -l $(which cc)`
point to an old version of gcc maybe?
Indeed it looks like sparse expand these macros to the version of the
compiler it was compiled with.
I'm building kernels for a powerpc platforms, with CROSS_COMPILE set to
ppc-linux- and ppc-linux-gcc being version 5.4
However my build machine is a CentOS6 and the native gcc has version
4.4.7, so sparse expands that version.
Is there a way to get sparse in line with my cross compiler version and
not with the local native version ?
Christophe
Also, it's worth to look at what is said in this email:
https://lore.kernel.org/lkml/ca+55afzyenzr2gzlr-dwponjmnygyody+6awlcvnaywiazu...@mail.gmail.com/
-- Luc
Re: v4.18.0+ WARNING: at mm/vmscan.c:1756 isolate_lru_page + bad page state
On Thu, 30 Aug 2018 at 15:31, Vegard Nossum wrote: > > Hi, > > Got this on a recent kernel (pretty sure it was > 2ad0d52699700a91660a406a4046017a2d7f246a but annoyingly the oops > itself doesn't tell me the exact version): > > [ cut here ] > trying to isolate tail page > WARNING: CPU: 2 PID: 19156 at mm/vmscan.c:1756 isolate_lru_page+0x235/0x250 [...] > I don't have the capacity to debug it atm and it may even have been > fixed in mainline (though searching didn't yield any other reports > AFAICT). > > I have .config and vmlinux (with DEBUG_INFO=y) if needed. > > It's not reproducible for the time being. Just a quick follow-up: I have a reproducer and Kirill Shutemov has identified the problem and provided a tentative patch. Vegard
Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage
On Mon, Sep 10, 2018 at 7:33 AM Baoquan He wrote:
>
> Hi Pingfan,
>
> On 09/06/18 at 10:36am, Pingfan Liu wrote:
> > commit 747ff6265db4 ("x86/boot/KASLR: Skip specified number of 1GB huge
> > pages when doing physical randomization (KASLR)") and commit
> > 9b912485e0e7 ("x86/boot/KASLR: Add two new functions for 1GB huge pages
> > handling") prevent the physical load addr of kernel from spoiling a good
> > candidate of GiB page. But the algorithm deterministicly chooses the most
> > front GiB page for hugetlb, and sacrifices the randomness, which
> > is the heart of the KASLR. This patch tries to enlarge the randomness in
> > the cases where hugepages=X < the num Y of good candidate of GiB
> > page.
>
> Better tell how you improve in cover letter or patch log.
>
Yes, good advice.
> > To comparison, taking a typical KVM guest for example, the head 3GiB mem
> > can not be used as GiB hugetlb. Denoting the total mem size as Z(GiB), when
> > Z=5, then Y=2, assuming X=1, the randomness range before this patch is
> > 4GiB, after this patch is 5GiB, and get a 25% improvement of randomness.
> > If Z=6, then Y=3, assuming X=2, the improvement equals: 50%( 6/(6-2) - 1);
> > assuming X=1, the improvement will be: 20% (6/(6-1) - 1)
>
> Hmm, what if hugepages=1, or 2, even 100, but system owns 1PB memory?
>
Not agree, since the kvm guest is much popular, but most of them have
no much memory.
> Secondly, even in the case that hugepages=1, system memory is 5G, if no
> 'movable_node' specified, the last 1G can't be chosen for hugepage.
> Because memblock will allocate memory top to down. This is not
> improving, but make the code not work.
>
Yes, you are right. It is too hard to consider the runtime layout at
this very early stage.
> Lastly, getting better randomness is the heart of KASLR, while
> process_mem_region() is the heart of kernel KASLR code. Unless the
> current code blocks serious fix, we'd better not touch it. Keeping
> it can make the current code logic simple and more readable. It's
Yes.
Thanks,
Pingfan
> like a proved running well machine, we just dig out the unwanted
> middle, feed the good head and tail regions into it, then it gives
> back good slot for kernel position one by one.
>
> To sum up, I personally think this patchset is not a good idea.
>
> Thanks
> Baoquan
Re: [BUG BISECT] NFS root failure (NULL pointer)
On Mon, 10 Sep 2018 at 08:44, Krzysztof Kozlowski wrote: > > On Thu, 6 Sep 2018 at 09:10, Krzysztof Kozlowski wrote: > > > > Hi, > > > > Today's next fails to mount NFS root under my ARM targets and fails to > > mount root from file image under QMU. > > > > [ 21.512866] Unable to handle kernel NULL pointer dereference at > > virtual address > > [ 21.695484] [] (nfs_fs_mount) from [] > > (legacy_get_tree+0x34/0xec) > > [ 21.703225] [] (legacy_get_tree) from [] > > (vfs_get_tree+0x64/0x180) > > [ 21.79] [] (vfs_get_tree) from [] > > (do_mount+0x21c/0x958) > > [ 21.718478] [] (do_mount) from [] > > (ksys_mount+0x8c/0xbc) > > [ 21.725513] [] (ksys_mount) from [] > > (ret_fast_syscall+0x0/0x28) > > > > Full log from ARM (NFS root): > > https://krzk.eu/#/builders/25/builds/750/steps/12/logs/serial0 > > > > The NFS root failure bisected to: > > bae551929c5433bd56ec4dcb97c7d4a50153d357 is the first bad commit > > commit bae551929c5433bd56ec4dcb97c7d4a50153d357 > > Author: David Howells > > Date: Tue Jul 10 21:43:37 2018 +0100 > > FYI, the bug is still present in linux-next. All boards fail to boot up. > > Let me know if I can help anymore in debugging this. Hm, my mistake. Today's next boots up fine. Seems fixed. Thanks! Best regards, Krzysztof
Re: [PATCH 3/3] rtc: pl031: switch to devm_rtc_allocate_device/rtc_register_device
On Sun, Sep 9, 2018 at 10:38 PM Alexandre Belloni wrote: > Switch to devm_rtc_allocate_device to simplify the erro and driver removal > paths. > > Cc: Linus Walleij > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
Re: [BUG BISECT] NFS root failure (NULL pointer)
On Thu, 6 Sep 2018 at 09:10, Krzysztof Kozlowski wrote: > > Hi, > > Today's next fails to mount NFS root under my ARM targets and fails to > mount root from file image under QMU. > > [ 21.512866] Unable to handle kernel NULL pointer dereference at > virtual address > [ 21.695484] [] (nfs_fs_mount) from [] > (legacy_get_tree+0x34/0xec) > [ 21.703225] [] (legacy_get_tree) from [] > (vfs_get_tree+0x64/0x180) > [ 21.79] [] (vfs_get_tree) from [] > (do_mount+0x21c/0x958) > [ 21.718478] [] (do_mount) from [] (ksys_mount+0x8c/0xbc) > [ 21.725513] [] (ksys_mount) from [] > (ret_fast_syscall+0x0/0x28) > > Full log from ARM (NFS root): > https://krzk.eu/#/builders/25/builds/750/steps/12/logs/serial0 > > The NFS root failure bisected to: > bae551929c5433bd56ec4dcb97c7d4a50153d357 is the first bad commit > commit bae551929c5433bd56ec4dcb97c7d4a50153d357 > Author: David Howells > Date: Tue Jul 10 21:43:37 2018 +0100 FYI, the bug is still present in linux-next. All boards fail to boot up. Let me know if I can help anymore in debugging this. Best regards, Krzysztof > > vfs: Separate changing mount flags full remount > > Separate just the changing of mount flags (MS_REMOUNT|MS_BIND) from full > remount because the mount data will get parsed with the new fs_context > stuff prior to doing a remount - and this causes the syscall to fail under > some circumstances. > > The QEMU issue seems slightly different and I did not bisect it. The > QEMU just cannot find rootfs: > [1.008052] Filesystem requires source device > [1.008513] VFS: Cannot open root device "mmcblk0" or > unknown-block(179,0): error -2 > [1.008790] Please append a correct "root=" boot option; here are > the available partitions: > [1.009300] 0100 16384 ram0 > [1.009337] (driver?) > [1.009806] fe005120 vda > [1.009843] driver: virtio_blk > [1.010296] b300 110592 mmcblk0 > [1.010319] driver: mmcblk > [1.010859] Kernel panic - not syncing: VFS: Unable to mount root > fs on unknown-block(179,0) > [1.011580] ---[ end Kernel panic - not syncing: VFS: Unable to > mount root fs on unknown-block(179,0) ]--- > > > > Boards config: > 1. Arch ARM Linux > 2. exynos_defconfig > - Odroid HC1 > ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC > Systemd: v239 > - Odroid U3 > ARMv7, quad-core, Exynos4412 SoC > Systemd: v238 > - Odroid XU > ARMv7, octa-core (Cortex-A7+A15) but only A15 working, Exynos5410 SoC > Systemd: v236 > - Odroid XU3 > ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC > Systemd: v236 > 3. Custom VF50 defconfig > - Toradex Colibri VF50 on Iris board > ARMv7, UP, Cortext-A5, NXP VF500 > Systemd: v232 > 4. All boards boot from TFTP with NFS root (NFSv4) > 5. QEMU > ARMv7, vexpress-v2p-ca9, 128 MB RAM > > > > Best regards, > Krzysztof
Re: [PATCH 0/2] s390: Use ARRAY_SIZE instead of reimplementing its function
On Sat, 8 Sep 2018 18:26:26 +0800 zhong jiang wrote: > I find the issue with the help of Coccinelle. > > zhong jiang (2): > s390: vmlogrdr: Use ARRAY_SIZE instead of reimplementing its function > s390: qeth_core_mpc: Use ARRAY_SIZE instead of reimplementing its > function > > drivers/s390/char/vmlogrdr.c | 2 +- > drivers/s390/net/qeth_core_mpc.c | 7 ++- > 2 files changed, 3 insertions(+), 6 deletions(-) Both patches applied to linux-s390:features. Thanks. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Re: [PATCH] s390: zfcp_aux: remove unnecessary null pointer check before mempool_destroy
On Sat, 8 Sep 2018 17:41:45 +0800 zhong jiang wrote: > mempool_destroy has taken null pointer check into account. so remove the > redundant check. > > Signed-off-by: zhong jiang > --- > drivers/s390/scsi/zfcp_aux.c | 21 +++-- > 1 file changed, 7 insertions(+), 14 deletions(-) Applied to linux-390:features. Thanks. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Re: [PATCH 4.9 00/63] 4.9.126-stable review
On Sun, Sep 09, 2018 at 01:53:51PM -0700, Guenter Roeck wrote: > On 09/09/2018 11:03 AM, Greg Kroah-Hartman wrote: > > On Sun, Sep 09, 2018 at 08:54:41AM -0700, Guenter Roeck wrote: > > > On 09/09/2018 01:55 AM, Greg Kroah-Hartman wrote: > > > > On Sat, Sep 08, 2018 at 02:14:53PM -0700, Guenter Roeck wrote: > > > > > On 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote: > > > > > > This is the start of the stable review cycle for the 4.9.126 > > > > > > release. > > > > > > There are 63 patches in this series, all will be posted as a > > > > > > response > > > > > > to this one. If anyone has any issues with these being applied, > > > > > > please > > > > > > let me know. > > > > > > > > > > > > Responses should be made by Sun Sep 9 21:09:58 UTC 2018. > > > > > > Anything received after that time might be too late. > > > > > > > > > > > > > > > > Build results: > > > > > total: 151 pass: 149 fail: 2 > > > > > Failed builds: > > > > > powerpc:defconfig > > > > > powerpc:allmodconfig > > > > > Qemu test results: > > > > > total: 301 pass: 285 fail: 16 > > > > > Failed tests: > > > > > powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd > > > > > powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd > > > > > powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs > > > > > powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs > > > > > powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs > > > > > powerpc:pseries:pseries_defconfig:initrd > > > > > powerpc:pseries:pseries_defconfig:scsi:rootfs > > > > > powerpc:pseries:pseries_defconfig:mmc:rootfs > > > > > powerpc:pseries:pseries_defconfig:nvme:rootfs > > > > > powerpc:pseries:pseries_defconfig:little:initrd > > > > > powerpc:pseries:pseries_defconfig:little:scsi:rootfs > > > > > powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs > > > > > powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs > > > > > powerpc:pseries:pseries_defconfig:little:mmc:rootfs > > > > > powerpc:pseries:pseries_defconfig:little:nvme:rootfs > > > > > powerpc:powernv:powernv_defconfig:initrd > > > > > > > > > > Details are available at https://kerneltests.org/builders/. > > > > > > > > I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of > > > > warnings for power that I don't think were caused by these series, I > > > > don't know if they have always been there or not. > > > > > > > > > > For v4.9.125-65-g0f793f1ec4f3: > > > > > > Build results: > > > total: 151 pass: 150 fail: 1 > > > Failed builds: > > > powerpc:allmodconfig > > > Qemu test results: > > > total: 301 pass: 301 fail: 0 > > > > > > arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges': > > > arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of > > > function 'kfree' > > > > > > arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges': > > > arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of > > > function 'krealloc' > > > > Oops, forgot to fix that one. Shoould now be resolved. > > > > Did you push your change ? My builders didn't pick it up. Yes, I pushed out the "real" 4.9.125 release with the fix in it. thanks, greg k-h
Re: [PATCH] s390/zcrypt: Use kmemdup to replace kmalloc + memcpy
On Sat, 8 Sep 2018 16:50:21 +0800 zhong jiang wrote: > kmemdup has implemented the function that kmalloc() + memcpy() will > do. and we prefer to use the kmemdup rather than the open coded > implementation. > > Signed-off-by: zhong jiang > --- > drivers/s390/crypto/zcrypt_msgtype6.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) Applied to linux-390:features. Thanks. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Re: [PATCH] ASoC: core: add support to card rebind
On 06/09/18 11:54, Mark Brown wrote: On Fri, Aug 10, 2018 at 10:37:08AM +0100, Srinivas Kandagatla wrote: Current behaviour of ASoC core w.r.t to component removal is that it unregisters dependent sound card totally. There is no support to rebind the card if the component comes back. Typical use case is DSP restart or kernel modules itself. This looks OK but needs rebasing against current code. Thanks I will rebase and send the patch. thanks, srini
Re: [PATCH] s390: zfcp_aux: remove unnecessary null pointer check before mempool_destroy
On Sat, Sep 08, 2018 at 05:41:45PM +0800, zhong jiang wrote:
> mempool_destroy has taken null pointer check into account. so remove the
> redundant check.
>
> Signed-off-by: zhong jiang
> ---
> drivers/s390/scsi/zfcp_aux.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/s390/scsi/zfcp_aux.c b/drivers/s390/scsi/zfcp_aux.c
> index 94f4d8f..e06c3f2 100644
> --- a/drivers/s390/scsi/zfcp_aux.c
> +++ b/drivers/s390/scsi/zfcp_aux.c
> @@ -248,20 +248,13 @@ static int zfcp_allocate_low_mem_buffers(struct
> zfcp_adapter *adapter)
>
> static void zfcp_free_low_mem_buffers(struct zfcp_adapter *adapter)
> {
> - if (adapter->pool.erp_req)
> - mempool_destroy(adapter->pool.erp_req);
> - if (adapter->pool.scsi_req)
> - mempool_destroy(adapter->pool.scsi_req);
> - if (adapter->pool.scsi_abort)
> - mempool_destroy(adapter->pool.scsi_abort);
> - if (adapter->pool.qtcb_pool)
> - mempool_destroy(adapter->pool.qtcb_pool);
> - if (adapter->pool.status_read_req)
> - mempool_destroy(adapter->pool.status_read_req);
> - if (adapter->pool.sr_data)
> - mempool_destroy(adapter->pool.sr_data);
> - if (adapter->pool.gid_pn)
> - mempool_destroy(adapter->pool.gid_pn);
> + mempool_destroy(adapter->pool.erp_req);
> + mempool_destroy(adapter->pool.scsi_req);
> + mempool_destroy(adapter->pool.scsi_abort);
> + mempool_destroy(adapter->pool.qtcb_pool);
> + mempool_destroy(adapter->pool.status_read_req);
> + mempool_destroy(adapter->pool.sr_data);
> + mempool_destroy(adapter->pool.gid_pn);
> }
>
Acked-by: Benjamin Block
Thank you. We'll send it along when we next send patches upstream.
--
With Best Regards, Benjamin Block / Linux on IBM Z Kernel Development
IBM Systems & Technology Group / IBM Deutschland Research & Development GmbH
Vorsitz. AufsR.: Martina Koederitz / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
Re: [PATCH v2 1/3] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size
* Baoquan He wrote:
> In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the
> initial size of the direct mapping region. This is right in the
> old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
> 46bit, and only 4-level mode was supported.
>
> Later, in commit:
> b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"),
> __PHYSICAL_MASK_SHIFT was changed to be 52 always, no matter it's
> 5-level or 4-level. This is wrong for 4-level paging. Then when
> adapt phyiscal memory region size based on available memory, it
> will overflow if the amount of system RAM and the padding is bigger
> than 64TB.
>
> In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by
> replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
>
> Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
> Signed-off-by: Baoquan He
> Acked-by: Kirill A. Shutemov
> Reviewed-by: Thomas Garnier
So this changelog has a handful of problems:
- there's a typo in the title
- what does 'memory KASLR' mean? All KASLR deals with memory.
- there's a typo in the second paragraph
- Please punctuate more precisely: '64TB' is written as '64 TB' and '46bit' is
written as
'46 bits'
- '52 always' is accurate but '52 bits always' would be more useful: write out
units where
appropriate to reduce ambiguity and parsing complexity of changelogs. Also,
in this
particular sentence it should be 'always 52 bits'.
- s/when adapt
/when we adapt
- s/This is right in the old code
/This is correct in the old code
Thanks,
Ingo
Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region
* Baoquan He wrote:
> Vmemmap region has different maximum size depending on paging mode.
> Now its size is hardcoded as 1TB in memory KASLR, this is not
> right for 5-level paging mode. It will cause overflow if vmemmap
> region is randomized to be adjacent to cpu_entry_area region and
> its actual size is bigger than 1TB.
>
> So here calculate how many TB by the actual size of vmemmap region
> and align up to 1TB boundary.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/mm/kaslr.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index 0988971069c9..1db8e166455e 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -51,7 +51,7 @@ static __initdata struct kaslr_memory_region {
> } kaslr_regions[] = {
> { &page_offset_base, 0 },
> { &vmalloc_base, 0 },
> - { &vmemmap_base, 1 },
> + { &vmemmap_base, 0 },
> };
>
> /* Get size in bytes used by the memory region */
> @@ -77,6 +77,7 @@ void __init kernel_randomize_memory(void)
> unsigned long rand, memory_tb;
> struct rnd_state rand_state;
> unsigned long remain_entropy;
> + unsigned long vmemmap_size;
>
> vaddr_start = pgtable_l5_enabled() ? __PAGE_OFFSET_BASE_L5 :
> __PAGE_OFFSET_BASE_L4;
> vaddr = vaddr_start;
> @@ -108,6 +109,14 @@ void __init kernel_randomize_memory(void)
> if (memory_tb < kaslr_regions[0].size_tb)
> kaslr_regions[0].size_tb = memory_tb;
>
> + /*
> + * Calculate how many TB vmemmap region needs, and align to
> + * 1TB boundary.
> + * */
Yeah, so that's not the standard comment style ...
> + vmemmap_size = (kaslr_regions[0].size_tb << (TB_SHIFT - PAGE_SHIFT)) *
> + sizeof(struct page);
> + kaslr_regions[2].size_tb = DIV_ROUND_UP(vmemmap_size, 1UL << TB_SHIFT);
So I tried to review what all this code does, and the comments aren't too great
to explain the
concepts.
For example:
/*
* Memory regions randomized by KASLR (except modules that use a separate logic
* earlier during boot). The list is ordered based on virtual addresses. This
* order is kept after randomization.
*/
static __initdata struct kaslr_memory_region {
unsigned long *base;
unsigned long size_tb;
} kaslr_regions[] = {
{ &page_offset_base, 0 },
{ &vmalloc_base, 0 },
{ &vmemmap_base, 1 },
};
So I get the part where the 'base' pointer is essentially pointers to various
global variables
used by the MM to get the virtual base address of the kernel, vmalloc and
vmemmap areas from,
which base addresses can thus be modified by the very early KASLR code to
dynamically shape the
virtual memory layout of these kernel memory areas on a per bootup basis.
(BTW., that would be a great piece of information to add for the uninitiated.
It's not like
it's obvious!)
But what does 'size_tb' do? Nothing explains it and your patch doesn't make it
clearer either.
Also, get_padding() looks like an unnecessary layer of obfuscation:
/* Get size in bytes used by the memory region */
static inline unsigned long get_padding(struct kaslr_memory_region *region)
{
return (region->size_tb << TB_SHIFT);
}
It's used only twice and we do bit shifts in the parent function anyway so it's
not like it's
hiding some uninteresting detail. (The style ugliness of the return statement
makes it annoying
as well.)
So could we please first clean up this code, explain it properly, name the
fields properly,
etc., before modifying it? Because it still looks unnecessarily hard to review.
I.e. this early
boot code needs improvements of quality and neither the base code nor your
patches give me the
impression of carefully created, easy to maintain code.
Thanks,
Ingo
Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow
On 2018-09-06 01:40, Bjorn Helgaas wrote:
On Thu, Aug 09, 2018 at 08:41:27PM +0530, p...@codeaurora.org wrote:
On 2018-08-09 20:27, Bharat Kumar Gogada wrote:
> As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages
> will be forwarded from the secondary interface to the primary interface,
> if the SERR# Enable bit in the Bridge Control register is set.
> Currently PCI_BRIDGE_CTL_SERR is being enabled only in
> ACPI flow.
> This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device.
>
> Signed-off-by: Bharat Kumar Gogada
> ---
> drivers/pci/pcie/aer.c | 23 +++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index a2e8838..4fb0d24 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct pci_dev
> *dev)
>if (!dev->aer_cap)
>return -EIO;
>
> + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> + u16 control;
> +
> + /*
> + * A Type-1 PCI bridge will not forward ERR_ messages coming
> + * from an endpoint if SERR# forwarding is not enabled.
> + */
> + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control);
> + if (!(control & PCI_BRIDGE_CTL_SERR)) {
> + control |= PCI_BRIDGE_CTL_SERR;
> + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control);
> + }
> + }
> +
>return pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
> PCI_EXP_AER_FLAGS);
> }
> EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
> @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct pci_dev
> *dev)
>if (pcie_aer_get_firmware_first(dev))
>return -EIO;
>
> + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> + u16 control;
> +
> + /* Clear SERR Forwarding */
> + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control);
> + control &= ~PCI_BRIDGE_CTL_SERR;
> + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control);
> + }
> +
>return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> PCI_EXP_AER_FLAGS);
> }
Hi Bjorn,
I made some comments on patchv1., same I am putting it across here.
what about hot-plug case ?
should not aer_init() call pci_enable_pcie_error_reporting() for all
the downstream pci_dev ?
and remove all the calls from drivers..
aer_init will be called for each device (pci_dev) while pciehp does
re-enumeration.
so probable we might want to call pci_enable_pcie_error_reporting()
but that dictates the design where AER framework is taking decision to
enable error reporting on behalf of drivers as well.
but thats fine I think, if drivers do not want to participate then
they have
to call pci_disable_pcie_error_reporting explicitly.
does this make sense ?
I just replied to the original patch; sorry, I forgot to add you to
the cc list. Bharat, when people respond to your v patch, can you
please add them (and anybody else *they* added) to the cc list when
you post your v patch?
If we set PCI_BRIDGE_CTL_SERR in the pci_configure_device() path,
would that address your comments?
yes, that should do.
There's still a separate question of where and how we should configure
the error bits in PCI_EXP_DEVCTL (currently done in
pci_enable_pcie_error_reporting()).
Bjorn
Re: [PATCH v2] perf/x86/intel/uncore: Provide alias for IIO free-running boxes on SKX
One week nearly passed, I guess there is no any objections for this patch from community. :) Thanks Jin Yao On 9/4/2018 3:45 PM, Jin, Yao wrote: On 9/4/2018 3:13 PM, Peter Zijlstra wrote: On Tue, Sep 04, 2018 at 06:58:17PM +0800, Jin Yao wrote: root@skx /sys/devices# ls | grep uncore_iio uncore_iio_0 uncore_iio_1 uncore_iio_2 uncore_iio_3 uncore_iio_4 uncore_iio_5 uncore_iio_free_running_0 uncore_iio_free_running_1 uncore_iio_free_running_2 uncore_iio_free_running_3 uncore_iio_free_running_4 uncore_iio_free_running_5 root@skx /sys/devices# ls | grep uncore_iio uncore_iio_0 uncore_iio_1 uncore_iio_2 uncore_iio_3 uncore_iio_4 uncore_iio_5 uncore_iio_cbdma uncore_iio_mcp0 uncore_iio_mcp1 uncore_iio_pcie0 uncore_iio_pcie1 uncore_iio_pcie2 I think I'm ok with that, except of course for people that have "free_running_#" in their scripts now and will to wtf when they upgrade their kernel. Do we care about them? Yes, that may be a potential issue but maybe it's not since we really don't know if some people have used uncore_iio_free_running_# in their scripts or not. I write this patch is because I always forget the meaning of uncore_iio_free_running_# so I have to go back to check the document "Intel Xeon Processor Scalable Memory Family Uncore Performance Monitoring" again and again to find the box definition. I guess other people may have similar trouble. Maybe we wait some time to see more feedback from community? Thanks Jin Yao
Re: [PATCH] kernel/{lockdep,hung_task}: Show locks and backtrace of running tasks.
On 2018/09/03 20:44, Tetsuo Handa wrote:
> We are getting reports from syzbot where running task seems to be
> relevant to a hung task problem but NMI backtrace does not print useful
> information [1].
According to my local cache, 69% of hung task reports from syzbot say that
one CPU was running check_hung_uninterruptible_tasks() and the other CPU
was idle. I think that this patch would in many cases give more useful
information than trigger_all_cpu_backtrace() reports. Can we try this patch?
$ ls -l */CrashLog.*[0-9a-f] | wc -l
1666
$ for i in */CrashLog.*; do awk ' BEGIN { flag = 0; } { if (index($0, "NMI
backtrace") > 0) { flag = 1; } else if (index($0, "panic") > 0) { exit; } if
(flag == 1) { print $0; } }' $i > $i.tmp; done
$ ls -l */*.tmp | wc -l
1666
$ grep -i watchdog+ */*.tmp | wc -l
1662
$ grep -i "idling at" */*.tmp | wc -l
1151
$ grep -F '' */*.tmp | wc -l
220
>
> Although commit 8cc05c71ba5f7936 ("locking/lockdep: Move sanity check to
> inside lockdep_print_held_locks()") says that calling
> lockdep_print_held_locks() on a running thread is considered unsafe,
> it is useful for syzbot to show locks and backtrace of running tasks.
> Thus, let's allow it if CONFIG_DEBUG_AID_FOR_SYZBOT is defined.
>
> [1]
> https://syzkaller.appspot.com/bug?id=8bab7a6a5597bb10f90e8227a7d8a483748d93be
>
> Signed-off-by: Tetsuo Handa
> Cc: Dmitry Vyukov
> ---
> kernel/hung_task.c | 20
> kernel/locking/lockdep.c | 9 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index b9132d1..1ac49a5 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -201,6 +201,26 @@ static void check_hung_uninterruptible_tasks(unsigned
> long timeout)
> if (hung_task_show_lock)
> debug_show_all_locks();
> if (hung_task_call_panic) {
> +#ifdef CONFIG_DEBUG_AID_FOR_SYZBOT
> + /*
> + * debug_show_all_locks() above forcibly dumped locks held by
> + * running tasks with locks held. Now, let's dump backtrace of
> + * running tasks as well, for NMI backtrace below tends to show
> + * current thread (i.e. khungtaskd thread itself) and idle CPU
> + * which are useless for debugging hung task problems.
> + */
> + rcu_read_lock();
> + for_each_process_thread(g, t) {
> + if (t->state != TASK_RUNNING || t == current)
> + continue;
> + pr_err("INFO: task %s:%d was running.\n", t->comm,
> +t->pid);
> + sched_show_task(t);
> + touch_nmi_watchdog();
> + touch_all_softlockup_watchdogs();
> + }
> + rcu_read_unlock();
> +#endif
> trigger_all_cpu_backtrace();
> panic("hung_task: blocked tasks");
> }
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index e406c5f..efeebf6 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -565,12 +565,21 @@ static void lockdep_print_held_locks(struct task_struct
> *p)
> else
> printk("%d lock%s held by %s/%d:\n", depth,
> depth > 1 ? "s" : "", p->comm, task_pid_nr(p));
> +#ifndef CONFIG_DEBUG_AID_FOR_SYZBOT
> /*
>* It's not reliable to print a task's held locks if it's not sleeping
>* and it's not the current task.
>*/
> if (p->state == TASK_RUNNING && p != current)
> return;
> +#else
> + /*
> + * But showing locks and backtrace of running tasks seems to be helpful
> + * for debugging hung task problems. Since syzbot will call panic()
> + * shortly, risking problems caused by accessing stale information is
> + * acceptable here.
> + */
> +#endif
> for (i = 0; i < depth; i++) {
> printk(" #%d: ", i);
> print_lock(p->held_locks + i);
>
Re: linux-next: 0907 fails to boot on thinkpad x60 (32bit machine)
On Sun 2018-09-09 23:46:32, Pavel Machek wrote: > Hi! > > I do have some oopses, but they seem to be different on each > boot. IIRC message was "scheduling?...on offline CPU?". > > Any ideas? Does it work for you? Seems that error is different on each try. Now it is: FS: Cannot open root device "sda4" or unknown-block(8,4): error -2 (followed by panic, but it listed sda4 as avialbe partition) Next try: sched: Unexpected reschedule of offline CPU#0! WARNING: CPU: 1 PID: 1 at ...smp.c:128 native_smp_send_reschedule (Aha, that's what I seen before) Next try: sched: Unexpected reschedule of offline CPU#0! Next try: I added "nosmp" on command line, and got FS: Cannot open root device "sda4" or unknown-block(8,4): error -2 (followed by panic, but it listed sda4 as avialbe partition) Next try: with "l1tf=off nospectre_v2 nospec_store_bypass_disable" FS: Cannot open root device "sda4" or unknown-block(8,4): error -2 (followed by panic, but it listed sda4 as avialbe partition) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] include/linux/compiler-clang.h: define __naked
ARM32 arch code uses the __naked attribute. This has previously been
defined in include/linux/compiler-gcc.h, which is no longer included
for Clang. Define __naked for Clang. Conservatively add all attributes
previously used (and supported by Clang).
This fixes compile errors when building ARM32 using Clang:
arch/arm/mach-exynos/mcpm-exynos.c:193:13: error: variable has incomplete
type 'void'
static void __naked exynos_pm_power_up_setup(unsigned int affinity_level)
^
Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
exclusive")
Signed-off-by: Stefan Agner
---
include/linux/compiler-clang.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index b1ce500fe8b3..a593e3ac0720 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -23,6 +23,12 @@
#define __no_sanitize_address __attribute__((no_sanitize("address")))
+/*
+ * ARM32 is currently the only user of __naked supported by Clang. Follow
+ * gcc: Do not trace naked functions and make sure they don't get inlined.
+ */
+#define __naked __attribute__((naked)) noinline notrace
+
/*
* Not all versions of clang implement the the type-generic versions
* of the builtin overflow checkers. Fortunately, clang implements
--
2.18.0
[PATCH 1/5] MIPS: don't select DMA_MAYBE_COHERENT from DMA_PERDEV_COHERENT
While both option select a form of conditional dma coherence they don't
actually share any code in the implementation, so untangle them.
Signed-off-by: Christoph Hellwig
Acked-by: Paul Burton
---
arch/mips/Kconfig| 2 +-
arch/mips/kernel/setup.c | 2 +-
arch/mips/mm/c-r4k.c | 17 -
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 35511999156a..0b25180028b8 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -,7 +,7 @@ config DMA_MAYBE_COHERENT
config DMA_PERDEV_COHERENT
bool
- select DMA_MAYBE_COHERENT
+ select DMA_NONCOHERENT
config DMA_NONCOHERENT
bool
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index c71d1eb7da59..6d840a44fa36 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -1067,7 +1067,7 @@ static int __init debugfs_mips(void)
arch_initcall(debugfs_mips);
#endif
-#if defined(CONFIG_DMA_MAYBE_COHERENT) && !defined(CONFIG_DMA_PERDEV_COHERENT)
+#ifdef CONFIG_DMA_MAYBE_COHERENT
/* User defined DMA coherency from command line. */
enum coherent_io_user_state coherentio = IO_COHERENCE_DEFAULT;
EXPORT_SYMBOL_GPL(coherentio);
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index a9ef057c79fe..05bd77727fb9 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1955,22 +1955,21 @@ void r4k_cache_init(void)
__flush_icache_user_range = r4k_flush_icache_user_range;
__local_flush_icache_user_range = local_r4k_flush_icache_user_range;
-#if defined(CONFIG_DMA_NONCOHERENT) || defined(CONFIG_DMA_MAYBE_COHERENT)
-# if defined(CONFIG_DMA_PERDEV_COHERENT)
- if (0) {
-# else
- if ((coherentio == IO_COHERENCE_ENABLED) ||
- ((coherentio == IO_COHERENCE_DEFAULT) && hw_coherentio)) {
-# endif
+#ifdef CONFIG_DMA_NONCOHERENT
+#ifdef CONFIG_DMA_MAYBE_COHERENT
+ if (coherentio == IO_COHERENCE_ENABLED ||
+ (coherentio == IO_COHERENCE_DEFAULT && hw_coherentio)) {
_dma_cache_wback_inv= (void *)cache_noop;
_dma_cache_wback= (void *)cache_noop;
_dma_cache_inv = (void *)cache_noop;
- } else {
+ } else
+#endif /* CONFIG_DMA_MAYBE_COHERENT */
+ {
_dma_cache_wback_inv= r4k_dma_cache_wback_inv;
_dma_cache_wback= r4k_dma_cache_wback_inv;
_dma_cache_inv = r4k_dma_cache_inv;
}
-#endif
+#endif /* CONFIG_DMA_NONCOHERENT */
build_clear_page();
build_copy_page();
--
2.18.0
Re: [PATCH v2 1/5] arm64: dts: fsl: use a generic node name for m25p80 flashes
On Sun, Sep 9, 2018 at 10:11 PM Shawn Guo wrote:
>
> The series looks good to me. @Leo, what about you?
Looks fine to me too.
Acked-by: Li Yang
>
> Shawn
>
> On Mon, Sep 03, 2018 at 04:08:36PM +0200, Alexandre Belloni wrote:
> > Use a generic node name for the m25p80 flashes on ls1043 and ls1046 boards.
> >
> > Signed-off-by: Alexandre Belloni
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 2 +-
> > arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 2 +-
> > arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 4 ++--
> > 3 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > index c7b8d2c009cd..af972e91d6bc 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > @@ -136,7 +136,7 @@
> > bus-num = <0>;
> > status = "okay";
> >
> > - qflash0: s25fl128s@0 {
> > + qflash0: flash@0 {
> > compatible = "spansion,m25p80";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> > index e69306e6b0b1..219068220b84 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> > @@ -165,7 +165,7 @@
> > bus-num = <0>;
> > status = "okay";
> >
> > - qflash0: s25fl128s@0 {
> > + qflash0: flash@0 {
> > compatible = "spansion,m25p80";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > index 440e111651d5..df676b30357b 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > @@ -103,7 +103,7 @@
> > bus-num = <0>;
> > status = "okay";
> >
> > - qflash0: s25fs512s@0 {
> > + qflash0: flash@0 {
> > compatible = "spansion,m25p80";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > @@ -111,7 +111,7 @@
> > reg = <0>;
> > };
> >
> > - qflash1: s25fs512s@1 {
> > + qflash1: flash@1 {
> > compatible = "spansion,m25p80";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > --
> > 2.19.0.rc1
> >
Re: locking/lockdep: Fix NMI handling
Hi Peter,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/locking/core]
[also build test ERROR on v4.19-rc2 next-20180906]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Peter-Zijlstra/locking-lockdep-Fix-NMI-handling/20180910-124306
config: i386-randconfig-x009-09101226 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/linux/spinlock_types.h:18:0,
from kernel/bounds.c:14:
include/linux/lockdep.h: In function 'lockdep_off':
>> include/linux/lockdep.h:277:2: error: 'current' undeclared (first use in
>> this function)
current->lockdep_recursion++;
^~~
include/linux/lockdep.h:277:2: note: each undeclared identifier is reported
only once for each function it appears in
include/linux/lockdep.h: In function 'lockdep_on':
include/linux/lockdep.h:282:2: error: 'current' undeclared (first use in
this function)
current->lockdep_recursion--;
^~~
make[2]: *** [kernel/bounds.s] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [sub-make] Error 2
vim +/current +277 include/linux/lockdep.h
274
275 static inline void lockdep_off(void)
276 {
> 277 current->lockdep_recursion++;
278 }
279
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [LKP] [tty] 0b4f83d510: INFO:task_blocked_for_more_than#seconds
On (09/07/18 08:39), Jiri Slaby wrote:
> > [ 244.944070]
> > [ 244.944070] Showing all locks held in the system:
> > [ 244.945558] 1 lock held by khungtaskd/18:
> > [ 244.946495] #0: (ptrval) (rcu_read_lock){}, at:
> > debug_show_all_locks+0x16/0x190
> > [ 244.948503] 2 locks held by askfirst/235:
> > [ 244.949439] #0: (ptrval) (&tty->ldisc_sem){}, at:
> > tty_ldisc_ref_wait+0x25/0x50
> > [ 244.951762] #1: (ptrval) (&ldata->atomic_read_lock){+.+.}, at:
> > n_tty_read+0x13d/0xa00
>
> Here, it just seems to wait for input from the user.
>
> > [ 244.953799] 1 lock held by validate_data/655:
> > [ 244.954814] #0: (ptrval) (&tty->ldisc_sem){}, at:
> > tty_ldisc_ref_wait+0x25/0x50
> > [ 244.956764] 1 lock held by dnsmasq/668:
> > [ 244.957649] #0: (ptrval) (&tty->ldisc_sem){}, at:
> > tty_ldisc_ref_wait+0x25/0x50
> > [ 244.959598] 1 lock held by dropbear/734:
> > [ 244.967564] #0: (ptrval) (&tty->ldisc_sem){}, at:
> > tty_ldisc_ref_wait+0x25/0x50
>
> Hmm, I assume there is another task waiting for write_ldsem and that one
> prevents these readers to proceed. Unfortunately, due to the defunct
> __ptrval__ pointer hashing crap, we do not see who is waiting for what.
> But I am guessing all are the same locks.
Hmm, interesting. Am I getting it right that the test did pass before.
And now we see that sort of/smells like live-lock right after the
introduction of tty_ldisc_lock() to tty_reopen().
> So I think, we are forced to limit the waiting to 5 seconds in reopen in
> the end too (the same as we do for new open in tty_init_dev).
If I got it right, LKP did test the 5*HZ patch
retval = tty_ldisc_lock(tty, 5 * HZ);
At least it's
In-Reply-To: <20180829022353.23568-3-d...@arista.com>
and
Message-Id: <20180829022353.23568-3-d...@arista.com>
is the patch which does the 5*HZ lock timeout thing.
-ss
linux-next: Tree for Sep 10
Hi all, Changes since 20180907: Dropped trees: xarray, ida (temporarily) The vfs tree lost a build failure, but I have still disabled erofs. It also gained other build failures for which I disabled building some sampels and reverted a commit. The net-next tree lost its build failure. The bfp-next tree lost its build failure. The akpm-current tree gained a conflict against the dma-mapping tree. Non-merge commits (relative to Linus' tree): 2637 2932 files changed, 91931 insertions(+), 59121 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 287 trees (counting Linus' and 66 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 (9a5682765a2e Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (f0b0d88a8251 kbuild: modules_install: warn when missing System.map file) Merging arc-current/for-curr (dd45210b6dd4 ARC: don't check for HIGHMEM pages in arch_dma_alloc) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (fac880c7d074 arm64: fix erroneous warnings in page freeing functions) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (5d407b071dc3 ip: frags: fix crash in ip_do_fragment()) Merging bpf/master (28619527b8a7 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (782710e333a5 xfrm: reset crypto_done when iterating over multiple input xfrms) Merging netfilter/master (7acfda539c0b netfilter: nf_tables: release chain in flushing set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (5b394b2ddf03 Linux 4.19-rc1) Merging mac80211/master (6eae4a6c2be3 mac80211: fix pending queue hang due to TX_DROP) Merging rdma-fixes/for-rc (8f28b178f71c RDMA/mlx4: Ensure that maximal send/receive SGE less than supported by HW) Merging sound-current/for-linus (f7c50fa636f7 ALSA: hda: Fix several mismatch for register mask and value) Merging sound-asoc-fixes/for-linus (65ee95658ef9 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (57361846b52b Linux 4.19-rc2) Merging regulator-fixes/for-linus (25be6316a30a Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (af37a01f9f7d Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (342227b42fe8 PCI: pciehp: Fix hot-add vs powerfault detection order) Merging driver-core.current/driver-core-linus (57361846b52b Linux 4.19-rc2) Merging tty.current/tty-linus (57361846b52b Linux 4.19-rc2) Merging usb.current/usb-linus (bfa150f37f80 Merge tag 'fixes-for-v4.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2
[RFC][PATCH 8/8] really consolidate INIT_C_CC definitions
From: Al Viro
they vary in two respects (renumbering of fields aside):
* sparc (and nobody else) has dsusp; set to ^Y.
* original (on i386) has discard set to historical
value (^O), mistaken comment nonwithstanding. alpha, ppc
and sparc have followed the comment. Not that we'd ever
handled that thing anyway...
Signed-off-by: Al Viro
---
arch/alpha/include/asm/termios_internal.h | 8 +---
arch/powerpc/include/asm/termios_internal.h | 3 +--
arch/sparc/include/asm/termios_internal.h | 8 +---
include/linux/termios_internal.h| 16 ++--
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/arch/alpha/include/asm/termios_internal.h
b/arch/alpha/include/asm/termios_internal.h
index 6c2a67e65992..07d5c1a6cdf6 100644
--- a/arch/alpha/include/asm/termios_internal.h
+++ b/arch/alpha/include/asm/termios_internal.h
@@ -2,13 +2,7 @@
#ifndef _ALPHA_TERMIOS_H
#define _ALPHA_TERMIOS_H
-/* eof=^D eol=\0 eol2=\0 erase=del
- werase=^W kill=^U reprint=^R sxtc=\0
- intr=^C quit=^\ susp=^Z
- start=^Qstop=^S lnext=^Vdiscard=^U
- vmin=\1 vtime=\0
-*/
-#define INIT_C_CC
"\004\000\000\177\027\025\022\000\003\034\032\000\021\023\026\025\001\000"
+#define INIT_C_CC_VDISCARD 'U'-0x40
/*
* Translate a "termio" structure into a "termios". Ugh.
diff --git a/arch/powerpc/include/asm/termios_internal.h
b/arch/powerpc/include/asm/termios_internal.h
index b93e889342cf..116b138ea232 100644
--- a/arch/powerpc/include/asm/termios_internal.h
+++ b/arch/powerpc/include/asm/termios_internal.h
@@ -12,7 +12,6 @@
#ifndef _ASM_POWERPC_TERMIOS_H
#define _ASM_POWERPC_TERMIOS_H
-/* ^C ^\ del ^U ^D 1 0 0 0 0 ^W ^R ^Z ^Q
^S ^V ^U */
-#define INIT_C_CC
"\003\034\177\025\004\001\000\000\000\000\027\022\032\021\023\026\025"
+#define INIT_C_CC_VDISCARD 'U'-0x40
#endif /* _ASM_POWERPC_TERMIOS_H */
diff --git a/arch/sparc/include/asm/termios_internal.h
b/arch/sparc/include/asm/termios_internal.h
index 028c6bd6e0a7..1649a0cecda9 100644
--- a/arch/sparc/include/asm/termios_internal.h
+++ b/arch/sparc/include/asm/termios_internal.h
@@ -13,13 +13,7 @@
#define _VMIN 4
#define _VTIME 5
-/* intr=^C quit=^\ erase=del kill=^U
- eof=^D eol=\0 eol2=\0 sxtc=\0
- start=^Qstop=^S susp=^Z dsusp=^Y
- reprint=^R discard=^U werase=^W lnext=^V
- vmin=\1 vtime=\0
-*/
-#define INIT_C_CC
"\003\034\177\025\004\000\000\000\021\023\032\031\022\025\027\026\001"
+#define INIT_C_CC_VDISCARD 'U'-0x40
/*
* Translate a "termios" structure into a "termio". Ugh.
diff --git a/include/linux/termios_internal.h b/include/linux/termios_internal.h
index 343f7868713d..549715b18d22 100644
--- a/include/linux/termios_internal.h
+++ b/include/linux/termios_internal.h
@@ -8,13 +8,24 @@
#include
#endif
-#ifndef INIT_C_CC
/* intr=^C quit=^\ erase=del kill=^U
eof=^D vtime=\0vmin=\1 sxtc=\0
start=^Qstop=^S susp=^Z eol=\0
reprint=^R discard=^U werase=^W lnext=^V
eol2=\0
+ ... except that discard is actually ^O on most of them.
*/
+#ifndef INIT_C_CC_VDISCARD
+#define INIT_C_CC_VDISCARD 'O'-0x40
+#endif
+
+#ifdef VDSUSP
+#define INIT_C_CC_VDSUSP_EXTRA [VDSUSP] = 'Y'-0x40,
+#else
+#define INIT_C_CC_VDSUSP_EXTRA
+#endif
+
+#ifndef INIT_C_CC
#define INIT_C_CC {\
[VINTR] = 'C'-0x40, \
[VQUIT] = '\\'-0x40,\
@@ -25,9 +36,10 @@
[VSTOP] = 'S'-0x40, \
[VSUSP] = 'Z'-0x40, \
[VREPRINT] = 'R'-0x40, \
- [VDISCARD] = 'O'-0x40, \
+ [VDISCARD] = INIT_C_CC_VDISCARD,\
[VWERASE] = 'W'-0x40, \
[VLNEXT] = 'V'-0x40,\
+ INIT_C_CC_VDSUSP_EXTRA \
[VMIN] = 1 }
#endif
--
2.11.0
[RFC][PATCH 2/8] move user_termio_to_kernel_termios/kernel_termios_to_user_termio
From: Al Viro
Signed-off-by: Al Viro
---
arch/alpha/include/asm/termios.h | 104 -
arch/ia64/include/asm/termios.h| 31 ---
arch/mips/include/asm/termios.h| 57
arch/parisc/include/asm/termios.h | 31 ---
arch/sparc/include/asm/termios.h | 52 +++
include/asm-generic/termios-base.h | 57
include/asm-generic/termios.h | 53 ---
include/linux/termios_internal.h | 41 +++
8 files changed, 114 insertions(+), 312 deletions(-)
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios.h
index 1cd44956ae7b..63e1ffc8f719 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios.h
@@ -2,6 +2,7 @@
#ifndef _ALPHA_TERMIOS_H
#define _ALPHA_TERMIOS_H
+#include
#include
/* eof=^D eol=\0 eol2=\0 erase=del
@@ -16,60 +17,65 @@
* Translate a "termio" structure into a "termios". Ugh.
*/
-#define user_termio_to_kernel_termios(a_termios, u_termio)
\
-({
\
- struct ktermios *k_termios = (a_termios);
\
- struct termio k_termio;
\
- int canon, ret;
\
-
\
- ret = copy_from_user(&k_termio, u_termio, sizeof(k_termio));
\
- if (!ret) {
\
- /* Overwrite only the low bits. */
\
- *(unsigned short *)&k_termios->c_iflag = k_termio.c_iflag;
\
- *(unsigned short *)&k_termios->c_oflag = k_termio.c_oflag;
\
- *(unsigned short *)&k_termios->c_cflag = k_termio.c_cflag;
\
- *(unsigned short *)&k_termios->c_lflag = k_termio.c_lflag;
\
- canon = k_termio.c_lflag & ICANON;
\
-
\
- k_termios->c_cc[VINTR] = k_termio.c_cc[_VINTR];
\
- k_termios->c_cc[VQUIT] = k_termio.c_cc[_VQUIT];
\
- k_termios->c_cc[VERASE] = k_termio.c_cc[_VERASE];
\
- k_termios->c_cc[VKILL] = k_termio.c_cc[_VKILL];
\
- k_termios->c_cc[VEOL2] = k_termio.c_cc[_VEOL2];
\
- k_termios->c_cc[VSWTC] = k_termio.c_cc[_VSWTC];
\
- k_termios->c_cc[canon ? VEOF : VMIN] = k_termio.c_cc[_VEOF];
\
- k_termios->c_cc[canon ? VEOL : VTIME] = k_termio.c_cc[_VEOL];
\
- }
\
- ret;
\
-})
+static inline int user_termio_to_kernel_termios(struct ktermios *termios,
+ struct termio __user *termio)
+{
+ struct termio v;
+ bool canon;
+
+ if (copy_from_user(&v, termio, sizeof(struct termio)))
+ return -EFAULT;
+
+ termios->c_iflag = (0x & termios->c_iflag) | v.c_iflag;
+ termios->c_oflag = (0x & termios->c_oflag) | v.c_oflag;
+ termios->c_cflag = (0x & termios->c_cflag) | v.c_cflag;
+ termios->c_lflag = (0x & termios->c_lflag) | v.c_lflag;
+ termios->c_line = (0x & termios->c_lflag) | v.c_line;
+
+ canon = v.c_lflag & ICANON;
+ termios->c_cc[VINTR] = v.c_cc[_VINTR];
+ termios->c_cc[VQUIT] = v.c_cc[_VQUIT];
+ termios->c_cc[VERASE] = v.c_cc[_VERASE];
+ termios->c_cc[VKILL] = v.c_cc[_VKILL];
+ termios->c_cc[VEOL2] = v.c_cc[_VEOL2];
+ termios->c_cc[VSWTC] = v.c_cc[_VSWTC];
+ termios->c_cc[canon ? VEOF : VMIN] = v.c_cc[_VEOF];
+ termios->c_cc[canon ? VEOL : VTIME] = v.c_cc[_VEOL];
+
+ return 0;
+}
+#define user_termio_to_kernel_termios user_termio_to_kernel_termios
/*
* Translate a "termios" structure into a "termio". Ugh.
*
* Note the "fun" _VMIN overloading.
*/
-#define kernel_termios_to_user_termio(u_termio, a_termios) \
-({ \
- struct ktermios *k_termios = (a_termios); \
- struct termio k_termio; \
- int canon; \
- \
- k_termio.c_iflag = k_termios->c_iflag; \
- k_termio.c_oflag = k_termios->c_oflag;
[RFC][PATCH 7/8] switch x86 to generic uapi asm/termios.h
From: Al Viro Signed-off-by: Al Viro --- arch/x86/include/uapi/asm/Kbuild| 1 + arch/x86/include/uapi/asm/termios.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) delete mode 100644 arch/x86/include/uapi/asm/termios.h diff --git a/arch/x86/include/uapi/asm/Kbuild b/arch/x86/include/uapi/asm/Kbuild index 322681622d1e..56994b75c491 100644 --- a/arch/x86/include/uapi/asm/Kbuild +++ b/arch/x86/include/uapi/asm/Kbuild @@ -2,6 +2,7 @@ include include/uapi/asm-generic/Kbuild.asm generic-y += bpf_perf_event.h +generic-y += termios.h generated-y += unistd_32.h generated-y += unistd_64.h generated-y += unistd_x32.h diff --git a/arch/x86/include/uapi/asm/termios.h b/arch/x86/include/uapi/asm/termios.h deleted file mode 100644 index 280d78a9d966.. --- a/arch/x86/include/uapi/asm/termios.h +++ /dev/null @@ -1 +0,0 @@ -#include -- 2.11.0
[RFC][PATCH 5/8] make generic INIT_C_CC a bit more generic
From: Al Viro
turn it into an array initializer; then mips variant folds into
it.
Signed-off-by: Al Viro
---
arch/mips/include/asm/termios.h | 9 -
include/linux/termios_internal.h | 15 ++-
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/mips/include/asm/termios.h b/arch/mips/include/asm/termios.h
index dbb62330b7a4..12bc56857bf1 100644
--- a/arch/mips/include/asm/termios.h
+++ b/arch/mips/include/asm/termios.h
@@ -12,13 +12,4 @@
#include
#include
-/*
- * intr=^C quit=^\ erase=del kill=^U
- * vmin=\1 vtime=\0eol2=\0 swtc=\0
- * start=^Qstop=^S susp=^Z vdsusp=
- * reprint=^R discard=^U werase=^W lnext=^V
- * eof=^D eol=\0
- */
-#define INIT_C_CC
"\003\034\177\025\1\0\0\0\021\023\032\0\022\017\027\026\004\0"
-
#endif /* _ASM_TERMIOS_H */
diff --git a/include/linux/termios_internal.h b/include/linux/termios_internal.h
index a77fd8df783e..d25b9a9c2faf 100644
--- a/include/linux/termios_internal.h
+++ b/include/linux/termios_internal.h
@@ -12,7 +12,20 @@
reprint=^R discard=^U werase=^W lnext=^V
eol2=\0
*/
-#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0"
+#define INIT_C_CC {\
+ [VINTR] = 'C'-0x40, \
+ [VQUIT] = '\\'-0x40,\
+ [VERASE] = '\177', \
+ [VKILL] = 'U'-0x40, \
+ [VEOF] = 'D'-0x40, \
+ [VSTART] = 'Q'-0x40,\
+ [VSTOP] = 'S'-0x40, \
+ [VSUSP] = 'Z'-0x40, \
+ [VREPRINT] = 'R'-0x40, \
+ [VDISCARD] = 'O'-0x40, \
+ [VWERASE] = 'W'-0x40, \
+ [VLNEXT] = 'V'-0x40,\
+ [VMIN] = 1 }
#endif
#ifndef user_termio_to_kernel_termios
--
2.11.0
[RFC][PATCH 4/8] make users of INIT_C_CC pull linux/termios_internal.h
From: Al Viro ... and move the default definition in there Signed-off-by: Al Viro --- arch/ia64/include/asm/termios.h | 9 - arch/parisc/include/asm/termios.h | 9 - arch/s390/include/asm/termios.h | 9 - drivers/tty/hvc/hvcs.c| 1 + drivers/tty/tty_io.c | 1 + drivers/tty/vcc.c | 1 + include/asm-generic/termios.h | 8 include/linux/termios_internal.h | 10 ++ 8 files changed, 13 insertions(+), 35 deletions(-) diff --git a/arch/ia64/include/asm/termios.h b/arch/ia64/include/asm/termios.h index 66ca23c03f3c..1cef02701401 100644 --- a/arch/ia64/include/asm/termios.h +++ b/arch/ia64/include/asm/termios.h @@ -10,13 +10,4 @@ #include - -/* intr=^C quit=^\ erase=del kill=^U - eof=^D vtime=\0vmin=\1 sxtc=\0 - start=^Qstop=^S susp=^Z eol=\0 - reprint=^R discard=^U werase=^W lnext=^V - eol2=\0 -*/ -#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0" - #endif /* _ASM_IA64_TERMIOS_H */ diff --git a/arch/parisc/include/asm/termios.h b/arch/parisc/include/asm/termios.h index 2f5153be531f..1850a90befb3 100644 --- a/arch/parisc/include/asm/termios.h +++ b/arch/parisc/include/asm/termios.h @@ -4,13 +4,4 @@ #include - -/* intr=^C quit=^\ erase=del kill=^U - eof=^D vtime=\0vmin=\1 sxtc=\0 - start=^Qstop=^S susp=^Z eol=\0 - reprint=^R discard=^U werase=^W lnext=^V - eol2=\0 -*/ -#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0" - #endif /* _PARISC_TERMIOS_H */ diff --git a/arch/s390/include/asm/termios.h b/arch/s390/include/asm/termios.h index 7ee16b5dcb6f..0e26fe97b0d4 100644 --- a/arch/s390/include/asm/termios.h +++ b/arch/s390/include/asm/termios.h @@ -9,13 +9,4 @@ #include - -/* intr=^C quit=^\ erase=del kill=^U - eof=^D vtime=\0vmin=\1 sxtc=\0 - start=^Qstop=^S susp=^Z eol=\0 - reprint=^R discard=^U werase=^W lnext=^V - eol2=\0 -*/ -#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0" - #endif /* _S390_TERMIOS_H */ diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c index cb4db1b3ca3c..f6be8f999026 100644 --- a/drivers/tty/hvc/hvcs.c +++ b/drivers/tty/hvc/hvcs.c @@ -69,6 +69,7 @@ #include #include #include +#include #include /* diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 32bc3e3fe4d3..9da2bd81e97e 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -97,6 +97,7 @@ #include #include #include +#include #include diff --git a/drivers/tty/vcc.c b/drivers/tty/vcc.c index 58b454c34560..f674306be121 100644 --- a/drivers/tty/vcc.c +++ b/drivers/tty/vcc.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h index 3ffed3886ff2..da3b0fe25442 100644 --- a/include/asm-generic/termios.h +++ b/include/asm-generic/termios.h @@ -6,12 +6,4 @@ #include #include -/* intr=^C quit=^\ erase=del kill=^U - eof=^D vtime=\0vmin=\1 sxtc=\0 - start=^Qstop=^S susp=^Z eol=\0 - reprint=^R discard=^U werase=^W lnext=^V - eol2=\0 -*/ -#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0" - #endif /* _ASM_GENERIC_TERMIOS_H */ diff --git a/include/linux/termios_internal.h b/include/linux/termios_internal.h index 894f565ffc5f..a77fd8df783e 100644 --- a/include/linux/termios_internal.h +++ b/include/linux/termios_internal.h @@ -5,6 +5,16 @@ #include #include +#ifndef INIT_C_CC +/* intr=^C quit=^\ erase=del kill=^U + eof=^D vtime=\0vmin=\1 sxtc=\0 + start=^Qstop=^S susp=^Z eol=\0 + reprint=^R discard=^U werase=^W lnext=^V + eol2=\0 +*/ +#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0" +#endif + #ifndef user_termio_to_kernel_termios /* * Translate a "termio" structure into a "termios". Ugh. -- 2.11.0
[RFC][PATCH 3/8] remove termios-base.h
From: Al Viro empty now Signed-off-by: Al Viro --- arch/powerpc/include/asm/termios.h | 2 -- arch/s390/include/asm/termios.h| 2 -- include/asm-generic/termios-base.h | 10 -- 3 files changed, 14 deletions(-) delete mode 100644 include/asm-generic/termios-base.h diff --git a/arch/powerpc/include/asm/termios.h b/arch/powerpc/include/asm/termios.h index b8353e2032d0..cb1e593e95bf 100644 --- a/arch/powerpc/include/asm/termios.h +++ b/arch/powerpc/include/asm/termios.h @@ -17,6 +17,4 @@ /* ^C ^\ del ^U ^D 1 0 0 0 0 ^W ^R ^Z ^Q ^S ^V ^U */ #define INIT_C_CC "\003\034\177\025\004\001\000\000\000\000\027\022\032\021\023\026\025" -#include - #endif /* _ASM_POWERPC_TERMIOS_H */ diff --git a/arch/s390/include/asm/termios.h b/arch/s390/include/asm/termios.h index 62759ac7a92b..7ee16b5dcb6f 100644 --- a/arch/s390/include/asm/termios.h +++ b/arch/s390/include/asm/termios.h @@ -18,6 +18,4 @@ */ #define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0" -#include - #endif /* _S390_TERMIOS_H */ diff --git a/include/asm-generic/termios-base.h b/include/asm-generic/termios-base.h deleted file mode 100644 index 63d948ab6746.. --- a/include/asm-generic/termios-base.h +++ /dev/null @@ -1,10 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* termios.h: generic termios/termio user copying/translation - */ - -#ifndef _ASM_GENERIC_TERMIOS_BASE_H -#define _ASM_GENERIC_TERMIOS_BASE_H - -#include - -#endif /* _ASM_GENERIC_TERMIOS_BASE_H */ -- 2.11.0
[RFC][PATCH 6/8] untangle asm/termios.h mess
From: Al Viro
Currently, asm/termios.h resolves either to uapi/asm/termios.h
(on architectures that don't have it) or to the same plus the
definitions that are only used by those who pull linux/termios_internal.h
That causes tons of inconveniences - e.g. we can't have generic
asm/termios.h with non-generic uapi/asm/termios.h.
Let's do the following:
* rename asm/termios.h to asm/termios_internal.h and make
linux/termios_internal.h pull that; that way all includes of
will go directly to uapi/asm/termios.h
* all but 3 architectures actually have asm/termios.h completely
generic. Make those 3 select a new config symbol (HAVE_TERMIOS_INTERNAL)
and make the include of asm/termios_internal.h conditional upon that.
Remove all generic instances of asm/termios.h (including include/asm-generic
one).
* get rid of one pointless include of in
drivers/tty.
Signed-off-by: Al Viro
---
arch/Kconfig | 3 +++
arch/alpha/Kconfig| 1 +
arch/alpha/include/asm/{termios.h => termios_internal.h} | 3 ---
arch/ia64/include/asm/termios.h | 13 -
arch/mips/include/asm/termios.h | 15 ---
arch/parisc/include/asm/termios.h | 7 ---
arch/powerpc/Kconfig | 1 +
.../powerpc/include/asm/{termios.h => termios_internal.h} | 2 --
arch/riscv/include/asm/Kbuild | 1 -
arch/s390/include/asm/termios.h | 12
arch/sparc/Kconfig| 1 +
arch/sparc/include/asm/{termios.h => termios_internal.h} | 4
drivers/tty/n_hdlc.c | 1 -
include/asm-generic/termios.h | 9 -
include/linux/termios_internal.h | 3 +++
15 files changed, 9 insertions(+), 67 deletions(-)
rename arch/alpha/include/asm/{termios.h => termios_internal.h} (97%)
delete mode 100644 arch/ia64/include/asm/termios.h
delete mode 100644 arch/mips/include/asm/termios.h
delete mode 100644 arch/parisc/include/asm/termios.h
rename arch/powerpc/include/asm/{termios.h => termios_internal.h} (96%)
delete mode 100644 arch/s390/include/asm/termios.h
rename arch/sparc/include/asm/{termios.h => termios_internal.h} (98%)
delete mode 100644 include/asm-generic/termios.h
diff --git a/arch/Kconfig b/arch/Kconfig
index 6801123932a5..a36cce432768 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -727,6 +727,9 @@ config OLD_SIGACTION
config COMPAT_OLD_SIGACTION
bool
+config HAS_TERMIOS_INTERNAL
+ bool
+
config 64BIT_TIME
def_bool ARCH_HAS_64BIT_TIME
help
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 5b4f88363453..85120bbda191 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -30,6 +30,7 @@ config ALPHA
select MODULES_USE_ELF_RELA
select ODD_RT_SIGACTION
select OLD_SIGSUSPEND
+ select HAS_TERMIOS_INTERNAL
select CPU_NO_EFFICIENT_FFS if !ALPHA_EV67
help
The Alpha is a 64-bit general-purpose processor designed and
diff --git a/arch/alpha/include/asm/termios.h
b/arch/alpha/include/asm/termios_internal.h
similarity index 97%
rename from arch/alpha/include/asm/termios.h
rename to arch/alpha/include/asm/termios_internal.h
index 63e1ffc8f719..6c2a67e65992 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios_internal.h
@@ -2,9 +2,6 @@
#ifndef _ALPHA_TERMIOS_H
#define _ALPHA_TERMIOS_H
-#include
-#include
-
/* eof=^D eol=\0 eol2=\0 erase=del
werase=^W kill=^U reprint=^R sxtc=\0
intr=^C quit=^\ susp=^Z
diff --git a/arch/ia64/include/asm/termios.h b/arch/ia64/include/asm/termios.h
deleted file mode 100644
index 1cef02701401..
--- a/arch/ia64/include/asm/termios.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Modified 1999
- * David Mosberger-Tang , Hewlett-Packard Co
- *
- * 99/01/28Added N_IRDA and N_SMSBLOCK
- */
-#ifndef _ASM_IA64_TERMIOS_H
-#define _ASM_IA64_TERMIOS_H
-
-#include
-
-#endif /* _ASM_IA64_TERMIOS_H */
diff --git a/arch/mips/include/asm/termios.h b/arch/mips/include/asm/termios.h
deleted file mode 100644
index 12bc56857bf1..
--- a/arch/mips/include/asm/termios.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1995, 1996, 2000, 2001 by Ralf Baechle
- * Copyright (C) 2000, 2001 Silicon Graphics, Inc.
- */
-#ifndef _ASM_TERMIOS_H
-#define _ASM_TERMIOS_H
-
-#include
-#include
-
-#endif /* _ASM_TERMIOS_H */
diff --git a/arch/parisc/include/asm/termio
[RFC][PATCH 1/8] start unifying termios convertors
From: Al Viro
* new header (linut/termios_internal.h), pulled by the sole user of those
suckers
* defaults for user_termios_to_kernel_termios{,_1} and
kernel_termios_to_user_termios{,_1} moved over there
Signed-off-by: Al Viro
---
arch/alpha/include/asm/termios.h | 6 --
arch/ia64/include/asm/termios.h| 5 --
arch/mips/include/asm/termios.h| 24 --
arch/parisc/include/asm/termios.h | 5 --
arch/s390/include/asm/termios.h| 3 -
arch/sparc/include/asm/termios.h | 165 -
drivers/tty/tty_ioctl.c| 1 +
include/asm-generic/termios-base.h | 11 ---
include/asm-generic/termios.h | 38 -
include/linux/termios_internal.h | 58 +
10 files changed, 148 insertions(+), 168 deletions(-)
create mode 100644 include/linux/termios_internal.h
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios.h
index 6a8c53dec57e..1cd44956ae7b 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios.h
@@ -72,10 +72,4 @@
copy_to_user(u_termio, &k_termio, sizeof(k_termio));\
})
-#define user_termios_to_kernel_termios(k, u) \
- copy_from_user(k, u, sizeof(struct termios))
-
-#define kernel_termios_to_user_termios(u, k) \
- copy_to_user(u, k, sizeof(struct termios))
-
#endif /* _ALPHA_TERMIOS_H */
diff --git a/arch/ia64/include/asm/termios.h b/arch/ia64/include/asm/termios.h
index 589c026444cc..1bd5ff9745e9 100644
--- a/arch/ia64/include/asm/termios.h
+++ b/arch/ia64/include/asm/termios.h
@@ -50,9 +50,4 @@
copy_to_user((termio)->c_cc, (termios)->c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
-#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
-
#endif /* _ASM_IA64_TERMIOS_H */
diff --git a/arch/mips/include/asm/termios.h b/arch/mips/include/asm/termios.h
index ce2d72e34274..3bd98a70e1d1 100644
--- a/arch/mips/include/asm/termios.h
+++ b/arch/mips/include/asm/termios.h
@@ -78,28 +78,4 @@ static inline int kernel_termios_to_user_termio(struct
termio __user *termio,
return 0;
}
-static inline int user_termios_to_kernel_termios(struct ktermios __user *k,
- struct termios2 *u)
-{
- return copy_from_user(k, u, sizeof(struct termios2)) ? -EFAULT : 0;
-}
-
-static inline int kernel_termios_to_user_termios(struct termios2 __user *u,
- struct ktermios *k)
-{
- return copy_to_user(u, k, sizeof(struct termios2)) ? -EFAULT : 0;
-}
-
-static inline int user_termios_to_kernel_termios_1(struct ktermios *k,
- struct termios __user *u)
-{
- return copy_from_user(k, u, sizeof(struct termios)) ? -EFAULT : 0;
-}
-
-static inline int kernel_termios_to_user_termios_1(struct termios __user *u,
- struct ktermios *k)
-{
- return copy_to_user(u, k, sizeof(struct termios)) ? -EFAULT : 0;
-}
-
#endif /* _ASM_TERMIOS_H */
diff --git a/arch/parisc/include/asm/termios.h
b/arch/parisc/include/asm/termios.h
index cded9dc90c1b..679d31db8d77 100644
--- a/arch/parisc/include/asm/termios.h
+++ b/arch/parisc/include/asm/termios.h
@@ -44,9 +44,4 @@
copy_to_user((termio)->c_cc, (termios)->c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
-#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
-
#endif /* _PARISC_TERMIOS_H */
diff --git a/arch/s390/include/asm/termios.h b/arch/s390/include/asm/termios.h
index 46fa3020b41e..62759ac7a92b 100644
--- a/arch/s390/include/asm/termios.h
+++ b/arch/s390/include/asm/termios.h
@@ -18,9 +18,6 @@
*/
#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0"
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
-
#include
#endif /* _S390_TERMIOS_H */
diff --git a/arch/sparc/include/asm/termios.h b/arch/sparc/include/asm/termios.h
index 4a558efdfa93..27a054a99a58 100644
--- a/arch/sparc/include/asm/termios.h
+++ b/arch/sparc/include/asm/termios.h
@@ -3,6 +3,7 @@
#define _SPARC_TERMIOS_H
#include
+#include
/*
@@ -64,84 +65,96 @@
err; \
})
-#define user_termios_to_kernel_termios(k, u) \
-({ \
- int err; \
- err = get_user((k)->c_iflag, &(u)->c_iflag); \
- err |= get_user((k)->c_oflag, &(u)->c_oflag); \
- err |= get_user((k)->c_cflag, &(u)->c_cflag); \
- err |= get_user((k)->c_lflag, &(u)->c_lflag
RE: [RFC PATCH v3 3/3] reset: reset-zynqmp: Adding support for Xilinx zynqmp reset controller.
Hi Philipp
Thanks for the quick response...
Please find my response inline.
> -Original Message-
> From: Philipp Zabel [mailto:p.za...@pengutronix.de]
> Sent: Wednesday, September 5, 2018 4:00 PM
> To: Nava kishore Manne ; robh...@kernel.org;
> mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> ; Jolly Shah ;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 3/3] reset: reset-zynqmp: Adding support for Xilinx
> zynqmp reset controller.
>
> Hi,
>
> thank you for the patch. I have a few comments below:
>
> On Wed, 2018-09-05 at 12:39 +0530, Nava kishore Manne wrote:
> > Add a reset controller driver for Xilinx Zynq UltraScale+ MPSoC.
> > The zynqmp reset-controller has the ability to reset lines connected
> > to different blocks and peripheral in the Soc.
> >
> > Signed-off-by: Nava kishore Manne
> > ---
> > Changes for v3:
> > -None.
> > Changes for v2:
> > -Moved eemi_ops into a priv struct as suggested
> > by philipp.
> >
> > drivers/reset/Makefile | 1 +
> > drivers/reset/reset-zynqmp.c | 115
> > +++
> > 2 files changed, 116 insertions(+)
> > create mode 100644 drivers/reset/reset-zynqmp.c
> >
> > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index
> > c1261dc..27e4a33 100644
> > --- a/drivers/reset/Makefile
> > +++ b/drivers/reset/Makefile
> > @@ -21,4 +21,5 @@ obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
> > obj-$(CONFIG_RESET_TI_SYSCON) += reset-ti-syscon.o
> > obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
> > obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
> > +obj-$(CONFIG_ARCH_ZYNQMP) += reset-zynqmp.o
> >
> > diff --git a/drivers/reset/reset-zynqmp.c
> > b/drivers/reset/reset-zynqmp.c new file mode 100644 index
> > 000..f908492
> > --- /dev/null
> > +++ b/drivers/reset/reset-zynqmp.c
> > @@ -0,0 +1,115 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018 Xilinx, Inc.
> > + *
> > + */
> > +
> > +#include
>
> I think including io.h is not necessary.
>
> [...]
Will fix in the next version.
> > +static int zynqmp_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long id)
> > +{
> > + struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
> > + int val, err;
> > +
> > + err = priv->eemi_ops->reset_get_status(ZYNQMP_RESET_ID + id, &val);
> > + if (!err)
> > + return -EINVAL;
>
> This looks like it should be
>
> if (err)
> return err;
>
> instead.
>
> [...]
Will fix in the next version.
> > +static struct reset_control_ops zynqmp_reset_ops = {
>
> static const struct reset_control_ops zynqmp_reset_ops = {
>
Will fix in the next version.
> > + .reset = zynqmp_reset_reset,
> > + .assert = zynqmp_reset_assert,
> > + .deassert = zynqmp_reset_deassert,
> > + .status = zynqmp_reset_status,
> > +};
> > +
> > +static int zynqmp_reset_probe(struct platform_device *pdev) {
> > + struct zynqmp_reset_data *priv;
> > +
> > + priv = devm_kzalloc(&pdev->dev,
> > + sizeof(*priv), GFP_KERNEL);
>
> This should fit on one line.
>
Will fix in the next version.
Regards,
Navakishore.
[RFC][PATCHES] termios.h cleanups
asm/termios.h has tons of duplication and rather
convoluted logics re includes.
First of all, while everyone has uapi asm/termios.h,
some architectures have asm/termios.h and some do not. So
include of can go either to arch asm/termios.h,
or to uapi/asm/termios.h.
In the former case asm/termios.h defines a bunch of
helpers (used in just one file) and a constant (3 more users)
and includes uapi/asm/termios.h
In the latter... uapi/asm/termios.h is in generated-y
or equivalent to it. Which is to say, it ends up doing
#include . Userland-side that would
refer to uapi/asm-generic/termios.h, but kernel-side we end
up with plain asm-generic/termios.h. Which defines the same
set of helpers and a constant and pulls uapi/asm-generic/termios.h
Helpers in question are heavily shared; there is an attempt
to put them into a common header (termios-base.h), but not all
instances use it. Another unpleasant thing is that said helpers
tend to be macros, with very little typechecking. And all of that
is pulled in by a lot more places than those that are actually
interested - 500-odd instead of 4.
Below is an attempt to untangle that; the branch is
vfs.git#work.termios,
patches in followups. FWIW, diffstat is
arch/Kconfig | 3 +
arch/alpha/Kconfig | 1 +
arch/alpha/include/asm/termios.h | 81
arch/alpha/include/asm/termios_internal.h | 72 ++
arch/ia64/include/asm/termios.h| 58
arch/mips/include/asm/termios.h| 105 ---
arch/parisc/include/asm/termios.h | 52
arch/powerpc/Kconfig | 1 +
.../include/asm/{termios.h => termios_internal.h} | 7 +-
arch/riscv/include/asm/Kbuild | 1 -
arch/s390/include/asm/termios.h| 26
arch/sparc/Kconfig | 1 +
arch/sparc/include/asm/termios.h | 147 -
arch/sparc/include/asm/termios_internal.h | 134 +++
arch/x86/include/uapi/asm/Kbuild | 1 +
arch/x86/include/uapi/asm/termios.h| 1 -
drivers/tty/hvc/hvcs.c | 1 +
drivers/tty/n_hdlc.c | 1 -
drivers/tty/tty_io.c | 1 +
drivers/tty/tty_ioctl.c| 1 +
drivers/tty/vcc.c | 1 +
include/asm-generic/termios-base.h | 78 ---
include/asm-generic/termios.h | 108 ---
include/linux/termios_internal.h | 137 +++
24 files changed, 355 insertions(+), 664 deletions(-)
delete mode 100644 arch/alpha/include/asm/termios.h
create mode 100644 arch/alpha/include/asm/termios_internal.h
delete mode 100644 arch/ia64/include/asm/termios.h
delete mode 100644 arch/mips/include/asm/termios.h
delete mode 100644 arch/parisc/include/asm/termios.h
rename arch/powerpc/include/asm/{termios.h => termios_internal.h} (70%)
delete mode 100644 arch/s390/include/asm/termios.h
delete mode 100644 arch/sparc/include/asm/termios.h
create mode 100644 arch/sparc/include/asm/termios_internal.h
delete mode 100644 arch/x86/include/uapi/asm/termios.h
delete mode 100644 include/asm-generic/termios-base.h
delete mode 100644 include/asm-generic/termios.h
create mode 100644 include/linux/termios_internal.h
RE: [RFC PATCH v3 1/3] firmware: xilinx: Add reset API's
Hi Philipp
Thanks for the quick response...
Please find my response inline.
> -Original Message-
> From: Philipp Zabel [mailto:p.za...@pengutronix.de]
> Sent: Wednesday, September 5, 2018 4:00 PM
> To: Nava kishore Manne ; robh...@kernel.org;
> mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> ; Jolly Shah ;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/3] firmware: xilinx: Add reset API's
>
> Hi,
>
> On Wed, 2018-09-05 at 12:39 +0530, Nava kishore Manne wrote:
> > This Patch Adds reset API's to support release, assert and status
> > functionalities by using firmware interface.
> >
> > Signed-off-by: Nava kishore Manne
> > ---
> > Changes for v3:
> > -None.
> > Changes for v2:
> > -New Patch.
> >
> > drivers/firmware/xilinx/zynqmp.c | 40 +++
> > include/linux/firmware/xlnx-zynqmp.h | 136
> > +++
> > 2 files changed, 176 insertions(+)
> >
> > diff --git a/drivers/firmware/xilinx/zynqmp.c
> > b/drivers/firmware/xilinx/zynqmp.c
> > index 7ccedf0..639c72f 100644
> > --- a/drivers/firmware/xilinx/zynqmp.c
> > +++ b/drivers/firmware/xilinx/zynqmp.c
> > @@ -447,6 +447,44 @@ static int zynqmp_pm_clock_getparent(u32
> clock_id, u32 *parent_id)
> > return ret;
> > }
> >
> > +/**
> > + * zynqmp_pm_reset_assert - Request setting of reset (1 - assert, 0 -
> > release)
> > + * @reset: Reset to be configured
> > + * @assert_flag: Flag stating should reset be asserted (1) or
> > + * released (0)
> > + *
> > + * Return: Returns status, either success or error+reason */ static
> > +int zynqmp_pm_reset_assert(const enum zynqmp_pm_reset reset,
> > + const enum zynqmp_pm_reset_action
> assert_flag) {
> > + return zynqmp_pm_invoke_fn(PM_RESET_ASSERT, reset, assert_flag,
> > + 0, 0, NULL);
> > +}
> > +
> > +/**
> > + * zynqmp_pm_reset_get_status - Get status of the reset
> > + * @reset: Reset whose status should be returned
> > + * @status: Returned status
> > + *
> > + * Return: Returns status, either success or error+reason */ static
> > +int zynqmp_pm_reset_get_status(const enum zynqmp_pm_reset reset,
> > + u32 *status)
> > +{
> > + u32 ret_payload[PAYLOAD_ARG_CNT];
> > + int ret;
> > +
> > + if (!status)
> > + return -EINVAL;
> > +
> > + ret = zynqmp_pm_invoke_fn(PM_RESET_GET_STATUS, reset, 0,
> > + 0, 0, ret_payload);
> > + *status = ret_payload[1];
>
> It doesn't really matter here, but in general I'd skip writing output
> arguments in
> case of error.
> For all I know, the result returned in ret_payload could be undefined.
>
Will fix in the next version.
Regards,
Navakishore.
Re: [RFC PATCH v3 1/2] dt-bindings: nand: meson: add Amlogic NAND controller driver
Hi boric,
Thanks for your quick reply.
On 9/7/2018 8:19 PM, Boris Brezillon wrote:
On Fri, 7 Sep 2018 18:57:10 +0800
Jianxin Pan wrote:
From: Liang Yang
Add Amlogic NAND controller dt-bindings for Meson SoC,
Current this driver support GXBB/GXL/AXG platform.
Signed-off-by: Liang Yang
Signed-off-by: Yixun Lan
---
.../devicetree/bindings/mtd/amlogic,meson-nand.txt | 91 ++
1 file changed, 91 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
new file mode 100644
index 000..655a778
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
@@ -0,0 +1,91 @@
+Amlogic NAND Flash Controller (NFC) for GXBB/GXL/AXG family SoCs
+
+This file documents the properties in addition to those available in
+the MTD NAND bindings.
+
+Required properties:
+- compatible : contains one of:
+ - "amlogic,meson-gxl-nfc"
+ - "amlogic,meson-axg-nfc"
+- clocks :
+ A list of phandle + clock-specifier pairs for the clocks listed
+ in clock-names.
+
+- clock-names: Should contain the following:
+ "core" - NFC module gate clock
+ "device" - device clock from eMMC sub clock controller
+
+- pins : Select pins which NFC need.
+- nand_pins: Detail NAND pins information.
You mean pinctrl-names and pinctrl-0, right? Not sure it's necessary to
document that, but if you do, please use the correct DT prop names.
I find no documentation for that in other xx_nand.txt; I will consider
to remove it.
+- amlogic,mmc-syscon : Required for NAND clocks, it's shared with SD/eMMC
+ controller port C
+
+Optional children nodes:
+Children nodes represent the available nand chips.
+
+
+
One too many blank lines here.
ok, i will remove it.
+Other properties:
+see Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
+
+Example demonstrate on AXG SoC:
+
+ sd_emmc_c_clkc: mmc@7000 {
+ compatible = "amlogic,meson-axg-mmc-clkc", "syscon";
+ reg = <0x0 0x7000 0x0 0x800>;
+ status = "okay";
+ };
+
+ nand: nfc@7800 {
+ compatible = "amlogic,meson-axg-nfc";
+ reg = <0x0 0x7800 0x0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ status = "disabled";
+
+ clocks = <&clkc CLKID_SD_EMMC_C>,
+ <&sd_emmc_c_clkc CLKID_MMC_DIV>;
+ clock-names = "core", "device";
+ amlogic,mmc-syscon = <&sd_emmc_c_clkc>;
+
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins>;
+
+ nand@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <1024>;
Drop nand-ecc- props. I guess you have a sensible default value and I
prefer when ECC requirements are directly extracted during chip
detection. Defining that in the DT is a bad habit. The only one that
could make sense (assuming you support it) is nand-ecc-maximize.
ok, i will drop them.
we adopt auto detection during init stage, it works too.
+
+ amlogic,nand-enable-scrambler;
Please drop this property (it's not longer documented).
em, we should have removed it when nfc driver never use it.
+
+ partition@0 {
+ label = "boot";
+ reg = <0x 0x0020>;
+ read-only;
+ };
+ partition@20 {
+ label = "env";
+ reg = <0x0020 0x0040>;
+ };
+ partition@60 {
+ label = "system";
+ reg = <0x0060 0x00a0>;
+ };
+ partition@100 {
+ label = "rootfs";
+ reg = <0x0100 0x0300>;
+ };
+ partition@400 {
+ label = "media";
+ reg = <0x0400 0x800>;
+ };
No need to define the partitions in your example, especially since they
should be placed in a partitions subnode with a "fixed-partitions"
compat.
ok, i will remove it.
+ };
+ };
.
RE: [RFC PATCH v3 2/3] dt-bindings: reset: Add bindings for ZynqMP reset driver
Hi Philipp
Thanks for the quick response..
Please find my commnets inline.
> -Original Message-
> From: Philipp Zabel [mailto:p.za...@pengutronix.de]
> Sent: Wednesday, September 5, 2018 3:40 PM
> To: Nava kishore Manne ; robh...@kernel.org;
> mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> ; Jolly Shah ;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 2/3] dt-bindings: reset: Add bindings for ZynqMP
> reset driver
>
> Hi,
>
> On Wed, 2018-09-05 at 12:39 +0530, Nava kishore Manne wrote:
> > Add documentation to describe Xilinx ZynqMP reset driver bindings.
> >
> > Signed-off-by: Nava kishore Manne
> > ---
> > Changes for v3:
> > -Corrected Commit Msg.
> > Changes for v2:
> > -Moved reset node as a child to firwmare
> > node.
> >
> > .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 142
> +
> > 1 file changed, 142 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmwa
> > re.txt
> > b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmwa
> > re.txt
> > index 1b431d9..351b1bb 100644
> > ---
> > a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmwa
> > re.txt
> > +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > +++ rmware.txt
> [...]
> > ---
> > Example
> > ---
> > @@ -25,5 +163,9 @@ firmware {
> > zynqmp_firmware: zynqmp-firmware {
> > compatible = "xlnx,zynqmp-firmware";
> > method = "smc";
> > + reset-controller:reset-controller@0 {
>
> I think the label should use underscore instead of hyphen, and the unit
> address
> part should be removed from the node name. There is no unit address, as there
> is no reg property inside the node and the parent node doesn't have #address-
> cells:
>
Will fix in the next version.
Regards,
Navakishore.
Reply For More Info
I have a donation for you and for my charity work in your region. Please reply me ASAp for more info
Re: [PATCH] mm: hugepage: mark splitted page dirty when needed
On Fri, Sep 07, 2018 at 01:54:35PM -0400, Jerome Glisse wrote: > On Fri, Sep 07, 2018 at 12:35:24PM +0800, Peter Xu wrote: > > On Thu, Sep 06, 2018 at 05:08:42PM +0300, Kirill A. Shutemov wrote: > > > On Thu, Sep 06, 2018 at 07:39:33PM +0800, Peter Xu wrote: > > > > On Wed, Sep 05, 2018 at 03:55:22PM +0300, Kirill A. Shutemov wrote: > > > > > On Wed, Sep 05, 2018 at 03:30:37PM +0800, Peter Xu wrote: > > > > > > On Tue, Sep 04, 2018 at 10:00:28AM -0400, Zi Yan wrote: > > > > > > > On 4 Sep 2018, at 4:01, Kirill A. Shutemov wrote: > > > > > > > > > > > > > > > On Tue, Sep 04, 2018 at 03:55:10PM +0800, Peter Xu wrote: > > > > > > > >> When splitting a huge page, we should set all small pages as > > > > > > > >> dirty if > > > > > > > >> the original huge page has the dirty bit set before. > > > > > > > >> Otherwise we'll > > > > > > > >> lose the original dirty bit. > > > > > > > > > > > > > > > > We don't lose it. It got transfered to struct page flag: > > > > > > > > > > > > > > > > if (pmd_dirty(old_pmd)) > > > > > > > > SetPageDirty(page); > > > > > > > > > > > > > > > > > > > > > > Plus, when split_huge_page_to_list() splits a THP, its subroutine > > > > > > > __split_huge_page() > > > > > > > propagates the dirty bit in the head page flag to all subpages in > > > > > > > __split_huge_page_tail(). > > > > > > > > > > > > Hi, Kirill, Zi, > > > > > > > > > > > > Thanks for your responses! > > > > > > > > > > > > Though in my test the huge page seems to be splitted not by > > > > > > split_huge_page_to_list() but by explicit calls to > > > > > > change_protection(). The stack looks like this (again, this is a > > > > > > customized kernel, and I added an explicit dump_stack() there): > > > > > > > > > > > > kernel: dump_stack+0x5c/0x7b > > > > > > kernel: __split_huge_pmd+0x192/0xdc0 > > > > > > kernel: ? update_load_avg+0x8b/0x550 > > > > > > kernel: ? update_load_avg+0x8b/0x550 > > > > > > kernel: ? account_entity_enqueue+0xc5/0xf0 > > > > > > kernel: ? enqueue_entity+0x112/0x650 > > > > > > kernel: change_protection+0x3a2/0xab0 > > > > > > kernel: mwriteprotect_range+0xdd/0x110 > > > > > > kernel: userfaultfd_ioctl+0x50b/0x1210 > > > > > > kernel: ? do_futex+0x2cf/0xb20 > > > > > > kernel: ? tty_write+0x1d2/0x2f0 > > > > > > kernel: ? do_vfs_ioctl+0x9f/0x610 > > > > > > kernel: do_vfs_ioctl+0x9f/0x610 > > > > > > kernel: ? __x64_sys_futex+0x88/0x180 > > > > > > kernel: ksys_ioctl+0x70/0x80 > > > > > > kernel: __x64_sys_ioctl+0x16/0x20 > > > > > > kernel: do_syscall_64+0x55/0x150 > > > > > > kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > > > > > > > At the very time the userspace is sending an UFFDIO_WRITEPROTECT > > > > > > ioctl > > > > > > to kernel space, which is handled by mwriteprotect_range(). In case > > > > > > you'd like to refer to the kernel, it's basically this one from > > > > > > Andrea's (with very trivial changes): > > > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git > > > > > > userfault > > > > > > > > > > > > So... do we have two paths to split the huge pages separately? > > > > > > > > > > We have two entiries that can be split: page table enties and > > > > > underlying > > > > > compound page. > > > > > > > > > > split_huge_pmd() (and variants of it) split the PMD entry into a PTE > > > > > page > > > > > table. It doens't touch underlying compound page. The page still can > > > > > be > > > > > mapped in other place as huge. > > > > > > > > > > split_huge_page() (and ivariants of it) split compound page into a > > > > > number > > > > > of 4k (or whatever PAGE_SIZE is). The operation requires splitting all > > > > > PMD, but not other way around. > > > > > > > > > > > > > > > > > Another (possibly very naive) question is: could any of you hint me > > > > > > how the page dirty bit is finally applied to the PTEs? These two > > > > > > dirty flags confused me for a few days already (the SetPageDirty() > > > > > > one > > > > > > which sets the page dirty flag, and the pte_mkdirty() which sets > > > > > > that > > > > > > onto the real PTEs). > > > > > > > > > > Dirty bit from page table entries transferes to sturct page flug and > > > > > used > > > > > for decision making in reclaim path. > > > > > > > > Thanks for explaining. It's much clearer for me. > > > > > > > > Though for the issue I have encountered, I am still confused on why > > > > that dirty bit can be ignored for the splitted PTEs. Indeed we have: > > > > > > > > if (pmd_dirty(old_pmd)) > > > > SetPageDirty(page); > > > > > > > > However to me this only transfers (as you explained above) the dirty > > > > bit (AFAIU it's possibly set by the hardware when the page is written) > > > > to the page struct of the compound page. It did not really apply to > > > > every small page of the splitted huge page. As you also explained, > > > >
linux-next: manual merge of the akpm-current tree with the dma-mapping tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/hexagon/Kconfig
between commit:
e0a9317d9004 ("hexagon: use generic dma_noncoherent_ops")
from the dma-mapping tree and commit:
365c1f4922a4 ("hexagon: switch to NO_BOOTMEM")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/hexagon/Kconfig
index 6cee842a9b44,f7934998913a..
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@@ -30,7 -29,9 +30,10 @@@ config HEXAGO
select GENERIC_CLOCKEVENTS_BROADCAST
select MODULES_USE_ELF_RELA
select GENERIC_CPU_DEVICES
+ select DMA_NONCOHERENT_OPS
+ select HAVE_MEMBLOCK
+ select ARCH_DISCARD_MEMBLOCK
+ select NO_BOOTMEM
---help---
Qualcomm Hexagon is a processor architecture designed for high
performance and low power across a wide variety of applications.
pgppr7_m2I4eD.pgp
Description: OpenPGP digital signature
Re: [PATCH] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
On Tuesday 28 August 2018 06:33 AM, Nishanth Menon wrote: > From: Lokesh Vutla > > Allow 8250 omap serial driver to be used for K3 platforms. > > Signed-off-by: Lokesh Vutla > Signed-off-by: Nishanth Menon > --- > Acked-by: Vignesh R > Now that we have the device tree support merged integrated AND we have > ARCH_K3, > Lets enable the 820 OMAP Driver to build for ARCH_K3 and make it operational. > > drivers/tty/serial/8250/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig > index f005eaf8bc57..15c2c5463835 100644 > --- a/drivers/tty/serial/8250/Kconfig > +++ b/drivers/tty/serial/8250/Kconfig > @@ -375,7 +375,7 @@ config SERIAL_8250_RT288X > > config SERIAL_8250_OMAP > tristate "Support for OMAP internal UART (8250 based driver)" > - depends on SERIAL_8250 && ARCH_OMAP2PLUS > + depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3) > help > If you have a machine based on an Texas Instruments OMAP CPU you > can enable its onboard serial ports by enabling this option. > -- Regards Vignesh
linux-next: build failure after merge of the vfs tree
Hi Al,
After merging the vfs tree, today's linux-next build (sparc64 defconfig)
failed like this:
In file included from arch/sparc/include/asm/fbio.h:5:0,
from fs/compat_ioctl.c:76:
arch/sparc/include/uapi/asm/fbio.h:100:25: error: field 'pos' has incomplete
type
struct fbcurpos pos;/* cursor position */
^~~
arch/sparc/include/uapi/asm/fbio.h:101:25: error: field 'hot' has incomplete
type
struct fbcurpos hot;/* cursor hot spot */
^~~
arch/sparc/include/uapi/asm/fbio.h:103:25: error: field 'size' has incomplete
type
struct fbcurpos size; /* cursor bit map size */
^~~~
In file included from fs/compat_ioctl.c:76:0:
arch/sparc/include/asm/fbio.h:63:18: error: field 'pos' has incomplete type
struct fbcurpos pos; /* cursor position */
^~~
arch/sparc/include/asm/fbio.h:64:18: error: field 'hot' has incomplete type
struct fbcurpos hot; /* cursor hot spot */
^~~
arch/sparc/include/asm/fbio.h:66:18: error: field 'size' has incomplete type
struct fbcurpos size; /* cursor bit map size */
^~~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of
'sizeof' to incomplete type 'struct fbcurpos'
#define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
^
fs/compat_ioctl.c:640:21: note: in definition of macro 'XFORM'
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
#define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
IGNORE_IOCTL(FBIOSCURPOS)
^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
#define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
IGNORE_IOCTL(FBIOSCURPOS)
^~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of
'sizeof' to incomplete type 'struct fbcurpos'
#define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
^
fs/compat_ioctl.c:640:28: note: in definition of macro 'XFORM'
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
#define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
IGNORE_IOCTL(FBIOSCURPOS)
^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
#define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
IGNORE_IOCTL(FBIOSCURPOS)
^~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of
'sizeof' to incomplete type 'struct fbcurpos'
#define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
^
fs/compat_ioctl.c:640:42: note: in definition of macro 'XFORM'
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
#define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
IGNORE_IOCTL(FBIOSCURPOS)
^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
#define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
IGNORE_IOCTL(FBIOSCURPOS)
^~~
arch/sparc/include/uapi/asm/fbio.h:114:39: error: invalid application of
'sizeof' to incomplete type 'struct fbcurpos'
#define FBIOGCURPOS _IOW('F', 27, struct fbcurpos)
^
fs/compat_ioctl.c:640:21: note: in definition of macro 'XFORM'
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_
Re: [PATCH V3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP
I see there is no need of taking the spinlock as timeout will be handled after the calculated time as per data size and speed. There is 99.9% less chances of interrupt during the timeout handler. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1201081 The thing is, we want it to be 100% reliable, not 99.9% reliable. Is it somehow wrong to add the spinlock? ...or are you noticing performance problems with the spinlock there? It's just nice not to have to think about it. As I said, timeout will be handled after the calculated time as per data size and speed. Enough time is given for interrupt, there is no chance of interrupt occurrence during the handle_fifo_timeout(). So there is no need of spinlock.
[PATCH v2] spi: mediatek: Don't modify spi_transfer when transfer.
Mediatek SPI driver modifies some fields (tx_buf, rx_buf, len, tx_dma,
rx_dma) of the spi_transfer* passed in when doing transfer_one and in
interrupt handler. This is somewhat unexpected, and there are some
caller (e.g. Cr50 spi driver) that reuse the spi_transfer for multiple
messages. Add a field to record how many bytes have been transferred,
and calculate the right len / buffer based on it instead.
Signed-off-by: Pi-Hsun Shih
Change-Id: I23e218cd964f16c0b2b26127d4a5ca6529867673
---
drivers/spi/spi-mt65xx.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 86bf45667a040..3dc31627c6558 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -98,6 +98,7 @@ struct mtk_spi {
struct clk *parent_clk, *sel_clk, *spi_clk;
struct spi_transfer *cur_transfer;
u32 xfer_len;
+ u32 num_xfered;
struct scatterlist *tx_sgl, *rx_sgl;
u32 tx_sgl_len, rx_sgl_len;
const struct mtk_spi_compatible *dev_comp;
@@ -385,6 +386,7 @@ static int mtk_spi_fifo_transfer(struct spi_master *master,
mdata->cur_transfer = xfer;
mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, xfer->len);
+ mdata->num_xfered = 0;
mtk_spi_prepare_transfer(master, xfer);
mtk_spi_setup_packet(master);
@@ -415,6 +417,7 @@ static int mtk_spi_dma_transfer(struct spi_master *master,
mdata->tx_sgl_len = 0;
mdata->rx_sgl_len = 0;
mdata->cur_transfer = xfer;
+ mdata->num_xfered = 0;
mtk_spi_prepare_transfer(master, xfer);
@@ -482,7 +485,7 @@ static int mtk_spi_setup(struct spi_device *spi)
static irqreturn_t mtk_spi_interrupt(int irq, void *dev_id)
{
- u32 cmd, reg_val, cnt, remainder;
+ u32 cmd, reg_val, cnt, remainder, len;
struct spi_master *master = dev_id;
struct mtk_spi *mdata = spi_master_get_devdata(master);
struct spi_transfer *trans = mdata->cur_transfer;
@@ -497,36 +500,38 @@ static irqreturn_t mtk_spi_interrupt(int irq, void
*dev_id)
if (trans->rx_buf) {
cnt = mdata->xfer_len / 4;
ioread32_rep(mdata->base + SPI_RX_DATA_REG,
-trans->rx_buf, cnt);
+trans->rx_buf + mdata->num_xfered, cnt);
remainder = mdata->xfer_len % 4;
if (remainder > 0) {
reg_val = readl(mdata->base + SPI_RX_DATA_REG);
- memcpy(trans->rx_buf + (cnt * 4),
- ®_val, remainder);
+ memcpy(trans->rx_buf +
+ mdata->num_xfered +
+ (cnt * 4),
+ ®_val,
+ remainder);
}
}
- trans->len -= mdata->xfer_len;
- if (!trans->len) {
+ mdata->num_xfered += mdata->xfer_len;
+ if (mdata->num_xfered == trans->len) {
spi_finalize_current_transfer(master);
return IRQ_HANDLED;
}
- if (trans->tx_buf)
- trans->tx_buf += mdata->xfer_len;
- if (trans->rx_buf)
- trans->rx_buf += mdata->xfer_len;
-
- mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, trans->len);
+ len = trans->len - mdata->num_xfered;
+ mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, len);
mtk_spi_setup_packet(master);
- cnt = trans->len / 4;
- iowrite32_rep(mdata->base + SPI_TX_DATA_REG, trans->tx_buf,
cnt);
+ cnt = len / 4;
+ iowrite32_rep(mdata->base + SPI_TX_DATA_REG,
+ trans->tx_buf + mdata->num_xfered, cnt);
- remainder = trans->len % 4;
+ remainder = len % 4;
if (remainder > 0) {
reg_val = 0;
- memcpy(®_val, trans->tx_buf + (cnt * 4), remainder);
+ memcpy(®_val,
+ trans->tx_buf + (cnt * 4) + mdata->num_xfered,
+ remainder);
writel(reg_val, mdata->base + SPI_TX_DATA_REG);
}
--
2.19.0.rc2.392.g5ba43deb5a-goog
[PATCH] spi: mediatek: Don't modify spi_transfer when transfer.
Mediatek SPI driver modifies some fields (tx_buf, rx_buf, len, tx_dma,
rx_dma) of the spi_transfer* passed in when doing transfer_one and in
interrupt handler. This is somewhat unexpected, and there are some
caller (e.g. Cr50 spi driver) that reuse the spi_transfer for multiple
messages. Add a field to record how many bytes have been transferred,
and calculate the right len / buffer based on it instead.
BUG=b:113973051
TEST=None
Signed-off-by: Pi-Hsun Shih
Change-Id: I23e218cd964f16c0b2b26127d4a5ca6529867673
---
drivers/spi/spi-mt65xx.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 86bf45667a040..3dc31627c6558 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -98,6 +98,7 @@ struct mtk_spi {
struct clk *parent_clk, *sel_clk, *spi_clk;
struct spi_transfer *cur_transfer;
u32 xfer_len;
+ u32 num_xfered;
struct scatterlist *tx_sgl, *rx_sgl;
u32 tx_sgl_len, rx_sgl_len;
const struct mtk_spi_compatible *dev_comp;
@@ -385,6 +386,7 @@ static int mtk_spi_fifo_transfer(struct spi_master *master,
mdata->cur_transfer = xfer;
mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, xfer->len);
+ mdata->num_xfered = 0;
mtk_spi_prepare_transfer(master, xfer);
mtk_spi_setup_packet(master);
@@ -415,6 +417,7 @@ static int mtk_spi_dma_transfer(struct spi_master *master,
mdata->tx_sgl_len = 0;
mdata->rx_sgl_len = 0;
mdata->cur_transfer = xfer;
+ mdata->num_xfered = 0;
mtk_spi_prepare_transfer(master, xfer);
@@ -482,7 +485,7 @@ static int mtk_spi_setup(struct spi_device *spi)
static irqreturn_t mtk_spi_interrupt(int irq, void *dev_id)
{
- u32 cmd, reg_val, cnt, remainder;
+ u32 cmd, reg_val, cnt, remainder, len;
struct spi_master *master = dev_id;
struct mtk_spi *mdata = spi_master_get_devdata(master);
struct spi_transfer *trans = mdata->cur_transfer;
@@ -497,36 +500,38 @@ static irqreturn_t mtk_spi_interrupt(int irq, void
*dev_id)
if (trans->rx_buf) {
cnt = mdata->xfer_len / 4;
ioread32_rep(mdata->base + SPI_RX_DATA_REG,
-trans->rx_buf, cnt);
+trans->rx_buf + mdata->num_xfered, cnt);
remainder = mdata->xfer_len % 4;
if (remainder > 0) {
reg_val = readl(mdata->base + SPI_RX_DATA_REG);
- memcpy(trans->rx_buf + (cnt * 4),
- ®_val, remainder);
+ memcpy(trans->rx_buf +
+ mdata->num_xfered +
+ (cnt * 4),
+ ®_val,
+ remainder);
}
}
- trans->len -= mdata->xfer_len;
- if (!trans->len) {
+ mdata->num_xfered += mdata->xfer_len;
+ if (mdata->num_xfered == trans->len) {
spi_finalize_current_transfer(master);
return IRQ_HANDLED;
}
- if (trans->tx_buf)
- trans->tx_buf += mdata->xfer_len;
- if (trans->rx_buf)
- trans->rx_buf += mdata->xfer_len;
-
- mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, trans->len);
+ len = trans->len - mdata->num_xfered;
+ mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, len);
mtk_spi_setup_packet(master);
- cnt = trans->len / 4;
- iowrite32_rep(mdata->base + SPI_TX_DATA_REG, trans->tx_buf,
cnt);
+ cnt = len / 4;
+ iowrite32_rep(mdata->base + SPI_TX_DATA_REG,
+ trans->tx_buf + mdata->num_xfered, cnt);
- remainder = trans->len % 4;
+ remainder = len % 4;
if (remainder > 0) {
reg_val = 0;
- memcpy(®_val, trans->tx_buf + (cnt * 4), remainder);
+ memcpy(®_val,
+ trans->tx_buf + (cnt * 4) + mdata->num_xfered,
+ remainder);
writel(reg_val, mdata->base + SPI_TX_DATA_REG);
}
--
2.19.0.rc2.392.g5ba43deb5a-goog
linux-next: build failure after merge of the vfs tree
Hi Al,
After merging the vfs tree, today's linux-next build (powerpc
allyesconfig) failed like this:
samples/vfs/test-fsinfo.c: In function 'fsinfo':
samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in
this function); did you mean 'fsinfo'?
return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
^~~
fsinfo
samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported
only once for each function it appears in
samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
unsigned int'} [-Wformat=]
printf("\tmax file size: %llx\n", f->max_file_size);
~~~^
%lx
samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
unsigned int'} [-Wformat=]
printf("\tmax ids : u=%llx g=%llx p=%llx\n",
~~~^
%lx
f->max_uid, f->max_gid, f->max_projid);
~~
samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long
unsigned int'} [-Wformat=]
printf("\tmax ids : u=%llx g=%llx p=%llx\n",
~~~^
%lx
f->max_uid, f->max_gid, f->max_projid);
~~
samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long
unsigned int'} [-Wformat=]
printf("\tmax ids : u=%llx g=%llx p=%llx\n",
~~~^
%lx
f->max_uid, f->max_gid, f->max_projid);
~
samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
unsigned int'} [-Wformat=]
printf("\tstx_attr=%llx\n", f->stx_attributes);
~~~^ ~
%lx
samples/vfs/test-fsmount.c: In function 'fsopen':
samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use in
this function); did you mean 'fsopen'?
return syscall(__NR_fsopen, fs_name, flags);
^~~
fsopen
samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is reported
only once for each function it appears in
samples/vfs/test-fsmount.c: In function 'fsmount':
samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use
in this function); did you mean 'fsmount'?
return syscall(__NR_fsmount, fsfd, flags, ms_flags);
^~~~
fsmount
samples/vfs/test-fsmount.c: In function 'fsconfig':
samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first use
in this function); did you mean 'fsconfig'?
return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
^
fsconfig
samples/vfs/test-fsmount.c: In function 'move_mount':
samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first
use in this function); did you mean 'move_mount'?
return syscall(__NR_move_mount,
^~~
move_mount
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use
in this function); did you mean 'fsopen'?
return syscall(__NR_fsopen, fs_name, flags);
^~~
fsopen
samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is reported
only once for each function it appears in
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use
in this function); did you mean 'fsinfo'?
return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
^~~
fsinfo
samples/vfs/test-statx.c: In function 'dump_statx':
samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
unsigned int'} [-Wformat=]
printf("Attributes: %016llx (", stx->stx_attributes);
~~^ ~~~
%016lx
Caused by commits
2615362dc9ce ("vfs: Add a sample program for the new mount API")
e9078278ec11 ("vfs: syscall: Add fsinfo() to query filesystem information")
The directory name has changed, but the errors persist!
I have applied this pat
Re: [PATCH v2] ARM: dts: imx6ul: Add DTS for ConnectCore 6UL SBC Pro
On Tue, Sep 04, 2018 at 05:28:29PM +0200, Alex Gonzalez wrote:
> The ConnectCore 6UL Single Board Computer (SBC) Pro contains the
> ConnectCore 6UL System-On-Module.
>
> Its hardware specifications are:
>
> * 256MB DDR3 memory
> * On module 256MB NAND flash
> * Dual 10/100 Ethernet
> * USB Host and USB OTG
> * Parallel RGB display header
> * LVDS display header
> * CSI camera
> * GPIO header
> * I2C, SPI, CAN headers
> * PCIe mini card and micro SIM slot
> * MicroSD external storage
> * On board 4GB eMMC flash
> * Audio headphone, line in/out, microphone lines
>
> Signed-off-by: Alex Gonzalez
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts | 394
>
> 2 files changed, 395 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 6135d3dc381c..3f6f8983f6c6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -534,6 +534,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
> dtb-$(CONFIG_SOC_IMX6UL) += \
> imx6ul-14x14-evk.dtb \
> imx6ul-ccimx6ulsbcexpress.dtb \
> + imx6ul-ccimx6ulsbcpro.dtb \
> imx6ul-geam.dtb \
> imx6ul-isiot-emmc.dtb \
> imx6ul-isiot-nand.dtb \
> diff --git a/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> new file mode 100644
> index ..08d550baa684
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> @@ -0,0 +1,394 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Digi International's ConnectCore6UL SBC Pro board device tree source
> + *
> + * Copyright 2018 Digi International, Inc.
> + *
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include "imx6ul.dtsi"
> +#include "imx6ul-ccimx6ulsom.dtsi"
> +
> +/ {
> + model = "Digi International ConnectCore 6UL SBC Pro.";
> + compatible = "digi,ccimx6ulsbcpro", "digi,ccimx6ulsom", "fsl,imx6ul";
> +
> + lcd_backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm5 0 5>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + status = "okay";
> + };
> +
> + reg_usb_otg1_vbus: reg-usb-otg1 {
Please spell out 'regulator' in node name:
reg_usb_otg1_vbus: regulator-usb-otg1 {
...
};
Shawn
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg1_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +};
Re: [PATCH v2 1/2] ARM: dts: imx6: RDU2: Use new CODEC reset pin name
On Tue, Sep 04, 2018 at 09:20:17AM -0500, Andrew F. Davis wrote:
> The correct DT property for specifying a GPIO used for reset
> is "reset-gpios", the driver now accepts this name use this here.
>
> Signed-off-by: Andrew F. Davis
> ---
>
> Changes from v1:
> - Remove "fix" from commit message
>
> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> index 7fff3717cf7c..a0f5cfda0055 100644
> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> @@ -384,7 +384,7 @@
> AVDD-supply = <®_3p3v>;
> IOVDD-supply = <®_3p3v>;
> DVDD-supply = <&vgen4_reg>;
> - gpio-reset = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
Is it intended to change the polarity?
Shawn
> };
>
> accel@1c {
> @@ -572,7 +572,7 @@
> AVDD-supply = <®_3p3v>;
> IOVDD-supply = <®_3p3v>;
> DVDD-supply = <&vgen4_reg>;
> - gpio-reset = <&gpio1 0 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> };
>
> touchscreen@20 {
> --
> 2.18.0
>
Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage
Hi Pingfan,
On 09/06/18 at 10:36am, Pingfan Liu wrote:
> commit 747ff6265db4 ("x86/boot/KASLR: Skip specified number of 1GB huge
> pages when doing physical randomization (KASLR)") and commit
> 9b912485e0e7 ("x86/boot/KASLR: Add two new functions for 1GB huge pages
> handling") prevent the physical load addr of kernel from spoiling a good
> candidate of GiB page. But the algorithm deterministicly chooses the most
> front GiB page for hugetlb, and sacrifices the randomness, which
> is the heart of the KASLR. This patch tries to enlarge the randomness in
> the cases where hugepages=X < the num Y of good candidate of GiB
> page.
Better tell how you improve in cover letter or patch log.
> To comparison, taking a typical KVM guest for example, the head 3GiB mem
> can not be used as GiB hugetlb. Denoting the total mem size as Z(GiB), when
> Z=5, then Y=2, assuming X=1, the randomness range before this patch is
> 4GiB, after this patch is 5GiB, and get a 25% improvement of randomness.
> If Z=6, then Y=3, assuming X=2, the improvement equals: 50%( 6/(6-2) - 1);
> assuming X=1, the improvement will be: 20% (6/(6-1) - 1)
Hmm, what if hugepages=1, or 2, even 100, but system owns 1PB memory?
Secondly, even in the case that hugepages=1, system memory is 5G, if no
'movable_node' specified, the last 1G can't be chosen for hugepage.
Because memblock will allocate memory top to down. This is not
improving, but make the code not work.
Lastly, getting better randomness is the heart of KASLR, while
process_mem_region() is the heart of kernel KASLR code. Unless the
current code blocks serious fix, we'd better not touch it. Keeping
it can make the current code logic simple and more readable. It's
like a proved running well machine, we just dig out the unwanted
middle, feed the good head and tail regions into it, then it gives
back good slot for kernel position one by one.
To sum up, I personally think this patchset is not a good idea.
Thanks
Baoquan
Re: [PATCH v2 4/5] dt-bindings: Add vendor prefix for Microsys
+Rob @Rob, Are you okay with this? The patch should really be sent to you from the beginning. Shawn On Mon, Sep 03, 2018 at 04:08:39PM +0200, Alexandre Belloni wrote: > Add vendor prefix for MicroSys Electronics GmbH > > Signed-off-by: Alexandre Belloni > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 2c3fc512e746..10155a44b783 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -235,6 +235,7 @@ micrelMicrel Inc. > microchipMicrochip Technology Inc. > microcrystal Micro Crystal AG > micron Micron Technology Inc. > +microsys MicroSys Electronics GmbH > minixMINIX Technology Ltd. > miramems MiraMEMS Sensing Technology Co., Ltd. > mitsubishi Mitsubishi Electric Corporation > -- > 2.19.0.rc1 >
Re: [PATCH v2 1/5] arm64: dts: fsl: use a generic node name for m25p80 flashes
The series looks good to me. @Leo, what about you?
Shawn
On Mon, Sep 03, 2018 at 04:08:36PM +0200, Alexandre Belloni wrote:
> Use a generic node name for the m25p80 flashes on ls1043 and ls1046 boards.
>
> Signed-off-by: Alexandre Belloni
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 2 +-
> arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 2 +-
> arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> index c7b8d2c009cd..af972e91d6bc 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> @@ -136,7 +136,7 @@
> bus-num = <0>;
> status = "okay";
>
> - qflash0: s25fl128s@0 {
> + qflash0: flash@0 {
> compatible = "spansion,m25p80";
> #address-cells = <1>;
> #size-cells = <1>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> index e69306e6b0b1..219068220b84 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
> @@ -165,7 +165,7 @@
> bus-num = <0>;
> status = "okay";
>
> - qflash0: s25fl128s@0 {
> + qflash0: flash@0 {
> compatible = "spansion,m25p80";
> #address-cells = <1>;
> #size-cells = <1>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> index 440e111651d5..df676b30357b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> @@ -103,7 +103,7 @@
> bus-num = <0>;
> status = "okay";
>
> - qflash0: s25fs512s@0 {
> + qflash0: flash@0 {
> compatible = "spansion,m25p80";
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -111,7 +111,7 @@
> reg = <0>;
> };
>
> - qflash1: s25fs512s@1 {
> + qflash1: flash@1 {
> compatible = "spansion,m25p80";
> #address-cells = <1>;
> #size-cells = <1>;
> --
> 2.19.0.rc1
>
[PATCH] sh: mm: Use dma_zalloc_coherent instead of dma_alloc_coherent + memset
dma_zalloc_coherent has taken the dma_alloc_coherent() and memset() into
account. Therefore, just use dma_zalloc_coherent to replace the open code.
Signed-off-by: zhong jiang
---
arch/sh/mm/consistent.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index 792f361..aa4e450 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -52,14 +52,12 @@ int __init platform_resource_setup_memory(struct
platform_device *pdev,
if (!memsize)
return 0;
- buf = dma_alloc_coherent(&pdev->dev, memsize, &dma_handle, GFP_KERNEL);
+ buf = dma_zalloc_coherent(&pdev->dev, memsize, &dma_handle, GFP_KERNEL);
if (!buf) {
pr_warning("%s: unable to allocate memory\n", name);
return -ENOMEM;
}
- memset(buf, 0, memsize);
-
r->flags = IORESOURCE_MEM;
r->start = dma_handle;
r->end = r->start + memsize - 1;
--
1.7.12.4
sysfs: Do not return POSIX ACL xattrs via listxattr()
Greetings.
Commit 786534b92f3ce68f4afc8a761c80b76887797b0a "tmpfs: listxattr
should include POSIX ACL xattrs", which first appeared in 4.5 kernels,
introduced a regression whereby listxattr() syscalls on anything in
sysfs, or its mountpoint, return the name of the two POSIX ACL xattrs,
but attempts to retrieve these values are denied with EOPNOTSUP. For
example ...
# getfattr -d --match=- /sys
/sys: system.posix_acl_access: Operation not supported
/sys: system.posix_acl_default: Operation not supported
#
This inconsistent behaviour confuses rsync(1) (among others) when it
runs into a sysfs mountpoint, even when told to not descend into it.
This issue occurs because simple_xattr_list() does not correctly deal
with cached ACLs.
The suggested fix below was developed with a 4.18.7 kernel, but should
apply, modulo patch fuzz, to any kernel >= 4.7. A fix for 4.5 <=
kernels < 4.7 is trivially different, but I won't bother given such
kernels are no longer maintained.
Note that the only other simple_xattr_list() caller, shmem, avoids
this glitch by previously calling cache_no_acl() on all inodes it
creates, so perhaps sysfs/kernfs should do the same.
Please Reply-To-All.
Thanks and have a great day.
Marc.
Signed-off-by: Marc Aurèle La France
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -949,13 +949,13 @@ ssize_t simple_xattr_list(struct inode *inode, struct
simple_xattrs *xattrs,
int err = 0;
#ifdef CONFIG_FS_POSIX_ACL
- if (inode->i_acl) {
+ if (inode->i_acl && !is_uncached_acl(inode->i_acl)) {
err = xattr_list_one(&buffer, &remaining_size,
XATTR_NAME_POSIX_ACL_ACCESS);
if (err)
return err;
}
- if (inode->i_default_acl) {
+ if (inode->i_default_acl && !is_uncached_acl(inode->i_default_acl)) {
err = xattr_list_one(&buffer, &remaining_size,
XATTR_NAME_POSIX_ACL_DEFAULT);
if (err)
[PATCH TRIVIAL] MAINTAINERS: small punctuation fix
Signed-off-by: Diego Viola --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d870cb57c..6567bf245 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -93,7 +93,7 @@ Descriptions of section entries: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. Odd Fixes: It has a maintainer but they don't have time to do - much other than throw the odd patch in. See below.. + much other than throw the odd patch in. See below. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete:Old code. Something tagged obsolete generally means -- 2.18.0
Re: [RFC 60/60] cosched: Add command line argument to enable coscheduling
On 9/7/18 2:40 PM, Jan H. Schönherr wrote:
> Add a new command line argument cosched_max_level=, which allows
> enabling coscheduling at boot. The number corresponds to the scheduling
> domain up to which coscheduling can later be enabled for cgroups.
>
> For example, to enable coscheduling of cgroups at SMT level, one would
> specify cosched_max_level=1.
>
> The use of symbolic names (like off, core, socket, system) is currently
> not possible, but could be added. However, to force coscheduling at up
> to system level not knowing the scheduling domain topology in advance,
> it is possible to just specify a too large number. It will be clamped
> transparently to system level.
>
> Signed-off-by: Jan H. Schönherr
> ---
> kernel/sched/cosched.c | 32 +++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/cosched.c b/kernel/sched/cosched.c
> index eb6a6a61521e..a1f0d3a7b02a 100644
> --- a/kernel/sched/cosched.c
> +++ b/kernel/sched/cosched.c
> @@ -162,6 +162,29 @@ static int __init cosched_split_domains_setup(char *str)
>
> early_param("cosched_split_domains", cosched_split_domains_setup);
>
> +
> +early_param("cosched_max_level", cosched_max_level_setup);
> +
Hi,
Please document both of these kernel parameters in
Documentation/admin-guide/kernel-parameters.txt.
thanks,
--
~Randy
Re: [PATCH 2/5] gpio: davinci: Use dev name for label and automatic base selection
On Sunday 09 September 2018 01:11 AM, Grygorii Strashko wrote: > > > On 09/06/2018 09:16 AM, Keerthy wrote: >> >> >> On Wednesday 05 September 2018 04:07 PM, Linus Walleij wrote: >>> On Mon, Sep 3, 2018 at 7:40 AM Keerthy wrote: On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote: > Use dev_name to get a unique label and use -1 for a base to get our > selection automatically. We pull in all GPIOs per chip now so this > does not have the effect of out of order labels like before. > > We do these both together so we can drop all the static data in one > patch. This also lets us normalize the return paths as we don't need > any cleanup after this change. echo 28 > /sys/class/gpio/export / # echo 28 > /sys/class/gpi[ 12.839205] export_store: invalid GPIO 28 o/export echo 2 > /sys/class/gp[ 22.165728] export_store: invalid GPIO 2 io/export / # echo 1 > /sys/class/gp[ 25.961392] export_store: invalid GPIO 1 io/export / # echo 3 > /sys/class/gp[ 29.981918] export_store: invalid GPIO 3 io/export Export fails with this patch. I am testing this on keystone-k2g-evm. >>> >>> I think the GPIO got a new number didn't it? >>> >>> Did you check the gpio file in debugfs to see which number >>> it got. >> >> Okay now its numbered differently: >> >> cat /sys/class/gpio/gpiochip340/ngpio >> 144 >> >> cat /sys/class/gpio/gpiochip272/ngpio >> 68 > > could you or Andrew provide content of /debug/gpio before/after? > And ls /sys/class/gpio/? Output on K2G: Before == cat /debug/gpio gpiochip1: GPIOs 0-143, parent: platform/2603000.gpio, davinci_gpio.0: gpiochip2: GPIOs 144-211, parent: platform/260a000.gpio, davinci_gpio.1: gpio-156 (|cd ) in lo gpiochip0: GPIOs 484-511, parent: platform/2620240.keystone_dsp_gpio, 2620240.keystone_dsp_gpio: ls /sys/class/gpio/ export gpiochip0gpiochip144 gpiochip484 unexport cat /sys/class/gpio/gpiochip0/label davinci_gpio.0 cat /sys/class/gpio/gpiochip144/label davinci_gpio.1 cat /sys/class/gpio/gpiochip144/ngpio 68 / # cat /sys/class/gpio/gpiochip0/ngpio 144 After = cat /debug/gpio gpiochip2: GPIOs 272-339, parent: platform/260a000.gpio, 260a000.gpio: gpio-284 (|cd ) in lo gpiochip1: GPIOs 340-483, parent: platform/2603000.gpio, 2603000.gpio: gpiochip0: GPIOs 484-511, parent: platform/2620240.keystone_dsp_gpio, 2620240.keystone_dsp_gpio: ls /sys/class/gpio/ export gpiochip272 gpiochip340 gpiochip484 unexport cat /sys/class/gpio/gpiochip340/label 2603000.gpio / # cat /sys/class/gpio/gpiochip272/label 260a000.gpio / # cat /sys/class/gpio/gpiochip272/label cat /sys/class/gpio/gpiochip272/ngpio 68 / # cat /sys/class/gpio/gpiochip340/ngpio 144 In the case of SoCs that support multiple instances of Davinci GPIO IPs it is harder to figure out the right gpio number to export. >> >> So gpio bank2 and bank1 have different gpio numbers. Is that acceptable? >> >>> >>> This is sadly the global numberspace that we are tying to >>> get rid of (new apps/scripts should use the chardev). >>> >>> Are there applications that rely on the sysfs ABI on DaVinci? >>> >>> In that case base needs to be prerseved. > > Not only base, but label also - /sys/class/gpio/gpiochip0/label, as this is > the way to find proper GPIO chip in sysfs using legacy GPIO ABI. > > Linus, this platform is old and most of the users do not use new ABI > (chardev), > so we could try change this, but need to be prepared for regressions reports. > Totally agree with this.
Re: [PATCH] bcache: remove redundant condition before debugfs_remove
LGTM Reviewed-by: tang.junhui.li...@gmail.com zhong jiang 于2018年9月8日周六 下午9:08写道： > > debugfs_remove has taken the IS_ERR_OR_NULL into account. Just > remove the unnecessary condition. > > Signed-off-by: zhong jiang > --- > drivers/md/bcache/super.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c > index 2d26f9e..a3d2a94 100644 > --- a/drivers/md/bcache/super.c > +++ b/drivers/md/bcache/super.c > @@ -1506,8 +1506,7 @@ static void cache_set_free(struct closure *cl) > struct cache *ca; > unsigned int i; > > - if (!IS_ERR_OR_NULL(c->debug)) > - debugfs_remove(c->debug); > + debugfs_remove(c->debug); > > bch_open_buckets_free(c); > bch_btree_cache_free(c); > -- > 1.7.12.4 >
Re: [PATCH resend] uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name
On Tue, Aug 28, 2018 at 04:34:04PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Since this header is in "include/uapi/linux/", apparently people
> want to use it in userspace programs -- even in C++ ones.
> However, the header uses a C++ reserved keyword ("private"),
> so change that to "dh_private" instead to allow the header file
> to be used in C++ userspace.
This change breaks all existing C programs that rely on
uapi header in order to get struct keyctl_dh_params definition, however.
>
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051
> Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
>
> Signed-off-by: Randy Dunlap
> Cc: David Howells
> Cc: James Morris
> Cc: "Serge E. Hallyn"
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: Mat Martineau
> Cc: sta...@vger.kernel.org
> ---
> include/uapi/linux/keyctl.h |2 +-
> security/keys/dh.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- lnx-416.orig/include/uapi/linux/keyctl.h
> +++ lnx-416/include/uapi/linux/keyctl.h
> @@ -65,7 +65,7 @@
>
> /* keyctl structures */
> struct keyctl_dh_params {
> - __s32 private;
> + __s32 dh_private;
> __s32 prime;
> __s32 base;
> };
> --- lnx-416.orig/security/keys/dh.c
> +++ lnx-416/security/keys/dh.c
> @@ -307,7 +307,7 @@ long __keyctl_dh_compute(struct keyctl_d
> }
> dh_inputs.g_size = dlen;
>
> - dlen = dh_data_from_key(pcopy.private, &dh_inputs.key);
> + dlen = dh_data_from_key(pcopy.dh_private, &dh_inputs.key);
> if (dlen < 0) {
> ret = dlen;
> goto out2;
>
>
Memory leak in dell-smbios-wmi.c
There might be a possible memory leak in drivers/platform/x86/dell-smbios-wmi.c
In the `run_smbios_call' function, the buffer created via ACPI_ALLOCATE_BUFFER
within the output object is not freed properly.
Generally, this buffer should be freed using:
kfree(output.pointer);
But it hasn't been cleaned up after a `memcpy' being done.
static int run_smbios_call(struct wmi_device *wdev)
{
struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
struct wmi_smbios_priv *priv;
struct acpi_buffer input;
union acpi_object *obj;
acpi_status status;
priv = dev_get_drvdata(&wdev->dev);
input.length = priv->req_buf_size - sizeof(u64);
input.pointer = &priv->buf->std;
dev_dbg(&wdev->dev, "evaluating: %u/%u [%x,%x,%x,%x]\n",
priv->buf->std.cmd_class, priv->buf->std.cmd_select,
priv->buf->std.input[0], priv->buf->std.input[1],
priv->buf->std.input[2], priv->buf->std.input[3]);
status = wmidev_evaluate_method(wdev, 0, 1, &input, &output);
if (ACPI_FAILURE(status))
return -EIO;
obj = (union acpi_object *)output.pointer;
if (obj->type != ACPI_TYPE_BUFFER) {
dev_dbg(&wdev->dev, "received type: %d\n", obj->type);
if (obj->type == ACPI_TYPE_INTEGER)
dev_dbg(&wdev->dev, "SMBIOS call failed: %llu\n",
obj->integer.value);
return -EIO;
}
memcpy(&priv->buf->std, obj->buffer.pointer, obj->buffer.length);
dev_dbg(&wdev->dev, "result: [%08x,%08x,%08x,%08x]\n",
priv->buf->std.output[0], priv->buf->std.output[1],
priv->buf->std.output[2], priv->buf->std.output[3]);
return 0;
}
Found with kmemleak:
unreferenced object 0x8f79382e (size 8192):
comm "fwupd", pid 3467, jiffies 4294967131 (age 265623.160s)
hex dump (first 32 bytes):
03 00 00 00 00 10 00 00 18 00 2e 38 79 8f ff ff ...8y...
00 00 00 00 00 00 00 00 11 00 16 00 00 00 00 00
backtrace:
[<00d8a77d>] __kmalloc+0x14e/0x240
[] acpi_os_allocate+0x27/0x29
[<3fd4a388>] acpi_ut_initialize_buffer+0x3f/0x73
[<27ecea33>] acpi_evaluate_object+0x22b/0x3aa
[] wmidev_evaluate_method+0x114/0x150 [wmi]
[] run_smbios_call+0x6d/0x190 [dell_smbios]
[] dell_smbios_wmi_filter+0x71/0xd0 [dell_smbios]
[] wmi_ioctl+0x100/0x232 [wmi]
[] do_vfs_ioctl+0xa8/0x620
[<35f23e13>] ksys_ioctl+0x67/0x90
[] __x64_sys_ioctl+0x1a/0x20
[<477604b1>] do_syscall_64+0x5a/0x110
[] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[] 0x
[PATCH v2 3/3] ARM: OMAP1: ams-delta: register MODEM device earlier
Amstrad Delta MODEM device used to be initialized at arch_initcall
before it was once moved to late_initcall by commit f7519d8c8290 ("ARM:
OMAP1: ams-delta: register latch dependent devices later"). The purpose
of that change was to postpone initialization of devices which depended
on latch2 pins until latch2 converted to GPIO device was ready.
After recent fixes to GPIO handling, it was possible to moove
registration of most of those device back to where they were before.
The same can be safely done with the MODEM device as initialization
of GPIO pins it depends on was moved to machine_init by preceding
patch.
Move registration of the MODEM device to arch_initcall_sync, not to
arch_initcall, so it is never exposed to potential conflict in
registration order hazard against OMAP serial ports.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Linus Walleij
---
arch/arm/mach-omap1/board-ams-delta.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 1d451142248c..667c3c1f05f5 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -896,11 +896,28 @@ static int __init modem_nreset_init(void)
/*
* This function expects MODEM IRQ number already assigned to the port
* and fails if it's not.
+ * The MODEM device requires its RESET# pin kept high during probe.
+ * That requirement can be fulfilled in several ways:
+ * - with a descriptor of already functional modem_nreset regulator
+ * assigned to the MODEM private data,
+ * - with the regulator not yet controlled by modem_pm function but
+ * already enabled by default on probe,
+ * - before the modem_nreset regulator is probed, with the pin already
+ * set high explicitly.
+ * The last one is already guaranteed by ams_delta_latch2_init() called
+ * from machine_init.
+ * In order to avoid taking over ttyS0 device slot, the MODEM device
+ * should be registered after OMAP serial ports. Since those ports
+ * are registered at arch_initcall, this function can be called safely
+ * at arch_initcall_sync earliest.
*/
static int __init ams_delta_modem_init(void)
{
int err;
+ if (!machine_is_ams_delta())
+ return -ENODEV;
+
if (ams_delta_modem_ports[0].irq < 0)
return ams_delta_modem_ports[0].irq;
@@ -913,6 +930,7 @@ static int __init ams_delta_modem_init(void)
return err;
}
+arch_initcall_sync(ams_delta_modem_init);
static int __init late_init(void)
{
@@ -922,10 +940,6 @@ static int __init late_init(void)
if (err)
return err;
- err = ams_delta_modem_init();
- if (err)
- return err;
-
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
--
2.16.4
[PATCH v2 1/3] ARM: OMAP1: ams-delta: assign MODEM IRQ from GPIO descriptor
Don't request MODEM IRQ GPIO by its global number in
ams_delta_modem_init(). Instead, obtain its GPIO descriptor
and assign related IRQ to the MODEM. Do that from
omap_gpio_deps_init(), where the chip is already looked up. Then, in
ams_delta_modem_init(), just check for the IRQ number having been
already assigned.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Linus Walleij
---
arch/arm/mach-omap1/board-ams-delta.c | 47 ++-
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 34cb63ff45b3..2b90b543c030 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -630,6 +630,28 @@ static struct gpiod_hog ams_delta_gpio_hogs[] = {
{},
};
+static struct plat_serial8250_port ams_delta_modem_ports[];
+
+/*
+ * Obtain MODEM IRQ GPIO descriptor using its hardware pin
+ * number and assign related IRQ number to the MODEM port.
+ * Keep the GPIO descriptor open so nobody steps in.
+ */
+static void __init modem_assign_irq(struct gpio_chip *chip)
+{
+ struct gpio_desc *gpiod;
+
+ gpiod = gpiochip_request_own_desc(chip, AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ "modem_irq");
+ if (IS_ERR(gpiod)) {
+ pr_err("%s: modem IRQ GPIO request failed (%ld)\n", __func__,
+ PTR_ERR(gpiod));
+ } else {
+ gpiod_direction_input(gpiod);
+ ams_delta_modem_ports[0].irq = gpiod_to_irq(gpiod);
+ }
+}
+
/*
* The purpose of this function is to take care of proper initialization of
* devices and data structures which depend on GPIO lines provided by OMAP GPIO
@@ -649,7 +671,13 @@ static void __init omap_gpio_deps_init(void)
return;
}
+ /*
+* Start with FIQ initialization as it may have to request
+* and release successfully each OMAP GPIO pin in turn.
+*/
ams_delta_init_fiq(chip, &ams_delta_serio_device);
+
+ modem_assign_irq(chip);
}
static void __init ams_delta_init(void)
@@ -844,20 +872,18 @@ static int __init modem_nreset_init(void)
}
+/*
+ * This function expects MODEM IRQ number already assigned to the port
+ * and fails if it's not.
+ */
static int __init ams_delta_modem_init(void)
{
int err;
- omap_cfg_reg(M14_1510_GPIO2);
- ams_delta_modem_ports[0].irq =
- gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+ if (ams_delta_modem_ports[0].irq < 0)
+ return ams_delta_modem_ports[0].irq;
- err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, "modem");
- if (err) {
- pr_err("Couldn't request gpio pin for modem\n");
- return err;
- }
- gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+ omap_cfg_reg(M14_1510_GPIO2);
/* Initialize the modem_nreset regulator consumer before use */
modem_priv.regulator = ERR_PTR(-ENODEV);
@@ -866,8 +892,6 @@ static int __init ams_delta_modem_init(void)
AMS_DELTA_LATCH2_MODEM_CODEC);
err = platform_device_register(&ams_delta_modem_device);
- if (err)
- gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
return err;
}
@@ -898,7 +922,6 @@ static int __init late_init(void)
unregister:
platform_device_unregister(&ams_delta_modem_device);
- gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
return err;
}
--
2.16.4
Re: [PATCH 1/7] ARM: imx: add mmdc ipg clock operation for mmdc
On Fri, Aug 31, 2018 at 03:53:12PM +0800, Anson Huang wrote: > i.MX6 SoCs have MMDC ipg clock for registers access, to make > sure MMDC registers access successfully, add optional clock > enable for MMDC driver. > > Signed-off-by: Anson Huang Applied this one, thanks.
[PATCH v2 0/3] ARM: OMAP1: ams-delta: Clean up GPIO setup for MODEM
Convert modem related GPIO setup from integer space to GPIO descriptors. Also, restore original initialization order of the MODEM device and its related GPIO pins. Cleanup of MODEM relaated regulator setup is postponed while waiting for upcoming conversion of fixed regulator API to GPIO descriptors. Janusz Krzysztofik (3): ARM: OMAP1: ams-delta: assign MODEM IRQ from GPIO descriptor ARM: OMAP1: ams-delta: initialize latch2 pins to safe values ARM: OMAP1: ams-delta: register MODEM device earlier Changelog: v2: - rebased on v4.19-rc1 - added Reviewed-by: obtained from Linus Walleij Please ignore the patch "ARM: OMAP1: ams-delta: assign MODEM IRQ from GPIO" sent alone on 2018-07-17. Thanks, Janusz diffstat: board-ams-delta.c | 121 +++--- board-ams-delta.h |7 --- 2 files changed, 88 insertions(+), 40 deletions(-)
Re: [patch 01/10] x86/mm/cpa: Split, rename and clean up try_preserve_large_page()
On Fri, 2018-09-07 at 17:01 +0200, Thomas Gleixner wrote:
> Avoid the extra variable and gotos by splitting the function into the
> actual algorithm and a callable function which contains the lock
> protection.
>
> Rename it to should_split_large_page() while at it so the return values make
> actually sense.
>
> Clean up the code flow, comments and general whitespace damage while at it. No
> functional change.
>
> Signed-off-by: Thomas Gleixner
> ---
> arch/x86/mm/pageattr.c | 121
> -
> 1 file changed, 60 insertions(+), 61 deletions(-)
>
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -421,18 +421,18 @@ pte_t *lookup_address_in_pgd(pgd_t *pgd,
> */
> pte_t *lookup_address(unsigned long address, unsigned int *level)
> {
> -return lookup_address_in_pgd(pgd_offset_k(address), address, level);
> + return lookup_address_in_pgd(pgd_offset_k(address), address, level);
> }
> EXPORT_SYMBOL_GPL(lookup_address);
>
> static pte_t *_lookup_address_cpa(struct cpa_data *cpa, unsigned long
> address,
> unsigned int *level)
> {
> -if (cpa->pgd)
> + if (cpa->pgd)
> return lookup_address_in_pgd(cpa->pgd + pgd_index(address),
> address, level);
>
> -return lookup_address(address, level);
> + return lookup_address(address, level);
> }
>
> /*
> @@ -549,27 +549,22 @@ static pgprot_t pgprot_clear_protnone_bi
> return prot;
> }
>
> -static int
> -try_preserve_large_page(pte_t *kpte, unsigned long address,
> - struct cpa_data *cpa)
> +static int __should_split_large_page(pte_t *kpte, unsigned long address,
> + struct cpa_data *cpa)
> {
> - unsigned long nextpage_addr, numpages, pmask, psize, addr, pfn, old_pfn;
> - pte_t new_pte, old_pte, *tmp;
> + unsigned long numpages, pmask, psize, lpaddr, addr, pfn, old_pfn;
> pgprot_t old_prot, new_prot, req_prot;
> - int i, do_split = 1;
> + pte_t new_pte, old_pte, *tmp;
> enum pg_level level;
> + int i;
>
> - if (cpa->force_split)
> - return 1;
> -
> - spin_lock(&pgd_lock);
> /*
>* Check for races, another CPU might have split this page
>* up already:
>*/
> tmp = _lookup_address_cpa(cpa, address, &level);
> if (tmp != kpte)
> - goto out_unlock;
> + return 1;
>
> switch (level) {
> case PG_LEVEL_2M:
> @@ -581,8 +576,7 @@ try_preserve_large_page(pte_t *kpte, uns
> old_pfn = pud_pfn(*(pud_t *)kpte);
> break;
> default:
> - do_split = -EINVAL;
> - goto out_unlock;
> + return -EINVAL;
> }
>
> psize = page_level_size(level);
> @@ -592,8 +586,8 @@ try_preserve_large_page(pte_t *kpte, uns
>* Calculate the number of pages, which fit into this large
>* page starting at address:
>*/
> - nextpage_addr = (address + psize) & pmask;
> - numpages = (nextpage_addr - address) >> PAGE_SHIFT;
> + lpaddr = (address + psize) & pmask;
> + numpages = (lpaddr - address) >> PAGE_SHIFT;
> if (numpages < cpa->numpages)
> cpa->numpages = numpages;
>
> @@ -620,57 +614,62 @@ try_preserve_large_page(pte_t *kpte, uns
> pgprot_val(req_prot) |= _PAGE_PSE;
>
> /*
> - * old_pfn points to the large page base pfn. So we need
> - * to add the offset of the virtual address:
> + * old_pfn points to the large page base pfn. So we need to add the
> + * offset of the virtual address:
>*/
> pfn = old_pfn + ((address & (psize - 1)) >> PAGE_SHIFT);
> cpa->pfn = pfn;
>
> - new_prot = static_protections(req_prot, address, pfn);
> + /*
> + * Calculate the large page base address and the number of 4K pages
> + * in the large page
> + */
> + lpaddr = address & pmask;
> + numpages = psize >> PAGE_SHIFT;
>
> /*
> - * We need to check the full range, whether
> - * static_protection() requires a different pgprot for one of
> - * the pages in the range we try to preserve:
> + * Make sure that the requested pgprot does not violate the static
> + * protections. Check the full large page whether one of the pages
> + * in it results in a different pgprot than the first one of the
> + * requested range. If yes, then the page needs to be split.
>*/
> - addr = address & pmask;
> + new_prot = static_protections(req_prot, address, pfn, 1);
"npg" is introduced by patch #3. It might be better to keep old API in
this patch.
> pfn = old_pfn;
> - for (i = 0; i < (psize >> PAGE_SHIFT); i++, addr += PAGE_SIZE, pfn++) {
> + for (i = 0, addr = lpaddr; i < numpages; i++, addr += PAGE_SIZE, pfn++)
> {
> pgprot_t chk_prot = static
Re: [PATCH] ARM: dts: imx6q-apalis: mux RESET_MOCI# signal
On Thu, Sep 06, 2018 at 04:46:58PM -0700, Stefan Agner wrote: > The pinctrl properties on the IOMUXC node get overwritten by the > carrier board level device tree, hence the pinctrl_reset_moci > pinctrl does not get applied. > > Associate the pinctrl_reset_moci pinctrl with the PCIe node where > we also make use of the pin as a reset GPIO. > > Since the pin is muxed as a GPIO by default not muxing it explicitly > worked fine in practise. > > Signed-off-by: Stefan Agner Applied, thanks.
Re: [PATCH] bcache: remove unecessary condition check before debugfs_remove_recursive
LGTM
Reviewed-by: tang.junhui.li...@gmail.com
zhong jiang 于2018年9月8日周六 下午9:41写道：
>
> debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
> remove the condition check before debugfs_remove_recursive.
>
> Signed-off-by: zhong jiang
> ---
> drivers/md/bcache/debug.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/md/bcache/debug.c b/drivers/md/bcache/debug.c
> index 06da66b..8c53d87 100644
> --- a/drivers/md/bcache/debug.c
> +++ b/drivers/md/bcache/debug.c
> @@ -249,8 +249,7 @@ void bch_debug_init_cache_set(struct cache_set *c)
>
> void bch_debug_exit(void)
> {
> - if (!IS_ERR_OR_NULL(bcache_debug))
> - debugfs_remove_recursive(bcache_debug);
> + debugfs_remove_recursive(bcache_debug);
> }
>
> void __init bch_debug_init(struct kobject *kobj)
> --
> 1.7.12.4
>
Re: [PATCH] percpu-refcount: relax limit on percpu_ref_reinit()
On Sun, Sep 09, 2018 at 11:46:20AM -0700, Bart Van Assche wrote: > On Sun, 2018-09-09 at 20:58 +0800, Ming Lei wrote: > > Now percpu_ref_reinit() can only be done on one percpu refcounter > > when it drops zero. And the limit shouldn't be so strict, and it > > is quite straightforward that percpu_ref_reinit() can be done when > > this counter is at atomic mode. > > > > This patch relaxes the limit, so we may avoid extra change[1] for NVMe > > timeout's requirement. > > > > [1] https://marc.info/?l=linux-kernel&m=153612052611020&w=2 > > Is the NVMe driver the only block driver that hangs if it is attempted to > freeze its request queue when a request times out? If so, can this hang be > fixed by modifying the NVMe driver instead of by modifying the percpu > refcount implementation? IMO, this patch is quite simple and it should be much simpler than solving this issue in block layer or NVMe, could we focus on the technical correctness of this patch first? However if anyone has better/simpler solution for this issue on any change, I am open to them too. Thanks, Ming
Linux 4.19-rc3
Another week, another rc. Things look fairly normal. The diffstat shows some unusual patterns, but that's partly due to some late nds32 updates and nilfs2 got the copyright messages converted to SPDX, and that just shows up like a sore thumb in the diffstat. But other than odd details like that, nothing really stands out. Drivers, networking and arch fixes, with misc random small changes all over (eg btrfs fixes). Shortlog appended, in case people want to look at the details. Linus --- Alexey Brodkin (3): ARC: configs: cleanup ARC: [plat-axs*/plat-hsdk]: Allow U-Boot to pass MAC-address to the kernel ARC: [plat-axs*]: Enable SWAP Alexey Khoroshilov (1): gpio: dwapb: Fix error handling in dwapb_gpio_probe() Alexey Kodanev (2): vti6: remove !skb->ignore_df check from vti6_xmit() ipv6: don't get lwtstate twice in ip6_rt_copy_init() Amir Goldstein (1): fsnotify: fix ignore mask logic in fsnotify() Anand Jain (1): btrfs: btrfs_shrink_device should call commit transaction at the end Andrew Lunn (1): net: phy: sfp: Handle unimplemented hwmon limits and alarms Andrew Morton (1): mm/util.c: improve kvfree() kerneldoc Andy Shevchenko (1): gpiolib: acpi: Switch to cansleep version of GPIO library call Aneesh Kumar K.V (1): mm/hugetlb: filter out hugetlb pages if HUGEPAGE migration is not supported. Anthony Wong (1): r8169: add support for NCube 8168 network card Arnd Bergmann (1): rfkill-gpio: include linux/mod_devicetable.h Arunk Khandavalli (1): cfg80211: nl80211_update_ft_ies() to validate NL80211_ATTR_IE Azat Khuzhin (1): r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices Bartosz Golaszewski (1): memory: ti-aemif: fix a potential NULL-pointer dereference Baruch Siach (1): net: mvpp2: initialize port of_node pointer Chris Brandt (1): sh_eth: Add R7S9210 support Christian Borntraeger (1): timekeeping: Fix declaration of read_persistent_wall_and_boot_offset() Christoph Hellwig (2): kernel/dma/direct: take DMA offset into account in dma_direct_supported sparc: set a default 32-bit dma mask for OF devices Chuanhua Lei (1): x86/tsc: Prevent result truncation on 32bit Colin Ian King (1): KVM: SVM: remove unused variable dst_vaddr_end Colin Xu (2): drm/i915/gvt: Make correct handling to vreg BXT_PHY_CTL_FAMILY drm/i915/gvt: Handle GEN9_WM_CHICKEN3 with F_CMD_ACCESS. Cong Wang (3): tipc: fix a missing rhashtable_walk_exit() tipc: switch to rhashtable iterator act_ife: fix a potential use-after-free Dan Carpenter (3): btrfs: use after free in btrfs_quota_enable scsi: aacraid: fix a signedness bug cfg80211: fix a type issue in ieee80211_chandef_to_operating_class() Danek Duvall (2): mac80211: correct use of IEEE80211_VHT_CAP_RXSTBC_X mac80211_hwsim: correct use of IEEE80211_VHT_CAP_RXSTBC_X Daniel Borkmann (6): bpf, sockmap: fix potential use after free in bpf_tcp_close bpf, sockmap: fix psock refcount leak in bpf_tcp_recvmsg bpf: fix several offset tests in bpf_msg_pull_data bpf: fix msg->data/data_end after sg shift repair in bpf_msg_pull_data bpf: fix shift upon scatterlist ring wrap-around in bpf_msg_pull_data bpf: fix sg shift repair start offset in bpf_msg_pull_data Dave Jiang (1): mm: fix BUG_ON() in vmf_insert_pfn_pud() from VM_MIXEDMAP removal David Ahern (1): net/ipv6: Only update MTU metric if it set David Howells (1): afs: Fix cell specification to permit an empty address list Davide Caratti (1): net/sched: act_pedit: fix dump of extended layered op Davidlohr Bueso (1): ipc/shm: properly return EIDRM in shm_lock() Dennis Zhou (Facebook) (3): Revert "blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()" blkcg: delay blkg destruction until after writeback has finished blkcg: use tryget logic when associating a blkg with a bio Dexuan Cui (1): hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe() Dinh Nguyen (1): net: stmmac: build the dwmac-socfpga platform driver for Stratix10 Doug Berger (1): net: bcmgenet: use MAC link status for fixed phy Dreyfuss, Haim (1): mac80211: fix WMM TXOP calculation Emmanuel Grumbach (4): mac80211: don't update the PM state of a peer upon a multicast frame mac80211: fix a race between restart and CSA flows mac80211: don't Tx a deauth frame if the AP forbade Tx mac80211: shorten the IBSS debug messages Eric Dumazet (1): Revert "packet: switch kvzalloc to allocate memory" Eugeniy Paltsev (5): ARC: cleanup show_faulting_vma() ARC: dma [IOC]: mark DMA devices connected as dma-coherent ARC: dma [IOC] Enable per device io coherency ARC: IOC: panic if both IOC and ZONE_HIGHMEM enabled ARC: don't check for HI
[PATCH v2 2/3] ARM: OMAP1: ams-delta: initialize latch2 pins to safe values
Latch2 pins control a number of on-board devices, namely LCD, NAND,
MODEM and CODEC. Those pins used to be initialized with safe values
from init_machine before that operation was:
1) moved to late_initcall in preparation for conversion of latch2 to
GPIO device - see commit f7519d8c8290 ("ARM: OMAP1: ams-delta: register
latch dependent devices later"),
2) replaced with non-atomic initialization performed by means of
gpio_request_array() - see commit 937eb4bb0058 ("ARM: OMAP1: ams-delta:
convert latches to basic_mmio_gpio"),
3) made completely asynchronous by delegation of GPIO request
operations performed on subsets of pins to respective device drivers in
subsequent commits.
One visible negative result of that disintegration was corrupt keyboard
data reported by serio driver, recently fixed by commit 41f8fee385a0
("ARM: OMAP1: ams-delta: Hog "keybrd_dataout" GPIO pin").
Moreover, initialization of LATCH2_PIN_MODEM_CODEC still performed with
ams_delta_latch2_write() wrapper from late_init() is now done on not
requested GPIO pin.
Reintroduce atomic initialization of latch2 pins at machine_init to
prevent from random values potentially corrupting NAND data or maybe
even destroing other hardware. Also take care of MODEM/CODEC related
pins so MODEM device probe succeeds even if latch2 GPIO device or
dependent regulator is not ready and CODEC can be reached over the
MODEM even if audio driver doesn't take control over
LATCH2_PIN_MODEM_CODEC.
Once done, remove the no longer needed GPIO based implementation of
ams_delta_latch_write() and its frontend macro.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Linus Walleij
---
arch/arm/mach-omap1/board-ams-delta.c | 52 +++
arch/arm/mach-omap1/board-ams-delta.h | 7 -
2 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 2b90b543c030..1d451142248c 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -321,20 +321,6 @@ struct modem_private_data {
static struct modem_private_data modem_priv;
-void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
-{
- int bit = 0;
- u16 bitpos = 1 << bit;
-
- for (; bit < ngpio; bit++, bitpos = bitpos << 1) {
- if (!(mask & bitpos))
- continue;
- else
- gpio_set_value(base + bit, (value & bitpos) != 0);
- }
-}
-EXPORT_SYMBOL(ams_delta_latch_write);
-
static struct resource ams_delta_nand_resources[] = {
[0] = {
.start = OMAP1_MPUIO_BASE,
@@ -680,6 +666,40 @@ static void __init omap_gpio_deps_init(void)
modem_assign_irq(chip);
}
+/*
+ * Initialize latch2 pins with values which are safe for dependent on-board
+ * devices or useful for their successull initialization even before GPIO
+ * driver takes control over the latch pins:
+ * - LATCH2_PIN_LCD_VBLEN = 0
+ * - LATCH2_PIN_LCD_NDISP = 0 Keep LCD device powered off before its
+ * driver takes control over it.
+ * - LATCH2_PIN_NAND_NCE = 0
+ * - LATCH2_PIN_NAND_NWP = 0 Keep NAND device down and write-
+ * protected before its driver takes
+ * control over it.
+ * - LATCH2_PIN_KEYBRD_PWR = 0 Keep keyboard powered off before serio
+ * driver takes control over it.
+ * - LATCH2_PIN_KEYBRD_DATAOUT = 0 Keep low to avoid corruption of first
+ * byte of data received from attached
+ * keyboard when serio device is probed;
+ * the pin is also hogged low by the latch2
+ * GPIO driver as soon as it is ready.
+ * - LATCH2_PIN_MODEM_NRESET = 1 Enable voice MODEM device, allowing for
+ * its successful probe even before a
+ * regulator it depends on, which in turn
+ * takes control over the pin, is set up.
+ * - LATCH2_PIN_MODEM_CODEC= 1 Attach voice MODEM CODEC data port
+ * to the MODEM so the CODEC is under
+ * control even if audio driver doesn't
+ * take it over.
+ */
+static void __init ams_delta_latch2_init(void)
+{
+ u16 latch2 = 1 << LATCH2_PIN_MODEM_NRESET | 1 << LATCH2_PIN_MODEM_CODEC;
+
+ __raw_writew(latch2, LATCH2_VIRT);
+}
+
static void __init ams_delta_init(void)
{
/* mux pins for uarts */
@@ -701,6 +721,7 @@ static void __init ams_delta_init(void)
omap_cfg_reg(J18_1610_CAM_D7);
omap_gpio_deps_init();
+ ams_delta_latch2_init();
gpiod_add_hogs(ams_delta_
Re: [PATCH 4.4 00/47] 4.4.155-stable review
On Sun, Sep 09, 2018 at 11:17:03AM +0200, Greg Kroah-Hartman wrote: > On Sun, Sep 09, 2018 at 10:22:27AM +0530, Naresh Kamboju wrote: > > On 8 September 2018 at 02:39, Greg Kroah-Hartman > > wrote: > > > This is the start of the stable review cycle for the 4.4.155 release. > > > There are 47 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sun Sep 9 21:08:44 UTC 2018. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.155-rc1.gz > > > or in the git tree and branch at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > linux-4.4.y > > > and the diffstat can be found below. > > > > > > thanks, > > > > > > greg k-h > > > > > > - > > > Pseudo-Shortlog of commits: > > > > > > Jann Horn > > > userns: move user access out of the mutex > > > > Results from Linaro’s test farm. > > Regressions on arm64, arm, x86_64 and i386. > > LTP containers tests > > > > Test cases: userns02/03/06/07 failed on all devices. > > > > LTP: user_namespace2 1 TBROK : safe_macros.c:452: userns02.c:95: > > write(6,0x7ffc133113d0,18446744073709551615) failed: errno=EFAULT(14): > > Bad address > > > > Other bug from kernel selftests, > > mount_run_tests.sh bugs needs to be investigated. > > > > selftests: mount_run_tests.sh [FAIL] > > write to /proc/self/uid_map failed: Bad address > > -rc3 is pushed out now with, hopefully, the fix for this. Looks good. The issues we saw in -rc1 in kselftest/mount_run_tests.sh and ltp/userns* have been resolved in -rc3. The "regressions" flagged below in the report are known intermittent failures, unrelated to the content of this release. Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.4.155-rc3 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: f4777549b6b8529d14ec8d0735ae16a75a576d0c git describe: v4.4.154-48-gf4777549b6b8 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.154-48-gf4777549b6b8 Regressions (compared to build v4.4.153-81-gc9eed05cd5dd) i386: ltp-open-posix-tests: * clock_settime_8-1 * test src: git://github.com/linux-test-project/ltp.git ltp-syscalls-tests: * fcntl36 * runltp_syscalls * test src: git://github.com/linux-test-project/ltp.git Ran 16810 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu_arm - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none Summary kernel: 4.4.155-rc3 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.155-rc3-hikey-20180909-278 git commit: 5cfd2cd505263e1e94e7d97e3b348dcd9f5e893b git describe: 4.4.155-rc3-hikey-20180909-278 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.155-rc3-hikey-20180909-278 No regressions (compared to build v4.4.153-81-gc9eed05cd5dd) Ran 2724 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 - qemu_arm64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] ARM: dts: imx6qdl-sabreauto: add gpio keys support
On Wed, Sep 05, 2018 at 03:46:12PM +0800, Anson Huang wrote: > Add i.MX6QDL SabreAuto board's gpio keys support, there > are 5 gpio keys on base board: > > SW3: KEY_HOME; > SW4: KEY_BACK; > SW5: KEY_PROGRAM; > SW6: KEY_VOLUMEUP; > SW7: KEY_VOLUMEDOWN; > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH] ARM: dts: imx6qdl-sabreauto: add egalax touch screen support
On Wed, Sep 05, 2018 at 04:10:29PM +0800, Anson Huang wrote: > Add egalax touch screen support on i2c2 bus. > > Signed-off-by: Anson Huang Applied, thanks.
Attention:
Attn: I am Mr. Salim Zaid, citizen and Principal assurance manager in one of reputable banks in Europe. Mr. Mohammed Raji a staff of Saudi Kayan Petrochemical Company got in touch with me on an investment which was placed under our banks management some years ago.I would respectfully request that you keep the contents of this mail confidential and respect the integrity of the information you come by as a result of this mail. I contact you independently of our investigation and no one is informed of this communication. I would like to intimate you with certain facts that I believe would be of interest to you. In 2010, the subject matter; Mr. Mohammed Raji came to our bank to engage in business discussions with our private banking division. He informed us that he had a financial portfolio of $75, 000, 000, 00 (Seventy-Five Million United States dollars), which he wished to have us turn over (invest) on his behalf. I was the officer assigned to his case; I made numerous suggestions in line with my duties as the de-facto chief operations officer, especially given the volume of funds he wished to put into our bank.We met on numerous occasions prior to any investments being placed. He later asks the business to be close that he wants to move the funds to another country for investment. The funds was moved to a private finance company who were specialist bank that accepts deposits from high net worth individuals and blue chip corporations that handle valuable products or undertake transactions that need immediate access to cash. Mr. Mohammed Raji told me he wanted the money there as soon as he got into the country. This was the last communication we had; this transpired last 2010, we later got a call from the finance Company informing us about the inactivity of that particular portfolio. This was an astounding position as far as I was concerned, given the fact that I managed the International private banking sector I was the only one who knew about the deposit, and I could not understand why Mr. Mohammed Raji had not come forward to claim his deposit. The disappearance of Mr. Mohammed Raji which was later confirmed that he was killed in of one of the bomb attack in Iraq. This bank has spent great amounts of money trying to track this man's family; they have investigated for months and have found no family. The investigation has come to an end. My proposal is I want to introduce you to the bank as the next of kin in a position to instruct the Finance company to release the deposit to you as the closest surviving relation. Upon receipt of the deposit, I am prepared to share the money with you. That is: I will simply nominate you as the next of kin and have them release the deposit to you.25% of the total fund will be given to you for your position as the next of kin. while I will keep the 75% for my retirement. I would have gone ahead to ask the funds be released to me but that would have drawn a straight line in my involvement in claiming the deposit. I assure you that I could have the deposit released to you within a few days. I will simply inform the bank of the final closing of the file relating to Mr. Mohammed Raji. I will then officially communicate with the Finance company and instruct them to release the deposit to you which they will gladly do. I am aware of the consequences of this proposal. So I ask that if you find no interest in this project that you should discard this mail. I ask that you do not be vindictive and destructive. If my offer is of no appeal to you, delete this message and forget I ever contacted you. Do not destroy my career because you do not approve of my proposal. You may not know this but people like me who have made tidy sums out of comparable situations run the whole private banking sector. I am not a criminal and what I do, I do not find against good conscience, this may be hard for you to understand, but the dynamics of my industry dictates that I make this move. Such opportunities only come ones way once in a lifetime. I cannot let this chance pass me by, for once I find myself in total control of my destiny. These chances won't pass me by. I ask that you do not destroy my chance, if you will not work with me let me know and let me move on with my life but do not destroy me. I am a family man and this is an opportunity to provide them with new opportunities. There is a reward for this project and it is a task well worth undertaking. I have evaluated the risks and the only risk I have here is from you refusing to work with me and alerting my bank. I am the only one who knows of this situation, good fortune has blessed you with a name that has planted you into the center of relevance in my life. Let's share the blessing. If you give me positive signals, I will initiate this process towards a conclusion. I wish to inform you that should you contact me via official channels; I will deny knowing you and about this project. I repeat, I do not want you contacting me through
linux-next: 0907 fails to boot on thinkpad x60 (32bit machine)
Hi! I do have some oopses, but they seem to be different on each boot. IIRC message was "scheduling?...on offline CPU?". Any ideas? Does it work for you? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH 5/5] MAINTAINERS: Add Lukas Wunner as co-maintainer of thunderbolt
Andreas Noever has let it be known off-list already a while ago that he currently cannot spare as much time for Thunderbolt development as he'd like. As a result the driver's development has become dominated by Intel. I would like to step up as co-maintainer to provide additional checks and balances and prevent the driver from degenerating into an Intel-only show. A number of things really irk me: * I've been contributing to this driver as well as Thunderbolt-related bits to the EFI, GPU and PCI subsystems for close to three years and was explicitly asked by Intel to cc them on every Thunderbolt-related patch. Yet Intel did not see fit to cc me on their changes that went into 4.17. I literally only learned about their existence from reading the news. In the 4.19 cycle I was only cc'ed on a subset of their patches. * Intel's efforts have been focussed exclusively on firmware-controlled tunnel management (ICM). They made no contributions to OS-controlled tunnel management. ICM cannot be used on Macs with Thunderbolt 1 + 2. ICM requires trusting a firmware blob. ICM does not offer the same versatility as OS-controlled tunnel management, e.g. using separate tunnels to afford different QoS levels or correlation of Thunderbolt ports with PCI devices. Apple chose OS-controlled tunnel management for very valid technical reasons. * Our OS-controlled tunnel management still lacks important features such as daisy-chaining and DP tunnels. Each feature needs to be reverse-engineered because there is no public spec. Intel issued a press statement in May 2017 promising to make the specification public "next year". More than a year has passed -- no spec. The company has since changed leadership, who knows if they haven't silently canned the plans for a public spec? I offered to sign an NDA and go through a disclosure process for every patch -- no reaction. * Reverse-engineering requires verbose logging so that we're able to collect data on various systems and endpoint devices to deduce the meaning of registers. Yet Intel now seeks to mute log output, thereby curbing our reverse-engineering efforts. This exemplifies a worrying tendency to ignore the needs of non-Intel stakeholders in the developer community or even undermine them. * Recent Intel contributions are maintainer self-commits without any Reviewed-by tags, which is generally considered a bad practice. Review comments offered by Intel-outsiders are not taken seriously. For example the driver's initcall level has been fiddled with twice now. A review comment pointing out the fragility of abusing initcall levels to implement dependencies and suggesting the use of a notifier chain instead was summarily dismissed as unnecessary unless it breaks a third time. Signed-off-by: Lukas Wunner --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index a5b256b25905..8815f4639e58 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14445,6 +14445,7 @@ F: drivers/platform/x86/thinkpad_acpi.c THUNDERBOLT DRIVER M: Andreas Noever +M: Lukas Wunner M: Michael Jamet M: Mika Westerberg M: Yehezkel Bernat -- 2.18.0
[PATCH 4/5] thunderbolt: Correlate PCI devices with Thunderbolt ports
macOS correlates PCI devices with Thunderbolt ports and stores their
device paths in each other's I/O Registry entry:
IOThunderboltPort@7 {
"PCI Device" = 4
"PCI Function" = 0
"PCI Path" =
"IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEG1@1,1/IOPP/UPSB@0/IOPP/DSB2@4"
...
}
DSB2@4 {
"pcidebug" = "6:4:0(132:132)"
"Thunderbolt Path" =
"IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEG1@1,1/IOPP/UPSB@0/IOPP/DSB0@0/IOPP/NHI0@0/AppleThunderboltHAL/AppleThunderboltNHIType1/IOThunderboltController/IOThunderboltPort@6/IOThunderboltSwitchType1/IOThunderboltPort@7"
...
}
Do the same by finding the Thunderbolt port corresponding to a PCI
device from a bus notifier and storing a pointer to the PCI device in
struct tb_port. On initial switch scan, fill in the pointers for
already enumerated PCI devices.
This achieves a unidirectional mapping from tb_port to pci_dev. If an
inverse mapping is needed, it may be possible to use the sysdata pointer
in struct pci_dev.
To find the Thunderbolt port, the PCI slot numbers specified in the root
switch's DROM need to be available. On Macs with Thunderbolt 1 that's
not the case unless the kernel is booted by the EFI stub.
Moreover the driver needs to know which tunnels have been established,
which is not the case with ICM-controlled tunnel management, so the bus
notifier is only registered if tunnel management is under OS control.
Perhaps it is possible to retrieve a list of established tunnels from
the ICM firmware, or if all else fails, follow the hop entries in a
downstream port's config space to discover established tunnels.
Correlation would then also work for ICM-controlled tunnel management.
Ideas what we can do with correlation:
* Represent the relationship between PCI devices and Thunderbolt ports
with symlinks in sysfs.
* Thunderbolt controllers up to revision 1 of Cactus Ridge 4C have to
use INTx because MSI signaling is broken. This results in hotplug
ports sharing interrupts with other devices and, when daisy-chaining
multiple affected Thunderbolt controllers, can lead to extremely
unbalanced interrupt usage. To avoid this we could prefer downstream
ports for tunnel establishment which do not share interrupts (based
on the nr_actions field of the correlated PCI device's irq_desc).
* Alternatively, we could use non-working MSI signaling on affected
controllers and synthesize an interrupt whenever a tunnel is
established or goes down on unplug.
The shared interrupts issue is grave. This is /proc/interrupts on a
MacBookPro9,1 with a daisy-chain of two Light Ridge controllers and
one Port Ridge (all with broken MSI signaling):
16: IO-APIC 16-fasteoi pciehp
17: IO-APIC 17-fasteoi pciehp, pciehp, pciehp, mmc0, snd_hda_intel, b43
18: IO-APIC 18-fasteoi pciehp, pciehp, i801_smbus
19: IO-APIC 19-fasteoi pciehp
Signed-off-by: Lukas Wunner
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/adapter_pci.c | 166 ++
drivers/thunderbolt/adapter_pci.h | 19
drivers/thunderbolt/tb.c | 21 ++--
drivers/thunderbolt/tb.h | 36 +++
5 files changed, 230 insertions(+), 14 deletions(-)
create mode 100644 drivers/thunderbolt/adapter_pci.c
create mode 100644 drivers/thunderbolt/adapter_pci.h
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index f2f0de27252b..c91b9f7d4c0b 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o
eeprom.o
-thunderbolt-objs += domain.o dma_port.o icm.o property.o xdomain.o
+thunderbolt-objs += adapter_pci.o domain.o dma_port.o icm.o property.o
xdomain.o
diff --git a/drivers/thunderbolt/adapter_pci.c
b/drivers/thunderbolt/adapter_pci.c
new file mode 100644
index ..e5abcbd6d064
--- /dev/null
+++ b/drivers/thunderbolt/adapter_pci.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe adapters on a Thunderbolt switch serve as endpoints for PCI tunnels.
+ * Each may be attached to an upstream or downstream port of the PCIe switch
+ * integrated into a Thunderbolt controller.
+ *
+ * Copyright (C) 2018 Lukas Wunner
+ */
+
+#include "tb.h"
+#include "tunnel_pci.h"
+#include "adapter_pci.h"
+
+/**
+ * tb_is_pci_adapter() - whether given PCI device is a Thunderbolt PCIe adapter
+ * @pdev: PCI device
+ *
+ * For simplicity this function returns a false positive in the following cases
+ * and callers need to make sure they can handle that:
+ * * Upstream port on a host controller
+ * * Downstream port to the XHCI on a host controller
+ * * Downstream port on non-chainable endpoint controllers such as Port Ridge
+ */
+static bool tb_is_pci_adapter(struct pci_dev *pdev)
+{
+ /* downstream ports with devfn 0 are reserved for the NHI */
+ return pdev->is_thunderbolt &&
+
[PATCH 3/5] thunderbolt: Move upstream_port to struct tb
The code for ICM-controlled tunnel management stores a pointer to the
upstream port in struct icm. We're going to need it in the code for
OS-controlled tunnel management as well, so move the pointer to
struct tb which is shared by both tunnel management methods.
Searching for the upstream port previously comprised walking upward from
the NHI until a PCIe upstream port is found. That seems needlessly
complicated since on all known Thunderbolt controllers, the upstream
port is the NHI's grandparent, i.e. exactly two levels above. Simplify
the search accordingly.
No functional change intended.
Signed-off-by: Lukas Wunner
---
drivers/thunderbolt/domain.c | 12 +++
drivers/thunderbolt/icm.c| 65 +---
include/linux/thunderbolt.h | 2 ++
3 files changed, 29 insertions(+), 50 deletions(-)
diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c
index 092381e2accf..ba9e4ed88bf2 100644
--- a/drivers/thunderbolt/domain.c
+++ b/drivers/thunderbolt/domain.c
@@ -326,6 +326,7 @@ struct device_type tb_domain_type = {
struct tb *tb_domain_alloc(struct tb_nhi *nhi, size_t privsize)
{
struct tb *tb;
+ int i;
/*
* Make sure the structure sizes map with that the hardware
@@ -350,6 +351,15 @@ struct tb *tb_domain_alloc(struct tb_nhi *nhi, size_t
privsize)
if (!tb->wq)
goto err_remove_ida;
+ tb->upstream = nhi->pdev;
+ for (i = 0; i < 2; i++) {
+ tb->upstream = pci_upstream_bridge(tb->upstream);
+ if (!tb->upstream) {
+ pci_err(nhi->pdev, "cannot find upstream, aborting\n");
+ goto err_destroy_wq;
+ }
+ }
+
tb->dev.parent = &nhi->pdev->dev;
tb->dev.bus = &tb_bus_type;
tb->dev.type = &tb_domain_type;
@@ -359,6 +369,8 @@ struct tb *tb_domain_alloc(struct tb_nhi *nhi, size_t
privsize)
return tb;
+err_destroy_wq:
+ destroy_workqueue(tb->wq);
err_remove_ida:
ida_simple_remove(&tb_domain_ida, tb->index);
err_free:
diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
index e1e264a9a4c7..b6ce3eea3de5 100644
--- a/drivers/thunderbolt/icm.c
+++ b/drivers/thunderbolt/icm.c
@@ -51,11 +51,8 @@
* struct icm - Internal connection manager private data
* @request_lock: Makes sure only one message is send to ICM at time
* @rescan_work: Work used to rescan the surviving switches after resume
- * @upstream_port: Pointer to the PCIe upstream port this host
- *controller is connected. This is only set for systems
- *where ICM needs to be started manually
* @vnd_cap: Vendor defined capability where PCIe2CIO mailbox resides
- * (only set when @upstream_port is not %NULL)
+ * (only set on Macs as they require a firmware reset to use ICM)
* @safe_mode: ICM is in safe mode
* @max_boot_acl: Maximum number of preboot ACL entries (%0 if not supported)
* @rpm: Does the controller support runtime PM (RTD3)
@@ -72,7 +69,6 @@
struct icm {
struct mutex request_lock;
struct delayed_work rescan_work;
- struct pci_dev *upstream_port;
size_t max_boot_acl;
int vnd_cap;
bool safe_mode;
@@ -1188,60 +1184,29 @@ icm_tr_xdomain_disconnected(struct tb *tb, const struct
icm_pkg_header *hdr)
}
}
-static struct pci_dev *get_upstream_port(struct pci_dev *pdev)
-{
- struct pci_dev *parent;
-
- parent = pci_upstream_bridge(pdev);
- while (parent) {
- if (!pci_is_pcie(parent))
- return NULL;
- if (pci_pcie_type(parent) == PCI_EXP_TYPE_UPSTREAM)
- break;
- parent = pci_upstream_bridge(parent);
- }
-
- if (!parent)
- return NULL;
-
- switch (parent->device) {
- case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_2C_BRIDGE:
- case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_BRIDGE:
- case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_LP_BRIDGE:
- case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_C_4C_BRIDGE:
- case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_C_2C_BRIDGE:
- return parent;
- }
-
- return NULL;
-}
-
static bool icm_ar_is_supported(struct tb *tb)
{
- struct pci_dev *upstream_port;
struct icm *icm = tb_priv(tb);
+ int cap;
/*
* Starting from Alpine Ridge we can use ICM on Apple machines
* as well. We just need to reset and re-enable it first.
+* Reset is performed through the vendor specific capability.
*/
if (!x86_apple_machine)
return true;
- /*
-* Find the upstream PCIe port in case we need to do reset
-* through its vendor specific registers.
-*/
- upstream_port = get_upstream_port(tb->nhi->pdev);
- if (upstream_port) {
- int cap;
-
- cap = pci_find_ext_capabili
[PATCH 2/5] thunderbolt: Obtain PCI slot number from DROM
The port numbers of PCIe adapters on a CIO switch and the slot numbers
of their corresponding PCI devices don't necessarily match up in
ascending order.
E.g. Light Ridge in host mode (MacBookPro9,1) mixes them up like this:
switch port 7 == pci slot 4 (PCIe downstream port)
switch port 8 == pci slot 5 (PCIe downstream port)
switch port 9 == pci slot 6 (PCIe downstream port)
switch port 10 == pci slot 3 (PCIe downstream port)
Light Ridge in endpoint mode (Sonnet Echo Express):
switch port 7 == pci slot 4 (PCIe downstream port)
switch port 8 == pci slot 5 (PCIe downstream port)
switch port 9 (PCIe downstream port, disabled in DROM)
switch port 10 == pci slot 0 (PCIe upstream port, pci slot 3 in DROM)
Obtain the slot number used by a switch port from the DROM and store it
in struct tb_port. This will allow us to correlate PCI devices with
Thunderbolt ports. For space efficiency, use a union in struct tb_port
to store attributes that are specific to certain port types.
Attributes specific to TB_TYPE_PORT could be moved into a separate
struct within the union.
The slot number occupies 3 bits in the third byte of PCI DROM entries.
The purpose of the remaining 5 bits is unknown (function number?).
Downstream port entries have 3 bytes, upstream port entries 11 bytes.
The slot number in upstream port entries is not that of the port itself
(which is always zero), but that of the PCI endpoint device built into
the Thunderbolt product. In the case of the Sonnet Echo Express, the
upstream port specifies slot 3, which is used by a PLX switch.
The purpose of the additional 8 bytes present on upstream ports is
unknown (number of PCIe lanes, priority requirements, direct tunnel to
the host desired?). Examples:
01 00 64 00 00 00 00 00 (Sonnet Echo Express, PLX switch)
01 40 0a 00 00 00 00 00 (Apple Gigabit Ethernet Adapter, BCM957762)
Signed-off-by: Lukas Wunner
---
drivers/thunderbolt/eeprom.c | 21 +
drivers/thunderbolt/switch.c | 14 +-
drivers/thunderbolt/tb.h | 9 +
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index 3e8caf22c294..ce6e037fdb39 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -236,6 +236,15 @@ struct tb_drom_entry_port {
u8 unknown4:2;
} __packed;
+struct tb_drom_entry_pci {
+ /* BYTES 0-1 */
+ struct tb_drom_entry_header header;
+ /* BYTE 2 */
+ u8 unknown:5;
+ u8 slot:3;
+ /* BYTES 3-10 are only present on PCIe upstream ports */
+} __packed;
+
/**
* tb_eeprom_get_drom_offset - get drom offset within eeprom
@@ -365,6 +374,18 @@ static int tb_drom_parse_entry_port(struct tb_switch *sw,
if (entry->has_dual_link_port)
port->dual_link_port =
&port->sw->ports[entry->dual_link_port_nr];
+ } else if (type == TB_TYPE_PCIE_UP || type == TB_TYPE_PCIE_DOWN) {
+ struct tb_drom_entry_pci *entry = (void *) header;
+ if (header->len < sizeof(*entry)) {
+ tb_sw_warn(sw,
+ "port entry has size %#x (expected %#zx+)\n",
+ header->len, sizeof(struct tb_drom_entry_pci));
+ return -EIO;
+ }
+ port->pci.devfn = PCI_DEVFN(entry->slot, 0);
+ memcpy(port->pci.unknown, header + 1,
+ min(header->len - sizeof(struct tb_drom_entry_header),
+ sizeof(port->pci.unknown)));
}
return 0;
}
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 7442bc4c6433..54fd42250935 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -577,6 +577,7 @@ int tb_port_clear_counter(struct tb_port *port, int counter)
*/
static int tb_init_port(struct tb_port *port)
{
+ struct tb *tb = port->sw->tb;
int res;
int cap;
@@ -594,9 +595,20 @@ static int tb_init_port(struct tb_port *port)
tb_port_WARN(port, "non switch port without a PHY\n");
}
- tb_dump_port(port->sw->tb, &port->config);
+ tb_dump_port(tb, &port->config);
/* TODO: Read dual link port, DP port and more from EEPROM. */
+ switch (port->config.type) {
+ case TB_TYPE_PCIE_UP:
+ case TB_TYPE_PCIE_DOWN:
+ tb_info(tb, " PCI slot: %02x.0\n", PCI_SLOT(port->pci.devfn));
+ tb_info(tb, " PCI unknown data: %*ph\n",
+ (int)sizeof(port->pci.unknown), port->pci.unknown);
+ break;
+ default:
+ break;
+ }
+
return 0;
}
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index 5067d69d0501..755183f0b257 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -125,6 +125,9 @@ struct
[PATCH 1/5] thunderbolt: Skip disabled ports on tunnel establishment
If a PCIe downstream adapter is marked disabled in the DROM, that port
is ineligible for tunnel establishment, so skip over it when searching
for an unused port.
Signed-off-by: Lukas Wunner
---
drivers/thunderbolt/tb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index 1424581fd9af..0da2e7a06ab5 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -147,6 +147,8 @@ static struct tb_port *tb_find_unused_down_port(struct
tb_switch *sw)
int res;
int data;
for (i = 1; i <= sw->config.max_port_number; i++) {
+ if (sw->ports[i].disabled)
+ continue;
if (tb_is_upstream_port(&sw->ports[i]))
continue;
if (sw->ports[i].config.type != TB_TYPE_PCIE_DOWN)
--
2.18.0
[PATCH 0/5] Thunderbolt material for v4.20
Thunderbolt material for v4.20, comprising: * A fix to skip disabled ports on tunnel establishment. I am not aware that this has caused breakage in the real world so far, so no need to apply to v4.19 or backport to stable. * Obtain PCI slot number from DROM and use it to correlate PCI devices with Thunderbolt ports. * I am nominating myself as co-maintainer, see commit message for the reasons. Regarding the driver's verbosity which Stephen Hemminger and Mika Westerberg have taken exception to: * Patch [2/5] logs the PCI slot number as well as data whose purpose is unknown at KERN_INFO severity. I am not opposed to log the former at KERN_DEBUG severity, but the latter must stay at KERN_INFO to allow us to collect the data of various Thunderbolt devices in the wild and reverse-engineer its meaning. If Intel divulges the data's meaning then it need no longer be dumped. This would be ideal for everyone involved. * Patch [4/5] logs a message at KERN_INFO severity whenever a PCI device correlates or no longer correlates with a Thunderbolt port. I am not opposed to toning this down to KERN_DEBUG, subject to the introduction of tb_port_dbg(). Thanks, Lukas Lukas Wunner (5): thunderbolt: Skip disabled ports on tunnel establishment thunderbolt: Obtain PCI slot number from DROM thunderbolt: Move upstream_port to struct tb thunderbolt: Correlate PCI devices with Thunderbolt ports MAINTAINERS: Add Lukas Wunner as co-maintainer of thunderbolt MAINTAINERS | 1 + drivers/thunderbolt/Makefile | 2 +- drivers/thunderbolt/adapter_pci.c | 166 ++ drivers/thunderbolt/adapter_pci.h | 19 drivers/thunderbolt/domain.c | 12 +++ drivers/thunderbolt/eeprom.c | 21 drivers/thunderbolt/icm.c | 65 +++- drivers/thunderbolt/switch.c | 14 ++- drivers/thunderbolt/tb.c | 23 ++--- drivers/thunderbolt/tb.h | 45 include/linux/thunderbolt.h | 2 + 11 files changed, 305 insertions(+), 65 deletions(-) create mode 100644 drivers/thunderbolt/adapter_pci.c create mode 100644 drivers/thunderbolt/adapter_pci.h -- 2.18.0
Re: [PATCH 4.9 00/63] 4.9.126-stable review
On 09/09/2018 11:03 AM, Greg Kroah-Hartman wrote: On Sun, Sep 09, 2018 at 08:54:41AM -0700, Guenter Roeck wrote: On 09/09/2018 01:55 AM, Greg Kroah-Hartman wrote: On Sat, Sep 08, 2018 at 02:14:53PM -0700, Guenter Roeck wrote: On 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 149 fail: 2 Failed builds: powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 301 pass: 285 fail: 16 Failed tests: powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs powerpc:pseries:pseries_defconfig:initrd powerpc:pseries:pseries_defconfig:scsi:rootfs powerpc:pseries:pseries_defconfig:mmc:rootfs powerpc:pseries:pseries_defconfig:nvme:rootfs powerpc:pseries:pseries_defconfig:little:initrd powerpc:pseries:pseries_defconfig:little:scsi:rootfs powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs powerpc:pseries:pseries_defconfig:little:mmc:rootfs powerpc:pseries:pseries_defconfig:little:nvme:rootfs powerpc:powernv:powernv_defconfig:initrd Details are available at https://kerneltests.org/builders/. I've pushed out a -rc2 to fix this. Hopefully. There were a bunch of warnings for power that I don't think were caused by these series, I don't know if they have always been there or not. For v4.9.125-65-g0f793f1ec4f3: Build results: total: 151 pass: 150 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 301 pass: 301 fail: 0 arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges': arch/powerpc/kernel/fadump.c:738:2: error: implicit declaration of function 'kfree' arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges': arch/powerpc/kernel/fadump.c:757:14: error: implicit declaration of function 'krealloc' Oops, forgot to fix that one. Shoould now be resolved. Did you push your change ? My builders didn't pick it up. Guenter
[PATCH] mfd: menelaus: fix possible race condition and leak
The IRQ work is added before the struct rtc is allocated and registered,
but this struct is used in the IRQ handler. This may lead to a NULL pointer
dereference.
Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
before calling menelaus_add_irq_work.
Also, this solves a possible leak as the RTC is never released.
Signed-off-by: Alexandre Belloni
---
Lee,
If that is ok with you, I would like to take this patch through the RTC
tree. So I can have a follow up patch removing rtc_device_register().
Thanks
drivers/mfd/menelaus.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 29b7164a823b..d28ebe7ecd21 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1094,6 +1094,7 @@ static void menelaus_rtc_alarm_work(struct menelaus_chip
*m)
static inline void menelaus_rtc_init(struct menelaus_chip *m)
{
int alarm = (m->client->irq > 0);
+ int err;
/* assume 32KDETEN pin is pulled high */
if (!(menelaus_read_reg(MENELAUS_OSC_CTRL) & 0x80)) {
@@ -1101,6 +1102,12 @@ static inline void menelaus_rtc_init(struct
menelaus_chip *m)
return;
}
+ m->rtc = devm_rtc_allocate_device(&m->client->dev);
+ if (IS_ERR(m->rtc))
+ return;
+
+ m->rtc->ops = &menelaus_rtc_ops;
+
/* support RTC alarm; it can issue wakeups */
if (alarm) {
if (menelaus_add_irq_work(MENELAUS_RTCALM_IRQ,
@@ -1125,10 +1132,8 @@ static inline void menelaus_rtc_init(struct
menelaus_chip *m)
menelaus_write_reg(MENELAUS_RTC_CTRL, m->rtc_control);
}
- m->rtc = rtc_device_register(DRIVER_NAME,
- &m->client->dev,
- &menelaus_rtc_ops, THIS_MODULE);
- if (IS_ERR(m->rtc)) {
+ err = rtc_register_device(m->rtc);
+ if (err) {
if (alarm) {
menelaus_remove_irq_work(MENELAUS_RTCALM_IRQ);
device_init_wakeup(&m->client->dev, 0);
--
2.19.0.rc2
[PATCH 2/3] rtc: pl030: fix possible race condition
The IRQ is requested before the struct rtc is allocated and registered, but
this struct is used in the IRQ handler. This may lead to a NULL pointer
dereference.
Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
before requesting the IRQ.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pl030.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-pl030.c b/drivers/rtc/rtc-pl030.c
index f85a1a93e669..343bb6ed1783 100644
--- a/drivers/rtc/rtc-pl030.c
+++ b/drivers/rtc/rtc-pl030.c
@@ -112,6 +112,13 @@ static int pl030_probe(struct amba_device *dev, const
struct amba_id *id)
goto err_rtc;
}
+ rtc->rtc = devm_rtc_allocate_device(&dev->dev);
+ if (IS_ERR(rtc->rtc)) {
+ ret = PTR_ERR(rtc->rtc);
+ goto err_rtc;
+ }
+
+ rtc->rtc->ops = &pl030_ops;
rtc->base = ioremap(dev->res.start, resource_size(&dev->res));
if (!rtc->base) {
ret = -ENOMEM;
@@ -128,12 +135,9 @@ static int pl030_probe(struct amba_device *dev, const
struct amba_id *id)
if (ret)
goto err_irq;
- rtc->rtc = rtc_device_register("pl030", &dev->dev, &pl030_ops,
- THIS_MODULE);
- if (IS_ERR(rtc->rtc)) {
- ret = PTR_ERR(rtc->rtc);
+ ret = rtc_register_device(rtc->rtc);
+ if (ret)
goto err_reg;
- }
return 0;
@@ -154,7 +158,6 @@ static int pl030_remove(struct amba_device *dev)
writel(0, rtc->base + RTC_CR);
free_irq(dev->irq[0], rtc);
- rtc_device_unregister(rtc->rtc);
iounmap(rtc->base);
amba_release_regions(dev);
--
2.19.0.rc2
[PATCH 1/3] rtc: mt6397: fix possible race condition
The IRQ is requested before the struct rtc is allocated and registered, but
this struct is used in the IRQ handler. This may lead to a NULL pointer
dereference.
Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
before requesting the IRQ.
Cc: Eddie Huang
Cc: Sean Wang
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-mt6397.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 385f8303bb41..e9a25ec4d434 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -332,6 +332,10 @@ static int mtk_rtc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, rtc);
+ rtc->rtc_dev = devm_rtc_allocate_device(rtc->dev);
+ if (IS_ERR(rtc->rtc_dev))
+ return PTR_ERR(rtc->rtc_dev);
+
ret = request_threaded_irq(rtc->irq, NULL,
mtk_rtc_irq_handler_thread,
IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
@@ -344,11 +348,11 @@ static int mtk_rtc_probe(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, 1);
- rtc->rtc_dev = rtc_device_register("mt6397-rtc", &pdev->dev,
- &mtk_rtc_ops, THIS_MODULE);
- if (IS_ERR(rtc->rtc_dev)) {
+ rtc->rtc_dev->ops = &mtk_rtc_ops;
+
+ ret = rtc_register_device(rtc->rtc_dev);
+ if (ret) {
dev_err(&pdev->dev, "register rtc device failed\n");
- ret = PTR_ERR(rtc->rtc_dev);
goto out_free_irq;
}
@@ -365,7 +369,6 @@ static int mtk_rtc_remove(struct platform_device *pdev)
{
struct mt6397_rtc *rtc = platform_get_drvdata(pdev);
- rtc_device_unregister(rtc->rtc_dev);
free_irq(rtc->irq, rtc->rtc_dev);
irq_dispose_mapping(rtc->irq);
--
2.19.0.rc2
[PATCH 3/3] rtc: pl031: switch to devm_rtc_allocate_device/rtc_register_device
Switch to devm_rtc_allocate_device to simplify the erro and driver removal
paths.
Cc: Linus Walleij
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pl031.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 82eb7da2c478..30943d200c5e 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -310,7 +310,6 @@ static int pl031_remove(struct amba_device *adev)
device_init_wakeup(&adev->dev, false);
if (adev->irq[0])
free_irq(adev->irq[0], ldata);
- rtc_device_unregister(ldata->rtc);
amba_release_regions(adev);
return 0;
@@ -383,24 +382,25 @@ static int pl031_probe(struct amba_device *adev, const
struct amba_id *id)
}
device_init_wakeup(&adev->dev, true);
- ldata->rtc = rtc_device_register("pl031", &adev->dev, ops,
- THIS_MODULE);
- if (IS_ERR(ldata->rtc)) {
- ret = PTR_ERR(ldata->rtc);
+ ldata->rtc = devm_rtc_allocate_device(&adev->dev);
+ if (IS_ERR(ldata->rtc))
+ return PTR_ERR(ldata->rtc);
+
+ ldata->rtc->ops = ops;
+
+ ret = rtc_register_device(ldata->rtc);
+ if (ret)
goto out;
- }
if (adev->irq[0]) {
ret = request_irq(adev->irq[0], pl031_interrupt,
vendor->irqflags, "rtc-pl031", ldata);
if (ret)
- goto out_no_irq;
+ goto out;
dev_pm_set_wake_irq(&adev->dev, adev->irq[0]);
}
return 0;
-out_no_irq:
- rtc_device_unregister(ldata->rtc);
out:
amba_release_regions(adev);
err_req:
--
2.19.0.rc2
Re: [PATCH v1] dd: Invoke one probe retry cycle after some initcall levels
On Mon, Aug 13, 2018 at 7:40 PM Rishabh Bhatnagar wrote:
>
> From: Rishabh Bhatnagar
>
> Drivers that are registered at an initcall level may have to
> wait until late_init before the probe deferral mechanism can
> retry their probe functions. It is possible that their
> dependencies were resolved much earlier, in some cases even
> before the next initcall level. Invoke one probe retry cycle
> at every _sync initcall level after subsys initcall, allowing
> these drivers to be probed earlier.
> To give an example many Qualcomm drivers are dependent on the
> regulator and bus driver. Both the regulator and bus driver
> are probed in the subsys_initcall level. Now the probe of bus
> driver requires regulator to be working. If the probe of bus
> driver happens before regulator, then bus driver's probe will
> be deferred and all other device's probes which depend on bus
> driver will also be deferred.
> The impact of this problem is reduced if we have this patch.
>
> Signed-off-by: Vikram Mulukutla
> Signed-off-by: Rishabh Bhatnagar
> ---
>
> Changes since v0:
> * Remove arch_initcall_sync(deferred_probe_initcall) from patch. This is not
>really needed as none of the devices are re-probed in arch_initcall_sync
>level.
>
> drivers/base/dd.c | 32 ++--
> 1 file changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 1435d72..9aa41aa 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -224,23 +224,43 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +static void enable_trigger_defer_cycle(void)
> +{
> + driver_deferred_probe_enable = true;
Isn't it sufficient to enable it once?
> + driver_deferred_probe_trigger();
> + /*
> +* Sort as many dependencies as possible before the next initcall
> +* level
> +*/
> + flush_work(&deferred_probe_work);
> +}
I would call this function driver_deferred_probe_sync() or similar to
indicate that it is a synchronization point.
Thanks,
Rafael
Re: [PATCH v6 13/14] sched/topology: Make Energy Aware Scheduling depend on schedutil
On Fri, Sep 7, 2018 at 5:29 PM Quentin Perret wrote: > > On Friday 07 Sep 2018 at 10:52:01 (+0200), Rafael J. Wysocki wrote: > > On Thursday, September 6, 2018 4:38:44 PM CEST Quentin Perret wrote: > > > Hi Rafael, > > > > > > On Thursday 06 Sep 2018 at 11:18:55 (+0200), Rafael J. Wysocki wrote: > > > > I'm not a particular fan of notifiers to be honest and you don't need > > > > to add an extra chain just in order to be able to register a callback > > > > from a single user. > > > > > > Right. I agree there are alternatives to using notifiers. I used them > > > because they're existing infrastructure, and because they let me do what > > > I want without too much troubles, which are two important points. > > > > > > > That can be achieved with a single callback > > > > pointer too, but also you could just call a function exported by the > > > > scheduler directly from where in the cpufreq code it needs to be > > > > called. > > > > > > Are you thinking about something comparable to what is done in > > > cpufreq_add_update_util_hook() (kernel/sched/cpufreq.c) for example ? > > > That would probably have the same drawback as my current implementation, > > > that is that the scheduler is notified of _all_ governor changes, not > > > only changes to/from sugov although this is the only thing we care about > > > for EAS. > > > > Well, why don't you implement it as something like "if the governor changes > > from sugov to something else (or the other way around), call this function > > from the scheduler"? > > I just gave it a try and ended up with the diff below. It's basically > the exact same patch with a direct function call instead of a notifier. > (I also tried the sugov_start/stop thing I keep mentioning but it is > more complex, so let's see if the simplest solution could work first). > > What do you think ? This generally works for me from the cpufreq perspective, but I would add "cpufreq" to the name of the new function, that is call it something like sched_cpufreq_governor_change(). Also do you really need the extra work item? Governor changes are carried out in process context anyway. Thanks, Rafael
Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO
On Fri, 31 Aug 2018, Andy Lutomirski wrote:
> (Hi, Florian!)
>
> On Fri, Aug 31, 2018 at 6:59 PM, Matt Rickard wrote:
> > Process clock_gettime(CLOCK_TAI) in vDSO.
> > This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC:
> >
> > nanoseconds
> > before after clockname
> > - -
> > 23387 CLOCK_TAI
> > 9693 CLOCK_REALTIME
> > 8887 CLOCK_MONOTONIC
>
> Are you sure you did this right? With the clocksource set to TSC
> (which is the only reasonable choice unless KVM has seriously cleaned
> up its act), with retpolines enabled, I get 24ns for CLOCK_MONOTONIC
> without your patch and 32ns with your patch. And there is indeed a
> retpoline in the disassembled output:
>
> e5: e8 07 00 00 00 callq f1 <__vdso_clock_gettime+0x31>
> ea: f3 90 pause
> ec: 0f ae e8lfence
> ef: eb f9 jmpea <__vdso_clock_gettime+0x2a>
> f1: 48 89 04 24 mov%rax,(%rsp)
> f5: c3 retq
>
> You're probably going to have to set -fno-jump-tables or do something
> clever like adding a whole array of (seconds, nsec) in gtod and
> indexing that array by the clock id.
See the patch below. It's integrating TAI without slowing down everything
and it definitely does not result in indirect calls.
On a HSW it slows down clock_gettime() by ~0.5ns. On a SKL I get a speedup
by ~0.5ns. On a AMD Epyc server it's 1.2ns speedup. So it somehow depends
on the uarch and I also observed compiler version dependend variations.
Thanks,
tglx
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -203,39 +203,18 @@ notrace static inline u64 vgetsns(int *m
return v * gtod->mult;
}
-/* Code size doesn't matter (vdso is 4k anyway) and this is faster. */
-notrace static int __always_inline do_realtime(struct timespec *ts)
+notrace static int __always_inline do_hres(struct timespec *ts, clockid_t clk)
{
- unsigned long seq;
- u64 ns;
+ struct vgtod_ts *base = >od->basetime[clk & VGTOD_HRES_MASK];
+ unsigned int seq;
int mode;
-
- do {
- seq = gtod_read_begin(gtod);
- mode = gtod->vclock_mode;
- ts->tv_sec = gtod->wall_time_sec;
- ns = gtod->wall_time_snsec;
- ns += vgetsns(&mode);
- ns >>= gtod->shift;
- } while (unlikely(gtod_read_retry(gtod, seq)));
-
- ts->tv_sec += __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
- ts->tv_nsec = ns;
-
- return mode;
-}
-
-notrace static int __always_inline do_monotonic(struct timespec *ts)
-{
- unsigned long seq;
u64 ns;
- int mode;
do {
seq = gtod_read_begin(gtod);
mode = gtod->vclock_mode;
- ts->tv_sec = gtod->monotonic_time_sec;
- ns = gtod->monotonic_time_snsec;
+ ts->tv_sec = base->sec;
+ ns = base->nsec;
ns += vgetsns(&mode);
ns >>= gtod->shift;
} while (unlikely(gtod_read_retry(gtod, seq)));
@@ -246,58 +225,50 @@ notrace static int __always_inline do_mo
return mode;
}
-notrace static void do_realtime_coarse(struct timespec *ts)
+notrace static void do_coarse(struct timespec *ts, clockid_t clk)
{
+ struct vgtod_ts *base = >od->basetime[clk];
unsigned long seq;
- do {
- seq = gtod_read_begin(gtod);
- ts->tv_sec = gtod->wall_time_coarse_sec;
- ts->tv_nsec = gtod->wall_time_coarse_nsec;
- } while (unlikely(gtod_read_retry(gtod, seq)));
-}
-notrace static void do_monotonic_coarse(struct timespec *ts)
-{
- unsigned long seq;
do {
seq = gtod_read_begin(gtod);
- ts->tv_sec = gtod->monotonic_time_coarse_sec;
- ts->tv_nsec = gtod->monotonic_time_coarse_nsec;
+ ts->tv_sec = base->sec;
+ ts->tv_nsec = base->nsec;
} while (unlikely(gtod_read_retry(gtod, seq)));
}
notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
{
- switch (clock) {
- case CLOCK_REALTIME:
- if (do_realtime(ts) == VCLOCK_NONE)
- goto fallback;
- break;
- case CLOCK_MONOTONIC:
- if (do_monotonic(ts) == VCLOCK_NONE)
- goto fallback;
- break;
- case CLOCK_REALTIME_COARSE:
- do_realtime_coarse(ts);
- break;
- case CLOCK_MONOTONIC_COARSE:
- do_monotonic_coarse(ts);
- break;
- default:
- goto fallback;
- }
+ unsigned int msk;
- return 0;
-fallback:
+ /* Sort out negative (CPU/FD) and invalid clocks */
+ if (unlikely((unsigned int) clock >= MAX_CLOCKS))
+ return vdso_fallback_gettime(clock
Re: [PATCH] cpuidle: Remove unnecessary wrapper cpuidle_get_last_residency()
On Fri, Sep 7, 2018 at 10:09 PM Fieah Lim wrote:
>
> There's no magic inside, let's just make it more intuitive.
Again, please fix the changelog. It is not useful as is.
> Signed-off-by: Fieah Lim
> ---
> drivers/cpuidle/governors/ladder.c | 2 +-
> drivers/cpuidle/governors/menu.c | 2 +-
> include/linux/cpuidle.h| 10 --
> 3 files changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/cpuidle/governors/ladder.c
> b/drivers/cpuidle/governors/ladder.c
> index 704880a6612a..f0dddc66af26 100644
> --- a/drivers/cpuidle/governors/ladder.c
> +++ b/drivers/cpuidle/governors/ladder.c
> @@ -80,7 +80,7 @@ static int ladder_select_state(struct cpuidle_driver *drv,
>
> last_state = &ldev->states[last_idx];
>
> - last_residency = cpuidle_get_last_residency(dev) -
> drv->states[last_idx].exit_latency;
> + last_residency = dev->last_residency -
> drv->states[last_idx].exit_latency;
>
> /* consider promotion */
> if (last_idx < drv->state_count - 1 &&
> diff --git a/drivers/cpuidle/governors/menu.c
> b/drivers/cpuidle/governors/menu.c
> index 1aef60d160eb..715520e339da 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -492,7 +492,7 @@ static void menu_update(struct cpuidle_driver *drv,
> struct cpuidle_device *dev)
> measured_us = 9 * MAX_INTERESTING / 10;
> } else {
> /* measured value */
> - measured_us = cpuidle_get_last_residency(dev);
> + measured_us = dev->last_residency;
>
> /* Deduct exit latency */
> if (measured_us > 2 * target->exit_latency)
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 4325d6fdde9b..d262f620890e 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -99,16 +99,6 @@ struct cpuidle_device {
> DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
> DECLARE_PER_CPU(struct cpuidle_device, cpuidle_dev);
>
> -/**
> - * cpuidle_get_last_residency - retrieves the last state's residency time
> - * @dev: the target CPU
> - */
> -static inline int cpuidle_get_last_residency(struct cpuidle_device *dev)
> -{
> - return dev->last_residency;
> -}
> -
> -
> /
> * CPUIDLE DRIVER INTERFACE *
> /
> --
> 2.18.0
>
Re: [PATCH] cpuidle: enter_state: Don't needlessly calculate diff time
On Fri, Sep 7, 2018 at 8:55 PM Fieah Lim wrote:
>
> ktime_us_delta() is not that cheap on some platform,
> and I think this is also the right thing to do.
> While at it, fix some coding style as well.
>
> Signed-off-by: Fieah Lim
> ---
> drivers/cpuidle/cpuidle.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 6df894d65d9e..5f6b2c9b6555 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -247,21 +247,20 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> if (!cpuidle_state_is_coupled(drv, index))
> local_irq_enable();
>
> - diff = ktime_us_delta(time_end, time_start);
> - if (diff > INT_MAX)
> - diff = INT_MAX;
> -
> - dev->last_residency = (int) diff;
> + dev->last_residency = 0;
>
> if (entered_state >= 0) {
> - /* Update cpuidle counters */
> - /* This can be moved to within driver enter routine
> + /* Update cpuidle counters
> +* This can be moved to within driver enter routine,
> * but that results in multiple copies of same code.
> */
> + diff = ktime_us_delta(time_end, time_start);
> + if (diff > INT_MAX)
> + diff = INT_MAX;
> +
> + dev->last_residency = (int)diff;
> dev->states_usage[entered_state].time += dev->last_residency;
> dev->states_usage[entered_state].usage++;
> - } else {
> - dev->last_residency = 0;
Besides, what's wrong with this branch?
> }
>
> return entered_state;
> --
> 2.18.0
>
Re: [PATCH] cpuidle: enter_state: Don't needlessly calculate diff time
On Fri, Sep 7, 2018 at 8:55 PM Fieah Lim wrote:
>
> ktime_us_delta() is not that cheap on some platform,
> and I think this is also the right thing to do.
> While at it, fix some coding style as well.
>
> Signed-off-by: Fieah Lim
Fix your changelog at least to say that you optimize the code without
changing its functionality.
> ---
> drivers/cpuidle/cpuidle.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 6df894d65d9e..5f6b2c9b6555 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -247,21 +247,20 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> if (!cpuidle_state_is_coupled(drv, index))
> local_irq_enable();
>
> - diff = ktime_us_delta(time_end, time_start);
> - if (diff > INT_MAX)
> - diff = INT_MAX;
> -
> - dev->last_residency = (int) diff;
> + dev->last_residency = 0;
>
> if (entered_state >= 0) {
> - /* Update cpuidle counters */
> - /* This can be moved to within driver enter routine
> + /* Update cpuidle counters
> +* This can be moved to within driver enter routine,
> * but that results in multiple copies of same code.
> */
> + diff = ktime_us_delta(time_end, time_start);
> + if (diff > INT_MAX)
> + diff = INT_MAX;
> +
> + dev->last_residency = (int)diff;
> dev->states_usage[entered_state].time += dev->last_residency;
> dev->states_usage[entered_state].usage++;
> - } else {
> - dev->last_residency = 0;
> }
>
> return entered_state;
> --
> 2.18.0
>
Re: [GIT PULL 00/13] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 66e5db4a1ccc64f278653bc69dc406d184dc750a:
>
> Merge tag 'perf-core-for-mingo-4.19-20180820' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
> (2018-08-23 10:29:19 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-urgent-for-mingo-4.19-20180903
>
> for you to fetch changes up to 4e67b2a5df5d3f341776d12ee575e00ca3ef92de:
>
> perf annotate: Fix parsing aarch64 branch instructions after objdump update
> (2018-08-30 15:51:54 -0300)
>
>
> perf/urgent fixes:
>
> Kernel:
>
> - Modify breakpoint fixes (Jiri Olsa)
>
> perf annotate:
>
> - Fix parsing aarch64 branch instructions after objdump update (Kim Phillips)
>
> - Fix parsing indirect calls in 'perf annotate' (Martin Liška)
>
> perf probe:
>
> - Ignore SyS symbols irrespective of endianness on PowerPC (Sandipan Das)
>
> perf trace:
>
> - Fix include path for asm-generic/unistd.h on arm64 (Kim Phillips)
>
> Core libraries:
>
> - Fix potential null pointer dereference in perf_evsel__new_idx() (Hisao
> Tanabe)
>
> - Use fixed size string for comms instead of scanf("%m"), that is
> not present in the bionic libc and leads to a crash (Chris Phlipot)
>
> - Fix bad memory access in trace info on 32-bit systems, we were reading
> 8 bytes from a 4-byte long variable when saving the command line in the
> perf.data file. (Chris Phlipot)
>
> Build system:
>
> - Streamline bpf examples and headers installation, clarifying
> some install messages. (Arnaldo Carvalho de Melo)
>
> Signed-off-by: Arnaldo Carvalho de Melo
>
>
> Arnaldo Carvalho de Melo (1):
> perf tools: Streamline bpf examples and headers installation
>
> Chris Phlipot (2):
> perf util: Fix bad memory access in trace info.
> perf event-parse: Use fixed size string for comms
>
> Hisao Tanabe (1):
> perf evsel: Fix potential null pointer dereference in
> perf_evsel__new_idx()
>
> Jiri Olsa (5):
> perf tests: Add breakpoint modify tests
> perf/hw_breakpoint: Modify breakpoint even if the new attr has disabled
> set
> perf/hw_breakpoint: Remove superfluous bp->attr.disabled = 0
> perf/hw_breakpoint: Enable breakpoint in modify_user_hw_breakpoint
> perf/hw_breakpoint: Simplify breakpoint enable in
> perf_event_modify_breakpoint
>
> Kim Phillips (2):
> perf arm64: Fix include path for asm-generic/unistd.h
> perf annotate: Fix parsing aarch64 branch instructions after objdump
> update
>
> Martin Liška (1):
> perf annotate: Properly interpret indirect call
>
> Sandipan Das (1):
> perf probe powerpc: Ignore SyS symbols irrespective of endianness
>
> kernel/events/core.c | 11 +-
> kernel/events/hw_breakpoint.c | 13 +-
> tools/perf/Makefile.perf | 14 +-
> tools/perf/arch/arm64/Makefile| 5 +-
> tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 6 +-
> tools/perf/arch/powerpc/util/sym-handling.c | 4 +-
> tools/perf/arch/x86/include/arch-tests.h | 1 +
> tools/perf/arch/x86/tests/Build | 1 +
> tools/perf/arch/x86/tests/arch-tests.c| 6 +
> tools/perf/arch/x86/tests/bp-modify.c | 213
> ++
> tools/perf/util/annotate.c| 32 +++-
> tools/perf/util/annotate.h| 1 +
> tools/perf/util/evsel.c | 5 +-
> tools/perf/util/trace-event-info.c| 2 +-
> tools/perf/util/trace-event-parse.c | 7 +-
> 15 files changed, 282 insertions(+), 39 deletions(-)
> create mode 100644 tools/perf/arch/x86/tests/bp-modify.c
Pulled into tip:perf/urgent, thanks a lot Arnaldo!
Ingo
Contact me for more details
Hello, I am Mr. Emeka Ezela, the head of International remittance Department, United Bank for Africa (UBA) I have a business deal i would like to propose to you. If you are interested to know more, kindly contact me on my private emails (emekaez...@mail.com) for more details. Regards, Mr. Emeka Ezela
Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Hi Olof, On Sat, Sep 8, 2018 at 6:18 PM, Olof Johansson wrote: > Hi, > > On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote: >> From: Rajan Vaja >> >> Add ZynqMP firmware IOCTL API to control and configure >> devices like PLLs, SD, Gem, etc. >> >> Signed-off-by: Rajan Vaja >> Signed-off-by: Jolly Shah > > This patch worries me somewhat. It's a transparent pass-through ioctl > driver. Is there a spec available for what the implemented IOCTLs are? > > Should some of them be proper drivers instead of an opaque > pass-through like this? Could some of them have stability impact on > the platform such that there are security concerns and the list of > arguments should somehow be sanitized? I tend to agree with this, good catch. > What's the intended usecase anyway? Just a debug tool during > development, or something that you expect heavy use of by some > userspace middleware? I suspect it is another attempt to make userspace clocks/plls work? Scary. Cheers, Moritz
Re: possible deadlock in free_ioctx_users
I would be inclined to blame FUSE for this problem.
On Sun, Sep 09, 2018 at 11:41:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:f8f65382c98a Merge tag 'for-linus' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=113260ae40
> kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
> dashboard link: https://syzkaller.appspot.com/bug?extid=d86c4426a01f60feddc7
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=120baa9e40
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13979cbe40
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d86c4426a01f60fed...@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
>
>
> WARNING: possible irq lock inversion dependency detected
> 4.19.0-rc2+ #229 Not tainted
>
> swapper/0/0 just changed the state of lock:
> c02bddef (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq
> include/linux/spinlock.h:354 [inline]
> c02bddef (&(&ctx->ctx_lock)->rlock){..-.}, at:
> free_ioctx_users+0xbc/0x710 fs/aio.c:603
> but this lock took another, SOFTIRQ-unsafe lock in the past:
> (&fiq->waitq){+.+.}
>
>
> and interrupts could create inverse lock ordering between them.
>
>
> other info that might help us debug this:
> Possible interrupt unsafe locking scenario:
>
>CPU0CPU1
>
> lock(&fiq->waitq);
>local_irq_disable();
>lock(&(&ctx->ctx_lock)->rlock);
>lock(&fiq->waitq);
>
> lock(&(&ctx->ctx_lock)->rlock);
>
> *** DEADLOCK ***
>
> 2 locks held by swapper/0/0:
> #0: 77c9a56b (rcu_callback){}, at: __rcu_reclaim
> kernel/rcu/rcu.h:226 [inline]
> #0: 77c9a56b (rcu_callback){}, at: rcu_do_batch
> kernel/rcu/tree.c:2576 [inline]
> #0: 77c9a56b (rcu_callback){}, at: invoke_rcu_callbacks
> kernel/rcu/tree.c:2880 [inline]
> #0: 77c9a56b (rcu_callback){}, at: __rcu_process_callbacks
> kernel/rcu/tree.c:2847 [inline]
> #0: 77c9a56b (rcu_callback){}, at:
> rcu_process_callbacks+0x1012/0x2670 kernel/rcu/tree.c:2864
> #1: 31dcf310 (rcu_read_lock_sched){}, at:
> percpu_ref_call_confirm_rcu lib/percpu-refcount.c:119 [inline]
> #1: 31dcf310 (rcu_read_lock_sched){}, at:
> percpu_ref_switch_to_atomic_rcu+0x2b7/0x820 lib/percpu-refcount.c:158
>
> the shortest dependencies between 2nd lock and 1st lock:
> -> (&fiq->waitq){+.+.} ops: 4 {
> HARDIRQ-ON-W at:
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3901
> __raw_spin_lock include/linux/spinlock_api_smp.h:142
> [inline]
> _raw_spin_lock+0x2d/0x40 kernel/locking/spinlock.c:144
> spin_lock include/linux/spinlock.h:329 [inline]
> flush_bg_queue+0x389/0x650 fs/fuse/dev.c:364
> fuse_request_send_background_locked+0x2f5/0x5a0
> fs/fuse/dev.c:598
> fuse_request_send_background+0x135/0x180
> fs/fuse/dev.c:606
> cuse_send_init fs/fuse/cuse.c:458 [inline]
> cuse_channel_open+0x6b0/0x963 fs/fuse/cuse.c:518
> misc_open+0x3ca/0x560 drivers/char/misc.c:141
> chrdev_open+0x25a/0x710 fs/char_dev.c:417
> do_dentry_open+0x499/0x1250 fs/open.c:771
> vfs_open+0xa0/0xd0 fs/open.c:880
> do_last fs/namei.c:3418 [inline]
> path_openat+0x12bf/0x5160 fs/namei.c:3534
> do_filp_open+0x255/0x380 fs/namei.c:3564
> do_sys_open+0x568/0x700 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+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> SOFTIRQ-ON-W at:
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3901
> __raw_spin_lock include/linux/spinlock_api_smp.h:142
> [inline]
> _raw_spin_lock+0x2d/0x40 kernel/locking/spinlock.c:144
> spin_lock include/linux/spinlock.h:329 [inline]
> flush_bg_queue+0x389/0x650 fs/fuse/dev.c:364
>
Re: [PATCH] Input: wm97xx: only unregister wm97xx_driver if it has been registered
Charles Keepax writes:
> On Tue, Sep 04, 2018 at 07:35:05PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> In the case where IS_BUILTIN(CONFIG_AC97_BUS)) is not true, the
>> wm97xx_driver driver is being unregistered even it has not been
>> previously registered. Fix this by only unregistering it if
>> IS_BUILTIN(CONFIG_AC97_BUS)) is true. This fixes the warning
>> message:
>>
>> [ 834.111248] [ cut here ]
>> [ 834.111248] Unexpected driver unregister!
>> [ 834.111319] WARNING: CPU: 2 PID: 11749 at drivers/base/driver.c:193
>> driver_unregister+0x3b/0x40
>> [ 834.111319] Modules linked in: wm97xx_ts(-)
>>
>> ..and a stack trace.
>>
>> To easily reproduce this, load and unload the module on a system where
>> the hardware is not supported.
>>
>> Fixes: ae9d1b5fbd7b ("Input: wm97xx: add new AC97 bus support")
>> Signed-off-by: Colin Ian King
>> ---
>
> Acked-by: Charles Keepax
Acked-by: Robert Jarzmik
Cheers.
--
Robert
Re: [PATCH] radix-tree: optimization for radix_tree_init_maxnodes
On Sun, Sep 09, 2018 at 09:21:00PM +0800, Wang Long wrote: > if i == 0, height_to_maxnodes[i] = 0, > if i >= 1, height_to_maxnodes[i] = height_to_maxnodes[i-1] > + __maxindex(i-1) + 1. > > so delete height_to_maxindex and optimize the calculation of > height_to_maxnodes array. Thanks for your patch. Unfortunately, this entire function is scheduled for deletion, so I won't be applying it. If you're interested in the radix tree, I'd recommend looking at its replacement, the XArray. The current version is at http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray but I'll be pushing another version out in the next few days.
Re: [PATCH v4 09/16] sched/core: uclamp: map TG's clamp values into CPU's clamp groups
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> Utilization clamping requires to map each different clamp value
> into one of the available clamp groups used by the scheduler's fast-path
> to account for RUNNABLE tasks. Thus, each time a TG's clamp value
> sysfs attribute is updated via:
>cpu_util_{min,max}_write_u64()
> we need to get (if possible) a reference to the new value's clamp group
> and release the reference to the previous one.
>
> Let's ensure that, whenever a task group is assigned a specific
> clamp_value, this is properly translated into a unique clamp group to be
> used in the fast-path (i.e. at enqueue/dequeue time).
> We do that by slightly refactoring uclamp_group_get() to make the
> *task_struct parameter optional. This allows to re-use the code already
> available to support the per-task API.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> Cc: Suren Baghdasaryan
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Juri Lelli
> Cc: Quentin Perret
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
>
> ---
> Changes in v4:
> Others:
> - rebased on v4.19-rc1
>
> Changes in v3:
> Message-ID:
>
> - add explicit calls to uclamp_group_find(), which is now not more
>part of uclamp_group_get()
> Others:
> - rebased on tip/sched/core
> Changes in v2:
> - rebased on v4.18-rc4
> - this code has been split from a previous patch to simplify the review
> ---
> include/linux/sched.h | 11 +++--
> kernel/sched/core.c | 95 +++
> 2 files changed, 95 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 2da130d17e70..4e5522ed57e0 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -587,17 +587,22 @@ struct sched_dl_entity {
> * The same "group_id" can be used by multiple scheduling entities, i.e.
> * either tasks or task groups, to enforce the same clamp "value" for a given
> * clamp index.
> + *
> + * Scheduling entity's specific clamp group index can be different
> + * from the effective clamp group index used at enqueue time since
> + * task groups's clamps can be restricted by their parent task group.
> */
> struct uclamp_se {
> unsigned int value;
> unsigned int group_id;
> /*
> -* Effective task (group) clamp value.
> -* For task groups is the value (eventually) enforced by a parent task
> -* group.
> +* Effective task (group) clamp value and group index.
> +* For task groups it's the value (eventually) enforced by a parent
> +* task group.
> */
> struct {
> unsigned int value;
> + unsigned int group_id;
> } effective;
> };
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b2d438b6484b..e617a7b18f2d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1250,24 +1250,51 @@ static inline int alloc_uclamp_sched_group(struct
> task_group *tg,
>struct task_group *parent)
> {
> struct uclamp_se *uc_se;
> + int next_group_id;
> int clamp_id;
>
> for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) {
> uc_se = &tg->uclamp[clamp_id];
> +
> uc_se->effective.value =
> parent->uclamp[clamp_id].effective.value;
> - uc_se->value = parent->uclamp[clamp_id].value;
> - uc_se->group_id = parent->uclamp[clamp_id].group_id;
> + uc_se->effective.group_id =
> + parent->uclamp[clamp_id].effective.group_id;
> +
> + next_group_id = parent->uclamp[clamp_id].group_id;
> + uc_se->group_id = UCLAMP_NOT_VALID;
> + uclamp_group_get(NULL, clamp_id, next_group_id, uc_se,
> +parent->uclamp[clamp_id].value);
> }
>
> return 1;
> }
> +
> +/**
> + * release_uclamp_sched_group: release utilization clamp references of a TG
free_uclamp_sched_group
> + * @tg: the task group being removed
> + *
> + * An empty task group can be removed only when it has no more tasks or child
> + * groups. This means that we can also safely release all the reference
> + * counting to clamp groups.
> + */
> +static inline void free_uclamp_sched_group(struct task_group *tg)
> +{
> + struct uclamp_se *uc_se;
> + int clamp_id;
> +
> + for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) {
> + uc_se = &tg->uclamp[clamp_id];
> + uclamp_group_put(clamp_id, uc_se->group_id);
> + }
> +}
> #else /* CONFIG_UCLAMP_TASK_GROUP */
> static inline int alloc_uclamp_sched_group(struct task_group *tg,
>struct task_group *parent)
> {
> r
