From 672bbe434b12d4730cf270f7245753fb98cf162d Mon Sep 17 00:00:00 2001 From: Aidan MacDonald Date: Sun, 19 Sep 2021 10:54:26 +0100 Subject: usb: rename usb_drv_recv() to usb_recv_recv_nonblocking() IMHO the current name is somewhat misleading: - usb_drv_send() is blocking and we have usb_drv_send_nonblocking() for the non-blocking case. This inconsistent naming can only promote confusion. (And what would we call a blocking receive?) - Other hardware abstraction APIs in Rockbox are usually blocking: storage, LCD, backlight, audio... in other words, blocking is the default expected behavior, with non-blocking calls being a rarity. Change-Id: I05b41088d09eab582697674f4f06fdca0c8950af --- firmware/target/arm/as3525/usb-drv-as3525.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'firmware/target/arm/as3525') diff --git a/firmware/target/arm/as3525/usb-drv-as3525.c b/firmware/target/arm/as3525/usb-drv-as3525.c index 01fae5f0ab..8369edc400 100644 --- a/firmware/target/arm/as3525/usb-drv-as3525.c +++ b/firmware/target/arm/as3525/usb-drv-as3525.c @@ -412,12 +412,12 @@ void usb_drv_cancel_all_transfers(void) restore_irq(flags); } -int usb_drv_recv(int ep, void *ptr, int len) +int usb_drv_recv_nonblocking(int ep, void *ptr, int len) { struct usb_dev_dma_desc *uc_desc = endpoints[ep][1].uc_desc; ep &= 0x7f; - logf("usb_drv_recv(%d,%x,%d)\n", ep, (int)ptr, len); + logf("usb_drv_recv_nonblocking(%d,%x,%d)\n", ep, (int)ptr, len); if (len > USB_DMA_DESC_RXTX_BYTES) panicf("usb_recv: len=%d > %d", len, USB_DMA_DESC_RXTX_BYTES); @@ -674,7 +674,8 @@ static void handle_out_ep(int ep) * The usb_storage buffer is 63KB, but Linux sends 120KB. * We get the first part, but upon re-enabling receive dma we * get a 'buffer not available' error from the hardware, since - * we haven't gotten the next usb_drv_recv() from the stack yet. + * we haven't gotten the next usb_drv_recv_nonblocking() from + * the stack yet. * It seems the NAK bit is ignored here and the HW tries to dma * the incoming data anyway. * In theory I think the BNA error should be recoverable, but -- cgit v1.2.3