Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2284217ybt; Tue, 16 Jun 2020 01:52:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyVkMGvwjWDqI4aGBNggPy9x7NjtbnuhldDMAf5M23/RzUgA6OSIYy2t4f3+sCNKupRJXWH X-Received: by 2002:a50:da83:: with SMTP id q3mr1621165edj.325.1592297548274; Tue, 16 Jun 2020 01:52:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592297548; cv=none; d=google.com; s=arc-20160816; b=DWAiAjDL9hAfKtUzIAtkpeXrEJPfBE9C4//Q6AIsIRgBkxrkY81iVb4fjHyT8JOQIC Hrhr8Nc/kbeorzy/cdTH88/6na27VSbjIYg6SYWdvWQMgRNormyKSIXYzO8V3az4Ygu4 r7iaM0Jg6gwYDi3SSKcWDlFOGg2Sg5zgqpBA3C/hrarqm0eUfXa+oHnyqxbAux/xIt0z FZW08S9MEZzBub4kW1XVeUXUe8m8DgBBSRtMYcn81PMyYRz9x8oZcmQxo5E1dOsYx9Vm rWLVXTX6OqHU6xQOK7s0t/O6iv93PGT+wVvohjFImr2COTxBYtuIy+CARGno3pQ2ZWs3 XmPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=y6iVAoQYhB4s4KWOwHCHVro9m7K4E8yWrvdpHQHxqtA=; b=e/aQJrY7mL1faBuCX9Fq7XeDAdl+jzZbAsrxin8lL7dyVI7ZTtTZGMWboCey6PpBz8 j+JSWjcYj5EZ0Z+Hbb9arY3vLdqkYly/q1U8MP5Dfk4WTzrx4U04Ma4IiLEDClnLWZxw OPo3+nVAeUyvICYj127/n/mpjC7xzFaxjMofoZZNi9nL3f7zRprAZWsJw0fWGcRPe/GT OKH31P63cZzwT0AAqBgfIhUNHA9SoMKfsN37H0gnU/DnYWcN8byDeOYeY/CcvuuLRoWf SCPiSdDvZsY/TByjJWHDm57HOOP612Tz1oosG7nd3Dqg7fg8LMyCXIJl7EWkjTEnC2fM iffg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cirrus.com header.s=PODMain02222019 header.b=Yffh8200; 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=REJECT sp=REJECT dis=NONE) header.from=cirrus.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id fi13si11038609ejb.436.2020.06.16.01.52.05; Tue, 16 Jun 2020 01:52:28 -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; dkim=pass header.i=@cirrus.com header.s=PODMain02222019 header.b=Yffh8200; 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=REJECT sp=REJECT dis=NONE) header.from=cirrus.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727804AbgFPIrw (ORCPT + 99 others); Tue, 16 Jun 2020 04:47:52 -0400 Received: from mx0a-001ae601.pphosted.com ([67.231.149.25]:30774 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725710AbgFPIrv (ORCPT ); Tue, 16 Jun 2020 04:47:51 -0400 Received: from pps.filterd (m0077473.ppops.net [127.0.0.1]) by mx0a-001ae601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05G8jK72024707; Tue, 16 Jun 2020 03:47:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cirrus.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=PODMain02222019; bh=y6iVAoQYhB4s4KWOwHCHVro9m7K4E8yWrvdpHQHxqtA=; b=Yffh8200d6wzvhfNckDLknVgmVwCz84juvDOZomg1HeArtm7mxI+kzDl+yDKSTOQgr4B pEpw85y560Q/IIP+ue80z/oSK+tK2X9c6il1YIbkRYnpdS7PZRIP5YTq7gyu12rM5DvJ tTFqHtsi+vXndtnNNwY7mHiCB2sgEWt0Iqws1gWBJ72eOBuOnxUMcI0vVmGRCveaFITy XYPCxrajdCzxI6kDw1DIGUmEz8uT2XXrAyYzdHYwEHx86+JWCicCPIhSBdOvxW0EP87J zR+X0J3UlJ8leF0w1pugELONkfYOfdA54isnHj4wMhYNKxlmKlqipyNQN94S0n+8qqp2 aw== Authentication-Results: ppops.net; spf=fail smtp.mailfrom=ckeepax@opensource.cirrus.com Received: from ediex01.ad.cirrus.com ([87.246.76.36]) by mx0a-001ae601.pphosted.com with ESMTP id 31mv73m3t0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 16 Jun 2020 03:47:50 -0500 Received: from EDIEX01.ad.cirrus.com (198.61.84.80) by EDIEX01.ad.cirrus.com (198.61.84.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 16 Jun 2020 09:47:48 +0100 Received: from ediswmail.ad.cirrus.com (198.61.86.93) by EDIEX01.ad.cirrus.com (198.61.84.80) with Microsoft SMTP Server id 15.1.1913.5 via Frontend Transport; Tue, 16 Jun 2020 09:47:48 +0100 Received: from ediswmail.ad.cirrus.com (ediswmail.ad.cirrus.com [198.61.86.93]) by ediswmail.ad.cirrus.com (Postfix) with ESMTP id 1032D2C5; Tue, 16 Jun 2020 08:47:48 +0000 (UTC) Date: Tue, 16 Jun 2020 08:47:48 +0000 From: Charles Keepax To: Lee Jones CC: , Subject: Re: [PATCH v2 1/2] mfd: mfd-core: Add mechanism for removal of a subset of children Message-ID: <20200616084748.GS71940@ediswmail.ad.cirrus.com> References: <20200615150722.5249-1-ckeepax@opensource.cirrus.com> <20200616075834.GF2608702@dell> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200616075834.GF2608702@dell> User-Agent: Mutt/1.5.21 (2010-09-15) X-Proofpoint-SPF-Result: fail X-Proofpoint-SPF-Record: v=spf1 include:spf-001ae601.pphosted.com include:spf.protection.outlook.com ip4:5.172.152.52 -all X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 mlxscore=0 phishscore=0 clxscore=1015 spamscore=0 impostorscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006160063 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 16, 2020 at 08:58:34AM +0100, Lee Jones wrote: > On Mon, 15 Jun 2020, Charles Keepax wrote: > > Happy to discuss other approaches as well, but this one was quite │·················· > > appealing as it was very simple but affords quite a lot of flexibility. │·················· > > What about this? > > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c > index f5a73af60dd40..a06e0332e1e31 100644 > --- a/drivers/mfd/mfd-core.c > +++ b/drivers/mfd/mfd-core.c > @@ -283,7 +283,7 @@ int mfd_add_devices(struct device *parent, int id, > } > EXPORT_SYMBOL(mfd_add_devices); > > -static int mfd_remove_devices_fn(struct device *dev, void *data) > +static int mfd_remove_devices_fn(struct device *dev, void *level) > { > struct platform_device *pdev; > const struct mfd_cell *cell; > @@ -294,6 +294,9 @@ static int mfd_remove_devices_fn(struct device *dev, void *data) > pdev = to_platform_device(dev); > cell = mfd_get_cell(pdev); > > + if (cell->level && (!level || cell->level != *level)) > + return 0; > + > regulator_bulk_unregister_supply_alias(dev, cell->parent_supplies, > cell->num_parent_supplies); > > @@ -303,7 +306,11 @@ static int mfd_remove_devices_fn(struct device *dev, void *data) > > void mfd_remove_devices(struct device *parent) > { > + int level = MFD_DEP_LEVEL_HIGH; > + > device_for_each_child_reverse(parent, NULL, mfd_remove_devices_fn); > + device_for_each_child_reverse(parent, &level, mfd_remove_devices_fn); > } > EXPORT_SYMBOL(mfd_remove_devices); > > No need for special calls from the parent driver in this case. > > Just a requirement to set the cell's dependency level. > Apologies if I am missing something here, but this looks like a pretty challenging interface from the drivers side. Rather than just statically setting tag in the mfd_cells and separate calls to mfd_remove_devices_by_tag, such as: mfd_remove_devices_by_tag(madera->dev, MADERA_OPTIONAL_DRIVER); pm_runtime_disable(madera->dev); regulator_disable(madera->dcvdd); regulator_put(madera->dcvdd); mfd_remove_devices(madera->dev); You need to statically set the level but then also iterate through the children and update the cell level on each subsequent remove, in my case: static int arizona_set_mfd_level(struct device *dev, void *data) { struct platform_device *pdev = to_platform_device(dev); if (pdev->mfd_cell) pdev->mfd_cell->level = MFD_DEP_LEVEL_HIGH; } ... mfd_remove_devices(madera->dev); device_for_each_child(madera->dev, NULL, arizona_set_mfd_level); pm_runtime_disable(madera->dev); regulator_disable(madera->dcvdd); regulator_put(madera->dcvdd); mfd_remove_devices(madera->dev); Does this match how you would expect this to be used? I do have some concerns. The code can't use mfd_get_cell since it returns a const pointer, although the pointer in platform_device isn't const so we access that directly, could update mfd_get_cell? We also don't have access to mfd_dev_type outside of the mfd core so its hard to check we are actually setting the mfd_cell of actual MFD children, I guess just checking for mfd_cell being not NULL is good enough? Thanks, Charles