On Wed, Sep 21, 2022 at 06:06:40PM -0700, Jakub Kicinski wrote: > On Thu, 22 Sep 2022 00:46:34 +0000 Yoshihiro Shimoda wrote: > > 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. All these patches should then meet up in next, and work. If any are missing, the driver should return -ENODEV or similar. 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. Andrew
