From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2A671C3DA7C for ; Sat, 24 Dec 2022 08:55:47 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 1624EA981; Sat, 24 Dec 2022 09:54:55 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 1624EA981 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1671872145; bh=m3Ir70l8g/TXMb/IV1C5kk10eAYAEp+V9k7xKdezeGA=; h=Date:From:To:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=Dq6pf/S4M9wKh6jnMymUhAPHf/4nOvyye74HTYEZG+Laigh2iPA8hViFbKo4skzV5 GkIMd00ep1WIH8TZUo2CbUkIMrz3oUW9HOSed5UuP4xkRWkAfDQGhRWTYM41CG6E3Q pbKx7q6LHi/7Eh/+3QOQHbI94j1FxPTum36d3zn4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id AD05FF802E0; Sat, 24 Dec 2022 09:54:54 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id B2317F8032B; Sat, 24 Dec 2022 09:54:53 +0100 (CET) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 73862F80249 for ; Sat, 24 Dec 2022 09:54:50 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 73862F80249 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=BQWqu7Gb Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 98E0B6020F; Sat, 24 Dec 2022 08:54:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79562C433D2; Sat, 24 Dec 2022 08:54:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1671872088; bh=m3Ir70l8g/TXMb/IV1C5kk10eAYAEp+V9k7xKdezeGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BQWqu7Gb6mhU/wDiU4LytDOURNWAMqtwN8md9fTezBNZ8s3NJfpnVvzG25oC2AQBa mUTLJMUQpHRZFrjrutDBg+lmU8PcRq1jqM639Tb1fxPUlr19o73tkMM1VNMjNs8tqA MpK8Xi23gbyhrOPX9UHjLfZeZj7KKVFgD3E6cjYg= Date: Sat, 24 Dec 2022 09:54:44 +0100 From: Greg KH To: Wesley Cheng Subject: Re: [RFC PATCH 06/14] usb: core: hcd: Introduce USB HCD APIs for interrupter management Message-ID: References: <20221223233200.26089-1-quic_wcheng@quicinc.com> <20221223233200.26089-7-quic_wcheng@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221223233200.26089-7-quic_wcheng@quicinc.com> X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-usb@vger.kernel.org, bgoswami@quicinc.com, mathias.nyman@intel.com, Thinh.Nguyen@synopsys.com, andersson@kernel.org, tiwai@suse.com, lgirdwood@gmail.com, robh+dt@kernel.org, broonie@kernel.org, srinivas.kandagatla@linaro.org, agross@kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-arm-msm@vger.kernel.org, quic_plai@quicinc.com, linux-kernel@vger.kernel.org, quic_jackp@quicinc.com Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Fri, Dec 23, 2022 at 03:31:52PM -0800, Wesley Cheng wrote: > For USB HCDs that can support multiple USB interrupters, expose functions > that class drivers can utilize for setting up secondary interrupters. > Class drivers can pass this information to its respective clients, i.e. > a dedicated DSP. Where is the locking here that seems to be required when a hcd is removed from the system and you have data in flight? What am I missing here in the design of this? And yes, HCDs get removed all the time, and will happen more and more in the future with the design of more systems moving to Thunderbolt/PCIe designs due to the simplicity of it. > +/** > + * usb_set_interruper - Reserve an interrupter Where is an "interrupter" defined? I don't know what this term means sorry, is this in the USB specification somewhere? > + * @udev: usb device which requested the interrupter > + * @intr_num: interrupter number to reserve > + * @dma: iova address to event ring > + * > + * Request for a specific interrupter to be reserved for a USB class driver. > + * This will return the base address to the event ring that was allocated to > + * the specific interrupter. > + **/ > +phys_addr_t usb_set_interruper(struct usb_device *udev, int intr_num, > + dma_addr_t *dma) > +{ > + struct usb_hcd *hcd; > + phys_addr_t pa = 0; > + > + hcd = bus_to_hcd(udev->bus); > + if (hcd->driver->update_interrupter) > + pa = hcd->driver->update_interrupter(hcd, intr_num, dma); > + > + return pa; Wait, you return a physical address? What are you going to do with that? And what guarantees that the address is valid after you return it (again, remember memory and devices can be removed at any point in time. thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93433C4332F for ; Sat, 24 Dec 2022 08:54:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229650AbiLXIyy (ORCPT ); Sat, 24 Dec 2022 03:54:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbiLXIyw (ORCPT ); Sat, 24 Dec 2022 03:54:52 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A462D126; Sat, 24 Dec 2022 00:54:50 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 405C1B8219B; Sat, 24 Dec 2022 08:54:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79562C433D2; Sat, 24 Dec 2022 08:54:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1671872088; bh=m3Ir70l8g/TXMb/IV1C5kk10eAYAEp+V9k7xKdezeGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BQWqu7Gb6mhU/wDiU4LytDOURNWAMqtwN8md9fTezBNZ8s3NJfpnVvzG25oC2AQBa mUTLJMUQpHRZFrjrutDBg+lmU8PcRq1jqM639Tb1fxPUlr19o73tkMM1VNMjNs8tqA MpK8Xi23gbyhrOPX9UHjLfZeZj7KKVFgD3E6cjYg= Date: Sat, 24 Dec 2022 09:54:44 +0100 From: Greg KH To: Wesley Cheng Cc: srinivas.kandagatla@linaro.org, mathias.nyman@intel.com, perex@perex.cz, broonie@kernel.org, lgirdwood@gmail.com, andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org, Thinh.Nguyen@synopsys.com, bgoswami@quicinc.com, tiwai@suse.com, robh+dt@kernel.org, agross@kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, quic_jackp@quicinc.com, quic_plai@quicinc.com Subject: Re: [RFC PATCH 06/14] usb: core: hcd: Introduce USB HCD APIs for interrupter management Message-ID: References: <20221223233200.26089-1-quic_wcheng@quicinc.com> <20221223233200.26089-7-quic_wcheng@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221223233200.26089-7-quic_wcheng@quicinc.com> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Fri, Dec 23, 2022 at 03:31:52PM -0800, Wesley Cheng wrote: > For USB HCDs that can support multiple USB interrupters, expose functions > that class drivers can utilize for setting up secondary interrupters. > Class drivers can pass this information to its respective clients, i.e. > a dedicated DSP. Where is the locking here that seems to be required when a hcd is removed from the system and you have data in flight? What am I missing here in the design of this? And yes, HCDs get removed all the time, and will happen more and more in the future with the design of more systems moving to Thunderbolt/PCIe designs due to the simplicity of it. > +/** > + * usb_set_interruper - Reserve an interrupter Where is an "interrupter" defined? I don't know what this term means sorry, is this in the USB specification somewhere? > + * @udev: usb device which requested the interrupter > + * @intr_num: interrupter number to reserve > + * @dma: iova address to event ring > + * > + * Request for a specific interrupter to be reserved for a USB class driver. > + * This will return the base address to the event ring that was allocated to > + * the specific interrupter. > + **/ > +phys_addr_t usb_set_interruper(struct usb_device *udev, int intr_num, > + dma_addr_t *dma) > +{ > + struct usb_hcd *hcd; > + phys_addr_t pa = 0; > + > + hcd = bus_to_hcd(udev->bus); > + if (hcd->driver->update_interrupter) > + pa = hcd->driver->update_interrupter(hcd, intr_num, dma); > + > + return pa; Wait, you return a physical address? What are you going to do with that? And what guarantees that the address is valid after you return it (again, remember memory and devices can be removed at any point in time. thanks, greg k-h