All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: rafael@kernel.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, lukasz.luba@arm.com
Subject: Re: [PATCH v4 2/5] powercap/drivers/dtpm: Create a registering system
Date: Sun, 28 Mar 2021 13:24:51 +0200	[thread overview]
Message-ID: <YGBng8D+nPS4/LJO@kroah.com> (raw)
In-Reply-To: <7df276d1-abea-622c-2c7e-2c5e412aa4a9@linaro.org>

On Sun, Mar 28, 2021 at 01:11:30PM +0200, Daniel Lezcano wrote:
> 
> Hi Greg,
> 
> On 28/03/2021 08:50, Greg KH wrote:
> 
> [ ... ]
> 
> >>> And any reason why you are not using "real" struct devices in this
> >>> subsystem?  You seem to be rolling your own infrastructure for no good
> >>> reason.  I imagine you want sysfs support next, right?
> >>
> >> Actually, the framework is on top of powercap, so it has de facto the
> >> sysfs support. On the other side, the dtpm backends are tied with the
> >> device they manage.
> > 
> > So why are they not a "real" device in the driver model?  It looks like
> > you almost are wanting all of that functionality and are having to
> > implement it "by hand" instead.
> 
> I'm sorry I misunderstanding your point. dtpm is the backend for the
> powercap subsystem which is the generic subsystem to do power limitation.
> 
> We have:
> 
> struct dtpm_cpu {
> 	struct dtpm dtmp;
> 	...
> }
> 
> struct dtpm {
> 	struct powercap powecap;
> };
> 
> struct powercap {
> 	struct device dev;
> };

Oh nice.  So you can not use a kref here at all as you already have a
reference counted device controling your structure.  You can not have 2
references trying to control the same structure, that way lies madness
and bugs :(

So why are you trying to add a kref here as the structure already has
support for proper lifetimes?

thanks,

greg k-h

  reply	other threads:[~2021-03-28 11:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 13:04 [PATCH v4 1/5] powercap/drivers/dtpm: Encapsulate even more the code Daniel Lezcano
2021-03-12 13:04 ` [PATCH v4 2/5] powercap/drivers/dtpm: Create a registering system Daniel Lezcano
2021-03-27 12:50   ` Greg KH
2021-03-27 19:41     ` Daniel Lezcano
2021-03-28  6:50       ` Greg KH
2021-03-28 11:11         ` Daniel Lezcano
2021-03-28 11:24           ` Greg KH [this message]
2021-03-28 16:07             ` Daniel Lezcano
2021-03-28 17:26               ` Greg KH
2021-03-28 18:01                 ` Daniel Lezcano
2021-03-12 13:04 ` [PATCH v4 3/5] powercap/drivers/dtpm: Simplify the dtpm table Daniel Lezcano
2021-03-12 13:04 ` [PATCH v4 4/5] powercap/drivers/dtpm: Use container_of instead of a private data field Daniel Lezcano
2021-03-12 13:04 ` [PATCH v4 5/5] powercap/drivers/dtpm: Scale the power with the load Daniel Lezcano

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=YGBng8D+nPS4/LJO@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=rafael@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 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.