From: Hayes Wang <hayeswang@realtek.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
nic_swsd <nic_swsd@realtek.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Oliver Neukum <oliver@neukum.org>
Subject: RE: [PATCH net-next 0/3] r8152: configuration setting
Date: Thu, 8 Sep 2016 13:02:01 +0000 [thread overview]
Message-ID: <0835B3720019904CB8F7AA43166CEEB201026170@RTITMBSV03.realtek.com.tw> (raw)
In-Reply-To: <87vay6hlmc.fsf@miraculix.mork.no>
Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Thursday, September 08, 2016 3:55 PM
[...]
> Yes, I see that. But is that strictly necessary? Couldn't you just say:
> "CDC ECM is supported by cdc_ether and therefore limited to the features
> implemented by cdc_ether. If you want feature X, then please use our
> vendor specific mode with the r8152 driver?"
My customs have a case that they must force the speed to 100M
for some reasons. I also wish to implement the driver as simple
as possible, but I don't think I could determine this. I accept
you reject my patches. However, I couldn't deny the requests
from the boss or customs without doing anything. I must prove
the way is unacceptable.
[...]
> Each USB configuation comes with a set of descriptors identifying the
> functions, and USB interface drivers attach to the functions they
> support. The user can dynamically switch the device from e.g. cfg #1 to
> cfg #3 by writing "3" to /sys/bus/usb/devices/<port>/bConfigurationValue
> This will cause the ECM and ACM USB interfaces to disappear, and the
> associated class drivers will unbind, and new vendor specific USB
> interfaces appear instead, causing a matching vendor specific driver to
> load and bind.
>
> Naturally, end users will not switch configurations all the time. They
> will select the configuration providing the set of functions they want.
> If this is different from the default configuration selected by the
> Linux USB core, then that's a simple udev rule to update the
> bConfigurationValue sysfs attribute on device disceovery.
I tested above method before. And I found that the cdc_ether
was loaded before switching the configuration. The behavior
of loading one driver and changing to another driver has
opportunity to let our some previous chips become abnormal.
To switch configuration is fine. However, it may have problem
to switch driver. That is why the current kernel only supports
vendor mode. If the method works fine, I have no trouble now.
Best Regards,
Hayes
next prev parent reply other threads:[~2016-09-08 13:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-07 8:12 Hayes Wang
2016-09-07 8:12 ` [PATCH net-next 1/3] r8152: check hw version first Hayes Wang
2016-09-07 8:12 ` [PATCH net-next 2/3] r8152: support ECM mode Hayes Wang
2016-09-18 18:37 ` kbuild test robot
2016-09-19 0:43 ` kbuild test robot
2016-09-07 8:12 ` [PATCH net-next 3/3] r8152: add CONFIG_RTL8152_CONFIG_VALUE Hayes Wang
2016-09-07 13:51 ` [PATCH net-next 0/3] r8152: configuration setting Bjørn Mork
2016-09-08 2:44 ` Hayes Wang
2016-09-08 7:54 ` Bjørn Mork
2016-09-08 13:02 ` Hayes Wang [this message]
2016-09-08 13:08 ` Oliver Neukum
2016-09-08 13:16 ` Bjørn Mork
2016-09-08 0:37 ` David Miller
2016-09-08 3:00 ` Hayes Wang
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=0835B3720019904CB8F7AA43166CEEB201026170@RTITMBSV03.realtek.com.tw \
--to=hayeswang@realtek.com \
--cc=bjorn@mork.no \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=oliver@neukum.org \
/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
all inboxes | Powered by JetHome®