linux-kernel - Re: [RFC+PATCH] RTC calibration

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]

Message-ID: <46E6E657.2050201@anagramm.de>
Date:	Tue, 11 Sep 2007 21:02:47 +0200
From:	Clemens Koller <clemens.koller@...gramm.de>
To:	Dag-Erling Smørgrav <des@...pro.no>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [RFC+PATCH] RTC calibration

Dag-Erling Smørgrav schrieb:
 > Clemens Koller <clemens.koller@...gramm.de> writes:
 >> I am talking about _how_ the calibration register is addressed from
 >> userspace. It's a simple register, some bits at address 7 and I would
 >> expect to read/modify/write registers to do all the things you want
 >> to do. Register access in userspace doesn't put any limitation
 >> to applications.
 >
 > It requires the application to know the hardware intimately.

That's right... there is no need to put that into the kernel and
hide this trivial functionality from userspace.

 > Calibration of the M41T11 is implemented using the lower 6 bits of
 > register 7; this is not necessarily the case for other existing or
 > future chips.

I've read the datasheet.
Your driver is specific for the M41T11 chip as mentioned in your
first mail, isn't it? If any future driver comes up with 8 bits
you wouldn't need to change a generic interface to read/modify/write
these 8 bits, right?

 > Let's say I normalize this to [-128;127];

Why do any normalization in the driver? That's what userspace can do
in any way it might be necessary to do.

 >> Having only incs and decs without getting the actual value back seems
 >> to be an absolutely unnecessary limitation here.
 >> You cannot get the current value back to see if it's i.e. in saturation in
 >> a way that it doesn't make sense to inc/decrement it further or in bigger steps
 >> or reset it to zero...
 >
 > The driver will return EINVAL if you try to increment or decrement the
 > calibration register beyond its limits.

That behaviour seems also odd to me...
I can increment/decrement by an unknown number and then I get an EINVAL.
And I cannot reset it to some default value easily.
I still don't see any reason to implement relative changes to an otherwise
unknown value if it's possible to give absolute values to work with.

Well, that's my opinion, my five cents... I don't want to get into a lenghtly
discussion... I just used common sense how a interface to a register might
look like and your way of a relative manipulation just looks very uncommon
to me, having seen lot's of drivers.

Best regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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