lkml.org 
[lkml]   [2020]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 03/18] platform/x86: intel_scu_ipc: Introduce new SCU IPC API
On Wed, Feb 12, 2020 at 01:43:41PM +0200, Mika Westerberg wrote:
> On Tue, Feb 11, 2020 at 05:48:41PM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 11, 2020 at 04:25:48PM +0300, Mika Westerberg wrote:
> > > The current SCU IPC API has been operating on a single instance and
> > > there has been no way to pin the providing module in place when the SCU
> > > IPC is in use.
> > >
> > > This implements a new API that takes the SCU IPC instance as first
> > > parameter (NULL means the single instance is being used). The SCU IPC
> > > instance can be retrieved by calling new function
> > > intel_scu_ipc_dev_get() that take care of pinning the providing module
> > > in place as long as intel_scu_ipc_dev_put() is not called.
> > >
> > > The old API and constants that are still being used are left there to
> > > support existing users that cannot be converted easily but they are put
> > > to a separate header that is subject to be removed eventually.
> > > Subsequent patches will convert most of the users over to the new API.
> >
> > I'm thinking now if it would be better to do this in two steps, i.e. split out
> > legacy header first and then introduce new API?
>
> No problem doing that but I'm not sure what's the benefit over what is
> done now?

That's what I'm trying to figure out. Would it be? Maybe you can play with it
locally and decide which one is better?

--
With Best Regards,
Andy Shevchenko


\
 
 \ /
  Last update: 2020-02-12 12:56    [W:0.123 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site