All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Wertenbroek <rick.wertenbroek@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: alberto.dassatti@heig-vd.ch, xxm@rock-chips.com,
	wenrui.li@rock-chips.com, rick.wertenbroek@heig-vd.ch,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jani Nikula" <jani.nikula@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Mikko Kovanen" <mikko.kovanen@aavamobile.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 0/8] PCI: rockchip: Fix PCIe endpoint controller driver
Date: Thu, 26 Jan 2023 16:23:57 +0100	[thread overview]
Message-ID: <CAAEEuhq9X0ppqTMp7fnZapbubf9k8xhH=u3gPva3hEpAdawK3w@mail.gmail.com> (raw)
In-Reply-To: <20230126145200.GA1270846@bhelgaas>

Hello, Bjorn
Thank you for your prompt reply and helpful comments.

Le jeu. 26 janv. 2023 à 15:52, Bjorn Helgaas <helgaas@kernel.org> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Rick Wertenbroek <rick.wertenbroek@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: alberto.dassatti@heig-vd.ch, xxm@rock-chips.com,
	wenrui.li@rock-chips.com, rick.wertenbroek@heig-vd.ch,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jani Nikula" <jani.nikula@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Mikko Kovanen" <mikko.kovanen@aavamobile.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 0/8] PCI: rockchip: Fix PCIe endpoint controller driver
Date: Thu, 26 Jan 2023 16:23:57 +0100	[thread overview]
Message-ID: <CAAEEuhq9X0ppqTMp7fnZapbubf9k8xhH=u3gPva3hEpAdawK3w@mail.gmail.com> (raw)
In-Reply-To: <20230126145200.GA1270846@bhelgaas>

Hello, Bjorn
Thank you for your prompt reply and helpful comments.

Le jeu. 26 janv. 2023 à 15:52, Bjorn Helgaas <helgaas@kernel.org> 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.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Rick Wertenbroek <rick.wertenbroek@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: alberto.dassatti@heig-vd.ch, xxm@rock-chips.com,
	wenrui.li@rock-chips.com, rick.wertenbroek@heig-vd.ch,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jani Nikula" <jani.nikula@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Mikko Kovanen" <mikko.kovanen@aavamobile.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 0/8] PCI: rockchip: Fix PCIe endpoint controller driver
Date: Thu, 26 Jan 2023 16:23:57 +0100	[thread overview]
Message-ID: <CAAEEuhq9X0ppqTMp7fnZapbubf9k8xhH=u3gPva3hEpAdawK3w@mail.gmail.com> (raw)
In-Reply-To: <20230126145200.GA1270846@bhelgaas>

Hello, Bjorn
Thank you for your prompt reply and helpful comments.

Le jeu. 26 janv. 2023 à 15:52, Bjorn Helgaas <helgaas@kernel.org> 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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-01-26 15:25 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 13:50 [PATCH 0/8] PCI: rockchip: Fix PCIe endpoint controller driver Rick Wertenbroek
2023-01-26 13:50 ` Rick Wertenbroek
2023-01-26 13:50 ` Rick Wertenbroek
2023-01-26 13:50 ` [PATCH 1/8] PCI: rockchip: Removed writes to unused registers Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50 ` [PATCH 2/8] PCI: rockchip: Fixed setup of Device ID Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50 ` [PATCH 3/8] PCI: rockchip: Fixed endpoint controller Configuration Request Retry Status Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50 ` [PATCH 4/8] PCI: rockchip: Added poll and timeout to wait for PHY PLLs to be locked Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 14:42   ` Bjorn Helgaas
2023-01-26 14:42     ` Bjorn Helgaas
2023-01-26 14:42     ` Bjorn Helgaas
2023-01-26 13:50 ` [PATCH 5/8] PCI: rockchip: Added dtsi entry for PCIe endpoint controller Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 15:23   ` Krzysztof Kozlowski
2023-01-26 15:23     ` Krzysztof Kozlowski
2023-01-26 15:23     ` Krzysztof Kozlowski
2023-01-26 15:30     ` Rick Wertenbroek
2023-01-26 15:30       ` Rick Wertenbroek
2023-01-26 15:30       ` Rick Wertenbroek
2023-01-26 15:43       ` Krzysztof Kozlowski
2023-01-26 15:43         ` Krzysztof Kozlowski
2023-01-26 15:43         ` Krzysztof Kozlowski
2023-01-27  8:42   ` ALOK TIWARI
2023-01-27  8:42     ` ALOK TIWARI
2023-01-27  8:42     ` ALOK TIWARI
2023-01-30 13:52     ` Rick Wertenbroek
2023-01-30 13:52       ` Rick Wertenbroek
2023-01-30 13:52       ` Rick Wertenbroek
2023-01-30 15:04   ` Rob Herring
2023-01-30 15:04     ` Rob Herring
2023-01-30 15:04     ` Rob Herring
2023-01-26 13:50 ` [PATCH 6/8] PCI: rockchip: Fixed window mapping and address translation for endpoint Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50 ` [PATCH 7/8] PCI: rockchip: Fixed legacy IRQ generation " Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 15:25   ` Krzysztof Kozlowski
2023-01-26 15:25     ` Krzysztof Kozlowski
2023-01-26 15:25     ` Krzysztof Kozlowski
2023-01-28  9:19   ` kernel test robot
2023-01-28  9:19     ` kernel test robot
2023-01-28  9:19     ` kernel test robot
2023-01-26 13:50 ` [PATCH 8/8] PCI: rockchip: Fixed MSI generation from PCIe endpoint core Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 13:50   ` Rick Wertenbroek
2023-01-26 15:26   ` Krzysztof Kozlowski
2023-01-26 15:26     ` Krzysztof Kozlowski
2023-01-26 15:26     ` Krzysztof Kozlowski
2023-01-26 14:52 ` [PATCH 0/8] PCI: rockchip: Fix PCIe endpoint controller driver Bjorn Helgaas
2023-01-26 14:52   ` Bjorn Helgaas
2023-01-26 14:52   ` Bjorn Helgaas
2023-01-26 15:23   ` Rick Wertenbroek [this message]
2023-01-26 15:23     ` Rick Wertenbroek
2023-01-26 15:23     ` Rick Wertenbroek
2023-01-26 15:49     ` Bjorn Helgaas
2023-01-26 15:49       ` Bjorn Helgaas
2023-01-26 15:49       ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAEEuhq9X0ppqTMp7fnZapbubf9k8xhH=u3gPva3hEpAdawK3w@mail.gmail.com' \
    --to=rick.wertenbroek@gmail.com \
    --cc=alberto.dassatti@heig-vd.ch \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=helgaas@kernel.org \
    --cc=jani.nikula@intel.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    --cc=mikko.kovanen@aavamobile.com \
    --cc=rick.wertenbroek@heig-vd.ch \
    --cc=robh+dt@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=wenrui.li@rock-chips.com \
    --cc=xxm@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.