RISC-V SoC Drivers for v6.2

[Palmer Dabbelt]

On Tue, 22 Nov 2022 06:38:40 PST (-0800), Arnd Bergmann wrote:
> 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:

Thanks!

> - please add "[GIT PULL]" to the subject line of the email

FWIW, here's the script I use to send pull requests: https://github.com/palmer-dabbelt/home/blob/master/.local/src/git-send-pull.bash

> - 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