[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sjrrxfjd.fsf@nemi.mork.no>
Date: Fri, 03 Jun 2011 14:31:18 +0200
From: Bjørn Mork <bjorn@...k.no>
To: Oliver Neukum <oneukum@...e.de>
Cc: Alexey ORISHKO <alexey.orishko@...ricsson.com>,
"Valdis.Kletnieks\@vt.edu" <Valdis.Kletnieks@...edu>,
Dan Williams <dcbw@...hat.com>,
Stefan Metzmacher <metze@...ba.org>,
Oliver Neukum <oliver@...kum.name>,
"Greg Kroah-Hartman" <gregkh@...e.de>,
"linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
Oliver Neukum <oneukum@...e.de> writes:
> Well, but cdc-ether usually means that you can start up dhcp and use the
> interface as a network card. Can the same be done with cdc-ncm or do you always
> need to establish a connection through a secondary interface?
Is there anything in the class definition that prevents either option,
for either protocol? No?
So, could we please kill the device guessing game? Making decisions
based on absolute measures like "do we have a global mac address?" do
make some sense. But guessing based on USB class does not. That will
only tell you the protocol for the USB link. If you want more specific
device information, then you will have to look at the vid/pid. And I
assume you don't want to put all of those into the kernel when a class
driver will do, and whatever additional device specific information just
as well can be added by udev rules. Preferably created by whatever
application wishing to support the device.
But I do also assume you know all this already...
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists