Re: [PATCH v7 3/8] gpu: nova-core: add TLV parser for firmware files

Timur Tabi <[email protected]>
Newsgroups dev.linux.lists.driver-core,dev.linux.lists.nova-gpu,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Tue, 2026-08-04 at 00:21 +0200, Danilo Krummrich wrote:
> > Well, maybe this is where we should return ENODATA?
> 
> Or maybe just ENOENT.
> 
> > I am expecting future Nova code to handle tags that may be legitimately absent, so maybe
> > having
> > it return ENODATA if the tag is missing, and EINVAL in all other situations is better.
> 
> In this case it makes sense to differenciate; AFAIC this can be a follow-up
> patch.

...

> This is what I refer to below as "signed tag".
> 
> Some background on this: We can't have patches as duplicate commits going to
> Linus. So in order for me to pull from the Rust tree, it has to guarantee to not
> change its histroy (which it does not). Besides that, we don't want all the
> commits from another tree, but just a specific one. The normal process for this
> is to put the commit on a separate branch based on a commit base, e.g. some -rc,
> typically -rc1. Then we can create a signed tag from this that can be merged
> into both (or multiple) trees, so the commit only exists exactly once.
> 
> However, this kind of logistics typically only makes sense for features, etc. In
> order to avoid a trivial conflict, it is usually overkill. Which is also why I
> said I'd go for the former.

How about this: replace all ENODATA with EINVAL in this patch for now, and then after drm-rust-
next pulls in my error.rs change from the Rust tree, I replace some of those EINVAL with ENOENT
or ENODATA.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.