netdev - Re: [PATCH net-next v2 6/6] r8152: support RTL8153

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8738l58pyd.fsf@nemi.mork.no>
Date:	Fri, 03 Jan 2014 08:49:46 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	hayeswang <hayeswang@...ltek.com>
Cc:	<oliver@...kum.org>, <netdev@...r.kernel.org>,
	"'nic_swsd'" <nic_swsd@...ltek.com>,
	<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [PATCH net-next v2 6/6] r8152: support RTL8153

hayeswang <hayeswang@...ltek.com> writes:

>  Bjørn Mork [mailto:bjorn@...k.no] 
>> Sent: Thursday, January 02, 2014 10:25 PM
>> To: Hayeswang
>> Cc: oliver@...kum.org; netdev@...r.kernel.org; nic_swsd; 
>> linux-kernel@...r.kernel.org; linux-usb@...r.kernel.org
>> Subject: Re: [PATCH net-next v2 6/6] r8152: support RTL8153
>> 
> [...]
>> > +#if defined(CONFIG_USB_RTL8152) || 
>> defined(CONFIG_USB_RTL8152_MODULE)
>> > +/* Samsung USB Ethernet Adapters */
>> > +{
>> > +	USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, 
>> 0xa101, USB_CLASS_COMM,
>> > +			USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
>> > +	.driver_info = 0,
>> > +},
>> > +#endif
>> 
>> 
>> We don't play the if-other-driver-is-enabled for any other of the
>> blacklisted devices, including other devices supported by the RTL8152
>> driver.  Why do we need it here?
>
> The USB nic have two configurations. One is the config 2 which is the ECM
> mode and uses the driver of cdc_ether. The other is the config 1 which use
> the driver of r8152.

Sorry, but then this makes even less sense.  The active USB
configuration is user selectable and you should make any of them work if
possible.  Why can't the drivers figure out this at runtime?

> When the dangle is plugged, I find the configuration
> is 2 and the ECM driver would be loaded.

The USB core will normally select cfg #1, but prefers classful
configurations over vendor-specific ones.  It will loop through all
possible configurations looking at the first interface of each of them,
and then select the first one with a class different from 0xff.

So what you write above indicates that the first interface of cfg #1 is
vendor specific.  But this doesn't seem to match the r815x driver, so I
don't quite understand the layout here.

In any case, if your device provides two _different_ functions in
different configurations, but using the exact class, subclass and
protocol, then I'd call that device buggy.  If at least one of these are
different, then it shouldn't be a problem making the respective drivers
match these functions.

> By this way, you could select
> which mode you want to run. Some people would select ECM mode for
> performance, and the other would select r8152 for power saving.

Build time driver selection is useless. All distros will enable all
drivers. End users don't build kernels.  That ended sometime around the
release of Linux 2.2

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