From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
To: Jon Masters <jcm@jonmasters.org>
Cc: David.Daney@cavium.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
stemerkhanov@CAVIUMNETWORKS.onmicrosoft.com,
Bjorn Helgaas <helgaas@kernel.org>,
tn@semihalf.com, bhelgaas@google.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization
Date: Wed, 15 Mar 2017 04:33:23 -0700 [thread overview]
Message-ID: <20170315113323.GA28027@localhost.localdomain> (raw)
In-Reply-To: <376ae1df-da85-e576-75d6-3ae2ab0f1b41@jonmasters.org>
Hi Jon,
On Wed, Mar 15, 2017 at 07:14:38AM -0400, Jon Masters wrote:
> Hi Bjorn, Vadim,
>
> Following up to this old thread...
>
> On 02/01/2017 10:18 AM, Bjorn Helgaas wrote:
> > On Wed, Feb 01, 2017 at 04:53:25AM -0800, Vadim Lomovtsev wrote:
>
> >>>> Because there is no such ACPI ID as "THRX0002" registered
> >>>> (http://www.uefi.org/acpi_id_list).
>
> There is still no "THRX" prefix registered with UEFI as of this morning.
>
> >>> To be pedantically correct, I think you want "THRX" registered. Then
> >>> you can manage the "0002" part internally without registering each
> >>> individual device.
>
> The upstream Linux kernel contains a quirk matching entry that looks for
> "THRX". Therefore, you have already agreed (as of at least January) that
> this is the prefix that you will use in any firmware updates to support
> the latest upstream Linux kernel. Please register this prefix promptly.
And from what I know for now - we wont going to register this
since we have already regsitered "CAV" prefix for that. And this was the part
of our discussion also.
We had a bit long review of proper implementation of legacy firmware support,
so my apologise on that.
Please take a look at link to the patchset posted by Tomasz.
https://www.spinics.net/lists/arm-kernel/msg568741.html
>
> >> Not sure if it would be registered that way, because (AFAIK)
> >> it expected to be string constructed from Vendor ID (not the Product ID) plus
> >> four hex digit manged internaly. So we suggest to change it to 177DXXXX
> >> which corresponds to Cavium PCI ID https://pci-ids.ucw.cz/pci.ids.
> >> It's also possible to use the 3-digit PNP ID, "CAV", to construct these
> >> _HID/_CID/_SUB values (http://www.uefi.org/pnp_id_list).
> >
> > My point was that you only need to register the prefix ("CAV" or
> > "THRX") of the PNP or ACPI ID. Then you manage the suffixes
> > internally. You as long as you register "CAV" or "THRX", you can
> > assign and use "THRX0002" yourself without registering that
> > specifically.
> >
And my reply here was :
"Yes, exactly. And the "CAV" perfix is already registered.
And I think will'll use it to keep things aligned to specs & rules."
> >> So the FW will be updated accordingly.
>
> Indeed.
Yes, it is now contains "CAVxxx" as _HID for device config object.
>
> The version Bjorn merged looks for "THRX". This is the version that you will
> use, and you will promptly register that prefix with UEFI and provide fixes
> for existing firmware to correctly use the solution that is upstream.
Cavium FW is updated accordingly to use already registered prefix.
For existent FW legacy support is posted by Tomasz.
>
> Thanks,
>
> Jon.
>
WBR,
Vadim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Vadim.Lomovtsev@caviumnetworks.com (Vadim Lomovtsev)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization
Date: Wed, 15 Mar 2017 04:33:23 -0700 [thread overview]
Message-ID: <20170315113323.GA28027@localhost.localdomain> (raw)
In-Reply-To: <376ae1df-da85-e576-75d6-3ae2ab0f1b41@jonmasters.org>
Hi Jon,
On Wed, Mar 15, 2017 at 07:14:38AM -0400, Jon Masters wrote:
> Hi Bjorn, Vadim,
>
> Following up to this old thread...
>
> On 02/01/2017 10:18 AM, Bjorn Helgaas wrote:
> > On Wed, Feb 01, 2017 at 04:53:25AM -0800, Vadim Lomovtsev wrote:
>
> >>>> Because there is no such ACPI ID as "THRX0002" registered
> >>>> (http://www.uefi.org/acpi_id_list).
>
> There is still no "THRX" prefix registered with UEFI as of this morning.
>
> >>> To be pedantically correct, I think you want "THRX" registered. Then
> >>> you can manage the "0002" part internally without registering each
> >>> individual device.
>
> The upstream Linux kernel contains a quirk matching entry that looks for
> "THRX". Therefore, you have already agreed (as of at least January) that
> this is the prefix that you will use in any firmware updates to support
> the latest upstream Linux kernel. Please register this prefix promptly.
And from what I know for now - we wont going to register this
since we have already regsitered "CAV" prefix for that. And this was the part
of our discussion also.
We had a bit long review of proper implementation of legacy firmware support,
so my apologise on that.
Please take a look at link to the patchset posted by Tomasz.
https://www.spinics.net/lists/arm-kernel/msg568741.html
>
> >> Not sure if it would be registered that way, because (AFAIK)
> >> it expected to be string constructed from Vendor ID (not the Product ID) plus
> >> four hex digit manged internaly. So we suggest to change it to 177DXXXX
> >> which corresponds to Cavium PCI ID https://pci-ids.ucw.cz/pci.ids.
> >> It's also possible to use the 3-digit PNP ID, "CAV", to construct these
> >> _HID/_CID/_SUB values (http://www.uefi.org/pnp_id_list).
> >
> > My point was that you only need to register the prefix ("CAV" or
> > "THRX") of the PNP or ACPI ID. Then you manage the suffixes
> > internally. You as long as you register "CAV" or "THRX", you can
> > assign and use "THRX0002" yourself without registering that
> > specifically.
> >
And my reply here was :
"Yes, exactly. And the "CAV" perfix is already registered.
And I think will'll use it to keep things aligned to specs & rules."
> >> So the FW will be updated accordingly.
>
> Indeed.
Yes, it is now contains "CAVxxx" as _HID for device config object.
>
> The version Bjorn merged looks for "THRX". This is the version that you will
> use, and you will promptly register that prefix with UEFI and provide fixes
> for existing firmware to correctly use the solution that is upstream.
Cavium FW is updated accordingly to use already registered prefix.
For existent FW legacy support is posted by Tomasz.
>
> Thanks,
>
> Jon.
>
WBR,
Vadim
WARNING: multiple messages have this Message-ID (diff)
From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
To: Jon Masters <jcm@jonmasters.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
David.Daney@cavium.com, tn@semihalf.com,
linux-kernel@vger.kernel.org,
stemerkhanov@CAVIUMNETWORKS.onmicrosoft.com,
linux-pci@vger.kernel.org, bhelgaas@google.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization
Date: Wed, 15 Mar 2017 04:33:23 -0700 [thread overview]
Message-ID: <20170315113323.GA28027@localhost.localdomain> (raw)
In-Reply-To: <376ae1df-da85-e576-75d6-3ae2ab0f1b41@jonmasters.org>
Hi Jon,
On Wed, Mar 15, 2017 at 07:14:38AM -0400, Jon Masters wrote:
> Hi Bjorn, Vadim,
>
> Following up to this old thread...
>
> On 02/01/2017 10:18 AM, Bjorn Helgaas wrote:
> > On Wed, Feb 01, 2017 at 04:53:25AM -0800, Vadim Lomovtsev wrote:
>
> >>>> Because there is no such ACPI ID as "THRX0002" registered
> >>>> (http://www.uefi.org/acpi_id_list).
>
> There is still no "THRX" prefix registered with UEFI as of this morning.
>
> >>> To be pedantically correct, I think you want "THRX" registered. Then
> >>> you can manage the "0002" part internally without registering each
> >>> individual device.
>
> The upstream Linux kernel contains a quirk matching entry that looks for
> "THRX". Therefore, you have already agreed (as of at least January) that
> this is the prefix that you will use in any firmware updates to support
> the latest upstream Linux kernel. Please register this prefix promptly.
And from what I know for now - we wont going to register this
since we have already regsitered "CAV" prefix for that. And this was the part
of our discussion also.
We had a bit long review of proper implementation of legacy firmware support,
so my apologise on that.
Please take a look at link to the patchset posted by Tomasz.
https://www.spinics.net/lists/arm-kernel/msg568741.html
>
> >> Not sure if it would be registered that way, because (AFAIK)
> >> it expected to be string constructed from Vendor ID (not the Product ID) plus
> >> four hex digit manged internaly. So we suggest to change it to 177DXXXX
> >> which corresponds to Cavium PCI ID https://pci-ids.ucw.cz/pci.ids.
> >> It's also possible to use the 3-digit PNP ID, "CAV", to construct these
> >> _HID/_CID/_SUB values (http://www.uefi.org/pnp_id_list).
> >
> > My point was that you only need to register the prefix ("CAV" or
> > "THRX") of the PNP or ACPI ID. Then you manage the suffixes
> > internally. You as long as you register "CAV" or "THRX", you can
> > assign and use "THRX0002" yourself without registering that
> > specifically.
> >
And my reply here was :
"Yes, exactly. And the "CAV" perfix is already registered.
And I think will'll use it to keep things aligned to specs & rules."
> >> So the FW will be updated accordingly.
>
> Indeed.
Yes, it is now contains "CAVxxx" as _HID for device config object.
>
> The version Bjorn merged looks for "THRX". This is the version that you will
> use, and you will promptly register that prefix with UEFI and provide fixes
> for existing firmware to correctly use the solution that is upstream.
Cavium FW is updated accordingly to use already registered prefix.
For existent FW legacy support is posted by Tomasz.
>
> Thanks,
>
> Jon.
>
WBR,
Vadim
next prev parent reply other threads:[~2017-03-15 11:33 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-30 16:25 [PATCH] PCI: ACPI: Fix ThunderX PEM initialization Vadim Lomovtsev
2017-01-30 16:25 ` Vadim Lomovtsev
2017-01-30 16:25 ` Vadim Lomovtsev
2017-01-30 17:39 ` David Daney
2017-01-30 17:39 ` David Daney
2017-01-30 17:39 ` David Daney
2017-01-30 21:12 ` Bjorn Helgaas
2017-01-30 21:12 ` Bjorn Helgaas
2017-01-30 21:12 ` Bjorn Helgaas
2017-01-31 10:28 ` Vadim Lomovtsev
2017-01-31 10:28 ` Vadim Lomovtsev
2017-01-31 14:25 ` Bjorn Helgaas
2017-01-31 14:25 ` Bjorn Helgaas
2017-01-31 14:25 ` Bjorn Helgaas
2017-01-31 14:57 ` Vadim Lomovtsev
2017-01-31 14:57 ` Vadim Lomovtsev
2017-01-31 14:57 ` Vadim Lomovtsev
2017-01-31 20:31 ` Bjorn Helgaas
2017-01-31 20:31 ` Bjorn Helgaas
2017-02-01 12:53 ` Vadim Lomovtsev
2017-02-01 12:53 ` Vadim Lomovtsev
2017-02-01 15:18 ` Bjorn Helgaas
2017-02-01 15:18 ` Bjorn Helgaas
2017-02-01 15:18 ` Bjorn Helgaas
2017-02-01 15:34 ` Vadim Lomovtsev
2017-02-01 15:34 ` Vadim Lomovtsev
2017-02-01 15:34 ` Vadim Lomovtsev
2017-03-15 11:14 ` Jon Masters
2017-03-15 11:14 ` Jon Masters
2017-03-15 11:14 ` Jon Masters
2017-03-15 11:33 ` Vadim Lomovtsev [this message]
2017-03-15 11:33 ` Vadim Lomovtsev
2017-03-15 11:33 ` Vadim Lomovtsev
2017-03-16 14:32 ` Jon Masters
2017-03-16 14:32 ` Jon Masters
2017-03-16 16:25 ` David Daney
2017-03-16 16:25 ` David Daney
2017-03-21 11:38 ` Jon Masters
2017-03-21 11:38 ` Jon Masters
2017-03-21 13:47 ` Bjorn Helgaas
2017-03-21 13:47 ` Bjorn Helgaas
2017-03-21 13:47 ` Bjorn Helgaas
2017-03-21 14:17 ` Tomasz Nowicki
2017-03-21 14:17 ` Tomasz Nowicki
2017-03-21 14:56 ` David Daney
2017-03-21 14:56 ` David Daney
2017-03-21 14:56 ` David Daney
2017-03-22 14:28 ` Jon Masters
2017-03-22 14:28 ` Jon Masters
2017-03-22 14:48 ` Bjorn Helgaas
2017-03-22 14:48 ` Bjorn Helgaas
2017-03-22 14:48 ` Bjorn Helgaas
2017-03-22 16:25 ` Jon Masters
2017-03-22 16:25 ` Jon Masters
2017-03-22 16:34 ` Bjorn Helgaas
2017-03-22 16:34 ` Bjorn Helgaas
2017-03-22 16:34 ` Bjorn Helgaas
2017-03-23 22:14 ` Bjorn Helgaas
2017-03-23 22:14 ` Bjorn Helgaas
2017-03-23 22:14 ` Bjorn Helgaas
2017-03-23 22:16 ` Jon Masters
2017-03-23 22:16 ` Jon Masters
2017-03-21 17:45 ` Bjorn Helgaas
2017-03-21 17:45 ` Bjorn Helgaas
2017-03-21 17:45 ` Bjorn Helgaas
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=20170315113323.GA28027@localhost.localdomain \
--to=vadim.lomovtsev@caviumnetworks.com \
--cc=David.Daney@cavium.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=jcm@jonmasters.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=stemerkhanov@CAVIUMNETWORKS.onmicrosoft.com \
--cc=tn@semihalf.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.