On Mon, Jul 20, 2026 at 7:24 PM Tom Rini <[email protected]> wrote: > > On Sun, Jul 19, 2026 at 10:13:46PM -0600, James Hilliard wrote: > > The hash command currently always uses the software implementation for > > the selected algorithm, even when driver-model hash providers are > > available. > > > > Add a hash_digest_wd_lookup() helper which probes UCLASS_HASH devices in > > order and uses the first provider supporting the requested algorithm. > > Continue past unavailable providers and unsupported operations, but > > propagate a hard digest failure once a provider accepts the operation. > > Remember probe failures so they are not silently hidden by software > > fallback when no later provider succeeds. > > > > Use the helper from the hash command and retain its software fallback > > when no usable provider is present. Add sandbox tests covering provider > > fallback and hard-error propagation. > > > > Signed-off-by: James Hilliard <[email protected]> > > --- > > Changes v3 -> v4: > > - New patch > > - Try all registered hash providers instead of only device zero > > - Add provider-selection and error-propagation tests > > - Reserve -EINVAL for hard errors > > - Use -EOPNOTSUPP for unsupported algorithms > > Putting new features in an unrelated patch series makes things harder to > merge. I don't know that Andre will be comfortable taking some generic > changes + sunxi support, but he might be. But it's even easier when > something like this is standalone and can be reviewed and picked up on > its own (I'm going to have some size questions about this, once I review > it globally..).
Maybe it makes sense to merge all my patches prior to the sunxi specific ones first? That way I can rebase my series and shrink the patchset substantially for the remaining sunxi ce driver patches for Andre.
