From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 0094FEB64DA
	for <linux-kernel@archiver.kernel.org>; Tue, 18 Jul 2023 14:43:33 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S233379AbjGROnc (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 18 Jul 2023 10:43:32 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59014 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S233355AbjGROn0 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 18 Jul 2023 10:43:26 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C017172A
        for <linux-kernel@vger.kernel.org>; Tue, 18 Jul 2023 07:43:25 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
         key-exchange X25519 server-signature RSA-PSS (2048 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 98E57615FB
        for <linux-kernel@vger.kernel.org>; Tue, 18 Jul 2023 14:43:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C10AC433CA;
        Tue, 18 Jul 2023 14:43:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
        s=korg; t=1689691404;
        bh=w6bVSOVVCvV+Mgr+uiH/C+j6HhM8JjZmVwgHkfRzIWA=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=R6i0a7rEZt3S1wzNlBgXdBulGDrNX1JARL5zcP3cg/fg8AqzNC6CSjpdHO6+npgS/
         HnvgS6BbAOiYABPLl90h7UIaF7nycBLTmIKhw4+hSjaDT9MXxuhiBQYoBs2Udx9sob
         cABFPM7UmpPxr86thinxvC97W4oUbpOgxaeEugAA=
Date:   Tue, 18 Jul 2023 16:43:20 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Daniel Golle <daniel@makrotopia.org>
Cc:     Miquel Raynal <miquel.raynal@bootlin.com>,
        Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] nvmem: core: clear sysfs attributes for each NVMEM
 device
Message-ID: <2023071834-sixfold-reggae-0406@gregkh>
References: <ZLaZ03PzkbPNJQ3b@makrotopia.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZLaZ03PzkbPNJQ3b@makrotopia.org>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jul 18, 2023 at 02:55:31PM +0100, Daniel Golle wrote:
> Set nvmem_cells_group.bin_attrs to NULL in case of an NVMEM device not
> having any cells in order to make sure sysfs attributes of a previously
> registered NVMEM device are not accidentally reused for a follow-up
> device which doesn't have any cells.

Wait, attributes and devices should NEVER be reused, how is that
happening here?

And just setting the attribute field to NULL doesn't free or clean up
anything, right?  Did memory just leak with this?

confused,

greg k-h