On Tue, 2019-06-18 at 23:06 +0200, Arnd Bergmann wrote: > On Tue, Jun 18, 2019 at 10:39 PM Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-06-18 at 22:33 +0200, Arnd Bergmann wrote: > > It seems to me though that this is far more complex than what I'm > > proposing? What I'm proposing there doesn't even need any userspace > > involvement, as long as all the pieces are in the different sub- > > drivers, > > they'd fall out automatically. > > > > And realistically, the wwan_device falls out anyway at some point, > > the > > only question is if we really make one specific driver be the > > "owner" of > > it. I'm suggesting that we don't, and just make its lifetime depend > > on > > the links to parts it has (unless something like IPA actually wants > > to > > be an owner). > > My feeling so far is that having the wwan_device be owned by a device > gives a nicer abstraction model that is also simpler for the common > case. A device driver like ipa would end up with a probe() function > that does does wwan_device_alloc/wwan_device_register, corresponding > to alloc_etherdev/register_netdev, and then communicates through > callbacks. > > I agree the compound device case would get more complex by > shoehorning it into this model, but that can be a valid tradeoff > if it's the exceptional case rather than the common one. In my experience, the compound device model is by far the most prevalent for regular Linux distros or anything *not* running on an SoC with an integrated modem. But it's also quite common for Android, no? drivers/net/ethernet/msm/ has rmnet and IPA ethernet drivers while arch/arm/mach-msm/ has various SMD-related control channel drivers like smd_tty.c and smd_qmi.c and smd_nmea.c. At least that's how I remember older SMD-based devices being in the 8xxx and 9xxx time. Ideally those setups can benefit from this framework as well, without having to write entirely new composite drivers for those devices. Dan
