Return-Path: 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 B6592C64ED6 for ; Tue, 21 Feb 2023 12:17:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234150AbjBUMRs (ORCPT ); Tue, 21 Feb 2023 07:17:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234299AbjBUMRq (ORCPT ); Tue, 21 Feb 2023 07:17:46 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C16429E32; Tue, 21 Feb 2023 04:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676981830; x=1708517830; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=uzVFzirXSv25kiPnI1/UuQaCx9NtBbad4el4UtQ8pe0=; b=nNgqwfG71vygG0xR+spoLVmsHWlB17enGDm6wnZdvPJHxTE+Ti7i7zjh 1/suefmJ9z+XRW2m+cWYtNgpBDy1k7f1d73uNndXyIKpb+fX1fEc79GmJ Zri72FeIDqZQ7tBqtT2t997Vvr/99+ClP2FDH3es5dCh7W0XSGvEcL0dm rD+UW5y1boQ7Y+d/IHVO7V6x/WhHYcW5jWpcsbIe7w7afb0sKGcySuu4S 1KL6ZUwrhxP0bwypYqaiE0rhalrfdPNKIL7EnXpv8K9lTQKXDHjkBLRU1 iS761+5TLLqydDRCQD8x9w1/ca37rHomvOz4B+Gcc3076aE4dyGI2OceH Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10627"; a="331281052" X-IronPort-AV: E=Sophos;i="5.97,315,1669104000"; d="scan'208";a="331281052" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2023 04:13:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10627"; a="664957815" X-IronPort-AV: E=Sophos;i="5.97,315,1669104000"; d="scan'208";a="664957815" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 21 Feb 2023 04:13:52 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pURWo-009wk6-2R; Tue, 21 Feb 2023 14:13:50 +0200 Date: Tue, 21 Feb 2023 14:13:50 +0200 From: Andy Shevchenko To: Okan Sahin Cc: Lee Jones , Rob Herring , Krzysztof Kozlowski , Liam Girdwood , Mark Brown , Jonathan Cameron , Lars-Peter Clausen , Geert Uytterhoeven , ChiYuan Huang , Lad Prabhakar , William Breathitt Gray , Ramona Bolboaca , Caleb Connolly , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org Subject: Re: [PATCH v5 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support Message-ID: References: <20230221103926.49597-1-okan.sahin@analog.com> <20230221103926.49597-6-okan.sahin@analog.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230221103926.49597-6-okan.sahin@analog.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 21, 2023 at 01:39:13PM +0300, Okan Sahin wrote: > MFD driver for MAX77541/MAX77540 to enable its sub > devices. > > The MAX77541 is a multi-function devices. It includes > buck converter and ADC. > > The MAX77540 is a high-efficiency buck converter > with two 3A switching phases. > > They have same regmap except for ADC part of MAX77541. Extra space in the Subject. ... > +#include Why? ... > +static const struct regmap_config max77541_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, Do you need lock of regmap? > +}; ... > +static const struct mfd_cell max77540_devs[] = { > + MFD_CELL_OF("max77540-regulator", NULL, NULL, 0, 0, > + NULL), Perfectly one line. > +}; > +static const struct mfd_cell max77541_devs[] = { > + MFD_CELL_OF("max77541-regulator", NULL, NULL, 0, 0, > + NULL), > + MFD_CELL_OF("max77541-adc", NULL, NULL, 0, 0, > + NULL), Ditto. > +}; ... > + if (max77541->chip->id == MAX77541) { > + ret = devm_regmap_add_irq_chip(dev, max77541->regmap, irq, > + IRQF_ONESHOT | IRQF_SHARED, 0, > + &max77541_adc_irq_chip, > + &max77541->irq_adc); > + if (ret) > + return ret; > + } > + return ret; return 0; ... > +static const struct i2c_device_id max77541_i2c_id[]; What for? ... > + if (dev->of_node) > + max77541->chip = of_device_get_match_data(dev); > + else > + max77541->chip = (struct chip_info *) > + i2c_match_id(max77541_i2c_id, > + client)->driver_data; Oh. Please use const struct i2c_device_id *id = i2c_client_get_device_id(client); ... max77541->chip = device_get_match_data(dev); // needs property.h if (!max77541->chip) max77541->chip = (struct chip_info *)id->driver_data; > + if (!max77541->chip) > + return -EINVAL; ... > +#ifndef __MAX77541_MFD_H__ > +#define __MAX77541_MFD_H__ Can we go towards consistency in this? Seems to me the most used patter so far is #ifndef __LINUX_MFD_MAX77541_H -- With Best Regards, Andy Shevchenko