linux-kernel - Re: [PATCH v7 00/19] platform/x86: Rework intel_scu_ipc and intel_pmc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 2 Mar 2020 17:42:05 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Darren Hart <dvhart@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Zha Qipeng <qipeng.zha@...el.com>,
        "David E . Box" <david.e.box@...ux.intel.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 00/19] platform/x86: Rework intel_scu_ipc and
 intel_pmc_ipc drivers

On Mon, Mar 02, 2020 at 03:19:24PM +0000, Lee Jones wrote:
> On Mon, 02 Mar 2020, Mika Westerberg wrote:
> > On Mon, Mar 02, 2020 at 02:26:21PM +0000, Lee Jones wrote:
> > > On Mon, 02 Mar 2020, Mika Westerberg wrote:

> > > > Currently both intel_scu_ipc.c and intel_pmc_ipc.c implement the same SCU
> > > > IPC communications with minor differences. This duplication does not make
> > > > much sense so this series reworks the two drivers so that there is only a
> > > > single implementation of the SCU IPC. In addition to that the API will be
> > > > updated to take SCU instance pointer as an argument, and most of the
> > > > callers will be converted to this new API. The old API is left there but
> > > > the plan is to get rid the callers and then the old API as well (this is
> > > > something we are working with Andy Shevchenko).
> > > > 
> > > > The intel_pmc_ipc.c is then moved under MFD which suits better for this
> > > > kind of a driver that pretty much sets up the SCU IPC and then creates a
> > > > bunch of platform devices for the things sitting behind the PMC. The driver
> > > > is renamed to intel_pmc_bxt.c which should follow the existing conventions
> > > > under drivers/mfd (and it is only meant for Intel Broxton derivatives).
> > > > 
> > > > This is on top of platform-driver-x86.git/for-next branch because there is
> > > > already some cleanup work queued that re-organizes Kconfig and Makefile
> > > > entries.
> > > > 
> > > > I have tested this on Intel Joule (Broxton-M) board.
> > > > 
> > > > Changes from v6:
> > > > 
> > > >   * Added Reviewed-by tag from Andy
> > > >   * Expanded PMC, IPC and IA acronyms
> > > >   * Drop TCO_DEVICE_NAME, PUNIT_DEVICE_NAME and TELEMETRY_DEVICE_NAME
> > > >   * Move struct intel_pmc_dev into include/linux/mfd/intel_pmc_bxt.h
> > > >   * Add PMC_DEVICE_MAX to the enum and use it
> > > >   * Add kernel-docs for simplecmd_store() and northpeak_store()
> > > >   * Use if (ret) return ret; over the ternary operator
> > > >   * Drop "This is index X" from comments
> > > >   * Use acpi_has_watchdog() to determine whether iTCO_wdt is added or not.
> > > >   * Rename intel_scu_ipc_pdata -> intel_scu_ipc_data to make it less
> > > >     confusing wrt. platform data for platform drivers.
> > > 
> > > Any reason why you've dropped all my tags?
> > 
> > You mean these?
> > 
> > For my own reference:
> >   Acked-for-MFD-by: Lee Jones <lee.jones@...aro.org>
> > 
> > I wasn't really sure what to do with them. They are not in the normal
> > tag format I've seen so I thought you use them yourself somehow to
> > manage your mailboxes. I can add them back if needed.
> 
> Yes, please add them, so I can track them.
> 
> It normally means that I plan to take the set through MFD and
> subsequently send an immutable pull-request out to the other
> Maintainers once all the other Acks have been provided.
> 
> MFD handles these kinds of cross-subsystem patch-sets often.

This series has dependencies to PDx86 (as mentioned in cover letter).

What do you prefer then, me to:
a) prepare ib from what I have, then you take it followed by me taking your ib, or
b) take everything and prepare ib for you?

-- 
With Best Regards,
Andy Shevchenko