linux-kernel - Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170718164438.GE20973@minitux>
Date:   Tue, 18 Jul 2017 09:44:38 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Varadarajan Narayanan <varada@...eaurora.org>
Cc:     bhelgaas@...gle.com, robh+dt@...nel.org, mark.rutland@....com,
        svarbanov@...sol.com, kishon@...com, sboyd@...eaurora.org,
        vivek.gautam@...eaurora.org, fengguang.wu@...el.com,
        weiyongjun1@...wei.com, linux-pci@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, smuthayy <smuthayy@...eaurora.org>
Subject: Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe
 controller

On Tue 18 Jul 02:58 PDT 2017, Varadarajan Narayanan wrote:

> On Mon, Jul 17, 2017 at 03:07:18PM -0700, Bjorn Andersson wrote:
> > On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote:
[..]
> >
> > Can you confirm that this is actually version 4 of this block? Or are we
> > just incrementing an arbitrary number here?
> 
> This is not exactly the 4th version of the block. However, it is
> a different version than the ones that are already supported in
> this driver. Since the existing driver didn't exactly tie it with
> the block IP version, I too followed the same versioning
> convention.
> 

Do you have a block IP version that you could base your numbering on, to
break the trend? (We should go back and fix up the others as well)

[..]
> > > +static int qcom_pcie_enable_resources_v4(struct qcom_pcie *pcie)
> > > +{
> > > +	struct qcom_pcie_resources_v4 *res = &pcie->res.v4;
> > > +	struct dw_pcie *pci = pcie->pci;
> > > +	struct device *dev = pci->dev;
> > > +	int ret;
> > > +
> > > +	ret = clk_prepare_enable(res->sys_noc_clk);
> > > +	if (ret) {
> > > +		dev_err(dev, "cannot prepare/enable core clock\n");
> > > +		return ret;
> > > +	}
> >
> > Should these clocks really be handled explicitly in the driver? Are
> > these not the bus clocks, to be handled by "msm_bus"?
> 
> This not the bus clock. This clock is for the Bus Interface Unit
> between the PCIe module and the System NOC.
> 

Right, that was the piece I meant. Sorry for not using the right
nomenclature.

So then it would be handled by the msm_bus in the downstream kernel?


Perhaps we can merge it like this and once we have the interconnect
framework setup we can make this the fallback method.

Thanks,
Bjorn