On Tue, Sep 23, 2025 at 07:53:02AM +0000, Tzung-Bi Shih wrote:
@@ -166,7 +166,6 @@ static int cros_ec_chardev_open(struct inode *inode, struct file *filp) if (!priv) return -ENOMEM;
- priv->ec_dev = ec_dev; priv->cmd_offset = ec->cmd_offset; filp->private_data = priv; INIT_LIST_HEAD(&priv->events);
@@ -370,6 +369,18 @@ static const struct file_operations chardev_fops = { #endif }; +static int cros_ec_chardev_rev_try_access(struct revocable *rev, void *data) +{
- struct chardev_priv *priv = data;
- priv->ec_dev = revocable_try_access(rev);
- return priv->ec_dev ? 0 : -ENODEV;
+}
+static const struct revocable_operations cros_ec_chardev_rops = {
- .try_access = cros_ec_chardev_rev_try_access,
+};
static int cros_ec_chardev_probe(struct platform_device *pdev) { struct cros_ec_dev *ec = dev_get_drvdata(pdev->dev.parent); @@ -385,6 +396,8 @@ static int cros_ec_chardev_probe(struct platform_device *pdev) misc->fops = &chardev_fops; misc->name = ec_platform->ec_name; misc->parent = pdev->dev.parent;
- misc->rp = ec->ec_dev->revocable_provider;
- misc->rops = &cros_ec_chardev_rops;
dev_set_drvdata(&pdev->dev, misc);
If we prefer to avoid modifying the device driver, the driver must at least register its resource providers with the subsystem.
This would allow the subsystem to guarantee resource validity by calling revocable_try_access() before dispatching any file operations.
The device driver could then access its resources directly (e.g., priv->ec_dev) within its fops, as their validity would have already been checked by the subsystem.