Greg Kroah-Hartman <gre...@linuxfoundation.org> writes:

>> +    /*
>> +     * ->assign() called when buffer 'mode' is set to this driver
>> +     *   (aka mode_store())
>> +     * @device:     struct device * of the msc
>> +     * @mode:       allows the driver to set HW mode (see the enum above)
>> +     * Returns:     a pointer to a private structure associated with this
>> +     *              msc or NULL in case of error. This private structure
>> +     *              will then be passed into all other callbacks.
>> +     */
>> +    void    *(*assign)(struct device *dev, int *mode);
>> +    /* ->unassign():        some other mode is selected, clean up */
>> +    void    (*unassign)(void *priv);
>> +    /*
>> +     * ->alloc_window(): allocate memory for the window of a given
>> +     *              size
>> +     * @sgt:        pointer to sg_table, can be overridden by the buffer
>> +     *              driver, or kept intact
>> +     * Returns:     number of sg table entries <= number of pages;
>> +     *              0 is treated as an allocation failure.
>> +     */
>> +    int     (*alloc_window)(void *priv, struct sg_table **sgt,
>> +                            size_t size);
>> +    void    (*free_window)(void *priv, struct sg_table *sgt);
>> +    /* ->activate():        trace has started */
>> +    void    (*activate)(void *priv);
>> +    /* ->deactivate():      trace is about to stop */
>> +    void    (*deactivate)(void *priv);
>> +    /*
>> +     * ->ready():   window @sgt is filled up to the last block OR
>> +     *              tracing is stopped by the user; this window contains
>> +     *              @bytes data. The window in question transitions into
>> +     *              the "LOCKED" state, indicating that it can't be used
>> +     *              by hardware. To clear this state and make the window
>> +     *              available to the hardware again, call
>> +     *              intel_th_msc_window_unlock().
>> +     */
>> +    int     (*ready)(void *priv, struct sg_table *sgt, size_t bytes);
>> +};
>
> Why isn't this based off of 'struct driver'?

It's not a real driver, in a sense that there's no underlying
device. None of the usual driver stuff applies. It's still a set of
callbacks, though. Should this be an elaborate comment, should I replace
the word "driver" with something else?

I'd really like to avoid shoehorning the whole 'struct device' + 'struct
driver' here.

Thanks,
--
Alex

Reply via email to