On Thu, Oct 27, 2022 at 08:40:48AM +0800, Albert Wang wrote:
> From: Howard Yen <howardyen@xxxxxxxxxx>
>
> This change is to provide USB offload function which allows to offload some
> xHCI operations on co-processor. This is especially designed for USB audio
> usecase. The co-processor is able to manipulate some USB structures in his
> own memory, like SRAM.
>
> There are several offload_ops introduced by this patch:
>
> struct xhci_offload_ops - function callbacks for offlad specific operations
> {
> @offload_init:
> - called for vendor init process during xhci-plat-hcd
> probe.
> @offload_cleanup:
> - called for vendor cleanup process during xhci-plat-hcd
> remove.
> @is_usb_offload_enabled:
> - called to check if usb offload enabled.
> @alloc_dcbaa:
> - called when allocating vendor specific dcbaa during
> memory initializtion.
> @free_dcbaa:
> - called to free vendor specific dcbaa when cleanup the
> memory.
> @alloc_transfer_ring:
> - called when vendor specific transfer ring allocation is required
> @free_transfer_ring:
> - called to free vendor specific transfer ring
> @usb_offload_skip_urb:
> - called to check if need to skip urb enqueue
> }
>
> The xhci hooks with prefix "xhci_vendor_" on the ops in xhci_offload_ops.
> For example, offload_init ops will be invoked by xhci_vendor_offload_init()
> hook,is_usb_offload_enabled ops will be invoked by
> xhci_vendor_is_usb_offload_enabled(), and so on.
>
> Signed-off-by: Howard Yen <howardyen@xxxxxxxxxx>
> Link: https://lore.kernel.org/r/20210119101044.1637023-1-howardyen@xxxxxxxxxx
> Signed-off-by: Greg Kroah-Harktman <gregkh@xxxxxxxxxx>
Sorry, but no, I did NOT sign of on this patch for submission here.
And if you read the link above, you will see that I explicitly rejected
this commit for inclusion.
What changed from this previous series? Is any of the issues raised
there now resolved? If so, how? If not, why not?
thanks,
greg k-h
