From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux LED Subsystem <linux-leds@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Hans de Goede <hdegoede@redhat.com>, Pavel Machek <pavel@denx.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: LED subsystem lagging maintenance
Date: Wed, 28 Jul 2021 14:31:43 +0300 [thread overview]
Message-ID: <CAHp75VdAN30qE_St3d3+6uy9m0tAJErAyobMoPAnPu3Pd3MXvA@mail.gmail.com> (raw)
In-Reply-To: <20210728111701.GA894@amd>
On Wed, Jul 28, 2021 at 2:17 PM Pavel Machek <pavel@ucw.cz> wrote:
...
> > > To be honest, patches were not applied because they were not that
> > > important to begin with,
> >
> > Reference counting disbalance is not critical, but what is then?
>
> Things with end-user impact. What is end-user impact here? How much
> memory is leaked in usual config?
Not sure what "usual" means, but if the user has a device in question,
then it's struct fwnode_handle (7 pointers + u8, unpacked) per each
modprobe. Taking into account that there are usually not so many of
the same LED devices in the system and the user rarely does
rmmod/insmod cycle, I can say a few dozens of bytes.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2021-07-28 11:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-28 10:26 LED subsystem lagging maintenance Andy Shevchenko
2021-07-28 10:35 ` Pavel Machek
2021-07-28 10:44 ` Hans de Goede
2021-08-03 21:58 ` Pavel Machek
2021-08-04 7:29 ` Andy Shevchenko
2021-08-04 7:36 ` Pavel Machek
2021-07-28 11:07 ` Andy Shevchenko
2021-07-28 11:17 ` Pavel Machek
2021-07-28 11:31 ` Andy Shevchenko [this message]
2021-07-28 10:36 ` Greg Kroah-Hartman
2021-07-28 11:11 ` Andy Shevchenko
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=CAHp75VdAN30qE_St3d3+6uy9m0tAJErAyobMoPAnPu3Pd3MXvA@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@denx.de \
--cc=pavel@ucw.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.