On Tue, Sep 22, 2015 at 09:29:49AM +0200, Tobias Klauser wrote:
> Converts the ch9200 driver to use the module_usb_driver() macro which
> makes the code smaller and a bit simpler.
>
> Signed-off-by: Tobias Klauser <tklau...@distanz.ch>
Acked-by: Matthew Garrett <mj...@srcf.u
From: Matthew Garrett <mj...@srcf.ucam.org>
There's a bunch of cheap USB 10/100 devices based on QinHeng chipsets. The
vendor driver supports the CH9100 and CH9200 devices, but the majority of
the code is of the if (ch9100) {} else {} form, with the most significant
difference being that
a partial chip reset turns off the activity LEDs too.
Do you still get link beat detection when the phy is powered down?
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Sat, Jun 30, 2007 at 07:44:59AM -0700, Arjan van de Ven wrote:
Matthew Garrett wrote:
Do you still get link beat detection when the phy is powered down?
does that matter?
If the interface is down, nic drivers aren't expected to detect
link... if userspace wants to find link status
that works, it's a bit early to set a timescale.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
, unfortunately...
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
as an entirely separate branch of the device tree, which doesn't
seem quite right.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Feb 10, 2007 at 10:03:57PM +0100, Michael Buesch wrote:
On Saturday 10 February 2007 21:46, Matthew Garrett wrote:
I'm testing with your bcm43xx git tree, which I'm guessing is the
current ssb code. The only problem I've found is that there doesn't seem
to be any sysfs
also drive the old cards?
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 01, 2007 at 09:47:05AM +0800, Zhu Yi wrote:
On Wed, 2007-01-31 at 07:52 +, Matthew Garrett wrote:
From my understanding, the intention of this patch is to defer the
device self-initialization work (including firmware loading) from netdev
initialization time to netdev open time
);
+ }
+
mutex_unlock(priv-action_mutex);
return 0;
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
(it's a model
we've already started using on the desktop as far as the CPU goes), I
think we still want to be able to expose as much power saving as
possible.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Wed, Jan 31, 2007 at 12:13:04PM +0100, Andi Kleen wrote:
Matthew Garrett [EMAIL PROTECTED] writes:
PCI seems to require a delay of 10ms when sequencing from D3 to D0,
which probably isn't acceptable latency for an up state.
It might be if the interface has been idle for some time
of some performance. It's
not as good as powering down the hardware completely, though.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
rather than just up
or down.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
, and what
kind of latency would be tolerable?
network-manager's behaviour when the interface is inactive is to scan
every 2 minutes. I don't think latency is too much of an issue.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
.
I'd have some concerns over how that would interact with the rest of the
PM infrastructure, but it certainly sounds good in principle.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
paths are
powered down?
Is rfkill not just primarily an interface for us getting events when the
radio changes state? Every time I read up on it I get a little more
confused - some time I really need to make sense of it...
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list
problems in some cases?
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote:
(allowing scanning while the interface is down)
No, it's absolutely a bug. It just so happens that some drivers incorrectly
allowed it.
Ok. Would it be reasonable to add warnings to any devices that allow it?
--
Matthew Garrett
is pretty slim.
Picking a number out of thin air would be one answer, but clearly less
than ideal. This may be a case of us not being able to satisfy everyone,
and so just having to force the user to choose between low power or
wireless scanning.
--
Matthew Garrett | [EMAIL PROTECTED
disables the radio, I guess we then want the driver
to down the interface as well.
In the (a) case, drivers should presumably refuse to bring the interface
up if the radio is disabled?
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev
On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote:
Matthew Garrett wrote:
Hm. Does the spec not set any upper bound on how long it might take for
APs to respond? I'm afraid that my 802.11 knowledge is pretty slim.
I'm not sure, but thats not entirely relevant either. The time
23 matches
Mail list logo
