All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Covington <cov@codeaurora.org>
To: Tomasz Nowicki <tn@semihalf.com>, 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 <liudon>
Subject: Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks
Date: Wed, 29 Jun 2016 09:34:01 -0400	[thread overview]
Message-ID: <5773CE49.1050802@codeaurora.org> (raw)
In-Reply-To: <5773A773.8040700@semihalf.com>

Hi Tomasz,

On 06/29/2016 06:48 AM, Tomasz Nowicki wrote:
> On 28.06.2016 18:12, Duc Dang wrote:
>> On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington
>> <cov@codeaurora.org> wrote:
>>> Hi Tomasz,

>>> Ard's comments on v3 included:
>>>
>>> "... exact OEM table/rev id matches ..."
>>> "... substring match ... out of the question ..."

Digging through the archives I see Jon Master commented earlier to "be
careful with substring match".

>> I think having OEM Table ID as "PLAT " and then "PLAT2 " (the the 
>> next version of the SoC) is common. So yes, matching full string is
>> better as we can use "PLAT2 " in MCFG table and not worry about the
>> "PLAT" sub-string match causes the quirk to be applied
>> unintentionally.

> Note that platforms already shipped where OEM string has no padding will

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.

> have change the firmware or add 0 padding to our quirk array IDs.

The fixed 6 or 8 character string compare, as used v2 of this patchset,
will be compatible with existing firmware as best I can tell. Adding
padding to the quirk array IDs is exactly what I'm suggesting, although
all the strings I've seen are space padded rather than null padded.

Matches:
{"APM   ", "XGENE   ", 1}
{"CAVIUM", "THUNDERX", 1}
{"HISI  ", "HISI-D02", 1}
{"HISI  ", "HISI-D03", 1}
{"QCOM  ", "QDF2432 ", 1}

Given the above tuples, won't accidentally match:
(guessing at possible future ids)
{"APM   ", "XGENEi  ", 1}
{"CAVIUM", "THUNDERX", i} i != 1
{"CAVIUM", "THUNDERi", 1}
{"CAVIUM", "THUNDRXi", 1}
{"HISI  ", "HISI-D0i", 1} i != 2 && i != 3
{"QCOM  ", "QDF24ij ", 1} i != 3 && j != 2

References for APM, HiSilicon IDs:
https://lists.linaro.org/pipermail/linaro-acpi/2016-June/007108.html
https://lists.linaro.org/pipermail/linaro-acpi/2016-June/007043.html

Thanks,
Cov

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: Christopher Covington <cov@codeaurora.org>
To: Tomasz Nowicki <tn@semihalf.com>, 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 09:34:01 -0400	[thread overview]
Message-ID: <5773CE49.1050802@codeaurora.org> (raw)
In-Reply-To: <5773A773.8040700@semihalf.com>

Hi Tomasz,

On 06/29/2016 06:48 AM, Tomasz Nowicki wrote:
> On 28.06.2016 18:12, Duc Dang wrote:
>> On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington
>> <cov@codeaurora.org> wrote:
>>> Hi Tomasz,

>>> Ard's comments on v3 included:
>>>
>>> "... exact OEM table/rev id matches ..."
>>> "... substring match ... out of the question ..."

Digging through the archives I see Jon Master commented earlier to "be
careful with substring match".

>> I think having OEM Table ID as "PLAT " and then "PLAT2 " (the the 
>> next version of the SoC) is common. So yes, matching full string is
>> better as we can use "PLAT2 " in MCFG table and not worry about the
>> "PLAT" sub-string match causes the quirk to be applied
>> unintentionally.

> Note that platforms already shipped where OEM string has no padding will

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.

> have change the firmware or add 0 padding to our quirk array IDs.

The fixed 6 or 8 character string compare, as used v2 of this patchset,
will be compatible with existing firmware as best I can tell. Adding
padding to the quirk array IDs is exactly what I'm suggesting, although
all the strings I've seen are space padded rather than null padded.

Matches:
{"APM   ", "XGENE   ", 1}
{"CAVIUM", "THUNDERX", 1}
{"HISI  ", "HISI-D02", 1}
{"HISI  ", "HISI-D03", 1}
{"QCOM  ", "QDF2432 ", 1}

Given the above tuples, won't accidentally match:
(guessing at possible future ids)
{"APM   ", "XGENEi  ", 1}
{"CAVIUM", "THUNDERX", i} i != 1
{"CAVIUM", "THUNDERi", 1}
{"CAVIUM", "THUNDRXi", 1}
{"HISI  ", "HISI-D0i", 1} i != 2 && i != 3
{"QCOM  ", "QDF24ij ", 1} i != 3 && j != 2

References for APM, HiSilicon IDs:
https://lists.linaro.org/pipermail/linaro-acpi/2016-June/007108.html
https://lists.linaro.org/pipermail/linaro-acpi/2016-June/007043.html

Thanks,
Cov

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: cov@codeaurora.org (Christopher Covington)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks
Date: Wed, 29 Jun 2016 09:34:01 -0400	[thread overview]
Message-ID: <5773CE49.1050802@codeaurora.org> (raw)
In-Reply-To: <5773A773.8040700@semihalf.com>

Hi Tomasz,

On 06/29/2016 06:48 AM, Tomasz Nowicki wrote:
> On 28.06.2016 18:12, Duc Dang wrote:
>> On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington
>> <cov@codeaurora.org> wrote:
>>> Hi Tomasz,

>>> Ard's comments on v3 included:
>>>
>>> "... exact OEM table/rev id matches ..."
>>> "... substring match ... out of the question ..."

Digging through the archives I see Jon Master commented earlier to "be
careful with substring match".

>> I think having OEM Table ID as "PLAT " and then "PLAT2 " (the the 
>> next version of the SoC) is common. So yes, matching full string is
>> better as we can use "PLAT2 " in MCFG table and not worry about the
>> "PLAT" sub-string match causes the quirk to be applied
>> unintentionally.

> Note that platforms already shipped where OEM string has no padding will

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.

> have change the firmware or add 0 padding to our quirk array IDs.

The fixed 6 or 8 character string compare, as used v2 of this patchset,
will be compatible with existing firmware as best I can tell. Adding
padding to the quirk array IDs is exactly what I'm suggesting, although
all the strings I've seen are space padded rather than null padded.

Matches:
{"APM   ", "XGENE   ", 1}
{"CAVIUM", "THUNDERX", 1}
{"HISI  ", "HISI-D02", 1}
{"HISI  ", "HISI-D03", 1}
{"QCOM  ", "QDF2432 ", 1}

Given the above tuples, won't accidentally match:
(guessing at possible future ids)
{"APM   ", "XGENEi  ", 1}
{"CAVIUM", "THUNDERX", i} i != 1
{"CAVIUM", "THUNDERi", 1}
{"CAVIUM", "THUNDRXi", 1}
{"HISI  ", "HISI-D0i", 1} i != 2 && i != 3
{"QCOM  ", "QDF24ij ", 1} i != 3 && j != 2

References for APM, HiSilicon IDs:
https://lists.linaro.org/pipermail/linaro-acpi/2016-June/007108.html
https://lists.linaro.org/pipermail/linaro-acpi/2016-June/007043.html

Thanks,
Cov

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2016-06-29 13:34 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 [this message]
2016-06-29 13:34           ` Christopher Covington
2016-06-29 13:34           ` Christopher Covington
2016-06-29 13:52           ` Tomasz Nowicki
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=5773CE49.1050802@codeaurora.org \
    --to=cov@codeaurora.org \
    --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=ddaney@caviumnetworks.com \
    --cc=dhdang@apm.com \
    --cc=hanjun.guo@linaro.org \
    --cc=helgaas@kernel.org \
    --cc=jchandra@broadcom.com \
    --cc=jcm@redhat.com \
    --cc=jeremy.linton@arm.com \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=msalter@redhat.com \
    --cc=mw@semihalf.com \
    --cc=okaya@codeaurora.org \
    --cc=rafael@kernel.org \
    --cc=robert.richter@caviumnetworks.com \
    --cc=tn@semihalf.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.