All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Yi" <yi1.li@linux.intel.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>, gregkh@linuxfoundation.org
Cc: wagi@monom.org, dwmw2@infradead.org, rafal@milecki.pl,
	arend.vanspriel@broadcom.com, rjw@rjwysocki.net,
	atull@opensource.altera.com, moritz.fischer@ettus.com,
	pmladek@suse.com, johannes.berg@intel.com,
	emmanuel.grumbach@intel.com, luciano.coelho@intel.com,
	kvalo@codeaurora.org, luto@kernel.org,
	torvalds@linux-foundation.org, keescook@chromium.org,
	takahiro.akashi@linaro.org, dhowells@redhat.com,
	pjones@redhat.com, hdegoede@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 1/5] firmware: add extensible driver data params
Date: Thu, 11 May 2017 13:17:39 -0500	[thread overview]
Message-ID: <3232277e-e7de-68ca-c415-4477ba68c421@linux.intel.com> (raw)
In-Reply-To: <20170502084914.23588-2-mcgrof@kernel.org>



On 5/2/2017 3:49 AM, Luis R. Rodriguez wrote:
> As the firmware API evolves we keep extending functions with more arguments.
> Stop this nonsense by proving an extensible data structure which can be used
> to represent both user parameters and private internal parameters.
>
> We introduce 3 data structures:
>
>    o struct driver_data_req_params  - used for user specified parameters
>    o struct driver_data_priv_params - used for internal use only
>    o struct driver_data_params - stiches both of the the above together,
> 				only for internal use
>
> This starts off by just making the existing APIs use the new data
> structures, it will make subsequent changes easier to review which will
> be adding new flexible APIs.
>
> A side consequences is get to replace all the old internal "firmware
> behavior  options" flags with enums we properly document, remove the
> blinding #ifdefs, and compartamentlize the userhelper fallback code
> more appropriately unde CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
>
> This commit should introduces no functional changes (TM).
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
>   drivers/base/firmware_class.c | 331 ++++++++++++++++++++++++++++++++----------
>   include/linux/driver_data.h   |  82 +++++++++++
>   2 files changed, 339 insertions(+), 74 deletions(-)
>   create mode 100644 include/linux/driver_data.h
> ...
> diff --git a/include/linux/driver_data.h b/include/linux/driver_data.h
> new file mode 100644
> index 000000000000..7ce3216a9a99
> --- /dev/null
> +++ b/include/linux/driver_data.h
> @@ -0,0 +1,82 @@
> +#ifndef _LINUX_DRIVER_DATA_H
> +#define _LINUX_DRIVER_DATA_H
> +
> +#include <linux/types.h>
> +#include <linux/compiler.h>
> +#include <linux/gfp.h>
> +#include <linux/device.h>
> +
> +/*
> + * Driver Data internals
> + *
> + * Copyright (C) 2017 Luis R. Rodriguez <mcgrof@kernel.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of copyleft-next (version 0.3.1 or later) as published
> + * at http://copyleft-next.org/.
> + */
> +
> +/**
> + * struct driver_data_async_cbs - callbacks for handling driver data requests
> + * @found_cb: callback to be used when the driver data has been found. A
> + *	callback is required. If the requested driver data is found it will
> + *	passed on the callback, using the context set on @found_ctx.
> + * @found_ctx: preferred context to be used as the second argument to
> + * 	@found_cb.
> + *
> + * Used for specifying callbacks and contexts used for when asynchronous driver
> + * data requests have completed. If no driver data is found the error will be
> + * passed on the respective callback.
> + */
> +struct driver_data_async_cbs {
> +	void (*found_cb)(const struct firmware *driver_data,
> +			 void *context,
> +			 int error);

Any reason why the call back function format are not consistent between 
async and sync mode.  In sync mode, the context is before struct 
firmware. in Async mode, it's reversed.

struct driver_data_sync_cbs {
     int __must_check
         (*found_cb)(void *context,
                 const struct firmware *driver_data,
                 int error);

Yi
> +	void *found_ctx;
> +};
> +
> +/**
> + * union driver_data_cbs - callbacks for driver data request
> + * @async: callbacks for handling driver data when asynchronous requests
> + * 	are made.
> + *
> + * Used for placement of callbacks used for handling results from driver
> + * data requests.
> + */
> +union driver_data_cbs {
> +	struct driver_data_async_cbs async;
> +};
> +
> +/**
> + * enum driver_data_reqs - requirements of the driver data request
> + * @DRIVER_DATA_REQ_OPTIONAL: if set it is not a hard requirement by the
> + *	caller that the file requested be present. An error will not be recorded
> + *	if the file is not found.
> + */
> +enum driver_data_reqs {
> +	DRIVER_DATA_REQ_OPTIONAL			= 1 << 0,
> +};
> +
> +/**
> + * struct driver_data_req_params - driver data request parameters
> + * @hold_module: module to hold during the driver data request operation. By
> + * 	default if sync requests set this to NULL the firmware_class module
> + * 	will be refcounted during operation.
> + * @gfp: flags to use for allocations when constructing the driver data request,
> + *	prior to scheduling. Unused on driver_data_request_sync().
> + * @reqs: set of &enum driver_data_reqs flags used to configure the driver
> + * 	data request. All of the specified requirements must be met.
> + * @cbs: set of callbacks to use for the driver data request.
> + *
> + * This data structure is intended to carry all requirements and specifications
> + * required to complete the task to get the requested driver date file to the
> + * caller.
> + */
> +struct driver_data_req_params {
> +	struct module *hold_module;
> +	gfp_t gfp;
> +	u64 reqs;
> +	const union driver_data_cbs cbs;
> +};
> +
> +#endif /* _LINUX_DRIVER_DATA_H */

  reply	other threads:[~2017-05-11 18:17 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30  3:25 [PATCH v6 0/5] firmware: add driver data API Luis R. Rodriguez
2017-03-30  3:25 ` [PATCH v6 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-04-06  7:26   ` Luca Coelho
2017-04-27  2:05     ` Luis R. Rodriguez
2017-03-30  3:25 ` [PATCH v6 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-04-10 12:42   ` Coelho, Luciano
2017-04-11  8:01     ` takahiro.akashi
2017-04-27  3:23       ` Luis R. Rodriguez
2017-04-27  3:16     ` Luis R. Rodriguez
2017-04-27  5:44       ` Luca Coelho
2017-04-27  8:04         ` Luis R. Rodriguez
2017-04-27  6:09       ` Luca Coelho
2017-04-27 10:31         ` Luis R. Rodriguez
2017-04-13  9:36   ` AKASHI Takahiro
2017-04-28  0:51     ` Luis R. Rodriguez
2017-04-28  3:19       ` AKASHI Takahiro
2017-04-29  4:36         ` Luis R. Rodriguez
2017-03-30  3:25 ` [PATCH v6 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-04-11  8:32   ` AKASHI Takahiro
2017-04-28  1:45     ` Luis R. Rodriguez
2017-05-11 10:46       ` AKASHI Takahiro
2017-05-11 17:11         ` Luis R. Rodriguez
2017-05-17 22:45           ` Li, Yi
2017-05-19 18:31             ` Luis R. Rodriguez
2017-05-11 18:12         ` Luis R. Rodriguez
2017-05-11 18:26         ` Luis R. Rodriguez
2017-05-11 18:32           ` Luis R. Rodriguez
2017-05-12  0:28             ` AKASHI Takahiro
2017-05-12 15:59               ` Luis R. Rodriguez
2017-05-17  9:08                 ` AKASHI Takahiro
2017-05-17 15:38                   ` Luis R. Rodriguez
2017-05-12  0:20           ` AKASHI Takahiro
2017-05-12 15:52             ` Luis R. Rodriguez
2017-05-13 18:46               ` Luis R. Rodriguez
2017-03-30  3:25 ` [PATCH v6 4/5] iwlwifi: convert to use driver data API Luis R. Rodriguez
2017-04-10 13:19   ` Luca Coelho
2017-04-28  0:56     ` Luis R. Rodriguez
2017-04-28 12:17       ` Luca Coelho
2017-03-30  3:25 ` [PATCH v6 5/5] brcmfmac: don't warn user if requested nvram fails Luis R. Rodriguez
2017-04-27  0:49   ` Luis R. Rodriguez
2017-05-02  8:49 ` [PATCH v7 0/5] firmware: add driver data API Luis R. Rodriguez
2017-05-02  8:49   ` [PATCH v7 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-05-11 18:17     ` Li, Yi [this message]
2017-05-11 18:28       ` Luis R. Rodriguez
2017-05-02  8:49   ` [PATCH v7 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-05-02  8:49   ` [PATCH v7 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-05-11 10:10     ` AKASHI Takahiro
2017-05-11 17:00       ` Luis R. Rodriguez
2017-05-15 18:23     ` [PATCH v8] " Luis R. Rodriguez
2017-05-02  8:49   ` [PATCH v7 4/5] firmware: document the extensible driver data API Luis R. Rodriguez
2017-05-02  8:49   ` [PATCH v7 5/5] iwlwifi: convert to use " Luis R. Rodriguez
2017-05-19 19:10   ` [PATCH v8 0/5] firmware: add " Luis R. Rodriguez
2017-05-19 19:10     ` [PATCH v8 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-05-19 19:10     ` [PATCH v8 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-05-19 19:10     ` [PATCH v8 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-05-19 19:10     ` [PATCH v8 4/5] firmware: document the extensible driver data API Luis R. Rodriguez
2017-05-19 19:10     ` [PATCH v8 5/5] iwlwifi: convert to use " Luis R. Rodriguez
2017-06-05 21:33     ` [PATCH v8 0/5] firmware: add " Luis R. Rodriguez
2017-06-05 21:39       ` [PATCH v9 " Luis R. Rodriguez
2017-06-05 21:39         ` [PATCH v9 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-06-13  9:05           ` Greg KH
2017-06-13 10:31             ` Rafał Miłecki
2017-06-13 13:17               ` Greg KH
2017-06-13 14:12                 ` Rafał Miłecki
2017-06-13 15:32                 ` Luis R. Rodriguez
2017-06-13 15:50                   ` Greg KH
2017-06-13 19:40             ` Luis R. Rodriguez
2017-06-14 15:57               ` Li, Yi
2017-06-17 19:38               ` Greg KH
2017-06-19  7:33                 ` Johannes Berg
2017-06-19 19:41                   ` Luis R. Rodriguez
2017-06-20  1:26                     ` AKASHI Takahiro
2017-06-19 19:35                 ` Luis R. Rodriguez
2017-06-23 15:51                   ` Greg KH
2017-06-23 22:43                     ` Luis R. Rodriguez
2017-06-23 23:09                       ` Linus Torvalds
2017-06-24  0:48                         ` Luis R. Rodriguez
2017-06-24 12:39                           ` Greg KH
2017-06-26 17:33                             ` Luis R. Rodriguez
2017-06-26 18:19                               ` Rafał Miłecki
2017-06-26 21:29                                 ` Luis R. Rodriguez
2017-06-27  2:28                               ` Vikram Mulukutla
2017-06-27 17:25                                 ` Luis R. Rodriguez
2017-06-24 12:40                       ` Greg KH
2017-06-26 15:50                         ` Luis R. Rodriguez
2017-06-23 15:59                   ` Greg KH
2017-06-23 22:47                     ` Luis R. Rodriguez
2017-06-19 22:51                 ` Li, Yi
2017-06-20  1:48                   ` AKASHI Takahiro
2017-06-20 15:20                     ` Li, Yi
2017-06-20 16:27                 ` Vikram Mulukutla
2017-06-20 17:22                   ` Luis R. Rodriguez
2017-06-21  0:49                     ` AKASHI Takahiro
2017-06-23 16:33                       ` Luis R. Rodriguez
2017-06-05 21:39         ` [PATCH v9 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-06-05 21:39         ` [PATCH v9 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-06-05 21:39         ` [PATCH v9 4/5] firmware: document the extensible driver data API Luis R. Rodriguez
2017-06-05 21:39         ` [PATCH v9 5/5] iwlwifi: convert to use " Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3232277e-e7de-68ca-c415-4477ba68c421@linux.intel.com \
    --to=yi1.li@linux.intel.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=atull@opensource.altera.com \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=emmanuel.grumbach@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=johannes.berg@intel.com \
    --cc=keescook@chromium.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luciano.coelho@intel.com \
    --cc=luto@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=moritz.fischer@ettus.com \
    --cc=pjones@redhat.com \
    --cc=pmladek@suse.com \
    --cc=rafal@milecki.pl \
    --cc=rjw@rjwysocki.net \
    --cc=takahiro.akashi@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=wagi@monom.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.