Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3637259pxf; Mon, 29 Mar 2021 07:34:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+kE3T3vdZPcxX00eHGGI82oZPN47HSDfsQRrkGdR9xb75Hg/uue5j7iICIpBKs+hrdTDd X-Received: by 2002:a17:906:a51:: with SMTP id x17mr28919128ejf.25.1617028491958; Mon, 29 Mar 2021 07:34:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617028491; cv=none; d=google.com; s=arc-20160816; b=ZKSP55MgL5h+NvgJrfRRsFXjlsr1Tl4lab2VSOr0QlykybqrJtg04a38UyHZjy51Kj YBWMnyp9Fg/3SAUE+2Zy+ZXQ/GTOF3V8kpnGJ2WliRok+mrKq7yUwtGRaHXOiTKtBLUR Psins4PBOsw0txCiXkSPlQu0U3cuc+J3R9jALTdqAfmm0D/zSrT2B+kgb4Nq5nyUjlEC XDxLSr45Z2Lr9qtg4JPrivkNNaYuaeKxZZlR24ZFlM6oyqkaq90pO4ZcGgne3W1IuOd+ MdqgOkdhEJkFNAYgri0/QrotMCDdruq/vHrGqnmfiZmFiLAYvIb+6Kbr0fZFddPAxWv+ QS3g== 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:subject:cc:to:from:date; bh=+XwEXhajxesnZG9Ce8x/8VGzC01yObrrTn7scfgWBg0=; b=QI/qpT7aiT8eB/3GcHzm8jYpMZm2cQMHghQycXFEIUlrHGo8BsVfa65vNk6Yi5q1AC bgvEr90crR28NIidRagDgnMNKKIG8oBcK9nueOa4MV8bZI0+ERSSsg683zcnj8hs5XSq hDqbug5Xdu8PdcO00mTm4JQmsiug0dq5OJ4UZ2hIp4Hyz/sjYjeDlvYFQJYEHc3YMSpI Tf94wA0Yazgf5Yd5TX6aqdEW993UAGezHvVo723V6RGYa9M1dCJooiHikmjkY+/b6RPx P2OqXlDplwe6/AItxTB3GCf399s82w597l1/K+i5Ev36kIizCIs8I4BPlsjDUtxvgB/i dmaQ== 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pk25si13244885ejb.402.2021.03.29.07.34.28; Mon, 29 Mar 2021 07:34:51 -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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229955AbhC2ObJ (ORCPT + 99 others); Mon, 29 Mar 2021 10:31:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:39280 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229822AbhC2Oan (ORCPT ); Mon, 29 Mar 2021 10:30:43 -0400 Received: from jic23-huawei (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C29EB61933; Mon, 29 Mar 2021 14:30:39 +0000 (UTC) Date: Mon, 29 Mar 2021 15:30:47 +0100 From: Jonathan Cameron To: Alexandru Ardelean Cc: platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, coproscefalo@gmail.com, hdegoede@redhat.com, mgross@linux.intel.com, linux@deviqon.com Subject: Re: [PATCH 01/10] platform/x86: toshiba_acpi: bind life-time of toshiba_acpi_dev to parent Message-ID: <20210329153047.57904ab4@jic23-huawei> In-Reply-To: <20210324125548.45983-2-aardelean@deviqon.com> References: <20210324125548.45983-1-aardelean@deviqon.com> <20210324125548.45983-2-aardelean@deviqon.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Mar 2021 14:55:39 +0200 Alexandru Ardelean wrote: > The 'toshiba_acpi_dev' object is allocated first and free'd last. We can > bind it's life-time to the parent ACPI device object. This is a first step > in using more device-managed allocated functions for this. > > The main intent is to try to convert the IIO framework to export only > device-managed functions (i.e. devm_iio_device_alloc() and > devm_iio_device_register()). It's still not 100% sure that this is > possible, but for now, this is the process of taking it slowly in that > direction. > > Signed-off-by: Alexandru Ardelean Might just be me, but naming anything dev that isn't a struct device * is downright confusing? > --- > drivers/platform/x86/toshiba_acpi.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c > index fa7232ad8c39..6d298810b7bf 100644 > --- a/drivers/platform/x86/toshiba_acpi.c > +++ b/drivers/platform/x86/toshiba_acpi.c > @@ -2998,8 +2998,6 @@ static int toshiba_acpi_remove(struct acpi_device *acpi_dev) > if (toshiba_acpi) > toshiba_acpi = NULL; > > - kfree(dev); > - > return 0; > } > > @@ -3016,6 +3014,7 @@ static const char *find_hci_method(acpi_handle handle) > > static int toshiba_acpi_add(struct acpi_device *acpi_dev) > { > + struct device *parent = &acpi_dev->dev; > struct toshiba_acpi_dev *dev; > const char *hci_method; > u32 dummy; > @@ -3033,7 +3032,7 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) > return -ENODEV; > } > > - dev = kzalloc(sizeof(*dev), GFP_KERNEL); > + dev = devm_kzalloc(parent, sizeof(*dev), GFP_KERNEL); > if (!dev) > return -ENOMEM; > dev->acpi_dev = acpi_dev; > @@ -3045,7 +3044,6 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) > ret = misc_register(&dev->miscdev); > if (ret) { > pr_err("Failed to register miscdevice\n"); > - kfree(dev); > return ret; > } >