From: "Bjørn Mork" <bjorn@mork.no>
To: Oliver Neukum <oneukum@suse.com>
Cc: Kristian Evensen <kristian.evensen@gmail.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling
Date: Mon, 08 Aug 2016 14:44:08 +0200 [thread overview]
Message-ID: <87y4475t2f.fsf@miraculix.mork.no> (raw)
In-Reply-To: <1468851242.2280.14.camel@suse.com> (Oliver Neukum's message of "Mon, 18 Jul 2016 16:14:02 +0200")
Oliver Neukum <oneukum@suse.com> writes:
> On Mon, 2016-07-18 at 16:10 +0200, Kristian Evensen wrote:
>> On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum <oneukum@suse.com> wrote:
>> > No, you misunderstand me. I don't want quirks if we can avoid it.
>> > But if you need to do this for rndis_host and cdc_ether and maybe other
>> > drivers you should not be touching drivers. This belongs into the core
>> > ethernet code. Your code is good, but you are putting it in the wrong
>> > places.
>>
>> Ok, sounds good. So far, I have only seen the random MAC issue with
>> the three previously mentioned devices, but who knows how many else is
>> out there with the same error ... I don't think it should be in the
>> core ethernet code, at least not yet, but I agree it would make sense
>> to move it to for example usbnet_core(). If you agree, I can prepare a
>> patch for it.
>
> I don't see how it would be specific for a subsystem. If the patch
> is correct, it belongs into the networking core.
The bug is in the firmware implementation of the "read unique vendor
assigned mac address" functions, and should therefore be fixed there.
It cannot be put into the networking core because "read unique vendor
assigned mac address" is a hardware dependent function. It's
implemented in each ethernet driver based of whatever interface the
firmware provides to that register.
IMHO, usbnet_get_ethernet_addr() would be the most appropriate place for
cdc_ether and other CDC drivers. And generic_rndis_bind() is the correct
place for rndis_host.
Putting this in usbnet_get_ethernet_addr() will also fix the XMM7160
based devices having an FF:FF:FF:FF:FF:FF mac address (sic). I'm pretty
sure there are other examples too. There is no end to the creative
crazyness of firmware engineers...
An lsusb snippet example:
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 13
bInterfaceProtocol 0
iInterface 5 Sierra Wireless EM7345 4G LTE (NCM)
CDC Header:
bcdCDC 1.20
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC NCM:
bcdNcmVersion 1.00
bmNetworkCapabilities 0x00
CDC Ethernet:
iMacAddress 6 FFFFFFFFFFFF
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
FWIW, putting the fix in usbnet_get_ethernet_addr() will not be a
problem for qmi_wwan. It will further fix up the resulting random
address if required.
Bjørn
next prev parent reply other threads:[~2016-08-08 12:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 12:24 [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling Kristian Evensen
2016-07-18 13:01 ` Oliver Neukum
2016-07-18 13:23 ` Kristian Evensen
2016-07-18 13:50 ` Oliver Neukum
2016-07-18 14:10 ` Kristian Evensen
2016-07-18 14:14 ` Oliver Neukum
2016-07-18 14:27 ` Kristian Evensen
2016-07-18 15:04 ` Kristian Evensen
2016-07-19 6:20 ` Oliver Neukum
2016-07-19 6:40 ` Kristian Evensen
2016-07-19 7:17 ` Oliver Neukum
2016-07-19 8:30 ` Lars Melin
2016-07-19 11:06 ` Kristian Evensen
2016-08-08 12:44 ` Bjørn Mork [this message]
2016-08-08 13:57 ` Oliver Neukum
2016-08-08 18:30 ` Bjørn Mork
2016-08-18 8:03 ` Oliver Neukum
-- strict thread matches above, loose matches on Subject: below --
2016-07-19 12:14 Andrey Melnikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4475t2f.fsf@miraculix.mork.no \
--to=bjorn@mork.no \
--cc=kristian.evensen@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox