Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx> writes: > Hello. > > Kevin Hilman wrote: > >>> There's absolutely no reason why the DaVinci USB platfrom device should >>> be in its own module; >> >> Other than devices*.c getting very cluttered, difficult to maintain >> and the root cause of merge conflicts because of so many unrleated >> patches wanting to touch the same files. >> >> For this reason, as well as to share more between DMx and DA8xx, I >> would like to move to a model where devices.c is split up into usb.c, >> mmc.c, etc., so I don't like this change. >> > > And I should say that don't like the split up idea. Because for me > it would mean that we're going to live in cpu_is_*() hell for all the > platform devices as every device detail is different between DaVincis > and DA8xx -- there is not much common, contrary to what you seem to > believe; and I started to hope that we'd avoid that kind of cpu_is_*() > hell... That said, I've never been fond of your idea of having both > subarchs in the single directory too. Now, with this split-up, this > approach is going to be even more messy... > >>> moreover, it will stand in the way of DA8xx's USB >>> platfrom device which occupies different region and IRQ -- so, move it >>> into devices.c and get rid of usb.c... >>> >> >> I'd rather see both DMx and da8xx consolidated into usb.c. In your >> patches, there is lots of duplication between those files. >> > > I wouldn't like to live in cpu_is_*() hell, hence I had no choice > but duplicate... I'll choose cpu_is_*() over code duplication. >> Then usb.c would have all the resource and platform_data for all devices >> and the interface would be: >> >> davinci_register_usb() -- renamed from setup_usb() >> da8xx_register_usb11() >> da8xx_register_usb20() >> > > Oh... if that means I can still have different MUSB platform devices > (with the same platform data probably) for DaVinci and DA8xx and get > around using cpu_is_*(), then I can consider that... That would be fine with me. > But anyway, that would mean that the e.g. the DaVinci code would be > burdened with e.g DA8xx devices when DA8xx is *not* configured (and > vice versa), unless we introduce some #ifdef'ery into this file -- > so I still don't quite like your idea... Yes, burdened by a little memory bloat at the expense of a maintainable kernel. That's the trade-off, and I've chosen maintainability. The memory bloat is easy enough to solve by using #ifdefs if you like. I do not object to #ifdefs in these cases. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
