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  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:   Thu, 23 Nov 2017 15:56:06 +0200
From:   Heikki Krogerus <>
Subject: Re: [RFC v8 0/7] SCU/PMC/PUNIT Inter-Processor Communication(IPC)
 driver cleanup


On Sun, Oct 29, 2017 at 02:49:53AM -0700, wrote:
> Currently intel_pmc_ipc.c, intel_punit_ipc.c, intel_scu_ipc.c drivers
> implements the same IPC features. This code duplication could be avoided if we
> implement the IPC driver as a generic library and let custom device drivers
> use API provided by generic driver. This patchset mainly addresses this issue.
> Along with above code duplication issue, This patchset also addresses
> following issues in intel_pmc_ipc and intel_punit_ipc drivers.
> 1. Intel_pmc_ipc.c driver does not use any resource managed (devm_*) calls.
> 2. In Intel_pmc_ipc.c driver, dependent devices like PUNIT, Telemetry and iTCO
> are created manually and uses lot of redundant buffer code.
> 3. Global variable is used to store the IPC device structure and it is used
> across all functions in intel_pmc_ipc.c and intel_punit_ipc.c.

I think those changes are definitely welcome. On top of those, I want
to have regmap for using the IPC. It does not make any sense that the
drivers for the devices attached to for example the PMC, like the
WhiskeyCove PMIC, have to implement their own regmaps.

But a class for the IPC library does feel like overkill to me.



Powered by blists - more mailing lists