linux-kernel - Re: [PATCH v5 6/7] ARM: zynq: Add OCM controller driver

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:	Mon, 01 Dec 2014 16:31:19 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Michal Simek <michal.simek@...inx.com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Soren Brinkmann <soren.brinkmann@...inx.com>,
	Olof Johansson <olof@...om.net>, monstr@...str.eu,
	Josh Cartwright <josh.cartwright@...com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	Rob Herring <robherring2@...il.com>,
	Peter Crosthwaite <peter.crosthwaite@...inx.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joe Perches <joe@...ches.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Antti Palosaari <crope@....fi>,
	Jingoo Han <jg1.han@...sung.com>,
	Sandeep Nair <sandeep_n@...com>,
	Kumar Gala <galak@...eaurora.org>,
	Santosh Shilimkar <santosh.shilimkar@...il.com>,
	Andy Gross <agross@...eaurora.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Thierry Reding <treding@...dia.com>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v5 6/7] ARM: zynq: Add OCM controller driver

On Monday 01 December 2014 14:24:57 Michal Simek wrote:
> The driver provide memory allocator which can
> be used by others drivers to allocate memory inside OCM.
> All locations for 64kB blocks are supported
> and driver is trying to allocate the largest continuous
> block of memory.
> 
> Checking mpcore addressing filterring is not done here
> but could be added in future.
> 
> Signed-off-by: Michal Simek <michal.simek@...inx.com>

The driver doesn't actually have any interface as far as I can tell,
so I wonder how you expect it to be used.

Do you have a list of drivers that would be using it?

How does it relate to the generic "mmio-sram" binding? Is this
meant as a specialization?

> +/**
> + * zynq_ocmc_irq_handler - Interrupt service routine of the OCM controller
> + * @irq:	IRQ number
> + * @data:	Pointer to the zynq_ocmc_dev structure
> + *
> + * Return:     IRQ_HANDLED always
> + */
> +static irqreturn_t zynq_ocmc_irq_handler(int irq, void *data)
> +{
> +	u32 sts;
> +	u32 err_addr;
> +	struct zynq_ocmc_dev *zynq_ocmc = data;
> +
> +	/* check status */
> +	sts = readl(zynq_ocmc->base + ZYNQ_OCMC_IRQ_STS);
> +	if (sts & ZYNQ_OCMC_IRQ_STS_ERR_MASK) {
> +		/* check error address */
> +		err_addr = readl(zynq_ocmc->base + ZYNQ_OCMC_PARITY_ERRADDRESS);
> +		pr_err("%s: OCM err intr generated at 0x%04x (stat: 0x%08x).",
> +		       __func__, err_addr, sts & ZYNQ_OCMC_IRQ_STS_ERR_MASK);
> +	}
> +	pr_warn("%s: Interrupt generated by OCM, but no error is found.",
> +		__func__);
> +
> +	return IRQ_HANDLED;
> +}

I'm also puzzled by this: you don't really do anything here but print
a message. What is the purpose of this interrupt? As this looks unrelated
to the rest of the driver, maybe this should be part of drivers/edac
instead?

> +static int zynq_ocmc_probe(struct platform_device *pdev)
> +{
> +       int ret;
> +       struct zynq_ocmc_dev *zynq_ocmc;
> +       u32 i, ocm_config, curr;
> +       struct resource *res;
> +
> +       ocm_config = zynq_slcr_get_ocm_config();
> +
> +       zynq_ocmc = devm_kzalloc(&pdev->dev, sizeof(*zynq_ocmc),
> GFP_KERNEL);
> +       if (!zynq_ocmc)
> +               return -ENOMEM;
> +
> +       zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev,
> +                                              ilog2(ZYNQ_OCMC_GRANULARITY),
> +                                              -1);
> +       if (!zynq_ocmc->pool)
> +               return -ENOMEM;
> +
> +       curr = 0; /* For storing current struct resource for OCM */
> +       for (i = 0; i < ZYNQ_OCMC_BLOCKS; i++) {
> +               u32 base, start, end;
> +
> +               /* Setup base address for 64kB OCM block */
> +               if (ocm_config & BIT(i))
> +                       base = ZYNQ_OCMC_HIGHADDR;
> +               else
> +                       base = ZYNQ_OCMC_LOWADDR;

You write in the introductory mail that you want to support detecting the
address from the slcr, and possibly even allow changing it at runtime,
but I don't understand what that would be good for.

It's not uncommon to describe in DT settings that one can also find
out from hardware but that are set up by the boot loader in a particular
way. Why not this one? For all I can tell, that would let you simply
use one driver for the EDAC and the generic mmio-sram from the memory,
without the need to do anything further.

	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/