Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2968019ybc; Thu, 14 Nov 2019 01:52:08 -0800 (PST) X-Google-Smtp-Source: APXvYqwYNQT94aFqSRKZ1WmvavNo9Um1ixluzpOCEiOBwbbMS46fWoE0aSDLnKxK5q0pKghcbNwI X-Received: by 2002:a50:f284:: with SMTP id f4mr138880edm.126.1573725128183; Thu, 14 Nov 2019 01:52:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573725128; cv=none; d=google.com; s=arc-20160816; b=xnEGO4S2vvwVC6v2leydCQg8Cf86w1Q2urWocNs+bR1qh0Px1RBbEGs3tPo84i2HsI iD+M0gfn7Epy+J8kGBl84djRu1hVq2CmMEH5c9D5d/huLXONI5vuaHG5HpMwaP9AESfB 6irqMjqa2JXDsNGUuHxMmW9LEC9wjuCIv7EdlwnL6occMROAmjQ14Co71iSQVtZ2HsTw GfkHcW117nL4MVxRKng1YgS8bHp3oK19c6xKqJrpTqoLMGJRxRwOAxAqXm740EfP+KMr SOJVEnWpU8BWQHMfgsVbPX10yD/yQpNyYs0mOnL3olwPBhT7F+dGMCevGO/NLm742ny8 de9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=1q4MpOUzBLd6f2gFBx2Y+31uqZ0iVHkf8HwMdleJdbM=; b=DAiDhQ5Lv1Q5GcWJ+LXxdoErtZxuRgF4GXKYUUVgk99Q6XU98wTVfh7FFDvYZvnO9n giZXM/+Wk3wka/EmZfpmGyxoPyACSjjWzagmTlguGntER7uJNsrQEzbKi/a3HITcz9by D30WhTr7FpxO6K9F6vJW85XrpCX+x+DbXzyvEOlgNrwwQNka6RqgpbBZ1vLvWFHabTiL wGClykqA21BZx6+LKaDDw7/XLeyHrB64J02F1R9pBV1IDeZ5G8fovlSQYfWk9/JWuQZP 0mccJa6lKgENZZNHaKUtd4MUTEDqmKs++XzakkW/oxwM0Db9znXYd6xiUXs9vKPYfwVX Ohrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=t+rAc2yk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f25si3008856eje.225.2019.11.14.01.51.43; Thu, 14 Nov 2019 01:52:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=t+rAc2yk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726613AbfKNJsR (ORCPT + 99 others); Thu, 14 Nov 2019 04:48:17 -0500 Received: from lelv0142.ext.ti.com ([198.47.23.249]:36876 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726179AbfKNJsQ (ORCPT ); Thu, 14 Nov 2019 04:48:16 -0500 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id xAE9m5a5027418; Thu, 14 Nov 2019 03:48:05 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1573724885; bh=1q4MpOUzBLd6f2gFBx2Y+31uqZ0iVHkf8HwMdleJdbM=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=t+rAc2ykt4MRCS1C16dg7sajamEvL5cKc2qB840wHukRFr/2PfmwG0mmJ5jpJvfr0 lbz7LUDxLnHvYBQT5jYXf6b/eRgyFjYsmlBkEeUYYh2nb0E+91xP5PSH7sq3H17BDR 4hU+5AT+nfsB4MjifWYyE0F1Vg7EQA9nznFGeIx8= Received: from DLEE100.ent.ti.com (dlee100.ent.ti.com [157.170.170.30]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id xAE9m51i050470 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 14 Nov 2019 03:48:05 -0600 Received: from DLEE101.ent.ti.com (157.170.170.31) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Thu, 14 Nov 2019 03:48:05 -0600 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Thu, 14 Nov 2019 03:48:05 -0600 Received: from [192.168.2.14] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id xAE9m2EF044096; Thu, 14 Nov 2019 03:48:02 -0600 Subject: Re: [RFC PATCH] usb: gadget: f_tcm: Added DMA32 flag while allocation of command buffer To: Peter Chen , Jayshri Pawar CC: "linux-usb@vger.kernel.org" , "gregkh@linuxfoundation.org" , "felipe.balbi@linux.intel.com" , "heikki.krogerus@linux.intel.com" , "linux-kernel@vger.kernel.org" , "jbergsagel@ti.com" , "nsekhar@ti.com" , "nm@ti.com" , "kurahul@cadence.com" , "pawell@cadence.com" , "sparmar@cadence.com" References: <1573640672-10344-1-git-send-email-jpawar@cadence.com> <20191114025301.GD30608@b29397-desktop> From: Roger Quadros Message-ID: <5b567d57-6206-24cf-5886-20e8b5a92a45@ti.com> Date: Thu, 14 Nov 2019 11:48:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191114025301.GD30608@b29397-desktop> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jayshri, On 14/11/2019 04:50, Peter Chen wrote: > On 19-11-13 10:24:32, Jayshri Pawar wrote: >> There is a problem when function driver allocate memory for buffer >> used by DMA from outside dma_mask space. >> It appears during testing f_tcm driver with cdns3 controller. >> In the result cdns3 driver was not able to map virtual buffer to DMA. >> This fix should be improved depending on dma_mask associated with device. >> Adding GFP_DMA32 flag while allocationg command data buffer only for 32 >> bit controllers. > > Hi Jayshri, > > This issue should be fixed by setting DMA_MASK correctly for controller, > you can't limit user's memory region. At usb_ep_queue, the UDC driver > will call DMA MAP API, for Cadence, it is usb_gadget_map_request_by_dev. > For the system without SMMU (IO-MMU), it will use swiotlb to make sure > the data buffer used for DMA transfer is within DMA mask for controller, > There is a reserved low memory region for debounce buffer in swiotlb > use case. > /** * struct usb_request - describes one i/o request * @buf: Buffer used for data. Always provide this; some controllers * only use PIO, or don't use DMA for some endpoints. * @dma: DMA address corresponding to 'buf'. If you don't set this * field, and the usb controller needs one, it is responsible * for mapping and unmapping the buffer. */ So if dma is not set in the usb_request then controller driver is responsible to do a dma_map of the buffer pointed by 'buf' before it attemps to do DMA. This should take care of DMA mask and swiotlb. This patch is not correct. cheers, -roger > Peter > >> >> Signed-off-by: Pawel Laszczak >> Signed-off-by: Jayshri Pawar >> --- >> drivers/usb/gadget/function/f_tcm.c | 20 ++++++++++++++------ >> include/linux/usb/gadget.h | 2 ++ >> 2 files changed, 16 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c >> index 36504931b2d1..a78d5fad3d84 100644 >> --- a/drivers/usb/gadget/function/f_tcm.c >> +++ b/drivers/usb/gadget/function/f_tcm.c >> @@ -213,7 +213,8 @@ static int bot_send_read_response(struct usbg_cmd *cmd) >> } >> >> if (!gadget->sg_supported) { >> - cmd->data_buf = kmalloc(se_cmd->data_length, GFP_ATOMIC); >> + cmd->data_buf = kmalloc(se_cmd->data_length, GFP_ATOMIC | >> + gadget->dma_flag); >> if (!cmd->data_buf) >> return -ENOMEM; >> >> @@ -257,7 +258,8 @@ static int bot_send_write_request(struct usbg_cmd *cmd) >> } >> >> if (!gadget->sg_supported) { >> - cmd->data_buf = kmalloc(se_cmd->data_length, GFP_KERNEL); >> + cmd->data_buf = kmalloc(se_cmd->data_length, GFP_KERNEL | >> + gadget->dma_flag); >> if (!cmd->data_buf) >> return -ENOMEM; >> >> @@ -305,6 +307,7 @@ static void bot_cmd_complete(struct usb_ep *ep, struct usb_request *req) >> static int bot_prepare_reqs(struct f_uas *fu) >> { >> int ret; >> + struct usb_gadget *gadget = fuas_to_gadget(fu); >> >> fu->bot_req_in = usb_ep_alloc_request(fu->ep_in, GFP_KERNEL); >> if (!fu->bot_req_in) >> @@ -327,7 +330,8 @@ static int bot_prepare_reqs(struct f_uas *fu) >> fu->bot_status.req->complete = bot_status_complete; >> fu->bot_status.csw.Signature = cpu_to_le32(US_BULK_CS_SIGN); >> >> - fu->cmd.buf = kmalloc(fu->ep_out->maxpacket, GFP_KERNEL); >> + fu->cmd.buf = kmalloc(fu->ep_out->maxpacket, GFP_KERNEL | >> + gadget->dma_flag); >> if (!fu->cmd.buf) >> goto err_buf; >> >> @@ -515,7 +519,8 @@ static int uasp_prepare_r_request(struct usbg_cmd *cmd) >> struct uas_stream *stream = cmd->stream; >> >> if (!gadget->sg_supported) { >> - cmd->data_buf = kmalloc(se_cmd->data_length, GFP_ATOMIC); >> + cmd->data_buf = kmalloc(se_cmd->data_length, GFP_ATOMIC | >> + gadget->dma_flag); >> if (!cmd->data_buf) >> return -ENOMEM; >> >> @@ -763,11 +768,13 @@ static int uasp_alloc_stream_res(struct f_uas *fu, struct uas_stream *stream) >> >> static int uasp_alloc_cmd(struct f_uas *fu) >> { >> + struct usb_gadget *gadget = fuas_to_gadget(fu); >> fu->cmd.req = usb_ep_alloc_request(fu->ep_cmd, GFP_KERNEL); >> if (!fu->cmd.req) >> goto err; >> >> - fu->cmd.buf = kmalloc(fu->ep_cmd->maxpacket, GFP_KERNEL); >> + fu->cmd.buf = kmalloc(fu->ep_cmd->maxpacket, GFP_KERNEL | >> + gadget->dma_flag); >> if (!fu->cmd.buf) >> goto err_buf; >> >> @@ -980,7 +987,8 @@ static int usbg_prepare_w_request(struct usbg_cmd *cmd, struct usb_request *req) >> struct usb_gadget *gadget = fuas_to_gadget(fu); >> >> if (!gadget->sg_supported) { >> - cmd->data_buf = kmalloc(se_cmd->data_length, GFP_ATOMIC); >> + cmd->data_buf = kmalloc(se_cmd->data_length, GFP_ATOMIC | >> + gadget->dma_flag); >> if (!cmd->data_buf) >> return -ENOMEM; >> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h >> index 124462d65eac..d6c9cd222600 100644 >> --- a/include/linux/usb/gadget.h >> +++ b/include/linux/usb/gadget.h >> @@ -373,6 +373,7 @@ struct usb_gadget_ops { >> * @connected: True if gadget is connected. >> * @lpm_capable: If the gadget max_speed is FULL or HIGH, this flag >> * indicates that it supports LPM as per the LPM ECN & errata. >> + * @dma_flag: dma zone to be used for buffer allocation. >> * >> * Gadgets have a mostly-portable "gadget driver" implementing device >> * functions, handling all usb configurations and interfaces. Gadget >> @@ -427,6 +428,7 @@ struct usb_gadget { >> unsigned deactivated:1; >> unsigned connected:1; >> unsigned lpm_capable:1; >> + unsigned int dma_flag; >> }; >> #define work_to_gadget(w) (container_of((w), struct usb_gadget, work)) >> >> -- >> 2.20.1 >> > -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki