On Tue, Dec 16, 2008 at 9:41 PM, Wolfram Sang <w.s...@pengutronix.de> wrote: > >> It is pretty poor form to not even bother to Cc the only author of the >> code you are modifying, and have no Signed-off-by or Acked-by to even >> suggest that it was ever even looked at. This isn't something that ought >> to have to be pointed out, either. > > Oops, yes, forgot this in the resend, I am sorry. I did CC Magnus in the > first round, though, and he replied to me that he liked adding OF and > just waited for Hans' reply first.
Right, that's exactly what happened. Last time when the platform drivers got merged was very very very intense so I expected a similar situation. Please excuse the hands-off handling. The result of our discussions last time was basically that we should have two reusable uio platform drivers; the regular uio_pdrv and uio_pdrv_genirq. The good thing with this is that we clearly show the difference between the two drivers, most people should just use the regular uio_pdrv driver and crazy people with unique interrupt sources should use the genirq version. The downside with the two drivers is the duplicated code, but I guess that's ok for now. >> In addition to the stuff pointed out by Greg, I don't see what you >> actually gain by hacking the OF crap in to this driver. You would be >> better off layering the OF driver on top of this, rather than trying to >> make them live together in the same file. I totally agree. > See my reply just posted. I found two ways to go, and from reading > discussions on the lists, finally decided for this way. May have been > the wrong path, but nothing that could not be changed. In my mind, the best way forward is to write a new uio driver that interfaces to open firmware. After that we can break out things like resource handling and maybe generic interrupt code. Please CC me and I'll help out. Cheers, / magnus _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
