Message-ID: <CAAVeFuJA835QCFZJcWR2SFxWq__a5KOtHHiH-OLUjyDt8+Lhhg@mail.gmail.com>
Date:	Wed, 20 Nov 2013 00:17:42 +0900
From:	Alexandre Courbot <gnurou@...il.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Alex Courbot <acourbot@...dia.com>,
	Russell King <linux@....linux.org.uk>,
	Olof Johansson <olof@...om.net>,
	Stephen Warren <swarren@...dia.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: move firmware_ops to drivers/firmware

On Wed, Nov 20, 2013 at 12:07 AM, Catalin Marinas
<catalin.marinas@....com> wrote:
> On Tue, Nov 19, 2013 at 02:29:39PM +0000, Alexandre Courbot wrote:
>> On Tue, Nov 19, 2013 at 9:26 PM, Catalin Marinas
>> <catalin.marinas@....com> wrote:
>> > On Tue, Nov 19, 2013 at 02:46:55AM +0000, Alex Courbot wrote:
>> >> 2) devices have already shipped with this firmware. Are we going to just
>> >> renounce supporting them, even though the necessary support is
>> >> lightweight and fits within already existing interfaces?
>> >
>> > I'm talking only about ARMv8 here. Please see my reply to Stephen for
>> > the details of (not) reusing existing firmware.
>> >
>> >> I certainly do hope that for ARMv8 things will be different and more
>> >> standardized. But that's not something that can be guaranteed unless ARM
>> >> strongly enforces it to firmware vendors. In case such a non-standard
>> >> firmware gets used again, I *do* hope that using cpu_ops will be
>> >> preferred over saying "this device cannot be supported in mainline, ever".
>> >
>> > cpu_ops or firmware_ops is just a name and can be unified (TBD what
>> > common functionality it contains). What I don't want to encourage is
>> > each SoC registering its own firmware interface.
>>
>> Sorry, are you talking about interface as in SMC interface, or as in
>> cpu_operations/firmware_ops?
>
> Both. I don't want to see platforms defining their own SMC interface for
> no good reason. The cpu_ops/firmware_ops handling in the kernel is just
> some naming but the key is having standard SMC interfaces for CPU
> operations.

Fair enough.

>
>> >> The kernel already supports non-standard hardware, BIOS, ACPI through
>> >> hacks that are *way* more horrible than that. This should certainly not
>> >> be encouraged, but that's not a valid reason to forbid otherwise
>> >> perfectly fine devices to run mainline IMHO.
>> >
>> > So you say we should just stop trying to standardise anything because
>> > people don't care anyway. Why do we even bother with DT (or ACPI) since
>> > board files were fine in the past (with a bit more code)?
>>
>> Oh no, that's not what I am saying at all. Standardization is good.
>> PSCI is good. Of course I would prefer that the secure monitor we use
>> follow established conventions - that'd be less work to support it and
>> less hassle to get my patches merged.
>>
>> I may have misunderstood you, but I felt your mail sounded a bit like
>> "we won't merge support for firmwares that do not follow PSCI".
>
> Just to clarify it: I won't merge support for _ARMv8_ firmware that does
> not follow a standard CPU booting/power protocol supported by Linux.
> Currently we only support PSCI. If there is a need for another protocol
> and a good proposal, I'm open for discussions.
>
> The above is all related to having no SoC code under arch/arm64 (or
> board files, whatever you want to call them).
>
>> I
>> agree that whenever it is possible to support a firmware through a
>> standard interface, this should be done - no discussion. But right now
>> I have two devices that are good representatives of Tegra 4 and
>> available in stores, which I would like to see supported in mainline
>> to satisfy requests from the community for Tegra development
>> platforms, and also initiate the habit to support future
>> NVIDIA-branded devices in mainline. Their secure monitor unfortunately
>> does not follow PSCI or the SMC convention and needs a custom
>> firmware_ops. Are they unworthy of mainline?
>
> Are they ARMv8? Since we didn't have any such rules on ARMv7 and
> earlier, standard secure interface is nice to have but should not
> prevent upstreaming. I made this clear already that it is ARMv8 only,
> please don't try to generalise it.

Sorry, that was not my intention at all - I just misunderstood what
you meant. Thanks for clarifying it.

>
>> And if, by sheer misfortune, the same thing happened on an ARMv8
>> device (despite the EL1/EL3 separation), what would be the outcome?
>
> If some people get it wrong and they have to work around firmware bugs
> for devices already in the field, we may need to bend the rules (bugs do
> happen, both in software and hardware). But definitely _not_ when people
> don't even bother.

Ok, I guess for ARMv8 there is absolutely no excuse not to follow PSCI
anyways. We'll need to be careful about this one.

>
>> IMHO, more devices in mainline is beneficial to everybody, and
>> actually *encourages* SoC vendors/firmware providers to follow
>> conventions. Banning devices is what triggers the kind of "screw it"
>> reactions mentioned earlier,
>
> By following some rules and doing things in a standard way (firmware
> interface in this case), it is more likely that their SoC support
> requires minimal kernel code and it's easier to upstream and maintain.
>
>> and on the contrary once a device is in,
>> you tend to make sure the next ones follow the kernel trends because
>> you know you will need to support them in mainline as well and it will
>> make your life easier.
>
> Not really. The next device won't follow the kernel trends but just the
> same non-standard way of doing things that were accepted in the first
> place.

I guess that depends on whether you see the glass as half-empty or half-full. ;)

So just in case this was not clear already, this patch is withdrawn,
right. :P I hope the ARM maintainers will be ok with Trusted
Foundations support using firmware_ops in arch/arm for that's the best
we can do.

Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists