Re: [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Oct 30, 2026 at 12:06:15PM +0800, Jeremy Kerr wrote:
> Hi Greg,
> 
> > FWIW, we did raise greybus as an approach to various HW vendors; I
> > assume there were reasons behind OBMF-ICP, and assume some prior-art
> > assesment was involved, but I don't have specifics for those reasons.
> >
> > HW peeps: This would be an excellent opportunity for elaboration on the
> > motivation there, either for LSTP or OBMF-OCP.
> 
> I have been doing some asking around, and a few items came up around
> motivations for OBMC-ICP over Greybus. My motivation here is entirely
> around OBMF-ICP; the NVIDIA contributions for LSTP somewhat comes under
> this, and so we're working on composing a unified solution.
> 
> Collating some of those items here:
> 
> As a bit of background, the typical use case for OBMF-ICP is for
> platform pre-boot environments, with limitations in capabilities of both
> the hardware and software stack. Microcontroller and mask-ROM
> implementations of either side of the protocol are potential targets.
>
> This leads to the structure of OBMF-ICP being intentionally
> light-weight; the channel configuration (ie, definition of the
> encapsulated devices) is static, and the channel-level messaging is kept
> simple, mainly through a requirement of only one message in flight per
> channel.

greybus is very light-weight, you don't need to have more than one
message in flight.  That's not a real answer :)

> [Greg, this is related to one of your points around why not use a
> multi-function USB device for individual, separate devices: the typical
> device-side hardware does not have support for enough USB endpoints to
> do so. Like greybus, the intention is to be able to support multiple
> downstream peripherals without constraints from USB hardware on existing
> SoC devices]

That's for LSTP, and USB devices are dirt cheap, multi-endpoint ones
should also be very cheap compared to the system they are attempting to
control here.  Don't place this on a "it would cost too much so we are
going to fix that by making the software a complex beast and having
someone else solve our problem for us" solution driven by a hardware
designer.  That's not acceptable these days, you all know that...

> There are a few design points that lead to the preference for OBMF-ICP:
> 
> The front-loaded configuration mechanism means less state to manage on
> both sides of the protocol; the channel set and channel-specific
> parameters (like individual GPIO descriptors and flash geometry) being
> stable over the lifetime of the device means simpler core protocol
> support and channel driver implementations.

What state needs to be managed here for Greybus?  And given that there
is firware and kernel code for greybus already written and working for
10+ years, that feels simpler to me.

> The simpler channel communication protocol is better suited to
> lower-complexity interfaces that are needed for the pre-boot
> environments (GPIO control, uart, IPMI, flash access) than the greybus
> targets for mobile device runtime, with higher-bandwidth communication
> requirements (camera, audio, display). For example, typical platform
> management functions generally involve a lot of short i2c operations -
> ICP messages for these are around half the length of greybus
> equivalents.

You don't have to do the high-bandwidth devices, just be a low-bandwidth
device.  and "size" of an operation doesn't make sense here, it's just
bytes in a buffer that you have plenty of on both sides of the
connection.

> For the platform-boot use-cases, we would need to provide a bunch of new
> channel definitions for greybus. This certainly isn't a showstopper in
> itself, but the specification does not appear to be in active
> development; last change was 10 years ago, and the spec repository has
> since been archived as far as I can tell (and so is read-only).

There are new proposals for the spec, see the mailing list.  And what is
missing for your needs that isn't currently present?

I haven't read all of OBMF, as obviously that isn't what is being
proposed here, I was just complaining about the madness of attempting to
create a device tree representation for a single USB device that wanted
to be carved up into different virtual devices because no one decided to
learn from history.

I have other objections about OBMF-ICP, but that's not what this thread
is about, sorry.  Please propose your own patch series for that and I'll
be glad to criticize it there.

And all of these seem to be OMBC answers, not LSTP answers.  There's
still no excuse for LSTP to be designed like this :)

> With OBMF-ICP's super-minimal core protocol, and the use-case
> appropriate channels, seems like a suitable approach to me.
> 
> The USB-IF has a class ID allocated for OBMF-ICP interface descriptors,
> with the intention that we have multiple vendor implementations of the
> common protocol; we would like Linux to be one of those.

It's always fun to make a new spec and protocol, but getting an ID
doesn't mean that usb-if says "this is how it shoudl be done."  Anyone
can get an ID :)

sorry,

greg k-h