From: Jonathan Corbet <corbet@lwn.net>
To: ira.weiny@intel.com
Cc: Ira Weiny <ira.weiny@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dan Williams <dan.j.williams@intel.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 1/3] Documentation/auxiliary_bus: Clarify auxiliary_device creation
Date: Tue, 02 Nov 2021 16:06:07 -0600 [thread overview]
Message-ID: <87k0hq2oxc.fsf@meer.lwn.net> (raw)
In-Reply-To: <20211102215317.3676782-2-ira.weiny@intel.com>
ira.weiny@intel.com writes:
> From: Ira Weiny <ira.weiny@intel.com>
>
> The documentation for creating an auxiliary device is a 3 step not a 2
> step process. Specifically the requirements of setting the name, id,
> dev.release, and dev.parent fields was not clear as a precursor to the '2
> step' process documented.
>
> Clarify by declaring this a 3 step process starting with setting the
> fields of struct auxiliary_device correctly.
>
> Also add some sample code and tie the change into the rest of the
> documentation.
>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Looks generally good but ...
> Documentation/driver-api/auxiliary_bus.rst | 77 +++++++++++++++++-----
> 1 file changed, 59 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst
> index ef902daf0d68..8b3e795f3691 100644
> --- a/Documentation/driver-api/auxiliary_bus.rst
> +++ b/Documentation/driver-api/auxiliary_bus.rst
> @@ -79,18 +79,6 @@ is given a name that, combined with the registering drivers KBUILD_MODNAME,
> creates a match_name that is used for driver binding, and an id that combined
> with the match_name provide a unique name to register with the bus subsystem.
>
> -Registering an auxiliary_device is a two-step process. First call
> -auxiliary_device_init(), which checks several aspects of the auxiliary_device
> -struct and performs a device_initialize(). After this step completes, any
> -error state must have a call to auxiliary_device_uninit() in its resolution path.
> -The second step in registering an auxiliary_device is to perform a call to
> -auxiliary_device_add(), which sets the name of the device and add the device to
> -the bus.
> -
> -Unregistering an auxiliary_device is also a two-step process to mirror the
> -register process. First call auxiliary_device_delete(), then call
> -auxiliary_device_uninit().
> -
> .. code-block:: c
>
> struct auxiliary_device {
> @@ -99,15 +87,68 @@ auxiliary_device_uninit().
> u32 id;
> };
>
> -If two auxiliary_devices both with a match_name "mod.foo" are registered onto
> -the bus, they must have unique id values (e.g. "x" and "y") so that the
> -registered devices names are "mod.foo.x" and "mod.foo.y". If match_name + id
> -are not unique, then the device_add fails and generates an error message.
> +Registering an auxiliary_device is a three-step process.
> +
> +First, a 'struct auxiliary_device' needs to be defined or allocated for each
> +sub-device desired. The name, id, dev.release, and dev.parent fields of this
> +structure must be filled in as follows.
> +
> +The 'name' field is to be given a name that is recognized by the auxiliary
> +driver. If two auxiliary_devices with the same match_name, eg
> +"mod.MY_DEVICE_NAME", are registered onto the bus, they must have unique id
> +values (e.g. "x" and "y") so that the registered devices names are "mod.foo.x"
> +and "mod.foo.y". If match_name + id are not unique, then the device_add fails
> +and generates an error message.
>
> The auxiliary_device.dev.type.release or auxiliary_device.dev.release must be
> -populated with a non-NULL pointer to successfully register the auxiliary_device.
> +populated with a non-NULL pointer to successfully register the
> +auxiliary_device. This release call is where resources associated with the
> +auxiliary device must be free'ed. Because once the device is placed on the bus
> +the parent driver can not tell what other code may have a reference to this
> +data.
> +
> +The auxiliary_device.dev.parent should be set. Typically to the registering
> +drivers device.
> +
> +Second, call auxiliary_device_init(), which checks several aspects of the
> +auxiliary_device struct and performs a device_initialize(). After this step
> +completes, any error state must have a call to auxiliary_device_uninit() in its
> +resolution path.
> +
> +The third and final step in registering an auxiliary_device is to perform a
> +call to auxiliary_device_add(), which sets the name of the device and adds the
> +device to the bus.
> +
> +.. code-block:: c
> +
> + struct axiliary_device *my_aux_dev = my_aux_dev_alloc(xxx);
This ----------^ would appear to be a typo...
Thanks,
jon
next prev parent reply other threads:[~2021-11-02 22:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-02 21:53 [PATCH 0/3] Improve Auxiliary Device documentation ira.weiny
2021-11-02 21:53 ` [PATCH 1/3] Documentation/auxiliary_bus: Clarify auxiliary_device creation ira.weiny
2021-11-02 22:06 ` Jonathan Corbet [this message]
2021-11-02 22:53 ` [PATCH v2] " ira.weiny
2021-11-26 16:16 ` Greg Kroah-Hartman
2021-11-28 5:32 ` Ira Weiny
2021-11-28 7:59 ` Greg Kroah-Hartman
2021-11-02 21:53 ` [PATCH 2/3] Documentation/auxiliary_bus: Clarify match_name ira.weiny
2021-11-02 21:53 ` [PATCH 3/3] Documentation/auxiliary_bus: Update Auxiliary device lifespan ira.weiny
2021-11-03 7:58 ` [PATCH 0/3] Improve Auxiliary Device documentation Greg Kroah-Hartman
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=87k0hq2oxc.fsf@meer.lwn.net \
--to=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@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
Powered by JetHome