Re: [PATCH v29 01/33] xhci: support setting interrupt moderation IMOD for secondary interrupters

[Takashi Iwai <tiwai@suse.de>]

On Fri, 18 Oct 2024 07:52:35 +0200,
Greg KH wrote:
> 
> On Thu, Oct 17, 2024 at 05:07:12PM -0700, Wesley Cheng wrote:
> > Hi Greg,
> > 
> > On 10/16/2024 11:40 PM, Greg KH wrote:
> > > On Tue, Oct 15, 2024 at 02:28:43PM -0700, Wesley Cheng wrote:
> > >> From: Mathias Nyman <mathias.nyman@linux.intel.com>
> > >>
> > >> Allow creators of xHCI secondary interrupters to specify the interrupt
> > >> moderation interval value in nanoseconds when creating the interrupter.
> > >>
> > >> If not sure what value to use then use the xhci driver default
> > >> xhci->imod_interval
> > >>
> > >> Suggested-by: Wesley Cheng <quic_wcheng@quicinc.com>
> > >> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> > >> Link: https://lore.kernel.org/r/20240905143300.1959279-13-mathias.nyman@linux.intel.com
> > >> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >> ---
> > >>  drivers/usb/host/xhci-mem.c | 8 +++++++-
> > >>  drivers/usb/host/xhci.c     | 4 ++--
> > >>  drivers/usb/host/xhci.h     | 5 ++++-
> > >>  3 files changed, 13 insertions(+), 4 deletions(-)
> > > This is already in 6.12-rc1, which makes me confused as to what tree you
> > > made this series against.
> > 
> > Sorry, I didn't fetch the latest changes from usb-next.
> 
> It wasn't even usb-next, it was 6.12-rc1, so I don't know what tree you
> based this on :(
> 
> > In this case, should I rebase and resbumit?
> 
> As the series can't be applied as-is, probably.  But I think you might
> want to collect some acks from the sound people and xhci developers, as
> I can't do anything with this until they look at the changes.

Honestly speaking, I couldn't follow fully the discussions about the
fundamental design -- IIRC, Pierre and others had concerns to the way
to manage the offload device via kcontrols.  Did we get consensus?

I believe that's the biggest obstacle in the audio side, i.e. what's
visible to users.  The kernel internals can be corrected at any time
later.


thanks,

Takashi