Hi Andrew,

From: Andrew Lunn, Sent: Thursday, September 22, 2022 10:19 AM

On Wed, Sep 21, 2022 at 06:06:40PM -0700, Jakub Kicinski wrote:

quoted

On Thu, 22 Sep 2022 00:46:34 +0000 Yoshihiro Shimoda wrote:

quoted

I thought we have 2 types about the use of the treewide:
1) Completely depends on multiple subsystems and/or
   change multiple subsystems in a patch.
2) Convenient for review.

This patch series type is the 2) above. However, should I use
treewide for the 1) only?

I thought "treewide" means you're changing something across the tree.
If you want to get a new platform reviewed I'd just post the patches
as RFC without any prefix in the subject. But I could be wrong.

My main point (which I did a pretty poor job of actually making)
was that for the networking driver to be merged it needs to get
posted separately.

Expanding on that...

You have a clock patch, which should go via the clock subsystem Maintainer.
You have a PHY path, which should go via the generic PHY subsystem Maintainer.
You have an Ethernet driver and binding patch, which can go via netdev,
Cc: the device tree list.
And a patch to add the needed nodes to .dts files which can go via the
renesas Maintainer.

At an early RFC stage, posting them all at once can be useful, to help
see all the bits and pieces. But by the time you have code ready for
merging, it should really go via easu subsystem Maintainer.

Thank you very much for the detailed explanation. I completely understood it.

All these patches should then meet up in next, and work. If any are
missing, the driver should return -ENODEV or similar.

Yes, I did test such things.

If there are any compile time dependencies in these patches, then we
need to handle them differently. But at a very quick glance, i don't
see any.

You're correct. This patch series doesn't depend in compile time.

Best regards,
Yoshihiro Shimoda

	 Andrew