I can hope this will be my last post on this topic, but you did deserve a response to your last note ...
> My response was that you're focus for the driver was wrong. You should > be targeting for a working system, not a buggy one. Which, as I repeatedly explained, WAS exactly the target. Not a fact you wanted to hear, I can tell. Really hearing it would have helped avoid much noise. > We can [ ... make all kinds of changes to resemble uhci ...] Let's not and say we didn't. I did observe how you do that stuff in "uhci.c" and see no reason to change. It's different hardware, different problems ... different solutions. > I spent some time trying to keep the conversations on topic and if that > meant focusing on the real topic at hand, then I did. That is, the subtopic you wanted to talk about ... rather than a different aspect of the original problem. In terms of resolving issues, that was no help at all. > > Could you give a point of yours that I've _ignored_ rather than > > just not agreeing with? (I know I've pointed out this one issue more > > than once, including your non-responses.) > > This whole thread for instance. You keep arguing that sohci_free_dev > should be that complicated. I did not. Certainly that's your phrasing, not mine, and I don't thank you for blaming it on me. If I justified anything, it was the current code (ohci-hcd), which is already much simpler. I started by reminding you that the bus->deallocate() may block, and has been allowed for several years now, though you kept claiming otherwise. Your refcount changes caused trouble in that area, which was not an issue in the 2.5.15 code. Now, at some point you evidently absorbed the fact that you were wrong about that, then decided that rather than say so, you would instead change the topic ...attacking that reality as if it were a bug. Only a very few recent messages made up the changed topic, "this whole thread", from what I can tell. Perhaps I should have noticed that's what was going on, but my l33t mind-reading skillz aren't that strong. But considering that you only went down that track recently, and I _did_ reply to it, you can't really believe I ignored what you said. > However I keep pointing to uhci.c since it has pretty much the same > problems. It's an example of how you can do this better. It's nothing but biased opinion to say "better" here. You want to make tradeoffs one way, for hardware that is much less involved in maintaining endpoint state, which may be fine for that hardware (UHCI). But the identical reasoning cannot apply when the hardware is more involved (EHCI and OHCI). You need to at least admit that there are differences, despite the surface similarities which I had identified to you. I see it as you wanting to simplify one thing by making others more complex ... and by making fairly significant changes to the policy for managing endpoint state, including data toggles (which are maintained in hardware except for UHCI) and for handling the inevitable faults. There'd be a performance impact to be that aggressive about taking the endpoint data (ED/QH) off the hardware schedules, since it'd mean waiting extra intervals (frames/microframes) for the endpoint unlinks to complete ... slowing down things like bulk data requeuing speed. > I haven't seen very many arguments refuting it, you just keep saying > things like "QH != dev", which are patently obvious and don't actually > address the fact I've solved the problems with uhci.c. Patently obvious, but clearly not reflected in your original comment. You were advocating a QH management policy that could only work for devices... or so it seemed. (Maybe you were just omitting 90% of what you were thinking.) > Anyway, all of this boils down to, been there, done that. I think you got carried away by the similarities I pointed out when explaining some of this to you. There are also noteworthy differences. The problem you solved was different. - Dave _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
