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

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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