Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Hanjun Guo]

On 12/22/2015 10:48 PM, Gabriele Paoloni wrote:

Hi Tomasz


-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
Sent: 22 December 2015 10:20
To: Gabriele Paoloni; bhelg...@google.com; a...@arndb.de;
will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
jiang@linux.intel.com; stefano.stabell...@eu.citrix.com
Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
liviu.du...@arm.com; dda...@caviumnetworks.com; t...@linutronix.de;
Wangyijing; suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
a...@lists.linaro.org; jchan...@broadcom.com; j...@redhat.com
Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
accessors against platfrom specific quirks.

On 21.12.2015 12:47, Gabriele Paoloni wrote:

2) In the quirk mechanism you proposed, I see that the callback

function

 allows to do some preparation work for the host bridge. For

example in

 Hisilicon hip05 case we would need to read some values from the

ACPI

 table (see acpi_pci_root_hisi_add() function in
 https://lkml.org/lkml/2015/12/3/426).
 I am quite new to ACPI and I wonder if it is OK to add such

"Packages"

 to the  PCI host bridge ACPI device...or maybe we need to declare

a new

 one...?


I may miss sth so please correct me in that case.

https://lkml.org/lkml/2015/12/3/426 shows that you need special
handling for root->secondary.start bus number only, right? So how about
creating special MCFG region  only for
.
Like that:

[0008]   Base Address : 
[0002]   Segment Group Number : 
[0001]   Start Bus Number : secondary.start>
[0001] End Bus Number : secondary.start>
[0004]   Reserved : 


static const struct dmi_system_id hisi_quirk[] = {
{
.ident = "HiSi...",
.matches = {
DMI_MATCH(),
},
},
{ }
};

static struct pci_ops hisi_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = hisi_pcie_cfg_read,
.write = hisi_pcie_cfg_write,
};

DECLARE_ACPI_MCFG_FIXUP(hisi_quirk, _ecam_pci_ops,
, );

With above code you can use your custom PCI config accessor only for
that region.

Let me know if that is not enough for you.


In principle I think it can work...

Liudongdong, Guo Hanjun what is your opinion about?


Let me and Dongdong prepare a patch for Hip05 and then will
back to this discussion to see if we met some problems.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Hanjun Guo]

On 12/22/2015 10:48 PM, Gabriele Paoloni wrote:

Hi Tomasz


-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
Sent: 22 December 2015 10:20
To: Gabriele Paoloni; bhelg...@google.com; a...@arndb.de;
will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
jiang@linux.intel.com; stefano.stabell...@eu.citrix.com
Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
liviu.du...@arm.com; dda...@caviumnetworks.com; t...@linutronix.de;
Wangyijing; suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
a...@lists.linaro.org; jchan...@broadcom.com; j...@redhat.com
Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
accessors against platfrom specific quirks.

On 21.12.2015 12:47, Gabriele Paoloni wrote:

2) In the quirk mechanism you proposed, I see that the callback

function

 allows to do some preparation work for the host bridge. For

example in

 Hisilicon hip05 case we would need to read some values from the

ACPI

 table (see acpi_pci_root_hisi_add() function in
 https://lkml.org/lkml/2015/12/3/426).
 I am quite new to ACPI and I wonder if it is OK to add such

"Packages"

 to the  PCI host bridge ACPI device...or maybe we need to declare

a new

 one...?


I may miss sth so please correct me in that case.

https://lkml.org/lkml/2015/12/3/426 shows that you need special
handling for root->secondary.start bus number only, right? So how about
creating special MCFG region <rc-base:rc-base+rc-size> only for
<segment,bus>.
Like that:

[0008]   Base Address : 
[0002]   Segment Group Number : 
[0001]   Start Bus Number : secondary.start>
[0001] End Bus Number : secondary.start>
[0004]   Reserved : 


static const struct dmi_system_id hisi_quirk[] = {
{
.ident = "HiSi...",
.matches = {
DMI_MATCH(),
},
},
{ }
};

static struct pci_ops hisi_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = hisi_pcie_cfg_read,
.write = hisi_pcie_cfg_write,
};

DECLARE_ACPI_MCFG_FIXUP(hisi_quirk, _ecam_pci_ops,
, );

With above code you can use your custom PCI config accessor only for
that region.

Let me know if that is not enough for you.


In principle I think it can work...

Liudongdong, Guo Hanjun what is your opinion about?


Let me and Dongdong prepare a patch for Hip05 and then will
back to this discussion to see if we met some problems.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

> -Original Message-
> From: Jon Masters [mailto:j...@redhat.com]
> Sent: 22 December 2015 16:45
> To: Gabriele Paoloni; Arnd Bergmann
> Cc: Tomasz Nowicki; bhelg...@google.com; will.dea...@arm.com;
> catalin.mari...@arm.com; r...@rjwysocki.net; hanjun@linaro.org;
> lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> On 12/22/2015 11:36 AM, Jon Masters wrote:
> > On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
> >> Hi Jon, thanks for replying
> >>
> >>> -Original Message-
> >>> From: Jon Masters [mailto:j...@redhat.com]
> >>> Sent: 21 December 2015 23:11
> >>> To: Arnd Bergmann
> >>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
> >>> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
> >>> hanjun@linaro.org; lorenzo.pieral...@arm.com;
> >>> ok...@codeaurora.org; jiang@linux.intel.com;
> >>> stefano.stabell...@eu.citrix.com; robert.rich...@caviumnetworks.com;
> >>> m...@semihalf.com; liviu.du...@arm.com; dda...@caviumnetworks.com;
> >>> t...@linutronix.de; Wangyijing; suravee.suthikulpa...@amd.com;
> >>> msal...@redhat.com; linux- p...@vger.kernel.org;
> >>> linux-arm-ker...@lists.infradead.org; linux- a...@vger.kernel.org;
> >>> linux-kernel@vger.kernel.org; linaro- a...@lists.linaro.org;
> >>> jchan...@broadcom.com
> >>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> >>> accessors against platfrom specific quirks.
> >>>
> >>> Sorry for top-posting. A quick note that SMBIOS3 is required by
> SBBR
> >>> so it can be presumed that compliant platforms will provide quirks
> via DMI.
> >>
> >> Ok so you completely clarified my question 1). Many Thanks for this
> >
> > No problem. One of the (many) reasons I pushed for requiring
> > SMBIOS/DMI in SBBR (I was lead author of one of the early drafts of
> > that document) was to make the experience ultimately equivalent
> across architectures.
> > We already know how to do quirks and handle platform deviations, and
> > the major Operating System vendors did not want to reinvent the wheel.
> 
> Additional: it is clear that more prescription is required to get the
> vendors onto the bandwagon that we have with other architectures (e.g.
> that other one). So there will be a Red Hat "ARM server whitepaper"
> coming in the early new year that will include the kind of "server 101"
> material we want to make sure people know. Things like making sure you
> implement and test PCIe correctly, handle backward compatibility (you
> will build hardware in the future that runs my existing OS release),
> design the hardware to allow for workarounds later, etc. I expect some
> other Operating System vendors to be involved in reviewing that.
> 
> Ultimately my objective is to make this whole thing dull and boring.
> You will get RHEL(SA)/upstream kernels and it will either boot or it
> will not. If it does not boot, vendor X screwed up their hardware. We
> know this story, it's been this way for over a decade already, and that
> is exactly how it is going to be with ARM servers shortly.

Ok got it.

Many Thanks

Gab

> 
> Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

On 12/22/2015 11:36 AM, Jon Masters wrote:
> On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
>> Hi Jon, thanks for replying
>>
>>> -Original Message-
>>> From: Jon Masters [mailto:j...@redhat.com]
>>> Sent: 21 December 2015 23:11
>>> To: Arnd Bergmann
>>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
>>> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
>>> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
>>> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
>>> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
>>> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
>>> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
>>> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>>> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>> a...@lists.linaro.org; jchan...@broadcom.com
>>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>>> accessors against platfrom specific quirks.
>>>
>>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>>> it can be presumed that compliant platforms will provide quirks via DMI.
>>
>> Ok so you completely clarified my question 1). Many Thanks for this
> 
> No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
> in SBBR (I was lead author of one of the early drafts of that document)
> was to make the experience ultimately equivalent across architectures.
> We already know how to do quirks and handle platform deviations, and the
> major Operating System vendors did not want to reinvent the wheel.

Additional: it is clear that more prescription is required to get the
vendors onto the bandwagon that we have with other architectures (e.g.
that other one). So there will be a Red Hat "ARM server whitepaper"
coming in the early new year that will include the kind of "server 101"
material we want to make sure people know. Things like making sure you
implement and test PCIe correctly, handle backward compatibility (you
will build hardware in the future that runs my existing OS release),
design the hardware to allow for workarounds later, etc. I expect some
other Operating System vendors to be involved in reviewing that.

Ultimately my objective is to make this whole thing dull and boring. You
will get RHEL(SA)/upstream kernels and it will either boot or it will
not. If it does not boot, vendor X screwed up their hardware. We know
this story, it's been this way for over a decade already, and that is
exactly how it is going to be with ARM servers shortly.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
> Hi Jon, thanks for replying
> 
>> -Original Message-
>> From: Jon Masters [mailto:j...@redhat.com]
>> Sent: 21 December 2015 23:11
>> To: Arnd Bergmann
>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
>> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
>> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
>> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
>> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
>> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
>> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
>> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>> a...@lists.linaro.org; jchan...@broadcom.com
>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>> accessors against platfrom specific quirks.
>>
>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>> it can be presumed that compliant platforms will provide quirks via DMI.
> 
> Ok so you completely clarified my question 1). Many Thanks for this

No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
in SBBR (I was lead author of one of the early drafts of that document)
was to make the experience ultimately equivalent across architectures.
We already know how to do quirks and handle platform deviations, and the
major Operating System vendors did not want to reinvent the wheel.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

Hi Tomasz

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> Sent: 22 December 2015 10:20
> To: Gabriele Paoloni; bhelg...@google.com; a...@arndb.de;
> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com
> Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
> liviu.du...@arm.com; dda...@caviumnetworks.com; t...@linutronix.de;
> Wangyijing; suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com; j...@redhat.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> On 21.12.2015 12:47, Gabriele Paoloni wrote:
> > 2) In the quirk mechanism you proposed, I see that the callback
> function
> > allows to do some preparation work for the host bridge. For
> example in
> > Hisilicon hip05 case we would need to read some values from the
> ACPI
> > table (see acpi_pci_root_hisi_add() function in
> > https://lkml.org/lkml/2015/12/3/426).
> > I am quite new to ACPI and I wonder if it is OK to add such
> "Packages"
> > to the  PCI host bridge ACPI device...or maybe we need to declare
> a new
> > one...?
> 
> I may miss sth so please correct me in that case.
> 
> https://lkml.org/lkml/2015/12/3/426 shows that you need special
> handling for root->secondary.start bus number only, right? So how about
> creating special MCFG region  only for
> .
> Like that:
> 
> [0008]   Base Address : 
> [0002]   Segment Group Number : 
> [0001]   Start Bus Number : secondary.start>
> [0001] End Bus Number : secondary.start>
> [0004]   Reserved : 
> 
> 
> static const struct dmi_system_id hisi_quirk[] = {
>   {
>   .ident = "HiSi...",
>   .matches = {
>   DMI_MATCH(),
>   },
>   },
>   { }
> };
> 
> static struct pci_ops hisi_ecam_pci_ops = {
>   .map_bus = pci_mcfg_dev_base,
>   .read = hisi_pcie_cfg_read,
>   .write = hisi_pcie_cfg_write,
> };
> 
> DECLARE_ACPI_MCFG_FIXUP(hisi_quirk, _ecam_pci_ops,
>   , );
> 
> With above code you can use your custom PCI config accessor only for
> that region.
> 
> Let me know if that is not enough for you.

In principle I think it can work...

Liudongdong, Guo Hanjun what is your opinion about?

Thanks

Gab

> 
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Tomasz Nowicki]

On 21.12.2015 12:47, Gabriele Paoloni wrote:

2) In the quirk mechanism you proposed, I see that the callback function
allows to do some preparation work for the host bridge. For example in
Hisilicon hip05 case we would need to read some values from the ACPI
table (see acpi_pci_root_hisi_add() function in
https://lkml.org/lkml/2015/12/3/426).
I am quite new to ACPI and I wonder if it is OK to add such "Packages"
to the  PCI host bridge ACPI device...or maybe we need to declare a new
one...?


I may miss sth so please correct me in that case.

https://lkml.org/lkml/2015/12/3/426 shows that you need special handling 
for root->secondary.start bus number only, right? So how about creating 
special MCFG region  only for . 
Like that:


[0008]   Base Address : 
[0002]   Segment Group Number : 
[0001]   Start Bus Number : secondary.start>
[0001] End Bus Number : secondary.start>
[0004]   Reserved : 


static const struct dmi_system_id hisi_quirk[] = {
{
.ident = "HiSi...",
.matches = {
DMI_MATCH(),
},
},
{ }
};

static struct pci_ops hisi_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = hisi_pcie_cfg_read,
.write = hisi_pcie_cfg_write,
};

DECLARE_ACPI_MCFG_FIXUP(hisi_quirk, _ecam_pci_ops,
, );

With above code you can use your custom PCI config accessor only for 
that region.


Let me know if that is not enough for you.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

Hi Jon, thanks for replying

> -Original Message-
> From: Jon Masters [mailto:j...@redhat.com]
> Sent: 21 December 2015 23:11
> To: Arnd Bergmann
> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
> it can be presumed that compliant platforms will provide quirks via DMI.

Ok so you completely clarified my question 1). Many Thanks for this

Gab

> 
> --
> Computer Architect | Sent from my 64-bit #ARM Powered phone
> 
> > On Dec 21, 2015, at 09:11, Arnd Bergmann  wrote:
> >
> > On Monday 21 December 2015, Gabriele Paoloni wrote:
> >>> -Original Message-
> >>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> >>> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> >
> >>> Some platforms may not be fully compliant with generic set of PCI
> >>> config accessors. For these cases we implement the way to overwrite
> >>> accessors set before PCI buses enumeration. Algorithm that
> overwrite
> >>> accessors matches against platform ID (DMI), domain and bus number,
> >>> hopefully enough for all cases. All quirks can be defined using:
> >>> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> >>
> >> I've got a couple of comments/questions about this patch..
> >>
> >> 1) So according to this mechanism quirks would be supported only by
> >>   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
> >>   with this but I don't know if this is OK in general as it would
> >>   narrow down the number of platforms that would be able to define
> >>   the quirks...
> >>   Lorenzo, Arnd what is your opinion here?
> >
> > I'd rather not see the quirks in mainline at all, and only support
> > SBSA compliant machines, or require the BIOS to work around the
> > hardware quirks differently (e.g. by trapping config space access
> > through secure firmware, or going through an AML method to be
> > defined). I'm certainly ok with making it depend on SMBIOS if we are
> going to use something like this.
> >
> >Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Tomasz Nowicki]

On 22.12.2015 00:10, Jon Masters wrote:

Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so it can 
be presumed that compliant platforms will provide quirks via DMI.



Thanks Jon for confirmation.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Tomasz Nowicki]

On 21.12.2015 12:47, Gabriele Paoloni wrote:

2) In the quirk mechanism you proposed, I see that the callback function
allows to do some preparation work for the host bridge. For example in
Hisilicon hip05 case we would need to read some values from the ACPI
table (see acpi_pci_root_hisi_add() function in
https://lkml.org/lkml/2015/12/3/426).
I am quite new to ACPI and I wonder if it is OK to add such "Packages"
to the  PCI host bridge ACPI device...or maybe we need to declare a new
one...?


I may miss sth so please correct me in that case.

https://lkml.org/lkml/2015/12/3/426 shows that you need special handling 
for root->secondary.start bus number only, right? So how about creating 
special MCFG region  only for . 
Like that:


[0008]   Base Address : 
[0002]   Segment Group Number : 
[0001]   Start Bus Number : secondary.start>
[0001] End Bus Number : secondary.start>
[0004]   Reserved : 


static const struct dmi_system_id hisi_quirk[] = {
{
.ident = "HiSi...",
.matches = {
DMI_MATCH(),
},
},
{ }
};

static struct pci_ops hisi_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = hisi_pcie_cfg_read,
.write = hisi_pcie_cfg_write,
};

DECLARE_ACPI_MCFG_FIXUP(hisi_quirk, _ecam_pci_ops,
, );

With above code you can use your custom PCI config accessor only for 
that region.


Let me know if that is not enough for you.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Tomasz Nowicki]

On 22.12.2015 00:10, Jon Masters wrote:

Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so it can 
be presumed that compliant platforms will provide quirks via DMI.



Thanks Jon for confirmation.

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

Hi Jon, thanks for replying

> -Original Message-
> From: Jon Masters [mailto:j...@redhat.com]
> Sent: 21 December 2015 23:11
> To: Arnd Bergmann
> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
> it can be presumed that compliant platforms will provide quirks via DMI.

Ok so you completely clarified my question 1). Many Thanks for this

Gab

> 
> --
> Computer Architect | Sent from my 64-bit #ARM Powered phone
> 
> > On Dec 21, 2015, at 09:11, Arnd Bergmann <a...@arndb.de> wrote:
> >
> > On Monday 21 December 2015, Gabriele Paoloni wrote:
> >>> -Original Message-
> >>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> >>> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> >
> >>> Some platforms may not be fully compliant with generic set of PCI
> >>> config accessors. For these cases we implement the way to overwrite
> >>> accessors set before PCI buses enumeration. Algorithm that
> overwrite
> >>> accessors matches against platform ID (DMI), domain and bus number,
> >>> hopefully enough for all cases. All quirks can be defined using:
> >>> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> >>
> >> I've got a couple of comments/questions about this patch..
> >>
> >> 1) So according to this mechanism quirks would be supported only by
> >>   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
> >>   with this but I don't know if this is OK in general as it would
> >>   narrow down the number of platforms that would be able to define
> >>   the quirks...
> >>   Lorenzo, Arnd what is your opinion here?
> >
> > I'd rather not see the quirks in mainline at all, and only support
> > SBSA compliant machines, or require the BIOS to work around the
> > hardware quirks differently (e.g. by trapping config space access
> > through secure firmware, or going through an AML method to be
> > defined). I'm certainly ok with making it depend on SMBIOS if we are
> going to use something like this.
> >
> >Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
> Hi Jon, thanks for replying
> 
>> -Original Message-
>> From: Jon Masters [mailto:j...@redhat.com]
>> Sent: 21 December 2015 23:11
>> To: Arnd Bergmann
>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
>> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
>> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
>> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
>> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
>> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
>> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
>> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>> a...@lists.linaro.org; jchan...@broadcom.com
>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>> accessors against platfrom specific quirks.
>>
>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>> it can be presumed that compliant platforms will provide quirks via DMI.
> 
> Ok so you completely clarified my question 1). Many Thanks for this

No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
in SBBR (I was lead author of one of the early drafts of that document)
was to make the experience ultimately equivalent across architectures.
We already know how to do quirks and handle platform deviations, and the
major Operating System vendors did not want to reinvent the wheel.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

On 12/22/2015 11:36 AM, Jon Masters wrote:
> On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
>> Hi Jon, thanks for replying
>>
>>> -Original Message-
>>> From: Jon Masters [mailto:j...@redhat.com]
>>> Sent: 21 December 2015 23:11
>>> To: Arnd Bergmann
>>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
>>> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
>>> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
>>> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
>>> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
>>> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
>>> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
>>> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>>> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>> a...@lists.linaro.org; jchan...@broadcom.com
>>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>>> accessors against platfrom specific quirks.
>>>
>>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>>> it can be presumed that compliant platforms will provide quirks via DMI.
>>
>> Ok so you completely clarified my question 1). Many Thanks for this
> 
> No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
> in SBBR (I was lead author of one of the early drafts of that document)
> was to make the experience ultimately equivalent across architectures.
> We already know how to do quirks and handle platform deviations, and the
> major Operating System vendors did not want to reinvent the wheel.

Additional: it is clear that more prescription is required to get the
vendors onto the bandwagon that we have with other architectures (e.g.
that other one). So there will be a Red Hat "ARM server whitepaper"
coming in the early new year that will include the kind of "server 101"
material we want to make sure people know. Things like making sure you
implement and test PCIe correctly, handle backward compatibility (you
will build hardware in the future that runs my existing OS release),
design the hardware to allow for workarounds later, etc. I expect some
other Operating System vendors to be involved in reviewing that.

Ultimately my objective is to make this whole thing dull and boring. You
will get RHEL(SA)/upstream kernels and it will either boot or it will
not. If it does not boot, vendor X screwed up their hardware. We know
this story, it's been this way for over a decade already, and that is
exactly how it is going to be with ARM servers shortly.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

Hi Tomasz

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> Sent: 22 December 2015 10:20
> To: Gabriele Paoloni; bhelg...@google.com; a...@arndb.de;
> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
> hanjun@linaro.org; lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com
> Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
> liviu.du...@arm.com; dda...@caviumnetworks.com; t...@linutronix.de;
> Wangyijing; suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com; j...@redhat.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> On 21.12.2015 12:47, Gabriele Paoloni wrote:
> > 2) In the quirk mechanism you proposed, I see that the callback
> function
> > allows to do some preparation work for the host bridge. For
> example in
> > Hisilicon hip05 case we would need to read some values from the
> ACPI
> > table (see acpi_pci_root_hisi_add() function in
> > https://lkml.org/lkml/2015/12/3/426).
> > I am quite new to ACPI and I wonder if it is OK to add such
> "Packages"
> > to the  PCI host bridge ACPI device...or maybe we need to declare
> a new
> > one...?
> 
> I may miss sth so please correct me in that case.
> 
> https://lkml.org/lkml/2015/12/3/426 shows that you need special
> handling for root->secondary.start bus number only, right? So how about
> creating special MCFG region <rc-base:rc-base+rc-size> only for
> <segment,bus>.
> Like that:
> 
> [0008]   Base Address : 
> [0002]   Segment Group Number : 
> [0001]   Start Bus Number : secondary.start>
> [0001] End Bus Number : secondary.start>
> [0004]   Reserved : 
> 
> 
> static const struct dmi_system_id hisi_quirk[] = {
>   {
>   .ident = "HiSi...",
>   .matches = {
>   DMI_MATCH(),
>   },
>   },
>   { }
> };
> 
> static struct pci_ops hisi_ecam_pci_ops = {
>   .map_bus = pci_mcfg_dev_base,
>   .read = hisi_pcie_cfg_read,
>   .write = hisi_pcie_cfg_write,
> };
> 
> DECLARE_ACPI_MCFG_FIXUP(hisi_quirk, _ecam_pci_ops,
>   , );
> 
> With above code you can use your custom PCI config accessor only for
> that region.
> 
> Let me know if that is not enough for you.

In principle I think it can work...

Liudongdong, Guo Hanjun what is your opinion about?

Thanks

Gab

> 
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

> -Original Message-
> From: Jon Masters [mailto:j...@redhat.com]
> Sent: 22 December 2015 16:45
> To: Gabriele Paoloni; Arnd Bergmann
> Cc: Tomasz Nowicki; bhelg...@google.com; will.dea...@arm.com;
> catalin.mari...@arm.com; r...@rjwysocki.net; hanjun@linaro.org;
> lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com;
> robert.rich...@caviumnetworks.com; m...@semihalf.com; liviu.du...@arm.com;
> dda...@caviumnetworks.com; t...@linutronix.de; Wangyijing;
> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com
> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> accessors against platfrom specific quirks.
> 
> On 12/22/2015 11:36 AM, Jon Masters wrote:
> > On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
> >> Hi Jon, thanks for replying
> >>
> >>> -Original Message-
> >>> From: Jon Masters [mailto:j...@redhat.com]
> >>> Sent: 21 December 2015 23:11
> >>> To: Arnd Bergmann
> >>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelg...@google.com;
> >>> will.dea...@arm.com; catalin.mari...@arm.com; r...@rjwysocki.net;
> >>> hanjun@linaro.org; lorenzo.pieral...@arm.com;
> >>> ok...@codeaurora.org; jiang@linux.intel.com;
> >>> stefano.stabell...@eu.citrix.com; robert.rich...@caviumnetworks.com;
> >>> m...@semihalf.com; liviu.du...@arm.com; dda...@caviumnetworks.com;
> >>> t...@linutronix.de; Wangyijing; suravee.suthikulpa...@amd.com;
> >>> msal...@redhat.com; linux- p...@vger.kernel.org;
> >>> linux-arm-ker...@lists.infradead.org; linux- a...@vger.kernel.org;
> >>> linux-kernel@vger.kernel.org; linaro- a...@lists.linaro.org;
> >>> jchan...@broadcom.com
> >>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
> >>> accessors against platfrom specific quirks.
> >>>
> >>> Sorry for top-posting. A quick note that SMBIOS3 is required by
> SBBR
> >>> so it can be presumed that compliant platforms will provide quirks
> via DMI.
> >>
> >> Ok so you completely clarified my question 1). Many Thanks for this
> >
> > No problem. One of the (many) reasons I pushed for requiring
> > SMBIOS/DMI in SBBR (I was lead author of one of the early drafts of
> > that document) was to make the experience ultimately equivalent
> across architectures.
> > We already know how to do quirks and handle platform deviations, and
> > the major Operating System vendors did not want to reinvent the wheel.
> 
> Additional: it is clear that more prescription is required to get the
> vendors onto the bandwagon that we have with other architectures (e.g.
> that other one). So there will be a Red Hat "ARM server whitepaper"
> coming in the early new year that will include the kind of "server 101"
> material we want to make sure people know. Things like making sure you
> implement and test PCIe correctly, handle backward compatibility (you
> will build hardware in the future that runs my existing OS release),
> design the hardware to allow for workarounds later, etc. I expect some
> other Operating System vendors to be involved in reviewing that.
> 
> Ultimately my objective is to make this whole thing dull and boring.
> You will get RHEL(SA)/upstream kernels and it will either boot or it
> will not. If it does not boot, vendor X screwed up their hardware. We
> know this story, it's been this way for over a decade already, and that
> is exactly how it is going to be with ARM servers shortly.

Ok got it.

Many Thanks

Gab

> 
> Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

On 12/21/2015 05:42 PM, Arnd Bergmann wrote:
> On Monday 21 December 2015, David Daney wrote:
>> On 12/21/2015 06:10 AM, Arnd Bergmann wrote:
>>> On Monday 21 December 2015, Gabriele Paoloni wrote:
>>
>>> or require the BIOS to work around the hardware
>>> quirks differently (e.g. by trapping config space access through secure
>>> firmware, or going through an AML method to be defined).
>>
>> Some systems don't seem to have this capability.  For example, in ARMv8 
>> (A.K.A. arm64), I haven't been able to figure out how to trap these 
>> accesses to EL3 for emulation.  The specification is 5700 pages long 
>> though, so perhaps I missed that bit.

There isn't a way to directly trap to EL3 for emulation (caveat - there
might be some nasty hack with an SMMU that wouldn't be supportable). I
requested the implementation of a generic mechanism for LPC type
emulation (complete with "SMI" traps to EL3 for fixups) about 4 years
ago. That wouldn't have helped with this situation, but this was to be
on the radar afterward. However, on ARM, it is still early days with
respect to transparently trapping and emulating hardware workarounds.

> How about using AML then? This would be similar to what CHRP used with
> RTAS calls to do PCI config space access.

The best way to do it for now (IMO) is via a DMI quirk match and a
special method for the early SoCs that aren't implementing MMCONFIG
correctly. An effort is underway to correct that in third party IP, and
similar directly with the partners for future generations. So this
should not get "much" more out of hand than it sadly is so far. Once we
have a good upstream solution (which is vital) then it will be an error
and a pre-tapeout bug to not be able to boot an upstream kernel with
stock ACPI hostbridge working sans nasty quirks. Therefore, the sooner
this is upstream, the better it will be for everyone involved.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so it can 
be presumed that compliant platforms will provide quirks via DMI.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Dec 21, 2015, at 09:11, Arnd Bergmann  wrote:
> 
> On Monday 21 December 2015, Gabriele Paoloni wrote:
>>> -Original Message-
>>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>>> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> 
>>> Some platforms may not be fully compliant with generic set of PCI
>>> config accessors. For these cases we implement the way to overwrite
>>> accessors set before PCI buses enumeration. Algorithm that overwrite
>>> accessors matches against platform ID (DMI), domain and bus number,
>>> hopefully enough for all cases. All quirks can be defined using:
>>> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
>> 
>> I've got a couple of comments/questions about this patch..
>> 
>> 1) So according to this mechanism quirks would be supported only by 
>>   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
>>   with this but I don't know if this is OK in general as it would 
>>   narrow down the number of platforms that would be able to define
>>   the quirks...
>>   Lorenzo, Arnd what is your opinion here?
> 
> I'd rather not see the quirks in mainline at all, and only support
> SBSA compliant machines, or require the BIOS to work around the hardware
> quirks differently (e.g. by trapping config space access through secure
> firmware, or going through an AML method to be defined). I'm certainly
> ok with making it depend on SMBIOS if we are going to use something like this.
> 
>Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Arnd Bergmann]

On Monday 21 December 2015, David Daney wrote:
> On 12/21/2015 06:10 AM, Arnd Bergmann wrote:
> > On Monday 21 December 2015, Gabriele Paoloni wrote:
> 
> > or require the BIOS to work around the hardware
> > quirks differently (e.g. by trapping config space access through secure
> > firmware, or going through an AML method to be defined).
> 
> Some systems don't seem to have this capability.  For example, in ARMv8 
> (A.K.A. arm64), I haven't been able to figure out how to trap these 
> accesses to EL3 for emulation.  The specification is 5700 pages long 
> though, so perhaps I missed that bit.

How about using AML then? This would be similar to what CHRP used with
RTAS calls to do PCI config space access.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[David Daney]

On 12/21/2015 06:10 AM, Arnd Bergmann wrote:

On Monday 21 December 2015, Gabriele Paoloni wrote:

-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki



Some platforms may not be fully compliant with generic set of PCI
config accessors. For these cases we implement the way to overwrite
accessors set before PCI buses enumeration. Algorithm that overwrite
accessors matches against platform ID (DMI), domain and bus number,
hopefully enough for all cases. All quirks can be defined using:
DECLARE_ACPI_MCFG_FIXUP() and keep self contained.


I've got a couple of comments/questions about this patch..

1) So according to this mechanism quirks would be supported only by
vendors whose BIOS are SMBIOS compliant. Now personally I am ok
with this but I don't know if this is OK in general as it would
narrow down the number of platforms that would be able to define
the quirks...
Lorenzo, Arnd what is your opinion here?


I'd rather not see the quirks in mainline at all, and only support
SBSA compliant machines,


There seems to exist a class of systems that were intended to be SBSA 
compliant, but after they were manufactured turn out to not be fully 
complaint.  It would be nice to have Linux kernel support for some of 
these systems


There also seems to be historical precedent for quirk frameworks in 
various kernel subsystems to handle systems and devices that are not 
fully "Spec. Compliant".



or require the BIOS to work around the hardware
quirks differently (e.g. by trapping config space access through secure
firmware, or going through an AML method to be defined).


Some systems don't seem to have this capability.  For example, in ARMv8 
(A.K.A. arm64), I haven't been able to figure out how to trap these 
accesses to EL3 for emulation.  The specification is 5700 pages long 
though, so perhaps I missed that bit.



I'm certainly
ok with making it depend on SMBIOS if we are going to use something like this.

Arnd



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Arnd Bergmann]

On Monday 21 December 2015, Gabriele Paoloni wrote:
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki

> > Some platforms may not be fully compliant with generic set of PCI
> > config accessors. For these cases we implement the way to overwrite
> > accessors set before PCI buses enumeration. Algorithm that overwrite
> > accessors matches against platform ID (DMI), domain and bus number,
> > hopefully enough for all cases. All quirks can be defined using:
> > DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> 
> I've got a couple of comments/questions about this patch..
> 
> 1) So according to this mechanism quirks would be supported only by 
>vendors whose BIOS are SMBIOS compliant. Now personally I am ok
>with this but I don't know if this is OK in general as it would 
>narrow down the number of platforms that would be able to define
>the quirks...
>Lorenzo, Arnd what is your opinion here?

I'd rather not see the quirks in mainline at all, and only support
SBSA compliant machines, or require the BIOS to work around the hardware
quirks differently (e.g. by trapping config space access through secure
firmware, or going through an AML method to be defined). I'm certainly
ok with making it depend on SMBIOS if we are going to use something like this.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

Hi Tomasz

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> Sent: 16 December 2015 15:17
> To: bhelg...@google.com; a...@arndb.de; will.dea...@arm.com;
> catalin.mari...@arm.com; r...@rjwysocki.net; hanjun@linaro.org;
> lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com
> Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
> liviu.du...@arm.com; dda...@caviumnetworks.com; t...@linutronix.de;
> Wangyijing; suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com; j...@redhat.com; Tomasz
> Nowicki
> Subject: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors
> against platfrom specific quirks.
> 
> Some platforms may not be fully compliant with generic set of PCI
> config accessors. For these cases we implement the way to overwrite
> accessors set before PCI buses enumeration. Algorithm that overwrite
> accessors matches against platform ID (DMI), domain and bus number,
> hopefully enough for all cases. All quirks can be defined using:
> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.

I've got a couple of comments/questions about this patch..

1) So according to this mechanism quirks would be supported only by 
   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
   with this but I don't know if this is OK in general as it would 
   narrow down the number of platforms that would be able to define
   the quirks...
   Lorenzo, Arnd what is your opinion here?

2) In the quirk mechanism you proposed, I see that the callback function
   allows to do some preparation work for the host bridge. For example in
   Hisilicon hip05 case we would need to read some values from the ACPI 
   table (see acpi_pci_root_hisi_add() function in 
   https://lkml.org/lkml/2015/12/3/426). 
   I am quite new to ACPI and I wonder if it is OK to add such "Packages"
   to the  PCI host bridge ACPI device...or maybe we need to declare a new
   one...?

Many Thanks

Gab

> 
> example:
> 
> static const struct dmi_system_id yyy[] = {
>   {
>   .ident = "",
>   .callback = ,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, ""),
>   DMI_MATCH(DMI_PRODUCT_NAME, ""),
>   DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
>   },
>   },
>   { }
> };
> 
> static struct pci_ops ecam_pci_ops = {
>   .map_bus = pci_mcfg_dev_base,
>   .read = _ecam_config_read,
>   .write = _ecam_config_write,
> };
> DECLARE_ACPI_MCFG_FIXUP(yyy, _pci_ops, , );
> 
> Note, that more custom actions can be done via DMI callback hook.
> 
> Signed-off-by: Tomasz Nowicki 
> ---
>  drivers/acpi/mcfg.c   | 35
> +--
>  include/asm-generic/vmlinux.lds.h |  7 +++
>  include/linux/ecam.h  | 17 +
>  3 files changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c index
> a9b2231..6d0194d 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -8,6 +8,7 @@
>   */
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -34,6 +35,31 @@ int __weak raw_pci_write(unsigned int domain,
> unsigned int bus,
>   return PCIBIOS_DEVICE_NOT_FOUND;
>  }
> 
> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[]; extern struct
> +pci_mcfg_fixup __end_acpi_mcfg_fixups[];
> +
> +static struct pci_ops *pci_mcfg_check_quirks(int domain, int
> +bus_number) {
> + struct pci_mcfg_fixup *fixup;
> +
> + fixup = __start_acpi_mcfg_fixups;
> + while (fixup < __end_acpi_mcfg_fixups) {
> + if (dmi_check_system(fixup->system) &&
> + (fixup->domain == domain ||
> +  fixup->domain == PCI_MCFG_DOMAIN_ANY) &&
> + (fixup->bus_number == bus_number ||
> +  fixup->bus_number == PCI_MCFG_BUS_ANY)) {
> + pr_info(PREFIX "Fixup applied: Platform [%s] domain
> [%d] bus number [%d]\n",
> + fixup->system->ident, fixup->domain,
> + fixup->bus_number);
> + return fixup->ops;
> + }
> + ++fixup;
> + }
> +
> + return NULL;
> +}
> +
>  void __iomem *
>  pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
> { @@ -56,10 +82,15 @@ static struct pci_ops default_pci_mcfg_ops = {
> 
>  struct pci_ops *pci_mcfg_get_ops(int domain, int bus)  {
> + struct pci_ops *pci_mcfg_ops_quirk;
> +
>   /*
> -  * TODO: Match against platform specific quirks and return
> -  * corresponding PCI config space accessor set.
> +  * Match against 

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so it can 
be presumed that compliant platforms will provide quirks via DMI.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Dec 21, 2015, at 09:11, Arnd Bergmann  wrote:
> 
> On Monday 21 December 2015, Gabriele Paoloni wrote:
>>> -Original Message-
>>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>>> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> 
>>> Some platforms may not be fully compliant with generic set of PCI
>>> config accessors. For these cases we implement the way to overwrite
>>> accessors set before PCI buses enumeration. Algorithm that overwrite
>>> accessors matches against platform ID (DMI), domain and bus number,
>>> hopefully enough for all cases. All quirks can be defined using:
>>> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
>> 
>> I've got a couple of comments/questions about this patch..
>> 
>> 1) So according to this mechanism quirks would be supported only by 
>>   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
>>   with this but I don't know if this is OK in general as it would 
>>   narrow down the number of platforms that would be able to define
>>   the quirks...
>>   Lorenzo, Arnd what is your opinion here?
> 
> I'd rather not see the quirks in mainline at all, and only support
> SBSA compliant machines, or require the BIOS to work around the hardware
> quirks differently (e.g. by trapping config space access through secure
> firmware, or going through an AML method to be defined). I'm certainly
> ok with making it depend on SMBIOS if we are going to use something like this.
> 
>Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Jon Masters]

On 12/21/2015 05:42 PM, Arnd Bergmann wrote:
> On Monday 21 December 2015, David Daney wrote:
>> On 12/21/2015 06:10 AM, Arnd Bergmann wrote:
>>> On Monday 21 December 2015, Gabriele Paoloni wrote:
>>
>>> or require the BIOS to work around the hardware
>>> quirks differently (e.g. by trapping config space access through secure
>>> firmware, or going through an AML method to be defined).
>>
>> Some systems don't seem to have this capability.  For example, in ARMv8 
>> (A.K.A. arm64), I haven't been able to figure out how to trap these 
>> accesses to EL3 for emulation.  The specification is 5700 pages long 
>> though, so perhaps I missed that bit.

There isn't a way to directly trap to EL3 for emulation (caveat - there
might be some nasty hack with an SMMU that wouldn't be supportable). I
requested the implementation of a generic mechanism for LPC type
emulation (complete with "SMI" traps to EL3 for fixups) about 4 years
ago. That wouldn't have helped with this situation, but this was to be
on the radar afterward. However, on ARM, it is still early days with
respect to transparently trapping and emulating hardware workarounds.

> How about using AML then? This would be similar to what CHRP used with
> RTAS calls to do PCI config space access.

The best way to do it for now (IMO) is via a DMI quirk match and a
special method for the early SoCs that aren't implementing MMCONFIG
correctly. An effort is underway to correct that in third party IP, and
similar directly with the partners for future generations. So this
should not get "much" more out of hand than it sadly is so far. Once we
have a good upstream solution (which is vital) then it will be an error
and a pre-tapeout bug to not be able to boot an upstream kernel with
stock ACPI hostbridge working sans nasty quirks. Therefore, the sooner
this is upstream, the better it will be for everyone involved.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Arnd Bergmann]

On Monday 21 December 2015, David Daney wrote:
> On 12/21/2015 06:10 AM, Arnd Bergmann wrote:
> > On Monday 21 December 2015, Gabriele Paoloni wrote:
> 
> > or require the BIOS to work around the hardware
> > quirks differently (e.g. by trapping config space access through secure
> > firmware, or going through an AML method to be defined).
> 
> Some systems don't seem to have this capability.  For example, in ARMv8 
> (A.K.A. arm64), I haven't been able to figure out how to trap these 
> accesses to EL3 for emulation.  The specification is 5700 pages long 
> though, so perhaps I missed that bit.

How about using AML then? This would be similar to what CHRP used with
RTAS calls to do PCI config space access.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Arnd Bergmann]

On Monday 21 December 2015, Gabriele Paoloni wrote:
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki

> > Some platforms may not be fully compliant with generic set of PCI
> > config accessors. For these cases we implement the way to overwrite
> > accessors set before PCI buses enumeration. Algorithm that overwrite
> > accessors matches against platform ID (DMI), domain and bus number,
> > hopefully enough for all cases. All quirks can be defined using:
> > DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> 
> I've got a couple of comments/questions about this patch..
> 
> 1) So according to this mechanism quirks would be supported only by 
>vendors whose BIOS are SMBIOS compliant. Now personally I am ok
>with this but I don't know if this is OK in general as it would 
>narrow down the number of platforms that would be able to define
>the quirks...
>Lorenzo, Arnd what is your opinion here?

I'd rather not see the quirks in mainline at all, and only support
SBSA compliant machines, or require the BIOS to work around the hardware
quirks differently (e.g. by trapping config space access through secure
firmware, or going through an AML method to be defined). I'm certainly
ok with making it depend on SMBIOS if we are going to use something like this.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[Gabriele Paoloni]

Hi Tomasz

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> Sent: 16 December 2015 15:17
> To: bhelg...@google.com; a...@arndb.de; will.dea...@arm.com;
> catalin.mari...@arm.com; r...@rjwysocki.net; hanjun@linaro.org;
> lorenzo.pieral...@arm.com; ok...@codeaurora.org;
> jiang@linux.intel.com; stefano.stabell...@eu.citrix.com
> Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
> liviu.du...@arm.com; dda...@caviumnetworks.com; t...@linutronix.de;
> Wangyijing; suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; jchan...@broadcom.com; j...@redhat.com; Tomasz
> Nowicki
> Subject: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors
> against platfrom specific quirks.
> 
> Some platforms may not be fully compliant with generic set of PCI
> config accessors. For these cases we implement the way to overwrite
> accessors set before PCI buses enumeration. Algorithm that overwrite
> accessors matches against platform ID (DMI), domain and bus number,
> hopefully enough for all cases. All quirks can be defined using:
> DECLARE_ACPI_MCFG_FIXUP() and keep self contained.

I've got a couple of comments/questions about this patch..

1) So according to this mechanism quirks would be supported only by 
   vendors whose BIOS are SMBIOS compliant. Now personally I am ok
   with this but I don't know if this is OK in general as it would 
   narrow down the number of platforms that would be able to define
   the quirks...
   Lorenzo, Arnd what is your opinion here?

2) In the quirk mechanism you proposed, I see that the callback function
   allows to do some preparation work for the host bridge. For example in
   Hisilicon hip05 case we would need to read some values from the ACPI 
   table (see acpi_pci_root_hisi_add() function in 
   https://lkml.org/lkml/2015/12/3/426). 
   I am quite new to ACPI and I wonder if it is OK to add such "Packages"
   to the  PCI host bridge ACPI device...or maybe we need to declare a new
   one...?

Many Thanks

Gab

> 
> example:
> 
> static const struct dmi_system_id yyy[] = {
>   {
>   .ident = "",
>   .callback = ,
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, ""),
>   DMI_MATCH(DMI_PRODUCT_NAME, ""),
>   DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
>   },
>   },
>   { }
> };
> 
> static struct pci_ops ecam_pci_ops = {
>   .map_bus = pci_mcfg_dev_base,
>   .read = _ecam_config_read,
>   .write = _ecam_config_write,
> };
> DECLARE_ACPI_MCFG_FIXUP(yyy, _pci_ops, , );
> 
> Note, that more custom actions can be done via DMI callback hook.
> 
> Signed-off-by: Tomasz Nowicki 
> ---
>  drivers/acpi/mcfg.c   | 35
> +--
>  include/asm-generic/vmlinux.lds.h |  7 +++
>  include/linux/ecam.h  | 17 +
>  3 files changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c index
> a9b2231..6d0194d 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -8,6 +8,7 @@
>   */
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -34,6 +35,31 @@ int __weak raw_pci_write(unsigned int domain,
> unsigned int bus,
>   return PCIBIOS_DEVICE_NOT_FOUND;
>  }
> 
> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[]; extern struct
> +pci_mcfg_fixup __end_acpi_mcfg_fixups[];
> +
> +static struct pci_ops *pci_mcfg_check_quirks(int domain, int
> +bus_number) {
> + struct pci_mcfg_fixup *fixup;
> +
> + fixup = __start_acpi_mcfg_fixups;
> + while (fixup < __end_acpi_mcfg_fixups) {
> + if (dmi_check_system(fixup->system) &&
> + (fixup->domain == domain ||
> +  fixup->domain == PCI_MCFG_DOMAIN_ANY) &&
> + (fixup->bus_number == bus_number ||
> +  fixup->bus_number == PCI_MCFG_BUS_ANY)) {
> + pr_info(PREFIX "Fixup applied: Platform [%s] domain
> [%d] bus number [%d]\n",
> + fixup->system->ident, fixup->domain,
> + fixup->bus_number);
> + return fixup->ops;
> + }
> + ++fixup;
> + }
> +
> + return NULL;
> +}
> +
>  void __iomem *
>  pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
> { @@ -56,10 +82,15 @@ static struct pci_ops default_pci_mcfg_ops = {
> 
>  struct pci_ops *pci_mcfg_get_ops(int domain, int bus)  {
> + struct pci_ops *pci_mcfg_ops_quirk;
> +
>   /*
> -  * TODO: Match against platform specific quirks and return
> -  * corresponding PCI config space accessor set.
> +  

Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

[David Daney]

On 12/21/2015 06:10 AM, Arnd Bergmann wrote:

On Monday 21 December 2015, Gabriele Paoloni wrote:

-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki



Some platforms may not be fully compliant with generic set of PCI
config accessors. For these cases we implement the way to overwrite
accessors set before PCI buses enumeration. Algorithm that overwrite
accessors matches against platform ID (DMI), domain and bus number,
hopefully enough for all cases. All quirks can be defined using:
DECLARE_ACPI_MCFG_FIXUP() and keep self contained.


I've got a couple of comments/questions about this patch..

1) So according to this mechanism quirks would be supported only by
vendors whose BIOS are SMBIOS compliant. Now personally I am ok
with this but I don't know if this is OK in general as it would
narrow down the number of platforms that would be able to define
the quirks...
Lorenzo, Arnd what is your opinion here?


I'd rather not see the quirks in mainline at all, and only support
SBSA compliant machines,


There seems to exist a class of systems that were intended to be SBSA 
compliant, but after they were manufactured turn out to not be fully 
complaint.  It would be nice to have Linux kernel support for some of 
these systems


There also seems to be historical precedent for quirk frameworks in 
various kernel subsystems to handle systems and devices that are not 
fully "Spec. Compliant".



or require the BIOS to work around the hardware
quirks differently (e.g. by trapping config space access through secure
firmware, or going through an AML method to be defined).


Some systems don't seem to have this capability.  For example, in ARMv8 
(A.K.A. arm64), I haven't been able to figure out how to trap these 
accesses to EL3 for emulation.  The specification is 5700 pages long 
though, so perhaps I missed that bit.



I'm certainly
ok with making it depend on SMBIOS if we are going to use something like this.

Arnd



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/