linux-kernel - Re: [PATCH] ARM: dts: bcm2711: Use bcm2711 compatible for sdhci

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:   Mon, 20 Jan 2020 11:59:00 -0800
From:   "Stephen Brennan" <stephen@...nnan.io>
To:     "Nicolas Saenz Julienne" <nsaenzjulienne@...e.de>
Cc:     "Mark Rutland" <mark.rutland@....com>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        "Rob Herring" <robh+dt@...nel.org>,
        <bcm-kernel-feedback-list@...adcom.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-rpi-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: dts: bcm2711: Use bcm2711 compatible for sdhci

Hi Nicolas,

You're right, this patch doesn't work (it doesn't even touch the correct 
device tree node). My bad.

> Your UHS class 1 card should work out of the box using the current
> kernel version.

I've been debugging an issue (reproduced on today's linux-next) in which my 
UHS class 1 card's partitions don't show up in `/dev`. For example, if I do 
`ls /dev | grep mmc`, I get just one result, "mmcblk1". I thought my patch 
fixed the issue, but it turns out that the issue is sporadic: on some 
boots, the issue manifests. On others, the partitions appear in /dev as 
normal. When I tested this patch, the issue had sporadically disappeared, 
leading me to believe the patch was effective.

Sorry for the noise! If you have any suggestions on debugging this, I'd 
appreciate it. As far as I know it could be anything - the particular card, 
the particular Pi, etc.

Thanks,
Stephen