On Mon, Oct 21, 2019 at 08:26:28PM +0530, Pankaj Dubey wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: Monday, October 21, 2019 7:46 PM
> > To: Anvesh Salveru
> > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linu
On Mon, Oct 21, 2019 at 07:56:55PM +0530, Pankaj Dubey wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: Monday, October 21, 2019 7:47 PM
> > To: Pankaj Dubey
> > Cc: 'Anvesh Salveru' ; linux-...@vger.kernel.org;
> &g
On Mon, Oct 21, 2019 at 07:44:25PM +0530, Pankaj Dubey wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: Monday, October 21, 2019 7:34 PM
> > To: Anvesh Salveru
> > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
&g
imx6q-pcie.txt). Therefore
it feels like this is in the wrong place. Is there a reason this isn't
described in the Phy?
Thanks,
Andrew Murray
> + ZRX-DC specification.
> RC mode:
> - num-viewport: number of view ports configured in hardware. If a platform
>does not specify it, the driver assumes 2.
> --
> 2.17.1
>
RXDC_NONCOMPL;
> + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> + }
> +
Given that this duplicates tegra_pcie_prepare_host in pcie-tegra194.c, can
we update that driver to adopt this new binding?
Thanks,
Andrew Murray
> }
> diff --git a/drivers/pci/controller/dwc/pcie-des
st be enabled */
> + pcie_rc_cfg_wr_mask(lpp, PCI_EXP_LNKCTL_HAWD, 0,
> + PCIE_CAP_OFST + PCI_EXP_LNKCTL);
> + dw_pcie_link_width_resize(&lpp->pci, val);
> +
> + return len;
> +}
> +static DEVICE_ATTR_WO(pcie_
ct dw_pcie_host_ops intel_pcie_dw_ops = {
> + .host_init =intel_pcie_rc_init,
> + .msi_host_init =intel_pcie_msi_init,
> +};
> +
> +static const struct intel_pcie_soc pcie_data = {
> + .pcie_ver = 0x520A,
> + .pcie_atu_offset = 0xC
#x27;---' before the following (and thanks for the
detailed history).
Besides that:
Reviewed-by: Andrew Murray
>
> changes on v4:
> Add "snps,dw-pcie" compatible.
> Rename phy-names property value to pcie.
> And maximum and minimum values to num-la
On Mon, Oct 14, 2019 at 12:04:52PM +0200, Greg Kroah-Hartman wrote:
> The function pci_irq_get_node() is not used by anyone in the tree, so
> just delete it.
>
> Cc: Bjorn Helgaas
> Signed-off-by: Greg Kroah-Hartman
> ---
Reviewed-by: Andrew Murray
>
> diff --g
I've not had any feedback on this earlier series (in your link), I was
planning to review *this* patchset after that.
Thanks,
Andrew Murray
> Xiaowei Bao (6):
> PCI: mobiveil: Add the EP driver support
> dt-bindings: Add DT binding for PCIE GEN4 EP of the layerscape
> PCI: mo
On Tue, Oct 08, 2019 at 05:01:59PM -0700, Nathan Chancellor wrote:
> On Tue, Oct 08, 2019 at 04:59:25PM -0700, 'Sami Tolvanen' via Clang Built
> Linux wrote:
> > On Tue, Oct 8, 2019 at 4:31 PM Andrew Murray wrote:
> > > This looks good to me. I can build and
^
:4:21: note: instantiated into assembly here
.long 1b - ., "" - .
^
I'm assuming that I'm doing something wrong?
Thanks,
Andrew Murray
> ---
> v2:
> - Add a preamble to inline assembly blocks th
ctly acceptable
for the compiler to then throw in some LSE instructions at some point.
Thus something may break further down the line.
> 2. per function function attribute
> 3. per asm statement assembler directive
Keen to hear Will's thoughts - but I'd suggest this is probably the
On Tue, Oct 01, 2019 at 04:49:12PM -0500, Bjorn Helgaas wrote:
> On Tue, Oct 01, 2019 at 11:07:28AM +0100, Andrew Murray wrote:
> > Hi Tom,
> >
> > Thanks for the patch.
> >
> > I'd suggest that you rename the subject of this series to "PCI: caden
roperties:
> compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC;
> "renesas,pcie-r8a7744" for the R8A7744 SoC;
> "renesas,pcie-r8a774a1" for the R8A774A1 SoC;
> + "renesas,pcie-r8a774b1" for the R8A774B1
t;csr_write"
> passed 4 arguments, but takes just 2
> static void csr_write(struct mobiveil_pcie *pcie, u32 val, u32 off, size_t
> size)
>
> Cc: Hou Zhiqiang
> Cc: Lorenzo Pieralisi
> Cc: Minghuan Lian
> Cc: Subrahmanya Lingappa
> Cc: Andrew Murray
>
On Tue, Oct 01, 2019 at 04:48:14PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Oct 01, 2019 at 04:28:27PM +0100, Andrew Murray wrote:
> > I hadn't noticed the use of __OPTIMIZE__ - indeed if __compiletime_assert
> > is no-op'd and you reach it then you won'
On Tue, Oct 01, 2019 at 03:36:26PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Oct 01, 2019 at 12:41:30PM +0100, Andrew Murray wrote:
> > On Tue, Oct 01, 2019 at 11:42:54AM +0100, Will Deacon wrote:
> > > On Tue, Oct 01, 2019 at 06:40:26PM +0900, Masahiro Yamada wro
as this is a common pattern - isn't there a benefit
here for changing all of these to BUILD_BUG? (So they can be found easily).
Or to avoid this class of issues, change them to BUG or unreachable - but
lose the benefit of compile time detection?
Thanks,
Andrew Murray
[1] https://lore.kerne
On Tue, Oct 01, 2019 at 04:08:45PM +0530, Kishon Vijay Abraham I wrote:
> Hi Andrew Murray,
>
> On 01/10/19 3:37 PM, Andrew Murray wrote:
> > Hi Tom,
> >
> > Thanks for the patch.
> >
> > I'd suggest that you rename the subject of this series to &
max_regions;
> + u32 no_bar_nbits;
> + u16 vendor_id;
> + u16 device_id;
> };
>
> +/**
> + * struct cdns_pcie_ep - private data for this PCIe endpoint controller
> driver
> + * @pcie: Cadence PCIe controller
> + * @max_regions: maximum number of regions supported by hardware
> + * @ob_region_map: bitmask of mapped outbound regions
> + * @ob_addr: base addresses in the AXI bus where the outbound regions start
> + * @irq_phys_addr: base address on the AXI bus where the MSI/legacy IRQ
> + * dedicated outbound regions is mapped.
> + * @irq_cpu_addr: base address in the CPU space where a write access triggers
> + * the sending of a memory write (MSI) / normal message (legacy
> + * IRQ) TLP through the PCIe bus.
> + * @irq_pci_addr: used to save the current mapping of the MSI/legacy IRQ
> + * dedicated outbound region.
> + * @irq_pci_fn: the latest PCI function that has updated the mapping of
> + * the MSI/legacy IRQ dedicated outbound region.
> + * @irq_pending: bitmask of asserted legacy IRQs.
> + */
> +struct cdns_pcie_ep {
> + struct cdns_pciepcie;
> + struct device *dev;
> + u32 max_regions;
> + unsigned long ob_region_map;
> + phys_addr_t *ob_addr;
> + phys_addr_t irq_phys_addr;
> + void __iomem*irq_cpu_addr;
> + u64 irq_pci_addr;
> + u8 irq_pci_fn;
> + u8 irq_pending;
> +};
> +
> +
> /* Register access */
> static inline void cdns_pcie_writeb(struct cdns_pcie *pcie, u32 reg, u8
> value)
> {
> @@ -306,6 +372,9 @@ static inline u32 cdns_pcie_ep_fn_readl(struct cdns_pcie
> *pcie, u8 fn, u32 reg)
> return readl(pcie->reg_base + CDNS_PCIE_EP_FUNC_BASE(fn) + reg);
> }
>
> +int cdns_pcie_host_setup(struct cdns_pcie_rc *rc);
> +int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep);
> +
What happens if a user only selects the host bridge, will you get a build
error relating to cdns_plat_pcie_probe not being able to find an
implementation of cdns_pcie_ep_setup?
Thanks,
Andrew Murray
> void cdns_pcie_set_outbound_region(struct cdns_pcie *pcie, u8 fn,
> u32 r, bool is_io,
> u64 cpu_addr, u64 pci_addr, size_t size);
> --
> 2.2.2
>
On Mon, Sep 30, 2019 at 06:52:30PM +0200, Remi Pommarel wrote:
> On Mon, Sep 30, 2019 at 04:40:18PM +0100, Andrew Murray wrote:
> > On Wed, May 22, 2019 at 11:33:51PM +0200, Remi Pommarel wrote:
> > > Aardvark's PCI_EXP_LNKSTA_LT flag in its link status register is not
>
PCI_EXP_LNKCAP:
> - case PCI_EXP_LNKCTL:
> *value = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + reg);
> return PCI_BRIDGE_EMUL_HANDLED;
> default:
> @@ -447,8 +469,13 @@ advk_pci_bridge_emul_pcie_conf_write(struct
> pci_bridge_emul *bridge,
&
est.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -65,6 +65,7 @@
> #define PCI_ENDPOINT_TEST_IRQ_NUMBER 0x28
>
> #define PCI_DEVICE_ID_TI_AM654 0xb00c
> +#define PCI_DEVICE_ID_LS1088A0x80c0
Reviewed-by: Andrew Murray
&
On Tue, Sep 24, 2019 at 10:18:48AM +0800, Xiaowei Bao wrote:
> Add PCIe EP node for ls1088a to support EP mode.
>
> Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
> ---
> v2:
> - Remove the pf-offset proparty.
> v3:
> - No change.
> v4:
> - No chan
Remi Pommarel
>
> Acked-by: Thomas Petazzoni
>
Reviewed-by: Andrew Murray
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
+#define PCI_DEVICE_ID_LOONGSON_PCIE_X8 0x7a29
Hi Tiezhu,
Thanks for the patch - however it is preferred to provide new PCI definitions
along with the drivers that use them. They don't provide any useful value
without drivers that use them.
Thanks,
Andrew Murray
> +
> #endif /* _LINUX_PCI_IDS_H */
> --
> 2.1.0
>
>
t;csr_write"
> passed 4 arguments, but takes just 2
> static void csr_write(struct mobiveil_pcie *pcie, u32 val, u32 off, size_t
> size)
>
> Cc: Hou Zhiqiang
> Cc: Lorenzo Pieralisi
> Cc: Minghuan Lian
> Cc: Subrahmanya Lingappa
> Cc: Christoph Hellwig
On Tue, Sep 03, 2019 at 03:43:15AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: 2019年9月3日 0:26
> > To: Xiaowei Bao
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li ; kis
@ static void csr_write(struct mobiveil_pcie *pcie, u32
> val, u32 off, size_t size)
>
> static u32 csr_readl(struct mobiveil_pcie *pcie, u32 off)
> {
> - return csr_read(pcie, off, 0x4);
> + return __csr_read(pcie, off, 0x4);
> }
>
> static void csr_wri
just that.
>
> Signed-off-by: Marc Zyngier
Reviewed-by: Andrew Murray
> ---
> drivers/irqchip/irq-gic-v3-its.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-i
; + if (fixed_sec)
> next_busnr = fixed_sec;
> - else
> - next_busnr = max + 1;
There is a subtle style change here (assigning and then potentially reassigning
with a new value vs assigning once using both i
icit-function-declaration]
>
> Fixes: ab2a50e7602b ("PCI: tegra: Add support to configure sideband pins")
> Signed-off-by: Arnd Bergmann
Thanks for this. Another fix for this came in earlier today:
https://patchwork.ozlabs.org/patch/1165139/
Reviewed-by: Andrew Murray
Thanks,
Andrew
0e7602b ("PCI: tegra: Add support to configure sideband pins")
> Signed-off-by: YueHaibing
> Reviewed-by: Vidya Sagar
> ---
> v2: keep alphabetical order
> ---
Thanks,
Reviewed-by: Andrew Murray
> drivers/pci/controller/dwc/pcie-tegra194.c | 1 +
> 1 file change
> #include
> #include
Thanks for spotting and fixing this. Is it possible to keep the include
list in alphabetical order?
Thanks,
Andrew Murray
> --
> 2.7.4
>
>
On Wed, Sep 18, 2019 at 05:26:59PM +0300, Denis Efremov wrote:
> On 9/18/19 11:58 AM, Andrew Murray wrote:
> > On Mon, Sep 16, 2019 at 11:41:38PM +0300, Denis Efremov wrote:
> >> Remove local definition PCI_BAR_COUNT for the number of PCI BARs and use
> >> global o
On Wed, Sep 18, 2019 at 05:31:33PM +0300, Denis Efremov wrote:
> On 9/18/19 12:17 PM, Andrew Murray wrote:
> > On Mon, Sep 16, 2019 at 11:41:49PM +0300, Denis Efremov wrote:
> >> Refactor loops to use idiomatic C style and avoid the fencepost error
> >> of using "i
On Tue, Sep 17, 2019 at 12:36:37PM +0100, Andrew Murray wrote:
> Hi Hou Zhiqiang,
>
> Apologies if I bring up any feedback that has previously been discussed as
> I've only recently began reviewing controller patches.
>
> On Tue, Aug 13, 2019 at 11:03:57AM +, Z.q. H
exsiting
users after this patchset?
As your patchset replaces BAR_0 with 0 and BAR_1 with 1, does this suggest
that other users of BAR_x should be removed and also replaced with a number?
Apologies if you this doesn't fall in the remit of this patchset.
Thanks,
Andrew Murray
>
- for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
> - res = vdev->pdev->resource + bar;
> + for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> + int bar = i + PCI_STD_RESOURCES;
> +
> + res = &vdev->pdev->
clude/linux/pci-epf.h. There are mostly used with pci_ioremap_bar and
pci_resource_** macros. I wonder if this is an indicator that these defintions
should live in the core.
Thanks,
Andrew Murray
>
> #define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
> PCI_DEVICE(PCI_VENDOR_ID_INT
mio(struct
> pci_dev *pdev, int bar,
> void __iomem *pci_iomap_wc_range(struct pci_dev *pdev, int bar,
>unsigned long offset, unsigned long max)
> {
> - if (!pci_resource_len(pdev, bar) || bar >= PCI_BAR_COUNT)
> + if (bar >
_desc_get_handler_data(desc);
> struct device *dev = &pcie->pdev->dev;
> - struct mobiveil_msi *msi = &pcie->msi;
> + struct mobiveil_msi *msi = &pcie->rp.msi;
> u32 msi_data, msi_addr_lo, msi_addr_hi;
> u32 intr_status, msi_status;
> un
On Sat, Sep 14, 2019 at 04:10:22AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: 2019年9月12日 20:50
> > To: Xiaowei Bao
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li
MIPI clock for the Amlogic AXG SoC Family.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Rob Herring
> ---
Reviewed-by: Andrew Murray
> .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
>
y the MCU.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Andrew Murray
> ---
> .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 25 +++
> .../amlogic/meson-g12b-s922x-khadas-vim3.dts | 25 +++
> .../boot/dts/amlogic/meson-khadas-vim3.dtsi
rol node if the
> shared differential lines are used for PCIe instead of USB3.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Andrew Murray
> ---
> .../boot/dts/amlogic/meson-g12-common.dtsi| 33 +++
> arch/arm64/boot/dts/amlogic/meson-sm1.dtsi| 4 +++
egmap_cr;
> @@ -196,6 +198,10 @@ static int phy_g12a_usb3_init(struct phy *phy)
> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> int data, ret;
>
> + ret = reset_control_reset(priv->reset);
> + if (ret)
> + return ret;
Reviewed-by: Andre
gt; + if (ret) {
> + dev_err(dev, "reset failed, %d\n", ret);
> + goto err_phy;
> + }
>
> ret = meson_pcie_probe_clocks(mp);
> if (ret) {
> dev_err(dev, "init clock resources failed, %d\n", ret);
&g
On Mon, Sep 16, 2019 at 04:36:33PM +0530, Pankaj Dubey wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: Monday, September 16, 2019 3:46 PM
> > To: Pankaj Dubey
> > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
; #define PCIE_PORT_LINK_CONTROL 0x710
> #define PORT_LINK_MODE_MASK GENMASK(21, 16)
> @@ -60,6 +64,10 @@
> #define PCIE_MSI_INTR0_MASK 0x82C
> #define PCIE_MSI_INTR0_STATUS0x830
>
> +#define PCIE_PORT_GEN3_RELATED
he stack buffer and will produce the following print:
> BUG: KASAN: stack-out-of-bounds in find_next_bit+0x38/0xb0
>
> Fixes: 1b497e6493c4 ("PCI: dwc: Fix uninitialized variable in
> dw_handle_msi_irq()")
> Signed-off-by: Niklas Cassel
> ---
Reviewed-by: Andrew
On Tue, Sep 03, 2019 at 02:01:32AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: 2019年9月2日 21:06
> > To: Xiaowei Bao
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li
On Tue, Sep 03, 2019 at 01:52:30AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: 2019年9月2日 20:55
> > To: Xiaowei Bao
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li
On Tue, Sep 03, 2019 at 01:47:36AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: 2019年9月2日 20:46
> > To: Xiaowei Bao
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li
On Thu, Sep 12, 2019 at 05:09:41PM +0530, Pankaj Dubey wrote:
>
>
> > From: Andrew Murray
> >
> > On Tue, Sep 10, 2019 at 09:46:28PM +0530, Pankaj Dubey wrote:
> > > On Tue, 10 Sep 2019 at 19:56, Andrew Murray
> > wrote:
> > > >
> > &
On Thu, Sep 12, 2019 at 02:58:45PM +0800, Dilip Kota wrote:
> Hi Andrew Murray,
>
> On 9/11/2019 6:30 PM, Andrew Murray wrote:
> > On Tue, Sep 10, 2019 at 03:46:17PM +0800, Dilip Kota wrote:
> > > Hi Andrew Murray,
> > >
> > > Please find my respons
On Wed, Sep 11, 2019 at 02:58:18PM +0200, Neil Armstrong wrote:
> On 11/09/2019 14:50, Andrew Murray wrote:
> > On Sun, Sep 08, 2019 at 01:42:58PM +, Neil Armstrong wrote:
> >> The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> lines using a FU
On Wed, Sep 11, 2019 at 02:45:23PM +0200, Neil Armstrong wrote:
> On 11/09/2019 14:19, Andrew Murray wrote:
> > On Sun, Sep 08, 2019 at 01:42:56PM +, Neil Armstrong wrote:
> >> This adds extended PCIe PHY functions for the Amlogic G12A
> >> USB3+PCIE Combo PHY to
On Wed, Sep 11, 2019 at 02:39:42PM +0200, Neil Armstrong wrote:
> Hi Andrew,
>
> On 11/09/2019 13:36, Andrew Murray wrote:
> > On Sun, Sep 08, 2019 at 01:42:55PM +, Neil Armstrong wrote:
> >> Add support for the Amlogic G12A SoC using a separate shared PHY.
> &g
uot;, "usb2-phy1";
> +};
I assume there is no way other way to determine from the hardware which way
the mux is set?
Otherwise phy_g12a_usb3_pcie_xlate could determine the hardware mode, and
reject the phy instance with the wrong mode. Thus resulting in either the
PCI or USB to fail thei
ock as optional for G12A.
Perhaps reword to "Thus this adds a phy phandle to control the PHY,
and only requires a MIPI clock for AXG SoC Family".
Thanks,
Andrew Murray
>
> Signed-off-by: Neil Armstrong
> ---
> .../devicetree/bindings/pci/amlogic,meson-pcie.txt |
e've moved this to apply to USB only, thus assuming PCI will
call .reset for its reset (why the asymmetry?).
Thanks,
Andrew Murray
> /* Switch PHY to USB3 */
> /* TODO figure out how to handle when PCIe was set in the bootloader */
> regmap_update_bits(priv->r
return ret;
> + }
>
> ret = meson_pcie_probe_clocks(mp);
> if (ret) {
> @@ -575,9 +629,22 @@ static int meson_pcie_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static struct meson_pcie_param meson_pcie_axg_param = {
> + .has_shared_phy = false,
> +};
> +
> +static struct meson_pcie_param meson_pcie_g12a_param = {
> + .has_shared_phy = true,
> +};
> +
> static const struct of_device_id meson_pcie_of_match[] = {
> {
> .compatible = "amlogic,axg-pcie",
> + .data = &meson_pcie_axg_param,
> + },
> + {
> + .compatible = "amlogic,g12a-pcie",
> + .data = &meson_pcie_g12a_param,
Here, we hard-code knowledge about the SOCs regarding if they have shared phys
or not. I guess the alternative would have been to assume there is a shared
phy if the DT has a phandle for it. I.e. instead of mp->param->has_shared_phy
everywhere you could test for mp->phy. Though I guess at least with the
current approach you guard against bad DTs, this seems OK.
Thanks,
Andrew Murray
> },
> {},
> };
> --
> 2.17.1
>
On Sun, Sep 08, 2019 at 01:42:54PM +, Neil Armstrong wrote:
> Fix the clock names used in the probe function according
> to the bindings.
>
> Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller
> driver")
> Signed-off-by: Neil Armstrong
On Tue, Sep 10, 2019 at 03:46:17PM +0800, Dilip Kota wrote:
> Hi Andrew Murray,
>
> Please find my response inline.
>
> On 9/9/2019 4:31 PM, Andrew Murray wrote:
> > On Mon, Sep 09, 2019 at 02:51:03PM +0800, Dilip Kota wrote:
> > > On 9/6/2019 7:20 PM, Andrew Murray
On Tue, Sep 10, 2019 at 09:51:41PM +0530, Pankaj Dubey wrote:
> On Tue, 10 Sep 2019 at 19:59, Andrew Murray wrote:
> >
> > On Tue, Sep 10, 2019 at 05:55:02PM +0530, Pankaj Dubey wrote:
> > > From: Anvesh Salveru
> > >
> > > In some platforms, PCIe PHY
On Tue, Sep 10, 2019 at 09:46:28PM +0530, Pankaj Dubey wrote:
> On Tue, 10 Sep 2019 at 19:56, Andrew Murray wrote:
> >
> > On Tue, Sep 10, 2019 at 05:55:01PM +0530, Pankaj Dubey wrote:
> > > From: Anvesh Salveru
> > >
> > > In some platforms, PCIe PHY
line hacks have gone, I wonder if this is actually
still a problem anymore. In any case isn't the right thing to do there
to add the __always_inline to functions that use the register keyword
in a function currently annotated inline?
I'm happy to look into this if there is likely to be some ben
-designware.h
> @@ -31,6 +31,7 @@
>
> /* Parameters for PCIe Quirks */
> #define DWC_EQUALIZATION_DISABLE 0x1
> +#define DWC_EQ_PHASE_2_3_DISABLE 0x2
It only makes sense for either DWC_EQUALIZATION_DISABLE or
DWC_EQ_PHASE_2_3_DISABLE
to be specified, though if dwc_pci_quirk in
wc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -29,6 +29,9 @@
> #define LINK_WAIT_MAX_IATU_RETRIES 5
> #define LINK_WAIT_IATU 9
>
> +/* Parameters for PCIe Quirks */
> +#define DWC_EQUALIZATION_DISABLE 0x1
How abo
On Tue, Sep 10, 2019 at 11:38:37AM +0200, Arnd Bergmann wrote:
> On Tue, Sep 10, 2019 at 11:23 AM Andrew Murray wrote:
>
> >
> > > arch/arm64/include/asm/cmpxchg.h | 15 ---
> > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > >
&g
t grep -B 3 BUILD_BUG\( | grep default), most instances are
within macros, but many are found in an __always_inline function:
arch/x86/kvm/cpuid.h
mm/kasan/generic.c
Though some are not:
include/linux/signal.h
arch/arm64/include/asm/arm_dsu/pmu.h
I wonder if there may be a latent mole ready to whack with pmu.h?
Anyway with just the three remaining hunks:
Reviewed-by: Andrew Murray
Tested-by: Andrew Murray
> --
> 2.20.0
>
On Mon, Sep 09, 2019 at 02:51:03PM +0800, Dilip Kota wrote:
>
> On 9/6/2019 7:20 PM, Andrew Murray wrote:
> > On Fri, Sep 06, 2019 at 06:58:11PM +0800, Dilip Kota wrote:
> > > Hi Andrew Murray,
> > >
> > > Thanks for the review. Please find my response i
Markus Elfring
Thanks for this, looks good to me:
Reviewed-by: Andrew Murray
> ---
> drivers/pci/controller/dwc/pci-exynos.c | 5 +
> drivers/pci/controller/dwc/pci-meson.c | 10 ++
> drivers/pci/controller/dwc/pcie-kirin.c | 10 ++
> 3 files changed, 5 i
On Fri, Sep 06, 2019 at 06:58:11PM +0800, Dilip Kota wrote:
> Hi Andrew Murray,
>
> Thanks for the review. Please find my response inline.
>
> On 9/5/2019 6:45 PM, Andrew Murray wrote:
> > On Wed, Sep 04, 2019 at 06:10:31PM +0800, Dilip Kota wrote:
> > > Add su
On Fri, Sep 06, 2019 at 02:55:19PM +0530, Abhishek Shah wrote:
> Hi Andrew,
>
> Thanks for the review. Please see my response inline:
>
> On Fri, Sep 6, 2019 at 2:08 PM Andrew Murray wrote:
> >
> > On Fri, Sep 06, 2019 at 09:28:13AM +0530, Abhishek Shah wrote:
&g
t; iproc_pcie_perst_ctrl(pcie, false);
>
> + iproc_pcie_invalidate_mapping(pcie);
> +
> if (pcie->need_ob_cfg) {
> ret = iproc_pcie_map_ranges(pcie, res);
> if (ret) {
The code changes look good to me.
Thanks,
Andrew Murray
> --
> 2.17.1
>
t;dev, "Failed reading PCI_HEADER_TYPE cfg space reg
> (ret: 0x%x)\n",
> + ret);
> + ret = pcibios_err_to_errno(ret);
> + goto err_free_msi;
> + }
> + if (hdr_type != PCI_HEADER_TYPE_BRIDGE) {
> + dev_err(pci->dev,
results in the following warning print:
>
> pcieport 0001:00:00.0: VPD access failed. This is likely a firmware bug on
> this device. Contact the card vendor for a firmware update
>
> Signed-off-by: Jonathan Chocron
> Reviewed-by: Gustavo Pimentel
Reviewed-by: Andrew Murray
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct intel_pcie_port *lpp = dev_get_drvdata(pci->dev);
> + int ret;
> +
> + /* RC/host initialization */
> + ret = intel_pcie_host_setup(lpp);
> + if (ret)
> + return ret;
Insert new line here.
> + ret = intel_pcie_sysfs_init(lpp);
> + if (ret)
> + __intel_pcie_remove(lpp);
> + return ret;
> +}
> +
> +int intel_pcie_msi_init(struct pcie_port *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +
> + dev_dbg(pci->dev, "PCIe MSI/MSIx is handled by MSI in x86 processor\n");
What about other processors? (Noting that this driver doesn't depend on
any specific ARCH in the KConfig).
> + return 0;
> +}
> +
> +u64 intel_pcie_cpu_addr(struct dw_pcie *pcie, u64 cpu_addr)
> +{
> + return cpu_addr + BUS_IATU_OFFS;
> +}
> +
> +static const struct dw_pcie_ops intel_pcie_ops = {
> + .cpu_addr_fixup = intel_pcie_cpu_addr,
> +};
> +
> +static const struct dw_pcie_host_ops intel_pcie_dw_ops = {
> + .host_init =intel_pcie_rc_init,
> + .msi_host_init =intel_pcie_msi_init,
> +};
> +
> +static const struct intel_pcie_soc pcie_data = {
> + .pcie_ver = 0x520A,
> + .pcie_atu_offset = 0xC,
> + .num_viewport = 3,
> +};
> +
> +static int intel_pcie_probe(struct platform_device *pdev)
> +{
> + const struct intel_pcie_soc *data;
> + struct device *dev = &pdev->dev;
> + struct intel_pcie_port *lpp;
> + struct pcie_port *pp;
> + struct dw_pcie *pci;
> + int ret;
> +
> + lpp = devm_kzalloc(dev, sizeof(*lpp), GFP_KERNEL);
> + if (!lpp)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, lpp);
> + pci = &lpp->pci;
> + pci->dev = dev;
> + pp = &pci->pp;
> +
> + ret = intel_pcie_get_resources(pdev);
> + if (ret)
> + return ret;
> +
> + data = device_get_match_data(dev);
> + pci->ops = &intel_pcie_ops;
> + pci->version = data->pcie_ver;
> + pci->atu_base = pci->dbi_base + data->pcie_atu_offset;
> + pp->ops = &intel_pcie_dw_ops;
> +
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(dev, "cannot initialize host\n");
> + return ret;
> + }
Add a new line after the closing brace.
> + /* Intel PCIe doesn't configure IO region, so configure
> + * viewport to not to access IO region during register
> + * read write operations.
> + */
> + pci->num_viewport = data->num_viewport;
> + dev_info(dev,
> + "Intel AXI PCIe Root Complex Port %d Init Done\n", lpp->id);
> + return ret;
> +}
> +
> +static const struct dev_pm_ops intel_pcie_pm_ops = {
> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(intel_pcie_suspend_noirq,
> + intel_pcie_resume_noirq)
> +};
> +
> +static const struct of_device_id of_intel_pcie_match[] = {
> + { .compatible = "intel,lgm-pcie", .data = &pcie_data },
> + {}
> +};
> +
> +static struct platform_driver intel_pcie_driver = {
> + .probe = intel_pcie_probe,
> + .remove = intel_pcie_remove,
> + .driver = {
> + .name = "intel-lgm-pcie",
Is there a reason why the we use intel-lgm-pcie here and pcie-intel-axi
elsewhere? What does lgm mean?
Thanks,
Andrew Murray
> + .of_match_table = of_intel_pcie_match,
> + .pm = &intel_pcie_pm_ops,
> + },
> +};
> +builtin_platform_driver(intel_pcie_driver);
> --
> 2.11.0
>
On Wed, Sep 04, 2019 at 01:36:12PM +, Chocron, Jonathan wrote:
> On Thu, 2019-08-22 at 16:07 +0100, Andrew Murray wrote:
> > On Thu, Aug 22, 2019 at 02:36:24PM +, Chocron, Jonathan wrote:
> > > On Thu, 2019-08-22 at 12:41 +0100, Andrew Murray wrote:
> > > >
to nearest power of 2.
However this doesn't guarantee that pci_alloc_irq_vectors will return a
power of 2. For example if you set maxvec to 17, then it will request
32 from the device and pci_alloc_irq_vectors will return 17 (i.e. it satisfies
your request by over allocating, but still give
t.
- The current approach is preferable to adding DWC EP driver callbacks
for writing to the EP config space (e.g. a variant of dw_pcie_writew_dbi
that takes a func number).
I'm keen to hear feedback from Jingoo/Gustavo on this.
Thanks,
Andrew Murray
> ---
> v2:
> - Remov
ep_func->msix_cap = dw_pcie_ep_find_capability(ep, func_no,
> +PCI_CAP_ID_MSIX);
> +
> + list_add_tail(&ep_func->list, &ep->func_list);
> + }
Whilst your patch addresses the issue of giving each function the ab
comments I just made to Kishon's feedback in the thread for
this patch in series v2.
Thanks,
Andrew Murray
> ---
> v2:
> - Remove the repeated assignment code.
> v3:
> - Use ep_func msi_cap and msix_cap to decide the msi_capable and
>msix_capable of pci_epc_features st
. Instead of doing this, is it possible that you can determine the flags
based on the compatible type alone? For example, is the MSI/MSIX capability
the same for all fsl,ls2088a-pcie-ep devices?
If it isn't *necessary* to probe for this information at probe time, then
you could instead create
ot;;
Here you specify a fallback "fsl,ls-pcie-ep" that is removed by this series.
Besides that, this looks OK.
Thanks,
Andrew Murray
> + reg = <0x00 0x0340 0x0 0x0010
> +0x20 0x 0x8 0x>;
> +
EVICE(PCI_VENDOR_ID_FREESCALE, 0x80c0) },
The Freescale PCI devices are the only devices in this table that don't
have a define for their device ID. I think a define should be created
for both of the device IDs above.
Thanks,
Andrew Murray
> { PCI_DEVICE_DATA(SYNOPS
{ .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
> + { },
This removes support for "fsl,ls-pcie-ep" - was that intentional? If you do
plan to drop it please
erscape: Add EP mode..."
as that patch drops the fallback "fsl,ls-pcie-ep". Either the fallback must
be preserved in the driver, or you need to drop it here.
What if there are existing users that depend on the fallback?
(I'm also not sure if that comma should have been droppe
with MSIX support, but the existing
> dw_pcie_ep_raise_msix_irq doesn't work, so use the doorbell method to
> support the MSIX feature.
>
> Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
> ---
> v2:
> - No change
> v3:
> - Modify the commit message make
failed, the timeout will never happen and will also cause
> the cpu to stall.
>
> This decrements a variable and wait instead of using jiffies.
>
> Signed-off-by: Remi Pommarel
Reviewed-by: Andrew Murray
> ---
> drivers/pci/controller/pci-aardvark.c | 10 +-
>
On Wed, Aug 28, 2019 at 10:58:50PM +0530, Vidya Sagar wrote:
> Add 3.3V and 12V supplies regulators information of x16 PCIe slot in
> p2972- platform which is owned by C5 controller and also enable C5
> controller.
>
> Signed-off-by: Vidya Sagar
Reviewed-by: Andrew Murr
Signed-off-by: Vidya Sagar
Reviewed-by: Andrew Murray
> ---
> V3:
> * None
>
> V2:
> * None
>
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 38 +++-
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts
upplies.
>
> Signed-off-by: Vidya Sagar
Reviewed-by: Andrew Murray
> ---
> V3:
> * None
>
> V2:
> * None
>
> .../devicetree/bindings/pci/nvidia,tegra194-pcie.txt | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devic
On Wed, Aug 28, 2019 at 10:58:45PM +0530, Vidya Sagar wrote:
> Add optional bindings "pinctrl-names" and "pinctrl-0" to describe pin
> configuration information of a particular PCIe controller.
>
> Signed-off-by: Vidya Sagar
Reviewed-by: Andrew Murray
> -
plies
> to x16 slot owned by C5 controller need to be enabled before attempting to
> enumerate the devices.
>
> Signed-off-by: Vidya Sagar
Reviewed-by: Andrew Murray
> ---
> V3:
> * Added a dev_err() print for failure case of
> tegra_pcie_get_slot_regulators() API
>
On Wed, Aug 28, 2019 at 10:58:47PM +0530, Vidya Sagar wrote:
> Add support to configure sideband signal pins when information is present
> in respective controller's device-tree node.
>
> Signed-off-by: Vidya Sagar
Reviewed-by: Andrew Murray
> ---
> V3:
> * Used &
plies
> to x16 slot owned by C5 controller need to be enabled before attempting to
> enumerate the devices.
>
> Signed-off-by: Vidya Sagar
> ---
> V2:
> * Addressed review comments from Thierry Reding and Andrew Murray
> * Handled failure case of devm_regulator_get_option
1 - 100 of 308 matches
Mail list logo
