Re: [PATCH v5 03/18] platform/x86: intel_scu_ipc: Introduce new SCU IPC API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux