[PATCH v1 1/1] add missing UARTs pins for AllWinner H3 DTS + add new I2C entries for AllWinner H3 DTS

[Chen-Yu Tsai]

On Tue, Apr 19, 2016 at 10:46 PM,  <martinayotte at gmail.com> wrote:
> Hi ChenYu,
>
> Thanks for your comments.
>
> On Tuesday, April 19, 2016 at 7:11:50 AM UTC-4, Chen-Yu Tsai wrote:
>> Hi,
>>
>> >  arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  | 36 ++++++++++++++
>> >  arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 36 ++++++++++++++
>> >  arch/arm/boot/dts/sun8i-h3.dtsi            | 75
>>
>> First of all, you are touching 3 different files here. These should
>> be separate patches.
>
> I'm trying to understand you here, but I can't. Those 3 files changed are related each other. I could have separated the UART changes from I2C changes, but still those 3 files would have been modified at the same time for a single commit and "git patch-format" would still have created a single patch for the 3 files commit.

Try to wrap lines to 80 characters or less.

1 change per patch. You are making 3 changes here. a) adding shared
pinmux settings,
b & c) enabling uarts and i2c busses for 2 boards.

You could split them into 1 dtsi patch adding the pinmux setting, and
then 1 for each
board enabling the peripherals.

>
> Seeing all the patches that coming into the mailing lists, all of them contains multiple files patches, why should it be different here ?
>
>>
>> Secondly, our policy is to not have a default function for generic GPIO pins.
>>
>
> If this is the official policy, then why so many DTS currently present are not following the same rules, such sun6i-a31-hummingbird, sun7i-a20-olinuxino-micro, sun7i-a20-mk808c, sun7i-a20-cubietruck and so many others ?

Perhaps they were enabled before the policy was enacted, or it just
slipped through. I
contributed to a few. But for many boards we might not have schematics
or the actual
device to check.

Also, other boards having such settings is not a good argument.

> I thought the rules were there to make DTS the most default common usage definitions for most end-users in a general availability.
> Then, if someone is really in shortage of GPIOs, they could easily turn them back to "disabled" state.

How would you determine what the most common usage is for "development boards"?
If the vendor explicitly designed the pins to be used one way, and even printed
the description on the board, then you may have a valid argument. But even then,
with the C.H.I.P., they are going with DT overlays.

It shouldn't be hard for an end user to modify the DT. And with I2C devices, it
is almost a requirement.


Regards
ChenYu