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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]