• usbip:(二)从linux内核了解usb


    一、前言

      1、首先了解一下EHCI、UHCI和OHCI。

      从硬件上来说,usb 设备要想工作,除了外设本身,必须依赖于 usb host controller.一般来说,一个电脑里有一个 usb host controller就可以了,她就可以控制很多个设备了,比如 u 盘,比如 usb 键盘,比如 usb 鼠标.所 有  的外设都把自己的请求提交给usb host controller.然后让 usb host controller 统一来调度.
      现在一般的USB桥接器模块有两种类型,UHCI和OHCI。在决定插入那一个桥接器模块时,可以察看/proc/pci文件来决定。一般而言,UHCI类型的桥接器它的插入模块是uhci或usb-uhci(由内核版本决定);而对于OHCI类型的桥接器它的插入模块是ohci或usb-ohci。


      uhci(universal host controller interface): Intel用在自家芯片组上的usb 1.1主控制器(host controller)的硬件实例
      ehci(enhanced host controller interface): usb 2.0的主控制器标准接口。
      ohci(open host controller inferface):一个不仅仅是usb用的主控制器接口标准。主要是遵循csr (configuration space register)标准。是其他厂商在设计usb host controller时遵循的标准,如via, nec, ali, 包括nvidia等等。
      ehci是满足usb 2.0 specification里面对usb host controller (high speed)的要求的硬件设计。

      就是主机控制器的接口。从硬件上来说,USB 设备要想工作,除了外设本身,必须还有一个 USB 主机控制器。一般来说,一个电脑里有一个 USB 主机控制器就可以了,它就可以控制很多个设备了,比如 U 盘,USB 键盘,USB 鼠标。所有的外设都把自己的请求提交给 USB主机控制器。然后让 USB 主机控制器统一来调度。而设备怎么连到主机控制器上?哎,这就是我们故事的主角,Hub,“乳名”叫做集线器。

      2、准备工作

      linux内核源码下载,可以根据自己喜好选择对应的版本。

      wget https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.4.145.tar.gz

      以usb_hub,来了解usb工作

      localhost:/usr/src/linux-2.6.22.1/drivers/usb/core # wc -l hub.c

    二、API

      1、Root_Hub

       

      USB 设备的初始化都是 Hub 这边发起的,通常我们写 USB 设备驱动程序都是在已经得到了一个 struct usb_interface 指针的情况下开始 probe 工作。可是我要问你,你的 struct usb_interface 从哪来的?老实说,要想知道从 USB 设备插入 USB 口的那一刻开始,这个世界发生了什么,你必须知道 Hub 是怎么工作的,Linux 中 Hub 驱动程序是怎么工作的。要说 USB Hub,那得从 Root Hub 说起。什么是 Root Hub?冤有头债有主,不管你的电脑里连了多少个 USB 设备,它们最终是有根的。所有的 USB 设备最终都是连接到了一个叫做 Root Hub 的设备上,或者说所有的根源都是从这里开始的。  

      Root Hub 上可以连接别的设备,可以连接 U 盘,可以连接 USB 鼠标,同样也可以连接另一个 Hub。所谓 Hub,就是用来级连。但是普通的 Hub,它一头接上级 Hub,另一头可以有多个口,多个口就可以级连多个设备,也可以只有一个口,一个口的就像大学宿舍里常用的那种延长线。而 Root Hub 呢?它比较特殊,它当然也是一种 USB 设备,但是它属于一人之下万人之上的角色,她只属于主机控制器,换言之,通常做芯片的人会把主机控制器和 Root Hub 集成在一起。特别是 PC 主机上,通常你就只能看到接口,看不到 Root Hub,因为她在主机控制器里。

      2、usb_init

      综上所述,整个USB子系统在初始化的时候,会先执行初始化Root Hub。

      来自drivers/usb/core/usb.c:

     982 static int __init usb_init(void)
     983 {
                ......
    1007     if (retval)
    1008         goto usb_devio_init_failed;
    1009     retval = usb_hub_init();
                ......
    1032 }

      在众多名叫*init*的函数之中,是有一个属于 Hub 的,它在这里初始化,换言之,随着 USB Core 的初
    始化,Hub 也就开始了它的初始化之路,usb_hub_init()函数得到调用。

      来自drivers/usb/core/hub.c:

    5600 int usb_hub_init(void)
    5601 {   
    5602     if (usb_register(&hub_driver) < 0) {
    5603         printk(KERN_ERR "%s: can't register hub driver\n",
    5604             usbcore_name);
    5605         return -1;
    5606     }
    5607     
    5608     /*
    5609      * The workqueue needs to be freezable to avoid interfering with
    5610      * USB-PERSIST port handover. Otherwise it might see that a full-speed
    5611      * device was gone before the EHCI controller had handed its port
    5612      * over to the companion full-speed controller.
    5613      */
    5614     hub_wq = alloc_workqueue("usb_hub_wq", WQ_FREEZABLE, 0);
    5615     if (hub_wq)
    5616         return 0;
    5617     
    5618     /* Fall through if kernel_thread failed */
    5619     usb_deregister(&hub_driver);
    5620     pr_err("%s: can't allocate workqueue for usb hub\n", usbcore_name);
    5621 
    5622     return -1;
    5623 }

      usb_register()这个函数是用来向 USB 核心层,即 USB Core,注册一个 USB 设备驱动的,而这里我们注册的是注册的是 Hub 的驱动程序所对应的 struct usb_driver 结构体变量。定义于 drivers/usb/core/hub.c 中。

    5586 static struct usb_driver hub_driver = {
    5587     .name =     "hub",
    5588     .probe =    hub_probe,
    5589     .disconnect =   hub_disconnect,
    5590     .suspend =  hub_suspend,
    5591     .resume =   hub_resume,
    5592     .reset_resume = hub_reset_resume,
    5593     .pre_reset =    hub_pre_reset,
    5594     .post_reset =   hub_post_reset,
    5595     .unlocked_ioctl = hub_ioctl,
    5596     .id_table = hub_id_table,
    5597     .supports_autosuspend = 1,
    5598 };

      这里面最重要的一个函数就是 hub_probe,很多事情都在这期间发生了。每个 USB 设备(或者说所有设备)的驱动都会有一个 probe 函数,比如 U 盘的 probe 函数就是 storage_probe(),不过 storage_probe()被调用需要两个前提,第一个 usb-storage 被加载了,第二个 U 盘等设备插入了被检测到了。而 Hub,说它特别,我可绝不是忽悠你。Hub 本身就有两种,一种是普通的 Hub,一种是 Root Hub。对于普通 Hub,它完全可能也是和 U 盘一样,在某个时刻被你插入,然后这种情况下 hub_probe 被调用,但是对于 Root Hub 就不需要这么多废话了,Root Hub 肯定是有的,只要你有 USB 主机控制器,就一定会有 Root Hub,所以 hub_probe()基本上是很自然地就被调用了,不用说非得等待某个插入事件的发生,没这个必要。当然没有 USB 主机控制器就没有 USB 设备能工作。那么 USB Core 这整个模块你就没有必要分析了。所以,只要你有 USB 主机控制器,那么在 USB 主机控制器的驱动程序初始化的过程中,它就会调用 hub_probe()来探测 RootHub,不管你的主机控制器是 OHCI、UHCI 还是 EHCI 的接口。如果 register 一切顺利的话,那么返回值为 0。如果返回值为负数,就说明出错了。现在假设这一步没有出错。

      Ok,usb_hub_init()的5614行,这行代码其实是很有技术含量的,不过对于写驱动的人来说,其作用就和当年的kernel_thread()相当。不过kernel_thread()返回值是一个int型的,而kthread_run()返回的却是structtask_struct 结构体指针。这里等号左边的 khubd_task 是我们自己定义的一个 struct task_struct 指针。

      56 /* workqueue to process hub events */
      57 static struct workqueue_struct *hub_wq;
      58 static void hub_event(struct work_struct *work);

      定义与 kernel/workqueue.c

     235 /*
     236  * The externally visible workqueue.  It relays the issued work items to
     237  * the appropriate worker_pool through its pool_workqueues.
     238  */
     239 struct workqueue_struct {
     240     struct list_head    pwqs;       /* WR: all pwqs of this wq */
     241     struct list_head    list;       /* PR: list of all workqueues */
     242 
     243     struct mutex        mutex;      /* protects this wq */
     244     int         work_color; /* WQ: current work color */
     245     int         flush_color;    /* WQ: current flush color */
     246     atomic_t        nr_pwqs_to_flush; /* flush in progress */
     247     struct wq_flusher   *first_flusher; /* WQ: first flusher */
     248     struct list_head    flusher_queue;  /* WQ: flush waiters */
     249     struct list_head    flusher_overflow; /* WQ: flush overflow list */
     250 
     251     struct list_head    maydays;    /* MD: pwqs requesting rescue */
     252     struct worker       *rescuer;   /* I: rescue worker */
     253 
     254     int         nr_drainers;    /* WQ: drain in progress */
     255     int         saved_max_active; /* WQ: saved pwq max_active */
     256 
     257     struct workqueue_attrs  *unbound_attrs; /* PW: only for unbound wqs */
     258     struct pool_workqueue   *dfl_pwq;   /* PW: only for unbound wqs */
     259 
     260 #ifdef CONFIG_SYSFS
     261     struct wq_device    *wq_dev;    /* I: for sysfs interface */
     262 #endif
     263 #ifdef CONFIG_LOCKDEP
     264     char            *lock_name;
     265     struct lock_class_key   key;
     266     struct lockdep_map  lockdep_map;
     267 #endif
     268     char            name[WQ_NAME_LEN]; /* I: workqueue name */
     269 
     270     /*
     271      * Destruction of workqueue_struct is RCU protected to allow walking
     272      * the workqueues list without grabbing wq_pool_mutex.
     273      * This is used to dump all workqueues from sysrq.
     274      */
     275     struct rcu_head     rcu;
     276 
     277     /* hot fields used during command issue, aligned to cacheline */
     278     unsigned int        flags ____cacheline_aligned; /* WQ: WQ_* flags */
     279     struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */
     280     struct pool_workqueue __rcu *numa_pwq_tbl[]; /* PWR: unbound pwqs indexed by node */
     281 };

      5615行,判断hub_wq,

      IS_ERR 是一个宏,用来判断指针的。当你创建了一个进程,你当然想知道这个进程创建成功了没有。以前我们注意到每次申请内存时都会做一次判断,你说创建进程是不是也要申请内存?不申请内存谁来记录 struct task_struct?很显然,要判断。以前我们判断的是指针是否为空。以后接触代码多了你会发现,其实 Linux 内核中有很多种内存申请的方式,而这些方式所返回的内存地址也是不一样的,所以并不是每一次我们都只要判断指针是否为空就可以了。事实上,每一次调用 kthread_run()之后,我们都会用一个IS_ERR()来判断指针是否有效。IS_ERR()为 1 就表示指针有错,或者准确一点说叫做指针无效。

      如果 IS_ERR()返回值是 0,那么说明没有问题,于是返回值为 0,也就是说 usb_hub_init()就这么结束了。反之,就会执行 usb_deregister()。

  • 相关阅读:
    谷歌json数据格式化插件
    引用图片出现403的解决办法
    CSS Sprite
    语义化标签
    响应式布局
    CSS浮动布局详解
    ELK华为云的镜像下载地址(ElasticSearch,logstash,kibana)
    redis集群方案--高可用集群
    redis集群方案--哨兵模式
    Redis集群实现分布式锁-RedLock
  • 原文地址:https://www.cnblogs.com/Ansing/p/16267641.html
Copyright © 2020-2023  润新知