Open
Conversation
Contributor
sarathso
commented
Mar 17, 2026
sarathso
commented
This PR fixes the P2P compilation issues. Change-type: Other Signed-off-by: Sarath Somasekharan <sarath.somasekharan@intel.com>
This PR prevents kcompat_*.h files from getting copied to the staging directory or root folder. Change-type: Other Signed-off-by: Sarath Somasekharan <sarath.somasekharan@intel.com>
Restore the call to vc_xn_shutdown() before handling resets. This avoids delays in cases where a reset is raised in the middle of a soft reset. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: DefectResolution
Set default goal to compile to ensure kernel modules are built when make is invoked without an explicit target. Change-type: Other Signed-off-by: Sarath Somasekharan <sarath.somasekharan@intel.com>
when the idpf driver gets built, this change ensures that the subsequent idpf_* build directory contains the README file as well. Change-type: Other Signed-off-by: Sarath Somasekharan <sarath.somasekharan@intel.com>
It is caused by __builtin_strlen() not smart enough to work. (see also other bug linked from that if interested) Change-type: Other Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Add device ids Change-type: ImplementationChange Signed-off-by: Christopher Pau <christopher.pau@intel.com>
In Linux, PCI Programming Interface is being used to enumerate the LAN APF device. Hence wrapping new device ID definition for Windows and ESX to use them. Change-type: EngineeringNotes Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
This PR adds the ability to turn on/off RCA_SUPPORT, OEM_CAPS & UPLINK_PORT_STATS via the corresponding build flags in the Makefile. Change-type: Other Signed-off-by: Sarath Somasekharan <sarath.somasekharan@intel.com>
The idpf driver previously crashed on unload when IOMMU bypass was enabled. This was due to an incorrect use of platform_data to store the platform_device pointer, which could lead to use-after-free scenarios during unregistration as platform_data is managed by the platform bus core. - Use container_of() to safely retrieve the platform_device pointer from the embedded struct device during de-initialization. - Remove the redundant and unsafe assignment of platform_data in idpf_init_iommu_bypass. - Add GFP_KERNEL flag as additional parameter for iommu_map(). - Remove incorrect assignment of reffilq->dev in idpf_rxq_group_alloc(). Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: DefectResolution
Clear the affinity hint on vport deinit to avoid triggering ... [228423.559328] free_irq+0x328/0x370 [228423.560235] idpf_vport_intr_deinit+0x110/0x150 [idpf] [228423.561636] idpf_vport_stop+0x108/0x1e8 [idpf] [228423.562872] idpf_initiate_soft_reset+0x98/0x2b0 [idpf] [228423.564295] idpf_change_mtu+0xac/0x128 [idpf] [228423.565509] dev_set_mtu_ext+0xec/0x1d0 [228423.566588] dev_set_mtu+0x54/0xc8 Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: DefectResolution
inadvertently removed the mapping of the bufq_sets refillqs pointers to the rxq refillqs pointers. This completely broke the Rx path for XDP since XDP was still accessing the refillqs through the rxqs. The standard datapath is accessing the refillqs through the bufq_sets data path will continue using the bufq_sets refillqs directly. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: DefectResolution
buffer pool") did away the next_to_used based generated completion tag and updating next_to_clean while processing RS completions in flow scheduling mode. The send functions were updated to fetch free buffer IDs to use as tags, but the cleaning functions never posted the IDs back to the refill queues to be used again. Add logic to post recycled buffer IDs back to the sending routines. Furthermore, next_to_clean is never udpated without the RE bit set periodically, meaning the descriptor ring will fill up once and never be usable again. Add the missing logic to set the RE bit. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: DefectResolution
Debug kernel reports possible circular dependency when loading
[ 3473.476364] ======================================================
[ 3473.476421] ------------------------------------------------------
[ 3473.476486]
but task is already holding lock:
...
&adapter->vport_cfg_lock --> &dev->lock --> &block->cb_lock
[ 3473.485556] CPU0 CPU1
[ 3473.485705] ---- ----
[ 3473.485853] lock(&block->cb_lock);
[ 3473.486001] lock(&dev->lock);
[ 3473.486153] lock(&block->cb_lock);
[ 3473.486306] lock(&adapter->vport_cfg_lock);
[ 3473.486459]
*** DEADLOCK ***
Fix by reducing the scope of the vport config lock only for the supported
operation.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Change-type: Other
During a successful reset the driver would re-allocate vport resources while keeping the netdevs intact. However, in case of an error in the init task, the netdev of the failing vport will be unregistered, ip -br a ens801f0 UP ens801f0d1 UP ens801f0d2 UP ens801f0d3 UP echo 1 > /sys/class/net/ens801f0/device/reset ip -br a ens801f0d1 DOWN ens801f0d2 DOWN ens801f0d3 DOWN Re-shuffle the logic in the error path of the init task to make sure the netdevs remain intact. This will allow the driver to attempt recovery via subsequent resets, provided the FW is still functional. The main change is to make sure that idpf_decfg_netdev() is not called should the init task fail during a reset. The error handling is consolidated under unwind_vports, as the removed labels had the same cleanup logic split depending on the point of failure. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: Other
If the init_task fails during a driver load, we end up without vports and netdevs, effectively failing the entire process. In that state a subsequent reset will result in a crash as the service task attempts to access uninitialized resources. Following trace is from an error in the ... ... [40958.178491] <TASK> [40958.179040] process_one_work+0x226/0x6d0 [40958.179609] worker_thread+0x19e/0x340 [40958.180158] ? __pfx_worker_thread+0x10/0x10 [40958.180702] kthread+0x10f/0x250 [40958.181238] ? __pfx_kthread+0x10/0x10 [40958.181774] ret_from_fork+0x251/0x2b0 [40958.182307] ? __pfx_kthread+0x10/0x10 [40958.182834] ret_from_fork_asm+0x1a/0x30 [40958.183370] </TASK> Fix the error handling in the init_task to make sure the service and mailbox tasks are disabled if the error happens during load. These are started in idpf_vc_core_init(), which spawns the init_task and has no way of knowing if it failed. If the error happens on reset, following successful driver load, the tasks can still run, as that will allow the netdevs to attempt recovery through another reset. Stop the PTP callbacks either way as those will be restarted by the call to idpf_vc_core_init() during a successful reset. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: Other
Protect the reset path from callbacks by setting the netdevs to detached state and close any netdevs in UP state until the reset handling has completed. During a reset, the driver will de-allocate resources for the vport, and there is no guarantee that those will recover, which is why the existing vport_ctrl_lock does not provide sufficient protection. idpf_detach_and_close() is called right before reset handling. If the reset handling succeeds, the netdevs state is recovered via call to idpf_attach_and_open(). If the reset handling fails the netdevs remain down. The detach/down calls are protected with RTNL lock to avoid racing with callbacks. On the recovery side the attach can be done without holding the RTNL lock as there are no callbacks expected at that point, due to detach/close always being done first in that flow. The previous logic restoring the netdevs state based on the IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is still being used to restore the state of the netdevs following the reset, but has no use outside of the reset handling flow. idpf_init_hard_reset() is converted to void, since it was used as such and there is no error handling being done based on its return value. Before this change, invoking hard and soft resets simultaneously will ip -br a <inf> UP echo 1 > /sys/class/net/ens801f0/device/reset& \ ethtool -L ens801f0 combined 8 ip -br a <inf> DOWN ip link set <inf> up ip -br a <inf> DOWN Also in case of a failure in the reset path, the netdev is left exposed to external callbacks, while vport resources are not [408508.127256] PGD 2aae2f067 P4D 0 ... ... [408508.139637] <TASK> [408508.140077] __dev_close_many+0xbb/0x260 [408508.140533] __dev_change_flags+0x1cf/0x280 [408508.140987] netif_change_flags+0x26/0x70 [408508.141434] dev_change_flags+0x3d/0xb0 [408508.141878] devinet_ioctl+0x460/0x890 [408508.142321] inet_ioctl+0x18e/0x1d0 [408508.142762] ? _copy_to_user+0x22/0x70 [408508.143207] sock_do_ioctl+0x3d/0xe0 [408508.143652] sock_ioctl+0x10e/0x330 [408508.144091] ? find_held_lock+0x2b/0x80 [408508.144537] __x64_sys_ioctl+0x96/0xe0 [408508.144979] do_syscall_64+0x79/0x3d0 [408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: Other
Refactor the queueing of the mailbox task to be more consistent. Do the first queueing of mbx_task in idpf_init_dflt_mbx(). Always cancel the task in idpf_deinit_dflt_mbx() for deinit and reset flows. And call idpf_mb_intr_rel_irq() first in each flow. Do not queue mbx_task in idpf_mb_intr_rel() while in a middle of a reset to avoid pointless queue/cancel. During a reset the MBX is down, or shutdown by the handlers. Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Change-type: Other
Following the refactor of the logic dealing with mbx_task queueing, there should be no need to hold cq_lock when releasing DMA memory. Add WARN_ON to prevent future changes from introducing a bug. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: DefectResolution
Make sure that recv_ptp_caps_msg is always freed when returning
comm "the_locking_tes", pid 14249, jiffies 4296635040
hex dump (first 32 bytes):
05 02 00 00 00 e1 f5 05 00 00 00 40 01 00 00 00 ...........@....
c5 01 04 01 00 00 00 00 08 40 40 08 0c 40 40 08 .........@@..@@.
backtrace (crc c247c722):
__kmalloc_cache_noprof+0x459/0x740
idpf_ptp_get_caps+0xdc/0x620 [idpf]
idpf_ptp_init+0x8a/0x410 [idpf]
idpf_vc_core_init+0x5de/0x680 [idpf]
idpf_reset_recover+0x83/0x100 [idpf]
idpf_pci_err_resume+0x49/0xd0 [idpf]
pci_reset_function+0x9a/0x130
reset_store+0x5a/0xa0
kernfs_fop_write_iter+0x171/0x220
vfs_write+0x272/0x510
ksys_write+0x6b/0xe0
do_syscall_64+0x79/0x750
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Change-type: Other
* dpll_device_get * dpll_device_put * dpll_pin_get * dpll_pin_put Passing tracker is optional, NULL can be used instead. Add HAVE_ flags generation for these args. Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Change-type: Other
With this approach, drivers can use the updated functions (with tracker arg) without any ifdefs. Also change from 4 different flags to one, as everything was added in a single commit anyway. Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Change-type: Other
Update NEED_DEFINE_GUARD_MUTEX flag detection to check for DEFINE_LOCK_GUARD_1 instead of DEFINE_GUARD in mutex.h. context analysis") converted mutex guards from the old DEFINE_GUARD API to the new DEFINE_LOCK_GUARD_1 API. The compatibility layer was still checking for the old API, causing it to incorrectly define mutex guards that already exist in kernel 7.0+, resulting in type conflicts. The NEED_DEFINE_GUARD_MUTEX flag now correctly detects when DEFINE_LOCK_GUARD_1 with mutex support is present in the kernel, preventing duplicate definitions. Change-type: Other Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
NOT FOR UPSTREAM Prevent issue that 'kc_module_init_impl' defined but not used that hit on PhotonOS 3.0. Signed-off-by: Adrian Pielech<adrian.pielech@intel.com> Change-type: Other
clocks") introduced getcycles64/getcyclesx64 callbacks in ptp_clock_info. Add kcompat-generator check for getcycles64 so older kernels without these callbacks can be handled. Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
was by mistake used DEFINE_SIMPLE_DEV_OPS instead of DEFINE_SIMPLE_DEV_PM_OPS. Change-type: DefectResolution Signed-off-by: Jakub Staniszewski <jakub.staniszewski@intel.com>
While trying to build RPMs on container environement, RHEL was complaining about missing /usr/man directory. Signed-off-by: Adrian Pielech <adrian.pielech@intel.com>
Kernels 6.13+ added helper functions to set resource start and end addresses. Add those helpers here. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
Signed-off-by: Wojciech Panfil <wojciech.panfil@intel.com>
free_irq() returns the devname pointer that was originally passed to request_irq(). In this case, that pointer is ivdm->ctx[vector].name, a kasprintf-allocated string. The code wraps free_irq() in kfree() to free that string, but then immediately calls kfree(ivdm->ctx[vector].name) on the same pointer — resulting in a double-free. kernel BUG at mm/slub.c:379! Call Trace: kfree+0x376/0x3f0 idpf_vdcm_dev_set_vector_signal+0x67/0x170 [idpf] idpf_vdcm_dev_set_vector_signals+0x5e/0xa0 [idpf] idpf_vdcm_dev_ioctl+0x563/0x5f0 [idpf] Fix by removing the redundant kfree(ivdm->ctx[vector].name) since kfree(free_irq(...)) already frees it. Change-type: Other Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
- Counter module in the FXP will send incremental updates to the software. Thus, it is necessary to add those queues via firmware Signed-off-by: Jayaprakash Shanmugam <jayaprakash.shanmugam@intel.com>
Use the new virtchnl2 OP codes to communicate with the Control Plane to
add flow steering filters. We add the basic functionality for add/delete
with TCP/UDP IPv4 only. Support for other OP codes and protocols will be
added later.
# ethtool -N ens801f0d1 flow-type tcp4 src-ip 10.0.0.1 action 6
to route all IPv4/TCP traffic from IP 10.0.0.1 to queue 6.
Change-type: Other
Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
Backport of f9841bd28b600526ca4f6713b0ca49bf7bb98452 The flow steering list maintains entries that are added and removed as ethtool creates and deletes flow steering rules. Module removal with active entries causes memory leak as the list is not properly cleaned up. Prevent this by iterating through the remaining entries in the list and freeing the associated memory during module removal. Add a spinlock (flow_steer_list_lock) to protect the list access from multiple threads. Change-type: Other Signed-off-by: Sreedevi Joshi <sreedevi.joshi@intel.com> Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
When ethtool -n is executed on an interface to display the flow steering
The flow steering list maintained in the driver currently stores only the
location and q_index but other fields of the ethtool_rx_flow_spec are not
stored. This may be enough for the virtchnl command to delete the entry.
However, when the ethtool -n command is used to query the flow steering
rules, the ethtool_rx_flow_spec returned is not complete causing the
error below.
Resolve this by storing the flow spec (fsp) when rules are added and
returning the complete flow spec when rules are queried.
Also, change the return value from EINVAL to ENOENT when flow steering
entry is not found during query by location or when deleting an entry.
Add logic to detect and reject duplicate filter entries at the same
location and change logic to perform upfront validation of all error
conditions before adding flow rules through virtchnl. This avoids the
need for additional virtchnl delete messages when subsequent operations
fail, which was missing in the original upstream code.
ethtool -n eth1
2 RX rings available
Total 2 rules
rxclass: Unknown flow type
rxclass: Unknown flow type
ethtool -n eth1
2 RX rings available
Total 2 rules
Rule Type: TCP over IPv4
Src IP addr: 10.0.0.1 mask: 0.0.0.0
Dest IP addr: 0.0.0.0 mask: 255.255.255.255
TOS: 0x0 mask: 0xff
Src port: 0 mask: 0xffff
Dest port: 0 mask: 0xffff
Action: Direct to queue 0
Rule Type: UDP over IPv4
Src IP addr: 10.0.0.1 mask: 0.0.0.0
Dest IP addr: 0.0.0.0 mask: 255.255.255.255
TOS: 0x0 mask: 0xff
Src port: 0 mask: 0xffff
Dest port: 0 mask: 0xffff
Action: Direct to queue 0
Change-type: Other
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
Signed-off-by: Sreedevi Joshi <sreedevi.joshi@intel.com>
Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
IDPF supports learning what LAN memory regions in the BAR. It does this by mapping static regions (mbx and rstat) for initial mailbox communication. Then retrieving the remaining regions from the control plane. Remove the old implementation that split the BAR mapping into 2 regions. Add the static regions and the dynamic list for the remaining regions. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: FeatureImplementation
memory regions"). The RDMA driver needs to map its own MMIO regions for the sake of performance, meaning the IDPF needs to avoid mapping portions of the BAR space. However, to be HW agnostic, the IDPF cannot assume where these are and must avoid mapping hard coded regions as much as possible. The IDPF maps the bare minimum to load and communicate with the control plane, i.e., the mailbox registers and the reset state registers. Because of how and when mailbox register offsets are initialized, it is easier to adjust the existing defines to be relative to the mailbox region starting address. Use a specific mailbox register write function that uses these relative offsets. The reset state register addresses are calculated the same way as for other registers, described below. The IDPF then calls a new virtchnl op to fetch a list of MMIO regions that it should map. The addresses for the registers in these regions are calculated by determining what region the register resides in, adjusting the offset to be relative to that region, and then adding the register's offset to that region's mapped address. If the new virtchnl op is not supported, the IDPF will fallback to mapping the whole bar. However, it will still map them as separate regions outside the mailbox and reset state registers. This way we can use the same logic in both cases to access the MMIO space. auxiliary driver will not be able to load with this implementation until the rest of the IDC series is backported. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: FeatureImplementation
Improve the logic on shutdown to make sure netdevs are brought down and - Set IDPF_REMOVE_IN_PROG flag since it provides protection similar to what is needed on remove. Mainly it will help short circuit the init task if shutdown happens to be called in the middle. Mailbox is also stopped which avoids delays in that path due to VC messages timing out. - Lock the calls to vc_core_deinit() to ensure the shutdown doesn't race with the remove callback and/or the init task. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: DefectResolution
Fix possible race in idpf_vc_xn_push_free() by protecting the set_bit() call with a spilock consistent with rest of the code where the bitmap is modified. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: DefectResolution
To ease backporting efforts, remove the previous IDC implementation. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: EngineeringNotes
Align with upstream commit bfc5cc8b5aecc9b0249322e39d8d6f65bd7c91ac Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
IEPS needs NAC topology details to initialize the CPI resource structure for DFX and Link management functions. Change-type: ImplementationChange Signed-off-by: Shubham Das <shubham.das@intel.com>
Add missing fields in iidc.h used by IDPF, and and IDPF specific iidc header. Bump version to 11.0. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
create, init, and destroy"). Add the initial idpf_idc.c file with the functions to kick off the IDC initialization, create and initialize a core RDMA auxiliary device, and destroy said device. The RDMA core has a dependency on the vports being created by the control plane before it can be initialized. Therefore, once all the vports are up after a hard reset (either during driver load a function level reset), the core RDMA device info will be created. It is populated with the function type (as distinguished by the IDC initialization function pointer), the core idc_ops function points (just stubs for now), the reserved RDMA MSIX table, and various other info the core RDMA auxiliary driver will need. It is then plugged on to the bus. During a function level reset or driver unload, the device will be unplugged from the bus and destroyed. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
auxiliary dev create, init, and destroy"). Implement the functions to create, initialize, and destroy an RDMA vport auxiliary device. The vport aux dev creation is dependent on the core aux device to call idpf_idc_vport_dev_ctrl to signal that it is ready for vport aux devices. Implement that core callback to either create and initialize the vport aux dev or deinitialize. RDMA vport aux dev creation is also dependent on the control plane to tell us the vport is RDMA enabled. Add a flag in the create vport message to signal individual vport RDMA capabilities. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
RDMA core callbacks and handlers"). Implement the idpf_idc_request_reset and idpf_idc_rdma_vc_send_sync callbacks for the rdma core auxiliary driver to issue reset events to the idpf and send (synchronous) virtchnl messages to the control plane respectively. Implement and plumb the reset handler for the opposite flow as well, i.e. when the idpf is resetiing and needs to notify the rdma core auxiliary driver. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
driver MTU change handler"). The only event an RDMA vport aux driver cares about right now is an MTU change on its underlying vport. Implement and plumb the handler to signal the pre MTU change event and post MTU change events to the RDMA vport aux driver. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
Temporarily add logic back to only create and initialize a vport auxiliary device for vport0 to ease integration. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
Bump version for MEV 2.10 release Change-type: Other Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
This reverts commit ac37b936accf823dac4581224fc9996b07f9c037. Added spinlock protection is causing an issue with nested spinlocks. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Change-type: Other
With the dynamic BAR region management, the mailbox interrupt register (dyn_ctl[0]) is not working properly on Simics. Keep the mailbox in poll mode for now. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: DefectResolution
Bump version for MEV 2.10 release Change-type: Other Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
The in-tree core device info struct consists only of the pdev, adev, rdma_protocol, and iidc_priv fields. By placing these fields first in the OOT driver struct, OOT irdma will be compatible with the in-tree IDPF. Rearrange these fields to be placed first and add a note about their placement. Also fix the vport aux dev event handler iidc_event param to be consistent with current header naming. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
Bump version for MEV 2.10 release Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
The ADI read/write_reg32 functions use idpf_get_mbx_reg_addr() to
access PF_MBX registers (at BAR0 offset 0x08000000). This function
hw.mbx.vaddr + reg_offset
regions"), hw.mbx.vaddr was mapped in a way that made this arithmetic
produce valid addresses. After that commit, hw.mbx.vaddr is ioremapped
at PF_FW_BASE (0x08400000) covering only 4K (IDPF_PF_MBX_REGION_SZ).
Adding an absolute PF_MBX offset like PF_MBX_ARQT(0) = 0x08000010 to
this base produces an address 128 MB past the mapped region, triggering
[ffff800089109010] pgd=..., pmd=0000000000000000
pc : idpf_adi_write_reg32+0x5c/0x480 [idpf]
The PF_MBX registers live in the LAN BAR region preceding PF_FW_BASE,
which is covered by hw.lan_regs[]. Switch all 20 PF_MBX_* accesses in
idpf_adi_read_reg32() and idpf_adi_write_reg32() from
idpf_get_mbx_reg_addr() to idpf_get_reg_addr(), which properly searches
lan_regs[] for the matching region and computes region-relative virtual
addresses.
The queue tail and interrupt register cases already used
idpf_get_reg_addr() and were unaffected.
Change-type: DefectResolution
Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
The IDC workaround to prevent anything but the very first vport from creating a vdev was in the wrong place. Each vports vdev_info was still allocated but not initialized. Consequently, if a reset occurred, the next call to idpf_idc_vport_dev_ctrl would try to bring all of the vdevs up (though 3 would be uninitialized) resulting in a crash. Move the workarond to the start idpf_idc_init_aux_vport_dev to prevent the extra vdev info structs from being allocated. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: Other
and use the correct mailbox related get_mbx_reg_addr API. The mailbox interrupt handler was mistakenly looking for the mailox len register in one of the other LAN regions when it should have been using the static mailbox region. Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Change-type: DefectResolution
Bump version for MEV 2.10 release Change-type: EngineeringNotes Signed-off-by: Madhu Chittim <madhu.chittim@intel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.