Re: [RFC] new bus architecture (+ byte-endianess)

["Petr Vandrovec Ing. VTEI" <VANDROVE@vc.cvut.cz>]

Hi Martin,
  I read your specification and it looks good, except that
(1) in proc filesystem, you (probably due to mistake) used
   pci0/xx.x/...
   pci1/xx.x/...
   usb0/xx.x/...
  Isn't it better to use pci/0/..., pci/1/... ?
  I also did not understand, if pci0/07.0/x.xx are devices on
bridge 7.0 on bus pci0, how is accessible bridge itself? As some
file in 07.0 subdirectory?
(2) will you offer some bus_to_bus address translation functions, for
  example for supporting DMA from one (PCI) bus to another on PowerPC
  (PowerPC uses translating bridge)?
(3) do not forget about architectures which maps regular I/O into
  memory address space - we should have ioremap_io() and inl/outl (_le?) -
  on ia32, ioremap_io = nothing, inl/outl are I/O operations, on
  PreP PPC, ioremap_io = return io+0x80000000; and inl/outl are synonyms
  for readl/writel...

  And for byte endianess in readl/writel - if you'll say that on every
architecture readl/writel will store long in little endian, we can
live with it - but I do not know why. If processors supports storing
data with both endianess, why not to export this functionality to kernel
drivers? I can understand that ia32 peoples complaints about supporting
readl_be on their hardware, but PPC can do both be and le accesses very
easy...
  If some ports have problem with it (specific iomapping and universal
load/store), then we can create complete set with both ioremap_[lb]e,
{read,write}[wl]_[bl]e. If there is some functionality hidden from
users, programmers get around with ugly hacks... Isn't it easier to
open the doors?
  For example matroxfb have to be compatible with old XF86_SVGA on PPC
(do not have, but it is better if it cost almost nothing...). And XF86_SVGA
on PPC switched matrox into big endian mode... So have I to byteswap
all pixels and commands written to hardware and then store these data
to hardware using little-endian store? Why? Or should I break backward
compatibility for no real reason? I do not want to do that.
                                That's all (for now),
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/