On 28/03/2021 13:24, Greg KH wrote: > 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?
Right, I'll revisit that part. Thanks for the review. I've a branch which is pulled by Rafael [1]. These parts are already merged in the dtpm/next branch but not yet in Rafael's tree. I think a rebase is possible but I would like to avoid that. Would be a patch on top of the dtpm/next acceptable given your flow with Android ? -- Daniel [1] https://git.kernel.org/pub/scm/linux/kernel/git/daniel.lezcano/linux.git/log/?h=dtpm/next -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog