Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4966739rwb; Sun, 13 Nov 2022 18:22:31 -0800 (PST) X-Google-Smtp-Source: AA0mqf5tz1z9FR8QwixijAI9UHce8dSo3S0a/hi08JSmo684lHMH2ic9EYfHTNpju8RJQhUYBVmv X-Received: by 2002:aa7:8813:0:b0:56b:f64b:b385 with SMTP id c19-20020aa78813000000b0056bf64bb385mr11860108pfo.68.1668392551689; Sun, 13 Nov 2022 18:22:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668392551; cv=none; d=google.com; s=arc-20160816; b=c+PPf9DFTpATA1ptmR+y9F6s0cTJummKsGqaVV9Aqlx21U0OG0QAppW2iJpgvFBIwH bQLot7j/UxfY1XOpUOMa00tiO+55CJMY5lmcym1Pu3c86OOKvv8DVApSWfnu/oT0loXd 8oI+UwMtC1pgp9XNpLOTddeGjlzDLOLOvFt5tspfPKV9TnqC8xNqZybqUIFa9674UYVL 1QInrZ9XfUiNkZh/B7Ec2rNZkDgvytanQKHFJAsZQyTnEGwPV9a9bZ1vTuPKJcJ5TgoY +0KEkJu+MyHKtPBghvC5fBpNf3rnBDyBbwtvII8Shg4Cf0qQH9AUKjRD4n1auWgypObR RAZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=qDwtSaTwD18UB/Z3hOSqJk3tJWRG3AhuKhyMNPIAzRA=; b=HtMcUs19nq0fx46Sjh9RtqxdK4FwHGJBlEvh3judKS3z35cmJG1C8C6wOKrrdpo5BW NlVyB8kr/1FP3lB3d1yMaZZg6smCio/H9rjJd4kxhdxjlb4TYYfPukiLfEMXyA2ZRlMN 3C64DiAEhEBffvHpDWN4tRILGt/n04gYM0Ban1Yzck8ya0cahDoT8mKwt7YUKvT7KG57 PUzoVIsIrCS6F/BXGIEPZSgaQ7qoqoc9t+r4FbVLreaDVGB73bcc3x6YWpGb4nKbvy+4 KCDD5TCYacTrcY6yxa8l4QFWZ8SGw4nAfvAqcExD8wtERKpR5Z8WjdodFakS7fImE9XX sdzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kqNqfXo1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c3-20020a056a000ac300b00565cb1ebdbcsi9188419pfl.277.2022.11.13.18.22.19; Sun, 13 Nov 2022 18:22:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kqNqfXo1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235589AbiKNCIY (ORCPT + 90 others); Sun, 13 Nov 2022 21:08:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229692AbiKNCIV (ORCPT ); Sun, 13 Nov 2022 21:08:21 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CDEAE00B; Sun, 13 Nov 2022 18:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668391700; x=1699927700; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=NKqfqlFULkV8Q2z4VRHX+tuirm9OvbwAxEukolp0ARU=; b=kqNqfXo19VCPZJRNbzF0s2nVgZAw10WsiJIZ1AP2awyIQ5WqAYsECEBv ov3wBs/XzY1AbWLZ6pfpuDosD+6tJjUybU0xYQArCCpPpXG/f9EZxrnvs QPdMb4q6ZKvtoxxoPnw0vCfSLezRufb9bB2lqVpo7mvrntYcnH/VRYFXh lDt9w6SRNHoINQyCRDmEyC0bFGmDRqY80F3LXI+TpLskPaNAAA+XZhksl OKjNpOccqJxXDrDInfVoTGoa3w7jHZHODAYdjzR9Plp+k9t+z7owDkEEZ 6vp/7wb1tJtIWiWhI5v7RX3Fcqr3I5ibpx5hGllERunUbGZtb5OFrRy3h g==; X-IronPort-AV: E=McAfee;i="6500,9779,10530"; a="338645836" X-IronPort-AV: E=Sophos;i="5.96,161,1665471600"; d="scan'208";a="338645836" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2022 18:08:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10530"; a="671380952" X-IronPort-AV: E=Sophos;i="5.96,161,1665471600"; d="scan'208";a="671380952" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.165]) by orsmga001.jf.intel.com with ESMTP; 13 Nov 2022 18:08:14 -0800 Date: Mon, 14 Nov 2022 09:58:51 +0800 From: Xu Yilun To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: linux-fpga@vger.kernel.org, Wu Hao , Tom Rix , Moritz Fischer , Lee Jones , Matthew Gerlach , Russ Weight , Tianfei zhang , Mark Brown , Greg KH , LKML Subject: Re: [PATCH 02/12] mfd: intel-m10-bmc: Create m10bmc_platform_info for type specific info Message-ID: References: <20221108144305.45424-1-ilpo.jarvinen@linux.intel.com> <20221108144305.45424-3-ilpo.jarvinen@linux.intel.com> <752a1dc-fae6-4431-41cf-a6deaf157ad3@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <752a1dc-fae6-4431-41cf-a6deaf157ad3@linux.intel.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-11-11 at 13:49:38 +0200, Ilpo J?rvinen wrote: > On Fri, 11 Nov 2022, Xu Yilun wrote: > > > On 2022-11-08 at 16:42:55 +0200, Ilpo J?rvinen wrote: > > > BMC type specific info is currently set by a switch/case block. The > > > size of this info is expected to grow as more dev types and features > > > are added which would have made the switch block bloaty. > > > > > > Store type specific info into struct and place them into .driver_data > > > instead because it makes things a bit cleaner. > > > > > > Reviewed-by: Russ Weight > > > Signed-off-by: Ilpo J?rvinen > > > --- > > > drivers/mfd/intel-m10-bmc.c | 50 +++++++++++++++++-------------- > > > include/linux/mfd/intel-m10-bmc.h | 14 +++++++++ > > > 2 files changed, 41 insertions(+), 23 deletions(-) > > > > > > diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c > > > index ee167c5dcd29..762808906380 100644 > > > --- a/drivers/mfd/intel-m10-bmc.c > > > +++ b/drivers/mfd/intel-m10-bmc.c > > > @@ -156,15 +156,17 @@ static int check_m10bmc_version(struct intel_m10bmc *ddata) > > > static int intel_m10_bmc_spi_probe(struct spi_device *spi) > > > { > > > const struct spi_device_id *id = spi_get_device_id(spi); > > > + const struct intel_m10bmc_platform_info *info; > > > struct device *dev = &spi->dev; > > > - struct mfd_cell *cells; > > > struct intel_m10bmc *ddata; > > > - int ret, n_cell; > > > + int ret; > > > > > > ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL); > > > if (!ddata) > > > return -ENOMEM; > > > > > > + info = (struct intel_m10bmc_platform_info *)id->driver_data; > > > + ddata->info = info; > > > > Where to use the ddata->info? > > In patch 5/12 there are many these constructs: > const struct m10bmc_csr_map *csr_map = sec->m10bmc->info->csr_map; > > Now that I look though, this particular line is altered by the split patch > 4/12 so it would be not strictly necessary to do it here. I'd prefer, > however, still to add it here even if it's technically not used until > after the split 5/12 patch because it very much logically belongs to this > change. It's good to me. > > > > ddata->dev = dev; > > > > > > ddata->regmap = > > > @@ -183,24 +185,8 @@ static int intel_m10_bmc_spi_probe(struct spi_device *spi) > > > return ret; > > > } > > > > > > - switch (id->driver_data) { > > > - case M10_N3000: > > > - cells = m10bmc_pacn3000_subdevs; > > > - n_cell = ARRAY_SIZE(m10bmc_pacn3000_subdevs); > > > - break; > > > - case M10_D5005: > > > - cells = m10bmc_d5005_subdevs; > > > - n_cell = ARRAY_SIZE(m10bmc_d5005_subdevs); > > > - break; > > > - case M10_N5010: > > > - cells = m10bmc_n5010_subdevs; > > > - n_cell = ARRAY_SIZE(m10bmc_n5010_subdevs); > > > - break; > > > - default: > > > - return -ENODEV; > > > - } > > > - > > > - ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cells, n_cell, > > > + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, > > > + info->cells, info->n_cells, > > > NULL, 0, NULL); > > > if (ret) > > > dev_err(dev, "Failed to register sub-devices: %d\n", ret); > > > @@ -208,10 +194,28 @@ static int intel_m10_bmc_spi_probe(struct spi_device *spi) > > > return ret; > > > } > > > > > > +static const struct intel_m10bmc_platform_info m10bmc_m10_n3000 = { > > > + .type = M10_N3000, > > > > Is the type enum still useful? Found no usage. > > There's no use within context of this patch series. However, I think there > might have been something depending on it in the changes that are not part > of this series so I left it in place for now. I'm not sure how it would be used later. This patch is to eliminate the "switch (board type) case" block, but similar code is still to be added later? Thanks, Yilun