Hi Hans,

Sorry for the slow response, it was burried in my inbox.

On Sun, Aug 07, 2016 at 04:25:20PM +0200, Hans de Goede wrote:

Hi,

On 28-07-16 22:36, Hans de Goede wrote:

quoted

Hi,

On 28-07-16 20:17, Maxime Ripard wrote:

quoted

Hi Hans,

On Tue, Jul 26, 2016 at 11:07:23PM +0200, Hans de Goede wrote:

quoted

quoted

quoted

quoted

Nothing prevents you from including the orange pi pc dts, from the
orange pi plus dts.

It prevents the duplication you were trying to avoid, and it doesn't
create all those spurious errors and devices.

That would solve the copy paste problem on the kernel side, but that
would still mean adding a new u-boot defconfig for this, which means that
all the distro's which ship with prebuild u-boot binaries need to build
for yet another board, something which I would like to avoid.

Still, registering devices that are not present on the board is not an
option.

Ok, new version send.

What about the other 3 patches in this series ?

I guess the same comment applies for patch 2.

The difference is that there really is no harm at all from
enabling the extra usb controllers used on the plus 2e
on the plus and plus 2 as well, no errors, no nothing, they
just sit their as usb controllers without an usb device plugged
in. But if you insist I can do a separate dts + u-boot defconfig
for the plus 2e as well (but I would rather not).

Ping, what is the verdict on this, are you ok with the patch or
do you want me to create a separate dts file for the Orange Pi
Plus 2E, note that doing so is going to be highly confusing to
users, there are 3 plus boards:

I still believe that enabling clocks, regulators, claiming pins for
device that are entirely unused on the board is not ok.

Orange Pi Plus
Orange Pi Plus 2   (same as the original plus but with 2G RAM, uses same u-boot defconfig / dts file)

Yes, that makes sense.

Orange Pi Plus 2E  (drops the USB-hub instead using all 3 host controllers)

However, I'm really worried about this one. If we go this way, there's
essentially no going back. If for some reason we want to have a
separate DT in the future (some unforeseen quirk to apply, pin to
setup that conflicts on another board, etc.), we will be completely
screwed because our users will be expecting to use the common DT,
while it wouldn't be wise anymore.

The other way around is much easier to deal with.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160831/88e23c44/attachment.sig>