Dave,
I let my patches pile-up! Yikes!!
This request includes the usual ton of stuff for -next -- driver
updates, fixes for some earlier -next stuff, a few cfg80211 changes to
accomodate the libertas driver, etc. Of note is the rt2800pci support
added to the rt2x00 family.
Pleaset 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 b37b62fea1d1bf68ca51818f8eb1035188efd030:
Ben Hutchings (1):
sfc: Rename 'xfp' file and functions to reflect reality
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Abhijeet Kolekar (5):
iwlwifi/iwl3945: unify rts_tx_cmd_flag
iwl3945: rename tx to tx_cmd
iwlwifi/iwl3945: remove data_retry_limit
iwl3945: rearrange the code.
iwl3945: disable all tx fifos
Amitkumar Karwar (1):
libertas: Check return status of command functions
Ben M Cahill (8):
iwl3945: update iwl3945_apm_init()
iwlwifi: turn off device when not used.
iwl3945: remove unnecessary call to apm_ops.reset()
iwlagn, iwl3945: remove apm_reset() functions
iwl3945: streamline iwl3945_rfkill_poll()
iwl3945: move iwl_power_initialize()
iwlwifi: consolidate apm_init() functions
iwlwifi: make sure device is reset when unloading driver
Benoit PAPILLAULT (1):
zd1211rw: Fix TX status reporting in order to have proper rate control
Bob Copeland (1):
ath5k: use noise calibration from madwifi hal
Christian Lamparter (3):
ar9170: atomic pending A-MPDU counter
ar9170usb: atomic pending urbs counter
ar9170: don't filter BlockACK frames
David Kilroy (1):
orinoco: use cfg80211 ethtool ops
David-John Willis (1):
wl1251: add support for PG11 chips.
Holger Schurig (22):
cfg80211: no cookies in cfg80211_send_XXX()
cfg80211: remove warning in deauth case
libertas: make __lbs_cmd_async() non-static
libertas: cleanup host.h and hostcmd.h
libertas: harmonize cmd.h
libertas: make lbs_get_channel() static
libertas: remove unused lbs_cmd_802_11_inactivity_timeout()
libertas: remove unused 11d code
libertas: remove unused 11d.h as well, priv->countryinfo
libertas: change IW_ESSID_MAX_SIZE -> IEEE80211_MAX_SSID_LEN
libertas: move scan/assoc related stuff
libertas: sort variables in struct lbs_private
libertas: get current channel out of priv->curbssparams
libertas: move association related commands into assoc.c
libertas: move lbs_send_iwevcustom_event() to wext.c
libertas: remove handling for CMD_802_11_LED_GPIO_CTRL
libertas: remove handling for CMD_GET_TSF
libertas: remove "struct cmd_ds_gen"
libertas: move SIOCGIWAP calls to wext.c
libertas: move mic failure event to wext.c
libertas: sort and categorize entries in decl.h
libertas: remove some references to IW_MODE_abc
Ivo van Doorn (2):
rt2x00: Add rt2x00soc bus module
rt2x00: Implement support for rt2800pci
Javier Cardona (1):
mac80211: Learn about mesh portals from multicast traffic
Jay Sternberg (1):
iwlwifi: add missing commands to syslog messages
John W. Linville (3):
mac80211: replace netif_tx_{start,stop,wake}_all_queues
b43: use ieee80211_rx_ni()
wl1251: re-disable PG10 chips
Juuso Oikarinen (44):
wl1271: Correction to TX block allocation calculation
wl1271: Security sequence number handling for TX (for WPA)
wl1271: Correct TKIP header space handling in TX path
wl1271: Implement delayed entry into ELP
wl1271: mask aid bits 14 and 15 in ps-poll template
wl1271: Implementation for SPI busy word checking
wl1271: Configure rate policies based on AP rates
wl1271: Update join usage
wl1271: Corrections to TX path
wl1271: use workqueue provided by mac80211 instead of the default
wl1271: Clear probe-request template after scan
wl1271: Multicast filtering configuration
wl1271: Use vmalloc to allocate memory for firmware
wl1271: Add connection monitoring configuration
wl1271: Enable beacon filtering with the stack
wl1271: Configure beacon filtering on if PSM used
wl1271: Mask unneeded events from firmware to conserve power
wl1271: Update memory mapping for firmware revision 6.1.0.0.241
wl1271: Remove RX workaround
wl1271: Add top-register access functions
wl1271: RefClk configuration
wl1271: Update interrupt handling by removing an extra SPI read
wl1271: Enable ELP
wl1271: Enable smart reflex
wl1271: Update TX path block calucation algo
wl1271: Remove outdated SPI functions
wl1271: Update boot time configuration for the new firmware
wl1271: Workaround for reference clock setting on boot.
wl1271: Add structure for firmware configuration values
wl1271: Add config structure for RX path parameters
wl1271: Add config structure for TX path parameters
wl1271: Add config structure for connection management parameters
wl1271: Add config structure for FW init parameters
wl1271: Move default FW config struct away from stack
wl1271: Fix IRQ enable handling on FW init failure
wl1271: Implement beacon early termination support
wl1271: Remove busy-word checking
wl1271: Fix multicast list handling
wl1271: Fix event handling mechanism
wl1271: Support for IPv4 ARP filtering
wl1271: Remove unnecessary rx_descriptor memory allocation
wl1271: Correct memory handling for FW boot
wl1271: Fix filter configuration
wl1271: Set IEEE80211_FCTL_TODS in the null data template
Kalle Valo (3):
wl1251: rename spi device to wl1251
mac80211: add ieee80211_rx_ni()
wl1251: use ieee80211_rx_ni()
Luciano Coelho (15):
wl1271: remove unecessary qual parameter from rx status
wl1271: added Juuso Oikarinen as module author
wl1271: hack to disable filters
wl1271: implement cmd_disconnect
wl1271: workaround to send a disconnect before rejoining
wl1271: add workaround to avoid distortion due to excessive tx power
wl1271: enable HW_AVAILABLE interrupt to fix ELP
wl1271: use acx_rx_config instead of join when updating filters
wl1271: remove unnecessary joins and join only when the bssid changes
wl1271: make sure PS is disabled in PLT
wl1271: fix sparse warnings about undeclared functions
wl1271: added missing packed modifier in some acx structs
wl1271: fix endianess issues
wl1271: added missing packed modifier in some cmd structs
wl1271: use ieee80211_rx_ni()
Luis R. Rodriguez (2):
ath9k_hw: run the carrier leakage calibration fix for ar9271 as well
ath9k_hw: run ath9k_hw_9271_pa_cal() initial calibration
Marek Lindner (1):
ath9k: adjust ahb callbacks to new struct layout to avoid compile errors
Matthieu CASTET (1):
airo : allow supend with card without power management
Michael Buesch (4):
b43/legacy: Fix usage of host_pci pointer
ssb: Put host pointers into a union
b43: Remove me as maintainer
b43: Optimize PIO scratchbuffer usage
Reinette Chatre (5):
iwlwifi: fix userspace setting of sleep_level_override
iwlwifi: move iwl_setup_mac to iwlagn
iwlwifi: move rate scaling structures to header file
iwlagn: store station rate scale information in mac80211 station structure
iwlwifi: remove duplicate defines
Rui Paulo (1):
mesh: use set_bit() to set MESH_WORK_HOUSEKEEPING.
Samuel Ortiz (13):
iwmc3200wifi: WPS support
iwmc3200wifi: CT kill support
iwmc3200wifi: Profile flags can be WPA1 or WPA2 not both
iwmc3200wifi: Improve rx debug
iwmc3200wifi: Update statistics notification structure
iwmc3200wifi: Update fixed size config definitions
iwmc3200wifi: Tx power setting
iwmc3200wifi: SDIO disable race fix
iwmc3200wifi: Check for cmd pointer before dereferencing it
iwmc3200wifi: Do not handle wifi command if the interface is not ready
iwmc3200wifi: Try shared auth when open WEP fails
iwmc3200wifi: Support unexpected reboot barker
iwmc3200wifi: Set wiphy firmware version
Sujith (1):
ath9k: Fix TX hang poll routine
Teemu Paasikivi (5):
wl1271: Added 5 GHz parameters for wl1273
wl1271: Scan only enabled channels
wl1271: Added support to scan on 5 GHz band
wl1271: Added 5 GHz support to join and rx
wl1271: Checking of rx descriptor status fixed
Vivek Natarajan (1):
ath: Updates for regulatory and country codes.
Wey-Yi Guy (23):
iwlwifi: remove duplicated/unused definition
iwlwifi: additional items in sensitivity range table
iwlwifi: dynamic allocate tx queue structure
iwlwifi: showing accumulative ucode statistics counters
iwlwifi: update channel switch command API
iwlwifi: show current power save status reported by uCode
iwlwifi: identify eeprom version for 6x50 series NIC
iwlwifi: fix incorrect otp blocks number for 6x50 series
iwlwifi: set auto clock gate disable bit for 6x00/6x50 series
iwlwifi: no chain noise support for 6x50 series
iwlwifi: rework for static power save
iwlwifi: fix gain computation for 5000 series and up
iwlwifi: separate led function from statistic notification
iwlwifi: update bt co-exit configuration parameter
iwlwifi: specify the valid tx/rx chain in device config structure
iwlwifi: increase max tfd payload size
iwlwifi: choose thermal throttle method based on device config
iwlwifi: issue ct_kill host command based on device config
iwlwifi: add channel switch support to 5000 series and up
iwlwifi: remove unused parameters
iwlwifi: remove duplicated define
iwlwifi: update lowest API version support for 6x00 & 6x50 series
iwlwifi: minor comments changes for wimax co-exist command
Zhu Yi (6):
iwlwifi: use paged Rx
iwmc3200wifi: add BGN sdio device id
iwmc3200wifi: allow joining an existed IBSS network
iwmc3200wifi: handle coexistence radio notification
iwlwifi: fix use after free bug for paged rx
iwlwifi: reuse page for notification packets
MAINTAINERS | 1 -
drivers/net/wireless/airo.c | 3 +-
drivers/net/wireless/ath/ar9170/ar9170.h | 2 +-
drivers/net/wireless/ath/ar9170/hw.h | 4 +-
drivers/net/wireless/ath/ar9170/main.c | 11 +-
drivers/net/wireless/ath/ar9170/usb.c | 12 +-
drivers/net/wireless/ath/ar9170/usb.h | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 13 +
drivers/net/wireless/ath/ath5k/attach.c | 2 +
drivers/net/wireless/ath/ath5k/phy.c | 185 +-
drivers/net/wireless/ath/ath5k/reg.h | 11 +-
drivers/net/wireless/ath/ath5k/reset.c | 17 +-
drivers/net/wireless/ath/ath9k/ahb.c | 6 +-
drivers/net/wireless/ath/ath9k/calib.c | 28 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +
drivers/net/wireless/ath/regd.h | 8 +
drivers/net/wireless/ath/regd_common.h | 32 +-
drivers/net/wireless/b43/b43.h | 16 +-
drivers/net/wireless/b43/main.c | 4 +-
drivers/net/wireless/b43/pio.c | 79 +-
drivers/net/wireless/b43/xmit.c | 7 +-
drivers/net/wireless/b43legacy/main.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 17 +-
drivers/net/wireless/iwlwifi/iwl-3945-hw.h | 12 -
drivers/net/wireless/iwlwifi/iwl-3945.c | 237 +-
drivers/net/wireless/iwlwifi/iwl-3945.h | 8 -
drivers/net/wireless/iwlwifi/iwl-4965-hw.h | 3 -
drivers/net/wireless/iwlwifi/iwl-4965.c | 172 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 219 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 172 ++-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 108 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.h | 101 +
drivers/net/wireless/iwlwifi/iwl-agn.c | 154 +-
drivers/net/wireless/iwlwifi/iwl-calib.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 79 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 260 ++-
drivers/net/wireless/iwlwifi/iwl-core.h | 24 +-
drivers/net/wireless/iwlwifi/iwl-csr.h | 11 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 1 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 676 ++++--
drivers/net/wireless/iwlwifi/iwl-dev.h | 82 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 8 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 23 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 83 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 177 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-spectrum.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 62 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 45 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 266 ++-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 47 +-
drivers/net/wireless/iwmc3200wifi/commands.c | 31 +-
drivers/net/wireless/iwmc3200wifi/commands.h | 70 +-
drivers/net/wireless/iwmc3200wifi/fw.c | 9 +
drivers/net/wireless/iwmc3200wifi/iwm.h | 6 +
drivers/net/wireless/iwmc3200wifi/lmac.h | 8 +
drivers/net/wireless/iwmc3200wifi/main.c | 46 +
drivers/net/wireless/iwmc3200wifi/netdev.c | 1 +
drivers/net/wireless/iwmc3200wifi/rx.c | 84 +-
drivers/net/wireless/iwmc3200wifi/sdio.c | 10 +-
drivers/net/wireless/iwmc3200wifi/umac.h | 5 +
drivers/net/wireless/libertas/11d.c | 696 ------
drivers/net/wireless/libertas/11d.h | 105 -
drivers/net/wireless/libertas/Makefile | 1 -
drivers/net/wireless/libertas/assoc.c | 445 ++++-
drivers/net/wireless/libertas/assoc.h | 141 ++-
drivers/net/wireless/libertas/cmd.c | 482 +----
drivers/net/wireless/libertas/cmd.h | 127 +-
drivers/net/wireless/libertas/cmdresp.c | 104 +-
drivers/net/wireless/libertas/debugfs.c | 27 +-
drivers/net/wireless/libertas/decl.h | 62 +-
drivers/net/wireless/libertas/defs.h | 1 -
drivers/net/wireless/libertas/dev.h | 424 +---
drivers/net/wireless/libertas/host.h | 960 +++++++--
drivers/net/wireless/libertas/hostcmd.h | 800 -------
drivers/net/wireless/libertas/main.c | 202 +--
drivers/net/wireless/libertas/persistcfg.c | 8 +-
drivers/net/wireless/libertas/rx.c | 2 +-
drivers/net/wireless/libertas/scan.c | 250 ++-
drivers/net/wireless/libertas/scan.h | 30 +
drivers/net/wireless/libertas/tx.c | 2 +-
drivers/net/wireless/libertas/types.h | 4 +-
drivers/net/wireless/libertas/wext.c | 144 +-
drivers/net/wireless/libertas/wext.h | 8 +
drivers/net/wireless/orinoco/hw.c | 33 +-
drivers/net/wireless/orinoco/hw.h | 3 +-
drivers/net/wireless/orinoco/main.c | 33 +-
drivers/net/wireless/orinoco/orinoco.h | 1 -
drivers/net/wireless/rt2x00/Kconfig | 30 +
drivers/net/wireless/rt2x00/Makefile | 2 +
drivers/net/wireless/rt2x00/rt2800pci.c | 3323 ++++++++++++++++++++++++++
drivers/net/wireless/rt2x00/rt2800pci.h | 1960 +++++++++++++++
drivers/net/wireless/rt2x00/rt2x00.h | 7 +
drivers/net/wireless/rt2x00/rt2x00soc.c | 159 ++
drivers/net/wireless/rt2x00/rt2x00soc.h | 52 +
drivers/net/wireless/wl12xx/wl1251_main.c | 7 +-
drivers/net/wireless/wl12xx/wl1251_rx.c | 2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c | 2 +-
drivers/net/wireless/wl12xx/wl1271.h | 92 +-
drivers/net/wireless/wl12xx/wl1271_acx.c | 369 +++-
drivers/net/wireless/wl12xx/wl1271_acx.h | 586 ++---
drivers/net/wireless/wl12xx/wl1271_boot.c | 215 +-
drivers/net/wireless/wl12xx/wl1271_boot.h | 22 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 329 ++-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 115 +-
drivers/net/wireless/wl12xx/wl1271_conf.h | 911 +++++++
drivers/net/wireless/wl12xx/wl1271_event.c | 64 +-
drivers/net/wireless/wl12xx/wl1271_event.h | 30 +-
drivers/net/wireless/wl12xx/wl1271_init.c | 155 +-
drivers/net/wireless/wl12xx/wl1271_init.h | 53 +-
drivers/net/wireless/wl12xx/wl1271_main.c | 963 ++++++--
drivers/net/wireless/wl12xx/wl1271_ps.c | 68 +-
drivers/net/wireless/wl12xx/wl1271_ps.h | 2 +-
drivers/net/wireless/wl12xx/wl1271_reg.h | 47 +-
drivers/net/wireless/wl12xx/wl1271_rx.c | 86 +-
drivers/net/wireless/wl12xx/wl1271_rx.h | 4 +-
drivers/net/wireless/wl12xx/wl1271_spi.c | 311 ++--
drivers/net/wireless/wl12xx/wl1271_spi.h | 65 +-
drivers/net/wireless/wl12xx/wl1271_tx.c | 76 +-
drivers/net/wireless/wl12xx/wl1271_tx.h | 18 +-
drivers/net/wireless/wl12xx/wl12xx_80211.h | 4 +-
drivers/net/wireless/zd1211rw/zd_chip.c | 4 +-
drivers/net/wireless/zd1211rw/zd_chip.h | 18 +-
drivers/net/wireless/zd1211rw/zd_mac.c | 202 ++-
drivers/net/wireless/zd1211rw/zd_mac.h | 25 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 4 +-
drivers/ssb/driver_pcicore.c | 4 +-
include/linux/ssb/ssb.h | 20 +-
include/net/cfg80211.h | 31 +-
include/net/mac80211.h | 32 +-
net/mac80211/iface.c | 4 +-
net/mac80211/mesh.c | 4 +-
net/mac80211/mlme.c | 22 +-
net/mac80211/rx.c | 21 +-
net/mac80211/scan.c | 10 +-
net/wireless/mlme.c | 45 +-
137 files changed, 13469 insertions(+), 6003 deletions(-)
delete mode 100644 drivers/net/wireless/libertas/11d.c
delete mode 100644 drivers/net/wireless/libertas/11d.h
delete mode 100644 drivers/net/wireless/libertas/hostcmd.h
create mode 100644 drivers/net/wireless/rt2x00/rt2800pci.c
create mode 100644 drivers/net/wireless/rt2x00/rt2800pci.h
create mode 100644 drivers/net/wireless/rt2x00/rt2x00soc.c
create mode 100644 drivers/net/wireless/rt2x00/rt2x00soc.h
create mode 100644 drivers/net/wireless/wl12xx/wl1271_conf.h
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-10-28.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> Dave,
>
> I let my patches pile-up! Yikes!!
>
> This request includes the usual ton of stuff for -next -- driver
> updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> accomodate the libertas driver, etc. Of note is the rt2800pci support
> added to the rt2x00 family.
Unfortunately rt2800pci support is non-functioning at the moment... :(
> Pleaset let me know if there are problems!
I find it rather disappointing that all my review comments regarding
rt2800pci support were just completely ignored and then the initial
patch was merged just as it was..
The way rt2800usb and rt2800pci drivers are designed really results
in making the task of adding working support for RT28x0 and RT30x0
chipsets to rt2x00 infrastructure more difficult and time consuming
than it should be... :(
--
Bartlomiej Zolnierkiewicz
On Wednesday 28 October 2009 22:56:00 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> > Dave,
> >
> > I let my patches pile-up! Yikes!!
> >
> > This request includes the usual ton of stuff for -next -- driver
> > updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> > accomodate the libertas driver, etc. Of note is the rt2800pci support
> > added to the rt2x00 family.
>
> Unfortunately rt2800pci support is non-functioning at the moment... :(
>
> > Pleaset let me know if there are problems!
>
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
>
> The way rt2800usb and rt2800pci drivers are designed really results
> in making the task of adding working support for RT28x0 and RT30x0
> chipsets to rt2x00 infrastructure more difficult and time consuming
> than it should be... :(
What is even more disappointing (especially after all that "working with"
preaching) is that the patch is now in net-next-2.6..
--
Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Thu, 29 Oct 2009 12:12:41 +0100
> What is even more disappointing (especially after all that "working with"
> preaching) is that the patch is now in net-next-2.6..
John is the wireless maintainer, I take his tree in since the changes
in there have his blessing.
If you have a problem with some change in there, work it out with him
and he'll send the fixed up changes to me thereafterwards.
I don't really see what the big deal is, any change can be reverted.
On Thursday 29 October 2009 13:15:09 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Thu, 29 Oct 2009 12:12:41 +0100
>
> > What is even more disappointing (especially after all that "working with"
> > preaching) is that the patch is now in net-next-2.6..
>
> John is the wireless maintainer, I take his tree in since the changes
> in there have his blessing.
>
> If you have a problem with some change in there, work it out with him
> and he'll send the fixed up changes to me thereafterwards.
What do you mean by that?
That *I* should be fixing the patch in question instead of the submitter?
Do some different rules apply in the networking than in other parts of
the kernel that I'm not aware of?
There were valid concerns raised on the initial rt2800pci patch submission,
yet two days later patch is in John's tree, after few more days it is in yours
tree and happily on his way into 2.6.33.
Until issues mentioned in:
http://lkml.org/lkml/2009/10/17/81
are addressed rt2800pci shouldn't be queued for Linus' tree.
[ Please note that this driver doesn't work at all currently so the standard
argument of having hardware support early upstream cannot be applied here. ]
--
Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Thu, 29 Oct 2009 13:45:05 +0100
> That *I* should be fixing the patch in question instead of the
> submitter?
I'm saying that you should work with John to have him send a revert or
whatever to me.
On Thursday 29 October 2009 13:59:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Thu, 29 Oct 2009 13:45:05 +0100
>
> > That *I* should be fixing the patch in question instead of the
> > submitter?
>
> I'm saying that you should work with John to have him send a revert or
> whatever to me.
This is your responsibility to deal with your downstream maintainers,
not mine and since you have accepted John's patch I'm asking you to
revert rt2800pci patch from your tree.
--
Bartlomiej Zolnierkiewicz
Hi Bart,
On Thu, Oct 29, 2009 at 3:35 PM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
>> I'm saying that you should work with John to have him send a revert or
>> whatever to me.
>
> This is your responsibility to deal with your downstream maintainers,
> not mine and since you have accepted John's patch I'm asking you to
> revert rt2800pci patch from your tree.
So why don't you just send a patch to fix it up? I see you're doing
lots of cleanups to the staging drivers, why not direct some of that
energy to the drivers/net/wireless ones?
Pekka
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Thu, 29 Oct 2009 14:35:54 +0100
> This is your responsibility to deal with your downstream maintainers,
> not mine and since you have accepted John's patch I'm asking you to
> revert rt2800pci patch from your tree.
That's not how it works Bart. You should not be asking 'me' to do
anything on wireless bits, there is absolutely no reason to bypass
John in the workflow.
On Thursday 29 October 2009 14:53:36 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Thu, 29 Oct 2009 14:35:54 +0100
>
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
>
> That's not how it works Bart. You should not be asking 'me' to do
> anything on wireless bits, there is absolutely no reason to bypass
> John in the workflow.
John has chosen to ignore my concerns and you are sending me back to him?
I like ping-pong but as a sport.
--
Bartlomiej Zolnierkiewicz
Hi,
On Thursday 29 October 2009 14:52:50 Pekka Enberg wrote:
> Hi Bart,
>
> On Thu, Oct 29, 2009 at 3:35 PM, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> >> I'm saying that you should work with John to have him send a revert or
> >> whatever to me.
> >
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
>
> So why don't you just send a patch to fix it up? I see you're doing
"git revert a9b3a9f"
done.
Dave, if you have problems with executing the command locally I'll be
happy to supply you with the patch.
> lots of cleanups to the staging drivers, why not direct some of that
> energy to the drivers/net/wireless ones?
When did we start to apply "fix it yourself" rule instead of "submitter
should fix it" one to the _new_ code..
rt2800 drivers have their maintainers and I would like to know what they
are doing besides complaining about users and staging tree..
--
Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Thu, 29 Oct 2009 15:13:54 +0100
> John has chosen to ignore my concerns and you are sending me back to him?
That's exactly why I won't overreach his maintainership role,
because you're inability to interact with and work with the
wireless maintainer isn't my problem.
In case you're concerned, I actually agree with John and others
on this issue, and disagree with your position.
So even if I felt it legitimate to overreach John, I still wouldn't
make the change you are requesting in this case.
Does it really eat you so hard when someone disagrees with you?
That's not going to work in the long term Bart, if John disagrees with
you he's the maintainer of wireless and that's it. You're going to
have to learn to work with people, and not just automatically go to a
"higher power" as soon as someone disagrees with you.
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Thu, 29 Oct 2009 15:14:40 +0100
> Dave, if you have problems with executing the command locally I'll be
> happy to supply you with the patch.
This is not the issue.
The issue is that John disagrees with you can you can't handle
that.
So instead of continuing to discuss things with him and the
other wireless folks, you want me to just overreach everybody
and revert someone else's work.
I'm not going to do that sorry, learn how to work with the
wireless people instead.
On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.
In this particular case, I think it makes more sense to duplicate the
code _especially_ because it's not working yet. That frees people
hacking on it of having to worry about breaking other devices.
johannes
On Thursday 29 October 2009 15:20:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Thu, 29 Oct 2009 15:13:54 +0100
>
> > John has chosen to ignore my concerns and you are sending me back to him?
>
> That's exactly why I won't overreach his maintainership role,
> because you're inability to interact with and work with the
> wireless maintainer isn't my problem.
>
> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.
>
> So even if I felt it legitimate to overreach John, I still wouldn't
> make the change you are requesting in this case.
Sorry but you are also wrong then and you are just in the way of progress.
> Does it really eat you so hard when someone disagrees with you?
>
> That's not going to work in the long term Bart, if John disagrees with
> you he's the maintainer of wireless and that's it. You're going to
> have to learn to work with people, and not just automatically go to a
> "higher power" as soon as someone disagrees with you.
I'm not going to waste my time on stupid or hopeless things just because you
or John like to call themselves "maintainers".
If Red Hat or some other company wants to hire me and pay me for spinning
inside networking bureaucracy than please contact me in private but as
long as it is my own time I'll just do what I think makes sense on technical
merits and not on who is the "maintainer" of this or that..
--
Bartlomiej Zolnierkiewicz
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
In the end this results in the driver maintainer being forced to maintain
code and handle bugreports for code that he disagrees with in the first place.
This is unacceptable and has to be resolved in some way.
If it's not possible to get it reverted through John (for whatever reason),
you're in charge to help the actual code maintainer out.
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is not the problem.
The problem is that stuff is merged without ack from the maintainer
and it's virtually impossible to get the stuff reverted. The only real
way for the maintainer to resolve this is 1) live with it or 2) fix it.
And that's bad, because it completely invalidates his priority queue.
Just like you must not bypass John, the driver maintainers must not be bypassed, too.
The quality control does _only_ work if nobody in the chain is bypassed.
But in this situation the quality control did already fail and it should be
tried hard to resolve (=revert) the situation instead of pointing at John.
--
Greetings, Michael.
On Thu, Oct 29, 2009 at 3:39 PM, Michael Buesch <[email protected]> wrote:
> On Thursday 29 October 2009 15:21:01 David Miller wrote:
>> The issue is that John disagrees with you can you can't handle
>> that.
>>
>> So instead of continuing to discuss things with him and the
>> other wireless folks, you want me to just overreach everybody
>> and revert someone else's work.
>
> In the end this results in the driver maintainer being forced to maintain
> code and handle bugreports for code that he disagrees with in the first place.
> This is unacceptable and has to be resolved in some way.
> If it's not possible to get it reverted through John (for whatever reason),
> you're in charge to help the actual code maintainer out.
>
>> I'm not going to do that sorry, learn how to work with the
>> wireless people instead.
>
> This is not the problem.
> The problem is that stuff is merged without ack from the maintainer
> and it's virtually impossible to get the stuff reverted. The only real
> way for the maintainer to resolve this is 1) live with it or 2) fix it.
> And that's bad, because it completely invalidates his priority queue.
>
> Just like you must not bypass John, the driver maintainers must not be bypassed, too.
> The quality control does _only_ work if nobody in the chain is bypassed.
> But in this situation the quality control did already fail and it should be
> tried hard to resolve (=revert) the situation instead of pointing at John.
>
Hold on here. In this case it is the driver maintainer (i.e. Ivo for
the rt2x00 project) that
submitted this driver for inclusion, so the driver maintainer has not
been bypassed in
this case.
Apparently Bart has issues with the code submitted by the maintainers
and has been
unsuccessful in convincing others about these issues.
---
Gertjan.
On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
> the rt2x00 project) that
> submitted this driver for inclusion, so the driver maintainer has not
> been bypassed in
> this case.
>
> Apparently Bart has issues with the code submitted by the maintainers
> and has been
> unsuccessful in convincing others about these issues.
So Bart is not a maintainer? That of course changes the situation.
--
Greetings, Michael.
On Thu, Oct 29, 2009 at 7:48 AM, Michael Buesch <[email protected]> wrote:
> On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
>> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
>> the rt2x00 project) that
>> submitted this driver for inclusion, so the driver maintainer has not
>> been bypassed in
>> this case.
>>
>> Apparently Bart has issues with the code submitted by the maintainers
>> and has been
>> unsuccessful in convincing others about these issues.
>
> So Bart is not a maintainer? That of course changes the situation.
But you were :-P
Luis
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Thu, 29 Oct 2009 15:14:40 +0100
>
> > Dave, if you have problems with executing the command locally I'll be
> > happy to supply you with the patch.
>
> This is not the issue.
>
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
Lets look at the technical merits of this work.
It is 5 KLOC of dead code and it should be 1-2 KLOC of working code
(we may turn the blink eye on "working" part but FFS at least fix other
parts)..
Hey, Linus. We have a new driver for ya. It doesn't work, has design
problems and is not even half-finished but most wireless folks are fine
with it!
I wonder when things went so wrong here..
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is a waste of time since technical merit doesn't find much love there.
Sorry Dave but you're making me go over your head now and go into unpleasant
mode again..
Looking on how you just reverted cmd64x change which you were so proud while
taking IDE over shows where the real problem is -- in subsystems supervised
by you loyalty and rank is everything while you are busy playing the pointy
haired boss everywhere from arm to ide.
--
Bartlomiej Zolnierkiewicz
Hi Bart,
On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
>> lots of cleanups to the staging drivers, why not direct some of that
>> energy to the drivers/net/wireless ones?
>
> When did we start to apply "fix it yourself" rule instead of "submitter
> should fix it" one to the _new_ code..
Don't be silly, I didn't say that.
I was simply pointing out that your time would probably be better
spent in improving the "proper" ralink wireless drivers but if you
_really_ prefer to spend your time in pointless arguments, go ahead.
It should be pretty obvious by now that the best way to improve things
is to work with the relevant maintainers, not against them. (Unless
you wish your work to be ignored, of course.)
Pekka
On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:
> Hi Bart,
>
> On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> >> lots of cleanups to the staging drivers, why not direct some of that
> >> energy to the drivers/net/wireless ones?
> >
> > When did we start to apply "fix it yourself" rule instead of "submitter
> > should fix it" one to the _new_ code..
>
> Don't be silly, I didn't say that.
Sorry, I must have misunderstood you.
> I was simply pointing out that your time would probably be better
> spent in improving the "proper" ralink wireless drivers but if you
Thanks for the concern. However recent discussions made my realize how
I should really be spending my time effectively way too well.
> _really_ prefer to spend your time in pointless arguments, go ahead.
I don't think that my technical arguments are pointless.
Quite the contrary, I'm pretty confident that addressing my review concerns
would result in better RT28x00 / RT30x0 support in the very near future.
> It should be pretty obvious by now that the best way to improve things
> is to work with the relevant maintainers, not against them. (Unless
> you wish your work to be ignored, of course.)
I work with a lot of other maintainers. I would say that providing valuable
review feedback is also "working with" (at least I would be very happy with
such feedback in my projects).
--
Bartlomiej Zolnierkiewicz
Hi Bart,
On Thu, Oct 29, 2009 at 11:48 PM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
>> _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
I don't think your technical arguments are pointless either. However,
asking Dave to revert something over John and then arguing about it is
pointless and will likely just piss people off and make them ignore
you.
Pekka
On Thu, 2009-10-29 at 22:48 +0100, Bartlomiej Zolnierkiewicz wrote:
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
So you know how to make the driver better, whine that it doesn't work,
but don't help out either. Hey, good way to collaborate!
> > It should be pretty obvious by now that the best way to improve things
> > is to work with the relevant maintainers, not against them. (Unless
> > you wish your work to be ignored, of course.)
>
> I work with a lot of other maintainers. I would say that providing valuable
> review feedback is also "working with" (at least I would be very happy with
> such feedback in my projects).
Face it though, people have read your feedback, thought about it, and
decided to disagree. You seem to have a childish problem with that,
appealing to higher authority to get your way just makes you look more
childish.
johannes
On 30-10-2009 08:00, Johannes Berg wrote:
> On Thu, 2009-10-29 at 22:48 +0100, Bartlomiej Zolnierkiewicz wrote:
>
>> I don't think that my technical arguments are pointless.
>>
>> Quite the contrary, I'm pretty confident that addressing my review concerns
>> would result in better RT28x00 / RT30x0 support in the very near future.
>
> So you know how to make the driver better, whine that it doesn't work,
> but don't help out either. Hey, good way to collaborate!
>
>>> It should be pretty obvious by now that the best way to improve things
>>> is to work with the relevant maintainers, not against them. (Unless
>>> you wish your work to be ignored, of course.)
>> I work with a lot of other maintainers. I would say that providing valuable
>> review feedback is also "working with" (at least I would be very happy with
>> such feedback in my projects).
>
> Face it though, people have read your feedback, thought about it, and
> decided to disagree. You seem to have a childish problem with that,
> appealing to higher authority to get your way just makes you look more
> childish.
There are various ways to disagree, and ignoring by John questions
from a merited developer both in this referenced lkml and current
threads looks at least strange (if not offensive) as well.
Jarek P.
On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:
> There are various ways to disagree, and ignoring by John questions
> from a merited developer both in this referenced lkml and current
> threads looks at least strange (if not offensive) as well.
Did you read the thread for which Bartlomiej provided a link earlier?
There were ten responses (only three of them from him) in that thread.
His comments were not ignored, they were rejected.
Ever since Bartlomiej decided to tear himself away from
drivers/staging, he has been nothing but negative -- petty, whining,
indignat, whatever. Just what has he done to merit any special
consideration here? Why should he have any sort of veto over rt2x00?
And of all things on which to take a stand -- how dare the rt2x00 guys
use two header files instead of three? The nerve of those people!!!
Ridiculous...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Thu, Oct 29, 2009 at 10:48:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:
> > I was simply pointing out that your time would probably be better
> > spent in improving the "proper" ralink wireless drivers but if you
>
> Thanks for the concern. However recent discussions made my realize how
> I should really be spending my time effectively way too well.
>
> > _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
More like "petty"...
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
Yeah, maybe. Or they could just waste someone's time mashing
together some definitions to prematurely turn two header files into
three instead of spending that time on resolving operational issues.
In either case it is a judgment call, and IMHO not your call to make.
> > It should be pretty obvious by now that the best way to improve things
> > is to work with the relevant maintainers, not against them. (Unless
> > you wish your work to be ignored, of course.)
>
> I work with a lot of other maintainers. I would say that providing valuable
> review feedback is also "working with" (at least I would be very happy with
> such feedback in my projects).
"Valuable" feedback would be welcome. In fact, your initial feedback
in this case was welcome -- even moreso had it included a patch.
Your arrogant follow-ups and self-righteous indignation, however,
is quite a bit less welcome. Please take it somewhere else.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Fri, Oct 30, 2009 at 11:02:24AM -0400, John W. Linville wrote:
> On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:
>
> > There are various ways to disagree, and ignoring by John questions
> > from a merited developer both in this referenced lkml and current
> > threads looks at least strange (if not offensive) as well.
>
> Did you read the thread for which Bartlomiej provided a link earlier?
> There were ten responses (only three of them from him) in that thread.
> His comments were not ignored, they were rejected.
>
> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,
> indignat, whatever. Just what has he done to merit any special
> consideration here? Why should he have any sort of veto over rt2x00?
>
> And of all things on which to take a stand -- how dare the rt2x00 guys
> use two header files instead of three? The nerve of those people!!!
>
> Ridiculous...
Maybe. Different tastes for sure, so simply no good solution.
Anyway, my point was somewhere else: Davem could be a good example;-)
I simply can't imagine a thread with such concerns left completely
uncommented before merging a patch. It's not about convincing anybody.
Usually you know at least if the concern is dismissed, or valid, but
fixable. (Sometimes you can even read between lines, or explicit, what
he really thinks...)
This discussion is mainly around trying to omit a maintainer with
"higher authority". Of course it's a mortal sin! ...Except, when the
maintainer doesn't seem to respond at all.
BTW, it seems Bartlomiej's main argument in the current thread has
changed to the non-working driver, so ridiculous only if you have a
clue.
Jarek P.
On Friday 30 October 2009 16:02:24 John W. Linville wrote:
> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,
I think that you should ping Greg about this since somebody impersonating
for me is sending him patches. Last week alone over 20 such patches were
merged -- who knows what this person might be planning.. ;)
Probably the following patch was the source of confusion:
http://patchwork.kernel.org/patch/55076/
It just aligns my personal interests w/ ongoing work done by other people,
hch is working on mac80211 via driver and Greg has announced some time ago
that he was going to work on proper rtl819x support.
--
Bartlomiej Zolnierkiewicz
* John W. Linville <[email protected]> wrote:
> On Fri, Oct 30, 2009 at 11:06:16AM +0000, Jarek Poplawski wrote:
>
> > There are various ways to disagree, and ignoring by John questions
> > from a merited developer both in this referenced lkml and current
> > threads looks at least strange (if not offensive) as well.
>
> Did you read the thread for which Bartlomiej provided a link earlier?
> There were ten responses (only three of them from him) in that thread.
> His comments were not ignored, they were rejected.
>
> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,
> indignat, whatever. Just what has he done to merit any special
> consideration here? Why should he have any sort of veto over rt2x00?
I got curious, as my past experience with Bartlomiej is that he is a
factual, reliable, knowledgable upstream driver developer interested in
difficult pieces of code others are reluctant to touch, for whom it is
rather atypical to get 'petty, whining, indignant'.
So i have read the thread you and Bartlomiej referenced:
http://lkml.org/lkml/2009/10/17/81
... and my understanding of that discussion is very different from
yours. Here is my annotated history of the beginnings of that
discussion:
Bartlomiej (in <[email protected]>) started his
review of the driver with:
| First let me say that I'm very happy to see this patch finally being
| submitted and I appreciate the effort..
|
| (I'll give it a spin on Eee 901 w/ 2.6.32-rc5 sometime later..)
Very friendly and constructive. Pretty much the Bartlomiej i have known
for years.
Then he continues with his technical observations:
| Now to the less happy part..
|
| I also used the opportunity to take a closer look at this driver and
| it seems that it needlessly adds around 2 KLOC to kernel by
| duplicating the common content of rt2800usb.h to rt2800pci.h instead
| of moving it to the shared header (like it is done in the staging
| crap drivers):
|
| [...]
|
| All in all, the total amount of the kernel code needed for
| implementing rt2800pci functionality should 1-2 KLOC instead of the
| current 5 KLOC.
Looks like a valid technical point that should be replied to in ernest.
Johannes Berg's first reply (<[email protected]>)
ignored Bartlomiej's friendly approach and launched a combative,
emotion-laden, unconstructive (and technically inapposite) attack:
| Tell me you're kidding -- comparing 2k duplicated LOC with a driver
| that ships its own wifi stack?
Bartlomiej's reply (<[email protected]>) ignored
the attack (gracefully) and replied to the technical portion only:
| > Tell me you're kidding -- comparing 2k duplicated LOC with a driver
| > that ships its own wifi stack?
|
| Why would I be?
|
| 1) The patch is submitted to kernel _proper_ not kernel staging so I
| see no excuse for duplicating 2-4 KLOC and it should be fixed.
|
| 2) The fact that the some staging driver consists in 90% of crap
| doesn't mean that it doesn't have some good design ideas.. (i.e.
| abstracting chipset registers access in a discussed case)
To which technical point Johannes elected not to reply. (Effectively
conceding Bartlomiej's point as per lkml discussion rules.)
[ There are similar patterns in other threads of this discussion - the
reply in (<[email protected]>) and followups
were similarly dismissive (while not as combative as Johannes's reply)
- with an often offensive tone against Bartlomiej. ]
Bartlomiej followed up with his test results in another message in
<[email protected]>. Corroborated by Luis Correia in
<[email protected]>. Both
messages were factual, constructive and friendly.
Neither failure report was replied to in that thread and remains ignored
up to today, 15 days down the line.
Alas, the portion of the story that is visible in that discussion on
lkml contradicts your claim almost 180 degrees. The person being
attacked there was Bartlomiej and i simply dont see where you got the
conclusion from that he was 'petty, whining, indignant'.
Now look at the aftermath from Bartlomiej's perspective: this
non-working driver with arguably unresponsive, unfriendly maintainers
got pulled twice (first by you and then by David), and it is now on the
unstoppable path upstream. By omission he's been forced to raise these
issues at every hop that pulls this piece of code - and it was not his
choice to be exposed to such a spiral of a workflow.
I can understand David trusting your judgement and not wanting to get
involved in the fine details, but having read the surrounding discussion
i dont understand your interpretation of the events, and i dont
understand on what basis you launched your very serious accusation, that
he is being 'petty, whining, indignant'. Every reply from him in that
thread is the exact opposite of that. Care to elaborate?
Thanks,
Ingo
On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> So i have read the thread you and Bartlomiej referenced:
>
> http://lkml.org/lkml/2009/10/17/81
>
> ... and my understanding of that discussion is very different from
> yours. Here is my annotated history of the beginnings of that
> discussion:
[snip]
You shouldn't ignore all previous interaction between Bart and us --
which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
Of course we were biased when he came around with that petty code
duplication argument, since it seemed to support only his agenda of
working only with the staging drivers.
johannes
* Johannes Berg <[email protected]> wrote:
> On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
>
> > So i have read the thread you and Bartlomiej referenced:
> >
> > http://lkml.org/lkml/2009/10/17/81
> >
> > ... and my understanding of that discussion is very different from
> > yours. Here is my annotated history of the beginnings of that
> > discussion:
>
> [snip]
>
> You shouldn't ignore all previous interaction between Bart and us --
> which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
I have seen that exchange too - here's the lkml.org link for those who
like the lkml.org format:
http://lkml.org/lkml/2009/10/13/186
And i can see no supporting fact here either, for the (very serious)
accusation launched by John Linville, that Bartlomiej is 'petty,
whining, indignant'. In my reading he is the opposite of that, even in
this second thread you point out.
So, no matter how much you disagree about the code and its direction,
please either back up your assertion with specific links to a pattern of
misbehavior or apologize for the ad-hominen attacks against Bartlomiej.
> Of course we were biased when he came around with that petty code
> duplication argument, since it seemed to support only his agenda of
> working only with the staging drivers.
Why do you think that disagreeing in the past gives you the right to get
into ad-hominens? You should concentrate on the code and on the
technical side, not on the person making the argument.
Also, why do you characterise a code duplication argument as 'petty'?
Bloat and unnecessary technical forking is the #1 enemy of Linux.
Integrating code and infrastructure is the #1 strength of Linux.
Upstream subsystems/drivers running away with their private
implementations has its clear costs:
- introduces bugs
- makes drivers shallow in practice
- makes unifying drivers and infrastructure so hard down the road
- bloats the code, increases i$ footprint
I routinely refuse patches based on 'please dont duplicate' arguments,
in fact i did it once today already.
[ I dont know why drivers/staging/ is even an argument here - he argued
about the technical qualities of a new upstream driver, not about a
staging driver. Upstream drivers are to be held to higher standards,
_especially_ now that we can isolate not-clean-enough-yet drivers into
drivers/staging/, without hurting users. ]
Thanks,
Ingo
On Mon, Nov 02, 2009 at 10:10:38AM +0100, Ingo Molnar wrote:
>
> * John W. Linville <[email protected]> wrote:
<snip>
> > Ever since Bartlomiej decided to tear himself away from
> > drivers/staging, he has been nothing but negative -- petty, whining,
> > indignat, whatever. Just what has he done to merit any special
> > consideration here? Why should he have any sort of veto over rt2x00?
>
> I got curious, as my past experience with Bartlomiej is that he is a
> factual, reliable, knowledgable upstream driver developer interested in
> difficult pieces of code others are reluctant to touch, for whom it is
> rather atypical to get 'petty, whining, indignant'.
YMMV...
<snip>
> Bartlomiej's reply (<[email protected]>) ignored
> the attack (gracefully) and replied to the technical portion only:
>
> | > Tell me you're kidding -- comparing 2k duplicated LOC with a driver
> | > that ships its own wifi stack?
> |
> | Why would I be?
> |
> | 1) The patch is submitted to kernel _proper_ not kernel staging so I
> | see no excuse for duplicating 2-4 KLOC and it should be fixed.
> |
> | 2) The fact that the some staging driver consists in 90% of crap
> | doesn't mean that it doesn't have some good design ideas.. (i.e.
> | abstracting chipset registers access in a discussed case)
>
> To which technical point Johannes elected not to reply. (Effectively
> conceding Bartlomiej's point as per lkml discussion rules.)
Really? "Last post wins" is the rule? I hope you are joking...
> I can understand David trusting your judgement and not wanting to get
> involved in the fine details, but having read the surrounding discussion
> i dont understand your interpretation of the events, and i dont
> understand on what basis you launched your very serious accusation, that
> he is being 'petty, whining, indignant'. Every reply from him in that
> thread is the exact opposite of that. Care to elaborate?
Despite your links, we seem to be reading different threads. I'm not
sure I can reach your conclusions even with the most generous reading
of Bartlomiej's posts and the most critical readings of _everyone_
else's.
It seems Bartlomiej has taken it personally that we don't like having
the Ralink vendor drivers in the staging tree and he has decided to be
an irritant in linux-wireless as some sort of revenge. As a bonus,
he has thrown-in some random ramblings attacking the inclusion of
Pulseaudio in Fedora and criticizing Dave's handling of the ide tree.
And worst of all he has chosen to make a big stink about whether or
not the rt2x00 family of drivers (which shares tons of code already,
BTW) is sharing enough code for his taste in drivers that are currently
under active development.
Now you have come along to defend him for whatever your reasons,
and you have chosen to act as if Bartlomiej has been ignored simply
because you don't like the responses he got. Further, you seem to
expect me to have given him some veto over a driver for which has
has contributed essentially nothing[1]. Why? Simply because he doesn't
agree with the driver maintainer's JUDGMENT CALL? Or mine? Or Dave's?
And for all his objections, he can't be bothered to offer a patch?
I can only guess as to why you are being deferential to Bartlomiej
and overlooking not only how he has treated the rest of us but also
that his technical complaint is minor. I can only ask you to consider
that maybe Bartlomiej is not so aggrieved as he claims.
John
[1] Even his bug reports and code reviews have clearly been from the
perspective of "you should just be using the staging driver".
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Mon, Nov 02, 2009 at 11:07:02AM +0100, Ingo Molnar wrote:
>
> * Johannes Berg <[email protected]> wrote:
>
> > On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> >
> > > So i have read the thread you and Bartlomiej referenced:
> > >
> > > http://lkml.org/lkml/2009/10/17/81
> > >
> > > ... and my understanding of that discussion is very different from
> > > yours. Here is my annotated history of the beginnings of that
> > > discussion:
> >
> > [snip]
> >
> > You shouldn't ignore all previous interaction between Bart and us --
> > which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
>
> I have seen that exchange too - here's the lkml.org link for those who
> like the lkml.org format:
>
> http://lkml.org/lkml/2009/10/13/186
>
> And i can see no supporting fact here either, for the (very serious)
> accusation launched by John Linville, that Bartlomiej is 'petty,
> whining, indignant'. In my reading he is the opposite of that, even in
> this second thread you point out.
Again, you seem to be very generous to Bartlomiej and very critical of
the rest of us in your readings.
> So, no matter how much you disagree about the code and its direction,
> please either back up your assertion with specific links to a pattern of
> misbehavior or apologize for the ad-hominen attacks against Bartlomiej.
His behavior is evident in the threads you cited. How you do not
see that is a mystery.
> > Of course we were biased when he came around with that petty code
> > duplication argument, since it seemed to support only his agenda of
> > working only with the staging drivers.
>
> Why do you think that disagreeing in the past gives you the right to get
> into ad-hominens? You should concentrate on the code and on the
> technical side, not on the person making the argument.
>
> Also, why do you characterise a code duplication argument as 'petty'?
Did you actually look at the thread? Or did you simply here "code
duplication" and run with it?
> Bloat and unnecessary technical forking is the #1 enemy of Linux.
> Integrating code and infrastructure is the #1 strength of Linux.
>
> Upstream subsystems/drivers running away with their private
> implementations has its clear costs:
...which has nothing to do with the case at hand. Please do not
perpetuate this myth. If anything, your argument applies far more
to the drivers in staging that Bartlomiej has focused his attention
upon until recently.
<snip>
> [ I dont know why drivers/staging/ is even an argument here - he argued
> about the technical qualities of a new upstream driver, not about a
> staging driver. Upstream drivers are to be held to higher standards,
> _especially_ now that we can isolate not-clean-enough-yet drivers into
> drivers/staging/, without hurting users. ]
If you had been keeping-up, you would realize that Bartlomiej is upset
about our criticisms of the Ralink drivers in staging. That would seem
to be the reason he has made himself such an irritant in linux-wireless
over the past few weeks.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
[huge snip]
This is going to be my last reply to this thread (even if I get to be insulted).
I'm not a coder, I'm a tester and administrator for the rt2x00 project.
I'm not happy about the current state of the rt2x00 in-kernel drivers.
I tend to agree that more could be done.
Even though I'm not a coder, I could be hipotetically responsable for
the current situation. It is my job function to motivate people to
work on the rt2x00 in-kernel drivers, but apparently I've failed here.
It's not an atitude problem, as some have suggested, it's just life.
About Bartlomiej, there is only one more thing that I'll say:
I've searched on my GMail archives and the only patch Bart has
provided so far for the rt2x00 project is this:
[PATCH] MAINTAINERS: rt2x00 list is moderated
Which, while technically correct, adds nothing to the project.
So, I will personally continue to ignore Bart's comments, regards and
rants, until he provides patches for rt2x00 that actually make the
driver better.
Luis Correia
rt2x00 project admin,
(but not writing this email as an official project statement)
Luis Correia wrote:
> [huge snip]
>
> This is going to be my last reply to this thread (even if I get to be insulted).
>
> I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> I'm not happy about the current state of the rt2x00 in-kernel drivers.
> I tend to agree that more could be done.
>
> Even though I'm not a coder, I could be hipotetically responsable for
> the current situation. It is my job function to motivate people to
> work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> It's not an atitude problem, as some have suggested, it's just life.
>
> About Bartlomiej, there is only one more thing that I'll say:
>
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
>
> [PATCH] MAINTAINERS: rt2x00 list is moderated
>
> Which, while technically correct, adds nothing to the project.
whatever. That patch still needs to be applied.
> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.
>
> Luis Correia
> rt2x00 project admin,
> (but not writing this email as an official project statement)
--
~Randy
On Mon, Nov 02, 2009 at 09:36:20AM -0800, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> >
> > This is going to be my last reply to this thread (even if I get to be insulted).
> >
> > I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> > I'm not happy about the current state of the rt2x00 in-kernel drivers.
> > I tend to agree that more could be done.
> >
> > Even though I'm not a coder, I could be hipotetically responsable for
> > the current situation. It is my job function to motivate people to
> > work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> > It's not an atitude problem, as some have suggested, it's just life.
> >
> > About Bartlomiej, there is only one more thing that I'll say:
> >
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And, in fact, it has been...already in linux-2.6:
commit b5654f5e7fc414a6e69b3647db2b043257c9e62e
Author: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Mon Oct 26 16:49:50 2009 -0700
MAINTAINERS: rt2x00 list is moderated
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Hth...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Well and then another rt2x00 developer discovered this nice little
fight about rt2x00 on the mailinglists...
First for the record, because at the start people where talking about the
maintainership of rt2x00, one thing needs to be straight:
As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
drivers/net/wireless/rt2x00 folder.
At this time I am hold the position within the rt2x00 team which is making the
decisions about the rt2x00 code and design.
I am also the one that is (N)Acks the patches from others when they are send
to the rt2x00-users or linux-wireless mailinglist.
As for my behavior in discussions:
I am doing my best to listen to all complains regarding the rt2x00 code and design and
improve it if the complainer has a valid point. However, obviously I can disagree with
the complainer and in that case I will explain to that person _why_ I disagree. It is up
to the complainer to convince me that he is right, agree with my response, or whine.
Now as for more specific responses:
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> rt2800 drivers have their maintainers and I would like to know what they
> are doing besides complaining about users and staging tree..
Working for Avanade, Zarafa and as freelancer for Linux Magazine.
But I guess you mean rt2x00 specific work?
Well that list consists of:
- Listening to people complain
- Responding to those people, because otherwise they complain that they are being ignored.
- Following bug reports, and request testing or additional information if required
- Bugfixing
- Reviewing patches from contributors
- Applying patches from contributors
- Discussing improvements over patches from contributors
Well nothing of this list should be new to you, but apparently you needed some confirmation.
On Thursday 29 October 2009, Johannes Berg wrote:
> On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
>
> > In case you're concerned, I actually agree with John and others
> > on this issue, and disagree with your position.
>
> In this particular case, I think it makes more sense to duplicate the
> code _especially_ because it's not working yet. That frees people
> hacking on it of having to worry about breaking other devices.
Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
in the previous discussion.
On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
Your code review comments were commented upon with my reasons
why this code duplication exists. I even admitted that when the time is
ready I will remove the code duplication.
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
The review concerns regarding the duplicate code would only reduce the
amount of code. It would not magically fix bugs (at least the chance of that
would be quite small).
So far rt2800usb performs better then rt2800pci, and the difference gets
only bigger when I use the exact same register initialization from rt2800usb
in rt2800pci.
But Bartjmoiej knows that the register initialization can be exactly the same,
from his experience with the staging drivers.
So far hasn't been interested in sharing the knowledge in what must be
changed in rt2800pci/usb to make them both work with the same register
initialization.
On Monday 02 November 2009, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And I haven't seen anybody stating the opposite...
Ivo
> About Bartlomiej, there is only one more thing that I'll say:
>
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
>
> [PATCH] MAINTAINERS: rt2x00 list is moderated
>
> Which, while technically correct, adds nothing to the project.
>
> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.
Well, he provided review feedback... he should be thanked for that,
not flamed for it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> Well and then another rt2x00 developer discovered this nice little
> fight about rt2x00 on the mailinglists...
>
> First for the record, because at the start people where talking about the
> maintainership of rt2x00, one thing needs to be straight:
>
> As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> drivers/net/wireless/rt2x00 folder.
>
> At this time I am hold the position within the rt2x00 team which is making the
> decisions about the rt2x00 code and design.
rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.
This is not how things work here, sorry.
> I am also the one that is (N)Acks the patches from others when they are send
> to the rt2x00-users or linux-wireless mailinglist.
If you are not willing to stand behind your own patches, how do you expect
others to trust your judgment?
> As for my behavior in discussions:
>
> I am doing my best to listen to all complains regarding the rt2x00 code and design and
> improve it if the complainer has a valid point. However, obviously I can disagree with
> the complainer and in that case I will explain to that person _why_ I disagree. It is up
> to the complainer to convince me that he is right, agree with my response, or whine.
>
> Now as for more specific responses:
>
> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > rt2800 drivers have their maintainers and I would like to know what they
> > are doing besides complaining about users and staging tree..
>
> Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> But I guess you mean rt2x00 specific work?
> Well that list consists of:
> - Listening to people complain
> - Responding to those people, because otherwise they complain that they are being ignored.
> - Following bug reports, and request testing or additional information if required
> - Bugfixing
> - Reviewing patches from contributors
> - Applying patches from contributors
> - Discussing improvements over patches from contributors
>
> Well nothing of this list should be new to you, but apparently you needed some confirmation.
I meant rt2800 support specifically, sorry if this was not clear.
The work on rt2800 drivers was started in the beginning of 2008 and after
few months you were already behind deadlines that you had set yourself:
http://markmail.org/message/a753dws6tqytb3a4
During almost two years rt2x00 project didn't manage to produce working
support for rt2800.. in the meantime the world has moved on and we have
another chipset generation (rt30x0) to worry about, and also rt33xx one
on the horizon..
> On Thursday 29 October 2009, Johannes Berg wrote:
> > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> >
> > > In case you're concerned, I actually agree with John and others
> > > on this issue, and disagree with your position.
> >
> > In this particular case, I think it makes more sense to duplicate the
> > code _especially_ because it's not working yet. That frees people
> > hacking on it of having to worry about breaking other devices.
>
> Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> in the previous discussion.
Nope, it just adds needles development/maintenance burden since it will
make people lose fixes already applied to the working code, please see my
other mail.
> On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > I find it rather disappointing that all my review comments regarding
> > rt2800pci support were just completely ignored and then the initial
> > patch was merged just as it was..
>
> Your code review comments were commented upon with my reasons
> why this code duplication exists. I even admitted that when the time is
> ready I will remove the code duplication.
The right time was two years ago when you were starting working on those
drivers. IOW It shouldn't have happened in the first place.
I also have serious questions about transparency of the process and cannot
understand why it takes so long for the code to be pushed upstream.
commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
tree back in September (you're re-basing rt2x00 tree at random moments so it
is impossible to track the status of patches that you are handling).
rt2800pci patch itself has been getting dust in your tree since at least
April (it hasn't received any bigger updates since then)..
> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > Quite the contrary, I'm pretty confident that addressing my review concerns
> > would result in better RT28x00 / RT30x0 support in the very near future.
>
> The review concerns regarding the duplicate code would only reduce the
> amount of code. It would not magically fix bugs (at least the chance of that
> would be quite small).
Please see my other mail.
> So far rt2800usb performs better then rt2800pci, and the difference gets
> only bigger when I use the exact same register initialization from rt2800usb
> in rt2800pci.
>
> But Bartjmoiej knows that the register initialization can be exactly the same,
> from his experience with the staging drivers.
> So far hasn't been interested in sharing the knowledge in what must be
> changed in rt2800pci/usb to make them both work with the same register
> initialization.
The knowledge is all in your local copy of linux-next (I don't memorize
things like chipset initialization sequences) and in the review comments
that you have happily dismissed.
--
Bartlomiej Zolnierkiewicz
On Tuesday 03 November 2009, Bartlomiej Zolnierkiewicz wrote:
> On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> > Well and then another rt2x00 developer discovered this nice little
> > fight about rt2x00 on the mailinglists...
> >
> > First for the record, because at the start people where talking about the
> > maintainership of rt2x00, one thing needs to be straight:
> >
> > As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> > for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> > drivers/net/wireless/rt2x00 folder.
> >
> > At this time I am hold the position within the rt2x00 team which is making the
> > decisions about the rt2x00 code and design.
>
> rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.
You really have problems reading mails, haven't you? Or at least you
only want to read what you want to read...
Please READ the paragraph again.
I will highlight the thing again:
"about the rt2x00 code and design"
I am not talking about Ralink support I am talking about RT2X00 support.
If you feel that the maintainer of a particular driver has no say about the driver
he wrote himself, then I am not seeing the point of having maintainers. We can
then all just randomly hack in all drivers without any form of structure.
> > I am also the one that is (N)Acks the patches from others when they are send
> > to the rt2x00-users or linux-wireless mailinglist.
>
> If you are not willing to stand behind your own patches, how do you expect
> others to trust your judgment?
Ehm, please explain? I am sending patches upstream, but apparently I don't stand behind them?
Then why the f*** am I sending them?
> > As for my behavior in discussions:
> >
> > I am doing my best to listen to all complains regarding the rt2x00 code and design and
> > improve it if the complainer has a valid point. However, obviously I can disagree with
> > the complainer and in that case I will explain to that person _why_ I disagree. It is up
> > to the complainer to convince me that he is right, agree with my response, or whine.
> >
> > Now as for more specific responses:
> >
> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > rt2800 drivers have their maintainers and I would like to know what they
> > > are doing besides complaining about users and staging tree..
> >
> > Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> > But I guess you mean rt2x00 specific work?
> > Well that list consists of:
> > - Listening to people complain
> > - Responding to those people, because otherwise they complain that they are being ignored.
> > - Following bug reports, and request testing or additional information if required
> > - Bugfixing
> > - Reviewing patches from contributors
> > - Applying patches from contributors
> > - Discussing improvements over patches from contributors
> >
> > Well nothing of this list should be new to you, but apparently you needed some confirmation.
>
> I meant rt2800 support specifically, sorry if this was not clear.
>
> The work on rt2800 drivers was started in the beginning of 2008 and after
> few months you were already behind deadlines that you had set yourself:
>
> http://markmail.org/message/a753dws6tqytb3a4
>
> During almost two years rt2x00 project didn't manage to produce working
> support for rt2800.. in the meantime the world has moved on and we have
> another chipset generation (rt30x0) to worry about, and also rt33xx one
> on the horizon..
And thank you for your valuable effort in assisting in the driver development
during those 2 years. I am really happy about people looking from the sideline
and complaining things are not moving as fast as they would like it.
If you cared about the slow progress, then you had the past 2 years to help out,
but apparently that is too much to ask. Unfortunately a lot of people think like
you, which means that during those 2 years dozens of people have complained
about the lack of progress without any of them helping out (and I am not talking
about users only, I am also talking about people who have programming skills).
If you look at the Signed-off list of the rt2800pci/usb patches you will see that
only a handfull of people actually helped.
> > On Thursday 29 October 2009, Johannes Berg wrote:
> > > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> > >
> > > > In case you're concerned, I actually agree with John and others
> > > > on this issue, and disagree with your position.
> > >
> > > In this particular case, I think it makes more sense to duplicate the
> > > code _especially_ because it's not working yet. That frees people
> > > hacking on it of having to worry about breaking other devices.t initialization sequences) and in the review
> >
> > Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> > in the previous discussion.
>
> Nope, it just adds needles development/maintenance burden since it will
> make people lose fixes already applied to the working code, please see my
> other mail.
As mentioned in my mail, there were differences in the drivers during development,
and I had a working rt2800usb driver as base. But with the same settings the rt2800pci
couldn't get to work.
With the merged drivers you would constantly need to check if it works for rt2800pci,
but also if you haven't broken rt2800usb in the meantime. This way rt2800usb was
able to be merged months before rt2800pci because there was no common code.
Once both drivers are solid working, then there are no problems with merging them,
I wonder how many times I have to repeat that...
> > On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > I find it rather disappointing that all my review comments regarding
> > > rt2800pci support were just completely ignored and then the initial
> > > patch was merged just as it was..
> >
> > Your code review comments were commented upon with my reasons
> > why this code duplication exists. I even admitted that when the time is
> > ready I will remove the code duplication.
>
> The right time was two years ago when you were starting working on those
> drivers. IOW It shouldn't have happened in the first place.
Please see my other mail, please read my above comment, and thank you again
for participating in the rt2800 development of those 2 years.
> I also have serious questions about transparency of the process and cannot
> understand why it takes so long for the code to be pushed upstream.
So you start looking now, and complain you can't see the process of the last 2 years?
There have been dozens of status reports regarding rt2800, and the number of responses
in general have always been limited.
But now I reread that last sentence, you are complaining that rt2800pci wasn't pushed
upstream earlier? While this whole discussion is about that merging rt2800pci was a bad
idea?
> commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
> tree back in September (you're re-basing rt2x00 tree at random moments so it
> is impossible to track the status of patches that you are handling).
I'm missing the point here.
> rt2800pci patch itself has been getting dust in your tree since at least
> April (it hasn't received any bigger updates since then)..
And how many times do I have to repeat the reason?
I think that after dozens of mails, the message should have been clear, especially
to somebody who apparently has been monitoring and worrying about the development
process for the last 2 years....
> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > Quite the contrary, I'm pretty confident that addressing my review concerns
> > > would result in better RT28x00 / RT30x0 support in the very near future.
> >
> > The review concerns regarding the duplicate code would only reduce the
> > amount of code. It would not magically fix bugs (at least the chance of that
> > would be quite small).
>
> Please see my other mail.
And did your patches make rt2800pci work better?
Does rt2800usb suddenly work for 11n networks?
> > So far rt2800usb performs better then rt2800pci, and the difference gets
> > only bigger when I use the exact same register initialization from rt2800usb
> > in rt2800pci.
> >
> > But Bartjmoiej knows that the register initialization can be exactly the same,
> > from his experience with the staging drivers.
> > So far hasn't been interested in sharing the knowledge in what must be
> > changed in rt2800pci/usb to make them both work with the same register
> > initialization.
>
> The knowledge is all in your local copy of linux-next (I don't memorize
> things like chipset initialization sequences) and in the review comments
> that you have happily dismissed.
Your review comments were regarding _moving_ code to a generic stack
for rt2800pci and rt2800usb while I already indicated that would not improve
the status of rt2800pci (instead it would make it worse, since I already tested
if those settings would work). But apparently merging the code is better then
fixing the code.
Ivo
On Tuesday 03 November 2009 21:32:30 Ivo van Doorn wrote:
> > rt2800pci patch itself has been getting dust in your tree since at least
> > April (it hasn't received any bigger updates since then)..
>
> And how many times do I have to repeat the reason?
> I think that after dozens of mails, the message should have been clear, especially
> to somebody who apparently has been monitoring and worrying about the development
> process for the last 2 years....
Just for the record:
I got only interested in rt2x00 support around April this year (while I was
doing major staging cleanups everywhere) and I was hearing back then that
rt2800pci will be merged "really soon" and that the project is making "great
progress"..
--
Bartlomiej Zolnierkiewicz
On Mon, 2 Nov 2009, Pavel Machek wrote:
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
> >
> > So, I will personally continue to ignore Bart's comments, regards and
> > rants, until he provides patches for rt2x00 that actually make the
> > driver better.
>
> Well, he provided review feedback... he should be thanked for that,
> not flamed for it.
He has actually written real patches (and quite non-trivial both in amount
and in functionality), see
http://lkml.org/lkml/2009/11/3/372
But yes, he got flamed for this for some odd reason. I got the impression
that the community around rt2x00 doesn't like (or understand) the way how
opensource development happens.
--
Jiri Kosina
SUSE Labs, Novell Inc.
On Wednesday 04 November 2009, Jiri Kosina wrote:
> On Mon, 2 Nov 2009, Pavel Machek wrote:
>
> > > I've searched on my GMail archives and the only patch Bart has
> > > provided so far for the rt2x00 project is this:
> > >
> > > [PATCH] MAINTAINERS: rt2x00 list is moderated
> > >
> > > Which, while technically correct, adds nothing to the project.
> > >
> > > So, I will personally continue to ignore Bart's comments, regards and
> > > rants, until he provides patches for rt2x00 that actually make the
> > > driver better.
> >
> > Well, he provided review feedback... he should be thanked for that,
> > not flamed for it.
>
> He has actually written real patches (and quite non-trivial both in amount
> and in functionality), see
>
> http://lkml.org/lkml/2009/11/3/372
Please look at the TIMESTAMP of the mail you refer to, and the TIMESTAMP
of the mail from Luis. And then you can make assumptions about the text...
> But yes, he got flamed for this for some odd reason. I got the impression
> that the community around rt2x00 doesn't like (or understand) the way how
> opensource development happens.
Well you mean the open source development where non-contributors
complain that the contributors work too slowly? Well if that is the way
things should go, then I don't want to be part of such idiocy. Perhaps
that is the policy in some companies which try to import it into the
Open Source world...
Ivo
> > But yes, he got flamed for this for some odd reason. I got the impression
> > that the community around rt2x00 doesn't like (or understand) the way how
> > opensource development happens.
>
> Well you mean the open source development where non-contributors
> complain that the contributors work too slowly?
This was the case when non-contributor complained that patch adds
2KLoC of unneccessary code.
> Perhaps
> that is the policy in some companies which try to import it into the
> Open Source world...
Do you really have to attack everyone around?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, Nov 04, 2009 at 11:00:25PM +0100, Pavel Machek wrote:
> > > But yes, he got flamed for this for some odd reason. I got the impression
> > > that the community around rt2x00 doesn't like (or understand) the way how
> > > opensource development happens.
> >
> > Well you mean the open source development where non-contributors
> > complain that the contributors work too slowly?
>
> This was the case when non-contributor complained that patch adds
> 2KLoC of unneccessary code.
>
> > Perhaps
> > that is the policy in some companies which try to import it into the
> > Open Source world...
>
> Do you really have to attack everyone around?
Really, this is enough.
It seems clear that neither side of this debate sees or appreciates
the injuries that the other side claims. In any case, there seems
little good can come from continuing this bickering.
Now that Bart is posting patches and the rt2x00 team is actively
reviewing (and mostly Acking) them, I hope everyone can just BACK
THE HELL OFF and let the process work itself out.
Please let this discussion end.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.