Add support for sysfs interface for runtime features configuration.
The user can configure the features at runtime. First the user need
to select the config id of the supported features and then the user
can configure the parameters of the feature based on the config id.
So far the support is added for the over temperature and external
watchdog features.
Signed-off-by: Ronak Jain <[email protected]>
---
Changes in v2:
- Update commit message
---
drivers/firmware/xilinx/zynqmp.c | 71 ++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 875d13bc1a57..a1434dd368f2 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1361,6 +1361,75 @@ static DEVICE_ATTR_RW(pggs1);
static DEVICE_ATTR_RW(pggs2);
static DEVICE_ATTR_RW(pggs3);
+static atomic_t feature_conf_id;
+
+static ssize_t feature_config_id_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sysfs_emit(buf, "%d\n", atomic_read(&feature_conf_id));
+}
+
+static ssize_t feature_config_id_store(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 config_id;
+ int ret;
+
+ if (!buf)
+ return -EINVAL;
+
+ ret = kstrtou32(buf, 10, &config_id);
+ if (ret)
+ return ret;
+
+ atomic_set(&feature_conf_id, config_id);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(feature_config_id);
+
+static ssize_t feature_config_value_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int ret;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+
+ ret = zynqmp_pm_get_feature_config(atomic_read(&feature_conf_id),
+ ret_payload);
+ if (ret)
+ return ret;
+
+ return sysfs_emit(buf, "%d\n", ret_payload[1]);
+}
+
+static ssize_t feature_config_value_store(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 value;
+ int ret;
+
+ if (!buf)
+ return -EINVAL;
+
+ ret = kstrtou32(buf, 10, &value);
+ if (ret)
+ return ret;
+
+ ret = zynqmp_pm_set_feature_config(atomic_read(&feature_conf_id),
+ value);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(feature_config_value);
+
static struct attribute *zynqmp_firmware_attrs[] = {
&dev_attr_ggs0.attr,
&dev_attr_ggs1.attr,
@@ -1372,6 +1441,8 @@ static struct attribute *zynqmp_firmware_attrs[] = {
&dev_attr_pggs3.attr,
&dev_attr_shutdown_scope.attr,
&dev_attr_health_status.attr,
+ &dev_attr_feature_config_id.attr,
+ &dev_attr_feature_config_value.attr,
NULL,
};
--
2.32.0.93.g670b81a
On Mon, Sep 13, 2021 at 01:39:55AM -0700, Ronak Jain wrote:
> Add support for sysfs interface for runtime features configuration.
> The user can configure the features at runtime. First the user need
> to select the config id of the supported features and then the user
> can configure the parameters of the feature based on the config id.
> So far the support is added for the over temperature and external
> watchdog features.
>
> Signed-off-by: Ronak Jain <[email protected]>
> ---
> Changes in v2:
> - Update commit message
> ---
> drivers/firmware/xilinx/zynqmp.c | 71 ++++++++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index 875d13bc1a57..a1434dd368f2 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1361,6 +1361,75 @@ static DEVICE_ATTR_RW(pggs1);
> static DEVICE_ATTR_RW(pggs2);
> static DEVICE_ATTR_RW(pggs3);
>
> +static atomic_t feature_conf_id;
Why does this have to be an atomic?
And shouldn't this be per-device, not global to all devices in the
system?
> +
> +static ssize_t feature_config_id_show(struct device *device,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return sysfs_emit(buf, "%d\n", atomic_read(&feature_conf_id));
> +}
> +
> +static ssize_t feature_config_id_store(struct device *device,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + u32 config_id;
> + int ret;
> +
> + if (!buf)
> + return -EINVAL;
How can there ever be a NULL buffer?
No need to check for impossible things.
thanks,
greg k-h
Hi Greg KH,
Thanks for reviewing.
> -----Original Message-----
> From: Greg KH <[email protected]>
> Sent: Tuesday, September 14, 2021 2:51 PM
> To: Ronak Jain <[email protected]>
> Cc: Michal Simek <[email protected]>; [email protected]; Rajan
> Vaja <[email protected]>; [email protected]; linux-arm-
> [email protected]; [email protected]; Sai Krishna Potthuri
> <[email protected]>
> Subject: Re: [PATCH v2 3/3] firmware: xilinx: Add sysfs support for feature
> config
>
> On Mon, Sep 13, 2021 at 01:39:55AM -0700, Ronak Jain wrote:
> > Add support for sysfs interface for runtime features configuration.
> > The user can configure the features at runtime. First the user need
> > to select the config id of the supported features and then the user
> > can configure the parameters of the feature based on the config id.
> > So far the support is added for the over temperature and external
> > watchdog features.
> >
> > Signed-off-by: Ronak Jain <[email protected]>
> > ---
> > Changes in v2:
> > - Update commit message
> > ---
> > drivers/firmware/xilinx/zynqmp.c | 71
> > ++++++++++++++++++++++++++++++++
> > 1 file changed, 71 insertions(+)
> >
> > diff --git a/drivers/firmware/xilinx/zynqmp.c
> > b/drivers/firmware/xilinx/zynqmp.c
> > index 875d13bc1a57..a1434dd368f2 100644
> > --- a/drivers/firmware/xilinx/zynqmp.c
> > +++ b/drivers/firmware/xilinx/zynqmp.c
> > @@ -1361,6 +1361,75 @@ static DEVICE_ATTR_RW(pggs1); static
> > DEVICE_ATTR_RW(pggs2); static DEVICE_ATTR_RW(pggs3);
> >
> > +static atomic_t feature_conf_id;
>
> Why does this have to be an atomic?
Use atomic to avoid race conditions. Suppose the case where the user is trying to write the variable and at the same time it tries to read, so there might be chances of occurrence of race condition. Also, I am not so sure whether the race condition will occur or not but just to prevent race condition I have used atomic variable so, the read/write operations can handle automatically.
>
> And shouldn't this be per-device, not global to all devices in the system?
This is to store the config-id set by the user which will be used to retrieve config. There is only one firmware device so we can consider it systemwide. Please let me know if you think of a better way of handling it.
>
> > +
> > +static ssize_t feature_config_id_show(struct device *device,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + return sysfs_emit(buf, "%d\n", atomic_read(&feature_conf_id)); }
> > +
> > +static ssize_t feature_config_id_store(struct device *device,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count) {
> > + u32 config_id;
> > + int ret;
> > +
> > + if (!buf)
> > + return -EINVAL;
>
> How can there ever be a NULL buffer?
>
> No need to check for impossible things.
Will update in next version.
Thanks,
Ronak
>
> thanks,
>
> greg k-h
On Wed, Sep 15, 2021 at 06:16:16AM +0000, Ronak Jain wrote:
> Hi Greg KH,
>
> Thanks for reviewing.
>
> > -----Original Message-----
> > From: Greg KH <[email protected]>
> > Sent: Tuesday, September 14, 2021 2:51 PM
> > To: Ronak Jain <[email protected]>
> > Cc: Michal Simek <[email protected]>; [email protected]; Rajan
> > Vaja <[email protected]>; [email protected]; linux-arm-
> > [email protected]; [email protected]; Sai Krishna Potthuri
> > <[email protected]>
> > Subject: Re: [PATCH v2 3/3] firmware: xilinx: Add sysfs support for feature
> > config
> >
> > On Mon, Sep 13, 2021 at 01:39:55AM -0700, Ronak Jain wrote:
> > > Add support for sysfs interface for runtime features configuration.
> > > The user can configure the features at runtime. First the user need
> > > to select the config id of the supported features and then the user
> > > can configure the parameters of the feature based on the config id.
> > > So far the support is added for the over temperature and external
> > > watchdog features.
> > >
> > > Signed-off-by: Ronak Jain <[email protected]>
> > > ---
> > > Changes in v2:
> > > - Update commit message
> > > ---
> > > drivers/firmware/xilinx/zynqmp.c | 71
> > > ++++++++++++++++++++++++++++++++
> > > 1 file changed, 71 insertions(+)
> > >
> > > diff --git a/drivers/firmware/xilinx/zynqmp.c
> > > b/drivers/firmware/xilinx/zynqmp.c
> > > index 875d13bc1a57..a1434dd368f2 100644
> > > --- a/drivers/firmware/xilinx/zynqmp.c
> > > +++ b/drivers/firmware/xilinx/zynqmp.c
> > > @@ -1361,6 +1361,75 @@ static DEVICE_ATTR_RW(pggs1); static
> > > DEVICE_ATTR_RW(pggs2); static DEVICE_ATTR_RW(pggs3);
> > >
> > > +static atomic_t feature_conf_id;
> >
> > Why does this have to be an atomic?
> Use atomic to avoid race conditions. Suppose the case where the user
> is trying to write the variable and at the same time it tries to read,
> so there might be chances of occurrence of race condition. Also, I am
> not so sure whether the race condition will occur or not but just to
> prevent race condition I have used atomic variable so, the read/write
> operations can handle automatically.
Reading/writing a single variable like this will not be a problem with
races. If you care about stuff like this, just use a lock to protect
it, don't try to mess with an atomic if you do not have to have it.
> > And shouldn't this be per-device, not global to all devices in the system?
> This is to store the config-id set by the user which will be used to
> retrieve config. There is only one firmware device so we can consider
> it systemwide. Please let me know if you think of a better way of
> handling it.
So is it a device attribute or a driver attribute?
And you never know how many devices you have in a system, do not assume
you will not have multiple ones. Use the proper structures to start
with and you never will have to change things in the future if you have
multiple devices.
thanks,
greg k-h