Hello, Bjorn
Thank you for your prompt reply and helpful comments.
Le jeu. 26 janv. 2023 à 15:52, Bjorn Helgaas <helgaas@xxxxxxxxxx> a écrit :
>
> Hi Rick,
>
> Thanks very much for your work.
>
> On Thu, Jan 26, 2023 at 02:50:40PM +0100, Rick Wertenbroek wrote:
> > This is a series of patches that fixes the PCIe endpoint controller driver
> > for the Rockchip RK3399 SoC. It is based on Linux kernel 6.0.19
> >
> > The original driver in mainline had issues and would not allow for the
> > RK3399 to operate in PCIe endpoint mode. This patch series fixes that so
> > that the PCIe core controller of the RK3399 SoC can now act as a PCIe
> > endpoint.
>
> So we merged cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip
> PCIe controller") when it actually didn't work? Ouch. Thanks for
> fixing it and testing it.
It seems it wasn't fully tested, the code compiles and kernel module loads,
but further functionality didn't seem to have been tested
(e.g., lspci, and with the pcitest tool and pci_endpoit_test_driver).
>
> For the next iteration, can you please update these subject lines and
> commit logs to:
Thank you, I will prepare the changes and add them to the next iteration
with changes from other comments that may arise.
>
> - Use imperative mood, i.e., read like a command, instead of a past
> tense description of what was done. For example, say "Remove
> writes to unused registers" instead of "Removed writes ..."
>
> - Be more specific when possible. "Fix" conveys no information
> about the actual code change. For example, "Fixed endpoint
> controller Configuration Request Retry Status" gives a general
> idea, but it would be more useful if it said something about
> clearing config mode after probe.
>
> - Say what the patch does in the commit log. The current ones often
> describe a *problem*, but do not explicitly say what the patch
> does. The commit log should be complete in itself even without
> the subject line, so it usually contains a slightly expanded
> version of the subject line.
>
> - Split patches that do more than one logical thing. The commit log
> for "Fixed MSI generation ..." talks about a u16/u32 shift issue,
> but the patch also adds an unrelated check for multi-function
> devices.
I will. I tried to split everything into the function it was related to, but I
now understand I should split even more so that the commit message
and changes are more tightly linked.
>
> - If a patch is a fix for an existing issue and may need to be
> backported, identify the commit that introduced the issue and add
> "Fixes: " lines. This helps distros figure out whether and how
> far to backport patches.
Does this mean I should refer to the commit cf590b078391
("PCI: rockchip: Add EP driver for Rockchip PCIe controller") ?
Because it wasn't working in the first place ?
>
> - Refer to the device consistently. I see:
> RK3399 PCI EP core
> RK3399 SoC PCIe EP core
> RK3399 PCIe endpoint core
> I vote for "RK3399 PCIe Endpoint core".
I agree.
>
> Notes about imperative mood:
> https://chris.beams.io/posts/git-commit/
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=v6.0#n94
Thank you for all the pointers, I'll take them into account for the
next iteration. This is the first time I actually submitted a series of
patches to the LKML so it's all relatively new to me.
