| Message ID | 20211122212850.321542-3-pauk.denis@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | hwmon: (nct6775) Support lock by ACPI mutex | expand |
> + if (ACPI_FAILURE(acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_DELAY_MSEC_LOCK))) On Mon, Nov 22, 2021 at 11:29 PM Denis Pauk <pauk.denis@gmail.com> wrote: No period in the Subject. > Use ACPI lock when board has separate lock for monitoring IO. the board a separate ... > +#define ASUSWMI_DELAY_MSEC_LOCK 500 /* Wait 0.5 s max. to get the lock */ Units are the last in the names, hence (also check the comment's location and English) /* Wait for up to 0.5 s to acquire the lock */ #define ASUSWMI_LOCK_TIMEOUT_MS 500 ... > - struct mutex update_lock; > + struct mutex update_lock; /* non ACPI lock */ > + acpi_handle acpi_wmi_mutex; /* ACPI lock */ Couldn't it be an anonymous union? ... > +static int nct6775_wmi_lock(struct nct6775_data *data) > +{ > + if (ACPI_FAILURE(acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_DELAY_MSEC_LOCK))) Please, use a temporary variable here and in the similar cases. acpi_status status; status = acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_LOCK_TIMEOUT_MS)); if (ACPI_FAILURE(status)) > + return -EIO; > + > + return 0; > +}
Dear Andy, Denis, and Günter, Denis worked on my code with the first attempt to read EC sensors from ASUS motherboards and submitted it as a driver named "asus_wmi_ec_sensors", which is not in hwmon-next. Now he adds the ACPI lock feature to support other motherboards, and I have another iteration of the EC sensor driver under development (needs some polishment) that utilizes the same concept (ACPI lock instead of WMI methods), which is smaller, cleaner and faster than the WMI-based one. I'm going to submit it to the mainline too. I think it should replace the WMI one. In anticipation of that, can we change the name of the accepted driver (asus_wmi_ec_sensors -> asus_ec_sensors) now, in order to not confuse users in the next version and to remove implementation detail from the module name? The drivers provide indistinguishable data to HWMON. Regards, Eugene On Wed, 24 Nov 2021 at 17:11, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > + if (ACPI_FAILURE(acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_DELAY_MSEC_LOCK))) > > > On Mon, Nov 22, 2021 at 11:29 PM Denis Pauk <pauk.denis@gmail.com> wrote: > > No period in the Subject. > > > Use ACPI lock when board has separate lock for monitoring IO. > > the board > a separate > > ... > > > +#define ASUSWMI_DELAY_MSEC_LOCK 500 /* Wait 0.5 s max. to get the lock */ > > Units are the last in the names, hence (also check the comment's > location and English) > > /* Wait for up to 0.5 s to acquire the lock */ > #define ASUSWMI_LOCK_TIMEOUT_MS 500 > > ... > > > - struct mutex update_lock; > > + struct mutex update_lock; /* non ACPI lock */ > > + acpi_handle acpi_wmi_mutex; /* ACPI lock */ > > Couldn't it be an anonymous union? > > ... > > > +static int nct6775_wmi_lock(struct nct6775_data *data) > > +{ > > + if (ACPI_FAILURE(acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_DELAY_MSEC_LOCK))) > > Please, use a temporary variable here and in the similar cases. > > acpi_status status; > > status = acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, > ASUSWMI_LOCK_TIMEOUT_MS)); > if (ACPI_FAILURE(status)) > > > + return -EIO; > > + > > + return 0; > > +} > > -- > With Best Regards, > Andy Shevchenko
On Thu, 25 Nov 2021 at 14:14, Eugene Shalygin <eugene.shalygin@gmail.com> wrote: > Denis worked on my code with the first attempt to read EC sensors from > ASUS motherboards and submitted it as a driver named > "asus_wmi_ec_sensors", which is not in hwmon-next. Sorry, "which is NOW in hwmon-next".
On 11/25/21 5:14 AM, Eugene Shalygin wrote: > Dear Andy, Denis, and Günter, > > Denis worked on my code with the first attempt to read EC sensors from > ASUS motherboards and submitted it as a driver named > "asus_wmi_ec_sensors", which is not in hwmon-next. Now he adds the > ACPI lock feature to support other motherboards, and I have another > iteration of the EC sensor driver under development (needs some > polishment) that utilizes the same concept (ACPI lock instead of WMI > methods), which is smaller, cleaner and faster than the WMI-based one. > I'm going to submit it to the mainline too. I think it should replace > the WMI one. In anticipation of that, can we change the name of the > accepted driver (asus_wmi_ec_sensors -> asus_ec_sensors) now, in order > to not confuse users in the next version and to remove implementation > detail from the module name? The drivers provide indistinguishable > data to HWMON. > Two drivers with the same functionality ? What would be the benefit of that ? Why not drop the current one entirely instead ? Guenter
On Thu, Nov 25, 2021 at 3:15 PM Eugene Shalygin <eugene.shalygin@gmail.com> wrote: > > Dear Andy, Denis, and Günter, Please, do not top post in the mailing lists! > Denis worked on my code with the first attempt to read EC sensors from > ASUS motherboards and submitted it as a driver named > "asus_wmi_ec_sensors", which is not in hwmon-next. Now he adds the > ACPI lock feature to support other motherboards, and I have another > iteration of the EC sensor driver under development (needs some > polishment) that utilizes the same concept (ACPI lock instead of WMI > methods), which is smaller, cleaner and faster than the WMI-based one. > I'm going to submit it to the mainline too. I think it should replace > the WMI one. In anticipation of that, can we change the name of the > accepted driver (asus_wmi_ec_sensors -> asus_ec_sensors) now, in order > to not confuse users in the next version and to remove implementation > detail from the module name? The drivers provide indistinguishable > data to HWMON. I'm not sure I have got the above correctly, do you mean that the just submitted asus_wmi_sensors HWMON driver will be replaced by your changes? If so, you guys, need a lot to improve communication between each other before submitting anything upstream.
> Two drivers with the same functionality ? What would be the benefit of that ? > Why not drop the current one entirely instead ? Exactly that: I want to replace the WMI one with the new one, which relies on ACPI lock and directly talks to the EC, and I want to keep the driver name unchanged. Thus asking to rename the WMI driver before the 5.16 release.
> Please, do not top post in the mailing lists! Well, it was almost a new topic... > I'm not sure I have got the above correctly, do you mean that the just > submitted asus_wmi_sensors HWMON driver will be replaced by your > changes? If so, you guys, need a lot to improve communication between > each other before submitting anything upstream. Yes, you get it right. Sorry for that, it was a long story and I worked on the subject only occasionally, so that when Denis took the code and submitted it to the mainline I was not sure which approach is better, and so I did not stop him. Best regards, Eugene
On 11/25/21 6:00 AM, Eugene Shalygin wrote: >> Please, do not top post in the mailing lists! > > Well, it was almost a new topic... > >> I'm not sure I have got the above correctly, do you mean that the just >> submitted asus_wmi_sensors HWMON driver will be replaced by your >> changes? If so, you guys, need a lot to improve communication between >> each other before submitting anything upstream. > > Yes, you get it right. Sorry for that, it was a long story and I > worked on the subject > only occasionally, so that when Denis took the code and submitted it > to the mainline > I was not sure which approach is better, and so I did not stop him. > We won't be heving two drivers with the same functionality. Give me one reason why I should not drop the wmi driver (or both of them; I am not sure which one we are talking about here). On top of all that, this submission isn't about any of the wmi drivers, but for the nct6775 driver, which just adds to the confusion. Guenter
On Thu, 25 Nov 2021 at 20:54, Guenter Roeck <linux@roeck-us.net> wrote: > We won't be heving two drivers with the same functionality. Give me one > reason why I should not drop the wmi driver (or both of them; I am not > sure which one we are talking about here). > > On top of all that, this submission isn't about any of the wmi drivers, > but for the nct6775 driver, which just adds to the confusion. Let me try to explain once again, please. I began to dig into the ASUS sensors and how to read their values and at first found the WMI function to do that, wrote a driver and Denis submitted it as asus_wmi_ec_sensors. Now, I know a better and simpler way to read those sensors, which uses ACPI mutex directly. I suggested Denis to use the mutex way for the nct6775 driver for motherboards without WMI functions to read from the nct chip. With that change entering the nct driver, I want to submit my updated driver for EC sensors, replacing the asus_wmi_ec_sensors code (which is essentially my old driver). So, now I ask to rename asus_wmi_sensors to asus_ec_sensors (source file and KBuild options) already before 5.16 is released, because the updated code, which I will submit later, and which will replace that in asus_wmi_ec_sensors.c, does not use WMI. Hope this clarifies my request and intention. Best regards, Eugene
On Thu, Nov 25, 2021 at 10:05 PM Eugene Shalygin <eugene.shalygin@gmail.com> wrote: > > On Thu, 25 Nov 2021 at 20:54, Guenter Roeck <linux@roeck-us.net> wrote: > > We won't be heving two drivers with the same functionality. Give me one > > reason why I should not drop the wmi driver (or both of them; I am not > > sure which one we are talking about here). > > > > On top of all that, this submission isn't about any of the wmi drivers, > > but for the nct6775 driver, which just adds to the confusion. > > Let me try to explain once again, please. I began to dig into the ASUS > sensors and how to read their values and at first found the WMI > function to do that, wrote a driver and Denis submitted it as > asus_wmi_ec_sensors. Now, I know a better and simpler way to read > those sensors, which uses ACPI mutex directly. I suggested Denis to > use the mutex way for the nct6775 driver for motherboards without WMI > functions to read from the nct chip. With that change entering the nct > driver, I want to submit my updated driver for EC sensors, replacing > the asus_wmi_ec_sensors code (which is essentially my old driver). > > So, now I ask to rename asus_wmi_sensors to asus_ec_sensors (source > file and KBuild options) already before 5.16 is released, because the > updated code, which I will submit later, and which will replace that > in asus_wmi_ec_sensors.c, does not use WMI. > > Hope this clarifies my request and intention. Since you are talking about something which is not ready yet (as I read "will" above), I propose a compromise variant, i.e. let's leave current driver(s) as is for v5.17 and after v5.17-rc1 you submit your proposal for review. Okay?
Hi, On Thu, 25 Nov 2021 22:09:46 +0200 Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Thu, Nov 25, 2021 at 10:05 PM Eugene Shalygin > <eugene.shalygin@gmail.com> wrote: > > > > On Thu, 25 Nov 2021 at 20:54, Guenter Roeck <linux@roeck-us.net> > > wrote: > > > We won't be heving two drivers with the same functionality. Give > > > me one reason why I should not drop the wmi driver (or both of > > > them; I am not sure which one we are talking about here). > > > > > > On top of all that, this submission isn't about any of the wmi > > > drivers, but for the nct6775 driver, which just adds to the > > > confusion. > > > > Let me try to explain once again, please. I began to dig into the > > ASUS sensors and how to read their values and at first found the WMI > > function to do that, wrote a driver and Denis submitted it as > > asus_wmi_ec_sensors. Now, I know a better and simpler way to read > > those sensors, which uses ACPI mutex directly. I suggested Denis to > > use the mutex way for the nct6775 driver for motherboards without > > WMI functions to read from the nct chip. With that change entering > > the nct driver, I want to submit my updated driver for EC sensors, > > replacing the asus_wmi_ec_sensors code (which is essentially my old > > driver). > > > > So, now I ask to rename asus_wmi_sensors to asus_ec_sensors (source > > file and KBuild options) already before 5.16 is released, because > > the updated code, which I will submit later, and which will replace > > that in asus_wmi_ec_sensors.c, does not use WMI. > > > > Hope this clarifies my request and intention. > > Since you are talking about something which is not ready yet (as I > read "will" above), I propose a compromise variant, i.e. let's leave > current driver(s) as is for v5.17 and after v5.17-rc1 you submit your > proposal for review. Okay? > I would like to propose to leave the current name of the driver and add the same logic as in the current patch. So when we know the exact name of acpi mutex - code will use such mutex for lock and directly read EC memory region. In case if we don't know the exact mutex name/path or for some reason ASUS decides to change UEFI code - code will use WMI methods. In such a case, adding or checking a new motherboard will require only adding a minimal list of well known registers without disassembling UEFI code. What do you think? Best regards, Denis.
On Thu, 25 Nov 2021 at 21:10, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > Since you are talking about something which is not ready yet (as I > read "will" above), I propose a compromise variant, i.e. let's leave > current driver(s) as is for v5.17 and after v5.17-rc1 you submit your > proposal for review. Okay? > Andy, I'm pretty sure the submission will happen and my only intention is to save possible users from driver name change right after the driver is introduced. I see no harm in renaming it. Eugene
On Thu, 25 Nov 2021 at 21:25, Denis Pauk <pauk.denis@gmail.com> wrote: > I would like to propose to leave the current name of the driver and add > the same logic as in the current patch. So when we know the exact name > of acpi mutex - code will use such mutex for lock and directly read EC > memory region. In case if we don't know the exact mutex name/path or for > some reason ASUS decides to change UEFI code - code will use WMI > methods. In such a case, adding or checking a new motherboard will > require only adding a minimal list of well known registers without > disassembling UEFI code. > > What do you think? Sounds reasonable to me, but nevertheless I think dropping the "wmi" part from the driver name would make the name clearer with the proposed functional change. Best regards, Eugene
On Thu, Nov 25, 2021 at 10:33 PM Eugene Shalygin <eugene.shalygin@gmail.com> wrote: > On Thu, 25 Nov 2021 at 21:25, Denis Pauk <pauk.denis@gmail.com> wrote: > > > I would like to propose to leave the current name of the driver and add > > the same logic as in the current patch. So when we know the exact name > > of acpi mutex - code will use such mutex for lock and directly read EC > > memory region. In case if we don't know the exact mutex name/path or for > > some reason ASUS decides to change UEFI code - code will use WMI > > methods. In such a case, adding or checking a new motherboard will > > require only adding a minimal list of well known registers without > > disassembling UEFI code. > > > > What do you think? > > Sounds reasonable to me, but nevertheless I think dropping the "wmi" > part from the driver name would make the name clearer with the > proposed functional change. We don't do changes for something which is not yet in the kernel or about to be there. My proposal stays the same, sorry.
diff --git a/drivers/hwmon/nct6775.c b/drivers/hwmon/nct6775.c index 049c42ea66bb..3aeb32093c35 100644 --- a/drivers/hwmon/nct6775.c +++ b/drivers/hwmon/nct6775.c @@ -140,6 +140,7 @@ struct nct6775_sio_data { int ld; enum kinds kind; enum sensor_access access; + acpi_handle acpi_wmi_mutex; /* superio_() callbacks */ void (*sio_outb)(struct nct6775_sio_data *sio_data, int reg, int val); @@ -155,6 +156,7 @@ struct nct6775_sio_data { #define ASUSWMI_METHODID_RHWM 0x5248574D #define ASUSWMI_METHODID_WHWM 0x5748574D #define ASUSWMI_UNSUPPORTED_METHOD 0xFFFFFFFE +#define ASUSWMI_DELAY_MSEC_LOCK 500 /* Wait 0.5 s max. to get the lock */ static int nct6775_asuswmi_evaluate_method(u32 method_id, u8 bank, u8 reg, u8 val, u32 *retval) { @@ -1243,7 +1245,9 @@ struct nct6775_data { unsigned int (*fan_from_reg)(u16 reg, unsigned int divreg); unsigned int (*fan_from_reg_min)(u16 reg, unsigned int divreg); - struct mutex update_lock; + struct mutex update_lock; /* non ACPI lock */ + acpi_handle acpi_wmi_mutex; /* ACPI lock */ + bool valid; /* true if following fields are valid */ unsigned long last_updated; /* In jiffies */ @@ -1563,6 +1567,20 @@ static int nct6775_wmi_write_value(struct nct6775_data *data, u16 reg, u16 value return res; } +static int nct6775_wmi_lock(struct nct6775_data *data) +{ + if (ACPI_FAILURE(acpi_acquire_mutex(data->acpi_wmi_mutex, NULL, ASUSWMI_DELAY_MSEC_LOCK))) + return -EIO; + + return 0; +} + +static void nct6775_wmi_unlock(struct nct6775_data *data, struct device *dev) +{ + if (ACPI_FAILURE(acpi_release_mutex(data->acpi_wmi_mutex, NULL))) + dev_err(dev, "Failed to release mutex."); +} + /* * On older chips, only registers 0x50-0x5f are banked. * On more recent chips, all registers are banked. @@ -4051,6 +4069,7 @@ static int nct6775_probe(struct platform_device *pdev) data->kind = sio_data->kind; data->sioreg = sio_data->sioreg; + data->acpi_wmi_mutex = sio_data->acpi_wmi_mutex; if (sio_data->access == access_direct) { data->addr = res->start; @@ -4061,9 +4080,14 @@ static int nct6775_probe(struct platform_device *pdev) data->write_value = nct6775_wmi_write_value; } - mutex_init(&data->update_lock); - data->lock = nct6775_lock; - data->unlock = nct6775_unlock; + if (data->acpi_wmi_mutex) { + data->lock = nct6775_wmi_lock; + data->unlock = nct6775_wmi_unlock; + } else { + mutex_init(&data->update_lock); + data->lock = nct6775_lock; + data->unlock = nct6775_unlock; + } data->name = nct6775_device_names[data->kind]; data->bank = 0xff; /* Force initial bank selection */ @@ -5114,6 +5138,7 @@ static int __init sensors_nct6775_init(void) int sioaddr[2] = { 0x2e, 0x4e }; enum sensor_access access = access_direct; const char *board_vendor, *board_name; + acpi_handle acpi_wmi_mutex = NULL; u8 tmp; err = platform_driver_register(&nct6775_driver); @@ -5159,6 +5184,7 @@ static int __init sensors_nct6775_init(void) found = true; sio_data.access = access; + sio_data.acpi_wmi_mutex = acpi_wmi_mutex; if (access == access_asuswmi) { sio_data.sio_outb = superio_wmi_outb; @@ -5186,11 +5212,13 @@ static int __init sensors_nct6775_init(void) res.end = address + IOREGION_OFFSET + IOREGION_LENGTH - 1; res.flags = IORESOURCE_IO; - err = acpi_check_resource_conflict(&res); - if (err) { - platform_device_put(pdev[i]); - pdev[i] = NULL; - continue; + if (!acpi_wmi_mutex) { + err = acpi_check_resource_conflict(&res); + if (err) { + platform_device_put(pdev[i]); + pdev[i] = NULL; + continue; + } } err = platform_device_add_resources(pdev[i], &res, 1);
Use ACPI lock when board has separate lock for monitoring IO. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk <pauk.denis@gmail.com> --- drivers/hwmon/nct6775.c | 46 +++++++++++++++++++++++++++++++++-------- 1 file changed, 37 insertions(+), 9 deletions(-)