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]
Date:	Sat, 20 Sep 2014 12:52:44 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Liviu Dudau <Liviu.Dudau@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Arnd Bergmann <arnd@...db.de>,
	Rob Herring <robh+dt@...nel.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	Russell King <linux@....linux.org.uk>,
	linux-pci <linux-pci@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>
CC:	Tanmay Inamdar <tinamdar@....com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Sinan Kaya <okaya@...eaurora.org>,
	Jingoo Han <jg1.han@...sung.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Suravee Suthikulanit <suravee.suthikulpanit@....com>,
	linux-arch <linux-arch@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Device Tree ML <devicetree@...r.kernel.org>,
	LAKML <linux-arm-kernel@...ts.infradead.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH v11 07/10] OF: Introduce helper function for getting PCI
 domain_nr

On 09/17/2014 08:30 PM, Liviu Dudau wrote:
> Add of_pci_get_domain_nr() to retrieve the PCI domain number
> of a given device from DT. If the information is not present,
> the function can be requested to allocate a new domain number.
> 
> Cc: Bjorn Helgaas <bhelgaas@...gle.com>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Grant Likely <grant.likely@...aro.org>
> Cc: Rob Herring <robh+dt@...nel.org>
> Reviewed-by: Catalin Marinas <catalin.marinas@....com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@....com>
> ---

[...]

> +/**
> + * This function will try to obtain the host bridge domain number by
> + * using of_alias_get_id() call with "pci-domain" as a stem. If that
> + * fails, a local allocator will be used. The local allocator can
> + * be requested to return a new domain_nr if the information is missing
> + * from the device tree.
> + *
> + * @node: device tree node with the domain information
> + * @allocate_if_missing: if DT lacks information about the domain nr,
> + * allocate a new number.
> + *
> + * Returns the associated domain number from DT, or a new domain number
> + * if DT information is missing and @allocate_if_missing is true. If
> + * @allocate_if_missing is false then the last allocated domain number
> + * will be returned.
> + */
> +int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
> +{
> +	int domain;
> +
> +	domain = atomic_read(&of_domain_nr);
> +	if (domain == -1) {
> +		/* first run, get max defined domain nr in device tree */
> +		domain = of_get_max_pci_domain_nr();
> +		/* then set the start value for allocator to be max + 1 */
> +		atomic_set(&of_domain_nr, domain + 1);

atomic_read followed by atomic_set is not an atomic operation.

As I previously said, I don't like how this function is a mixture of
data retrieval and domian # allocation. I think we need 2 functions.

> +	}
> +	domain = of_alias_get_id(node, "pci-domain");

I still do not like using aliases here. Just put pci-domain or
linux,pci-domain into the PCI node.

I think we should assume all PCI root buses either have a domain
property or they don't and a mixture is an error. I'm not sure if that
simplifies the code or not though.

In the interest of merging, I think you should just do a simple
allocation and add the DT domain handling as a second step. You will
also need to document the DT part.

Rob

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