| Message ID | 1454756672-12790-2-git-send-email-zhang.chunyan@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Chunyan Zhang <zhang.chunyan@linaro.org> writes: > There is already an interface of set_options, but no get_options yet. > Before setting any options, one would may want to see the current > status of that option by means of get_options interface. This > interface has been used in CoreSight STM driver. I'm not sure I understand the reasoning behind this. If a userspace program opens a communication channel and wants to configure certain features on it, why does its choice depend on what has been configured for this channel previously? It can be anything at all. Most likely, it's either unconfigured or configured to its default values, but why does this matter for a new writer? Regards, -- Alex
On 12 February 2016 at 08:18, Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote: > Chunyan Zhang <zhang.chunyan@linaro.org> writes: > >> There is already an interface of set_options, but no get_options yet. >> Before setting any options, one would may want to see the current >> status of that option by means of get_options interface. This >> interface has been used in CoreSight STM driver. > > I'm not sure I understand the reasoning behind this. If a userspace > program opens a communication channel and wants to configure certain > features on it, why does its choice depend on what has been configured > for this channel previously? It can be anything at all. Most likely, > it's either unconfigured or configured to its default values, but why > does this matter for a new writer? A client may wish to change the settings (invariant/guaranteed) it has on a specific channel - it may even want to so do multiple times. The idea behind introducing a get_options() was to probe the specific settings of a channel before going a head with a new configuration. In hindsight it may not be needed as a client should simply go ahead and push down the configuration it wants. > > Regards, > -- > Alex
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c index b6445d9..854a16d 100644 --- a/drivers/hwtracing/stm/core.c +++ b/drivers/hwtracing/stm/core.c @@ -571,6 +571,18 @@ stm_char_ioctl(struct file *file, unsigned int cmd, unsigned long arg) options); break; + + case STP_GET_OPTIONS: + if (stm_data->get_options) + err = stm_data->get_options(stm_data, + stmf->output.master, + stmf->output.channel, + stmf->output.nr_chans, + &options); + + if (copy_to_user((void __user *)arg, &options, sizeof(u64))) + return -EFAULT; + default: break; } diff --git a/include/linux/stm.h b/include/linux/stm.h index 9d0083d..f351d62 100644 --- a/include/linux/stm.h +++ b/include/linux/stm.h @@ -88,6 +88,9 @@ struct stm_data { long (*set_options)(struct stm_data *, unsigned int, unsigned int, unsigned int, unsigned long); + long (*get_options)(struct stm_data *, unsigned int, + unsigned int, unsigned int, + u64 *); }; int stm_register_device(struct device *parent, struct stm_data *stm_data, diff --git a/include/uapi/linux/stm.h b/include/uapi/linux/stm.h index 626a8d3..0dab16e 100644 --- a/include/uapi/linux/stm.h +++ b/include/uapi/linux/stm.h @@ -46,5 +46,6 @@ struct stp_policy_id { #define STP_POLICY_ID_SET _IOWR('%', 0, struct stp_policy_id) #define STP_POLICY_ID_GET _IOR('%', 1, struct stp_policy_id) #define STP_SET_OPTIONS _IOW('%', 2, __u64) +#define STP_GET_OPTIONS _IOR('%', 3, __u64) #endif /* _UAPI_LINUX_STM_H */
There is already an interface of set_options, but no get_options yet. Before setting any options, one would may want to see the current status of that option by means of get_options interface. This interface has been used in CoreSight STM driver. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> --- drivers/hwtracing/stm/core.c | 12 ++++++++++++ include/linux/stm.h | 3 +++ include/uapi/linux/stm.h | 1 + 3 files changed, 16 insertions(+)