Re: [PATCH v7 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

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 linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html