linux-kernel - Re: [PATCH v3 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO 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]

Message-ID: <20141031100925.GA798@leverpostej>
Date:	Fri, 31 Oct 2014 10:09:25 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Ankit Jindal <ankit.jindal@...aro.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Hans J. Koch" <hjk@...sjkoch.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"patches@....com" <patches@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Herring <robh+dt@...nel.org>,
	Tushar Jagad <tushar.jagad@...aro.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Varka Bhadram <varkabhadram@...il.com>
Subject: Re: [PATCH v3 5/6] Documentation: dt-bindings: Add binding info for
 X-Gene QMTM UIO driver

> >> +Required properties:
> >> +- compatible: Should be "apm,xgene-qmtm"
> >> +- reg: Address and length of the register set for the device. It contains the
> >> +  information of registers in the same order as described by reg-names.
> >> +- reg-names: Should contain the register set names
> >> +  - "csr": QMTM control and status register address space.
> >> +  - "fabric": QMTM memory mapped access to queue states.
> >> +- qpool: Points to the phandle of the node defining memory location for
> >> +      creating QMTM queues. This could point either to the reserved-memory
> >> +      node (as-per reserved memory bindings) or to the node of on-chip
> >> +      SRAM etc. It is expected that size and location of qpool memory will
> >> +      be configurable via bootloader.
> >
> > Is that on-chip SRAM part of the QMTM, or is that a shared part of the
> > SoC?
> Its not part of QMTM.
> 
> >
> > It feels odd to have a phandle that can go to completely different
> > classes of node, especially as you will need to use a different API to
> > acquire the memory region within Linux.
> It is expected that phandle will point to a node whose first reg
> property will be only for qpool memory.

Even if that's true you will need to use completely different APIs for
accessing that memory (so that the kernel can account the use of
reserved-memory correctly), so this might not be the best design. It
might be better to have qpool-sram and qpool-memory properties that
point at an sram node or a reserved-memory node respectively.

> >
> >> +- clocks: Reference to the clock entry.
> >
> > Just the one clock? Does the clock input to the QMTM have a name?
> Just one input clock. There is no specific name of it.

Ok.

> 
> >
> >> +- num-queues: Number of queues under this QMTM device.
> >> +- devid: QMTM identification number for the system having multiple QMTM devices.
> >> +      This is used to form a unique id (a tuple of queue number and
> >> +      device id) for the queues belonging to this device.
> >
> > Is this just an arbitrary unique ID, or is this a non-probeable property
> > of the HW? If the former, isn't the base address sufficient as a unique
> > identifier?
> Its a non-probeable property of the HW.

Ok. That sounds fine then.

Thanks,
Mark.
--
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/