All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.