Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
Hi On 2016-07-22, Arnd Bergmann wrote: > On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote: > > Stefan Lippers-Hollmann <s@gmx.de> writes: > > > On 2016-07-20, Arnd Bergmann wrote: > > >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > >> > Arnd Bergmann <a...@arndb.de> writes: > > >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> > >> Arnd Bergmann <a...@arndb.de> writes: [...] > > > While probably not overly common, it was/ is (hardware-wise) a pretty > > > interesting device due to its support for 5 GHz[1] - actually I hoped > > > it to be a (supported-) RTL8192CU variant when I bought it. > > > Unfortunately no driver[2] made it to staging or the proper kernel. > > > > I actually have one of those in my USB dongle box, but as you say, not > > overly common so not sure if/when I'll get to it. > > > > Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too > > complicated. > > My guess is that these devices have largely been replaced by > 802.11ac devices on the market, and whoever has one of the old ones > probably bought it because of the 5GHz support, so adding 2.4GHz-only > support for it may not help all that much either. Talking purely for myself, I've certainly bought the rtl8192du device because of its 5 GHz support, as I've made it a fairly hard policy for me not to buy 2.4 GHz only devices anymore. But this doesn't mean that a mainline driver only supporting 2.4 GHz for the time being would not be appreciated dearly, given that the current state of the device is pretty much being a doorstop[1] - especially considering that 5 GHz support might even become a possibility at a later time, when 802.11ac devices start demanding most of the functionality for potentially more common newer chipset generations. So even with my current personal policy of only buying 5 GHz capable devices, in practice you probably won't find 5 GHz only AP installations (aside from long range/ outdoor point-to-point connections), be it because of the plethora of existing 2.4 GHz only devices or just because of the longer indoor (walls) range of the 2.4 GHz band. In practice, by far most of my existing wireless devices don't support 5 GHz (the router does, of course) because of the reasons mentioned above, but replacing older devices takes its time. Regards Stefan Lippers-Hollmann [1] yes, I know about https://github.com/lwfinger/rtl8192du/ and even have a couple of clean-up patches pending[2] for the kernel-version branch, but those need some further testing. [2] http://aptosid.com/slh/rtl8192du/kernel-version/
Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
Hi On 2016-07-20, Arnd Bergmann wrote: > On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > Arnd Bergmann <a...@arndb.de> writes: > > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> Arnd Bergmann <a...@arndb.de> writes: [...] > Yes, I was just agreeing here that it's not worth doing that one. > As far as I can see, the evolution of these devices is > > RTL81xxU (2008) > RTL81xxSU (2009) > RTL81xxCU (2010) There is also RTL81xxDU, apparently from 2011, a dualband device coming in several variants (single MAC + single PHY, double MAC + double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC). While probably not overly common, it was/ is (hardware-wise) a pretty interesting device due to its support for 5 GHz[1] - actually I hoped it to be a (supported-) RTL8192CU variant when I bought it. Unfortunately no driver[2] made it to staging or the proper kernel. > RTL81xxEU (2013) Regards Stefan Lippers-Hollmann [1] apparently even concurrent operations for the double MAC + double PHY variants [2] https://github.com/lwfinger/rtl8192du pgp85Y9TKCthM.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages
Hi
On 2015-11-15, Dave Young wrote:
> cfg80211 module prints a lot of messages like below. Actually printing
> once is acceptable but sometimes it will print again and again, it looks
> very annoying. It is better to change these detail messages to debugging
> only.
It is a lot of info, easily repeated 3 times on boot, but it's also the
only real chance to determine why you ended up with the regulatory
domain settings you got, rather than just the values itself. Given that
a lot (most?) of officially shipping wireless devices are misconfigured
(wrong EEPROM regdom settings for the region they're sold in) and
considering that the limits can even change at runtime (IEEE 802.11d),
it is imho quite important not just to be able what the current
restrictions (iw reg get) are, but also why the kernel settled on those.
Regards
Stefan Lippers-Hollmann
--
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
Re: [PATCH] Add IP1000A Driver
Hi
Just some very basic comments to actually get it compiling, adding Francois
Romieu to CC because he has been involved with this driver in the past.
On Dienstag, 11. September 2007, Jesse Huang wrote:
From: Jesse Huang [EMAIL PROTECTED]
Change Logs: Add IP1000A Driver to kernel tree.
Signed-off-by: Jesse Huang [EMAIL PROTECTED]
---
drivers/net/ipg.c | 2331 +
drivers/net/ipg.h | 856 +++
2 files changed, 3187 insertions(+), 0 deletions(-)
create mode 100755 drivers/net/ipg.c
create mode 100755 drivers/net/ipg.h
Kconfig/ Makefile adaptions missing (borrowed from
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc2/ip1000/0001-ipg-new-gigabit-ethernet-device-driver.txt):
diff -Nrup a/drivers/net/Kconfig b/drivers/net/Kconfig
--- a/drivers/net/Kconfig 2007-09-11 12:56:50.0 +0200
+++ b/drivers/net/Kconfig 2007-09-11 13:00:52.0 +0200
@@ -159,6 +159,15 @@ config NET_SB1000
If you don't have this card, of course say N.
+config IP1000
+ tristate IP1000 Gigabit Ethernet support
+ depends on PCI EXPERIMENTAL
+ ---help---
+ This driver supports IP1000 gigabit Ethernet cards.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ipg. This is recommended.
+
source drivers/net/arcnet/Kconfig
source drivers/net/phy/Kconfig
diff -Nrup a/drivers/net/Makefile b/drivers/net/Makefile
--- a/drivers/net/Makefile 2007-09-11 13:17:23.0 +0200
+++ b/drivers/net/Makefile 2007-09-11 13:28:00.0 +0200
@@ -4,6 +4,7 @@
obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_IBM_EMAC) += ibm_emac/
+obj-$(CONFIG_IP1000) += ipg.o
obj-$(CONFIG_IXGB) += ixgb/
obj-$(CONFIG_CHELSIO_T1) += chelsio/
obj-$(CONFIG_CHELSIO_T3) += cxgb3/
e804d1c265bf1d843f845457f925a1728bbfdff7
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
new file mode 100755
index 000..bdc2b8d
--- /dev/null
+++ b/drivers/net/ipg.c
[...]
+static struct pci_device_id ipg_pci_tbl[] __devinitdata = {
+ { PCI_DEVICE(PCI_VENDOR_ID_SUNDANCE,0x1023), 0, 0, 0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_SUNDANCE,0x2021), 0, 0, 1 },
+ { PCI_DEVICE(PCI_VENDOR_ID_SUNDANCE,0x1021), 0, 0, 2 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x9021), 0, 0, 3 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4000), 0, 0, 4 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4020), 0, 0, 5 },
+ { 0, }
+};
PCI_VENDOR_ID_SUNDANCE is undefined in kernel 2.6.23-rc6:
diff -Nrup a/include/linux/pci_ids.h b/include/linux/pci_ids.h
--- a/include/linux/pci_ids.h 2007-09-11 13:17:25.0 +0200
+++ b/include/linux/pci_ids.h 2007-09-11 13:15:34.0 +0200
@@ -1841,6 +1841,8 @@
#define PCI_VENDOR_ID_ABOCOM 0x13D1
#define PCI_DEVICE_ID_ABOCOM_2BD1 0x2BD1
+#define PCI_VENDOR_ID_SUNDANCE 0x13F0
+
#define PCI_VENDOR_ID_CMEDIA 0x13f6
#define PCI_DEVICE_ID_CMEDIA_CM8338A 0x0100
#define PCI_DEVICE_ID_CMEDIA_CM8338B 0x0101
After these changes it seems to work in a 100 MBit/s network for me.
00:0a.0 Ethernet controller [0200]: Sundance Technology Inc / IC Plus Corp IC
Plus IP1000 Family Gigabit Ethernet [13f0:1023] (rev 41)
--- /dev/null
+++ b/drivers/net/ipg.h
[...]
+
+/* Miscellaneous Constants. */
+#define TRUE 1
+#define FALSE 0
Using the generic boolean definitions might be preferred.
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
