Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 08:50:24AM +0100, Arjan van de Ven wrote: (Adding netdev - context is the altering of the runtime power management interface, with the effect that it's no longer possible for userspace to request that drivers suspend a device, so Arjan has suggested that we do it via other existing interfaces) > > Seriously. How many pieces of userspace-visible functionality have > > recently been removed without there being any sort of alternative? > > There IS an alternative, you're using it for networking: > > You *down the interface*. > > If there's a NIC that doesn't support that let us (or preferably netdev) > know and it'll get fixed quickly I'm sure. As far as I can tell, the following network devices don't put the hardware into D3 on interface down: 3c59x 8139too acenic amd8111e b44 cassini defxx dl2k e100 e1000 epic100 fealnx forcedeth hamachi hp100 ioc3-eth natsemi ne2k-pci ns83820 pcnet32 qla3xxx rtl8169 rrunner s2io saa9730 sis190 sis900 skge sky2 spider_net starfire sundance sungem sunhme tc35815 tlan via-rhine yellowfin while these ones do: bnx2 tg3 typhoon via-velocity tulip is somewhere in between - it puts the chip in a lower power state, but not D3. It's possible that some of the other drivers do something similar, but nothing leapt out at me. The situation is more complicated for wireless. Userspace expects to be able to get scan results from the card even 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
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: > about your driver list; > do you have an idea of what the top 5 relevant ones would be? > I'd be surprised if the top 5 together had less than 95% market share, > so if we fix those we'd be mostly done already. In terms of what I've seen on vaguely modern hardware, I'd guess at e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, with via-rhine appearing at the very low end. I'll try to grep through our hardware database results to get a stronger idea about percentages. > > The situation is more complicated for wireless. Userspace expects to be > > able to get scan results from the card even if the interface is down. > > if it's down userspace cannot currently expect this (if it does it's > broken), just as it currently can't expect link notifications when the > interface is down. It needs to have the interface up for this. > (but point taken for a 3rd state) The documentation for what userspace can legitimately expect of the kernel is distinctly lacking, and as far as I can tell most of the common drivers support scanning while the interface is down. It would be immensely helpful if we could have a better idea of which kernel behaviour is deliberate, and which bits of kernel functionality are accidental and might go away at any time. Right now, I have various scripts depending on this behaviour because there's absolutely no indication that I'm not supposed to be. (Of course, I may have missed it somewhere - I've never been able to find terribly comprehensive documentation on WE) > so what do you want from this 3rd state? rough guess based on what I > think the desktop wants (so please correct/append) Just to be clear: in this world view, "down" maps to "fully powered down", so this third state is a "low power consumption mode"? If so: > In the third state you > * don't expect to get or send "regular" packets > * don't have a dhcp lease or anything like that > * you do expect to get link change notification [1] > * you do expect to be able to scan for access points [2] Yes, I think that's a fair summary. > open questions > * what if you get a WOL event? In an ideal world, I think the information would be passed to userspace and it would get to make the distinction. I appreciate that the hardware may have different ideas about what's appropriate... > [1] What kind of latency would be allowed? Would an implementation be > allowed to power up the phy say once per minute or once per 5 minutes to > see if there is link? The implementation could do this progressively; > first poll every X seconds, then after an hour, every minute etc. Yeah, I guess that's a problem. From a user perspective, the functionality is only really useful if the latency is very small. I think where possible we'd want to power down the chip while keeping the phy up, but it would be nice to know how much power that would actually cost us. (We have a similar issue when it comes to stuff like monitor hotplug - it's the sort of thing that many 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 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 of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:49:06PM -0800, Stephen Hemminger wrote: > When device is down, it should: >a) use as few resources as possible: > - not grab memory for buffers > - not assign IRQ unless it could get one > - turn off all power consumption possible >b) allow setting parameters like speed/duplex/autonegotiation, > ring buffers, ... with ethtool, and remember the state Veering off at something of a tangent - how much of this should be true for wireless devices? Softmac seems to be unhappy about setting the essid unless the card is up, which breaks various assumptions... Beyond that, I think your descriptions of up and down states make sense for userspace. As Arjan suggests, there's then the intermediate state of "disable as much as possible while still providing scanning and link detection". > 2) Network device infrastructure should make it easier for devices: > bring interface down on suspend and bring it up after resume > (if it was running when suspended). This would allow many devices to > have no suspend/resume hook; except those 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 "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote: > Entirely correct. If the card is DOWN, the radio should be off (both TX > & RX) and it should be in max power save mode. If userspace expects to > be able to get the card to do _anything_ when it's down, that's just > 110% wrong. You can't get link events for many wired cards when they > are down, so I fail to see where userspace could expect to do anything > with a wireless card when it's down too. Because it works on the common hardware? If there's documentation about what userspace can legitimately expect, then I'm happy to defer to that. But in the absence of any indication as to what functionality users can depend on, deciding that existing functionality is a bug is, well, impolite. > Also, how does rfkill fit into this? rfkill implies killing TX, but 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... -- 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
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote: > Softmac isn't the only wireless code that likes to be configured after going > up first. Configuring after the card goes up has generally been more > reliable, though that should not be necessary and is a bug IMHO. Ok, that's nice to know. > In order to scan, we need to have the radio on and we need to be able to send > and receive. What are you gonna turn off? The obvious route would be to power the card down, but come back up every two minutes to perform a scan, or if userspace explicitly 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
Re: Network drivers that don't suspend on interface down
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 | [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
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 09:38:20PM -0500, Daniel Drake wrote: > I don't think that supporting scanning when the interface is supposed to > be disabled is sensible. If you want to scan, you are simply sending and > receiving frames, it's no different from having the interface up and > sending/receiving data frames. >From a usability point of view, it's helpful to power the card down as much as possible while it's not being actively used. However, it's also helpful to be able to provide a list of available wireless networks, though some degree of latency would be acceptable in that. These two desires are obviously not entirely compatible with one another, so it would be helpful if there was some means of providing an intermediate state. > There are additional implementation problems: scanning requires 2 > different ioctl calls: siwscan, then several giwscan. If you want the > driver to effectively temporarily bring the interface up when userspace > requests a scan but the interface was down, then how does the driver > know when to bring it down again? 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. 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] - 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
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote: > a) tied to the wireless hardware, switch kills hardware directly > b) tied to wireless hardware, but driver handles the kill request > c) just another key, a separate key driver handles the event and asks > the wireless driver to kill the card > > It's also complicated because some switches are supposed to rfkill both > an 802.11 module _and_ a bluetooth module at the same time, or I guess > some laptops may even have one rfkill switch for each wireless device. > Furthermore, some people want to 'softkill' the hardware via software > without pushing the key, which is a subset of (b) or (c) above. If we define interface down as meaning that the device is powered down and the radio switched off, then (b) and (c) would presumably just need to ensure that the interface is downed. (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 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
Re: Network drivers that don't suspend on interface down
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 it takes > for the AP to respond is not related to the delay between userspace > sending the siwscan and giwscan ioctls (unless you're thinking of > userspace being too quick, but GIWSCAN already returns -EINPROGRESS when > appropriate so this is detectable) Ah - I've mostly been looking at the ipw* drivers, where giwscan just seems to return information cached by the ieee80211 layer. A quick scan suggests that most cards behave like this, but prism54 seems to refer to the hardware. I can see why that would cause problems. > I think it's reasonable to keep the interface down, but then when the > user does want to connect, bring the interface up, scan, present scan > results. Scanning is quick, there would be minimal wait needed here. Yeah, that's true. -- 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
Re: [PATCH] b44: power down PHY when interface down
On Sat, Jun 30, 2007 at 02:47:35PM +0300, Török Edvin wrote: > When the interface is down (or driver removed), the BroadCom 44xx card > remains > powered on, and both its MAC and PHY is using up power. > This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface > 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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
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 it should have the > interface up. If that's the policy, why do we leave this up to individual drivers? Right now most of them let you make the query regardless of interface state. I'd agree that there's a need for a state where we power down as much as possible (even at the cost of functionality), but where possible it would also be nice to offer a state where the mac is powered down and the phy left up. If the existing semantics are confused then it would be nice to fix them, too. -- 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
[RFC] Runtime power management on ipw2100
pci_disable_device(pci_dev);
+ pci_set_power_state(pci_dev, PCI_D3hot);
IPW_DEBUG_INFO("exit\n");
@@ -6353,8 +6382,6 @@ static void __devexit ipw2100_pci_remove_one(struct
pci_dev *pci_dev)
if (ipw2100_firmware.version)
ipw2100_release_firmware(priv, &ipw2100_firmware);
#endif
- /* Take down the hardware */
- ipw2100_down(priv);
/* Release the mutex so that the network subsystem can
* complete any needed calls into the driver... */
@@ -6384,7 +6411,6 @@ static void __devexit ipw2100_pci_remove_one(struct
pci_dev *pci_dev)
}
pci_release_regions(pci_dev);
- pci_disable_device(pci_dev);
IPW_DEBUG_INFO("exit\n");
}
@@ -6398,7 +6424,7 @@ static int ipw2100_suspend(struct pci_dev *pci_dev,
pm_message_t state)
IPW_DEBUG_INFO("%s: Going into suspend...\n", dev->name);
mutex_lock(&priv->action_mutex);
- if (priv->status & STATUS_INITIALIZED) {
+ if (priv->status & STATUS_INITIALIZED && dev->flags & IFF_UP) {
/* Take down the device; powers it off, etc. */
ipw2100_down(priv);
}
@@ -6406,9 +6432,11 @@ static int ipw2100_suspend(struct pci_dev *pci_dev,
pm_message_t state)
/* Remove the PRESENT state of the device */
netif_device_detach(dev);
- pci_save_state(pci_dev);
- pci_disable_device(pci_dev);
- pci_set_power_state(pci_dev, PCI_D3hot);
+ if (dev->flags & IFF_UP) {
+ pci_save_state(pci_dev);
+ pci_disable_device(pci_dev);
+ pci_set_power_state(pci_dev, PCI_D3hot);
+ }
mutex_unlock(&priv->action_mutex);
@@ -6453,9 +6481,13 @@ static int ipw2100_resume(struct 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);
-
+ else {
+ pci_disable_device(pci_dev);
+ pci_set_power_state(pci_dev, PCI_D3hot);
+ }
+
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
Re: [linux-pm] [RFC] Runtime power management on ipw2100
On Wed, Jan 31, 2007 at 11:13:07AM +0200, Amit Kucheria wrote: > What is the latency in changing between different PCI power states for > peripherals? I'm not sure in the general case, but the power-down path for the ipw2100 involves a static wait of 100ms in ipw2100_hw_stop_adapter(). > Would it be possible e.g. to put the peripheral into a low power state > after each Tx/Rx (with reasonable hyteresis)? Most wireless drivers support some degree of power management at this scale, but (in ipw2100 at least) it's implemented in the firmware so I have absolutely no idea what it's actually doing. > > > > The situation is slightly more complicated for wired interfaces. As > > previously discussed, we potentially want three interface states (on, > > low power, off) with the intermediate one powering down as much of the > > hardware as possible while still implementing link detection. > > And this low power state is what the HW should be in all the time, > except when it has work to do. PCI seems to require a delay of 10ms when sequencing from D3 to D0, which probably isn't acceptable latency for an "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 | [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
Re: [linux-pm] [RFC] Runtime power management on ipw2100
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 > (and the delay is not busy looping of course) Hm. How would this interact with receiving packets? -- 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
Re: [linux-pm] [RFC] Runtime power management on ipw2100
On Wed, Jan 31, 2007 at 02:44:16PM +0100, Pavel Machek wrote: > Okay, but I'm somehow not sure if ipw2100 can do this kind of > tricks. Yes, n800 is likely very nice toy :-). Well, to an extent - if you use the wext power features, you can get it into a relatively low-power state at 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://vger.kernel.org/majordomo-info.html
Re: [Ipw2100-devel] [RFC] Runtime power management on ipw2100
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 to netdev open time (ifconfig up) and de-initialize
> the device when it is not being used (ifconfig down). This saves power
> during the time the driver is loaded but the interface is not open.
That's correct.
> You should remove ipw2100_up() from ipw2100_net_init() which is
> netdev->init() since it will be called in ->open() in your patch. I'd
> also suggest you to request_irq()/free_irq() in the netdev ->open() and
> ->close() in case the device shares IRQ with other devices, the
> interrupt handler should not be invoked anyway.
I've removed net_init() entirely, since all it did was call
ipw2100_up(). I'm reluctant to drop the IRQ because PCMCIA seems to have
a nasty habit of grabbing free looking IRQs and setting them to be edge
triggered, which would obviously be bad.
How's this patch?
Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index 24ef52a..679946e 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -1809,13 +1809,6 @@ static int ipw2100_up(struct ipw2100_priv *priv, int
deferred)
return rc;
}
-/* Called by register_netdev() */
-static int ipw2100_net_init(struct net_device *dev)
-{
- struct ipw2100_priv *priv = ieee80211_priv(dev);
- return ipw2100_up(priv, 1);
-}
-
static void ipw2100_down(struct ipw2100_priv *priv)
{
unsigned long flags;
@@ -5771,8 +5764,38 @@ static int ipw2100_open(struct net_device *dev)
{
struct ipw2100_priv *priv = ieee80211_priv(dev);
unsigned long flags;
+ int err, val;
IPW_DEBUG_INFO("dev->open\n");
+ mutex_lock(&priv->action_mutex);
+
+ pci_set_power_state(priv->pci_dev, PCI_D0);
+ err = pci_enable_device (priv->pci_dev);
+
+ if (err) {
+ printk(KERN_WARNING DRV_NAME
+ "Error calling pci_enable_device.\n");
+ mutex_unlock(&priv->action_mutex);
+ return err;
+}
+
+ pci_restore_state(priv->pci_dev);
+
+ pci_read_config_dword(priv->pci_dev, 0x40, &val);
+ if ((val & 0xff00) != 0)
+ pci_write_config_dword(priv->pci_dev, 0x40, val & 0x00ff);
+
+ err = ipw2100_up(priv, 0);
+
+ if (err) {
+ printk(KERN_WARNING DRV_NAME
+ " Error bringing card up.\n");
+ pci_disable_device(priv->pci_dev);
+ pci_set_power_state(priv->pci_dev, PCI_D3hot);
+ mutex_unlock(&priv->action_mutex);
+ return err;
+}
+
spin_lock_irqsave(&priv->low_lock, flags);
if (priv->status & STATUS_ASSOCIATED) {
netif_carrier_on(dev);
@@ -5780,6 +5803,8 @@ static int ipw2100_open(struct net_device *dev)
}
spin_unlock_irqrestore(&priv->low_lock, flags);
+ mutex_unlock(&priv->action_mutex);
+
return 0;
}
@@ -5814,6 +5839,19 @@ static int ipw2100_close(struct net_device *dev)
}
spin_unlock_irqrestore(&priv->low_lock, flags);
+ ipw2100_down(priv);
+
+#ifdef ACPI_CSTATE_LIMIT_DEFINED
+ if (priv->config & CFG_C3_DISABLED) {
+ IPW_DEBUG_INFO(": Resetting C3 transitions.\n");
+ acpi_set_cstate_limit(priv->cstate_limit);
+ priv->config &= ~CFG_C3_DISABLED;
+ }
+#endif
+
+ pci_disable_device(priv->pci_dev);
+ pci_set_power_state(priv->pci_dev, PCI_D3hot);
+
IPW_DEBUG_INFO("exit\n");
return 0;
@@ -6021,7 +6059,6 @@ static struct net_device *ipw2100_alloc_device(struct
pci_dev *pci_dev,
dev->open = ipw2100_open;
dev->stop = ipw2100_close;
- dev->init = ipw2100_net_init;
dev->ethtool_ops = &ipw2100_ethtool_ops;
dev->tx_timeout = ipw2100_tx_timeout;
dev->wireless_handlers = &ipw2100_wx_handler_def;
@@ -6208,6 +6245,7 @@ static int ipw2100_pci_init_one(struct pci_dev *pci_dev,
pci_write_config_dword(pci_dev, 0x40, val & 0x00ff);
pci_set_power_state(pci_dev, PCI_D0);
+ pci_save_state(pci_dev);
if (!ipw2100_hw_is_adapter_in_system(dev)) {
printk(KERN_WARNING DRV_NAME
@@ -6274,23 +6312,9 @@ static int ipw2100_pci_init_one(struct pci_dev *pci_dev,
if (err)
goto fail_unlock;
- /* If the RF Kill switch is disabled, go
Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007
On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote: > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and > 4306 revisions even > after d80211 becomes the in-kernel driver. Of course, I hope that we will > have found the killer bugs > by that time, and that maintenance will only require following kernel API > changes. Just to make sure I'm understanding this correctly - does the v4 firmware drop compatibility for older cards, or is it just that Broadcom dropped support in the driver at the same time as the firmware changed, and 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
Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007
On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote: > We don't know. > > It's likely that old cards still work with v4 firmware, but we don't know and > it has to be tested. > > Care to do so? I'll check the revision of my 4306, but I think 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
Re: The new SSB subsystem for bcm43xx (and others)
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 relationship between the ssb bus and (in this case) the PCI device that it's associated with. Is this fixable? Right 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
Re: The new SSB subsystem for bcm43xx (and others)
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 relationship between the ssb bus and (in this case) the
> > PCI device that it's associated with. Is this fixable? Right now it
> > appears as an entirely separate branch of the device tree, which doesn't
> > seem quite right.
>
> I guess that's fixable, but I didn't care too much, yet.
Ok, here's a patch. The stack of PCMCIA headers are needed to get the
pcmcia_device structure. Seems to work fine for PCI - I don't have any
PCMCIA devices. The SSB devices now appear underneath the PCI device
rather than in the top level of /sys/devices.
Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
---
diff --git a/drivers/ssb/scan.c b/drivers/ssb/scan.c
index 64f94b8..b16cee9 100644
--- a/drivers/ssb/scan.c
+++ b/drivers/ssb/scan.c
@@ -15,6 +15,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include
#include "ssb_private.h"
@@ -306,8 +311,12 @@ int ssb_bus_scan(struct ssb_bus *bus,
dev->id.vendor = (idhi & SSB_IDHIGH_VC) >> SSB_IDHIGH_VC_SHIFT;
dev->core_index = i;
dev->bus = bus;
- if ((dev->bus->bustype == SSB_BUSTYPE_PCI) && (bus->host_pci))
+ if ((dev->bus->bustype == SSB_BUSTYPE_PCI) && (bus->host_pci)) {
dev->irq = bus->host_pci->irq;
+ dev->dev.parent = &bus->host_pci->dev;
+ } else if (dev->bus->bustype == SSB_BUSTYPE_PCMCIA) {
+ dev->dev.parent = &bus->host_pcmcia->dev;
+ }
ssb_dprintk(KERN_INFO PFX
"Core %d found: %s "
--
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
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 02:39:00PM -0800, Greg KH wrote: > Ok, I only named HAL as that is what people have told me the problem is. > I have been running this change on my boxs, without > CONFIG_SYSFS_DEPRECATED since last July or so. > > But I don't use NetworkManager here for the most part, but I have tried > this in the OpenSuse10.3 alpha releases and it seems to work just fine > with whatever version of NetworkManager it uses. At a guess, you're carrying either a git snapshot or have backports from git. Several distributions do this, but until there'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
[PATCH] usbnet: New driver for QinHeng CH9200 devices
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 real MII interface but CH9100 fakes
one with a bunch of global variables and magic commands. I don't have a
CH9100, so it's probably better if someone who does provides an independent
driver for it. In any case, this is a lightly cleaned up version of the
vendor driver with all the CH9100 code dropped.
Signed-off-by: Matthew Garrett
---
drivers/net/usb/Kconfig | 11 ++
drivers/net/usb/Makefile | 2 +-
drivers/net/usb/ch9200.c | 443 +++
3 files changed, 455 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/usb/ch9200.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 1610b79..fbb9325 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -583,4 +583,15 @@ config USB_VL600
http://ubuntuforums.org/showpost.php?p=10589647&postcount=17
+config USB_NET_CH9200
+ tristate "QingHeng CH9200 USB ethernet support"
+ depends on USB_USBNET
+ select MII
+ help
+ Choose this option if you have a USB ethernet adapter with a QinHeng
+ CH9200 chipset.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ch9200.
+
endif # USB_NET_DRIVERS
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index cf6a0e6..b5f0406 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -38,4 +38,4 @@ obj-$(CONFIG_USB_NET_HUAWEI_CDC_NCM) += huawei_cdc_ncm.o
obj-$(CONFIG_USB_VL600)+= lg-vl600.o
obj-$(CONFIG_USB_NET_QMI_WWAN) += qmi_wwan.o
obj-$(CONFIG_USB_NET_CDC_MBIM) += cdc_mbim.o
-
+obj-$(CONFIG_USB_NET_CH9200) += ch9200.o
diff --git a/drivers/net/usb/ch9200.c b/drivers/net/usb/ch9200.c
new file mode 100644
index 000..cabb670
--- /dev/null
+++ b/drivers/net/usb/ch9200.c
@@ -0,0 +1,443 @@
+/*
+ * USB 10M/100M ethernet adapter
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CH9200_VID 0x1A86
+#define CH9200_PID_E0920xE092
+
+#define CTRL_TIMEOUT_MS1000
+
+#define CONTROL_TIMEOUT_MS 1000
+
+#define REQUEST_READ 0x0E
+#define REQUEST_WRITE 0x0F
+
+/* Address space:
+ * 00-63 : MII
+ * 64-128: MAC
+ *
+ * Note: all accesses must be 16-bit
+ */
+
+#define MAC_REG_CTRL 64
+#define MAC_REG_STATUS 66
+#define MAC_REG_INTERRUPT_MASK 68
+#define MAC_REG_PHY_COMMAND 70
+#define MAC_REG_PHY_DATA 72
+#define MAC_REG_STATION_L 74
+#define MAC_REG_STATION_M 76
+#define MAC_REG_STATION_H 78
+#define MAC_REG_HASH_L 80
+#define MAC_REG_HASH_M1 82
+#define MAC_REG_HASH_M2 84
+#define MAC_REG_HASH_H 86
+#define MAC_REG_THRESHOLD 88
+#define MAC_REG_FIFO_DEPTH 90
+#define MAC_REG_PAUSE 92
+#define MAC_REG_FLOW_CONTROL 94
+
+/* Control register bits
+ *
+ * Note: bits 13 and 15 are reserved
+ */
+#define LOOPBACK (0x01 << 14)
+#define BASE100X (0x01 << 12)
+#define MBPS_10(0x01 << 11)
+#define DUPLEX_MODE(0x01 << 10)
+#define PAUSE_FRAME(0x01 << 9)
+#define PROMISCUOUS(0x01 << 8)
+#define MULTICAST (0x01 << 7)
+#define BROADCAST (0x01 << 6)
+#define HASH (0x01 << 5)
+#define APPEND_PAD (0x01 << 4)
+#define APPEND_CRC (0x01 << 3)
+#define TRANSMITTER_ACTION (0x01 << 2)
+#define RECEIVER_ACTION(0x01 << 1)
+#define DMA_ACTION (0x01 << 0)
+
+/* Status register bits
+ *
+ * Note: bits 7-15 are reserved
+ */
+#define ALIGNMENT (0x01 << 6)
+#define FIFO_OVER_RUN (0x01 << 5)
+#define FIFO_UNDER_RUN (0x01 << 4)
+#define RX_ERROR (0x01 << 3)
+#define RX_COMPLETE(0x01 << 2)
+#define TX_ERROR (0x01 << 1)
+#define TX_COMPLETE(0x01 << 0)
+
+/* FIFO depth register bits
+ *
+ * Note: bits 6 and 14 are reserved
+ */
+
+#define ETH_TXBD (0x01 << 15)
+#define ETN_TX_FIFO_DEPTH (0x01 << 8)
+#define ETH_RXBD (0x01 << 7)
+#define ETH_RX_FIFO_DEPTH (0x01 << 0)
+
+static int control_read(struct usbnet *dev,
+ unsigned char request, unsigned short value,
+ unsigned short inde
Re: [PATCH] ch9200: Convert to use module_usb_driver
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.ucam.org -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V38 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
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 Cook
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee
cc: Alexei Starovoitov
Cc: Daniel Borkmann
---
include/linux/security.h | 1 +
kernel/trace/bpf_trace.c | 10 ++
security/lockdown/lockdown.c | 1 +
3 files changed, 12 insertions(+)
diff --git a/include/linux/security.h b/include/linux/security.h
index 987d8427f091..8dd1741a52cd 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -118,6 +118,7 @@ enum lockdown_reason {
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_KCORE,
LOCKDOWN_KPROBES,
+ LOCKDOWN_BPF_READ,
LOCKDOWN_CONFIDENTIALITY_MAX,
};
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index ca1255d14576..492a8bfaae98 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -142,8 +142,13 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size, const
void *, unsafe_ptr)
{
int ret;
+ ret = security_locked_down(LOCKDOWN_BPF_READ);
+ if (ret < 0)
+ goto out;
+
ret = probe_kernel_read(dst, unsafe_ptr, size);
if (unlikely(ret < 0))
+out:
memset(dst, 0, size);
return ret;
@@ -569,6 +574,10 @@ BPF_CALL_3(bpf_probe_read_str, void *, dst, u32, size,
{
int ret;
+ ret = security_locked_down(LOCKDOWN_BPF_READ);
+ if (ret < 0)
+ goto out;
+
/*
* The strncpy_from_unsafe() call will likely not fill the entire
* buffer, but that's okay in this circumstance as we're probing
@@ -580,6 +589,7 @@ BPF_CALL_3(bpf_probe_read_str, void *, dst, u32, size,
*/
ret = strncpy_from_unsafe(dst, unsafe_ptr, size);
if (unlikely(ret < 0))
+out:
memset(dst, 0, size);
return ret;
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 6b123cbf3748..1b89d3e8e54d 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -33,6 +33,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1]
= {
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
+ [LOCKDOWN_BPF_READ] = "use of bpf to read kernel RAM",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
};
--
2.22.0.770.g0f2c4a37fd-goog
