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: <5462407.z4eX3u12aQ@wuerfel>
Date:	Tue, 22 Jul 2014 23:11:14 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Kishon Vijay Abraham I <kishon@...com>, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-pci@...r.kernel.org,
	jg1.han@...sung.com, mohit.kumar@...com,
	linux-kernel@...r.kernel.org, grant.likely@...aro.org,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Marek Vasut <marex@...x.de>
Subject: Re: [PATCH v3 1/4] PCI: designware: Configuration space should be specified in 'reg'

On Tuesday 22 July 2014 14:53:26 Bjorn Helgaas wrote:
> > @@ -2,6 +2,10 @@
> >  
> >  Required properties:
> >  - compatible: should contain "snps,dw-pcie" to identify the core.
> > +- reg: Should contain the configuration address space.
> > +- reg-names: Must be "config" for the PCIe configuration space.
> > +    (The old way of getting the configuration address space from "ranges"
> > +    is deprecated and should be avoided.)
> 
> I'm not a devicetree person, so please excuse my floundering here.
> There doesn't seem to be consistent usage of "reg" or "reg-names".

I think the above is ok, given the constraints we hae.

> Here's what I found in the existing Documentation/devicetree/bindings/pci
> stuff:
>
>   83xx-512x-pci.txt
>     - reg: should contain two address length tuples
>         The first is for the internal pci bridge registers
>         The second is for the pci config space access registers

This is fine

>   fsl,imx6q-pcie.txt
>     - reg: base addresse and length of the pcie controller

This should have included an entry for the config space, it was a
mistake

>   host-generic-pci.txt
>     - reg            : The Configuration Space base address and size, as accessed
>                        from the parent bus.

This is fine.

>   nvidia,tegra20-pcie.txt
>     - reg: A list of physical base address and length for each set of controller
>       registers. Must contain an entry for each entry in the reg-names property.
>     - reg-names: Must include the following entries:
>       "pads": PADS registers
>       "afi": AFI registers
>       "cs": configuration space region

The names are a bit strange, but it's also ok. In general we should mandate
the order of the entries as well.

>   pci-rcar-gen2.txt
>     - reg:  A list of physical regions to access the device: the first is
>             the operational registers for the OHCI/EHCI controllers and the
>             second is for the bridge configuration and control registers.

This one is wrong, as previously discussed. The first region should
have been listed in the 'ranges' property, because these are the registers
of the child nodes (the actual PCI devices) rather than the host controller
itself.

>   ralink,rt3883-pci.txt
>      - reg: specifies the physical base address of the controller and
>        the length of the memory mapped region.

The wording is a bit strange but it seems otherwise correct.

>   rcar-pci.txt
>     - reg: base address and length of the pcie controller registers.

This is ok

>   samsung,exynos5440-pcie.txt
>     - reg: base addresses and lengths of the pcie controller,
>           the phy controller, additional register for the phy controller.

Could be a bit more verbose, but is not wrong. In order to work
with the "snps,dw-pcie" binding, this will need a reg-names property.

>   v3-v360epc-pci.txt
>     - reg: should contain the base address of the V3 adapter.

This has the same mistake that the pcie-dw driver has and should
be fixed by putting the config space in there.

> So my questions are:
> 
> 1) Is "reg" the right place for configuration space?  I assume this is
> CAM or ECAM.  Only 83xx-512x-pci.txt, host-generic-pci.txt, and
> nvidia,tegra20-pcie.txt mention using "reg" for config space; all the
> others use "reg" for register space for the PCIe controller itself.

We had long debates about this. The conclusion was that we should
have put them in 'reg' from the start and not used 'ranges' here.

> 2) Is "config" the correct value for "reg-names"?  Only
> nvidia,tegra20-pcie.txt has something similar, and it wants "cs".
> Should these be the same?

It would be better if they were the same, but it's not important.
The names are private to the device driver, and the register layout
within this region is driver specific, so we can't use common code
to parse them anyway.

> 3) Doesn't this add a revlock (kernels with this patch require a new
> device tree that adds "reg" and "reg-names"?  I know both Mohit and
> Jingoo acked this [1,2], so I'm just double-checking that this is
> expected and desired.

My understanding is that the patch still allows the old method as
a fallback if no reg with the name "config" is present.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ