Re: [PATCH 2.6.17-rc5-mm2 17/18] sbp2: provide helptext for CONFIG_IEEE1394_SBP2_PHYS_DMA and mark it experimental

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ben Collins wrote:
Rather it be in the config. Plus your suggestion still makes it
unusable :)

Right. But only if ohci1394 is loaded with phys_dma=0 or a controller without phys DMA is used. Only these conditions let sbp2 run into the routine which currently uses bus_to_virt.

Right now, sbp2 is unusable _on all platforms_ if these conditions apply and if CONFIG_IEEE1394_SBP2_PHYS_DMA=N.

The previously sent "address range properties" patches would allow sbp2 to check for phys DMA at runtime. If phys DMA is off, sbp2 may either proceed to use the old bus_to_virt mapping or say: "Sorry lad, I won't connect unless you get this phys DMA thing going." (Until sbp2 learns platform independent DMA mapping.) IOW we could get rid of the CONFIG_IEEE1394_SBP2_PHYS_DMA switch immediately.

But since the non-phys-DMA mode of sbp2 is currently prone to lock-ups, runtime detection of non-phys-DMA is of lower priority to me.

I suggest instead doing '&& X86_32'. That should affect the least people
and keep it where it's known to work.

Would '&& (X86_32 || PPC_32)' work too?
--
Stefan Richter
-=====-=-==- -==- ---==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux