linux-kernel - Re: [PATCH 6/8] ARM: mvebu: enable SDHCI card detection using DAT3 pin on A388-GP

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 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:	Tue, 6 Oct 2015 17:05:21 +0200
From:	Marcin Wojtas <mw@...ihalf.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	linux-kernel@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Jason Cooper <jason@...edaemon.net>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Gregory Clément 
	<gregory.clement@...e-electrons.com>, nadavh@...vell.com,
	Lior Amsalem <alior@...vell.com>,
	Tawfik Bayouk <tawfik@...vell.com>,
	Grzegorz Jaszczyk <jaz@...ihalf.com>
Subject: Re: [PATCH 6/8] ARM: mvebu: enable SDHCI card detection using DAT3
 pin on A388-GP

Andrew,

2015-10-06 16:45 GMT+02:00 Andrew Lunn <andrew@...n.ch>:
>> I expected this patch would be controversial, hence I propose a
>> compromise: set A388-GP SDHCI to 'broken-cd' by defeault.
>
> So for boards < 1.5, you are introducing a regression. It used to work
> via GPIO. Now that is ignored and it is declared broken. Or am i
> mis-understanding what broken-cd means, and it actually means, poll
> it?
>

"broken-cd" property means that the mmc subsystem is polling instead
of using hardware detection.

>> However Marvell insisted on HW card detection
>
> Marvell does not get to decide what goes into the kernel and what can
> be deliberately broken. Marvell can make recommendations, provide
> benchmarks reports, etc. But the community, and ultimately the
> responsible maintainer decides.

Sure, this is why I submitted the patch to the list in order to get
review. Please bear in mind, that I do not work in Marvell and I just
wanted to present some justification of the decision, about which I
got informed. Personally I think it would be reasonable to keep GPIO
detect as is, but maybe I'm lacking some background.

>
>> because software polling spoils the SD/MMC benchmarks, but this way
>> the user would decide whether to stay with broken-cd or switch to
>> GPIO/DAT3 detection. What do you think?
>
> So rather than presenting a solution, please could you list all the
> different options you can think of, and how they would work for < 1.5
> and >= 1.5.
>

We have three options here:
- leave GPIO-based card detection and see if in future anyone
complains about not working detection
- switch to DAT3 detection - yes you're right, that it is a regression
for all boards < 1.5
- enable SW polling for detection ("broken-cd") which should satisfy
all kind of boards

> One other useful bit of information. How many < 1.5 boards are there,
> and who has them. Are they internal to Marvell and Free Electrons, or
> do a lot of people have them? We have thrown away fixes which are
> requires for A0 stepping SoCs, because very few people have such
> devices and they can easily replace them for B1. If nearly nobody
> actually has < 1.5, ....

I have no information, nor an access to such data, I can have only
suspicions which cannot be a reference in any way.

Best regards,
Marcin
--
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/