From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753215AbcGSMOX (ORCPT ); Tue, 19 Jul 2016 08:14:23 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:35377 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752489AbcGSMOV (ORCPT ); Tue, 19 Jul 2016 08:14:21 -0400 MIME-Version: 1.0 From: Andrey Melnikov Date: Tue, 19 Jul 2016 15:14:19 +0300 Message-ID: Subject: Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling To: Kristian Evensen , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Tue, Jul 19, 2016 at 10:30 AM, Lars Melin wrote: > > On 2016-07-19 13:40, Kristian Evensen wrote: > > > >> I guess I can match on the VID/PID in usbnet, but won't it be cleaner > >> to add a new bind() function (in cdc_ether) which matches the two PIDs > >> and leave usbnet as is? Or am I misunderstanding how to add this > >> functionality to usbnet? > >> > > > > Matching on the usb id is probably not a great idea, there is more id's > > than the two you have found and there is also more than two non-unique mac > > addresses. > > > > Example: > > > > 0200FFAAAAAA 19d2:1589/1592/1595 > > 020CE70B0102 19d2:1040/1048/1405 > > > > You can easily find them by googling them, without colon separators you > > will find them in verbose lsusb listings, with colons you will find them in > > dmesg pastings. > > > > I would probably have found more dupes if users had refrained from using the > > stupid usbdevices cmd which removes almost all interesting info from device > > listings in internet foras. > Thanks for letting me know. It seems that the static MAC behaviour is > the default behaviour of ZTE-devices that use cdc_ether. Unless anyone > objects, I will make the following changes for v2: > * Create a ZTE-specific bind method in cdc_ether that checks for a > random MAC and generates a new MAC if found. > * Use the ZTE-specific bind + rx fixup for all ZTE cdc_ether devices > by default, and add exceptions if we find any devices not displaying > this behaviour. I see there are already five ZTE devices with separate > entries in the products-array in cdc_ether. This is not only ZTE specific bug. Huawei (balong based) modems use predefined MAC 0a:5b:8f:27:9a:64. I think - better detect this devices by MAC address, not by VID/PID.