linux-kernel - Re: [PATCH v4] mmc: OCTEON: Add host driver for OCTEON MMC controller

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: <CAPDyKFqdOuZfcvdFNq5dw-6k_eES-GMJAtq_V_YtF5AgE4QTig@mail.gmail.com>
Date:	Mon, 23 Mar 2015 11:48:56 +0100
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	David Daney <ddaney.cavm@...il.com>
Cc:	Aleksey Makarov <aleksey.makarov@...iga.com>,
	linux-mmc <linux-mmc@...r.kernel.org>, linux-mips@...ux-mips.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Daney <david.daney@...ium.com>,
	Chandrakala Chavva <cchavva@...iumnetworks.com>,
	Leonid Rosenboim <lrosenboim@...iumnetworks.com>,
	Peter Swain <pswain@...ium.com>,
	Aaron Williams <aaron.williams@...ium.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Chris Ball <chris@...ntf.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v4] mmc: OCTEON: Add host driver for OCTEON MMC controller

[...]

>>> +
>>> +This controller is present on some members of the Cavium OCTEON SoC
>>> +family, provide an interface for eMMC, MMC and SD devices.  There is a
>>> +single controller that may have several "slots" connected.  These
>>
>>
>> Even it it may have several slots, that's not being supported by the
>> mmc core from a MMC/SD/SDIO protocol perspective.
>>
>> We have hade some discussions around this historocally, and I doubt
>> that we ever will be adding this.
>>
>> So, with that in mind I would rather see that you remove the concept
>> of "slot" entirely and thus don't do the DT configuration within a
>> child node.
>
>
> As you note this is a device tree representation, and thus really has
> nothing to do with the capabilities and internal structure of any given
> operating system.
>
> The hardware really is structured as a single controller with a single set
> of registers and register fields that can control multiple "slots".  There
> are not multiple independent slot controllers.
>
> This device tree representation reflects,  with fidelity, the actual
> hardware topology.

I understand, you have point - but...

We can debate whether why you think using a child-node for a slot is
reflecting the hardware better, but I rather don't. Everybody else
isn't using a child node, so I don't think you should.

Moreover in the SDIO case, child nodes of mmc hosts reflects the
actual embedded functional SDIO devices. So if child nodes are going
to be used for anything, it should be to contain properties of an
embedded SD/MMC/SDIO card. At least that's my view.

>
> But none of this matters, because the device tree bindings train has already
> left the station.  You should have expressed opposition to this binding back
> when it was first discussed:
>
> http://www.linux-mips.org/archives/linux-mips/2012-05/msg00119.html

I don't get it. What happened with the RFC above? It wasn't merged for
any release, but the DT-bindings that was proposed was accepted? How
is that possible?

>
> The device tree is deployed in the boot firmware of shipping devices, and we
> are merely documenting what is there.

That's a problem. :-)

[...]

Kind regards
Uffe
--
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/