A few initial EM7565 observations

[Bjørn Mork]

Dan Williams <dcbw at redhat.com> writes:

> On Thu, 2018-01-18 at 18:55 +0100, Bjørn Mork wrote:
>> Dan Williams <dcbw at redhat.com> writes:
>> > On Wed, 2018-01-17 at 23:03 +0100, Bjørn Mork wrote:
>> > 
>> > > Nice.  That confirms the theory: QMAP is the future.  Good thing
>> > > we
>> > > already support that then :-)
>> > 
>> > I guess we should find out how to make drivers/net/qualcomm/rmnet
>> > work
>> > with qmi_wwan then...
>> 
>> Or just use the support built into qmi_wwan.  See the
>> 
>>  /sys/class/net/<iface>/qmi/{add_mux,del_mux}
>> 
>> syfs attributes.  They are even (sort of) documented:
>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net-
>> qmi
>> 
>> Qualcomm was a bit late into the game as always.  Not as late as
>> usual,
>> but still too late.
>
> Oh hey cool, missed that or forgot about it, not sure which.  Though it
> still seems to me that having two drivers to do the same thing
> (theoretically) is somewhat redundant.

Yes, the qmi_wwan implementation would not have been done if we had
known about the Qualcomm plans.

> I was hoping you'd chime in
> when the rmnet driver got proposed upstream, but davem merged it anyway
> even though I think it has some conceptual issues.

And I think his strategy is sane.  Let's see where this goes.  If it
doesn't go anywhere, then there is no harm done.  But we do not want to
create unnecessary problems for Qualcomm when they finally try to
contribute to mainline.

> Do we plan to
> support most of the things that the rmnet driver does (aggregation,
> etc) or do we plan on making them compatible with each other at some
> point?

Personally I have no plans for more features in qmi_wwan.  But I will
not object if someone else needs something either.  Not that I think I
can.  Davem will see right through that ;-)

My hope is that someone at Qualcomm has some plan covering all the loose
ends.  I am just going to wait and see where they take this.  I believe
it is great that they finally have started contributing to the community
they depend on.  Although they still have a long way to go wrt
communication. There are lots of NDA docs which should be publically
available. And they probably have plans which should be discussed with
the community.  Or we should at least know about them, so that we can
avoid more redundant implementations etc. But it's a start. The
direction is good.


Bjørn