Re: [PATCH 01/15] ide: include <asm/ide.h> only when needed

[Sergei Shtylyov]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/