On Mon, Sep 22, 2014 at 04:55:48PM -0600, Al Stone wrote:
> Exactly so. Or, collaborate with the hardware vendor, or a distro
> or anyone else that is a Promoter or Contributor as defined by UEFI
> [0]. The only thing to keep clear when doing so is who owns the
> intellectual property for any pr
On Tuesday, September 23, 2014 06:34:42 AM Hanjun Guo wrote:
> On Sep 23, 2014, 06:28AM, Matthew Garrett wrote:
> > On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
> >> On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
> >>> Explicit Change Request. These can only
On 09/22/2014 04:46 PM, Rafael J. Wysocki wrote:
> On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
>> On Mon, Sep 22, 2014 at 09:48:41PM +0200, Pavel Machek wrote:
>>> On Fri 2014-09-12 22:00:16, Hanjun Guo wrote:
+No code shall be accepted into the kernel unless it complies w
On 09/22/2014 01:48 PM, Pavel Machek wrote:
> On Fri 2014-09-12 22:00:16, Hanjun Guo wrote:
>> From: Graeme Gregory
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
>
>> +No code shall be accepted into the kernel unless it complies with the
>> released
>> +standards fro
On Tue, Sep 23, 2014 at 06:34:42AM +0800, Hanjun Guo wrote:
> On Sep 23, 2014, 06:28AM, Matthew Garrett wrote:
> > On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
> >> On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
> >>> Explicit Change Request. These can only b
On Sep 23, 2014, 06:28AM, Matthew Garrett wrote:
> On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
>> On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
>>> Explicit Change Request. These can only be filed by paid-up members of
>>> the UEFI Forum, so I suspect this
On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
> On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
> > Explicit Change Request. These can only be filed by paid-up members of
> > the UEFI Forum, so I suspect this requirement is going to be unworkable
> > (there's
On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
> On Mon, Sep 22, 2014 at 09:48:41PM +0200, Pavel Machek wrote:
> > On Fri 2014-09-12 22:00:16, Hanjun Guo wrote:
> > > +No code shall be accepted into the kernel unless it complies with the
> > > released
> > > +standards from UEFI
On Mon, Sep 22, 2014 at 09:48:41PM +0200, Pavel Machek wrote:
> On Fri 2014-09-12 22:00:16, Hanjun Guo wrote:
> > +No code shall be accepted into the kernel unless it complies with the
> > released
> > +standards from UEFI ASWG. If there are features missing from ACPI to make
> > it
> > +function
On Fri 2014-09-12 22:00:16, Hanjun Guo wrote:
> From: Graeme Gregory
>
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
> +No code shall be accepted into the kernel unless it complies with the
> released
> +standards from UEFI ASWG. If there are features missing from ACPI t
On 09/18/2014 07:20 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 17, 2014 04:40:36 PM Graeme Gregory wrote:
>> On Thu, Sep 18, 2014 at 01:22:10AM +0200, Arnd Bergmann wrote:
>>> On Wednesday 17 September 2014, Graeme Gregory wrote:
It sounds like from the discussions in other threads
On Wednesday, September 17, 2014 04:40:36 PM Graeme Gregory wrote:
> On Thu, Sep 18, 2014 at 01:22:10AM +0200, Arnd Bergmann wrote:
> > On Wednesday 17 September 2014, Graeme Gregory wrote:
> > > It sounds like from the discussions in other threads that ARM64 should
> > > be following x86 and re-us
On Thu, Sep 18, 2014 at 12:40:36AM +0100, Graeme Gregory wrote:
> On Thu, Sep 18, 2014 at 01:22:10AM +0200, Arnd Bergmann wrote:
> > On Wednesday 17 September 2014, Graeme Gregory wrote:
> > > It sounds like from the discussions in other threads that ARM64 should
> > > be following x86 and re-using
On Thu, Sep 18, 2014 at 01:22:10AM +0200, Arnd Bergmann wrote:
> On Wednesday 17 September 2014, Graeme Gregory wrote:
> > It sounds like from the discussions in other threads that ARM64 should
> > be following x86 and re-using DT bindings here. In which case there is
> > not need to submit things
On Wednesday 17 September 2014, Graeme Gregory wrote:
> It sounds like from the discussions in other threads that ARM64 should
> be following x86 and re-using DT bindings here. In which case there is
> not need to submit things to UEFI organisation.
>
> What I got a little lost in has there been a
On 2014年09月18日 04:11, Rafael J. Wysocki wrote:
> On Wednesday, September 17, 2014 08:22:59 PM Matthew Garrett wrote:
>> On Wed, Sep 17, 2014 at 09:37:42PM +0200, Rafael J. Wysocki wrote:
>>
>>> There are no implied IP issues with using the information there I know of
>>> and
>>> if there's any fin
On Wed, Sep 17, 2014 at 10:11:13PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 17, 2014 08:22:59 PM Matthew Garrett wrote:
> > Using the information should be fine, but my understanding of the UEFI
> > forum rules is that any submissions to UEFI specs must be from UEFI
> > forum mem
On Wednesday, September 17, 2014 08:22:59 PM Matthew Garrett wrote:
> On Wed, Sep 17, 2014 at 09:37:42PM +0200, Rafael J. Wysocki wrote:
>
> > There are no implied IP issues with using the information there I know of
> > and
> > if there's any fine print anywhere that may suggest so, please let m
On 09/17/2014 03:22 PM, Matthew Garrett wrote:
> On Wed, Sep 17, 2014 at 09:37:42PM +0200, Rafael J. Wysocki wrote:
>
>> There are no implied IP issues with using the information there I know of and
>> if there's any fine print anywhere that may suggest so, please let me know.
>
> Using the infor
On Wed, Sep 17, 2014 at 09:37:42PM +0200, Rafael J. Wysocki wrote:
> There are no implied IP issues with using the information there I know of and
> if there's any fine print anywhere that may suggest so, please let me know.
Using the information should be fine, but my understanding of the UEFI
On Wednesday, September 17, 2014 02:44:10 AM Matthew Garrett wrote:
> On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
>
> > +Common _DSD bindings should be submitted to ASWG to be included in the
> > +document :-
> > +
> > +http://www.uefi.org/sites/default/files/resources/_DSD-impleme
On Wed, Sep 17, 2014 at 04:58:10AM -0400, Jon Masters wrote:
> On 09/16/2014 09:44 PM, Matthew Garrett wrote:
> >> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> > How are individuals/companies who aren't UEFI members supposed to do
> > this? Aren't t
On Wed, Sep 17, 2014 at 02:44:10AM +0100, Matthew Garrett wrote:
> On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
>
> > +Common _DSD bindings should be submitted to ASWG to be included in the
> > +document :-
> > +
> > +http://www.uefi.org/sites/default/files/resources/_DSD-implementa
On 09/16/2014 09:44 PM, Matthew Garrett wrote:
> On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
>
>> +Common _DSD bindings should be submitted to ASWG to be included in the
>> +document :-
>> +
>> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.ht
On Wed, Sep 17, 2014 at 02:44:10AM +0100, Matthew Garrett wrote:
> On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
> > +No code shall be accepted into the kernel unless it complies with the
> > released
> > +standards from UEFI ASWG. If there are features missing from ACPI to make
> >
On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
> +Common _DSD bindings should be submitted to ASWG to be included in the
> +document :-
> +
> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
How are individuals/companies who aren't UEFI member
On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
> From: Graeme Gregory
>
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
>
> Signed-off-by: Graeme Gregory
> Signed-off-by: Hanjun Guo
> ---
> Documentation/arm64/arm-acpi.txt | 218
> +
From: Graeme Gregory
Add documentation for the guidelines of how to use ACPI
on ARM64.
Signed-off-by: Graeme Gregory
Signed-off-by: Hanjun Guo
---
Documentation/arm64/arm-acpi.txt | 218 ++
1 file changed, 218 insertions(+)
create mode 100644 Documentatio
28 matches
Mail list logo
