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:	Sat, 17 May 2008 20:16:20 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Atsushi Nemoto <anemo@....ocn.ne.jp>
cc:	a.zummo@...ertech.it, hvr@....org, akpm@...ux-foundation.org,
	rtc-linux@...glegroups.com, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] RTC: M41T80: Century Bit support

On Sun, 18 May 2008, Atsushi Nemoto wrote:

> This patch enforces that all (including future) users of this device
> must use same interpretation of CB bit.  I think this is too
> intrusive.

 I feared so, but on the other hand I did not want to introduce yet 
another kernel/module command line parameter -- there are too many of them 
already. :-(

> And I have one (out-of-tree, and only one in the world) board with
> this device and its firmware uses different interpretation.
> Fortunately I can change this firmware, so this is not a serious
> problem for me. ;)

 Hmm, how about pushing your bits upstream? ;-)

> How about doing like this?
> 
> 1. If CEB was 0, keep current behavior. (does not touch CB bit)
> 
> 2. If CEB was 1, detect polarity of CB bit on get_datetime, and set or
>    clear CB bit on set_datetime based on the polarity.

 That's what I did initially as it is as obvious as you can get.  But as I
noted, CFE, the firmware used with the SWARM, does not set CEB even though
it takes CB into account.  The approach is not useful therefore at least
for one major user of the device.

 Of course CFE is BSD-licensed and can be changed too, but based on my
experience with how serious bugs are handled, I would not count on getting
such a minor change integrated into the official sources.

> Please look at "c_polarity" variable in rtc-pcf8563.c driver.

 Hmm, not terribly useful as few of us if anybody live back in the 20th
century. ;-)  I think let's scrap the patch in this case and let our
grandchildren solve the problem -- a proposal has been published and can
be reused as needed.

  Maciej
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ