From: Jonathan Cameron <jic23@kernel.org>
To: Ye Xiang <xiang.ye@intel.com>
Cc: jikos@kernel.org, srinivas.pandruvada@linux.intel.com,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure
Date: Sat, 21 Nov 2020 17:33:30 +0000 [thread overview]
Message-ID: <20201121173330.3afd1087@archlinux> (raw)
In-Reply-To: <20201119100331.2594-4-xiang.ye@intel.com>
On Thu, 19 Nov 2020 18:03:30 +0800
Ye Xiang <xiang.ye@intel.com> wrote:
> Use iio->trig instead of attrb->trig as parameter of iio_trigger_unregister
> and iio_trigger_free. This allows one HID sensor driver to create
> multiple iio devices. In this case common attributes are shared and
> there can be one instance for the structure containing common attributes
> for all iio devices.
>
> Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Whilst indio_dev->trig is set to the local trigger at startup,
I'm not seeing the validate callbacks that will be needed to ensure it
is still set to that trigger when you remove the driver.
Specifically validate_trigger callback for all the hid sensor devices.
It is entirely possible that should be set and these devices can only
use the hid sensor trigger, but I don't think it currently is.
Thus this patch is going to cause some interesting crashes.
Note this is the reason all IIO drivers have to carry an extra copy
of the trig pointer.
So you'll have to do something a bit more interesting to pass that
trigger to the relevant devices that share it.
Arguably if they are actually sharing the trigger, then we shouldn't really
have separate IIO devices in the first place as we loose the
connection between the timing of the data across the different channels.
Jonathan
> ---
> drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index 30340abcbc8d..bb5e7c8ff15b 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -236,8 +236,8 @@ void hid_sensor_remove_trigger(struct iio_dev *indio_dev,
> pm_runtime_put_noidle(&attrb->pdev->dev);
>
> cancel_work_sync(&attrb->work);
> - iio_trigger_unregister(attrb->trigger);
> - iio_trigger_free(attrb->trigger);
> + iio_trigger_unregister(indio_dev->trig);
> + iio_trigger_free(indio_dev->trig);
> iio_triggered_buffer_cleanup(indio_dev);
> }
> EXPORT_SYMBOL(hid_sensor_remove_trigger);
next prev parent reply other threads:[~2020-11-21 17:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 10:03 [PATCH v2 0/4] add custom hinge sensor support Ye Xiang
2020-11-19 10:03 ` [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support Ye Xiang
2020-11-21 17:21 ` Jonathan Cameron
2020-11-24 10:29 ` Ye, Xiang
2020-11-24 11:32 ` Jonathan Cameron
2020-11-25 2:27 ` Ye, Xiang
2020-11-28 13:29 ` Jonathan Cameron
2020-11-19 10:03 ` [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal Ye Xiang
2020-11-21 17:22 ` Jonathan Cameron
2020-11-22 1:54 ` Pandruvada, Srinivas
2020-11-19 10:03 ` [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure Ye Xiang
2020-11-21 17:33 ` Jonathan Cameron [this message]
2020-11-19 10:03 ` [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver Ye Xiang
2020-11-21 17:56 ` Jonathan Cameron
2020-11-22 1:46 ` Pandruvada, Srinivas
2020-11-22 2:14 ` Pandruvada, Srinivas
2020-11-22 14:14 ` Jonathan Cameron
2020-11-22 15:51 ` Pandruvada, Srinivas
2020-11-22 16:50 ` Jonathan Cameron
2020-11-24 3:30 ` Ye, Xiang
2020-11-24 11:36 ` Jonathan Cameron
2020-11-25 3:24 ` Ye, Xiang
2020-11-24 6:43 ` Ye, Xiang
2020-11-24 11:39 ` Jonathan Cameron
2020-11-25 2:39 ` Ye, Xiang
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=20201121173330.3afd1087@archlinux \
--to=jic23@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=xiang.ye@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).