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: <CAPTm99V1m4QQReQTBJfN5biBtvg1KTSpW_vF67mPnCt30szSuA@mail.gmail.com>
Date:	Fri, 31 Oct 2014 15:45:25 +0530
From:	Ankit Jindal <ankit.jindal@...aro.org>
To:	Mark Rutland <mark.rutland@....com>
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

On 31 October 2014 15:39, Mark Rutland <mark.rutland@....com> wrote:
>> >> +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.
Thanks, I will go as per your suggestion. I will add two properties
qpool-sram and qpool-memory to tackle this.
>
>> >
>> >> +- 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,
Ankit
> 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/