RISC-V SoC Drivers for v6.2

[Arnd Bergmann]

On Mon, Nov 21, 2022, at 18:24, Conor Dooley wrote:
> Hey Arnd,
>
> Same stuff applies here: lmk if there's something you'd rather see changed.
> Perhaps you'd prefer to see PRs per vendor? Although I think that's less
> likely to matter here than in the DT stuff. Again, I'll try to get the PR
> out a bit earlier next time.

Applied, this looks fine, just a few things to keep in mind:

- please add "[GIT PULL]" to the subject line of the email
- Splitting up a large pull request into smaller ones can be
  helpful to make sure things don't go in unnoticed. I try to
  (briefly) look at each patch, but if you have 20 boring but
  large patches, and a small but important patch that I may
  need to comment on, that is a good reason to split.

> Not too much to see here, Yang Yingliang has added some error handling
> to the setup of the driver that reports SiFive cache topology
> information. I've put it on -next given how far we are in the release
> cycle, feel free to put it on fixes if you disagree :)

This is fine either way, as none of the fixes are likely to cause
any real issues. I usually like to err on the side of having too much
in the fixes branch instead of risking to miss something, but I'm
just as happy to follow your preference here.

> RISC-V SoC drivers for v6.2
>
> SiFive:
> - add probe error handling to the ccache driver

Since this tag description becomes part of the git history, try to write
it like you would write a commit log in the future. Ideally that
avoids bulleted lists (I know they are easy) and instead uses full
sentences that explain things about the state of the patches. If there
are bugfixes, are users likely to need the fixes or were they found
through inspection? For new features, explain who would have the
corresponding hardware and what it does. Again, what you have here
is not wrong, but it can always get better.

      Arnd