linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Albert Wang <albertccwang@google.com>
Cc: mathias.nyman@intel.com, badhri@google.com, howardyen@google.com,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 3/3] usb: host: add the xhci offload hooks implementations
Date: Thu, 24 Nov 2022 10:08:00 +0100	[thread overview]
Message-ID: <Y380cMKIUJfP7Ya3@kroah.com> (raw)
In-Reply-To: <CANqn-rj++p_rSkZxa5rpRXQ-9or-_18VzaE_M1vjq4aVNsrAKg@mail.gmail.com>

On Thu, Nov 24, 2022 at 02:47:22PM +0800, Albert Wang wrote:
> > > +/*
> > > + * This is the driver call to co-processor for offload operations.
> > > + */
> > > +int offload_driver_call(enum usb_offload_msg msg, void *ptr)
> > > +{
> > > +     enum usb_offload_msg offload_msg;
> > > +     void *argptr;
> > > +
> > > +     offload_msg = msg;
> > > +     argptr = ptr;
> >
> > Don't just silence compiler warnings for no reason.
> >
> > Again, this does not actually do anything at all.  So how can we accept
> > this code?
> >
> 
> This is the driver call to our co-processor which is a specific
> hardware, so I don't submit it
> and make it silent here.

"specific hardware" is what Linux is all about!  Please submit your
actual drivers for this hardware, otherwise there is no way we can even
review properly this type of code, let alone accept it.

You all know this in great detail, I've been saying this for many years
now.  It is very frustrating on my end to constantly have to reject this
type of change all the time.

What would you do if you were on the reviewer's side?  Would you accept
this type of submission after constantly saying "I will only accept this
if you do X" and you get another patch that does NOT do "X"?

> We define and use those hook apis in the common xhci driver to offload
> some memory
> manipulation to a co-processor. So these apis will be executed to
> allocate or free memory,
> like dcbaa, transfer ring, in the co-processor memory space when
> offlooffload_driver_callad enabled. The file,
> xhci-offload-impl.c, shows how we use those xHCI hook apis for the
> offload implementation.
> 
> Here is the flow diagram:
> xHCI common driver        xHCI offload implement driver
> co-processor driver
> hooks
>                     offload_driver_call()
> ----------------------------
> ----------------------------------------
> --------------------------------------------------------------
> offload_init                         usb_audio_offload_init
> offload_cleanup                 usb_audio_offload_cleanup
> is_offload_enabled             is_offload_enabled
> alloc_dcbaa                        alloc_dcbaa
>        offload_driver_call(SET_DCBAA_PTR, &dcbaa_ptr);
> 
>                        offload_driver_call(SETUP_DONE, NULL);
> free_dcbaa                         free_dcbaa
> alloc_transfer_ring             alloc_transfer_ring
>    offload_driver_call(SET_ISOC_TR_INFO, &tr_info);
> free_transfer_ring              free_transfer_ring
> usb_offload_skip_urb        offload_skip_urb


This does not make any sense, sorry.  Perhaps your lines got wrapped
incorrectly?

thanks,

greg k-h

      reply	other threads:[~2022-11-24  9:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10  8:00 [PATCH v2 0/3] add xhci hooks for USB offload Albert Wang
2022-11-10  8:00 ` [PATCH v2 1/3] usb: host: " Albert Wang
2022-11-10  8:00 ` [PATCH v2 2/3] usb: xhci-plat: add xhci_plat_priv_overwrite Albert Wang
2022-11-10  8:00 ` [PATCH v2 3/3] usb: host: add the xhci offload hooks implementations Albert Wang
2022-11-10  8:17   ` Greg KH
2022-11-24  6:47     ` Albert Wang
2022-11-24  9:08       ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y380cMKIUJfP7Ya3@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=albertccwang@google.com \
    --cc=badhri@google.com \
    --cc=howardyen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).