
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>

static int sample_platform_probe(struct platform_device *pdev)
{
    return 0;
}

static int sample_platform_remove(struct platform_device *pdev)
{
    return 0;
}

static struct platform_driver hogehoge_driver = {
    .probe  = hogehoge_probe,
    .remove = hogehoge_remove,
    .driver = {
        .name   = "hogehoge"
    },
};

module_platform_driver(hogehoge_driver);

このドライバに対して、下記のようにデバイスを追加します。platform_busの場合、デバイス名は "ドライバ名.ID番号" つまりhogehoge.0という名前になるようです。

platform_busにデバイスを追加する


#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>

static struct platform_device *pdev = NULL;

static int __init hogehoge_device_init(void)
{
    int ret;

    pdev = platform_device_alloc("hogehoge", 0);
    if (pdev == NULL) {
        //error
        return -ENOMEM;
    }

    ret = platform_device_add(pdev);
    if (ret != 0) {
        //error
        platform_device_put(pdev);
        return -ENOMEM;
    }

    return 0;
}

static void __exit hogehoge_device_exit(void)
{
    platform_device_del(pdev);
}

module_init(hogehoge_device_init);
module_exit(hogehoge_device_exit);

ドライバの登録とデバイスの追加はどちらが先でも構いません。

ドライバを登録してからデバイスを追加するか、その逆、デバイスを追加してからドライバを登録すれば、デバイスドライバのprobe() コールバック、つまりhogehoge_probe() が呼ばれます。

ぱっと見、デバイス追加が先で、ドライバ登録が後の場合をケアする必然性があるのか？疑問を感じるかもしれませんが、USBデバイスが既に筐体に接続されていて、USBドライバをカーネルモジュールでロードする場合を考えると、ごく普通の状況ですよね。

経路その1 - デバイス追加がトリガ

ドライバを登録してからデバイスを追加する場合と「思われる」経路の一例です。ちゃんと呼び出しの条件を追っていないので、条件が間違っているかもしれません。

- platform_device_add()
  - device_add()
    - bus_probe_device()
      - device_initial_probe()
        - __device_attach()
          - __device_attach_driver()
            - driver_probe_device()
              - really_probe()
                - drv->probe()

デバイス追加の際に呼ばれるdevice_add() が契機になるようです。platform_busの場合はplatform_device_add() が内部で呼んでいます。

経路その2 - ドライバ追加がトリガ

デバイスを追加してからドライバを登録する場合の経路と思われる一例です。ちゃんと呼び出しの条件を追っていないので、条件が間違っているかもしれません。

- __platform_driver_register()
  - driver_register()
    - bus_add_driver()
      - driver_attach()
        - __driver_attach()
          - driver_probe_device()
            - really_probe()
              - drv->probe()

ドライバ追加の際に呼ばれるdriver_register() が契機になるようです。先ほどの例だとmodule_platform_driver() マクロが勝手に呼んでくれます。

補足

他にもdevice_attach() 時に __device_attach_async_helper() なる関数をワークキューにぶっ込んで非同期でデバイスを検知する系、bind_store() で手動でデバイスを検知する系がありそうです。

他にもprobe() を呼び出す系はありそうですが、今のところ良くわかってません。あの手この手で動かしているんだなー、と思いました。

編集者:すずき(2023/04/29 21:38)

コメント一覧

コメントはありません。

この記事にコメントする

2016年2月13日

permalink

編集する

あえてCookieをブロックしてみる

SNSなどのWebサービスでは不可欠の存在となったCookieですが、Cookieをブロックしても正常にサービスを使えるんだろうか？と気になったので、やってみました。

ブラウザはSeaMonkeyです。メニューのEdit - Preferencesの画面から、左のツリービューをPrivacy & Security - Cookiesと辿り、Block cookiesオプションを選んでOKを押します。この設定によって、明示的に許可されたサイト以外はCookieをブロックします。

Cookieを全てブロックするとSNSなどのログインは一切出来なくなります。この状態から、どのドメインのCookieを受け入れればサービスが使えるようになるか？を見てみたいと思います。