* Re: [PATCH 0/6] stricter netlink validation
From: Johannes Berg @ 2019-04-08 9:01 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: linux-wireless, netdev, Pablo Neira Ayuso, David Ahern
In-Reply-To: <20190408090010.GG3201@mtr-leonro.mtl.com>
> This series crashes on mlx4 devices with the following kernel panic.
Yeah, I know. Like I said elsewhere on the thread, I accidentally sent
out the wrong branch (not realizing I had made two). :-(
This should work:
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/log/?h=netlink-validation
johannes
^ permalink raw reply
* Re: [PATCH 0/6] stricter netlink validation
From: Leon Romanovsky @ 2019-04-08 9:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Pablo Neira Ayuso, David Ahern
In-Reply-To: <20190404065408.5864-1-johannes@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 17450 bytes --]
On Thu, Apr 04, 2019 at 08:54:02AM +0200, Johannes Berg wrote:
> Here's a version that has passed build testing ;-)
>
> As mentioned in the RFC postings, this was inspired by talks
> between David, Pablo and myself. Pablo is somewhat firmly on
> the side of less strict validation, while David and myself
> are in the very strict validation camp. If I understand him
> correctly, Pablo doesn't mind the strict validation if it is
> accompanied by exposing the policy to userspace, but that
> isn't something we can do today. I'll work on it later.
>
> What this series does is basically first replace nla_parse()
> and all its friends by nla_parse_deprecated(), while making
> all of those just inlines around __nla_parse() and friends
> with configurable strict checking bits. Three versions exist
> after this patchset:
> * liberal - no bits set
> * deprecated_strict - reject attrs > maxtype
> reject trailing junk
> * new default - reject trailing junk
> reject attrs > maxtype
> reject policy entries that are NLA_UNSPEC
> require a policy
> strictly validate attributes
>
> The NLA_UNSPEC one can be opted in even in existing code with
> existing userspace in the future, as policies are updated.
>
> In addition, infrastructure is added to opt in to the strict
> attribute validation even for new attributes added to existing
> policies, regardless of the nla_parse() strictness setting
> described above, as new attributes should not be a compatibility
> issue.
>
> Finally, much of this is plumbed through generic netlink etc.,
> and I've included a patch to tag nl80211 with the future attribute
> strictness for reference.
>
> johannes
Hi Johannes,
This series crashes on mlx4 devices with the following kernel panic.
[ 92.937629] BUG: unable to handle kernel paging request at 0000000000001023
[ 92.940094] #PF error: [normal kernel read fault]
[ 92.941731] PGD 80000002291da067 P4D 80000002291da067 PUD 20f295067 PMD 0
[ 92.943983] Oops: 0000 [#1] SMP PTI
[ 92.945248] CPU: 1 PID: 3976 Comm: devlink Not tainted 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 92.947951] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 92.950921] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 92.952502] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 92.958146] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 92.959817] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 92.962079] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 92.964297] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 92.966475] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 92.968575] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 92.970688] FS: 00007fa7e963bb80(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 92.973158] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 92.974895] CR2: 0000000000001023 CR3: 000000020f8fa001 CR4: 00000000003606a0
[ 92.976994] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 92.979033] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 92.981030] Call Trace:
[ 92.981870] netlink_dump+0x166/0x390
[ 92.982995] netlink_recvmsg+0x2ef/0x3e0
[ 92.984184] ? copy_msghdr_from_user+0xd5/0x150
[ 92.985540] ___sys_recvmsg+0xf5/0x250
[ 92.986685] ? netlink_sendmsg+0x120/0x3a0
[ 92.987905] ? __sys_sendto+0x10e/0x140
[ 92.989077] ? __sys_recvmsg+0x5b/0xa0
[ 92.990205] __sys_recvmsg+0x5b/0xa0
[ 92.991253] do_syscall_64+0x48/0x100
[ 92.992327] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 92.993743] RIP: 0033:0x7fa7e8d48437
[ 92.994783] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00
00 00 8b 05 1a f4 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2f 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
[ 92.999640] RSP: 002b:00007ffcee2ae168 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
[ 93.001745] RAX: ffffffffffffffda RBX: 0000000000707320 RCX: 00007fa7e8d48437
[ 93.003556] RDX: 0000000000000000 RSI: 00007ffcee2ae190 RDI: 0000000000000012
[ 93.005383] RBP: 0000000000707260 R08: 00007fa7e900b0e0 R09: 000000000000000c
[ 93.007206] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004035e0
[ 93.009023] R13: 00007ffcee2ae348 R14: 0000000000000000 R15: 0000000000000000
[ 93.010847] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.016658] CR2: 0000000000001023
[ 93.017489] ---[ end trace 295441d824c2b8ba ]---
[ 93.018440] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.019577] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.023640] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.024836] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.026321] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.027867] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.029333] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.030744] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.032187] FS: 00007fa7e963bb80(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 93.033881] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.035071] CR2: 0000000000001023 CR3: 000000020f8fa001 CR4: 00000000003606a0
[ 93.036502] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.037898] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.052853] BUG: unable to handle kernel paging request at ffffc90002df7be8
[ 93.054466] #PF error: [normal kernel read fault]
[ 93.055615] PGD 236931067 P4D 236931067 PUD 236934067 PMD 226489067 PTE 0
[ 93.057203] Oops: 0000 [#2] SMP PTI
[ 93.058069] CPU: 1 PID: 43 Comm: kworker/1:1 Tainted: G D 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 93.060241] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 93.062335] Workqueue: events netlink_sock_destruct_work
[ 93.063579] RIP: 0010:genl_lock_done+0xf/0x60
[ 93.064641] Code: 48 c7 c7 e0 e6 30 82 e9 8f 6f 19 00 0f 1f 44 00 00
66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 53 48 83 ec 08 48 8b 47
20 <48> 8b 28 31 c0 48 83 7d 18 00 74 2f 48 89 fb 48 c7 c7 e0 e6 30 82
[ 93.068791] RSP: 0018:ffffc90000173e50 EFLAGS: 00010286
[ 93.070042] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000000
[ 93.071695] RDX: 0000000000000000 RSI: ffff888231b0e94c RDI: ffff888231b0eb30
[ 93.073296] RBP: ffff888231b0e800 R08: 000073746e657665 R09: 8080808080808080
[ 93.074964] R10: ffffc9000006bdf0 R11: fefefefefefefeff R12: ffff888237aa4200
[ 93.076566] R13: 0000000000000000 R14: ffff888237aa0380 R15: 0000000000000000
[ 93.078209] FS: 0000000000000000(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 93.080107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.081403] CR2: ffffc90002df7be8 CR3: 0000000229700004 CR4: 00000000003606a0
[ 93.083006] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.084590] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.086277] Call Trace:
[ 93.086924] netlink_sock_destruct+0x2a/0xa0
[ 93.087949] __sk_destruct+0x24/0x180
[ 93.088817] process_one_work+0x17d/0x3b0
[ 93.089835] worker_thread+0x30/0x370
[ 93.090670] ? process_one_work+0x3b0/0x3b0
[ 93.091624] kthread+0x113/0x130
[ 93.092382] ? kthread_park+0x90/0x90
[ 93.093260] ret_from_fork+0x35/0x40
[ 93.094067] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.099824] CR2: ffffc90002df7be8
[ 93.100718] ---[ end trace 295441d824c2b8bb ]---
[ 93.101829] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.102919] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.107107] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.108382] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.110007] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.111941] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.113574] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.115220] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.116821] FS: 0000000000000000(0000) GS:ffff888237a80000(0000) knlGS:0000000000000000
[ 93.118937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.120592] CR2: ffffc90002df7be8 CR3: 0000000229700004 CR4: 00000000003606a0
[ 93.122196] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.123791] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.528971] BUG: unable to handle kernel paging request at 0000000000001023
[ 93.532427] #PF error: [normal kernel read fault]
[ 93.534683] PGD 8000000228100067 P4D 8000000228100067 PUD 20f87e067 PMD 0
[ 93.537776] Oops: 0000 [#3] SMP PTI
[ 93.539379] CPU: 2 PID: 4005 Comm: devlink Tainted: G D 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 93.543345] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 93.547167] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.549214] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.556214] RSP: 0018:ffffc90002e97c30 EFLAGS: 00010202
[ 93.558301] RAX: ffffc90002e97be8 RBX: ffff888232bf8800 RCX: 0000000000000ec0
[ 93.561059] RDX: 00000000000000a8 RSI: ffff888232bf8b30 RDI: ffff888228cf9700
[ 93.563644] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.566212] R10: ffffea0008a33e40 R11: 0000000000000040 R12: 0000000000001000
[ 93.568773] R13: ffff888232bf8b30 R14: 0000000000000000 R15: ffff888225084000
[ 93.571347] FS: 00007f1754062b80(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.574320] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.591673] CR2: 0000000000001023 CR3: 000000020f30e004 CR4: 00000000003606a0
[ 93.593943] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.596196] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.598425] Call Trace:
[ 93.599303] netlink_dump+0x166/0x390
[ 93.600509] netlink_recvmsg+0x2ef/0x3e0
[ 93.601792] ? copy_msghdr_from_user+0xd5/0x150
[ 93.603242] ___sys_recvmsg+0xf5/0x250
[ 93.604477] ? netlink_sendmsg+0x120/0x3a0
[ 93.605816] ? __sys_sendto+0x10e/0x140
[ 93.607076] ? __sys_recvmsg+0x5b/0xa0
[ 93.608308] __sys_recvmsg+0x5b/0xa0
[ 93.609503] do_syscall_64+0x48/0x100
[ 93.610649] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 93.612160] RIP: 0033:0x7f175376f437
[ 93.613295] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00
00 00 8b 05 1a f4 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2f 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
[ 93.618540] RSP: 002b:00007ffcb7c72218 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
[ 93.620790] RAX: ffffffffffffffda RBX: 000000000186d320 RCX: 00007f175376f437
[ 93.622768] RDX: 0000000000000000 RSI: 00007ffcb7c72240 RDI: 000000000000000c
[ 93.624688] RBP: 000000000186d260 R08: 00007f1753a320e0 R09: 000000000000000c
[ 93.626610] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004035e0
[ 93.628533] R13: 00007ffcb7c723f8 R14: 0000000000000000 R15: 0000000000000000
[ 93.630457] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.637391] CR2: 0000000000001023
[ 93.638348] ---[ end trace 295441d824c2b8bc ]---
[ 93.639610] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.640876] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.645621] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.646966] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.648733] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.650510] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.652283] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.654061] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.655803] FS: 00007f1754062b80(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.657761] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.658951] CR2: 0000000000001023 CR3: 000000020f30e004 CR4: 00000000003606a0
[ 93.660431] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.661971] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.684915] BUG: unable to handle kernel paging request at ffffc90002e97be8
[ 93.686561] #PF error: [normal kernel read fault]
[ 93.687650] PGD 236931067 P4D 236931067 PUD 236934067 PMD 228084067 PTE 0
[ 93.689182] Oops: 0000 [#4] SMP PTI
[ 93.690035] CPU: 2 PID: 38 Comm: kworker/2:1 Tainted: G D 5.1.0-rc2-J2742-G9070daeb7d6d #1
[ 93.692162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 93.694147] Workqueue: events netlink_sock_destruct_work
[ 93.695381] RIP: 0010:genl_lock_done+0xf/0x60
[ 93.696387] Code: 48 c7 c7 e0 e6 30 82 e9 8f 6f 19 00 0f 1f 44 00 00
66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 53 48 83 ec 08 48 8b 47
20 <48> 8b 28 31 c0 48 83 7d 18 00 74 2f 48 89 fb 48 c7 c7 e0 e6 30 82
[ 93.700436] RSP: 0018:ffffc9000014be50 EFLAGS: 00010286
[ 93.701605] RAX: ffffc90002e97be8 RBX: ffff888232bf8800 RCX: 0000000000000000
[ 93.703153] RDX: 0000000000000000 RSI: ffff888232bf894c RDI: ffff888232bf8b30
[ 93.704712] RBP: ffff888232bf8800 R08: 000073746e657665 R09: 8080808080808080
[ 93.706351] R10: ffffc900000c3df0 R11: fefefefefefefeff R12: ffff888237b24200
[ 93.707943] R13: 0000000000000000 R14: ffff888237b20380 R15: 0000000000000000
[ 93.709567] FS: 0000000000000000(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.711426] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.712712] CR2: ffffc90002e97be8 CR3: 000000021ce62006 CR4: 00000000003606a0
[ 93.714299] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 93.715888] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 93.717426] Call Trace:
[ 93.718093] netlink_sock_destruct+0x2a/0xa0
[ 93.719157] __sk_destruct+0x24/0x180
[ 93.720027] process_one_work+0x17d/0x3b0
[ 93.721033] worker_thread+0x30/0x370
[ 93.721946] ? process_one_work+0x3b0/0x3b0
[ 93.722926] kthread+0x113/0x130
[ 93.723753] ? kthread_park+0x90/0x90
[ 93.724606] ret_from_fork+0x35/0x40
[ 93.725494] Modules linked in: mlx4_en mlx4_ib mlx4_core geneve
ip6_udp_tunnel udp_tunnel bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre
ip_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp
rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm
ib_core [last unloaded: mlx4_core]
[ 93.731221] CR2: ffffc90002e97be8
[ 93.732069] ---[ end trace 295441d824c2b8bd ]---
[ 93.733128] RIP: 0010:genl_lock_dumpit+0x10/0xb0
[ 93.734186] Code: c7 c7 a0 e6 30 82 e9 ef 96 a7 ff 0f 1f 44 00 00 66
2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53 48 8b 46 20 48 8b
28 <0f> b6 55 23 f6 c2 02 75 4d 4c 8b 48 08 83 e2 04 4c 8b 5e 08 80 fa
[ 93.738319] RSP: 0018:ffffc90002df7c30 EFLAGS: 00010202
[ 93.739515] RAX: ffffc90002df7be8 RBX: ffff888231b0e800 RCX: 0000000000000ec0
[ 93.741111] RDX: 00000000000000a8 RSI: ffff888231b0eb30 RDI: ffff88823195b400
[ 93.742665] RBP: 0000000000001000 R08: 0000000000001ec0 R09: ffffffff81686c01
[ 93.744233] R10: ffffea0008c656c0 R11: 0000000000000040 R12: 0000000000001000
[ 93.745866] R13: ffff888231b0eb30 R14: 0000000000000000 R15: ffff888230f63700
[ 93.747438] FS: 0000000000000000(0000) GS:ffff888237b00000(0000) knlGS:0000000000000000
[ 93.749209] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 93.750540] CR2: ffffc90002e97be8 CR3: 000000021ce62006 C00000000000 DR1: 0000000000000000
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v6 12/20] kvm/vmx: Emulate MSR TEST_CTL
From: Xiaoyao Li @ 2019-04-08 8:54 UTC (permalink / raw)
To: Sean Christopherson, Fenghua Yu, Paolo Bonzini
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Dave Hansen, Ashok Raj, Peter Zijlstra, Kalle Valo, Michael Chan,
Ravi V Shankar, linux-kernel, x86, linux-wireless, netdev, kvm
In-Reply-To: <20190404144402.GA9911@linux.intel.com>
On Thu, 2019-04-04 at 07:44 -0700, Sean Christopherson wrote:
> On Wed, Apr 03, 2019 at 02:21:58PM -0700, Fenghua Yu wrote:
> > From: Xiaoyao Li <xiaoyao.li@linux.intel.com>
> >
> > A control bit (bit 29) in TEST_CTL MSR 0x33 will be introduced in
> > future x86 processors. When bit 29 is set, the processor causes #AC
> > exception for split locked accesses at all CPL.
> >
> > Please check the latest Intel 64 and IA-32 Architectures Software
> > Developer's Manual for more detailed information on the MSR and
> > the split lock bit.
> >
> > This patch emulate MSR TEST_CTL with vmx->msr_test_ctl and does the
> > following:
> > 1. As MSR TEST_CTL of guest is emulated, enable the related bits
> > in CORE_CAPABILITY to corretly report this feature to guest.
>
> s/corretly/correctly
will correct it. thanks.
> >
> > 2. Differentiate MSR TEST_CTL between host and guest.
> >
> > Signed-off-by: Xiaoyao Li <xiaoyao.li@linux.intel.com>
> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> > arch/x86/kvm/vmx/vmx.c | 35 +++++++++++++++++++++++++++++++++++
> > arch/x86/kvm/vmx/vmx.h | 1 +
> > arch/x86/kvm/x86.c | 17 ++++++++++++++++-
> > 3 files changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index ab432a930ae8..309ccf593f0d 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -1663,6 +1663,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > u32 index;
> >
> > switch (msr_info->index) {
> > + case MSR_TEST_CTL:
> > + if (!msr_info->host_initiated &&
> > + !(vcpu->arch.core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> > + return 1;
> > + msr_info->data = vmx->msr_test_ctl;
> > + break;
> > #ifdef CONFIG_X86_64
> > case MSR_FS_BASE:
> > msr_info->data = vmcs_readl(GUEST_FS_BASE);
> > @@ -1797,6 +1803,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct
> > msr_data *msr_info)
> > u32 index;
> >
> > switch (msr_index) {
> > + case MSR_TEST_CTL:
> > + if (!(vcpu->arch.core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
> > + return 1;
> > +
> > + if (data & ~TEST_CTL_ENABLE_SPLIT_LOCK_DETECT)
> > + return 1;
> > + vmx->msr_test_ctl = data;
> > + break;
> > case MSR_EFER:
> > ret = kvm_set_msr_common(vcpu, msr_info);
> > break;
> > @@ -4077,6 +4091,9 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
> > ++vmx->nmsrs;
> > }
> >
> > + /* disable AC split lock by default */
> > + vmx->msr_test_ctl = 0;
> > +
> > vm_exit_controls_init(vmx, vmx_vmexit_ctrl());
> >
> > /* 22.2.1, 20.8.1 */
> > @@ -4114,6 +4131,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool
> > init_event)
> >
> > vmx->rmode.vm86_active = 0;
> > vmx->spec_ctrl = 0;
> > + vmx->msr_test_ctl = 0;
> >
> > vcpu->arch.microcode_version = 0x100000000ULL;
> > vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
> > @@ -6313,6 +6331,21 @@ static void atomic_switch_perf_msrs(struct vcpu_vmx
> > *vmx)
> > msrs[i].host, false);
> > }
> >
> > +static void atomic_switch_msr_test_ctl(struct vcpu_vmx *vmx)
> > +{
> > + u64 host_msr_test_ctl;
> > +
> > + /* if TEST_CTL MSR doesn't exist on the hardware, do nothing */
> > + if (rdmsrl_safe(MSR_TEST_CTL, &host_msr_test_ctl))
> > + return;
>
> This adds a RDMSR on every VM-Enter, and a fault on CPUs that don't
> support MSR_TEST_CTL. Ideally the kernel would cache MSR_TEST_CTL and
> expose a helper that returns a boolean to indicate the existence of the
> MSRs along with the current value. Racing with split_lock_detect_store()
> is ok since this code runs with interrupts disabled, i.e. will block
> split_lock_detect_store() until after VM-Exit.
>
> Paolo, can you weigh in with your thoughts? I'm surprised you acked
> this patch given your earlier comment:
>
> https://patchwork.kernel.org/patch/10413779/#21892723
In v4 patchset, it checks boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) first in
atomic_switch_msr_test_ctl().
In v5 patchset, considering that there is another bit (bit 31) in MSR_TEST_CTL,
and !boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) cannot guarantee there is no
MSR_TEST_CTL in hardware. So I changed it to rdmsrl_safe() in v5.
It's my fault that I didn't point it out in the changelog in v5 patchset.
Considering the overhead of rdmsr every VMENTRY. I will use a percpu variable
msr_test_ctl_cache based on Thomas's comment to cache the value of host's
MSR_TEST_CTL.
> > +
> > + if (host_msr_test_ctl == vmx->msr_test_ctl)
> > + clear_atomic_switch_msr(vmx, MSR_TEST_CTL);
> > + else
> > + add_atomic_switch_msr(vmx, MSR_TEST_CTL, vmx->msr_test_ctl,
> > + host_msr_test_ctl, false);
> > +}
> > +
> > static void vmx_arm_hv_timer(struct vcpu_vmx *vmx, u32 val)
> > {
> > vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, val);
> > @@ -6419,6 +6452,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
> >
> > atomic_switch_perf_msrs(vmx);
> >
> > + atomic_switch_msr_test_ctl(vmx);
> > +
> > vmx_update_hv_timer(vcpu);
> >
> > /*
> > diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> > index a1e00d0a2482..6091a8b9de74 100644
> > --- a/arch/x86/kvm/vmx/vmx.h
> > +++ b/arch/x86/kvm/vmx/vmx.h
> > @@ -190,6 +190,7 @@ struct vcpu_vmx {
> > u64 msr_guest_kernel_gs_base;
> > #endif
> >
> > + u64 msr_test_ctl;
> > u64 spec_ctrl;
> >
> > u32 vm_entry_controls_shadow;
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 4459115eb0ec..e93c2f620cdb 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -1229,7 +1229,22 @@ EXPORT_SYMBOL_GPL(kvm_get_arch_capabilities);
> >
> > u64 kvm_get_core_capability(void)
> > {
> > - return 0;
> > + u64 data;
> > +
> > + rdmsrl_safe(MSR_IA32_CORE_CAPABILITY, &data);
> > +
> > + /* mask non-virtualizable functions */
> > + data &= CORE_CAP_SPLIT_LOCK_DETECT;
> > +
> > + /*
> > + * There will be a list of FMS values that have split lock detection
> > + * but lack the CORE CAPABILITY MSR. In this case, set
> > + * CORE_CAP_SPLIT_LOCK_DETECT since we emulate MSR CORE_CAPABILITY.
> > + */
> > + if (boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
> > + data |= CORE_CAP_SPLIT_LOCK_DETECT;
> > +
> > + return data;
> > }
> > EXPORT_SYMBOL_GPL(kvm_get_core_capability);
> >
> > --
> > 2.19.1
> >
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
From: Maxime Ripard @ 2019-04-08 8:47 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Ondřej Jirman, linux-sunxi, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
open list:GPIO SUBSYSTEM
In-Reply-To: <CAGb2v65W_H5HrnY9+DuW-noshXLHgErJhEpHHhzcG15n1u=8iw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote:
> On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sat, Apr 06, 2019 at 01:45:04AM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> > > transistors, before it can be used. Model this as a power supply for DDC
> > > (via regulator framework).
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> >
> > The DDC bus itself is usually attached to the HDMI connector, so it
> > would make sense to make the supply also a property of the connector.
>
> I believe these are separate things. What this patch covers is power for
> a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's
> 5V supply to power the remote DDC chip is something else. And on the
> Orange Pi 3 they are indeed separate supplies.
Then maybe the endpoint link between the two would be the best place
to put this?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 01/12] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
From: Maxime Ripard @ 2019-04-08 7:46 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-2-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 7366 bytes --]
On Sat, Apr 06, 2019 at 01:45:03AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 is a H6 based SBC made by Xulong, released in
> January 2019. It has the following features:
>
> - Allwinner H6 quad-core 64-bit ARM Cortex-A53
> - GPU Mali-T720
> - 1GB or 2GB LPDDR3 RAM
> - AXP805 PMIC
> - AP6256 Wifi/BT 5.0
> - USB 2.0 host port (A)
> - USB 2.0 micro usb, OTG
> - USB 3.0 Host + 4 port USB hub (GL3510)
> - Gigabit Ethernet (Realtek RTL8211E phy)
> - HDMI 2.0 port
> - soldered eMMC (optional)
> - 3x LED (one is on the bottom)
> - microphone
> - audio jack
> - PCIe
>
> Add basic support for the board.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 212 ++++++++++++++++++
> 2 files changed, 213 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index e4dce2f6fa3a..285a7cb5135b 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> new file mode 100644
> index 000000000000..7a2424fcaed7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -0,0 +1,212 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2019 Ondřej Jirman <megous@megous.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + model = "OrangePi 3";
> + compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
As Clement pointed out, this should be documented in
Documentation/devicetree/bindings/arm/sunxi.yaml
It's part of sunxi/for-next only at this point, and it will go through
a different branch than the H6 DTS, so it would be great to have it in
a separate patch.
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "orangepi:red:power";
> + gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> + default-state = "on";
> + };
> +
> + status {
> + label = "orangepi:green:status";
> + gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC jack */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +};
> +
> +&cpu0 {
> + cpu-supply = <®_dcdca>;
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + vmmc-supply = <®_cldo1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
> +
> +&pio {
> + vcc-pc-supply = <®_bldo2>;
> + vcc-pd-supply = <®_cldo1>;
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp805: pmic@36 {
> + compatible = "x-powers,axp805", "x-powers,axp806";
> + reg = <0x36>;
> + interrupt-parent = <&r_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-pl-led-ir";
> + };
> +
> + reg_aldo2: aldo2 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc33-audio-tv-ephy-mac";
> + };
> +
> + /* ALDO3 is shorted to CLDO1 */
> + reg_aldo3: aldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc33-io-pd-emmc-sd-usb-uart-1";
> + };
> +
> + reg_bldo1: bldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc18-dram-bias-pll";
> + };
> +
> + reg_bldo2: bldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc-efuse-pcie-hdmi-pc";
> + };
> +
> + bldo3 {
> + /* unused */
> + };
> +
> + bldo4 {
> + /* unused */
> + };
> +
> + reg_cldo1: cldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc33-io-pd-emmc-sd-usb-uart-2";
> + };
> +
> + cldo2 {
> + /* unused */
> + };
> +
> + cldo3 {
> + /* unused */
> + };
> +
> + reg_dcdca: dcdca {
> + regulator-always-on;
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1160000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + reg_dcdcc: dcdcc {
> + regulator-min-microvolt = <810000>;
> + regulator-max-microvolt = <1080000>;
> + regulator-name = "vdd-gpu";
> + };
> +
> + reg_dcdcd: dcdcd {
> + regulator-always-on;
> + regulator-min-microvolt = <960000>;
> + regulator-max-microvolt = <960000>;
> + regulator-name = "vdd-sys";
> + };
> +
> + reg_dcdce: dcdce {
> + regulator-always-on;
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-name = "vcc-dram";
> + };
> +
> + sw {
> + /* unused */
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> +
> +&usb2otg {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> +&usb2phy {
> + usb0_id_det-gpios = <&pio 2 15 GPIO_ACTIVE_HIGH>; /* PC15 */
> + usb0_vbus-supply = <®_vcc5v>;
> + usb3_vbus-supply = <®_vcc5v>;
> + status = "okay";
If we have an ID pin, then why is the OTG controller set to host?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
From: Maxime Ripard @ 2019-04-08 7:43 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-9-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 920 bytes --]
On Sat, Apr 06, 2019 at 01:45:10AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index 91fecab58836..dccad79da90c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -238,6 +238,15 @@
> bias-pull-up;
> };
>
> +
Extra line
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> + "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
Is that the only muxing option?
If so, then it should be assigned by default to mmc1
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 10/12] pinctrl: sunxi: Support I/O bias voltage setting on H6
From: Maxime Ripard @ 2019-04-08 7:42 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-11-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 3248 bytes --]
On Sat, Apr 06, 2019 at 01:45:12AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> H6 SoC has a "pio group withstand voltage mode" register (datasheet
> description), that needs to be used to select either 1.8V or 3.3V
> I/O mode, based on what voltage is powering the respective pin
> banks and is thus used for I/O signals.
>
> Add support for configuring this register according to the voltage
> of the pin bank regulator (if enabled).
>
> This is similar to the support for I/O bias voltage setting patch
> for A80 and the same concerns apply. (see commit 402bfb3c135213dc
> Support I/O bias voltage setting on A80).
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 1 +
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 14 ++++++++++++++
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 3 +++
> 3 files changed, 18 insertions(+)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> index ef4268cc6227..30b1befa8ed8 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> @@ -591,6 +591,7 @@ static const struct sunxi_pinctrl_desc h6_pinctrl_data = {
> .irq_banks = 4,
> .irq_bank_map = h6_irq_bank_map,
> .irq_read_needs_mux = true,
> + .io_bias_cfg_variant = IO_BIAS_CFG_V2,
> };
>
> static int h6_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 9f329fec77cf..59a4ed396d92 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -607,6 +607,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
> unsigned pin,
> struct regulator *supply)
> {
> + unsigned short bank = pin / PINS_PER_BANK;
> + unsigned long flags;
> u32 val, reg;
> int uV;
>
> @@ -639,6 +641,18 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
> reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
> reg &= ~IO_BIAS_MASK;
> writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
> + } else if (pctl->desc->io_bias_cfg_variant == IO_BIAS_CFG_V2) {
> + val = uV <= 1800000 ? 1 : 0;
> +
> + dev_info(pctl->dev,
> + "Setting voltage bias to %sV on bank P%c\n",
> + val ? "1.8" : "3.3", 'A' + bank);
> +
> + raw_spin_lock_irqsave(&pctl->lock, flags);
> + reg = readl(pctl->membase + PIO_POW_MOD_SEL_REG);
> + reg &= ~(1 << bank);
> + writel(reg | val << bank, pctl->membase + PIO_POW_MOD_SEL_REG);
> + raw_spin_unlock_irqrestore(&pctl->lock, flags);
> }
>
> return 0;
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index 476772f91dba..3a66376f141b 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -95,7 +95,10 @@
> #define PINCTRL_SUN7I_A20 BIT(7)
> #define PINCTRL_SUN8I_R40 BIT(8)
>
> +#define PIO_POW_MOD_SEL_REG 0x340
> +
> #define IO_BIAS_CFG_V1 1
> +#define IO_BIAS_CFG_V2 2
Can you document what V1 and V2 means exactly?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: Maxime Ripard @ 2019-04-08 7:40 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-8-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]
On Sat, Apr 06, 2019 at 01:45:09AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> According to the phy datasheet, both regulators need to be enabled
> at the same time, but we can only specify a single phy-supply in
> the DT.
>
> This can be achieved by making one regulator depedning on the
> other via vin-supply. While it's not a technically correct
> description of the hardware, it achieves the purpose.
>
> All values of RX/TX delay were tested exhaustively and a middle
> one of the working values was chosen.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 44 +++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index 644946749088..5270142527f5 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -15,6 +15,7 @@
>
> aliases {
> serial0 = &uart0;
> + ethernet0 = &emac;
> };
>
> chosen {
> @@ -64,6 +65,27 @@
> regulator-max-microvolt = <5000000>;
> regulator-always-on;
> };
> +
> + /*
> + * The board uses 2.5V RGMII signalling. Power sequence
> + * to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> + * power rails at the same time and to wait 100ms.
> + */
> + reg_gmac_2v5: gmac-2v5 {
> + compatible = "regulator-fixed";
> + regulator-name = "gmac-2v5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + startup-delay-us = <100000>;
> + enable-active-high;
> + gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
Is enable-active-high still needed? It's redundant with the
GPIO_ACTIVE_HIGH flag.
The indentation is wrong here as well.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] mt76: fix a leaked reference by adding a missingof_node_put
From: Markus Elfring @ 2019-04-08 7:37 UTC (permalink / raw)
To: Wen Yang, linux-arm-kernel, linux-mediatek, linux-wireless,
netdev
Cc: UNGLinuxDriver, Alexandre Belloni, Andrew Lunn, Anirudha Sarangi,
David S. Miller, Florian Fainelli, Kalle Valo, Linus Walleij,
Lorenzo Bianconi, Matthias Brugger, Michal Simek, Felix Fietkau,
Vivien Didelot, John Linn, Yi Wang, linux-kernel
In-Reply-To: <201904081455561126540@zte.com.cn>
>>> @@ -54,22 +54,30 @@ mt76_get_of_eeprom(struct mt76_dev *dev, int len)
>>> part = np->name;
>>>
>>> mtd = get_mtd_device_nm(part);
>> …
>>> + if (retlen < len) {
>>> + ret = -EINVAL;
>>> + goto out_put_node;
>>
>> I find a jump to an immediately following source code place unnecessary.
>> Would you like to delete it?
>>
>>
>>> + }
>>>
>>> - return 0;
>>> +out_put_node:
>>> + of_node_put(np);
>>> + return ret;
>>> #else
>>
>> Can another bit of fine-tuning matter here?
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/wireless/mediatek/mt76/eeprom.c?id=34e022d8b780a03902d82fb3997ba7c7b1f40c81#n73
…
> We may have some different opinions here.
Obviously, yes for this implementation detail.
> Deleting the goto statement may not be good.
I find such an adjustment helpful here.
> If the code further up is changed it's easy enough to miss
> that a goto statement needs to be added here.
There are the usual consequences to consider for every change.
> Better to set ret to zero explicitly, this is the success path after all.
I disagree to this information because the variable was set to
the return value from a call of the function “mtd_read” already.
Regards,
Markus
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
From: Chen-Yu Tsai @ 2019-04-08 7:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Ondřej Jirman, linux-sunxi, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
open list:GPIO SUBSYSTEM
In-Reply-To: <20190408072338.3urcotemju3qi2un@flea>
On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Sat, Apr 06, 2019 at 01:45:04AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> > transistors, before it can be used. Model this as a power supply for DDC
> > (via regulator framework).
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
>
> The DDC bus itself is usually attached to the HDMI connector, so it
> would make sense to make the supply also a property of the connector.
I believe these are separate things. What this patch covers is power for
a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's
5V supply to power the remote DDC chip is something else. And on the
Orange Pi 3 they are indeed separate supplies.
ChenYu
^ permalink raw reply
* Re: [PATCH 05/12] net: stmmac: sun8i: add support for Allwinner H6 EMAC
From: Maxime Ripard @ 2019-04-08 7:25 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
Icenowy Zheng, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-6-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
On Sat, Apr 06, 2019 at 01:45:07AM +0200, megous@megous.com wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY"
> on H6 is on a co-packaged AC200 chip, and it's not really internal (it's
> connected via RMII at PA GPIO bank).
>
> Add support for the Allwinner H6 EMAC in the dwmac-sun8i driver.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
This should have your Signed-off-by (just like all the other
subsequent patches from someone else you sent in this series).
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 04/12] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: Maxime Ripard @ 2019-04-08 7:24 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-5-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]
On Sat, Apr 06, 2019 at 01:45:06AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables
> the DDC I2C bus. Before EDID can be read, we need to pull PH2 high.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index 7a2424fcaed7..644946749088 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -21,6 +21,17 @@
> stdout-path = "serial0:115200n8";
> };
>
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> @@ -36,6 +47,15 @@
> };
> };
>
> + reg_ddc: ddc-io {
> + compatible = "regulator-fixed";
> + regulator-name = "ddc-io";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + enable-active-high;
> + gpio = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + };
> +
This is indented with spaces and generates checkpatch warnings.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
From: Maxime Ripard @ 2019-04-08 7:23 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Chen-Yu Tsai, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-3-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
On Sat, Apr 06, 2019 at 01:45:04AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> transistors, before it can be used. Model this as a power supply for DDC
> (via regulator framework).
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
The DDC bus itself is usually attached to the HDMI connector, so it
would make sense to make the supply also a property of the connector.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: Jagan Teki @ 2019-04-08 6:11 UTC (permalink / raw)
To: megous, Chen-Yu Tsai
Cc: linux-sunxi, Maxime Ripard, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-8-megous@megous.com>
On Sat, Apr 6, 2019 at 5:15 AM <megous@megous.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> According to the phy datasheet, both regulators need to be enabled
> at the same time, but we can only specify a single phy-supply in
> the DT.
>
> This can be achieved by making one regulator depedning on the
> other via vin-supply. While it's not a technically correct
> description of the hardware, it achieves the purpose.
>
> All values of RX/TX delay were tested exhaustively and a middle
> one of the working values was chosen.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 44 +++++++++++++++++++
> 1 file changed, 44 insertions(+)
This was in ML[1], I thought this change would already merged. I
remember Chen-Yu applied and revert due to emac node not mainlined at
that time.
[1] https://patchwork.kernel.org/patch/10558281/
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3
From: Jagan Teki @ 2019-04-08 6:01 UTC (permalink / raw)
To: megous, Clément Péron, linux-sunxi, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Linus Walleij, David Airlie,
Daniel Vetter, Mark Rutland, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, Arend van Spriel,
Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, Naveen Gupta, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, netdev, linux-stm32, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-gpio
In-Reply-To: <20190407143237.2qyoef4r5e3qvbmh@core.my.home>
On Sun, Apr 7, 2019 at 8:02 PM 'Ondřej Jirman' via linux-sunxi
<linux-sunxi@googlegroups.com> wrote:
>
> On Sun, Apr 07, 2019 at 03:36:21PM +0200, Clément Péron wrote:
> > Hi,
> >
> > On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
> > <linux-sunxi@googlegroups.com> wrote:
> > >
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > This series implements support for Xunlong Orange Pi 3 board.
> >
> > OrangePi 3 Lite2 and One Plus boards support has already been merged.
> > The support is not complete but you should rebase your patches on top
> > of sunxi/for-next
>
> Hi,
>
> OrangePi 3 is somewhat different from these two boards (mostly it has a differnt
> power tree). It doesn't use the AXP regulators that are defined in the
> sun50i-h6-orangepi.dtsi in the same way.
>
> For example:
>
> - bldo3 (is turned always on in sun50i-h6-orangepi.dtsi but unused for opi3)
> - cldo2 and cldo3 are unused on opi3 and have nothing to do with WiFi
> - aldo3 is not for dram
> - bldo1 on the other hand is for dram on opi3
> - some other regulators are used for different/more functions and thus
> named differntly
> - USB id-det pin is differnt
> - ...
Based on my communication with OrangePI, OPI-3 has PCIE, 4 USB-3.0
ports and AV are the key differences and rest seems to be similar. but
if we have a diff or unused regulators may be we can't enable them in
dtsi (I never looked that close as of now)
^ permalink raw reply
* [PATCH] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Yue Haibing @ 2019-04-08 3:45 UTC (permalink / raw)
To: kvalo; +Cc: linux-kernel, linux-wireless, davem, netdev, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
Syzkaller report this:
[ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
[ 1213.469530] #PF error: [normal kernel read fault]
[ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
[ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
[ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8
[ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
[ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
[ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
[ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
[ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
[ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
[ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
[ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
[ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
[ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
[ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1213.473514] PKRU: 55555554
[ 1213.473514] Call Trace:
[ 1213.473514] led_trigger_register+0x112/0x3f0
[ 1213.473514] led_trigger_register_simple+0x7a/0x110
[ 1213.473514] ? 0xffffffffc1c10000
[ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb]
[ 1213.473514] do_one_initcall+0xbc/0x47d
[ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] do_init_module+0x1b5/0x547
[ 1213.473514] load_module+0x6405/0x8c10
[ 1213.473514] ? module_frob_arch_sections+0x20/0x20
[ 1213.473514] ? kernel_read_file+0x1e6/0x5d0
[ 1213.473514] ? find_held_lock+0x32/0x1c0
[ 1213.473514] ? cap_capable+0x1ae/0x210
[ 1213.473514] ? __do_sys_finit_module+0x162/0x190
[ 1213.473514] __do_sys_finit_module+0x162/0x190
[ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0
[ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690
[ 1213.473514] ? wait_for_completion+0x370/0x370
[ 1213.473514] ? vfs_write+0x204/0x4a0
[ 1213.473514] ? do_syscall_64+0x18/0x450
[ 1213.473514] do_syscall_64+0x9f/0x450
[ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1213.473514] RIP: 0033:0x462e99
[ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
[ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
[ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
[ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
[ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
[ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
If usb_register failed, no need to call led_trigger_register_simple.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 1264b951463a ("at76c50x-usb: add driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/atmel/at76c50x-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c b/drivers/net/wireless/atmel/at76c50x-usb.c
index e99e766..1cabae4 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -2585,8 +2585,8 @@ static int __init at76_mod_init(void)
if (result < 0)
printk(KERN_ERR DRIVER_NAME
": usb_register failed (status %d)\n", result);
-
- led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
+ else
+ led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
return result;
}
--
2.7.4
^ permalink raw reply related
* RE: [PATCH v8 00/14] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips
From: Tony Chuang @ 2019-04-08 2:14 UTC (permalink / raw)
To: Kalle Valo
Cc: Brian Norris, Johannes Berg, linux-wireless, Greg Kroah-Hartman,
Pkshih, Andy Huang, Larry Finger, Stanislaw Gruszka
In-Reply-To: <20190327102623.GA20943@redhat.com>
Hi Kalle
> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> Sent: Wednesday, March 27, 2019 6:26 PM
> To: Tony Chuang
> Cc: Brian Norris; Kalle Valo; Johannes Berg; linux-wireless; Greg Kroah-Hartman;
> Pkshih; Andy Huang; Larry Finger
> Subject: Re: [PATCH v8 00/14] rtw88: mac80211 driver for Realtek 802.11ac
> wireless network chips
>
It's just a gentle reply to ask if rtw88 is getting merged.
Are you still reviewing or is there anything I can help.
Thanks!
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH 10/12] pinctrl: sunxi: Support I/O bias voltage setting on H6
From: Ondřej Jirman @ 2019-04-08 1:31 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij
Cc: Mark Rutland, David Airlie, Chi-Hsien Lin, dri-devel, linux-stm32,
brcm80211-dev-list, Jose Abreu, Naveen Gupta, devicetree,
Arend van Spriel, Alexandre Torgue, Hante Meuleman, linux-gpio,
Wright Feng, Giuseppe Cavallaro, linux-arm-kernel, Franky Lin,
Maxime Coquelin, brcm80211-dev-list.pdl, netdev, linux-wireless,
linux-kernel, Kalle Valo, Daniel Vetter, David S. Miller
In-Reply-To: <20190405234514.6183-11-megous@megous.com>
On Sat, Apr 06, 2019 at 01:45:12AM +0200, verejna wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> H6 SoC has a "pio group withstand voltage mode" register (datasheet
> description), that needs to be used to select either 1.8V or 3.3V
> I/O mode, based on what voltage is powering the respective pin
> banks and is thus used for I/O signals.
>
> Add support for configuring this register according to the voltage
> of the pin bank regulator (if enabled).
>
> This is similar to the support for I/O bias voltage setting patch
> for A80 and the same concerns apply. (see commit 402bfb3c135213dc
> Support I/O bias voltage setting on A80).
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 1 +
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 14 ++++++++++++++
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 3 +++
> 3 files changed, 18 insertions(+)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> index ef4268cc6227..30b1befa8ed8 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> @@ -591,6 +591,7 @@ static const struct sunxi_pinctrl_desc h6_pinctrl_data = {
> .irq_banks = 4,
> .irq_bank_map = h6_irq_bank_map,
> .irq_read_needs_mux = true,
> + .io_bias_cfg_variant = IO_BIAS_CFG_V2,
> };
>
> static int h6_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 9f329fec77cf..59a4ed396d92 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -607,6 +607,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
> unsigned pin,
> struct regulator *supply)
> {
> + unsigned short bank = pin / PINS_PER_BANK;
> + unsigned long flags;
> u32 val, reg;
> int uV;
>
> @@ -639,6 +641,18 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
> reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
> reg &= ~IO_BIAS_MASK;
> writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
> + } else if (pctl->desc->io_bias_cfg_variant == IO_BIAS_CFG_V2) {
> + val = uV <= 1800000 ? 1 : 0;
> +
> + dev_info(pctl->dev,
> + "Setting voltage bias to %sV on bank P%c\n",
> + val ? "1.8" : "3.3", 'A' + bank);
I'll drop this logging in v2. I forgot it here, after testing the patch.
o.
> + raw_spin_lock_irqsave(&pctl->lock, flags);
> + reg = readl(pctl->membase + PIO_POW_MOD_SEL_REG);
> + reg &= ~(1 << bank);
> + writel(reg | val << bank, pctl->membase + PIO_POW_MOD_SEL_REG);
> + raw_spin_unlock_irqrestore(&pctl->lock, flags);
> }
>
> return 0;
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index 476772f91dba..3a66376f141b 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -95,7 +95,10 @@
> #define PINCTRL_SUN7I_A20 BIT(7)
> #define PINCTRL_SUN8I_R40 BIT(8)
>
> +#define PIO_POW_MOD_SEL_REG 0x340
> +
> #define IO_BIAS_CFG_V1 1
> +#define IO_BIAS_CFG_V2 2
>
> struct sunxi_desc_function {
> unsigned long variant;
> --
> 2.21.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 12/12] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Ondřej Jirman @ 2019-04-07 16:15 UTC (permalink / raw)
To: Clément Péron
Cc: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <CAJiuCcdRHj56p_KFRhK8H9xO+M3ycNp1Jpzw_QWcKQZorcKGpA@mail.gmail.com>
On Sun, Apr 07, 2019 at 05:31:52PM +0200, Clément Péron wrote:
> Hi,
>
> On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
> <linux-sunxi@googlegroups.com> wrote:
> >
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is
> > called bcm43356 and can be used with the brcmfmac driver. The module
> > is powered by the two always on regulators (not AXP805).
> >
> > WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> > configured so that it sets up an 1.8V input bias on this port. This is
> > done by the pio driver by reading the vcc-pg-supply voltage.
> >
> > You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> > configuration that can be found in the Xulongs's repository for H6:
> >
> > https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
> >
> > Mainline brcmfmac driver expects the firmware and nvram at the
> > following paths relative to the firmware directory:
> >
> > brcm/brcmfmac43456-sdio.bin
> > brcm/brcmfmac43456-sdio.txt
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index 5270142527f5..6a201829bb62 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -66,6 +66,26 @@
> > regulator-always-on;
> > };
> >
> > + reg_vcc33_wifi: vcc33-wifi {
> > + /* Always on 3.3V regulator for WiFi and BT */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc33-wifi";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc5v>;
> > + };
> > +
> > + reg_vcc_wifi_io: vcc-wifi-io {
> > + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-wifi-io";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc33_wifi>;
> > + };
> > +
> > /*
> > * The board uses 2.5V RGMII signalling. Power sequence
> > * to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> > @@ -86,6 +106,14 @@
> > */
> > vin-supply = <®_aldo2>; /* GMAC-3V3 */
> > };
> > +
> > + wifi_pwrseq: wifi_pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + clocks = <&rtc 1>;
>
> Maybe I missed something, but the RTC in H6 is not yet available :
> https://lkml.org/lkml/2018/10/31/822
You're right. I'm using an out-of-tree patch for that and didn't notice the
dependency. I guess, WiFi DTS patch can be ignored for now.
thanks,
o.
> Regards,
> Clement
>
> > + clock-names = "ext_clock";
> > + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> > + post-power-on-delay-ms = <200>;
> > + };
> > };
> >
> > &cpu0 {
> > @@ -146,6 +174,25 @@
> > status = "okay";
> > };
> >
> > +&mmc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
> > + vmmc-supply = <®_vcc33_wifi>;
> > + vqmmc-supply = <®_vcc_wifi_io>;
> > + mmc-pwrseq = <&wifi_pwrseq>;
> > + bus-width = <4>;
> > + non-removable;
> > + status = "okay";
> > +
> > + brcm: sdio-wifi@1 {
> > + reg = <1>;
> > + compatible = "brcm,bcm4329-fmac";
> > + interrupt-parent = <&r_pio>;
> > + interrupts = <1 0 IRQ_TYPE_LEVEL_LOW>; /* PM0 */
> > + interrupt-names = "host-wake";
> > + };
> > +};
> > +
> > &ohci0 {
> > status = "okay";
> > };
> > @@ -157,6 +204,7 @@
> > &pio {
> > vcc-pc-supply = <®_bldo2>;
> > vcc-pd-supply = <®_cldo1>;
> > + vcc-pg-supply = <®_vcc_wifi_io>;
> > };
> >
> > &r_i2c {
> > --
> > 2.21.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 12/12] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Clément Péron @ 2019-04-07 15:31 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-13-megous@megous.com>
Hi,
On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
<linux-sunxi@googlegroups.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is
> called bcm43356 and can be used with the brcmfmac driver. The module
> is powered by the two always on regulators (not AXP805).
>
> WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> configured so that it sets up an 1.8V input bias on this port. This is
> done by the pio driver by reading the vcc-pg-supply voltage.
>
> You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> configuration that can be found in the Xulongs's repository for H6:
>
> https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
>
> Mainline brcmfmac driver expects the firmware and nvram at the
> following paths relative to the firmware directory:
>
> brcm/brcmfmac43456-sdio.bin
> brcm/brcmfmac43456-sdio.txt
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index 5270142527f5..6a201829bb62 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -66,6 +66,26 @@
> regulator-always-on;
> };
>
> + reg_vcc33_wifi: vcc33-wifi {
> + /* Always on 3.3V regulator for WiFi and BT */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc33-wifi";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + vin-supply = <®_vcc5v>;
> + };
> +
> + reg_vcc_wifi_io: vcc-wifi-io {
> + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-wifi-io";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + vin-supply = <®_vcc33_wifi>;
> + };
> +
> /*
> * The board uses 2.5V RGMII signalling. Power sequence
> * to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> @@ -86,6 +106,14 @@
> */
> vin-supply = <®_aldo2>; /* GMAC-3V3 */
> };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rtc 1>;
Maybe I missed something, but the RTC in H6 is not yet available :
https://lkml.org/lkml/2018/10/31/822
Regards,
Clement
> + clock-names = "ext_clock";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> + post-power-on-delay-ms = <200>;
> + };
> };
>
> &cpu0 {
> @@ -146,6 +174,25 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_vcc33_wifi>;
> + vqmmc-supply = <®_vcc_wifi_io>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcm: sdio-wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&r_pio>;
> + interrupts = <1 0 IRQ_TYPE_LEVEL_LOW>; /* PM0 */
> + interrupt-names = "host-wake";
> + };
> +};
> +
> &ohci0 {
> status = "okay";
> };
> @@ -157,6 +204,7 @@
> &pio {
> vcc-pc-supply = <®_bldo2>;
> vcc-pd-supply = <®_cldo1>;
> + vcc-pg-supply = <®_vcc_wifi_io>;
> };
>
> &r_i2c {
> --
> 2.21.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3
From: Clément Péron @ 2019-04-07 15:08 UTC (permalink / raw)
To: Clément Péron, linux-sunxi, Maxime Ripard, Chen-Yu Tsai,
Rob Herring, Linus Walleij, David Airlie, Daniel Vetter,
Mark Rutland, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
David S. Miller, Maxime Coquelin, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, Kalle Valo,
Naveen Gupta, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, netdev, linux-stm32, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, linux-gpio
In-Reply-To: <20190407143237.2qyoef4r5e3qvbmh@core.my.home>
Hi,
On Sun, 7 Apr 2019 at 16:32, Ondřej Jirman <megous@megous.com> wrote:
>
> On Sun, Apr 07, 2019 at 03:36:21PM +0200, Clément Péron wrote:
> > Hi,
> >
> > On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
> > <linux-sunxi@googlegroups.com> wrote:
> > >
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > This series implements support for Xunlong Orange Pi 3 board.
> >
> > OrangePi 3 Lite2 and One Plus boards support has already been merged.
> > The support is not complete but you should rebase your patches on top
> > of sunxi/for-next
>
> Hi,
>
> OrangePi 3 is somewhat different from these two boards (mostly it has a differnt
> power tree). It doesn't use the AXP regulators that are defined in the
> sun50i-h6-orangepi.dtsi in the same way.
>
> For example:
>
> - bldo3 (is turned always on in sun50i-h6-orangepi.dtsi but unused for opi3)
> - cldo2 and cldo3 are unused on opi3 and have nothing to do with WiFi
> - aldo3 is not for dram
> - bldo1 on the other hand is for dram on opi3
> - some other regulators are used for different/more functions and thus
> named differntly
> - USB id-det pin is differnt
> - ...
>
> OrangePi 3 is not a superset of what is defined in sun50i-h6-orangepi.dtsi.
>
> So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd have
> to first move some things out of the base dtsi to the OrangePi Lite2 and One
> Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe HW
> that is *really* shared by these 2 boards and Orange Pi 3.
>
> If I do that, I'd undefine all the axp805 regulator nodes and move the
> configurations to each of the 3 board files. That will probably end up being
> the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for
> what I mean.
>
> What do you think? Is this acceptable to everyone?
Indeed it seems to be a totally different board, not as much in common
as I thought with Lite2 and One Plus.
You should also add your board in Documentation
devicetree/bindings/arm/sunxi.yaml
Regards,
Clement
>
> regards,
> o.
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?h=sunxi/for-next
> >
> > Regards,
> > Clement
> >
> > >
> > > Unfortunately, this board needs some small driver patches, so I have
> > > split the boards DT patch into chunks that require patches for drivers
> > > in various subsystems:
> > >
> > > - Basic DT for the board (patch 1)
> > > - HDMI support (patches 2, 3, 4)
> > > - Ethernet support (patches 5, 6, 7)
> > > - WiFi support (patches 8, 9, 10, 11, 12)
> > >
> > > This patch is also needed to not get segfault on boot:
> > > https://lkml.org/lkml/2019/4/5/856
> > >
> > > Please take a look.
> > >
> > > regards,
> > > Ondrej Jirman
> > >
> > > Icenowy Zheng (2):
> > > net: stmmac: sun8i: add support for Allwinner H6 EMAC
> > > net: stmmac: sun8i: force select external PHY when no internal one
> > >
> > > Ondrej Jirman (10):
> > > arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
> > > drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
> > > dt-bindings: display: sun4i-drm: Add DDC power supply
> > > arm64: dts: allwinner: orange-pi-3: Enable HDMI output
> > > arm64: dts: allwinner: orange-pi-3: Enable ethernet
> > > arm64: dts: allwinner: h6: Add MMC1 pins
> > > pinctrl: sunxi: Prepare for alternative bias voltage setting methods
> > > pinctrl: sunxi: Support I/O bias voltage setting on H6
> > > brcmfmac: Loading the correct firmware for brcm43456
> > > arm64: dts: allwinner: orange-pi-3: Enable WiFi
> > >
> > > .../bindings/display/sunxi/sun4i-drm.txt | 1 +
> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 339 ++++++++++++++++++
> > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 17 +-
> > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> > > .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 22 ++
> > > .../broadcom/brcm80211/brcmfmac/sdio.c | 4 +-
> > > drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 1 +
> > > drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
> > > drivers/pinctrl/sunxi/pinctrl-sunxi.c | 50 ++-
> > > drivers/pinctrl/sunxi/pinctrl-sunxi.h | 7 +-
> > > 12 files changed, 433 insertions(+), 21 deletions(-)
> > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > >
> > > --
> > > 2.21.0
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3
From: Ondřej Jirman @ 2019-04-07 14:32 UTC (permalink / raw)
To: Clément Péron
Cc: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <CAJiuCcew10Q3PUOk4VPoiyFc7ZhXwJzxXHQHNeVBUvVAQ3BkbQ@mail.gmail.com>
On Sun, Apr 07, 2019 at 03:36:21PM +0200, Clément Péron wrote:
> Hi,
>
> On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
> <linux-sunxi@googlegroups.com> wrote:
> >
> > From: Ondrej Jirman <megous@megous.com>
> >
> > This series implements support for Xunlong Orange Pi 3 board.
>
> OrangePi 3 Lite2 and One Plus boards support has already been merged.
> The support is not complete but you should rebase your patches on top
> of sunxi/for-next
Hi,
OrangePi 3 is somewhat different from these two boards (mostly it has a differnt
power tree). It doesn't use the AXP regulators that are defined in the
sun50i-h6-orangepi.dtsi in the same way.
For example:
- bldo3 (is turned always on in sun50i-h6-orangepi.dtsi but unused for opi3)
- cldo2 and cldo3 are unused on opi3 and have nothing to do with WiFi
- aldo3 is not for dram
- bldo1 on the other hand is for dram on opi3
- some other regulators are used for different/more functions and thus
named differntly
- USB id-det pin is differnt
- ...
OrangePi 3 is not a superset of what is defined in sun50i-h6-orangepi.dtsi.
So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd have
to first move some things out of the base dtsi to the OrangePi Lite2 and One
Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe HW
that is *really* shared by these 2 boards and Orange Pi 3.
If I do that, I'd undefine all the axp805 regulator nodes and move the
configurations to each of the 3 board files. That will probably end up being
the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for
what I mean.
What do you think? Is this acceptable to everyone?
regards,
o.
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?h=sunxi/for-next
>
> Regards,
> Clement
>
> >
> > Unfortunately, this board needs some small driver patches, so I have
> > split the boards DT patch into chunks that require patches for drivers
> > in various subsystems:
> >
> > - Basic DT for the board (patch 1)
> > - HDMI support (patches 2, 3, 4)
> > - Ethernet support (patches 5, 6, 7)
> > - WiFi support (patches 8, 9, 10, 11, 12)
> >
> > This patch is also needed to not get segfault on boot:
> > https://lkml.org/lkml/2019/4/5/856
> >
> > Please take a look.
> >
> > regards,
> > Ondrej Jirman
> >
> > Icenowy Zheng (2):
> > net: stmmac: sun8i: add support for Allwinner H6 EMAC
> > net: stmmac: sun8i: force select external PHY when no internal one
> >
> > Ondrej Jirman (10):
> > arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
> > drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
> > dt-bindings: display: sun4i-drm: Add DDC power supply
> > arm64: dts: allwinner: orange-pi-3: Enable HDMI output
> > arm64: dts: allwinner: orange-pi-3: Enable ethernet
> > arm64: dts: allwinner: h6: Add MMC1 pins
> > pinctrl: sunxi: Prepare for alternative bias voltage setting methods
> > pinctrl: sunxi: Support I/O bias voltage setting on H6
> > brcmfmac: Loading the correct firmware for brcm43456
> > arm64: dts: allwinner: orange-pi-3: Enable WiFi
> >
> > .../bindings/display/sunxi/sun4i-drm.txt | 1 +
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 339 ++++++++++++++++++
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 17 +-
> > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> > .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 22 ++
> > .../broadcom/brcm80211/brcmfmac/sdio.c | 4 +-
> > drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 1 +
> > drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
> > drivers/pinctrl/sunxi/pinctrl-sunxi.c | 50 ++-
> > drivers/pinctrl/sunxi/pinctrl-sunxi.h | 7 +-
> > 12 files changed, 433 insertions(+), 21 deletions(-)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> >
> > --
> > 2.21.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3
From: Clément Péron @ 2019-04-07 13:36 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Linus Walleij, David Airlie, Daniel Vetter, Mark Rutland,
Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Maxime Coquelin, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Naveen Gupta, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
linux-gpio
In-Reply-To: <20190405234514.6183-1-megous@megous.com>
Hi,
On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi
<linux-sunxi@googlegroups.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> This series implements support for Xunlong Orange Pi 3 board.
OrangePi 3 Lite2 and One Plus boards support has already been merged.
The support is not complete but you should rebase your patches on top
of sunxi/for-next
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?h=sunxi/for-next
Regards,
Clement
>
> Unfortunately, this board needs some small driver patches, so I have
> split the boards DT patch into chunks that require patches for drivers
> in various subsystems:
>
> - Basic DT for the board (patch 1)
> - HDMI support (patches 2, 3, 4)
> - Ethernet support (patches 5, 6, 7)
> - WiFi support (patches 8, 9, 10, 11, 12)
>
> This patch is also needed to not get segfault on boot:
> https://lkml.org/lkml/2019/4/5/856
>
> Please take a look.
>
> regards,
> Ondrej Jirman
>
> Icenowy Zheng (2):
> net: stmmac: sun8i: add support for Allwinner H6 EMAC
> net: stmmac: sun8i: force select external PHY when no internal one
>
> Ondrej Jirman (10):
> arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
> drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
> dt-bindings: display: sun4i-drm: Add DDC power supply
> arm64: dts: allwinner: orange-pi-3: Enable HDMI output
> arm64: dts: allwinner: orange-pi-3: Enable ethernet
> arm64: dts: allwinner: h6: Add MMC1 pins
> pinctrl: sunxi: Prepare for alternative bias voltage setting methods
> pinctrl: sunxi: Support I/O bias voltage setting on H6
> brcmfmac: Loading the correct firmware for brcm43456
> arm64: dts: allwinner: orange-pi-3: Enable WiFi
>
> .../bindings/display/sunxi/sun4i-drm.txt | 1 +
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 339 ++++++++++++++++++
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 17 +-
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 22 ++
> .../broadcom/brcm80211/brcmfmac/sdio.c | 4 +-
> drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 50 ++-
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 7 +-
> 12 files changed, 433 insertions(+), 21 deletions(-)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
>
> --
> 2.21.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context.
From: Tetsuo Handa @ 2019-04-07 12:58 UTC (permalink / raw)
To: Adham Abozaeid, Ajay Singh, Greg Kroah-Hartman
Cc: linux-wireless, Tetsuo Handa
Since wilc_set_multicast_list() is called with dev->addr_list_lock
spinlock held, we can't use GFP_KERNEL memory allocation.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: e624c58cf8eb5116 ("staging: wilc1000: refactor code to avoid use of wilc_set_multicast_list global")
Cc: Ajay Singh <ajay.kathat@microchip.com>
---
drivers/staging/wilc1000/wilc_netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/wilc_netdev.c b/drivers/staging/wilc1000/wilc_netdev.c
index 1787154..ba78c08 100644
--- a/drivers/staging/wilc1000/wilc_netdev.c
+++ b/drivers/staging/wilc1000/wilc_netdev.c
@@ -708,7 +708,7 @@ static void wilc_set_multicast_list(struct net_device *dev)
return;
}
- mc_list = kmalloc_array(dev->mc.count, ETH_ALEN, GFP_KERNEL);
+ mc_list = kmalloc_array(dev->mc.count, ETH_ALEN, GFP_ATOMIC);
if (!mc_list)
return;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 2/2 net] nfc: nci: Potential off by one in ->pipes[] array
From: David Miller @ 2019-04-06 22:04 UTC (permalink / raw)
To: dan.carpenter
Cc: sameo, christophe.ricard, linux-wireless, kernel-janitors, netdev
In-Reply-To: <20190403071351.GB5758@kadam>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 3 Apr 2019 10:13:51 +0300
> This is similar to commit e285d5bfb7e9 ("NFC: Fix the number of pipes")
> where we changed NFC_HCI_MAX_PIPES from 127 to 128.
>
> As the comment next to the define explains, the pipe identifier is 7
> bits long. The highest possible pipe is 127, but the number of possible
> pipes is 128. As the code is now, then there is potential for an
> out of bounds array access:
>
> net/nfc/nci/hci.c:297 nci_hci_cmd_received() warn: array off by one?
> 'ndev->hci_dev->pipes[pipe]' '0-127 == 127'
>
> Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox