Message ID | 20240130-onboard_xvf3500-v1-2-51b5398406cb@wolfvision.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-44605-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp1183026dyb; Tue, 30 Jan 2024 04:28:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IHr/CmAPSVe7ygGE6EaNud6jKmKZ/xZPPIflMDR2OSQkYx2Uz7SJ+YtNmovd03CPhrTSP5d X-Received: by 2002:a67:f782:0:b0:46a:fa5d:2027 with SMTP id j2-20020a67f782000000b0046afa5d2027mr4055329vso.49.1706617707440; Tue, 30 Jan 2024 04:28:27 -0800 (PST) Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id j2-20020a05620a000200b00784f2e78a4bsi588113qki.528.2024.01.30.04.28.27 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 04:28:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-44605-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@wolfvision.net header.s=selector2 header.b=Oy6Y69yu; arc=fail (signature failed); spf=pass (google.com: domain of linux-kernel+bounces-44605-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44605-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=wolfvision.net Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 30D051C24612 for <ouuuleilei@gmail.com>; Tue, 30 Jan 2024 12:28:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5F4036D1BD; Tue, 30 Jan 2024 12:27:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=wolfvision.net header.i=@wolfvision.net header.b="Oy6Y69yu" Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2069.outbound.protection.outlook.com [40.107.6.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8DAB26A34F; Tue, 30 Jan 2024 12:27:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.6.69 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706617632; cv=fail; b=focjufY3D8w5hpQdDw6xISKvrPcp84ouEwQYOqf/9cY5Y/aegXWfmUsvEvZcyPgbQOmF3fNEmUlGq58bIisxBP6rqYsUMKkjYibsHnDfD4ci72+BVo/McSPyrEkxqJ2VU+mmGAU6fUiOh4ix8N8xiw6mveFrAw2W108oLn90gPc= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706617632; c=relaxed/simple; bh=V7NsmgNnWJFlF/itQ9Ex8RWjiqi0iPRtBiqkbxjiYig=; h=From:Date:Subject:Content-Type:Message-Id:References:In-Reply-To: To:Cc:MIME-Version; b=TOQkfI7NKh1NN+6HvH65JT3jrOKtaVXwNJ3G7f9C4fAbq2bon1sCwx4x2JafwSPv96VBEnqLJaRgVpQk2AWH2SFZ9zWw4bZvz9uIOWTPTH2Rj4GdwGmhrawoXayfoSiQm/fZ5mJ2Q7XFgciCIwWxFz1fEfth2p3y7lgwye/HhII= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wolfvision.net; spf=pass smtp.mailfrom=wolfvision.net; dkim=pass (1024-bit key) header.d=wolfvision.net header.i=@wolfvision.net header.b=Oy6Y69yu; arc=fail smtp.client-ip=40.107.6.69 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wolfvision.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wolfvision.net ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HMT1ckDfPdp6fsbd34dE/rM50lgqJK6QQ5QooZTYfaO5FPivxoU1HyCxqblwaMTZ0GOg9v+HJmgPsuIgmETiz6kTDEdFgJ1T6TGdb5RyIEryNqlgBCi6+zhe7LkEoJHzDyDti92rI/SnoBthn1jbqVNdUDuQHBfTSdSXCWbIHOko1slX8b7UAcTBz6iY+96nHNJNopQNJcm2/tslsTM2ml93KtJfIEzOrURCyjAa4rtecOzfIyZy6eTJZ4rH14cfvR0l/LWxRf5FK+4GWSbQxY8YjNHFsQ3QGH5fEUlv8ghuFjzRI0ksdI3XZo+3LO+t0mSBtPx9V2wLVl9cITzrfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cxa4RP8RQluOUry7+pBnwhCmr9F9NYfO0oJ5ANkCN40=; b=bRFj78qy/9ZSelMVEVXVbqx9dJ3HKnx1ujwVRB/TVzhbMljpoVbX1OtraF4fWUqi26al1IsoOQ4QqAeSWSj19qW1jnbTnm9cwqphEn7CuTDDJse1hGvE+BAijiabHAYBqV8p3ehyIoUbKr/dxYRqlJzK6+QhV7r99V46OtPgb1xwfZE8cKfLryYnOFBHh1Q0sJnCbB35xAV/fEko/sVzekIhnbcvigCMNcmiIPkw/bC7DLdtZwgwGuAWojJsRyfIr1WteRwYAkmqOXDyvaxQlApwvmO8Nzl4wQw16/HRny1pJPNqEhuvxDNQmpgDrcMu4QWACyV0pc/Ld++EauE9Eg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wolfvision.net; dmarc=pass action=none header.from=wolfvision.net; dkim=pass header.d=wolfvision.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wolfvision.net; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cxa4RP8RQluOUry7+pBnwhCmr9F9NYfO0oJ5ANkCN40=; b=Oy6Y69yuKmefOfpGxiWTr/4V49PfTSJFa5I7gAbVWbGodLo5Z7Ia1JvYFOe8c78yK8sCEEPDXUoaDN648ExFFefiV2gXytwy9g0cnPskN+510t1vLcKxOxt7FzJPWADnkZFtRS/jp75W0bagaPYwRo/E5JfB4OA8jO+W1p90gE4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=wolfvision.net; Received: from VE1PR08MB4974.eurprd08.prod.outlook.com (2603:10a6:803:111::15) by AS8PR08MB9954.eurprd08.prod.outlook.com (2603:10a6:20b:638::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.34; Tue, 30 Jan 2024 12:27:04 +0000 Received: from VE1PR08MB4974.eurprd08.prod.outlook.com ([fe80::c8ee:9414:a0c6:42ab]) by VE1PR08MB4974.eurprd08.prod.outlook.com ([fe80::c8ee:9414:a0c6:42ab%7]) with mapi id 15.20.7228.029; Tue, 30 Jan 2024 12:27:04 +0000 From: Javier Carrasco <javier.carrasco@wolfvision.net> Date: Tue, 30 Jan 2024 13:26:57 +0100 Subject: [PATCH 2/2] usb: misc: onboard_hub: add support for XMOS XVF3500 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240130-onboard_xvf3500-v1-2-51b5398406cb@wolfvision.net> References: <20240130-onboard_xvf3500-v1-0-51b5398406cb@wolfvision.net> In-Reply-To: <20240130-onboard_xvf3500-v1-0-51b5398406cb@wolfvision.net> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Matthias Kaehlcke <mka@chromium.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-sound@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Javier Carrasco <javier.carrasco@wolfvision.net> X-Mailer: b4 0.13-dev-0434a X-Developer-Signature: v=1; a=ed25519-sha256; t=1706617622; l=2715; i=javier.carrasco@wolfvision.net; s=20230509; h=from:subject:message-id; bh=V7NsmgNnWJFlF/itQ9Ex8RWjiqi0iPRtBiqkbxjiYig=; b=MCS3mXR0vHTv4dzlSeBa4msa32KzBT9J4dBEVwp+qtrx+xg9v12V0SBWTNUKEyJowaMEQ1746 bOMbD5QlMqGAa0WIn1ezAF56C7avM+OVHbrCzIgOQ9UEfxJn0b/mOqm X-Developer-Key: i=javier.carrasco@wolfvision.net; a=ed25519; pk=tIGJV7M+tCizagNijF0eGMBGcOsPD+0cWGfKjl4h6K8= X-ClientProxiedBy: VE1PR03CA0017.eurprd03.prod.outlook.com (2603:10a6:802:a0::29) To VE1PR08MB4974.eurprd08.prod.outlook.com (2603:10a6:803:111::15) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR08MB4974:EE_|AS8PR08MB9954:EE_ X-MS-Office365-Filtering-Correlation-Id: a0290ae5-b9d8-4e6c-0ee6-08dc218ec493 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1MwoWPveET13T8DqLg2XRca2fvip9QDZ2u+qATwI+C8jbzcoYTrfTx/rLmpUpeY3J2LvjzSLToEUi+dvflInPsbQlKYKQha9rVJMd5yuJsMqxx4IjG7VBMn8njcAZ751FsP9+m7WkuuhK3rvF2kcQ7G9mz7EwkB+UQstvLRLVAofTYGiRmAyrf84DBDS2o4XvyZa5rQ8p7rfigSYr9Y98ERFcF3AL39CuY3WMKPd7cel4twupiDfVAr3nTUOYGXZANpR9NxNLGR/85mfyNACiBvKYsX4CeDhCoHllrwnCUk8zoNe0hl+Ckxmpm/c0De5gvu+nqr77eulr6dT0/iHTh1TO7pFxlH0BziFAuZ1RjC1NvuRPmZHEdFo3NhFM8GU/8K6jwxHAgaNq4e/QSlOVRbRVpYbXwXe9us0KT/bmjv3q41PodztxQxUdfXFIlv1wnEvTMqiWpLqr+1i5NI/wDT1lFL3hyhquondkMzLr9chwJ+7EZa8Yl5q1JxISkP7zJg1HDYRgvYAs567cb1AVNNHl3O2ifMQtBYUATr7vgPjR/wZd23vLyMDsgb7MuNKd1z0PBiYp+0FWTi64h1B02Z+YoIWYsKcCzw4SvKTnOQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR08MB4974.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(396003)(39850400004)(366004)(346002)(376002)(230922051799003)(186009)(451199024)(64100799003)(1800799012)(26005)(7416002)(38100700002)(5660300002)(2906002)(41300700001)(44832011)(38350700005)(36756003)(316002)(86362001)(6486002)(478600001)(966005)(107886003)(6512007)(6506007)(2616005)(6666004)(4326008)(8676002)(8936002)(66556008)(66946007)(110136005)(52116002)(66476007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?ThlmK9HvaFpadoVSfp0UvAEhjEY8?= =?utf-8?q?w3Lj68x/purM0QHYZPS8pHJ+PtMSSENdVqdMwuQ9XfG/yCK/rATDViuFB8NE7m+Mc?= =?utf-8?q?m9PGHa1iMu9EuChqNPiPUbcZyeupatiTV6TJwdCFELSM3FYOm6LrIWP1RwrROM9EJ?= =?utf-8?q?vd6TAiPRMIvZlpnKIevYd24S94XEIFscw3eY7a19umldfTqECubJehP9UBvOP77q9?= =?utf-8?q?qpEuwPiGk6GFV7lyud4uGRBb/XiLRDsAvoABnelhfvTA0ZRyO02QN75BkQc3RZbcg?= =?utf-8?q?g+kxSQEnBwAAgC0ijBzR2npsQFboT0CeDNR+pifYehuWLRAWKV9+zB8RF/41eTV0v?= =?utf-8?q?D2Zvs8H6InbL/k3daQYUCluIDQZljsxnznAGP09TU6cM0EBFMvDGgWs+3Syx6Ea9p?= =?utf-8?q?lWsYscdX4WviLvxHkExuDQs6hQiWvqU8CI2OoW6hr0b6DHpA9vf+hqjp4XA+UutqA?= =?utf-8?q?g10Ll5OtmLUaxN/cyP8TNKzhwfzDm5I7aLgjStf5Ac+nauWQlDkzVvcuPKEveVxNV?= =?utf-8?q?60HjCjbRD6rdjk94xx4RWV6vp6Kxep+0Zl4c/R2hX6CCeEDfJu3aZ6c3RNBA9crt+?= =?utf-8?q?7tHgRkRMMuoS0POGbhLJuQ2vf9jZXqf9SwvMtyB6zTNMLRCjL+mKld2WmP0ryhFbk?= =?utf-8?q?jgP8FfxbEGo1JMN7W1ZauvJ/HFdi3QE1JS9wrUi9h6TLG41JrpSu8z7h1uzvgj3VP?= =?utf-8?q?w+reFlr4nOnZxYZiGkm7LfQVrDpN7AssUV/T8kfeGT7mruXYD04l+8E1QL2Lpt+dx?= =?utf-8?q?DM522UZiS9Fp2U9x2PNCHjZrCrl7X9SEepCqM+xBRiS42krhztsm9Ev+hN6kBUmf+?= =?utf-8?q?cip4AkTLy8cwU2k/1VVJFulShjVpka4GTg1Q2KfH9T4zujiE9+zccMkTgxEa1+e6M?= =?utf-8?q?4nCXWXbEcfzk+yhxo6843Ol11BJMeJRr1A73Xg+Z3/iYKdOumDA9Ly7uO/2vBsNXu?= =?utf-8?q?7Fs+bG860JWNyp6ns81URdcrN6AEnNXxNHqlZUPNUOzvBu5M65vX5T6elXiVQL34x?= =?utf-8?q?Y/E/WtS1DIcw2jGlJnA5PisduFiat19C9+W7zmTjJ5RgPjgJKtDN49KVZvHtgnI+s?= =?utf-8?q?OJSfR82r3I5YaQgfL/UEN4Bvb7z0426HNSIrl/dNgr+C8xyuyZecwtXfXeWDp1dyF?= =?utf-8?q?Iv6egCMjKUvAPiupTEUHcYlxF+LAya7adFHlskUQ1/+nTSIvp+NGQ7VaF3Q7imuVY?= =?utf-8?q?3fQ1haNC8s5Ni7ryk+AKSB8GeE2BGZzVNZ760BH7NlKo0auxqT2MtA8fmqSBNgHAc?= =?utf-8?q?0d5t0TOsnQPHnaV6Gv3f+N9YgMvze2Lv8j8/39oZOXaP/s3b0kXJouAIR75Wq9ekw?= =?utf-8?q?r/izI7RcZ/42yDq4OTg3YATAvp2zqgwD8S+OWadFxCRbeCbC0Wq0Q/c7GXFTiqAH9?= =?utf-8?q?YqYpJTBkgZXd6zXU3dBqO9ENucPyybyCVqBTtoB3dIBhIjwAqbcd2jNVX59HlEs00?= =?utf-8?q?/AVrtnhPjRnNPaFDlbPEz641urp5pHo1hK3vjkJuTJUBS8LPV5AVRy7PKvXsCc+rM?= =?utf-8?q?Uez5hob78l7LZftCC/M6qq/O292o1WX7XvNslgmn0yM5EjCEF2CugFw=3D?= X-OriginatorOrg: wolfvision.net X-MS-Exchange-CrossTenant-Network-Message-Id: a0290ae5-b9d8-4e6c-0ee6-08dc218ec493 X-MS-Exchange-CrossTenant-AuthSource: VE1PR08MB4974.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2024 12:27:04.8012 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e94ec9da-9183-471e-83b3-51baa8eb804f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: y6dgNtrHRG5UHzD80o68YfWS8LSFwUinnI0UjLmgafSkkqwlLxhqL/olavEso25z3GRTkCZFvEMSqsW26/sGQ7RM4qyEGx3c+pZsJJBjpwE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9954 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789518368758898791 X-GMAIL-MSGID: 1789518368758898791 |
Series |
usb: misc: onboard_usb_hub: add support for XMOS XVF3500
|
|
Commit Message
Javier Carrasco
Jan. 30, 2024, 12:26 p.m. UTC
The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
multicore controller for voice processing.
This device requires a specific power sequence, which consists of
enabling the regulators that control the 3V3 and 1V0 device supplies,
and a reset de-assertion after a delay of at least 100ns. Such power
sequence is already supported by the onboard_hub driver, and it can be
reused for non-hub USB devices as well.
Once in normal operation, the XVF3500 registers itself as a USB device,
and it does not require any device-specific operations in the driver.
[1] https://www.xmos.com/xvf3500/
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
drivers/usb/misc/onboard_usb_hub.c | 2 ++
drivers/usb/misc/onboard_usb_hub.h | 6 ++++++
2 files changed, 8 insertions(+)
Comments
Hi Javier, I understand your motivation for using the onboard_usb_hub driver for powering up a non-hub device, it feels a bit hacky to use it as is though. Re-using the driver might be the right thing to do, but then it should probably be renamed to onboard_usb_dev (or similar) and do the hub specific bits as special case. Greg, do you have any thoughts on this? Also there is an implication that might not matter for the XVF3500, but could for other non-hub devices with wakeup support: by default the driver powers the hub/device down during suspend, unless (in case of a hub) wakeup capable devices are connected. This behavior can be changed through sysfs, but the default would still be unexpected. In hindsight I think the default should have been to keep the hub powered. Not sure if it's an option to change the default at this point, since folks might rely on it (I know systems that do, but those could be adapted). We could possibly change the behavior for non-hub devices and keep the device powered if wakeup is supported and enabled m. On Tue, Jan 30, 2024 at 01:26:57PM +0100, Javier Carrasco wrote: > The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit > multicore controller for voice processing. > > This device requires a specific power sequence, which consists of > enabling the regulators that control the 3V3 and 1V0 device supplies, > and a reset de-assertion after a delay of at least 100ns. Such power > sequence is already supported by the onboard_hub driver, and it can be > reused for non-hub USB devices as well. > > Once in normal operation, the XVF3500 registers itself as a USB device, > and it does not require any device-specific operations in the driver. > > [1] https://www.xmos.com/xvf3500/ > > Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> > --- > drivers/usb/misc/onboard_usb_hub.c | 2 ++ > drivers/usb/misc/onboard_usb_hub.h | 6 ++++++ > 2 files changed, 8 insertions(+) > > diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c > index 0dd2b032c90b..f16ea3053f84 100644 > --- a/drivers/usb/misc/onboard_usb_hub.c > +++ b/drivers/usb/misc/onboard_usb_hub.c > @@ -366,6 +366,7 @@ static struct platform_driver onboard_hub_driver = { > #define VENDOR_ID_REALTEK 0x0bda > #define VENDOR_ID_TI 0x0451 > #define VENDOR_ID_VIA 0x2109 > +#define VENDOR_ID_XMOS 0x20B1 > > /* > * Returns the onboard_hub platform device that is associated with the USB > @@ -458,6 +459,7 @@ static const struct usb_device_id onboard_hub_id_table[] = { > { USB_DEVICE(VENDOR_ID_TI, 0x8142) }, /* TI USB8041 2.0 */ > { USB_DEVICE(VENDOR_ID_VIA, 0x0817) }, /* VIA VL817 3.1 */ > { USB_DEVICE(VENDOR_ID_VIA, 0x2817) }, /* VIA VL817 2.0 */ > + { USB_DEVICE(VENDOR_ID_XMOS, 0x0013) }, /* XMOS XVF3500 */ > {} > }; > MODULE_DEVICE_TABLE(usb, onboard_hub_id_table); > diff --git a/drivers/usb/misc/onboard_usb_hub.h b/drivers/usb/misc/onboard_usb_hub.h > index f360d5cf8d8a..1809c0923b98 100644 > --- a/drivers/usb/misc/onboard_usb_hub.h > +++ b/drivers/usb/misc/onboard_usb_hub.h > @@ -56,6 +56,11 @@ static const struct onboard_hub_pdata vialab_vl817_data = { > .num_supplies = 1, > }; > > +static const struct onboard_hub_pdata xmos_xvf3500_data = { > + .reset_us = 1, > + .num_supplies = 2, > +}; > + > static const struct of_device_id onboard_hub_match[] = { > { .compatible = "usb424,2412", .data = µchip_usb424_data, }, > { .compatible = "usb424,2514", .data = µchip_usb424_data, }, > @@ -77,6 +82,7 @@ static const struct of_device_id onboard_hub_match[] = { > { .compatible = "usbbda,5414", .data = &realtek_rts5411_data, }, > { .compatible = "usb2109,817", .data = &vialab_vl817_data, }, > { .compatible = "usb2109,2817", .data = &vialab_vl817_data, }, > + { .compatible = "usb20b1,0013", .data = &xmos_xvf3500_data, }, > {} > }; > > > -- > 2.39.2 >
On Tue, Jan 30, 2024 at 04:11:29PM +0000, Matthias Kaehlcke wrote: > Hi Javier, > > I understand your motivation for using the onboard_usb_hub driver > for powering up a non-hub device, it feels a bit hacky to use it > as is though. Re-using the driver might be the right thing to do, > but then it should probably be renamed to onboard_usb_dev (or > similar) and do the hub specific bits as special case. > > Greg, do you have any thoughts on this? Yeah, this worries me, adding non-hub support to this driver feels odd. Why can't this all just be done in an individual driver for this device itself? Javier, what kernel driver supports this device to communicate with it? Having 2 different drivers poke the same device is just going to cause problems in the end, as there is no way to communicate between the two, right? thanks, greg k-h
On Tue, Jan 30, 2024 at 08:19:40AM -0800, Greg Kroah-Hartman wrote: > On Tue, Jan 30, 2024 at 04:11:29PM +0000, Matthias Kaehlcke wrote: > > Hi Javier, > > > > I understand your motivation for using the onboard_usb_hub driver > > for powering up a non-hub device, it feels a bit hacky to use it > > as is though. Re-using the driver might be the right thing to do, > > but then it should probably be renamed to onboard_usb_dev (or > > similar) and do the hub specific bits as special case. > > > > Greg, do you have any thoughts on this? > > Yeah, this worries me, adding non-hub support to this driver feels odd. It is odd as long as this driver claims to be hub-specific, but truth is that the hub-specific bits are a small part of the driver, I think it might be worthwhile to consider adapting the driver to other devices if there is no clear better solution. A possible alternative could be a separate onboard_usb_dev driver for non-hub devices, with a similar structure as the onboard_hub driver, but without the hub-specific bits. > Why can't this all just be done in an individual driver for this device > itself? I suppose the reason is the good old chicken-egg situation that the (USB) driver is only instantiated after the device has bee powered on, which is what the driver is supposed to take care of. For the onboard_hub driver this was solved by having a platform driver that is instantiated by the parent hub if the onboard hub has a device tree entry. Probably something similar would be needed for an individual driver, and the generic hub driver would have to call the equivalent of onboard_hub_create_pdevs() for all drivers of this type (or a wrapper that does this). m.
On 30.01.24 18:26, Matthias Kaehlcke wrote: > On Tue, Jan 30, 2024 at 08:19:40AM -0800, Greg Kroah-Hartman wrote: >> On Tue, Jan 30, 2024 at 04:11:29PM +0000, Matthias Kaehlcke wrote: >>> Hi Javier, >>> >>> I understand your motivation for using the onboard_usb_hub driver >>> for powering up a non-hub device, it feels a bit hacky to use it >>> as is though. Re-using the driver might be the right thing to do, >>> but then it should probably be renamed to onboard_usb_dev (or >>> similar) and do the hub specific bits as special case. >>> >>> Greg, do you have any thoughts on this? >> >> Yeah, this worries me, adding non-hub support to this driver feels odd. > > It is odd as long as this driver claims to be hub-specific, but truth > is that the hub-specific bits are a small part of the driver, I think > it might be worthwhile to consider adapting the driver to other devices > if there is no clear better solution. The driver was programmed for hubs from the beginning, and that makes non-hub additions look weird, but I wonder if the other way round would have been seen less odd: a generic onboard_usb_dev that ended up being extended to support hub-specific capabilities. As Matthias pointed out, most of the driver is generic, but I have to admit that adding a non-hub device directly (without any renaming) does not look 100% right. > A possible alternative could be a separate onboard_usb_dev driver for > non-hub devices, with a similar structure as the onboard_hub driver, > but without the hub-specific bits. > I was thinking about that possibility too, but the new driver would be a renamed onboard_usb_hub with less functionality. Its only added value would be that it keeps onboard_usb_hub only for hubs. But if that is exactly the goal, I have nothing against an onboard_usb_dev driver for the next patch version. Adding a device-specific driver for such a generic power sequence and resume/suspend support might not be the best approach, though, especially if more USB devices with similar needs arise. >> Why can't this all just be done in an individual driver for this device >> itself? > > I suppose the reason is the good old chicken-egg situation that the (USB) > driver is only instantiated after the device has bee powered on, which is > what the driver is supposed to take care of. For the onboard_hub driver > this was solved by having a platform driver that is instantiated by the > parent hub if the onboard hub has a device tree entry. Probably something > similar would be needed for an individual driver, and the generic hub > driver would have to call the equivalent of onboard_hub_create_pdevs() > for all drivers of this type (or a wrapper that does this). > > m. The XVF3500 does not have kernel support so far, and once it reaches normal operation and registers itself as a USB device, the communication is achieved in userspace. What this device needs from a driver is only the power sequence and eventually the resume/suspend support, which makes it a good candidate for generic implementations. Best regards, Javier Carrasco
diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c index 0dd2b032c90b..f16ea3053f84 100644 --- a/drivers/usb/misc/onboard_usb_hub.c +++ b/drivers/usb/misc/onboard_usb_hub.c @@ -366,6 +366,7 @@ static struct platform_driver onboard_hub_driver = { #define VENDOR_ID_REALTEK 0x0bda #define VENDOR_ID_TI 0x0451 #define VENDOR_ID_VIA 0x2109 +#define VENDOR_ID_XMOS 0x20B1 /* * Returns the onboard_hub platform device that is associated with the USB @@ -458,6 +459,7 @@ static const struct usb_device_id onboard_hub_id_table[] = { { USB_DEVICE(VENDOR_ID_TI, 0x8142) }, /* TI USB8041 2.0 */ { USB_DEVICE(VENDOR_ID_VIA, 0x0817) }, /* VIA VL817 3.1 */ { USB_DEVICE(VENDOR_ID_VIA, 0x2817) }, /* VIA VL817 2.0 */ + { USB_DEVICE(VENDOR_ID_XMOS, 0x0013) }, /* XMOS XVF3500 */ {} }; MODULE_DEVICE_TABLE(usb, onboard_hub_id_table); diff --git a/drivers/usb/misc/onboard_usb_hub.h b/drivers/usb/misc/onboard_usb_hub.h index f360d5cf8d8a..1809c0923b98 100644 --- a/drivers/usb/misc/onboard_usb_hub.h +++ b/drivers/usb/misc/onboard_usb_hub.h @@ -56,6 +56,11 @@ static const struct onboard_hub_pdata vialab_vl817_data = { .num_supplies = 1, }; +static const struct onboard_hub_pdata xmos_xvf3500_data = { + .reset_us = 1, + .num_supplies = 2, +}; + static const struct of_device_id onboard_hub_match[] = { { .compatible = "usb424,2412", .data = µchip_usb424_data, }, { .compatible = "usb424,2514", .data = µchip_usb424_data, }, @@ -77,6 +82,7 @@ static const struct of_device_id onboard_hub_match[] = { { .compatible = "usbbda,5414", .data = &realtek_rts5411_data, }, { .compatible = "usb2109,817", .data = &vialab_vl817_data, }, { .compatible = "usb2109,2817", .data = &vialab_vl817_data, }, + { .compatible = "usb20b1,0013", .data = &xmos_xvf3500_data, }, {} };