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:	Thu, 04 Apr 2013 13:03:04 -0400
From:	Douglas Gilbert <dgilbert@...erlog.com>
To:	Nicolas Ferre <nicolas.ferre@...el.com>
CC:	linux-arm-kernel@...ts.infradead.org, jhovold@...il.com,
	robertcnelson@...il.com,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ARM: at91: add Acme Systems Aria G25 board

On 13-04-04 11:42 AM, Nicolas Ferre wrote:
> From: Douglas Gilbert <dgilbert@...erlog.com>
>
> Signed-off-by: Douglas Gilbert <dgilbert@...erlog.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@...el.com>
> ---
> Hi all,
>
> Here is the third revision of this patch. I plan to include it in a
> pull-request real-soon-now!
>
> v3: - move to "at91-" prefix for .dts[i] files
>      - remove the rtc activation code because of the ongoing discussions
>        about this IP and its DT binding.
>

Nicolas,
It's a pity that the rtc activation code is removed.
At worst:
                         rtc@...ffeb0 {
                                 status = "okay";
                         };

does nothing. Also it is unlikely to be changed by any
movement on the rtc-at91rm9200 front.


The lack of use of uart1 is for my own, private reasons.
I think it would be more generally useful to show uart1's
definition and disable it as shown in the attached patch
fragment.


I also note that my date line was removed. I like dates,
so when I add comments like "the i2c-at91 driver is broken
for the SAM9G20 ** and use the i2c-gpio driver instead" then
this is not taken as an eternal truth. It worked in the
past and hopefully it will work again in the future.

While on the subject of I2C, I'm getting tired of seeing
this oft-copied line:
    i2c-gpio,delay-us = <2>;        /* ~100 kHz */

It is the clock half period in microseconds and for the 100 kHz
(standard) I2C clock speed, it should be 5. Due to rounding
(up) that gives a measured clock speed of around 88 kHz on
my equipment. Crappy I2C devices *** seem to cope better
with 12% below the standard clock frequency than 80% above
it.

Doug Gilbert

** broken in my tests on the FoxG20 with lk 3.9.0-rc5

*** if my experience is anything to go by there are many
     dodgy I2C devices, probably using I2C bit banging
     code borrowed from Wikipedia.



View attachment "ariag25_390rc5_dg1.patch" of type "text/x-patch" (1032 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ