public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Darren Hart <dvhart@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Zha Qipeng <qipeng.zha@intel.com>,
	"David E . Box" <david.e.box@linux.intel.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 18/19] platform/x86: intel_pmc_ipc: Convert to MFD
Date: Wed, 26 Feb 2020 11:23:24 +0000	[thread overview]
Message-ID: <20200226112324.GL3494@dell> (raw)
In-Reply-To: <20200226103355.GO2667@lahna.fi.intel.com>

On Wed, 26 Feb 2020, Mika Westerberg wrote:

> On Wed, Feb 26, 2020 at 08:47:49AM +0000, Lee Jones wrote:
> > On Mon, 17 Feb 2020, Mika Westerberg wrote:
> > 
> > > This driver only creates a bunch of platform devices sharing resources
> > > belonging to the PMC device. This is pretty much what MFD subsystem is
> > > for so move the driver there, renaming it to intel_pmc_bxt.c which
> > > should be more clear what it is.
> > > 
> > > MFD subsystem provides nice helper APIs for subdevice creation so
> > > convert the driver to use those. Unfortunately the ACPI device includes
> > > separate resources for most of the subdevices so we cannot simply call
> > > mfd_add_devices() to create all of them but instead we need to call it
> > > separately for each device.
> > > 
> > > The new MFD driver continues to expose two sysfs attributes that allow
> > > userspace to send IPC commands to the PMC/SCU to avoid breaking any
> > > existing applications that may use these. Generally this is bad idea so
> > > document this in the ABI documentation.
> > > 
> > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > ---
> > >  .../ABI/obsolete/sysfs-driver-intel_pmc_bxt   |  22 +
> > >  arch/x86/include/asm/intel_pmc_ipc.h          |  47 --
> > >  arch/x86/include/asm/intel_telemetry.h        |   1 +
> > >  drivers/mfd/Kconfig                           |  16 +-
> > >  drivers/mfd/Makefile                          |   1 +
> > >  drivers/mfd/intel_pmc_bxt.c                   | 489 +++++++++++++
> > >  drivers/platform/x86/Kconfig                  |  16 +-
> > >  drivers/platform/x86/Makefile                 |   1 -
> > >  drivers/platform/x86/intel_pmc_ipc.c          | 645 ------------------
> > >  .../platform/x86/intel_telemetry_debugfs.c    |  12 +-
> > >  drivers/platform/x86/intel_telemetry_pltdrv.c |   2 +
> > >  drivers/usb/typec/tcpm/Kconfig                |   2 +-
> > >  include/linux/mfd/intel_pmc_bxt.h             |  21 +
> > >  13 files changed, 565 insertions(+), 710 deletions(-)
> > >  create mode 100644 Documentation/ABI/obsolete/sysfs-driver-intel_pmc_bxt
> > >  delete mode 100644 arch/x86/include/asm/intel_pmc_ipc.h
> > >  create mode 100644 drivers/mfd/intel_pmc_bxt.c
> > >  delete mode 100644 drivers/platform/x86/intel_pmc_ipc.c
> > >  create mode 100644 include/linux/mfd/intel_pmc_bxt.h
> > 
> > [...]

[...]

> > > +struct intel_pmc_dev {
> > > +	struct device *dev;
> > > +	struct intel_scu_ipc_dev *scu;
> > > +
> > > +	struct mfd_cell cells[PMC_TELEM + 1];
> > 
> > Nicer to add a "PMC_DEVICE_MAX" enum and use that.
> > 
> > Why do these even need to be in here?
> 
> They need to be here because we need to fill them in dynamically based
> on the resources we get from the ACPI device.

Why can't you do that with statically defined structs?

HINT: You can.

> > I would normally suggest creating a cell per device.
> 
> You mean 
> 
> struct intel_pmc_dev {
> 	...
> 	struct mfd_cell tco_cell;
> 	struct mfd_cell punit_cell;
> 	...
> 
> right? Sure no problem.

No.  We don't usually put them in device data at all.

I mean:

static struct mfd_cell tco_cell[] = {
        {      }
};

static struct mfd_cell tco_cell[] = {
        {      }
};

[...]

> > > +static const struct mfd_cell tco = {
> > > +	.name = TCO_DEVICE_NAME,
> > 
> > Use proper string please.
> > 
> > > +	.ignore_resource_conflicts = true,
> > 
> > Why not add tco_pdata here?
> 
> Because we need to pass it the private PMC pointer that is filled later
> on. It is being used by the iTCO_wdt .update_no_reboot_bit() callback as
> its private data.

Just drop the const.

> > > +};
> > > +
> > > +static const struct resource telem_res[] = {
> > > +	DEFINE_RES_MEM(TELEM_PUNIT_SSRAM_OFFSET, TELEM_SSRAM_SIZE),
> > > +	DEFINE_RES_MEM(TELEM_PMC_SSRAM_OFFSET, TELEM_SSRAM_SIZE),
> > > +};
> > > +
> > > +static const struct mfd_cell telem = {
> > > +	.name = TELEMETRY_DEVICE_NAME,
> > 
> > Use proper string please.
> 
> Okay.
> 
> > > +	.resources = telem_res,
> > > +	.num_resources = ARRAY_SIZE(telem_res),
> > > +};
> > > +
> > > +static int intel_pmc_get_tco_resources(struct platform_device *pdev,
> > > +				       struct intel_pmc_dev *pmc)
> > > +{
> > > +	struct itco_wdt_platform_data *pdata;
> > > +	struct resource *res, *tco_res;
> > > +
> > > +	if (acpi_has_watchdog())
> > > +		return 0;
> > > +
> > > +	res = platform_get_resource(pdev, IORESOURCE_IO,
> > > +				    PLAT_RESOURCE_ACPI_IO_INDEX);
> > > +	if (!res) {
> > > +		dev_err(&pdev->dev, "Failed to get IO resource\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	tco_res = devm_kcalloc(&pdev->dev, 2, sizeof(*tco_res), GFP_KERNEL);
> > > +	if (!tco_res)
> > > +		return -ENOMEM;
> > > +
> > > +	tco_res[0].flags = IORESOURCE_IO;
> > > +	tco_res[0].start = res->start + TCO_BASE_OFFSET;
> > > +	tco_res[0].end = tco_res[0].start + TCO_REGS_SIZE - 1;
> > > +	tco_res[1].flags = IORESOURCE_IO;
> > > +	tco_res[1].start = res->start + SMI_EN_OFFSET;
> > > +	tco_res[1].end = tco_res[1].start + SMI_EN_SIZE - 1;
> > > +
> > > +	pmc->cells[PMC_TCO].resources = tco_res;
> > > +	pmc->cells[PMC_TCO].num_resources = 2;
> > > +
> > > +	pdata = devm_kmemdup(&pdev->dev, &tco_pdata, sizeof(*pdata), GFP_KERNEL);
> > > +	if (!pdata)
> > > +		return -ENOMEM;
> > > +
> > > +	pdata->no_reboot_priv = pmc;
> > 
> > This looks hacky.  What are you doing here?
> 
> So the pmc instance is created per device as you requested. This one
> passes it to the iTCO_wdt .update_no_reboot_bit() callback which we
> implemented in this driver (sane name update_no_reboot_bit()).
> 
> The iTCO_wdt platform data can be found in this header if you want to
> take a look: include/linux/platform_data/itco_wdt.h.

We usually pass these kinds of pointers via device data, rather than
platform data.

> > > +	pmc->cells[PMC_TCO].platform_data = pdata;
> > > +	pmc->cells[PMC_TCO].pdata_size = sizeof(*pdata);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int intel_pmc_get_resources(struct platform_device *pdev,
> > > +				   struct intel_pmc_dev *pmc,
> > > +				   struct intel_scu_ipc_pdata *pdata)
> > > +{
> > > +	struct resource *res, *punit_res;
> > > +	struct resource gcr_res;
> > > +	size_t npunit_res = 0;
> > > +	int ret;
> > > +
> > > +	pdata->irq = platform_get_irq_optional(pdev, 0);
> > > +
> > > +	res = platform_get_resource(pdev, IORESOURCE_MEM,
> > > +				    PLAT_RESOURCE_IPC_INDEX);
> > > +	if (!res) {
> > > +		dev_err(&pdev->dev, "Failed to get IPC resource\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	/* IPC registers */
> > > +	pdata->mem.flags = res->flags;
> > > +	pdata->mem.start = res->start;
> > > +	pdata->mem.end = res->start + PLAT_RESOURCE_IPC_SIZE - 1;
> > 
> > Passing register addresses through pdata also looks like a hack.
> > 
> > Why not pass via resources?
> 
> It is not actual "platform data" but just a structure that we pass for
> the IPC registration function that then creates the underlying device
> for the SCU IPC using these. Since it is plain device (not struct
> platform device) it does not have the concept of "resources" such as
> platform devices have.

Calling something platform data that isn't platform data is confusing.

Why aren't you using the standard device driver model to register this
device?

[...]

> > > diff --git a/include/linux/mfd/intel_pmc_bxt.h b/include/linux/mfd/intel_pmc_bxt.h
> > > new file mode 100644
> > > index 000000000000..a5fb41910d78
> > > --- /dev/null
> > > +++ b/include/linux/mfd/intel_pmc_bxt.h
> > > @@ -0,0 +1,21 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +#ifndef MFD_INTEL_PMC_BXT_H
> > > +#define MFD_INTEL_PMC_BXT_H
> > > +
> > > +#include <linux/types.h>
> > > +
> > > +/* GCR reg offsets from GCR base */
> > > +#define PMC_GCR_PMC_CFG_REG		0x08
> > > +#define PMC_GCR_TELEM_DEEP_S0IX_REG	0x78
> > > +#define PMC_GCR_TELEM_SHLW_S0IX_REG	0x80
> > > +
> > > +/*
> > > + * Pointer to the PMC device can be obtained by calling
> > > + * dev_get_drvdata() to the parent MFD device.
> > > + */
> > > +struct intel_pmc_dev;
> > 
> > Don't you have a shared header file you can put the definition in
> > instead?
> 
> Unfortunately no. This one is the shared header.

Please consider moving the definition into here then.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-02-26 11:22 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-17 13:14 [PATCH v6 00/19] platform/x86: Rework intel_scu_ipc and intel_pmc_ipc drivers Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 01/19] platform/x86: intel_scu_ipc: Split out SCU IPC functionality from the SCU driver Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 02/19] platform/x86: intel_scu_ipc: Log more information if SCU IPC command fails Mika Westerberg
2020-02-17 14:08   ` Andy Shevchenko
2020-02-17 13:14 ` [PATCH v6 03/19] platform/x86: intel_scu_ipc: Move legacy SCU IPC API to a separate header Mika Westerberg
2020-02-17 14:11   ` Andy Shevchenko
2020-02-17 13:14 ` [PATCH v6 04/19] platform/x86: intel_scu_ipc: Introduce new SCU IPC API Mika Westerberg
2020-02-17 14:11   ` Andy Shevchenko
2020-02-17 13:14 ` [PATCH v6 05/19] platform/x86: intel_mid_powerbtn: Convert to use " Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 06/19] watchdog: intel-mid_wdt: " Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 07/19] platform/x86: intel_scu_ipcutil: " Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 08/19] platform/x86: intel_scu_ipc: Add managed function to register SCU IPC Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 09/19] platform/x86: intel_pmc_ipc: Start using " Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 10/19] mfd: intel_soc_pmic: Add SCU IPC member to struct intel_soc_pmic Mika Westerberg
2020-02-24 15:30   ` Lee Jones
2020-02-17 13:14 ` [PATCH v6 11/19] mfd: intel_soc_pmic_bxtwc: Convert to use new SCU IPC API Mika Westerberg
2020-02-25  9:24   ` Lee Jones
2020-02-17 13:14 ` [PATCH v6 12/19] mfd: intel_soc_pmic_mrfld: " Mika Westerberg
2020-02-26  6:45   ` Lee Jones
2020-02-17 13:14 ` [PATCH v6 13/19] platform/x86: intel_telemetry: " Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 14/19] platform/x86: intel_pmc_ipc: Drop intel_pmc_ipc_command() Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 15/19] x86/platform/intel-mid: Add empty stubs for intel_scu_devices_[create|destroy]() Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 16/19] platform/x86: intel_pmc_ipc: Move PCI IDs to intel_scu_pcidrv.c Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 17/19] platform/x86: intel_telemetry: Add telemetry_get_pltdata() Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 18/19] platform/x86: intel_pmc_ipc: Convert to MFD Mika Westerberg
2020-02-26  8:47   ` Lee Jones
2020-02-26 10:33     ` Mika Westerberg
2020-02-26 11:23       ` Lee Jones [this message]
2020-02-26 12:22         ` Mika Westerberg
2020-02-17 13:14 ` [PATCH v6 19/19] MAINTAINERS: Update entry for Intel Broxton PMC driver Mika Westerberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200226112324.GL3494@dell \
    --to=lee.jones@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=david.e.box@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mingo@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=qipeng.zha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=wim@linux-watchdog.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox