[U-Boot] [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings

[Maxime Ripard]

Hi Andre,

On Wed, Jan 31, 2018 at 01:40:23PM +0000, Andre Przywara wrote:
> > Is this issue happening when you sync the whole DT, and would it break
> > if you just convert the EMAC binding?
> > 
> > Otherwise, we might try to revive the DTC garbage collection of unused
> > nodes patches. This would prevent us from using the overlays on such a
> > DT, but that doesn't like like an unfair tradeoff.
> 
> Well, what's the point in updating the DT if we then deviate from it
> again? I would rather suggest to postpone the DT update, until we ditch
> the MMC environment. The whole reason I wanted the update is to pass it
> on to Linux, so garbage collection will kill that purpose.

Not really, the garbage collection I had in mind is:
https://patchwork.kernel.org/patch/3840371/

ie, removing only nodes marked as such that are not referenced
anywhere in your tree (typically pinctrl nodes). It should totally be
usable from Linux, since the usable part of the DT will remain
untouched.

As I was saying, the only noticeable "glitch" would be that you don't
have nodes in the base DT anymore that used to be there, and overlays
won't be able to apply properly if they depended on those nodes.

However, that's not really bad, because:
  - U-Boot doesn't build its DT with the overlay support anyway
  - Linux in itself is pretty dumb when it comes to applying overlays
    at the moment, so there's not a lot of things you can do. The only
    user in tree (as far as I'm aware) is the FPGA manager, but it
    doesn't really apply to our SoCs.

> So what about this plan:
> - We need to do something *now* about the breakage of the 64-bit sunxi
> *_defconfigs, which do not build with origin/master (for me). I tried
> GCC 7.1.0, 7.3.0 and 6.4.0, also the actual merge point of the sunxi
> branch in addition to origin/master.
> The fix I sent (remove the Pine64 "non-plus" .dtb from the FIT image)
> was supposed do the trick, but in contrast to my test on Friday doesn't
> work (anymore?). bananapi_m64_defconfig for instance fails also (with a
> single .dtb).

Yes, we should definitely merge that patch.

> Can someone confirm this? Maybe it's worth to see what made U-Boot
> proper grow in the last few days/weeks?

I guess I'm (at least partially) to blame with the introduction of the
FAT environment...

How much size do we need?

I've looked at the gains we could have with the dtc patch mentionned
above if we flag all the PIO nodes, and its roughly around 500-800
bytes for an A64 DTS. Would it be enough?

> - Regardless of this we take the patches from this series, so U-Boot
> *can* deal with both DTs.

We should merge those patches, but I don't get why we should maintain
the compatibility with the old bindings. Yes, I know what you are
going to say, but the deal that was made about those bindings when
they were introduced was that we would simply update those bindings
when Linux would have decided.

And not maintain any kind of compatibility. Apparently, that deal has
changed without consulting or notifying anyone. Great.

And since most of that discussion has been around using the U-Boot DT
from Linux, I'm not even sure what the pro would be to keep the old
binding around.

> - We wait with any DT updates until we remove the MMC environment
> support, so that we have enough space to give U-Boot the proper .dts.
> 
> What is the current plan for the MMC environment? Remove it (or not
> enable it by default) in 2018.05?

Not enabling it by default in 2018.05, and removing the migration code
later on seems like a good idea yes.

> Having the support for both DT bindings in the EMAC driver *now* would
> allow people to build their own firmware, *configuring* out the MMC
> environment already and not suffer from any limits anymore.

I understand your frustration, and honestly, it frustrates me even
more to see that the hunt of config option and the discussion we had a
month ago are already rendered useless, and we need to do it again.

> It would just be the _defconfig build which keeps compatibility, for
> users who care.

We do agree on that :)
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: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180201/56053e42/attachment.sig>