From: David Howells
bpf_read() and bpf_read_str() could potentially be abused to (eg) allow
private keys in kernel memory to be leaked. Disable them if the kernel
has been locked down in confidentiality mode.
Suggested-by: Alexei Starovoitov
Signed-off-by: Matthew Garrett
Reviewed-by: Kees
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
Acked-by: Matthew Garrett
--
Matthew Garrett | mj...@srcf.uc
From: Matthew Garrett
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 CH9200 provides a rea
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
is halted, and does 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 PROTE
ere's actually been a
released version 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
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 doe
ght now it
appears 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
nk it's probably too new to
be useful, 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
d the new firmware will still 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 +0000, 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
the cost 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:/
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.
>
>
quot;up" state. While there's
definitely a benefit to the sort of PM you're describing (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 | [
pci_dev *pci_dev)
netif_device_attach(dev);
/* Bring the device back up */
- if (!(priv->status & STATUS_RF_KILL_SW))
+ if (!(priv->status & STATUS_RF_KILL_SW) && (dev->flags & IFF_UP))
ipw2100_up(priv, 0);
-
+ el
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
ed. (a) is a slightly more special
case - if the switch 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 unsubscri
ght take for
APs to respond? I'm afraid that my 802.11 knowledge 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
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?
--
Matt
requests
one. Would this cause 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
do
> we have the granularity to still receive while the transmit 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...
e that have some better power
> control over hardware.
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
y users are willing to accept losing some
battery for, and there probably isn't a single right answer)
> [2] would it be permissible to temporarily power up the device on scan?
> Eg how frequently does the desktop expect to poll for scanning, and what
> kind of latency would be tolerab
if the interface is down. In
that case, I'm pretty sure we need a third state 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
24 matches
Mail list logo
