Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4729887pxb; Tue, 2 Nov 2021 14:55:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsPb5ndNEb09j4/UolZ4BlBdN+M/BZse44oHkA0KNprOwe26HYs324DpH4h136c9prWGVH X-Received: by 2002:a92:1e11:: with SMTP id e17mr26660619ile.196.1635890109960; Tue, 02 Nov 2021 14:55:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635890109; cv=none; d=google.com; s=arc-20160816; b=LXdBXYC9Ra53Zhv9BE1GmmbrBn5wJ2qgR52ZVbfJ4w6/Qa4YvcG4bRPc8XaRuXb/P0 gBzOyxTAkz+kitE6/8JbXzBp32mRN5Hjk9z+Z6MGAF7bVNV+EJVOZg0IvQX7VZn268lm ctUS+n+UbCYh9f4dW7JBymhh/BeUr4BNsy6T9s1EK5Bp8tzq+ct4r7hcv3IHpQZSds9w OgXanVIoF5tcFk8OZ5Gxp09/FqjFDe0YshLZeH6isY0kanUobN4A/6fR5SB4jLkLvqid XLGTpvsiy2LJmVrY13k7qAKh6svGu+jvXD98+B6GhOj2v17oFgs52Mo+FLJToj0zT9Cx lOHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=2jx2UXWgxHz2TTfoTygcMNy8EX3Q9si0B5/cMys9MhE=; b=miQmpPsrZRyKCple93+HjkoAtOiTiO/8HG4Ur/PVxQ7Q9NuzvZxSdU1Z5gZkZkvH7Q 5ZTFuWIDuKLHprRHk7IxDi3ZJcDkWiNcQslKq/7SmRO9yH7I6QJjik6ugI3DfPaAKFx9 7wDpsLtY8NMYPWTus651qk2eXWeG2KU2rDnaff3GQL7wpPvUHuxbcCyA2QCNaVva0t2I RodArErCDHon9s+rSoV5fuc+2TcVBq4hvq9NNOANcjTG9z3VDv7PXqPAvTnIHrZZ30GE tzX9GegTKwuGzMpFwRKLqn2IcK0PhoaBFxTzua7L11XMSl7kfzEZvOuVyxSWaon9+AqK wIeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f2si276669jat.110.2021.11.02.14.54.57; Tue, 02 Nov 2021 14:55:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231785AbhKBV4F (ORCPT + 99 others); Tue, 2 Nov 2021 17:56:05 -0400 Received: from mga01.intel.com ([192.55.52.88]:56524 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230438AbhKBV4B (ORCPT ); Tue, 2 Nov 2021 17:56:01 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10156"; a="254993996" X-IronPort-AV: E=Sophos;i="5.87,203,1631602800"; d="scan'208";a="254993996" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2021 14:53:22 -0700 X-IronPort-AV: E=Sophos;i="5.87,203,1631602800"; d="scan'208";a="500772582" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2021 14:53:21 -0700 From: ira.weiny@intel.com To: Jonathan Corbet Cc: Ira Weiny , Dave Jiang , Greg Kroah-Hartman , Dan Williams , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH 3/3] Documentation/auxiliary_bus: Update Auxiliary device lifespan Date: Tue, 2 Nov 2021 14:53:17 -0700 Message-Id: <20211102215317.3676782-4-ira.weiny@intel.com> X-Mailer: git-send-email 2.28.0.rc0.12.gb6a658bd00c9 In-Reply-To: <20211102215317.3676782-1-ira.weiny@intel.com> References: <20211102215317.3676782-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ira Weiny It was unclear when the auxiliary device objects were to be free'ed by the parent (registering) driver. Also there are some patterns like using devm_add_action_or_reset() which are helpful to mention to those using the interface to ensure they don't double free or miss freeing the auxiliary devices. Reviewed-by: Dave Jiang Signed-off-by: Ira Weiny --- Documentation/driver-api/auxiliary_bus.rst | 32 ++++++++++++++-------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst index 41ec9aed059f..77c1a39e38d5 100644 --- a/Documentation/driver-api/auxiliary_bus.rst +++ b/Documentation/driver-api/auxiliary_bus.rst @@ -164,9 +164,15 @@ Auxiliary Device Memory Model and Lifespan ------------------------------------------ The registering driver is the entity that allocates memory for the -auxiliary_device and register it on the auxiliary bus. It is important to note +auxiliary_device and registers it on the auxiliary bus. It is important to note that, as opposed to the platform bus, the registering driver is wholly -responsible for the management for the memory used for the driver object. +responsible for the management of the memory used for the device object. + +To be clear the memory for the auxiliary_device is freed in the release() +callback defined by the registering driver. The registering driver should only +call auxiliary_device_delete() and then auxiliary_device_uninit() when it is +done with the device. The release() function is then automatically called if +and when other drivers release their reference to the devices. A parent object, defined in the shared header file, contains the auxiliary_device. It also contains a pointer to the shared object(s), which @@ -177,18 +183,22 @@ from the pointer to the auxiliary_device, that is passed during the call to the auxiliary_driver's probe function, up to the parent object, and then have access to the shared object(s). -The memory for the auxiliary_device is freed only in its release() callback -flow as defined by its registering driver. - The memory for the shared object(s) must have a lifespan equal to, or greater -than, the lifespan of the memory for the auxiliary_device. The auxiliary_driver -should only consider that this shared object is valid as long as the -auxiliary_device is still registered on the auxiliary bus. It is up to the -registering driver to manage (e.g. free or keep available) the memory for the -shared object beyond the life of the auxiliary_device. +than, the lifespan of the memory for the auxiliary_device. The +auxiliary_driver should only consider that the shared object is valid as long +as the auxiliary_device is still registered on the auxiliary bus. It is up to +the registering driver to manage (e.g. free or keep available) the memory for +the shared object beyond the life of the auxiliary_device. The registering driver must unregister all auxiliary devices before its own -driver.remove() is completed. +driver.remove() is completed. An easy way to ensure this is to use the +devm_add_action_or_reset() call to register a function against the parent device +which unregisters the auxiliary device object(s). + +Finally, any operations which operate on the auxiliary devices must continue to +function (if only to return an error) after the registering driver unregisters +the auxiliary device. + Auxiliary Drivers ================= -- 2.28.0.rc0.12.gb6a658bd00c9