From: Honghui Zhang <[email protected]>
Two fixups for mediatek's host bridge:
The first patch fixup the IRQ handle routine to avoid IRQ reentry which
may exist for both MT2712 and MT7622.
The second patch fixup class type for MT7622.
Change Since v1:
- Add the second patch.
- Make the first patch's commit message more standard.
Honghui Zhang (2):
PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
PCI: mediatek: Fixup class type for MT7622
drivers/pci/host/pcie-mediatek.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--
2.6.4
From: Honghui Zhang <[email protected]>
There maybe a same IRQ reentry scenario after IRQ received in current
IRQ handle flow:
EP device PCIe host driver EP driver
1. issue an IRQ
2. received IRQ
3. clear IRQ status
4. dispatch IRQ
5. clear IRQ source
The IRQ status was not successfully cleared at step 2 since the IRQ
source was not cleared yet. So the PCIe host driver may receive the
same IRQ after step 5. Then there's an IRQ reentry occurred.
Even worse, if the reentry IRQ was not an IRQ that EP driver expected,
it may not handle the IRQ. Then we may run into the infinite loop from
step 2 to step 4.
Clear the IRQ status after IRQ have been dispatched to avoid the IRQ
reentry.
Signed-off-by: Honghui Zhang <[email protected]>
Acked-by: Ryder Lee <[email protected]>
---
drivers/pci/host/pcie-mediatek.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index db93efd..3248771 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
- /* Clear the INTx */
- writel(1 << bit, port->base + PCIE_INT_STATUS);
virq = irq_find_mapping(port->irq_domain,
bit - INTX_SHIFT);
generic_handle_irq(virq);
+ /* Clear the INTx */
+ writel(1 << bit, port->base + PCIE_INT_STATUS);
}
}
@@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
- /* Clear the MSI */
- writel(1 << bit, port->base + PCIE_IMSI_STATUS);
virq = irq_find_mapping(port->msi_domain, bit);
generic_handle_irq(virq);
+ /* Clear the MSI */
+ writel(1 << bit, port->base + PCIE_IMSI_STATUS);
}
}
/* Clear MSI interrupt status */
--
2.6.4
From: Honghui Zhang <[email protected]>
The host bridge of MT7622 has hardware code the class code to an
arbitrary, meaningless value, fix that.
Signed-off-by: Honghui Zhang <[email protected]>
---
drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 3248771..ae8d367 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
},
};
builtin_platform_driver(mtk_pcie_driver);
+
+/* The host bridge of MT7622 advertises the wrong device class. */
+static void mtk_fixup_class(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+
+/*
+ * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
+ * 0x3258, which are arbitrary, meaningless values.
+ */
+DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
--
2.6.4
On Thu, 2017-12-21 at 10:11 +0800, [email protected] wrote:
> From: Honghui Zhang <[email protected]>
>
> The host bridge of MT7622 has hardware code the class code to an
> arbitrary, meaningless value, fix that.
>
> Signed-off-by: Honghui Zhang <[email protected]>
> ---
> drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> index 3248771..ae8d367 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
> },
> };
> builtin_platform_driver(mtk_pcie_driver);
> +
> +/* The host bridge of MT7622 advertises the wrong device class. */
> +static void mtk_fixup_class(struct pci_dev *dev)
> +{
> + dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> +}
> +
> +/*
> + * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
> + * 0x3258, which are arbitrary, meaningless values.
> + */
What's the right vendor id and device id? is it possible to fix them
too?
> +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> On Thu, 2017-12-21 at 10:11 +0800, [email protected] wrote:
> > From: Honghui Zhang <[email protected]>
> >
> > The host bridge of MT7622 has hardware code the class code to an
> > arbitrary, meaningless value, fix that.
> >
> > Signed-off-by: Honghui Zhang <[email protected]>
> > ---
> > drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > index 3248771..ae8d367 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
> > },
> > };
> > builtin_platform_driver(mtk_pcie_driver);
> > +
> > +/* The host bridge of MT7622 advertises the wrong device class. */
> > +static void mtk_fixup_class(struct pci_dev *dev)
> > +{
> > + dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> > +}
> > +
> > +/*
> > + * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
> > + * 0x3258, which are arbitrary, meaningless values.
> > + */
>
> What's the right vendor id and device id? is it possible to fix them
> too?
Vendor ID is managed by PCI-SIG, you may get the assigned vendor ID
from:
https://pci-ids.ucw.cz/read/PC?restrict=
The vendor ID for Mediatek Corp. should be 14c3.
Device ID is something like vendor-defined.
Those values are in the configuration space and are read-only defined by
spec, it's been stored at the pci_dev, we may change the vendor and
device values in pci_dev, but I don't think it's necessary to change
that.
BTW, Does anyone really cares about the vendor ID and device ID except
the device's driver?
thanks.
>
> > +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
>
>
On Thu, Dec 21, 2017 at 03:01:12PM +0800, Honghui Zhang wrote:
> On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> > On Thu, 2017-12-21 at 10:11 +0800, [email protected] wrote:
> > > From: Honghui Zhang <[email protected]>
> > >
> > > The host bridge of MT7622 has hardware code the class code to an
> > > arbitrary, meaningless value, fix that.
> > >
> > > Signed-off-by: Honghui Zhang <[email protected]>
> > > ---
> > > drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > > index 3248771..ae8d367 100644
> > > --- a/drivers/pci/host/pcie-mediatek.c
> > > +++ b/drivers/pci/host/pcie-mediatek.c
> > > @@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
> > > },
> > > };
> > > builtin_platform_driver(mtk_pcie_driver);
> > > +
> > > +/* The host bridge of MT7622 advertises the wrong device class. */
> > > +static void mtk_fixup_class(struct pci_dev *dev)
> > > +{
> > > + dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> > > +}
> > > +
> > > +/*
> > > + * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
> > > + * 0x3258, which are arbitrary, meaningless values.
They may be arbitrary but they are certainly not meaningless.
> > What's the right vendor id and device id? is it possible to fix them
> > too?
>
> Vendor ID is managed by PCI-SIG, you may get the assigned vendor ID
> from:
> https://pci-ids.ucw.cz/read/PC?restrict=
It's true that Vendor IDs are managed by the PCI-SIG. The link above
is not managed by the PCI-SIG and is not the official list of assigned
Vendor IDs.
> The vendor ID for Mediatek Corp. should be 14c3.
> Device ID is something like vendor-defined.
> Those values are in the configuration space and are read-only defined by
> spec, it's been stored at the pci_dev, we may change the vendor and
> device values in pci_dev, but I don't think it's necessary to change
> that.
> BTW, Does anyone really cares about the vendor ID and device ID except
> the device's driver?
Yes. This is a fundamental misunderstanding of how Vendor and Device
IDs work. The *driver* really doesn't care about the IDs. The PCI
*core* cares about them because it uses the IDs to select the
appropriate driver to bind to the device.
> > > +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
This is absolutely not OK. You cannot take over Vendor ID 0x0e8d
unless it has been assigned to you by the PCI-SIG.
To my knowledge, 0x0e8d has not been assigned to any company yet, but
the PCI-SIG could assign it to some new company X tomorrow. Company X
may then build a device with Device ID 0x3258. Now we cannot tell the
difference between the Company X device that is correctly designed and
this Mediatek device that is broken.
This quirk would improperly overwrite dev->class for the Company X
device, and we would not be able to bind the correct driver to either
device.
I am amazed that somebody could build a device that claims to be a PCI
device and get the Vendor ID wrong. That should be literally the
first thing the hardware designer does. If you have hardware in the
field that uses the wrong Vendor ID, it is definitely not
PCI-compliant.
Bjorn
On Thu, 2017-12-21 at 18:27 -0600, Bjorn Helgaas wrote:
> On Thu, Dec 21, 2017 at 03:01:12PM +0800, Honghui Zhang wrote:
> > On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> > > On Thu, 2017-12-21 at 10:11 +0800, [email protected] wrote:
> > > > From: Honghui Zhang <[email protected]>
> > > >
> > > > The host bridge of MT7622 has hardware code the class code to an
> > > > arbitrary, meaningless value, fix that.
> > > >
> > > > Signed-off-by: Honghui Zhang <[email protected]>
> > > > ---
> > > > drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > > > index 3248771..ae8d367 100644
> > > > --- a/drivers/pci/host/pcie-mediatek.c
> > > > +++ b/drivers/pci/host/pcie-mediatek.c
> > > > @@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
> > > > },
> > > > };
> > > > builtin_platform_driver(mtk_pcie_driver);
> > > > +
> > > > +/* The host bridge of MT7622 advertises the wrong device class. */
> > > > +static void mtk_fixup_class(struct pci_dev *dev)
> > > > +{
> > > > + dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> > > > +}
> > > > +
> > > > +/*
> > > > + * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
> > > > + * 0x3258, which are arbitrary, meaningless values.
>
> They may be arbitrary but they are certainly not meaningless.
>
> > > What's the right vendor id and device id? is it possible to fix them
> > > too?
> >
> > Vendor ID is managed by PCI-SIG, you may get the assigned vendor ID
> > from:
> > https://pci-ids.ucw.cz/read/PC?restrict=
>
> It's true that Vendor IDs are managed by the PCI-SIG. The link above
> is not managed by the PCI-SIG and is not the official list of assigned
> Vendor IDs.
>
> > The vendor ID for Mediatek Corp. should be 14c3.
> > Device ID is something like vendor-defined.
> > Those values are in the configuration space and are read-only defined by
> > spec, it's been stored at the pci_dev, we may change the vendor and
> > device values in pci_dev, but I don't think it's necessary to change
> > that.
> > BTW, Does anyone really cares about the vendor ID and device ID except
> > the device's driver?
>
> Yes. This is a fundamental misunderstanding of how Vendor and Device
> IDs work. The *driver* really doesn't care about the IDs. The PCI
> *core* cares about them because it uses the IDs to select the
> appropriate driver to bind to the device.
>
Thanks, I was wrong about this, I had not seen that the Vendor IDs may
be assigned to another company in the future. I should try another way
to fix this.
> > > > +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
>
> This is absolutely not OK. You cannot take over Vendor ID 0x0e8d
> unless it has been assigned to you by the PCI-SIG.
>
> To my knowledge, 0x0e8d has not been assigned to any company yet, but
> the PCI-SIG could assign it to some new company X tomorrow. Company X
> may then build a device with Device ID 0x3258. Now we cannot tell the
> difference between the Company X device that is correctly designed and
> this Mediatek device that is broken.
>
> This quirk would improperly overwrite dev->class for the Company X
> device, and we would not be able to bind the correct driver to either
> device.
>
I will try another way to fix this, thanks very much for your explain.
> I am amazed that somebody could build a device that claims to be a PCI
> device and get the Vendor ID wrong. That should be literally the
> first thing the hardware designer does. If you have hardware in the
> field that uses the wrong Vendor ID, it is definitely not
> PCI-compliant.
There's an internal control register that control the Vendor ID and
device ID values, our designer leave the default value un-touched. I
will set these values in that way for the next version of fix.
Thanks.
>
> Bjorn
On Fri, Dec 22, 2017 at 08:56:34AM +0800, Honghui Zhang wrote:
> There's an internal control register that control the Vendor ID and
> device ID values, our designer leave the default value un-touched. I
> will set these values in that way for the next version of fix.
Then there's no problem. The mtk_pcie driver is a platform driver
that claims the host controller based on an of_device_id from a device
tree.
Apparently the bridge is also materialized in PCI config space, which
is typical for x86 host bridges, and makes the bridge appear in
"lspci". But drivers generally don't claim bridges that way.
You can just program the Vendor and Device IDs by writing the internal
control registers somewhere in the mtk_pci_probe() path.
Then you can set the class code the same way, using an internal
control register (if that's possible), or using a quirk with the
correct Mediatek Vendor ID (if there is no internal writable
register).
Bjorn