Re: [PATCH] PCI: mediatek: get optional clock by devm_clk_get_optional()

[Honghui Zhang]

On Sat, 2019-03-30 at 18:00 +0800, Chunfeng Yun wrote:
> Use devm_clk_get_optional() to get optional clock
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 46 ++
>  1 file changed, 11 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index 0b6c72804e03..9a66a018489b 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -915,49 +915,25 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
>  
>   /* sys_ck might be divided into the following parts in some chips */
>   snprintf(name, sizeof(name), "ahb_ck%d", slot);
> - port->ahb_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->ahb_ck)) {
> - if (PTR_ERR(port->ahb_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->ahb_ck = NULL;
> - }
> + port->ahb_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->ahb_ck))
> + return PTR_ERR(port->ahb_ck);
>  
>   snprintf(name, sizeof(name), "axi_ck%d", slot);
> - port->axi_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->axi_ck)) {
> - if (PTR_ERR(port->axi_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->axi_ck = NULL;
> - }
> + port->axi_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->axi_ck);
>  
>   snprintf(name, sizeof(name), "aux_ck%d", slot);
> - port->aux_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->aux_ck)) {
> - if (PTR_ERR(port->aux_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->aux_ck = NULL;
> - }
> + port->aux_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->aux_ck);
>  
>   snprintf(name, sizeof(name), "obff_ck%d", slot);
> - port->obff_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->obff_ck)) {
> - if (PTR_ERR(port->obff_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->obff_ck = NULL;
> - }
> + port->obff_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->obff_ck);
>  
>   snprintf(name, sizeof(name), "pipe_ck%d", slot);
> - port->pipe_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->pipe_ck)) {
> - if (PTR_ERR(port->pipe_ck) == -EPROBE_DEFER)
> -     return -EPROBE_DEFER;
> -
> - port->pipe_ck = NULL;
> - }
> + port->pipe_ck = devm_clk_get_optional(dev, name);
> + return PTR_ERR(port->pipe_ck);
>  

Hi, Chunfeng,

Thanks for this patch, I had not noticed that the devm_clk_get_optional
have been applied, I like this change.

Acked-by: Honghui Zhang 

>   snprintf(name, sizeof(name), "pcie-rst%d", slot);
>   port->reset = devm_reset_control_get_optional_exclusive(dev, name);

Re: [PATCH 7/8] PCI: mediatek: fix a leaked reference by adding missing of_node_put

[Honghui Zhang]

On Wed, 2019-02-27 at 12:40 +0800, Wen Yang wrote:
> The call to of_get_next_child returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
> irq_domain_add_linear also calls of_node_get to increase refcount,
> so irq_domain will not be affected when it is released.
> 
> Detected by coccinelle with the following warnings:
> ./drivers/pci/controller/pcie-mediatek.c:577:2-8: ERROR: missing of_node_put; 
> acquired a node pointer with refcount incremented on line 567, but without a 
> corresponding object release within this function.
> ./drivers/pci/controller/pcie-mediatek.c:583:3-9: ERROR: missing of_node_put; 
> acquired a node pointer with refcount incremented on line 567, but without a 
> corresponding object release within this function.
> ./drivers/pci/controller/pcie-mediatek.c:586:1-7: ERROR: missing of_node_put; 
> acquired a node pointer with refcount incremented on line 567, but without a 
> corresponding object release within this function.
> 
> Signed-off-by: Wen Yang 
> Cc: Ryder Lee 
> Cc: Lorenzo Pieralisi 
> Cc: Bjorn Helgaas 
> Cc: Matthias Brugger 
> Cc: linux-...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>  drivers/pci/controller/pcie-mediatek.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index 55e471c..e91716a 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -572,6 +572,7 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
> *port,
>  
>   port->irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
>_domain_ops, port);
> + of_node_put(pcie_intc_node);
>   if (!port->irq_domain) {
>   dev_err(dev, "failed to get INTx IRQ domain\n");
>   return -ENODEV;

Thanks for fix this.

Acked-by: Honghui Zhang 

Re: [PATCH v3 2/2] PCI: mediatek: Enlarge PCIe2AHB window size to support 4GB DRAM

[Honghui Zhang]

On Thu, 2019-02-28 at 17:42 +, Lorenzo Pieralisi wrote:
> On Fri, Feb 01, 2019 at 01:36:07PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The PCIE_AXI_WINDOW0 defines the translate window size for the request
> > from EP side. Request outside of this window will be treated as
> > unsupported request.
> > 
> > Enlarge this window size from fls(0x) to 2^33 to support 8GB
> > translate address range then EP DMA is capable of fully access 4GB
> > DRAM range(physical DRAM is start from 0x4000).
> 
> I have rewritten both patches logs with the aim of merging them even if
> it is quite late in the cycle, first you have to explain something to
> me.
> 

Thanks very much for this.

> fls(0x) = 0x1f, which by your logic -> 2^31
> 
> What does it mean given what you say above ? That PCI devices can't
> do _any_ DMA in the current setting (given the DRAM start address) ?
> 

I'm afraid so.
>From the HW datasheet I got from our HW designer, the description for
this pcie2axi_win_size filed is
" Possible values are 12 to 36 which means 2^12 to 2^36 bytes, leaving
this filed to 0 causes window to be disabled."

Current setting set the window size as 2^31, which means the request
from EP side could only access the address range from 0 to 0x8000_.
Considering the DRAM start from 0x4000_, that means only the first
1GB(0x4000_ ~ 0x8000_) could be accessed by EP side DMA.

This has not run into an error for our current usage, I guess because
MT2712 and MT7622 have several type boards, most of are only have 2GB
physical memory, and our test sample is not bigger enough to cover the
case that EP DMA will access fully DRAM. Or most EP device does not have
an built-in DMA engine, they may relay on the host side's MMIO(memory
mapped IO) operations.
 
Take MT2712 as example, in arch/arm64/boot/dts/mediatek/mt2712-evb.dts,
the physical memory size is defined as 0x8000 and is described by
below node:

memory@4 {
device_type = "memory";
    reg = <0 0x4 0 0x8>
}

Thanks.

> Lorenzo
> 
> > Reported-by: Bjorn Helgaas 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index c42fe5c..0b6c728 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -90,6 +90,12 @@
> >  #define AHB2PCIE_SIZE(x)   ((x) & GENMASK(4, 0))
> >  #define PCIE_AXI_WINDOW0   0x448
> >  #define WIN_ENABLE BIT(7)
> > +/*
> > + * Define PCIe to AHB window size as 2^33 to support max 8GB address space
> > + * translate, support least 4GB DRAM size access from EP DMA(physical DRAM
> > + * start from 0x4000).
> > + */
> > +#define PCIE2AHB_SIZE  0x21
> >  
> >  /* PCIe V2 configuration transaction header */
> >  #define PCIE_CFG_HEADER0   0x460
> > @@ -713,7 +719,7 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > writel(val, port->base + PCIE_AHB_TRANS_BASE0_H);
> >  
> > /* Set PCIe to AXI translation memory space.*/
> > -   val = fls(0x) | WIN_ENABLE;
> > +   val = PCIE2AHB_SIZE | WIN_ENABLE;
> > writel(val, port->base + PCIE_AXI_WINDOW0);
> >  
> > return 0;
> > -- 
> > 2.6.4
> > 

Re: [RFC PATCH] PCI/portdrv: Support for subtractive decode bridge

[Honghui Zhang]

On Thu, 2019-02-07 at 13:52 -0600, Bjorn Helgaas wrote:
> On Thu, Feb 07, 2019 at 09:18:16AM -0600, Bjorn Helgaas wrote:
> > On Fri, Dec 14, 2018 at 11:40:29AM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > The Class Code for subtractive decode PCI-to-PCI bridge is 060401h,
> > > change the class_mask values to make portdrv support this type bridge.
> > 
> > I assume you have a Root Port or Switch Port that supports subtractive
> > decode?  I'm trying to understand how such a device would work.
> > 
> > Out of curiosity, can you show the "lspci -vv" output for the device
> > and the downstream devices of interest?
> 
> Actually, since subtractive decode has to do with how the bridge
> interacts with its *peers*, what would be interesting is the host
> bridge window information from ACPI _CRS or DT and the lspci info for
> everything under that host bridge.
> 
> Assuming we're talking about a Root Port, I guess that would mean
> anything inside the host bridge windows but outside the positive
> decode windows (the normal PCI-PCI bridge apertures in the Root Ports)
> would be claimed by the subtractive decode Root Port?

Per my understanding, mediatek's Root Port does not claim anything, or
it's fine to assign no resource which is dedicated to this bridge. Those
information could be got through lspci output which is attached in the
last mail. All the resource it claimed is from the subordinate device,
bridge itself does not need any special resource.
> 
> I guess you would want this because this path ultimately leads to an
> ISA or similar bus where you don't know what resources the device
> actually consumes?
> 
I was not get to that far, I just want to start a discussion about this,
since spec does not forbidden subtractive bridge to support port
service.

Thanks.

> Bjorn

Re: [RFC PATCH] PCI/portdrv: Support for subtractive decode bridge

[Honghui Zhang]

On Thu, 2019-02-07 at 09:18 -0600, Bjorn Helgaas wrote:
> Hi Honghui,
> 
> On Fri, Dec 14, 2018 at 11:40:29AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The Class Code for subtractive decode PCI-to-PCI bridge is 060401h,
> > change the class_mask values to make portdrv support this type bridge.
> 
> I assume you have a Root Port or Switch Port that supports subtractive
> decode?  I'm trying to understand how such a device would work.
> 
Hi, Bjorn,

Yes, most of Mediatek's RC device have set the class type as 060401h as
HW default values, include mt2712 and mt7622.

Those RC device work fine with all I have tried EP device except that
the portdrv was not attached to those device. But no scenario need those
service as far as I know.

> Out of curiosity, can you show the "lspci -vv" output for the device
> and the downstream devices of interest?
> 
lspci only read the class type 0604h, it does not care about the
subordinate values of the class type. I will put the "lspci -vv" output
at bottom of this mail.

> Do you happen to know whether this functionality is configurable,
> e.g., is there some way software can enable or disable subtractive
> decode?  I assume this would be some device-specific thing, because I
> can't find anything in the Bridge Control register or similar.  The
> PCIe spec doesn't even contain the word "subtractive".
> 

Those class type values for Mediatek's RC has a register which could be
used to change its values. We never touch this backdoor register since
without the portdrv attached is fine, nobody ask for the port service
yet.

I did some homework for the subtractive decode PCI-to-PCI bridge, and
did not found much more information about that. I guess those port
service should also support subtractive bridge since spec does not
forbidden that.

> The "PCI Express to PCI/PCI-X Bridge Specification", r1.0, says a PCI
> Express bridge (which would include Root Ports and Switch Ports) has a
> Class Code of 0x060400 (Non-Subtractive PCI-PCI Bridge) (sec 1.1).
> 
> Sec 1.3.4 says subtractive decode on the primary interface is "not
> applicable or outside the scope of this spec".
> 
> Bjorn
> 



# lspci -vvv
00:01.0 Class 0604: Device 14c3:5396
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR-  (64-bit, prefetchable)
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: -0fff
Memory behind bridge: 2000-206f
Prefetchable memory behind bridge: -000f
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=slow >TAbort-
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 0807a0c0  Data: 
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express (v2) Root Port (Slot+), MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend+
LnkCap: Port #1, Speed 5GT/s, Width x2, ASPM L0s L1,
Exit Latency L0s <64ns, L1 <2us
ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
LnkCtl: ASPM L1 Enabled; RCB 128 bytes Disabled- CommClk
+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug-
Surprise-
Slot #0, PowerLimit 0.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt-
HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power-
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt-
PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-,
LTR+, OBFF Not Supported ARIFwd-
   

Re: [PATCH v2 1/2] PCI: mediatek: Use resource_size function on resource object

[Honghui Zhang]

On Thu, 2019-01-31 at 15:36 -0600, Bjorn Helgaas wrote:
> On Thu, Jan 31, 2019 at 04:01:52PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > scripts/coccinelle/api/resource_size.cocci complain about the
> > following warning:
> > 
> > pcie-mediatek.c:720:13-16: WARNING: Suspicious code. resource_size is maybe 
> > missing with mem
> > 
> > Use resource_size(mem) instead of mem->end - mem->start to eliminate the
> > complain. Since the MMIO window size for both MT2712 and MT7622 are all
> > 0x1000_, this change also fix the AHB2PCIe window size smaller than
> > HW MMIO window size issue by change the values of fls(size) from
> > fls(0xfff_) to fls(0x1000_).
> 
> Good, I'm glad this actually fixes a bug.  The warning was actually
> useful!
> 
> Since that's the case, the *bug* is the important thing (not the
> warning), and the subject line should be about the bug fix.  The fact
> that it also happens to remove a warning is really just incidental.
> 
> You say "the AHB2PCIe window size smaller than HW MMIO window size
> issue" as though it should be familiar to us.  But it's not :)
> 

Oh, My bad.

The HW design assigned a bus address range(typically start from
0x2000_ to 0x2fff_ for both mt2712 and mt7622) for PCIe usage.
This means, when CPU or other HW access address in this range, PCIe RC
HW should response to this access. Normally it will translate those
access request to TLPs and send to EP side. Tt's like the total memory
resource which could be allocated by EP's BAR and RC's itself BAR.

Although those address range is available for allocated, but it should
be enabled by this PCIE_AHB_TRANS_BASE register, what size should be
enabled is determined by AHB2PCIE_SIZE bits in this register.

In previous code we did not enable the full size of HW assigned address
range, if the EP's BAR requested size is bigger than the size we enabled
and smaller than the HW available size. The access request from CPU
which address is bigger than the address we enabled but smaller that HW
available address, then RC will block those request and those request
will never get to EP side by TLPs.

Previous code never run into a system error in production because even
half of those range(128MB) is bigger enough for typical EP device's BAR
request(4MB).

But all those HW assigned bus range should be enabled. And it's Okay to
do that. RC will never forward a request to EP when this request is not
suitable for EP's BAR range.


> So the changelog needs to start by explaining what the AHB2PCIe window
> size issue is, mention what user-visible problem that causes, then
> explain how you're fixing it by using resource_size().
> 
> Then you can mention that this also incidentally removes a coccinelle
> warning.
> 

Okay, thanks for your advise.

> Bjorn
> 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 55e471c..01126b8 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -654,7 +654,6 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > struct resource *mem = >mem;
> > const struct mtk_pcie_soc *soc = port->pcie->soc;
> > u32 val;
> > -   size_t size;
> > int err;
> >  
> > /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
> > @@ -706,8 +705,8 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > mtk_pcie_enable_msi(port);
> >  
> > /* Set AHB to PCIe translation windows */
> > -   size = mem->end - mem->start;
> > -   val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
> > +   val = lower_32_bits(mem->start)
> > + | AHB2PCIE_SIZE(fls(resource_size(mem)));
> 
> Nit: I think it's more typical to put the "|" on the first line.

Okay, will update this in next version.

Thanks for your comments.

> 
> > writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
> >  
> > val = upper_32_bits(mem->start);
> > -- 
> > 2.6.4
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v1] PCI: mediatek: Remove MSI inner domain

[Honghui Zhang]

On Tue, 2019-01-22 at 17:37 +0800, Jianjun Wang wrote:
> There is no need to create the inner domain as a parent for MSI domian,
> some feature has been implemented by MSI framework.
> 
> Remove the inner domain and its irq chip, it will be more closer to
> hardware implementation.
> 
Hi, jianjun, I'm not quite familiar with the irq_chip framework, It was
under Marc's great help with the first version of irq_chip solution
code. I would like you to add him for the review.

Thanks.

> Signed-off-by: Jianjun Wang 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 86 +++---
>  1 file changed, 37 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index 8d05df56158b..f996a9a6331f 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -169,7 +169,6 @@ struct mtk_pcie_soc {
>   * @slot: port slot
>   * @irq: GIC irq
>   * @irq_domain: legacy INTx IRQ domain
> - * @inner_domain: inner IRQ domain
>   * @msi_domain: MSI IRQ domain
>   * @lock: protect the msi_irq_in_use bitmap
>   * @msi_irq_in_use: bit map for assigned MSI IRQ
> @@ -190,7 +189,6 @@ struct mtk_pcie_port {
>   u32 slot;
>   int irq;
>   struct irq_domain *irq_domain;
> - struct irq_domain *inner_domain;
>   struct irq_domain *msi_domain;
>   struct mutex lock;
>   DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> @@ -418,22 +416,15 @@ static void mtk_msi_ack_irq(struct irq_data *data)
>   u32 hwirq = data->hwirq;
>  
>   writel(1 << hwirq, port->base + PCIE_IMSI_STATUS);
> + writel(MSI_STATUS, port->base + PCIE_INT_STATUS);
>  }
>  
> -static struct irq_chip mtk_msi_bottom_irq_chip = {
> - .name   = "MTK MSI",
> - .irq_compose_msi_msg= mtk_compose_msi_msg,
> - .irq_set_affinity   = mtk_msi_set_affinity,
> - .irq_ack= mtk_msi_ack_irq,
> -};
> -
> -static int mtk_pcie_irq_domain_alloc(struct irq_domain *domain, unsigned int 
> virq,
> -  unsigned int nr_irqs, void *args)
> +static irq_hw_number_t mtk_pcie_msi_get_hwirq(struct msi_domain_info *info,
> +   msi_alloc_info_t *arg)
>  {
> - struct mtk_pcie_port *port = domain->host_data;
> - unsigned long bit;
> + struct mtk_pcie_port *port = info->chip_data;
> + irq_hw_number_t bit;
>  
> - WARN_ON(nr_irqs != 1);
>   mutex_lock(>lock);
>  
>   bit = find_first_zero_bit(port->msi_irq_in_use, MTK_MSI_IRQS_NUM);
> @@ -446,18 +437,14 @@ static int mtk_pcie_irq_domain_alloc(struct irq_domain 
> *domain, unsigned int vir
>  
>   mutex_unlock(>lock);
>  
> - irq_domain_set_info(domain, virq, bit, _msi_bottom_irq_chip,
> - domain->host_data, handle_edge_irq,
> - NULL, NULL);
> -
> - return 0;
> + return bit;
>  }
>  
> -static void mtk_pcie_irq_domain_free(struct irq_domain *domain,
> -  unsigned int virq, unsigned int nr_irqs)
> +static void mtk_pcie_msi_free(struct irq_domain *domain,
> +   struct msi_domain_info *info, unsigned int virq)
>  {
>   struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> - struct mtk_pcie_port *port = irq_data_get_irq_chip_data(d);
> + struct mtk_pcie_port *port = info->chip_data;
>  
>   mutex_lock(>lock);
>  
> @@ -468,46 +455,50 @@ static void mtk_pcie_irq_domain_free(struct irq_domain 
> *domain,
>   __clear_bit(d->hwirq, port->msi_irq_in_use);
>  
>   mutex_unlock(>lock);
> -
> - irq_domain_free_irqs_parent(domain, virq, nr_irqs);
>  }
>  
> -static const struct irq_domain_ops msi_domain_ops = {
> - .alloc  = mtk_pcie_irq_domain_alloc,
> - .free   = mtk_pcie_irq_domain_free,
> +static struct msi_domain_ops mtk_msi_domain_ops = {
> + .get_hwirq  = mtk_pcie_msi_get_hwirq,
> + .msi_free   = mtk_pcie_msi_free,
>  };
>  
>  static struct irq_chip mtk_msi_irq_chip = {
> - .name   = "MTK PCIe MSI",
> - .irq_ack= irq_chip_ack_parent,
> - .irq_mask   = pci_msi_mask_irq,
> - .irq_unmask = pci_msi_unmask_irq,
> + .name   = "MTK PCIe",
> + .irq_compose_msi_msg= mtk_compose_msi_msg,
> + .irq_write_msi_msg  = pci_msi_domain_write_msg,
> + .irq_set_affinity   = mtk_msi_set_affinity,
> + .irq_ack= mtk_msi_ack_irq,
> + .irq_mask   = pci_msi_mask_irq,
> + .irq_unmask = pci_msi_unmask_irq,
>  };
>  
>  static struct msi_domain_info mtk_msi_domain_info = {
> - .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> -MSI_FLAG_PCI_MSIX),
> - .chip   = _msi_irq_chip,
> + .flags  = (MSI_FLAG_USE_DEF_DOM_OPS |
> +MSI_FLAG_USE_DEF_CHIP_OPS | MSI_FLAG_PCI_MSIX),
> + 

Re: [PATCH] PCI: Mediatek: Use resource_size function on resource object

[Honghui Zhang]

On Thu, 2019-01-31 at 11:03 +0800, Honghui Zhang wrote:
> On Wed, 2019-01-30 at 09:49 -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 02, 2019 at 02:03:53PM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > drivers/pci/pcie-mediatek.c:720:13-16: WARNING: Suspicious code. 
> > > resource_size is maybe missing with mem
> > > 
> > > Generated by: scripts/coccinelle/api/resource_size.cocci
> > > 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index e307166..0168376 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -654,7 +654,6 @@ static int mtk_pcie_startup_port_v2(struct 
> > > mtk_pcie_port *port)
> > >   struct resource *mem = >mem;
> > >   const struct mtk_pcie_soc *soc = port->pcie->soc;
> > >   u32 val;
> > > - size_t size;
> > >   int err;
> > >  
> > >   /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
> > > @@ -706,8 +705,7 @@ static int mtk_pcie_startup_port_v2(struct 
> > > mtk_pcie_port *port)
> > >   mtk_pcie_enable_msi(port);
> > >  
> > >   /* Set AHB to PCIe translation windows */
> > > - size = mem->end - mem->start;
> > > - val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
> > > + val = lower_32_bits(mem->start) | 
> > > AHB2PCIE_SIZE(fls(resource_size(mem)));
> > 
> > This is actually a fairly interesting change because it effectively
> > changes this:
> > 
> >   fls(mem->end - mem->start)
> > 
> > to this:
> > 
> >   fls(mem->end - mem->start + 1)
> > 
> > And mem->end is the last valid address, so it changes something like
> > this:
> > 
> >   fls(0x) # == 15
> > 
> > to this:
> > 
> >   fls(0x1)# == 16
> > 
> > So while this *looks* like a trivial warning fix, it likely fixes an
> > important bug, and it's worth pointing out what that bug is in the
> > changelog.
> > 
> > >   writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
> > >  
> > >   val = upper_32_bits(mem->start);
> 
> This size will set the MMIO size, which means that the RC will translate
> the MMIO access from mem->start to mem->end.
> The real MMIO size is specified in devicetree, which is 0x1000_ for
> both mt2712 and mt7622.
> 
> This change make the size from fls(0x1000_) to fls(0x1000_0001), not
> really change the values.
> 
> I will update the commit message and add the information mentioned
> above.
> 
> Thanks for your kindly review.

I was wrong, after take a look at the resource parser function, that it
will initialize the res->end as res->start + res->size - 1.

But this change is still Ok since it will change the MMIO from
fls(0xfff_) to fls(0x1000_), this just enlarge the MMIO
translate window size. The HW assigned MMIO is 0x1000_, but original
code set this translate window to fls(0xfff_) = 0x800_ is fine
in most case since all the EP device we connect never asked a MMIO
window bigger than 0x800_. (As a matter of fact, most EP device will
only ask for 4MB MMIO window size.)

I will put this in the commit message.

thanks.
> 
> >  > -- 
> > > 2.6.4
> > > 
> 
> 

Re: [PATCH] PCI: Mediatek: Use resource_size function on resource object

[Honghui Zhang]

On Wed, 2019-01-30 at 09:49 -0600, Bjorn Helgaas wrote:
> On Wed, Jan 02, 2019 at 02:03:53PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > drivers/pci/pcie-mediatek.c:720:13-16: WARNING: Suspicious code. 
> > resource_size is maybe missing with mem
> > 
> > Generated by: scripts/coccinelle/api/resource_size.cocci
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index e307166..0168376 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -654,7 +654,6 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > struct resource *mem = >mem;
> > const struct mtk_pcie_soc *soc = port->pcie->soc;
> > u32 val;
> > -   size_t size;
> > int err;
> >  
> > /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
> > @@ -706,8 +705,7 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > mtk_pcie_enable_msi(port);
> >  
> > /* Set AHB to PCIe translation windows */
> > -   size = mem->end - mem->start;
> > -   val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
> > +   val = lower_32_bits(mem->start) | 
> > AHB2PCIE_SIZE(fls(resource_size(mem)));
> 
> This is actually a fairly interesting change because it effectively
> changes this:
> 
>   fls(mem->end - mem->start)
> 
> to this:
> 
>   fls(mem->end - mem->start + 1)
> 
> And mem->end is the last valid address, so it changes something like
> this:
> 
>   fls(0x) # == 15
> 
> to this:
> 
>   fls(0x1)# == 16
> 
> So while this *looks* like a trivial warning fix, it likely fixes an
> important bug, and it's worth pointing out what that bug is in the
> changelog.
> 
> > writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
> >  
> > val = upper_32_bits(mem->start);

This size will set the MMIO size, which means that the RC will translate
the MMIO access from mem->start to mem->end.
The real MMIO size is specified in devicetree, which is 0x1000_ for
both mt2712 and mt7622.

This change make the size from fls(0x1000_) to fls(0x1000_0001), not
really change the values.

I will update the commit message and add the information mentioned
above.

Thanks for your kindly review.

>  > -- 
> > 2.6.4
> > 

Re: [PATCH] PCI: Mediatek: Use resource_size function on resource object

[Honghui Zhang]

On Wed, 2019-01-30 at 16:31 +, Lorenzo Pieralisi wrote:
> On Wed, Jan 30, 2019 at 09:58:53AM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 30, 2019 at 12:33:47PM +, Lorenzo Pieralisi wrote:
> > > On Wed, Jan 02, 2019 at 02:03:53PM +0800, honghui.zh...@mediatek.com 
> > > wrote:
> > > > From: Honghui Zhang 
> > > > 
> > > > drivers/pci/pcie-mediatek.c:720:13-16: WARNING: Suspicious code. 
> > > > resource_size is maybe missing with mem
> > > > 
> > > > Generated by: scripts/coccinelle/api/resource_size.cocci
> > > > 
> > > > Signed-off-by: Honghui Zhang 
> > > > ---
> > > >  drivers/pci/controller/pcie-mediatek.c | 4 +---
> > > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > > b/drivers/pci/controller/pcie-mediatek.c
> > > > index e307166..0168376 100644
> > > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > > @@ -654,7 +654,6 @@ static int mtk_pcie_startup_port_v2(struct 
> > > > mtk_pcie_port *port)
> > > > struct resource *mem = >mem;
> > > > const struct mtk_pcie_soc *soc = port->pcie->soc;
> > > > u32 val;
> > > > -   size_t size;
> > > > int err;
> > > >  
> > > > /* MT7622 platforms need to enable LTSSM and ASPM from PCIe 
> > > > subsys */
> > > > @@ -706,8 +705,7 @@ static int mtk_pcie_startup_port_v2(struct 
> > > > mtk_pcie_port *port)
> > > > mtk_pcie_enable_msi(port);
> > > >  
> > > > /* Set AHB to PCIe translation windows */
> > > > -   size = mem->end - mem->start;
> > > > -   val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
> > > > +   val = lower_32_bits(mem->start) | 
> > > > AHB2PCIE_SIZE(fls(resource_size(mem)));
> > > 
> > > checkpatch warns on this line, please make sure patches pass it before
> > > posting them.
> > 
> > I didn't actually run checkpatch myself, so I don't know why it
> > complained.
> 
> WARNING: line over 80 characters
> #35: FILE: drivers/pci/controller/pcie-mediatek.c:708:
> + val = lower_32_bits(mem->start) | 
> AHB2PCIE_SIZE(fls(resource_size(mem)));
> 
> I do run it as a sanity check.
> 
> > The patch you merged moves "mem_size = resource_size(mem)" higher up,
> > away from the previous location and its use, which makes it a little
> > harder to read.
> 
> That's because it was how the original code (which as you pointed out
> is likely buggy) was written.
> 
> Anyway patch dropped waiting for a v2 consistent with your review -
> apologies for missing some key review points.
> 

Thanks for your comments, I will send a v2 and fix all the issue you
pointed out.

> Lorenzo

Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629

[Honghui Zhang]

On Fri, 2018-12-07 at 20:56 +0800, Jianjun Wang wrote:
> On Thu, 2018-12-06 at 13:53 +0800, Honghui Zhang wrote:
> > On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> > > MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> > > 
> > > The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> > > in arm64 but bogus alignment values at arm32, the pcie device and devices
> > 
> > :s /the pcie device /the bridge device
> > 
> > > behind this bridge will not be enabled. Fix it's BAR0 resource size to
> > > guarantee the pcie devices will be enabled correctly.
> > > 
> > > The HW default value of its device id is invalid, fix it's device id to
> > > match the hardware implementation.
> > > 
> > > Signed-off-by: Jianjun Wang 
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c | 26 ++
> > >  include/linux/pci_ids.h|  1 +
> > >  2 files changed, 27 insertions(+)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index d20cf461ba00..f8937cc3c87c 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -73,6 +73,7 @@
> > >  #define PCIE_MSI_VECTOR  0x0c0
> > >  
> > >  #define PCIE_CONF_VEND_ID0x100
> > > +#define PCIE_CONF_DEVICE_ID  0x102
> > >  #define PCIE_CONF_CLASS_ID   0x106
> > >  
> > >  #define PCIE_INT_MASK0x420
> > > @@ -135,12 +136,14 @@ struct mtk_pcie_port;
> > >  /**
> > >   * struct mtk_pcie_soc - differentiate between host generations
> > >   * @need_fix_class_id: whether this host's class ID needed to be fixed 
> > > or not
> > > + * @need_fix_device_id: whether this host's device ID needed to be fixed 
> > > or not
> > >   * @ops: pointer to configuration access functions
> > >   * @startup: pointer to controller setting functions
> > >   * @setup_irq: pointer to initialize IRQ functions
> > >   */
> > >  struct mtk_pcie_soc {
> > >   bool need_fix_class_id;
> > > + bool need_fix_device_id;
> > >   struct pci_ops *ops;
> > >   int (*startup)(struct mtk_pcie_port *port);
> > >   int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > > @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct 
> > > mtk_pcie_port *port)
> > >   writew(val, port->base + PCIE_CONF_CLASS_ID);
> > >   }
> > >  
> > > + if (soc->need_fix_device_id) {
> > > + val = PCI_DEVICE_ID_MEDIATEK_7629;
> > > + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> > > + }
> > > +
> > >   /* 100ms timeout value should be enough for Gen1/2 training */
> > >   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > >!!(val & PCIE_PORT_LINKUP_V2), 20,
> > > @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc 
> > > mtk_pcie_soc_mt7622 = {
> > >   .setup_irq = mtk_pcie_setup_irq,
> > >  };
> > >  
> > > +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> > > + .need_fix_class_id = true,
> > > + .need_fix_device_id = true,
> > > + .ops = _pcie_ops_v2,
> > > + .startup = mtk_pcie_startup_port_v2,
> > > + .setup_irq = mtk_pcie_setup_irq,
> > > +};
> > > +
> > > +static void mtk_fixup_bar_size(struct pci_dev *dev)
> > > +{
> > > + struct resource *dev_res = >resource[0];
> > > + /* 32bit resource length will calculate size to 0, set it smaller */
> > > + dev_res->end = 0xfffe;
> > > +}
> > 
> > I'm not sure assign the BAR0 size in driver to fit in the bogus
> > alignment is a good idea. Seems the size value of 0x_fffe also is an
> > arbitrary value.
> > Do we have a chance to change the resource framework code to make it
> > adopt this scenario?

I have take a look at the resource assign routine, it's better keep it
in current way.

Thanks.

> > 
> > Thanks.
> 
> I'm afraid not, the resource size length defined by phys_addr_t, which
> related to the hardware's physical address length. 
> It will be much more better if the BAR0 size is not related with the
> pcie to axi window, when we set the window to 4GB, the BAR0 size still
> have initial value, and we can set the BAR0 size value 

Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629

[Honghui Zhang]

On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> 
> The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> in arm64 but bogus alignment values at arm32, the pcie device and devices

:s /the pcie device /the bridge device

> behind this bridge will not be enabled. Fix it's BAR0 resource size to
> guarantee the pcie devices will be enabled correctly.
> 
> The HW default value of its device id is invalid, fix it's device id to
> match the hardware implementation.
> 
> Signed-off-by: Jianjun Wang 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 26 ++
>  include/linux/pci_ids.h|  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index d20cf461ba00..f8937cc3c87c 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -73,6 +73,7 @@
>  #define PCIE_MSI_VECTOR  0x0c0
>  
>  #define PCIE_CONF_VEND_ID0x100
> +#define PCIE_CONF_DEVICE_ID  0x102
>  #define PCIE_CONF_CLASS_ID   0x106
>  
>  #define PCIE_INT_MASK0x420
> @@ -135,12 +136,14 @@ struct mtk_pcie_port;
>  /**
>   * struct mtk_pcie_soc - differentiate between host generations
>   * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> + * @need_fix_device_id: whether this host's device ID needed to be fixed or 
> not
>   * @ops: pointer to configuration access functions
>   * @startup: pointer to controller setting functions
>   * @setup_irq: pointer to initialize IRQ functions
>   */
>  struct mtk_pcie_soc {
>   bool need_fix_class_id;
> + bool need_fix_device_id;
>   struct pci_ops *ops;
>   int (*startup)(struct mtk_pcie_port *port);
>   int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
> *port)
>   writew(val, port->base + PCIE_CONF_CLASS_ID);
>   }
>  
> + if (soc->need_fix_device_id) {
> + val = PCI_DEVICE_ID_MEDIATEK_7629;
> + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> + }
> +
>   /* 100ms timeout value should be enough for Gen1/2 training */
>   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
>!!(val & PCIE_PORT_LINKUP_V2), 20,
> @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 
> = {
>   .setup_irq = mtk_pcie_setup_irq,
>  };
>  
> +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> + .need_fix_class_id = true,
> + .need_fix_device_id = true,
> + .ops = _pcie_ops_v2,
> + .startup = mtk_pcie_startup_port_v2,
> + .setup_irq = mtk_pcie_setup_irq,
> +};
> +
> +static void mtk_fixup_bar_size(struct pci_dev *dev)
> +{
> + struct resource *dev_res = >resource[0];
> + /* 32bit resource length will calculate size to 0, set it smaller */
> + dev_res->end = 0xfffe;
> +}

I'm not sure assign the BAR0 size in driver to fit in the bogus
alignment is a good idea. Seems the size value of 0x_fffe also is an
arbitrary value.
Do we have a chance to change the resource framework code to make it
adopt this scenario?

Thanks.

> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK, PCI_DEVICE_ID_MEDIATEK_7629,
> +  mtk_fixup_bar_size);
> +
>  static const struct of_device_id mtk_pcie_ids[] = {
>   { .compatible = "mediatek,mt2701-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt7623-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt2712-pcie", .data = _pcie_soc_mt2712 },
>   { .compatible = "mediatek,mt7622-pcie", .data = _pcie_soc_mt7622 },
> + { .compatible = "mediatek,mt7629-pcie", .data = _pcie_soc_mt7629 },
>   {},
>  };
>  
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 69f0abe1ba1a..77b278bac3a8 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2126,6 +2126,7 @@
>  #define PCI_VENDOR_ID_MYRICOM0x14c1
>  
>  #define PCI_VENDOR_ID_MEDIATEK   0x14c3
> +#define PCI_DEVICE_ID_MEDIATEK_7629  0x7629
>  
>  #define PCI_VENDOR_ID_TITAN  0x14D2
>  #define PCI_DEVICE_ID_TITAN_010L 0x8001

Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629

[Honghui Zhang]

On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> 
> The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> in arm64 but bogus alignment values at arm32, the pcie device and devices

:s /the pcie device /the bridge device

> behind this bridge will not be enabled. Fix it's BAR0 resource size to
> guarantee the pcie devices will be enabled correctly.
> 
> The HW default value of its device id is invalid, fix it's device id to
> match the hardware implementation.
> 
> Signed-off-by: Jianjun Wang 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 26 ++
>  include/linux/pci_ids.h|  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index d20cf461ba00..f8937cc3c87c 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -73,6 +73,7 @@
>  #define PCIE_MSI_VECTOR  0x0c0
>  
>  #define PCIE_CONF_VEND_ID0x100
> +#define PCIE_CONF_DEVICE_ID  0x102
>  #define PCIE_CONF_CLASS_ID   0x106
>  
>  #define PCIE_INT_MASK0x420
> @@ -135,12 +136,14 @@ struct mtk_pcie_port;
>  /**
>   * struct mtk_pcie_soc - differentiate between host generations
>   * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> + * @need_fix_device_id: whether this host's device ID needed to be fixed or 
> not
>   * @ops: pointer to configuration access functions
>   * @startup: pointer to controller setting functions
>   * @setup_irq: pointer to initialize IRQ functions
>   */
>  struct mtk_pcie_soc {
>   bool need_fix_class_id;
> + bool need_fix_device_id;
>   struct pci_ops *ops;
>   int (*startup)(struct mtk_pcie_port *port);
>   int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
> *port)
>   writew(val, port->base + PCIE_CONF_CLASS_ID);
>   }
>  
> + if (soc->need_fix_device_id) {
> + val = PCI_DEVICE_ID_MEDIATEK_7629;
> + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> + }
> +
>   /* 100ms timeout value should be enough for Gen1/2 training */
>   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
>!!(val & PCIE_PORT_LINKUP_V2), 20,
> @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 
> = {
>   .setup_irq = mtk_pcie_setup_irq,
>  };
>  
> +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> + .need_fix_class_id = true,
> + .need_fix_device_id = true,
> + .ops = _pcie_ops_v2,
> + .startup = mtk_pcie_startup_port_v2,
> + .setup_irq = mtk_pcie_setup_irq,
> +};
> +
> +static void mtk_fixup_bar_size(struct pci_dev *dev)
> +{
> + struct resource *dev_res = >resource[0];
> + /* 32bit resource length will calculate size to 0, set it smaller */
> + dev_res->end = 0xfffe;
> +}

I'm not sure assign the BAR0 size in driver to fit in the bogus
alignment is a good idea. Seems the size value of 0x_fffe also is an
arbitrary value.
Do we have a chance to change the resource framework code to make it
adopt this scenario?

Thanks.

> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK, PCI_DEVICE_ID_MEDIATEK_7629,
> +  mtk_fixup_bar_size);
> +
>  static const struct of_device_id mtk_pcie_ids[] = {
>   { .compatible = "mediatek,mt2701-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt7623-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt2712-pcie", .data = _pcie_soc_mt2712 },
>   { .compatible = "mediatek,mt7622-pcie", .data = _pcie_soc_mt7622 },
> + { .compatible = "mediatek,mt7629-pcie", .data = _pcie_soc_mt7629 },
>   {},
>  };
>  
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 69f0abe1ba1a..77b278bac3a8 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2126,6 +2126,7 @@
>  #define PCI_VENDOR_ID_MYRICOM0x14c1
>  
>  #define PCI_VENDOR_ID_MEDIATEK   0x14c3
> +#define PCI_DEVICE_ID_MEDIATEK_7629  0x7629
>  
>  #define PCI_VENDOR_ID_TITAN  0x14D2
>  #define PCI_DEVICE_ID_TITAN_010L 0x8001

Re: [PATCH v2] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[Honghui Zhang]

On Thu, 2018-11-29 at 11:33 +, Lorenzo Pieralisi wrote:
> On Thu, Nov 08, 2018 at 10:56:55AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 98 
> > +-
> >  1 file changed, 24 insertions(+), 74 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 2a1f97c..0590a93 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -197,11 +197,7 @@ struct mtk_pcie_port {
> >   * @dev: pointer to PCIe device
> >   * @base: IO mapped register base
> >   * @free_ck: free-run reference clock
> > - * @io: IO resource
> > - * @pio: PIO resource
> >   * @mem: non-prefetchable memory resource
> > - * @busn: bus range
> > - * @offset: IO / Memory offset
> >   * @ports: pointer to PCIe port information
> >   * @soc: pointer to SoC-dependent operations
> >   */
> > @@ -210,14 +206,7 @@ struct mtk_pcie {
> > void __iomem *base;
> > struct clk *free_ck;
> >  
> > -   struct resource io;
> > -   struct resource pio;
> > struct resource mem;
> > -   struct resource busn;
> > -   struct {
> > -   resource_size_t mem;
> > -   resource_size_t io;
> > -   } offset;
> > struct list_head ports;
> > const struct mtk_pcie_soc *soc;
> >  };
> > @@ -1045,55 +1034,43 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
> >  {
> > struct device *dev = pcie->dev;
> > struct device_node *node = dev->of_node, *child;
> > -   struct of_pci_range_parser parser;
> > -   struct of_pci_range range;
> > -   struct resource res;
> > struct mtk_pcie_port *port, *tmp;
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +   struct list_head *windows = >windows;
> > +   struct resource_entry *win, *tmp_win;
> > +   resource_size_t io_base;
> > int err;
> >  
> > -   if (of_pci_range_parser_init(, node)) {
> > -   dev_err(dev, "missing \"ranges\" property\n");
> > -   return -EINVAL;
> > -   }
> > +   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> > +   windows, _base);
> > +   if (err)
> > +   return err;
> >  
> > -   for_each_of_pci_range(, ) {
> > -   err = of_pci_range_to_resource(, node, );
> > -   if (err < 0)
> > -   return err;
> > +   err = devm_request_pci_bus_resources(dev, windows);
> > +   if (err < 0)
> > +   return err;
> >  
> > -   switch (res.flags & IORESOURCE_TYPE_BITS) {
> > +   /* Get the I/O and memory ranges from DT */
> > +   resource_list_for_each_entry_safe(win, tmp_win, windows) {
> > +   switch (resource_type(win->res)) {
> > case IORESOURCE_IO:
> > -   pcie->offset.io = res.start - range.pci_addr;
> > -
> > -   memcpy(>pio, , sizeof(res));
> > -   pcie->pio.name = node->full_name;
> > -
> > -   pcie->io.start = range.cpu_addr;
> > -   pcie->io.end = range.cpu_addr + range.size - 1;
> > -   pcie->io.flags = IORESOURCE_MEM;
> > -   pcie->io.name = "I/O";
> > -
> > -   memcpy(, >io, sizeof(res));
> > +   err = devm_pci_remap_iospace(dev, win->res, io_base);
> > +   if (err) {
> > +   dev_warn(dev, "error %d: failed to map resource 
> > %pR\n",
> > +err, win->res);
> > +   resource_list_destroy_entry(win);
> > +   }
> > break;
> > -
> > case IORESOURCE_MEM:
> > -   pcie->offset.mem = res.start - range.pci_addr;
> > -
> > -   memcpy(>mem, , sizeof(res));
> > +   memcpy(>mem, win->res, sizeof(*win->res));
> > pcie->mem.name = "non-prefetchable";
> > break;
> > +   case IORESOURCE_BUS:

Re: [PATCH v2] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[Honghui Zhang]

On Thu, 2018-11-29 at 11:33 +, Lorenzo Pieralisi wrote:
> On Thu, Nov 08, 2018 at 10:56:55AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 98 
> > +-
> >  1 file changed, 24 insertions(+), 74 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 2a1f97c..0590a93 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -197,11 +197,7 @@ struct mtk_pcie_port {
> >   * @dev: pointer to PCIe device
> >   * @base: IO mapped register base
> >   * @free_ck: free-run reference clock
> > - * @io: IO resource
> > - * @pio: PIO resource
> >   * @mem: non-prefetchable memory resource
> > - * @busn: bus range
> > - * @offset: IO / Memory offset
> >   * @ports: pointer to PCIe port information
> >   * @soc: pointer to SoC-dependent operations
> >   */
> > @@ -210,14 +206,7 @@ struct mtk_pcie {
> > void __iomem *base;
> > struct clk *free_ck;
> >  
> > -   struct resource io;
> > -   struct resource pio;
> > struct resource mem;
> > -   struct resource busn;
> > -   struct {
> > -   resource_size_t mem;
> > -   resource_size_t io;
> > -   } offset;
> > struct list_head ports;
> > const struct mtk_pcie_soc *soc;
> >  };
> > @@ -1045,55 +1034,43 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
> >  {
> > struct device *dev = pcie->dev;
> > struct device_node *node = dev->of_node, *child;
> > -   struct of_pci_range_parser parser;
> > -   struct of_pci_range range;
> > -   struct resource res;
> > struct mtk_pcie_port *port, *tmp;
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +   struct list_head *windows = >windows;
> > +   struct resource_entry *win, *tmp_win;
> > +   resource_size_t io_base;
> > int err;
> >  
> > -   if (of_pci_range_parser_init(, node)) {
> > -   dev_err(dev, "missing \"ranges\" property\n");
> > -   return -EINVAL;
> > -   }
> > +   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> > +   windows, _base);
> > +   if (err)
> > +   return err;
> >  
> > -   for_each_of_pci_range(, ) {
> > -   err = of_pci_range_to_resource(, node, );
> > -   if (err < 0)
> > -   return err;
> > +   err = devm_request_pci_bus_resources(dev, windows);
> > +   if (err < 0)
> > +   return err;
> >  
> > -   switch (res.flags & IORESOURCE_TYPE_BITS) {
> > +   /* Get the I/O and memory ranges from DT */
> > +   resource_list_for_each_entry_safe(win, tmp_win, windows) {
> > +   switch (resource_type(win->res)) {
> > case IORESOURCE_IO:
> > -   pcie->offset.io = res.start - range.pci_addr;
> > -
> > -   memcpy(>pio, , sizeof(res));
> > -   pcie->pio.name = node->full_name;
> > -
> > -   pcie->io.start = range.cpu_addr;
> > -   pcie->io.end = range.cpu_addr + range.size - 1;
> > -   pcie->io.flags = IORESOURCE_MEM;
> > -   pcie->io.name = "I/O";
> > -
> > -   memcpy(, >io, sizeof(res));
> > +   err = devm_pci_remap_iospace(dev, win->res, io_base);
> > +   if (err) {
> > +   dev_warn(dev, "error %d: failed to map resource 
> > %pR\n",
> > +err, win->res);
> > +   resource_list_destroy_entry(win);
> > +   }
> > break;
> > -
> > case IORESOURCE_MEM:
> > -   pcie->offset.mem = res.start - range.pci_addr;
> > -
> > -   memcpy(>mem, , sizeof(res));
> > +   memcpy(>mem, win->res, sizeof(*win->res));
> > pcie->mem.name = "non-prefetchable";
> > break;
> > +   case IORESOURCE_BUS:

Re: [PATCH] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[Honghui Zhang]

On Wed, 2018-11-07 at 12:03 +, Lorenzo Pieralisi wrote:
> On Thu, Oct 18, 2018 at 11:23:34AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 109 
> > +
> >  1 file changed, 29 insertions(+), 80 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 2a1f97c..6632d4e 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -197,29 +197,20 @@ struct mtk_pcie_port {
> >   * @dev: pointer to PCIe device
> >   * @base: IO mapped register base
> >   * @free_ck: free-run reference clock
> > - * @io: IO resource
> > - * @pio: PIO resource
> >   * @mem: non-prefetchable memory resource
> > - * @busn: bus range
> > - * @offset: IO / Memory offset
> >   * @ports: pointer to PCIe port information
> >   * @soc: pointer to SoC-dependent operations
> > + * @busnr: root bus number
> >   */
> >  struct mtk_pcie {
> > struct device *dev;
> > void __iomem *base;
> > struct clk *free_ck;
> >  
> > -   struct resource io;
> > -   struct resource pio;
> > struct resource mem;
> > -   struct resource busn;
> > -   struct {
> > -   resource_size_t mem;
> > -   resource_size_t io;
> > -   } offset;
> > struct list_head ports;
> > const struct mtk_pcie_soc *soc;
> > +   int busnr;
> 
> If you move the code initializing and probing the pci_host_bridge into
> mtk_pcie_setup() (and rename that function) this variable becomes
> useless. It should be an unsigned int, by the way.

Yes, I can directly assign the busnr to host->busnr in the
mtk_pcie_setup and remove this variable.

Thanks.

> 
> >  };
> >  
> >  static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
> > @@ -1045,55 +1036,42 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
> >  {
> > struct device *dev = pcie->dev;
> > struct device_node *node = dev->of_node, *child;
> > -   struct of_pci_range_parser parser;
> > -   struct of_pci_range range;
> > -   struct resource res;
> > struct mtk_pcie_port *port, *tmp;
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +   struct list_head *windows = >windows;
> > +   struct resource_entry *win, *tmp_win;
> > +   resource_size_t io_base;
> > int err;
> >  
> > -   if (of_pci_range_parser_init(, node)) {
> > -   dev_err(dev, "missing \"ranges\" property\n");
> > -   return -EINVAL;
> > -   }
> > +   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> > +   windows, _base);
> > +   if (err)
> > +   return err;
> >  
> > -   for_each_of_pci_range(, ) {
> > -   err = of_pci_range_to_resource(, node, );
> > -   if (err < 0)
> > -   return err;
> > +   err = devm_request_pci_bus_resources(dev, windows);
> > +   if (err < 0)
> > +   return err;
> >  
> > -   switch (res.flags & IORESOURCE_TYPE_BITS) {
> > +   /* Get the I/O and memory ranges from DT */
> > +   resource_list_for_each_entry_safe(win, tmp_win, windows) {
> > +   switch (resource_type(win->res)) {
> > case IORESOURCE_IO:
> > -   pcie->offset.io = res.start - range.pci_addr;
> > -
> > -   memcpy(>pio, , sizeof(res));
> > -   pcie->pio.name = node->full_name;
> > -
> > -   pcie->io.start = range.cpu_addr;
> > -   pcie->io.end = range.cpu_addr + range.size - 1;
> > -   pcie->io.flags = IORESOURCE_MEM;
> > -   pcie->io.name = "I/O";
> > -
> > -   memcpy(, >io, sizeof(res));
> > -   break;
> > -
> > +   err = devm_pci_remap_iospace(dev, win->res, io_base);
> > +   if (err) {
> > +   dev_warn(dev, "error %d: failed to map resource 
> > %pR\n",
> > +err, win->res);
> > +   resource_list_destroy_entry(win);
&

Re: [PATCH] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[Honghui Zhang]

On Wed, 2018-11-07 at 12:03 +, Lorenzo Pieralisi wrote:
> On Thu, Oct 18, 2018 at 11:23:34AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 109 
> > +
> >  1 file changed, 29 insertions(+), 80 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 2a1f97c..6632d4e 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -197,29 +197,20 @@ struct mtk_pcie_port {
> >   * @dev: pointer to PCIe device
> >   * @base: IO mapped register base
> >   * @free_ck: free-run reference clock
> > - * @io: IO resource
> > - * @pio: PIO resource
> >   * @mem: non-prefetchable memory resource
> > - * @busn: bus range
> > - * @offset: IO / Memory offset
> >   * @ports: pointer to PCIe port information
> >   * @soc: pointer to SoC-dependent operations
> > + * @busnr: root bus number
> >   */
> >  struct mtk_pcie {
> > struct device *dev;
> > void __iomem *base;
> > struct clk *free_ck;
> >  
> > -   struct resource io;
> > -   struct resource pio;
> > struct resource mem;
> > -   struct resource busn;
> > -   struct {
> > -   resource_size_t mem;
> > -   resource_size_t io;
> > -   } offset;
> > struct list_head ports;
> > const struct mtk_pcie_soc *soc;
> > +   int busnr;
> 
> If you move the code initializing and probing the pci_host_bridge into
> mtk_pcie_setup() (and rename that function) this variable becomes
> useless. It should be an unsigned int, by the way.

Yes, I can directly assign the busnr to host->busnr in the
mtk_pcie_setup and remove this variable.

Thanks.

> 
> >  };
> >  
> >  static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
> > @@ -1045,55 +1036,42 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
> >  {
> > struct device *dev = pcie->dev;
> > struct device_node *node = dev->of_node, *child;
> > -   struct of_pci_range_parser parser;
> > -   struct of_pci_range range;
> > -   struct resource res;
> > struct mtk_pcie_port *port, *tmp;
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +   struct list_head *windows = >windows;
> > +   struct resource_entry *win, *tmp_win;
> > +   resource_size_t io_base;
> > int err;
> >  
> > -   if (of_pci_range_parser_init(, node)) {
> > -   dev_err(dev, "missing \"ranges\" property\n");
> > -   return -EINVAL;
> > -   }
> > +   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> > +   windows, _base);
> > +   if (err)
> > +   return err;
> >  
> > -   for_each_of_pci_range(, ) {
> > -   err = of_pci_range_to_resource(, node, );
> > -   if (err < 0)
> > -   return err;
> > +   err = devm_request_pci_bus_resources(dev, windows);
> > +   if (err < 0)
> > +   return err;
> >  
> > -   switch (res.flags & IORESOURCE_TYPE_BITS) {
> > +   /* Get the I/O and memory ranges from DT */
> > +   resource_list_for_each_entry_safe(win, tmp_win, windows) {
> > +   switch (resource_type(win->res)) {
> > case IORESOURCE_IO:
> > -   pcie->offset.io = res.start - range.pci_addr;
> > -
> > -   memcpy(>pio, , sizeof(res));
> > -   pcie->pio.name = node->full_name;
> > -
> > -   pcie->io.start = range.cpu_addr;
> > -   pcie->io.end = range.cpu_addr + range.size - 1;
> > -   pcie->io.flags = IORESOURCE_MEM;
> > -   pcie->io.name = "I/O";
> > -
> > -   memcpy(, >io, sizeof(res));
> > -   break;
> > -
> > +   err = devm_pci_remap_iospace(dev, win->res, io_base);
> > +   if (err) {
> > +   dev_warn(dev, "error %d: failed to map resource 
> > %pR\n",
> > +err, win->res);
> > +   resource_list_destroy_entry(win);
&

Re: [PATCH] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[Honghui Zhang]

On Fri, 2018-11-02 at 14:36 +0800, Ryder Lee wrote:
> On Thu, 2018-10-18 at 11:23 +0800, Honghui Zhang (张洪辉) wrote:
> > From: Honghui Zhang 
> > 
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 109 
> > +
> >  1 file changed, 29 insertions(+), 80 deletions(-)
> > 
[..]
> > 
> 
> Acked-by: Ryder Lee 
> 
> 

Hi, Lorenzo, could you help take a look at this patch?

Thanks.

Re: [PATCH] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT

[Honghui Zhang]

On Fri, 2018-11-02 at 14:36 +0800, Ryder Lee wrote:
> On Thu, 2018-10-18 at 11:23 +0800, Honghui Zhang (张洪辉) wrote:
> > From: Honghui Zhang 
> > 
> > Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> > DT parser.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 109 
> > +
> >  1 file changed, 29 insertions(+), 80 deletions(-)
> > 
[..]
> > 
> 
> Acked-by: Ryder Lee 
> 
> 

Hi, Lorenzo, could you help take a look at this patch?

Thanks.

Re: [PATCH v8 0/9] PCI: mediatek: fixup find_port, enable_msi and add PM, module support

[Honghui Zhang]

On Wed, 2018-10-17 at 16:19 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 15, 2018 at 04:08:51PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > This patchset includes misc patchs:
> > 
> > The patch 1 fixup the mtk_pcie_find_port logic which will cause system
> > could not touch the EP's configuration space that connected to PCIe slot 1.
> > 
> > The patch 2 fixup the class type for MT7622.
> > The patch 6 fixup the enable msi logic, the operation to enable MSI
> > should be after system clock is enabled. Call mtk_pcie_enable_msi in
> > mtk_pcie_startup_port_v2 since the clock was all enabled at that time.
> > 
> > The patch 7 was rebased and refactor of the v4 patch[1], changes are:
> >  -Add PM support for MT7622.
> >  -Using mtk_pcie_enable_port to re-establish the link when resumed.
> >  -Rebased on this patchset.
> > 
> > The patch 9 add loadable kernel module support.
> > 
> > [1] https://patchwork.kernel.org/patch/10479079
> 
> I have pushed out (after basically rewriting all commit logs and
> squashing two patches) this version of the patchset to my pci/mediatek
> branch for v4.20, keeping in mind that you must follow-up with Bjorn on
> this patch:

Thanks for your great help with this serial.

> 
> https://patchwork.ozlabs.org/patch/984668/
> 
> that we shall still consider for v4.21.
> 
> Lorenzo
> 
> > Change since v7:
> >  - Add Acked-by tags from Ryder Lee.
> >  - Add Fix tags for patch 2(Fix calss type for MT7622 as 
> > PCI_CLASS_BRIDGE_PCI)
> >and patch 6(Fixup enable MSI logic by enable MSI after clock enabled)
> > 
> > Change since v6:
> >  - Remove the pci_unmap_iospace when remove the device since the
> >devm_pci_remap_iospace is an devm_ version.
> >  - Commit message changed for patch 2(Fix class type for MT7622 as 
> > PCI_CLASS_BRIDGE_PCI).
> >  - Capitilizing "MSI" and "PM" in the patch title.
> > 
> > Change since v5:
> >  - A bit improvement of mtk_pcie_find_port suggest by Lorenzo.
> >MSI after clock enabled).
> >  - Add Acked-by tags from Ryder.
> > 
> > Change since v4:
> >  - Add patch 2 to fixup class type for MT7622.
> >  - Add patch 3 to remove the redundant dev->pm_domain check
> >  - Add patch 4 to covert to use pci_host_probe
> >  - Add patch 5 to re-arrange the function define, this is a prepare patch 
> > for
> >fixup the enable_msi logic, no functional changed have been made by this 
> > one.
> >  - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for 
> > tear
> >down the irq when remove the kernel module.
> >  - Re-arrange the find_port flow suggest by Lorenzo to make the code parse 
> > easier
> >for the patch 1.
> >  - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was 
> > not
> >supported, then those pm callbacks will never be executed for MT7622. So 
> > the
> >.pm_support is not needed.
> > 
> > Change since v3:
> >  - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third 
> > patch.
> >  - Rebase to 4.19-rc1.
> > 
> > Change since v2:
> >  - Fix the list_for_each_entry_safe parameter error.
> >  - Add Ryder's Acked-by flag.
> > 
> > Change since v1:
> >  - A bit of code refact of the first patch suggested by Andy Shevchenko, and
> >commit message updated.
> > 
> > Honghui Zhang (9):
> >   PCI: mediatek: Using slot's devfn for compare to fix
> > mtk_pcie_find_port logic
> >   PCI: mediatek: Fix class type for MT7622 as PCI_CLASS_BRIDGE_PCI
> >   PCI: mediatek: Remove the redundant dev->pm_domain check
> >   PCI: mediatek: Convert to use pci_host_probe()
> >   PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
> > after mtk_pcie_setup_irq
> >   PCI: mediatek: Fixup enable MSI logic by enable MSI after clock
> > enabled
> >   PCI: mediatek: Add system PM support for MT2712 and MT7622
> >   PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
> >   PCI: mediatek: Add loadable kernel module support
> > 
> >  drivers/pci/controller/Kconfig |   2 +-
> >  drivers/pci/controller/pcie-mediatek.c | 319 
> > +
> >  2 files changed, 204 insertions(+), 117 deletions(-)
> > 
> > -- 
> > 2.6.4
> > 

Re: [PATCH v8 0/9] PCI: mediatek: fixup find_port, enable_msi and add PM, module support

[Honghui Zhang]

On Wed, 2018-10-17 at 16:19 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 15, 2018 at 04:08:51PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > This patchset includes misc patchs:
> > 
> > The patch 1 fixup the mtk_pcie_find_port logic which will cause system
> > could not touch the EP's configuration space that connected to PCIe slot 1.
> > 
> > The patch 2 fixup the class type for MT7622.
> > The patch 6 fixup the enable msi logic, the operation to enable MSI
> > should be after system clock is enabled. Call mtk_pcie_enable_msi in
> > mtk_pcie_startup_port_v2 since the clock was all enabled at that time.
> > 
> > The patch 7 was rebased and refactor of the v4 patch[1], changes are:
> >  -Add PM support for MT7622.
> >  -Using mtk_pcie_enable_port to re-establish the link when resumed.
> >  -Rebased on this patchset.
> > 
> > The patch 9 add loadable kernel module support.
> > 
> > [1] https://patchwork.kernel.org/patch/10479079
> 
> I have pushed out (after basically rewriting all commit logs and
> squashing two patches) this version of the patchset to my pci/mediatek
> branch for v4.20, keeping in mind that you must follow-up with Bjorn on
> this patch:

Thanks for your great help with this serial.

> 
> https://patchwork.ozlabs.org/patch/984668/
> 
> that we shall still consider for v4.21.
> 
> Lorenzo
> 
> > Change since v7:
> >  - Add Acked-by tags from Ryder Lee.
> >  - Add Fix tags for patch 2(Fix calss type for MT7622 as 
> > PCI_CLASS_BRIDGE_PCI)
> >and patch 6(Fixup enable MSI logic by enable MSI after clock enabled)
> > 
> > Change since v6:
> >  - Remove the pci_unmap_iospace when remove the device since the
> >devm_pci_remap_iospace is an devm_ version.
> >  - Commit message changed for patch 2(Fix class type for MT7622 as 
> > PCI_CLASS_BRIDGE_PCI).
> >  - Capitilizing "MSI" and "PM" in the patch title.
> > 
> > Change since v5:
> >  - A bit improvement of mtk_pcie_find_port suggest by Lorenzo.
> >MSI after clock enabled).
> >  - Add Acked-by tags from Ryder.
> > 
> > Change since v4:
> >  - Add patch 2 to fixup class type for MT7622.
> >  - Add patch 3 to remove the redundant dev->pm_domain check
> >  - Add patch 4 to covert to use pci_host_probe
> >  - Add patch 5 to re-arrange the function define, this is a prepare patch 
> > for
> >fixup the enable_msi logic, no functional changed have been made by this 
> > one.
> >  - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for 
> > tear
> >down the irq when remove the kernel module.
> >  - Re-arrange the find_port flow suggest by Lorenzo to make the code parse 
> > easier
> >for the patch 1.
> >  - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was 
> > not
> >supported, then those pm callbacks will never be executed for MT7622. So 
> > the
> >.pm_support is not needed.
> > 
> > Change since v3:
> >  - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third 
> > patch.
> >  - Rebase to 4.19-rc1.
> > 
> > Change since v2:
> >  - Fix the list_for_each_entry_safe parameter error.
> >  - Add Ryder's Acked-by flag.
> > 
> > Change since v1:
> >  - A bit of code refact of the first patch suggested by Andy Shevchenko, and
> >commit message updated.
> > 
> > Honghui Zhang (9):
> >   PCI: mediatek: Using slot's devfn for compare to fix
> > mtk_pcie_find_port logic
> >   PCI: mediatek: Fix class type for MT7622 as PCI_CLASS_BRIDGE_PCI
> >   PCI: mediatek: Remove the redundant dev->pm_domain check
> >   PCI: mediatek: Convert to use pci_host_probe()
> >   PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
> > after mtk_pcie_setup_irq
> >   PCI: mediatek: Fixup enable MSI logic by enable MSI after clock
> > enabled
> >   PCI: mediatek: Add system PM support for MT2712 and MT7622
> >   PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
> >   PCI: mediatek: Add loadable kernel module support
> > 
> >  drivers/pci/controller/Kconfig |   2 +-
> >  drivers/pci/controller/pcie-mediatek.c | 319 
> > +
> >  2 files changed, 204 insertions(+), 117 deletions(-)
> > 
> > -- 
> > 2.6.4
> > 

Re: [PATCH v9 2/9] PCI: Using PCI configuration space header type instead of class type to assign resource

[Honghui Zhang]

On Wed, 2018-10-17 at 08:22 -0500, Bjorn Helgaas wrote:
> On Tue, Oct 16, 2018 at 03:53:55PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Oct 16, 2018 at 06:44:43PM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > The PCI configuration space header type defines the layout of the rest
> > > of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9) while the
> > > resource assignment is based on the configuration space layout instead
> > > of its class type. Using configuration space header type instead of
> > > class type for the resource assignment.
> > > 
> > > Suggested-by: Bjorn Helgaas 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/pci.c   |  3 +--
> > >  drivers/pci/probe.c |  3 ---
> > >  drivers/pci/setup-bus.c | 20 ++--
> > >  3 files changed, 11 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 29ff961..7d379ca 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -5908,8 +5908,7 @@ void pci_reassigndev_resource_alignment(struct 
> > > pci_dev *dev)
> > >* to enable the kernel to reassign new resource
> > >* window later on.
> > >*/
> > > - if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
> > > - (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
> > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > >   for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++) {
> > >   r = >resource[i];
> > >   if (!(r->flags & IORESOURCE_MEM))
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index ec78400..29a35c1 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -1695,9 +1695,6 @@ int pci_setup_device(struct pci_dev *dev)
> > >   break;
> > >  
> > >   case PCI_HEADER_TYPE_BRIDGE:/* bridge header */
> > > - if (class != PCI_CLASS_BRIDGE_PCI)
> > > - goto bad;
> > > -
> > >   /*
> > >* The PCI-to-PCI bridge spec requires that subtractive
> > >* decoding (i.e. transparent) bridge must have programming
> > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > > index 79b1824..69f90f4 100644
> > > --- a/drivers/pci/setup-bus.c
> > > +++ b/drivers/pci/setup-bus.c
> > > @@ -182,7 +182,7 @@ static void __dev_sort_resources(struct pci_dev *dev,
> > >   u16 class = dev->class >> 8;
> > >  
> > >   /* Don't touch classless devices or host bridges or ioapics.  */
> > > - if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST)
> > > + if (class == PCI_CLASS_NOT_DEFINED)
> > 
> > I think this check has been there since the first initial git commit,
> > whether that's _really_ needed or not in the current kernel it is very
> > hard to say.
> > 
> > I am not that sure it is safe to remove it, especially given that we are at
> > -rc8 and close to a release, it would be good if this patch could sit in
> > next to give it some exposure to testing before merging it upstream.
> 

I'm not sure why the first version has take care of
PCI_CLASS_BRIDGE_HOST separately, I have no idea whether there's some
host bridge device that has their resource fixed.

I agree that this patch should be hold for the moment since I have it
tested only in Mediatek's platform.

Thanks

> Yes, you're right; I think I think this is a little too risky at this
> point.  I'll pull this patch out and queue it up for the next cycle
> (v4.21).

Thanks, I will follow up this patch.

> 
> For v4.20, I think you should resurrect the class code patch [1].  That
> should be enough to make things work in v4.20, even without this hdr_type
> patch.  It will also improve the lspci output, because I think it uses the
> class code to look up the generic description, e.g., in this output:
> 
>   00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root 
> Port (rev f1)
> 
> I think the "PCI bridge" part is based on the class code.
> 
> Bjorn
> 
> [1] 
> https://lore.kernel.org/linux-pci/1539590940-13355-3-git-send-email-honghui.zh...@mediatek.com
> 
> > >   return;
> > >  
> > >   /* Don't touch ioapic devices already enabled by firmware */
> > > @@ -1221,12 +1221,12 @@ void __pci_bus_size_bridges(str

Re: [PATCH v9 2/9] PCI: Using PCI configuration space header type instead of class type to assign resource

[Honghui Zhang]

On Wed, 2018-10-17 at 08:22 -0500, Bjorn Helgaas wrote:
> On Tue, Oct 16, 2018 at 03:53:55PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Oct 16, 2018 at 06:44:43PM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > The PCI configuration space header type defines the layout of the rest
> > > of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9) while the
> > > resource assignment is based on the configuration space layout instead
> > > of its class type. Using configuration space header type instead of
> > > class type for the resource assignment.
> > > 
> > > Suggested-by: Bjorn Helgaas 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/pci.c   |  3 +--
> > >  drivers/pci/probe.c |  3 ---
> > >  drivers/pci/setup-bus.c | 20 ++--
> > >  3 files changed, 11 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 29ff961..7d379ca 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -5908,8 +5908,7 @@ void pci_reassigndev_resource_alignment(struct 
> > > pci_dev *dev)
> > >* to enable the kernel to reassign new resource
> > >* window later on.
> > >*/
> > > - if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
> > > - (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
> > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > >   for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++) {
> > >   r = >resource[i];
> > >   if (!(r->flags & IORESOURCE_MEM))
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index ec78400..29a35c1 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -1695,9 +1695,6 @@ int pci_setup_device(struct pci_dev *dev)
> > >   break;
> > >  
> > >   case PCI_HEADER_TYPE_BRIDGE:/* bridge header */
> > > - if (class != PCI_CLASS_BRIDGE_PCI)
> > > - goto bad;
> > > -
> > >   /*
> > >* The PCI-to-PCI bridge spec requires that subtractive
> > >* decoding (i.e. transparent) bridge must have programming
> > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> > > index 79b1824..69f90f4 100644
> > > --- a/drivers/pci/setup-bus.c
> > > +++ b/drivers/pci/setup-bus.c
> > > @@ -182,7 +182,7 @@ static void __dev_sort_resources(struct pci_dev *dev,
> > >   u16 class = dev->class >> 8;
> > >  
> > >   /* Don't touch classless devices or host bridges or ioapics.  */
> > > - if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST)
> > > + if (class == PCI_CLASS_NOT_DEFINED)
> > 
> > I think this check has been there since the first initial git commit,
> > whether that's _really_ needed or not in the current kernel it is very
> > hard to say.
> > 
> > I am not that sure it is safe to remove it, especially given that we are at
> > -rc8 and close to a release, it would be good if this patch could sit in
> > next to give it some exposure to testing before merging it upstream.
> 

I'm not sure why the first version has take care of
PCI_CLASS_BRIDGE_HOST separately, I have no idea whether there's some
host bridge device that has their resource fixed.

I agree that this patch should be hold for the moment since I have it
tested only in Mediatek's platform.

Thanks

> Yes, you're right; I think I think this is a little too risky at this
> point.  I'll pull this patch out and queue it up for the next cycle
> (v4.21).

Thanks, I will follow up this patch.

> 
> For v4.20, I think you should resurrect the class code patch [1].  That
> should be enough to make things work in v4.20, even without this hdr_type
> patch.  It will also improve the lspci output, because I think it uses the
> class code to look up the generic description, e.g., in this output:
> 
>   00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root 
> Port (rev f1)
> 
> I think the "PCI bridge" part is based on the class code.
> 
> Bjorn
> 
> [1] 
> https://lore.kernel.org/linux-pci/1539590940-13355-3-git-send-email-honghui.zh...@mediatek.com
> 
> > >   return;
> > >  
> > >   /* Don't touch ioapic devices already enabled by firmware */
> > > @@ -1221,12 +1221,12 @@ void __pci_bus_size_bridges(str

Re: [PATCH v7 0/9] PCI: mediatek: fixup find_port, enable_msi and add PM, module support

[Honghui Zhang]

On Mon, 2018-10-15 at 14:05 +0800, Ryder Lee wrote:
> On Mon, 2018-10-15 at 13:44 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > This patchset includes misc patchs:
> > 
> > The patch 1 fixup the mtk_pcie_find_port logic which will cause system
> > could not touch the EP's configuration space that connected to PCIe slot 1.
> > 
> > The patch 2 fixup the class type for MT7622.
> > The patch 6 fixup the enable msi logic, the operation to enable MSI
> > should be after system clock is enabled. Call mtk_pcie_enable_msi in
> > mtk_pcie_startup_port_v2 since the clock was all enabled at that time.
> > 
> > The patch 7 was rebased and refactor of the v4 patch[1], changes are:
> >  -Add PM support for MT7622.
> >  -Using mtk_pcie_enable_port to re-establish the link when resumed.
> >  -Rebased on this patchset.
> > 
> > The patch 9 add loadable kernel module support.
> > 
> > [1] https://patchwork.kernel.org/patch/10479079
> > 
> > Change since v6:
> >  - Remove the pci_unmap_iospace when remove the device since the
> >devm_pci_remap_iospace is an devm_ version.
> >  - Commit message changed for patch 2(Fix class type for MT7622 as 
> > PCI_CLASS_BRIDGE_PCI).
> >  - Capitilizing "MSI" and "PM" in the patch title.
> > 
> > Change since v5:
> >  - A bit improvement of mtk_pcie_find_port suggest by Lorenzo.
> >  - Add fixup tags of fix enable MSI logic in patch 6.
> >  - Add Acked-by tags from Ryder.
> > 
> > Change since v4:
> >  - Add patch 2 to fixup class type for MT7622.
> >  - Add patch 3 to remove the redundant dev->pm_domain check
> >  - Add patch 4 to covert to use pci_host_probe
> >  - Add patch 5 to re-arrange the function define, this is a prepare patch 
> > for
> >fixup the enable_msi logic, no functional changed have been made by this 
> > one.
> >  - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for 
> > tear
> >down the irq when remove the kernel module.
> >  - Re-arrange the find_port flow suggest by Lorenzo to make the code parse 
> > easier
> >for the patch 1.
> >  - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was 
> > not
> >supported, then those pm callbacks will never be executed for MT7622. So 
> > the
> >.pm_support is not needed.
> > 
> > Change since v3:
> >  - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third 
> > patch.
> >  - Rebase to 4.19-rc1.
> > 
> > Change since v2:
> >  - Fix the list_for_each_entry_safe parameter error.
> >  - Add Ryder's Acked-by flag.
> > 
> > Change since v1:
> >  - A bit of code refact of the first patch suggested by Andy Shevchenko, and
> >commit message updated.
> > 
> > Honghui Zhang (9):
> >   PCI: mediatek: Using slot's devfn for compare to fix
> > mtk_pcie_find_port logic
> >   PCI: mediatek: Fix class type for MT7622 as PCI_CLASS_BRIDGE_PCI
> >   PCI: mediatek: Remove the redundant dev->pm_domain check
> >   PCI: mediatek: Convert to use pci_host_probe()
> >   PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
> > after mtk_pcie_setup_irq
> >   PCI: mediatek: Fixup enable MSI logic by enable MSI after clock
> > enabled
> >   PCI: mediatek: Add system PM support for MT2712 and MT7622
> >   PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
> >   PCI: mediatek: Add loadable kernel module support
> > 
> >  drivers/pci/controller/Kconfig |   2 +-
> >  drivers/pci/controller/pcie-mediatek.c | 319 
> > +
> >  2 files changed, 204 insertions(+), 117 deletions(-)
> 
> 
> You forgot to add my Acked-by tags in v7.
> 
> Acked-by: Ryder Lee  for the series.

Sorry about that,

Lorenzo, do I need to re-send this series with Ryder's Acked-by tags?

Thanks.
> 
> Thanks.
> 

Re: [PATCH v7 0/9] PCI: mediatek: fixup find_port, enable_msi and add PM, module support

[Honghui Zhang]

On Mon, 2018-10-15 at 14:05 +0800, Ryder Lee wrote:
> On Mon, 2018-10-15 at 13:44 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > This patchset includes misc patchs:
> > 
> > The patch 1 fixup the mtk_pcie_find_port logic which will cause system
> > could not touch the EP's configuration space that connected to PCIe slot 1.
> > 
> > The patch 2 fixup the class type for MT7622.
> > The patch 6 fixup the enable msi logic, the operation to enable MSI
> > should be after system clock is enabled. Call mtk_pcie_enable_msi in
> > mtk_pcie_startup_port_v2 since the clock was all enabled at that time.
> > 
> > The patch 7 was rebased and refactor of the v4 patch[1], changes are:
> >  -Add PM support for MT7622.
> >  -Using mtk_pcie_enable_port to re-establish the link when resumed.
> >  -Rebased on this patchset.
> > 
> > The patch 9 add loadable kernel module support.
> > 
> > [1] https://patchwork.kernel.org/patch/10479079
> > 
> > Change since v6:
> >  - Remove the pci_unmap_iospace when remove the device since the
> >devm_pci_remap_iospace is an devm_ version.
> >  - Commit message changed for patch 2(Fix class type for MT7622 as 
> > PCI_CLASS_BRIDGE_PCI).
> >  - Capitilizing "MSI" and "PM" in the patch title.
> > 
> > Change since v5:
> >  - A bit improvement of mtk_pcie_find_port suggest by Lorenzo.
> >  - Add fixup tags of fix enable MSI logic in patch 6.
> >  - Add Acked-by tags from Ryder.
> > 
> > Change since v4:
> >  - Add patch 2 to fixup class type for MT7622.
> >  - Add patch 3 to remove the redundant dev->pm_domain check
> >  - Add patch 4 to covert to use pci_host_probe
> >  - Add patch 5 to re-arrange the function define, this is a prepare patch 
> > for
> >fixup the enable_msi logic, no functional changed have been made by this 
> > one.
> >  - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for 
> > tear
> >down the irq when remove the kernel module.
> >  - Re-arrange the find_port flow suggest by Lorenzo to make the code parse 
> > easier
> >for the patch 1.
> >  - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was 
> > not
> >supported, then those pm callbacks will never be executed for MT7622. So 
> > the
> >.pm_support is not needed.
> > 
> > Change since v3:
> >  - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third 
> > patch.
> >  - Rebase to 4.19-rc1.
> > 
> > Change since v2:
> >  - Fix the list_for_each_entry_safe parameter error.
> >  - Add Ryder's Acked-by flag.
> > 
> > Change since v1:
> >  - A bit of code refact of the first patch suggested by Andy Shevchenko, and
> >commit message updated.
> > 
> > Honghui Zhang (9):
> >   PCI: mediatek: Using slot's devfn for compare to fix
> > mtk_pcie_find_port logic
> >   PCI: mediatek: Fix class type for MT7622 as PCI_CLASS_BRIDGE_PCI
> >   PCI: mediatek: Remove the redundant dev->pm_domain check
> >   PCI: mediatek: Convert to use pci_host_probe()
> >   PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
> > after mtk_pcie_setup_irq
> >   PCI: mediatek: Fixup enable MSI logic by enable MSI after clock
> > enabled
> >   PCI: mediatek: Add system PM support for MT2712 and MT7622
> >   PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
> >   PCI: mediatek: Add loadable kernel module support
> > 
> >  drivers/pci/controller/Kconfig |   2 +-
> >  drivers/pci/controller/pcie-mediatek.c | 319 
> > +
> >  2 files changed, 204 insertions(+), 117 deletions(-)
> 
> 
> You forgot to add my Acked-by tags in v7.
> 
> Acked-by: Ryder Lee  for the series.

Sorry about that,

Lorenzo, do I need to re-send this series with Ryder's Acked-by tags?

Thanks.
> 
> Thanks.
> 

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Fri, 2018-10-12 at 09:12 -0500, Bjorn Helgaas wrote:
> On Fri, Oct 12, 2018 at 11:22:30AM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Oct 12, 2018 at 04:01:29PM +0800, Honghui Zhang wrote:
> >> On Thu, 2018-10-11 at 12:38 +0100, Lorenzo Pieralisi wrote:
> >>> On Tue, Oct 09, 2018 at 11:08:15AM +0800, Honghui Zhang wrote:
> >>>> On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> >>>>> On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com 
> >>>>> wrote:
> >>>>>> From: Honghui Zhang 
> >>>>>> 
> >>>>>> The PCIe controller of MT7622 has TYPE 1 configuration
> >>>>>> space type, but the HW default class type values is
> >>>>>> invalid.
> >>>>>> 
> >>>>>> The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID
> >>>>>> and class type for MT7622") have set the class ID for
> >>>>>> MT7622 as PCI_CLASS_BRIDGE_HOSTe, but it's not workable
> >>>>>> for MT7622:
> >>>>>> 
> >>>>>> In __pci_bus_assign_resources, the framework only setup
> >>>>>> bridge's resource window only if class type is
> >>>>>> PCI_CLASS_BRIDGE_PCI. Or it will leave the subordinary PCIe
> >>>>>> device's MMIO window un-touched.
> 
> I think __pci_bus_assign_resources() should be testing dev->hdr_type
> instead of dev->class.  The connection between "Header Type" and the
> layout of the rest of the header is very explicit (PCI r3.0 sec 6.1,
> PCIe r4.0 sec 7.5.1.1.9), and the reason for the switch statement in
> __pci_bus_assign_resources() is precisely to determine which layout to
> use.
> 
> There are several other uses of dev->class in setup-bus.c that I think
> should also be changed to use dev->hdr_type.
> 
> If we make these changes in setup-bus.c, I suspect the class code you
> assign won't matter too much.  There are a few other tests of the
> class code to figure out whether to leave certain things untouched.
> These seem a little hacky to me, but we're probably stuck with them
> for now, so you should look and see whether they apply to your
> situation.

If these change could be made in the PCI core, then the class code is no
matter what will be workable for MT7622.

As Lorenzo point it out, it's more reasonable for MT7622 to defined as a
PCI-to-PCI class code since the IP is defined as that. I intend to
following Lorenzo's suggest to update the commit message and re-send
this patch set for current solution.

> 
> >>>> And for MT7622, it integrated with block of internal control
> >>>> registers, type 1 configuration space, and is considered as a
> >>>> root complex.
> >>> 
> >>> I assume you mean a type 1 config header here. I do not think it
> >>> is mandatory for a host bridge to have a type 1 config header (and
> >>> related bridge windows + primary/secondary/subordinate bus
> >>> numbers) but I do not know how the IP you are programming is
> >>> designed.
> 
> It is definitely not mandatory for a host bridge to have a type 1
> header.  I'm not even sure that would make sense: the "Primary Bus
> Number" would not apply to a host bridge (since a host bridge's
> primary bus is some sort of CPU bus, not a PCI bus), and a type 1
> device cannot perform address translation between its primary and
> secondary buses, while a host bridge can.
> 
> A Root Port is a type 1 device where the primary bus is logically
> internal to the Root Complex.  A host bridge bridges from the CPU bus
> to that internal bus and might perform address translation.  The Root
> Port must be a PCI device.  A host bridge, being a bridge *to* the PCI
> domain, is not itself generally programmed via PCI config space and
> might not even be visible as a device in PCI config space.
> 
Thanks for the explain. Per my understanding, MT7622 is more like a
complex of Root Port and PCI-to-PCI bridge. It has type 1 header and has
the ability to translate address between its primary and secondary
buses. I guess apply the class type as PCI_CLASS_BRIDGE_PCI is
reasonable way to make its integrated internal bridge workable.

Thanks.
> Bjorn

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Fri, 2018-10-12 at 09:12 -0500, Bjorn Helgaas wrote:
> On Fri, Oct 12, 2018 at 11:22:30AM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Oct 12, 2018 at 04:01:29PM +0800, Honghui Zhang wrote:
> >> On Thu, 2018-10-11 at 12:38 +0100, Lorenzo Pieralisi wrote:
> >>> On Tue, Oct 09, 2018 at 11:08:15AM +0800, Honghui Zhang wrote:
> >>>> On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> >>>>> On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com 
> >>>>> wrote:
> >>>>>> From: Honghui Zhang 
> >>>>>> 
> >>>>>> The PCIe controller of MT7622 has TYPE 1 configuration
> >>>>>> space type, but the HW default class type values is
> >>>>>> invalid.
> >>>>>> 
> >>>>>> The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID
> >>>>>> and class type for MT7622") have set the class ID for
> >>>>>> MT7622 as PCI_CLASS_BRIDGE_HOSTe, but it's not workable
> >>>>>> for MT7622:
> >>>>>> 
> >>>>>> In __pci_bus_assign_resources, the framework only setup
> >>>>>> bridge's resource window only if class type is
> >>>>>> PCI_CLASS_BRIDGE_PCI. Or it will leave the subordinary PCIe
> >>>>>> device's MMIO window un-touched.
> 
> I think __pci_bus_assign_resources() should be testing dev->hdr_type
> instead of dev->class.  The connection between "Header Type" and the
> layout of the rest of the header is very explicit (PCI r3.0 sec 6.1,
> PCIe r4.0 sec 7.5.1.1.9), and the reason for the switch statement in
> __pci_bus_assign_resources() is precisely to determine which layout to
> use.
> 
> There are several other uses of dev->class in setup-bus.c that I think
> should also be changed to use dev->hdr_type.
> 
> If we make these changes in setup-bus.c, I suspect the class code you
> assign won't matter too much.  There are a few other tests of the
> class code to figure out whether to leave certain things untouched.
> These seem a little hacky to me, but we're probably stuck with them
> for now, so you should look and see whether they apply to your
> situation.

If these change could be made in the PCI core, then the class code is no
matter what will be workable for MT7622.

As Lorenzo point it out, it's more reasonable for MT7622 to defined as a
PCI-to-PCI class code since the IP is defined as that. I intend to
following Lorenzo's suggest to update the commit message and re-send
this patch set for current solution.

> 
> >>>> And for MT7622, it integrated with block of internal control
> >>>> registers, type 1 configuration space, and is considered as a
> >>>> root complex.
> >>> 
> >>> I assume you mean a type 1 config header here. I do not think it
> >>> is mandatory for a host bridge to have a type 1 config header (and
> >>> related bridge windows + primary/secondary/subordinate bus
> >>> numbers) but I do not know how the IP you are programming is
> >>> designed.
> 
> It is definitely not mandatory for a host bridge to have a type 1
> header.  I'm not even sure that would make sense: the "Primary Bus
> Number" would not apply to a host bridge (since a host bridge's
> primary bus is some sort of CPU bus, not a PCI bus), and a type 1
> device cannot perform address translation between its primary and
> secondary buses, while a host bridge can.
> 
> A Root Port is a type 1 device where the primary bus is logically
> internal to the Root Complex.  A host bridge bridges from the CPU bus
> to that internal bus and might perform address translation.  The Root
> Port must be a PCI device.  A host bridge, being a bridge *to* the PCI
> domain, is not itself generally programmed via PCI config space and
> might not even be visible as a device in PCI config space.
> 
Thanks for the explain. Per my understanding, MT7622 is more like a
complex of Root Port and PCI-to-PCI bridge. It has type 1 header and has
the ability to translate address between its primary and secondary
buses. I guess apply the class type as PCI_CLASS_BRIDGE_PCI is
reasonable way to make its integrated internal bridge workable.

Thanks.
> Bjorn

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Fri, 2018-10-12 at 11:22 +0100, Lorenzo Pieralisi wrote:
> On Fri, Oct 12, 2018 at 04:01:29PM +0800, Honghui Zhang wrote:
> > On Thu, 2018-10-11 at 12:38 +0100, Lorenzo Pieralisi wrote:
> > > On Tue, Oct 09, 2018 at 11:08:15AM +0800, Honghui Zhang wrote:
> > > > On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> > > > > On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com 
> > > > > wrote:
> > > > > > From: Honghui Zhang 
> > > > > > 
> > > > > > The PCIe controller of MT7622 has TYPE 1 configuration space type, 
> > > > > > but
> > > > > > the HW default class type values is invalid.
> > > > > > 
> > > > > > The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
> > > > > > type for MT7622") have set the class ID for MT7622 as
> > > > > > PCI_CLASS_BRIDGE_HOSTe, but it's not workable for MT7622:
> > > > > > 
> > > > > > In __pci_bus_assign_resources, the framework only setup bridge's
> > > > > > resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
> > > > > > will leave the subordinary PCIe device's MMIO window un-touched.
> > > 
> > > Can you please provide me with a full log of the issue ?
> > > 
> > > What is the bug this patch is actually fixing ?
> > > 
> > > > > > Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the 
> > > > > > controller
> > > > > > driver do.
> > > > > 
> > > > > I think that this patch is correct but the commit log fails to pin 
> > > > > point
> > > > > the problem. The IP you are programming is a root port, that's why you
> > > > > have to have the proper class code, the patch looks fine but I would
> > > > > like to peek Bjorn's brain on this since it is a fundamental concept.
> > > > > 
> > > > 
> > > > I'm a bit confused with the concepts of PCI_CLASS_BRIDGE_HOST and
> > > > PCI_CLASS_BRIDGE_PCI, from PCI express spec,
> > > > 4.0r1.0(PCI_Express_Base_4.0r1.0_September-27-2017-c), Host Bridge is
> > > > "part of a Root Complex that connects a host CPU or CPUs to a
> > > > Hierarchy". While Root Complex defines as "A defined System Element that
> > > > includes at least one Host Bridge, Root port, or Root complex Integrated
> > > > Endpoint".
> > > > 
> > > > But according to my understanding, most of the root port IPs integrated
> > > > with a "PCI_CLASS_BRIDGE_PCI", which has type 1 configuration space and
> > > > could be saw as a pci device when using lspci.
> > > > 
> > > > And for MT7622, it integrated with block of internal control registers,
> > > > type 1 configuration space, and is considered as a root complex.
> > > 
> > > I assume you mean a type 1 config header here. I do not think it
> > > is mandatory for a host bridge to have a type 1 config header
> > > (and related bridge windows + primary/secondary/subordinate bus
> > > numbers) but I do not know how the IP you are programming is
> > > designed.
> > 
> > Yes, MT7622 has the type 1 config header and related bridge windows and
> > primary/secondary/subordinate bus numbers.
> > 
> > > 
> > > If the host bridge needs its memory window to be configured you can
> > > easily do that in the driver (with driver specific code) without
> > > requiring the generic PCI resource core to do that for you, the host
> > > bridge is the root of the bus I do not see any reason why it should
> > > be up to core PCI code to assign it, it is preprogrammed.
> > > 
> > Thanks for explain this.
> > Yes, the MT7622 bridge needs its memory window to be configured but I
> > prefer the PCI resource core to do this for the following reasons:
> > 1. MTK have MT7622 and MT2712, they pretty much using the same IP, but
> > have different memory window base. Currently we using device tree to
> > pass the memory window base. Take using of PCI resource core code to
> > parse and assign those resource will release the burden of driver.
> > 2. I do not want to re-implement the resource parse code to get the
> > memory base from device node. And hard code the memory base in driver is
> > not quite elegant.
> > 3. Most of the host driver which I referenced are using the PCI res

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Fri, 2018-10-12 at 11:22 +0100, Lorenzo Pieralisi wrote:
> On Fri, Oct 12, 2018 at 04:01:29PM +0800, Honghui Zhang wrote:
> > On Thu, 2018-10-11 at 12:38 +0100, Lorenzo Pieralisi wrote:
> > > On Tue, Oct 09, 2018 at 11:08:15AM +0800, Honghui Zhang wrote:
> > > > On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> > > > > On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com 
> > > > > wrote:
> > > > > > From: Honghui Zhang 
> > > > > > 
> > > > > > The PCIe controller of MT7622 has TYPE 1 configuration space type, 
> > > > > > but
> > > > > > the HW default class type values is invalid.
> > > > > > 
> > > > > > The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
> > > > > > type for MT7622") have set the class ID for MT7622 as
> > > > > > PCI_CLASS_BRIDGE_HOSTe, but it's not workable for MT7622:
> > > > > > 
> > > > > > In __pci_bus_assign_resources, the framework only setup bridge's
> > > > > > resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
> > > > > > will leave the subordinary PCIe device's MMIO window un-touched.
> > > 
> > > Can you please provide me with a full log of the issue ?
> > > 
> > > What is the bug this patch is actually fixing ?
> > > 
> > > > > > Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the 
> > > > > > controller
> > > > > > driver do.
> > > > > 
> > > > > I think that this patch is correct but the commit log fails to pin 
> > > > > point
> > > > > the problem. The IP you are programming is a root port, that's why you
> > > > > have to have the proper class code, the patch looks fine but I would
> > > > > like to peek Bjorn's brain on this since it is a fundamental concept.
> > > > > 
> > > > 
> > > > I'm a bit confused with the concepts of PCI_CLASS_BRIDGE_HOST and
> > > > PCI_CLASS_BRIDGE_PCI, from PCI express spec,
> > > > 4.0r1.0(PCI_Express_Base_4.0r1.0_September-27-2017-c), Host Bridge is
> > > > "part of a Root Complex that connects a host CPU or CPUs to a
> > > > Hierarchy". While Root Complex defines as "A defined System Element that
> > > > includes at least one Host Bridge, Root port, or Root complex Integrated
> > > > Endpoint".
> > > > 
> > > > But according to my understanding, most of the root port IPs integrated
> > > > with a "PCI_CLASS_BRIDGE_PCI", which has type 1 configuration space and
> > > > could be saw as a pci device when using lspci.
> > > > 
> > > > And for MT7622, it integrated with block of internal control registers,
> > > > type 1 configuration space, and is considered as a root complex.
> > > 
> > > I assume you mean a type 1 config header here. I do not think it
> > > is mandatory for a host bridge to have a type 1 config header
> > > (and related bridge windows + primary/secondary/subordinate bus
> > > numbers) but I do not know how the IP you are programming is
> > > designed.
> > 
> > Yes, MT7622 has the type 1 config header and related bridge windows and
> > primary/secondary/subordinate bus numbers.
> > 
> > > 
> > > If the host bridge needs its memory window to be configured you can
> > > easily do that in the driver (with driver specific code) without
> > > requiring the generic PCI resource core to do that for you, the host
> > > bridge is the root of the bus I do not see any reason why it should
> > > be up to core PCI code to assign it, it is preprogrammed.
> > > 
> > Thanks for explain this.
> > Yes, the MT7622 bridge needs its memory window to be configured but I
> > prefer the PCI resource core to do this for the following reasons:
> > 1. MTK have MT7622 and MT2712, they pretty much using the same IP, but
> > have different memory window base. Currently we using device tree to
> > pass the memory window base. Take using of PCI resource core code to
> > parse and assign those resource will release the burden of driver.
> > 2. I do not want to re-implement the resource parse code to get the
> > memory base from device node. And hard code the memory base in driver is
> > not quite elegant.
> > 3. Most of the host driver which I referenced are using the PCI res

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Thu, 2018-10-11 at 12:38 +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 09, 2018 at 11:08:15AM +0800, Honghui Zhang wrote:
> > On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> > > On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com 
> > > wrote:
> > > > From: Honghui Zhang 
> > > > 
> > > > The PCIe controller of MT7622 has TYPE 1 configuration space type, but
> > > > the HW default class type values is invalid.
> > > > 
> > > > The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
> > > > type for MT7622") have set the class ID for MT7622 as
> > > > PCI_CLASS_BRIDGE_HOSTe, but it's not workable for MT7622:
> > > > 
> > > > In __pci_bus_assign_resources, the framework only setup bridge's
> > > > resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
> > > > will leave the subordinary PCIe device's MMIO window un-touched.
> 
> Can you please provide me with a full log of the issue ?
> 
> What is the bug this patch is actually fixing ?
> 
> > > > Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the controller
> > > > driver do.
> > > 
> > > I think that this patch is correct but the commit log fails to pin point
> > > the problem. The IP you are programming is a root port, that's why you
> > > have to have the proper class code, the patch looks fine but I would
> > > like to peek Bjorn's brain on this since it is a fundamental concept.
> > > 
> > 
> > I'm a bit confused with the concepts of PCI_CLASS_BRIDGE_HOST and
> > PCI_CLASS_BRIDGE_PCI, from PCI express spec,
> > 4.0r1.0(PCI_Express_Base_4.0r1.0_September-27-2017-c), Host Bridge is
> > "part of a Root Complex that connects a host CPU or CPUs to a
> > Hierarchy". While Root Complex defines as "A defined System Element that
> > includes at least one Host Bridge, Root port, or Root complex Integrated
> > Endpoint".
> > 
> > But according to my understanding, most of the root port IPs integrated
> > with a "PCI_CLASS_BRIDGE_PCI", which has type 1 configuration space and
> > could be saw as a pci device when using lspci.
> > 
> > And for MT7622, it integrated with block of internal control registers,
> > type 1 configuration space, and is considered as a root complex.
> 
> I assume you mean a type 1 config header here. I do not think it
> is mandatory for a host bridge to have a type 1 config header
> (and related bridge windows + primary/secondary/subordinate bus
> numbers) but I do not know how the IP you are programming is
> designed.

Yes, MT7622 has the type 1 config header and related bridge windows and
primary/secondary/subordinate bus numbers.

> 
> If the host bridge needs its memory window to be configured you can
> easily do that in the driver (with driver specific code) without
> requiring the generic PCI resource core to do that for you, the host
> bridge is the root of the bus I do not see any reason why it should
> be up to core PCI code to assign it, it is preprogrammed.
> 
Thanks for explain this.
Yes, the MT7622 bridge needs its memory window to be configured but I
prefer the PCI resource core to do this for the following reasons:
1. MTK have MT7622 and MT2712, they pretty much using the same IP, but
have different memory window base. Currently we using device tree to
pass the memory window base. Take using of PCI resource core code to
parse and assign those resource will release the burden of driver.
2. I do not want to re-implement the resource parse code to get the
memory base from device node. And hard code the memory base in driver is
not quite elegant.
3. Most of the host driver which I referenced are using the PCI resource
core to help with it's memory window configure, I guess following the
majority way maybe better even they may have slit different of the IP
design from MTK.
4. Passing the memory base in device node make it more flexible to
change the memory window base (in the HW acceptable range) in case of
some special EP device required some special PCI address range.
5. MT7622 and MT2712 have the pretty much same IP only MT7622's HW has
set the class type to an un-proper class type. Set it to the same values
as MT2712 is an easy way to fix.

thanks.
> > I'm not sure which CLASS type it should have:
> > From PCI_Code-ID_r_1_10__v8-Nov_2017, class type of
> > 0x0604(PCI_CLASS_BRIDGE_PCI) is defined as a PCI-to-PCI bridge, not
> > literally suitable for MT7622(which is a root complex)(In my personal
> > opinion). But it is the only workable CLASS type for MT7622 in current
> > kernel.
> > 
>

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Thu, 2018-10-11 at 12:38 +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 09, 2018 at 11:08:15AM +0800, Honghui Zhang wrote:
> > On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> > > On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com 
> > > wrote:
> > > > From: Honghui Zhang 
> > > > 
> > > > The PCIe controller of MT7622 has TYPE 1 configuration space type, but
> > > > the HW default class type values is invalid.
> > > > 
> > > > The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
> > > > type for MT7622") have set the class ID for MT7622 as
> > > > PCI_CLASS_BRIDGE_HOSTe, but it's not workable for MT7622:
> > > > 
> > > > In __pci_bus_assign_resources, the framework only setup bridge's
> > > > resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
> > > > will leave the subordinary PCIe device's MMIO window un-touched.
> 
> Can you please provide me with a full log of the issue ?
> 
> What is the bug this patch is actually fixing ?
> 
> > > > Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the controller
> > > > driver do.
> > > 
> > > I think that this patch is correct but the commit log fails to pin point
> > > the problem. The IP you are programming is a root port, that's why you
> > > have to have the proper class code, the patch looks fine but I would
> > > like to peek Bjorn's brain on this since it is a fundamental concept.
> > > 
> > 
> > I'm a bit confused with the concepts of PCI_CLASS_BRIDGE_HOST and
> > PCI_CLASS_BRIDGE_PCI, from PCI express spec,
> > 4.0r1.0(PCI_Express_Base_4.0r1.0_September-27-2017-c), Host Bridge is
> > "part of a Root Complex that connects a host CPU or CPUs to a
> > Hierarchy". While Root Complex defines as "A defined System Element that
> > includes at least one Host Bridge, Root port, or Root complex Integrated
> > Endpoint".
> > 
> > But according to my understanding, most of the root port IPs integrated
> > with a "PCI_CLASS_BRIDGE_PCI", which has type 1 configuration space and
> > could be saw as a pci device when using lspci.
> > 
> > And for MT7622, it integrated with block of internal control registers,
> > type 1 configuration space, and is considered as a root complex.
> 
> I assume you mean a type 1 config header here. I do not think it
> is mandatory for a host bridge to have a type 1 config header
> (and related bridge windows + primary/secondary/subordinate bus
> numbers) but I do not know how the IP you are programming is
> designed.

Yes, MT7622 has the type 1 config header and related bridge windows and
primary/secondary/subordinate bus numbers.

> 
> If the host bridge needs its memory window to be configured you can
> easily do that in the driver (with driver specific code) without
> requiring the generic PCI resource core to do that for you, the host
> bridge is the root of the bus I do not see any reason why it should
> be up to core PCI code to assign it, it is preprogrammed.
> 
Thanks for explain this.
Yes, the MT7622 bridge needs its memory window to be configured but I
prefer the PCI resource core to do this for the following reasons:
1. MTK have MT7622 and MT2712, they pretty much using the same IP, but
have different memory window base. Currently we using device tree to
pass the memory window base. Take using of PCI resource core code to
parse and assign those resource will release the burden of driver.
2. I do not want to re-implement the resource parse code to get the
memory base from device node. And hard code the memory base in driver is
not quite elegant.
3. Most of the host driver which I referenced are using the PCI resource
core to help with it's memory window configure, I guess following the
majority way maybe better even they may have slit different of the IP
design from MTK.
4. Passing the memory base in device node make it more flexible to
change the memory window base (in the HW acceptable range) in case of
some special EP device required some special PCI address range.
5. MT7622 and MT2712 have the pretty much same IP only MT7622's HW has
set the class type to an un-proper class type. Set it to the same values
as MT2712 is an easy way to fix.

thanks.
> > I'm not sure which CLASS type it should have:
> > From PCI_Code-ID_r_1_10__v8-Nov_2017, class type of
> > 0x0604(PCI_CLASS_BRIDGE_PCI) is defined as a PCI-to-PCI bridge, not
> > literally suitable for MT7622(which is a root complex)(In my personal
> > opinion). But it is the only workable CLASS type for MT7622 in current
> > kernel.
> > 
>

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The PCIe controller of MT7622 has TYPE 1 configuration space type, but
> > the HW default class type values is invalid.
> > 
> > The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
> > type for MT7622") have set the class ID for MT7622 as
> > PCI_CLASS_BRIDGE_HOST, but it's not workable for MT7622:
> > 
> > In __pci_bus_assign_resources, the framework only setup bridge's
> > resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
> > will leave the subordinary PCIe device's MMIO window un-touched.
> > 
> > Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the controller
> > driver do.
> 
> I think that this patch is correct but the commit log fails to pin point
> the problem. The IP you are programming is a root port, that's why you
> have to have the proper class code, the patch looks fine but I would
> like to peek Bjorn's brain on this since it is a fundamental concept.
> 

I'm a bit confused with the concepts of PCI_CLASS_BRIDGE_HOST and
PCI_CLASS_BRIDGE_PCI, from PCI express spec,
4.0r1.0(PCI_Express_Base_4.0r1.0_September-27-2017-c), Host Bridge is
"part of a Root Complex that connects a host CPU or CPUs to a
Hierarchy". While Root Complex defines as "A defined System Element that
includes at least one Host Bridge, Root port, or Root complex Integrated
Endpoint".

But according to my understanding, most of the root port IPs integrated
with a "PCI_CLASS_BRIDGE_PCI", which has type 1 configuration space and
could be saw as a pci device when using lspci.

And for MT7622, it integrated with block of internal control registers,
type 1 configuration space, and is considered as a root complex.

I'm not sure which CLASS type it should have:
>From PCI_Code-ID_r_1_10__v8-Nov_2017, class type of
0x0604(PCI_CLASS_BRIDGE_PCI) is defined as a PCI-to-PCI bridge, not
literally suitable for MT7622(which is a root complex)(In my personal
opinion). But it is the only workable CLASS type for MT7622 in current
kernel.

> If the kernel does not assign resources unless it detects a
> PCI_CLASS_BRIDGE_PCI this means that for components that are
> actually PCI_CLASS_BRIDGE_HOST their register set must come
> preprogrammed unless I am missing something.
> 

In the function pci_request_resource_alignment, it will by pass the
resource assignment for PCI_CLASS_BRIDGE_HOST, though I'm not figured
out why.

> I would like to get to the bottom of this since it is a fundamental
> enumeration concept.
> 

Do you like me to re-write the commit message for this patch and put the
above information in? Or just not mention the PCI_CLASS_BRIDGE_HOST
assign resource routine?

Thanks

> Thanks,
> Lorenzo
> 
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 288b8e2..bcdac9b 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -432,7 +432,7 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > val = PCI_VENDOR_ID_MEDIATEK;
> > writew(val, port->base + PCIE_CONF_VEND_ID);
> >  
> > -   val = PCI_CLASS_BRIDGE_HOST;
> > +   val = PCI_CLASS_BRIDGE_PCI;
> > writew(val, port->base + PCIE_CONF_CLASS_ID);
> > }
> >  
> > -- 
> > 2.6.4
> > 

Re: [PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

[Honghui Zhang]

On Mon, 2018-10-08 at 18:23 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 08, 2018 at 11:24:41AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The PCIe controller of MT7622 has TYPE 1 configuration space type, but
> > the HW default class type values is invalid.
> > 
> > The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
> > type for MT7622") have set the class ID for MT7622 as
> > PCI_CLASS_BRIDGE_HOST, but it's not workable for MT7622:
> > 
> > In __pci_bus_assign_resources, the framework only setup bridge's
> > resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
> > will leave the subordinary PCIe device's MMIO window un-touched.
> > 
> > Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the controller
> > driver do.
> 
> I think that this patch is correct but the commit log fails to pin point
> the problem. The IP you are programming is a root port, that's why you
> have to have the proper class code, the patch looks fine but I would
> like to peek Bjorn's brain on this since it is a fundamental concept.
> 

I'm a bit confused with the concepts of PCI_CLASS_BRIDGE_HOST and
PCI_CLASS_BRIDGE_PCI, from PCI express spec,
4.0r1.0(PCI_Express_Base_4.0r1.0_September-27-2017-c), Host Bridge is
"part of a Root Complex that connects a host CPU or CPUs to a
Hierarchy". While Root Complex defines as "A defined System Element that
includes at least one Host Bridge, Root port, or Root complex Integrated
Endpoint".

But according to my understanding, most of the root port IPs integrated
with a "PCI_CLASS_BRIDGE_PCI", which has type 1 configuration space and
could be saw as a pci device when using lspci.

And for MT7622, it integrated with block of internal control registers,
type 1 configuration space, and is considered as a root complex.

I'm not sure which CLASS type it should have:
>From PCI_Code-ID_r_1_10__v8-Nov_2017, class type of
0x0604(PCI_CLASS_BRIDGE_PCI) is defined as a PCI-to-PCI bridge, not
literally suitable for MT7622(which is a root complex)(In my personal
opinion). But it is the only workable CLASS type for MT7622 in current
kernel.

> If the kernel does not assign resources unless it detects a
> PCI_CLASS_BRIDGE_PCI this means that for components that are
> actually PCI_CLASS_BRIDGE_HOST their register set must come
> preprogrammed unless I am missing something.
> 

In the function pci_request_resource_alignment, it will by pass the
resource assignment for PCI_CLASS_BRIDGE_HOST, though I'm not figured
out why.

> I would like to get to the bottom of this since it is a fundamental
> enumeration concept.
> 

Do you like me to re-write the commit message for this patch and put the
above information in? Or just not mention the PCI_CLASS_BRIDGE_HOST
assign resource routine?

Thanks

> Thanks,
> Lorenzo
> 
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 288b8e2..bcdac9b 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -432,7 +432,7 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > val = PCI_VENDOR_ID_MEDIATEK;
> > writew(val, port->base + PCIE_CONF_VEND_ID);
> >  
> > -   val = PCI_CLASS_BRIDGE_HOST;
> > +   val = PCI_CLASS_BRIDGE_PCI;
> > writew(val, port->base + PCIE_CONF_CLASS_ID);
> > }
> >  
> > -- 
> > 2.6.4
> > 

Re: [PATCH v6 0/9] PCI: mediatek: fixup find_port, enable_msi and add pm, module support

[Honghui Zhang]

On Mon, 2018-10-08 at 12:31 -0500, Bjorn Helgaas wrote:
> On Mon, Oct 08, 2018 at 11:24:39AM +0800, honghui.zh...@mediatek.com wrote:
> 
> > Honghui Zhang (9):
> >   PCI: mediatek: Using slot's devfn for compare to fix
> > mtk_pcie_find_port logic
> >   PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI
> >   PCI: mediatek: Remove the redundant dev->pm_domain check
> >   PCI: mediatek: Convert to use pci_host_probe()
> >   PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
> > after mtk_pcie_setup_irq
> >   PCI: mediatek: Fixup enable msi logic by enable msi after clock
> > enabled
> 
> s/msi/MSI/ (twice)
> 
> >   PCI: mediatek: Add system pm support for MT2712 and MT7622
> 
> s/pm/PM/
> 
> "msi" and "pm" are not English words, and capitalizing them tells the
> reader that they are acronyms or initialisms (like GIC and IRQ below).
> 

Thanks for the comments. Will fix those in the next version.

thanks.

> >   PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
> >   PCI: mediatek: Add loadable kernel module support

Re: [PATCH v6 0/9] PCI: mediatek: fixup find_port, enable_msi and add pm, module support

[Honghui Zhang]

On Mon, 2018-10-08 at 12:31 -0500, Bjorn Helgaas wrote:
> On Mon, Oct 08, 2018 at 11:24:39AM +0800, honghui.zh...@mediatek.com wrote:
> 
> > Honghui Zhang (9):
> >   PCI: mediatek: Using slot's devfn for compare to fix
> > mtk_pcie_find_port logic
> >   PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI
> >   PCI: mediatek: Remove the redundant dev->pm_domain check
> >   PCI: mediatek: Convert to use pci_host_probe()
> >   PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
> > after mtk_pcie_setup_irq
> >   PCI: mediatek: Fixup enable msi logic by enable msi after clock
> > enabled
> 
> s/msi/MSI/ (twice)
> 
> >   PCI: mediatek: Add system pm support for MT2712 and MT7622
> 
> s/pm/PM/
> 
> "msi" and "pm" are not English words, and capitalizing them tells the
> reader that they are acronyms or initialisms (like GIC and IRQ below).
> 

Thanks for the comments. Will fix those in the next version.

thanks.

> >   PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
> >   PCI: mediatek: Add loadable kernel module support

Re: [PATCH v5 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic

[Honghui Zhang]

On Tue, 2018-10-02 at 11:59 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 01, 2018 at 03:36:41PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Sep 28, 2018 at 06:04:32PM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > The Mediatek's host controller has two slots, each with it's own control
> > > registers. The host driver need to identify which slot was connected
> > > in order to access the device's configuration space. There's problem
> > > for current host driver to find out which slot was connected to for
> > > a given EP device.
> > > 
> > > Assuming each slot have connect with one EP device as below:
> > > 
> > > host bridge
> > >   bus 0 --> __|___
> > >|  |
> > >|  |
> > >  slot 0 slot 1
> > >   bus 1 -->|bus 2 --> |
> > >|  |
> > >  EP 0   EP 1
> > > 
> > > During PCI enumeration, system software will scan all the PCI device
> > > starting from devfn 0. So it will get the proper port for slot0 and
> > > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > > for port0's slot value. So the host driver should not using EP's devfn
> > > but the slot's devfn(the slot which EP was connected to) for match.
> > > 
> > > This patch fix the mtk_pcie_find_port's logic by using the slot's
> > > devfn for match if finding device connected to the subordinate bus.
> > > 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c | 17 -
> > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index dae..264e03f 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -337,10 +337,25 @@ static struct mtk_pcie_port 
> > > *mtk_pcie_find_port(struct pci_bus *bus,
> > >  {
> > >   struct mtk_pcie *pcie = bus->sysdata;
> > >   struct mtk_pcie_port *port;
> > > + struct pci_dev *dev = NULL;
> > > +
> > > + /*
> > > +  * Walk the bus hierarchy to get the devfn value
> > > +  * of the port in the root bus.
> > > +  */
> > > + while (bus && bus->number) {
> > > + dev = bus->self;
> > > + bus = dev->bus;
> > 
> > If you add:
> > 
> > devfn = dev->devfn;
> > 
> > here
> > 
> > > + }
> > > +
> > > + list_for_each_entry(port, >ports, list) {
> > > + /* Using slot's devfn to compare for subordinary bus. */
> > > + if (dev)
> > > + devfn = dev->devfn;
> > 
> > You can remove this ugly hunk altogether (and dev initialization
> > to NULL).
> 
> Hi Honghui,
> 
> if you can make this change I would merge this series, it has been
> been in the mailing lists for a while, I can make that change too
> just let me know please.
> 

Hi, Lorenzo, sorry for the late reply.

I tried your advise and it works fine.

I will send another version to fix this, as well as to add a fix tag in
the commit message of patch 6.

thanks

> Thanks,
> Lorenzo

Re: [PATCH v5 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic

[Honghui Zhang]

On Tue, 2018-10-02 at 11:59 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 01, 2018 at 03:36:41PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Sep 28, 2018 at 06:04:32PM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > The Mediatek's host controller has two slots, each with it's own control
> > > registers. The host driver need to identify which slot was connected
> > > in order to access the device's configuration space. There's problem
> > > for current host driver to find out which slot was connected to for
> > > a given EP device.
> > > 
> > > Assuming each slot have connect with one EP device as below:
> > > 
> > > host bridge
> > >   bus 0 --> __|___
> > >|  |
> > >|  |
> > >  slot 0 slot 1
> > >   bus 1 -->|bus 2 --> |
> > >|  |
> > >  EP 0   EP 1
> > > 
> > > During PCI enumeration, system software will scan all the PCI device
> > > starting from devfn 0. So it will get the proper port for slot0 and
> > > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > > for port0's slot value. So the host driver should not using EP's devfn
> > > but the slot's devfn(the slot which EP was connected to) for match.
> > > 
> > > This patch fix the mtk_pcie_find_port's logic by using the slot's
> > > devfn for match if finding device connected to the subordinate bus.
> > > 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c | 17 -
> > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index dae..264e03f 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -337,10 +337,25 @@ static struct mtk_pcie_port 
> > > *mtk_pcie_find_port(struct pci_bus *bus,
> > >  {
> > >   struct mtk_pcie *pcie = bus->sysdata;
> > >   struct mtk_pcie_port *port;
> > > + struct pci_dev *dev = NULL;
> > > +
> > > + /*
> > > +  * Walk the bus hierarchy to get the devfn value
> > > +  * of the port in the root bus.
> > > +  */
> > > + while (bus && bus->number) {
> > > + dev = bus->self;
> > > + bus = dev->bus;
> > 
> > If you add:
> > 
> > devfn = dev->devfn;
> > 
> > here
> > 
> > > + }
> > > +
> > > + list_for_each_entry(port, >ports, list) {
> > > + /* Using slot's devfn to compare for subordinary bus. */
> > > + if (dev)
> > > + devfn = dev->devfn;
> > 
> > You can remove this ugly hunk altogether (and dev initialization
> > to NULL).
> 
> Hi Honghui,
> 
> if you can make this change I would merge this series, it has been
> been in the mailing lists for a while, I can make that change too
> just let me know please.
> 

Hi, Lorenzo, sorry for the late reply.

I tried your advise and it works fine.

I will send another version to fix this, as well as to add a fix tag in
the commit message of patch 6.

thanks

> Thanks,
> Lorenzo

Re: [PATCH v5 4/9] PCI: mediatek: Convert to use pci_host_probe()

[Honghui Zhang]

On Fri, 2018-09-28 at 23:41 +0800, Ryder Lee wrote:
> On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Part of mtk_pcie_register_host is an open-coded version of
> > pci_host_probe(). So instead of duplicating this code, use
> > pci_host_probe() directly and remove mtk_pcie_register_host.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 37 
> > --
> >  1 file changed, 8 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index e2c4127..cbf4543 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -1125,34 +1125,6 @@ static int mtk_pcie_request_resources(struct 
> > mtk_pcie *pcie)
> > return 0;
> >  }
> >  
> > -static int mtk_pcie_register_host(struct pci_host_bridge *host)
> > -{
> > -   struct mtk_pcie *pcie = pci_host_bridge_priv(host);
> > -   struct pci_bus *child;
> > -   int err;
> 
> To make the patch simple, could we keep these host->*. and return
> pci_host_probe() directly?

Well, I guess it's not necessary to keep the mtk_pcie_register_host just
wrap pci_host_probe(). Put those host->* directly in probe function is
no harm, it will reduce one function call and related parameter passing.

I may update this patch to keep the mtk_pcie_register_host if you insist
though I prefer the current way.

Thanks.
> 
> > -   host->busnr = pcie->busn.start;
> > -   host->dev.parent = pcie->dev;
> > -   host->ops = pcie->soc->ops;
> > -   host->map_irq = of_irq_parse_and_map_pci;
> > -   host->swizzle_irq = pci_common_swizzle;
> > -   host->sysdata = pcie;
> > -
> > -   err = pci_scan_root_bus_bridge(host);
> > -   if (err < 0)
> > -   return err;
> > -
> > -   pci_bus_size_bridges(host->bus);
> > -   pci_bus_assign_resources(host->bus);
> > -
> > -   list_for_each_entry(child, >bus->children, node)
> > -   pcie_bus_configure_settings(child);
> > -
> > -   pci_bus_add_devices(host->bus);
> > -
> > -   return 0;
> > -}
> > -
> >  static int mtk_pcie_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = >dev;
> > @@ -1179,7 +1151,14 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > if (err)
> > goto put_resources;
> >  
> > -   err = mtk_pcie_register_host(host);
> > +   host->busnr = pcie->busn.start;
> > +   host->dev.parent = pcie->dev;
> > +   host->ops = pcie->soc->ops;
> > +   host->map_irq = of_irq_parse_and_map_pci;
> > +   host->swizzle_irq = pci_common_swizzle;
> > +   host->sysdata = pcie;
> > +
> > +   err = pci_host_probe(host);
> > if (err)
> > goto put_resources;
> >  
> 
> 

Re: [PATCH v5 4/9] PCI: mediatek: Convert to use pci_host_probe()

[Honghui Zhang]

On Fri, 2018-09-28 at 23:41 +0800, Ryder Lee wrote:
> On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Part of mtk_pcie_register_host is an open-coded version of
> > pci_host_probe(). So instead of duplicating this code, use
> > pci_host_probe() directly and remove mtk_pcie_register_host.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 37 
> > --
> >  1 file changed, 8 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index e2c4127..cbf4543 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -1125,34 +1125,6 @@ static int mtk_pcie_request_resources(struct 
> > mtk_pcie *pcie)
> > return 0;
> >  }
> >  
> > -static int mtk_pcie_register_host(struct pci_host_bridge *host)
> > -{
> > -   struct mtk_pcie *pcie = pci_host_bridge_priv(host);
> > -   struct pci_bus *child;
> > -   int err;
> 
> To make the patch simple, could we keep these host->*. and return
> pci_host_probe() directly?

Well, I guess it's not necessary to keep the mtk_pcie_register_host just
wrap pci_host_probe(). Put those host->* directly in probe function is
no harm, it will reduce one function call and related parameter passing.

I may update this patch to keep the mtk_pcie_register_host if you insist
though I prefer the current way.

Thanks.
> 
> > -   host->busnr = pcie->busn.start;
> > -   host->dev.parent = pcie->dev;
> > -   host->ops = pcie->soc->ops;
> > -   host->map_irq = of_irq_parse_and_map_pci;
> > -   host->swizzle_irq = pci_common_swizzle;
> > -   host->sysdata = pcie;
> > -
> > -   err = pci_scan_root_bus_bridge(host);
> > -   if (err < 0)
> > -   return err;
> > -
> > -   pci_bus_size_bridges(host->bus);
> > -   pci_bus_assign_resources(host->bus);
> > -
> > -   list_for_each_entry(child, >bus->children, node)
> > -   pcie_bus_configure_settings(child);
> > -
> > -   pci_bus_add_devices(host->bus);
> > -
> > -   return 0;
> > -}
> > -
> >  static int mtk_pcie_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = >dev;
> > @@ -1179,7 +1151,14 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > if (err)
> > goto put_resources;
> >  
> > -   err = mtk_pcie_register_host(host);
> > +   host->busnr = pcie->busn.start;
> > +   host->dev.parent = pcie->dev;
> > +   host->ops = pcie->soc->ops;
> > +   host->map_irq = of_irq_parse_and_map_pci;
> > +   host->swizzle_irq = pci_common_swizzle;
> > +   host->sysdata = pcie;
> > +
> > +   err = pci_host_probe(host);
> > if (err)
> > goto put_resources;
> >  
> 
> 

Re: [PATCH v4 2/4] PCI: mediatek: enable msi after clock enabled

[Honghui Zhang]

On Fri, 2018-09-21 at 17:46 +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 10, 2018 at 05:50:21PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The clocks was not enabled when enable MSI. This patch fix this
> > issue by calling mtk_pcie_enable_msi in mtk_pcie_startup_port_v2
> > since the clock was all enabled at that time.
> > 
> > The function of mtk_pcie_startup_port_v2's define location is
> > re-arranged to avoid mtk_pcie_enable_msi's forward declaration.
> > 
> > Signed-off-by: Honghui Zhang 
> > Reviewed-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 143 
> > +
> >  1 file changed, 72 insertions(+), 71 deletions(-)
> 
> Can you read:
> 
> https://marc.info/?l=linux-pci=150905742808166=2
> 
> follow it and adapt this patch and the others accordingly please ?
> 
Sorry, I mixed those patches together. I will split a new patch to do
the code re-arrangement to avoid forward declaration.

Thanks.
> Thanks,
> Lorenzo
> 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 20b9088..5aba43a 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -398,75 +398,6 @@ static struct pci_ops mtk_pcie_ops_v2 = {
> > .write = mtk_pcie_config_write,
> >  };
> >  
> > -static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> > -{
> > -   struct mtk_pcie *pcie = port->pcie;
> > -   struct resource *mem = >mem;
> > -   const struct mtk_pcie_soc *soc = port->pcie->soc;
> > -   u32 val;
> > -   size_t size;
> > -   int err;
> > -
> > -   /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
> > -   if (pcie->base) {
> > -   val = readl(pcie->base + PCIE_SYS_CFG_V2);
> > -   val |= PCIE_CSR_LTSSM_EN(port->slot) |
> > -  PCIE_CSR_ASPM_L1_EN(port->slot);
> > -   writel(val, pcie->base + PCIE_SYS_CFG_V2);
> > -   }
> > -
> > -   /* Assert all reset signals */
> > -   writel(0, port->base + PCIE_RST_CTRL);
> > -
> > -   /*
> > -* Enable PCIe link down reset, if link status changed from link up to
> > -* link down, this will reset MAC control registers and configuration
> > -* space.
> > -*/
> > -   writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
> > -
> > -   /* De-assert PHY, PE, PIPE, MAC and configuration reset */
> > -   val = readl(port->base + PCIE_RST_CTRL);
> > -   val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
> > -  PCIE_MAC_SRSTB | PCIE_CRSTB;
> > -   writel(val, port->base + PCIE_RST_CTRL);
> > -
> > -   /* Set up vendor ID and class code */
> > -   if (soc->need_fix_class_id) {
> > -   val = PCI_VENDOR_ID_MEDIATEK;
> > -   writew(val, port->base + PCIE_CONF_VEND_ID);
> > -
> > -   val = PCI_CLASS_BRIDGE_HOST;
> > -   writew(val, port->base + PCIE_CONF_CLASS_ID);
> > -   }
> > -
> > -   /* 100ms timeout value should be enough for Gen1/2 training */
> > -   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > -!!(val & PCIE_PORT_LINKUP_V2), 20,
> > -100 * USEC_PER_MSEC);
> > -   if (err)
> > -   return -ETIMEDOUT;
> > -
> > -   /* Set INTx mask */
> > -   val = readl(port->base + PCIE_INT_MASK);
> > -   val &= ~INTX_MASK;
> > -   writel(val, port->base + PCIE_INT_MASK);
> > -
> > -   /* Set AHB to PCIe translation windows */
> > -   size = mem->end - mem->start;
> > -   val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
> > -   writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
> > -
> > -   val = upper_32_bits(mem->start);
> > -   writel(val, port->base + PCIE_AHB_TRANS_BASE0_H);
> > -
> > -   /* Set PCIe to AXI translation memory space.*/
> > -   val = fls(0x) | WIN_ENABLE;
> > -   writel(val, port->base + PCIE_AXI_WINDOW0);
> > -
> > -   return 0;
> > -}
> > -
> >  static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> >  {
> > struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> > @@ -643,8 +574,6 @@ static int mtk_pcie_init_irq_domain(struct 
> > mtk_pcie_port *port,
> > ret = mtk_pcie_allocate_msi_domains(port);
> >

Re: [PATCH v4 2/4] PCI: mediatek: enable msi after clock enabled

[Honghui Zhang]

On Fri, 2018-09-21 at 17:46 +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 10, 2018 at 05:50:21PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The clocks was not enabled when enable MSI. This patch fix this
> > issue by calling mtk_pcie_enable_msi in mtk_pcie_startup_port_v2
> > since the clock was all enabled at that time.
> > 
> > The function of mtk_pcie_startup_port_v2's define location is
> > re-arranged to avoid mtk_pcie_enable_msi's forward declaration.
> > 
> > Signed-off-by: Honghui Zhang 
> > Reviewed-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 143 
> > +
> >  1 file changed, 72 insertions(+), 71 deletions(-)
> 
> Can you read:
> 
> https://marc.info/?l=linux-pci=150905742808166=2
> 
> follow it and adapt this patch and the others accordingly please ?
> 
Sorry, I mixed those patches together. I will split a new patch to do
the code re-arrangement to avoid forward declaration.

Thanks.
> Thanks,
> Lorenzo
> 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 20b9088..5aba43a 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -398,75 +398,6 @@ static struct pci_ops mtk_pcie_ops_v2 = {
> > .write = mtk_pcie_config_write,
> >  };
> >  
> > -static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> > -{
> > -   struct mtk_pcie *pcie = port->pcie;
> > -   struct resource *mem = >mem;
> > -   const struct mtk_pcie_soc *soc = port->pcie->soc;
> > -   u32 val;
> > -   size_t size;
> > -   int err;
> > -
> > -   /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
> > -   if (pcie->base) {
> > -   val = readl(pcie->base + PCIE_SYS_CFG_V2);
> > -   val |= PCIE_CSR_LTSSM_EN(port->slot) |
> > -  PCIE_CSR_ASPM_L1_EN(port->slot);
> > -   writel(val, pcie->base + PCIE_SYS_CFG_V2);
> > -   }
> > -
> > -   /* Assert all reset signals */
> > -   writel(0, port->base + PCIE_RST_CTRL);
> > -
> > -   /*
> > -* Enable PCIe link down reset, if link status changed from link up to
> > -* link down, this will reset MAC control registers and configuration
> > -* space.
> > -*/
> > -   writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
> > -
> > -   /* De-assert PHY, PE, PIPE, MAC and configuration reset */
> > -   val = readl(port->base + PCIE_RST_CTRL);
> > -   val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
> > -  PCIE_MAC_SRSTB | PCIE_CRSTB;
> > -   writel(val, port->base + PCIE_RST_CTRL);
> > -
> > -   /* Set up vendor ID and class code */
> > -   if (soc->need_fix_class_id) {
> > -   val = PCI_VENDOR_ID_MEDIATEK;
> > -   writew(val, port->base + PCIE_CONF_VEND_ID);
> > -
> > -   val = PCI_CLASS_BRIDGE_HOST;
> > -   writew(val, port->base + PCIE_CONF_CLASS_ID);
> > -   }
> > -
> > -   /* 100ms timeout value should be enough for Gen1/2 training */
> > -   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > -!!(val & PCIE_PORT_LINKUP_V2), 20,
> > -100 * USEC_PER_MSEC);
> > -   if (err)
> > -   return -ETIMEDOUT;
> > -
> > -   /* Set INTx mask */
> > -   val = readl(port->base + PCIE_INT_MASK);
> > -   val &= ~INTX_MASK;
> > -   writel(val, port->base + PCIE_INT_MASK);
> > -
> > -   /* Set AHB to PCIe translation windows */
> > -   size = mem->end - mem->start;
> > -   val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
> > -   writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
> > -
> > -   val = upper_32_bits(mem->start);
> > -   writel(val, port->base + PCIE_AHB_TRANS_BASE0_H);
> > -
> > -   /* Set PCIe to AXI translation memory space.*/
> > -   val = fls(0x) | WIN_ENABLE;
> > -   writel(val, port->base + PCIE_AXI_WINDOW0);
> > -
> > -   return 0;
> > -}
> > -
> >  static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> >  {
> > struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> > @@ -643,8 +574,6 @@ static int mtk_pcie_init_irq_domain(struct 
> > mtk_pcie_port *port,
> > ret = mtk_pcie_allocate_msi_domains(port);
> >

Re: [PATCH v4 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical

[Honghui Zhang]

On Fri, 2018-09-21 at 17:07 +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 10, 2018 at 05:50:20PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The Mediatek's host controller has two slots, each with it's own control
> > registers. The host driver need to identify which slot was connected
> > in order to access the device's configuration space. There's problem
> > for current host driver to find out which slot was connected to for
> > a given EP device.
> > 
> > Assuming each slot have connect with one EP device as below:
> > 
> > host bridge
> >   bus 0 --> __|___
> >|  |
> >|  |
> >  slot 0 slot 1
> >   bus 1 -->|bus 2 --> |
> >|  |
> >  EP 0   EP 1
> > 
> > During PCI enumeration, system software will scan all the PCI device
> > starting from devfn 0. So it will get the proper port for slot0 and
> > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > for port0's slot value. So the host driver should not using EP's devfn
> > but the slot's devfn(the slot which EP was connected to) for match.
> > 
> > This patch fix the mtk_pcie_find_port's logical by using the slot's
> > devfn for match.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 19 +--
> >  1 file changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 861dda6..20b9088 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -337,11 +337,26 @@ static struct mtk_pcie_port 
> > *mtk_pcie_find_port(struct pci_bus *bus,
> >  {
> > struct mtk_pcie *pcie = bus->sysdata;
> > struct mtk_pcie_port *port;
> > +   struct pci_dev *dev;
> > +   struct pci_bus *pbus;
> >  
> > -   list_for_each_entry(port, >ports, list)
> > -   if (port->slot == PCI_SLOT(devfn))
> > +   list_for_each_entry(port, >ports, list) {
> > +   if (!bus->number && port->slot == PCI_SLOT(devfn))
> > return port;
> >  
> > +   if (bus->number) {
> > +   pbus = bus;
> > +
> > +   while (pbus->number) {
> > +   dev = pbus->self;
> > +   pbus = dev->bus;
> > +   }
> > +
> > +   if (port->slot == PCI_SLOT(dev->devfn))
> > +   return port;
> > +   }
> > +   }
> 
>   /*
>* Walk the bus hierarchy to get the devfn value
>* of the port in the root bus.
>*/
>   while (bus && bus->number) {
>   devfn = bus->self->devfn;
>   bus = bus->parent;
>   }
> 
>   list_for_each_entry(port, >ports, list) {
>   if (port->slot == PCI_SLOT(devfn))
>   return port;
> 
>   return NULL;
> 
> Would it work ? Maybe it is a little easier to parse.
> 

Thanks, this is much better.

> I think this can even be made easier by using struct device_node* as
> comparison (and store it in port->slot instead of the port number), I
> think that the pci_dev representing the port should have the right
> of_node associated with it by core code, so it is just a matter of
> finding the first pci_dev parent with an of_node set and compare it
> against port->slot (that should be converted to a struct device_node*).
> 
> This ought to be tested and written but I think that's doable.
> 

Thanks, I will do my homework and figure a way out through this
solution.
Currently port->slot is used in too much place to be removed, I guess I
need to added a new parameter in the port struct to store the of_node
for compare.
I'm not sure which way is better, anyway, let me try the new solution.

thanks.

> Lorenzo

Re: [PATCH v4 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical

[Honghui Zhang]

On Fri, 2018-09-21 at 17:07 +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 10, 2018 at 05:50:20PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The Mediatek's host controller has two slots, each with it's own control
> > registers. The host driver need to identify which slot was connected
> > in order to access the device's configuration space. There's problem
> > for current host driver to find out which slot was connected to for
> > a given EP device.
> > 
> > Assuming each slot have connect with one EP device as below:
> > 
> > host bridge
> >   bus 0 --> __|___
> >|  |
> >|  |
> >  slot 0 slot 1
> >   bus 1 -->|bus 2 --> |
> >|  |
> >  EP 0   EP 1
> > 
> > During PCI enumeration, system software will scan all the PCI device
> > starting from devfn 0. So it will get the proper port for slot0 and
> > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > for port0's slot value. So the host driver should not using EP's devfn
> > but the slot's devfn(the slot which EP was connected to) for match.
> > 
> > This patch fix the mtk_pcie_find_port's logical by using the slot's
> > devfn for match.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 19 +--
> >  1 file changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 861dda6..20b9088 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -337,11 +337,26 @@ static struct mtk_pcie_port 
> > *mtk_pcie_find_port(struct pci_bus *bus,
> >  {
> > struct mtk_pcie *pcie = bus->sysdata;
> > struct mtk_pcie_port *port;
> > +   struct pci_dev *dev;
> > +   struct pci_bus *pbus;
> >  
> > -   list_for_each_entry(port, >ports, list)
> > -   if (port->slot == PCI_SLOT(devfn))
> > +   list_for_each_entry(port, >ports, list) {
> > +   if (!bus->number && port->slot == PCI_SLOT(devfn))
> > return port;
> >  
> > +   if (bus->number) {
> > +   pbus = bus;
> > +
> > +   while (pbus->number) {
> > +   dev = pbus->self;
> > +   pbus = dev->bus;
> > +   }
> > +
> > +   if (port->slot == PCI_SLOT(dev->devfn))
> > +   return port;
> > +   }
> > +   }
> 
>   /*
>* Walk the bus hierarchy to get the devfn value
>* of the port in the root bus.
>*/
>   while (bus && bus->number) {
>   devfn = bus->self->devfn;
>   bus = bus->parent;
>   }
> 
>   list_for_each_entry(port, >ports, list) {
>   if (port->slot == PCI_SLOT(devfn))
>   return port;
> 
>   return NULL;
> 
> Would it work ? Maybe it is a little easier to parse.
> 

Thanks, this is much better.

> I think this can even be made easier by using struct device_node* as
> comparison (and store it in port->slot instead of the port number), I
> think that the pci_dev representing the port should have the right
> of_node associated with it by core code, so it is just a matter of
> finding the first pci_dev parent with an of_node set and compare it
> against port->slot (that should be converted to a struct device_node*).
> 
> This ought to be tested and written but I think that's doable.
> 

Thanks, I will do my homework and figure a way out through this
solution.
Currently port->slot is used in too much place to be removed, I guess I
need to added a new parameter in the port struct to store the of_node
for compare.
I'm not sure which way is better, anyway, let me try the new solution.

thanks.

> Lorenzo

Re: [PATCH v3 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622

[Honghui Zhang]

On Wed, 2018-07-18 at 10:49 +0100, Lorenzo Pieralisi wrote:
> On Wed, Jul 18, 2018 at 02:02:41PM +0800, Honghui Zhang wrote:
> 
> 
> 
> > > > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> > > > +{
> > > > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > > > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > > > +   struct mtk_pcie_port *port, *tmp;
> > > > +
> > > > +   if (!soc->pm_support)
> > > > +   return 0;
> > > > +
> > > > +   if (list_empty(>ports))
> > > > +   return 0;
> > > > +
> > > > +   if (dev->pm_domain) {
> > > > +   pm_runtime_enable(dev);
> > > > +   pm_runtime_get_sync(dev);
> > > > +   }
> > > 
> > > Are these runtime PM calls needed/abused here ?
> > > 
> > > Mind explaining the logic ?
> > > 
> > > There is certainly an asymmetry with the suspend callback which made me
> > > suspicious, I am pretty certain Rafael/Kevin/Ulf can help me clarify so
> > > that we can make progress with this patch.
> > > 
> > > Lorenzo
> > > 
> > Hi Lorenzo, thanks for your comments.
> > Sorry I don't get you.
> > I believe that in suspend callbacks the pm_runtime_put_sync and
> > pm_runtime_disable should be called to gated the CMOS for this module,
> > while the pm_rumtime_enable and pm_rumtime_get_sync should be called
> > in resume callback.

> That's why I CC'ed Rafael, Kevin and Ulf, to answer this question
> thoroughly, I am not sure it is needed and that's the right way
> of doing it in system suspend callbacks.
> 

hi, Rafael, Kevin and Ulf,

after reading of the power related documents in Documents/power/, I'm
still confused whether the runtime_pm callbacks should be called in
system suspend callbacks.

I believe that system suspend does not care about the device's CMOS
status. And the device's CMOS status is controlled by runtime pm.
That why I gated the CMOS through runtime pm in the system suspend
callbacks.

But I checked all existing system suspend callbacks and found there's no
runtime pm was executed in system suspend callbacks. Does that means
when system suspend, the system suspend framework does not care about
the power consume? Or does it gated each device's CMOS in somewhere
else?

Or should I just remove the runtime pm callbacks in the system suspend
flow?

Could someone kindly give me some comments?

Thanks in advance.

> > That's exactly this patch doing.
> > But the pm_rumtime_put_sync and pm_runtime_disable functions was wrapped
> > in the mtk_pcie_subsys_powerdown.
> 
> Ah, sorry, I missed that.
> 
> > I did not call mtk_pcie_subsys_powerup since it does not just wrapped
> > pm_rumtime related functions but also do the platform_resource_get,
> > devm_ioremap, and free_ck clock get which I do not needed in resume
> > callback.
> > 
> > Do you think it will be much clear if I abstract the
> > platform_resource_get, devm_ioremap functions from
> > mtk_pcie_subsys_powerup and put it to a new functions like
> > mtk_pcie_subsys_resource_get, and then we may call the
> > mtk_pcie_subsys_powerup in the resume function?
> 
> I think so but let's wait first for feedback on whether those
> runtime PM calls are needed in the first place.
> 
> Lorenzo

Re: [PATCH v3 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622

[Honghui Zhang]

On Wed, 2018-07-18 at 10:49 +0100, Lorenzo Pieralisi wrote:
> On Wed, Jul 18, 2018 at 02:02:41PM +0800, Honghui Zhang wrote:
> 
> 
> 
> > > > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> > > > +{
> > > > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > > > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > > > +   struct mtk_pcie_port *port, *tmp;
> > > > +
> > > > +   if (!soc->pm_support)
> > > > +   return 0;
> > > > +
> > > > +   if (list_empty(>ports))
> > > > +   return 0;
> > > > +
> > > > +   if (dev->pm_domain) {
> > > > +   pm_runtime_enable(dev);
> > > > +   pm_runtime_get_sync(dev);
> > > > +   }
> > > 
> > > Are these runtime PM calls needed/abused here ?
> > > 
> > > Mind explaining the logic ?
> > > 
> > > There is certainly an asymmetry with the suspend callback which made me
> > > suspicious, I am pretty certain Rafael/Kevin/Ulf can help me clarify so
> > > that we can make progress with this patch.
> > > 
> > > Lorenzo
> > > 
> > Hi Lorenzo, thanks for your comments.
> > Sorry I don't get you.
> > I believe that in suspend callbacks the pm_runtime_put_sync and
> > pm_runtime_disable should be called to gated the CMOS for this module,
> > while the pm_rumtime_enable and pm_rumtime_get_sync should be called
> > in resume callback.

> That's why I CC'ed Rafael, Kevin and Ulf, to answer this question
> thoroughly, I am not sure it is needed and that's the right way
> of doing it in system suspend callbacks.
> 

hi, Rafael, Kevin and Ulf,

after reading of the power related documents in Documents/power/, I'm
still confused whether the runtime_pm callbacks should be called in
system suspend callbacks.

I believe that system suspend does not care about the device's CMOS
status. And the device's CMOS status is controlled by runtime pm.
That why I gated the CMOS through runtime pm in the system suspend
callbacks.

But I checked all existing system suspend callbacks and found there's no
runtime pm was executed in system suspend callbacks. Does that means
when system suspend, the system suspend framework does not care about
the power consume? Or does it gated each device's CMOS in somewhere
else?

Or should I just remove the runtime pm callbacks in the system suspend
flow?

Could someone kindly give me some comments?

Thanks in advance.

> > That's exactly this patch doing.
> > But the pm_rumtime_put_sync and pm_runtime_disable functions was wrapped
> > in the mtk_pcie_subsys_powerdown.
> 
> Ah, sorry, I missed that.
> 
> > I did not call mtk_pcie_subsys_powerup since it does not just wrapped
> > pm_rumtime related functions but also do the platform_resource_get,
> > devm_ioremap, and free_ck clock get which I do not needed in resume
> > callback.
> > 
> > Do you think it will be much clear if I abstract the
> > platform_resource_get, devm_ioremap functions from
> > mtk_pcie_subsys_powerup and put it to a new functions like
> > mtk_pcie_subsys_resource_get, and then we may call the
> > mtk_pcie_subsys_powerup in the resume function?
> 
> I think so but let's wait first for feedback on whether those
> runtime PM calls are needed in the first place.
> 
> Lorenzo

Re: [PATCH] PCI: mediatek: Fix unchecked return value

[Honghui Zhang]

On Fri, 2018-07-20 at 10:01 -0500, Gustavo A. R. Silva wrote:
> Check return value of devm_pci_remap_iospace.
> 
> Notice that, currently, all instances of devm_pci_remap_iospace
> are being checked.
> 
> Addresses-Coverity-ID: 1471965 ("Unchecked return value")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Hi, Gustavo, thanks for your help.

Acked-by: Honghui Zhang 

> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index 861dda6..1477939 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -1109,7 +1109,9 @@ static int mtk_pcie_request_resources(struct mtk_pcie 
> *pcie)
>   if (err < 0)
>   return err;
>  
> - devm_pci_remap_iospace(dev, >pio, pcie->io.start);
> + err = devm_pci_remap_iospace(dev, >pio, pcie->io.start);
> + if (err)
> + return err;
>  
>   return 0;
>  }

Re: [PATCH] PCI: mediatek: Fix unchecked return value

[Honghui Zhang]

On Fri, 2018-07-20 at 10:01 -0500, Gustavo A. R. Silva wrote:
> Check return value of devm_pci_remap_iospace.
> 
> Notice that, currently, all instances of devm_pci_remap_iospace
> are being checked.
> 
> Addresses-Coverity-ID: 1471965 ("Unchecked return value")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Hi, Gustavo, thanks for your help.

Acked-by: Honghui Zhang 

> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index 861dda6..1477939 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -1109,7 +1109,9 @@ static int mtk_pcie_request_resources(struct mtk_pcie 
> *pcie)
>   if (err < 0)
>   return err;
>  
> - devm_pci_remap_iospace(dev, >pio, pcie->io.start);
> + err = devm_pci_remap_iospace(dev, >pio, pcie->io.start);
> + if (err)
> + return err;
>  
>   return 0;
>  }

Re: [PATCH v3 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622

[Honghui Zhang]

On Tue, 2018-07-17 at 18:15 +0100, Lorenzo Pieralisi wrote:
> [+Rafael, Kevin, Ulf]
> 
> On Mon, Jul 02, 2018 at 03:57:43PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The MTCMOS of PCIe Host for MT2712 and MT7622 will be off when system
> > suspend, and all the internal control register will be reset after system
> > resume. The PCIe link should be re-established and the related control
> > register values should be re-set after system resume.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 67 
> > ++
> >  1 file changed, 67 insertions(+)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 86918d4..175d7b6 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -134,12 +134,14 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > + * @pm_support: whether the host's MTCMOS will be off when suspend
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > +   bool pm_support;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1197,12 +1199,75 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >  
> > +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   if (list_empty(>ports))
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->pipe_ck);
> > +   clk_disable_unprepare(port->obff_ck);
> > +   clk_disable_unprepare(port->axi_ck);
> > +   clk_disable_unprepare(port->aux_ck);
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   phy_exit(port->phy);
> > +   }
> > +
> > +   mtk_pcie_subsys_powerdown(pcie);
> > +
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port, *tmp;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   if (list_empty(>ports))
> > +   return 0;
> > +
> > +   if (dev->pm_domain) {
> > +   pm_runtime_enable(dev);
> > +   pm_runtime_get_sync(dev);
> > +   }
> 
> Are these runtime PM calls needed/abused here ?
> 
> Mind explaining the logic ?
> 
> There is certainly an asymmetry with the suspend callback which made me
> suspicious, I am pretty certain Rafael/Kevin/Ulf can help me clarify so
> that we can make progress with this patch.
> 
> Lorenzo
> 
Hi Lorenzo, thanks for your comments.
Sorry I don't get you.
I believe that in suspend callbacks the pm_runtime_put_sync and
pm_runtime_disable should be called to gated the CMOS for this module,
while the pm_rumtime_enable and pm_rumtime_get_sync should be called in
resume callback.

That's exactly this patch doing.
But the pm_rumtime_put_sync and pm_runtime_disable functions was wrapped
in the mtk_pcie_subsys_powerdown.

I did not call mtk_pcie_subsys_powerup since it does not just wrapped
pm_rumtime related functions but also do the platform_resource_get,
devm_ioremap, and free_ck clock get which I do not needed in resume
callback.

Do you think it will be much clear if I abstract the
platform_resource_get, devm_ioremap functions from
mtk_pcie_subsys_powerup and put it to a new functions like
mtk_pcie_subsys_resource_get, and then we may call the
mtk_pcie_subsys_powerup in the resume function?

thanks
> > +
> > +   clk_prepare_enab

Re: [PATCH v3 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622

[Honghui Zhang]

On Tue, 2018-07-17 at 18:15 +0100, Lorenzo Pieralisi wrote:
> [+Rafael, Kevin, Ulf]
> 
> On Mon, Jul 02, 2018 at 03:57:43PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The MTCMOS of PCIe Host for MT2712 and MT7622 will be off when system
> > suspend, and all the internal control register will be reset after system
> > resume. The PCIe link should be re-established and the related control
> > register values should be re-set after system resume.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 67 
> > ++
> >  1 file changed, 67 insertions(+)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 86918d4..175d7b6 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -134,12 +134,14 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > + * @pm_support: whether the host's MTCMOS will be off when suspend
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > +   bool pm_support;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1197,12 +1199,75 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >  
> > +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   if (list_empty(>ports))
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->pipe_ck);
> > +   clk_disable_unprepare(port->obff_ck);
> > +   clk_disable_unprepare(port->axi_ck);
> > +   clk_disable_unprepare(port->aux_ck);
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   phy_exit(port->phy);
> > +   }
> > +
> > +   mtk_pcie_subsys_powerdown(pcie);
> > +
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port, *tmp;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   if (list_empty(>ports))
> > +   return 0;
> > +
> > +   if (dev->pm_domain) {
> > +   pm_runtime_enable(dev);
> > +   pm_runtime_get_sync(dev);
> > +   }
> 
> Are these runtime PM calls needed/abused here ?
> 
> Mind explaining the logic ?
> 
> There is certainly an asymmetry with the suspend callback which made me
> suspicious, I am pretty certain Rafael/Kevin/Ulf can help me clarify so
> that we can make progress with this patch.
> 
> Lorenzo
> 
Hi Lorenzo, thanks for your comments.
Sorry I don't get you.
I believe that in suspend callbacks the pm_runtime_put_sync and
pm_runtime_disable should be called to gated the CMOS for this module,
while the pm_rumtime_enable and pm_rumtime_get_sync should be called in
resume callback.

That's exactly this patch doing.
But the pm_rumtime_put_sync and pm_runtime_disable functions was wrapped
in the mtk_pcie_subsys_powerdown.

I did not call mtk_pcie_subsys_powerup since it does not just wrapped
pm_rumtime related functions but also do the platform_resource_get,
devm_ioremap, and free_ck clock get which I do not needed in resume
callback.

Do you think it will be much clear if I abstract the
platform_resource_get, devm_ioremap functions from
mtk_pcie_subsys_powerup and put it to a new functions like
mtk_pcie_subsys_resource_get, and then we may call the
mtk_pcie_subsys_powerup in the resume function?

thanks
> > +
> > +   clk_prepare_enab

Re: [PATCH v3 0/4] PCI: mediatek: fixup find_port, enable_msi and add pm, module support

[Honghui Zhang]

Hi, Bjorn, Lorenzo,

could you kindly take a look at this serial?

thanks.

On Mon, 2018-07-02 at 15:57 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> This patchset includes misc patchs:
> 
> The first patch fixup the mtk_pcie_find_port logical which will cause system
> could not touch the EP's configuration space which was connected to PCIe slot 
> 1.
> 
> The second patch fixup the enable msi logical, the operation to enable msi
> should be after system clock is enabled. The function of 
> mtk_pcie_startup_port_v2's
> define location is re-arranged to avoid mtk_pcie_enable_msi's forward 
> declaration.
> And call mtk_pcie_enable_msi in mtk_pcie_startup_port_v2 since the clock was 
> all
> enabled at that time.
> 
> The third patch was rebased and refactor of the v4 patch[1], changes are:
>  -Add PM support for MT7622.
>  -Using mtk_pcie_enable_port to re-establish the link when resumed.
>  -Rebase on the previous two patches.
> 
> The fourth patch add loadable kernel module support.
> 
> Some of those patches was already reviewed-by Ryder Lee 
> ,
> so I just add the Reviewed-by tags in those patches.
> 
> [1] https://patchwork.kernel.org/patch/10479079
> 
> Change since v2:
>  - Fix the list_for_each_entry_safe parameter error.
>  - Add Ryder's Acked-by flag.
> 
> Change since v1:
>  - A bit of code refact of the first patch suggested by Andy Shevchenko, and
>commit message updated.
>  - Using __maybe_unused.
>  - Remove the redundant list_empty check of the fourth patch.
> 
> Honghui Zhang (4):
>   PCI: mediatek: fixup mtk_pcie_find_port logical
>   PCI: mediatek: enable msi after clock enabled
>   PCI: mediatek: Add system pm support for MT2712 and MT7622
>   PCI: mediatek: Add loadable kernel module support
> 
>  drivers/pci/controller/Kconfig |   2 +-
>  drivers/pci/controller/pcie-mediatek.c | 289 
> -
>  2 files changed, 213 insertions(+), 78 deletions(-)
> 

Re: [PATCH v3 0/4] PCI: mediatek: fixup find_port, enable_msi and add pm, module support

[Honghui Zhang]

Hi, Bjorn, Lorenzo,

could you kindly take a look at this serial?

thanks.

On Mon, 2018-07-02 at 15:57 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> This patchset includes misc patchs:
> 
> The first patch fixup the mtk_pcie_find_port logical which will cause system
> could not touch the EP's configuration space which was connected to PCIe slot 
> 1.
> 
> The second patch fixup the enable msi logical, the operation to enable msi
> should be after system clock is enabled. The function of 
> mtk_pcie_startup_port_v2's
> define location is re-arranged to avoid mtk_pcie_enable_msi's forward 
> declaration.
> And call mtk_pcie_enable_msi in mtk_pcie_startup_port_v2 since the clock was 
> all
> enabled at that time.
> 
> The third patch was rebased and refactor of the v4 patch[1], changes are:
>  -Add PM support for MT7622.
>  -Using mtk_pcie_enable_port to re-establish the link when resumed.
>  -Rebase on the previous two patches.
> 
> The fourth patch add loadable kernel module support.
> 
> Some of those patches was already reviewed-by Ryder Lee 
> ,
> so I just add the Reviewed-by tags in those patches.
> 
> [1] https://patchwork.kernel.org/patch/10479079
> 
> Change since v2:
>  - Fix the list_for_each_entry_safe parameter error.
>  - Add Ryder's Acked-by flag.
> 
> Change since v1:
>  - A bit of code refact of the first patch suggested by Andy Shevchenko, and
>commit message updated.
>  - Using __maybe_unused.
>  - Remove the redundant list_empty check of the fourth patch.
> 
> Honghui Zhang (4):
>   PCI: mediatek: fixup mtk_pcie_find_port logical
>   PCI: mediatek: enable msi after clock enabled
>   PCI: mediatek: Add system pm support for MT2712 and MT7622
>   PCI: mediatek: Add loadable kernel module support
> 
>  drivers/pci/controller/Kconfig |   2 +-
>  drivers/pci/controller/pcie-mediatek.c | 289 
> -
>  2 files changed, 213 insertions(+), 78 deletions(-)
> 

Re: [PATCH 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical

[Honghui Zhang]

On Thu, 2018-06-28 at 08:07 -0500, Bjorn Helgaas wrote:
> On Wed, Jun 27, 2018 at 05:21:35PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Mediatek's host controller have two slots, each have it's own control
> > registers. The host driver need to identify which slot was connected
> > in order to access the device's configuration space. There's problem
> > for current host driver to find out which slot was connected to for
> > a given EP device.
> 
>   The Mediatek host controller has two slots, each with its own control
>   registers.

Thanks, I will update it in the next version.

> 
> > Assuming each slot have connect with one EP device as below:
> > 
> > host bridge
> >   bus 0 --> __|___
> >|  |
> >|  |
> >  slot 0 slot 1
> >   bus 1 -->|bus 2 --> |
> >|  |
> >  EP 0   EP 1
> > 
> > While PCI emulation, system software will scan all the PCI device
> 
> s/While PCI emulation/During PCI enumeration/

Thanks, will update this.

> 
> > starting from devfn 0. So it will get the proper port for slot0 and
> > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > for port0's slot value. So the host driver should not using EP's devfn
> > but the slot's devfn(the slot which EP was connected to) for match.
> > 
> > This patch fix the mtk_pcie_find_port's logical by using the slot's
> > devfn for match.
> > 
> > Signed-off-by: Honghui Zhang 
> > Reviewed-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 17 +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 0baabe3..9cf7ecf 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -337,10 +337,23 @@ static struct mtk_pcie_port 
> > *mtk_pcie_find_port(struct pci_bus *bus,
> >  {
> > struct mtk_pcie *pcie = bus->sysdata;
> > struct mtk_pcie_port *port;
> > +   struct pci_dev *dev;
> > +   struct pci_bus *pbus;
> >  
> > -   list_for_each_entry(port, >ports, list)
> > -   if (port->slot == PCI_SLOT(devfn))
> > +   list_for_each_entry(port, >ports, list) {
> 
> mvebu has the identical hardware structure but uses an array instead
> of a list:
> 
>   num = of_get_available_child_count(np);
>   pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL);
>   for_each_available_child_of_node(np, child) {
> struct mvebu_pcie_port *port = >ports[i];
> mvebu_pcie_parse_port(pcie, port, child);
>   }
> 
> It would be nice if mvebu and mtk used the same strategy so the code
> looks the same.

Seems there's different approach existing in current host controller
driver for this, tegra PCIe is using list too.
I guess I can change it to using array after this problem is fixed if
you have strong opinion here.

> 
> > +   if (bus->number == 0 && port->slot == PCI_SLOT(devfn)) {
> 
> Is the root bus number fixed at 0 or is it programmable?  Many drivers
> do something like this:

The primary bus number is fixed at 0.(technically speaking, hardware
will capture the very first value of primary bus number, once it's been
captured, change the value in configuration space will not take effort. 

But the hardware default value is 0, the hardware will not response to
other values except 0 at the first time. And the only way to touch the
value in it's configuration space is using primary bus number 0. So it
could be taken as fixed at 0.)

> 
>   if (bus->number == pcie->root_bus_nr)
> 
> to handle the case of the root bus number being programmable.
> 
> > return port;
> > +   } else if (bus->number != 0) {
> > +   pbus = bus;
> > +   do {
> > +   dev = pbus->self;
> > +   if (port->slot == PCI_SLOT(dev->devfn))
> > +   return port;
> > +
> > +   pbus = dev->bus;
> > +   } while (dev->bus->number != 0);
> 
> You should not need to search up the tree of dev->bus->self.
> 
> mvebu_

Re: [PATCH 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical

[Honghui Zhang]

On Thu, 2018-06-28 at 08:07 -0500, Bjorn Helgaas wrote:
> On Wed, Jun 27, 2018 at 05:21:35PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Mediatek's host controller have two slots, each have it's own control
> > registers. The host driver need to identify which slot was connected
> > in order to access the device's configuration space. There's problem
> > for current host driver to find out which slot was connected to for
> > a given EP device.
> 
>   The Mediatek host controller has two slots, each with its own control
>   registers.

Thanks, I will update it in the next version.

> 
> > Assuming each slot have connect with one EP device as below:
> > 
> > host bridge
> >   bus 0 --> __|___
> >|  |
> >|  |
> >  slot 0 slot 1
> >   bus 1 -->|bus 2 --> |
> >|  |
> >  EP 0   EP 1
> > 
> > While PCI emulation, system software will scan all the PCI device
> 
> s/While PCI emulation/During PCI enumeration/

Thanks, will update this.

> 
> > starting from devfn 0. So it will get the proper port for slot0 and
> > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > for port0's slot value. So the host driver should not using EP's devfn
> > but the slot's devfn(the slot which EP was connected to) for match.
> > 
> > This patch fix the mtk_pcie_find_port's logical by using the slot's
> > devfn for match.
> > 
> > Signed-off-by: Honghui Zhang 
> > Reviewed-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 17 +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index 0baabe3..9cf7ecf 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -337,10 +337,23 @@ static struct mtk_pcie_port 
> > *mtk_pcie_find_port(struct pci_bus *bus,
> >  {
> > struct mtk_pcie *pcie = bus->sysdata;
> > struct mtk_pcie_port *port;
> > +   struct pci_dev *dev;
> > +   struct pci_bus *pbus;
> >  
> > -   list_for_each_entry(port, >ports, list)
> > -   if (port->slot == PCI_SLOT(devfn))
> > +   list_for_each_entry(port, >ports, list) {
> 
> mvebu has the identical hardware structure but uses an array instead
> of a list:
> 
>   num = of_get_available_child_count(np);
>   pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL);
>   for_each_available_child_of_node(np, child) {
> struct mvebu_pcie_port *port = >ports[i];
> mvebu_pcie_parse_port(pcie, port, child);
>   }
> 
> It would be nice if mvebu and mtk used the same strategy so the code
> looks the same.

Seems there's different approach existing in current host controller
driver for this, tegra PCIe is using list too.
I guess I can change it to using array after this problem is fixed if
you have strong opinion here.

> 
> > +   if (bus->number == 0 && port->slot == PCI_SLOT(devfn)) {
> 
> Is the root bus number fixed at 0 or is it programmable?  Many drivers
> do something like this:

The primary bus number is fixed at 0.(technically speaking, hardware
will capture the very first value of primary bus number, once it's been
captured, change the value in configuration space will not take effort. 

But the hardware default value is 0, the hardware will not response to
other values except 0 at the first time. And the only way to touch the
value in it's configuration space is using primary bus number 0. So it
could be taken as fixed at 0.)

> 
>   if (bus->number == pcie->root_bus_nr)
> 
> to handle the case of the root bus number being programmable.
> 
> > return port;
> > +   } else if (bus->number != 0) {
> > +   pbus = bus;
> > +   do {
> > +   dev = pbus->self;
> > +   if (port->slot == PCI_SLOT(dev->devfn))
> > +   return port;
> > +
> > +   pbus = dev->bus;
> > +   } while (dev->bus->number != 0);
> 
> You should not need to search up the tree of dev->bus->self.
> 
> mvebu_

Re: [PATCH 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622

[Honghui Zhang]

On Wed, 2018-06-27 at 19:45 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 12:21 PM,   wrote:
> > From: Honghui Zhang 
> >
> > The MTCMOS of PCIe Host for MT2712 and MT7622 will be off when system
> > suspend, and all the internal control register will be reset after system
> > resume. The PCIe link should be re-established and the related control
> > register values should be re-set after system resume.
> 
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> 
> > +   bool pm_support;
> 
> Hmm... Do you really need this flag? Can't runtime PM API tell you this?

This host driver is both for MT2712, MT7622 and MT7623, but MT7623 do
not this this patch.
I only add this flag to identify whether we need to do the PM operation
for this SoC since I do not want to touch anything for MT7623.
 
> 
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node 
> > *node);
> > @@ -1195,12 +1197,76 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_pcie_suspend_noirq(struct device *dev)
> 
> Perhaps __maybe_unused?

Ok, I'm a bit confused about this, if there's some discussion about
this, do you have the link of those discussion and kindly point put it
in this thread? Or I guess I can change this back to __maybe_unused if
there's no other comments about this.

> 
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> 
> > +   if (list_empty(>ports))
> > +   return 0;
> 
> So, if the list is empty you are not suspending for the host?
> 

if the list was empty then it indicate that all the PCIe slot was not
connected with any EP device, and all the resource have been release in
probe time. So the host driver does not need to save or restore
anything.

> 
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->pipe_ck);
> > +   clk_disable_unprepare(port->obff_ck);
> > +   clk_disable_unprepare(port->axi_ck);
> > +   clk_disable_unprepare(port->aux_ck);
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   phy_exit(port->phy);
> > +   }
> > +
> > +   mtk_pcie_subsys_powerdown(pcie);
> > +
> > +   return 0;
> > +}
> > +
> > +static int mtk_pcie_resume_noirq(struct device *dev)
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> 
> > +   if (list_empty(>ports))
> > +   return 0;
> 
> No runtime PM for this case?
> (It seems now I understand why in previous patch you have a similar check)
> 
I guess host driver does not need to resume anything if there's no EP
device was connected.

> > +
> > +   if (dev->pm_domain) {
> > +   pm_runtime_enable(dev);
> > +   pm_runtime_get_sync(dev);
> > +   }
> > +
> > +   clk_prepare_enable(pcie->free_ck);
> > +
> > +   list_for_each_entry(port, >ports, list)
> > +   mtk_pcie_enable_port(port);
> > +
> 
> > +   if (list_empty(>ports))
> 
> Hmm... How it would be true if you already bailed out above on the
> same condition?

Assuming that there's EP device connected before suspend, and the EP was
removed from the link while system suspend. It means that when enter
this function the list is not empty, but after the function of
mtk_pcie_enable_port was called, host driver found there's no EP device
was connected anymore, it will free this list and some other resources
in mtk_pcie_enable_port,(after mtk_pcie_enable_port was called, the list
is empty in this scenario) but leave the subsys power along, I guess we
need to take care of this scenario.
> 
> > +   mtk_pcie_subsys_powerdown(pcie);
> > +
> > +   return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops mtk_pcie_pm_ops =

Re: [PATCH 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622

[Honghui Zhang]

On Wed, 2018-06-27 at 19:45 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 12:21 PM,   wrote:
> > From: Honghui Zhang 
> >
> > The MTCMOS of PCIe Host for MT2712 and MT7622 will be off when system
> > suspend, and all the internal control register will be reset after system
> > resume. The PCIe link should be re-established and the related control
> > register values should be re-set after system resume.
> 
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> 
> > +   bool pm_support;
> 
> Hmm... Do you really need this flag? Can't runtime PM API tell you this?

This host driver is both for MT2712, MT7622 and MT7623, but MT7623 do
not this this patch.
I only add this flag to identify whether we need to do the PM operation
for this SoC since I do not want to touch anything for MT7623.
 
> 
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node 
> > *node);
> > @@ -1195,12 +1197,76 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_pcie_suspend_noirq(struct device *dev)
> 
> Perhaps __maybe_unused?

Ok, I'm a bit confused about this, if there's some discussion about
this, do you have the link of those discussion and kindly point put it
in this thread? Or I guess I can change this back to __maybe_unused if
there's no other comments about this.

> 
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> 
> > +   if (list_empty(>ports))
> > +   return 0;
> 
> So, if the list is empty you are not suspending for the host?
> 

if the list was empty then it indicate that all the PCIe slot was not
connected with any EP device, and all the resource have been release in
probe time. So the host driver does not need to save or restore
anything.

> 
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->pipe_ck);
> > +   clk_disable_unprepare(port->obff_ck);
> > +   clk_disable_unprepare(port->axi_ck);
> > +   clk_disable_unprepare(port->aux_ck);
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   phy_exit(port->phy);
> > +   }
> > +
> > +   mtk_pcie_subsys_powerdown(pcie);
> > +
> > +   return 0;
> > +}
> > +
> > +static int mtk_pcie_resume_noirq(struct device *dev)
> > +{
> > +   struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > +   const struct mtk_pcie_soc *soc = pcie->soc;
> > +   struct mtk_pcie_port *port;
> > +
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> 
> > +   if (list_empty(>ports))
> > +   return 0;
> 
> No runtime PM for this case?
> (It seems now I understand why in previous patch you have a similar check)
> 
I guess host driver does not need to resume anything if there's no EP
device was connected.

> > +
> > +   if (dev->pm_domain) {
> > +   pm_runtime_enable(dev);
> > +   pm_runtime_get_sync(dev);
> > +   }
> > +
> > +   clk_prepare_enable(pcie->free_ck);
> > +
> > +   list_for_each_entry(port, >ports, list)
> > +   mtk_pcie_enable_port(port);
> > +
> 
> > +   if (list_empty(>ports))
> 
> Hmm... How it would be true if you already bailed out above on the
> same condition?

Assuming that there's EP device connected before suspend, and the EP was
removed from the link while system suspend. It means that when enter
this function the list is not empty, but after the function of
mtk_pcie_enable_port was called, host driver found there's no EP device
was connected anymore, it will free this list and some other resources
in mtk_pcie_enable_port,(after mtk_pcie_enable_port was called, the list
is empty in this scenario) but leave the subsys power along, I guess we
need to take care of this scenario.
> 
> > +   mtk_pcie_subsys_powerdown(pcie);
> > +
> > +   return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops mtk_pcie_pm_ops =

Re: [PATCH 4/4] PCI: mediatek: Add loadable kernel module support

[Honghui Zhang]

On Wed, 2018-06-27 at 19:39 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 12:21 PM,   wrote:
> > From: Honghui Zhang 
> >
> > Implement remove callback function for Mediatek PCIe driver to add
> > loadable kernel module support.
> 
> > +static void mtk_pcie_irq_teardown(struct mtk_pcie *pcie)
> > +{
> > +   struct mtk_pcie_port *port, *tmp;
> > +
> 
> > +   if (list_empty(>ports))
> > +   return;
> 
> This is redundant.

Yeah, you are right, I will remove it.

> 
> > +
> > +   list_for_each_entry_safe(port, tmp, >ports, list) {
> > +   irq_set_chained_handler_and_data(port->irq, NULL, NULL);
> > +
> > +   if (port->irq_domain)
> > +   irq_domain_remove(port->irq_domain);
> > +
> > +   if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > +   if (port->msi_domain)
> > +   irq_domain_remove(port->msi_domain);
> > +   if (port->inner_domain)
> > +   irq_domain_remove(port->inner_domain);
> > +   }
> > +
> > +   irq_dispose_mapping(port->irq);
> > +   }
> > +}
> 
> > +static void mtk_pcie_free_resources(struct mtk_pcie *pcie)
> > +{
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +   struct list_head *windows = >windows;
> > +
> > +   pci_unmap_iospace(>pio);
> > +   pci_free_resource_list(windows);
> > +}
> > +
> > +static int mtk_pcie_remove(struct platform_device *pdev)
> > +{
> > +   struct mtk_pcie *pcie = platform_get_drvdata(pdev);
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +
> > +   pci_stop_root_bus(host->bus);
> > +   pci_remove_root_bus(host->bus);
> > +   mtk_pcie_free_resources(pcie);
> > +
> > +   mtk_pcie_irq_teardown(pcie);
> > +
> 
> > +   if (!list_empty(>ports))
> 
> I think this is also not needed. Do you put runtime PM by the way?

Yes, it's could be removed.
the pm was putted in mtk_pcie_put_resources which will call
mtk_pcie_subsys_powerdown, and the pm was putted in that function.

thanks.

> 
> > +   mtk_pcie_put_resources(pcie);
> > +
> > +   return 0;
> > +}
> 

Re: [PATCH 4/4] PCI: mediatek: Add loadable kernel module support

[Honghui Zhang]

On Wed, 2018-06-27 at 19:39 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 12:21 PM,   wrote:
> > From: Honghui Zhang 
> >
> > Implement remove callback function for Mediatek PCIe driver to add
> > loadable kernel module support.
> 
> > +static void mtk_pcie_irq_teardown(struct mtk_pcie *pcie)
> > +{
> > +   struct mtk_pcie_port *port, *tmp;
> > +
> 
> > +   if (list_empty(>ports))
> > +   return;
> 
> This is redundant.

Yeah, you are right, I will remove it.

> 
> > +
> > +   list_for_each_entry_safe(port, tmp, >ports, list) {
> > +   irq_set_chained_handler_and_data(port->irq, NULL, NULL);
> > +
> > +   if (port->irq_domain)
> > +   irq_domain_remove(port->irq_domain);
> > +
> > +   if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > +   if (port->msi_domain)
> > +   irq_domain_remove(port->msi_domain);
> > +   if (port->inner_domain)
> > +   irq_domain_remove(port->inner_domain);
> > +   }
> > +
> > +   irq_dispose_mapping(port->irq);
> > +   }
> > +}
> 
> > +static void mtk_pcie_free_resources(struct mtk_pcie *pcie)
> > +{
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +   struct list_head *windows = >windows;
> > +
> > +   pci_unmap_iospace(>pio);
> > +   pci_free_resource_list(windows);
> > +}
> > +
> > +static int mtk_pcie_remove(struct platform_device *pdev)
> > +{
> > +   struct mtk_pcie *pcie = platform_get_drvdata(pdev);
> > +   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> > +
> > +   pci_stop_root_bus(host->bus);
> > +   pci_remove_root_bus(host->bus);
> > +   mtk_pcie_free_resources(pcie);
> > +
> > +   mtk_pcie_irq_teardown(pcie);
> > +
> 
> > +   if (!list_empty(>ports))
> 
> I think this is also not needed. Do you put runtime PM by the way?

Yes, it's could be removed.
the pm was putted in mtk_pcie_put_resources which will call
mtk_pcie_subsys_powerdown, and the pm was putted in that function.

thanks.

> 
> > +   mtk_pcie_put_resources(pcie);
> > +
> > +   return 0;
> > +}
> 

Re: [PATCH 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical

[Honghui Zhang]

On Wed, 2018-06-27 at 19:35 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 12:21 PM,   wrote:
> > From: Honghui Zhang 
> >
> > Mediatek's host controller have two slots, each have it's own control
> > registers. The host driver need to identify which slot was connected
> > in order to access the device's configuration space. There's problem
> > for current host driver to find out which slot was connected to for
> > a given EP device.
> >
> > Assuming each slot have connect with one EP device as below:
> >
> > host bridge
> >   bus 0 --> __|___
> >|  |
> >|  |
> >  slot 0 slot 1
> >   bus 1 -->|bus 2 --> |
> >|  |
> >  EP 0   EP 1
> >
> > While PCI emulation, system software will scan all the PCI device
> > starting from devfn 0. So it will get the proper port for slot0 and
> > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > for port0's slot value. So the host driver should not using EP's devfn
> > but the slot's devfn(the slot which EP was connected to) for match.
> >
> > This patch fix the mtk_pcie_find_port's logical by using the slot's
> > devfn for match.
> 
> 
> > +   list_for_each_entry(port, >ports, list) {
> > +   if (bus->number == 0 && port->slot == PCI_SLOT(devfn)) {
> > return port;
> > +   } else if (bus->number != 0) {
> 
> You can do it like (no need 'else')
> 
> if (...)
>  return ...;
> if (bus->number) {
>  ...
> }
> 
> > +   pbus = bus;
> > +   do {
> > +   dev = pbus->self;
> > +   if (port->slot == PCI_SLOT(dev->devfn))
> > +   return port;
> > +
> > +   pbus = dev->bus;
> > +   } while (dev->bus->number != 0);
> 
> This can be rewritten like
> 
> pbus = bus;
> while (pbus->number) {
>  dev = ...;
>  ...
>  pbus = dev->bus;
> }
> 
> and no need for if (bus->number) anymore.
> 

Hi, Andy, thanks very much for your advise, I will change it in the next
version.

thanks.
> > +   }
> > +   }
> >
> > return NULL;
> >  }
> > --
> > 2.6.4
> >
> 
> 
> 

Re: [PATCH 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical

[Honghui Zhang]

On Wed, 2018-06-27 at 19:35 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 12:21 PM,   wrote:
> > From: Honghui Zhang 
> >
> > Mediatek's host controller have two slots, each have it's own control
> > registers. The host driver need to identify which slot was connected
> > in order to access the device's configuration space. There's problem
> > for current host driver to find out which slot was connected to for
> > a given EP device.
> >
> > Assuming each slot have connect with one EP device as below:
> >
> > host bridge
> >   bus 0 --> __|___
> >|  |
> >|  |
> >  slot 0 slot 1
> >   bus 1 -->|bus 2 --> |
> >|  |
> >  EP 0   EP 1
> >
> > While PCI emulation, system software will scan all the PCI device
> > starting from devfn 0. So it will get the proper port for slot0 and
> > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > for port0's slot value. So the host driver should not using EP's devfn
> > but the slot's devfn(the slot which EP was connected to) for match.
> >
> > This patch fix the mtk_pcie_find_port's logical by using the slot's
> > devfn for match.
> 
> 
> > +   list_for_each_entry(port, >ports, list) {
> > +   if (bus->number == 0 && port->slot == PCI_SLOT(devfn)) {
> > return port;
> > +   } else if (bus->number != 0) {
> 
> You can do it like (no need 'else')
> 
> if (...)
>  return ...;
> if (bus->number) {
>  ...
> }
> 
> > +   pbus = bus;
> > +   do {
> > +   dev = pbus->self;
> > +   if (port->slot == PCI_SLOT(dev->devfn))
> > +   return port;
> > +
> > +   pbus = dev->bus;
> > +   } while (dev->bus->number != 0);
> 
> This can be rewritten like
> 
> pbus = bus;
> while (pbus->number) {
>  dev = ...;
>  ...
>  pbus = dev->bus;
> }
> 
> and no need for if (bus->number) anymore.
> 

Hi, Andy, thanks very much for your advise, I will change it in the next
version.

thanks.
> > +   }
> > +   }
> >
> > return NULL;
> >  }
> > --
> > 2.6.4
> >
> 
> 
> 

Re: [PATCH v3] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Fri, 2018-06-01 at 13:52 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 1:49 PM, Honghui Zhang
>  wrote:
> > On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> >> On Fri, Jun 1, 2018 at 6:04 AM,   wrote:
> >> > From: Honghui Zhang 
> >>
> >> > +#ifdef CONFIG_PM_SLEEP
> >> > +static int mtk_pcie_suspend_noirq(struct device *dev)
> >>
> >> __maybe_unused
> >>
> >
> > Hi, Andy, thanks for your review.
> > Bjorn had point this out that at:
> > https://www.spinics.net/lists/arm-kernel/msg656774.html
> 
> Nice, one more maintainer with strong opinion here.
> 
> Arnd, that's what I mentioned as a split in opinions earlier.
> Any new developer or even existing contributor would be now really
> confusing since maintainers asked for two different approaches on the
> same matter.
> 

Hi, Arnd, Do you have any comments about this patch? Sorry I missed the
previous discussion about which should be used for this approach.

thanks.

Re: [PATCH v3] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Fri, 2018-06-01 at 13:52 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 1:49 PM, Honghui Zhang
>  wrote:
> > On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> >> On Fri, Jun 1, 2018 at 6:04 AM,   wrote:
> >> > From: Honghui Zhang 
> >>
> >> > +#ifdef CONFIG_PM_SLEEP
> >> > +static int mtk_pcie_suspend_noirq(struct device *dev)
> >>
> >> __maybe_unused
> >>
> >
> > Hi, Andy, thanks for your review.
> > Bjorn had point this out that at:
> > https://www.spinics.net/lists/arm-kernel/msg656774.html
> 
> Nice, one more maintainer with strong opinion here.
> 
> Arnd, that's what I mentioned as a split in opinions earlier.
> Any new developer or even existing contributor would be now really
> confusing since maintainers asked for two different approaches on the
> same matter.
> 

Hi, Arnd, Do you have any comments about this patch? Sorry I missed the
previous discussion about which should be used for this approach.

thanks.

Re: [PATCH v3] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 6:04 AM,   wrote:
> > From: Honghui Zhang 
> 
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_pcie_suspend_noirq(struct device *dev)
> 
> __maybe_unused
> 

Hi, Andy, thanks for your review.
Bjorn had point this out that at:
https://www.spinics.net/lists/arm-kernel/msg656774.html

So __maybe_unused is not really needed.

thanks

Re: [PATCH v3] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 6:04 AM,   wrote:
> > From: Honghui Zhang 
> 
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_pcie_suspend_noirq(struct device *dev)
> 
> __maybe_unused
> 

Hi, Andy, thanks for your review.
Bjorn had point this out that at:
https://www.spinics.net/lists/arm-kernel/msg656774.html

So __maybe_unused is not really needed.

thanks

Re: [PATCH] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Wed, 2018-05-30 at 23:20 -0500, Bjorn Helgaas wrote:
> On Wed, May 30, 2018 at 10:35:36AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> > the internel control register will be reset after system resume. The PCIe
> > link should be re-established and the related control register values should
> > be re-set after system resume.
> > 
> > Signed-off-by: Honghui Zhang 
> > CC: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 82 
> > 
> >  1 file changed, 82 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index dabf1086..60f98d92 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -132,12 +132,14 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > + * @pm_support: whether the host's MTCMOS will be off when suspend
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > +   bool pm_support;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >  
> > +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> > +{
> > +   struct platform_device *pdev;
> > +   struct mtk_pcie *pcie;
> > +   struct mtk_pcie_port *port;
> > +   const struct mtk_pcie_soc *soc;
> > +
> > +   pdev = to_platform_device(dev);
> > +   pcie = platform_get_drvdata(pdev);
> > +   soc = pcie->soc;
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> 
> I don't really like the __maybe_unused annotations.  Looking at the
> other users of SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, I think a small majority
> of them wrap the function definitions in #ifdef CONFIG_PM_SLEEP
> instead of using __maybe_unused.  That's also a bit ugly, but has the
> advantage of truly omitting the definitions when they're not needed.

Ok, I will follow your advise in the next version.

thanks.

Re: [PATCH] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Wed, 2018-05-30 at 23:20 -0500, Bjorn Helgaas wrote:
> On Wed, May 30, 2018 at 10:35:36AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> > the internel control register will be reset after system resume. The PCIe
> > link should be re-established and the related control register values should
> > be re-set after system resume.
> > 
> > Signed-off-by: Honghui Zhang 
> > CC: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 82 
> > 
> >  1 file changed, 82 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index dabf1086..60f98d92 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -132,12 +132,14 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > + * @pm_support: whether the host's MTCMOS will be off when suspend
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > +   bool pm_support;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >  
> > +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> > +{
> > +   struct platform_device *pdev;
> > +   struct mtk_pcie *pcie;
> > +   struct mtk_pcie_port *port;
> > +   const struct mtk_pcie_soc *soc;
> > +
> > +   pdev = to_platform_device(dev);
> > +   pcie = platform_get_drvdata(pdev);
> > +   soc = pcie->soc;
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> 
> I don't really like the __maybe_unused annotations.  Looking at the
> other users of SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, I think a small majority
> of them wrap the function definitions in #ifdef CONFIG_PM_SLEEP
> instead of using __maybe_unused.  That's also a bit ugly, but has the
> advantage of truly omitting the definitions when they're not needed.

Ok, I will follow your advise in the next version.

thanks.

Re: [PATCH] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Thu, 2018-05-31 at 10:05 +0800, Ryder Lee wrote:
> On Wed, 2018-05-30 at 10:35 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> > the internel control register will be reset after system resume. The PCIe
> > link should be re-established and the related control register values should
> > be re-set after system resume.
> > 
> > Signed-off-by: Honghui Zhang 
> > CC: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 82 
> > 
> >  1 file changed, 82 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index dabf1086..60f98d92 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -132,12 +132,14 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > + * @pm_support: whether the host's MTCMOS will be off when suspend
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > +   bool pm_support;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >  
> > +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> > +{
> > +   struct platform_device *pdev;
> > +   struct mtk_pcie *pcie;
> > +   struct mtk_pcie_port *port;
> > +   const struct mtk_pcie_soc *soc;
> > +
> > +   pdev = to_platform_device(dev);
> > +   pcie = platform_get_drvdata(pdev);
> 
> How about this -
> struct mtk_pcie *pcie = dev_get_drvdata(dev);

Yes, I forgot that, thanks very much for your reminder.

> 
> > +   soc = pcie->soc;
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> > +{
> > +   struct platform_device *pdev;
> > +   struct mtk_pcie *pcie;
> > +   struct mtk_pcie_port *port;
> > +   const struct mtk_pcie_soc *soc;
> > +   int ret;
> > +
> > +   pdev = to_platform_device(dev);
> > +   pcie = platform_get_drvdata(pdev);
> 
> struct mtk_pcie *pcie = dev_get_drvdata(dev);

thanks.

> 
> > +   soc = pcie->soc;
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   ret = phy_power_on(port->phy);
> > +   if (ret) {
> > +   dev_err(dev, "could not power on phy\n");
> > +   return ret;
> > +   }
> > +   ret = clk_prepare_enable(port->sys_ck);
> > +   if (ret) {
> > +   dev_err(dev, "enable sys clock error\n");
> > +   phy_power_off(port->phy);
> > +   return ret;
> > +   }
> > +
> > +   ret = clk_prepare_enable(port->ahb_ck);
> > +   if (ret) {
> > +   dev_err(dev, "enable ahb clock error\n");
> > +   phy_power_off(port->phy);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   return ret;
> > +   }
> > +
> > +   ret = soc->startup(port);
> > +   if (ret) {
> > +   dev_err(dev, "pcie linkup failed\n");
> > +   phy_power_off(port->phy);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   return ret;
> > +   }
> > +
> > +   if (IS_ENABLED(CONFIG_PCI_MSI))
> > +   mtk_pcie_enable_msi(port);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> 
> 
> 

Re: [PATCH] PCI: mediatek: Add system pm support for MT2712

[Honghui Zhang]

On Thu, 2018-05-31 at 10:05 +0800, Ryder Lee wrote:
> On Wed, 2018-05-30 at 10:35 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> > the internel control register will be reset after system resume. The PCIe
> > link should be re-established and the related control register values should
> > be re-set after system resume.
> > 
> > Signed-off-by: Honghui Zhang 
> > CC: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 82 
> > 
> >  1 file changed, 82 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index dabf1086..60f98d92 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -132,12 +132,14 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > + * @pm_support: whether the host's MTCMOS will be off when suspend
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > +   bool pm_support;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > return err;
> >  }
> >  
> > +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> > +{
> > +   struct platform_device *pdev;
> > +   struct mtk_pcie *pcie;
> > +   struct mtk_pcie_port *port;
> > +   const struct mtk_pcie_soc *soc;
> > +
> > +   pdev = to_platform_device(dev);
> > +   pcie = platform_get_drvdata(pdev);
> 
> How about this -
> struct mtk_pcie *pcie = dev_get_drvdata(dev);

Yes, I forgot that, thanks very much for your reminder.

> 
> > +   soc = pcie->soc;
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   phy_power_off(port->phy);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> > +{
> > +   struct platform_device *pdev;
> > +   struct mtk_pcie *pcie;
> > +   struct mtk_pcie_port *port;
> > +   const struct mtk_pcie_soc *soc;
> > +   int ret;
> > +
> > +   pdev = to_platform_device(dev);
> > +   pcie = platform_get_drvdata(pdev);
> 
> struct mtk_pcie *pcie = dev_get_drvdata(dev);

thanks.

> 
> > +   soc = pcie->soc;
> > +   if (!soc->pm_support)
> > +   return 0;
> > +
> > +   list_for_each_entry(port, >ports, list) {
> > +   ret = phy_power_on(port->phy);
> > +   if (ret) {
> > +   dev_err(dev, "could not power on phy\n");
> > +   return ret;
> > +   }
> > +   ret = clk_prepare_enable(port->sys_ck);
> > +   if (ret) {
> > +   dev_err(dev, "enable sys clock error\n");
> > +   phy_power_off(port->phy);
> > +   return ret;
> > +   }
> > +
> > +   ret = clk_prepare_enable(port->ahb_ck);
> > +   if (ret) {
> > +   dev_err(dev, "enable ahb clock error\n");
> > +   phy_power_off(port->phy);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   return ret;
> > +   }
> > +
> > +   ret = soc->startup(port);
> > +   if (ret) {
> > +   dev_err(dev, "pcie linkup failed\n");
> > +   phy_power_off(port->phy);
> > +   clk_disable_unprepare(port->sys_ck);
> > +   clk_disable_unprepare(port->ahb_ck);
> > +   return ret;
> > +   }
> > +
> > +   if (IS_ENABLED(CONFIG_PCI_MSI))
> > +   mtk_pcie_enable_msi(port);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> 
> 
> 

Re: [PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Honghui Zhang]

On Thu, 2018-05-03 at 14:05 +0100, Marc Zyngier wrote:
> On 03/05/18 10:41, Honghui Zhang wrote:
> > On Wed, 2018-05-02 at 11:09 +0100, Marc Zyngier wrote:
> >> On 02/05/18 10:41, Honghui Zhang wrote:
> >>> On Mon, 2018-04-30 at 12:03 +0100, Marc Zyngier wrote:
> >>>> Hi Zhang,
> >>>>
> >>>> On 20/04/18 06:25, honghui.zh...@mediatek.com wrote:
> >>>>> From: Honghui Zhang <honghui.zh...@mediatek.com>
> >>>>>
> >>>>> Using irq_chip solution to setup IRQs for the consistent with IRQ 
> >>>>> framework.
> >>>>>
> >>>>> Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> >>>>> ---
> >>>>>  drivers/pci/host/pcie-mediatek.c | 192 
> >>>>> +--
> >>>>>  1 file changed, 105 insertions(+), 87 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/pci/host/pcie-mediatek.c 
> >>>>> b/drivers/pci/host/pcie-mediatek.c
> >>>>> index c3dc549..1d9c6f1 100644
> >>>>> --- a/drivers/pci/host/pcie-mediatek.c
> >>>>> +++ b/drivers/pci/host/pcie-mediatek.c
> >>>>> @@ -11,8 +11,10 @@
> >>>>>  #include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>> +#include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>> +#include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>> @@ -130,14 +132,12 @@ struct mtk_pcie_port;
> >>>>>  /**
> >>>>>   * struct mtk_pcie_soc - differentiate between host generations
> >>>>>   * @need_fix_class_id: whether this host's class ID needed to be fixed 
> >>>>> or not
> >>>>> - * @has_msi: whether this host supports MSI interrupts or not
> >>>>>   * @ops: pointer to configuration access functions
> >>>>>   * @startup: pointer to controller setting functions
> >>>>>   * @setup_irq: pointer to initialize IRQ functions
> >>>>>   */
> >>>>>  struct mtk_pcie_soc {
> >>>>> bool need_fix_class_id;
> >>>>> -   bool has_msi;
> >>>>> struct pci_ops *ops;
> >>>>> int (*startup)(struct mtk_pcie_port *port);
> >>>>> int (*setup_irq)(struct mtk_pcie_port *port, struct device_node 
> >>>>> *node);
> >>>>> @@ -161,7 +161,9 @@ struct mtk_pcie_soc {
> >>>>>   * @lane: lane count
> >>>>>   * @slot: port slot
> >>>>>   * @irq_domain: legacy INTx IRQ domain
> >>>>> + * @inner_domain: inner IRQ domain
> >>>>>   * @msi_domain: MSI IRQ domain
> >>>>> + * @lock: protect the msi_irq_in_use bitmap
> >>>>>   * @msi_irq_in_use: bit map for assigned MSI IRQ
> >>>>>   */
> >>>>>  struct mtk_pcie_port {
> >>>>> @@ -179,7 +181,9 @@ struct mtk_pcie_port {
> >>>>> u32 lane;
> >>>>> u32 slot;
> >>>>> struct irq_domain *irq_domain;
> >>>>> +   struct irq_domain *inner_domain;
> >>>>> struct irq_domain *msi_domain;
> >>>>> +   struct mutex lock;
> >>>>> DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >>>>>  };
> >>>>>  
> >>>>> @@ -446,103 +450,122 @@ static int mtk_pcie_startup_port_v2(struct 
> >>>>> mtk_pcie_port *port)
> >>>>> return 0;
> >>>>>  }
> >>>>>  
> >>>>> -static int mtk_pcie_msi_alloc(struct mtk_pcie_port *port)
> >>>>> +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg 
> >>>>> *msg)
> >>>>>  {
> >>>>> -   int msi;
> >>>>> +   struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> >>>>> +   phys_addr_t addr;
> >>>>>  
> >>>>> -   msi = find_first_zero_bit(port->msi_irq_in_use, 
> >>>>> MTK_MSI_IRQS_NUM);
> >>>>> -   if (msi < MTK_MSI_IRQS_NUM)
> >>>>> -   set_bit(msi, port->msi_i

Re: [PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Honghui Zhang]

On Thu, 2018-05-03 at 14:05 +0100, Marc Zyngier wrote:
> On 03/05/18 10:41, Honghui Zhang wrote:
> > On Wed, 2018-05-02 at 11:09 +0100, Marc Zyngier wrote:
> >> On 02/05/18 10:41, Honghui Zhang wrote:
> >>> On Mon, 2018-04-30 at 12:03 +0100, Marc Zyngier wrote:
> >>>> Hi Zhang,
> >>>>
> >>>> On 20/04/18 06:25, honghui.zh...@mediatek.com wrote:
> >>>>> From: Honghui Zhang 
> >>>>>
> >>>>> Using irq_chip solution to setup IRQs for the consistent with IRQ 
> >>>>> framework.
> >>>>>
> >>>>> Signed-off-by: Honghui Zhang 
> >>>>> ---
> >>>>>  drivers/pci/host/pcie-mediatek.c | 192 
> >>>>> +--
> >>>>>  1 file changed, 105 insertions(+), 87 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/pci/host/pcie-mediatek.c 
> >>>>> b/drivers/pci/host/pcie-mediatek.c
> >>>>> index c3dc549..1d9c6f1 100644
> >>>>> --- a/drivers/pci/host/pcie-mediatek.c
> >>>>> +++ b/drivers/pci/host/pcie-mediatek.c
> >>>>> @@ -11,8 +11,10 @@
> >>>>>  #include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>> +#include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>> +#include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>>  #include 
> >>>>> @@ -130,14 +132,12 @@ struct mtk_pcie_port;
> >>>>>  /**
> >>>>>   * struct mtk_pcie_soc - differentiate between host generations
> >>>>>   * @need_fix_class_id: whether this host's class ID needed to be fixed 
> >>>>> or not
> >>>>> - * @has_msi: whether this host supports MSI interrupts or not
> >>>>>   * @ops: pointer to configuration access functions
> >>>>>   * @startup: pointer to controller setting functions
> >>>>>   * @setup_irq: pointer to initialize IRQ functions
> >>>>>   */
> >>>>>  struct mtk_pcie_soc {
> >>>>> bool need_fix_class_id;
> >>>>> -   bool has_msi;
> >>>>> struct pci_ops *ops;
> >>>>> int (*startup)(struct mtk_pcie_port *port);
> >>>>> int (*setup_irq)(struct mtk_pcie_port *port, struct device_node 
> >>>>> *node);
> >>>>> @@ -161,7 +161,9 @@ struct mtk_pcie_soc {
> >>>>>   * @lane: lane count
> >>>>>   * @slot: port slot
> >>>>>   * @irq_domain: legacy INTx IRQ domain
> >>>>> + * @inner_domain: inner IRQ domain
> >>>>>   * @msi_domain: MSI IRQ domain
> >>>>> + * @lock: protect the msi_irq_in_use bitmap
> >>>>>   * @msi_irq_in_use: bit map for assigned MSI IRQ
> >>>>>   */
> >>>>>  struct mtk_pcie_port {
> >>>>> @@ -179,7 +181,9 @@ struct mtk_pcie_port {
> >>>>> u32 lane;
> >>>>> u32 slot;
> >>>>> struct irq_domain *irq_domain;
> >>>>> +   struct irq_domain *inner_domain;
> >>>>> struct irq_domain *msi_domain;
> >>>>> +   struct mutex lock;
> >>>>> DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >>>>>  };
> >>>>>  
> >>>>> @@ -446,103 +450,122 @@ static int mtk_pcie_startup_port_v2(struct 
> >>>>> mtk_pcie_port *port)
> >>>>> return 0;
> >>>>>  }
> >>>>>  
> >>>>> -static int mtk_pcie_msi_alloc(struct mtk_pcie_port *port)
> >>>>> +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg 
> >>>>> *msg)
> >>>>>  {
> >>>>> -   int msi;
> >>>>> +   struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> >>>>> +   phys_addr_t addr;
> >>>>>  
> >>>>> -   msi = find_first_zero_bit(port->msi_irq_in_use, 
> >>>>> MTK_MSI_IRQS_NUM);
> >>>>> -   if (msi < MTK_MSI_IRQS_NUM)
> >>>>> -   set_bit(msi, port->msi_irq_in_use);
> >>>>> -   else
> >>>>

Re: [PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Honghui Zhang]

On Wed, 2018-05-02 at 11:09 +0100, Marc Zyngier wrote:
> On 02/05/18 10:41, Honghui Zhang wrote:
> > On Mon, 2018-04-30 at 12:03 +0100, Marc Zyngier wrote:
> >> Hi Zhang,
> >>
> >> On 20/04/18 06:25, honghui.zh...@mediatek.com wrote:
> >>> From: Honghui Zhang <honghui.zh...@mediatek.com>
> >>>
> >>> Using irq_chip solution to setup IRQs for the consistent with IRQ 
> >>> framework.
> >>>
> >>> Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> >>> ---
> >>>  drivers/pci/host/pcie-mediatek.c | 192 
> >>> +--
> >>>  1 file changed, 105 insertions(+), 87 deletions(-)
> >>>
> >>> diff --git a/drivers/pci/host/pcie-mediatek.c 
> >>> b/drivers/pci/host/pcie-mediatek.c
> >>> index c3dc549..1d9c6f1 100644
> >>> --- a/drivers/pci/host/pcie-mediatek.c
> >>> +++ b/drivers/pci/host/pcie-mediatek.c
> >>> @@ -11,8 +11,10 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> @@ -130,14 +132,12 @@ struct mtk_pcie_port;
> >>>  /**
> >>>   * struct mtk_pcie_soc - differentiate between host generations
> >>>   * @need_fix_class_id: whether this host's class ID needed to be fixed 
> >>> or not
> >>> - * @has_msi: whether this host supports MSI interrupts or not
> >>>   * @ops: pointer to configuration access functions
> >>>   * @startup: pointer to controller setting functions
> >>>   * @setup_irq: pointer to initialize IRQ functions
> >>>   */
> >>>  struct mtk_pcie_soc {
> >>>   bool need_fix_class_id;
> >>> - bool has_msi;
> >>>   struct pci_ops *ops;
> >>>   int (*startup)(struct mtk_pcie_port *port);
> >>>   int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> >>> @@ -161,7 +161,9 @@ struct mtk_pcie_soc {
> >>>   * @lane: lane count
> >>>   * @slot: port slot
> >>>   * @irq_domain: legacy INTx IRQ domain
> >>> + * @inner_domain: inner IRQ domain
> >>>   * @msi_domain: MSI IRQ domain
> >>> + * @lock: protect the msi_irq_in_use bitmap
> >>>   * @msi_irq_in_use: bit map for assigned MSI IRQ
> >>>   */
> >>>  struct mtk_pcie_port {
> >>> @@ -179,7 +181,9 @@ struct mtk_pcie_port {
> >>>   u32 lane;
> >>>   u32 slot;
> >>>   struct irq_domain *irq_domain;
> >>> + struct irq_domain *inner_domain;
> >>>   struct irq_domain *msi_domain;
> >>> + struct mutex lock;
> >>>   DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >>>  };
> >>>  
> >>> @@ -446,103 +450,122 @@ static int mtk_pcie_startup_port_v2(struct 
> >>> mtk_pcie_port *port)
> >>>   return 0;
> >>>  }
> >>>  
> >>> -static int mtk_pcie_msi_alloc(struct mtk_pcie_port *port)
> >>> +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg 
> >>> *msg)
> >>>  {
> >>> - int msi;
> >>> + struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> >>> + phys_addr_t addr;
> >>>  
> >>> - msi = find_first_zero_bit(port->msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >>> - if (msi < MTK_MSI_IRQS_NUM)
> >>> - set_bit(msi, port->msi_irq_in_use);
> >>> - else
> >>> - return -ENOSPC;
> >>> + /* MT2712/MT7622 only support 32-bit MSI addresses */
> >>> + addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> >>> + msg->address_hi = 0;
> >>> + msg->address_lo = lower_32_bits(addr);
> >>>  
> >>> - return msi;
> >>> + msg->data = data->hwirq;
> >>> +
> >>> + dev_dbg(port->pcie->dev, "msi#%d address_hi %#x address_lo %#x\n",
> >>> + (int)data->hwirq, msg->address_hi, msg->address_lo);
> >>>  }
> >>>  
> >>> -static void mtk_pcie_msi_free(struct mtk_pcie_port *port, unsigned long 
> >>> hwirq)
> >>> +static int mtk_msi_set_affinity(struct irq_data *irq_data,
> >>> +const struct cpumask *mask, bool

Re: [PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Honghui Zhang]

On Wed, 2018-05-02 at 11:09 +0100, Marc Zyngier wrote:
> On 02/05/18 10:41, Honghui Zhang wrote:
> > On Mon, 2018-04-30 at 12:03 +0100, Marc Zyngier wrote:
> >> Hi Zhang,
> >>
> >> On 20/04/18 06:25, honghui.zh...@mediatek.com wrote:
> >>> From: Honghui Zhang 
> >>>
> >>> Using irq_chip solution to setup IRQs for the consistent with IRQ 
> >>> framework.
> >>>
> >>> Signed-off-by: Honghui Zhang 
> >>> ---
> >>>  drivers/pci/host/pcie-mediatek.c | 192 
> >>> +--
> >>>  1 file changed, 105 insertions(+), 87 deletions(-)
> >>>
> >>> diff --git a/drivers/pci/host/pcie-mediatek.c 
> >>> b/drivers/pci/host/pcie-mediatek.c
> >>> index c3dc549..1d9c6f1 100644
> >>> --- a/drivers/pci/host/pcie-mediatek.c
> >>> +++ b/drivers/pci/host/pcie-mediatek.c
> >>> @@ -11,8 +11,10 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> @@ -130,14 +132,12 @@ struct mtk_pcie_port;
> >>>  /**
> >>>   * struct mtk_pcie_soc - differentiate between host generations
> >>>   * @need_fix_class_id: whether this host's class ID needed to be fixed 
> >>> or not
> >>> - * @has_msi: whether this host supports MSI interrupts or not
> >>>   * @ops: pointer to configuration access functions
> >>>   * @startup: pointer to controller setting functions
> >>>   * @setup_irq: pointer to initialize IRQ functions
> >>>   */
> >>>  struct mtk_pcie_soc {
> >>>   bool need_fix_class_id;
> >>> - bool has_msi;
> >>>   struct pci_ops *ops;
> >>>   int (*startup)(struct mtk_pcie_port *port);
> >>>   int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> >>> @@ -161,7 +161,9 @@ struct mtk_pcie_soc {
> >>>   * @lane: lane count
> >>>   * @slot: port slot
> >>>   * @irq_domain: legacy INTx IRQ domain
> >>> + * @inner_domain: inner IRQ domain
> >>>   * @msi_domain: MSI IRQ domain
> >>> + * @lock: protect the msi_irq_in_use bitmap
> >>>   * @msi_irq_in_use: bit map for assigned MSI IRQ
> >>>   */
> >>>  struct mtk_pcie_port {
> >>> @@ -179,7 +181,9 @@ struct mtk_pcie_port {
> >>>   u32 lane;
> >>>   u32 slot;
> >>>   struct irq_domain *irq_domain;
> >>> + struct irq_domain *inner_domain;
> >>>   struct irq_domain *msi_domain;
> >>> + struct mutex lock;
> >>>   DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >>>  };
> >>>  
> >>> @@ -446,103 +450,122 @@ static int mtk_pcie_startup_port_v2(struct 
> >>> mtk_pcie_port *port)
> >>>   return 0;
> >>>  }
> >>>  
> >>> -static int mtk_pcie_msi_alloc(struct mtk_pcie_port *port)
> >>> +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg 
> >>> *msg)
> >>>  {
> >>> - int msi;
> >>> + struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> >>> + phys_addr_t addr;
> >>>  
> >>> - msi = find_first_zero_bit(port->msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >>> - if (msi < MTK_MSI_IRQS_NUM)
> >>> - set_bit(msi, port->msi_irq_in_use);
> >>> - else
> >>> - return -ENOSPC;
> >>> + /* MT2712/MT7622 only support 32-bit MSI addresses */
> >>> + addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> >>> + msg->address_hi = 0;
> >>> + msg->address_lo = lower_32_bits(addr);
> >>>  
> >>> - return msi;
> >>> + msg->data = data->hwirq;
> >>> +
> >>> + dev_dbg(port->pcie->dev, "msi#%d address_hi %#x address_lo %#x\n",
> >>> + (int)data->hwirq, msg->address_hi, msg->address_lo);
> >>>  }
> >>>  
> >>> -static void mtk_pcie_msi_free(struct mtk_pcie_port *port, unsigned long 
> >>> hwirq)
> >>> +static int mtk_msi_set_affinity(struct irq_data *irq_data,
> >>> +const struct cpumask *mask, bool force)
> >>>  {
> >>> - clear_bit(hwirq, port-&

Re: [PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Honghui Zhang]

On Mon, 2018-04-30 at 12:03 +0100, Marc Zyngier wrote:
> Hi Zhang,
> 
> On 20/04/18 06:25, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > 
> > Using irq_chip solution to setup IRQs for the consistent with IRQ framework.
> > 
> > Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 192 
> > +--
> >  1 file changed, 105 insertions(+), 87 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index c3dc549..1d9c6f1 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -11,8 +11,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -130,14 +132,12 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > - * @has_msi: whether this host supports MSI interrupts or not
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > -   bool has_msi;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -161,7 +161,9 @@ struct mtk_pcie_soc {
> >   * @lane: lane count
> >   * @slot: port slot
> >   * @irq_domain: legacy INTx IRQ domain
> > + * @inner_domain: inner IRQ domain
> >   * @msi_domain: MSI IRQ domain
> > + * @lock: protect the msi_irq_in_use bitmap
> >   * @msi_irq_in_use: bit map for assigned MSI IRQ
> >   */
> >  struct mtk_pcie_port {
> > @@ -179,7 +181,9 @@ struct mtk_pcie_port {
> > u32 lane;
> > u32 slot;
> > struct irq_domain *irq_domain;
> > +   struct irq_domain *inner_domain;
> > struct irq_domain *msi_domain;
> > +   struct mutex lock;
> > DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >  };
> >  
> > @@ -446,103 +450,122 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > return 0;
> >  }
> >  
> > -static int mtk_pcie_msi_alloc(struct mtk_pcie_port *port)
> > +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> >  {
> > -   int msi;
> > +   struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> > +   phys_addr_t addr;
> >  
> > -   msi = find_first_zero_bit(port->msi_irq_in_use, MTK_MSI_IRQS_NUM);
> > -   if (msi < MTK_MSI_IRQS_NUM)
> > -   set_bit(msi, port->msi_irq_in_use);
> > -   else
> > -   return -ENOSPC;
> > +   /* MT2712/MT7622 only support 32-bit MSI addresses */
> > +   addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> > +   msg->address_hi = 0;
> > +   msg->address_lo = lower_32_bits(addr);
> >  
> > -   return msi;
> > +   msg->data = data->hwirq;
> > +
> > +   dev_dbg(port->pcie->dev, "msi#%d address_hi %#x address_lo %#x\n",
> > +   (int)data->hwirq, msg->address_hi, msg->address_lo);
> >  }
> >  
> > -static void mtk_pcie_msi_free(struct mtk_pcie_port *port, unsigned long 
> > hwirq)
> > +static int mtk_msi_set_affinity(struct irq_data *irq_data,
> > +  const struct cpumask *mask, bool force)
> >  {
> > -   clear_bit(hwirq, port->msi_irq_in_use);
> > +   return -EINVAL;
> >  }
> >  
> > -static int mtk_pcie_msi_setup_irq(struct msi_controller *chip,
> > - struct pci_dev *pdev, struct msi_desc *desc)
> > -{
> > -   struct mtk_pcie_port *port;
> > -   struct msi_msg msg;
> > -   unsigned int irq;
> > -   int hwirq;
> > -   phys_addr_t msg_addr;
> > +static struct irq_chip mtk_msi_bottom_irq_chip = {
> > +   .name   = "MTK MSI",
> > +   .irq_compose_msi_msg= mtk_compose_msi_msg,
> > +   .irq_set_affinity   = mtk_msi_set_affinity,
> > +   .irq_mask   = pci_msi_mask_irq,
> > +   .irq_unmask = pci_msi_unmask_irq,
> > +};
> >  
> > -   port 

Re: [PATCH 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Honghui Zhang]

On Mon, 2018-04-30 at 12:03 +0100, Marc Zyngier wrote:
> Hi Zhang,
> 
> On 20/04/18 06:25, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Using irq_chip solution to setup IRQs for the consistent with IRQ framework.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 192 
> > +--
> >  1 file changed, 105 insertions(+), 87 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index c3dc549..1d9c6f1 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -11,8 +11,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -130,14 +132,12 @@ struct mtk_pcie_port;
> >  /**
> >   * struct mtk_pcie_soc - differentiate between host generations
> >   * @need_fix_class_id: whether this host's class ID needed to be fixed or 
> > not
> > - * @has_msi: whether this host supports MSI interrupts or not
> >   * @ops: pointer to configuration access functions
> >   * @startup: pointer to controller setting functions
> >   * @setup_irq: pointer to initialize IRQ functions
> >   */
> >  struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > -   bool has_msi;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -161,7 +161,9 @@ struct mtk_pcie_soc {
> >   * @lane: lane count
> >   * @slot: port slot
> >   * @irq_domain: legacy INTx IRQ domain
> > + * @inner_domain: inner IRQ domain
> >   * @msi_domain: MSI IRQ domain
> > + * @lock: protect the msi_irq_in_use bitmap
> >   * @msi_irq_in_use: bit map for assigned MSI IRQ
> >   */
> >  struct mtk_pcie_port {
> > @@ -179,7 +181,9 @@ struct mtk_pcie_port {
> > u32 lane;
> > u32 slot;
> > struct irq_domain *irq_domain;
> > +   struct irq_domain *inner_domain;
> > struct irq_domain *msi_domain;
> > +   struct mutex lock;
> > DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
> >  };
> >  
> > @@ -446,103 +450,122 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > return 0;
> >  }
> >  
> > -static int mtk_pcie_msi_alloc(struct mtk_pcie_port *port)
> > +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> >  {
> > -   int msi;
> > +   struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
> > +   phys_addr_t addr;
> >  
> > -   msi = find_first_zero_bit(port->msi_irq_in_use, MTK_MSI_IRQS_NUM);
> > -   if (msi < MTK_MSI_IRQS_NUM)
> > -   set_bit(msi, port->msi_irq_in_use);
> > -   else
> > -   return -ENOSPC;
> > +   /* MT2712/MT7622 only support 32-bit MSI addresses */
> > +   addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> > +   msg->address_hi = 0;
> > +   msg->address_lo = lower_32_bits(addr);
> >  
> > -   return msi;
> > +   msg->data = data->hwirq;
> > +
> > +   dev_dbg(port->pcie->dev, "msi#%d address_hi %#x address_lo %#x\n",
> > +   (int)data->hwirq, msg->address_hi, msg->address_lo);
> >  }
> >  
> > -static void mtk_pcie_msi_free(struct mtk_pcie_port *port, unsigned long 
> > hwirq)
> > +static int mtk_msi_set_affinity(struct irq_data *irq_data,
> > +  const struct cpumask *mask, bool force)
> >  {
> > -   clear_bit(hwirq, port->msi_irq_in_use);
> > +   return -EINVAL;
> >  }
> >  
> > -static int mtk_pcie_msi_setup_irq(struct msi_controller *chip,
> > - struct pci_dev *pdev, struct msi_desc *desc)
> > -{
> > -   struct mtk_pcie_port *port;
> > -   struct msi_msg msg;
> > -   unsigned int irq;
> > -   int hwirq;
> > -   phys_addr_t msg_addr;
> > +static struct irq_chip mtk_msi_bottom_irq_chip = {
> > +   .name   = "MTK MSI",
> > +   .irq_compose_msi_msg= mtk_compose_msi_msg,
> > +   .irq_set_affinity   = mtk_msi_set_affinity,
> > +   .irq_mask   = pci_msi_mask_irq,
> > +   .irq_unmask = pci_msi_unmask_irq,
> > +};
> >  
> > -   port = mtk_pcie_find_port(pdev->bus, pdev->devfn)

Re: [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry

[Honghui Zhang]

On Thu, 2018-01-04 at 19:04 +, Marc Zyngier wrote:
> On 04/01/18 18:40, Lorenzo Pieralisi wrote:
> > [+Marc]
> > 
> > On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zh...@mediatek.com wrote:
> >> From: Honghui Zhang <honghui.zh...@mediatek.com>
> >>
> >> There maybe a same IRQ reentry scenario after IRQ received in current
> >> IRQ handle flow:
> >>EP device   PCIe host driverEP 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.
> >> This patch also fix another INTx IRQ issue by initialize the iterate
> >> before the loop. If an INTx IRQ re-occurred while we are dispatching
> >> the INTx IRQ, then iterate may start from PCI_NUM_INTX + INTX_SHIFT
> >> instead of INTX_SHIFT for the second time entering the
> >> for_each_set_bit_from() loop.
> > 
> > This looks like two different issues that should be fixed with two
> > patches.

Ok, I split this into two patches and figure out a more reasonable
approach by using irq_chip solution.

> > 
> >> Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> >> Acked-by: Ryder Lee <ryder@mediatek.com>
> >> ---
> >>  drivers/pci/host/pcie-mediatek.c | 11 ++-
> >>  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > For the sake of uniformity, I first want to understand why this
> > driver does not call:
> > 
> > chained_irq_enter/exit()
> > 
> > in the primary handler (mtk_pcie_intr_handler()).
> > 
> > With the GIC as a primary interrupt controller we have not
> > even figured out how current code can actually work without
> > calling the chained_* API.
> > 
> > I want to come up with a consistent handling of IRQ domains for
> > all host bridges and any discrepancy should be explained.
> 
> That's because this driver is a huge hack, see below:
> 
> > 
> >> diff --git a/drivers/pci/host/pcie-mediatek.c 
> >> b/drivers/pci/host/pcie-mediatek.c
> >> index db93efd..fc29a9a 100644
> >> --- a/drivers/pci/host/pcie-mediatek.c
> >> +++ b/drivers/pci/host/pcie-mediatek.c
> >> @@ -601,15 +601,16 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, 
> >> void *data)
> 
> This function is not a chained irqchip, but an interrupt handler...
> 
> >>struct mtk_pcie_port *port = (struct mtk_pcie_port *)data;
> >>unsigned long status;
> >>u32 virq;
> >> -  u32 bit = INTX_SHIFT;
> >> +  u32 bit;
> >>  
> >>while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> >> +  bit = INTX_SHIFT;
> >>for_each_set_bit_from(bit, , 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);
> 
> and nonetheless, this calls into generic_handle_irq(). That's a complete
> violation of the interrupt layering. Maybe there is a good reason for
> it, but I'd like to know which one.
> 
> Which means that all of the ack/mask has to be done outside of the
> irqchip framework too... Disgusting.
> 
> >> +  /* Clear the INTx */
> >> +  writel(1 << bit, port->base + PCIE_INT_STATUS);
> > 
> > I think that these masking/acking should actually be done through
> > the irq_chip hooks (see for instance pci-ftpci100.c) - that would
> > make this kind of bugs much easier to prevent (because the IRQ
> > layer does the sequencing for you).
> 
> +1.
> 

Thanks for your advice, I need to do some homework to have a better
understanding of the irq_chip approach.

> > Marc (CC'ed) has a more comprehensive view on this than me - I would
> > like to get to a point where all host bridges uses a consistent
> > approach for chained IRQ handling and I hope this bug fix can be
> > a starting point.
> 
> +1 again. We definitely need to come up with some form of common
> approach for all these host drivers, and maybe turn that into a library...
> 

Well, this is beyond my knowledge now, I guess I can figure out how to
using irq_chip for the first step, then I may following this "common
approach" after we have a solution for that?

thanks.
> Thanks,
> 
>   M.

Re: [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry

[Honghui Zhang]

On Thu, 2018-01-04 at 19:04 +, Marc Zyngier wrote:
> On 04/01/18 18:40, Lorenzo Pieralisi wrote:
> > [+Marc]
> > 
> > On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zh...@mediatek.com wrote:
> >> From: Honghui Zhang 
> >>
> >> There maybe a same IRQ reentry scenario after IRQ received in current
> >> IRQ handle flow:
> >>EP device   PCIe host driverEP 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.
> >> This patch also fix another INTx IRQ issue by initialize the iterate
> >> before the loop. If an INTx IRQ re-occurred while we are dispatching
> >> the INTx IRQ, then iterate may start from PCI_NUM_INTX + INTX_SHIFT
> >> instead of INTX_SHIFT for the second time entering the
> >> for_each_set_bit_from() loop.
> > 
> > This looks like two different issues that should be fixed with two
> > patches.

Ok, I split this into two patches and figure out a more reasonable
approach by using irq_chip solution.

> > 
> >> Signed-off-by: Honghui Zhang 
> >> Acked-by: Ryder Lee 
> >> ---
> >>  drivers/pci/host/pcie-mediatek.c | 11 ++-
> >>  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > For the sake of uniformity, I first want to understand why this
> > driver does not call:
> > 
> > chained_irq_enter/exit()
> > 
> > in the primary handler (mtk_pcie_intr_handler()).
> > 
> > With the GIC as a primary interrupt controller we have not
> > even figured out how current code can actually work without
> > calling the chained_* API.
> > 
> > I want to come up with a consistent handling of IRQ domains for
> > all host bridges and any discrepancy should be explained.
> 
> That's because this driver is a huge hack, see below:
> 
> > 
> >> diff --git a/drivers/pci/host/pcie-mediatek.c 
> >> b/drivers/pci/host/pcie-mediatek.c
> >> index db93efd..fc29a9a 100644
> >> --- a/drivers/pci/host/pcie-mediatek.c
> >> +++ b/drivers/pci/host/pcie-mediatek.c
> >> @@ -601,15 +601,16 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, 
> >> void *data)
> 
> This function is not a chained irqchip, but an interrupt handler...
> 
> >>struct mtk_pcie_port *port = (struct mtk_pcie_port *)data;
> >>unsigned long status;
> >>u32 virq;
> >> -  u32 bit = INTX_SHIFT;
> >> +  u32 bit;
> >>  
> >>while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> >> +  bit = INTX_SHIFT;
> >>for_each_set_bit_from(bit, , 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);
> 
> and nonetheless, this calls into generic_handle_irq(). That's a complete
> violation of the interrupt layering. Maybe there is a good reason for
> it, but I'd like to know which one.
> 
> Which means that all of the ack/mask has to be done outside of the
> irqchip framework too... Disgusting.
> 
> >> +  /* Clear the INTx */
> >> +  writel(1 << bit, port->base + PCIE_INT_STATUS);
> > 
> > I think that these masking/acking should actually be done through
> > the irq_chip hooks (see for instance pci-ftpci100.c) - that would
> > make this kind of bugs much easier to prevent (because the IRQ
> > layer does the sequencing for you).
> 
> +1.
> 

Thanks for your advice, I need to do some homework to have a better
understanding of the irq_chip approach.

> > Marc (CC'ed) has a more comprehensive view on this than me - I would
> > like to get to a point where all host bridges uses a consistent
> > approach for chained IRQ handling and I hope this bug fix can be
> > a starting point.
> 
> +1 again. We definitely need to come up with some form of common
> approach for all these host drivers, and maybe turn that into a library...
> 

Well, this is beyond my knowledge now, I guess I can figure out how to
using irq_chip for the first step, then I may following this "common
approach" after we have a solution for that?

thanks.
> Thanks,
> 
>   M.

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Honghui Zhang]

On Tue, 2018-01-02 at 10:56 +, Lorenzo Pieralisi wrote:
> On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote:
> > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zh...@mediatek.com 
> > > wrote:
> > > > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > > > 

> > > > +   /* Set up class code for MT7622 */
> > > > +   val = PCI_CLASS_BRIDGE_PCI << 16;
> > > > +   writel(val, port->base + PCIE_CONF_CLASS);
> > > 
> > > 1) Your comments mention MT7622 specifically, but this code is run for
> > > both mt2712-pcie and mt7622-pcie.  If this code is safe and necessary
> > > for both mt2712-pcie and mt7622-pcie, please remove the mention of
> > > MT7622.
> > 
> > Hmm, the code snippet added here will only be executed by MT7622, since
> > MT2712 will not enter this  "if (pcie->base) {"  condition.
> > Should the mention of MT7622 must be removed in this case?
> 
> You should add an explicit way (eg of_device_is_compatible() match for
> instance) to apply the quirk just on the platform that requires it.
> 
> Checking for "if (pcie->base)" is really not the way to do it.
> 

hi, Lorenzo,
Thanks very much for your advise.
Passing the compatible string or platform data into this function needed
to add some new field in the struct mtk_pcie_port, then I guess both set
it for MT2712 and MT7622 is an easy way, since re-setting those values
for MT2712 is safe.

> > > 2) The first comment mentions both "vendor ID and device ID" but you
> > > don't write the device ID.  Since this code applies to both
> > > mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> > > write the device ID.  If that's the case, please fix the comment.
> > > 
> > 
> > My bad, I did not check the comments carefully.
> > Thanks.
> > 
> > > 3) If you only need to set the vendor ID, you're performing a 32-bit
> > > write (writel()) to update a 16-bit value.  Please use writew()
> > > instead.
> > > 
> > 
> > Ok, thanks, I guess I could use the following code snippet in the next
> > version:
> > val = readl(port->base + PCIE_CONF_VENDOR_ID)
> > val &= ~GENMASK(15, 0);
> > val |= PCI_VENDOR_ID_MEDIATEK;
> > writel(val, port->base + PCIE_CONF_VENDOR_ID);
> 
> Have you read Bjorn's comment ? Or there is a problem with using
> a writew() ?
> 

This control register is a 32bit register, I'm not sure whether the apb
bus support write an 16bit value with 16bit but not 32bit address
alignment. I prefer the more safety old way of writel.

I need to do more test about the writew if the code elegant is more
important.

thanks.

> Lorenzo
> 
> > > 4) If you only need to set the vendor ID, please use a definition like
> > > "PCIE_CONF_VENDOR_ID" instead of the ambiguous "PCIE_CONF_ID".
> > > 
> > > 5) If you only need to set the vendor ID, please update the changelog
> > > to mention "vendor ID" specifically instead of the ambiguous "IDs".
> > 
> > > 6) Please add a space before the closing "*/" of the first comment.
> > > 
> > > 7) PCI_CLASS_BRIDGE_PCI is for a PCI-to-PCI bridge, i.e., one that has
> > > PCI on both the primary (upstream) side and the secondary (downstream)
> > > side.  That kind of bridge has a type 1 config header (see
> > > PCI_HEADER_TYPE) and the PCI_PRIMARY_BUS and PCI_SECONDARY_BUS
> > > registers tell us the bus number of the primary and secondary sides.
> > > 
> > > I don't believe this device is a PCI-to-PCI bridge.  I think it's a
> > > *host* bridge that has some non-PCI interface on the upstream side and
> > > should have a type 0 config header.  If that's the case you should use
> > > PCI_CLASS_BRIDGE_HOST instead.
> > > 
> > 
> > Thanks very much for your help with the review, I will fix the other
> > issue in the next version.
> > 
> > > > }
> > > >  
> > > > /* Assert all reset signals */
> > > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > > > index ab20dc5..2480b0e 100644
> > > > --- a/include/linux/pci_ids.h
> > > > +++ b/include/linux/pci_ids.h
> > > > @@ -2113,6 +2113,8 @@
> > > >  
> > > >  #define PCI_VENDOR_ID_MYRICOM  0x14c1
> > > >  
> > > > +#define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > > > +
> > > >  #define PCI_VENDOR_ID_TITAN0x14D2
> > > >  #define PCI_DEVICE_ID_TITAN_010L   0x8001
> > > >  #define PCI_DEVICE_ID_TITAN_100L   0x8010
> > > > -- 
> > > > 2.6.4
> > > > 
> > 
> > 

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Honghui Zhang]

On Tue, 2018-01-02 at 10:56 +, Lorenzo Pieralisi wrote:
> On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote:
> > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> > > On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zh...@mediatek.com 
> > > wrote:
> > > > From: Honghui Zhang 
> > > > 

> > > > +   /* Set up class code for MT7622 */
> > > > +   val = PCI_CLASS_BRIDGE_PCI << 16;
> > > > +   writel(val, port->base + PCIE_CONF_CLASS);
> > > 
> > > 1) Your comments mention MT7622 specifically, but this code is run for
> > > both mt2712-pcie and mt7622-pcie.  If this code is safe and necessary
> > > for both mt2712-pcie and mt7622-pcie, please remove the mention of
> > > MT7622.
> > 
> > Hmm, the code snippet added here will only be executed by MT7622, since
> > MT2712 will not enter this  "if (pcie->base) {"  condition.
> > Should the mention of MT7622 must be removed in this case?
> 
> You should add an explicit way (eg of_device_is_compatible() match for
> instance) to apply the quirk just on the platform that requires it.
> 
> Checking for "if (pcie->base)" is really not the way to do it.
> 

hi, Lorenzo,
Thanks very much for your advise.
Passing the compatible string or platform data into this function needed
to add some new field in the struct mtk_pcie_port, then I guess both set
it for MT2712 and MT7622 is an easy way, since re-setting those values
for MT2712 is safe.

> > > 2) The first comment mentions both "vendor ID and device ID" but you
> > > don't write the device ID.  Since this code applies to both
> > > mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> > > write the device ID.  If that's the case, please fix the comment.
> > > 
> > 
> > My bad, I did not check the comments carefully.
> > Thanks.
> > 
> > > 3) If you only need to set the vendor ID, you're performing a 32-bit
> > > write (writel()) to update a 16-bit value.  Please use writew()
> > > instead.
> > > 
> > 
> > Ok, thanks, I guess I could use the following code snippet in the next
> > version:
> > val = readl(port->base + PCIE_CONF_VENDOR_ID)
> > val &= ~GENMASK(15, 0);
> > val |= PCI_VENDOR_ID_MEDIATEK;
> > writel(val, port->base + PCIE_CONF_VENDOR_ID);
> 
> Have you read Bjorn's comment ? Or there is a problem with using
> a writew() ?
> 

This control register is a 32bit register, I'm not sure whether the apb
bus support write an 16bit value with 16bit but not 32bit address
alignment. I prefer the more safety old way of writel.

I need to do more test about the writew if the code elegant is more
important.

thanks.

> Lorenzo
> 
> > > 4) If you only need to set the vendor ID, please use a definition like
> > > "PCIE_CONF_VENDOR_ID" instead of the ambiguous "PCIE_CONF_ID".
> > > 
> > > 5) If you only need to set the vendor ID, please update the changelog
> > > to mention "vendor ID" specifically instead of the ambiguous "IDs".
> > 
> > > 6) Please add a space before the closing "*/" of the first comment.
> > > 
> > > 7) PCI_CLASS_BRIDGE_PCI is for a PCI-to-PCI bridge, i.e., one that has
> > > PCI on both the primary (upstream) side and the secondary (downstream)
> > > side.  That kind of bridge has a type 1 config header (see
> > > PCI_HEADER_TYPE) and the PCI_PRIMARY_BUS and PCI_SECONDARY_BUS
> > > registers tell us the bus number of the primary and secondary sides.
> > > 
> > > I don't believe this device is a PCI-to-PCI bridge.  I think it's a
> > > *host* bridge that has some non-PCI interface on the upstream side and
> > > should have a type 0 config header.  If that's the case you should use
> > > PCI_CLASS_BRIDGE_HOST instead.
> > > 
> > 
> > Thanks very much for your help with the review, I will fix the other
> > issue in the next version.
> > 
> > > > }
> > > >  
> > > > /* Assert all reset signals */
> > > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > > > index ab20dc5..2480b0e 100644
> > > > --- a/include/linux/pci_ids.h
> > > > +++ b/include/linux/pci_ids.h
> > > > @@ -2113,6 +2113,8 @@
> > > >  
> > > >  #define PCI_VENDOR_ID_MYRICOM  0x14c1
> > > >  
> > > > +#define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > > > +
> > > >  #define PCI_VENDOR_ID_TITAN0x14D2
> > > >  #define PCI_DEVICE_ID_TITAN_010L   0x8001
> > > >  #define PCI_DEVICE_ID_TITAN_100L   0x8010
> > > > -- 
> > > > 2.6.4
> > > > 
> > 
> > 

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Honghui Zhang]

On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > 
> > The hardware default value of IDs and class type is not correct,
> > fix that by setup the correct values before start up.
> > 
> > Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 12 
> >  include/linux/pci_ids.h  |  2 ++
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index fc29a9a..62aac0ea 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -74,6 +74,10 @@
> >  
> >  /* PCIe V2 per-port registers */
> >  #define PCIE_MSI_VECTOR0x0c0
> > +
> > +#define PCIE_CONF_ID   0x100
> > +#define PCIE_CONF_CLASS0x104
> > +
> >  #define PCIE_INT_MASK  0x420
> >  #define INTX_MASK  GENMASK(19, 16)
> >  #define INTX_SHIFT 16
> > @@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > val |= PCIE_CSR_LTSSM_EN(port->slot) |
> >PCIE_CSR_ASPM_L1_EN(port->slot);
> > writel(val, pcie->base + PCIE_SYS_CFG_V2);
> > +
> > +   /* Set up vendor ID and device ID for MT7622*/
> > +   val = PCI_VENDOR_ID_MEDIATEK;
> > +   writel(val, port->base + PCIE_CONF_ID);
> > +
> > +   /* Set up class code for MT7622 */
> > +   val = PCI_CLASS_BRIDGE_PCI << 16;
> > +   writel(val, port->base + PCIE_CONF_CLASS);
> 
> 1) Your comments mention MT7622 specifically, but this code is run for
> both mt2712-pcie and mt7622-pcie.  If this code is safe and necessary
> for both mt2712-pcie and mt7622-pcie, please remove the mention of
> MT7622.

Hmm, the code snippet added here will only be executed by MT7622, since
MT2712 will not enter this  "if (pcie->base) {"  condition.
Should the mention of MT7622 must be removed in this case?

> 
> 2) The first comment mentions both "vendor ID and device ID" but you
> don't write the device ID.  Since this code applies to both
> mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> write the device ID.  If that's the case, please fix the comment.
> 

My bad, I did not check the comments carefully.
Thanks.

> 3) If you only need to set the vendor ID, you're performing a 32-bit
> write (writel()) to update a 16-bit value.  Please use writew()
> instead.
> 

Ok, thanks, I guess I could use the following code snippet in the next
version:
val = readl(port->base + PCIE_CONF_VENDOR_ID)
val &= ~GENMASK(15, 0);
val |= PCI_VENDOR_ID_MEDIATEK;
writel(val, port->base + PCIE_CONF_VENDOR_ID);

> 4) If you only need to set the vendor ID, please use a definition like
> "PCIE_CONF_VENDOR_ID" instead of the ambiguous "PCIE_CONF_ID".
> 
> 5) If you only need to set the vendor ID, please update the changelog
> to mention "vendor ID" specifically instead of the ambiguous "IDs".

> 6) Please add a space before the closing "*/" of the first comment.
> 
> 7) PCI_CLASS_BRIDGE_PCI is for a PCI-to-PCI bridge, i.e., one that has
> PCI on both the primary (upstream) side and the secondary (downstream)
> side.  That kind of bridge has a type 1 config header (see
> PCI_HEADER_TYPE) and the PCI_PRIMARY_BUS and PCI_SECONDARY_BUS
> registers tell us the bus number of the primary and secondary sides.
> 
> I don't believe this device is a PCI-to-PCI bridge.  I think it's a
> *host* bridge that has some non-PCI interface on the upstream side and
> should have a type 0 config header.  If that's the case you should use
> PCI_CLASS_BRIDGE_HOST instead.
> 

Thanks very much for your help with the review, I will fix the other
issue in the next version.

> > }
> >  
> > /* Assert all reset signals */
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index ab20dc5..2480b0e 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2113,6 +2113,8 @@
> >  
> >  #define PCI_VENDOR_ID_MYRICOM  0x14c1
> >  
> > +#define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > +
> >  #define PCI_VENDOR_ID_TITAN0x14D2
> >  #define PCI_DEVICE_ID_TITAN_010L   0x8001
> >  #define PCI_DEVICE_ID_TITAN_100L   0x8010
> > -- 
> > 2.6.4
> > 

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Honghui Zhang]

On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The hardware default value of IDs and class type is not correct,
> > fix that by setup the correct values before start up.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 12 
> >  include/linux/pci_ids.h  |  2 ++
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index fc29a9a..62aac0ea 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -74,6 +74,10 @@
> >  
> >  /* PCIe V2 per-port registers */
> >  #define PCIE_MSI_VECTOR0x0c0
> > +
> > +#define PCIE_CONF_ID   0x100
> > +#define PCIE_CONF_CLASS0x104
> > +
> >  #define PCIE_INT_MASK  0x420
> >  #define INTX_MASK  GENMASK(19, 16)
> >  #define INTX_SHIFT 16
> > @@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > val |= PCIE_CSR_LTSSM_EN(port->slot) |
> >PCIE_CSR_ASPM_L1_EN(port->slot);
> > writel(val, pcie->base + PCIE_SYS_CFG_V2);
> > +
> > +   /* Set up vendor ID and device ID for MT7622*/
> > +   val = PCI_VENDOR_ID_MEDIATEK;
> > +   writel(val, port->base + PCIE_CONF_ID);
> > +
> > +   /* Set up class code for MT7622 */
> > +   val = PCI_CLASS_BRIDGE_PCI << 16;
> > +   writel(val, port->base + PCIE_CONF_CLASS);
> 
> 1) Your comments mention MT7622 specifically, but this code is run for
> both mt2712-pcie and mt7622-pcie.  If this code is safe and necessary
> for both mt2712-pcie and mt7622-pcie, please remove the mention of
> MT7622.

Hmm, the code snippet added here will only be executed by MT7622, since
MT2712 will not enter this  "if (pcie->base) {"  condition.
Should the mention of MT7622 must be removed in this case?

> 
> 2) The first comment mentions both "vendor ID and device ID" but you
> don't write the device ID.  Since this code applies to both
> mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> write the device ID.  If that's the case, please fix the comment.
> 

My bad, I did not check the comments carefully.
Thanks.

> 3) If you only need to set the vendor ID, you're performing a 32-bit
> write (writel()) to update a 16-bit value.  Please use writew()
> instead.
> 

Ok, thanks, I guess I could use the following code snippet in the next
version:
val = readl(port->base + PCIE_CONF_VENDOR_ID)
val &= ~GENMASK(15, 0);
val |= PCI_VENDOR_ID_MEDIATEK;
writel(val, port->base + PCIE_CONF_VENDOR_ID);

> 4) If you only need to set the vendor ID, please use a definition like
> "PCIE_CONF_VENDOR_ID" instead of the ambiguous "PCIE_CONF_ID".
> 
> 5) If you only need to set the vendor ID, please update the changelog
> to mention "vendor ID" specifically instead of the ambiguous "IDs".

> 6) Please add a space before the closing "*/" of the first comment.
> 
> 7) PCI_CLASS_BRIDGE_PCI is for a PCI-to-PCI bridge, i.e., one that has
> PCI on both the primary (upstream) side and the secondary (downstream)
> side.  That kind of bridge has a type 1 config header (see
> PCI_HEADER_TYPE) and the PCI_PRIMARY_BUS and PCI_SECONDARY_BUS
> registers tell us the bus number of the primary and secondary sides.
> 
> I don't believe this device is a PCI-to-PCI bridge.  I think it's a
> *host* bridge that has some non-PCI interface on the upstream side and
> should have a type 0 config header.  If that's the case you should use
> PCI_CLASS_BRIDGE_HOST instead.
> 

Thanks very much for your help with the review, I will fix the other
issue in the next version.

> > }
> >  
> > /* Assert all reset signals */
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index ab20dc5..2480b0e 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2113,6 +2113,8 @@
> >  
> >  #define PCI_VENDOR_ID_MYRICOM  0x14c1
> >  
> > +#define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > +
> >  #define PCI_VENDOR_ID_TITAN0x14D2
> >  #define PCI_DEVICE_ID_TITAN_010L   0x8001
> >  #define PCI_DEVICE_ID_TITAN_100L   0x8010
> > -- 
> > 2.6.4
> > 

Re: [PATCH v4 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Honghui Zhang]

On Mon, 2017-12-25 at 18:27 +0800, Ryder Lee wrote:
> On Fri, 2017-12-22 at 13:39 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > 
> > The hardware default value of IDs and class type is not correct,
> > fix that by setup the correct values before start up.
> > 
> > Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 12 
> >  include/linux/pci_ids.h  |  3 +++
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index fc29a9a..0ef33e4 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -74,6 +74,10 @@
> >  
> >  /* PCIe V2 per-port registers */
> >  #define PCIE_MSI_VECTOR0x0c0
> > +
> > +#define PCIE_CONF_ID   0x100
> > +#define PCIE_CONF_CLASS0x104
> > +
> >  #define PCIE_INT_MASK  0x420
> >  #define INTX_MASK  GENMASK(19, 16)
> >  #define INTX_SHIFT 16
> > @@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > val |= PCIE_CSR_LTSSM_EN(port->slot) |
> >PCIE_CSR_ASPM_L1_EN(port->slot);
> > writel(val, pcie->base + PCIE_SYS_CFG_V2);
> > +
> > +   /* Set up vendor ID and device ID for MT7622*/
> > +   val = PCI_VENDOR_ID_MEDIATEK | (PCI_DEVICE_ID_MT7622 << 16);
> > +   writel(val, port->base + PCIE_CONF_ID);
> 
> IMHO, this is a general function so you can ignore "device ID for
> MT7622" here, but just make sure class code/vendor ID correct.

Hmm, this condition is only for MT7622 for now.
Well, host driver and framework does not cares about the device ID for
host bridge. I guess I can bypass the setting of device ID.

thanks.

> 
> > +   /* Set up class code for MT7622 */
> > +   val = PCI_CLASS_BRIDGE_PCI << 16;
> > +   writel(val, port->base + PCIE_CONF_CLASS);
> > }
> >  
> > /* Assert all reset signals */
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index ab20dc5..000c5df 100644

> 

Re: [PATCH v4 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Honghui Zhang]

On Mon, 2017-12-25 at 18:27 +0800, Ryder Lee wrote:
> On Fri, 2017-12-22 at 13:39 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The hardware default value of IDs and class type is not correct,
> > fix that by setup the correct values before start up.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 12 
> >  include/linux/pci_ids.h  |  3 +++
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index fc29a9a..0ef33e4 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -74,6 +74,10 @@
> >  
> >  /* PCIe V2 per-port registers */
> >  #define PCIE_MSI_VECTOR0x0c0
> > +
> > +#define PCIE_CONF_ID   0x100
> > +#define PCIE_CONF_CLASS0x104
> > +
> >  #define PCIE_INT_MASK  0x420
> >  #define INTX_MASK  GENMASK(19, 16)
> >  #define INTX_SHIFT 16
> > @@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct 
> > mtk_pcie_port *port)
> > val |= PCIE_CSR_LTSSM_EN(port->slot) |
> >PCIE_CSR_ASPM_L1_EN(port->slot);
> > writel(val, pcie->base + PCIE_SYS_CFG_V2);
> > +
> > +   /* Set up vendor ID and device ID for MT7622*/
> > +   val = PCI_VENDOR_ID_MEDIATEK | (PCI_DEVICE_ID_MT7622 << 16);
> > +   writel(val, port->base + PCIE_CONF_ID);
> 
> IMHO, this is a general function so you can ignore "device ID for
> MT7622" here, but just make sure class code/vendor ID correct.

Hmm, this condition is only for MT7622 for now.
Well, host driver and framework does not cares about the device ID for
host bridge. I guess I can bypass the setting of device ID.

thanks.

> 
> > +   /* Set up class code for MT7622 */
> > +   val = PCI_CLASS_BRIDGE_PCI << 16;
> > +   writel(val, port->base + PCIE_CONF_CLASS);
> > }
> >  
> > /* Assert all reset signals */
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index ab20dc5..000c5df 100644

> 

Re: [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622

[Honghui Zhang]

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, honghui.zh...@mediatek.com wrote:
> > > > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > > > 
> > > > The host bridge of MT7622 has hardware code the class code to an
> > > > arbitrary, meaningless value, fix that.
> > > > 
> > > > Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> > > > ---
> > > >  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

Re: [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622

[Honghui Zhang]

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, honghui.zh...@mediatek.com wrote:
> > > > From: Honghui Zhang 
> > > > 
> > > > The host bridge of MT7622 has hardware code the class code to an
> > > > arbitrary, meaningless value, fix that.
> > > > 
> > > > Signed-off-by: Honghui Zhang 
> > > > ---
> > > >  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

Re: [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622

[Honghui Zhang]

On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> On Thu, 2017-12-21 at 10:11 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > 
> > The host bridge of MT7622 has hardware code the class code to an
> > arbitrary, meaningless value, fix that.
> > 
> > Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> > ---
> >  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);
> 
> 

Re: [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622

[Honghui Zhang]

On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> On Thu, 2017-12-21 at 10:11 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > The host bridge of MT7622 has hardware code the class code to an
> > arbitrary, meaningless value, fix that.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  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);
> 
> 

Re: [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

[Honghui Zhang]

On Thu, 2017-12-21 at 10:08 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang <honghui.zh...@mediatek.com>
> 
> 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.
> 

Sorry about the noise, to the wrong mail group, please ignore this.
thanks.

> 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(-)
> 

Re: [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

[Honghui Zhang]

On Thu, 2017-12-21 at 10:08 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> 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.
> 

Sorry about the noise, to the wrong mail group, please ignore this.
thanks.

> 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(-)
> 

Re: [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry

[Honghui Zhang]

On Wed, 2017-12-20 at 18:52 -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo, please cc him on all drivers/{host,dwc,endpoint} material]
> 
> Please run "git log --oneline drivers/pci/host/pcie-mediatek.c" and
> make yours match.  Same capitalization, same sentence structure, etc.,
> e.g.,
> 
>   PCI: mediatek: Clear IRQ status ...
> 
> s/dispathed/dispatched/
> 
> s/irq/IRQ/ in the summary and all the English text below.

Thanks for your review and sorry for the mismatch, I will fix that in
next version.

> 
> On Wed, Dec 20, 2017 at 10:52:14AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > 
> > There maybe a same irq reentry scenario after irq received in current
> > irq handle flow:
> > EP device   PCIe host driverEP 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 dead loop from
> 
> By "dead loop" I assume you mean "infinite loop"?  I don't think it's
> a deadlock since nothing is waiting.
> 
Yes, it should be "infinite loop", I will update the commit message in
next version.

thanks.
> > step 2 to step 4.
> > Clear the irq status after irq have been dispatched to avoid the irq
> > reentry.
> > 
> > Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> > ---
> >  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, , 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, _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
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry

[Honghui Zhang]

On Wed, 2017-12-20 at 18:52 -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo, please cc him on all drivers/{host,dwc,endpoint} material]
> 
> Please run "git log --oneline drivers/pci/host/pcie-mediatek.c" and
> make yours match.  Same capitalization, same sentence structure, etc.,
> e.g.,
> 
>   PCI: mediatek: Clear IRQ status ...
> 
> s/dispathed/dispatched/
> 
> s/irq/IRQ/ in the summary and all the English text below.

Thanks for your review and sorry for the mismatch, I will fix that in
next version.

> 
> On Wed, Dec 20, 2017 at 10:52:14AM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > There maybe a same irq reentry scenario after irq received in current
> > irq handle flow:
> > EP device   PCIe host driverEP 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 dead loop from
> 
> By "dead loop" I assume you mean "infinite loop"?  I don't think it's
> a deadlock since nothing is waiting.
> 
Yes, it should be "infinite loop", I will update the commit message in
next version.

thanks.
> > step 2 to step 4.
> > Clear the irq status after irq have been dispatched to avoid the irq
> > reentry.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  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, , 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, _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
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] PCI: mediatek: take use of PCI_NUM_INTX

[Honghui Zhang]

On Wed, 2017-08-30 at 09:19 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang <honghui.zh...@mediatek.com>
> 
> Switch from using a custom NUM_INTX macro to the generic PCI_NUM_INTX
> definition for the number of INTx interrupts.
> 
> Signed-off-by: Honghui Zhang <honghui.zh...@mediatek.com>
> ---
>  drivers/pci/host/pcie-mediatek.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 

Hi, Bjorn, Ryder,
this patch is based on Paul's v7 version of patch[1]("Move enum
pci_interrupt_pin to linux/pci.h").
[1]http://www.spinics.net/lists/linux-pci/msg63891.html

Thanks.

> diff --git a/drivers/pci/host/pcie-mediatek.c 
> b/drivers/pci/host/pcie-mediatek.c
> index c567996..5c0ce9b 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -77,7 +77,6 @@
>  #define PCIE_INT_MASK0x420
>  #define INTX_MASKGENMASK(19, 16)
>  #define INTX_SHIFT   16
> -#define INTX_NUM 4
>  #define PCIE_INT_STATUS  0x424
>  #define MSI_STATUS   BIT(23)
>  #define PCIE_IMSI_STATUS 0x42c
> @@ -576,7 +575,7 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
> *port,
>   return -ENODEV;
>   }
>  
> - port->irq_domain = irq_domain_add_linear(pcie_intc_node, INTX_NUM,
> + port->irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
>_domain_ops, port);
>   if (!port->irq_domain) {
>   dev_err(dev, "failed to get INTx IRQ domain\n");
> @@ -594,7 +593,7 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void 
> *data)
>   u32 bit = INTX_SHIFT;
>  
>   while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> - for_each_set_bit_from(bit, , INTX_NUM + INTX_SHIFT) {
> + for_each_set_bit_from(bit, , PCI_NUM_INTX + INTX_SHIFT) {
>   /* Clear the INTx */
>   writel(1 << bit, port->base + PCIE_INT_STATUS);
>   virq = irq_find_mapping(port->irq_domain,

Re: [PATCH] PCI: mediatek: take use of PCI_NUM_INTX

[Honghui Zhang]

On Wed, 2017-08-30 at 09:19 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> Switch from using a custom NUM_INTX macro to the generic PCI_NUM_INTX
> definition for the number of INTx interrupts.
> 
> Signed-off-by: Honghui Zhang 
> ---
>  drivers/pci/host/pcie-mediatek.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 

Hi, Bjorn, Ryder,
this patch is based on Paul's v7 version of patch[1]("Move enum
pci_interrupt_pin to linux/pci.h").
[1]http://www.spinics.net/lists/linux-pci/msg63891.html

Thanks.

> diff --git a/drivers/pci/host/pcie-mediatek.c 
> b/drivers/pci/host/pcie-mediatek.c
> index c567996..5c0ce9b 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -77,7 +77,6 @@
>  #define PCIE_INT_MASK0x420
>  #define INTX_MASKGENMASK(19, 16)
>  #define INTX_SHIFT   16
> -#define INTX_NUM 4
>  #define PCIE_INT_STATUS  0x424
>  #define MSI_STATUS   BIT(23)
>  #define PCIE_IMSI_STATUS 0x42c
> @@ -576,7 +575,7 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
> *port,
>   return -ENODEV;
>   }
>  
> - port->irq_domain = irq_domain_add_linear(pcie_intc_node, INTX_NUM,
> + port->irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
>_domain_ops, port);
>   if (!port->irq_domain) {
>   dev_err(dev, "failed to get INTx IRQ domain\n");
> @@ -594,7 +593,7 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void 
> *data)
>   u32 bit = INTX_SHIFT;
>  
>   while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> - for_each_set_bit_from(bit, , INTX_NUM + INTX_SHIFT) {
> + for_each_set_bit_from(bit, , PCI_NUM_INTX + INTX_SHIFT) {
>   /* Clear the INTx */
>   writel(1 << bit, port->base + PCIE_INT_STATUS);
>   virq = irq_find_mapping(port->irq_domain,

Re: [RESEND PATCH 1/2] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Honghui Zhang]

On Fri, 2017-08-11 at 09:37 +0800, Jun Gao wrote:
> On Thu, 2017-08-10 at 16:19 +0800, Honghui Zhang wrote:
> > On Thu, 2017-08-10 at 10:27 +0800, Jun Gao wrote:
> > > From: Jun Gao <jun@mediatek.com>
> > > 
> > > Add MT7622 i2c binding to binding file. Compare to MT8173 i2c
> > > controller, MT7622 limits message numbers to 255, and does not
> > > support 4GB DMA mode.
> > > 
> > > Signed-off-by: Jun Gao <jun@mediatek.com>
> > > ---
> > >  Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
> > >  1 file changed, 6 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
> > > b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> > > index bd5a7be..ff9ac61 100644
> > > --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> > > +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> > > @@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with 
> > > I2C devices.
> > >  
> > >  Required properties:
> > >- compatible: value should be either of the following.
> > > -  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
> > > -  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
> > > -  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
> > > -  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible 
> > > with mt7623.
> > > -  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
> > > + "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek MT2701
> > > + "mediatek,mt6577-i2c": for Mediatek MT6577
> > > + "mediatek,mt6589-i2c": for Mediatek MT6589
> > 
> > Better not change those and just add compatible strings for mt7622.
> > 
> It seems better to use the same format for all SoCs. 
> 

Alright, do you need to put those changes in commit message?
Thanks.

> Jun
> > > + "mediatek,mt7622-i2c": for Mediatek MT7622
> > > + "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for Mediatek MT7623
> > > + "mediatek,mt8173-i2c": for Mediatek MT8173
> > >- reg: physical base address of the controller and dma base, length of 
> > > memory
> > >  mapped region.
> > >- interrupts: interrupt number to the cpu.
> > 
> > 
> 
> 

Re: [RESEND PATCH 1/2] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Honghui Zhang]

On Fri, 2017-08-11 at 09:37 +0800, Jun Gao wrote:
> On Thu, 2017-08-10 at 16:19 +0800, Honghui Zhang wrote:
> > On Thu, 2017-08-10 at 10:27 +0800, Jun Gao wrote:
> > > From: Jun Gao 
> > > 
> > > Add MT7622 i2c binding to binding file. Compare to MT8173 i2c
> > > controller, MT7622 limits message numbers to 255, and does not
> > > support 4GB DMA mode.
> > > 
> > > Signed-off-by: Jun Gao 
> > > ---
> > >  Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
> > >  1 file changed, 6 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
> > > b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> > > index bd5a7be..ff9ac61 100644
> > > --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> > > +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> > > @@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with 
> > > I2C devices.
> > >  
> > >  Required properties:
> > >- compatible: value should be either of the following.
> > > -  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
> > > -  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
> > > -  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
> > > -  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible 
> > > with mt7623.
> > > -  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
> > > + "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek MT2701
> > > + "mediatek,mt6577-i2c": for Mediatek MT6577
> > > + "mediatek,mt6589-i2c": for Mediatek MT6589
> > 
> > Better not change those and just add compatible strings for mt7622.
> > 
> It seems better to use the same format for all SoCs. 
> 

Alright, do you need to put those changes in commit message?
Thanks.

> Jun
> > > + "mediatek,mt7622-i2c": for Mediatek MT7622
> > > + "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for Mediatek MT7623
> > > + "mediatek,mt8173-i2c": for Mediatek MT8173
> > >- reg: physical base address of the controller and dma base, length of 
> > > memory
> > >  mapped region.
> > >- interrupts: interrupt number to the cpu.
> > 
> > 
> 
> 

Re: [RESEND PATCH 1/2] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Honghui Zhang]

On Thu, 2017-08-10 at 10:27 +0800, Jun Gao wrote:
> From: Jun Gao 
> 
> Add MT7622 i2c binding to binding file. Compare to MT8173 i2c
> controller, MT7622 limits message numbers to 255, and does not
> support 4GB DMA mode.
> 
> Signed-off-by: Jun Gao 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> index bd5a7be..ff9ac61 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> @@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C 
> devices.
>  
>  Required properties:
>- compatible: value should be either of the following.
> -  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
> -  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
> -  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
> -  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with 
> mt7623.
> -  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
> + "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek MT2701
> + "mediatek,mt6577-i2c": for Mediatek MT6577
> + "mediatek,mt6589-i2c": for Mediatek MT6589

Better not change those and just add compatible strings for mt7622.

> + "mediatek,mt7622-i2c": for Mediatek MT7622
> + "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for Mediatek MT7623
> + "mediatek,mt8173-i2c": for Mediatek MT8173
>- reg: physical base address of the controller and dma base, length of 
> memory
>  mapped region.
>- interrupts: interrupt number to the cpu.

Re: [RESEND PATCH 1/2] dt-bindings: i2c: Add MediaTek MT7622 i2c binding

[Honghui Zhang]

On Thu, 2017-08-10 at 10:27 +0800, Jun Gao wrote:
> From: Jun Gao 
> 
> Add MT7622 i2c binding to binding file. Compare to MT8173 i2c
> controller, MT7622 limits message numbers to 255, and does not
> support 4GB DMA mode.
> 
> Signed-off-by: Jun Gao 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> index bd5a7be..ff9ac61 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
> @@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C 
> devices.
>  
>  Required properties:
>- compatible: value should be either of the following.
> -  "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701
> -  "mediatek,mt6577-i2c": for i2c compatible with mt6577.
> -  "mediatek,mt6589-i2c": for i2c compatible with mt6589.
> -  "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with 
> mt7623.
> -  "mediatek,mt8173-i2c": for i2c compatible with mt8173.
> + "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek MT2701
> + "mediatek,mt6577-i2c": for Mediatek MT6577
> + "mediatek,mt6589-i2c": for Mediatek MT6589

Better not change those and just add compatible strings for mt7622.

> + "mediatek,mt7622-i2c": for Mediatek MT7622
> + "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for Mediatek MT7623
> + "mediatek,mt8173-i2c": for Mediatek MT8173
>- reg: physical base address of the controller and dma base, length of 
> memory
>  mapped region.
>- interrupts: interrupt number to the cpu.

Re: [PATCH v2 4/5] PCI: mediatek: Add new generation controller support

[Honghui Zhang]

On Tue, 2017-08-08 at 15:19 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 04, 2017 at 08:18:09AM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 04, 2017 at 04:39:36PM +0800, Honghui Zhang wrote:
> > > On Thu, 2017-08-03 at 17:42 -0500, Bjorn Helgaas wrote:
> 
> > > > > + port->irq_domain = irq_domain_add_linear(pcie_intc_node, 
> > > > > INTX_NUM,
> > > > > +  _domain_ops, 
> > > > > port);
> > > > 
> > > > I think there's an issue here with a 4-element IRQ domain and the
> > > > hwirq numbers 1-4 from the of_irq_parse_and_map_pci() path, so INTD
> > > > may not work correctly.
> > > > 
> > > > See
> > > > http://lkml.kernel.org/r/20170801212931.ga26...@bhelgaas-glaptop.roam.corp.google.com
> > > > and related discussion.
> > > 
> > > Sorry, I did not get this,
> > > I do some test with an intel E350T4 PCIe NICs, it's a x1 lane
> > > multi-function device.
> > > What I got from the log is below:
> > > ->of_irq_parse_and_map_pci
> > >   ->of_irq_parse_pci
> > >   ->irq_create_of_mapping
> > >   ->irq_create_fwspec_mapping
> > >   ->irq_domain_translate
> > >   which will go through
> > >   d->ops->translate #the hwirq really start from 0
> > > 
> > > And I tested every NIC port of the Intel E350T4 with tftp transfer data,
> > > seems all are OK with this code.
> > 
> > OK.  I don't know what d->ops->translate is involved here, but if it
> > works, I guess this is OK for now.  We're trying to clean this up and
> > make it consistent across all the drivers.  Many of them allocate a
> > 5-element IRQ domain, some make a 4-element domain, and on some of
> > them INTD doesn't work.  It's a mess.
> 
> Paul Burton is cleaning this up.  Can you point out the d->ops->translate
> function that's involved here?

Hi, Bjorn,

Sorry for my last reply, I was tracking the wrong logs. The real trick
is here:

->of_irq_parse_and_map_pci
  ->of_irq_parse_pci#out_irq->args[0] start from 1(1 == INTA)
 ->of_irq_parse_raw

After of_irq_parse_raw finished it's work, the out_irq->args[0] will be
remapped as "interrupt-map" property defines[1], which in my case, it's
start from 0, and then fwspec->param[0] is start from 0 (0 == INTA).

My "interrupt-map" property is defined as below:
interrupt-map = <0 0 0 1 _intc0 0>,
<0 0 0 2 _intc0 1>,
<0 0 0 3 _intc0 2>,
<0 0 0 4 _intc0 3>;

I do some test with the changes of property defined as below:
interrupt-map = <0 0 0 1 _intc0 1>,
<0 0 0 2 _intc0 2>,
<0 0 0 3 _intc0 3>,
<0 0 0 4 _intc0 4>;
Then I got the same running complain as Paul have got[2]

So I guess it's the "interrupt-map" property defined in dtsi node play
the key role in this.

[1]http://elixir.free-electrons.com/linux/v4.13-rc4/source/drivers/of/irq.c#L265
[2]https://patchwork.kernel.org/patch/9794355

thanks.

Re: [PATCH v2 4/5] PCI: mediatek: Add new generation controller support

[Honghui Zhang]

On Tue, 2017-08-08 at 15:19 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 04, 2017 at 08:18:09AM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 04, 2017 at 04:39:36PM +0800, Honghui Zhang wrote:
> > > On Thu, 2017-08-03 at 17:42 -0500, Bjorn Helgaas wrote:
> 
> > > > > + port->irq_domain = irq_domain_add_linear(pcie_intc_node, 
> > > > > INTX_NUM,
> > > > > +  _domain_ops, 
> > > > > port);
> > > > 
> > > > I think there's an issue here with a 4-element IRQ domain and the
> > > > hwirq numbers 1-4 from the of_irq_parse_and_map_pci() path, so INTD
> > > > may not work correctly.
> > > > 
> > > > See
> > > > http://lkml.kernel.org/r/20170801212931.ga26...@bhelgaas-glaptop.roam.corp.google.com
> > > > and related discussion.
> > > 
> > > Sorry, I did not get this,
> > > I do some test with an intel E350T4 PCIe NICs, it's a x1 lane
> > > multi-function device.
> > > What I got from the log is below:
> > > ->of_irq_parse_and_map_pci
> > >   ->of_irq_parse_pci
> > >   ->irq_create_of_mapping
> > >   ->irq_create_fwspec_mapping
> > >   ->irq_domain_translate
> > >   which will go through
> > >   d->ops->translate #the hwirq really start from 0
> > > 
> > > And I tested every NIC port of the Intel E350T4 with tftp transfer data,
> > > seems all are OK with this code.
> > 
> > OK.  I don't know what d->ops->translate is involved here, but if it
> > works, I guess this is OK for now.  We're trying to clean this up and
> > make it consistent across all the drivers.  Many of them allocate a
> > 5-element IRQ domain, some make a 4-element domain, and on some of
> > them INTD doesn't work.  It's a mess.
> 
> Paul Burton is cleaning this up.  Can you point out the d->ops->translate
> function that's involved here?

Hi, Bjorn,

Sorry for my last reply, I was tracking the wrong logs. The real trick
is here:

->of_irq_parse_and_map_pci
  ->of_irq_parse_pci#out_irq->args[0] start from 1(1 == INTA)
 ->of_irq_parse_raw

After of_irq_parse_raw finished it's work, the out_irq->args[0] will be
remapped as "interrupt-map" property defines[1], which in my case, it's
start from 0, and then fwspec->param[0] is start from 0 (0 == INTA).

My "interrupt-map" property is defined as below:
interrupt-map = <0 0 0 1 _intc0 0>,
<0 0 0 2 _intc0 1>,
<0 0 0 3 _intc0 2>,
<0 0 0 4 _intc0 3>;

I do some test with the changes of property defined as below:
interrupt-map = <0 0 0 1 _intc0 1>,
<0 0 0 2 _intc0 2>,
<0 0 0 3 _intc0 3>,
<0 0 0 4 _intc0 4>;
Then I got the same running complain as Paul have got[2]

So I guess it's the "interrupt-map" property defined in dtsi node play
the key role in this.

[1]http://elixir.free-electrons.com/linux/v4.13-rc4/source/drivers/of/irq.c#L265
[2]https://patchwork.kernel.org/patch/9794355

thanks.

Re: [PATCH] memory: mtk-smi: Handle return value of clk_prepare_enable

[Honghui Zhang]

On Tue, 2017-08-08 at 11:06 +0530, Arvind Yadav wrote:
> clk_prepare_enable() can fail here and we must check its return value.
> 
> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
> ---

Hi, Arvind,
please rebase this to my latest patchset[1], it's been applied by Joerg.
And please send this one to Joerg and iommu mail list.

otherwise:
Acked-by: Honghui Zhang <honghui.zh...@mediatek.com>

[1]https://lkml.org/lkml/2017/8/3/968

Thanks.
>  drivers/memory/mtk-smi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 4afbc41..edf36f0 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -321,6 +321,7 @@ static int mtk_smi_common_probe(struct platform_device 
> *pdev)
>   struct resource *res;
>   const struct of_device_id *of_id;
>   enum mtk_smi_gen smi_gen;
> + int ret;
>  
>   if (!dev->pm_domain)
>   return -EPROBE_DEFER;
> @@ -359,7 +360,9 @@ static int mtk_smi_common_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(common->clk_async))
>   return PTR_ERR(common->clk_async);
>  
> - clk_prepare_enable(common->clk_async);
> + ret = clk_prepare_enable(common->clk_async);
> + if (ret)
> + return ret;
>   }
>   pm_runtime_enable(dev);
>   platform_set_drvdata(pdev, common);

Re: [PATCH] memory: mtk-smi: Handle return value of clk_prepare_enable

[Honghui Zhang]

On Tue, 2017-08-08 at 11:06 +0530, Arvind Yadav wrote:
> clk_prepare_enable() can fail here and we must check its return value.
> 
> Signed-off-by: Arvind Yadav 
> ---

Hi, Arvind,
please rebase this to my latest patchset[1], it's been applied by Joerg.
And please send this one to Joerg and iommu mail list.

otherwise:
Acked-by: Honghui Zhang 

[1]https://lkml.org/lkml/2017/8/3/968

Thanks.
>  drivers/memory/mtk-smi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 4afbc41..edf36f0 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -321,6 +321,7 @@ static int mtk_smi_common_probe(struct platform_device 
> *pdev)
>   struct resource *res;
>   const struct of_device_id *of_id;
>   enum mtk_smi_gen smi_gen;
> + int ret;
>  
>   if (!dev->pm_domain)
>   return -EPROBE_DEFER;
> @@ -359,7 +360,9 @@ static int mtk_smi_common_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(common->clk_async))
>   return PTR_ERR(common->clk_async);
>  
> - clk_prepare_enable(common->clk_async);
> + ret = clk_prepare_enable(common->clk_async);
> + if (ret)
> + return ret;
>   }
>   pm_runtime_enable(dev);
>   platform_set_drvdata(pdev, common);

Re: [PATCH v3 5/6] PCI: mediatek: Add new generation controller support

[Honghui Zhang]

On Sun, 2017-08-06 at 10:06 +0800, Ryder Lee wrote:
> Hi Honghui,
> 
> If you plan to send next version, then I would suggest some minor
> changes.
> 
> On Fri, 2017-08-04 at 20:06 +0800, honghui.zh...@mediatek.com wrote:
> > +#define PCIE_CRSTB BIT(3)
> > +#define PCIE_PERSTBBIT(8)
> > +#define PCI_LINKDOWN_RST_ENGENMASK(15, 13)
> 
> PCIE_LINKDOWN_RST_EN

Thanks, I will change it in the next version.

> 
> > +#define PCIE_LINK_STATUS_V20x804
> > +#define PCIE_PORT_LINKUP_V2BIT(10)
> > +
> > +
> > +static int mtk_pcie_hw_rd_cfg(struct mtk_pcie_port *port, u32 bus, u32 
> > devfn,
> > + int where, int size, u32 *val)
> > +{
> > +   int reg, shift = 8 * (where & 3);
> 
> int reg => u32

sharp eyes, thanks.

> 
> > +   /* Write PCIe Configuration Transaction Header for cfgrd */
> > +   writel(CFG_HEADER_DW0(CFG_WRRD_TYPE_0, CFG_RD_FMT),
> > +  port->base + PCIE_CFG_HEADER0);
> > +   writel(CFG_HEADER_DW1(where, size), port->base + PCIE_CFG_HEADER1);
> > +   writel(CFG_HEADER_DW2(where, PCI_FUNC(devfn), PCI_SLOT(devfn), bus),
> > +  port->base + PCIE_CFG_HEADER2);
> > +
> > +   /* Trigger h/w to transmit Cfgrd TLP */
> > +   reg = readl(port->base + PCIE_APP_TLP_REQ);
> > +   writel(reg | APP_CFG_REQ, port->base + PCIE_APP_TLP_REQ);
> > +
> > +   /* Check completion status */
> > +   if (mtk_pcie_check_cfg_cpld(port))
> > +   return PCIBIOS_SET_FAILED;
> > +
> > +   /* Read cpld payload of Cfgrd */
> > +   *val = readl(port->base + PCIE_CFG_RDATA);
> > +
> > +   switch (size) {
> > +   case 4:
> > +   break;
> > +   case 3:
> > +   *val = (*val >> shift) & 0xff;
> > +   break;
> > +   case 2:
> > +   *val = (*val >> shift) & 0x;
> > +   break;
> > +   case 1:
> > +   *val = (*val >> shift) & 0xff;
> > +   break;
> > +   default:
> > +   return PCIBIOS_BAD_REGISTER_NUMBER;
> > +   }
> 
> Do we really need case 3? I guess case 1, 2 or 4 should be enough.
> 

I will change this as the following snippet:
if (size == 1)
*val = (*val >> (8 * (where & 3))) & 0xff;
else if (size == 2)
*val = (*val >> (8 * (where & 3))) & 0x;

thanks.

> > +   return PCIBIOS_SUCCESSFUL;
> > +}
> > +
> > +static int mtk_pcie_hw_wr_cfg(struct mtk_pcie_port *port, u32 bus, u32 
> > devfn,
> > + int where, int size, u32 val)
> > +{
> > +   /* Write PCIe Configuration Transaction Header for Cfgwr */
> > +   writel(CFG_HEADER_DW0(CFG_WRRD_TYPE_0, CFG_WR_FMT),
> > +  port->base + PCIE_CFG_HEADER0);
> > +   writel(CFG_HEADER_DW1(where, size), port->base + PCIE_CFG_HEADER1);
> > +   writel(CFG_HEADER_DW2(where, PCI_FUNC(devfn), PCI_SLOT(devfn), bus),
> > +  port->base + PCIE_CFG_HEADER2);
> > +
> > +   /* Write cfgwr data */
> > +   val = val << 8 * (where & 3);
> > +   writel(val, port->base + PCIE_CFG_WDATA);
> > +
> > +   /* Trigger h/w to transmit Cfgwr TLP */
> > +   val = readl(port->base + PCIE_APP_TLP_REQ);
> > +   val |= APP_CFG_REQ;
> > +   writel(val, port->base + PCIE_APP_TLP_REQ);
> > +
> > +   /* Check completion status */
> > +   return mtk_pcie_check_cfg_cpld(port);
> > +}
> > +
> > +static int mtk_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
> > +   int where, int size, u32 *val)
> > +{
> > +   struct mtk_pcie_port *port = NULL, *iter, *tmp;
> > +   struct mtk_pcie *pcie = bus->sysdata;
> > +   u32 bn = bus->number;
> > +   int ret;
> > +
> > +   list_for_each_entry_safe(iter, tmp, >ports, list)
> > +   if (iter->index == PCI_SLOT(devfn)) {
> > +   port = iter;
> > +   break;
> > +   }
> > +
> > +   if (!port) {
> > +   *val = ~0;
> > +   return PCIBIOS_DEVICE_NOT_FOUND;
> > +   }
> 
> list_for_each_entry(), since you don't really remove or free something.
> 
> I know you need to find port->base to write/read configuration space. I
> think it's better to move this part to another function. You can take a
> look at pci-mvebu.c mvebu_pcie_find_portmvebu().


Sure, I will add the mtk_pcie_find_port interface, then the code is a
bit more readable.

thanks.

>  
> > +   ret = mtk_pcie_hw_rd_cfg(port, bn, devfn, where, size, val);
> > +   if (ret)
> > +   *val = ~0;
> > +
> > +   return ret;
> > +}
> > +
> > +static int mtk_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
> > +int where, int size, u32 val)
> > +{
> > +   struct mtk_pcie_port *port = NULL, *iter, *tmp;
> > +   struct mtk_pcie *pcie = bus->sysdata;
> > +   u32 bn = bus->number;
> > +
> > +   list_for_each_entry_safe(iter, tmp, >ports, list)
> > +   if (iter->index == PCI_SLOT(devfn)) {
> > +   port = iter;
> > +   break;
> > +   }
> > +
> > +   if (!port)
> > +   return PCIBIOS_DEVICE_NOT_FOUND;
> 
> Ditto.
> 
> >