From owner-svn-src-all@FreeBSD.ORG Tue Nov 11 23:52:02 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92D40B56; Tue, 11 Nov 2014 23:52:02 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 44599A9; Tue, 11 Nov 2014 23:52:00 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id C71E1780A2A; Wed, 12 Nov 2014 10:51:51 +1100 (AEDT) Date: Wed, 12 Nov 2014 10:51:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Subject: Re: svn commit: r274340 - in head/sys: crypto/rijndael dev/random geom/bde In-Reply-To: <86oasd6dad.fsf@nine.des.no> Message-ID: <20141112100207.Q1068@besplex.bde.org> References: <201411100944.sAA9icnN061962@svn.freebsd.org> <3C962D07-3AAF-42EA-9D3E-D8F6D9A812B0@FreeBSD.org> <86sihq5a2v.fsf@nine.des.no> <20141111223756.F3519@besplex.bde.org> <86oasd6dad.fsf@nine.des.no> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=fvDlOjIf c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=nlC_4_pT8q9DhB4Ho9EA:9 a=cz2ZRIgtxKwA:10 a=wJWlkF7cXJYA:10 a=sZzK7gw1hgqkUVxrSp8A:9 a=45ClL6m2LaAA:10 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Bjoern A. Zeeb" , src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 23:52:02 -0000 On Tue, 11 Nov 2014, [utf-8] Dag-Erling Sm=C3=B8rgrav wrote: > Bruce Evans writes: >> -Wcast-qual is not a very good warning option since the official way >> to remove qualifiers in C is to cast them away. Casting them away is >> better than using the __DECONST() abomination. The option exists >> because it is too easy for sloppy code to cast away const without >> really intending to or when casting away const is done intentionally >> but is an error. > > I agree that __DECONST() is ugly (not least because it strips all > qualifiers, not just const, so it should be DEQUAL()), It is not quite that broken. __DEQUALIFIER() strips all qualifiers, but __DECONST() starts by casting to const void *; thus if the initial type has a volatile qualifier, and -Wcast-qual is configured, and -Wcast-qual is not broken, then you get a cast-qual warning for attempting to strip volatile. > but the > alternative is worse. In my experience, the majority of cases where a > cast discards a qualifier are bugs, with struct iov being one of very > few legitimate use cases. That is a (design) bug too. The pointer type is 'const void *' for write() and plain 'void *' for read(), but struct iov is older than const so there aren't separate pointers to keep the types separate in it. read() and write() are even older, but changing the API of write() to add the const didn't risk breaking so much so it was done. It was a much larger API/ABI change and breakage to change read() and write() to use [s]size_t instead of int. Interestingly, struct iov was changed signfificantly without fixing this bug -- in Net/2, it contained 'caddr_t iov_base' instead of void *iobase, and 'int iov_len' instead of 'size_t iov_len'. The next level of design errors that require the cast is for the str*() family. E.g., strchr() takes a 'const char *' and returns a plain 'char *'. This is like the error for readv(), except strchr() is lower level than readv(). The level below that is design errors errors in the C type system. 'const' doesn't work right after the first level of indirection, so it is impossible to declare functions like strtol() and excecv() with the correct number of const's, and callers of these functions need hacks to be comitbly broken. > In the same vein, you could also argue that it is wrong of gcc and clang > to warn about underparanthesized boolean expressions or about using an > assignment as a truth value. Yet these warnings are extremely useful, > because code that triggers them is often either incorrect or easily > misinterpreted by a casual reader. I certainly complain about their warning about "missing" parentheses for && vs || and & vs |. This is like complaining about "missing" parentheses for * vs +. All of these have a standard conventional precdedence and no design errors for this in C (the C design errors for precedence are only nearby, with & and | having much lower precedence than * and +, so much lower that they are below comparison operators; OTOH, it is correct for && and || to have lower precedence than comparison operators). When I maintained local patches for gcc-2.4.5 and gcc-2.7.2 ending when the ports tree started about 19 years ago, I used to delete check for && vs ||. This bug is larger in clang, since clang enables the && vs || warnings at a lower level than gcc, so some of my code where I intentionally leave out the parentheses exposes the brokenness of the compiler. > Apple's "goto fail" certificate verification bug was caused by code that > was perfectly legal and looked fine at first glance but would have been > caught by -Wunreachable-code. Unfortunately, turning it on in our tree > breaks the build in non-trivially-fixable ways because it is triggered > by const propagation into inline functions. Turning on warnings finds too many problems in dusty decks. Compilers shouldn't put new warnings under only warning flags since this mainly finds non-bugs in code that is not dusty enough to need compiling with no warning flags. -Wunreachable code is fine here since it is new. I don't know of any solution for killing warnings selectively except for ugly lint-like markup. Bruce From owner-svn-src-all@FreeBSD.ORG Tue Nov 11 23:55:38 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F42BDC6; Tue, 11 Nov 2014 23:55:38 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5AF28CB; Tue, 11 Nov 2014 23:55:38 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id sABNtcFl092580; Tue, 11 Nov 2014 23:55:38 GMT (envelope-from loos@FreeBSD.org) Received: (from loos@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id sABNtcRJ092579; Tue, 11 Nov 2014 23:55:38 GMT (envelope-from loos@FreeBSD.org) Message-Id: <201411112355.sABNtcRJ092579@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: loos set sender to loos@FreeBSD.org using -f From: Luiz Otavio O Souza Date: Tue, 11 Nov 2014 23:55:38 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r274409 - head/sys/arm/broadcom/bcm2835 X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 23:55:38 -0000 Author: loos Date: Tue Nov 11 23:55:37 2014 New Revision: 274409 URL: https://svnweb.freebsd.org/changeset/base/274409 Log: Since r273264 the SD card detection on Raspberry Pi is reliably working and that expose new bugs with HS mode. When the old code could not do the proper card detection it would boot with lower defaults (and no HS mode) and this makes some HS cards boots. Now, with the card always identified as HS capable, the sdhci controller tries to run the card at HS speeds and makes the boot always fail. Disable the HS mode for now (which still can be enabled with the tunable) until it is properly fixed. MFC with: r273264 Requested by: many Modified: head/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c Modified: head/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c ============================================================================== --- head/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c Tue Nov 11 22:08:18 2014 (r274408) +++ head/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c Tue Nov 11 23:55:37 2014 (r274409) @@ -84,10 +84,13 @@ __FBSDID("$FreeBSD$"); /* * Arasan HC seems to have problem with Data CRC on lower frequencies. * Use this tunable to cap initialization sequence frequency at higher - * value. Default is standard 400kHz + * value. Default is standard 400kHz. + * HS mode brings too many problems for most of cards, so disable HS mode + * until a better fix comes up. + * HS mode still can be enabled with the tunable. */ static int bcm2835_sdhci_min_freq = 400000; -static int bcm2835_sdhci_hs = 1; +static int bcm2835_sdhci_hs = 0; static int bcm2835_sdhci_pio_mode = 0; TUNABLE_INT("hw.bcm2835.sdhci.min_freq", &bcm2835_sdhci_min_freq);