On 2023-10-12 00:31, Matthew Brost wrote: > On Wed, Oct 11, 2023 at 08:39:55PM -0400, Luben Tuikov wrote: >> On 2023-10-11 19:58, Matthew Brost wrote: >>> Rather than a global modparam for scheduling policy, move the scheduling >>> policy to scheduler so user can control each scheduler policy. >>> >>> v2: >>> - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben) >>> - Only include policy in scheduler (Luben) >>> v3: >>> - use a ternary operator as opposed to an if-control (Luben) >>> - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben) >>> - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben) >>> - Update commit message (Boris) >>> - Fix v3d build (CI) >>> - s/bad_policies/drm_sched_policy_mismatch/ (Luben) >>> - Don't update modparam doc (Luben) >>> v4: >>> - Fix alignment in msm_ringbuffer_new (Luben / checkpatch) >>> >>> Reviewed-by: Luben Tuikov <luben.tuikov@xxxxxxx> >>> Signed-off-by: Matthew Brost <matthew.brost@xxxxxxxxx> >> >> Was the R-V added by hand? (As in editing the commit message manually?) >> > > Yes. > >> I use automated tools for this which do not re-order the tags. >> IOW, the S-O-B is first as this is how it appears in the patch, >> then the R-V most probably added by automated tools, and then >> any other as are tacked on by other automated tools. >> > > Ok, so always add tags in order starting with S-O-B? Yes! The S-O-B tag you add when you write the commit and then you post it up to a mailing list, it's mandatory and it's always there. It's most likely the first, top tag. Then various other scripts and tools start adding tags in an automated way, and those tags are just appended below any existing tags. Generally, always follow a natural order (meaning least amount of energy expenditure--if you have to edit to reorder, that is extra energy expenditure and nature doesn't like that). Make it like a letter you'd get from or write to your bank, attorney, etc. These are tags you add when you craft your commit: Cc: goes first, followed by other tags whose values Cc: are personal emails, i.e. people. These are people Cc: you want to let know of this commit. This is followed Cc: by other personal tags, for instance, Co-developed-by: or Suggested-by: Another personal tag is, Reported-by: which must be followed by a Link tag with Link: the link of the report. This could also be a link to anything else. You can also add a Fixes: tag which should follow a --pretty %h (\"%s\") format. Closes: link to the bug the patch closes Signed-off-by: You Then scripts and tools (or even people) would append the tag list with: Tested-by: someone reliable, could have more than one instance of this tag, Acked-by: someone Reviewed-by: someone There are no empty lines between tags. They form a block paragraph as they would if/when added by a script. (I never add _any_ tag manually.) So, for instance, you may have: Cc: Luben Signed-off-by: Matt And when the patch is R-V-ed this becomes (least amount of energy, append at the bottom), Cc: Luben Signed-off-by: Matt Reviewed-by: Luben Then other tags may be appended, depending on the path the patch takes to land in a tree. Check out: https://docs.kernel.org/process/5.Posting.html https://docs.kernel.org/process/submitting-patches.html https://docs.kernel.org/process/submit-checklist.html And there's more resources to check out in the Documentation/process directory. -- Regards, Luben
