linux-imx

/*

 * This module provides an interface to trigger and test firmware loading.

 *

 * It is designed to be used for basic evaluation of the firmware loading

 * subsystem (for example when validating firmware verification). It lacks

 * any extra dependencies, and will not normally be loaded by the system

 * unless explicitly requested by name.

 */

​

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

​

#include <linux/init.h>

#include <linux/module.h>

#include <linux/printk.h>

#include <linux/completion.h>

#include <linux/firmware.h>

#include <linux/device.h>

#include <linux/fs.h>

#include <linux/miscdevice.h>

#include <linux/slab.h>

#include <linux/uaccess.h>

#include <linux/delay.h>

#include <linux/kthread.h>

#include <linux/vmalloc.h>

​

#define TEST_FIRMWARE_NAME  "test-firmware.bin"

#define TEST_FIRMWARE_NUM_REQS  4

​

static DEFINE_MUTEX(test_fw_mutex);

static const struct firmware *test_firmware;

​

struct test_batched_req {

    u8 idx;

    int rc;

    bool sent;

    const struct firmware *fw;

    const char *name;

    struct completion completion;

    struct task_struct *task;

    struct device *dev;

};

​

/**

 * test_config - represents configuration for the test for different triggers

 *

 * @name: the name of the firmware file to look for

 * @sync_direct: when the sync trigger is used if this is true

 *  request_firmware_direct() will be used instead.

 * @send_uevent: whether or not to send a uevent for async requests

 * @num_requests: number of requests to try per test case. This is trigger

 *  specific.

 * @reqs: stores all requests information

 * @read_fw_idx: index of thread from which we want to read firmware results

 *  from through the read_fw trigger.

 * @test_result: a test may use this to collect the result from the call

 *  of the request_firmware*() calls used in their tests. In order of

 *  priority we always keep first any setup error. If no setup errors were

 *  found then we move on to the first error encountered while running the

 *  API. Note that for async calls this typically will be a successful

 *  result (0) unless of course you've used bogus parameters, or the system

 *  is out of memory.  In the async case the callback is expected to do a

 *  bit more homework to figure out what happened, unfortunately the only

 *  information passed today on error is the fact that no firmware was

 *  found so we can only assume -ENOENT on async calls if the firmware is

 *  NULL.

 *

 *  Errors you can expect:

 *

 *  API specific:

 *

 *  0:      success for sync, for async it means request was sent

 *  -EINVAL:    invalid parameters or request

 *  -ENOENT:    files not found

 *

 *  System environment:

 *

 *  -ENOMEM:    memory pressure on system

 *  -ENODEV:    out of number of devices to test

 *  -EINVAL:    an unexpected error has occurred

 * @req_firmware: if @sync_direct is true this is set to

 *  request_firmware_direct(), otherwise request_firmware()

 */

struct test_config {

    char *name;

    bool sync_direct;

    bool send_uevent;

    u8 num_requests;

    u8 read_fw_idx;

​

    /*

     * These below don't belong her but we'll move them once we create

     * a struct fw_test_device and stuff the misc_dev under there later.