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: > > 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. 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
