On Thu, Apr 12, 2018 at 2:10 PM, Andreas Färber <afaerber@xxxxxxx> wrote: > Am 12.04.2018 um 11:04 schrieb Linus Walleij: >> On Wed, Apr 4, 2018 at 7:22 PM, Manivannan Sadhasivam >> <manivannan.sadhasivam@xxxxxxxxxx> wrote: >> >>> Add pinctrl driver for Actions Semi S900 SoC. The driver supports >>> pinctrl, pinmux and pinconf functionalities through a range of registers >>> common to both gpio driver and pinctrl driver. >>> >>> Pinmux functionality is available only for the pin groups while the >>> pinconf functionality is available for both pin groups and individual >>> pins. >>> >>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx> >> >> Patch applied for v4.18 >> >> GOOD WORK! >> >> We really need to get this in so that Andreas can work on S500 >> patches with this as a base. > > No, I refused to do that. If his patches get merged, Mani offered that > he will take care of rebasing/rewriting S500 part. OK then. >> If any review comments still remain they can surely be addressed >> with incremental improvement patches. > > My biggest problem was/is that Mani designed his structs totally > different from mine, with no explanation why or how they correlate. This kind of clashes happen all the time because of parallel work. As much as we all hate to reimplement stuff just because coordination is not perfect, it still invariably happens, it's just a natural flaw to the way asynchronous development without project managers work. But what is important to keep in mind is that there is no bad intent from anyone here, you are both enthusiastic contributors and let's keep this friendly. If Manivannan has already offered to update your patch, that's great. If you feel any kind of annoyance or aggression toward another contributor, then I have a big problem as maintainer, and that problem is hard to solve, scary to deal with and extremely exhausting and diverting attention from important technical work, so please help me as much as you can NOT to give me this particular problem. > Also I had protested against him defining fake pins for the drive > strength. Since I did not have time to review the newer patches yet, > please make sure that this is addressed _before_ merging. Changing the > binding after the fact is a problem! This is more of a technical issue and a bit of philosophical debate on how to partition the hardware so as to be represented in the binding. Let's discuss it. Surely Manivannan can augment his DT bindings if there is a problem. With that in mind, I have a softer stance that some DT fundamentalists out there: I do not consider the DT binding as etched in stone because it was merged to the kernel tree. I see the stone-etching as something that happens when a mass-produced system is deployed with a DTB file using these bindings in its boot partition. When sold to end users. That means that these bindings can still be augmented as long as we are in prototype stage, and if we are just talking about hobbyist work using attached device trees or booting off media with DTB as a separate target image but copied from the kernel tree, we can always augment them. I guess some will disagree with me on this stance. But those are my principles. If you don't like them, I have others. :D Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
