From: "Marek Behún" <kabel@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>,
Andrew Lunn <andrew@lunn.ch>, Arnd Bergmann <arnd@arndb.de>,
soc@kernel.org, arm@kernel.org, Andy Shevchenko <andy@kernel.org>,
Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH 10/19] firmware: turris-mox-rwtm: Simplify driver kobject code
Date: Thu, 13 Jun 2024 17:39:01 +0200 [thread overview]
Message-ID: <20240613173901.0f56573e@dellmb> (raw)
In-Reply-To: <36e3991f-f61c-d400-d783-5ddd8605a390@linux.intel.com>
On Thu, 13 Jun 2024 16:37:23 +0300 (EEST)
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> On Thu, 13 Jun 2024, Marek Behún wrote:
>
> > On Thu, 13 Jun 2024 13:19:47 +0300 (EEST)
> > Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> >
> > > On Thu, 13 Jun 2024, Marek Behún wrote:
> > >
> > > > On Thu, 13 Jun 2024 11:31:43 +0300 (EEST)
> > > > Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> > > >
> > > > > Is empty .release necessary at all? I found some kobj_type structs without
> > > > > .release so I'd expect it to be unnecessary.
> > > >
> > > > lib/kobject.c function kobject_cleanup() has the following:
> > > >
> > > > if (t && !t->release)
> > > > pr_debug("'%s' (%p): does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst.\n",
> > >
> > > Hmm, the plot thickens... that documentation file says:
> > >
> > > 'Do not try to get rid of this warning by providing an "empty" release
> > > function.'
> > >
> > > ?
> >
> > This whole thing stinks. I will rewrite it so that the attributes will
> > be under the device's kobject, as they should be. This way I can get
> > rid of the whole own kobject type.
>
> Yeah, I didn't really understand why they weren't there in the first
> place.
>
> > Then I will add a symlink from /sys/firmware/turris-mox-rwtm to the
> > device, for sysfs ABI compatibility.
>
>
> BTW (unrelated to any of your patches unless I missed something)...
> You might want to check one unlock_mutex: label that seemed to be 100%
> duplicate the tail of the return path.
Do you mean this?
mutex_unlock(&rwtm->busy);
return len;
unlock_mutex:
mutex_unlock(&rwtm->busy);
return ret;
It's not 100% duplicate, but yes, I could do ret = len.
The thing is that this whole debugfs code is going away. I wanted to
clean the driver up a little before converting this debugfs code to
keyctl (which is the correct API for the thing that is now exposed to
userspace via debugfs).
Marek
next prev parent reply other threads:[~2024-06-13 15:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 13:54 [PATCH 00/19] Updates for turris-mox-rwtm driver Marek Behún
2024-06-12 13:54 ` [PATCH 01/19] firmware: turris-mox-rwtm: Do not complete if there are no waiters Marek Behún
2024-06-12 13:54 ` [PATCH 02/19] firmware: turris-mox-rwtm: Fix checking return value of wait_for_completion_timeout() Marek Behún
2024-06-13 8:06 ` Ilpo Järvinen
2024-06-12 13:54 ` [PATCH 03/19] firmware: turris-mox-rwtm: Use PAGE_SIZE instead of hardcoded 4096 Marek Behún
2024-06-13 8:01 ` Ilpo Järvinen
2024-06-13 9:54 ` Marek Behún
2024-06-12 13:54 ` [PATCH 04/19] firmware: turris-mox-rwtm: Use ETH_ALEN instead of hardcoded 6 Marek Behún
2024-06-13 8:02 ` Ilpo Järvinen
2024-06-12 13:54 ` [PATCH 05/19] firmware: turris-mox-rwtm: Use the boolean type where appropriate Marek Behún
2024-06-12 13:54 ` [PATCH 06/19] firmware: turris-mox-rwtm: Hide signature related constants behind macros Marek Behún
2024-06-12 13:54 ` [PATCH 07/19] firmware: turris-mox-rwtm: Fix driver includes Marek Behún
2024-06-12 13:54 ` [PATCH 08/19] firmware: turris-mox-rwtm: Use kobj_type's default_groups member for automatic sysfs files creation Marek Behún
2024-06-13 8:14 ` Ilpo Järvinen
2024-06-12 13:54 ` [PATCH 09/19] firmware: turris-mox-rwtm: Simplify debugfs code Marek Behún
2024-06-12 13:54 ` [PATCH 10/19] firmware: turris-mox-rwtm: Simplify driver kobject code Marek Behún
2024-06-13 8:31 ` Ilpo Järvinen
2024-06-13 9:55 ` Marek Behún
2024-06-13 10:19 ` Ilpo Järvinen
2024-06-13 13:31 ` Marek Behún
2024-06-13 13:37 ` Ilpo Järvinen
2024-06-13 15:39 ` Marek Behún [this message]
2024-06-13 15:44 ` Ilpo Järvinen
2024-06-12 13:54 ` [PATCH 11/19] firmware: turris-mox-rwtm: Return true error code if kobject_add() fails Marek Behún
2024-06-12 13:54 ` [PATCH 12/19] firmware: turris-mox-rwtm: Convert rest to devm_* and get rid of driver .remove() Marek Behún
2024-06-12 13:54 ` [PATCH 13/19] firmware: turris-mox-rwtm: Use dev_err_probe() where possible Marek Behún
2024-06-12 13:54 ` [PATCH 14/19] firmware: turris-mox-rwtm: Rearrange probe calls Marek Behún
2024-06-12 13:54 ` [PATCH 15/19] firmware: turris-mox-rwtm: Drop redundant device pointer Marek Behún
2024-06-12 13:54 ` [PATCH 16/19] firmware: turris-mox-rwtm: Use devm_mutex_init() instead of mutex_init() Marek Behún
2024-06-12 13:54 ` [PATCH 17/19] firmware: turris-mox-rwtm: Use container_of() instead of hwrng .priv member Marek Behún
2024-06-12 13:54 ` [PATCH 18/19] firmware: turris-mox-rwtm: Deduplicate command execution code Marek Behún
2024-06-12 13:54 ` [PATCH 19/19] firmware: turris-mox-rwtm: Use EOPNOTSUPP instead of ENOSYS Marek Behún
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=20240613173901.0f56573e@dellmb \
--to=kabel@kernel.org \
--cc=andrew@lunn.ch \
--cc=andy@kernel.org \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=gregory.clement@bootlin.com \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=soc@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