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:	Sun, 08 Feb 2009 02:37:42 +0300
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Atsushi Nemoto <anemo@....ocn.ne.jp>
Cc:	bzolnier@...il.com, geert@...ux-m68k.org,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	apw@...onical.com
Subject: Re: [PATCH 01/15] ide: include <asm/ide.h> only when needed

Hello.

Atsushi Nemoto wrote:

>>> config CONFIG_IDE_BE_IO
>>> 	bool
>>>       
>>     If it was that simple... Normally the BE case gets handled automagically 
>> (moreover, there is MIPS option that additionally controls I/O and memory 
>> space byte swapping). The case we have to address for TX493x is actually where 
>> the usual magic fails (or actually the code just doesn't want to use that 
>> option). So this doesn't look like a good name to me...
>>     
>
> Well, for TX493x (MIPS), we have CONFIG_SWAP_IO_SPACE for big endian
> and it works fine for PCI-IDE host controllers.  For SoC internal
> controllers, no swapping is needed for both endian, thus custom tp_ops
> is needed only for big endian.
>   

   Yeah, SoCs *typically* can handle different endianness for the 
integrated devices in a transparent way. TX4939 didn't do that 
consistently still, and that's where the MIPS address swizzling macros 
could have helped but Atsushi chose to reserve their usage only to the 
external bus accesses. I however don't think that TX4938 case should 
have been handled the same way as TX4939 since in this case the 
controller is *not* SoC integrated device and the IDE registers are 
situated on the chip's external bus with their mapping is actually board 
specific, if I don't mistake (I don't have the datasheet at hand).

> So ... IDE_BE_IO looks actually not best name for this case.  It is
> IDE_RAW_IO or something.

   Yes, I was going to suggest exactly that.

> But IDE_RAW_IO might not fit for other cases.  IDE_SWAPPED_IO?

   I'd prefer IDE_RAW_IO because it can be swapped when using the 
standard accessors as well. Frankly speaking, I'm not sure why ide-h8300 
needs its own accessors while this arch's io.h has an abundance of 
swapping and not swapping accessors already defined...

> Any other good name?
>   

   I'm still not convinced that it's really worth the trouble...

> ---
> Atsushi Nemoto
>   

MBR, Sergei


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