* Re: [PATCH] HID: i2c-hid: fix handling of unpopulated devices
From: Doug Anderson @ 2023-09-20 15:41 UTC (permalink / raw)
To: Johan Hovold
Cc: Johan Hovold, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel, Maxime Ripard, Dmitry Torokhov, LinusW, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM
In-Reply-To: <ZQqemN8P2VKgxhsV@hovoldconsulting.com>
Hi,
On Wed, Sep 20, 2023 at 12:26 AM Johan Hovold <johan@kernel.org> wrote:
>
> On Tue, Sep 19, 2023 at 11:15:46AM -0700, Doug Anderson wrote:
> > On Tue, Sep 19, 2023 at 12:07 AM Johan Hovold <johan@kernel.org> wrote:
>
> > > But regardless of what a long-term proper solution to this may look
> > > like, we need to fix the regression in 6.6-rc1 by restoring the old
> > > behaviour.
> >
> > OK, fair enough. I'll take a look at your patch, though I think the
> > person that really needs to approve it is Benjamin...
> >
> > Style-wise, I will say that Benjamin really wanted to keep the "panel
> > follower" code out of the main probe routine. Some of my initial
> > patches adding "panel follower" looked more like the results after
> > your patch but Benjamin really wasn't happy until there were no
> > special cases for panel-followers in the main probe routine. This is
> > why the code is structured as it is.
>
> Ok, I prefer not hiding away things like that as it obscures what's
> really going on, for example, in this case, that you register a device
> without really having probed it.
I can see your reasoning and I think that intuition is why the earlier
versions of my patches had explicit "panel follower" logic in probe.
However, Benjamin really liked the logic abstracted out.
> As I alluded to in the commit message, you probably want to be able to
> support second-source touchscreen panel followers as well at some point
> and then deferring checking whether device is populated until the panel
> is powered on is not going to work.
Yeah, I've been pondering this too. I _think_ it would work OK-ish if
both devices probed and then only one of the two would actually make
the sub-HID devices. So you'd actually see both devices succeed at
probing but only one of them would actually be functional. It's a bit
ugly, though. :( Maybe marginally better would be if we could figure
out how to have the device which fails to get its interrupt later
unbind itself, if that's possible...
The only other thought I had would be to have the parent i2c bus
understand that it had children that were panel followers, which it
should be able to do by seeing the "panel" attribute in their device
tree. Then the i2c bus could itself register as a panel follower and
could wait to probe its children until they were powered on. This
could happen in the i2c core so we didn't have to add code like this
to all i2c bus drivers. ...and, if necessary, we could add this to
other busses like SPI. It feels a little awkward but could work.
> I skimmed the thread were you added this, but I'm not sure I saw any
> reason for why powering on the panel follower temporarily during probe
> would not work?
My first instinct says we can't do this, but let's think about it...
In general the "panel follower" API is designed to give all the
decision making about when to power things on and off to the panel
driver, which is controlled by DRM.
The reason for this is from experience I had when dealing with the
Samsung ATNA33XC20 panel that's on "sc7180-trogdor-homestar". The TCON
on that panel tended to die if you didn't sequence it just right.
Specifically, if you were sending pixels to the panel and then stopped
then you absolutely needed to power the panel off and on again. Folks
I talked to even claimed that the panel was working "to spec" since,
in the "Power Sequencing" section of the eDP spec it clearly shows
that you _must_ turn the panel off and on again after you stop giving
it bits. ...this is despite the fact that no other panel I've worked
with cares. ;-)
On homestar, since we didn't have the "panel follower" API, we ended
up adding cost to the hardware and putting the panel and touchscreens
on different power rails. However, I wanted to make sure that if we
ran into a similar situation in the future (or maybe if we were trying
to make hardware work that we didn't have control over) that we could
solve it.
The other reason for giving full control to the panel driver is just
how userspace usually works. Right now userspace tends to power off
panels if they're not used (like if a lid is closed on a laptop) but
doesn't necessarily power off the touchscreen. Thus if the touchscreen
has the ability to keep things powered on then we'd never get to a low
power state.
The above all explains why panel followers like the touchscreen
shouldn't be able to keep power on. However, you are specifically
suggesting that we just turn the power on temporarily during probe. As
I think about that, it might be possible? I guess you'd have to
temporarily block DRM from changing the state of the panel while the
touchscreen is probing. Then if the panel was off then you'd turn it
on briefly, do your probe, and then turn it off again. If the panel
was on then by blocking DRM you'd ensure that it stayed on. I'm not
sure how palatable that would be or if there are any other tricky
parts I'm not thinking about.
> > Thinking that way, is there any reason you can't just move the
> > i2c_hid_init_irq() into __do_i2c_hid_core_initial_power_up()? You
> > could replace the call to enable_irq() with it and then remove the
> > `IRQF_NO_AUTOEN` flag? I think that would also solve the issue if you
> > wanted to use a 2nd source + the panel follower concept? Both devices
> > would probe, but only one of them would actually grab the interrupt
> > and only one of them would actually create real HID devices. We might
> > need to do some work to keep from trying again at every poweron of the
> > panel, but it would probably be workable? I think this would also be a
> > smaller change...
>
> That was my first idea as well, but conceptually it is more correct to
> request resources at probe time and not at some later point when you can
> no longer fail probe.
>
> You'd also need to handle the fact that the interrupt may never have
> been requested when remove() is called, which adds unnecessary
> complexity.
I don't think it's a lot of complexity, is it? Just an extra "if" statement...
-Doug
^ permalink raw reply
* Re: [PATCH v2 9/9] HID: amd_sfh: Add light chromaticity for SFH1.1
From: Jiri Kosina @ 2023-09-20 15:26 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: benjamin.tissoires, jic23, lars, srinivas.pandruvada, linux-input,
linux-iio
In-Reply-To: <20230919081054.2050714-10-Basavaraj.Natikar@amd.com>
On Tue, 19 Sep 2023, Basavaraj Natikar wrote:
> In most cases, ambient color sensors also support the x and y light
> colors, which represent the coordinates on the CIE 1931 chromaticity
> diagram. Thus, add light chromaticity x and y for SFH1.1.
>
> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
> ---
> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 5 ++++-
> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> index f100aaafa167..8a037de08e92 100644
> --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> @@ -238,8 +238,11 @@ static u8 get_input_rep(u8 current_index, int sensor_idx, int report_id,
> als_input.illuminance_value = float_to_int(als_data.lux);
>
> memcpy_fromio(&binfo, mp2->vsbase, sizeof(struct sfh_base_info));
> - if (binfo.sbase.s_prop[ALS_IDX].sf.feat & 0x2)
> + if (binfo.sbase.s_prop[ALS_IDX].sf.feat & 0x2) {
> als_input.light_color_temp = als_data.light_color_temp;
> + als_input.chromaticity_x_value = float_to_int(als_data.chromaticity_x);
> + als_input.chromaticity_y_value = float_to_int(als_data.chromaticity_y);
> + }
>
> report_size = sizeof(als_input);
> memcpy(input_report, &als_input, sizeof(als_input));
> diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h
> index 6f6f5db150c3..656c3e95ef8c 100644
> --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h
> +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h
> @@ -147,6 +147,8 @@ struct sfh_als_data {
> struct sfh_common_data commondata;
> u32 lux;
> u32 light_color_temp;
> + u32 chromaticity_x;
> + u32 chromaticity_y;
> };
>
> struct hpd_status {
> --
> 2.25.1
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 8/9] HID: amd_sfh: Add light chromaticity support
From: Jiri Kosina @ 2023-09-20 15:25 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: benjamin.tissoires, jic23, lars, srinivas.pandruvada, linux-input,
linux-iio
In-Reply-To: <20230919081054.2050714-9-Basavaraj.Natikar@amd.com>
On Tue, 19 Sep 2023, Basavaraj Natikar wrote:
> In most cases, ambient color sensors also support the x and y light
> colors, which represent the coordinates on the CIE 1931 chromaticity
> diagram. Thus, add light chromaticity x and y.
>
> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
> ---
> .../amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c | 5 ++++-
> .../amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h | 2 ++
> .../hid_descriptor/amd_sfh_hid_report_desc.h | 14 ++++++++++++++
> 3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
> index b7e732ec4806..ef1f9be8b893 100644
> --- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
> +++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
> @@ -258,8 +258,11 @@ static u8 get_input_report(u8 current_index, int sensor_idx, int report_id,
> als_input.illuminance_value =
> (int)sensor_virt_addr[0] / AMD_SFH_FW_MULTIPLIER;
>
> - if (sensor_idx == ACS_IDX)
> + if (sensor_idx == ACS_IDX) {
> als_input.light_color_temp = sensor_virt_addr[1];
> + als_input.chromaticity_x_value = sensor_virt_addr[2];
> + als_input.chromaticity_y_value = sensor_virt_addr[3];
> + }
>
> report_size = sizeof(als_input);
> memcpy(input_report, &als_input, sizeof(als_input));
> diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
> index a7fc50deca4d..882434b1501f 100644
> --- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
> +++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
> @@ -100,6 +100,8 @@ struct als_input_report {
> /* values specific to this sensor */
> int illuminance_value;
> int light_color_temp;
> + int chromaticity_x_value;
> + int chromaticity_y_value;
> } __packed;
>
> struct hpd_feature_report {
> diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
> index 26e994e54ded..67ec2d6a417d 100644
> --- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
> +++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
> @@ -648,6 +648,20 @@ static const u8 als_report_descriptor[] = {
> 0x75, 32, /* HID report size(32) */
> 0x95, 1, /* HID report count (1) */
> 0X81, 0x02, /* HID Input (Data_Arr_Abs) */
> +0x0A, 0xD4, 0x04, /* HID usage sensor data light chromaticity_x */
> +0x17, 0x00, 0x00, 0x01, 0x80, /* HID logical Min_32 */
> +0x27, 0xFF, 0xFF, 0xFF, 0x7F, /* HID logical Max_32 */
> +0x55, 0x0, /* HID unit exponent(0x0) */
> +0x75, 32, /* HID report size(32) */
> +0x95, 1, /* HID report count(1) */
> +0X81, 0x02, /* HID Input (Data_Var_Abs) */
> +0x0A, 0xD5, 0x04, /* HID usage sensor data light chromaticity_y */
> +0x17, 0x00, 0x00, 0x01, 0x80, /* HID logical Min_32 */
> +0x27, 0xFF, 0xFF, 0xFF, 0x7F, /* HID logical Max_32 */
> +0x55, 0x0, /* HID unit exponent(0x0) */
> +0x75, 32, /* HID report size(32) */
> +0x95, 1, /* HID report count (1) */
> +0X81, 0x02, /* HID Input (Data_Var_Abs) */
> 0xC0 /* HID end collection */
> };
>
> --
> 2.25.1
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 5/9] HID: amd_sfh: Add support for SFH1.1 light color temperature
From: Jiri Kosina @ 2023-09-20 15:25 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: benjamin.tissoires, jic23, lars, srinivas.pandruvada, linux-input,
linux-iio
In-Reply-To: <20230919081054.2050714-6-Basavaraj.Natikar@amd.com>
On Tue, 19 Sep 2023, Basavaraj Natikar wrote:
> In most cases, ambient color sensors also support light color temperature.
> As a result, add support of light color temperature for SFH1.1.
>
> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
> ---
> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 6 ++++++
> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 13 +++++++++++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> index 06bdcf072d10..f100aaafa167 100644
> --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c
> @@ -188,6 +188,7 @@ static u8 get_input_rep(u8 current_index, int sensor_idx, int report_id,
> struct sfh_mag_data mag_data;
> struct sfh_als_data als_data;
> struct hpd_status hpdstatus;
> + struct sfh_base_info binfo;
> void __iomem *sensoraddr;
> u8 report_size = 0;
>
> @@ -235,6 +236,11 @@ static u8 get_input_rep(u8 current_index, int sensor_idx, int report_id,
> memcpy_fromio(&als_data, sensoraddr, sizeof(struct sfh_als_data));
> get_common_inputs(&als_input.common_property, report_id);
> als_input.illuminance_value = float_to_int(als_data.lux);
> +
> + memcpy_fromio(&binfo, mp2->vsbase, sizeof(struct sfh_base_info));
> + if (binfo.sbase.s_prop[ALS_IDX].sf.feat & 0x2)
> + als_input.light_color_temp = als_data.light_color_temp;
> +
> report_size = sizeof(als_input);
> memcpy(input_report, &als_input, sizeof(als_input));
> break;
> diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h
> index 9d31d5b510eb..6f6f5db150c3 100644
> --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h
> +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_interface.h
> @@ -88,6 +88,16 @@ struct sfh_sensor_list {
> };
> };
>
> +struct sfh_sensor_prop {
> + union {
> + u32 sprop;
> + struct {
> + u32 elist : 16;
> + u32 feat : 16;
> + } sf;
> + };
> +};
> +
> struct sfh_base_info {
> union {
> u32 sfh_base[24];
> @@ -95,6 +105,8 @@ struct sfh_base_info {
> struct sfh_platform_info plat_info;
> struct sfh_firmware_info fw_info;
> struct sfh_sensor_list s_list;
> + u32 rsvd;
> + struct sfh_sensor_prop s_prop[16];
> } sbase;
> };
> };
> @@ -134,6 +146,7 @@ struct sfh_mag_data {
> struct sfh_als_data {
> struct sfh_common_data commondata;
> u32 lux;
> + u32 light_color_temp;
> };
>
> struct hpd_status {
> --
> 2.25.1
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 4/9] HID: amd_sfh: Add support for light color temperature
From: Jiri Kosina @ 2023-09-20 15:25 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: benjamin.tissoires, jic23, lars, srinivas.pandruvada, linux-input,
linux-iio
In-Reply-To: <20230919081054.2050714-5-Basavaraj.Natikar@amd.com>
On Tue, 19 Sep 2023, Basavaraj Natikar wrote:
> In most cases, ambient color sensors also support light color temperature.
> As a result, add support of light color temperature.
>
> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
> ---
> drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c | 4 ++++
> drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h | 1 +
> .../amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h | 7 +++++++
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
> index 8716a05950c8..b7e732ec4806 100644
> --- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
> +++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
> @@ -257,6 +257,10 @@ static u8 get_input_report(u8 current_index, int sensor_idx, int report_id,
> else
> als_input.illuminance_value =
> (int)sensor_virt_addr[0] / AMD_SFH_FW_MULTIPLIER;
> +
> + if (sensor_idx == ACS_IDX)
> + als_input.light_color_temp = sensor_virt_addr[1];
> +
> report_size = sizeof(als_input);
> memcpy(input_report, &als_input, sizeof(als_input));
> break;
> diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
> index ebd55675eb62..a7fc50deca4d 100644
> --- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
> +++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
> @@ -99,6 +99,7 @@ struct als_input_report {
> struct common_input_property common_property;
> /* values specific to this sensor */
> int illuminance_value;
> + int light_color_temp;
> } __packed;
>
> struct hpd_feature_report {
> diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
> index 697f2791ea9c..26e994e54ded 100644
> --- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
> +++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
> @@ -641,6 +641,13 @@ static const u8 als_report_descriptor[] = {
> 0x75, 32, /* HID report size(32) */
> 0x95, 1, /* HID report count (1) */
> 0X81, 0x02, /* HID Input (Data_Arr_Abs) */
> +0x0A, 0xD2, 0x04, /* HID usage sensor data light temperature */
> +0x17, 0x00, 0x00, 0x01, 0x80, /* HID logical Min_32 */
> +0x27, 0xFF, 0xFF, 0xFF, 0x7F, /* HID logical Max_32 */
> +0x55, 0x0, /* HID unit exponent(0x0) */
> +0x75, 32, /* HID report size(32) */
> +0x95, 1, /* HID report count (1) */
> +0X81, 0x02, /* HID Input (Data_Arr_Abs) */
> 0xC0 /* HID end collection */
> };
>
> --
> 2.25.1
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 0/9] Support light color temperature and chromaticity
From: Basavaraj Natikar @ 2023-09-20 15:23 UTC (permalink / raw)
To: Jiri Kosina, Basavaraj Natikar
Cc: benjamin.tissoires, jic23, lars, srinivas.pandruvada, linux-input,
linux-iio
In-Reply-To: <nycvar.YFH.7.76.2309201612350.14216@cbobk.fhfr.pm>
On 9/20/2023 7:43 PM, Jiri Kosina wrote:
> On Tue, 19 Sep 2023, Basavaraj Natikar wrote:
>
>> This series adds support for light color temperature and chromaticity.
>>
>> v1->v2:
>> *Rename the series.
>> *Rename als_illum to als channel as it supports other channels.
>> *Update patch description to include same reading for the two existing
>> channels to use channel index to support more hub attributes.
>> *Keep line length under 80chars in hid-sensor-als.
>> *Add new channel type IIO_COLORTEMP.
>> *Update patch description and its subject to add channel type for
>> chromaticity.
>>
>> Basavaraj Natikar (9):
>> iio: hid-sensor-als: Use channel index to support more hub attributes
>> iio: Add channel type light color temperature
>> iio: hid-sensor-als: Add light color temperature support
>> HID: amd_sfh: Add support for light color temperature
>> HID: amd_sfh: Add support for SFH1.1 light color temperature
>> iio: Add channel type for chromaticity
>> iio: hid-sensor-als: Add light chromaticity support
>> HID: amd_sfh: Add light chromaticity support
>> HID: amd_sfh: Add light chromaticity for SFH1.1
>>
>> Documentation/ABI/testing/sysfs-bus-iio | 15 ++
>> .../hid_descriptor/amd_sfh_hid_desc.c | 7 +
>> .../hid_descriptor/amd_sfh_hid_desc.h | 3 +
>> .../hid_descriptor/amd_sfh_hid_report_desc.h | 21 +++
>> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 9 ++
>> .../amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 15 ++
>> drivers/iio/industrialio-core.c | 2 +
>> drivers/iio/light/hid-sensor-als.c | 130 +++++++++++++++---
>> include/linux/hid-sensor-ids.h | 4 +
>> include/uapi/linux/iio/types.h | 2 +
>> tools/iio/iio_event_monitor.c | 3 +
>> 11 files changed, 195 insertions(+), 16 deletions(-)
> I believe this should go through Jonathan's tree as a whole, right?
Yes, this should go through Jonathan's tree as a whole.
If you don't have concerns, can you please ack HID amd_sfh changes?
Thanks,
--
Basavaraj
^ permalink raw reply
* Re: [PATCH 52/52] input: wm97xx-core - Convert to platform remove callback returning void
From: Charles Keepax @ 2023-09-20 14:24 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Dmitry Torokhov, Linus Walleij, Jonathan Cameron, patches,
linux-input, kernel
In-Reply-To: <20230920125829.1478827-53-u.kleine-koenig@pengutronix.de>
On Wed, Sep 20, 2023 at 02:58:29PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new() which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH 51/52] input: wm831x-ts - Convert to platform remove callback returning void
From: Charles Keepax @ 2023-09-20 14:24 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Dmitry Torokhov, patches, linux-input, kernel
In-Reply-To: <20230920125829.1478827-52-u.kleine-koenig@pengutronix.de>
On Wed, Sep 20, 2023 at 02:58:28PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new() which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH 27/52] input: wm831x-on - Convert to platform remove callback returning void
From: Charles Keepax @ 2023-09-20 14:24 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Dmitry Torokhov, patches, linux-input, kernel
In-Reply-To: <20230920125829.1478827-28-u.kleine-koenig@pengutronix.de>
On Wed, Sep 20, 2023 at 02:58:04PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new() which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v2 0/9] Support light color temperature and chromaticity
From: Jiri Kosina @ 2023-09-20 14:13 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: benjamin.tissoires, jic23, lars, srinivas.pandruvada, linux-input,
linux-iio
In-Reply-To: <20230919081054.2050714-1-Basavaraj.Natikar@amd.com>
On Tue, 19 Sep 2023, Basavaraj Natikar wrote:
> This series adds support for light color temperature and chromaticity.
>
> v1->v2:
> *Rename the series.
> *Rename als_illum to als channel as it supports other channels.
> *Update patch description to include same reading for the two existing
> channels to use channel index to support more hub attributes.
> *Keep line length under 80chars in hid-sensor-als.
> *Add new channel type IIO_COLORTEMP.
> *Update patch description and its subject to add channel type for
> chromaticity.
>
> Basavaraj Natikar (9):
> iio: hid-sensor-als: Use channel index to support more hub attributes
> iio: Add channel type light color temperature
> iio: hid-sensor-als: Add light color temperature support
> HID: amd_sfh: Add support for light color temperature
> HID: amd_sfh: Add support for SFH1.1 light color temperature
> iio: Add channel type for chromaticity
> iio: hid-sensor-als: Add light chromaticity support
> HID: amd_sfh: Add light chromaticity support
> HID: amd_sfh: Add light chromaticity for SFH1.1
>
> Documentation/ABI/testing/sysfs-bus-iio | 15 ++
> .../hid_descriptor/amd_sfh_hid_desc.c | 7 +
> .../hid_descriptor/amd_sfh_hid_desc.h | 3 +
> .../hid_descriptor/amd_sfh_hid_report_desc.h | 21 +++
> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 9 ++
> .../amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 15 ++
> drivers/iio/industrialio-core.c | 2 +
> drivers/iio/light/hid-sensor-als.c | 130 +++++++++++++++---
> include/linux/hid-sensor-ids.h | 4 +
> include/uapi/linux/iio/types.h | 2 +
> tools/iio/iio_event_monitor.c | 3 +
> 11 files changed, 195 insertions(+), 16 deletions(-)
I believe this should go through Jonathan's tree as a whole, right?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: (subset) [PATCH v4 0/5] ARM: omap: omap4-embt2ws: 32K clock for WLAN
From: Lee Jones @ 2023-09-20 13:45 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt, lee,
bcousson, tony, mturquette, sboyd, linux-input, devicetree,
linux-kernel, linux-omap, linux-clk, Andreas Kemnade
In-Reply-To: <20230916100515.1650336-1-andreas@kemnade.info>
On Sat, 16 Sep 2023 12:05:10 +0200, Andreas Kemnade wrote:
> To have WLAN working properly, enable a 32K clock of the TWL6032.
> In earlier tests, it was still enabled from a previous boot into
> the vendor system.
>
> Changes in V4:
> - use dev_err_probe in clk probe()
> - R-by
>
> [...]
Applied, thanks!
[1/5] dt-bindings: mfd: convert twl-family.txt to json-schema
commit: 098e2d6fd72fc99097af33e6e8cb4cd0921a26ac
[2/5] dt-bindings: mfd: ti,twl: Add clock provider properties
commit: eb9fba08e386ff98818de12b40a5ee1443129229
[3/5] mfd: twl-core: Add a clock subdevice for the TWL6032
commit: 3e359099b245227c6729dd5f81f2757dea5d4656
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH] hid: cp2112: Fix IRQ shutdown stopping polling for all IRQs on chip
From: Andy Shevchenko @ 2023-09-20 13:33 UTC (permalink / raw)
To: Danny Kaehn; +Cc: jikos, benjamin.tissoires, linux-input, ethan.twardy
In-Reply-To: <20230919212426.489637-1-danny.kaehn@plexus.com>
On Tue, Sep 19, 2023 at 04:24:26PM -0500, Danny Kaehn wrote:
> Previously cp2112_gpio_irq_shutdown always cancelled the
cp2112_gpio_irq_shutdown()
> gpio_poll_worker, even if other IRQs were still active, and did not set
> the gpio_poll flag to false. This resulted in any call to _shutdown()
> resulting in interrupts no longer functioning on the chip until a
> _remove occurred (a.e. the cp2112 is unplugged or system rebooted).
_remove()
> Only cancel polling if all IRQs are disabled/masked, and correctly set
> the gpio_poll flag, allowing polling to restart when an interrupt is
> next enabled.
...
> + if (!dev->irq_mask)
> + {
The style tells to use these on a single line.
> + dev->gpio_poll = false;
> + cancel_delayed_work_sync(&dev->gpio_poll_worker);
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 34/52] drivers/input/serio/i8042-sparcio.h :: Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 13:06 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Rob Herring, Liang He, kernel, linux-input
In-Reply-To: <20230920125829.1478827-35-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
Hello Dmitry,
for this patch's Subject my git filter-branch cmdline failed. I guess it
should be something like
input: i8042-sparcio - Convert to platform remove callback returning void
instead. I'll wait until the dust settles. In the meantime feel free to
skip this patch or adapt the Subject yourself. In the former case I'll
come back to this patch later.
Thanks and sorry for the annoyance,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] hid: cp2112: Fix duplicate workqueue initialization
From: Andy Shevchenko @ 2023-09-20 13:04 UTC (permalink / raw)
To: Danny Kaehn; +Cc: jikos, benjamin.tissoires, linux-input, ethan.twardy
In-Reply-To: <20230919212245.483646-1-danny.kaehn@plexus.com>
On Tue, Sep 19, 2023 at 04:22:45PM -0500, Danny Kaehn wrote:
> Previously the cp2112 driver called INIT_DELAYED_WORK within
> cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
> workqueue on subsequent IRQ startups following an initial request. This
> resulted in a warning in set_work_data in workqueue.c, as well as a rare
> NULL dereference within process_one_work in workqueue.c.
>
> Initialize the workqueue within _probe instead.
Does it deserve a Fixes tag?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 23/52] input: pm8941-pwrkey - Convert to platform remove callback returning void
From: Konrad Dybcio @ 2023-09-20 13:03 UTC (permalink / raw)
To: Uwe Kleine-König, Dmitry Torokhov
Cc: Andy Gross, Bjorn Andersson, linux-arm-msm, linux-input, kernel
In-Reply-To: <20230920125829.1478827-24-u.kleine-koenig@pengutronix.de>
On 9/20/23 14:58, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new() which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* [PATCH 00/52] input: Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:57 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Michael Hennerich, linux-input, kernel, Benson Leung,
Guenter Roeck, Greg Kroah-Hartman, Jonathan Cameron,
joewu (吳仲振), chrome-platform,
Andy Shevchenko, Mattijs Korpershoek, Jeff LaBundy, Rob Herring,
Siarhei Volkau, Pavel Machek, Steven Rostedt (Google),
Paolo Abeni, Kalle Valo, Yangtao Li, ye xingchen, Maxime Coquelin,
Alexandre Torgue, linux-stm32, linux-arm-kernel,
Support Opensource, Andrey Moiseev, Lee Jones, Linus Walleij,
Andy Gross, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
Hans de Goede, Miloslav Trmac, patches, Christophe JAILLET,
Liang He, Chen Jun, Ruan Jinjie, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, linux-sunxi, Michal Simek, Robert Jarzmik,
Dmitry Baryshkov, Arnd Bergmann, Rafael J. Wysocki,
Krzysztof Kozlowski, Daniel Lezcano, Jonathan Corbet
Hello,
this series converts all platform drivers below drivers/input to use
remove_new. The motivation is to get rid of an integer return code
that is (mostly) ignored by the platform driver core and error prone on
the driver side.
See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
There are no interdependencies between the patches. As there are still
quite a few drivers to convert, I'm happy about every patch that makes
it in. So even if there is a merge conflict with one patch until you
apply or a subject prefix is suboptimal, please apply the remainder of
this series anyhow.
Best regards
Uwe
Uwe Kleine-König (52):
input: adp5520-keys - Convert to platform remove callback returning
void
input: cros_ec_keyb - Convert to platform remove callback returning
void
input: ep93xx_keypad - Convert to platform remove callback returning
void
input: iqs62x-keys - Convert to platform remove callback returning
void
input: matrix_keypad - Convert to platform remove callback returning
void
input: omap-keypad - Convert to platform remove callback returning
void
input: omap4-keypad - Convert to platform remove callback returning
void
input: samsung-keypad - Convert to platform remove callback returning
void
input: sh_keysc - Convert to platform remove callback returning void
input: spear-keyboard - Convert to platform remove callback returning
void
input: stmpe-keypad - Convert to platform remove callback returning
void
input: 88pm80x_onkey - Convert to platform remove callback returning
void
input: da9052_onkey - Convert to platform remove callback returning
void
input: da9055_onkey - Convert to platform remove callback returning
void
input: ideapad_slidebar - Convert to platform remove callback
returning void
input: m68kspkr - Convert to platform remove callback returning void
input: max8997_haptic - Convert to platform remove callback returning
void
input: mc13783-pwrbutton - Convert to platform remove callback
returning void
input: palmas-pwrbutton - Convert to platform remove callback
returning void
input: pcap_keys - Convert to platform remove callback returning void
input: pcf50633-input - Convert to platform remove callback returning
void
input: pcspkr - Convert to platform remove callback returning void
input: pm8941-pwrkey - Convert to platform remove callback returning
void
input: soc_button_array - Convert to platform remove callback
returning void
input: sparcspkr - Convert to platform remove callback returning void
input: wistron_btns - Convert to platform remove callback returning
void
input: wm831x-on - Convert to platform remove callback returning void
input: navpoint - Convert to platform remove callback returning void
input: altera_ps2 - Convert to platform remove callback returning void
input: ams_delta_serio - Convert to platform remove callback returning
void
input: apbps2 - Convert to platform remove callback returning void
input: arc_ps2 - Convert to platform remove callback returning void
input: ct82c710 - Convert to platform remove callback returning void
drivers/input/serio/i8042-sparcio.h :: Convert to platform remove
callback returning void
input: i8042 - Convert to platform remove callback returning void
input: ioc3kbd - Convert to platform remove callback returning void
input: maceps2 - Convert to platform remove callback returning void
input: olpc_apsp - Convert to platform remove callback returning void
input: ps2-gpio - Convert to platform remove callback returning void
input: q40kbd - Convert to platform remove callback returning void
input: rpckbd - Convert to platform remove callback returning void
input: sun4i-ps2 - Convert to platform remove callback returning void
input: xilinx_ps2 - Convert to platform remove callback returning void
input: da9052_tsi - Convert to platform remove callback returning void
input: mainstone-wm97xx - Convert to platform remove callback
returning void
input: mc13783_ts - Convert to platform remove callback returning void
input: pcap_ts - Convert to platform remove callback returning void
input: stmpe-ts - Convert to platform remove callback returning void
input: sun4i-ts - Convert to platform remove callback returning void
input: ti_am335x_tsc - Convert to platform remove callback returning
void
input: wm831x-ts - Convert to platform remove callback returning void
input: wm97xx-core - Convert to platform remove callback returning
void
drivers/input/keyboard/adp5520-keys.c | 6 ++----
drivers/input/keyboard/cros_ec_keyb.c | 6 ++----
drivers/input/keyboard/ep93xx_keypad.c | 6 ++----
drivers/input/keyboard/iqs62x-keys.c | 6 ++----
drivers/input/keyboard/matrix_keypad.c | 6 ++----
drivers/input/keyboard/omap-keypad.c | 6 ++----
drivers/input/keyboard/omap4-keypad.c | 6 ++----
drivers/input/keyboard/samsung-keypad.c | 6 ++----
drivers/input/keyboard/sh_keysc.c | 6 ++----
drivers/input/keyboard/spear-keyboard.c | 6 ++----
drivers/input/keyboard/stmpe-keypad.c | 6 ++----
drivers/input/misc/88pm80x_onkey.c | 5 ++---
drivers/input/misc/da9052_onkey.c | 6 ++----
drivers/input/misc/da9055_onkey.c | 6 ++----
drivers/input/misc/ideapad_slidebar.c | 6 ++----
drivers/input/misc/m68kspkr.c | 6 ++----
drivers/input/misc/max8997_haptic.c | 6 ++----
drivers/input/misc/mc13783-pwrbutton.c | 6 ++----
drivers/input/misc/palmas-pwrbutton.c | 6 ++----
drivers/input/misc/pcap_keys.c | 6 ++----
drivers/input/misc/pcf50633-input.c | 6 ++----
drivers/input/misc/pcspkr.c | 6 ++----
drivers/input/misc/pm8941-pwrkey.c | 6 ++----
drivers/input/misc/soc_button_array.c | 6 ++----
drivers/input/misc/sparcspkr.c | 12 ++++--------
drivers/input/misc/wistron_btns.c | 6 ++----
drivers/input/misc/wm831x-on.c | 6 ++----
drivers/input/mouse/navpoint.c | 6 ++----
drivers/input/serio/altera_ps2.c | 6 ++----
drivers/input/serio/ams_delta_serio.c | 6 ++----
drivers/input/serio/apbps2.c | 6 ++----
drivers/input/serio/arc_ps2.c | 6 ++----
drivers/input/serio/ct82c710.c | 6 ++----
drivers/input/serio/i8042-sparcio.h | 6 ++----
drivers/input/serio/i8042.c | 6 ++----
drivers/input/serio/ioc3kbd.c | 6 ++----
drivers/input/serio/maceps2.c | 6 ++----
drivers/input/serio/olpc_apsp.c | 6 ++----
drivers/input/serio/ps2-gpio.c | 5 ++---
drivers/input/serio/q40kbd.c | 6 ++----
drivers/input/serio/rpckbd.c | 6 ++----
drivers/input/serio/sun4i-ps2.c | 6 ++----
drivers/input/serio/xilinx_ps2.c | 6 ++----
drivers/input/touchscreen/da9052_tsi.c | 6 ++----
drivers/input/touchscreen/mainstone-wm97xx.c | 6 ++----
drivers/input/touchscreen/mc13783_ts.c | 6 ++----
drivers/input/touchscreen/pcap_ts.c | 6 ++----
drivers/input/touchscreen/stmpe-ts.c | 6 ++----
drivers/input/touchscreen/sun4i-ts.c | 6 ++----
drivers/input/touchscreen/ti_am335x_tsc.c | 5 ++---
drivers/input/touchscreen/wm831x-ts.c | 6 ++----
drivers/input/touchscreen/wm97xx-core.c | 6 ++----
52 files changed, 106 insertions(+), 209 deletions(-)
base-commit: 926f75c8a5ab70567eb4c2d82fbc96963313e564
--
2.40.1
^ permalink raw reply
* [PATCH 49/52] input: sun4i-ts - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Rafael J. Wysocki,
Krzysztof Kozlowski, Daniel Lezcano, Jonathan Corbet, linux-input,
linux-arm-kernel, linux-sunxi, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/touchscreen/sun4i-ts.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c
index bb3c6072fc82..92b2b840b4b7 100644
--- a/drivers/input/touchscreen/sun4i-ts.c
+++ b/drivers/input/touchscreen/sun4i-ts.c
@@ -375,7 +375,7 @@ static int sun4i_ts_probe(struct platform_device *pdev)
return 0;
}
-static int sun4i_ts_remove(struct platform_device *pdev)
+static void sun4i_ts_remove(struct platform_device *pdev)
{
struct sun4i_ts_data *ts = platform_get_drvdata(pdev);
@@ -385,8 +385,6 @@ static int sun4i_ts_remove(struct platform_device *pdev)
/* Deactivate all IRQs */
writel(0, ts->base + TP_INT_FIFOC);
-
- return 0;
}
static const struct of_device_id sun4i_ts_of_match[] = {
@@ -403,7 +401,7 @@ static struct platform_driver sun4i_ts_driver = {
.of_match_table = sun4i_ts_of_match,
},
.probe = sun4i_ts_probe,
- .remove = sun4i_ts_remove,
+ .remove_new = sun4i_ts_remove,
};
module_platform_driver(sun4i_ts_driver);
--
2.40.1
^ permalink raw reply related
* [PATCH 50/52] input: ti_am335x_tsc - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Rob Herring, Jonathan Cameron, linux-input, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/touchscreen/ti_am335x_tsc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
index 9aa4e35fb4f5..34324f8512ac 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -491,7 +491,7 @@ static int titsc_probe(struct platform_device *pdev)
return err;
}
-static int titsc_remove(struct platform_device *pdev)
+static void titsc_remove(struct platform_device *pdev)
{
struct titsc *ts_dev = platform_get_drvdata(pdev);
u32 steps;
@@ -508,7 +508,6 @@ static int titsc_remove(struct platform_device *pdev)
input_unregister_device(ts_dev->input);
kfree(ts_dev);
- return 0;
}
static int titsc_suspend(struct device *dev)
@@ -552,7 +551,7 @@ MODULE_DEVICE_TABLE(of, ti_tsc_dt_ids);
static struct platform_driver ti_tsc_driver = {
.probe = titsc_probe,
- .remove = titsc_remove,
+ .remove_new = titsc_remove,
.driver = {
.name = "TI-am335x-tsc",
.pm = pm_sleep_ptr(&titsc_pm_ops),
--
2.40.1
^ permalink raw reply related
* [PATCH 52/52] input: wm97xx-core - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Jonathan Cameron, patches, linux-input, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/touchscreen/wm97xx-core.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c
index ac3b3dd59488..f01f6cc9b59f 100644
--- a/drivers/input/touchscreen/wm97xx-core.c
+++ b/drivers/input/touchscreen/wm97xx-core.c
@@ -756,11 +756,9 @@ static int wm97xx_mfd_probe(struct platform_device *pdev)
return ret;
}
-static int wm97xx_mfd_remove(struct platform_device *pdev)
+static void wm97xx_mfd_remove(struct platform_device *pdev)
{
wm97xx_remove(&pdev->dev);
-
- return 0;
}
static int wm97xx_suspend(struct device *dev)
@@ -878,7 +876,7 @@ static struct platform_driver wm97xx_mfd_driver = {
.pm = pm_sleep_ptr(&wm97xx_pm_ops),
},
.probe = wm97xx_mfd_probe,
- .remove = wm97xx_mfd_remove,
+ .remove_new = wm97xx_mfd_remove,
};
static int __init wm97xx_init(void)
--
2.40.1
^ permalink raw reply related
* [PATCH 42/52] input: sun4i-ps2 - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-input,
linux-arm-kernel, linux-sunxi, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/serio/sun4i-ps2.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/sun4i-ps2.c b/drivers/input/serio/sun4i-ps2.c
index eb262640192e..aec66d9f5176 100644
--- a/drivers/input/serio/sun4i-ps2.c
+++ b/drivers/input/serio/sun4i-ps2.c
@@ -297,7 +297,7 @@ static int sun4i_ps2_probe(struct platform_device *pdev)
return error;
}
-static int sun4i_ps2_remove(struct platform_device *pdev)
+static void sun4i_ps2_remove(struct platform_device *pdev)
{
struct sun4i_ps2data *drvdata = platform_get_drvdata(pdev);
@@ -311,8 +311,6 @@ static int sun4i_ps2_remove(struct platform_device *pdev)
iounmap(drvdata->reg_base);
kfree(drvdata);
-
- return 0;
}
static const struct of_device_id sun4i_ps2_match[] = {
@@ -324,7 +322,7 @@ MODULE_DEVICE_TABLE(of, sun4i_ps2_match);
static struct platform_driver sun4i_ps2_driver = {
.probe = sun4i_ps2_probe,
- .remove = sun4i_ps2_remove,
+ .remove_new = sun4i_ps2_remove,
.driver = {
.name = DRIVER_NAME,
.of_match_table = sun4i_ps2_match,
--
2.40.1
^ permalink raw reply related
* [PATCH 45/52] input: mainstone-wm97xx - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Robert Jarzmik, Dmitry Baryshkov, Arnd Bergmann, linux-input,
kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/touchscreen/mainstone-wm97xx.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/mainstone-wm97xx.c b/drivers/input/touchscreen/mainstone-wm97xx.c
index 85b95ed461e7..bfbebe245040 100644
--- a/drivers/input/touchscreen/mainstone-wm97xx.c
+++ b/drivers/input/touchscreen/mainstone-wm97xx.c
@@ -252,18 +252,16 @@ static int mainstone_wm97xx_probe(struct platform_device *pdev)
return wm97xx_register_mach_ops(wm, &mainstone_mach_ops);
}
-static int mainstone_wm97xx_remove(struct platform_device *pdev)
+static void mainstone_wm97xx_remove(struct platform_device *pdev)
{
struct wm97xx *wm = platform_get_drvdata(pdev);
wm97xx_unregister_mach_ops(wm);
-
- return 0;
}
static struct platform_driver mainstone_wm97xx_driver = {
.probe = mainstone_wm97xx_probe,
- .remove = mainstone_wm97xx_remove,
+ .remove_new = mainstone_wm97xx_remove,
.driver = {
.name = "wm97xx-touch",
},
--
2.40.1
^ permalink raw reply related
* [PATCH 51/52] input: wm831x-ts - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: patches, linux-input, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/touchscreen/wm831x-ts.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/wm831x-ts.c b/drivers/input/touchscreen/wm831x-ts.c
index 319f57fb9af5..9cee26b63341 100644
--- a/drivers/input/touchscreen/wm831x-ts.c
+++ b/drivers/input/touchscreen/wm831x-ts.c
@@ -374,14 +374,12 @@ static int wm831x_ts_probe(struct platform_device *pdev)
return error;
}
-static int wm831x_ts_remove(struct platform_device *pdev)
+static void wm831x_ts_remove(struct platform_device *pdev)
{
struct wm831x_ts *wm831x_ts = platform_get_drvdata(pdev);
free_irq(wm831x_ts->pd_irq, wm831x_ts);
free_irq(wm831x_ts->data_irq, wm831x_ts);
-
- return 0;
}
static struct platform_driver wm831x_ts_driver = {
@@ -389,7 +387,7 @@ static struct platform_driver wm831x_ts_driver = {
.name = "wm831x-touch",
},
.probe = wm831x_ts_probe,
- .remove = wm831x_ts_remove,
+ .remove_new = wm831x_ts_remove,
};
module_platform_driver(wm831x_ts_driver);
--
2.40.1
^ permalink raw reply related
* [PATCH 43/52] input: xilinx_ps2 - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Michal Simek, Rob Herring, linux-input, linux-arm-kernel, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/serio/xilinx_ps2.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c
index f3d28da70b75..d8f9faf2b529 100644
--- a/drivers/input/serio/xilinx_ps2.c
+++ b/drivers/input/serio/xilinx_ps2.c
@@ -329,7 +329,7 @@ static int xps2_of_probe(struct platform_device *ofdev)
* if the driver module is being unloaded. It frees any resources allocated to
* the device.
*/
-static int xps2_of_remove(struct platform_device *of_dev)
+static void xps2_of_remove(struct platform_device *of_dev)
{
struct xps2data *drvdata = platform_get_drvdata(of_dev);
struct resource r_mem; /* IO mem resources */
@@ -344,8 +344,6 @@ static int xps2_of_remove(struct platform_device *of_dev)
release_mem_region(r_mem.start, resource_size(&r_mem));
kfree(drvdata);
-
- return 0;
}
/* Match table for of_platform binding */
@@ -361,7 +359,7 @@ static struct platform_driver xps2_of_driver = {
.of_match_table = xps2_of_match,
},
.probe = xps2_of_probe,
- .remove = xps2_of_remove,
+ .remove_new = xps2_of_remove,
};
module_platform_driver(xps2_of_driver);
--
2.40.1
^ permalink raw reply related
* [PATCH 47/52] input: pcap_ts - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/touchscreen/pcap_ts.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/pcap_ts.c b/drivers/input/touchscreen/pcap_ts.c
index b2da0194e02a..821245019fea 100644
--- a/drivers/input/touchscreen/pcap_ts.c
+++ b/drivers/input/touchscreen/pcap_ts.c
@@ -197,7 +197,7 @@ static int pcap_ts_probe(struct platform_device *pdev)
return err;
}
-static int pcap_ts_remove(struct platform_device *pdev)
+static void pcap_ts_remove(struct platform_device *pdev)
{
struct pcap_ts *pcap_ts = platform_get_drvdata(pdev);
@@ -207,8 +207,6 @@ static int pcap_ts_remove(struct platform_device *pdev)
input_unregister_device(pcap_ts->input);
kfree(pcap_ts);
-
- return 0;
}
#ifdef CONFIG_PM
@@ -240,7 +238,7 @@ static const struct dev_pm_ops pcap_ts_pm_ops = {
static struct platform_driver pcap_ts_driver = {
.probe = pcap_ts_probe,
- .remove = pcap_ts_remove,
+ .remove_new = pcap_ts_remove,
.driver = {
.name = "pcap-ts",
.pm = PCAP_TS_PM_OPS,
--
2.40.1
^ permalink raw reply related
* [PATCH 48/52] input: stmpe-ts - Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-09-20 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Maxime Coquelin, Alexandre Torgue, linux-input, linux-stm32,
linux-arm-kernel, kernel
In-Reply-To: <20230920125829.1478827-1-u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/touchscreen/stmpe-ts.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/stmpe-ts.c b/drivers/input/touchscreen/stmpe-ts.c
index 25c45c3a3561..b204fdb2d22c 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -350,13 +350,11 @@ static int stmpe_input_probe(struct platform_device *pdev)
return 0;
}
-static int stmpe_ts_remove(struct platform_device *pdev)
+static void stmpe_ts_remove(struct platform_device *pdev)
{
struct stmpe_touch *ts = platform_get_drvdata(pdev);
stmpe_disable(ts->stmpe, STMPE_BLOCK_TOUCHSCREEN);
-
- return 0;
}
static struct platform_driver stmpe_ts_driver = {
@@ -364,7 +362,7 @@ static struct platform_driver stmpe_ts_driver = {
.name = STMPE_TS_NAME,
},
.probe = stmpe_input_probe,
- .remove = stmpe_ts_remove,
+ .remove_new = stmpe_ts_remove,
};
module_platform_driver(stmpe_ts_driver);
--
2.40.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox