INFO: task hung in __x64_sys_io_destroy
Hello,
syzbot found the following crash on:
HEAD commit:d2ff0ff2c23f Merge tag 'armsoc-fixes' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=124fc13340
kernel config: https://syzkaller.appspot.com/x/.config?x=9384ecb1c973baed
dashboard link: https://syzkaller.appspot.com/bug?extid=2eb72911e1b5139da5e2
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2eb72911e1b5139da...@syzkaller.appspotmail.com
overlayfs: filesystem on './file0' not supported as upperdir
INFO: task syz-executor3:24161 blocked for more than 140 seconds.
Not tainted 4.19.0+ #96
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor3 D18616 24161 22624 0x
Call Trace:
context_switch kernel/sched/core.c:2831 [inline]
__schedule+0x8cf/0x21d0 kernel/sched/core.c:3472
schedule+0xfe/0x460 kernel/sched/core.c:3516
schedule_timeout+0x1cc/0x260 kernel/time/timer.c:1780
do_wait_for_common kernel/sched/completion.c:83 [inline]
__wait_for_common kernel/sched/completion.c:104 [inline]
wait_for_common kernel/sched/completion.c:115 [inline]
wait_for_completion+0x427/0x8a0 kernel/sched/completion.c:136
__do_sys_io_destroy fs/aio.c:1376 [inline]
__se_sys_io_destroy fs/aio.c:1354 [inline]
__x64_sys_io_destroy+0x495/0x580 fs/aio.c:1354
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: Bad RIP value.
RSP: 002b:7f8cc0ff0c78 EFLAGS: 0246 ORIG_RAX: 00cf
RAX: ffda RBX: 0001 RCX: 00457569
RDX: RSI: RDI: 7f8cc0fd
RBP: 0072bf00 R08: R09:
R10: R11: 0246 R12: 7f8cc0ff16d4
R13: 004be6fe R14: 004ce5a0 R15:
Showing all locks held in the system:
1 lock held by khungtaskd/1008:
#0: 5c912532 (rcu_read_lock){}, at:
debug_show_all_locks+0xd0/0x424 kernel/locking/lockdep.c:4379
2 locks held by rsyslogd/5596:
#0: 83898e10 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x1bb/0x200
fs/file.c:766
#1: c175b53b (&rq->lock){-.-.}, at: rq_lock
kernel/sched/sched.h:1126 [inline]
#1: c175b53b (&rq->lock){-.-.}, at: __schedule+0x236/0x21d0
kernel/sched/core.c:3410
2 locks held by getty/5686:
#0: 5c9a0b0b (&tty->ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 9740bc82 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/5687:
#0: 6d18a19c (&tty->ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: cecadd40 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/5688:
#0: 742bdf36 (&tty->ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 46d0d657 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/5689:
#0: 93d6282e (&tty->ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: ce5627fc (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/5690:
#0: 0f40a3d3 (&tty->ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 9d7531af (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/5691:
#0: 8658f0ae (&tty->ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: bb83ce86 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/5692:
#0: 48965eed (&tty->ldisc_sem){}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 09c97b8b (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by kworker/0:2/5844:
#0: 8d501078 ((wq_completion)"rcu_gp"){+.+.}, at:
__write_once_size include/linux/compiler.h:209 [inline]
#0: 8d501078 ((wq_completion)"rcu_gp"){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 8d501078 ((wq_completion)"rcu_gp"){+.+.}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 8d501078 ((wq_completion)"rcu_gp"){+.+.}, at: atomic_long_set
include/asm-generic/atomic-long.h:59 [inline]
#0: 8d501078 ((wq_completion)"rcu_gp"){+.+.}, at: set_work_data
kernel/workqueue.c:617 [inline]
#0: 8d501078 ((wq_completion)"rcu_gp"){+.+.}, at:
set_work_pool_and_clear_pending kernel/work
INFO: task hung in unregister_netdevice_notifier (3)
Hello, syzbot found the following crash on: HEAD commit:aa0c38cf39de Merge branch 'fixes' of git://git.kernel.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=105302a740 kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1 dashboard link: https://syzkaller.appspot.com/bug?extid=0f1827363a305f74996f compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+0f1827363a305f749...@syzkaller.appspotmail.com INFO: task syz-executor.1:32467 blocked for more than 140 seconds. Not tainted 5.0.0-rc6+ #69 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor.1 D28224 32467 30279 0x0004 Call Trace: context_switch kernel/sched/core.c:2844 [inline] __schedule+0x817/0x1cc0 kernel/sched/core.c:3485 schedule+0x92/0x180 kernel/sched/core.c:3529 __rwsem_down_write_failed_common kernel/locking/rwsem-xadd.c:584 [inline] rwsem_down_write_failed+0x774/0xc30 kernel/locking/rwsem-xadd.c:613 call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117 __down_write arch/x86/include/asm/rwsem.h:142 [inline] down_write+0x53/0x90 kernel/locking/rwsem.c:72 unregister_netdevice_notifier+0x7e/0x3a0 net/core/dev.c:1703 raw_release+0x57/0x6f0 net/can/raw.c:358 __sock_release+0xd3/0x250 net/socket.c:579 sock_close+0x1b/0x30 net/socket.c:1139 __fput+0x2df/0x8d0 fs/file_table.c:278 fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x411d41 Code: 00 00 8b b3 30 01 00 00 31 c0 bf d0 36 44 00 e8 05 f3 00 00 8b b3 08 01 00 00 31 c0 bf e4 36 44 00 e8 f3 f2 00 00 8b 83 e0 00 <00> 00 48 89 ee bf f9 36 44 00 85 c0 49 0f 44 f4 31 c0 e8 d8 f2 00 RSP: 002b:7ffc0aec9520 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0005 RCX: 00411d41 RDX: RSI: RDI: 0004 RBP: R08: 8100a073 R09: 21576e54 R10: 7ffc0aec9450 R11: 0293 R12: R13: 0001 R14: 0072 R15: 0001 INFO: task syz-executor.5:32470 blocked for more than 140 seconds. Not tainted 5.0.0-rc6+ #69 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor.5 D28224 32470 7467 0x0004 Call Trace: context_switch kernel/sched/core.c:2844 [inline] __schedule+0x817/0x1cc0 kernel/sched/core.c:3485 schedule+0x92/0x180 kernel/sched/core.c:3529 __rwsem_down_write_failed_common kernel/locking/rwsem-xadd.c:584 [inline] rwsem_down_write_failed+0x774/0xc30 kernel/locking/rwsem-xadd.c:613 call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117 __down_write arch/x86/include/asm/rwsem.h:142 [inline] down_write+0x53/0x90 kernel/locking/rwsem.c:72 unregister_netdevice_notifier+0x7e/0x3a0 net/core/dev.c:1703 raw_release+0x57/0x6f0 net/can/raw.c:358 __sock_release+0xd3/0x250 net/socket.c:579 sock_close+0x1b/0x30 net/socket.c:1139 __fput+0x2df/0x8d0 fs/file_table.c:278 fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x411d41 Code: 00 00 8b b3 30 01 00 00 31 c0 bf d0 36 44 00 e8 05 f3 00 00 8b b3 08 01 00 00 31 c0 bf e4 36 44 00 e8 f3 f2 00 00 8b 83 e0 00 <00> 00 48 89 ee bf f9 36 44 00 85 c0 49 0f 44 f4 31 c0 e8 d8 f2 00 RSP: 002b:7ffe4f2857d0 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0008 RCX: 00411d41 RDX: RSI: 00741140 RDI: 0007 RBP: R08: 8175450f R09: 21576e54 R10: 7ffe4f285700 R11: 0293 R12: R13: 0001 R14: 1504 R15: 0005 INFO: task syz-executor.0:32475 blocked for more than 140 seconds. Not tainted 5.0.0-rc6+ #69 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor.0 D28224 32475 25857 0x0004 Call Trace: context_switch kernel/sched/core.c:2844 [inline] __schedule+0x817/0x1cc0 kernel/sched/core.c:3485 schedule+0x92/0x180 kernel/sched/core.c:3529 __rwsem_down_
[GIT PULL] Please pull powerpc/linux.git powerpc-5.0-5 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Linus, Please pull one more powerpc fix for 5.0: The following changes since commit 5a3840a470c41ec0b85cd36ca80370330656b163: powerpc/papr_scm: Use the correct bind address (2019-02-01 10:13:51 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.0-5 for you to fetch changes up to a58007621be33e9f7c7bed5d5ff8ecb914e1044a: powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present() (2019-02-17 15:24:45 +1100) - -- powerpc fixes for 5.0 #5 Just one fix, for pgd/pud_present() which were broken on big endian since v4.20, leading to possible data corruption. Thanks to: Aneesh Kumar K.V., Erhard F., Jan Kara. - -- Michael Ellerman (1): powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present() arch/powerpc/include/asm/book3s/64/pgtable.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJcaRiIAAoJEFHr6jzI4aWA6rYQAKQQGiQAWrbGlP65hMGjx++c 6YTsHnR88NpvWc0hGp9Pa8w/JCHBVWY1rlkrm/WfmerGb9y2vHR7HrwMVwA3Sw4Y tTzYO4zUPtRghdcSQhLLKmkfxFtX6w/ZrLcBDwcQkhUhNKGxEptgIaJZFwJmdpfv 2eAbq+inaNwDK5IVjANOxniwUmRYCcj5HhmnBiK46zrQ5q6S/0Z77CvZri4OxrlX ywyH9RjqTTqqfUe0abAt3C0/7SKjzjZeHOOGHeGb314+70zCYfT781IlCaII6d3J sOP4WnXGXX4pKVuDqu6BzaRf/sJBppiyHe4+iWE4FGKFUT1AUU18wausYmIeJcE/ P4FzEMWk9dOJEOJ4/XKbvrpWmpOiUl9w1jY/PVNh1QWyrzk1NVr+jhhNTjgvX6lj 9SVrYuhl57Ops5nqv3b6we+WbnG9Irfy+LqopJUePyUrdq/OljrRGp21WiLF1GYI fzYszqvv8+iES+F4sgocpgf0nt2M3YSu+f5HdHJ8Q2RwbeScZz24IVSV7N4/ko3e aGG8PL8dhddu5jFxOWEKWesv5w4RaxPpnMqz+VolDoP21+p6nZvx2QsxtVwk0V/R WXMV7iEMZpjJK+KvKN1dKDKVX+sf5XcMa2fbCZ2LiXEnj5esF3EL2YABuSUOapm3 i04uXRAf2lxI5mEXPxK7 =PcTT -END PGP SIGNATURE-
Re: powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
On Thu, 2019-02-14 at 06:23:39 UTC, Michael Ellerman wrote:
> In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
> rather than just checking that the value is non-zero, e.g.:
>
> static inline int pgd_present(pgd_t pgd)
> {
> - return !pgd_none(pgd);
> + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
> }
>
> Unfortunately this is broken on big endian, as the result of the
> bitwise && is truncated to int, which is always zero because
> _PAGE_PRESENT is 0x8000ul. This means pgd_present() and
> pud_present() are always false at compile time, and the compiler
> elides the subsequent code.
>
> Remarkably with that bug present we are still able to boot and run
> with few noticeable effects. However under some work loads we are able
> to trigger a warning in the ext4 code:
>
> WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927
> .ext4_set_page_dirty+0x70/0xb0
> CPU: 11 PID: 29593 Comm: debugedit Not tainted 4.20.0-rc1 #1
> ...
> NIP .ext4_set_page_dirty+0x70/0xb0
> LR .set_page_dirty+0xa0/0x150
> Call Trace:
>.set_page_dirty+0xa0/0x150
>.unmap_page_range+0xbf0/0xe10
>.unmap_vmas+0x84/0x130
>.unmap_region+0xe8/0x190
>.__do_munmap+0x2f0/0x510
>.__vm_munmap+0x80/0x110
>.__se_sys_munmap+0x14/0x30
>system_call+0x5c/0x70
>
> The fix is simple, we need to convert the result of the bitwise && to
> an int before returning it.
>
> Thanks to Jan Kara and Aneesh for help with debugging.
>
> Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at
> _PAGE_PRESENT bit")
> Cc: sta...@vger.kernel.org # v4.20+
> Reported-by: Erhard F.
> Reviewed-by: Aneesh Kumar K.V
> Signed-off-by: Michael Ellerman
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/a58007621be33e9f7c7bed5d5ff8ecb9
cheers
Re: [PATCH] firmware: hardcode the debug message for -ENOENT
On 2019-02-05 07:30 AM, Luis Chamberlain wrote:
On Mon, Jan 14, 2019 at 05:58:30PM +0800, yuank...@codeaurora.org
wrote:
Hi,
Refined at below.
From bbd0d9c8f28eb78ca34353347c3d4092e88f000c Mon Sep 17 00:00:00 2001
This is all garbled, not sure why your patch looks all messed up.
Are you using git sendemail or something manual?
Luis
Done. Update it with resend it as below.
From: John Zhao
When the return code of "-ENOENT" was printed inside
of the debug message, which could be hardcoded meaningful.
Signed-off-by: John Zhao
---
drivers/base/firmware_loader/main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index 8e9213b..7eaaf5e 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -328,12 +328,12 @@ fw_get_filesystem_firmware(struct device *device,
struct fw_priv *fw_priv)
rc = kernel_read_file_from_path(path, &fw_priv->data, &size,
msize, id);
if (rc) {
- if (rc == -ENOENT)
- dev_dbg(device, "loading %s failed with error
%d\n",
-path, rc);
- else
+ if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error
%d\n",
path, rc);
+ else
+dev_dbg(device, "loading %s failed for no such file or
directory.\n",
+path);
continue;
}
dev_dbg(device, "direct-loading %s\n", fw_priv->fw_name);
--
2.7.4
Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
Andreas Schwab writes: > On Feb 14 2019, Michael Ellerman wrote: > >> The fix is simple, we need to convert the result of the bitwise && to >> an int before returning it. > > Alternatively, the return type could be changed to bool, so that the > compiler does the right thing by itself. Yes that would be preferable. All other architectures return an int so I wasn't game to switch to bool for a fix. But I don't see why it should matter so I'll do a patch using bool for next. cheers
Re: [PATCH] sparc64: simplify reduce_memory() function
Any comments on this?
On Tue, Feb 12, 2019 at 11:32:36AM +0200, Mike Rapoport wrote:
> The reduce_memory() function clampls the available memory to a limit
> defined by the "mem=" command line parameter. It takes into account the
> amount of already reserved memory and excludes it from the limit
> calculations.
>
> Rather than traverse memblocks and remove them by hand, use
> memblock_reserved_size() to account the reserved memory and
> memblock_enforce_memory_limit() to clamp the available memory.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/sparc/mm/init_64.c | 42 ++
> 1 file changed, 2 insertions(+), 40 deletions(-)
>
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index b4221d3..478b818 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -2261,19 +2261,6 @@ static unsigned long last_valid_pfn;
> static void sun4u_pgprot_init(void);
> static void sun4v_pgprot_init(void);
>
> -static phys_addr_t __init available_memory(void)
> -{
> - phys_addr_t available = 0ULL;
> - phys_addr_t pa_start, pa_end;
> - u64 i;
> -
> - for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, &pa_start,
> - &pa_end, NULL)
> - available = available + (pa_end - pa_start);
> -
> - return available;
> -}
> -
> #define _PAGE_CACHE_4U (_PAGE_CP_4U | _PAGE_CV_4U)
> #define _PAGE_CACHE_4V (_PAGE_CP_4V | _PAGE_CV_4V)
> #define __DIRTY_BITS_4U (_PAGE_MODIFIED_4U | _PAGE_WRITE_4U |
> _PAGE_W_4U)
> @@ -2287,33 +2274,8 @@ static phys_addr_t __init available_memory(void)
> */
> static void __init reduce_memory(phys_addr_t limit_ram)
> {
> - phys_addr_t avail_ram = available_memory();
> - phys_addr_t pa_start, pa_end;
> - u64 i;
> -
> - if (limit_ram >= avail_ram)
> - return;
> -
> - for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, &pa_start,
> - &pa_end, NULL) {
> - phys_addr_t region_size = pa_end - pa_start;
> - phys_addr_t clip_start = pa_start;
> -
> - avail_ram = avail_ram - region_size;
> - /* Are we consuming too much? */
> - if (avail_ram < limit_ram) {
> - phys_addr_t give_back = limit_ram - avail_ram;
> -
> - region_size = region_size - give_back;
> - clip_start = clip_start + give_back;
> - }
> -
> - memblock_remove(clip_start, region_size);
> -
> - if (avail_ram <= limit_ram)
> - break;
> - i = 0UL;
> - }
> + limit_ram += memblock_reserved_size();
> + memblock_enforce_memory_limit(limit_ram);
> }
>
> void __init paging_init(void)
> --
> 2.7.4
>
--
Sincerely yours,
Mike.
Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
Segher Boessenkool writes:
> Hi all,
>
> On Sat, Feb 16, 2019 at 09:55:11PM +1100, Balbir Singh wrote:
>> On Thu, Feb 14, 2019 at 05:23:39PM +1100, Michael Ellerman wrote:
>> > In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
>> > rather than just checking that the value is non-zero, e.g.:
>> >
>> > static inline int pgd_present(pgd_t pgd)
>> > {
>> > - return !pgd_none(pgd);
>> > + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
>> > }
>> >
>> > Unfortunately this is broken on big endian, as the result of the
>> > bitwise && is truncated to int, which is always zero because
>
> (Bitwise "&" of course).
Thanks, I fixed that up.
cheers
Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
Balbir Singh writes:
> On Sat, Feb 16, 2019 at 08:22:12AM -0600, Segher Boessenkool wrote:
>> Hi all,
>>
>> On Sat, Feb 16, 2019 at 09:55:11PM +1100, Balbir Singh wrote:
>> > On Thu, Feb 14, 2019 at 05:23:39PM +1100, Michael Ellerman wrote:
>> > > In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
>> > > rather than just checking that the value is non-zero, e.g.:
>> > >
>> > > static inline int pgd_present(pgd_t pgd)
>> > > {
>> > > - return !pgd_none(pgd);
>> > > + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
>> > > }
>> > >
>> > > Unfortunately this is broken on big endian, as the result of the
>> > > bitwise && is truncated to int, which is always zero because
>>
>> (Bitwise "&" of course).
>>
>> > Not sure why that should happen, why is the result an int? What
>> > causes the casting of pgd_t & be64 to be truncated to an int.
>>
>> Yes, it's not obvious as written... It's simply that the return type of
>> pgd_present is int. So it is truncated _after_ the bitwise and.
>>
>
> Thanks, I am surprised the compiler does not complain about the truncation
> of bits. I wonder if we are missing -Wconversion
Good luck with that :)
What I should start doing is building with it enabled and then comparing
the output before and after commits to make sure we're not introducing
new cases.
cheers
[PATCHv3] random: Make /dev/random wait for crng_ready
Reading from /dev/random may return data while the getrandom
syscall is still blocking.
Those bytes are not yet cryptographically secure.
The first byte from /dev/random can have as little
as 8 bits entropy estimation. Once a read blocks, it will
block until /proc/sys/kernel/random/read_wakeup_threshold
bits are available, which is usually 64 bits, but can be
configured as low as 8 bits. A select will wake up when
at least read_wakeup_threshold bits are available.
Also when constantly reading bytes out of /dev/random
it will prevent the crng init done event forever.
Fixed by making read and select on /dev/random wait until
the crng is fully initialized and the blocking_pool is
also initialized which means that more than 128 bits of
entopy have been accumulated in the blocking_pool.
Signed-off-by: Bernd Edlinger
---
The v3 version waits much longer than the v2 version,
since first 128 bits from the input_pool go into the
CRNG, the next 64 bits are only accounted 3/4 = 48 bits
in the blocking_pool, so we need in total 192 bits from
the input_pool until the blocking_pool is initialized
And another 64 bits until a select on /dev/random wakes up.
On a system with only interrupt_randomness, this
takes 128+192+64=384 random bits, about 6.5 minutes
from boot until /dev/random is readable.
Maybe this is taking too long, after the CRNG ready?
After the input_pool had already been initialized,
I wonder if feeding the next 64 bits from the input pool
to the empty blocking_pool could already be considered
to be good enough to derive the first random byte from
the blocking_pool?
Thanks
Bernd.
---
drivers/char/random.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 38c6d1a..666102d 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -476,6 +476,7 @@ struct entropy_store {
__u8 last_data[EXTRACT_SIZE];
};
+static void _xfer_secondary_pool(struct entropy_store *r, size_t nbytes);
static ssize_t extract_entropy(struct entropy_store *r, void *buf,
size_t nbytes, int min, int rsvd);
static ssize_t _extract_entropy(struct entropy_store *r, void *buf,
@@ -719,8 +720,16 @@ static void credit_entropy_bits(struct entropy_store *r,
int nbits)
entropy_bits = r->entropy_count >> ENTROPY_SHIFT;
}
+ if (crng_ready() && !blocking_pool.initialized &&
+ entropy_bits >= random_read_wakeup_bits) {
+ _xfer_secondary_pool(&blocking_pool, entropy_bits / 8);
+ r->entropy_total = 0;
+ entropy_bits = r->entropy_count >> ENTROPY_SHIFT;
+ }
+
/* should we wake readers? */
- if (entropy_bits >= random_read_wakeup_bits &&
+ if (blocking_pool.initialized &&
+ entropy_bits >= random_read_wakeup_bits &&
wq_has_sleeper(&random_read_wait)) {
wake_up_interruptible(&random_read_wait);
kill_fasync(&fasync, SIGIO, POLL_IN);
@@ -1317,7 +1326,6 @@ void add_disk_randomness(struct gendisk *disk)
* from the primary pool to the secondary extraction pool. We make
* sure we pull enough for a 'catastrophic reseed'.
*/
-static void _xfer_secondary_pool(struct entropy_store *r, size_t nbytes);
static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
{
if (!r->pull ||
@@ -1661,7 +1669,7 @@ void get_random_bytes(void *buf, int nbytes)
*/
int wait_for_random_bytes(void)
{
- if (likely(crng_ready()))
+ if (crng_ready())
return 0;
return wait_event_interruptible(crng_init_wait, crng_ready());
}
@@ -1851,7 +1859,9 @@ void rand_initialize_disk(struct gendisk *disk)
nbytes = min_t(size_t, nbytes, SEC_XFER_SIZE);
while (1) {
- n = extract_entropy_user(&blocking_pool, buf, nbytes);
+ n = blocking_pool.initialized
+ ? extract_entropy_user(&blocking_pool, buf, nbytes)
+ : 0;
if (n < 0)
return n;
trace_random_read(n*8, (nbytes-n)*8,
@@ -1865,6 +1875,7 @@ void rand_initialize_disk(struct gendisk *disk)
return -EAGAIN;
wait_event_interruptible(random_read_wait,
+ blocking_pool.initialized &&
ENTROPY_BITS(&input_pool) >=
random_read_wakeup_bits);
if (signal_pending(current))
@@ -1909,7 +1920,8 @@ void rand_initialize_disk(struct gendisk *disk)
poll_wait(file, &random_read_wait, wait);
poll_wait(file, &random_write_wait, wait);
mask = 0;
- if (ENTROPY_BITS(&input_pool) >= random_read_wakeup_bits)
+ if (blocking_pool.initialized &&
+ ENTROPY_BITS(&inp
Re: nbd, nbdkit, loopback mounts and memory management
So not to dispute that this could be a bug, but I couldn't cause a deadlock. I wonder if you can see something wrong with my method? *** Set up *** - kernel 5.0.0-0.rc3.git0.1.fc30.x86_64 - nbd-client 3.19-1.fc30 - nbdkit 1.11.5 (git commit ef9d1978ce28) Baremetal machine was booted with mem=2G to artificially limit the RAM. The machine has 64G of swap. # free -m totalusedfree shared buff/cache available Mem: 1806 3291383 0 931357 Swap: 65535 179 65356 *** Method *** I started nbdkit as a 4G RAM disk: ./nbdkit memory size=4G This is implemented as a sparse array with a 2 level page table, and should allocate (using malloc) every time a new area of the disk is written to. Exact implementation is here: https://github.com/libguestfs/nbdkit/tree/master/common/sparse I started nbd-client using the -swap option which uses mlockall(MCL_FUTURE) to lock the client into RAM. nbd-client -b 512 -swap localhost /dev/nbd0 I then created a filesystem on the RAM disk, mounted it, and copied a 3G file into it. I tried this various ways, but the variation I was eventually happy with was: mke2fs /dev/nbd0 mount /dev/nbd0 /tmp/mnt dd if=/dev/zero of=/tmp/big bs=1M count=3000 cp /tmp/big /tmp/mnt/big I couldn't get any kind of deadlock or failure in this test. (Note that if you repeat the test several times, in theory you could delete the file and fstrim the filesystem, but when I was testing it to be sure I unmounted everything and killed and restarted nbdkit between each test.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
[PATCH v6 02/22] iommu/mediatek: Use a struct as the platform data
Use a struct as the platform special data instead of the enumeration.
This is a prepare patch for adding mt8183 iommu support.
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
Reviewed-by: Evan Green
---
drivers/iommu/mtk_iommu.c | 24
drivers/iommu/mtk_iommu.h | 6 +-
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index de3e022..189d1b5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -54,7 +54,7 @@
#define REG_MMU_CTRL_REG 0x110
#define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4)
#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
- ((data)->m4u_plat == M4U_MT2712 ? 4 : 5)
+ ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
/* It's named by F_MMU_TF_PROT_SEL in mt2712. */
#define F_MMU_TF_PROTECT_SEL(prot, data) \
(((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
@@ -520,7 +520,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
}
regval = F_MMU_TF_PROTECT_SEL(2, data);
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
@@ -541,14 +541,14 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
else
regval = lower_32_bits(data->protect_base) |
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->m4u_plat != M4U_MT8173) {
+ if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1__ to 0x1__. here record bit[32:30].
@@ -559,7 +559,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
/* It's MISC control register whose default value is ok except mt8173.*/
- if (data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->m4u_plat == M4U_MT8173)
writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
@@ -592,7 +592,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
data->dev = dev;
- data->m4u_plat = (enum mtk_iommu_plat)of_device_get_match_data(dev);
+ data->plat_data = of_device_get_match_data(dev);
/* Protect memory. HW will access here while translation fault.*/
protect = devm_kzalloc(dev, MTK_PROTECT_PA_ALIGN * 2, GFP_KERNEL);
@@ -736,9 +736,17 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
};
+static const struct mtk_iommu_plat_data mt2712_data = {
+ .m4u_plat = M4U_MT2712,
+};
+
+static const struct mtk_iommu_plat_data mt8173_data = {
+ .m4u_plat = M4U_MT8173,
+};
+
static const struct of_device_id mtk_iommu_of_ids[] = {
- { .compatible = "mediatek,mt2712-m4u", .data = (void *)M4U_MT2712},
- { .compatible = "mediatek,mt8173-m4u", .data = (void *)M4U_MT8173},
+ { .compatible = "mediatek,mt2712-m4u", .data = &mt2712_data},
+ { .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 778498b..333a0ef 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -41,6 +41,10 @@ enum mtk_iommu_plat {
M4U_MT8173,
};
+struct mtk_iommu_plat_data {
+ enum mtk_iommu_plat m4u_plat;
+};
+
struct mtk_iommu_domain;
struct mtk_iommu_data {
@@ -57,7 +61,7 @@ struct mtk_iommu_data {
booltlb_flush_active;
struct iommu_device iommu;
- enum mtk_iommu_plat m4u_plat;
+ const struct mtk_iommu_plat_data *plat_data;
struct list_headlist;
};
--
1.9.1
[PATCH v6 05/22] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers
Add two helper functions: paddr_to_iopte and iopte_to_paddr.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
Reviewed-by: Evan Green
---
drivers/iommu/io-pgtable-arm-v7s.c | 45 --
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index cec29bf..11d8505 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -173,18 +173,38 @@ struct arm_v7s_io_pgtable {
spinlock_t split_lock;
};
+static bool arm_v7s_pte_is_cont(arm_v7s_iopte pte, int lvl);
+
static dma_addr_t __arm_v7s_dma_addr(void *pages)
{
return (dma_addr_t)virt_to_phys(pages);
}
-static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl)
+static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
+ struct io_pgtable_cfg *cfg)
{
+ return paddr & ARM_V7S_LVL_MASK(lvl);
+}
+
+static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
+ struct io_pgtable_cfg *cfg)
+{
+ arm_v7s_iopte mask;
+
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
- pte &= ARM_V7S_TABLE_MASK;
+ mask = ARM_V7S_TABLE_MASK;
+ else if (arm_v7s_pte_is_cont(pte, lvl))
+ mask = ARM_V7S_LVL_MASK(lvl) * ARM_V7S_CONT_PAGES;
else
- pte &= ARM_V7S_LVL_MASK(lvl);
- return phys_to_virt(pte);
+ mask = ARM_V7S_LVL_MASK(lvl);
+
+ return pte & mask;
+}
+
+static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
+ struct arm_v7s_io_pgtable *data)
+{
+ return phys_to_virt(iopte_to_paddr(pte, lvl, &data->iop.cfg));
}
static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
@@ -396,7 +416,7 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
if (num_entries > 1)
pte = arm_v7s_pte_to_cont(pte, lvl);
- pte |= paddr & ARM_V7S_LVL_MASK(lvl);
+ pte |= paddr_to_iopte(paddr, lvl, cfg);
__arm_v7s_set_pte(ptep, pte, num_entries, cfg);
return 0;
@@ -462,7 +482,7 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data,
unsigned long iova,
}
if (ARM_V7S_PTE_IS_TABLE(pte, lvl)) {
- cptep = iopte_deref(pte, lvl);
+ cptep = iopte_deref(pte, lvl, data);
} else if (pte) {
/* We require an unmap first */
WARN_ON(!selftest_running);
@@ -512,7 +532,8 @@ static void arm_v7s_free_pgtable(struct io_pgtable *iop)
arm_v7s_iopte pte = data->pgd[i];
if (ARM_V7S_PTE_IS_TABLE(pte, 1))
- __arm_v7s_free_table(iopte_deref(pte, 1), 2, data);
+ __arm_v7s_free_table(iopte_deref(pte, 1, data),
+2, data);
}
__arm_v7s_free_table(data->pgd, 1, data);
kmem_cache_destroy(data->l2_tables);
@@ -582,7 +603,7 @@ static size_t arm_v7s_split_blk_unmap(struct
arm_v7s_io_pgtable *data,
if (!ARM_V7S_PTE_IS_TABLE(pte, 1))
return 0;
- tablep = iopte_deref(pte, 1);
+ tablep = iopte_deref(pte, 1, data);
return __arm_v7s_unmap(data, iova, size, 2, tablep);
}
@@ -641,7 +662,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable
*data,
io_pgtable_tlb_add_flush(iop, iova, blk_size,
ARM_V7S_BLOCK_SIZE(lvl + 1), false);
io_pgtable_tlb_sync(iop);
- ptep = iopte_deref(pte[i], lvl);
+ ptep = iopte_deref(pte[i], lvl, data);
__arm_v7s_free_table(ptep, lvl + 1, data);
} else if (iop->cfg.quirks &
IO_PGTABLE_QUIRK_NON_STRICT) {
/*
@@ -666,7 +687,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable
*data,
}
/* Keep on walkin' */
- ptep = iopte_deref(pte[0], lvl);
+ ptep = iopte_deref(pte[0], lvl, data);
return __arm_v7s_unmap(data, iova, size, lvl + 1, ptep);
}
@@ -692,7 +713,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct
io_pgtable_ops *ops,
do {
ptep += ARM_V7S_LVL_IDX(iova, ++lvl);
pte = READ_ONCE(*ptep);
- ptep = iopte_deref(pte, lvl);
+ ptep = iopte_deref(pte, lvl, data);
} while (ARM_V7S_PTE_IS_TABLE(pte, lvl));
if (!ARM_V7S_PTE_IS_VALID(pte))
@@ -701,7 +722,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct
io_pgtable_ops *ops,
mask = ARM_V7S_LVL_MASK(lvl);
if (arm_v7s_pte_is_cont(pte, lvl))
mask *= ARM_V7S_CONT_PAGES;
- return (pte & mask) | (iova & ~mask);
+ return iopte_to_paddr(pte, lvl, &data->iop.cfg)
[PATCH v6 04/22] memory: mtk-smi: Use a struct for the platform data for smi-common
Use a struct as the platform special data instead of the enumeration.
Also there is a minor change that moving the position of
"enum mtk_smi_gen" definition, this is because we expect define
"struct mtk_smi_common_plat" before it is referred.
This is a preparing patch for mt8183.
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
Reviewed-by: Evan Green
---
drivers/memory/mtk-smi.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 9fd6b3d..8a2f968 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -49,6 +49,15 @@
#define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+enum mtk_smi_gen {
+ MTK_SMI_GEN1,
+ MTK_SMI_GEN2
+};
+
+struct mtk_smi_common_plat {
+ enum mtk_smi_gen gen;
+};
+
struct mtk_smi_larb_gen {
bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
@@ -61,6 +70,8 @@ struct mtk_smi {
struct clk *clk_apb, *clk_smi;
struct clk *clk_async; /*only needed by mt2701*/
void __iomem*smi_ao_base;
+
+ const struct mtk_smi_common_plat *plat;
};
struct mtk_smi_larb { /* larb: local arbiter */
@@ -72,11 +83,6 @@ struct mtk_smi_larb { /* larb: local arbiter */
u32 *mmu;
};
-enum mtk_smi_gen {
- MTK_SMI_GEN1,
- MTK_SMI_GEN2
-};
-
static int mtk_smi_enable(const struct mtk_smi *smi)
{
int ret;
@@ -351,18 +357,26 @@ static int mtk_smi_larb_remove(struct platform_device
*pdev)
}
};
+static const struct mtk_smi_common_plat mtk_smi_common_gen1 = {
+ .gen = MTK_SMI_GEN1,
+};
+
+static const struct mtk_smi_common_plat mtk_smi_common_gen2 = {
+ .gen = MTK_SMI_GEN2,
+};
+
static const struct of_device_id mtk_smi_common_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-common",
- .data = (void *)MTK_SMI_GEN2
+ .data = &mtk_smi_common_gen2,
},
{
.compatible = "mediatek,mt2701-smi-common",
- .data = (void *)MTK_SMI_GEN1
+ .data = &mtk_smi_common_gen1,
},
{
.compatible = "mediatek,mt2712-smi-common",
- .data = (void *)MTK_SMI_GEN2
+ .data = &mtk_smi_common_gen2,
},
{}
};
@@ -372,13 +386,13 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
struct device *dev = &pdev->dev;
struct mtk_smi *common;
struct resource *res;
- enum mtk_smi_gen smi_gen;
int ret;
common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
if (!common)
return -ENOMEM;
common->dev = dev;
+ common->plat = of_device_get_match_data(dev);
common->clk_apb = devm_clk_get(dev, "apb");
if (IS_ERR(common->clk_apb))
@@ -394,8 +408,7 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
* clock into emi clock domain, but for mtk smi gen2, there's no smi ao
* base.
*/
- smi_gen = (enum mtk_smi_gen)of_device_get_match_data(dev);
- if (smi_gen == MTK_SMI_GEN1) {
+ if (common->plat->gen == MTK_SMI_GEN1) {
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
common->smi_ao_base = devm_ioremap_resource(dev, res);
if (IS_ERR(common->smi_ao_base))
--
1.9.1
[PATCH v6 08/22] iommu/mediatek: Add larb-id remapped support
The larb-id may be remapped in the smi-common, this means the
larb-id reported in the mtk_iommu_isr isn't the real larb-id,
Take mt8183 as a example:
M4U
|
-
| SMI common |
-0-7-5-6-1-2--3-4- <- Id remapped
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc imgcam
As above, larb0 connects with the id 0 in smi-common.
larb1 connects with the id 7 in smi-common.
...
If the larb-id reported in the isr is 7, actually it's larb1(vdec).
In order to output the right larb-id in the isr, we add a larb-id
remapping relationship in this patch.
If there is no this larb-id remapping in some SoCs, use the linear
mapping array instead.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu
Reviewed-by: Nicolas Boichat
Reviewed-by: Evan Green
---
drivers/iommu/mtk_iommu.c | 4
drivers/iommu/mtk_iommu.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 685f5d5..3bf7b76 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -220,6 +220,8 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+ fault_larb = data->plat_data->larbid_remap[fault_larb];
+
if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
dev_err_ratelimited(
@@ -740,12 +742,14 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
.has_bclk = true,
+ .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
.has_bclk = true,
+ .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b8749ac..eec19a6 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,6 +47,8 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
boolhas_bclk;
+
+ unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
struct mtk_iommu_domain;
--
1.9.1
[PATCH v6 06/22] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
MediaTek extend the arm v7s descriptor to support the dram over 4GB.
In the mt2712 and mt8173, it's called "4GB mode", the physical address
is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
is remapped to high address from 0x1__ to 0x1__, the
bit32 is always enabled. thus, in the M4U, we always enable the bit9
for all PTEs which means to enable bit32 of physical address.
but in mt8183, M4U support the dram from 0x4000_ to 0x3__
which isn't remaped. We extend the PTEs: the bit9 represent bit32 of
PA and the bit4 represent bit33 of PA. Meanwhile the iova still is
32bits.
In order to unify code, in the "4GB mode", we add the bit32 for the
physical address manually in our driver.
Correspondingly, Adding bit32 and bit33 for the PA in the iova_to_phys
has to been moved into v7s.
Regarding whether the pagetable address could be over 4GB, the mt8183
support it while the previous mt8173 don't. thus keep it as is.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
Comparing the previous version, I add MTK_4GB quirk always since mtk_iommu
has already controlled the PA itself. Helped from Evan.
---
drivers/iommu/io-pgtable-arm-v7s.c | 31 ---
drivers/iommu/io-pgtable.h | 7 +++
drivers/iommu/mtk_iommu.c | 20 ++--
drivers/iommu/mtk_iommu.h | 1 +
4 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 11d8505..8803a35 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -124,7 +124,9 @@
#define ARM_V7S_TEX_MASK 0x7
#define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) <<
ARM_V7S_TEX_SHIFT)
-#define ARM_V7S_ATTR_MTK_4GB BIT(9) /* MTK extend it for 4GB mode */
+/* MediaTek extend the two bits below for over 4GB mode */
+#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
+#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
/* *well, except for TEX on level 2 large pages, of course :( */
#define ARM_V7S_CONT_PAGE_TEX_SHIFT6
@@ -183,13 +185,22 @@ static dma_addr_t __arm_v7s_dma_addr(void *pages)
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ }
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -198,7 +209,14 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int
lvl,
else
mask = ARM_V7S_LVL_MASK(lvl);
- return pte & mask;
+ paddr = pte & mask;
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
+ paddr |= BIT_ULL(32);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
+ paddr |= BIT_ULL(33);
+ }
+ return paddr;
}
static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
@@ -315,9 +333,6 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot, int lvl,
if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
pte |= ARM_V7S_ATTR_NS_SECTION;
- if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)
- pte |= ARM_V7S_ATTR_MTK_4GB;
-
return pte;
}
@@ -504,7 +519,9 @@ static int arm_v7s_map(struct io_pgtable_ops *ops, unsigned
long iova,
if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
return 0;
- if (WARN_ON(upper_32_bits(iova) || upper_32_bits(paddr)))
+ if (WARN_ON(upper_32_bits(iova)) ||
+ WARN_ON(upper_32_bits(paddr) &&
+ !(iop->cfg.quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)))
return -ERANGE;
ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd);
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index 47d5ae5..69db115 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -62,10 +62,9 @@ struct io_pgtable_cfg {
* (unmapped) entries but the hardware might do so anyway, perform
* TLB maintenance when mapping as well as when unmapping.
*
-* IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) Set bit 9 in all
-* PTEs, for Mediatek IOMMUs which treat it as a 33rd address bit
-* when the SoC is in "4GB mode" and they can only access the hi
[PATCH v6 03/22] memory: mtk-smi: Use a general config_port interface
The config_port of mt2712 and mt8183 are the same. Use a general
config_port interface instead.
In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which
are not the normal larb, their register space are different from the
normal one. thus, we can not call the general config_port. In mt8183,
IPU0/1 and CCU connect with smi-common directly, they also are not
the normal larb. Hence, we add a "larb_direct_to_common_mask" for these
larbs which connect to smi-commmon directly.
This is also a preparing patch for adding mt8183 SMI support.
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
Reviewed-by: Evan Green
---
drivers/memory/mtk-smi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 8f2d152..9fd6b3d 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -53,6 +53,7 @@ struct mtk_smi_larb_gen {
bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
+ unsigned int larb_direct_to_common_mask;
};
struct mtk_smi {
@@ -176,17 +177,13 @@ void mtk_smi_larb_put(struct device *larbdev)
return -ENODEV;
}
-static void mtk_smi_larb_config_port_mt2712(struct device *dev)
+static void mtk_smi_larb_config_port_gen2_general(struct device *dev)
{
struct mtk_smi_larb *larb = dev_get_drvdata(dev);
u32 reg;
int i;
- /*
-* larb 8/9 is the bdpsys larb, the iommu_en is enabled defaultly.
-* Don't need to set it again.
-*/
- if (larb->larbid == 8 || larb->larbid == 9)
+ if (BIT(larb->larbid) & larb->larb_gen->larb_direct_to_common_mask)
return;
for_each_set_bit(i, (unsigned long *)larb->mmu, 32) {
@@ -261,7 +258,8 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
.need_larbid = true,
- .config_port = mtk_smi_larb_config_port_mt2712,
+ .config_port= mtk_smi_larb_config_port_gen2_general,
+ .larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
static const struct of_device_id mtk_smi_larb_of_ids[] = {
--
1.9.1
[PATCH v6 07/22] iommu/mediatek: Add bclk can be supported optionally
In some SoCs, M4U doesn't have its "bclk", it will use the EMI
clock instead which has always been enabled when entering kernel.
Currently mt2712 and mt8173 have this bclk while mt8183 doesn't.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/iommu/mtk_iommu.c | 10 +++---
drivers/iommu/mtk_iommu.h | 3 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b2d517c..685f5d5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -611,9 +611,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- data->bclk = devm_clk_get(dev, "bclk");
- if (IS_ERR(data->bclk))
- return PTR_ERR(data->bclk);
+ if (data->plat_data->has_bclk) {
+ data->bclk = devm_clk_get(dev, "bclk");
+ if (IS_ERR(data->bclk))
+ return PTR_ERR(data->bclk);
+ }
larb_nr = of_count_phandle_with_args(dev->of_node,
"mediatek,larbs", NULL);
@@ -737,11 +739,13 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
+ .has_bclk = true,
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
+ .has_bclk = true,
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 5890e55..b8749ac 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -44,6 +44,9 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
boolhas_4gb_mode;
+
+ /* HW will use the EMI clock if there isn't the "bclk". */
+ boolhas_bclk;
};
struct mtk_iommu_domain;
--
1.9.1
[PATCH v6 00/22] MT8183 IOMMU SUPPORT
This patchset mainly adds support for mt8183 IOMMU and SMI. mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which uses ARM Short-Descriptor translation table format. The mt8183 M4U-SMI HW diagram is as below: EMI | M4U | -- || gals0-rx gals1-rx || || gals0-tx gals1-tx || SMI Common | +-+-++-+-+---+---+ | | || | | | | | | gals-rx gals-rx | gals-rx gals-rx gals-rx | | || | | | | | | || | | | | | | gals-tx gals-tx | gals-tx gals-tx gals-tx | | || | | | | larb0 larb1 IPU0IPU1 larb4 larb5 larb6CCU disp vdec img camvenc imgcam All the connections are HW fixed, SW can NOT adjust it. Compared with mt8173, we add a GALS(Global Async Local Sync) module between SMI-common and M4U, and additional GALS between larb2/3/5/6 and SMI-common. GALS can help synchronize for the modules in different clock frequency, it can be seen as a "asynchronous fifo". GALS can only help transfer the command/data while it doesn't have the configuring register, thus it has the special "smi" clock and it doesn't have the "apb" clock. From the diagram above, we add "gals0" and "gals1" clocks for smi-common and add a "gals" clock for smi-larb. >From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera Control Unit) is connected with smi-common directly, we can take them as "larb2", "larb3" and "larb7", and their register spaces are different with the normal larb. This is the general purpose of each patch in this patchset: the patch 1..13 add the iommu/smi support for mt8183; the patch 14..16 add mmu1 support; the last patches contain some minor changes: -patch 17 cleanup some smi codes(delete need_larbid). -patch 18 fix a issue(fix vld_pa_rng). -patch 19 improve the code flow(add shutdown). -patch 20/21 improve the 4GB mode. -patch 22 switch to SPDX license. The dtsi was included at [1] since it should depend on power-domain and ccf nodes. [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016539.html Change notes: v6: 1) rebase on v5.0-rc1. 2) About the register name (VLD_PA_RNG), Keep consistent in all the patches. 3) In the 4GB mode, Always add MTK_4GB_quirk. 4) Reword some commit message helped from Evan. like common->smi_ao_base is completely different from common->base; STANDARD_AXI_MODE reg is completely different from CTRL_MISC; commit in the shutdown patch. 5) Add 2 new patches again: iommu/mediatek: Rename enable_4GB to dram_is_4gb iommu/mediatek: Fix iova_to_phys PA start for 4GB mode v5: https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032387.html 1) Remove this patch "iommu/mediatek: Constify iommu_ops" from here as it was applied for v5.0. 2) Again, add 3 preparing patches. Move two property into the plat_data. iommu/mediatek: Move vld_pa_rng into plat_data iommu/mediatek: Move reset_axi into plat_data iommu/mediatek: Refine protect memory definition 3) Add shutdown callback for mtk_iommu_v1 in patch[19/20]. v4: http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016205.html 1) Add 3 preparing patches. Seperate some minor meaningful code into a new patch according to Matthias's suggestion. memory: mtk-smi: Add gals support iommu/mediatek: Add larb-id remapped support iommu/mediatek: Add bclk can be supported optionally 2) rebase on "iommu/mediatek: Make it explicitly non-modular" which was applied. https://lore.kernel.org/patchwork/patch/1020125/ 3) add some comment about "mediatek,larb-id" in the commit message of the patch "mtk-smi: Get rid of need_larbid". 4) Fix bus_sel value. v3: https://lists.linuxfoundation.org/pipermail/iommu/2018-November/031121.html 1) rebase on v4.20-rc1. 2) In the dt-binding, add a minor string "mt7623" which also use gen1 since Matthias added it in v4.20. 3) About v7s: a) for paddr_to_pte, change the param from "arm_v7s_io_pgtable" to "arm_pgtable_cfg", according to Robin suggestion. b) Don't use CONFIG_PHYS_ADDR_T_64BIT. c) add a little comment(pgtable address still don't over 4GB) in the commit message of the patch "Extend MediaTek 4GB Mode". 4) add "iommu/mediatek: Constify iommu_ops" into this patchset. this may
[PATCH v6 01/22] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
This patch adds decriptions for mt8183 IOMMU and SMI. mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which uses ARM Short-Descriptor translation table format. The mt8183 M4U-SMI HW diagram is as below: EMI | M4U | -- || gals0-rx gals1-rx || || gals0-tx gals1-tx || SMI Common | +-+-++-+-+---+---+ | | || | | | | | | gals-rx gals-rx | gals-rx gals-rx gals-rx | | || | | | | | | || | | | | | | gals-tx gals-tx | gals-tx gals-tx gals-tx | | || | | | | larb0 larb1 IPU0IPU1 larb4 larb5 larb6CCU disp vdec img camvenc imgcam All the connections are HW fixed, SW can NOT adjust it. Compared with mt8173, we add a GALS(Global Async Local Sync) module between SMI-common and M4U, and additional GALS between larb2/3/5/6 and SMI-common. GALS can help synchronize for the modules in different clock frequency, it can be seen as a "asynchronous fifo". GALS can only help transfer the command/data while it doesn't have the configuring register, thus it has the special "smi" clock and it doesn't have the "apb" clock. From the diagram above, we add "gals0" and "gals1" clocks for smi-common and add a "gals" clock for smi-larb. >From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera Control Unit) is connected with smi-common directly, we can take them as "larb2", "larb3" and "larb7", and their register spaces are different with the normal larb. Signed-off-by: Yong Wu --- Hi Rob, In this version, I changed the picture in the binding and list the detailed SoCs which has "bclk" and "gals". So I don't keep your R-b. --- .../devicetree/bindings/iommu/mediatek,iommu.txt | 30 - .../memory-controllers/mediatek,smi-common.txt | 12 +- .../memory-controllers/mediatek,smi-larb.txt | 4 + include/dt-bindings/memory/mt8183-larb-port.h | 130 + 4 files changed, 170 insertions(+), 6 deletions(-) create mode 100644 include/dt-bindings/memory/mt8183-larb-port.h diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt index 6922db5..ce59a50 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt @@ -11,10 +11,23 @@ ARM Short-Descriptor translation table format for address translation. | m4u (Multimedia Memory Management Unit) | + ++ + || + gals0-rx gals1-rx(Global Async Local Sync rx) + || + || + gals0-tx gals1-tx(Global Async Local Sync tx) + || Some SoCs may have GALS. + ++ + | SMI Common(Smart Multimedia Interface Common) | ++--- || + | gals-rxThere may be GALS in some larbs. + || + || + | gals-tx || SMI larb0SMI larb1 ... SoCs have several SMI local arbiter(larb). (display) (vdec) @@ -36,6 +49,10 @@ each local arbiter. like display, video decode, and camera. And there are different ports in each larb. Take a example, There are many ports like MC, PP, VLD in the video decode local arbiter, all these ports are according to the video HW. + In some SoCs, there may be a GALS(Global Async Local Sync) module between +smi-common and m4u, and additional GALS module between smi-larb and +smi-common. GALS can been seen as a "asynchronous fifo" which could help +synchronize for the modules in different clock frequency. Required properties: - compatible : must be one of the following string: @@ -44,18 +61,25 @@ Required properties: "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses generation one m4u HW. "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW. + "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW. - reg : m4u register base and size. - interrupts : the interrupt of m4u. - clocks : must contain one entry for each clock-names. -- clock-names : must be "bclk", It is the block clock of m4u. +- clock-names : Only 1 optional clock:
[PATCH v6 09/22] iommu/mediatek: Refine protect memory definition
The protect memory setting is a little different in the different SoCs. In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault protect) shift bit is normally 4 while it shift 5 bits only in the mt8173. This patch delete the complex MACRO and use a common if-else instead. Signed-off-by: Yong Wu --- drivers/iommu/mtk_iommu.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index 3bf7b76..483f6e8 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -52,12 +52,9 @@ #define REG_MMU_DCM_DIS0x050 #define REG_MMU_CTRL_REG 0x110 +#define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4) #define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4) -#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \ - ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5) -/* It's named by F_MMU_TF_PROT_SEL in mt2712. */ -#define F_MMU_TF_PROTECT_SEL(prot, data) \ - (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data)) +#define F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173 (2 << 5) #define REG_MMU_IVRP_PADDR 0x114 @@ -519,9 +516,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data) return ret; } - regval = F_MMU_TF_PROTECT_SEL(2, data); if (data->plat_data->m4u_plat == M4U_MT8173) - regval |= F_MMU_PREFETCH_RT_REPLACE_MOD; + regval = F_MMU_PREFETCH_RT_REPLACE_MOD | +F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173; + else + regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR; writel_relaxed(regval, data->base + REG_MMU_CTRL_REG); regval = F_L2_MULIT_HIT_EN | -- 1.9.1
[PATCH v6 10/22] iommu/mediatek: Move reset_axi into plat_data
In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is
REG_MMU_CTRL in the other SoCs, and the bits meaning is completely
different with the REG_MMU_STANDARD_AXI_MODE.
This patch moves this property to plat_data, it's also a preparing
patch for mt8183.
Signed-off-by: Yong Wu
Reviewed-by: Nicolas Boichat
---
drivers/iommu/mtk_iommu.c | 4 ++--
drivers/iommu/mtk_iommu.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 483f6e8..2cf814c 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -557,8 +557,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- /* It's MISC control register whose default value is ok except mt8173.*/
- if (data->plat_data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->reset_axi)
writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
@@ -748,6 +747,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
.has_bclk = true,
+ .reset_axi= true,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index eec19a6..b46aeaa 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,7 +47,7 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
boolhas_bclk;
-
+ boolreset_axi;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
1.9.1
[PATCH v4] exec: load_script: Do not exec truncated interpreter path
Commit 8099b047ecc4 ("exec: load_script: don't blindly truncate
shebang string") was trying to protect against a confused exec of a
truncated interpreter path. However, it was overeager and also refused
to truncate arguments as well, which broke userspace, and it was
reverted. This attempts the protection again, but allows arguments to
remain truncated. In an effort to improve readability, helper functions
and comments have been added.
Co-developed-by: Linus Torvalds
Signed-off-by: Kees Cook
---
fs/binfmt_script.c | 57 ++
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index 7cde3f46ad26..32cdf6ee1f75 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -14,13 +14,30 @@
#include
#include
+static inline bool spacetab(char c) { return c == ' ' || c == '\t'; }
+static inline char *next_non_spacetab(char *first, const char *last)
+{
+ for (; first <= last; first++)
+ if (!spacetab(*first))
+ return first;
+ return NULL;
+}
+static inline char *next_spacetab(char *first, const char *last)
+{
+ for (; first <= last; first++)
+ if (spacetab(*first))
+ return first;
+ return NULL;
+}
+
static int load_script(struct linux_binprm *bprm)
{
const char *i_arg, *i_name;
- char *cp;
+ char *cp, *buf_end;
struct file *file;
int retval;
+ /* Not ours to exec if we don't start with "#!". */
if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))
return -ENOEXEC;
@@ -33,18 +50,40 @@ static int load_script(struct linux_binprm *bprm)
if (bprm->interp_flags & BINPRM_FLAGS_PATH_INACCESSIBLE)
return -ENOENT;
- /*
-* This section does the #! interpretation.
-* Sorta complicated, but hopefully it will work. -TYT
-*/
-
+ /* Release since we are not mapping a binary into memory. */
allow_write_access(bprm->file);
fput(bprm->file);
bprm->file = NULL;
- bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
- if ((cp = strchr(bprm->buf, '\n')) == NULL)
- cp = bprm->buf+BINPRM_BUF_SIZE-1;
+ /*
+* This section handles parsing the #! line into separate
+* interpreter path and argument strings. We must be careful
+* because bprm->buf is not yet guaranteed to be NUL-terminated
+* (though the buffer will have trailing NUL padding when the
+* file size was smaller than the buffer size).
+*
+* We do not want to exec a truncated interpreter path, so either
+* we find a newline (which indicates nothing is truncated), or
+* we find a space/tab/NUL after the interpreter path (which
+* itself may be preceded by spaces/tabs). Truncating the
+* arguments is fine: the interpreter can re-read the script to
+* parse them on its own.
+*/
+ buf_end = bprm->buf + sizeof(bprm->buf) - 1;
+ cp = strnchr(bprm->buf, sizeof(bprm->buf), '\n');
+ if (!cp) {
+ cp = next_non_spacetab(bprm->buf + 2, buf_end);
+ if (!cp)
+ return -ENOEXEC; /* Entire buf is spaces/tabs */
+ /*
+* Without later spaces/tabs and a non-NUL final byte we
+* must assume the interpreter path is truncated.
+*/
+ if (!next_spacetab(cp, buf_end) && *buf_end)
+ return -ENOEXEC;
+ cp = buf_end;
+ }
+ /* NUL-terminate the buffer and any trailing spaces/tabs. */
*cp = '\0';
while (cp > bprm->buf) {
cp--;
--
2.17.1
--
Kees Cook
[PATCH v6 15/22] memory: mtk-smi: Invoke pm runtime_callback to enable clocks
This patch only move the clk_prepare_enable and config_port into the
runtime suspend/resume callback. It doesn't change the code content
and sequence.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
(SMI_BUS_SEL need to be restored after smi-common resume every time.)
Also it gives a chance to get rid of mtk_smi_larb_get/put which could
be a next topic.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/memory/mtk-smi.c | 113 ++-
1 file changed, 72 insertions(+), 41 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index a430721..9790801 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -86,17 +86,13 @@ struct mtk_smi_larb { /* larb: local arbiter */
u32 *mmu;
};
-static int mtk_smi_enable(const struct mtk_smi *smi)
+static int mtk_smi_clk_enable(const struct mtk_smi *smi)
{
int ret;
- ret = pm_runtime_get_sync(smi->dev);
- if (ret < 0)
- return ret;
-
ret = clk_prepare_enable(smi->clk_apb);
if (ret)
- goto err_put_pm;
+ return ret;
ret = clk_prepare_enable(smi->clk_smi);
if (ret)
@@ -118,59 +114,28 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
clk_disable_unprepare(smi->clk_smi);
err_disable_apb:
clk_disable_unprepare(smi->clk_apb);
-err_put_pm:
- pm_runtime_put_sync(smi->dev);
return ret;
}
-static void mtk_smi_disable(const struct mtk_smi *smi)
+static void mtk_smi_clk_disable(const struct mtk_smi *smi)
{
clk_disable_unprepare(smi->clk_gals1);
clk_disable_unprepare(smi->clk_gals0);
clk_disable_unprepare(smi->clk_smi);
clk_disable_unprepare(smi->clk_apb);
- pm_runtime_put_sync(smi->dev);
}
int mtk_smi_larb_get(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
- int ret;
+ int ret = pm_runtime_get_sync(larbdev);
- /* Enable the smi-common's power and clocks */
- ret = mtk_smi_enable(common);
- if (ret)
- return ret;
-
- /* Enable the larb's power and clocks */
- ret = mtk_smi_enable(&larb->smi);
- if (ret) {
- mtk_smi_disable(common);
- return ret;
- }
-
- /* Configure the iommu info for this larb */
- larb_gen->config_port(larbdev);
-
- return 0;
+ return (ret < 0) ? ret : 0;
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
void mtk_smi_larb_put(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
-
- /*
-* Don't de-configure the iommu info for this larb since there may be
-* several modules in this larb.
-* The iommu info will be reset after power off.
-*/
-
- mtk_smi_disable(&larb->smi);
- mtk_smi_disable(common);
+ pm_runtime_put_sync(larbdev);
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
@@ -385,12 +350,52 @@ static int mtk_smi_larb_remove(struct platform_device
*pdev)
return 0;
}
+static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+ const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
+ int ret;
+
+ /* Power on smi-common. */
+ ret = pm_runtime_get_sync(larb->smi_common_dev);
+ if (ret < 0) {
+ dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
+ return ret;
+ }
+
+ ret = mtk_smi_clk_enable(&larb->smi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable clock(%d).\n", ret);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return ret;
+ }
+
+ /* Configure the basic setting for this larb */
+ larb_gen->config_port(dev);
+
+ return 0;
+}
+
+static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+
+ mtk_smi_clk_disable(&larb->smi);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return 0;
+}
+
+static const struct dev_pm_ops smi_larb_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_smi_larb_suspend, mtk_smi_larb_resume, NULL)
+};
+
static struct platform_driver mtk_smi_larb_driver = {
.probe = mtk_smi_larb_probe,
.remove = mtk_smi_larb_remove,
.driver = {
.name = "mtk-smi-larb",
.of_match_table = mtk_smi_larb_of_ids,
+ .pm = &smi_larb_pm_ops,
}
};
@@ -489,12 +494,38 @@ static int mtk_smi_common_remove(struct platform_device
*pdev)
return 0;
}
+static int __maybe_unuse
[PATCH v6 16/22] memory: mtk-smi: Add bus_sel for mt8183
There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
mmu0 or mmu1 to balance the bandwidth via the smi-common register
SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
In mt8183, For better performance, we switch larb1/2/5/7 to enter
mmu1 while the others still keep enter mmu0.
In mt8173 and mt2712, we don't get the performance issue,
Keep its default value(0x0), that means all the larbs enter mmu0.
Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
And, the base of smi-common is completely different with smi_ao_base
of gen1, thus I add new variable for that.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 9790801..08cf40d 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -49,6 +49,12 @@
#define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+/* SMI COMMON */
+#define SMI_BUS_SEL0x220
+#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
+/* All are MMU0 defaultly. Only specialize mmu1 here. */
+#define F_MMU1_LARB(larbid)(0x1 << SMI_BUS_LARB_SHIFT(larbid))
+
enum mtk_smi_gen {
MTK_SMI_GEN1,
MTK_SMI_GEN2
@@ -57,6 +63,7 @@ enum mtk_smi_gen {
struct mtk_smi_common_plat {
enum mtk_smi_gen gen;
bool has_gals;
+ u32 bus_sel; /* Balance some larbs to enter mmu0 or mmu1 */
};
struct mtk_smi_larb_gen {
@@ -72,8 +79,8 @@ struct mtk_smi {
struct clk *clk_apb, *clk_smi;
struct clk *clk_gals0, *clk_gals1;
struct clk *clk_async; /*only needed by mt2701*/
- void __iomem*smi_ao_base;
-
+ void __iomem*smi_ao_base; /* only for gen1 */
+ void __iomem*base;/* only for gen2 */
const struct mtk_smi_common_plat *plat;
};
@@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
device *dev)
static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
.gen = MTK_SMI_GEN2,
.has_gals = true,
+ .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
+ F_MMU1_LARB(7),
};
static const struct of_device_id mtk_smi_common_of_ids[] = {
@@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
ret = clk_prepare_enable(common->clk_async);
if (ret)
return ret;
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ common->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(common->base))
+ return PTR_ERR(common->base);
}
pm_runtime_enable(dev);
platform_set_drvdata(pdev, common);
@@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct platform_device
*pdev)
static int __maybe_unused mtk_smi_common_resume(struct device *dev)
{
struct mtk_smi *common = dev_get_drvdata(dev);
+ u32 bus_sel = common->plat->bus_sel;
int ret;
ret = mtk_smi_clk_enable(common);
@@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
device *dev)
dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
return ret;
}
+
+ if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
+ writel(bus_sel, common->base + SMI_BUS_SEL);
return 0;
}
--
1.9.1
[PATCH v6 12/22] memory: mtk-smi: Add gals support
In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
which can help synchronize for the modules in different clock frequency.
It can be seen as a "asynchronous fifo". This is a example diagram:
M4U
|
--
||
gals0-rx gals1-rx
||
||
gals0-tx gals1-tx
||
SMI Common
|
+-++-+- ...
| || |
| gals-rx gals-rx |
| || |
| || |
| gals-tx gals-tx |
| || |
larb1 larb2 larb3 larb4
GALS only help transfer the command/data while it doesn't have the
configuring register, thus it has the special "smi" clock and doesn't
have the "apb" clock. From the diagram above, we add "gals0" and
"gals1" clocks for smi-common and add a "gals" clock for smi-larb.
This patch adds gals clock supporting in the SMI. Note that some larbs
may still don't have the "gals" clock like larb1 and larb4 above.
This is also a preparing patch for mt8183 which has GALS.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/memory/mtk-smi.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 8a2f968..91634d7 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -56,6 +56,7 @@ enum mtk_smi_gen {
struct mtk_smi_common_plat {
enum mtk_smi_gen gen;
+ bool has_gals;
};
struct mtk_smi_larb_gen {
@@ -63,11 +64,13 @@ struct mtk_smi_larb_gen {
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
unsigned int larb_direct_to_common_mask;
+ bool has_gals;
};
struct mtk_smi {
struct device *dev;
struct clk *clk_apb, *clk_smi;
+ struct clk *clk_gals0, *clk_gals1;
struct clk *clk_async; /*only needed by mt2701*/
void __iomem*smi_ao_base;
@@ -99,8 +102,20 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
if (ret)
goto err_disable_apb;
+ ret = clk_prepare_enable(smi->clk_gals0);
+ if (ret)
+ goto err_disable_smi;
+
+ ret = clk_prepare_enable(smi->clk_gals1);
+ if (ret)
+ goto err_disable_gals0;
+
return 0;
+err_disable_gals0:
+ clk_disable_unprepare(smi->clk_gals0);
+err_disable_smi:
+ clk_disable_unprepare(smi->clk_smi);
err_disable_apb:
clk_disable_unprepare(smi->clk_apb);
err_put_pm:
@@ -110,6 +125,8 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
static void mtk_smi_disable(const struct mtk_smi *smi)
{
+ clk_disable_unprepare(smi->clk_gals1);
+ clk_disable_unprepare(smi->clk_gals0);
clk_disable_unprepare(smi->clk_smi);
clk_disable_unprepare(smi->clk_apb);
pm_runtime_put_sync(smi->dev);
@@ -310,6 +327,15 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
larb->smi.clk_smi = devm_clk_get(dev, "smi");
if (IS_ERR(larb->smi.clk_smi))
return PTR_ERR(larb->smi.clk_smi);
+
+ if (larb->larb_gen->has_gals) {
+ /* The larbs may still haven't gals even if the SoC support.*/
+ larb->smi.clk_gals0 = devm_clk_get(dev, "gals");
+ if (PTR_ERR(larb->smi.clk_gals0) == -ENOENT)
+ larb->smi.clk_gals0 = NULL;
+ else if (IS_ERR(larb->smi.clk_gals0))
+ return PTR_ERR(larb->smi.clk_gals0);
+ }
larb->smi.dev = dev;
if (larb->larb_gen->need_larbid) {
@@ -402,6 +428,16 @@ static int mtk_smi_common_probe(struct platform_device
*pdev)
if (IS_ERR(common->clk_smi))
return PTR_ERR(common->clk_smi);
+ if (common->plat->has_gals) {
+ common->clk_gals0 = devm_clk_get(dev, "gals0");
+ if (IS_ERR(common->clk_gals0))
+ return PTR_ERR(common->clk_gals0);
+
+ common->clk_gals1 = devm_clk_get(dev, "gals1");
+ if (IS_ERR(common->clk_gals1))
+ return PTR_ERR(common->clk_gals1);
+ }
+
/*
* for mtk smi gen 1, we need to get the ao(always on) base to config
* m4u port, and we need to enable the aync clock for transform the smi
--
1.9.1
[PATCH v6 13/22] iommu/mediatek: Add mt8183 IOMMU support
The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
the ARM Short-descriptor like mt8173, and most of the HW registers
are the same.
Here list main differences between mt8183 and mt8173/mt2712:
1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
mode".
4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
the bit[33:32] in the physical address of the pgtable base, But the
standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
we add a mask.
5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
6) mt8183 need reset_axi like mt8173.
7) the larb-id in smi-common is remapped. M4U should add its larbid_remap.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 15 ---
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 20
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 57aa526..bdf8dea 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -36,6 +36,7 @@
#include "mtk_iommu.h"
#define REG_MMU_PT_BASE_ADDR 0x000
+#define MMU_PT_ADDR_MASK GENMASK(31, 7)
#define REG_MMU_INVALIDATE 0x020
#define F_ALL_INVLD0x2
@@ -341,7 +342,7 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
/* Update the pgtable base address register of the M4U HW */
if (!data->m4u_dom) {
data->m4u_dom = dom;
- writel(dom->cfg.arm_v7s_cfg.ttbr[0],
+ writel(dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
data->base + REG_MMU_PT_BASE_ADDR);
}
@@ -711,6 +712,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
struct mtk_iommu_suspend_reg *reg = &data->reg;
+ struct mtk_iommu_domain *m4u_dom = data->m4u_dom;
void __iomem *base = data->base;
int ret;
@@ -726,8 +728,8 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
- if (data->m4u_dom)
- writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
+ if (m4u_dom)
+ writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
base + REG_MMU_PT_BASE_ADDR);
return 0;
}
@@ -752,9 +754,16 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
+static const struct mtk_iommu_plat_data mt8183_data = {
+ .m4u_plat = M4U_MT8183,
+ .reset_axi= true,
+ .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
+};
+
static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt2712-m4u", .data = &mt2712_data},
{ .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
+ { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index f170a1d..db12424 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -39,6 +39,7 @@ enum mtk_iommu_plat {
M4U_MT2701,
M4U_MT2712,
M4U_MT8173,
+ M4U_MT8183,
};
struct mtk_iommu_plat_data {
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 91634d7..a430721 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -285,6 +285,13 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
.larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
+static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {
+ .has_gals = true,
+ .config_port= mtk_smi_larb_config_port_gen2_general,
+ .larb_direct_to_common_mask = BIT(2) | BIT(3) | BIT(7),
+ /* IPU0 | IPU1 | CCU */
+};
+
static const struct of_device_id mtk_smi_larb_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-larb",
@@ -298,6 +305,10 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
.compatible = "mediatek,mt2712-smi-larb",
.data = &mtk_smi_larb_mt2712
},
+ {
+ .compatible = "mediatek,mt8183-smi-larb",
+ .data = &mtk_smi_larb_mt8183
+ },
{}
};
@@ -391,6 +402,11 @@ static int mtk_smi_larb_remove(struct platform_device
*pdev)
.gen = MTK_SMI_GEN2,
};
+static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
[PATCH v6 20/22] iommu/mediatek: Rename enable_4GB to dram_is_4gb
This patch only rename the variable name from enable_4GB to
dram_is_4gb for readable.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 10 +-
drivers/iommu/mtk_iommu.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8742841..0277396 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -382,7 +382,7 @@ static int mtk_iommu_map(struct iommu_domain *domain,
unsigned long iova,
int ret;
/* The "4GB mode" M4U physically can not use the lower remap of Dram. */
- if (data->plat_data->has_4gb_mode && data->enable_4GB)
+ if (data->plat_data->has_4gb_mode && data->dram_is_4gb)
paddr |= BIT_ULL(32);
spin_lock_irqsave(&dom->pgtlock, flags);
@@ -554,13 +554,13 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
if (data->plat_data->m4u_plat == M4U_MT8173)
- regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
+ regval = (data->protect_base >> 1) | (data->dram_is_4gb << 31);
else
regval = lower_32_bits(data->protect_base) |
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
+ if (data->dram_is_4gb && data->plat_data->has_vld_pa_rng) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1__ to 0x1__. here record bit[32:30].
@@ -611,8 +611,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return -ENOMEM;
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
- /* Whether the current dram is over 4GB */
- data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
+ /* Whether the current dram is 4GB. */
+ data->dram_is_4gb = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
data->base = devm_ioremap_resource(dev, res);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index dedf05c..90e98a6 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -66,7 +66,7 @@ struct mtk_iommu_data {
struct mtk_iommu_domain *m4u_dom;
struct iommu_group *m4u_group;
struct mtk_smi_iommusmi_imu; /* SMI larb iommu info */
- boolenable_4GB;
+ booldram_is_4gb;
booltlb_flush_active;
struct iommu_device iommu;
--
1.9.1
[PATCH v6 19/22] iommu/mediatek: Add shutdown callback
This patch only improve the shutdown flow. The shutdown callback will
mute the M4U HW when the system shutdown.
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/iommu/mtk_iommu.c| 6 ++
drivers/iommu/mtk_iommu_v1.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b02854c..8742841 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -702,6 +702,11 @@ static int mtk_iommu_remove(struct platform_device *pdev)
return 0;
}
+static void mtk_iommu_shutdown(struct platform_device *pdev)
+{
+ mtk_iommu_remove(pdev);
+}
+
static int __maybe_unused mtk_iommu_suspend(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -783,6 +788,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static struct platform_driver mtk_iommu_driver = {
.probe = mtk_iommu_probe,
.remove = mtk_iommu_remove,
+ .shutdown = mtk_iommu_shutdown,
.driver = {
.name = "mtk-iommu",
.of_match_table = of_match_ptr(mtk_iommu_of_ids),
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 4f15043..dd84eea 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -660,6 +660,11 @@ static int mtk_iommu_remove(struct platform_device *pdev)
return 0;
}
+static void mtk_iommu_shutdown(struct platform_device *pdev)
+{
+ mtk_iommu_remove(pdev);
+}
+
static int __maybe_unused mtk_iommu_suspend(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -697,6 +702,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
static struct platform_driver mtk_iommu_driver = {
.probe = mtk_iommu_probe,
.remove = mtk_iommu_remove,
+ .shutdown = mtk_iommu_shutdown,
.driver = {
.name = "mtk-iommu-v1",
.of_match_table = mtk_iommu_of_ids,
--
1.9.1
[PATCH v6 14/22] iommu/mediatek: Add mmu1 support
Normally the M4U HW connect EMI with smi. the diagram is like below:
EMI
|
M4U
|
smi-common
|
-
||| |...
larb0 larb1 larb2 larb3
Actually there are 2 mmu cells in the M4U HW, like this diagram:
EMI
-
| |
mmu0 mmu1 <- M4U
| |
-
|
smi-common
|
-
||| |...
larb0 larb1 larb2 larb3
This patch add support for mmu1. In order to get better performance,
we could adjust some larbs go to mmu1 while the others still go to
mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220).
mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default
value of that register is 0 which means all the larbs go to mmu0
defaultly.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/iommu/mtk_iommu.c | 46 +-
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index bdf8dea..84f18bd 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -72,26 +72,32 @@
#define F_INT_CLR_BIT BIT(12)
#define REG_MMU_INT_MAIN_CONTROL 0x124
-#define F_INT_TRANSLATION_FAULTBIT(0)
-#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
-#define F_INT_INVALID_PA_FAULT BIT(2)
-#define F_INT_ENTRY_REPLACEMENT_FAULT BIT(3)
-#define F_INT_TLB_MISS_FAULT BIT(4)
-#define F_INT_MISS_TRANSACTION_FIFO_FAULT BIT(5)
-#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT BIT(6)
+ /* mmu0 | mmu1 */
+#define F_INT_TRANSLATION_FAULT(BIT(0) | BIT(7))
+#define F_INT_MAIN_MULTI_HIT_FAULT (BIT(1) | BIT(8))
+#define F_INT_INVALID_PA_FAULT (BIT(2) | BIT(9))
+#define F_INT_ENTRY_REPLACEMENT_FAULT (BIT(3) | BIT(10))
+#define F_INT_TLB_MISS_FAULT (BIT(4) | BIT(11))
+#define F_INT_MISS_TRANSACTION_FIFO_FAULT (BIT(5) | BIT(12))
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT (BIT(6) | BIT(13))
#define REG_MMU_CPE_DONE 0x12C
#define REG_MMU_FAULT_ST1 0x134
+#define F_REG_MMU0_FAULT_MASK GENMASK(6, 0)
+#define F_REG_MMU1_FAULT_MASK GENMASK(13, 7)
-#define REG_MMU_FAULT_VA 0x13c
+#define REG_MMU0_FAULT_VA 0x13c
#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
-#define REG_MMU_INVLD_PA 0x140
-#define REG_MMU_INT_ID 0x150
-#define F_MMU0_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
-#define F_MMU0_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
+#define REG_MMU0_INVLD_PA 0x140
+#define REG_MMU1_FAULT_VA 0x144
+#define REG_MMU1_INVLD_PA 0x148
+#define REG_MMU0_INT_ID0x150
+#define REG_MMU1_INT_ID0x154
+#define F_MMU_INT_ID_LARB_ID(a)(((a) >> 7) & 0x7)
+#define F_MMU_INT_ID_PORT_ID(a)(((a) >> 2) & 0x1f)
#define MTK_PROTECT_PA_ALIGN 128
@@ -210,13 +216,19 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
/* Read error info from registers */
int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
- fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
+ if (int_state & F_REG_MMU0_FAULT_MASK) {
+ regval = readl_relaxed(data->base + REG_MMU0_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU0_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU0_INVLD_PA);
+ } else {
+ regval = readl_relaxed(data->base + REG_MMU1_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU1_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU1_INVLD_PA);
+ }
layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
- fault_pa = readl_relaxed(data->base + REG_MMU_INVLD_PA);
- regval = readl_relaxed(data->base + REG_MMU_INT_ID);
- fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
- fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+ fault_larb = F_MMU_INT_ID_LARB_ID(regval);
+ fault_port = F_MMU_INT_ID_PORT_ID(regval);
fault_larb = data->plat_data->larbid_remap[fault_larb];
--
1.9.1
[PATCH v6 18/22] iommu/mediatek: Fix VLD_PA_RNG register backup when suspend
The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
mode support for mt2712. this patch add it.
Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
drivers/iommu/mtk_iommu.c | 2 ++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 22c508b..b02854c 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -715,6 +715,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
*dev)
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
+ reg->vld_pa_rng = readl_relaxed(base + REG_MMU_VLD_PA_RNG);
clk_disable_unprepare(data->bclk);
return 0;
}
@@ -739,6 +740,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
+ writel_relaxed(reg->vld_pa_rng, base + REG_MMU_VLD_PA_RNG);
if (m4u_dom)
writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
base + REG_MMU_PT_BASE_ADDR);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index db12424..dedf05c 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -33,6 +33,7 @@ struct mtk_iommu_suspend_reg {
u32 int_control0;
u32 int_main_control;
u32 ivrp_paddr;
+ u32 vld_pa_rng;
};
enum mtk_iommu_plat {
--
1.9.1
[PATCH v6 17/22] memory: mtk-smi: Get rid of need_larbid
The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
It's no need to parse it again in SMI driver. Only clean some codes.
This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
and mt8183.
After this patch, the "mediatek,larb-id" only be needed for mt2712
which have 2 M4Us. In the other SoCs, we can get the larb-id from M4U
in which the larbs in the "mediatek,larbs" always are ordered.
Correspondingly, the larb_nr in the "struct mtk_smi_iommu" could also
be deleted.
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c| 1 -
drivers/iommu/mtk_iommu_v1.c | 2 --
drivers/memory/mtk-smi.c | 26 ++
include/soc/mediatek/smi.h | 1 -
4 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 84f18bd..22c508b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -634,7 +634,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
"mediatek,larbs", NULL);
if (larb_nr < 0)
return larb_nr;
- data->smi_imu.larb_nr = larb_nr;
for (i = 0; i < larb_nr; i++) {
struct device_node *larbnode;
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 6097e29..4f15043 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -621,8 +621,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
larb_nr++;
}
- data->smi_imu.larb_nr = larb_nr;
-
platform_set_drvdata(pdev, data);
ret = mtk_iommu_hw_init(data);
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 08cf40d..10e6493 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -67,7 +67,6 @@ struct mtk_smi_common_plat {
};
struct mtk_smi_larb_gen {
- bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
unsigned int larb_direct_to_common_mask;
@@ -153,18 +152,9 @@ void mtk_smi_larb_put(struct device *larbdev)
struct mtk_smi_iommu *smi_iommu = data;
unsigned int i;
- if (larb->larb_gen->need_larbid) {
- larb->mmu = &smi_iommu->larb_imu[larb->larbid].mmu;
- return 0;
- }
-
- /*
-* If there is no larbid property, Loop to find the corresponding
-* iommu information.
-*/
- for (i = 0; i < smi_iommu->larb_nr; i++) {
+ for (i = 0; i < MTK_LARB_NR_MAX; i++) {
if (dev == smi_iommu->larb_imu[i].dev) {
- /* The 'mmu' may be updated in iommu-attach/detach. */
+ larb->larbid = i;
larb->mmu = &smi_iommu->larb_imu[i].mmu;
return 0;
}
@@ -243,7 +233,6 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
};
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2701 = {
- .need_larbid = true,
.port_in_larb = {
LARB0_PORT_OFFSET, LARB1_PORT_OFFSET,
LARB2_PORT_OFFSET, LARB3_PORT_OFFSET
@@ -252,7 +241,6 @@ static void mtk_smi_larb_config_port_gen1(struct device
*dev)
};
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
- .need_larbid = true,
.config_port= mtk_smi_larb_config_port_gen2_general,
.larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
@@ -291,7 +279,6 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *smi_node;
struct platform_device *smi_pdev;
- int err;
larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
if (!larb)
@@ -321,15 +308,6 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
}
larb->smi.dev = dev;
- if (larb->larb_gen->need_larbid) {
- err = of_property_read_u32(dev->of_node, "mediatek,larb-id",
- &larb->larbid);
- if (err) {
- dev_err(dev, "missing larbid property\n");
- return err;
- }
- }
-
smi_node = of_parse_phandle(dev->of_node, "mediatek,smi", 0);
if (!smi_node)
return -EINVAL;
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 5201e90..a65324d 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -29,7 +29,6 @@ struct mtk_smi_larb_iommu {
};
struct mtk_smi_iommu {
- unsigned int larb_nr;
struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
};
--
1.9.1
[PATCH v6 11/22] iommu/mediatek: Move vld_pa_rng into plat_data
Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
range) register while mt2712 have. Move it into the plat_data.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 3 ++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2cf814c..57aa526 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -547,7 +547,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
+ if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1__ to 0x1__. here record bit[32:30].
@@ -740,6 +740,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
.has_bclk = true,
+ .has_vld_pa_rng = true,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b46aeaa..f170a1d 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -48,6 +48,7 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
boolhas_bclk;
boolreset_axi;
+ boolhas_vld_pa_rng;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
1.9.1
[PATCH v6 21/22] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
In the 4GB mode, the physical address is remapped,
Here is the detailed remap relationship.
CPU PA ->HW PA
0x4000_ 0x1_4000_ (Add bit32)
0x8000_ 0x1_8000_ ...
0xc000_ 0x1_c000_ ...
0x1__0x1__ (No change)
Thus, we always add bit32 for PA when entering mtk_iommu_map.
But in the iova_to_phys, the CPU don't need this bit32 if the
PA is from 0x1_4000_ to 0x1__.
This patch discards the bit32 in this iova_to_phys in the 4GB mode.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 0277396..076d333 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -119,6 +119,19 @@ struct mtk_iommu_domain {
static const struct iommu_ops mtk_iommu_ops;
+/*
+ * In M4U 4GB mode, the physical address is remapped as below:
+ * CPU PA -> M4U HW PA
+ * 0x4000_ 0x1_4000_ (Add bit32)
+ * 0x8000_ 0x1_8000_ ...
+ * 0xc000_ 0x1_c000_ ...
+ * 0x1__ 0x1__ (No change)
+ *
+ * Thus, We always add BIT32 in the iommu_map and disable BIT32 if PA is >=
+ * 0x1_4000_ in the iova_to_phys.
+ */
+#define MTK_IOMMU_4GB_MODE_PA_14000 0x14000UL
+
static LIST_HEAD(m4ulist); /* List all the M4U HWs */
#define for_each_m4u(data) list_for_each_entry(data, &m4ulist, list)
@@ -415,6 +428,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
iommu_domain *domain,
dma_addr_t iova)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
unsigned long flags;
phys_addr_t pa;
@@ -422,6 +436,10 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
iommu_domain *domain,
pa = dom->iop->iova_to_phys(dom->iop, iova);
spin_unlock_irqrestore(&dom->pgtlock, flags);
+ if (data->plat_data->has_4gb_mode && data->dram_is_4gb &&
+ pa >= MTK_IOMMU_4GB_MODE_PA_14000)
+ pa &= ~BIT_ULL(32);
+
return pa;
}
--
1.9.1
[PATCH v6 22/22] iommu/mediatek: Switch to SPDX license identifier
Switch to SPDX license identifier for MediaTek iommu/smi and their header files. Signed-off-by: Yong Wu Reviewed-by: Rob Herring Reviewed-by: Evan Green --- drivers/iommu/mtk_iommu.c | 10 +- drivers/iommu/mtk_iommu.h | 10 +- drivers/iommu/mtk_iommu_v1.c | 10 +- drivers/memory/mtk-smi.c | 10 +- include/dt-bindings/memory/mt2701-larb-port.h | 10 +- include/dt-bindings/memory/mt8173-larb-port.h | 10 +- include/soc/mediatek/smi.h| 10 +- 7 files changed, 7 insertions(+), 63 deletions(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index 076d333..63fa724 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -1,15 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong Wu - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include #include diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h index 90e98a6..ceffa54 100644 --- a/drivers/iommu/mtk_iommu.h +++ b/drivers/iommu/mtk_iommu.h @@ -1,15 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Honghui Zhang - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef _MTK_IOMMU_H_ diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c index dd84eea..0aa0670 100644 --- a/drivers/iommu/mtk_iommu_v1.c +++ b/drivers/iommu/mtk_iommu_v1.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * IOMMU API for MTK architected m4u v1 implementations * @@ -5,15 +6,6 @@ * Author: Honghui Zhang * * Based on driver/iommu/mtk_iommu.c - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include #include diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c index 10e6493..9688341 100644 --- a/drivers/memory/mtk-smi.c +++ b/drivers/memory/mtk-smi.c @@ -1,15 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong Wu - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include #include diff --git a/include/dt-bindings/memory/mt2701-larb-port.h b/include/dt-bindings/memory/mt2701-larb-port.h index 6764d74..c511f0f 100644 --- a/include/dt-bindings/memory/mt2701-larb-port.h +++ b/include/dt-bindings/memory/mt2701-larb-port.h @@ -1,15 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015 MediaTek Inc. * Author: Honghui Zhang - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef _MT2701_LARB_PORT_H_ diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h index 111b4b0..a62bfeb 100644 --- a/include/dt-bindings/memory/mt8173-larb-port.h +++ b/include/dt-bindings/memory/mt8173-larb-port.h @@ -1,15 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong
[PATCH v5 0/4] input: touchscreen: Add goodix GT5553 CTP support
This is v5 patchset for supporting goodix GT5553 CTP. Here is the previous version[1] Changes for v4: - document AVDD22, DVDD12, VDDIO as optional properties - use regulator bulk calls, for get, enable and disable functionalities Changes for v4: - devm_add_action_or_reset for disabling regulator Changes for v3: - add cover-letter - s/ADVV28/AVDD28 on commit head - fix few typo Changes for v2: - Rename vcc-supply with AVDD28-supply - disable regulator in remove - fix to setup regulator in probe code - add chipdata - drop example node in dt-bindings [1] https://patchwork.kernel.org/cover/10807779/ Jagan Teki (4): dt-bindings: input: touchscreen: goodix: Document regulator properties Input: goodix - Add regulators support dt-bindings: input: touchscreen: goodix: Add GT5663 compatible Input: goodix - Add GT5663 CTP support .../bindings/input/touchscreen/goodix.txt | 8 +++ drivers/input/touchscreen/goodix.c| 60 +-- 2 files changed, 62 insertions(+), 6 deletions(-) -- 2.18.0.321.gffc6fa0e3
Re: [PATCH v3 1/4] dt-bindings: input: touchscreen: goodix: Document AVDD28-supply property
On Sun, Feb 17, 2019 at 1:21 PM Jagan Teki wrote: > > Hi Dmitry and Rob, > > On Thu, Feb 14, 2019 at 3:21 AM Rob Herring wrote: > > > > On Tue, Jan 22, 2019 at 7:39 AM Jagan Teki > > wrote: > > > > > > On Mon, Jan 21, 2019 at 9:46 PM Rob Herring wrote: > > > > > > > > On Fri, Jan 18, 2019 at 10:01 AM Jagan Teki > > > > wrote: > > > > > > > > > > On Wed, Jan 9, 2019 at 7:08 PM Rob Herring wrote: > > > > > > > > > > > > Please CC DT list if you want bindings reviewed. > > > > > > > > > > Sorry I forgot. > > > > > > > > > > > > > > > > > On Wed, Jan 9, 2019 at 1:40 AM Dmitry Torokhov > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Dec 15, 2018 at 08:47:59PM +0530, Jagan Teki wrote: > > > > > > > > Most of the Goodix CTP controllers are supply with AVDD28 pin. > > > > > > > > which need to supply for controllers like GT5663 on some boards > > > > > > > > to trigger the power. > > > > > > > > > > > > > > > > So, document the supply property so-that the require boards > > > > > > > > that used on GT5663 can enable it via device tree. > > > > > > > > > > > > > > > > Signed-off-by: Jagan Teki > > > > > > > > --- > > > > > > > > Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > | 1 + > > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > diff --git > > > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > > > > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > index f7e95c52f3c7..c4622c983e08 100644 > > > > > > > > --- > > > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > +++ > > > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > > @@ -23,6 +23,7 @@ Optional properties: > > > > > > > > - touchscreen-inverted-y : Y axis is inverted (boolean) > > > > > > > > - touchscreen-swapped-x-y : X and Y axis are swapped (boolean) > > > > > > > > (swapping is done after inverting > > > > > > > > the axis) > > > > > > > > + - AVDD28-supply : Analog power supply regulator on AVDD28 > > > > > > > > pin > > > > > > > > > > > > > > I think we normally use lower case in DT bindings and rarely > > > > > > > encode > > > > > > > voltage in the supply name unless we are dealing with several > > > > > > > supplies > > > > > > > of the same kind, but I'll let Ron comment on this. > > > > > > > > > > > > Yes on lowercase though there are some exceptions. > > > > > > > > > > > > There's also a AVDD22 supply as well as DVDD12 and VDDIO. So we > > > > > > probably need to keep the voltage, but the binding is incomplete. > > > > > > > > > > What is incomplete here? can you please elaborate. > > > > > > > > You are missing the 3 other supplies the chip has: AVDD22, DVDD12 and > > > > VDDIO. > > > > > > Though it has other supplies, only AVDD28 is connected in the Host > > > interface design similar like 9. Reference Schematic on Page, 23 in > > > attached manual. > > > > That is for a particular board design. It still has other supplies. > > Just make the binding complete please. You can make them optional. I > > don't care if the driver supports controlling all the supplies or not > > (though Dmitry might). > > So, Can I make bulk get and enable in all 4 regulators global to > driver or specific to that chip, in either way the regulators which > are not used to process via dummy regulators (which we all know). > > or regulator which are not using are get via devm_regulator_get_optional. > > Any suggestions? Just realized to go with bulk calls, please have a look at on v5 [1] [1] https://patchwork.kernel.org/cover/10816901/
[PATCH v5 1/4] dt-bindings: input: touchscreen: goodix: Document regulator properties
Goodix CTP controllers support analog, digital and gpio regulator supplies on relevant controller pin configurations. Out of which AVDD28 regulator is mandatory supplied regulator in most of the board designs, so document AVDD28 as required property and rest marked as optional regulators. Signed-off-by: Jagan Teki --- .../devicetree/bindings/input/touchscreen/goodix.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt index f7e95c52f3c7..8f6e6eede64d 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt @@ -23,6 +23,13 @@ Optional properties: - touchscreen-inverted-y : Y axis is inverted (boolean) - touchscreen-swapped-x-y : X and Y axis are swapped (boolean) (swapping is done after inverting the axis) + - AVDD28-supply : Analog power supply regulator on AVDD28 pin + +Optional properties: + + - AVDD22-supply : Analog power supply regulator on AVDD22 pin + - DVDD12-supply : Digital power supply regulator on DVDD12 pin + - VDDIO-supply: GPIO power supply regulator on VDDIO pin Example: -- 2.18.0.321.gffc6fa0e3
[PATCH v5 4/4] Input: goodix - Add GT5663 CTP support
GT5663 is capacitive touch controller with customized smart
wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum has 16-bit
Signed-off-by: Jagan Teki
---
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 294456a53fe0..80f8b920ef5e 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -227,6 +227,7 @@ static const struct goodix_chip_data
*goodix_get_chip_data(u16 id)
{
switch (id) {
case 1151:
+ case 5663:
return >1x_chip_data;
case 911:
@@ -988,6 +989,7 @@ MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);
#ifdef CONFIG_OF
static const struct of_device_id goodix_of_match[] = {
{ .compatible = "goodix,gt1151" },
+ { .compatible = "goodix,gt5663" },
{ .compatible = "goodix,gt911" },
{ .compatible = "goodix,gt9110" },
{ .compatible = "goodix,gt912" },
--
2.18.0.321.gffc6fa0e3
[PATCH v5 2/4] Input: goodix - Add regulators support
Goodix CTP controllers support analog, digital and gpio regulator
supplies on relevant controller pin configurations.
Support them via regulator bulk calls.
Signed-off-by: Jagan Teki
---
drivers/input/touchscreen/goodix.c | 58 ++
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index f2d9c2c41885..294456a53fe0 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -40,6 +41,15 @@ struct goodix_chip_data {
int (*check_config)(struct goodix_ts_data *, const struct firmware *);
};
+static const char * const goodix_supply_names[] = {
+ "AVDD28",
+ "AVDD22",
+ "DVDD12",
+ "VDDIO",
+};
+
+#define GOODIX_NUM_SUPPLIESARRAY_SIZE(goodix_supply_names)
+
struct goodix_ts_data {
struct i2c_client *client;
struct input_dev *input_dev;
@@ -47,6 +57,7 @@ struct goodix_ts_data {
struct touchscreen_properties prop;
unsigned int max_touch_num;
unsigned int int_trigger_type;
+ struct regulator_bulk_data supplies[GOODIX_NUM_SUPPLIES];
struct gpio_desc *gpiod_int;
struct gpio_desc *gpiod_rst;
u16 id;
@@ -761,11 +772,18 @@ static void goodix_config_cb(const struct firmware *cfg,
void *ctx)
complete_all(&ts->firmware_loading_complete);
}
+static void goodix_disable_regulator(void *arg)
+{
+ struct goodix_ts_data *ts = arg;
+
+ regulator_bulk_disable(GOODIX_NUM_SUPPLIES, ts->supplies);
+}
+
static int goodix_ts_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct goodix_ts_data *ts;
- int error;
+ int error, i;
dev_dbg(&client->dev, "I2C Address: 0x%02x\n", client->addr);
@@ -786,25 +804,49 @@ static int goodix_ts_probe(struct i2c_client *client,
if (error)
return error;
+ for (i = 0; i < GOODIX_NUM_SUPPLIES; i++)
+ ts->supplies[i].supply = goodix_supply_names[i];
+
+ error = devm_regulator_bulk_get(&client->dev, GOODIX_NUM_SUPPLIES,
+ ts->supplies);
+ if (error) {
+ dev_err(&client->dev, "Failed to get regulators (ret=%d)\n",
+ error);
+ return error;
+ }
+
+ error = devm_add_action_or_reset(&client->dev,
+goodix_disable_regulator, ts);
+ if (error)
+ return error;
+
+ /* power the controller */
+ error = regulator_bulk_enable(GOODIX_NUM_SUPPLIES, ts->supplies);
+ if (error) {
+ dev_err(&client->dev, "Failed to enable regulators (ret=%d)\n",
+ error);
+ return error;
+ }
+
if (ts->gpiod_int && ts->gpiod_rst) {
/* reset the controller */
error = goodix_reset(ts);
if (error) {
dev_err(&client->dev, "Controller reset failed.\n");
- return error;
+ goto error;
}
}
error = goodix_i2c_test(client);
if (error) {
dev_err(&client->dev, "I2C communication failure: %d\n", error);
- return error;
+ goto error;
}
error = goodix_read_version(ts);
if (error) {
dev_err(&client->dev, "Read version failed.\n");
- return error;
+ goto error;
}
ts->chip = goodix_get_chip_data(ts->id);
@@ -823,17 +865,21 @@ static int goodix_ts_probe(struct i2c_client *client,
dev_err(&client->dev,
"Failed to invoke firmware loader: %d\n",
error);
- return error;
+ goto error;
}
return 0;
} else {
error = goodix_configure_dev(ts);
if (error)
- return error;
+ goto error;
}
return 0;
+
+error:
+ regulator_bulk_disable(GOODIX_NUM_SUPPLIES, ts->supplies);
+ return error;
}
static int goodix_ts_remove(struct i2c_client *client)
--
2.18.0.321.gffc6fa0e3
[PATCH v5 3/4] dt-bindings: input: touchscreen: goodix: Add GT5663 compatible
GT5663 is capacitive touch controller with customized smart wakeup gestures, it support chipdata which is similar to existing GT1151 and require AVDD28 supply for some boards. Document the compatible for the same. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt index 8f6e6eede64d..29c149d91a05 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt @@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen controller Required properties: - compatible : Should be "goodix,gt1151" +or "goodix,gt5663" or "goodix,gt911" or "goodix,gt9110" or "goodix,gt912" -- 2.18.0.321.gffc6fa0e3
Re: [PATCH v4 03/37] ARM: davinci: aintc: use irq domain
On 2/14/19 8:51 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski We need to create an irq domain if we want to select SPARSE_IRQ. The cp-intc driver already supports it, but aintc doesn't. Use the helpers provided by the generic irq chip abstraction. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 07/37] ARM: davinci: wrap HW interrupt numbers with a macro
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 09/37] ARM: davinci: make irqs.h a local header
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski The existence of irqs.h in mach-davinci/include/mach only makes sense without SPARSE_IRQ as it's then expected to define NR_IRQS and is included from asm/irq.h. As we now support SPARSE_IRQ, this header can be moved to mach-davinci and used as the source of HW interrupt numbers. While updating the includes in various files - also rearrange the headers by directory (linux/asm/mach). Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 8d5be6dd2019..26c123f35350 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -44,10 +44,11 @@ #include #include -#include + We could leave out the blank line here. #include #include "davinci.h" +#include "irqs.h" #define NAND_BLOCK_SIZE SZ_128K ... diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c index 9d4a58a3113a..1e14e964c34d 100644 --- a/arch/arm/mach-davinci/usb.c +++ b/arch/arm/mach-davinci/usb.c @@ -5,13 +5,13 @@ #include #include #include Could put dma-mapping.h before init.h here too. - +#include #include #include -#include #include -#include + +#include "irqs.h" #define DAVINCI_USB_OTG_BASE 0x01c64000
Re: [PATCH v4 14/37] ARM: davinci: aintc: use readl/writel_relaxed()
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Raplace all calls to __raw_readl() & __raw_writel() with readl_relaxed()
and writel_relaxed() respectively. It's safe to do as there's no
endianness conversion being done in the code.
This patch only changes writel. There is no readl.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/irq.c b/arch/arm/mach-davinci/irq.c
index 2df91fc0dade..509be44eda22 100644
--- a/arch/arm/mach-davinci/irq.c
+++ b/arch/arm/mach-davinci/irq.c
@@ -36,7 +36,7 @@ static struct irq_domain *davinci_aintc_irq_domain;
static inline void davinci_aintc_writel(unsigned long value, int offset)
{
- __raw_writel(value, davinci_aintc_base + offset);
+ writel_relaxed(value, davinci_aintc_base + offset);
}
static inline unsigned long davinci_aintc_readl(int offset)
Re: [PATCH v4 15/37] irqchip: davinci-aintc: add a new config structure
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Add a config structure that will be used by aintc-based platforms. It contains the register range resource, number of interrupts and a list of priorities. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 16/37] ARM: davinci: aintc: use the new irqchip config structure in dm* SoCs
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Add the new-style config structures for dm* SoCs. They will be used once we make the aintc driver stop using davinci_soc_info. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 19/37] ARM: davinci: aintc: request memory region before remapping it
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Add a missing call to request_mem_region() before calling ioremap() to make sure the region is not being used by anyone else. Signed-off-by: Bartosz Golaszewski --- Reviewed-by:
Re: [PATCH v6] coccinelle: semantic code search for missing put_device()
> +@search exists@
> +local idexpression id;
> +expression x,e,e1;
> +position p1,p2;
> +type T,T1,T2;
> +@@
> +
> +id = of_find_device_by_node@p1(x)
> +... when != e = id
I suggest to increase your software development attention also for
another implementation detail.
Source code analysis triggers challenges for safe data flow handling.
the semantic patch language supports search specifications for
the exclusion of specific assignments.
Does this SmPL code contain a questionable order for the source
and target metavariables?
Can the following variant be more appropriate?
+ ... when != id = e
> +if (id == NULL || ...) { ... return ...; }
> +... when != put_device(&id->dev)
> +when != platform_device_put(id)
> +when != of_dev_put(id)
> +when != if (id) { ... put_device(&id->dev) ... }
> +when != e1 = (T)id
Would you like to avoid that the return value from the shown function call
gets overwritten in the variable before it was used once at least
(when a bit of extra C code is tolerated before a null pointer check)?
Regards,
Markus
Re: [PATCH v4 22/37] irqchip: davinci-aintc: move the driver to drivers/irqchip
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski The aintc driver has now been cleaned up. Move it to drivers/irqchip where it belongs. There's no device-tree support for any dm* board so there's no IRQCHIP_OF_DECLARE() - there's only the exported init function called from machine code. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 25/37] irqchip: davinci-cp-intc: add a new config structure
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Add a config structure that will be used by cp-intc-based platforms. It contains the register range resource and the number of interrupts. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 26/37] ARM: davinci: cp-intc: add the new config structures for da8xx SoCs
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Add the new-style config structures for da8xx SoCs. They will be used once we make the cp-intc driver stop using davinci_soc_info. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 29/37] ARM: davinci: cp-intc: use the new-style config structure
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Modify the cp-intc driver to take all its configuration from the new config structure. Stop referencing davinci_soc_info in any way. Move the declaration for davinci_cp_intc_init() to irq-davinci-cp-intc.h and make it take the new config structure as parameter. Convert all users to the new version. Also: since the two da8xx SoCs default all irq priorities to 7, just drop the priority configuration at all and hardcode the channels to 7. It will simplify the driver code and make our lives easier when it comes to device-tree support. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 30/37] ARM: davinci: cp-intc: request the memory region before remapping it
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Add a missing call to request_mem_region() before calling ioremap() to make sure it's not been requested by another user. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
Re: [PATCH v4 33/37] ARM: davinci: cp-intc: use readl/writel_relaxed()
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Raplace all calls to __raw_readl() & __raw_writel() with readl_relaxed()
s/Raplace/Replace/
and writel_relaxed() respectively. It's safe to do as there's no
endianness conversion being done in the code.
Should this be combined with patch 14/37?
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/cp_intc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
index 1bf11fa8be76..f88b7f0978aa 100644
--- a/arch/arm/mach-davinci/cp_intc.c
+++ b/arch/arm/mach-davinci/cp_intc.c
@@ -45,13 +45,13 @@ static struct irq_domain *davinci_cp_intc_irq_domain;
static inline unsigned int davinci_cp_intc_read(unsigned int offset)
{
- return __raw_readl(davinci_cp_intc_base + offset);
+ return readl_relaxed(davinci_cp_intc_base + offset);
}
static inline void davinci_cp_intc_write(unsigned long value,
unsigned int offset)
{
- __raw_writel(value, davinci_cp_intc_base + offset);
+ writel_relaxed(value, davinci_cp_intc_base + offset);
}
static void davinci_cp_intc_ack_irq(struct irq_data *d)
Re: [PATCH v6 06/20] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
On Tue, 2019-02-05 at 15:11 -0800, Evan Green wrote:
> On Fri, Feb 1, 2019 at 1:42 AM Yong Wu wrote:
> >
> > On Thu, 2019-01-31 at 11:23 -0800, Evan Green wrote:
> > > On Wed, Jan 30, 2019 at 10:59 PM Yong Wu wrote:
> > > >
> > > > On Wed, 2019-01-30 at 10:28 -0800, Evan Green wrote:
> > > > > On Mon, Dec 31, 2018 at 7:57 PM Yong Wu wrote:
> > > > > >
> > > > > > MediaTek extend the arm v7s descriptor to support the dram over 4GB.
> > > > > >
> > > > > > In the mt2712 and mt8173, it's called "4GB mode", the physical
> > > > > > address
> > > > > > is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
> > > > > > is remapped to high address from 0x1__ to 0x1__, the
> > > > > > bit32 is always enabled. thus, in the M4U, we always enable the bit9
> > > > > > for all PTEs which means to enable bit32 of physical address.
> > > > >
> > > > > I got a little lost here. I get that you're trying to explain why you
> > > > > always used to set bit32 of the physical address. But I don't totally
> > > > > get the part about physical addresses being from 0x4000_ -
> > > > > 0x1_3fff_, but also from 0x1__-0x1__. Are you
> > > > > saying that the physical addresses from the iommu's perspective were
> > > > > always >0x1__?
> > > >
> > > > Yes. From the IOMMU's perspective, the Physical address is from
> > > > 0x1__ to 0x1__.
> > > >
> > > > > But then from whose perspective is it 0x4000_? ...
> > > >
> > > > I guess from SW point view. it is from 0x4000_ to 0x1_3fff_.
> > > >
> > > > If 4GB mode is enabled, the memory property in dts like this:
> > > >
> > > > memory@4000 {
> > > > device_type = "memory";
> > > > reg = <0 0x4000 0x0001 0x>;
> > > > };
> > > >
> > > > > oh, or you're saying there was some sort of remapping
> > > > > facility that moved the physical addresses around?
> > > > >
> > > > > >
> > > > > > but in mt8183, M4U support the dram from 0x4000_ to
> > > > > > 0x3__
> > > > > > which isn't remaped. We extend the PTEs: the bit9 represent bit32 of
> > > > > > PA and the bit4 represent bit33 of PA. Meanwhile the iova still is
> > > > > > 32bits.
> > > > > >
> > > > > > In order to unify code, in the "4GB mode", we add the bit32 for the
> > > > > > physical address manually in our driver.
> > > > > >
> > > > > > Correspondingly, Adding bit32 and bit33 for the PA in the
> > > > > > iova_to_phys
> > > > > > has to been moved into v7s.
> > > > > >
> > > > > > Regarding whether the pagetable address could be over 4GB, the
> > > > > > mt8183
> > > > > > support it while the previous mt8173 don't. thus keep it as is.
> > > > > >
> > > > > > Signed-off-by: Yong Wu
> > > > > > Reviewed-by: Robin Murphy
> > > > > > ---
> > > > > > drivers/iommu/io-pgtable-arm-v7s.c | 31
> > > > > > ---
> > > > > > drivers/iommu/io-pgtable.h | 7 +++
> > > > > > drivers/iommu/mtk_iommu.c | 14 --
> > > > > > drivers/iommu/mtk_iommu.h | 1 +
> > > > > > 4 files changed, 36 insertions(+), 17 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> > > > > > b/drivers/iommu/io-pgtable-arm-v7s.c
> > > > > > index 11d8505..8803a35 100644
> > > > > > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > > > > > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > > > > > @@ -124,7 +124,9 @@
> > > > > > #define ARM_V7S_TEX_MASK 0x7
> > > > > > #define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK)
> > > > > > << ARM_V7S_TEX_SHIFT)
> > > > > >
> > > > > > -#define ARM_V7S_ATTR_MTK_4GB BIT(9) /* MTK extend it for
> > > > > > 4GB mode */
> > > > > > +/* MediaTek extend the two bits below for over 4GB mode */
> > > > > > +#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
> > > > > > +#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
> > > > >
> > > > > If other vendors start doing stuff like this we'll need a more generic
> > > > > way to handle this... but I guess until we see a pattern this is okay.
> > > > >
> > > > > >
> > > > > > /* *well, except for TEX on level 2 large pages, of course :( */
> > > > > > #define ARM_V7S_CONT_PAGE_TEX_SHIFT6
> > > > > > @@ -183,13 +185,22 @@ static dma_addr_t __arm_v7s_dma_addr(void
> > > > > > *pages)
> > > > > > static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
> > > > > > struct io_pgtable_cfg *cfg)
> > > > > > {
> > > > > > - return paddr & ARM_V7S_LVL_MASK(lvl);
> > > > > > + arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
> > > > > > +
> > > > > > + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
> > > > > > + if (paddr & BIT_ULL(32))
> > > > > > + pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
> > > > > > + if (paddr & BIT_ULL(33))
> > > > > > + pte |= ARM_V7S_ATTR_M
Re: [PATCH v4 37/37] ARM: davinci: remove intc related fields from davinci_soc_info
On 2/14/19 8:52 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski The fields related to the two davinci interrupt controllers are no longer used. Remove them. Signed-off-by: Bartosz Golaszewski --- Reviewed-by: David Lechner
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 528871b456026e6127d95b1b2bd8e3a003dc1614 perf/core: Fix impossible
ring-buffer sizes warning
Two fixes on the kernel side: fix an over-eager condition that failed
larger perf ring-buffer sizes, plus fix crashes in the Intel BTS code for
a corner case, found by fuzzing.
Thanks,
Ingo
-->
Ingo Molnar (1):
perf/core: Fix impossible ring-buffer sizes warning
Jiri Olsa (1):
perf/x86: Add check_period PMU callback
arch/x86/events/core.c | 14 ++
arch/x86/events/intel/core.c | 9 +
arch/x86/events/perf_event.h | 16 ++--
include/linux/perf_event.h | 5 +
kernel/events/core.c | 16
kernel/events/ring_buffer.c | 2 +-
6 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 374a19712e20..b684f0294f35 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2278,6 +2278,19 @@ void perf_check_microcode(void)
x86_pmu.check_microcode();
}
+static int x86_pmu_check_period(struct perf_event *event, u64 value)
+{
+ if (x86_pmu.check_period && x86_pmu.check_period(event, value))
+ return -EINVAL;
+
+ if (value && x86_pmu.limit_period) {
+ if (x86_pmu.limit_period(event, value) > value)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct pmu pmu = {
.pmu_enable = x86_pmu_enable,
.pmu_disable= x86_pmu_disable,
@@ -2302,6 +2315,7 @@ static struct pmu pmu = {
.event_idx = x86_pmu_event_idx,
.sched_task = x86_pmu_sched_task,
.task_ctx_size = sizeof(struct x86_perf_task_context),
+ .check_period = x86_pmu_check_period,
};
void arch_perf_update_userpage(struct perf_event *event,
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index daafb893449b..730978dff63f 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3587,6 +3587,11 @@ static void intel_pmu_sched_task(struct
perf_event_context *ctx,
intel_pmu_lbr_sched_task(ctx, sched_in);
}
+static int intel_pmu_check_period(struct perf_event *event, u64 value)
+{
+ return intel_pmu_has_bts_period(event, value) ? -EINVAL : 0;
+}
+
PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
PMU_FORMAT_ATTR(ldlat, "config1:0-15");
@@ -3667,6 +3672,8 @@ static __initconst const struct x86_pmu core_pmu = {
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
.cpu_dead = intel_pmu_cpu_dead,
+
+ .check_period = intel_pmu_check_period,
};
static struct attribute *intel_pmu_attrs[];
@@ -3711,6 +3718,8 @@ static __initconst const struct x86_pmu intel_pmu = {
.guest_get_msrs = intel_guest_get_msrs,
.sched_task = intel_pmu_sched_task,
+
+ .check_period = intel_pmu_check_period,
};
static __init void intel_clovertown_quirk(void)
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index 78d7b7031bfc..d46fd6754d92 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -646,6 +646,11 @@ struct x86_pmu {
* Intel host/guest support (KVM)
*/
struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr);
+
+ /*
+* Check period value for PERF_EVENT_IOC_PERIOD ioctl.
+*/
+ int (*check_period) (struct perf_event *event, u64 period);
};
struct x86_perf_task_context {
@@ -857,7 +862,7 @@ static inline int amd_pmu_init(void)
#ifdef CONFIG_CPU_SUP_INTEL
-static inline bool intel_pmu_has_bts(struct perf_event *event)
+static inline bool intel_pmu_has_bts_period(struct perf_event *event, u64
period)
{
struct hw_perf_event *hwc = &event->hw;
unsigned int hw_event, bts_event;
@@ -868,7 +873,14 @@ static inline bool intel_pmu_has_bts(struct perf_event
*event)
hw_event = hwc->config & INTEL_ARCH_EVENT_MASK;
bts_event = x86_pmu.event_map(PERF_COUNT_HW_BRANCH_INSTRUCTIONS);
- return hw_event == bts_event && hwc->sample_period == 1;
+ return hw_event == bts_event && period == 1;
+}
+
+static inline bool intel_pmu_has_bts(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ return intel_pmu_has_bts_period(event, hwc->sample_period);
}
int intel_pmu_save_and_restart(struct perf_event *event);
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1d5c551a5add..e1a051724f7e 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -447,6 +447,11 @@ struct pmu {
* Filter events for PMU-specific reasons.
[PULL REQUEST] i2c for 5.0
Linus, I2C has two more driver bugfixes for you. Please pull. Thanks, Wolfram The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to f275a4659484716259cc46268d9043424e51cf0f: i2c: bcm2835: Clear current buffer pointers and counts after a transfer (2019-02-15 09:45:05 +0100) Paul Kocialkowski (1): i2c: bcm2835: Clear current buffer pointers and counts after a transfer Shubhrajyoti Datta (1): i2c: cadence: Fix the hold bit setting with much appreciated quality assurance from Kyle Roeschley (1): (Test) i2c: cadence: Fix the hold bit setting drivers/i2c/busses/i2c-bcm2835.c | 12 drivers/i2c/busses/i2c-cadence.c | 9 +++-- 2 files changed, 19 insertions(+), 2 deletions(-) signature.asc Description: PGP signature
[GIT PULL] x86 fixes
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: f331e766c4be33f4338574f3c9f7f77e98ab4571 x86/platform/UV: Use
efi_runtime_lock to serialise BIOS calls
Three changes:
- An UV fix/quirk to pull UV BIOS calls into the efi_runtime_lock
locking regime. (This done by aliasing __efi_uv_runtime_lock to
efi_runtime_lock, which should make the quirk nature obvious and
maintain the general policy that the EFI lock (name...) isn't exposed
to drivers.)
- Our version of MAGA: Make a.out Great Again.
- Add a new Intel model name enumerator to an upstream header to help
reduce dependencies going forward.
out-of-topic modifications in x86-urgent-for-linus:
-
drivers/firmware/efi/runtime-wrappers.c# f331e766c4be: x86/platform/UV: Use
efi_run
Thanks,
Ingo
-->
Borislav Petkov (1):
x86/a.out: Clear the dump structure initially
Hedi Berriche (1):
x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls
Rajneesh Bhardwaj (1):
x86/CPU: Add Icelake model number
arch/x86/ia32/ia32_aout.c | 6 --
arch/x86/include/asm/intel-family.h | 2 ++
arch/x86/include/asm/uv/bios.h | 8 +++-
arch/x86/platform/uv/bios_uv.c | 23 +--
drivers/firmware/efi/runtime-wrappers.c | 7 +++
5 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index f65b78d32f5e..7dbbe9ffda17 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -51,7 +51,7 @@ static unsigned long get_dr(int n)
/*
* fill in the user structure for a core dump..
*/
-static void dump_thread32(struct pt_regs *regs, struct user32 *dump)
+static void fill_dump(struct pt_regs *regs, struct user32 *dump)
{
u32 fs, gs;
memset(dump, 0, sizeof(*dump));
@@ -157,10 +157,12 @@ static int aout_core_dump(struct coredump_params *cprm)
fs = get_fs();
set_fs(KERNEL_DS);
has_dumped = 1;
+
+ fill_dump(cprm->regs, &dump);
+
strncpy(dump.u_comm, current->comm, sizeof(current->comm));
dump.u_ar0 = offsetof(struct user32, regs);
dump.signal = cprm->siginfo->si_signo;
- dump_thread32(cprm->regs, &dump);
/*
* If the size of the dump file exceeds the rlimit, then see
diff --git a/arch/x86/include/asm/intel-family.h
b/arch/x86/include/asm/intel-family.h
index d9a9993af882..9f15384c504a 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -52,6 +52,8 @@
#define INTEL_FAM6_CANNONLAKE_MOBILE 0x66
+#define INTEL_FAM6_ICELAKE_MOBILE 0x7E
+
/* "Small Core" Processors (Atom) */
#define INTEL_FAM6_ATOM_BONNELL0x1C /* Diamondville, Pineview
*/
diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
index e652a7cc6186..3f697a9e3f59 100644
--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -48,7 +48,8 @@ enum {
BIOS_STATUS_SUCCESS = 0,
BIOS_STATUS_UNIMPLEMENTED = -ENOSYS,
BIOS_STATUS_EINVAL = -EINVAL,
- BIOS_STATUS_UNAVAIL = -EBUSY
+ BIOS_STATUS_UNAVAIL = -EBUSY,
+ BIOS_STATUS_ABORT = -EINTR,
};
/* Address map parameters */
@@ -167,4 +168,9 @@ extern long system_serial_number;
extern struct kobject *sgi_uv_kobj;/* /sys/firmware/sgi_uv */
+/*
+ * EFI runtime lock; cf. firmware/efi/runtime-wrappers.c for details
+ */
+extern struct semaphore __efi_uv_runtime_lock;
+
#endif /* _ASM_X86_UV_BIOS_H */
diff --git a/arch/x86/platform/uv/bios_uv.c b/arch/x86/platform/uv/bios_uv.c
index 4a6a5a26c582..eb33432f2f24 100644
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -29,7 +29,8 @@
struct uv_systab *uv_systab;
-s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64
a5)
+static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
+ u64 a4, u64 a5)
{
struct uv_systab *tab = uv_systab;
s64 ret;
@@ -51,6 +52,19 @@ s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64
a3, u64 a4, u64 a5)
return ret;
}
+
+s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64
a5)
+{
+ s64 ret;
+
+ if (down_interruptible(&__efi_uv_runtime_lock))
+ return BIOS_STATUS_ABORT;
+
+ ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
+ up(&__efi_uv_runtime_lock);
+
+ return ret;
+}
EXPORT_SYMBOL_GPL(uv_bios_call);
s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -59,10 +73,15 @@ s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1,
u64 a2, u64 a3,
unsigned long bios_flags;
s64 ret
Re: [Xen-devel][PATCH 2/2] xen/gntdev: Check and release imported dma-bufs on close
On 14/02/2019 15:23, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Check if there are any imported dma-bufs left not released by > user-space when grant device's release callback is called and > free those if this is the case. This can happen if user-space > leaks the buffers because of a bug or application has been > terminated for any reason. > > Signed-off-by: Oleksandr Andrushchenko Applied-to: xen/tip.git for-linus-5.1 Juergen
Re: [Xen-devel][PATCH 1/2] xen/gntdev: Do not destroy context while dma-bufs are in use
On 14/02/2019 15:23, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > If there are exported DMA buffers which are still in use and > grant device is closed by either normal user-space close or by > a signal this leads to the grant device context to be destroyed, > thus making it not possible to correctly destroy those exported > buffers when they are returned back to gntdev and makes the module > crash: > > [ 339.617540] [] dmabuf_exp_ops_release+0x40/0xa8 > [ 339.617560] [] dma_buf_release+0x60/0x190 > [ 339.617577] [] __fput+0x88/0x1d0 > [ 339.617589] [] fput+0xc/0x18 > [ 339.617607] [] task_work_run+0x9c/0xc0 > [ 339.617622] [] do_notify_resume+0xfc/0x108 > > Fix this by referencing gntdev on each DMA buffer export and > unreferencing on buffer release. > > Signed-off-by: Oleksandr Andrushchenko Applied to xen/tip.git for-linus-5.1 Juergen
Re: [PATCH] arm64: dts: rockchip: add HDMI sound node for rk3328-rock64
Hello Heiko, On 2019/02/12 20:12, Heiko Stübner wrote: Hi, Am Montag, 4. Februar 2019, 13:59:37 CET schrieb Katsuhiro Suzuki: On 2019/02/03 18:06, Heiko Stuebner wrote: Am Samstag, 2. Februar 2019, 05:34:44 CET schrieb Katsuhiro Suzuki: This patch adds HDMI sound (I2S0) node and remove dma properties from UART2 node for rock64. The DMAC of rk3328 can use 8 channels at same time. Currently, total 7 channels are used as follows: - I2S1 2ch - UART2 2ch - SPDIF 1ch - SPI0 2ch HDMI audio using I2S0 that requires 2ch but DMAC has only 1 channel. UART2 can work without DMA resources, so this patch removes dma allocation for UART2 and reuses it to I2S0. I don't follow that description. How can i2s0 re-use the uart2 dma channels? Looking at the dma table in the TRM, uart2 has channels 6+7 while i2s0 uses channels 11+12. They should just run concurrently? Sorry for confusing... 6 or 7 is as ID number of slave DMA channel. TRM calls it 'Req number'. Req number 6+7 and 11+12 can work concurrently but TRM says DMAC can transfer 8 DMA channels at same time. So all 16 Req numbers cannot activate at same time. It should be keep less or equal than 8 numbers. But that "shortcoming" of having more requests than channels is not something specific to the pl330, instead most dma controllers have that "problem", which seems to get solved by the virt-dma mechanism of dmaengine - which pl330 doesn't use so far. (but see pl080 for example) I understand. I drop these patches. The devicetree only describes the hardware and is never meant as a configuration space for kernel-code shortcomings. Yes, right. I don't want to use device-tree as configuration space, so which is better? - Fix the pl330 driver first and after that add HDMI-sound node to device-tree. - Just add HDMI-sound node to device-tree. If someone (include me) want to support virt-dma on pl330 driver, they will fix it. (PL330 will face error but all sounds works fine and UART still works fine with DMA error) Heiko Best Regards, Katsuhiro Suzuki
[RFC GIT PULL] EFI fixes, memblock quirk
Linus,
Please pull the latest efi-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
efi-urgent-for-linus
# HEAD: 582a32e708823e5957fd73ccd78dc4a9e49d21ea efi/arm: Revert "Defer
persistent reservations until after paging_init()"
This tree reverts a GICv3 commit (which was broken) and fixes it in
another way, by adding a memblock build-time entries quirk for ARM64.
I marked it RFC: please have a second look at the mm/memblock.c change,
which adds a INIT_MEMBLOCK_RESERVED_REGIONS detour that ARM64 takes for
these systems.
Perhaps we should upgrade the build time sizing of all platforms to
INIT_MEMBLOCK_REGIONS+NR_CPUS+1 and thus centrally give an extra
allocation entry per CPU configured?
Or is there some cleaner solution?
Thanks,
Ingo
-->
Ard Biesheuvel (2):
arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve
table
efi/arm: Revert "Defer persistent reservations until after paging_init()"
arch/arm64/include/asm/memory.h | 11 +++
arch/arm64/kernel/setup.c | 1 -
drivers/firmware/efi/efi.c | 4
drivers/firmware/efi/libstub/arm-stub.c | 3 ---
include/linux/efi.h | 7 ---
include/linux/memblock.h| 3 ---
mm/memblock.c | 11 +--
7 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index e1ec947e7c0c..0c656850eeea 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -332,6 +332,17 @@ static inline void *phys_to_virt(phys_addr_t x)
#define virt_addr_valid(kaddr) \
(_virt_addr_is_linear(kaddr) && _virt_addr_valid(kaddr))
+/*
+ * Given that the GIC architecture permits ITS implementations that can only be
+ * configured with a LPI table address once, GICv3 systems with many CPUs may
+ * end up reserving a lot of different regions after a kexec for their LPI
+ * tables (one per CPU), as we are forced to reuse the same memory after kexec
+ * (and thus reserve it persistently with EFI beforehand)
+ */
+#if defined(CONFIG_EFI) && defined(CONFIG_ARM_GIC_V3_ITS)
+# define INIT_MEMBLOCK_RESERVED_REGIONS(INIT_MEMBLOCK_REGIONS +
NR_CPUS + 1)
+#endif
+
#include
#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4b0e1231625c..d09ec76f08cf 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,7 +313,6 @@ void __init setup_arch(char **cmdline_p)
arm64_memblock_init();
paging_init();
- efi_apply_persistent_mem_reservations();
acpi_table_upgrade();
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 4c46ff6f2242..55b77c576c42 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -592,11 +592,7 @@ int __init efi_config_parse_tables(void *config_tables,
int count, int sz,
early_memunmap(tbl, sizeof(*tbl));
}
- return 0;
-}
-int __init efi_apply_persistent_mem_reservations(void)
-{
if (efi.mem_reserve != EFI_INVALID_TABLE_ADDR) {
unsigned long prsv = efi.mem_reserve;
diff --git a/drivers/firmware/efi/libstub/arm-stub.c
b/drivers/firmware/efi/libstub/arm-stub.c
index eee42d5e25ee..c037c6c5d0b7 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -75,9 +75,6 @@ void install_memreserve_table(efi_system_table_t
*sys_table_arg)
efi_guid_t memreserve_table_guid = LINUX_EFI_MEMRESERVE_TABLE_GUID;
efi_status_t status;
- if (IS_ENABLED(CONFIG_ARM))
- return;
-
status = efi_call_early(allocate_pool, EFI_LOADER_DATA, sizeof(*rsv),
(void **)&rsv);
if (status != EFI_SUCCESS) {
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 45ff763fba76..28604a8d0aa9 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1198,8 +1198,6 @@ static inline bool efi_enabled(int feature)
extern void efi_reboot(enum reboot_mode reboot_mode, const char *__unused);
extern bool efi_is_table_address(unsigned long phys_addr);
-
-extern int efi_apply_persistent_mem_reservations(void);
#else
static inline bool efi_enabled(int feature)
{
@@ -1218,11 +1216,6 @@ static inline bool efi_is_table_address(unsigned long
phys_addr)
{
return false;
}
-
-static inline int efi_apply_persistent_mem_reservations(void)
-{
- return 0;
-}
#endif
extern int efi_status_to_err(efi_status_t status);
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 64c41cf45590..859b55b66db2 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -29,9 +29,6 @@ extern unsigned long max_pfn;
*/
extern unsigned long long max_possible_pfn;
-#define INIT_MEMBLOCK_REGIONS 128
-#define INIT_PHYSMEM_REGIONS 4
-
/*
Re: [PATCH] ARM: dts: rockchip: rk3188-bqedison2qc: remove cap-mmc-highspeed from mmc1 node
Am Samstag, 16. Februar 2019, 11:25:45 CET schrieb Johan Jonker: > The mmc1 pins are used for SDIO with a wifi chip. > The function mmc_sdio_switch_hs() only checks for MMC_CAP_SD_HIGHSPEED and > not for MMC_CAP_MMC_HIGHSPEED, so cap-mmc-highspeed can be removed. > > Signed-off-by: Johan Jonker applied for 5.1 Thanks Heiko
Re: [RFC PATCH 01/31] mm: migrate: Add exchange_pages to exchange two lists of pages.
On Fri, Feb 15, 2019 at 02:08:26PM -0800, Zi Yan wrote:
> +struct page_flags {
> + unsigned int page_error :1;
> + unsigned int page_referenced:1;
> + unsigned int page_uptodate:1;
> + unsigned int page_active:1;
> + unsigned int page_unevictable:1;
> + unsigned int page_checked:1;
> + unsigned int page_mappedtodisk:1;
> + unsigned int page_dirty:1;
> + unsigned int page_is_young:1;
> + unsigned int page_is_idle:1;
> + unsigned int page_swapcache:1;
> + unsigned int page_writeback:1;
> + unsigned int page_private:1;
> + unsigned int __pad:3;
> +};
I'm not sure how to feel about this. It's a bit fragile versus somebody adding
new page flags. I don't know whether it's needed or whether you can just
copy page->flags directly because you're holding PageLock.
> +static void exchange_page(char *to, char *from)
> +{
> + u64 tmp;
> + int i;
> +
> + for (i = 0; i < PAGE_SIZE; i += sizeof(tmp)) {
> + tmp = *((u64 *)(from + i));
> + *((u64 *)(from + i)) = *((u64 *)(to + i));
> + *((u64 *)(to + i)) = tmp;
> + }
> +}
I have a suspicion you'd be better off allocating a temporary page and
using copy_page(). Some architectures have put a lot of effort into
making copy_page() run faster.
> + xa_lock_irq(&to_mapping->i_pages);
> +
> + to_pslot = radix_tree_lookup_slot(&to_mapping->i_pages,
> + page_index(to_page));
This needs to be converted to the XArray. radix_tree_lookup_slot() is
going away soon. You probably need:
XA_STATE(to_xas, &to_mapping->i_pages, page_index(to_page));
This is a lot of code and I'm still trying to get my head aroud it all.
Thanks for putting in this work; it's good to see this approach being
explored.
Re: [PATCH v6] coccinelle: semantic code search for missing put_device()
On Sun, 17 Feb 2019, Markus Elfring wrote:
> > +@search exists@
> > +local idexpression id;
> > +expression x,e,e1;
> > +position p1,p2;
> > +type T,T1,T2;
> > +@@
> > +
> > +id = of_find_device_by_node@p1(x)
> > +... when != e = id
>
> I suggest to increase your software development attention also for
> another implementation detail.
> Source code analysis triggers challenges for safe data flow handling.
> the semantic patch language supports search specifications for
> the exclusion of specific assignments.
>
> Does this SmPL code contain a questionable order for the source
> and target metavariables?
> Can the following variant be more appropriate?
>
> + ... when != id = e
This is possible, but I think unlikely.
>
>
> > +if (id == NULL || ...) { ... return ...; }
> > +... when != put_device(&id->dev)
> > +when != platform_device_put(id)
> > +when != of_dev_put(id)
> > +when != if (id) { ... put_device(&id->dev) ... }
> > +when != e1 = (T)id
>
> Would you like to avoid that the return value from the shown function call
> gets overwritten in the variable before it was used once at least
> (when a bit of extra C code is tolerated before a null pointer check)?
Indeed there should be a put then too, but again, it seems unlikely.
julia
>
> Regards,
> Markus
>
Re: [PATCH v6] coccinelle: semantic code search for missing put_device()
>>> +@search exists@ >>> +local idexpression id; >>> +expression x,e,e1; >>> +position p1,p2; >>> +type T,T1,T2; >>> +@@ >>> + >>> +id = of_find_device_by_node@p1(x) >>> +... when != e = id >> >> I suggest to increase your software development attention also for >> another implementation detail. >> Source code analysis triggers challenges for safe data flow handling. >> the semantic patch language supports search specifications for >> the exclusion of specific assignments. >> >> Does this SmPL code contain a questionable order for the source >> and target metavariables? >> Can the following variant be more appropriate? >> >> + ... when != id = e > > This is possible, but I think unlikely. Would you dare to interpret my update suggestion (reordering of two identifiers) as a required SmPL script correction? Regards, Markus
Re: [PATCH v6] coccinelle: semantic code search for missing put_device()
On Sun, 17 Feb 2019, Markus Elfring wrote: > >>> +@search exists@ > >>> +local idexpression id; > >>> +expression x,e,e1; > >>> +position p1,p2; > >>> +type T,T1,T2; > >>> +@@ > >>> + > >>> +id = of_find_device_by_node@p1(x) > >>> +... when != e = id > >> > >> I suggest to increase your software development attention also for > >> another implementation detail. > >> Source code analysis triggers challenges for safe data flow handling. > >> the semantic patch language supports search specifications for > >> the exclusion of specific assignments. > >> > >> Does this SmPL code contain a questionable order for the source > >> and target metavariables? > >> Can the following variant be more appropriate? > >> > >> + ... when != id = e > > > > This is possible, but I think unlikely. > > Would you dare to interpret my update suggestion (reordering of two > identifiers) > as a required SmPL script correction? I didn't suggest to reorder anything. Both are needed. And, no I don't consider it to be a required suggestion. In practice, reassigning such a variable is very unlikely. julia
Re: [v6] coccinelle: semantic code search for missing put_device()
>> Would you dare to interpret my update suggestion (reordering of two >> identifiers) >> as a required SmPL script correction? > > I didn't suggest to reorder anything. This is obvious according to your acknowledgement for the sixth version of this evolving SmPL script. > Both are needed. If you would insist on the specification of such an assignment exclusion for a SmPL ellipsis: Can we agree on a correct order? > And, no I don't consider it to be a required suggestion. Have we got a different view about an implementation detail at this place? > In practice, reassigning such a variable is very unlikely. This can be. Regards, Markus
Re: [v6] coccinelle: semantic code search for missing put_device()
On Sun, 17 Feb 2019, Markus Elfring wrote: > >> Would you dare to interpret my update suggestion (reordering of two > >> identifiers) > >> as a required SmPL script correction? > > > > I didn't suggest to reorder anything. > > This is obvious according to your acknowledgement for the sixth version > of this evolving SmPL script. > > > > Both are needed. > > If you would insist on the specification of such an assignment exclusion > for a SmPL ellipsis: > Can we agree on a correct order? I don't get your point. There is no correct order. Each order expresses something different. The order that is currently in the semantic patch is the one that is more likely in practice. julia > > > > And, no I don't consider it to be a required suggestion. > > Have we got a different view about an implementation detail at this place? > > > > In practice, reassigning such a variable is very unlikely. > > This can be. > > Regards, > Markus >
Re: [v6] coccinelle: semantic code search for missing put_device()
>> If you would insist on the specification of such an assignment exclusion >> for a SmPL ellipsis: >> Can we agree on a correct order? > > I don't get your point. I propose to take another closer look at a bit of SmPL code. > There is no correct order. I have got an other software development view here. > Each order expresses something different. I agree to this information. > The order that is currently in the semantic patch is the one > that is more likely in practice. Please check once more. … +@search exists@ +local idexpression id; +expression x,e,e1; +position p1,p2; … +@@ + +id = of_find_device_by_node@p1(x) +... when != e = id … Or: … + ... when != id = e … Which SmPL specification will achieve the desired software behaviour? Regards, Markus
Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs
Hi, On 2/16/19 11:03 PM, Hans de Goede wrote: Hi, On 2/16/19 10:54 PM, Jacek Anaszewski wrote: On 2/16/19 8:37 PM, Pavel Machek wrote: Hi! I think that should work fine, which means that we can use the timer and pattern trigger support for the blinking and breathing modes. That still leaves the switching between user and hw-control modes, as discussed the hw-controlled mode could be modelled as a new "hardware" trigger, but then we cannot choose between on/blink/breathing when in hw-controlled mode. As Pavel mentioned, that would require some sort of composed trigger, where we have both the hardware and timer triggers active for example. I think it might be easier to just allow turning on/off the hardware control mode through a special "hardware_control" sysfs attribute and then use the existing timer and pattern triggers for blinking / breathing. Pattern trigger exposes pattern file by default and hw_pattern if pattern_set/get ops are provided. Writing them enables software and hardware pattern respectively. This is not about software vs hardware pattern. There are 2 *orthogonal*, separate problems/challenges with this LED controller: 1) It has hardware blinking and breathing, as discussed this can be controlled through the timer and pattern triggers, so this problem is solved. 2) It has 2 operating modes: a) Automatic/hardware controlled, in this mode the LED is turned off or on (where on can be continues on, blinking or breathing) by the hardware itself, when in this mode we / userspace is not in control of the LED b) Manual/user controlled mode, in this mode we / userspace can control of the LED. Currently there is no API in the ledclass to switch a LED from automatic controlled to user controlled and back, This is what the proposed hardware trigger was for, to switch to automatic mode. A problem with this is that we still want to be able to chose between continues on, blinking or breathing (when on), configure the max brightness, etc. Yes, we do have the API to switch a LED from automatic (hardware accelerated) control to software control and back. This is pattern trigger, which exposes two files for setting pattern: pattern and hw_pattern. Writing pattern file switches the device to software control mode and writing hw_pattern switches it to the hardware control, with the possibility of defining device specific ABI syntax to enable particular pattern (blinking, breathing or event permanently on in case of this device). OK, I see. So we would use the hw_pattern for this and the driver would implement the pattern_set led_classdev callback. The pattern_set callback would then expect 6 brightness/time tuples with the following meaning for the time part of each tupple tupple0: charging blinking_on_time tupple1: charging blinking_off_time tupple2: charging breathing_time tupple3: manual blinking_on_time tupple4: manual blinking_off_time tupple5: manual breathing_time Where only the times in tupple 0-2; or the times in 3-5 can be non-zero. Having non zero times for both some charging and some manual values is not allowed. If a breathing time is set, none of the other times may be non 0. If blinkig_on and blinking_off are used then breathing_time must be 0. When configured to blink then blinking_off must be either 0 (continuously on); or it must be the same as blinking_on. I believe this will work, does this sound ok to you ? I don't pretend to fully understand it, _but_ hw_pattern should really describe the pattern LED should do, not whether it reacts to charging or not. This is hardware specific and is supposed to have dedicated ABI documentation. There's no reason to introduce new mechanisms when existing ones fit. It will still describe a pattern but activated on some condition. Right, but we can control the condition, so either we need to make the condition part of the pattern as in my recent proposal with: tupple0: charging blinking_on_time tupple1: charging blinking_off_time tupple2: charging breathing_time tupple3: manual blinking_on_time tupple4: manual blinking_off_time tupple5: manual breathing_time As hw_pattern ABI; or we need to add an extra sysfs file to set the condition. So do you prefer the driver to code the condition into the hw_pattern (see above); or do you prefer a separate sysfs attribute for the condition? OK, so we'll need to add hardware_controlled file to the LED core. It should be exposed only when supported by the hardware, so we will need the flag in leds.h: #define LED_DEV_CAP_HW_CONTROL BIT(24) -- Best regards, Jacek Anaszewski
Re: [PATCH] netfilter/ipvs: Fix unused variable warning
On Sat, Feb 16, 2019 at 11:33:58PM +0100, Borislav Petkov wrote: > From: Borislav Petkov > > Move the local variable 'ret' into the IP_VS_IPV6 ifdef so that the > unused variable warning doesn't fire for randconfig builds with > CONFIG_IP_VS_IPV6 disabled. Thanks! We already have a patch for this, will pass it to David asap. https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git/commit/?id=c93a49b9769e435990c82297aa0baa31e1538790
Re: [v6] coccinelle: semantic code search for missing put_device()
On Sun, 17 Feb 2019, Markus Elfring wrote: > >> If you would insist on the specification of such an assignment exclusion > >> for a SmPL ellipsis: > >> Can we agree on a correct order? > > > > I don't get your point. > > I propose to take another closer look at a bit of SmPL code. > > > > There is no correct order. > > I have got an other software development view here. > > > > Each order expresses something different. > > I agree to this information. > > > > The order that is currently in the semantic patch is the one > > that is more likely in practice. > > Please check once more. > > … > +@search exists@ > +local idexpression id; > +expression x,e,e1; > +position p1,p2; > … > +@@ > + > +id = of_find_device_by_node@p1(x) > +... when != e = id > … > > Or: > > … > + ... when != id = e > … > > > Which SmPL specification will achieve the desired software behaviour? The desired behavior is to check whether the allocated value is saved in some other variable (typically a structure field) and thus it doesn't need to be freed just because the original local variable goes out of scope at the end of the function. when != e = id achieves this behavior. julia
Re: [PATCH V15 00/18] block: support multi-page bvec
On Fri, Feb 15, 2019 at 03:51:26PM +0100, Christoph Hellwig wrote: > I still don't understand why mp_bvec_last_segment isn't simply > called bvec_last_segment as there is no conflict. But I don't > want to hold this series up on that as there only are two users > left and we can always just fix it up later. mp_bvec_last_segment() is one bvec helper, so better to keep its name consistent with other bvec helpers. Thanks, Ming
Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
On Fri, Feb 15, 2019 at 09:14:15AM -0800, Bart Van Assche wrote:
> On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
> > On 2/15/19 4:13 AM, Ming Lei wrote:
> > > This patchset brings multi-page bvec into block layer:
> >
> > Applied, thanks Ming. Let's hope it sticks!
>
> Hi Jens and Ming,
>
> Test nvmeof-mp/002 fails with Jens' for-next branch from this morning.
> I have not yet tried to figure out which patch introduced the failure.
> Anyway, this is what I see in the kernel log for test nvmeof-mp/002:
>
> [ 475.611363] BUG: unable to handle kernel NULL pointer dereference at
> 0020
> [ 475.621188] #PF error: [normal kernel read fault]
> [ 475.623148] PGD 0 P4D 0
> [ 475.624737] Oops: [#1] PREEMPT SMP KASAN
> [ 475.626628] CPU: 1 PID: 277 Comm: kworker/1:1H Tainted: GB
> 5.0.0-rc6-dbg+ #1
> [ 475.630232] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 475.633855] Workqueue: kblockd blk_mq_requeue_work
> [ 475.635777] RIP: 0010:__blk_recalc_rq_segments+0xbe/0x590
> [ 475.670948] Call Trace:
> [ 475.693515] blk_recalc_rq_segments+0x2f/0x50
> [ 475.695081] blk_insert_cloned_request+0xbb/0x1c0
> [ 475.701142] dm_mq_queue_rq+0x3d1/0x770
> [ 475.707225] blk_mq_dispatch_rq_list+0x5fc/0xb10
> [ 475.717137] blk_mq_sched_dispatch_requests+0x256/0x300
> [ 475.721767] __blk_mq_run_hw_queue+0xd6/0x180
> [ 475.725920] __blk_mq_delay_run_hw_queue+0x25c/0x290
> [ 475.727480] blk_mq_run_hw_queue+0x119/0x1b0
> [ 475.732019] blk_mq_run_hw_queues+0x7b/0xa0
> [ 475.733468] blk_mq_requeue_work+0x2cb/0x300
> [ 475.736473] process_one_work+0x4f1/0xa40
> [ 475.739424] worker_thread+0x67/0x5b0
> [ 475.741751] kthread+0x1cf/0x1f0
> [ 475.746034] ret_from_fork+0x24/0x30
>
> (gdb) list *(__blk_recalc_rq_segments+0xbe)
> 0x816a152e is in __blk_recalc_rq_segments (block/blk-merge.c:366).
> 361 struct bio *bio)
> 362 {
> 363 struct bio_vec bv, bvprv = { NULL };
> 364 int prev = 0;
> 365 unsigned int seg_size, nr_phys_segs;
> 366 unsigned front_seg_size = bio->bi_seg_front_size;
> 367 struct bio *fbio, *bbio;
> 368 struct bvec_iter iter;
> 369
> 370 if (!bio)
>
> Bart.
Thanks for your test!
The following patch should fix this issue:
diff --git a/block/blk-merge.c b/block/blk-merge.c
index bed065904677..066b66430523 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -363,13 +363,15 @@ static unsigned int __blk_recalc_rq_segments(struct
request_queue *q,
struct bio_vec bv, bvprv = { NULL };
int prev = 0;
unsigned int seg_size, nr_phys_segs;
- unsigned front_seg_size = bio->bi_seg_front_size;
+ unsigned front_seg_size;
struct bio *fbio, *bbio;
struct bvec_iter iter;
if (!bio)
return 0;
+ front_seg_size = bio->bi_seg_front_size;
+
switch (bio_op(bio)) {
case REQ_OP_DISCARD:
case REQ_OP_SECURE_ERASE:
Thanks,
Ming
Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
On Fri, Feb 15, 2019 at 10:59:47AM -0700, Jens Axboe wrote:
> On 2/15/19 10:14 AM, Bart Van Assche wrote:
> > On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
> >> On 2/15/19 4:13 AM, Ming Lei wrote:
> >>> This patchset brings multi-page bvec into block layer:
> >>
> >> Applied, thanks Ming. Let's hope it sticks!
> >
> > Hi Jens and Ming,
> >
> > Test nvmeof-mp/002 fails with Jens' for-next branch from this morning.
> > I have not yet tried to figure out which patch introduced the failure.
> > Anyway, this is what I see in the kernel log for test nvmeof-mp/002:
> >
> > [ 475.611363] BUG: unable to handle kernel NULL pointer dereference at
> > 0020
> > [ 475.621188] #PF error: [normal kernel read fault]
> > [ 475.623148] PGD 0 P4D 0
> > [ 475.624737] Oops: [#1] PREEMPT SMP KASAN
> > [ 475.626628] CPU: 1 PID: 277 Comm: kworker/1:1H Tainted: GB
> > 5.0.0-rc6-dbg+ #1
> > [ 475.630232] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.10.2-1 04/01/2014
> > [ 475.633855] Workqueue: kblockd blk_mq_requeue_work
> > [ 475.635777] RIP: 0010:__blk_recalc_rq_segments+0xbe/0x590
> > [ 475.670948] Call Trace:
> > [ 475.693515] blk_recalc_rq_segments+0x2f/0x50
> > [ 475.695081] blk_insert_cloned_request+0xbb/0x1c0
> > [ 475.701142] dm_mq_queue_rq+0x3d1/0x770
> > [ 475.707225] blk_mq_dispatch_rq_list+0x5fc/0xb10
> > [ 475.717137] blk_mq_sched_dispatch_requests+0x256/0x300
> > [ 475.721767] __blk_mq_run_hw_queue+0xd6/0x180
> > [ 475.725920] __blk_mq_delay_run_hw_queue+0x25c/0x290
> > [ 475.727480] blk_mq_run_hw_queue+0x119/0x1b0
> > [ 475.732019] blk_mq_run_hw_queues+0x7b/0xa0
> > [ 475.733468] blk_mq_requeue_work+0x2cb/0x300
> > [ 475.736473] process_one_work+0x4f1/0xa40
> > [ 475.739424] worker_thread+0x67/0x5b0
> > [ 475.741751] kthread+0x1cf/0x1f0
> > [ 475.746034] ret_from_fork+0x24/0x30
> >
> > (gdb) list *(__blk_recalc_rq_segments+0xbe)
> > 0x816a152e is in __blk_recalc_rq_segments (block/blk-merge.c:366).
> > 361 struct bio *bio)
> > 362 {
> > 363 struct bio_vec bv, bvprv = { NULL };
> > 364 int prev = 0;
> > 365 unsigned int seg_size, nr_phys_segs;
> > 366 unsigned front_seg_size = bio->bi_seg_front_size;
> > 367 struct bio *fbio, *bbio;
> > 368 struct bvec_iter iter;
> > 369
> > 370 if (!bio)
>
> Just ran a few tests, and it also seems to cause about a 5% regression
> in per-core IOPS throughput. Prior to this work, I could get 1620K 4k
> rand read IOPS out of core, now I'm at ~1535K. The cycler stealer seems
> to be blk_queue_split() and blk_rq_map_sg().
Could you share us your test setting?
I will run null_blk first and see if it can be reproduced.
Thanks,
Ming
Re: [v6] coccinelle: semantic code search for missing put_device()
>> … >> +@search exists@ >> +local idexpression id; >> +expression x,e,e1; >> +position p1,p2; >> … >> +@@ >> + >> +id = of_find_device_by_node@p1(x) >> +... when != e = id >> … >> >> Or: >> >> … >> + ... when != id = e >> … >> >> >> Which SmPL specification will achieve the desired software behaviour? > > The desired behavior is to check whether the allocated value is saved in > some other variable (typically a structure field) and thus it doesn't need > to be freed just because the original local variable goes out of scope at > the end of the function. I find this description reasonable to some degree. (I am unsure if a programmer would like to fiddle with return value storage in a data structure member from a local variable.) > when != e = id achieves this behavior. I can not agree to this view completely because of the meaning that is connected with these variable identifiers. Both metavariables share the kind “expression”. So I can imagine that there is an intersection for the source code match possibility. But one was intentionally restricted to the kind “local idexpression” so far. Which data element should not get reassigned here (before a corresponding null pointer check)? Regards, Markus
Re: [PATCH] arm64: dts: rockchip: add HDMI sound node for rk3328-rock64
Am Sonntag, 17. Februar 2019, 11:58:36 CET schrieb Katsuhiro Suzuki: > Hello Heiko, > > On 2019/02/12 20:12, Heiko Stübner wrote: > > Hi, > > > > Am Montag, 4. Februar 2019, 13:59:37 CET schrieb Katsuhiro Suzuki: > >> On 2019/02/03 18:06, Heiko Stuebner wrote: > >>> Am Samstag, 2. Februar 2019, 05:34:44 CET schrieb Katsuhiro Suzuki: > This patch adds HDMI sound (I2S0) node and remove dma properties > from UART2 node for rock64. > > The DMAC of rk3328 can use 8 channels at same time. Currently, total > > 7 channels are used as follows: > - I2S1 2ch > - UART2 2ch > - SPDIF 1ch > - SPI0 2ch > > HDMI audio using I2S0 that requires 2ch but DMAC has only 1 channel. > > UART2 can work without DMA resources, so this patch removes dma > allocation for UART2 and reuses it to I2S0. > >>> > >>> I don't follow that description. How can i2s0 re-use the uart2 dma > >>> channels? Looking at the dma table in the TRM, uart2 has channels 6+7 > >>> while i2s0 uses channels 11+12. They should just run concurrently? > >> > >> Sorry for confusing... 6 or 7 is as ID number of slave DMA channel. > >> TRM calls it 'Req number'. Req number 6+7 and 11+12 can work > >> concurrently but TRM says DMAC can transfer 8 DMA channels at same > >> time. So all 16 Req numbers cannot activate at same time. It should > >> be keep less or equal than 8 numbers. > > > > But that "shortcoming" of having more requests than channels is not > > something specific to the pl330, instead most dma controllers have that > > "problem", which seems to get solved by the virt-dma mechanism of > > dmaengine - which pl330 doesn't use so far. (but see pl080 for example) > > > > I understand. I drop these patches. > > > > The devicetree only describes the hardware and is never meant as a > > configuration space for kernel-code shortcomings. > > > > Yes, right. I don't want to use device-tree as configuration space, > so which is better? > > - Fix the pl330 driver first and after that add HDMI-sound node >to device-tree. > - Just add HDMI-sound node to device-tree. If someone (include me) >want to support virt-dma on pl330 driver, they will fix it. >(PL330 will face error but all sounds works fine and UART still >works fine with DMA error) I'd go with this second option :-) . Heiko
Re: [PATCH v7 21/23] block: Avoid that flushing triggers a lockdep complaint
On Fri, Feb 15, 2019 at 08:08:08AM -0800, Bart Van Assche wrote:
> On Fri, 2019-02-15 at 10:26 +0800, Ming Lei wrote:
> > There might be lots of blk_flush_queue instance which is allocated
> > for each hctx, then lots of class key slot may be wasted.
> >
> > So I suggest to use one nvmet_loop_flush_lock_key for this particular issue,
> > something like the following patch:
> >
> > diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
> > index 4aac1b4a8112..ec4248c12ed9 100644
> > --- a/drivers/nvme/target/loop.c
> > +++ b/drivers/nvme/target/loop.c
> > @@ -524,7 +524,9 @@ static const struct nvme_ctrl_ops nvme_loop_ctrl_ops = {
> >
> > static int nvme_loop_create_io_queues(struct nvme_loop_ctrl *ctrl)
> > {
> > - int ret;
> > + static struct lock_class_key nvme_loop_flush_lock_key;
> > + int ret, i;
> > + struct blk_mq_hw_ctx *hctx;
> >
> > ret = nvme_loop_init_io_queues(ctrl);
> > if (ret)
> > @@ -553,6 +555,10 @@ static int nvme_loop_create_io_queues(struct
> > nvme_loop_ctrl *ctrl)
> > goto out_free_tagset;
> > }
> >
> > + queue_for_each_hw_ctx(ctrl->ctrl.connect_q, hctx, i)
> > + lockdep_set_class(&hctx->fq->mq_flush_lock,
> > + &nvme_loop_flush_lock_key);
> > +
> > ret = nvme_loop_connect_io_queues(ctrl);
> > if (ret)
> > goto out_cleanup_connect_q;
>
> Hi Ming,
>
> Thanks for your feedback.
>
> Are you aware that sizeof(struct lock_class_key) is zero if lockdep is
> disabled?
Yes.
> Does this alleviate your concern?
No, I mean in case of CONFIG_LOCKDP.
1) MAX_LOCKDEP_KEYS is defined as 8k-1
2) lock validation runs as graph search algorithm actually, and each lock
class acts as one graph vertex.
So more lock class will make the lock validation much slower, also lock
class key may be overflow.
>
> I'm not enthusiast about your patch. I don't think that block layer users
> should touch the lock class key of the flush queue. That's a key that should
> be set by the block layer core.
Why? lockdep_set_class is used tree-wide actually.
Thanks,
Ming
Re: [PATCH] drm/mediatek: add mipi_tx driver for mt8183
On Tue, 2019-02-12 at 10:28 +0100, Matthias Brugger wrote: > > On 12/02/2019 07:19, Jitao Shi wrote: > > This patch adds mipi tx driver support for mt8183. > > > > Mipi_tx of mt8183 is very different to mt8173. > > 1.Separate mipi tx setting to mtk_mt8173_mipi_tx.c for mt8173 > > 2.Separate mipi tx setting to mtk_mt8183_mipi_tx.c for mt8183 > > 3.To reuse the common code, make the common functions in mtk_mipi_tx.c > > > > I hadn't a look on the code, but this commit message already indicates, that > you > should split this up in several patches. > Something like this: > 1. patch: carve out common functions to mtk_mipi_tx.c at this point only used > by > mt8173 > 2. patch: add support for mt8183 > > Regards, > Matthias > Thanks for your advice. I'll split it to several patches. Best Regards Jitao > > Signed-off-by: Jitao Shi > > --- > > drivers/gpu/drm/mediatek/Makefile | 2 + > > drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 352 ++ > > drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 52 +++ > > drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++ > > drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 + > > 5 files changed, 549 insertions(+), 315 deletions(-) > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c > > > > diff --git a/drivers/gpu/drm/mediatek/Makefile > > b/drivers/gpu/drm/mediatek/Makefile > > index 82ae49c64221..8067a4be8311 100644 > > --- a/drivers/gpu/drm/mediatek/Makefile > > +++ b/drivers/gpu/drm/mediatek/Makefile > > @@ -12,6 +12,8 @@ mediatek-drm-y := mtk_disp_color.o \ > > mtk_drm_plane.o \ > > mtk_dsi.o \ > > mtk_mipi_tx.o \ > > + mtk_mt8173_mipi_tx.o \ > > + mtk_mt8183_mipi_tx.o \ > > mtk_dpi.o > > > > obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o > > diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > > b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > > index 90e913108950..7591a38ca565 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > > +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c > > @@ -11,292 +11,45 @@ > > * GNU General Public License for more details. > > */ > > > > -#include > > -#include > > -#include > > -#include > > -#include > > -#include > > -#include > > -#include > > - > > -#define MIPITX_DSI_CON 0x00 > > -#define RG_DSI_LDOCORE_EN BIT(0) > > -#define RG_DSI_CKG_LDOOUT_EN BIT(1) > > -#define RG_DSI_BCLK_SEL(3 << 2) > > -#define RG_DSI_LD_IDX_SEL (7 << 4) > > -#define RG_DSI_PHYCLK_SEL (2 << 8) > > -#define RG_DSI_DSICLK_FREQ_SEL BIT(10) > > -#define RG_DSI_LPTX_CLMP_ENBIT(11) > > - > > -#define MIPITX_DSI_CLOCK_LANE 0x04 > > -#define MIPITX_DSI_DATA_LANE0 0x08 > > -#define MIPITX_DSI_DATA_LANE1 0x0c > > -#define MIPITX_DSI_DATA_LANE2 0x10 > > -#define MIPITX_DSI_DATA_LANE3 0x14 > > -#define RG_DSI_LNTx_LDOOUT_EN BIT(0) > > -#define RG_DSI_LNTx_CKLANE_EN BIT(1) > > -#define RG_DSI_LNTx_LPTX_IPLUS1BIT(2) > > -#define RG_DSI_LNTx_LPTX_IPLUS2BIT(3) > > -#define RG_DSI_LNTx_LPTX_IMINUSBIT(4) > > -#define RG_DSI_LNTx_LPCD_IPLUS BIT(5) > > -#define RG_DSI_LNTx_LPCD_IMINUSBIT(6) > > -#define RG_DSI_LNTx_RT_CODE(0xf << 8) > > - > > -#define MIPITX_DSI_TOP_CON 0x40 > > -#define RG_DSI_LNT_INTR_EN BIT(0) > > -#define RG_DSI_LNT_HS_BIAS_EN BIT(1) > > -#define RG_DSI_LNT_IMP_CAL_EN BIT(2) > > -#define RG_DSI_LNT_TESTMODE_EN BIT(3) > > -#define RG_DSI_LNT_IMP_CAL_CODE(0xf << 4) > > -#define RG_DSI_LNT_AIO_SEL (7 << 8) > > -#define RG_DSI_PAD_TIE_LOW_EN BIT(11) > > -#define RG_DSI_DEBUG_INPUT_EN BIT(12) > > -#define RG_DSI_PRESERVE(7 << 13) > > - > > -#define MIPITX_DSI_BG_CON 0x44 > > -#define RG_DSI_BG_CORE_EN BIT(0) > > -#define RG_DSI_BG_CKEN BIT(1) > > -#define RG_DSI_BG_DIV (0x3 << 2) > > -#define RG_DSI_BG_FAST_CHARGE BIT(4) > > -#define RG_DSI_VOUT_MSK(0x3 << 5) > > -#define RG_DSI_V12_SEL (7 << 5) > > -#define RG_DSI_V10_SEL (7 << 8) > > -#define RG_DSI_V072_SEL(7 << 11) > > -#define RG_DSI_V04_SEL (7 << 14) > > -#define RG_DSI_V032_SEL(7 << 17) > > -#define RG_DSI_V02_SEL (7 << 20) > > -#define RG_DSI_BG_R1_TRIM (0xf << 24) > > -#define RG_DSI_BG_R2_TRIM (0xf << 28) > > - > > -#define MIPITX_DSI_PLL_CON00x50 > > -#define RG_DSI_MPPLL_PLL_ENBIT(0) > > -#define RG_DSI_MPPLL_DIV
Re: [patch v6 1/7] genirq/affinity: Code consolidation
On Sat, Feb 16, 2019 at 06:13:07PM +0100, Thomas Gleixner wrote:
> All information and calculations in the interrupt affinity spreading code
> is strictly unsigned int. Though the code uses int all over the place.
>
> Convert it over to unsigned int.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/interrupt.h | 20 +---
> kernel/irq/affinity.c | 56
> ++
> 2 files changed, 38 insertions(+), 38 deletions(-)
>
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -251,10 +251,10 @@ struct irq_affinity_notify {
> * @sets:Number of affinitized sets
> */
> struct irq_affinity {
> - int pre_vectors;
> - int post_vectors;
> - int nr_sets;
> - int *sets;
> + unsigned intpre_vectors;
> + unsigned intpost_vectors;
> + unsigned intnr_sets;
> + unsigned int*sets;
> };
>
> /**
> @@ -314,9 +314,10 @@ extern int
> irq_set_affinity_notifier(unsigned int irq, struct irq_affinity_notify
> *notify);
>
> struct irq_affinity_desc *
> -irq_create_affinity_masks(int nvec, const struct irq_affinity *affd);
> +irq_create_affinity_masks(unsigned int nvec, const struct irq_affinity
> *affd);
>
> -int irq_calc_affinity_vectors(int minvec, int maxvec, const struct
> irq_affinity *affd);
> +unsigned int irq_calc_affinity_vectors(unsigned int minvec, unsigned int
> maxvec,
> +const struct irq_affinity *affd);
>
> #else /* CONFIG_SMP */
>
> @@ -350,13 +351,14 @@ irq_set_affinity_notifier(unsigned int i
> }
>
> static inline struct irq_affinity_desc *
> -irq_create_affinity_masks(int nvec, const struct irq_affinity *affd)
> +irq_create_affinity_masks(unsigned int nvec, const struct irq_affinity *affd)
> {
> return NULL;
> }
>
> -static inline int
> -irq_calc_affinity_vectors(int minvec, int maxvec, const struct irq_affinity
> *affd)
> +static inline unsigned int
> +irq_calc_affinity_vectors(unsigned int minvec, unsigned int maxvec,
> + const struct irq_affinity *affd)
> {
> return maxvec;
> }
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -9,7 +9,7 @@
> #include
>
> static void irq_spread_init_one(struct cpumask *irqmsk, struct cpumask *nmsk,
> - int cpus_per_vec)
> + unsigned int cpus_per_vec)
> {
> const struct cpumask *siblmsk;
> int cpu, sibl;
> @@ -95,15 +95,17 @@ static int get_nodes_in_cpumask(cpumask_
> }
>
> static int __irq_build_affinity_masks(const struct irq_affinity *affd,
> - int startvec, int numvecs, int firstvec,
> + unsigned int startvec,
> + unsigned int numvecs,
> + unsigned int firstvec,
> cpumask_var_t *node_to_cpumask,
> const struct cpumask *cpu_mask,
> struct cpumask *nmsk,
> struct irq_affinity_desc *masks)
> {
> - int n, nodes, cpus_per_vec, extra_vecs, done = 0;
> - int last_affv = firstvec + numvecs;
> - int curvec = startvec;
> + unsigned int n, nodes, cpus_per_vec, extra_vecs, done = 0;
> + unsigned int last_affv = firstvec + numvecs;
> + unsigned int curvec = startvec;
> nodemask_t nodemsk = NODE_MASK_NONE;
>
> if (!cpumask_weight(cpu_mask))
> @@ -117,18 +119,16 @@ static int __irq_build_affinity_masks(co
>*/
> if (numvecs <= nodes) {
> for_each_node_mask(n, nodemsk) {
> - cpumask_or(&masks[curvec].mask,
> - &masks[curvec].mask,
> - node_to_cpumask[n]);
> + cpumask_or(&masks[curvec].mask, &masks[curvec].mask,
> +node_to_cpumask[n]);
> if (++curvec == last_affv)
> curvec = firstvec;
> }
> - done = numvecs;
> - goto out;
> + return numvecs;
> }
>
> for_each_node_mask(n, nodemsk) {
> - int ncpus, v, vecs_to_assign, vecs_per_node;
> + unsigned int ncpus, v, vecs_to_assign, vecs_per_node;
>
> /* Spread the vectors per node */
> vecs_per_node = (numvecs - (curvec - firstvec)) / nodes;
> @@ -163,8 +163,6 @@ static int __irq_build_affinity_masks(co
> curvec = firstvec;
> --nodes;
> }
> -
> -out:
> return done;
> }
>
> @@ -174,13 +172,14 @@ static int __irq_build_affinity_masks(co
> * 2) spread other possible CPUs on these vectors
> */
> static int irq_build_affinity_masks(const struct irq_affinity *affd,
> - i
Re: [patch v6 5/7] genirq/affinity: Remove the leftovers of the original set support
On Sat, Feb 16, 2019 at 06:13:11PM +0100, Thomas Gleixner wrote:
> Now that the NVME driver is converted over to the calc_set() callback, the
> workarounds of the original set support can be removed.
>
> Signed-off-by: Thomas Gleixner
> ---
> kernel/irq/affinity.c | 20
> 1 file changed, 4 insertions(+), 16 deletions(-)
>
> Index: b/kernel/irq/affinity.c
> ===
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -264,20 +264,13 @@ irq_create_affinity_masks(unsigned int n
>
> /*
>* Simple invocations do not provide a calc_sets() callback. Install
> - * the generic one. The check for affd->nr_sets is a temporary
> - * workaround and will be removed after the NVME driver is converted
> - * over.
> + * the generic one.
>*/
> - if (!affd->nr_sets && !affd->calc_sets)
> + if (!affd->calc_sets)
> affd->calc_sets = default_calc_sets;
>
> - /*
> - * If the device driver provided a calc_sets() callback let it
> - * recalculate the number of sets and their size. The check will go
> - * away once the NVME driver is converted over.
> - */
> - if (affd->calc_sets)
> - affd->calc_sets(affd, affvecs);
> + /* Recalculate the sets */
> + affd->calc_sets(affd, affvecs);
>
> if (WARN_ON_ONCE(affd->nr_sets > IRQ_AFFINITY_MAX_SETS))
> return NULL;
> @@ -344,11 +337,6 @@ unsigned int irq_calc_affinity_vectors(u
>
> if (affd->calc_sets) {
> set_vecs = maxvec - resv;
> - } else if (affd->nr_sets) {
> - unsigned int i;
> -
> - for (i = 0, set_vecs = 0; i < affd->nr_sets; i++)
> - set_vecs += affd->set_size[i];
> } else {
> get_online_cpus();
> set_vecs = cpumask_weight(cpu_possible_mask);
>
>
Reviewed-by: Ming Lei
Thanks,
Ming
Re: [patch v6 6/7] PCI/MSI: Remove obsolete sanity checks for multiple interrupt sets
On Sat, Feb 16, 2019 at 06:13:12PM +0100, Thomas Gleixner wrote: > Multiple interrupt sets for affinity spreading are now handled in the core > code and the number of sets and their size is recalculated via a driver > supplied callback. > > That avoids the requirement to invoke pci_alloc_irq_vectors_affinity() with > the arguments minvecs and maxvecs set to the same value and the callsite > handling the ENOSPC situation. > > Remove the now obsolete sanity checks and the related comments. > > Signed-off-by: Thomas Gleixner > > --- > drivers/pci/msi.c | 14 -- > 1 file changed, 14 deletions(-) > > --- a/drivers/pci/msi.c > +++ b/drivers/pci/msi.c > @@ -1035,13 +1035,6 @@ static int __pci_enable_msi_range(struct > if (maxvec < minvec) > return -ERANGE; > > - /* > - * If the caller is passing in sets, we can't support a range of > - * vectors. The caller needs to handle that. > - */ > - if (affd && affd->nr_sets && minvec != maxvec) > - return -EINVAL; > - > if (WARN_ON_ONCE(dev->msi_enabled)) > return -EINVAL; > > @@ -1093,13 +1086,6 @@ static int __pci_enable_msix_range(struc > if (maxvec < minvec) > return -ERANGE; > > - /* > - * If the caller is passing in sets, we can't support a range of > - * supported vectors. The caller needs to handle that. > - */ > - if (affd && affd->nr_sets && minvec != maxvec) > - return -EINVAL; > - > if (WARN_ON_ONCE(dev->msix_enabled)) > return -EINVAL; > > > Reviewed-by: Ming Lei Thanks, Ming
Re: [patch v6 7/7] genirq/affinity: Add support for non-managed affinity sets
Hi Thomas,
On Sat, Feb 16, 2019 at 06:13:13PM +0100, Thomas Gleixner wrote:
> Some drivers need an extra set of interrupts which should not be marked
> managed, but should get initial interrupt spreading.
Could you share the drivers and their use case?
>
> Add a bitmap to struct irq_affinity which allows the driver to mark a
> particular set of interrupts as non managed. Check the bitmap during
> spreading and use the result to mark the interrupts in the sets
> accordingly.
>
> The unmanaged interrupts get initial spreading, but user space can change
> their affinity later on. For the managed sets, i.e. the corresponding bit
> in the mask is not set, there is no change in behaviour.
>
> Usage example:
>
> struct irq_affinity affd = {
> .pre_vectors= 2,
> .unmanaged_sets = 0x02,
> .calc_sets = drv_calc_sets,
> };
>
>
> For both interrupt sets the interrupts are properly spread out, but the
> second set is not marked managed.
Given drivers only care the managed vs non-managed interrupt numbers,
just wondering why this case can't be covered by .pre_vectors &
.post_vectors?
Also this kind of usage may break blk-mq easily, in which the following
rule needs to be respected:
1) all CPUs are required to spread among each interrupt set
2) no any CPU is shared between two IRQs in same set.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/interrupt.h |2 ++
> kernel/irq/affinity.c | 16 +++-
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> Index: b/include/linux/interrupt.h
> ===
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -251,6 +251,7 @@ struct irq_affinity_notify {
> * the MSI(-X) vector space
> * @nr_sets: The number of interrupt sets for which affinity
> * spreading is required
> + * @unmanaged_sets: Bitmap to mark entries in the @set_size array unmanaged
> * @set_size:Array holding the size of each interrupt set
> * @calc_sets: Callback for calculating the number and size
> * of interrupt sets
> @@ -261,6 +262,7 @@ struct irq_affinity {
> unsigned intpre_vectors;
> unsigned intpost_vectors;
> unsigned intnr_sets;
> + unsigned intunmanaged_sets;
> unsigned intset_size[IRQ_AFFINITY_MAX_SETS];
> void(*calc_sets)(struct irq_affinity *, unsigned int nvecs);
> void*priv;
> Index: b/kernel/irq/affinity.c
> ===
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -249,6 +249,8 @@ irq_create_affinity_masks(unsigned int n
> unsigned int affvecs, curvec, usedvecs, i;
> struct irq_affinity_desc *masks = NULL;
>
> + BUILD_BUG_ON(IRQ_AFFINITY_MAX_SETS > sizeof(affd->unmanaged_sets) * 8);
> +
> /*
>* Determine the number of vectors which need interrupt affinities
>* assigned. If the pre/post request exhausts the available vectors
> @@ -292,7 +294,8 @@ irq_create_affinity_masks(unsigned int n
>* have multiple sets, build each sets affinity mask separately.
>*/
> for (i = 0, usedvecs = 0; i < affd->nr_sets; i++) {
> - unsigned int this_vecs = affd->set_size[i];
> + bool managed = affd->unmanaged_sets & (1U << i) ? true : false;
The above check is inverted.
Thanks,
Ming
[PATCH 1/2] regulator: twl6030: Use regulator_list_voltage_linear_range for twl6030ldo_ops
Use linear range to replace the twl6030ldo_list_voltage implementation.
With this change, the min_mV is not used and can be removed from
struct twlreg_info.
Signed-off-by: Axel Lin
---
drivers/regulator/twl6030-regulator.c | 73 ++-
1 file changed, 27 insertions(+), 46 deletions(-)
diff --git a/drivers/regulator/twl6030-regulator.c
b/drivers/regulator/twl6030-regulator.c
index 78b964539775..dcaa6512d760 100644
--- a/drivers/regulator/twl6030-regulator.c
+++ b/drivers/regulator/twl6030-regulator.c
@@ -31,9 +31,6 @@ struct twlreg_info {
/* twl resource ID, for resource control state machine */
u8 id;
- /* chip constraints on regulator behavior */
- u16 min_mV;
-
u8 flags;
/* used by regulator core */
@@ -252,27 +249,6 @@ static struct regulator_ops twl6030coresmps_ops = {
.get_voltage= twl6030coresmps_get_voltage,
};
-static int twl6030ldo_list_voltage(struct regulator_dev *rdev, unsigned sel)
-{
- struct twlreg_info *info = rdev_get_drvdata(rdev);
-
- switch (sel) {
- case 0:
- return 0;
- case 1 ... 24:
- /* Linear mapping from 0001 to 00011000:
-* Absolute voltage value = 1.0 V + 0.1 V × (sel – 0001)
-*/
- return (info->min_mV + 100 * (sel - 1)) * 1000;
- case 25 ... 30:
- return -EINVAL;
- case 31:
- return 275;
- default:
- return -EINVAL;
- }
-}
-
static int
twl6030ldo_set_voltage_sel(struct regulator_dev *rdev, unsigned selector)
{
@@ -291,7 +267,7 @@ static int twl6030ldo_get_voltage_sel(struct regulator_dev
*rdev)
}
static struct regulator_ops twl6030ldo_ops = {
- .list_voltage = twl6030ldo_list_voltage,
+ .list_voltage = regulator_list_voltage_linear_range,
.set_voltage_sel = twl6030ldo_set_voltage_sel,
.get_voltage_sel = twl6030ldo_get_voltage_sel,
@@ -513,6 +489,11 @@ static struct regulator_ops twlsmps_ops = {
};
/*--*/
+static const struct regulator_linear_range twl6030ldo_linear_range[] = {
+ REGULATOR_LINEAR_RANGE(0, 0, 0, 0),
+ REGULATOR_LINEAR_RANGE(100, 1, 24, 10),
+ REGULATOR_LINEAR_RANGE(275, 31, 31, 0),
+};
#define TWL6030_ADJUSTABLE_SMPS(label) \
static const struct twlreg_info TWL6030_INFO_##label = { \
@@ -525,28 +506,30 @@ static const struct twlreg_info TWL6030_INFO_##label = { \
}, \
}
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts) \
+#define TWL6030_ADJUSTABLE_LDO(label, offset) \
static const struct twlreg_info TWL6030_INFO_##label = { \
.base = offset, \
- .min_mV = min_mVolts, \
.desc = { \
.name = #label, \
.id = TWL6030_REG_##label, \
.n_voltages = 32, \
+ .linear_ranges = twl6030ldo_linear_range, \
+ .n_linear_ranges = ARRAY_SIZE(twl6030ldo_linear_range), \
.ops = &twl6030ldo_ops, \
.type = REGULATOR_VOLTAGE, \
.owner = THIS_MODULE, \
}, \
}
-#define TWL6032_ADJUSTABLE_LDO(label, offset, min_mVolts) \
+#define TWL6032_ADJUSTABLE_LDO(label, offset) \
static const struct twlreg_info TWL6032_INFO_##label = { \
.base = offset, \
- .min_mV = min_mVolts, \
.desc = { \
.name = #label, \
.id = TWL6032_REG_##label, \
.n_voltages = 32, \
+ .linear_ranges = twl6030ldo_linear_range, \
+ .n_linear_ranges = ARRAY_SIZE(twl6030ldo_linear_range), \
.ops = &twl6030ldo_ops, \
.type = REGULATOR_VOLTAGE, \
.owner = THIS_MODULE, \
@@ -557,7 +540,6 @@ static const struct twlreg_info TWL6032_INFO_##label = { \
static const struct twlreg_info TWLFIXED_INFO_##label = { \
.base = offset, \
.id = 0, \
- .min_mV = mVolts, \
.desc = { \
.name = #label, \
.id = TWL6030##_REG_##label, \
@@ -574,7 +556,6 @@ static const struct twlreg_info TWLFIXED_INFO_##label = { \
#define TWL6032_ADJUSTABLE_SMPS(label, offset) \
static const struct twlreg_info TWLSMPS_INFO_##label = { \
.base = offset, \
- .min_mV = 600, \
.desc = { \
.name = #label, \
.id = TWL6032_REG_##label, \
@@ -592,22 +573,22 @@ static const struct twlreg_info TWLSMPS_INFO_##label = { \
TWL6030_ADJUSTABLE_SMPS(VDD1);
TWL6030_ADJUSTABLE_SMPS(VDD2);
TWL6030_ADJUSTABLE_SMPS(VDD3);
-TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000);
-TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000);
-TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000);
-TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 1000);
-TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 1000);
-T
[PATCH 2/2] regulator: twl6030: Constify regulator_ops
Signed-off-by: Axel Lin
---
drivers/regulator/twl6030-regulator.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/twl6030-regulator.c
b/drivers/regulator/twl6030-regulator.c
index dcaa6512d760..15f19df6bc5d 100644
--- a/drivers/regulator/twl6030-regulator.c
+++ b/drivers/regulator/twl6030-regulator.c
@@ -244,7 +244,7 @@ static int twl6030coresmps_get_voltage(struct regulator_dev
*rdev)
return -ENODEV;
}
-static struct regulator_ops twl6030coresmps_ops = {
+static const struct regulator_ops twl6030coresmps_ops = {
.set_voltage= twl6030coresmps_set_voltage,
.get_voltage= twl6030coresmps_get_voltage,
};
@@ -266,7 +266,7 @@ static int twl6030ldo_get_voltage_sel(struct regulator_dev
*rdev)
return vsel;
}
-static struct regulator_ops twl6030ldo_ops = {
+static const struct regulator_ops twl6030ldo_ops = {
.list_voltage = regulator_list_voltage_linear_range,
.set_voltage_sel = twl6030ldo_set_voltage_sel,
@@ -281,7 +281,7 @@ static struct regulator_ops twl6030ldo_ops = {
.get_status = twl6030reg_get_status,
};
-static struct regulator_ops twl6030fixed_ops = {
+static const struct regulator_ops twl6030fixed_ops = {
.list_voltage = regulator_list_voltage_linear,
.enable = twl6030reg_enable,
@@ -472,7 +472,7 @@ static int twl6030smps_get_voltage_sel(struct regulator_dev
*rdev)
return twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE_SMPS);
}
-static struct regulator_ops twlsmps_ops = {
+static const struct regulator_ops twlsmps_ops = {
.list_voltage = twl6030smps_list_voltage,
.map_voltage= twl6030smps_map_voltage,
--
2.17.1
Re: [PATCHv3] random: Make /dev/random wait for crng_ready
On 2/17/19 9:44 AM, Bernd Edlinger wrote:
>
> + if (crng_ready() && !blocking_pool.initialized &&
After some more debugging I realize that blocking_pool.initialized
is true after 128 bits of input entropy, but that is only 80 bits
credited, due to the asymptotic 3/4 crediting formula.
I see that will also enable the code path below:
if (entropy_bits > random_write_wakeup_bits &&
r->initialized &&
r->entropy_total >= 2*random_read_wakeup_bits) {
struct entropy_store *other = &blocking_pool;
if (other->entropy_count <=
3 * other->poolinfo->poolfracbits / 4) {
schedule_work(&other->push_work);
r->entropy_total = 0;
}
when random_write_wakeup_bits is below 80, and random_read_wakeup_bits
is also smallish. This depletes the input_pool in favor of the
blocking pool, while we are actually waiting for the input_pool to
reach 128 bits security strength, in order to seed the CRNG.
I am testing a new version and will post it later today.
Sorry for all the back-and forth.
Bernd.
[PATCH 3/3] dt-bindings: timer: mediatek: update bindings for MT7629 SoC
From: Ryder Lee Update the binding for MT7629 SoC, which uses fallback compatible to MT6765 SYST, so add more descriptions to distinguish it from the other SoCs that use GPT. Signed-off-by: Ryder Lee Cc: Daniel Lezcano --- .../devicetree/bindings/timer/mediatek,mtk-timer.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index 18d4d01..ff7c567 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -1,7 +1,7 @@ -Mediatek Timers +MediaTek Timers --- -Mediatek SoCs have two different timers on different platforms, +MediaTek SoCs have two different timers on different platforms, - GPT (General Purpose Timer) - SYST (System Timer) @@ -9,6 +9,7 @@ The proper timer will be selected automatically by driver. Required properties: - compatible should contain: + For those SoCs that use GPT * "mediatek,mt2701-timer" for MT2701 compatible timers (GPT) * "mediatek,mt6580-timer" for MT6580 compatible timers (GPT) * "mediatek,mt6589-timer" for MT6589 compatible timers (GPT) @@ -17,7 +18,11 @@ Required properties: * "mediatek,mt8135-timer" for MT8135 compatible timers (GPT) * "mediatek,mt8173-timer" for MT8173 compatible timers (GPT) * "mediatek,mt6577-timer" for MT6577 and all above compatible timers (GPT) - * "mediatek,mt6765-timer" for MT6765 compatible timers (SYST) + + For those SoCs that use SYST + * "mediatek,mt7629-timer" for MT7629 compatible timers (SYST) + * "mediatek,mt6765-timer" for MT6765 and all above compatible timers (SYST) + - reg: Should contain location and length for timer register. - clocks: Should contain system clock. -- 1.9.1
[PATCH 2/3] dt-bindings: soc: fix a typo for MT7623A
From: Ryder Lee This fixes a typo for MT7623A Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/soc/mediatek/scpsys.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index 9a88d418..876693a 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -35,7 +35,7 @@ Required properties: Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", "vdec" Required clocks for MT6797: "mm", "mfg", "vdec" Required clocks for MT7622 or MT7629: "hif_sel" - Required clocks for MT7622A: "ethif" + Required clocks for MT7623A: "ethif" Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" Optional properties: -- 1.9.1
[PATCH 1/3] dt-bindings: mediatek: update bindings for MT7629 SoC
From: Ryder Lee This updates bindings for MT7629 SoC, which includes very basic items such as system timer, UART, sysirq and scpsys unit. Signed-off-by: Ryder Lee Cc: Marc Zyngier Cc: Greg Kroah-Hartman --- .../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 5 +++-- Documentation/devicetree/bindings/serial/mtk-uart.txt| 3 ++- Documentation/devicetree/bindings/soc/mediatek/scpsys.txt| 3 ++- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index c5d5891..e8b3688 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -1,6 +1,6 @@ -+Mediatek MT65xx/MT67xx/MT81xx sysirq +MediaTek sysirq -Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI +MediaTek SOCs sysirq support controllable irq inverter for each GIC SPI interrupt. Required properties: @@ -10,6 +10,7 @@ Required properties: "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127 "mediatek,mt7622-sysirq", "mediatek,mt6577-sysirq": for MT7622 "mediatek,mt7623-sysirq", "mediatek,mt6577-sysirq": for MT7623 + "mediatek,mt7629-sysirq", "mediatek,mt6577-sysirq": for MT7629 "mediatek,mt6795-sysirq", "mediatek,mt6577-sysirq": for MT6795 "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq": for MT6797 "mediatek,mt6765-sysirq", "mediatek,mt6577-sysirq": for MT6765 diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index 742cb47..4910f63 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -1,4 +1,4 @@ -* Mediatek Universal Asynchronous Receiver/Transmitter (UART) +* MediaTek Universal Asynchronous Receiver/Transmitter (UART) Required properties: - compatible should contain: @@ -13,6 +13,7 @@ Required properties: * "mediatek,mt6797-uart" for MT6797 compatible UARTS * "mediatek,mt7622-uart" for MT7622 compatible UARTS * "mediatek,mt7623-uart" for MT7623 compatible UARTS + * "mediatek,mt7629-uart" for MT7629 compatible UARTS * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index d6fe16f..9a88d418 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -23,6 +23,7 @@ Required properties: - "mediatek,mt7622-scpsys" - "mediatek,mt7623-scpsys", "mediatek,mt2701-scpsys": For MT7623 SoC - "mediatek,mt7623a-scpsys": For MT7623A SoC + - "mediatek,mt7629-scpsys", "mediatek,mt7622-scpsys": For MT7629 SoC - "mediatek,mt8173-scpsys" - #power-domain-cells: Must be 1 - reg: Address range of the SCPSYS unit @@ -33,7 +34,7 @@ Required properties: Required clocks for MT2701 or MT7623: "mm", "mfg", "ethif" Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", "vdec" Required clocks for MT6797: "mm", "mfg", "vdec" - Required clocks for MT7622: "hif_sel" + Required clocks for MT7622 or MT7629: "hif_sel" Required clocks for MT7622A: "ethif" Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" -- 1.9.1
linux-next: Fixes tags need some work in the net tree
Hi all,
In commit
a40061ea2e39 ("net: systemport: Fix reception of BPDUs")
Fixes tag
Fixes: 4e8aedfe78c7 ("net: systemport: Turn on offloads by default")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: b5061778f822 ("net: systemport: Turn on offloads by default")?
In commit
3b89ea9c5902 ("net: Fix for_each_netdev_feature on Big endian")
Fixes tag
Fixes: fd867d51f ("net/core: generic support for disabling netdev features
down stack")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
pgpGXnnmaZkMs.pgp
Description: OpenPGP digital signature
linux-next: Signed-off-by missing for commits in the xen-tip tree
Hi all,
Commits
28df69acbd27 ("xen-scsiback: mark expected switch fall-through")
7bb17e0ca4a5 ("xen: mark expected switch fall-through")
are missing a Signed-off-by from their committer.
--
Cheers,
Stephen Rothwell
pgpkPsg58d30U.pgp
Description: OpenPGP digital signature
Re: [PATCH] rtc: meson: remove useless rtc_nvmem_unregister call
Hi Alexandre, On Mon, Feb 11, 2019 at 11:33 AM Alexandre Belloni wrote: > > rtc_nvmem_unregister() is called on rtc_device release so it is not > necessary to call it from the driver. thank you for taking care of the linker-error! > Signed-off-by: Alexandre Belloni Reviewed-by: Martin Blumenstingl Regards Martin
Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs
Hi,
On 2/17/19 1:08 AM, Pavel Machek wrote:
I don't pretend to fully understand it, _but_ hw_pattern should really
describe the pattern LED should do, not whether it reacts to charging
or not.
Then we are back to step 1 of the discussion, that we need another
mechanism outside of the trigger to select if the LED shows the configured
pattern always, or only when the charger is on.
Yep, sorry.
These really are 2 orthogonal settings, there is a pattern which can
be set and the LED can either show that pattern always; or only when
charging the battery. Note that the same pattern is used in both cases.
This is why I previously suggested having a custom sysfs hardware_control
attribute which selects between the "only show pattern when charging"
modes ("hardware_control=1" or "always show the pattern mode"
("hardware_control=0").
I see... and yes, that would be the easiest solution.
But somehow I see "this LED is controlled by charging state" as
primary and "it shows pulses instead of staying on" as secondary
eye-candy.
This week there was another driver for charger LED.. but that one does
not do pulses. Ideally, we'd like consistent interface to the
userland.
(To make it complex, the other driver supports things like:
LED solid on -- fully charged
LED blinking slowly -- charging
LED blinking fast -- charge error
LED off -- not charging).
Something like that could be supported with my original hw_pattern
proposal where we simply encode all of this in the hw-pattern file:
tupple0: charging blinking_on_time
tupple1: charging blinking_off_time
tupple2: charging breathing_time
tupple3: manual blinking_on_time
tupple4: manual blinking_off_time
tupple5: manual breathing_time
So for this chip you mention, we do not need the breathing time (no breathing
support),
so we would get the following tupples:
tupple0: not charging blinking_on_time
tupple1: not charging blinking_off_time
tupple2: slow charging blinking_on_time
tupple3: slow charging blinking_off_time
tupple4: fast charging blinking_on_time
tupple5: fast charging blinking_off_time
tupple6: charging error blinking_on_time
tupple7: charging error blinking_off_time
Where by solid on/off can be done by setting one
of the blinking times to 0.
Having hw_pattern ABIs like this where some of
the tupples only activate on certain conditions
might be better then a hardware_control sysfs
file as it offers more flexibility.
Regards,
Hans
[PATCH 1/7] iio: inkern: API for reading available iio channel attribute values
Extend the inkern API with a function for reading available
attribute values of iio channels.
Signed-off-by: Artur Rojek
---
drivers/iio/inkern.c | 20
include/linux/iio/consumer.h | 14 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 06ca3f7fcc44..f19dbde3c945 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -733,6 +733,26 @@ static int iio_channel_read_avail(struct iio_channel *chan,
vals, type, length, info);
}
+int iio_read_avail_channel_attribute(struct iio_channel *chan,
+const int **vals, int *type, int *length,
+enum iio_chan_info_enum attribute)
+{
+ int ret;
+
+ mutex_lock(&chan->indio_dev->info_exist_lock);
+ if (!chan->indio_dev->info) {
+ ret = -ENODEV;
+ goto err_unlock;
+ }
+
+ ret = iio_channel_read_avail(chan, vals, type, length, attribute);
+err_unlock:
+ mutex_unlock(&chan->indio_dev->info_exist_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iio_read_avail_channel_attribute);
+
int iio_read_avail_channel_raw(struct iio_channel *chan,
const int **vals, int *length)
{
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 9887f4f8e2a8..b2d34831ed7c 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -290,6 +290,20 @@ int iio_read_max_channel_raw(struct iio_channel *chan, int
*val);
int iio_read_avail_channel_raw(struct iio_channel *chan,
const int **vals, int *length);
+/**
+ * iio_read_avail_channel_attribute() - read available channel attribute values
+ * @chan: The channel being queried.
+ * @vals: Available values read back.
+ * @type: Type of values read back.
+ * @length:Number of entries in vals.
+ * @attribute: info attribute to be read back.
+ *
+ * Returns an error code, IIO_AVAIL_RANGE or IIO_AVAIL_LIST.
+ */
+int iio_read_avail_channel_attribute(struct iio_channel *chan,
+const int **vals, int *type, int *length,
+enum iio_chan_info_enum attribute);
+
/**
* iio_get_channel_type() - get the type of a channel
* @channel: The channel being queried.
--
2.20.1
[PATCH 4/7] dt-bindings: power: supply: Add docs for Ingenic JZ47xx SoCs battery.
Add documentation for the ingenic-battery driver, used on JZ47xx SoCs.
Signed-off-by: Artur Rojek
---
.../bindings/power/supply/ingenic,battery.txt | 31 +++
1 file changed, 31 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/supply/ingenic,battery.txt
diff --git a/Documentation/devicetree/bindings/power/supply/ingenic,battery.txt
b/Documentation/devicetree/bindings/power/supply/ingenic,battery.txt
new file mode 100644
index ..66430bf73815
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/ingenic,battery.txt
@@ -0,0 +1,31 @@
+* Ingenic JZ47xx battery bindings
+
+Required properties:
+
+- compatible: Must be "ingenic,jz4740-battery".
+- io-channels: phandle and IIO specifier pair to the IIO device.
+ Format described in iio-bindings.txt.
+- monitored-battery: phandle to a "simple-battery" compatible node.
+
+The "monitored-battery" property must be a phandle to a node using the format
+described in battery.txt, with the following properties being required:
+
+- voltage-min-design-microvolt: Drained battery voltage.
+- voltage-max-design-microvolt: Fully charged battery voltage.
+
+Example:
+
+#include
+
+simple_battery: battery {
+ compatible = "simple-battery";
+ voltage-min-design-microvolt = <360>;
+ voltage-max-design-microvolt = <420>;
+};
+
+ingenic_battery {
+ compatible = "ingenic,jz4740-battery";
+ io-channels = <&adc INGENIC_ADC_BATTERY>;
+ io-channel-names = "battery";
+ monitored-battery = <&simple_battery>;
+};
--
2.20.1
[PATCH 3/7] dt-bindings: power: supply: Add voltage-max-design-microvolt property
Add documentation for the "voltage-max-design-microvolt" property.
Signed-off-by: Artur Rojek
---
Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt
b/Documentation/devicetree/bindings/power/supply/battery.txt
index 89871ab8c704..5c913d4cf36c 100644
--- a/Documentation/devicetree/bindings/power/supply/battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -16,6 +16,7 @@ Required Properties:
Optional Properties:
- voltage-min-design-microvolt: drained battery voltage
+ - voltage-max-design-microvolt: fully charged battery voltage
- energy-full-design-microwatt-hours: battery design energy
- charge-full-design-microamp-hours: battery design capacity
- precharge-current-microamp: current for pre-charge phase
@@ -48,6 +49,7 @@ Example:
bat: battery {
compatible = "simple-battery";
voltage-min-design-microvolt = <320>;
+ voltage-max-design-microvolt = <420>;
energy-full-design-microwatt-hours = <529>;
charge-full-design-microamp-hours = <143>;
precharge-current-microamp = <256000>;
--
2.20.1
[PATCH 2/7] power: supply: core: Add a field to support battery max voltage
Add a field for "voltage_max_design_uv" to present fully charged
battery voltage.
Signed-off-by: Artur Rojek
---
drivers/power/supply/power_supply_core.c | 3 +++
include/linux/power_supply.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/power/supply/power_supply_core.c
b/drivers/power/supply/power_supply_core.c
index 569790ea6917..702a2b17ff78 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -575,6 +575,7 @@ int power_supply_get_battery_info(struct power_supply *psy,
info->energy_full_design_uwh = -EINVAL;
info->charge_full_design_uah = -EINVAL;
info->voltage_min_design_uv = -EINVAL;
+ info->voltage_max_design_uv = -EINVAL;
info->precharge_current_ua = -EINVAL;
info->charge_term_current_ua = -EINVAL;
info->constant_charge_current_max_ua = -EINVAL;
@@ -615,6 +616,8 @@ int power_supply_get_battery_info(struct power_supply *psy,
&info->charge_full_design_uah);
of_property_read_u32(battery_np, "voltage-min-design-microvolt",
&info->voltage_min_design_uv);
+ of_property_read_u32(battery_np, "voltage-max-design-microvolt",
+&info->voltage_max_design_uv);
of_property_read_u32(battery_np, "precharge-current-microamp",
&info->precharge_current_ua);
of_property_read_u32(battery_np, "charge-term-current-microamp",
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 57b2ab82b951..2f9c201a54d1 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -332,6 +332,7 @@ struct power_supply_battery_info {
int energy_full_design_uwh; /* microWatt-hours */
int charge_full_design_uah; /* microAmp-hours */
int voltage_min_design_uv; /* microVolts */
+ int voltage_max_design_uv; /* microVolts */
int precharge_current_ua; /* microAmps */
int charge_term_current_ua; /* microAmps */
int constant_charge_current_max_ua; /* microAmps */
--
2.20.1
