Received: by 10.223.176.46 with SMTP id f43csp880095wra; Fri, 26 Jan 2018 08:19:03 -0800 (PST) X-Google-Smtp-Source: AH8x227z4J0GpCPipoa3Tn4L/U3TSCg1P7cO7y/VSo0CaTJimtFl+4pSMwX/cIgQVufnOAZnR9as X-Received: by 10.99.179.77 with SMTP id x13mr14547869pgt.135.1516983543392; Fri, 26 Jan 2018 08:19:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516983543; cv=none; d=google.com; s=arc-20160816; b=J57CN9MT72DX7PTCtzcGqTkYtuWFhXj31j/0Au6pGrhvcgbycLZtgUkEs8sR09eOHZ NClTXZb2XSWxLUrqaS5SVe72YCQfK9mQS1qIWdgZcP9S5Xx8o1UPiBCESTB7mEfAGtWS O7wVRKFd6FCUS2RKxtYVOtV+Z50vQ3vV651Ufp+OSjN/nG/WdqRYwcaWwgR/yCiP5/OQ JJJVSIGa8qPta/zwNRNKvEzPYuu4H3b0mFJSzca1k/JyUOcEqfbNm19PorugGHgeJ56W vqWLCJtjxcQLJhqJJLKqlbL9naGQJ3lSXs2/K983T19yBux48kVutl8dFKtgIyAgKbyN wciQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=7RajqD28Lz/ymAqMkWmmcm7TeWxS2mgyzQqvX1A4fzc=; b=jO4z8+TfU9p7guJNsQWHipF2r7goCzCoQsW93ZT1OumwX3wVKKHfnQZnrCnAEqAGls N6sTKF/ixE6aPWfDho3MtAPOWTrWIIhaD6pzWBgfNANX1SUuPGXkCdRR/gpOWKVVtgmL qhpjaEds0iabpOkg0CrUldqctK7wzkGpSxLCX/lJKbhpERINveaceGp6/M0bVhzrZpZW +1vY/39AWwznuIvaLEdLP0s5PblVb2Bblhleam5Kf5F61bpLlZgg0eyRPHVN3f9E9sTT cfjBw2a0UYmRHvTMp8D9zb/h0z0JVe4+djl615zBjCmpM85Upch/9hGwcbg8kgK/MtNY AiOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rI5fumva; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w86si6567068pfa.304.2018.01.26.08.18.49; Fri, 26 Jan 2018 08:19:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rI5fumva; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932102AbeAZQRU (ORCPT + 99 others); Fri, 26 Jan 2018 11:17:20 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:45674 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751676AbeAZQRS (ORCPT ); Fri, 26 Jan 2018 11:17:18 -0500 Received: by mail-qt0-f193.google.com with SMTP id x27so2505213qtm.12; Fri, 26 Jan 2018 08:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7RajqD28Lz/ymAqMkWmmcm7TeWxS2mgyzQqvX1A4fzc=; b=rI5fumvagnCFJLGojVfimV+d/sbnFck+NnfsfVEee6ICtuQaHVOb+C/8jtzSFxpbi+ 8/Xm0Z7lyVAsIIeA17HJs/Kw1b+VS0eKT82VTD/Oc1K9LgJaB5EtqoVkgoGRuAFmmkVN lSP5Q2Yr+hKFaVmniil4WnrdUzc276WyABmzoE90z4yLhQ3JRb5U9CHOaYH64Jr+QegS iofp0UjCNrnE2yrvjUdC4d5TaQHD22zSBJQ8RzMmoT7U1vhSzNDmw0g8q/7epPsqyMVd LrOUfkZWpUMmNEaV6Whe0HPIEFI9eZXVHMuTKTAOXKbyEceoB63Wlp7OCX5obir1b8x1 6iPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7RajqD28Lz/ymAqMkWmmcm7TeWxS2mgyzQqvX1A4fzc=; b=i6oeGqqCdFSeqrgWYKZRXNv81tjAH4og3HEF6kpRAvAt34qIEjJD8hiKlFdRMi5jYU 6GSZ0Tv8jXQ6AXFmR7mDvcm21U/oVhOsGyl9kV9GZRbx89/dI20O/AdH8a5IFOePX7xn Gae7zo8WOWXfgmXI9fTkZ4c+hAa4MEbz6uV/fdly5RHUGoIQ8UD6b2rmzNzZjiHqZ+gL XDc9xA8kYrzdu8VE+XlLYF/9DiuNUZPRLMMFUVssrN8mksUwnAfFfojd5psROvpwa7Kq IhGZ66R501PTF3ECrcFIEhQrfYaWilfOTSqEHkbWAqw9WiO7HhfSbIacewNf7RgFKO5+ BysQ== X-Gm-Message-State: AKwxyte5cxyOVPUo8QOIH33ZTs+6LNn3VczJi8LK4FbXdgx4FsmbAiWw Q1yCrYJDfWaf3/sHvXDYye6UBoHjz8iUEr/ocII= X-Received: by 10.55.185.134 with SMTP id j128mr17833370qkf.341.1516983437984; Fri, 26 Jan 2018 08:17:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.175.35 with HTTP; Fri, 26 Jan 2018 08:17:17 -0800 (PST) In-Reply-To: References: From: Andy Shevchenko Date: Fri, 26 Jan 2018 18:17:17 +0200 Message-ID: Subject: Re: [PATCH v1 1/2] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices To: Kuppuswamy Sathyanarayanan Cc: Darren Hart , Andy Shevchenko , Zha Qipeng , "Krogerus, Heikki" , Linux Kernel Mailing List , Platform Driver , Sathyanarayanan Kuppuswamy Natarajan , Andy Shevchenko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 26, 2018 at 12:53 AM, wrote: > From: Kuppuswamy Sathyanarayanan > > Currently, we have lot of repetitive code in dependent device resource > allocation and device creation handling code. This logic can be improved if > we use MFD framework for dependent device creation. This patch adds this > support. Thanks for an update. My comments below. > Signed-off-by: Kuppuswamy Sathyanarayanan > Signed-off-by: Andy Shevchenko First of all, I barely remember what I did to this patch. In any case this one is redundant since it will have mine when I push it to our repo. > @@ -508,7 +492,7 @@ static int ipc_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) > ret = devm_request_irq(&pdev->dev, pdev->irq, ioc, 0, "intel_pmc_ipc", > pmc); > if (ret) { > - dev_err(&pdev->dev, "Failed to request irq\n"); > + dev_err(&pdev->dev, "Failed to request IRQ\n"); > return ret; > } Split this kind of changes in a separate patch. > +static int ipc_create_punit_device(struct platform_device *pdev) > { > + static struct resource punit_res[PLAT_RESOURCE_MEM_MAX_INDEX]; > + static struct mfd_cell punit_cell; > + struct resource *res; > + int ret, mindex, pindex = 0; > + > + for (mindex = 0; mindex <= PLAT_RESOURCE_MEM_MAX_INDEX; mindex++) { '<=' ??? (Why = is here?) > + res = platform_get_resource(pdev, IORESOURCE_MEM, mindex); > + > + switch (mindex) { > + /* Get PUNIT resources */ > + case PLAT_RESOURCE_BIOS_DATA_INDEX: > + case PLAT_RESOURCE_BIOS_IFACE_INDEX: > + /* BIOS resources are required, so return error if not > + * available > + */ It's not the network subsystem, please, do a proper style for multi-line comments. > + if (!res) { Would the following work for you? if (res) break; dev_err(&pdev->dev, "Failed to get PUNIT MEM resource %d\n", pindex); return -ENXIO; case ...: ... if (res) break; default: continue; memcpy(...); ... > + dev_err(&pdev->dev, > + "Failed to get PUNIT MEM resource %d\n", > + pindex); > + return -ENXIO; > + } > + case PLAT_RESOURCE_ISP_DATA_INDEX: > + case PLAT_RESOURCE_ISP_IFACE_INDEX: > + case PLAT_RESOURCE_GTD_DATA_INDEX: > + case PLAT_RESOURCE_GTD_IFACE_INDEX: > + /* if valid resource found, copy the resource to PUNIT > + * resource > + */ > + if (res) > + memcpy(&punit_res[pindex], res, sizeof(*res)); > + punit_res[pindex].flags = IORESOURCE_MEM; > + pindex++; > + break; > }; > + } > + ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE, &punit_cell, > + 1, NULL, 0, NULL); > > + dev_dbg(&pdev->dev, "Successfully created PUNIT device\n"); > Wrong. If ret is not 0 the message is misleading. Just remove it. Same for the rest cases. > + return ret; > } > +static int ipc_create_wdt_device(struct platform_device *pdev) > { > + static struct resource wdt_ipc_res[2]; > + static struct mfd_cell wdt_cell; > struct resource *res; > + int ret; > > + /* If we have ACPI based watchdog use that instead, othewise create > + * a MFD cell for iTCO watchdog > + */ Style. > + if (acpi_has_watchdog()) > + return 0; > + ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE, &wdt_cell, > + 1, NULL, 0, NULL); > + > + dev_dbg(&pdev->dev, "Successfully created watchdog device\n"); > + > + return ret; What Heikki meant is to fill cells by those helper functions and call mfd_add_devices() only once. See lpc_ich.c as an example. > } > +static int ipc_create_pmc_devices(struct platform_device *pdev) > { > int ret; > > + ret = ipc_create_punit_device(pdev); > + if (ret < 0) > + return ret; Is it fatal? (Hint: it's quite likely not) > + ret = ipc_create_wdt_device(pdev); > + if (ret < 0) > + return ret; Is it fatal? > + ret = ipc_create_telemetry_device(pdev); > + if (ret < 0) > + return ret; Is it fatal? > + return 0; > } > + ret = devm_request_irq(&pdev->dev, ipcdev.irq, ioc, IRQF_NO_SUSPEND, > + "intel_pmc_ipc", &ipcdev); > + if (ret) { > + dev_err(&pdev->dev, "Failed to request IRQ\n"); > + return ret; > } > > ret = sysfs_create_group(&pdev->dev.kobj, &intel_ipc_group); > if (ret) { > dev_err(&pdev->dev, "Failed to create sysfs group %d\n", > ret); > - goto err_sys; > + devm_free_irq(&pdev->dev, ipcdev.irq, &ipcdev); Why do you need this one? > + return ret; > } > > ipcdev.has_gcr_regs = true; > > return 0; > } And to the main question, what this is doing in PDx86 now? There should be a patch to move it under drivers/mfd. In _any case_ I need an Ack from Lee. -- With Best Regards, Andy Shevchenko