Re: [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm

[Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>]

On Tue, Jul 22, 2014 at 05:27:25PM +0100, Stephen Warren wrote:
> On 07/22/2014 04:27 AM, Catalin Marinas wrote:
> ...
> > ...It's also aimed at
> > pushing back on hardware people who think they can mess up, for example,
> > a GIC implementation because the rest is just software and you can
> > always add #ifdefs.
> 
> I'm very concerned about this statement.
> 
> Yes, it would be nice if all HW was sanely designed, but it's not
> always. The time to push back on bad HW design is during IP licensing
> agreements or HW design reviews, not upstreaming.

I agree about the HW design reviews. But I suspect some software people
in such companies, concerned with upstreaming Linux support, are allowed
to give feedback. And the feedback could be something like (just an
example) "if we use a standard GIC and the architected timer, sane
(!PL310-like) system caches, we get the benefit of no additional
upstream work, better virtualisation support etc". I hope someone in the
HW team would take such feedback into account rather than assume that
software and upstreaming comes for free.

Of course, we've never rejected Linux upstreaming because of the
hardware design (well, as long as Linux could reliably run on it) and I
don't plan to do this in the future, but just show that there are clear
benefits in doing something in a more standardised way (e.g. SBSA for
servers).

Even though ARM licenses the architecture, there is no way to enforce a
HW design as part of the agreement (or risk not licensing the IP at
all). But there is effort to standardise things like SBSA, Trusted
Firmware.

> Any pushback during SW upstreaming simply serves to make it difficult
> for the SW people doing the upstreaming. It has zero impact on the
> current HW design (it's already shipped). It probably has zero impact on
> the next N revisions of the HW (they're already baked). It's possible it
> has zero-to-minimal impact on any future HW (end-user product
> requirements are what matter most).

I agree that pushing back during SW upstreaming is very late. But I hope
to raise the awareness earlier for ARMv8 hardware.

-- 
Catalin