From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D1F6A3321D7 for ; Fri, 16 Jan 2026 15:09:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768576163; cv=none; b=GAX0VkzhQJgxFI5xOhN8uNIbjf7tOpL0F3lF7Kf41h4G662n4xAJct3gYE7RQ8IGA6LxfPRN05IRwRLAerHMxaaQLkWCQL/ceGP1Kwdeo+o5Sc8TwKSnPXjbDIDP2E+QFNpBJkUm3i2dlqKJ4xCSiTwhvx8l16pNPm+KoG0s9RU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768576163; c=relaxed/simple; bh=oNE2dKlFJ63ad7ginHJHCdoW6/HCrltr5Mq2vPCToqw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DwhRsvL5sOFN2BULFxeQPesjA3wFZ98xBsA5+7yIt6ArP+VKccPss///anOjCDZADNkRKFZtz/wfClPMmnDMuTjFqupD3xwJZuJQXoD4/eiJL3392LsGaehdAGb4EO0SlhsTZw3pEXUe6njTS6DVwPUR2EobSGGoDQmbHS8roG8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=M3ibkHnq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="M3ibkHnq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9E01C116C6; Fri, 16 Jan 2026 15:09:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1768576163; bh=oNE2dKlFJ63ad7ginHJHCdoW6/HCrltr5Mq2vPCToqw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M3ibkHnqqkwbo4xLmmVrjULUYNlR+JeQDH0neDzX97ssE8vCAnDjaaGJKQLPXIQD+ k67ds9UMqlL7wAAttHu2e4w09CztZM+/3pYEGeAnvUukLl3VTBctbVq66dm7ljIVQy mfQEY/z4hu0ilDx//rQ12dnPuOzGxS7xqCETgdWM= Date: Fri, 16 Jan 2026 16:09:20 +0100 From: Greg Kroah-Hartman To: Damien =?iso-8859-1?Q?Ri=E9gel?= Cc: greybus-dev@lists.linaro.org, linux-kernel@vger.kernel.org, Johan Hovold , Alex Elder , linux-devel@silabs.com Subject: Re: [PATCH 0/8] greybus: support point-to-point topology Message-ID: <2026011606-qualified-dental-bef0@gregkh> References: <20251223183142.31897-1-damien.riegel@silabs.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251223183142.31897-1-damien.riegel@silabs.com> On Tue, Dec 23, 2025 at 01:31:34PM -0500, Damien Riégel wrote: > In a classic Greybus topology, there is an application processor, an > SVC, and one or more modules, all connected to a UniPro bus. Most of the > time, as the application processor doesn't have a UniPro interface, it > is actually connected to a device acting as a bridge with the bus, and > this bridge also acts as the SVC. > > Sometimes, there is no UniPro bus at all, like for the BeaglePlay, which > has the following topology: > > +----+ +------------+ +--------+ > | AP | <--- UART ---> | SVC/Bridge | <--- 802.15.4 ---> | Module | > +----+ +------------+ +--------+ > | > | +--------+ > `------------ 802.15.4 ---> | Module | > +--------+ > > There are two main interesting aspects with Greybus: > - the SVC protocol to monitor and configure the bus > - other protocols, to expose module peripherals to the host > > When the bus has a single module connected directly to the AP, then this > module must also implement the SVC protocol: > > +----+ +------------+ > | AP | <--- bus ---> | SVC/Module | > +----+ +------------+ > > The SVC doesn' really serve a purpose here, as there is no bus to > manage, and adding its support only increase the complexity and the code > size needed on memory-constrained devices. Exactly how much memory does a "single point" SVC driver take, vs. adding new P2P functionality everywhere in the code like you just did? Finding that out would be good first before worrying about adding another type of "bus" here please. > The goal of this patchset is to let a single module expose some Greybus > protocols without requiring the module to also implement SVC protocol. > We call this mode "Point-To-Point". There are three main notable facts > with the implementation of this patchset: > > - most of the time, what this patchet does is just skipping calls that > issue commands to the SVC, as they are not applicable without an SVC Great, make a SVC that just ignores them :) > - CPort ID allocation is a bit different as there is no SVC/Bridge to > do translation between AP address space and interface address space, > so the patchset forces allocation of AP CPort IDs that matches the > ones found in interface's manifest Again, a simple SCV would make this not needed. > - enumeration of a module is normally started by a "Module Inserted" > event issued by the SVC. As the SVC is absent, the host device > driver must manually call a function to start the enumeration I'd prefer again, to have that in the SVC you are using. > We tested this patchset with the gb-beagleplay driver, slightly tweaked > to only keep the HLDC over UART part of the driver, connected over UART > to an EFR32MG24 running BeagleBoard's implementation of Greybus-Zephyr [1]. > > In the discussion to integrate this module into Zephyr [2] (it's > currently as separate module not part of the main Zephyr code base), > there seems to be interest in being able to have a single-node > device on the bus without SVC [3]. If some features that were > implemented by the SVC are missing, we can consider adding more > callbacks to the gb_hd_driver structure at a later time, and let drivers > decide how they want to support these features. I can understand if you want to be a greybus host running zephyr that this might make sense, as it lets you not even have to write any SVC logic, but for Linux here, I think the simplicity makes more sense (i.e. everything goes through the same data paths, no multiple test paths that need to always be exercised.) So I'd prefer not to do this, just try to make a simple svc module and see if that works instead. thanks, greg k-h