linux-kernel - Re: [PATCH 1/2] [IDE] Platform IDE driver

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: <ef909c9835ecc57be4f4fa7fdc405889@kernel.crashing.org>
Date:	Mon, 6 Aug 2007 19:16:27 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
Cc:	Scott Wood <scottwood@...escale.com>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 1/2] [IDE] Platform IDE driver

>> More importantly, "reg-shift" doesn't say what part of
>> the bigger words to access.  A common example is byte-wide
>> registers on a 32-bit-only bus; it's about 50%-50% between
>> connecting the registers to the low byte vs. connecting it
>> to the byte with the lowest address.
>
>    We already have "big-endian" prop used in MPIC nodes, IIRC. Could 
> try to "reuse" it here as well...

Sure.  This would be an okay way to handle legacy devices that
are connected in inventive ways: add "reg-shift" and/or "big-endian"
properties.  We should make sure this is documented in the
appropriate bindings though, don't just assume it will work.

For non-legacy devices, please just use the "compatible"
property to figure out the endianness etc.; it is a bad idea
to make a "blablabla-big-endian" compatible value, but you can
almost often just use a more specific model name instead; and
typically the device has some other quirks anyway ;-)

>> It would be nice to not name similar properties in the
>> device tree dissimilarly.  Kernel code doesn't come into
>> the picture here.
>
>    The "reg-shift" prop is yet unaccepted ad-hockery at this point. ;-)
>    So, I don't see why we have to be consistent with it.

Don't treat your ad-hockery ad hoc, that way leads to insanity :-)

It's quite important to use good names for all new properties
you define, so you naturally end up with similar names for
similar purposes.  Of course it isn't a *requirement*, you're
right about that.


Segher

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