* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Neil Horman @ 2009-08-20 20:19 UTC (permalink / raw)
To: Bill Fink; +Cc: Linux Network Developers, brice, gallatin
In-Reply-To: <20090820035044.9b70fca6.billfink@mindspring.com>
On Thu, Aug 20, 2009 at 03:50:44AM -0400, Bill Fink wrote:
> On Fri, 14 Aug 2009, Neil Horman wrote:
>
> > On Fri, Aug 14, 2009 at 04:44:12PM -0400, Bill Fink wrote:
> > > On Fri, 7 Aug 2009, Neil Horman wrote:
> > >
> > > > On Fri, Aug 07, 2009 at 08:54:42PM -0400, Bill Fink wrote:
> > > > > On Fri, 7 Aug 2009, Neil Horman wrote:
> > > > >
> > > > > > You're timing is impeccable! I just posted a patch for an ftrace module to help
> > > > > > detect just these kind of conditions:
> > > > > > http://marc.info/?l=linux-netdev&m=124967650218846&w=2
> > > > > >
> > > > > > Hope that helps you out
> > > > > > Neil
> > > > >
> > > > > Thanks! It could be helpful. Do you have a pointer to documentation
> > > > > on how to use it? And does it require the latest GIT kernel or could
> > > > > it possibly be used with a 2.6.29.6 kernel?
> > > > >
> > > > > -Bill
> > > >
> > > > It should apply to 2.6.29.6 no problem (might take a little massaging, but not
> > > > much).
> > >
> > > It doesn't look like I can apply your patches to my 2.6.29.6 kernel.
> > >
> > > For starters, there's no include/trace/events directory, so there's
> > > no include/trace/events/skb.h. There is an include/trace/skb.h file,
> > > but there's no TRACE_EVENT defined anywhere in the kernel.
> > >
> > > I don't suppose it's as simple as defining (from include/linux/tracepoint.h
> > > from Linus's GIT tree):
> > >
> > > #define PARAMS(args...) args
> > >
> > > #define TRACE_EVENT(name, proto, args, struct, assign, print) \
> > > DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
> > >
> > > So do you still think it's reasonable to try applying your patches
> > > to my 2.6.29.6 kernel, or should I get a newer kernel like 2.6.30.4
> > > or 2.6.31-rc6?
> > >
> > > -Thanks
> > >
> > > -Bill
> > >
> > >
> > >
> > I thought the trace stuff went it around 2.6.29 but I might be mistaken.
> > Easiest thing to do likely would be find where in the tree those were introduced
> > and just apply them prior to my patches, or move to the latest kernel if you
> > can (at least for the purposes of testing)
>
> I finally got a 2.6.31-rc6 kernel built and had some limited success
> with your ftrace patches. Doing some simple ping tests I was able to
> verify that everything was mostly as expected regarding CPU and NUMA
> memory affinity, with one weird exception. eth2 through eth7, which
> all connect to the 5520 I/O Hub that connects to NUMA node 1, all
> correctly showed their allocations and consumptions on NUMA node 1.
> eth8 through eth13 are all connected to the 5520 I/O Hub that connects
> to NUMA node 0, and eth9 through eth13 all correctly reflected that
> on the ping ftrace tests. But eth8 showed its allocations being
> done on NUMA node 1 instead of the expected NUMA node 0, which just
> doesn't make sense since eth8 and eth9 are part of a dual-port 10-GigE
> Myricom NIC (and I doublechecked that all the IRQ assignments were
> correct).
>
Hmm, memory pressure on node zero causing netdev_alloc_skb to allocate on a
remote node perhaps?
> When I tried an actual nuttcp performance test, even when rate limiting
> to just 1 Mbps, I immediately got a kernel oops. I tried to get a
> crashdump via kexec/kdump, but the kexec kernel, instead of just
> generating a crashdump, fully booted the new kernel, which was
> extremely sluggish until I rebooted it through a BIOS re-init,
> and never produced a crashdump. I tried this several times and
> an immediate kernel oops was always the result (with either a TCP
> or UDP test). A ping test of 1000 9000-byte packets with an interval
> of 0.001 seconds (which is 72 Mbps for 1 second) on the other hand
> worked just fine.
>
The sluggishness is expected, since the kdump kernel operates out of such
limited memory. don't know why you booted to a full system rather than did a
crash recovery. Don't suppose you got a backtrace did you?
Neil
> -Thanks
>
> -Bill
>
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-20 19:42 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <392fb48f0908191505v47f99d1cvef18d40bcf4c08d1@mail.gmail.com>
Am Donnerstag, 20. August 2009 00:05:03 schrieb Mike McCormack:
> 2009/8/20 Rene Mayrhofer <rene.mayrhofer@gibraltar.at>:
> > Pulling the latest sky2.c and sky2.h from net-next-2.6 and applying the
> > patch rids me of the oops - it is unreproducible right now. However, a
> > networking restart (i.e. all interfaces attached to sky2) leaves the
> > devices in a state where they no longer receive any network packets (at
> > least nothing visible in tcpdump). In this state, rmmod sky2 / modprobe
> > sky2 gives:
>
> After you've got it into that state, does "rmmod sky2; modprobe sky2"
> change anything?
Nope, tried that multiple times...
Rene
--
-------------------------------------------------
Gibraltar firewall http://www.gibraltar.at/
^ permalink raw reply
* Re: Strange network timeouts w/ 2.6.30.5
From: David Miller @ 2009-08-20 19:28 UTC (permalink / raw)
To: khc; +Cc: walt, linux-kernel, netdev
In-Reply-To: <m3skfmk39q.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Thu, 20 Aug 2009 15:45:21 +0200
> Something like maybe:
>
> Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
>
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index 014dfb6..b610088 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -1762,9 +1762,12 @@ static int e100_rx_indicate(struct nic *nic, struct rx *rx,
>
> if (ioread8(&nic->csr->scb.status) & rus_no_res)
> nic->ru_running = RU_SUSPENDED;
> +#ifndef CONFIG_X86
> + /* FIXME interferes with swiotlb. */
> pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr,
> sizeof(struct rfd),
> PCI_DMA_BIDIRECTIONAL);
> +#endif
> return -ENODATA;
> }
>
I'm not willing to apply something like this.
swiotlb emulates what hardware does, so if it can go wrong with
swiotlb it can go wrong with hardware to.
Figure out what the exact bug is.
^ permalink raw reply
* Re: e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?
From: Bjørn Mork @ 2009-08-20 19:25 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <200908201714.30638.elendil@planet.nl>
Frans Pop <elendil@planet.nl> writes:
> - if broken hardware is common, should the kernel complain at all,
> or at least maybe show a slightly "friendlier" message?
FWIW, I see the same message on resume on slighly different hardware, so
it's at least more common than just a single configuration:
[80885.498749] e1000e 0000:00:19.0: PCI INT A disabled
[80885.498755] e1000e 0000:00:19.0: PME# enabled
[80885.498763] e1000e 0000:00:19.0: wake-up capability enabled by ACPI
[80887.614545] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[80887.614548] e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed 0xfffffffb
[80887.614554] e1000e 0000:00:19.0: setting latency timer to 64
[80887.614559] e1000e 0000:00:19.0: wake-up capability disabled by ACPI
[80887.614565] e1000e 0000:00:19.0: PME# disabled
[80887.614567] e1000e 0000:00:19.0: wake-up capability disabled by ACPI
[80887.614572] e1000e 0000:00:19.0: PME# disabled
[80887.614626] e1000e 0000:00:19.0: irq 26 for MSI/MSI-X
nemi:/etc/apt# lspci -vvnns 00:19.0
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
Subsystem: Lenovo Device [17aa:20ee]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 26
Region 0: Memory at f0600000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f0625000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 1840 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Address: 00000000fee0300c Data: 41b2
Capabilities: [e0] PCIe advanced features <?>
Kernel driver in use: e1000e
Kernel modules: e1000e
The system is a Lenovo Thinkpad X301. The chipset is ICH9M.
I guess the "non-fatal, continue" comment is a pretty strong indication
that dev_err() is overkill here?
/* AER (Advanced Error Reporting) hooks */
err = pci_enable_pcie_error_reporting(pdev);
if (err) {
dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
"0x%x\n", err);
/* non-fatal, continue */
}
Bjørn
^ permalink raw reply
* Re: Sparc X1 Tulip Issue - NetDev
From: David Miller @ 2009-08-20 19:09 UTC (permalink / raw)
To: maillist; +Cc: netdev
In-Reply-To: <4A8D5F9C.90205@jg555.com>
From: Jim Gifford <maillist@jg555.com>
Date: Thu, 20 Aug 2009 07:37:16 -0700
> Dave Miller asked me to forward this report here.
To both lists, not seperately, but at the same time. So that if
someone replies to you, people on both lists can see what's happening.
:-/
^ permalink raw reply
* RE: [PATCH] [V3] net: add Xilinx emac lite device driver
From: Stephen Neuendorffer @ 2009-08-20 17:45 UTC (permalink / raw)
To: Grant Likely
Cc: John Linn, netdev, linuxppc-dev, davem, jgarzik, John Linn,
Sadanand Mutyala, John Williams, Michal Simek
In-Reply-To: <fa686aa40908201044y17acb4c1lacf09fafc2647fa4@mail.gmail.com>
Sorry... you're right... brain fart on my part.. :)
Steve
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely
> Sent: Thursday, August 20, 2009 10:45 AM
> To: Stephen Neuendorffer
> Cc: John Linn; netdev@vger.kernel.org; linuxppc-dev@ozlabs.org; davem@davemloft.net;
> jgarzik@pobox.com; John Linn; Sadanand Mutyala; John Williams; Michal Simek
> Subject: Re: [PATCH] [V3] net: add Xilinx emac lite device driver
>
> On Thu, Aug 20, 2009 at 10:02 AM, Stephen
> Neuendorffer<stephen.neuendorffer@xilinx.com> wrote:
> >
> > John,
> >
> > I just got a chance to browse this... Do you want to put in the
> > stripped device names?
> >
> > .compatible = "xlnx,xps-ethernetlite-2", etc...
>
> We've covered this territory before. Compatible values need to be
> exact for the IP cores. No wildcards. No abbreviations or stripping.
> Newer cores can claim compatibility with older when appropriate.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [RFC][PATCH][v4] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: Ajit Khaparde @ 2009-08-20 17:44 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, jgarzik, netdev
In-Reply-To: <1250789072.2779.1.camel@achroite>
On 20/08/09 18:24 +0100, Ben Hutchings wrote:
> On Thu, 2009-08-20 at 22:46 +0530, Ajit Khaparde wrote:
> [...]
> > @@ -489,6 +501,7 @@ struct ethtool_ops {
> > int (*get_stats_count)(struct net_device *);/* use get_sset_count */
> > int (*get_rxnfc)(struct net_device *, struct ethtool_rxnfc *, void *);
> > int (*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
> > + int (*flash_device)(struct net_device *, u8 *);
> [...]
>
> The second parameter type should be struct ethtool_flash * not u8 *.
> The compiler warning should make this easy to spot...
Thanks for the catch. My bad. To get over my slow net connection today, I did
a make with the -j option, before I cut the patch. I missed the
warning between the other messages.
Thanks
-Ajit
>
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [V3] net: add Xilinx emac lite device driver
From: Grant Likely @ 2009-08-20 17:44 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Sadanand Mutyala, netdev, John Linn, linuxppc-dev, John Linn,
Michal Simek, jgarzik, davem, John Williams
In-Reply-To: <20090820160356.F1A03340054@mail79-sin.bigfish.com>
On Thu, Aug 20, 2009 at 10:02 AM, Stephen
Neuendorffer<stephen.neuendorffer@xilinx.com> wrote:
>
> John,
>
> I just got a chance to browse this... Do you want to put in the
> stripped device names?
>
> .compatible = "xlnx,xps-ethernetlite-2", etc...
We've covered this territory before. Compatible values need to be
exact for the IP cores. No wildcards. No abbreviations or stripping.
Newer cores can claim compatibility with older when appropriate.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC][PATCH][v4] ethtool: Add a new ethtool option to flash a firmware image from the specified file to a device.
From: Ben Hutchings @ 2009-08-20 17:27 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: davem, jgarzik, netdev
In-Reply-To: <20090820171635.GA20213@serverengines.com>
On Thu, 2009-08-20 at 22:46 +0530, Ajit Khaparde wrote:
> This patch adds a new "-f" option to the ethtool utility
> to flash a firmware image specified by a file, to a network device.
> The filename is passed to the network driver which will flash the image
> on the chip using the request_firmware path.
[...]
> @@ -304,6 +309,9 @@ static int rx_fhash_get = 0;
> static int rx_fhash_set = 0;
> static u32 rx_fhash_val = 0;
> static int rx_fhash_changed = 0;
> +static char flash_file[ETHTOOL_FLASH_MAX_FILENAME];
It would be much simpler to make this a pointer...
> +static int flash = -1;
> +static int flash_region = 0;
> static enum {
> ONLINE=0,
> OFFLINE,
[...]
> @@ -516,6 +525,10 @@ static void parse_cmdline(int argc, char **argp)
> if (phys_id_time < 0)
> show_usage(1);
> break;
> + } else if (mode == MODE_FLASHDEV) {
> + sprintf(flash_file, "%s", argp[i]);
...and to change this to "flash_file = argp[i];"...
> + flash = 1;
> + break;
> }
> /* fallthrough */
> default:
[...]
> @@ -2398,6 +2419,38 @@ static int do_grxclass(int fd, struct ifreq *ifr)
> return 0;
> }
>
> +static int do_flash(int fd, struct ifreq *ifr)
> +{
> + struct ethtool_flash efl;
> + int err;
> +
> + if (flash < 0) {
> + fprintf(stdout, "Missing filename argument\n");
> + show_usage(1);
> + return 98;
> + }
> +
> + if (strlen(flash_file) > ETHTOOL_FLASH_MAX_FILENAME - 1) {
> + fprintf(stdout, "Filename too long\n");
> + return 99;
> + }
[...]
...and then this length check would work properly.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* pull request: wireless-next-2.6 2009-08-20
From: John W. Linville @ 2009-08-20 17:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Dave,
The relentless march of wireless patches for 2.6.32 continues... In
this batch, further implementation of the LP-PHY support for b43 along
with the usual batches of driver updates and the like -- iwlwifi, ath9k,
rt2x00, mwl8k, and others.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 1758c0947605211ef953cc91d6bbdf847a21b822:
Oliver Hartkopp (1):
can: Use WARN_ONCE() instead of BUG_ON() for sanity check in receive path
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Andrey Yurovsky (1):
libertas: don't use dynamic-sized array
Benoit PAPILLAULT (1):
rt2x00: Add support for retry rates
Bob Copeland (2):
wl1251: correct definitions for 0th bit defines
wl1251: halt the embedded CPU before loading firmware
Christian Lamparter (2):
p54: disable PS by default
ar9170: refactor configure_filter
Daniel C Halperin (7):
iwlwifi: remove unused HT configuration entry tx_chan_width
iwlwifi: include HT configuration when adding stations through rs_rate_init
iwlwifi: refactor packet reception code
iwlwifi: configure HT40 channels in iwl_mac_config
iwlwifi: check short GI support per-station rather than globally
iwlwifi: use station HT capabilities and BSS operating mode for Green-field
iwlwifi: fix erroneous use of iwl_rx_packet.len as a length
Daniel Walker (1):
mac80211: New stat counters for multicast and unicast forwarded frames
David Kilroy (2):
cfg80211: fix leaks of wdev->conn->ie
orinoco: remove spare whitespace
Gábor Stefanik (21):
b43: Update dummy transmission to match V4 specs
b43: LP-PHY: Initialize TX power control
b43: LP-PHY: Implement channel switching for rev2+/B2063 radio
b43: LP-PHY: Implement channel switching for rev0/1/B2062 radio
ssb: Fix typo in the rev8 SPROM extraction routine
b43: Add LP-PHY firmware loading support
b43: Make LP-PHY testable
b43: LP-PHY: Don't adjust gain table for rev2+ when setting channel
b43: LP-PHY: Update TX gain override for a spec typo fix
b43: LP-PHY: Fix another TX power control abuse
b43: Handle B43_PHYTYPE_LP in RX path
b43: LP-PHY: Update baseband init for recent spec changes
b43: LP-PHY: Fix a spec error in the B2062 channel switch routine
b43: LP-PHY: Update code for spec fixes, and fix a few typos
b43: LP-PHY: Fix a bug in the B2062 channel tune path
b43: LP-PHY: Update B2062 radio init with recent spec changes
b43: LP-PHY: Remove BROKEN from B43_PHY_LP
b43: LP-PHY: Fix reading old mode in the set TX power control routine
b43: LP-PHY: Fix setting TX power control mode during RC calibration
b43: LP-PHY: Two small spec updates
b43: LP-PHY: Implement spec updates and remove resolved FIXMEs
Ivo van Doorn (8):
rt2x00: Fix RFKILL polling
rt2x00: Fix for rt2800usb for SHARED_KEY_TABLE initializations
rt2x00: Add new RF chip defines
rt2x00: Set SKBDESC_L2_PADDED in RX path
rt2x00: wireless CLI ID and packet ID must not be 0
rt2x00: Fix MCS register intialization
rt2x00: configure_filter() callback is allowed to sleep
rt2x00: bss_info_changed() callback is allowed to sleep
Javier Cardona (1):
mac80211: Decouple fail_avg stats used by mesh from rate control algorithm.
Johannes Berg (8):
iwlwifi: remove unused members of iwl_ht_info
iwlwifi: disable PS by default
cfg80211: fix deadlock
cfg80211: report userspace SME connected event properly
mac80211: allow configure_filter callback to sleep
mac80211: remove deprecated API
cfg80211: fix dangling scan request checking
mac80211: fix register_hw error path
John W. Linville (2):
rc80211_pid_algo.c: remove unused variable declaration
wl1271: remove print_mac usage
Jussi Kivilinna (1):
cfg80211: export cfg80211_wext_siwfreq
Lennert Buytenhek (29):
mwl8k: remove various unused struct members and defines
mwl8k: s/IEEE80211_ADDR_LEN/ETH_ALEN/g
mwl8k: sort firmware command list by opcode, and trim unused commands
mwl8k: various coding style cleanups
mwl8k: remove MWL8K_RADIO_* defines
mwl8k: remove MWL8K_RADIO_*_PREAMBLE defines
mwl8k: remove MWL8K_WMM_* defines
mwl8k: remove MWL8K_*_SLOTTIME defines
mwl8k: fix mwl8k_configure_filter() parameter lifetime issue
mwl8k: ->add_interface() is not called for monitor interfaces
mwl8k: dma header manipulations can't fail
mwl8k: don't touch 'command done' interrupt during firmware load
mwl8k: don't hardcode the number of transmit queues
mwl8k: no need to hold ->tx_lock while setting the hardware interrupt mask
mwl8k: implement idle mode
mwl8k: mwl8k_txq_xmit() rework
mwl8k: mwl8k_queue_work() cleanup
mwl8k: fix firmware command serialisation
mwl8k: get rid of mwl8k_start() workqueue use
mwl8k: get rid of mwl8k_stop() workqueue use
mwl8k: get rid of mwl8k_config() workqueue use
mwl8k: get rid of mwl8k_bss_info_changed() workqueue use
mwl8k: get rid of mwl8k_set_rts_threshold() workqueue use
mwl8k: get rid of mwl8k_conf_tx() workqueue use
mwl8k: get rid of mwl8k_get_stats() workqueue use
mwl8k: get rid of mwl8k_configure_filter() workqueue use
mwl8k: remove mwl8k_queue_work()
mwl8k: update copyright and version number
MAINTAINERS: add information for mwl8k wireless driver
Luis R. Rodriguez (1):
ath: move regulatory info into shared common structure
Reinette Chatre (2):
iwlwifi: prevent read outside array bounds
ipw2x00: fix sparse warnings
Sujith (1):
ath9k: Fix TX poll cancelling
Vasanthakumar Thiagarajan (2):
ath9k: Fix bug in retrieving average beacon rssi
ath9k: Nuke struct ath9k_node_stats
Vivek Natarajan (5):
ath9k: Add open loop power control support for AR9287.
ath9k: Set AR_WA for AR9287 as it improves consistency in throughput.
ath9k: Enable LEDs for AR9287 chipsets.
ath9k: Fix ref power interpolation logic for AR9287 chipsets.
ath9k: Updates for AR9287_12 version of chipset.
Wey-Yi Guy (2):
iwlwifi: traverse linklist to find the valid OTP block
iwlwifi: add thermal throttling support to 5150
Zhu Yi (2):
iwlwifi: cleanup HT40 extension channels setup
cfg80211: allow cfg80211_connect_result with bssid == NULL
gregor kowski (1):
b43: add hardware tkip
MAINTAINERS | 6 +
drivers/net/wireless/adm8211.c | 42 +-
drivers/net/wireless/at76c50x-usb.c | 12 +-
drivers/net/wireless/ath/ar9170/ar9170.h | 16 +-
drivers/net/wireless/ath/ar9170/mac.c | 22 +-
drivers/net/wireless/ath/ar9170/main.c | 112 +--
drivers/net/wireless/ath/ath.h | 18 +
drivers/net/wireless/ath/ath5k/ath5k.h | 3 -
drivers/net/wireless/ath/ath5k/base.c | 78 +-
drivers/net/wireless/ath/ath5k/base.h | 13 +
drivers/net/wireless/ath/ath5k/phy.c | 3 +-
drivers/net/wireless/ath/ath9k/ani.c | 6 +-
drivers/net/wireless/ath/ath9k/ani.h | 20 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 14 +-
drivers/net/wireless/ath/ath9k/calib.c | 44 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 8 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 28 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 14 +-
drivers/net/wireless/ath/ath9k/hw.c | 81 +-
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 52 +-
drivers/net/wireless/ath/ath9k/pci.c | 6 +-
drivers/net/wireless/ath/ath9k/phy.h | 7 +
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/ath/ath9k/reg.h | 9 +-
drivers/net/wireless/ath/regd.h | 20 +-
drivers/net/wireless/b43/Kconfig | 14 +-
drivers/net/wireless/b43/dma.c | 2 +-
drivers/net/wireless/b43/lo.c | 2 +-
drivers/net/wireless/b43/main.c | 205 +++-
drivers/net/wireless/b43/main.h | 2 +-
drivers/net/wireless/b43/phy_g.c | 6 +-
drivers/net/wireless/b43/phy_lp.c | 1042 ++++++++++++++++--
drivers/net/wireless/b43/phy_lp.h | 25 +-
drivers/net/wireless/b43/pio.c | 4 +-
drivers/net/wireless/b43/tables_lpphy.c | 12 +-
drivers/net/wireless/b43/wa.c | 4 +-
drivers/net/wireless/b43/xmit.c | 29 +-
drivers/net/wireless/b43/xmit.h | 3 +-
drivers/net/wireless/b43legacy/main.c | 4 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 14 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 73 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 11 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 25 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 116 +--
drivers/net/wireless/iwlwifi/iwl-commands.h | 3 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 74 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 8 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 20 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 222 +++-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 10 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 207 ++---
drivers/net/wireless/iwlwifi/iwl-tx.c | 5 +
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +
drivers/net/wireless/libertas/assoc.c | 8 +-
drivers/net/wireless/libertas_tf/main.c | 37 +-
drivers/net/wireless/mac80211_hwsim.c | 4 +-
drivers/net/wireless/mwl8k.c | 1530 ++++++++------------------
drivers/net/wireless/orinoco/wext.c | 2 +-
drivers/net/wireless/p54/main.c | 8 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 1 -
drivers/net/wireless/rt2x00/rt2800usb.c | 19 +-
drivers/net/wireless/rt2x00/rt2800usb.h | 10 +-
drivers/net/wireless/rt2x00/rt2x00.h | 6 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 40 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 25 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 2 +
drivers/net/wireless/rt2x00/rt73usb.c | 1 -
drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 +-
drivers/net/wireless/rtl818x/rtl8187_dev.c | 11 +-
drivers/net/wireless/wl12xx/wl1251_boot.c | 3 +
drivers/net/wireless/wl12xx/wl1251_main.c | 4 +-
drivers/net/wireless/wl12xx/wl1251_reg.h | 4 +-
drivers/net/wireless/wl12xx/wl1271_main.c | 9 +-
drivers/net/wireless/zd1211rw/zd_mac.c | 44 +-
drivers/ssb/pci.c | 2 +-
include/net/cfg80211.h | 2 +
include/net/mac80211.h | 36 +-
net/mac80211/debugfs_netdev.c | 6 +
net/mac80211/driver-ops.h | 24 +-
net/mac80211/driver-trace.h | 36 +-
net/mac80211/ieee80211_i.h | 9 +-
net/mac80211/iface.c | 15 +-
net/mac80211/main.c | 32 +-
net/mac80211/mesh.h | 2 +
net/mac80211/mesh_hwmp.c | 21 +
net/mac80211/rc80211_minstrel.c | 16 +-
net/mac80211/rc80211_pid_algo.c | 16 +-
net/mac80211/rx.c | 8 +-
net/mac80211/scan.c | 16 +-
net/mac80211/util.c | 2 -
net/wireless/core.c | 98 ++-
net/wireless/core.h | 2 +
net/wireless/mlme.c | 9 +
net/wireless/sme.c | 29 +-
net/wireless/wext-compat.c | 1 +
99 files changed, 2790 insertions(+), 2170 deletions(-)
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-08-20.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Muli Ben-Yehuda @ 2009-08-20 17:25 UTC (permalink / raw)
To: Avi Kivity
Cc: Gregory Haskins, Ingo Molnar, kvm, alacrityvm-devel, linux-kernel,
netdev, Michael S. Tsirkin, Patrick Mullaney
In-Reply-To: <4A8C627C.70001@redhat.com>
On Wed, Aug 19, 2009 at 11:37:16PM +0300, Avi Kivity wrote:
> On 08/19/2009 09:26 PM, Gregory Haskins wrote:
>>>> This is for things like the setup of queue-pairs, and the
>>>> transport of door-bells, and ib-verbs. I am not on the team
>>>> doing that work, so I am not an expert in this area. What I do
>>>> know is having a flexible and low-latency signal-path was deemed
>>>> a key requirement.
>>>>
>>>>
>>> That's not a full bypass, then. AFAIK kernel bypass has userspace
>>> talking directly to the device.
>>>
>> Like I said, I am not an expert on the details here. I only work
>> on the vbus plumbing. FWIW, the work is derivative from the
>> "Xen-IB" project
>>
>> http://www.openib.org/archives/nov2006sc/xen-ib-presentation.pdf
>>
>> There were issues with getting Xen-IB to map well into the Xen
>> model. Vbus was specifically designed to address some of those
>> short-comings.
>
> Well I'm not an Infiniband expert. But from what I understand VMM
> bypass means avoiding the call to the VMM entirely by exposing
> hardware registers directly to the guest.
The original IB VMM bypass work predates SR-IOV (i.e., does not assume
that the adapter has multiple hardware register windows for multiple
devices). The way it worked was to split all device operations into
`privileged' and `non-privileged'. Privileged operations such as
mapping and pinning memory went through the hypervisor. Non-privileged
operations such reading or writing previously mapped memory went
directly to the adpater. Now-days with SR-IOV devices, VMM bypass
usually means bypassing the hypervisor completely.
Cheers,
Muli
--
Muli Ben-Yehuda | muli@il.ibm.com | +972-4-8281080
Manager, Virtualization and Systems Architecture
Master Inventor, IBM Haifa Research Laboratory
^ permalink raw reply
* Re: [RFC][PATCH][v4] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: Ben Hutchings @ 2009-08-20 17:24 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: davem, jgarzik, netdev
In-Reply-To: <20090820171631.GA19783@serverengines.com>
On Thu, 2009-08-20 at 22:46 +0530, Ajit Khaparde wrote:
[...]
> @@ -489,6 +501,7 @@ struct ethtool_ops {
> int (*get_stats_count)(struct net_device *);/* use get_sset_count */
> int (*get_rxnfc)(struct net_device *, struct ethtool_rxnfc *, void *);
> int (*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
> + int (*flash_device)(struct net_device *, u8 *);
[...]
The second parameter type should be struct ethtool_flash * not u8 *.
The compiler warning should make this easy to spot...
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [RFC][PATCH][v4] ethtool: Add a new ethtool option to flash a firmware image from the specified file to a device.
From: Ajit Khaparde @ 2009-08-20 17:16 UTC (permalink / raw)
To: davem, jgarzik, netdev
This patch adds a new "-f" option to the ethtool utility
to flash a firmware image specified by a file, to a network device.
The filename is passed to the network driver which will flash the image
on the chip using the request_firmware path.
The region "on the chip" to be flashed can be specified by an option.
It is upto the device driver to enumerate the region number passed by ethtool,
to the region to be flashed.
The default behavior is to flash all the regions on the chip.
Usage:
ethtool -f <interface name> <filename of firmware image>
ethtool -f <interface name> <filename of firmware image> [ REGION-NUMBER-TO-FLASH ]
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
ethtool-copy.h | 13 +++++++++++++
ethtool.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3ca4e2c..66429e5 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -272,6 +272,18 @@ struct ethtool_perm_addr {
__u8 data[0];
};
+#define ETHTOOL_FLASH_MAX_FILENAME 128
+enum ethtool_flash_op_type {
+ ETHTOOL_FLASH_ALL_REGIONS = 0,
+};
+
+/* for passing firmware flashing related parameters */
+struct ethtool_flash {
+ __u32 cmd;
+ __u32 region;
+ char data[ETHTOOL_FLASH_MAX_FILENAME];
+};
+
/* boolean flags controlling per-interface behavior characteristics.
* When reading, the flag indicates whether or not a certain behavior
* is enabled/present. When writing, the flag indicates whether
@@ -338,6 +350,7 @@ struct ethtool_rxnfc {
#define ETHTOOL_SRXFH 0x0000002a /* Set RX flow hash configuration */
#define ETHTOOL_GGRO 0x0000002b /* Get GRO enable (ethtool_value) */
#define ETHTOOL_SGRO 0x0000002c /* Set GRO enable (ethtool_value) */
+#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/ethtool.c b/ethtool.c
index 0110682..e905948 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -77,6 +77,7 @@ static char *unparse_rxfhashopts(u64 opts);
static int dump_rxfhash(int fhash, u64 val);
static int do_srxclass(int fd, struct ifreq *ifr);
static int do_grxclass(int fd, struct ifreq *ifr);
+static int do_flash(int fd, struct ifreq *ifr);
static int send_ioctl(int fd, struct ifreq *ifr);
static enum {
@@ -101,6 +102,7 @@ static enum {
MODE_GSTATS,
MODE_GNFC,
MODE_SNFC,
+ MODE_FLASHDEV,
} mode = MODE_GSET;
static struct option {
@@ -192,6 +194,9 @@ static struct option {
"classification options",
" [ rx-flow-hash tcp4|udp4|ah4|sctp4|"
"tcp6|udp6|ah6|sctp6 p|m|v|t|s|d|f|n|r... ]\n" },
+ { "-f", "--flash", MODE_FLASHDEV, "FILENAME " "Flash firmware image "
+ "from the specified file to a region on the device",
+ " [ REGION-NUMBER-TO-FLASH ]\n" },
{ "-h", "--help", MODE_HELP, "Show this help" },
{}
};
@@ -304,6 +309,9 @@ static int rx_fhash_get = 0;
static int rx_fhash_set = 0;
static u32 rx_fhash_val = 0;
static int rx_fhash_changed = 0;
+static char flash_file[ETHTOOL_FLASH_MAX_FILENAME];
+static int flash = -1;
+static int flash_region = 0;
static enum {
ONLINE=0,
OFFLINE,
@@ -496,7 +504,8 @@ static void parse_cmdline(int argc, char **argp)
(mode == MODE_GSTATS) ||
(mode == MODE_GNFC) ||
(mode == MODE_SNFC) ||
- (mode == MODE_PHYS_ID)) {
+ (mode == MODE_PHYS_ID) ||
+ (mode == MODE_FLASHDEV)) {
devname = argp[i];
break;
}
@@ -516,6 +525,10 @@ static void parse_cmdline(int argc, char **argp)
if (phys_id_time < 0)
show_usage(1);
break;
+ } else if (mode == MODE_FLASHDEV) {
+ sprintf(flash_file, "%s", argp[i]);
+ flash = 1;
+ break;
}
/* fallthrough */
default:
@@ -590,6 +603,12 @@ static void parse_cmdline(int argc, char **argp)
show_usage(1);
break;
}
+ if (mode == MODE_FLASHDEV) {
+ flash_region = strtol(argp[i], NULL, 0);
+ if (flash_region < 0)
+ show_usage(1);
+ break;
+ }
if (mode == MODE_SNFC) {
if (!strcmp(argp[i], "rx-flow-hash")) {
i += 1;
@@ -1504,6 +1523,8 @@ static int doit(void)
return do_grxclass(fd, &ifr);
} else if (mode == MODE_SNFC) {
return do_srxclass(fd, &ifr);
+ } else if (mode == MODE_FLASHDEV) {
+ return do_flash(fd, &ifr);
}
return 69;
@@ -2398,6 +2419,38 @@ static int do_grxclass(int fd, struct ifreq *ifr)
return 0;
}
+static int do_flash(int fd, struct ifreq *ifr)
+{
+ struct ethtool_flash efl;
+ int err;
+
+ if (flash < 0) {
+ fprintf(stdout, "Missing filename argument\n");
+ show_usage(1);
+ return 98;
+ }
+
+ if (strlen(flash_file) > ETHTOOL_FLASH_MAX_FILENAME - 1) {
+ fprintf(stdout, "Filename too long\n");
+ return 99;
+ }
+
+ efl.cmd = ETHTOOL_FLASHDEV;
+ strcpy(efl.data, flash_file);
+
+ if (flash_region < 0)
+ efl.region = ETHTOOL_FLASH_ALL_REGIONS;
+ else
+ efl.region = flash_region;
+
+ ifr->ifr_data = (caddr_t)&efl;
+ err = send_ioctl(fd, ifr);
+ if (err < 0)
+ perror("Flashing failed");
+
+ return err;
+}
+
static int send_ioctl(int fd, struct ifreq *ifr)
{
return ioctl(fd, SIOCETHTOOL, ifr);
--
1.6.0.4
^ permalink raw reply related
* [RFC][PATCH][v4] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: Ajit Khaparde @ 2009-08-20 17:16 UTC (permalink / raw)
To: davem, jgarzik, netdev
This patch adds support to flash a firmware image to a device using ethtool.
The driver gets the filename of the firmware image and flashes the image
using the request firmware path.
The region "on the chip" to be flashed can be specified by an option.
It is upto the device driver to enumerate the region number passed by ethtool,
to the region to be flashed.
The default behavior is to flash all the regions on the chip.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
include/linux/ethtool.h | 14 ++++++++++++++
net/core/ethtool.c | 17 +++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 90c4a36..7614267 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -362,6 +362,18 @@ struct ethtool_rxnfc {
__u32 rule_locs[0];
};
+#define ETHTOOL_FLASH_MAX_FILENAME 128
+enum ethtool_flash_op_type {
+ ETHTOOL_FLASH_ALL_REGIONS = 0,
+};
+
+/* for passing firmware flashing related parameters */
+struct ethtool_flash {
+ __u32 cmd;
+ __u32 region;
+ char data[ETHTOOL_FLASH_MAX_FILENAME];
+};
+
#ifdef __KERNEL__
struct net_device;
@@ -489,6 +501,7 @@ struct ethtool_ops {
int (*get_stats_count)(struct net_device *);/* use get_sset_count */
int (*get_rxnfc)(struct net_device *, struct ethtool_rxnfc *, void *);
int (*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
+ int (*flash_device)(struct net_device *, u8 *);
};
#endif /* __KERNEL__ */
@@ -545,6 +558,7 @@ struct ethtool_ops {
#define ETHTOOL_GRXCLSRLALL 0x00000030 /* Get all RX classification rule */
#define ETHTOOL_SRXCLSRLDEL 0x00000031 /* Delete RX classification rule */
#define ETHTOOL_SRXCLSRLINS 0x00000032 /* Insert RX classification rule */
+#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 44e5711..fbcd9f7 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -898,6 +898,20 @@ static int ethtool_set_value(struct net_device *dev, char __user *useraddr,
return actor(dev, edata.data);
}
+static int ethtool_flash_device(struct net_device *dev, char __user *useraddr)
+{
+ int err;
+ struct ethtool_flash efl;
+
+ if (copy_from_user(&efl, useraddr, sizeof(efl)))
+ return -EFAULT;
+
+ if (!dev->ethtool_ops->flash_device)
+ return -EOPNOTSUPP;
+
+ return dev->ethtool_ops->flash_device(dev, &efl);
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1111,6 +1125,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SGRO:
rc = ethtool_set_gro(dev, useraddr);
break;
+ case ETHTOOL_FLASHDEV:
+ rc = ethtool_flash_device(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] [V3] net: add Xilinx emac lite device driver
From: Stephen Hemminger @ 2009-08-20 16:49 UTC (permalink / raw)
To: John Linn
Cc: netdev, linuxppc-dev, davem, jgarzik, John Linn, Grant Likely,
Josh Boyer, John Williams, Michal Simek, Sadanand M
In-Reply-To: <20090820094956.02DFC45004F@mail96-dub.bigfish.com>
On Thu, 20 Aug 2009 03:49:51 -0600
John Linn <john.linn@xilinx.com> wrote:
> +/**
> + * xemaclite_ioctl - Perform IO Control operations on the network device
> + * @dev: Pointer to the network device
> + * @rq: Pointer to the interface request structure
> + * @cmd: IOCTL command
> + *
> + * The only IOCTL operation supported by this function is setting the MAC
> + * address. An error is reported if any other operations are requested.
> + *
> + * Return: 0 to indicate success, or a negative error for failure.
> + */
> +static int xemaclite_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> +{
> + struct net_local *lp = (struct net_local *) netdev_priv(dev);
> + struct hw_addr_data *hw_addr = (struct hw_addr_data *) &rq->ifr_hwaddr;
> +
> + switch (cmd) {
> + case SIOCETHTOOL:
> + return -EIO;
> +
> + case SIOCSIFHWADDR:
> + dev_err(&lp->ndev->dev, "SIOCSIFHWADDR\n");
> +
> + /* Copy MAC address in from user space */
> + copy_from_user((void __force *) dev->dev_addr,
> + (void __user __force *) hw_addr,
> + IFHWADDRLEN);
> + xemaclite_set_mac_address(lp, dev->dev_addr);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
Do you really need this? I doubt the SIOCSIFHWADDR even reaches driver!
The normal call path for setting hardware address is:
dev_ifsioc
dev_set_mac_address
ops->ndo_set_mac_address -->
The driver should be:
1. defining new code to do ndo_set_mac_address
2. remove existing xmaclite_ioctl - all ioctl's handled by upper layers
FYI - the only ioctl's that make it to network device ndo_ioctl
are listed in dev_ifsioc
SIOCDEVPRIVATE ... SIOCDEVPRIVATE + 15
SIOCBOND*
SIOCMII*
SIOCBR*
SIOCHWTSTAMP
SIOCWANDEV
^ permalink raw reply
* RE: [PATCH] [V3] net: add Xilinx emac lite device driver
From: Stephen Neuendorffer @ 2009-08-20 16:02 UTC (permalink / raw)
To: John Linn, netdev, linuxppc-dev, davem, jgarzik
Cc: Sadanand Mutyala, Michal Simek, John Linn, John Williams
In-Reply-To: <20090820094956.02DFC45004F@mail96-dub.bigfish.com>
John,
I just got a chance to browse this... Do you want to put in the
stripped device names?
.compatible = "xlnx,xps-ethernetlite-2", etc...
Steve
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [GIT PULL 0/5] IEEE 802.15.4 updates
From: Dmitry Eremin-Solenikov @ 2009-08-20 16:13 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-zigbee-devel, Sergey Lapin
The following changes since commit 886f9fe68310168358f55028a03553ae154dfeb6:
David S. Miller (1):
ppp_generic: Help GCC see that 'flen' is always initialized.
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-next
Dmitry Eremin-Solenikov (5):
ieee802154: document the skb->cb usage clearly.
ieee802154: add a sysfs representation of WPAN master devices
fakehard: add binding to wpan-phy device
ieee802154: add support for channel pages from IEEE 802.15.4-2006
Drop ARPHRD_IEEE802154_PHY
Documentation/networking/ieee802154.txt | 9 ++-
drivers/ieee802154/fakehard.c | 62 ++++++++++--
include/linux/if_arp.h | 1 -
include/linux/nl802154.h | 2 +
include/net/ieee802154_netdev.h | 6 +-
include/net/nl802154.h | 2 +-
include/net/wpan-phy.h | 63 ++++++++++++
net/core/dev.c | 4 +-
net/ieee802154/Makefile | 2 +-
net/ieee802154/af_ieee802154.c | 4 +-
net/ieee802154/netlink.c | 28 +++++-
net/ieee802154/nl_policy.c | 1 +
net/ieee802154/raw.c | 3 +-
net/ieee802154/wpan-class.c | 159 +++++++++++++++++++++++++++++++
14 files changed, 318 insertions(+), 28 deletions(-)
create mode 100644 include/net/wpan-phy.h
create mode 100644 net/ieee802154/wpan-class.c
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 5/5] Drop ARPHRD_IEEE802154_PHY
From: Dmitry Eremin-Solenikov @ 2009-08-20 16:13 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1250784787-30590-5-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
There are not maste devices in mac802154 anymore, so drop
ARPHRD_IEEE802154_PHY definition.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/linux/if_arp.h | 1 -
net/core/dev.c | 4 ++--
net/ieee802154/af_ieee802154.c | 4 +---
net/ieee802154/raw.c | 3 +--
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/include/linux/if_arp.h b/include/linux/if_arp.h
index b554300..282eb37 100644
--- a/include/linux/if_arp.h
+++ b/include/linux/if_arp.h
@@ -87,7 +87,6 @@
#define ARPHRD_IEEE80211_PRISM 802 /* IEEE 802.11 + Prism2 header */
#define ARPHRD_IEEE80211_RADIOTAP 803 /* IEEE 802.11 + radiotap header */
#define ARPHRD_IEEE802154 804
-#define ARPHRD_IEEE802154_PHY 805
#define ARPHRD_PHONET 820 /* PhoNet media type */
#define ARPHRD_PHONET_PIPE 821 /* PhoNet pipe header */
diff --git a/net/core/dev.c b/net/core/dev.c
index 09fb03f..4b83789 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -269,7 +269,7 @@ static const unsigned short netdev_lock_type[] =
ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
ARPHRD_FCFABRIC, ARPHRD_IEEE802_TR, ARPHRD_IEEE80211,
ARPHRD_IEEE80211_PRISM, ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET,
- ARPHRD_PHONET_PIPE, ARPHRD_IEEE802154, ARPHRD_IEEE802154_PHY,
+ ARPHRD_PHONET_PIPE, ARPHRD_IEEE802154,
ARPHRD_VOID, ARPHRD_NONE};
static const char *const netdev_lock_name[] =
@@ -287,7 +287,7 @@ static const char *const netdev_lock_name[] =
"_xmit_IRDA", "_xmit_FCPP", "_xmit_FCAL", "_xmit_FCPL",
"_xmit_FCFABRIC", "_xmit_IEEE802_TR", "_xmit_IEEE80211",
"_xmit_IEEE80211_PRISM", "_xmit_IEEE80211_RADIOTAP", "_xmit_PHONET",
- "_xmit_PHONET_PIPE", "_xmit_IEEE802154", "_xmit_IEEE802154_PHY",
+ "_xmit_PHONET_PIPE", "_xmit_IEEE802154",
"_xmit_VOID", "_xmit_NONE"};
static struct lock_class_key netdev_xmit_lock_key[ARRAY_SIZE(netdev_lock_type)];
diff --git a/net/ieee802154/af_ieee802154.c b/net/ieee802154/af_ieee802154.c
index d504c34..cd949d5 100644
--- a/net/ieee802154/af_ieee802154.c
+++ b/net/ieee802154/af_ieee802154.c
@@ -147,9 +147,7 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
dev_load(sock_net(sk), ifr.ifr_name);
dev = dev_get_by_name(sock_net(sk), ifr.ifr_name);
- if ((dev->type == ARPHRD_IEEE802154 ||
- dev->type == ARPHRD_IEEE802154_PHY) &&
- dev->netdev_ops->ndo_do_ioctl)
+ if (dev->type == ARPHRD_IEEE802154 && dev->netdev_ops->ndo_do_ioctl)
ret = dev->netdev_ops->ndo_do_ioctl(dev, &ifr, cmd);
if (!ret && copy_to_user(arg, &ifr, sizeof(struct ifreq)))
diff --git a/net/ieee802154/raw.c b/net/ieee802154/raw.c
index 60dee69..4681501 100644
--- a/net/ieee802154/raw.c
+++ b/net/ieee802154/raw.c
@@ -74,8 +74,7 @@ static int raw_bind(struct sock *sk, struct sockaddr *uaddr, int len)
goto out;
}
- if (dev->type != ARPHRD_IEEE802154_PHY &&
- dev->type != ARPHRD_IEEE802154) {
+ if (dev->type != ARPHRD_IEEE802154) {
err = -ENODEV;
goto out_put;
}
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 4/5] ieee802154: add support for channel pages from IEEE 802.15.4-2006
From: Dmitry Eremin-Solenikov @ 2009-08-20 16:13 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1250784787-30590-4-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
IEEE 802.15.4-2006 adds new concept: channel pages, which can contain several
channels. Add support for channel pages in the API and in the fakehard driver.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/ieee802154/fakehard.c | 10 ++++++----
include/linux/nl802154.h | 2 ++
include/net/ieee802154_netdev.h | 6 +++---
include/net/nl802154.h | 2 +-
net/ieee802154/netlink.c | 28 +++++++++++++++++++++++++---
net/ieee802154/nl_policy.c | 1 +
6 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/ieee802154/fakehard.c b/drivers/ieee802154/fakehard.c
index 22a93bc..c1c9697 100644
--- a/drivers/ieee802154/fakehard.c
+++ b/drivers/ieee802154/fakehard.c
@@ -119,12 +119,13 @@ static u8 fake_get_bsn(struct net_device *dev)
* 802.15.4-2006 document.
*/
static int fake_assoc_req(struct net_device *dev,
- struct ieee802154_addr *addr, u8 channel, u8 cap)
+ struct ieee802154_addr *addr, u8 channel, u8 page, u8 cap)
{
struct wpan_phy *phy = net_to_phy(dev);
mutex_lock(&phy->pib_lock);
phy->current_channel = channel;
+ phy->current_page = page;
mutex_unlock(&phy->pib_lock);
/* We simply emulate it here */
@@ -191,7 +192,7 @@ static int fake_disassoc_req(struct net_device *dev,
* document, with 7.3.8 describing coordinator realignment.
*/
static int fake_start_req(struct net_device *dev, struct ieee802154_addr *addr,
- u8 channel,
+ u8 channel, u8 page,
u8 bcn_ord, u8 sf_ord, u8 pan_coord, u8 blx,
u8 coord_realign)
{
@@ -199,6 +200,7 @@ static int fake_start_req(struct net_device *dev, struct ieee802154_addr *addr,
mutex_lock(&phy->pib_lock);
phy->current_channel = channel;
+ phy->current_page = page;
mutex_unlock(&phy->pib_lock);
/* We don't emulate beacons here at all, so START should fail */
@@ -222,11 +224,11 @@ static int fake_start_req(struct net_device *dev, struct ieee802154_addr *addr,
* Note: This is in section 7.5.2.1 of the IEEE 802.15.4-2006 document.
*/
static int fake_scan_req(struct net_device *dev, u8 type, u32 channels,
- u8 duration)
+ u8 page, u8 duration)
{
u8 edl[27] = {};
return ieee802154_nl_scan_confirm(dev, IEEE802154_SUCCESS, type,
- channels,
+ channels, page,
type == IEEE802154_MAC_SCAN_ED ? edl : NULL);
}
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index 9a1af5f..b7d9435 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -64,6 +64,8 @@ enum {
IEEE802154_ATTR_COORD_REALIGN,
IEEE802154_ATTR_SEC,
+ IEEE802154_ATTR_PAGE,
+
__IEEE802154_ATTR_MAX,
};
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index e2506af..5dc6a61 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -80,7 +80,7 @@ static inline int mac_cb_type(struct sk_buff *skb)
struct ieee802154_mlme_ops {
int (*assoc_req)(struct net_device *dev,
struct ieee802154_addr *addr,
- u8 channel, u8 cap);
+ u8 channel, u8 page, u8 cap);
int (*assoc_resp)(struct net_device *dev,
struct ieee802154_addr *addr,
u16 short_addr, u8 status);
@@ -89,10 +89,10 @@ struct ieee802154_mlme_ops {
u8 reason);
int (*start_req)(struct net_device *dev,
struct ieee802154_addr *addr,
- u8 channel, u8 bcn_ord, u8 sf_ord,
+ u8 channel, u8 page, u8 bcn_ord, u8 sf_ord,
u8 pan_coord, u8 blx, u8 coord_realign);
int (*scan_req)(struct net_device *dev,
- u8 type, u32 channels, u8 duration);
+ u8 type, u32 channels, u8 page, u8 duration);
/*
* FIXME: these should become the part of PIB/MIB interface.
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index e554ecd..99d2ba1 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -95,7 +95,7 @@ int ieee802154_nl_disassoc_confirm(struct net_device *dev,
* Note: This API does not permit the return of an active scan result.
*/
int ieee802154_nl_scan_confirm(struct net_device *dev,
- u8 status, u8 scan_type, u32 unscanned,
+ u8 status, u8 scan_type, u32 unscanned, u8 page,
u8 *edl/*, struct list_head *pan_desc_list */);
/**
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index cd0567f..2106ecb 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -232,7 +232,7 @@ nla_put_failure:
EXPORT_SYMBOL(ieee802154_nl_beacon_indic);
int ieee802154_nl_scan_confirm(struct net_device *dev,
- u8 status, u8 scan_type, u32 unscanned,
+ u8 status, u8 scan_type, u32 unscanned, u8 page,
u8 *edl/* , struct list_head *pan_desc_list */)
{
struct sk_buff *msg;
@@ -251,6 +251,7 @@ int ieee802154_nl_scan_confirm(struct net_device *dev,
NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, status);
NLA_PUT_U8(msg, IEEE802154_ATTR_SCAN_TYPE, scan_type);
NLA_PUT_U32(msg, IEEE802154_ATTR_CHANNELS, unscanned);
+ NLA_PUT_U8(msg, IEEE802154_ATTR_PAGE, page);
if (edl)
NLA_PUT(msg, IEEE802154_ATTR_ED_LIST, 27, edl);
@@ -349,6 +350,7 @@ static int ieee802154_associate_req(struct sk_buff *skb,
{
struct net_device *dev;
struct ieee802154_addr addr;
+ u8 page;
int ret = -EINVAL;
if (!info->attrs[IEEE802154_ATTR_CHANNEL] ||
@@ -374,8 +376,14 @@ static int ieee802154_associate_req(struct sk_buff *skb,
}
addr.pan_id = nla_get_u16(info->attrs[IEEE802154_ATTR_COORD_PAN_ID]);
+ if (info->attrs[IEEE802154_ATTR_PAGE])
+ page = nla_get_u8(info->attrs[IEEE802154_ATTR_PAGE]);
+ else
+ page = 0;
+
ret = ieee802154_mlme_ops(dev)->assoc_req(dev, &addr,
nla_get_u8(info->attrs[IEEE802154_ATTR_CHANNEL]),
+ page,
nla_get_u8(info->attrs[IEEE802154_ATTR_CAPABILITY]));
dev_put(dev);
@@ -458,6 +466,7 @@ static int ieee802154_start_req(struct sk_buff *skb, struct genl_info *info)
struct ieee802154_addr addr;
u8 channel, bcn_ord, sf_ord;
+ u8 page;
int pan_coord, blx, coord_realign;
int ret;
@@ -488,13 +497,19 @@ static int ieee802154_start_req(struct sk_buff *skb, struct genl_info *info)
blx = nla_get_u8(info->attrs[IEEE802154_ATTR_BAT_EXT]);
coord_realign = nla_get_u8(info->attrs[IEEE802154_ATTR_COORD_REALIGN]);
+ if (info->attrs[IEEE802154_ATTR_PAGE])
+ page = nla_get_u8(info->attrs[IEEE802154_ATTR_PAGE]);
+ else
+ page = 0;
+
+
if (addr.short_addr == IEEE802154_ADDR_BROADCAST) {
ieee802154_nl_start_confirm(dev, IEEE802154_NO_SHORT_ADDRESS);
dev_put(dev);
return -EINVAL;
}
- ret = ieee802154_mlme_ops(dev)->start_req(dev, &addr, channel,
+ ret = ieee802154_mlme_ops(dev)->start_req(dev, &addr, channel, page,
bcn_ord, sf_ord, pan_coord, blx, coord_realign);
dev_put(dev);
@@ -508,6 +523,7 @@ static int ieee802154_scan_req(struct sk_buff *skb, struct genl_info *info)
u8 type;
u32 channels;
u8 duration;
+ u8 page;
if (!info->attrs[IEEE802154_ATTR_SCAN_TYPE] ||
!info->attrs[IEEE802154_ATTR_CHANNELS] ||
@@ -522,7 +538,13 @@ static int ieee802154_scan_req(struct sk_buff *skb, struct genl_info *info)
channels = nla_get_u32(info->attrs[IEEE802154_ATTR_CHANNELS]);
duration = nla_get_u8(info->attrs[IEEE802154_ATTR_DURATION]);
- ret = ieee802154_mlme_ops(dev)->scan_req(dev, type, channels,
+ if (info->attrs[IEEE802154_ATTR_PAGE])
+ page = nla_get_u8(info->attrs[IEEE802154_ATTR_PAGE]);
+ else
+ page = 0;
+
+
+ ret = ieee802154_mlme_ops(dev)->scan_req(dev, type, channels, page,
duration);
dev_put(dev);
diff --git a/net/ieee802154/nl_policy.c b/net/ieee802154/nl_policy.c
index 83cb4cc..2363ebe 100644
--- a/net/ieee802154/nl_policy.c
+++ b/net/ieee802154/nl_policy.c
@@ -33,6 +33,7 @@ const struct nla_policy ieee802154_policy[IEEE802154_ATTR_MAX + 1] = {
[IEEE802154_ATTR_HW_ADDR] = { .type = NLA_HW_ADDR, },
[IEEE802154_ATTR_PAN_ID] = { .type = NLA_U16, },
[IEEE802154_ATTR_CHANNEL] = { .type = NLA_U8, },
+ [IEEE802154_ATTR_PAGE] = { .type = NLA_U8, },
[IEEE802154_ATTR_COORD_SHORT_ADDR] = { .type = NLA_U16, },
[IEEE802154_ATTR_COORD_HW_ADDR] = { .type = NLA_HW_ADDR, },
[IEEE802154_ATTR_COORD_PAN_ID] = { .type = NLA_U16, },
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 3/5] fakehard: add binding to wpan-phy device
From: Dmitry Eremin-Solenikov @ 2009-08-20 16:13 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1250784787-30590-3-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Make fakehard create and maintain wpan-phy node, thus representing
it's phy in the sysfs.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/ieee802154/fakehard.c | 52 ++++++++++++++++++++++++++++++++++++----
1 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/ieee802154/fakehard.c b/drivers/ieee802154/fakehard.c
index 262536f..22a93bc 100644
--- a/drivers/ieee802154/fakehard.c
+++ b/drivers/ieee802154/fakehard.c
@@ -30,6 +30,12 @@
#include <net/ieee802154_netdev.h>
#include <net/ieee802154.h>
#include <net/nl802154.h>
+#include <net/wpan-phy.h>
+
+struct wpan_phy *net_to_phy(struct net_device *dev)
+{
+ return container_of(dev->dev.parent, struct wpan_phy, dev);
+}
/**
* fake_get_pan_id - Retrieve the PAN ID of the device.
@@ -115,6 +121,12 @@ static u8 fake_get_bsn(struct net_device *dev)
static int fake_assoc_req(struct net_device *dev,
struct ieee802154_addr *addr, u8 channel, u8 cap)
{
+ struct wpan_phy *phy = net_to_phy(dev);
+
+ mutex_lock(&phy->pib_lock);
+ phy->current_channel = channel;
+ mutex_unlock(&phy->pib_lock);
+
/* We simply emulate it here */
return ieee802154_nl_assoc_confirm(dev, fake_get_short_addr(dev),
IEEE802154_SUCCESS);
@@ -183,6 +195,12 @@ static int fake_start_req(struct net_device *dev, struct ieee802154_addr *addr,
u8 bcn_ord, u8 sf_ord, u8 pan_coord, u8 blx,
u8 coord_realign)
{
+ struct wpan_phy *phy = net_to_phy(dev);
+
+ mutex_lock(&phy->pib_lock);
+ phy->current_channel = channel;
+ mutex_unlock(&phy->pib_lock);
+
/* We don't emulate beacons here at all, so START should fail */
ieee802154_nl_start_confirm(dev, IEEE802154_INVALID_PARAMETER);
return 0;
@@ -290,6 +308,14 @@ static const struct net_device_ops fake_ops = {
.ndo_set_mac_address = ieee802154_fake_mac_addr,
};
+static void ieee802154_fake_destruct(struct net_device *dev)
+{
+ struct wpan_phy *phy = net_to_phy(dev);
+
+ wpan_phy_unregister(phy);
+ free_netdev(dev);
+ wpan_phy_free(phy);
+}
static void ieee802154_fake_setup(struct net_device *dev)
{
@@ -302,22 +328,34 @@ static void ieee802154_fake_setup(struct net_device *dev)
dev->type = ARPHRD_IEEE802154;
dev->flags = IFF_NOARP | IFF_BROADCAST;
dev->watchdog_timeo = 0;
+ dev->destructor = ieee802154_fake_destruct;
}
static int __devinit ieee802154fake_probe(struct platform_device *pdev)
{
- struct net_device *dev =
- alloc_netdev(0, "hardwpan%d", ieee802154_fake_setup);
+ struct net_device *dev;
+ struct wpan_phy *phy = wpan_phy_alloc(0);
int err;
- if (!dev)
+ if (!phy)
+ return -ENOMEM;
+
+ dev = alloc_netdev(0, "hardwpan%d", ieee802154_fake_setup);
+ if (!dev) {
+ wpan_phy_free(phy);
return -ENOMEM;
+ }
+
+ phy->dev.platform_data = dev;
memcpy(dev->dev_addr, "\xba\xbe\xca\xfe\xde\xad\xbe\xef",
dev->addr_len);
memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
+ phy->channels_supported = (1 << 27) - 1;
+ phy->transmit_power = 0xbf;
+
dev->netdev_ops = &fake_ops;
dev->ml_priv = &fake_mlme;
@@ -331,15 +369,18 @@ static int __devinit ieee802154fake_probe(struct platform_device *pdev)
goto out;
}
- SET_NETDEV_DEV(dev, &pdev->dev);
+ SET_NETDEV_DEV(dev, &phy->dev);
platform_set_drvdata(pdev, dev);
+ err = wpan_phy_register(&pdev->dev, phy);
+ if (err)
+ goto out;
+
err = register_netdev(dev);
if (err < 0)
goto out;
-
dev_info(&pdev->dev, "Added ieee802154 HardMAC hardware\n");
return 0;
@@ -352,7 +393,6 @@ static int __devexit ieee802154fake_remove(struct platform_device *pdev)
{
struct net_device *dev = platform_get_drvdata(pdev);
unregister_netdev(dev);
- free_netdev(dev);
return 0;
}
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 2/5] ieee802154: add a sysfs representation of WPAN master devices
From: Dmitry Eremin-Solenikov @ 2009-08-20 16:13 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1250784787-30590-2-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Add a sysfs/in-kernel representation of LR-WPAN master devices.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/wpan-phy.h | 63 +++++++++++++++++
net/ieee802154/Makefile | 2 +-
net/ieee802154/wpan-class.c | 159 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 223 insertions(+), 1 deletions(-)
create mode 100644 include/net/wpan-phy.h
create mode 100644 net/ieee802154/wpan-class.c
diff --git a/include/net/wpan-phy.h b/include/net/wpan-phy.h
new file mode 100644
index 0000000..547b1e2
--- /dev/null
+++ b/include/net/wpan-phy.h
@@ -0,0 +1,63 @@
+/*
+ * Copyright (C) 2007, 2008, 2009 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Written by:
+ * Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ */
+
+#ifndef WPAN_PHY_H
+#define WPAN_PHY_H
+
+#include <linux/netdevice.h>
+#include <linux/mutex.h>
+
+struct wpan_phy {
+ struct mutex pib_lock;
+
+ /*
+ * This is a PIB acording to 802.15.4-2006.
+ * We do not provide timing-related variables, as they
+ * aren't used outside of driver
+ */
+ u8 current_channel;
+ u8 current_page;
+ u32 channels_supported;
+ u8 transmit_power;
+ u8 cca_mode;
+
+ struct device dev;
+ int idx;
+
+ char priv[0] __attribute__((__aligned__(NETDEV_ALIGN)));
+};
+
+struct wpan_phy *wpan_phy_alloc(size_t priv_size);
+int wpan_phy_register(struct device *parent, struct wpan_phy *phy);
+void wpan_phy_unregister(struct wpan_phy *phy);
+void wpan_phy_free(struct wpan_phy *phy);
+
+static inline void *wpan_phy_priv(struct wpan_phy *phy)
+{
+ BUG_ON(!phy);
+ return &phy->priv;
+}
+
+struct wpan_phy *wpan_phy_find(const char *str);
+static inline const char *wpan_phy_name(struct wpan_phy *phy)
+{
+ return dev_name(&phy->dev);
+}
+#endif
diff --git a/net/ieee802154/Makefile b/net/ieee802154/Makefile
index f99338a..4068a9f 100644
--- a/net/ieee802154/Makefile
+++ b/net/ieee802154/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_IEEE802154) += nl802154.o af_802154.o
+obj-$(CONFIG_IEEE802154) += nl802154.o af_802154.o wpan-class.o
nl802154-y := netlink.o nl_policy.o
af_802154-y := af_ieee802154.o raw.o dgram.o
diff --git a/net/ieee802154/wpan-class.c b/net/ieee802154/wpan-class.c
new file mode 100644
index 0000000..f306604
--- /dev/null
+++ b/net/ieee802154/wpan-class.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright (C) 2007, 2008, 2009 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/device.h>
+
+#include <net/wpan-phy.h>
+
+#define MASTER_SHOW_COMPLEX(name, format_string, args...) \
+static ssize_t name ## _show(struct device *dev, \
+ struct device_attribute *attr, char *buf) \
+{ \
+ struct wpan_phy *phy = container_of(dev, struct wpan_phy, dev); \
+ int ret; \
+ \
+ mutex_lock(&phy->pib_lock); \
+ ret = sprintf(buf, format_string "\n", args); \
+ mutex_unlock(&phy->pib_lock); \
+ return ret; \
+}
+
+#define MASTER_SHOW(field, format_string) \
+ MASTER_SHOW_COMPLEX(field, format_string, phy->field)
+
+MASTER_SHOW(current_channel, "%d");
+MASTER_SHOW(current_page, "%d");
+MASTER_SHOW(channels_supported, "%#x");
+MASTER_SHOW_COMPLEX(transmit_power, "%d +- %d dB",
+ ((signed char) (phy->transmit_power << 2)) >> 2,
+ (phy->transmit_power >> 6) ? (phy->transmit_power >> 6) * 3 : 1 );
+MASTER_SHOW(cca_mode, "%d");
+
+static struct device_attribute pmib_attrs[] = {
+ __ATTR_RO(current_channel),
+ __ATTR_RO(current_page),
+ __ATTR_RO(channels_supported),
+ __ATTR_RO(transmit_power),
+ __ATTR_RO(cca_mode),
+ {},
+};
+
+static void wpan_phy_release(struct device *d)
+{
+ struct wpan_phy *phy = container_of(d, struct wpan_phy, dev);
+ kfree(phy);
+}
+
+static struct class wpan_phy_class = {
+ .name = "ieee802154",
+ .dev_release = wpan_phy_release,
+ .dev_attrs = pmib_attrs,
+};
+
+static DEFINE_MUTEX(wpan_phy_mutex);
+static int wpan_phy_idx;
+
+static int wpan_phy_match(struct device *dev, void *data)
+{
+ return !strcmp(dev_name(dev), (const char *)data);
+}
+
+struct wpan_phy *wpan_phy_find(const char *str)
+{
+ struct device *dev;
+
+ if (WARN_ON(!str))
+ return NULL;
+
+ dev = class_find_device(&wpan_phy_class, NULL,
+ (void *)str, wpan_phy_match);
+ if (!dev)
+ return NULL;
+
+ return container_of(dev, struct wpan_phy, dev);
+}
+EXPORT_SYMBOL(wpan_phy_find);
+
+static int wpan_phy_idx_valid(int idx)
+{
+ return idx >= 0;
+}
+
+struct wpan_phy *wpan_phy_alloc(size_t priv_size)
+{
+ struct wpan_phy *phy = kzalloc(sizeof(*phy) + priv_size,
+ GFP_KERNEL);
+
+ mutex_lock(&wpan_phy_mutex);
+ phy->idx = wpan_phy_idx++;
+ if (unlikely(!wpan_phy_idx_valid(phy->idx))) {
+ wpan_phy_idx--;
+ mutex_unlock(&wpan_phy_mutex);
+ kfree(phy);
+ return NULL;
+ }
+ mutex_unlock(&wpan_phy_mutex);
+
+ mutex_init(&phy->pib_lock);
+
+ device_initialize(&phy->dev);
+ dev_set_name(&phy->dev, "wpan-phy%d", phy->idx);
+
+ phy->dev.class = &wpan_phy_class;
+
+ return phy;
+}
+EXPORT_SYMBOL(wpan_phy_alloc);
+
+int wpan_phy_register(struct device *parent, struct wpan_phy *phy)
+{
+ phy->dev.parent = parent;
+
+ return device_add(&phy->dev);
+}
+EXPORT_SYMBOL(wpan_phy_register);
+
+void wpan_phy_unregister(struct wpan_phy *phy)
+{
+ device_del(&phy->dev);
+}
+EXPORT_SYMBOL(wpan_phy_unregister);
+
+void wpan_phy_free(struct wpan_phy *phy)
+{
+ put_device(&phy->dev);
+}
+EXPORT_SYMBOL(wpan_phy_free);
+
+static int __init wpan_phy_class_init(void)
+{
+ return class_register(&wpan_phy_class);
+}
+subsys_initcall(wpan_phy_class_init);
+
+static void __exit wpan_phy_class_exit(void)
+{
+ class_unregister(&wpan_phy_class);
+}
+module_exit(wpan_phy_class_exit);
+
+MODULE_DESCRIPTION("IEEE 802.15.4 device class");
+MODULE_LICENSE("GPL v2");
+
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 1/5] ieee802154: document the skb->cb usage clearly.
From: Dmitry Eremin-Solenikov @ 2009-08-20 16:13 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1250784787-30590-1-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/networking/ieee802154.txt | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1c0c82c..23c995e 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -56,8 +56,12 @@ HardMAC
See the header include/net/ieee802154_netdev.h. You have to implement Linux
net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
-code via plain sk_buffs. The control block of sk_buffs will contain additional
-info as described in the struct ieee802154_mac_cb.
+code via plain sk_buffs. On skb reception skb->cb must contain additional
+info as described in the struct ieee802154_mac_cb. During packet transmission
+the skb->cb is used to provide additional data to device's header_ops->create
+function. Be aware, that this data can be overriden later (when socket code
+submits skb to qdisc), so if you need something from that cb later, you should
+store info in the skb->data on your own.
To hook the MLME interface you have to populate the ml_priv field of your
net_device with a pointer to struct ieee802154_mlme_ops instance. All fields are
@@ -73,3 +77,4 @@ We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
in software. This is currently WIP.
See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
+
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?
From: Frans Pop @ 2009-08-20 15:14 UTC (permalink / raw)
To: Netdev; +Cc: linux-kernel, Xiaotian Feng, Jeff Kirsher
With the current kernel I suddenly get the following error displayed
during boot:
e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
! e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed 0xfffffffb
e1000e 0000:00:19.0: setting latency timer to 64
e1000e 0000:00:19.0: irq 26 for MSI/MSI-X
This looks to be the consequence of:
commit 68eac4602b9104cdaa6c18b3edd914cececa6a1e
Author: Xiaotian Feng <dfeng@redhat.com>
Date: Fri Aug 14 14:35:52 2009 +0000
e1000e: fix use of pci_enable_pcie_error_reporting
Looking at the change it seems logical that this error, that I previously
only saw during resumes from suppend to RAM, now also shows up during
system boot. So I don't think it can be qualified as a regression, but it
is certainly rather annoying.
Questions:
- is it possible that the error occurs due to a kernel bug, or is this
certain to be due to broken hardware?
- as the error is non-fatal, should it maybe be changed from dev_err
to dev_info, so that at least it does not show up during a boot
with 'quiet'?
- if broken hardware is common, should the kernel complain at all,
or at least maybe show a slightly "friendlier" message?
System: hp2510p (ICH8, Core2 Duo) running x86_64, Debian stable ("Lenny")
00:19.0 Ethernet controller [0200]: Intel Corporation 82566MM
Gigabit Network Connection [8086:1049] (rev 03)
Subsystem: Hewlett-Packard Company Device 30c9
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 26
Region 0: Memory at e0620000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at e0640000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 2060 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Address: 00000000fee0300c Data: 41b1
Kernel driver in use: e1000e
Kernel modules: e1000e
I can provide full dmesg and kernel config if desired.
Cheers,
FJP
^ permalink raw reply
* Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server
From: Arnd Bergmann @ 2009-08-20 15:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtualization, netdev, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Or Gerlitz
In-Reply-To: <20090820144256.GB8338@redhat.com>
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
>
> > The errors from the socket (or chardev, as that was the
> > start of the argument) should still fit into the categories
> > that I mentioned, either they can be handled by the host
> > kernel, or they are fatal.
>
> Hmm, are you sure? Imagine a device going away while socket is bound to
> it. You get -ENXIO. It's not fatal in a sense that you can bind the
> socket to another device and go on, right?
Right. Not fatal in that sense, but fatal in the sense that I
can no longer transmit other frames until you recover. I think
we both meant the same here.
Arnd <><
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Sparc X1 Tulip Issue - NetDev
From: Jim Gifford @ 2009-08-20 14:37 UTC (permalink / raw)
To: netdev
Dave Miller asked me to forward this report here.
I've tried reporting this several times, this issue started with 2.6.24.
It randomly just stops transmitting after receiving after an oops.
This is from a fresh install of a 2.6.30.5 kernel.
[35883.804335] WARNING: at net/sched/sch_generic.c:226
dev_watchdog+0x24c/0x260()
[35883.804351] NETDEV WATCHDOG: eth0 (tulip): transmit timed out
[35883.804362] Modules linked in: tulip bitrev crc32
[35883.804383] Call Trace:
[35883.804406] [0000000000452308] warn_slowpath_fmt+0x28/0x40
[35883.804427] [000000000060420c] dev_watchdog+0x24c/0x260
[35883.804449] [000000000045c520] run_timer_softirq+0x180/0x200
[35883.804473] [00000000004577e8] __do_softirq+0xa8/0x180
[35883.804495] [000000000042a470] do_softirq+0x70/0xa0
[35883.804514] [0000000000457478] irq_exit+0x78/0xa0
[35883.804537] [000000000042f578] timer_interrupt+0x58/0xa0
[35883.804558] [00000000004209d4] tl0_irq14+0x14/0x20
[35883.804582] [00000000004398c8] touch_nmi_watchdog+0x8/0x40
[35883.804607] [000000000074e738] start_kernel+0x278/0x2b4
[35883.804633] [000000000065c344] tlb_fixup_done+0x80/0x9c
[35883.804648] [0000000000000000] (null)
[35883.804659] ---[ end trace 7e1dab9c687ff5bf ]---
[35883.806006] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35891.801619] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35899.797635] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35907.793597] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35915.789526] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35923.785595] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
Here's the error I got a long time ago with a 2.6.26 kernel
[ 6423.138199] ------------[ cut here ]------------
[ 6423.138230] WARNING: at net/sched/sch_generic.c:219
dev_watchdog+0x250/0x280()
[ 6423.138243] NETDEV WATCHDOG: eth0 (tulip): transmit timed out
[ 6423.138252] Modules linked in: openpromfs tulip
[ 6423.138268] Call Trace:
[ 6423.138285] [00000000005ecf10] dev_watchdog+0x250/0x280
[ 6423.138307] [000000000045f64c] run_timer_softirq+0x16c/0x1e0
[ 6423.138325] [000000000045ab7c] __do_softirq+0x5c/0xe0
[ 6423.138351] [000000000042e3f0] do_softirq+0x70/0xa0
[ 6423.138366] [000000000045a764] irq_exit+0x84/0xc0
[ 6423.138381] [000000000043327c] timer_interrupt+0x5c/0xc0
[ 6423.138400] [00000000004209d4] tl0_irq14+0x14/0x20
[ 6423.138414] [0000000000428040] cpu_idle+0x20/0xc0
[ 6423.138437] [000000000070c8bc] start_kernel+0x27c/0x2c0
[ 6423.138453] [0000000000643744] tlb_fixup_done+0x80/0x9c
[ 6423.138465] [0000000000000000] 0x0
[ 6423.138475] ---[ end trace f5f651c5dad2e555 ]---
Here's one from 2.6.28
[131219.643283] ------------[ cut here ]------------
[131219.643314] WARNING: at net/sched/sch_generic.c:219
dev_watchdog+0x250/0x280()
[131219.643327] NETDEV WATCHDOG: eth0 (tulip): transmit timed out
[131219.643337] Modules linked in: openpromfs tulip
[131219.643353] Call Trace:
[131219.643369] [00000000005ecf10] dev_watchdog+0x250/0x280
[131219.643392] [000000000045f64c] run_timer_softirq+0x16c/0x1e0
[131219.643409] [000000000045ab7c] __do_softirq+0x5c/0xe0
[131219.643435] [000000000042e3f0] do_softirq+0x70/0xa0
[131219.643450] [000000000045a764] irq_exit+0x84/0xc0
[131219.643466] [000000000043327c] timer_interrupt+0x5c/0xc0
[131219.643484] [00000000004209d4] tl0_irq14+0x14/0x20
[131219.643499] [0000000000428050] cpu_idle+0x30/0xc0
[131219.643522] [000000000070c8bc] start_kernel+0x27c/0x2c0
[131219.643538] [0000000000643744] tlb_fixup_done+0x80/0x9c
[131219.643550] [0000000000000000] 0x0
[131219.643560] ---[ end trace b95673019322adce ]---
[131219.644916] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20ec000)
[131227.640686] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20ec000)
Here are the other times I reported the issue.
http://kerneltrap.org/mailarchive/linux-net/2008/10/27/3818464
http://marc.info/?l=linux-sparc&m=123195048607500&w=2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox