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
| ||
|
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/
Powered by blists - more mailing lists