From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32BD8C11F67 for ; Tue, 29 Jun 2021 19:32:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1340761DF5 for ; Tue, 29 Jun 2021 19:32:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235198AbhF2Teb (ORCPT ); Tue, 29 Jun 2021 15:34:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:34360 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233670AbhF2Te3 (ORCPT ); Tue, 29 Jun 2021 15:34:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EB5F861DE7; Tue, 29 Jun 2021 19:31:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624995122; bh=7qlnV8Wl2x3Qvv6mjcrc1tpRP72lSFEAs94lptLsNag=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OtoOXB+ZI2h/+SJgHhKPPbLYyNLu+3r1mZ0jlff2s5A9AoMdTxn6fPhhWbOZ0rPp0 2dKDi3WiNCr6Pe+7sD7CS+x/IKX48v4o+ceYEd9ONlxoUvyawzS5YwelmiRgqHB3y2 7VQ5LrQkfVsUji2I7nDdwL0xyngSsUeAhp0DnttnMvKPo9NGGFu/zlA4g/SU5DljFV 5ZYt9sz/wVIGnx6mCmlDwdJ/xso5eExSp2xc613M2T2VxEmBpOUDJlxVecHCmEsJ5g EyF3BMnAlTr9WZiUntFPqZxaDUTj9KyuxtJ5S6LigcoB1S2qCjApxGw06nK+UUZZMH E4zkSGIxq4jxg== Date: Tue, 29 Jun 2021 21:31:56 +0200 From: Mauro Carvalho Chehab To: Mark Brown Cc: Greg Kroah-Hartman , linuxarm@huawei.com, mauro.chehab@huawei.com, Axel Lin , Lee Jones , Arnd Bergmann , Liam Girdwood , linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev Subject: Re: [PATCH v10 2/5] regulator: hi6421v600-regulator: fix platform drvdata Message-ID: <20210629213156.56e6f126@coco.lan> In-Reply-To: <20210629151101.GB4613@sirena.org.uk> References: <20210629151101.GB4613@sirena.org.uk> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-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 Em Tue, 29 Jun 2021 16:11:01 +0100 Mark Brown escreveu: > On Tue, Jun 29, 2021 at 12:31:28PM +0200, Mauro Carvalho Chehab wrote: > > > platform drvdata can't be used inside the regulator driver, > > as this is already used by the MFD and SPMI drivers. > > Can you clarify what exactly is using which platform drvdata already? > This all feels very confused and I can't tell what the problem that's > being fixed is, if it's a real issue or how this fixes it. I don't remember the dirty details anymore... It has been almost a year since when I started doing that. The SPMI controller driver left staging 8 months ago. I guess it is related with passing the parent's device to devm_regulator_register() at the hi6421v600-regulator driver: struct regulator_config config = { }; ... config.dev = pdev->dev.parent; ... rdev = devm_regulator_register(dev, &info->desc, &config); This is needed by SPMI bus and the SPMI controller in order to use the right platform data when talking to the hardware. > > drivers/misc/hi6421v600-irq.c | 9 ++-- > > drivers/regulator/hi6421v600-regulator.c | 49 +++++++++++---------- > > drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 18 +++----- > > include/linux/mfd/hi6421-spmi-pmic.h | 25 ----------- > > I'm especially nervous about the core driver still being in staging > perhaps meaning there's some issue with it doing odd and confusing > things. The only missing part in staging is the MFD driver. At the current way, it is very simple (71 lines in total): it just declares a regmap, and has a single function on it: static int hi6421_spmi_pmic_probe(struct spmi_device *pdev) { struct device *dev = &pdev->dev; int ret; struct hi6421_spmi_pmic *ddata; ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL); if (!ddata) return -ENOMEM; ddata->regmap = devm_regmap_init_spmi_ext(pdev, ®map_config); if (IS_ERR(ddata->regmap)) return PTR_ERR(ddata->regmap); ddata->dev = dev; dev_set_drvdata(&pdev->dev, ddata); ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE, hi6421v600_devs, ARRAY_SIZE(hi6421v600_devs), NULL, 0, NULL); if (ret < 0) dev_err(dev, "Failed to add child devices: %d\n", ret); return ret; } You can see the full driver's code at: https://lore.kernel.org/lkml/8d871e2ccc544d11959c16d8312dbf03dd01b1c8.1624962269.git.mchehab+huawei@kernel.org/#Z30drivers:mfd:hi6421-spmi-pmic.c I'm not aware of anything left preventing it to leave staging. Thanks, Mauro