linux-kernel - Re: [PATCH 3/7] mmc: dw_mmc: add device tree support

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, 12 May 2012 00:07:29 -0700
From:	Olof Johansson <olof@...om.net>
To:	Thomas Abraham <thomas.abraham@...aro.org>
Cc:	linux-mmc@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	cjb@...top.org, grant.likely@...retlab.ca, rob.herring@...xeda.com,
	linux-samsung-soc@...r.kernel.org, kgene.kim@...sung.com,
	patches@...aro.org
Subject: Re: [PATCH 3/7] mmc: dw_mmc: add device tree support

Hi,

On Thu, May 10, 2012 at 3:15 AM, Thomas Abraham
<thomas.abraham@...aro.org> wrote:
> Hi Olof,
>
> On 2 May 2012 23:37, Olof Johansson <olof@...om.net> wrote:
>> Hi,
>
> [...]
>
>>> +# Slots: The slot specific information are contained within child-nodes with
>>> +  each child-node representing a supported slot. There should be atleast one
>>> +  child node representing a card slot. The name of the slot child node should
>>> +  be 'slot{n}' where n is the unique number of the slot connnected to the
>>> +  controller. The following are optional properties which can be included in
>>> +  the slot child node.
>>
>> Since we're talking slots / cards on a bus, I think the addressing
>> model would be useful here. So in the main controller node:
>>    #address-cells = <1>;
>>    #size-cells = <0>;
>>
>> And then each slot would need a reg property and possibly unit address:
>>
>>   slot {
>>        reg = <0>;
>>        ...
>>   };
>>
>> (unit addresses on the slots are only needed if they can't be
>> disambiguated by name, so not needed if you only have one slot).
>>
>
> Is the addressing model as described above needed in this case? The
> address for a slot is not used by the controller driver code and is
> just a virtual number. It would be sufficient to represent the nodes
> representing the slots with a unique name.

The driver has the concept of slot IDs (slot->id struct member), and
the hardware definitely enumerates them.

So, I think it makes sense to give a chance to enumerate the slots in
the device tree. Otherwise, how do you know which one is which on
hardware? It also opens up the flexibility to have the same name for
both slots if it makes sense to describe a board that way.


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