PCIE_MCC驱动阅读过程--HOST篇

最新推荐文章于 2024-03-01 19:28:37 发布
最新推荐文章于 2024-03-01 19:28:37 发布
阅读量1.5k 收藏 10
点赞数 2
分类专栏： kernel pcie 文章标签： linux kernel
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_38878510/article/details/109648061
版权
kernel 同时被 2 个专栏收录
25 篇文章 17 订阅
订阅专栏
pcie
3 篇文章 1 订阅
订阅专栏

PCIE_MCC驱动阅读过程–HOST篇

文章目录


先看一下海思提供的 pcie_mcc代码里面的文档《主片引导从片启动方法.txt》，给出了几个模块的加载顺序，这里就先拿HOST端的加载顺序来看一下： 

insmod hi35xx_dev_host.ko
insmod irq_map_host.ko
insmod boot_device.ko
./booter start_device
insmod pcit_dma_host.ko
insmod mcc_drv_host.ko
insmod mcc_usrdev_host.ko

从上面看，最底层的hi35xx_dev_host.ko，那么就先从这个看；一般直接与应用程序交互的应该是mcc_usrdev_host.ko。但由于海思好像把相关接口封装在了hi35xxvxxx_pciv.ko模块和libpciv.a库，源码不提供，所以就没有办法进行太多的分析，只能着重上面几个模块的分析。在实际看代码过程中并不是简单的从顶之下或者从底到上，都是看各个模块之间的关联关系。

hi35xx_dev_host.ko

init

模块注册部分如下，exit部分就是init部分的逆过程：

在这里插入图片描述

主要看一下init的过程：

在这里插入图片描述

pci_register_driver()注册驱动后，会在/sys/bus/pci/drivers/目录下看到对应名字的目录，名字就是PCI_HIDEV_MODULE（pci_hidev_driver具体内容看下一节probe）。

看一下hidev_host_init()函数，就是针对于HOST端的特定函数赋值，相关函数后面用到了再进行细看。

在这里插入图片描述

看一下架构相关的pci_arch_init()函数，
在这里插入图片描述在这里插入图片描述

看一下host_pcie_controller_init()函数，主要涉及硬件中断号的配置。0x12200000就是海思Hi3559AV100芯片的PCI Express控制器寄存器，包括做EP时的TYPE0以及做RC是的TYPE1的协议标准寄存器，以及内部其他的寄存器。

在这里插入图片描述

probe

回过头看pci_register_driver(&pci_hidev_driver)这一行代码，pci_hidev_driver的内容如下所示：

在这里插入图片描述

着重先看一下probe过程，这个probe被调用证明更底层的驱动或是硬件检测到了PCIe设备的接入并且驱动的pci_device_id匹配上了。因为只有PCIe做EP时寄存器描述才有BAR的概念，所以这个probe过程中获取的BAR资源应该都是指EP端的资源。
在这里插入图片描述
在这里插入图片描述

alloc_hi35xxdev()函数就是一个简单的申请内存并清零的一个过程：

在这里插入图片描述

mk_slot_index()函数是获取设备的总线号：

在这里插入图片描述

irq_map_host.ko

这个驱动就是针对上面的hi35xx_dev_host.ko初始化之后，获取PCIe的几个硬件中断号。

在这里插入图片描述

对应的设备树如下：143~146是INT_A~INT_D的中断线，对应芯片数据手册的中断源175~178，147是PCIE_EDMA的中断号，对应芯片数据手册的中断源179，38对应的中断源是70，数据手册上注明是SOFTWARE，是专门用于软件的中断号？

在这里插入图片描述

boot_device.ko

init

模块的注册是注册一个杂项设备，设备名称是/dev/hisi_boot，具体的操作集是boot_usrdev_fops。

在这里插入图片描述

pcie_arch_init()也是几个函数指针的赋值：

在这里插入图片描述

pcie_cfg_store()：为两个全局变量申请内存，并读取对端设备的配置。

在这里插入图片描述

store_pci_context()：读对端设备的相关配置信息。

在这里插入图片描述

open/release/read/write/poll

这几个函数都没有什么太多的内容，pool的函数也是空的，这里就不截图放下来了。

在这里插入图片描述

ioctl

这个驱动的ioctl()提供4个命令：

  • HI_GET_ALL_DEVICES ： 获取所有设备
  • HI_PCIE_TRANSFER_DATA ： 传输数据
  • HI_START_TARGET_DEVICE ： 启动目标设备
  • HI_RESET_TARGET_DEVICE ： 复位目标设备

在这里插入图片描述
在这里插入图片描述

HI_GET_ALL_DEVICES

这个命令调用的函数是pcie_boot_get_devices_info()，是一个简单的遍历过程。

在这里插入图片描述

HI_PCIE_TRANSFER_DATA

这个命令调用的函数是pcie_boot_transfer_data()，pcie_arch_init()时将g_boot_opt.init_ddr初始化为init_ddr()，将g_boot_opt.transfer_data初始化为transfer_data().

在这里插入图片描述

init_ddr

init_ddr()函数如下所示：海思u-boot的前面32KB是一些初始化DDR的代码，寄存器信息以及加密验签的信息，这里如果是要调用DDR初始化，则u-boot的前面32KB发送到对端；否则知识简单地进行寄存器的初始化。

在这里插入图片描述

slave_ddr_init()函数如下：先写对端的一些寄存器（海思特有的一些初始化标记），然后将对端的片内RAM映射（Hi3559AV100的片内RAM空间地址从0x08000000开始的1MB）。将u-boot的前面32K拷贝到对面的片内RAM之后，对端的芯片就可以初始化DDR了（对端的Hi3559AV100芯片是设置的DDR启动模式，这时候再把完整的u-boot传到对面就可以跑u-boot了。）

在这里插入图片描述

slave_reg_write()与slave_reg_read()函数如下：都是判断一下当前要写的寄存器地址是否已经经过move_pf_window_in映射进来了，如果当前要写的寄存器没有映射过，那么就将对端的寄存器映射BAR1上，然后再直接写映射出来的地址。（芯片的ATU会将读写操作自己转换成PCIe的TLP相应的事务。）

在这里插入图片描述

move_pf_window_in

看一下move_pf_window_in()函数：传入要映射的对端的的地址，再使能ATU地址转换。根据海思的手册意思，配置了ATU地址转换，那么访问对应的地址空间都会被ATU转换成对应的PCIe事务去处理。（目前的关键点是理解这个操作，彻底理解了之后阅读过程就轻松些了。）

在这里插入图片描述

pci_config_write()函数如下：读写对端的配置信息。

在这里插入图片描述

到内核的pci驱动的pci_bus_write_config_dword()函数：用自旋锁保护的读写操作宏。

在这里插入图片描述

这里的bus->ops->read/write应该是指向drivers/pci/hipcie/pcie.c里面的pcie_read_conf()和pcie_write_conf()。根据总线号来判断要写对端设备还是写当前设备。

在这里插入图片描述

这里我们应该是要写入到对端的设备的，走pcie_write_to_device()：

在这里插入图片描述

里面的pcie_read_from_device()函数如下：通过__to_pcie_address()函数转换后读对应偏移的值。

在这里插入图片描述

to_pcie_address()函数如下：info->base_addr是架构相关的PCIe初始化时通过ioremap_nocache映射的芯片PCIe控制器的配置空间。

在这里插入图片描述

假如是写入当前总线控制器，即ROOT BUS的，就没有了上面的to_pcie_address()函数，取而代之的是芯片的PCIe控制器的寄存器（注意是控制器的寄存器，而不是标准的PCIe配置寄存器。这片空间在初始化时通过ioremap_nocache()函数映射过了），pcie_write_to_dbi()函数：
在这里插入图片描述

pcie_read_from_dbi()函数：info->conf_base_addr是

在这里插入图片描述

transfer_data

transfer_data()函数如下：这里的move_pf_window_in的序号是0，按照理解应该是映射目标地址到BAR0上，Hi3559AV100的BAR0有8MB大小，这里是用来传输数据。这里的目标地址，比如在DDR初始化时，就是DDR地址了。

在这里插入图片描述

HI_START_TARGET_DEVICE

这个命令调用的函数是pcie_boot_start_device，判断总线号后调用start_device()。

在这里插入图片描述

start_device()函数就是一个写寄存器的过程，跟架构有关系，暂时就先不细看了。

在这里插入图片描述

HI_RESET_TARGET_DEVICE

这个命令调用的函数是pcie_boot_start_device，判断总线号后调用reset_device()。

在这里插入图片描述

reset_device()函数就是一个写寄存器之后再将对端设备信息保存下来。

在这里插入图片描述

./booter start_device

main函数

先看一下main()函数：检验参数之后，ioctl()获取所有的设备，然后进行业务处理。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

u-boot传输

u-boot的传输过程如下，特别的地方是增加了一个NEED_DDR_INIT标记。这部分代码可以回头看boot_device.ko的ioctl部分，至于其他的uImage的传输，除了少了一个DDR初始化的过程，基本一致的。

在这里插入图片描述

pcit_dma_host.ko

init

模块注册部分如下，exit部分就是init部分的逆过程：

在这里插入图片描述

主要看一下init的过程：

在这里插入图片描述

看DMA读写通道的初始过程：内部有两个DMA通道，调用trans_list_init()对内部的相关链表初始化后，再初始化了读写的自旋锁和信号量。

在这里插入图片描述

trans_list_init()初始化完后，最后加到free_list_head链表后。

在这里插入图片描述

dma_channel结构体如下：与内核DMA engine的不一样。

在这里插入图片描述

还有一个DMA中断相关的初始化：中断处理函数设置为host_dma_irq_handler()，然后申请中断资源。

在这里插入图片描述

看一下中断资源申请的，清除读写中断后，申请中断资源，再使能中断。

在这里插入图片描述

再回头看一下中断处理函数，调用__do_pcit_dma_trans()分别处理读写中断。

在这里插入图片描述

__do_pcit_dma_trans()处理的过程大概如下所示：根据读写方向，读取读写的中断状态，传输被打断则开启新的DMA传输，完成后将DMA传输相关的描述资源移动到free链表中，如果busy链表非空则继续DMA传输。具体的start_dma_task()->__start_dma_task()主要是一个写寄存器的过程，这里就不细看了，需要和寄存器手册对应着看就比较清晰了。

在这里插入图片描述
在这里插入图片描述

open/release/read/write/poll

pci_dma_miscdev结构体指向的fops操作集如下所示：

在这里插入图片描述

读写等操作函数基本没有什么内容，如下所示：

在这里插入图片描述

ioctl

相关的操作还是放在ioctl上，实现了读写操作，用pcit_create_task()函数来实现。

在这里插入图片描述

pcit_create_task()函数里面注释主要解释了一下DMA操作时的DMA地址情况，

在这里插入图片描述

可以对比一下手册上关于这个的描述：

在这里插入图片描述

__pcit_create_task()函数根据不同的方向使用不同的描述数据。

在这里插入图片描述

__do_create_task()函数：根据不同的类型选择对应的链表头，如果业务繁忙则退出；否则从空闲链表中取出一个，开启新的DMA传输（原来没有任何数据在传输）或者放到busy链表中（原来有数据传输，等终端触发后自动发起新的DMA传输）。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

mcc_drv_host.ko

这一个模块只是单纯地提供一些接口，算是承前启后的作用，后面用到就进行分析一下。

在这里插入图片描述

mcc_usrdev_host.ko

先看一下mcc_usrdev_host.ko的代码，查看Makefile，可以看到这个模块是由下面两个文件编译而成的：

mcc_usrdev_host-objs := mcc_core/hios_mcc/hios_mcc_usrdev.o mcc_core/hios_mcc/hios_mcc.o

init

先看hios_mcc_usrdev.c，可以看到这个模块是注册了一个杂项设备。

在这里插入图片描述

这个杂项设备驱动提供了一些标准的字符设备的操作接口，open/close，read/write，ioctl/poll这些接口。

在这里插入图片描述

open

先看一下提供的的open()函数，可以看到函数很简单，就是把file->private_data指针置空了。

在这里插入图片描述

read

再看一下read()函数，这个函数就是查看一下链表里面是否有数据，如果有数据取出第一个数据后拷贝到用户空间，并没有明显看到与其他驱动的直接交互。

在这里插入图片描述
在这里插入图片描述

write

看一下write()函数，这里一开始的handle取值于file->private_data的过程就表明了在write()之前必须要对file->private_data赋值的过程，由于open()的过程是置空，那么必然是在其他接口进行了赋值。再看下面，申请空间拷贝了用户空间数据后，调用了hios_mcc_sendto_user()函数进行发送，这里就可以看到与其他文件的接口直接交互了。

在这里插入图片描述
在这里插入图片描述

ioctl

上面read/write过程中都有对file->private_data的取值过程，实际的赋值过程是在ioctl()这个接口里，提供了5个命令，看代码的情况应该是先INIT，再CONNECT，再执行其他的命令。

  • HI_MCC_IOC_ATTR_INIT：属性初始化
  • HI_MCC_IOC_CONNECT：连接对端PCIe
  • HI_MCC_IOC_CHECK：检查对端PCIe
  • HI_MCC_IOC_GET_LOCAL_ID：获取本地ID
  • HI_MCC_IOC_GET_REMOTE_ID：获取对端ID

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

HI_MCC_IOC_ATTR_INIT

ioctl()的HI_MCC_IOC_ATTR_INIT调用hios_mcc_handle_attr_init()函数，这个属性初始化的过程就是一个简单的赋值过程，都赋值为一些非法的值。

在这里插入图片描述

HI_MCC_IOC_CONNECT

ioctl()的HI_MCC_IOC_CONNECT调用hios_mcc_open()函数，里面有一个关于是否处于中断处理过程的判断，如果是处于中断处理过程中，申请内存需要GFP_ATOMIC原子申请，否则可能会休眠导致系统异常；hios_mcc_open()函数将用户态传入的attr的target_id，port，priority参数传入pci_vdd_open()函数，进行下一层处理。

在这里插入图片描述

再看一下pci_vdd_open()函数，一开始就对这个target_id进行入参判断，但ioctl()的INIT过程对这些参数赋值都是一个非法值，那么这个条件肯定不满足，那么就是应用层INIT之后会先对这个入参进行赋值，再调用CONNECT？？？（可能是先使用GET_REMOTE_ID之后再使用open就可以了？？?）。

在这里插入图片描述

在这里插入图片描述

HI_MCC_IOC_CHECK

ioctl()的HI_MCC_IOC_CHECK调用hios_mcc_check_remote()函数：

在这里插入图片描述

调用的pci_vdd_check_remote()函数如下所示，获取到设备结构体后，根据当前是否是RC端来进行检查。

在这里插入图片描述

HOST端执行host_check_slv()进行检查，执行两步握手，设置共享内存为768K，并初始化共享内存。

在这里插入图片描述

握手
第零步握手

HOST 端：

使能本地读写DMA，映射对端寄存器到BAR空间。
在这里插入图片描述
在这里插入图片描述

SLAVE端：循环读取RC端写入的值，读到后检查握手位，共享内存在从片时，将共享内存地址写入寄存，置位握手位。

在这里插入图片描述

在这里插入图片描述

第一步握手

HOST端：等待从端写握手位，并读出共享内存的地址。

在这里插入图片描述

SLAVE端：直接返回。

在这里插入图片描述

共享内存初始化

将768K共享内存分成两半，一般用作发送消息，一半用来接收消息。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

HI_MCC_IOC_GET_LOCAL_ID

ioctl()的HI_MCC_IOC_GET_LOCAL_ID调用hios_mcc_getlocalid()函数：

在这里插入图片描述

调用的pci_vdd_remoteids()函数根据当前是否是HOST端（RC），返回0，如果当前是EP端，则读芯片寄存器返回总线号。

在这里插入图片描述

HI_MCC_IOC_GET_REMOTE_ID

ioctl()的HI_MCC_IOC_GET_REMOTE_ID调用hios_mcc_getremoteids()函数：

在这里插入图片描述

调用的pci_vdd_remoteids()函数根据当前是否是HOST端（RC），返回SLAVE端（EP）的总线号，如果当前是EP端，则返回ID为0，表明对端是RC。
在这里插入图片描述

一位不愿意透漏姓氏的底层搬砖人员
关注
  • 2
    点赞
  • 踩
  • 10
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
PCIE_MCC驱动阅读过程--SLAVE篇
weixin_38878510的博客
11-21 978
PCIE_MCC驱动阅读过程–SLAVE篇 文章目录PCIE_MCC驱动阅读过程--SLAVE篇hi35xx_dev_slv.koinitirq_map_slv.kopcit_dma_slv.komcc_drv_slv.komcc_usrdev_slv.ko补充握手过程Step 0 准备过程Step 1 握手过程 阅读讨论pcie_mcc代码的过程就是不断地推翻之前草率不深刻的结论，多讨论还是会有收获。 从端驱动加载顺序： insmod hi35xx_dev_slv.ko; insmod irq_map
PCIE_Install_rtl8111-3exp网卡(亲测能用 xp)
05-06
标题中的“PCIE_Install_rtl8111-3exp网卡(亲测能用 xp)”指的是在个人计算机扩展接口（PCI Express，简称PCI-E）上安装Realtek rtl8111-3EXP网络适配器驱动程序，并且这个过程已经在Windows XP操作系统下进行了测试...
hi3536 pcie驱动学习笔记
heliangbin87的专栏
05-23 7824
pcie 内核和驱动
浅谈PCIe体系结构(PCI桥与PCI设备的配置空间)
07-31
PCI设备都有独立的配置空间，HOST主桥通过配置读写总线事务访问这段空间。PCI总线规定了三种类型的PCI配置空间，分别是PCI Agent设备使用的配置空间，PCI桥使用的配置空间和Cardbus桥片使用的配置空间。本节重点介绍PCI Agent和PCI桥使用的配置空间，而并不介绍Cardbus桥片使用的配置空间。
PCIE设备与HOST之间的地址转换
weixin_30814329的博客
09-20 913
最近刚好用到了通过PCIE的与PC端相连的ARM板子，看了看代码，里面的地址转换确实把我也弄得有些晕，一边和组里的人讨论一边去问大神，终于算是把这块给弄的明白了，在博客里稍微记录一下，防止之后又忘记。 PCIE是一种高速串行计算机扩展总线标准，旨在替代老版的PCI总线，现在大多数主板都配有多个PCIE插槽，外设可以通过PCIE总线与主机HOST进行IO。 PCIE设备通过桥接到PCIE总...
[PCIe]PCIe设备在一个系统中是如何发现与访问的
Lenz_s_law的开发记录本
04-20 3131
首先我们来看一下在x86系统中，PCIe是什么样的一个体系架构。下图是一个PCIe的拓扑结构示例,PCIe协议支持256个Bus, 每条Bus最多支持32个Device，每个Device最多支持8个Function，所以由BDF（Bus，device，function）构成了每个PCIe设备节点的身份证号。 PCIe体系架构一般由root complex，switch，endpoint等类型...
PCIE-high-speed-data-acqusistion.rar_PCIE上位机_PCIE采集_high_pcie 驱动
07-14
pcie 高速数据采集系统驱动开发以及上位机程序开发
linux_driver.rar_linux pcie 驱动_linux驱动pcie_pcie driver_pcie linu
07-14
以下将详细介绍Linux下的PCIe驱动开发以及Xilinx PCIe驱动的相关知识点。 1. Linux PCIe架构：Linux内核提供了对PCIe设备的支持，它遵循PCI总线规范。PCIe设备通过PCIe总线与CPU进行数据传输，内核的PCI子系统负责...
PCIe_SFF-8639_R3.0_V1.0.pdf
07-26
PCI Express SFF-8639 Module Specification; Revision 3.0, Version 1.0; July 12, 2018
Altera FPGA pcie MSI中断驱动
07-18
Altera FPGA pcie MSI中断驱动 ，也可用于其它带pcie接口的FPGA中断功能开发。
Xilinx-FPGA-PCIE-Linux驱动程序.rar_FPGA Linux 驱动_PCIe FPGA_pcie_pci
07-14
标题中的“Xilinx-FPGA-PCIE-Linux驱动程序”是指针对Xilinx FPGA在Linux操作系统下与PCI Express（PCIe）接口交互的驱动程序。这一主题涵盖了FPGA设计、PCIe协议、Linux内核驱动开发等多个关键知识点。 1. **FPGA*...
NVMe开发——PCIe基础
最新发布
飞鹤的程序员人生
03-01 1326
PCI(Peripheral Component Interconnect)，外设组件互连。PCI是一种并口总线标准，对比其之前的其他总线，PCI因其速度快、支持即插即用，中断共享等特性，占领计算机总线标准近20年。随着CPU以及外设的速度要求越来越高，PCI总线愈发显得有心无力。PCI因为是并口，在高速信号传输中，因为信号质量问题，以及信号同步问题，并口解决这些问题的成本高，难以为继。在这个时候，PCI的替代者PCIe出现了。
PCIE_MCC驱动阅读过程–HOST篇
cpj123cpj的博客
11-24 499
PCIE_MCC驱动阅读过程--HOST篇hi35xx_dev_host.koinitprobe irq_map_host.koboot_device.koinitopen/release/read/write/pollioctlHI_GET_ALL_DEVICESHI_PCIE_TRANSFER_DATAinit_ddrmove_pf_window_in transfer_data HI_START_TARGET_DEVICEHI_RESET_TARGET_DEVICE .
PCIE总线理解笔记
qq_42254853的博客
10-24 2万+
基本介绍 PCI的EP和RC分别对应从模式和主模式，普通的PCI RC主模式可以用于连接PCI-E以太网芯片或PCI-E的硬盘等外设。RC模式使用外设一般都有LINUX 驱动程序，安装好驱动基本都能正常使用。但是对于SOC芯片本身能做EP有能做RC 两者如何互相通信可能就需要对PCIE的使用和基本原理有所了解才能较好的使用。 先了解几个定义： TLP TLP（Transaction Layer Packet）据包的描述被定义为事务层数据包 (TLP)，它与 ​​PCIe 的最上层有关。数据链路层负责
PCIe扫盲——基地址寄存器（BAR）详解
热门推荐
kunkliu的博客
07-01 2万+
转载地址：http://blog.chinaaet.com/justlxy/p/5100053320 基地址寄存器（BAR）在配置空间（Configuration Space）中的位置如下图所示： 其中Type0 Header最多有6个BAR，而Type1 Header最多有两个BAR。这就意味着，对于Endpoint来说，最多可以拥有6个不同的地址空间。但是实际应用中基本上不会用到6个，...
RK3399_PCIe_Host驱动分析_地址映射
jia_weihui的博客
02-06 2480
在这样一个速食的时代，坚持做自己，慢下来，潜心琢磨，心怀敬畏，领悟知识，才能向下扎到根，向上捅破天，背着世界往前行！所谓建立CPU和PCI地址空间的映射，就是设置Region对应的寄存器，都是使用函数。即：只写读写0xF8000000这段空间，就可以只写读写PCIe设备的配置空间。其中Region 0大小为32MB，Region1~31大小分别为1MB。，就是PCIe控制器，它的驱动做什么？
RK3399_PCIe_Host驱动分析_设备枚举
jia_weihui的博客
02-07 1391
resource结构体如下，要注意的是：里面记录的start、end等，是基于CPU角度看待的。也就是说，如果记录的是内存地址、IO地址，那么是CPU地址，不是PCI地址。每个PCI/PCIe设备都有配置空间，就是一系列的寄存器，对于普通的设备，它的配置空间格式如下。Class Code：这是只读的寄存器，它含有3个字节，用来表明设备的功能，它分为3部分。对应pci_dev结构体里的设备信息：读取PCI设备的配置空间即可获得。把这块空间对应的PCI地址写入PCIe设备的BAR。
kallsyms 内核符号表
weixin_38878510的博客
01-27 4529
kallsyms 内核符号表 文章目录kallsyms 内核符号表生成`kallsyms`脚本执行过程两次`kallsyms``vmlinux_link`过程三次`ld`程序运行过程读标准输入中的符号信息对`percpu`段内容进行修正寻找相对符号的基地址符号排序优化符号表生成token表字符串学习过程 -- 统计两个字符组合出现的频率生成best表 -- 统计单个字符是否有出现优化符号表算法压缩字符串写入符号表写入相对于基地址的数据写入符号表个数以及快速查找标记写入字符串查找表内核的`kallsyms`根
error: include/uapi/linux/rk-pcie-ep.h: leak CONFIG_PCIE_DW_DMATEST to user-space
06-01
这个错误提示可能是由于驱动程序中的某些宏定义泄漏到了用户空间。具体来说，这个错误可能是由于驱动程序中使用了 CONFIG_PCIE_DW_DMATEST 宏定义，但是这个宏定义没有被正确的限定在内核空间中，导致它泄漏到了用户空间。要解决这个问题，您可以尝试修改驱动程序中的宏定义，或者检查是否有其他的宏定义存在泄漏问题。另外，您也可以尝试查看内核日志，以获取更多关于这个错误的详细信息。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值