On 19 April 2016 at 17:11, Chen-Yu Tsai <wens@xxxxxxxx> wrote: > On Tue, Apr 19, 2016 at 10:46 PM, <martinayotte@xxxxxxxxx> 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. +1 for what Wen is saying here. If the pins go to a header then it's best to leave it as a GPIO. Uart2 on the mk808c is enabled as it's used for Bluetooth. CK > >> 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 > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@xxxxxxxxxxxxxxxx. > For more options, visit https://groups.google.com/d/optout. -- 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
