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 <>
To:	Andrew Lunn <>
	"" <>,
	Ulf Hansson <>,
	Sebastian Hesselbarth <>,
	Jason Cooper <>,
	Thomas Petazzoni <>,
	Gregory Clément 
	Lior Amsalem <>,
	Tawfik Bayouk <>,
	Grzegorz Jaszczyk <>
Subject: Re: [PATCH 6/8] ARM: mvebu: enable SDHCI card detection using DAT3
 pin on A388-GP


2015-10-06 16:45 GMT+02:00 Andrew Lunn <>:
>> 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,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists