linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: xxm <xxm@rock-chips.com>,
	devicetree@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Heiko Stuebner <heiko@sntech.de>,
	linux-pci@vger.kernel.org, Shawn Lin <shawn.lin@rock-chips.com>,
	linux-rockchip@lists.infradead.org, robh+dt@kernel.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	Johan Jonker <jbx6244@gmail.com>
Subject: Re: [PATCH v3 2/2] PCI: rockchip: add DesignWare based PCIe controller
Date: Mon, 25 Jan 2021 20:45:41 +0200	[thread overview]
Message-ID: <20210125184541.GJ579511@unreal> (raw)
In-Reply-To: <e7ed6586-06f3-52e3-b2db-38887a5a37e4@arm.com>

On Mon, Jan 25, 2021 at 03:53:38PM +0000, Robin Murphy wrote:
> On 2021-01-25 09:01, Leon Romanovsky wrote:
> > On Mon, Jan 25, 2021 at 02:40:10PM +0800, xxm wrote:
> > > Hi Leon,
> > >
> > > Thanks for your reply.
> > >
> > > 在 2021/1/25 13:48, Leon Romanovsky 写道:
> > > > On Mon, Jan 25, 2021 at 10:49:27AM +0800, Simon Xue wrote:
> > > > > pcie-dw-rockchip is based on DWC IP. But pcie-rockchip-host
> > > > > is Rockchip designed IP which is only used for RK3399. So all the following
> > > > > non-RK3399 SoCs should use this driver.
> > > > >
> > > > > Signed-off-by: Simon Xue <xxm@rock-chips.com>
> > > > > Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> > > > > ---
> > > > >    drivers/pci/controller/dwc/Kconfig            |   9 +
> > > > >    drivers/pci/controller/dwc/Makefile           |   1 +
> > > > >    drivers/pci/controller/dwc/pcie-dw-rockchip.c | 286 ++++++++++++++++++
> > > > >    3 files changed, 296 insertions(+)
> > > > >    create mode 100644 drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > > > >
> > > > > diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> > > > > index 22c5529e9a65..aee408fe9283 100644
> > > > > --- a/drivers/pci/controller/dwc/Kconfig
> > > > > +++ b/drivers/pci/controller/dwc/Kconfig
> > > > > @@ -214,6 +214,15 @@ config PCIE_ARTPEC6_EP
> > > > >    	  Enables support for the PCIe controller in the ARTPEC-6 SoC to work in
> > > > >    	  endpoint mode. This uses the DesignWare core.
> > > > >
> > > > > +config PCIE_ROCKCHIP_DW_HOST
> > > > > +	bool "Rockchip DesignWare PCIe controller"
> > > > > +	select PCIE_DW
> > > > > +	select PCIE_DW_HOST
> > > > > +	depends on ARCH_ROCKCHIP || COMPILE_TEST
> > > > > +	depends on OF
> > > > > +	help
> > > > > +	  Enables support for the DW PCIe controller in the Rockchip SoC.
> > > > > +
> > > > >    config PCIE_INTEL_GW
> > > > >    	bool "Intel Gateway PCIe host controller support"
> > > > >    	depends on OF && (X86 || COMPILE_TEST)
> > > > > diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
> > > > > index a751553fa0db..30eef8e9ee8a 100644
> > > > > --- a/drivers/pci/controller/dwc/Makefile
> > > > > +++ b/drivers/pci/controller/dwc/Makefile
> > > > > @@ -13,6 +13,7 @@ obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
> > > > >    obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> > > > >    obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
> > > > >    obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> > > > > +obj-$(CONFIG_PCIE_ROCKCHIP_DW_HOST) += pcie-dw-rockchip.o
> > > > >    obj-$(CONFIG_PCIE_INTEL_GW) += pcie-intel-gw.o
> > > > >    obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
> > > > >    obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o
> > > > > diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > > > > new file mode 100644
> > > > > index 000000000000..07f6d1cd5853
> > > > > --- /dev/null
> > > > > +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > > > > @@ -0,0 +1,286 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > +/*
> > > > > + * PCIe host controller driver for Rockchip SoCs
> > > > > + *
> > > > > + * Copyright (C) 2021 Rockchip Electronics Co., Ltd.
> > > > > + *		http://www.rock-chips.com
> > > > > + *
> > > > > + * Author: Simon Xue <xxm@rock-chips.com>
> > > > > + */
> > > > > +
> > > > > +#include <linux/clk.h>
> > > > > +#include <linux/gpio/consumer.h>
> > > > > +#include <linux/mfd/syscon.h>
> > > > > +#include <linux/module.h>
> > > > > +#include <linux/of_device.h>
> > > > > +#include <linux/phy/phy.h>
> > > > > +#include <linux/platform_device.h>
> > > > > +#include <linux/regmap.h>
> > > > > +#include <linux/reset.h>
> > > > > +
> > > > > +#include "pcie-designware.h"
> > > > > +
> > > > > +/*
> > > > > + * The upper 16 bits of PCIE_CLIENT_CONFIG are a write
> > > > > + * mask for the lower 16 bits.  This allows atomic updates
> > > > > + * of the register without locking.
> > > > > + */
> > > > This is correct only for the variables that naturally aligned, I imagine
> > > > that this is the case here and in the Linux, but better do not write comments
> > > > in the code that are not accurate.
> > >
> > > Ok, will remove.
> > > I wonder what it would be when outside the Linux? Could you share some information?
> >
> > The C standard says nothing about atomicity, integer assignment maybe atomic,
> > maybe it isn’t. There is no guarantee, plain integer assignment in C is non-atomic
> > by definition.
> >
> > The atomicity of u32 is very dependent on hardware vendor, memory model and compiler,
> > for example x86 and ARMs guarantee atomicity for u32. This is why I said that probably
> > here (Linux) it is ok and you are not alone in expecting lockless write.
>
> Huh? What do variables and the abstract machine of the C language
> environment have to do with the definition of *hardware MMIO registers*? We
> don't write to registers with plain integer assignment of u32, we use
> writel() (precisely in order to bypass that abstract C environment).
>
> I appreciate that the comment is not universally true if taken completely
> out of context, but I that's true of pretty much all comments ever. If
> someone really were trying to learn basic programming principles from random
> comments in Linux drivers, then it's already a bit late for us to try and
> save them from themselves.

So what? Does it mean that new code should have comments that are not
correct? As you can see from this conversation, even the author didn't
know what u32 isn’t guaranteed to be atomic, so yes, the comments should
be correct.

Thanks

  reply	other threads:[~2021-01-25 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25  2:48 [PATCH v3 1/2] dt-bindings: rockchip: Add DesignWare based PCIe controller Simon Xue
2021-01-25  2:49 ` [PATCH v3 2/2] PCI: rockchip: add " Simon Xue
2021-01-25  5:48   ` Leon Romanovsky
2021-01-25  6:40     ` xxm
2021-01-25  9:01       ` Leon Romanovsky
2021-01-25 15:53         ` Robin Murphy
2021-01-25 18:45           ` Leon Romanovsky [this message]
2021-01-26  2:34             ` xxm
2021-01-26 14:52         ` Rob Herring
2021-01-26 15:25           ` Leon Romanovsky
2021-01-25 14:51 ` [PATCH v3 1/2] dt-bindings: rockchip: Add " Rob Herring
2021-01-25 15:26 ` Rob Herring
2021-01-26  2:44   ` [PATCH v3 1/2] dt-bindings: rockchip: Add DesignWare based PCIe controller【请注意,邮件由robherring2@gmail.com代发】 xxm
2021-01-26 14:48     ` Rob Herring
2021-01-25 15:55 ` [PATCH v3 1/2] dt-bindings: rockchip: Add DesignWare based PCIe controller Johan Jonker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210125184541.GJ579511@unreal \
    --to=leon@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=xxm@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).