From: Jonathan Cameron <jic23@kernel.org>
To: Alexandru Ardelean <aardelean@deviqon.com>
Cc: platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
coproscefalo@gmail.com, hdegoede@redhat.com,
mgross@linux.intel.com, linux@deviqon.com
Subject: Re: [PATCH 00/10] platform/x86: toshiba_acpi: move acpi add/remove to device-managed routines
Date: Mon, 29 Mar 2021 13:38:24 +0100 [thread overview]
Message-ID: <20210329133824.1a1fad6f@jic23-huawei> (raw)
In-Reply-To: <20210324125548.45983-1-aardelean@deviqon.com>
On Wed, 24 Mar 2021 14:55:38 +0200
Alexandru Ardelean <aardelean@deviqon.com> wrote:
> This changeset tries to do a conversion of the toshiba_acpi driver to use
> only device-managed routines. The driver registers as a singleton, so no
> more than one device can be registered at a time.
>
> My main intent here is to try to convert the iio_device_alloc() and
> iio_device_register() to their devm_ variants.
>
> Usually, when converting a registration call to device-managed variant, the
> init order must be preserved. And the deregistration order must be a mirror
> of the registration (in reverse order).
>
> This change tries to do that, by using devm_ variants where available and
> devm_add_action_or_reset() where this isn't possible.
> Some deregistration ordering is changed, because it wasn't exactly
> mirroring (in reverse) the init order.
>
> For the IIO subsystem, the toshiba_acpi driver is the only user of
> iio_device_alloc(). If this changeset is accepted (after discussion), I
> will propose to remove the iio_device_alloc() function.
>
> While I admit this may look like an overzealous effort to use devm_
> everywhere (in IIO at least), for me it's a fun/interesting excercise.
hmm. I am dubious about 'removing' the support for non devm_ in the long
run because it can lead to requiring fiddly changes in existing drivers
(like this one :) and I don't want to put that barrier in front of anyone
using IIO.
However, I'm more than happy to see them used in very few drivers and
nice warning text added to suggest people might want to look at whether
then can move to a device managed probe flow
Jonathan
>
> Alexandru Ardelean (10):
> platform/x86: toshiba_acpi: bind life-time of toshiba_acpi_dev to
> parent
> platform/x86: toshiba_acpi: use devm_add_action_or_reset() for
> singleton clear
> platform/x86: toshiba_acpi: bind registration of miscdev object to
> parent
> platform/x86: toshiba_acpi: use device-managed functions for input
> device
> platform/x86: toshiba_acpi: register backlight with device-managed
> variant
> platform/x86: toshiba_acpi: use devm_led_classdev_register() for LEDs
> platform/x86: toshiba_acpi: use device-managed functions for
> accelerometer
> platform/x86: toshiba_acpi: use device-managed for wwan_rfkill
> management
> platform/x86: toshiba_acpi: use device-managed for sysfs removal
> platform/x86: toshiba_acpi: bind proc entries creation to parent
>
> drivers/platform/x86/toshiba_acpi.c | 249 +++++++++++++++++-----------
> 1 file changed, 150 insertions(+), 99 deletions(-)
>
next prev parent reply other threads:[~2021-03-29 12:39 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-24 12:55 [PATCH 00/10] platform/x86: toshiba_acpi: move acpi add/remove to device-managed routines Alexandru Ardelean
2021-03-24 12:55 ` [PATCH 01/10] platform/x86: toshiba_acpi: bind life-time of toshiba_acpi_dev to parent Alexandru Ardelean
2021-03-29 14:30 ` Jonathan Cameron
2021-03-30 6:49 ` Alexandru Ardelean
2021-03-24 12:55 ` [PATCH 02/10] platform/x86: toshiba_acpi: use devm_add_action_or_reset() for singleton clear Alexandru Ardelean
2021-03-29 14:27 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 03/10] platform/x86: toshiba_acpi: bind registration of miscdev object to parent Alexandru Ardelean
2021-03-29 14:33 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 04/10] platform/x86: toshiba_acpi: use device-managed functions for input device Alexandru Ardelean
2021-03-29 14:48 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 05/10] platform/x86: toshiba_acpi: register backlight with device-managed variant Alexandru Ardelean
2021-03-29 14:50 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 06/10] platform/x86: toshiba_acpi: use devm_led_classdev_register() for LEDs Alexandru Ardelean
2021-03-29 14:52 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 07/10] platform/x86: toshiba_acpi: use device-managed functions for accelerometer Alexandru Ardelean
2021-03-29 14:54 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 08/10] platform/x86: toshiba_acpi: use device-managed for wwan_rfkill management Alexandru Ardelean
2021-03-29 14:57 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 09/10] platform/x86: toshiba_acpi: use device-managed for sysfs removal Alexandru Ardelean
2021-03-29 15:09 ` Jonathan Cameron
2021-03-24 12:55 ` [PATCH 10/10] platform/x86: toshiba_acpi: bind proc entries creation to parent Alexandru Ardelean
2021-03-29 15:10 ` Jonathan Cameron
2021-03-29 12:38 ` Jonathan Cameron [this message]
2021-03-29 14:01 ` [PATCH 00/10] platform/x86: toshiba_acpi: move acpi add/remove to device-managed routines Alexandru Ardelean
2021-03-30 8:20 ` Hans de Goede
2021-03-30 9:22 ` Alexandru Ardelean
2021-03-30 9:27 ` Hans de Goede
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=20210329133824.1a1fad6f@jic23-huawei \
--to=jic23@kernel.org \
--cc=aardelean@deviqon.com \
--cc=coproscefalo@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@deviqon.com \
--cc=mgross@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
/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).