Re: [PATCH] platform/x86/amd/hsmp: switch to use device_add_groups()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, Feb 01, 2024 at 06:40:30PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Feb 01, 2024 at 04:34:30PM +0200, Ilpo Järvinen wrote:
> > On Thu, 1 Feb 2024, Greg Kroah-Hartman wrote:
> > 
> > > On Thu, Feb 01, 2024 at 06:50:33PM +0530, Hegde, Suma wrote:
> > > > On 1/29/2024 6:16 PM, Ilpo Järvinen wrote:
> > > > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > > > > 
> > > > > 
> > > > > + Cc Suma Hegde.
> > > > > 
> > > > > On Sun, 28 Jan 2024, Greg Kroah-Hartman wrote:
> > > > > 
> > > > > > The use of devm_*() functions works properly for when the device
> > > > > > structure itself is dynamic, but the hsmp driver is attempting to have a
> > > > > > local, static, struct device and then calls devm_() functions attaching
> > > > > > memory to the device that will never be freed.
> > > > > > 
> > > > > > The logic of having a static struct device is almost never a wise
> > > > > > choice, but for now, just remove the use of devm_device_add_groups() in
> > > > > > this driver as it obviously is not needed.
> > > > 
> > > > Hi Greg,
> > > > 
> > > > Could you please hold on merging this patch for a week? I will push a patch
> > > > for converting platform specific structure's memory allocation from static
> > > > to a dynamic
> > > > 
> > > > allocation.
> > > 
> > > Push it where?  Ususally we do "first patch wins" type stuff, why not
> > > just do your work on top of mine?
> > > 
> > > Also, when you do make the needed changes, please remove the explicit
> > > call to create sysfs groups and use the default groups pointer instead,
> > > that will make things much simpler and avoid races in the code.
> > 
> > Hi Greg,
> > 
> > Well, if you really want to "win" :-), please provide an updated version 
> > which considers the changes already made in the for-next branch (the 
> > current one won't apply).
> 
> It applies just fine to the latest linux-next tree, version
> -next-20240201, what tree/branch are you referring to here?

Ah platform driver tree, got it, will rebase...