[REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi All,

While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
get console / kernel messages output on the hdmi output of my ARM board / on tty0

This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d

Reverting this commit fixes this for me.

What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);"
happens before the tty0 registers stopping tty0 from becoming part of the console list
since there already is a preferred console at that time.

This is an undesirable behavior change caused by the commit in question, on boards
where there is both video output, and a serial console configured through stdout-path
we want to have console output on both as we do not know which of the 2 will actually
be hooked up by the user.

Regards,

Hans

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

Hi Hans,

On 03/16/2015 12:31 PM, Hans de Goede wrote:
> Hi All,
> 
> While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
> get console / kernel messages output on the hdmi output of my ARM board / on tty0
> 
> This is caused by:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
> 
> Reverting this commit fixes this for me.
> 
> What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);"
> happens before the tty0 registers stopping tty0 from becoming part of the console list
> since there already is a preferred console at that time.
> 
> This is an undesirable behavior change caused by the commit in question, on boards
> where there is both video output, and a serial console configured through stdout-path
> we want to have console output on both as we do not know which of the 2 will actually
> be hooked up by the user.

I don't see this as a regression, but rather a misconfiguration.

1. Your DT indicates the stdout device is a serial console; that is
   the expected outcome. Here's what ePAPR has to say on the chosen/stdout-path
   property node:

   "A string that specifies the full path to the node representing the device to be
   used for boot console output. If the character ":" is present in the value it
   terminates the path. The value may be an alias."

   If the serial console is not the stdout device then the DT should not
   claim it is.

2. The tty0 console is not now, and has never been, always enabled.

   The tty0 console is only enabled when either,
     a) there is no other console
     b) when specified on the command line (ie., "console=tty0") or
        by prom/dt.

   Your situation is akin to adding the serial console to the command line; if
   "console=tty0" is not also explicitly added, there is no boot console output
   to tty0.

3. This same breakage will happen if any other device registers a console matching
   the stdout-path at console_init() time (ie, with console_initcall() macro) before
   the dummy console. The order in which consoles are inited via console_initcall()
   is dependent on link order, so essentially not controllable across different
   subsystems (or if there were consoles defined with the arch itself).

That said, I'll look into fixing your use-case automagically without requiring
configuration changes.

Regards,
Peter Hurley

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 16-03-15 18:49, Peter Hurley wrote:
> Hi Hans,
>
> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>> Hi All,
>>
>> While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
>> get console / kernel messages output on the hdmi output of my ARM board / on tty0
>>
>> This is caused by:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>>
>> Reverting this commit fixes this for me.
>>
>> What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);"
>> happens before the tty0 registers stopping tty0 from becoming part of the console list
>> since there already is a preferred console at that time.
>>
>> This is an undesirable behavior change caused by the commit in question, on boards
>> where there is both video output, and a serial console configured through stdout-path
>> we want to have console output on both as we do not know which of the 2 will actually
>> be hooked up by the user.
>
> I don't see this as a regression, but rather a misconfiguration.

As said it is an undesirable behavior change, whether you want to call that a regression
or not is not all that interesting. Fixing it however is important, as e.g. Fedora
ARM images rely on this behavior, both "regular" arm as well as aarch64.

> 1. Your DT indicates the stdout device is a serial console; that is
>     the expected outcome. Here's what ePAPR has to say on the chosen/stdout-path
>     property node:
>
>     "A string that specifies the full path to the node representing the device to be
>     used for boot console output. If the character ":" is present in the value it
>     terminates the path. The value may be an alias."
>
>     If the serial console is not the stdout device then the DT should not
>     claim it is.
>
> 2. The tty0 console is not now, and has never been, always enabled.
>
>     The tty0 console is only enabled when either,
>       a) there is no other console
>       b) when specified on the command line (ie., "console=tty0") or
>          by prom/dt.
>
>     Your situation is akin to adding the serial console to the command line; if
>     "console=tty0" is not also explicitly added, there is no boot console output
>     to tty0.
>
> 3. This same breakage will happen if any other device registers a console matching
>     the stdout-path at console_init() time (ie, with console_initcall() macro) before
>     the dummy console. The order in which consoles are inited via console_initcall()
>     is dependent on link order, so essentially not controllable across different
>     subsystems (or if there were consoles defined with the arch itself).
>
> That said, I'll look into fixing your use-case automagically without requiring
> configuration changes.

Thanks!

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 02:12 PM, Hans de Goede wrote:
> Hi,
> 
> On 16-03-15 18:49, Peter Hurley wrote:
>> Hi Hans,
>>
>> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>>> Hi All,
>>>
>>> While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
>>> get console / kernel messages output on the hdmi output of my ARM board / on tty0
>>>
>>> This is caused by:
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>>>
>>> Reverting this commit fixes this for me.
>>>
>>> What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);"
>>> happens before the tty0 registers stopping tty0 from becoming part of the console list
>>> since there already is a preferred console at that time.
>>>
>>> This is an undesirable behavior change caused by the commit in question, on boards
>>> where there is both video output, and a serial console configured through stdout-path
>>> we want to have console output on both as we do not know which of the 2 will actually
>>> be hooked up by the user.
>>
>> I don't see this as a regression, but rather a misconfiguration.
> 
> As said it is an undesirable behavior change, whether you want to call that a regression
> or not is not all that interesting. Fixing it however is important, as e.g. Fedora
> ARM images rely on this behavior, both "regular" arm as well as aarch64.

What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 16-03-15 19:23, Peter Hurley wrote:
> On 03/16/2015 02:12 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 16-03-15 18:49, Peter Hurley wrote:
>>> Hi Hans,
>>>
>>> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>>>> Hi All,
>>>>
>>>> While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
>>>> get console / kernel messages output on the hdmi output of my ARM board / on tty0
>>>>
>>>> This is caused by:
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>>>>
>>>> Reverting this commit fixes this for me.
>>>>
>>>> What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);"
>>>> happens before the tty0 registers stopping tty0 from becoming part of the console list
>>>> since there already is a preferred console at that time.
>>>>
>>>> This is an undesirable behavior change caused by the commit in question, on boards
>>>> where there is both video output, and a serial console configured through stdout-path
>>>> we want to have console output on both as we do not know which of the 2 will actually
>>>> be hooked up by the user.
>>>
>>> I don't see this as a regression, but rather a misconfiguration.
>>
>> As said it is an undesirable behavior change, whether you want to call that a regression
>> or not is not all that interesting. Fixing it however is important, as e.g. Fedora
>> ARM images rely on this behavior, both "regular" arm as well as aarch64.
>
> What dts file is causing this problem?
> Is it in mainline or distributed only in Fedora?

This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, currently
the setting of stdout-path on these boards is done by (an unmodified) upstream u-boot.

To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using
machines, those will also output to both a serial tty and tty0 when the acpi equivalent
of stdout-path is present and points to a serial tty.

Regards,

Hans

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 02:35 PM, Hans de Goede wrote:
> To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using
> machines, those will also output to both a serial tty and tty0 when the acpi equivalent
> of stdout-path is present and points to a serial tty.

I already made comments addressing the unsuitability of the license for the
aarch64 acpi console; the proposed SPCR table format is patented by Microsoft and
licensed incompatibly with GPLv2.

That said, the aarch64 acpi console should be treated like any other prom that
starts a console and so won't suffer from this breakage.

Regards,
Peter Hurley

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 02:35 PM, Hans de Goede wrote:
> Hi,
> 
> On 16-03-15 19:23, Peter Hurley wrote:
>> On 03/16/2015 02:12 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 16-03-15 18:49, Peter Hurley wrote:
>>>> Hi Hans,
>>>>
>>>> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>>>>> Hi All,
>>>>>
>>>>> While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
>>>>> get console / kernel messages output on the hdmi output of my ARM board / on tty0
>>>>>
>>>>> This is caused by:
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>>>>>
>>>>> Reverting this commit fixes this for me.
>>>>>
>>>>> What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);"
>>>>> happens before the tty0 registers stopping tty0 from becoming part of the console list
>>>>> since there already is a preferred console at that time.
>>>>>
>>>>> This is an undesirable behavior change caused by the commit in question, on boards
>>>>> where there is both video output, and a serial console configured through stdout-path
>>>>> we want to have console output on both as we do not know which of the 2 will actually
>>>>> be hooked up by the user.
>>>>
>>>> I don't see this as a regression, but rather a misconfiguration.
>>>
>>> As said it is an undesirable behavior change, whether you want to call that a regression
>>> or not is not all that interesting. Fixing it however is important, as e.g. Fedora
>>> ARM images rely on this behavior, both "regular" arm as well as aarch64.
>>
>> What dts file is causing this problem?
>> Is it in mainline or distributed only in Fedora?
> 
> This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, currently
> the setting of stdout-path on these boards is done by (an unmodified) upstream u-boot.

You forgot to mention my patch is not very likely to break anything
in the wild since _you_ upstreamed the dependency only 3 weeks ago [1].

And what "Fedora ARM images rely on this behavior"?

I don't appreciate the deception.

Regards,
Peter Hurley

[1] git log from u-boot repo

commit f3133962f469a8b6b9ba237ba670f0ca7c88a02e
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Feb 20 16:55:12 2015 +0100

    sunxi: Set the /chosen/stdout-path fdt property for sunxi boards
    
    While discussing with some people how to get the Linux kernel to do the
    right thing wrt sending output to both the serial console and the
    hdmi out / lcd screen when booting on ARM devices, Grant Likely pointed out
    that there already is a solution for this.
    
    All we need to do is set the /chosen/stdout-path fdt property, and if no
    console= arguments were specified on the kernel commandline the kernel
    will honor this and add this device as a console (next to the primary
    video output on hdmi).
    
    And u-boot already has support for setting this, all we need to do is
    define OF_STDOUT_PATH and then everything will just work ootb, without
    people needing to meddle with adding console= arguments in extlinux.conf .
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Ian Campbell <ijc@hellion.org.uk>
    Reviewed-by: Tom Rini <trini@ti.com>

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index f5efebb..0b4f0a0 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -210,6 +210,20 @@ extern int soft_i2c_gpio_scl;
 #define CONFIG_CONS_INDEX              1       /* UART0 */
 #endif
 
+#if CONFIG_CONS_INDEX == 1
+#ifdef CONFIG_MACH_SUN9I
+#define OF_STDOUT_PATH		"/soc/serial@07000000:115200"
+#else
+#define OF_STDOUT_PATH		"/soc@01c00000/serial@01c28000:115200"
+#endif
+#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
+#define OF_STDOUT_PATH		"/soc@01c00000/serial@01c28400:115200"
+#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
+#define OF_STDOUT_PATH		"/soc@01c00000/serial@01f02800:115200"
+#else
+#error Unsupported console port nr. Please fix stdout-path in sunxi-common.h.
+#endif
+
 /* GPIO */
 #define CONFIG_SUNXI_GPIO
 #define CONFIG_SPL_GPIO_SUPPORT

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Peter Hurley <peter@hurleysoftware.com> writes:

> I don't see this as a regression, but rather a misconfiguration.

It breaks booting on PowerMac.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 08:19 PM, Andreas Schwab wrote:
> Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org> writes:
> 
>> I don't see this as a regression, but rather a misconfiguration.
> 
> It breaks booting on PowerMac.

It doesn't boot?

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Peter Hurley <peter@hurleysoftware.com> writes:

> On 03/16/2015 08:19 PM, Andreas Schwab wrote:
>> Peter Hurley <peter@hurleysoftware.com> writes:
>> 
>>> I don't see this as a regression, but rather a misconfiguration.
>> 
>> It breaks booting on PowerMac.
>
> It doesn't boot?

Yes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 08:35 PM, Andreas Schwab wrote:
> Peter Hurley <peter@hurleysoftware.com> writes:
> 
>> On 03/16/2015 08:19 PM, Andreas Schwab wrote:
>>> Peter Hurley <peter@hurleysoftware.com> writes:
>>>
>>>> I don't see this as a regression, but rather a misconfiguration.
>>>
>>> It breaks booting on PowerMac.
>>
>> It doesn't boot?
> 
> Yes.

Ok, thanks for the report.

Can you attach
1) your .dts
2) your .config
3) complete dmesg from 4.0-rc4 boot with that patch reverted?

Do you have a serial console hooked up?

Regards,
Peter Hurley
 

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Geert Uytterhoeven]

On Tue, Mar 17, 2015 at 1:46 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On 03/16/2015 08:35 PM, Andreas Schwab wrote:
>> Peter Hurley <peter@hurleysoftware.com> writes:
>>> On 03/16/2015 08:19 PM, Andreas Schwab wrote:
>>>> Peter Hurley <peter@hurleysoftware.com> writes:
>>>>> I don't see this as a regression, but rather a misconfiguration.
>>>>
>>>> It breaks booting on PowerMac.
>>>
>>> It doesn't boot?
>>
>> Yes.
>
> Ok, thanks for the report.
>
> Can you attach
> 1) your .dts

Note that this is a PowerMac, so there's no DTS, only a real DT passed by
the Firmware.

> Do you have a serial console hooked up?

Most probably, the chosen/stdout-path is provided automatically by the
firmware, even if no serial console is present. Andreas, is that correct?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 16-03-15 23:36, Peter Hurley wrote:
> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 16-03-15 19:23, Peter Hurley wrote:
>>> On 03/16/2015 02:12 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 16-03-15 18:49, Peter Hurley wrote:
>>>>> Hi Hans,
>>>>>
>>>>> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
>>>>>> get console / kernel messages output on the hdmi output of my ARM board / on tty0
>>>>>>
>>>>>> This is caused by:
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>>>>>>
>>>>>> Reverting this commit fixes this for me.
>>>>>>
>>>>>> What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);"
>>>>>> happens before the tty0 registers stopping tty0 from becoming part of the console list
>>>>>> since there already is a preferred console at that time.
>>>>>>
>>>>>> This is an undesirable behavior change caused by the commit in question, on boards
>>>>>> where there is both video output, and a serial console configured through stdout-path
>>>>>> we want to have console output on both as we do not know which of the 2 will actually
>>>>>> be hooked up by the user.
>>>>>
>>>>> I don't see this as a regression, but rather a misconfiguration.
>>>>
>>>> As said it is an undesirable behavior change, whether you want to call that a regression
>>>> or not is not all that interesting. Fixing it however is important, as e.g. Fedora
>>>> ARM images rely on this behavior, both "regular" arm as well as aarch64.
>>>
>>> What dts file is causing this problem?
>>> Is it in mainline or distributed only in Fedora?
>>
>> This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, currently
>> the setting of stdout-path on these boards is done by (an unmodified) upstream u-boot.
>
> You forgot to mention my patch is not very likely to break anything
> in the wild since _you_ upstreamed the dependency only 3 weeks ago [1].

I contacted Grant Likely a while ago about how to get the same behavior we
have on aarch64 (console on both video output/tty0 and a serial tty by default)
on devicetree based platforms and he pointed to stdout-path, and then I wrote
the patch.

I did this after talking to several Fedora ARM people about the problems we've with boards
where we have both a video output and a serial console, such as on eg also Rasberry Pi-s,
and the conclusion was that there is no single way for users to use these boards, so we
must show boot messages on both, so that if things fail the user gets a chance to see
how / why things fail. And passing a console= argument does not work here, we (the
distro) need something which will just work everywhere, and we had that until your
patch broke things.

> And what "Fedora ARM images rely on this behavior"?

All of them, Fedora ARM images are generic and use a multi-platform kernel, so any
supported board which has a serial console connector + video output needs this to work.

More specifically the Fedora nightly composes of F-22 which contain u-boot
v2015.04-rc3 which contains the sunxi commit I gave *as an example*.

> I don't appreciate the deception.

There is no deception sunxi happens to be the ARM SOC I do a lot of work on, but it
is hardly the only user of stdout-path while also having video-output / tty0.

Note that my initial mail did not mention sunxi at all. You asked for an example, and
now providing the example is deception ???

I can understand that your unhappy to hear that your patch breaks things, but please
stop blaming the messenger.

I've been in your shoes were a kernel patch of mine caused a behavioral changed and
people saw that as a regression. In my case it had to escalate to Linus, and Linus
ordered the subsys maintainer to revert my patch, before I saw that I was wrong.
I had to cool off a bit after that before I realized that Linus was actually right,
the no regressions policy we have in the kernel is a very sensible one, and you
cannot just go and change behavior people rely on, because that indeed is a
REGRESSION.

TBH I do not understand why we're even arguing here, AFAICT the behavior change
is an unwanted side-effect of your patch, so the solution is to rewrite the patch
so that we get the same end result (not turning off bootconsole-s too early) without
the unwanted side-effect, and you agreed to work on that ?

Regards,

Hans

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 17-03-15 01:19, Andreas Schwab wrote:
> Peter Hurley <peter@hurleysoftware.com> writes:
>
>> I don't see this as a regression, but rather a misconfiguration.
>
> It breaks booting on PowerMac.

Actually that is more likely to be caused by:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=106937e8ccdcf0f4b95fbf0fe9abd42766cade33

Try reverting that one, also see:

http://www.spinics.net/lists/stable/msg82872.html

Note that if either if these patches are the culprit likely
your system is still booting you're just not getting any
messages on either video output (caused by the commit discussed
in this thread) nor on a serial console (caused by the 106937e8
commit). If you've a network interface which comes up automatically
try pinging it.

Regards,

Hans

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Leif Lindholm]

On Tue, Mar 17, 2015 at 09:25:32AM +0100, Hans de Goede wrote:
> On 17-03-15 01:19, Andreas Schwab wrote:
> >Peter Hurley <peter@hurleysoftware.com> writes:
> >
> >>I don't see this as a regression, but rather a misconfiguration.
> >
> >It breaks booting on PowerMac.
> 
> Actually that is more likely to be caused by:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=106937e8ccdcf0f4b95fbf0fe9abd42766cade33

If so, I would appreciate a test of my proposed fix:
http://www.spinics.net/lists/stable/msg82878.html

Regards,

Leif

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 17-03-15 11:09, Leif Lindholm wrote:
> On Tue, Mar 17, 2015 at 09:25:32AM +0100, Hans de Goede wrote:
>> On 17-03-15 01:19, Andreas Schwab wrote:
>>> Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org> writes:
>>>
>>>> I don't see this as a regression, but rather a misconfiguration.
>>>
>>> It breaks booting on PowerMac.
>>
>> Actually that is more likely to be caused by:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=106937e8ccdcf0f4b95fbf0fe9abd42766cade33
>
> If so, I would appreciate a test of my proposed fix:
> http://www.spinics.net/lists/stable/msg82878.html

Yeah I have testing that on my todo list for today :)

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Rob Herring]

On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 16-03-15 23:36, Peter Hurley wrote:
>>
>> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 16-03-15 19:23, Peter Hurley wrote:
>>>>
>>>> On 03/16/2015 02:12 PM, Hans de Goede wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 16-03-15 18:49, Peter Hurley wrote:
>>>>>>
>>>>>> Hi Hans,
>>>>>>
>>>>>> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> While updating my local working tree to 4.0-rc4 this morning I
>>>>>>> noticed that I no longer
>>>>>>> get console / kernel messages output on the hdmi output of my ARM
>>>>>>> board / on tty0
>>>>>>>
>>>>>>> This is caused by:
>>>>>>>
>>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>>>>>>>
>>>>>>> Reverting this commit fixes this for me.
>>>>>>>
>>>>>>> What is happening here is that the
>>>>>>> "add_preferred_console("stdout-path", 0, NULL);"
>>>>>>> happens before the tty0 registers stopping tty0 from becoming part of
>>>>>>> the console list
>>>>>>> since there already is a preferred console at that time.
>>>>>>>
>>>>>>> This is an undesirable behavior change caused by the commit in
>>>>>>> question, on boards
>>>>>>> where there is both video output, and a serial console configured
>>>>>>> through stdout-path
>>>>>>> we want to have console output on both as we do not know which of the
>>>>>>> 2 will actually
>>>>>>> be hooked up by the user.
>>>>>>
>>>>>>
>>>>>> I don't see this as a regression, but rather a misconfiguration.
>>>>>
>>>>>
>>>>> As said it is an undesirable behavior change, whether you want to call
>>>>> that a regression
>>>>> or not is not all that interesting. Fixing it however is important, as
>>>>> e.g. Fedora
>>>>> ARM images rely on this behavior, both "regular" arm as well as
>>>>> aarch64.
>>>>
>>>>
>>>> What dts file is causing this problem?
>>>> Is it in mainline or distributed only in Fedora?
>>>
>>>
>>> This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based
>>> boards, currently
>>> the setting of stdout-path on these boards is done by (an unmodified)
>>> upstream u-boot.
>>
>>
>> You forgot to mention my patch is not very likely to break anything
>> in the wild since _you_ upstreamed the dependency only 3 weeks ago [1].
>
>
> I contacted Grant Likely a while ago about how to get the same behavior we
> have on aarch64 (console on both video output/tty0 and a serial tty by
> default)
> on devicetree based platforms and he pointed to stdout-path, and then I
> wrote
> the patch.
>
> I did this after talking to several Fedora ARM people about the problems
> we've with boards
> where we have both a video output and a serial console, such as on eg also
> Rasberry Pi-s,
> and the conclusion was that there is no single way for users to use these
> boards, so we
> must show boot messages on both, so that if things fail the user gets a
> chance to see
> how / why things fail. And passing a console= argument does not work here,
> we (the
> distro) need something which will just work everywhere, and we had that
> until your
> patch broke things.
>
>> And what "Fedora ARM images rely on this behavior"?
>
>
> All of them, Fedora ARM images are generic and use a multi-platform kernel,
> so any
> supported board which has a serial console connector + video output needs
> this to work.
>
> More specifically the Fedora nightly composes of F-22 which contain u-boot
> v2015.04-rc3 which contains the sunxi commit I gave *as an example*.
>
>> I don't appreciate the deception.
>
>
> There is no deception sunxi happens to be the ARM SOC I do a lot of work on,
> but it
> is hardly the only user of stdout-path while also having video-output /
> tty0.
>
> Note that my initial mail did not mention sunxi at all. You asked for an
> example, and
> now providing the example is deception ???
>
> I can understand that your unhappy to hear that your patch breaks things,
> but please
> stop blaming the messenger.
>
> I've been in your shoes were a kernel patch of mine caused a behavioral
> changed and
> people saw that as a regression. In my case it had to escalate to Linus, and
> Linus
> ordered the subsys maintainer to revert my patch, before I saw that I was
> wrong.
> I had to cool off a bit after that before I realized that Linus was actually
> right,
> the no regressions policy we have in the kernel is a very sensible one, and
> you
> cannot just go and change behavior people rely on, because that indeed is a
> REGRESSION.
>
> TBH I do not understand why we're even arguing here, AFAICT the behavior
> change
> is an unwanted side-effect of your patch, so the solution is to rewrite the
> patch
> so that we get the same end result (not turning off bootconsole-s too early)
> without
> the unwanted side-effect, and you agreed to work on that ?

I intend to revert this if we don't have a fix soon.

I think we just need a flag saying we've enabled the earlycon from
stdout-path or not and then add the preferred console based on that. I
assume with "earlycon" only on the command-line, getting console only
on stdout-path is okay.

Rob

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 17-03-15 14:30, Rob Herring wrote:
> On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

<snip>

>> TBH I do not understand why we're even arguing here, AFAICT the behavior
>> change
>> is an unwanted side-effect of your patch, so the solution is to rewrite the
>> patch
>> so that we get the same end result (not turning off bootconsole-s too early)
>> without
>> the unwanted side-effect, and you agreed to work on that ?
>
> I intend to revert this if we don't have a fix soon.
>
> I think we just need a flag saying we've enabled the earlycon from
> stdout-path or not and then add the preferred console based on that. I
> assume with "earlycon" only on the command-line, getting console only
> on stdout-path is okay.

Yes, if a user explicitly specifies something like "earlycon" on the
commandline then not automatically getting console output on tty0 is
fine AFAICT. The use case important for me / distros is when no
console= (or related) arguments are present on the cmdline at all,
then the desired behavior is to have console output on tty0 as well
as on any serial console specified with stdout-path.

Thanks & Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/17/2015 09:43 AM, Hans de Goede wrote:
> Hi,
> 
> On 17-03-15 14:30, Rob Herring wrote:
>> On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> 
> <snip>
> 
>>> TBH I do not understand why we're even arguing here, AFAICT the behavior
>>> change
>>> is an unwanted side-effect of your patch, so the solution is to rewrite the
>>> patch
>>> so that we get the same end result (not turning off bootconsole-s too early)
>>> without
>>> the unwanted side-effect, and you agreed to work on that ?
>>
>> I intend to revert this if we don't have a fix soon.
>>
>> I think we just need a flag saying we've enabled the earlycon from
>> stdout-path or not and then add the preferred console based on that. I
>> assume with "earlycon" only on the command-line, getting console only
>> on stdout-path is okay.
> 
> Yes, if a user explicitly specifies something like "earlycon" on the
> commandline then not automatically getting console output on tty0 is
> fine AFAICT. The use case important for me / distros is when no
> console= (or related) arguments are present on the cmdline at all,
> then the desired behavior is to have console output on tty0 as well
> as on any serial console specified with stdout-path.

The issues raised by this patch have nothing to do with earlycon.

1. PowerPC boot crash - the report with the most troubleshooting info right now
   implicates some buffer overflow or console mismanagement triggered by simply
   having defined a preferred console. This needs to be figured out regardless,
   and this is what I'm working right now.

2. Hans' use-case was _already broken_ even before this patch; _any_ driver
   that adds a preferred console before the vt console driver will cause
   this problem. So again, this needs to be fixed regardless.

Regards,
Peter Hurley

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Jon Masters]

On 03/16/2015 03:46 PM, Peter Hurley wrote:
> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>> To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using
>> machines, those will also output to both a serial tty and tty0 when the acpi equivalent
>> of stdout-path is present and points to a serial tty.
> 
> I already made comments addressing the unsuitability of the license for the
> aarch64 acpi console;

Yes, you did. However, I believe you might have outdated information.
Have you read the SPCR in the past few months, or are you looking at a
version prior to update that was made in October of 2014?

> the proposed SPCR table format is patented by Microsoft and
> licensed incompatibly with GPLv2.

Can you be specific about your concerns? The license has already been
changed once (I instigated the request that lead to that change to drop
several pages of terse terms that used to cover the first few pages). I
have found the Microsoft team extremely responsive and amenable to
resolving issues, so if you would do us the service of articulating what
the concern is, I'll reach back out and get that addressed. I have a
direct line into their server and legal teams to discuss this issue.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

Hi Jon,

On 03/17/2015 12:48 PM, Jon Masters wrote:
> On 03/16/2015 03:46 PM, Peter Hurley wrote:
>> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>>> To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using
>>> machines, those will also output to both a serial tty and tty0 when the acpi equivalent
>>> of stdout-path is present and points to a serial tty.
>>
>> I already made comments addressing the unsuitability of the license for the
>> aarch64 acpi console;
> 
> Yes, you did. However, I believe you might have outdated information.
> Have you read the SPCR in the past few months, or are you looking at a
> version prior to update that was made in October of 2014?

The version of the Serial Port Console Redirection Table specification
I was referring to is downloadable here:

https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132%28v=vs.85%29.aspx

That page says Last Updated: October 21, 2014

The cover page of that downloaded specification has this text:

"
Patent Notice. Microsoft provides you certain patent rights for implementations of this specification under the terms of Microsoft’s Community Promise, available at http://www.microsoft.com/openspecifications/en/us/programs/community-promise/default.aspx. 
Version 1.02 — October 9, 2014
"

>> the proposed SPCR table format is patented by Microsoft and
>> licensed incompatibly with GPLv2.
> 
> Can you be specific about your concerns? The license has already been
> changed once (I instigated the request that lead to that change to drop
> several pages of terse terms that used to cover the first few pages). I
> have found the Microsoft team extremely responsive and amenable to
> resolving issues, so if you would do us the service of articulating what
> the concern is, I'll reach back out and get that addressed. I have a
> direct line into their server and legal teams to discuss this issue.

Well, I'm deducing somewhat here because the code that would use the
SPCR table format has not been submitted. So I don't _know_ what license(s)
you intend to submit with.

But assuming you're using some part of the SPCR specification to implement
the aarch64 acpi console, then my concern stems from the incompatibility
between GPL v2 and the Microsoft Community Promise license.

In order for you to submit code to mainline, you (or rather, the submitter)
must certify that you have the legal right to do so. That's spelled out
in Documentation/SubmittingPatches, under 'Developer's Certficate of Origin 1.1'.

So if you and Microsoft have worked out some deal where Microsoft has
licensed the SPCR spec to you under GPL v2 terms, then, great! there is no
problem.

However, if Microsoft is licensing your use of the SPCR specification
under the Microsoft Community Promise and you intend license your submission
with the same, then the problem is that the Microsoft Community Promise
License asserts additional limitations which are not compatible with GPL v2;
specifically, this text:

[from https://msdn.microsoft.com/en-us/openspecifications/dn646766 ]

"If you file, maintain, or voluntarily participate in a patent infringement lawsuit
against a Microsoft implementation of any Covered Specification, then this personal
promise does not apply with respect to any Covered Implementation made or used by you."


IOW, if I sue Microsoft for patent infringement ste,ming from their use of
Microsoft XML Document Object Model Level 1 Standards Support Document
(which infringes on patents I own), then my embedded aarch64 kernel - which
merely contains your implementation - is no longer covered under the terms
of the license.

Now, that's just my interpretation of it; maybe the Linux Foundation's
lawyers would see it differently.

Regards,
Peter Hurley

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Most probably, the chosen/stdout-path is provided automatically by the
> firmware, even if no serial console is present. Andreas, is that correct?

There is only chosen/linux,stdout-path, pointing to the display device.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Hans de Goede <hdegoede@redhat.com> writes:

> Actually that is more likely to be caused by:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=106937e8ccdcf0f4b95fbf0fe9abd42766cade33
>
> Try reverting that one, also see:

That doesn't help.

> Note that if either if these patches are the culprit likely
> your system is still booting you're just not getting any
> messages on either video output

No, it is panicking.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Peter Hurley <peter@hurleysoftware.com> writes:

> It doesn't boot?

It boots right into user space, but the initrd doesn't like something
(perhaps the missing console) and exits.  Note that the framebuffer
console does work, but all I see are the penguins.

[    6.235604] Warning: unable to open an initial console.
[    6.237611] Freeing unused kernel memory: 2156K (c000000000a0a000 - c000000000c25000)
[    6.262059] mount (70) used greatest stack depth: 10064 bytes left
[    6.298795] mkdir (76) used greatest stack depth: 9760 bytes left
[    6.376450] sysrq: SysRq : Changing Loglevel
[    6.376513] sysrq: Loglevel set to 1
[    6.430512] systemd-udevd[111]: starting version 208
[    6.488367] udevadm (112) used greatest stack depth: 9312 bytes left
[    6.605581] ata_id (127) used greatest stack depth: 8400 bytes left
[    8.578710] btrfs (217) used greatest stack depth: 8032 bytes left
[    8.700698] PM: Starting manual resume from disk
[   13.354795] EXT4-fs (dm-1): mounting ext3 file system using the ext4 subsystem
[   13.391899] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[   23.852033] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[   23.852033] 
[   23.852067] CPU: 1 PID: 1 Comm: run-init Not tainted 4.0.0-rc4-test #27
[   23.852078] Call Trace:
[   23.852095] [c0000001ee0bbb30] [c0000000006f8f64] .dump_stack+0x88/0xa8 (unreliable)
[   23.852118] [c0000001ee0bbbb0] [c0000000006f52f8] .panic+0xe8/0x284
[   23.852139] [c0000001ee0bbc50] [c000000000045b38] .do_exit+0x550/0xa08
[   23.852156] [c0000001ee0bbd30] [c000000000047178] .do_group_exit+0x48/0xbc
[   23.852173] [c0000001ee0bbdc0] [c000000000047200] .__wake_up_parent+0x0/0x38
[   23.852192] [c0000001ee0bbe30] [c000000000007d18] system_call+0x38/0xd0

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/17/2015 03:35 PM, Andreas Schwab wrote:
> Peter Hurley <peter@hurleysoftware.com> writes:
> 
>> It doesn't boot?
> 
> It boots right into user space, but the initrd doesn't like something
> (perhaps the missing console) and exits.  Note that the framebuffer
> console does work, but all I see are the penguins.
> 
> [    6.235604] Warning: unable to open an initial console.

Thanks, Andreas. I had figured out from your earlier email that your
specific breakage was the absence of any console.

Regards,
Peter Hurley

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/17/2015 03:44 PM, Peter Hurley wrote:
> On 03/17/2015 03:35 PM, Andreas Schwab wrote:
>> Peter Hurley <peter@hurleysoftware.com> writes:
>>
>>> It doesn't boot?
>>
>> It boots right into user space, but the initrd doesn't like something
>> (perhaps the missing console) and exits.  Note that the framebuffer
>> console does work, but all I see are the penguins.
>>
>> [    6.235604] Warning: unable to open an initial console.
> 
> Thanks, Andreas. I had figured out from your earlier email that your
> specific breakage was the absence of any console.

Would you share what the actual prom stdout string value is?
(linux,stdout-path is equivalent)

Regards,
Peter Hurley

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/17/2015 10:20 AM, Peter Hurley wrote:
> On 03/17/2015 09:43 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 17-03-15 14:30, Rob Herring wrote:
>>> On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> <snip>
>>
>>>> TBH I do not understand why we're even arguing here, AFAICT the behavior
>>>> change
>>>> is an unwanted side-effect of your patch, so the solution is to rewrite the
>>>> patch
>>>> so that we get the same end result (not turning off bootconsole-s too early)
>>>> without
>>>> the unwanted side-effect, and you agreed to work on that ?
>>>
>>> I intend to revert this if we don't have a fix soon.
>>>
>>> I think we just need a flag saying we've enabled the earlycon from
>>> stdout-path or not and then add the preferred console based on that. I
>>> assume with "earlycon" only on the command-line, getting console only
>>> on stdout-path is okay.
>>
>> Yes, if a user explicitly specifies something like "earlycon" on the
>> commandline then not automatically getting console output on tty0 is
>> fine AFAICT. The use case important for me / distros is when no
>> console= (or related) arguments are present on the cmdline at all,
>> then the desired behavior is to have console output on tty0 as well
>> as on any serial console specified with stdout-path.
> 
> The issues raised by this patch have nothing to do with earlycon.
> 
> 1. PowerPC boot crash - the report with the most troubleshooting info right now
>    implicates some buffer overflow or console mismanagement triggered by simply
>    having defined a preferred console. This needs to be figured out regardless,
>    and this is what I'm working right now.
> 
> 2. Hans' use-case was _already broken_ even before this patch; _any_ driver
>    that adds a preferred console before the vt console driver will cause
>    this problem. So again, this needs to be fixed regardless.

Rob,

You're right; this patch will need to be reverted. I'll send you a revert.

Regards,
Peter Hurley

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Peter Hurley <peter@hurleysoftware.com> writes:

> Would you share what the actual prom stdout string value is?
> (linux,stdout-path is equivalent)

You mean the contents of chosen/linux,stdout-path?

"/pci@0,f0000000/NVDA,Parent@10/NVDA,Display-B@1"

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Jon Masters]

Hi Peter,

On 03/17/2015 01:47 PM, Peter Hurley wrote:

> On 03/17/2015 12:48 PM, Jon Masters wrote:
>> On 03/16/2015 03:46 PM, Peter Hurley wrote:
>>> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>>>> To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using
>>>> machines, those will also output to both a serial tty and tty0 when the acpi equivalent
>>>> of stdout-path is present and points to a serial tty.
>>>
>>> I already made comments addressing the unsuitability of the license for the
>>> aarch64 acpi console;
>>
>> Yes, you did. However, I believe you might have outdated information.
>> Have you read the SPCR in the past few months, or are you looking at a
>> version prior to update that was made in October of 2014?
> 
> The version of the Serial Port Console Redirection Table specification
> I was referring to is downloadable here:
> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132%28v=vs.85%29.aspx
> 
> That page says Last Updated: October 21, 2014

Ok. You've got the most recent version :) Let me predicate the following
with the assertion that I am not a lawyer and I am not offering legal
advice. But I have worked with Microsoft (and many other large hardware
and software vendors) for some time on topics related to standardization
of ARM and I am offering to reach back out to them to resolve any
legitimate concerns arising here. The thing we need to ascertain is
whether there is a legitimate concern.

>> Can you be specific about your concerns? The license has already been
>> changed once (I instigated the request that lead to that change to drop
>> several pages of terse terms that used to cover the first few pages). I
>> have found the Microsoft team extremely responsive and amenable to
>> resolving issues, so if you would do us the service of articulating what
>> the concern is, I'll reach back out and get that addressed. I have a
>> direct line into their server and legal teams to discuss this issue.
> 
> Well, I'm deducing somewhat here because the code that would use the
> SPCR table format has not been submitted. So I don't _know_ what license(s)
> you intend to submit with.

Fair enough. I wrote an initial quick and dirty implementation of SPCR
parsing which I handed off to a colleague to cleanup. They are indeed
planning such a submission. So such an implementation does in fact exist
and there is an intent to submit. Ultimately, ACPI based ARM systems
(and even x86 ones) will be better off for supporting SPCR. While not
required, it does obviate the need for both "console=" and "earlycon="
kernel command line parameters, and thus improves end user experience by
making console setup automatic. We decided to include SPCR in the SBBR
rather than writing a new table on the understanding that writing a new
table was otherwise the default, and a wasted effort when such a
specification already existed. The concern you raise was anticipated,
and the changes mentioned were already made. I'm sure we'll be able to
ask for additional clarification and changes also.

> So if you and Microsoft have worked out some deal where Microsoft has
> licensed the SPCR spec to you under GPL v2 terms, then, great! there is no
> problem.

I am willing to assist in brokering a discussion on this. But first we
should ascertain what is necessary here and articulate that succinctly.

<snip>

> Now, that's just my interpretation of it; maybe the Linux Foundation's
> lawyers would see it differently.

Who ultimately is going to make the legal call on this one? In other
words, would an opinion from LF be the best thing to pursue? I can reach
out and connect a few people off-list for some conversation.

Ultimately, I believe Microsoft are willing to have a productive
conversation with us on these topics. I have found them very amenable
and professional when collaborating on ARM related standardization
topics and I am sure we can resolve any issues arising here.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/17/2015 08:13 PM, Jon Masters wrote:
> Hi Peter,
> 
> On 03/17/2015 01:47 PM, Peter Hurley wrote:
> 
>> On 03/17/2015 12:48 PM, Jon Masters wrote:
>>> On 03/16/2015 03:46 PM, Peter Hurley wrote:
>>>> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>>>>> To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using
>>>>> machines, those will also output to both a serial tty and tty0 when the acpi equivalent
>>>>> of stdout-path is present and points to a serial tty.
>>>>
>>>> I already made comments addressing the unsuitability of the license for the
>>>> aarch64 acpi console;
>>>
>>> Yes, you did. However, I believe you might have outdated information.
>>> Have you read the SPCR in the past few months, or are you looking at a
>>> version prior to update that was made in October of 2014?
>>
>> The version of the Serial Port Console Redirection Table specification
>> I was referring to is downloadable here:
>>
>> https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132%28v=vs.85%29.aspx
>>
>> That page says Last Updated: October 21, 2014
> 
> Ok. You've got the most recent version :) Let me predicate the following
> with the assertion that I am not a lawyer and I am not offering legal
> advice. But I have worked with Microsoft (and many other large hardware
> and software vendors) for some time on topics related to standardization
> of ARM and I am offering to reach back out to them to resolve any
> legitimate concerns arising here. The thing we need to ascertain is
> whether there is a legitimate concern.
> 
>>> Can you be specific about your concerns? The license has already been
>>> changed once (I instigated the request that lead to that change to drop
>>> several pages of terse terms that used to cover the first few pages). I
>>> have found the Microsoft team extremely responsive and amenable to
>>> resolving issues, so if you would do us the service of articulating what
>>> the concern is, I'll reach back out and get that addressed. I have a
>>> direct line into their server and legal teams to discuss this issue.
>>
>> Well, I'm deducing somewhat here because the code that would use the
>> SPCR table format has not been submitted. So I don't _know_ what license(s)
>> you intend to submit with.
> 
> Fair enough. I wrote an initial quick and dirty implementation of SPCR
> parsing which I handed off to a colleague to cleanup. They are indeed
> planning such a submission. So such an implementation does in fact exist
> and there is an intent to submit.

I assumed that because I received no reply to my first email that this
effort had been abandoned, so I didn't bother to raise the technical
issues that plague the devicetree hack.


> Ultimately, ACPI based ARM systems
> (and even x86 ones) will be better off for supporting SPCR. While not
> required, it does obviate the need for both "console=" and "earlycon="
> kernel command line parameters, and thus improves end user experience by
> making console setup automatic.

Sure; there are several platforms/arches that already do this from proms.

> We decided to include SPCR in the SBBR
> rather than writing a new table on the understanding that writing a new
> table was otherwise the default, and a wasted effort when such a
> specification already existed. The concern you raise was anticipated,
> and the changes mentioned were already made. I'm sure we'll be able to
> ask for additional clarification and changes also.
> 
>> So if you and Microsoft have worked out some deal where Microsoft has
>> licensed the SPCR spec to you under GPL v2 terms, then, great! there is no
>> problem.
> 
> I am willing to assist in brokering a discussion on this. But first we
> should ascertain what is necessary here and articulate that succinctly.

The kernel source is licensed under GPL v2 (see ./COPYING), so contributions
are expected to be licensed under compatible terms.

Patent retaliation provisions are not compatible with GPL v2, because
those provisions assert limitations that don't exist in GPL v2.
For example, the Apache 2.0 license and the original Eclipse 1.0 license
both have patent retaliation provisions that make them incompatible
with GPL v2.

The Free Software Foundation maintains a list of free and non-free software
licenses at http://www.gnu.org/philosophy/license-list.html with
commentary on each regarding their compatibility and provisions.
FSF also maintains a licensing and compliance lab which you can contact
at licensing@fsf.org

The new(er) Microsoft Open Specification licenses are not reviewed on
that page; contacting FSF licensing is probably the best next step.

> <snip>
> 
>> Now, that's just my interpretation of it; maybe the Linux Foundation's
>> lawyers would see it differently.
> 
> Who ultimately is going to make the legal call on this one? In other
> words, would an opinion from LF be the best thing to pursue? I can reach
> out and connect a few people off-list for some conversation.

Any license outside the typical free-software licenses like GPL v2, MIT,
public domain statements, etc. will face an uphill battle at submission
time.

That said, there's no harm done in submitting the work and addressing
these issues at that time. Either it will be accepted or it won't with
an explanation of why not.

Regards,
Peter Hurley

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Jon Masters]

Hi Peter,

On 03/18/2015 09:00 AM, Peter Hurley wrote:
> On 03/17/2015 08:13 PM, Jon Masters wrote:

>>>> Can you be specific about your concerns? The license has already been
>>>> changed once (I instigated the request that lead to that change to drop
>>>> several pages of terse terms that used to cover the first few pages). I
>>>> have found the Microsoft team extremely responsive and amenable to
>>>> resolving issues, so if you would do us the service of articulating what
>>>> the concern is, I'll reach back out and get that addressed. I have a
>>>> direct line into their server and legal teams to discuss this issue.
>>>
>>> Well, I'm deducing somewhat here because the code that would use the
>>> SPCR table format has not been submitted. So I don't _know_ what license(s)
>>> you intend to submit with.
>>
>> Fair enough. I wrote an initial quick and dirty implementation of SPCR
>> parsing which I handed off to a colleague to cleanup. They are indeed
>> planning such a submission. So such an implementation does in fact exist
>> and there is an intent to submit.
> 
> I assumed that because I received no reply to my first email that this
> effort had been abandoned, so I didn't bother to raise the technical
> issues that plague the devicetree hack.

I apologize for that. These patches are currently being developed
against an internal tree and we'll get them posted for review.

>>> So if you and Microsoft have worked out some deal where Microsoft has
>>> licensed the SPCR spec to you under GPL v2 terms, then, great! there is no
>>> problem.
>>
>> I am willing to assist in brokering a discussion on this. But first we
>> should ascertain what is necessary here and articulate that succinctly.
> 
> The kernel source is licensed under GPL v2 (see ./COPYING), so contributions
> are expected to be licensed under compatible terms.

Just a sidenote, that this is a data structure, not code. There are
plenty of other specifications and standards that the kernel uses that
are licensed under a variety of terms. The specific issue seems to be
the potential for conflict over the patent language in that document as
possibly pertaining to implementations, not the specific license of the
document per se. I'll ping a few and get a conversation going.

Jon.

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/18/2015 06:46 PM, Jon Masters wrote:
> Just a sidenote, that this is a data structure, not code. There are
> plenty of other specifications and standards that the kernel uses that
> are licensed under a variety of terms. The specific issue seems to be
> the potential for conflict over the patent language in that document as
> possibly pertaining to implementations, not the specific license of the
> document per se. I'll ping a few and get a conversation going.

Strictly speaking, only the patent claim(s) are relevant.

Either,
a. your code infringes on the claim(s), in which case, the specific license
   from Microsoft is required, or
b. your code does not infringe, in which case, no license is necessary.

In case (a), all of my previous email applies; ie., the terms of the license
should be GPL v2 compatible.

In case (b), there is no actual problem. Yes, the patent notice in the
specification is a barrier, and it would be helpful to your cause if
Microsoft cited the patent numbers, but you could also just explain these
in your cover letter at submission time.

Regards,
Peter Hurley



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html