Hi Andrew, To completely my response here, sorry for the delay. > Looking at it bottom up, is the WWAN device itself made up of multiple > devices? Are the TTYs separate drivers to the packet moving engines? > They have there own USB end points, and could just be standard CDC > ACM? Depends on the device, must often yes; Yes and yes. In fact, they _are_ often just the standard drivers, so sometimes you don't even know if that thing is part of the modem or not, without further out-of-band information. For the netdevs that was partially solved by USB ID matching and netdev "wwan" type. > driver/base/component.c could be useful for bringing together these > individual devices to form the whole WWAN device. This is often used > for graphics drivers, where there can be i2c devices, display pipeline > devices, acceleration drivers etc, which each probe separately, but > need to be brought together to form a gpu driver as a whole. I looked at this now, but ... Hmm. It's not really clear that really is usable directly. The component framework really wants to have a 'master' and a bunch of 'components', whereas in the WWAN case you don't really have a master, necessarily? Each part _may_ contribute something to the overall picture, but it could also just be one of those ACM drivers that doesn't really know if it's part of a modem or not, so it just tentatively adds something without knowing if there will even _be_ an overall WWAN device. Also, I don't think a WWAN device is necessarily "done" at some point. It may be, for example, that the netdev sub-device knows that it's part of a modem so it registers "yes I know this is a modem", but then the other pieces are only discovered later, without knowing what they might even be. Could be that they aren't, however, but even then the WWAN device would still exist and be useful to some extent. I don't see a way of expressing any of this with the component framework. Yes, all of the pieces could register there, but then why should any particular one of them register as a component master? That would at the very least have to be hidden under some other abstraction, but even if it is, it's not clear that we might not - in the future, not in my code now - have some sort of "if there are certain pieces that we know belong together then it must be a modem" logic... And once it decided that it's "done" (a master is 'bound'), the component framework will not add further components to a master or similar, and it doesn't really seem suited to doing that either. > Plus you need to avoid confusion by not adding another "component > framework" which means something totally different to the existing > component framework. Fair point. I guess I can rename this somehow, or clarify the differences in the code. johannes
