Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4k page brcmfmac brcmf_pcie_init_dmabuffer_for_device dma_alloc_coherent fails #47

Closed
CathyKMeow opened this issue Aug 23, 2022 · 6 comments

Comments

@CathyKMeow
Copy link

4k page brcmfmac brcmf_pcie_init_dmabuffer_for_device dma_alloc_coherent fails

Device model

MacBook Pro 14-inch, 2021, M1 Pro, 10 core CPU, 16 GiB memory

macOS version

12.3.1

Kernel log

4k:

$ sudo dmesg | grep -E 'brcmfmac|jrydclleyafhlwt'
[    1.189418] usbcore: registered new interface driver brcmfmac
[    1.189690] brcmfmac 0000:01:00.0: Adding to iommu group 3
[    1.189695] brcmfmac 0000:01:00.0: Removing from iommu group 3
[    1.189713] brcmfmac 0000:01:00.0: enabling device (0000 -> 0002)
[    1.298215] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4387c2-pcie for chip BCM4387/7
[    1.298966] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN-u-4.7-X2.bin failed with error -2
[    1.299976] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN-u-4.7.bin failed with error -2
[    1.299999] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN-u.bin failed with error -2
[    1.300014] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN.bin failed with error -2
[    1.300058] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-X2.bin failed with error -2
[    2.138005] jrydclleyafhlwt   CCCCCCCCCCCCCC 2560 0
[    2.138045] jrydclleyafhlwt   AAAAAAAAAAAAAA 2560
[    2.138074] brcmfmac 0000:01:00.0: brcmf_pcie_init_ringbuffers: Allocating ring buffers failed
$ sudo iwctl station list
                            Devices in Station Mode                            
--------------------------------------------------------------------------------
  Name                  State            Scanning
--------------------------------------------------------------------------------
No devices in Station mode available.

16k:

$ sudo dmesg | grep -E 'brcmfmac|jrydclleyafhlwt'
[    1.142057] usbcore: registered new interface driver brcmfmac
[    1.142515] brcmfmac 0000:01:00.0: Adding to iommu group 4
[    1.142558] brcmfmac 0000:01:00.0: enabling device (0000 -> 0002)
[    1.257236] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4387c2-pcie for chip BCM4387/7
[    1.257974] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN-u-4.7-X2.bin failed with error -2
[    1.257994] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN-u-4.7.bin failed with error -2
[    1.258008] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN-u.bin failed with error -2
[    1.258023] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-TPHN.bin failed with error -2
[    1.258058] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4387c2-pcie.apple,maldives-X2.bin failed with error -2
[    2.022143] jrydclleyafhlwt   CCCCCCCCCCCCCC 2560 ffff800009fb4000
[    2.022182] jrydclleyafhlwt   BBBBBBBBBBBBBB 2560
[    2.022214] jrydclleyafhlwt   CCCCCCCCCCCCCC 32768 ffff80000ab90000
[    2.022247] jrydclleyafhlwt   BBBBBBBBBBBBBB 32768
[    2.022279] jrydclleyafhlwt   CCCCCCCCCCCCCC 1536 ffff80000a478000
[    2.022313] jrydclleyafhlwt   BBBBBBBBBBBBBB 1536
[    2.022344] jrydclleyafhlwt   CCCCCCCCCCCCCC 24576 ffff80000abb8000
[    2.022377] jrydclleyafhlwt   BBBBBBBBBBBBBB 24576
[    2.022410] jrydclleyafhlwt   CCCCCCCCCCCCCC 40960 ffff80000abc4000
[    2.022443] jrydclleyafhlwt   BBBBBBBBBBBBBB 40960
[    2.083446] brcmfmac: brcmf_c_process_txcap_blob: TxCap blob found, loading
[    2.084333] brcmfmac: brcmf_c_process_cal_blob: Calibration blob provided by platform, loading
[    2.094411] brcmfmac: brcmf_c_preinit_dcmds: Fi

$ uname -a
Linux localhost 5.19.0-asahi-5-2-4kpage-ARCH #2 SMP PREEMPT_DYNAMIC Mon, 22 Aug 2022 00:00:00 +0000 aarch64 GNU/Linux


--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1099,6 +1099,8 @@ brcmf_pcie_init_dmabuffer_for_device(struct brcmf_pciedev_info *devinfo,
 
        ring = dma_alloc_coherent(&devinfo->pdev->dev, size, dma_handle,
                                  GFP_KERNEL);
+
+       printk(KERN_EMERG "jrydclleyafhlwt   CCCCCCCCCCCCCC %d %lx\n", size, ring);
        if (!ring)
                return NULL;
 
@@ -1131,8 +1133,11 @@ brcmf_pcie_alloc_dma_and_ring(struct brcmf_pciedev_info *devinfo, u32 ring_id,
        dma_buf = brcmf_pcie_init_dmabuffer_for_device(devinfo, size,
                        tcm_ring_phys_addr + BRCMF_RING_MEM_BASE_ADDR_OFFSET,
                        &dma_handle);
-       if (!dma_buf)
+       if (!dma_buf) {
+               printk(KERN_EMERG "jrydclleyafhlwt   AAAAAAAAAAAAAA %d\n", size);
                return NULL;
+       }
+       printk(KERN_EMERG "jrydclleyafhlwt   BBBBBBBBBBBBBB %d\n", size);
 
        addr = tcm_ring_phys_addr + BRCMF_RING_MAX_ITEM_OFFSET;
        brcmf_pcie_write_tcm16(devinfo, addr, brcmf_ring_max_item[ring_id]);
`
@jannau
Copy link
Member

jannau commented Aug 23, 2022

PCIe needs the IOMMU work and the IOMMU supports on a page size of 16k. There will be ways around that but those are not yet there.

Shall we make CONFIG_PCIE_APPLE depend on CONFIG_ARM64_PAGE_SHIFT=14?

@svenpeter42
Copy link
Member

Either that and/or add a much bigger warning when we get a DART hat has force_bypass and !supports_bypass

@jannau
Copy link
Member

jannau commented Sep 9, 2022

unless the bigger warning is BUG_ON() I fear it will be still missed. With #52 it will be

Bob: WiFi is broken
Alice: does lspci show anything
Bob: no
Alice: is PCIE_APPLE enabled?
Bob: no

At that point it is self documented why PCIe is not enabled

@CathyKMeow
Copy link
Author

CathyKMeow commented Sep 25, 2022

Is iommu-4k/dev ready? I merged it and the IOMMU works, but I'm not sure if it is safe, as it is related to the IOMMU / security.

@svenpeter42
Copy link
Member

If it was ready it would have been merged into either asahi or upstream. If you merge it yourself you are on your own and get to keep the parts if it breaks.

That being said, it does work but the implementation is a bit of a hack and I’m waiting for another series by Robin Murphy which cleans up the iommu API before I continue working on it.

We also deliberately don’t want to provide a 4K kernel to encourage people to fix software that breaks though because there’s a measurable performance decrease.

marcan pushed a commit that referenced this issue Nov 15, 2022
syzbot reported a warning like below [1]:

WARNING: CPU: 3 PID: 9 at net/netfilter/nf_tables_api.c:10096 nf_tables_exit_net+0x71c/0x840
Modules linked in:
CPU: 2 PID: 9 Comm: kworker/u8:0 Tainted: G        W          6.1.0-rc3-00072-g8e5423e991e8 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
Workqueue: netns cleanup_net
RIP: 0010:nf_tables_exit_net+0x71c/0x840
...
Call Trace:
 <TASK>
 ? __nft_release_table+0xfc0/0xfc0
 ops_exit_list+0xb5/0x180
 cleanup_net+0x506/0xb10
 ? unregister_pernet_device+0x80/0x80
 process_one_work+0xa38/0x1730
 ? pwq_dec_nr_in_flight+0x2b0/0x2b0
 ? rwlock_bug.part.0+0x90/0x90
 ? _raw_spin_lock_irq+0x46/0x50
 worker_thread+0x67e/0x10e0
 ? process_one_work+0x1730/0x1730
 kthread+0x2e5/0x3a0
 ? kthread_complete_and_exit+0x40/0x40
 ret_from_fork+0x1f/0x30
 </TASK>

In nf_tables_exit_net(), there is a case where nft_net->commit_list is
empty but nft_net->module_list is not empty.  Such a case occurs with
the following scenario:

1. nfnetlink_rcv_batch() is called
2. nf_tables_newset() returns -EAGAIN and NFNL_BATCH_FAILURE bit is
   set to status
3. nf_tables_abort() is called with NFNL_ABORT_AUTOLOAD
   (nft_net->commit_list is released, but nft_net->module_list is not
   because of NFNL_ABORT_AUTOLOAD flag)
4. Jump to replay label
5. netlink_skb_clone() fails and returns from the function (this is
   caused by fault injection in the reproducer of syzbot)

This patch fixes this issue by calling __nf_tables_abort() when
nft_net->module_list is not empty in nf_tables_exit_net().

Fixes: eb014de ("netfilter: nf_tables: autoload modules from the abort path")
Link: https://syzkaller.appspot.com/bug?id=802aba2422de4218ad0c01b46c9525cc9d4e4aa3 [1]
Reported-by: syzbot+178efee9e2d7f87f5103@syzkaller.appspotmail.com
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
marcan pushed a commit that referenced this issue Mar 28, 2023
syzbot reported a warning[1] where the bond device itself is a slave and
we try to enslave a non-ethernet device as the first slave which fails
but then in the error path when ether_setup() restores the bond device
it also clears all flags. In my previous fix[2] I restored the
IFF_MASTER flag, but I didn't consider the case that the bond device
itself might also be a slave with IFF_SLAVE set, so we need to restore
that flag as well. Use the bond_ether_setup helper which does the right
thing and restores the bond's flags properly.

Steps to reproduce using a nlmon dev:
 $ ip l add nlmon0 type nlmon
 $ ip l add bond1 type bond
 $ ip l add bond2 type bond
 $ ip l set bond1 master bond2
 $ ip l set dev nlmon0 master bond1
 $ ip -d l sh dev bond1
 22: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000
 (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we
  try to delete it)

[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef
[2] commit 7d5cd2c ("bonding: correctly handle bonding type change on enslave failure")
[3] example warning:
 [   27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address
 [   27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address
 [   32.464639] bond1 (unregistering): Released all slaves
 [   32.464685] ------------[ cut here ]------------
 [   32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780
 [   32.464694] Modules linked in: br_netfilter bridge bonding virtio_net
 [   32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47
 [   32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
 [   32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780
 [   32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59
 [   32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206
 [   32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000
 [   32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520
 [   32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728
 [   32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140
 [   32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140
 [   32.464723] FS:  00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000
 [   32.464725] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 [   32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0
 [   32.464730] Call Trace:
 [   32.464763]  <TASK>
 [   32.464767]  rtnl_dellink+0x13e/0x380
 [   32.464776]  ? cred_has_capability.isra.0+0x68/0x100
 [   32.464780]  ? __rtnl_unlock+0x33/0x60
 [   32.464783]  ? bpf_lsm_capset+0x10/0x10
 [   32.464786]  ? security_capable+0x36/0x50
 [   32.464790]  rtnetlink_rcv_msg+0x14e/0x3b0
 [   32.464792]  ? _copy_to_iter+0xb1/0x790
 [   32.464796]  ? post_alloc_hook+0xa0/0x160
 [   32.464799]  ? rtnl_calcit.isra.0+0x110/0x110
 [   32.464802]  netlink_rcv_skb+0x50/0xf0
 [   32.464806]  netlink_unicast+0x216/0x340
 [   32.464809]  netlink_sendmsg+0x23f/0x480
 [   32.464812]  sock_sendmsg+0x5e/0x60
 [   32.464815]  ____sys_sendmsg+0x22c/0x270
 [   32.464818]  ? import_iovec+0x17/0x20
 [   32.464821]  ? sendmsg_copy_msghdr+0x59/0x90
 [   32.464823]  ? do_set_pte+0xa0/0xe0
 [   32.464828]  ___sys_sendmsg+0x81/0xc0
 [   32.464832]  ? mod_objcg_state+0xc6/0x300
 [   32.464835]  ? refill_obj_stock+0xa9/0x160
 [   32.464838]  ? memcg_slab_free_hook+0x1a5/0x1f0
 [   32.464842]  __sys_sendmsg+0x49/0x80
 [   32.464847]  do_syscall_64+0x3b/0x90
 [   32.464851]  entry_SYSCALL_64_after_hwframe+0x44/0xae
 [   32.464865] RIP: 0033:0x7f297bf2e5e7
 [   32.464868] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
 [   32.464869] RSP: 002b:00007ffd96c824c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
 [   32.464872] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f297bf2e5e7
 [   32.464874] RDX: 0000000000000000 RSI: 00007ffd96c82540 RDI: 0000000000000003
 [   32.464875] RBP: 00000000640f19de R08: 0000000000000001 R09: 000000000000007c
 [   32.464876] R10: 00007f297bffabe0 R11: 0000000000000246 R12: 0000000000000001
 [   32.464877] R13: 00007ffd96c82d20 R14: 00007ffd96c82610 R15: 000055bfe38a7020
 [   32.464881]  </TASK>
 [   32.464882] ---[ end trace 0000000000000000 ]---

Fixes: 7d5cd2c ("bonding: correctly handle bonding type change on enslave failure")
Reported-by: syzbot+9dfc3f3348729cc82277@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Acked-by: Jonathan Toppins <jtoppins@redhat.com>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dberlin pushed a commit to dberlin/linux that referenced this issue Oct 27, 2023
commit 72377ab upstream.

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a AsahiLinux#47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
marcan pushed a commit that referenced this issue Nov 19, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
@jannau
Copy link
Member

jannau commented Apr 29, 2024

closing as resolved since CONFIG_PCIE_APPLE now depends on ARM64_PAGE_SHIFT = 14

@jannau jannau closed this as completed Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants