netdev - Re: [RFC] wwan: add a new WWAN subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 02 Mar 2020 14:06:14 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        Alex Elder <elder@...aro.org>, m.chetan.kumar@...el.com,
        Dan Williams <dcbw@...hat.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [RFC] wwan: add a new WWAN subsystem

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