All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Nowicki <tn@semihalf.com>
To: Christopher Covington <cov@codeaurora.org>, Duc Dang <dhdang@apm.com>
Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Rafael Wysocki <rafael@kernel.org>,
	linux-pci@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	Sinan Kaya <okaya@codeaurora.org>,
	Yijing Wang <wangyijing@huawei.com>,
	Andrea Gallo <andrea.gallo@linaro.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Jeffrey Hugo <jhugo@codeaurora.org>,
	linaro-acpi@lists.linaro.org,
	David Daney <ddaney@caviumnetworks.com>,
	linux-acpi@vger.kernel.org,
	Robert Richter <robert.richter@caviumnetworks.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Dongdong Liu <liudongdong3@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Liviu Dudau <Liviu.Dudau@arm.com>, Arnd Bergmann <arnd@arndb.de>,
	Jon Masters <jcm@redhat.com>, Mark Salter <msalter@redhat.com>,
	Marcin Wojtas <mw@semihalf.com>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Jayachandran C <jchandra@broadcom.com>Ard Biesheuvel <a>
Subject: Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks
Date: Wed, 29 Jun 2016 15:52:04 +0200	[thread overview]
Message-ID: <5773D284.8060404@semihalf.com> (raw)
In-Reply-To: <5773CE49.1050802@codeaurora.org>

On 29.06.2016 15:34, Christopher Covington wrote:
> I'm confused by this statement. OEMID is defined as 6 bytes long and OEM
> Table ID as 8 bytes long in the ACPI specification. As far as I can
> tell, if your string isn't exactly that long, padding up to that length
> is required.

Well, I cannot find that requirement in ACPI spec. but I might missed 
something.

I dumped my x86 machine ACPI tables and here is an example of MCFG:

$ cat mcfg.dsl
/*
  * Intel ACPI Component Architecture
  * AML/ASL+ Disassembler version 20160108-64
  * Copyright (c) 2000 - 2016 Intel Corporation
  *
  * Disassembly of mcfg.dat, Wed Jun 29 15:48:16 2016
  *
  * ACPI Data Table [MCFG]
  *
  * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
  */

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped 
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : A9
[00Ah 0010   6]                       Oem ID : "ALASKA"
[010h 0016   8]                 Oem Table ID : "A M I"
[018h 0024   4]                 Oem Revision : 01072009
[01Ch 0028   4]              Asl Compiler ID : "MSFT"
[020h 0032   4]        Asl Compiler Revision : 00000097

[024h 0036   8]                     Reserved : 0000000000000000

[02Ch 0044   8]                 Base Address : 00000000F8000000
[034h 0052   2]         Segment Group Number : 0000
[036h 0054   1]             Start Bus Number : 00
[037h 0055   1]               End Bus Number : 3F
[038h 0056   4]                     Reserved : 00000000

Raw Table Data: Length 60 (0x3C)

00000000  4d 43 46 47 3c 00 00 00  01 a9 41 4c 41 53 4b 41 
|MCFG<.....ALASKA|
00000010  41 20 4d 20 49 00 00 00  09 20 07 01 4d 53 46 54  |A M I.... 
..MSFT|
00000020  97 00 00 00 00 00 00 00  00 00 00 00 00 00 00 f8 
|................|
00000030  00 00 00 00 00 00 00 3f  00 00 00 00              |.......?....|

So in this example I have OEM table ID "A M I" 6 character long and 0 
padding.

Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Nowicki <tn@semihalf.com>
To: Christopher Covington <cov@codeaurora.org>, Duc Dang <dhdang@apm.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rafael Wysocki <rafael@kernel.org>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Sinan Kaya <okaya@codeaurora.org>,
	Jayachandran C <jchandra@broadcom.com>,
	Robert Richter <robert.richter@caviumnetworks.com>,
	Marcin Wojtas <mw@semihalf.com>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	David Daney <ddaney@caviumnetworks.com>,
	Yijing Wang <wangyijing@huawei.com>,
	Mark Salter <msalter@redhat.com>,
	linux-pci@vger.kernel.org,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	linux-acpi@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linaro-acpi@lists.linaro.org, Jon Masters <jcm@redhat.com>,
	Andrea Gallo <andrea.gallo@linaro.org>,
	jeremy.linton@arm.com, Dongdong Liu <liudongdong3@huawei.com>,
	Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Jeffrey Hugo <jhugo@codeaurora.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks
Date: Wed, 29 Jun 2016 15:52:04 +0200	[thread overview]
Message-ID: <5773D284.8060404@semihalf.com> (raw)
In-Reply-To: <5773CE49.1050802@codeaurora.org>

On 29.06.2016 15:34, Christopher Covington wrote:
> I'm confused by this statement. OEMID is defined as 6 bytes long and OEM
> Table ID as 8 bytes long in the ACPI specification. As far as I can
> tell, if your string isn't exactly that long, padding up to that length
> is required.

Well, I cannot find that requirement in ACPI spec. but I might missed 
something.

I dumped my x86 machine ACPI tables and here is an example of MCFG:

$ cat mcfg.dsl
/*
  * Intel ACPI Component Architecture
  * AML/ASL+ Disassembler version 20160108-64
  * Copyright (c) 2000 - 2016 Intel Corporation
  *
  * Disassembly of mcfg.dat, Wed Jun 29 15:48:16 2016
  *
  * ACPI Data Table [MCFG]
  *
  * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
  */

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped 
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : A9
[00Ah 0010   6]                       Oem ID : "ALASKA"
[010h 0016   8]                 Oem Table ID : "A M I"
[018h 0024   4]                 Oem Revision : 01072009
[01Ch 0028   4]              Asl Compiler ID : "MSFT"
[020h 0032   4]        Asl Compiler Revision : 00000097

[024h 0036   8]                     Reserved : 0000000000000000

[02Ch 0044   8]                 Base Address : 00000000F8000000
[034h 0052   2]         Segment Group Number : 0000
[036h 0054   1]             Start Bus Number : 00
[037h 0055   1]               End Bus Number : 3F
[038h 0056   4]                     Reserved : 00000000

Raw Table Data: Length 60 (0x3C)

00000000  4d 43 46 47 3c 00 00 00  01 a9 41 4c 41 53 4b 41 
|MCFG<.....ALASKA|
00000010  41 20 4d 20 49 00 00 00  09 20 07 01 4d 53 46 54  |A M I.... 
..MSFT|
00000020  97 00 00 00 00 00 00 00  00 00 00 00 00 00 00 f8 
|................|
00000030  00 00 00 00 00 00 00 3f  00 00 00 00              |.......?....|

So in this example I have OEM table ID "A M I" 6 character long and 0 
padding.

Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: tn@semihalf.com (Tomasz Nowicki)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks
Date: Wed, 29 Jun 2016 15:52:04 +0200	[thread overview]
Message-ID: <5773D284.8060404@semihalf.com> (raw)
In-Reply-To: <5773CE49.1050802@codeaurora.org>

On 29.06.2016 15:34, Christopher Covington wrote:
> I'm confused by this statement. OEMID is defined as 6 bytes long and OEM
> Table ID as 8 bytes long in the ACPI specification. As far as I can
> tell, if your string isn't exactly that long, padding up to that length
> is required.

Well, I cannot find that requirement in ACPI spec. but I might missed 
something.

I dumped my x86 machine ACPI tables and here is an example of MCFG:

$ cat mcfg.dsl
/*
  * Intel ACPI Component Architecture
  * AML/ASL+ Disassembler version 20160108-64
  * Copyright (c) 2000 - 2016 Intel Corporation
  *
  * Disassembly of mcfg.dat, Wed Jun 29 15:48:16 2016
  *
  * ACPI Data Table [MCFG]
  *
  * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
  */

[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped 
Configuration table]
[004h 0004   4]                 Table Length : 0000003C
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : A9
[00Ah 0010   6]                       Oem ID : "ALASKA"
[010h 0016   8]                 Oem Table ID : "A M I"
[018h 0024   4]                 Oem Revision : 01072009
[01Ch 0028   4]              Asl Compiler ID : "MSFT"
[020h 0032   4]        Asl Compiler Revision : 00000097

[024h 0036   8]                     Reserved : 0000000000000000

[02Ch 0044   8]                 Base Address : 00000000F8000000
[034h 0052   2]         Segment Group Number : 0000
[036h 0054   1]             Start Bus Number : 00
[037h 0055   1]               End Bus Number : 3F
[038h 0056   4]                     Reserved : 00000000

Raw Table Data: Length 60 (0x3C)

00000000  4d 43 46 47 3c 00 00 00  01 a9 41 4c 41 53 4b 41 
|MCFG<.....ALASKA|
00000010  41 20 4d 20 49 00 00 00  09 20 07 01 4d 53 46 54  |A M I.... 
..MSFT|
00000020  97 00 00 00 00 00 00 00  00 00 00 00 00 00 00 f8 
|................|
00000030  00 00 00 00 00 00 00 3f  00 00 00 00              |.......?....|

So in this example I have OEM table ID "A M I" 6 character long and 0 
padding.

Tomasz

  reply	other threads:[~2016-06-29 13:52 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28  7:53 [RFC PATCH v4 0/5] ECAM quirks handling for ARM64 platforms Tomasz Nowicki
2016-06-28  7:53 ` Tomasz Nowicki
2016-06-28  7:53 ` [RFC PATCH v4 1/5] PCI: Embed pci_ecam_ops in pci_config_window structure Tomasz Nowicki
2016-06-28  7:53   ` Tomasz Nowicki
2016-06-28  7:53   ` Tomasz Nowicki
2016-06-28  7:53 ` [RFC PATCH v4 2/5] PCI/ACPI: Move ACPI ECAM mapping to generic MCFG driver Tomasz Nowicki
2016-06-28  7:53   ` Tomasz Nowicki
2016-06-28  7:53   ` Tomasz Nowicki
2016-06-28  7:54 ` [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks Tomasz Nowicki
2016-06-28  7:54   ` Tomasz Nowicki
2016-06-28 13:04   ` Christopher Covington
2016-06-28 13:04     ` Christopher Covington
2016-06-28 16:12     ` Duc Dang
2016-06-28 16:12       ` Duc Dang
2016-06-28 16:12       ` Duc Dang
2016-06-29 10:48       ` Tomasz Nowicki
2016-06-29 10:48         ` Tomasz Nowicki
2016-06-29 10:48         ` Tomasz Nowicki
2016-06-29 13:34         ` Christopher Covington
2016-06-29 13:34           ` Christopher Covington
2016-06-29 13:34           ` Christopher Covington
2016-06-29 13:52           ` Tomasz Nowicki [this message]
2016-06-29 13:52             ` Tomasz Nowicki
2016-06-29 13:52             ` Tomasz Nowicki
2016-06-29 13:57             ` Ard Biesheuvel
2016-06-29 13:57               ` Ard Biesheuvel
2016-06-29 13:57               ` Ard Biesheuvel
2016-06-29 15:38             ` Jeffrey Hugo
2016-06-29 15:38               ` Jeffrey Hugo
2016-06-29 15:38               ` Jeffrey Hugo
2016-06-29 13:56           ` Ard Biesheuvel
2016-06-29 13:56             ` Ard Biesheuvel
2016-06-29 13:56             ` Ard Biesheuvel
2016-07-22 11:38             ` Robert Richter
2016-07-22 11:38               ` Robert Richter
2016-07-22 11:38               ` Robert Richter
2016-07-22 12:00               ` Ard Biesheuvel
2016-07-22 12:00                 ` Ard Biesheuvel
2016-07-22 12:00                 ` Ard Biesheuvel
2016-07-22 12:11                 ` Robert Richter
2016-07-22 12:11                   ` Robert Richter
2016-07-22 12:11                   ` Robert Richter
2016-07-25 21:56   ` Mark Salter
2016-07-25 21:56     ` Mark Salter
2016-06-28  7:54 ` [RFC PATCH v4 4/5] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller Tomasz Nowicki
2016-06-28  7:54   ` Tomasz Nowicki
2016-06-28  7:54 ` [RFC PATCH v4 5/5] PCI: thunder: Add ThunderX PEM MCFG quirk to the list Tomasz Nowicki
2016-06-28  7:54   ` Tomasz Nowicki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5773D284.8060404@semihalf.com \
    --to=tn@semihalf.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=andrea.gallo@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=cov@codeaurora.org \
    --cc=ddaney@caviumnetworks.com \
    --cc=dhdang@apm.com \
    --cc=gabriele.paoloni@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=jchandra@broadcom.com \
    --cc=jcm@redhat.com \
    --cc=jhugo@codeaurora.org \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liudongdong3@huawei.com \
    --cc=msalter@redhat.com \
    --cc=mw@semihalf.com \
    --cc=okaya@codeaurora.org \
    --cc=rafael@kernel.org \
    --cc=robert.richter@caviumnetworks.com \
    --cc=wangyijing@huawei.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.