linux-kernel - Re: [PATCH] ARM: dts: imx6qdl-cubox-i: Move card-detect GPIO to 1.5 SOM devices only

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: <CABdtJHun8DWbr-bUgwQEK61UXMLh5pPkwvUTF+KxhHmJaXEr-A@mail.gmail.com>
Date:   Sun, 29 Apr 2018 16:09:31 +0200
From:   Jon Nettleton <jon@...id-run.com>
To:     Paul Kocialkowski <contact@...lk.fr>
Cc:     Russell King - ARM Linux <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] ARM: dts: imx6qdl-cubox-i: Move card-detect GPIO to 1.5
 SOM devices only

On Sun, Apr 29, 2018 at 3:47 PM, Paul Kocialkowski <contact@...lk.fr> wrote:
> Hi,
>
> Le dimanche 22 avril 2018 à 19:22 +0200, Paul Kocialkowski a écrit :
>> Are all CuBox-i units that have ever been sold supposed to have a
>> connector with a CD line? I find it hard to believe that it's broken
>> specifically on mine.
>
> Do you have a clue whether there should, in fact, be a CD line on all
> CuBox-i models out there? Although you seemed to imply that my device
> might be broken, I am still confused about whether this issue concerns
> my device only or a specific revision of the CuBox-i.
>
>> If that's really needed, I could open up the device, check whether the
>> R8 pull is in place and check the voltage there.
>
> In case there is a doubt, I will proceed with opening the device so we
> can have a clear idea, but I'd rather avoid it as much as possible.
>
> Cheers,
>
> --
> Paul Kocialkowski,
>
> developer of free digital technology and hardware support.
>
> Website: https://www.paulk.fr/
> Coding blog: https://code.paulk.fr/
> Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

Paul,

You can see on our schematics that the hinged sdhc card slot is an
assembly option and not the default.
https://wiki.solid-run.com/lib/exe/fetch.php?media=imx6:cubox-i:schematics-rev-1.1:cubox-i-lower.pdf

You have either an initial early developer unit (pre-production) that
was assembled like this for testing, or a unit that someone
specifically ordered assembled this way.  You can see from the
schematic that this option does not have a CD-pin because it is meant
to be a more permanent storage option.

That being said, this is not a default option and therefore should not
be merged into the mainline device-tree.  Our soms and carriers are
designed to be very flexible regarding the assembly options and we try
to mainline device-tree files that represent the most common assembly
options.  Once there is a common accepted mainlining for device-tree
fragments for overlays, that would be the proper place to make this
change.  Although in this case you would also need a custom u-boot so
it is probably best to just handle the change there.  If you would
like touch base with me off list and I can point you at the required
u-boot changes.

Thanks,
Jon