From: Jonathan Cameron <jic23@kernel.org>
To: Yauhen Kharuzhy <jekhor@gmail.com>
Cc: linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
linux-kernel@vger.kernel.org, Jiri Kosina <jikos@kernel.org>,
Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Subject: Re: [PATCH] iio: hid-sensor-als: Don't stop probing at non-supported attribute
Date: Sun, 17 Dec 2023 14:40:39 +0000 [thread overview]
Message-ID: <20231217144039.5c971685@jic23-huawei> (raw)
In-Reply-To: <20231216114229.652020-1-jekhor@gmail.com>
On Sat, 16 Dec 2023 13:42:29 +0200
Yauhen Kharuzhy <jekhor@gmail.com> wrote:
> Some ambient light sensors don't support color temperature and
> chromaticity attributes. The driver stops probing if it finds this.
>
> To support sensors without of color temperature and chromaticity
> attributes, just skip them at probing if they weren't found.
>
> Tested at Lenovo Yogabook YB1-X91L tablet.
>
> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
i reviewed this one as as well as Srinivas' as that had issues that need solving.
This one just seems to half paper over the problem It won't update the channels
etc but the set of channels provided to userspace are still garbage.
So better than before, but not fixing the issue fully.
Jonathan
> ---
> drivers/iio/light/hid-sensor-als.c | 39 ++++++++++++++++++------------
> 1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index f17304b54468..b711bac3bb2b 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
> @@ -314,8 +314,11 @@ static int als_parse_report(struct platform_device *pdev,
> usage_id,
> HID_USAGE_SENSOR_LIGHT_ILLUM,
> &st->als[i]);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err(&pdev->dev,
> + "Failed to setup Illuminance attribute\n");
> return ret;
> + }
Unrelated change. For a fix we should look to keep things minimal.
> als_adjust_channel_bit_mask(channels, i, st->als[i].size);
>
> dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
> @@ -326,14 +329,16 @@ static int als_parse_report(struct platform_device *pdev,
> usage_id,
> HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE,
> &st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP]);
> - if (ret < 0)
> - return ret;
> - als_adjust_channel_bit_mask(channels, CHANNEL_SCAN_INDEX_COLOR_TEMP,
> - st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].size);
> + if (!ret) {
> + dev_info(&pdev->dev, "Color temperature is supported\n");
I'd argue we shouldn't print a message on this.
Use the availability of channels after driver is probed to figure this out if
needed.
> + als_adjust_channel_bit_mask(channels,
> + CHANNEL_SCAN_INDEX_COLOR_TEMP,
> + st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].size);
>
> - dev_dbg(&pdev->dev, "als %x:%x\n",
> - st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].index,
> - st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].report_id);
> + dev_dbg(&pdev->dev, "als %x:%x\n",
> + st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].index,
> + st->als[CHANNEL_SCAN_INDEX_COLOR_TEMP].report_id);
> + }
>
> for (i = 0; i < 2; i++) {
> int next_scan_index = CHANNEL_SCAN_INDEX_CHROMATICITY_X + i;
> @@ -342,23 +347,25 @@ static int als_parse_report(struct platform_device *pdev,
> HID_INPUT_REPORT, usage_id,
> HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X + i,
> &st->als[next_scan_index]);
> - if (ret < 0)
> - return ret;
> -
> - als_adjust_channel_bit_mask(channels,
> + if (!ret) {
> + dev_info(&pdev->dev,
> + "Light chromaticity %c is supported\n",
> + i ? 'Y' : 'X');
> + als_adjust_channel_bit_mask(channels,
> CHANNEL_SCAN_INDEX_CHROMATICITY_X + i,
> st->als[next_scan_index].size);
>
> - dev_dbg(&pdev->dev, "als %x:%x\n",
> - st->als[next_scan_index].index,
> - st->als[next_scan_index].report_id);
> + dev_dbg(&pdev->dev, "als %x:%x\n",
> + st->als[next_scan_index].index,
> + st->als[next_scan_index].report_id);
> + }
> }
>
> st->scale_precision = hid_sensor_format_scale(usage_id,
> &st->als[CHANNEL_SCAN_INDEX_INTENSITY],
> &st->scale_pre_decml, &st->scale_post_decml);
>
> - return ret;
> + return 0;
> }
>
> /* Function to initialize the processing for usage id */
prev parent reply other threads:[~2023-12-17 14:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-16 11:42 [PATCH] iio: hid-sensor-als: Don't stop probing at non-supported attribute Yauhen Kharuzhy
2023-12-16 12:45 ` Yauhen Kharuzhy
2023-12-17 14:40 ` Jonathan Cameron [this message]
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=20231217144039.5c971685@jic23-huawei \
--to=jic23@kernel.org \
--cc=Basavaraj.Natikar@amd.com \
--cc=jekhor@gmail.com \
--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 \
/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