+ wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

+ wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

[akpm]

The patch titled
     wireless: fix "iwlwifi: unify init driver flow"
has been added to the -mm tree.  Its filename is
     wireless-fix-iwlwifi-unify-init-driver-flow.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: wireless: fix "iwlwifi: unify init driver flow"
From: Andrew Morton <akpm@linux-foundation.org>

drivers/net/wireless/iwlwifi/iwl-core.c: In function 'iwlcore_init_geos':
drivers/net/wireless/iwlwifi/iwl-core.c:323: error: implicit declaration of function 'iwlcore_init_ht_hw_capab'

This (or something like it) should be folded into the base patch to avoid
breaking bisection, please.

Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/net/wireless/iwlwifi/iwl-core.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff -puN drivers/net/wireless/iwlwifi/iwl-core.c~wireless-fix-iwlwifi-unify-init-driver-flow drivers/net/wireless/iwlwifi/iwl-core.c
--- a/drivers/net/wireless/iwlwifi/iwl-core.c~wireless-fix-iwlwifi-unify-init-driver-flow
+++ a/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -259,6 +259,12 @@ static void iwlcore_init_ht_hw_capab(con
 	if (priv->hw_params.tx_chains_num >= 3)
 		ht_info->supp_mcs_set[2] = 0xFF;
 }
+#else
+static inline void iwlcore_init_ht_hw_capab(const struct iwl_priv *priv,
+			      struct ieee80211_ht_info *ht_info,
+			      enum ieee80211_band band)
+{
+}
 #endif /* CONFIG_IWL4965_HT */
 
 static void iwlcore_init_hw_rates(struct iwl_priv *priv,
_

Patches currently in -mm which might be from akpm@linux-foundation.org are

origin.patch
linux-next.patch
linux-next-git-rejects.patch
next-remove-localversion.patch
revert-9p-convert-from-semaphore-to-spinlock.patch
ia64-kvm-dont-delete-files-which-we-need.patch
revert-acpica-fixes-for-unload-and-ddbhandles.patch
acpi-enable-c3-power-state-on-dell-inspiron-8200.patch
acpi-video-balcklist-fujitsu-lifebook-s6410.patch
git-x86-fixup.patch
arch-x86-mm-patc-use-boot_cpu_has.patch
x86-setup_force_cpu_cap-dont-do-clear_bitnon-unsigned-long.patch
lguest-use-cpu-capability-accessors.patch
x86-set_restore_sigmask-avoid-bitop-on-a-u32.patch
x86-early_init_centaur-use-set_cpu_cap.patch
x86-bitops-take-an-unsigned-long.patch
arm-omap1-n770-convert-audio_pwr_sem-in-a-mutex-fix.patch
audit_send_reply-fix-error-path-memory-leak.patch
cifs-suppress-warning.patch
sysfs-provide-a-clue-about-the-effects-of-config_usb_device_class=y.patch
zoran-use-correct-type-for-cpu-flags.patch
i2c-renesas-highlander-fpga-smbus-support.patch
ibmaem-new-driver-for-power-energy-temp-meters-in-ibm-system-x-hardware-ia64-warnings.patch
drivers-infiniband-hw-mlx4-qpc-fix-uninitialised-var-warning.patch
git-input.patch
git-jg-misc-git-rejects.patch
drivers-scsi-broadsasc-fix-uninitialised-var-warning.patch
git-mmc.patch
mmc-sd-host-driver-for-ricoh-bay1controllers-fix.patch
mmc-sd-host-driver-for-ricoh-bay1controllers-fix-2.patch
git-ubifs.patch
git-net.patch
git-net-git-rejects.patch
hysdn-no-longer-broken-on-smp.patch
sundance-set-carrier-status-on-link-change-events.patch
dm9000-use-delayed-work-to-update-mii-phy-state-fix.patch
pcnet32-fix-warning.patch
drivers-net-tokenring-3c359c-squish-a-warning.patch
drivers-net-tokenring-olympicc-fix-warning.patch
update-smc91x-driver-with-arm-versatile-board-info.patch
git-battery.patch
fs-nfs-callback_xdrc-suppress-uninitialiized-variable-warnings.patch
arch-parisc-kernel-unalignedc-use-time_-macros.patch
selinux-dopey-hack.patch
pci-hotplug-introduce-pci_slot.patch
pci-hotplug-acpi-pci-slot-detection-driver.patch
drivers-scsi-qla2xxx-qla_osc-suppress-uninitialized-var-warning.patch
revert-git-block.patch
s390-uninline-spinlock-functions-which-use-smp_processor_id.patch
git-unionfs.patch
git-unionfs-fixup.patch
unionfs-broke.patch
git-logfs-fixup.patch
drivers-uwb-nehc-processor-flags-have-type-unsigned-long.patch
drivers-usb-host-isp1760-hcdc-procesxor-flags-have-type-unsigned-long.patch
uwb-fix-scscanf-warning.patch
drivers-uwb-wlp-sysfsc-dead-code.patch
drivers-uwb-i1480-dfu-macc-fix-min-warning.patch
drivers-uwb-i1480-dfu-usbc-fix-size_t-confusion.patch
drivers-uwb-whcic-needs-dma-mappingh.patch
rndis-switch-to-seq_files-checkpatch-fixes.patch
git-v9fs.patch
revert-git-v9fs.patch
git-watchdog.patch
git-watchdog-git-rejects.patch
watchdog-fix-booke_wdtc-on-mpc85xx-smp-system.patch
xfs-suppress-uninitialized-var-warnings.patch
git-xtensa.patch
git-orion-git-rejects.patch
ext4-is-busted-on-m68k.patch
common-implementation-of-iterative-div-mod-fix.patch
common-implementation-of-iterative-div-mod-checkpatch-fixes.patch
common-implementation-of-iterative-div-mod-fix-2.patch
mprotect-prevent-alteration-of-the-pat-bits-checkpatch-fixes.patch
scsi-dpt_i2o-is-bust-on-ia64.patch
tty_check_change-avoid-taking-tasklist_lock-while-holding-tty-ctrl_lock.patch
colibri-fix-support-for-dm9000-ethernet-device-fix.patch
mm-verify-the-page-links-and-memory-model.patch
mspec-convert-nopfn-to-fault-fix.patch
page-allocator-inlnie-some-__alloc_pages-wrappers-fix.patch
kill-generic_file_direct_io-checkpatch-fixes.patch
vmscan-give-referenced-active-and-unmapped-pages-a-second-trip-around-the-lru.patch
vm-dont-run-touch_buffer-during-buffercache-lookups.patch
split-the-typecheck-macros-out-of-include-linux-kernelh.patch
locking-add-typecheck-on-irqsave-and-friends-for-correct-flags.patch
locking-add-typecheck-on-irqsave-and-friends-for-correct-flags-fix.patch
remove-apparently-unused-fd1772h-header-file.patch
lib-allow-memparse-to-accept-a-null-and-ignorable-second-parm-checkpatch-fixes.patch
rename-warn-to-warning-to-clear-the-namespace-fix.patch
add-a-warn-macro-this-is-warn_on-printk-arguments-fix.patch
flag-parameters-paccept-fix.patch
flag-parameters-paccept-sys_ni.patch
flag-parameters-anon_inode_getfd-extension-fix.patch
flag-parameters-inotify_init-fix.patch
flag-parameters-check-magic-constants-alpha-hack.patch
drivers-video-aty-radeon_basec-notify-user-if-sysfs_create_bin_file-failed-checkpatch-fixes.patch
reiserfs-convert-j_commit_lock-to-mutex-checkpatch-fixes.patch
documentation-build-source-files-in-documentation-sub-dir-disable.patch
ppc-use-the-common-ascii-hex-helpers-fix.patch
reiser4.patch
reiser4-semaphore-fix.patch
page-owner-tracking-leak-detector.patch
nr_blockdev_pages-in_interrupt-warning.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
shrink_slab-handle-bad-shrinkers.patch
getblk-handle-2tb-devices.patch
getblk-handle-2tb-devices-fix.patch
undeprecate-pci_find_device.patch
notify_change-callers-must-hold-i_mutex.patch
profile-likely-unlikely-macros.patch
drivers-net-bonding-bond_sysfsc-suppress-uninitialized-var-warning.patch
w1-build-fix.patch
wireless-fix-iwlwifi-unify-init-driver-flow.patch

Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

[David Miller]

From: akpm@linux-foundation.org
Date: Tue, 13 May 2008 21:05:50 -0700

> Subject: wireless: fix "iwlwifi: unify init driver flow"
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> drivers/net/wireless/iwlwifi/iwl-core.c: In function 'iwlcore_init_geos':
> drivers/net/wireless/iwlwifi/iwl-core.c:323: error: implicit declaration of function 'iwlcore_init_ht_hw_capab'
> 
> This (or something like it) should be folded into the base patch to avoid
> breaking bisection, please.
> 
> Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
> Cc: Tomas Winkler <tomas.winkler@intel.com>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Andrew, you have to figure out what we're supposed to do here.

If I "fold in the patch" to avoid breaking bisection, I have to
completely rebase my tree screwing up everyone of my downstream
developers.

Or is this some patch I'm supposed to remember to fold in several
months from now, to some random changeset out of thousands, when the
merge window opens?

Neither option is tenable, and the headaches of neither are
worth it purely for the sake of bisection.

My solution to the bisection problem is to wait a day before pushing
out usually, it's a best effort thing.  I do as many sanity builds as
I can, and we also hope that someone during that day might solve the
problem independantly and post a fix.  That way I can fix it in my
tree locally before the tree goes public.

And I think this is the most reasonable approach.

Once I push something to my public tree, quite frankly, it's the real
deal, it's staying there, and it's a part of the permanent record.
And therefore, we'll put fixes on top.

Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

[Andrew Morton]

On Tue, 13 May 2008 21:39:27 -0700 (PDT) David Miller <davem@davemloft.net> wrote:

> From: akpm@linux-foundation.org
> Date: Tue, 13 May 2008 21:05:50 -0700
> 
> > Subject: wireless: fix "iwlwifi: unify init driver flow"
> > From: Andrew Morton <akpm@linux-foundation.org>
> > 
> > drivers/net/wireless/iwlwifi/iwl-core.c: In function 'iwlcore_init_geos':
> > drivers/net/wireless/iwlwifi/iwl-core.c:323: error: implicit declaration of function 'iwlcore_init_ht_hw_capab'
> > 
> > This (or something like it) should be folded into the base patch to avoid
> > breaking bisection, please.
> > 
> > Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
> > Cc: Tomas Winkler <tomas.winkler@intel.com>
> > Cc: John W. Linville <linville@tuxdriver.com>
> > Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> 
> Andrew, you have to figure out what we're supposed to do here.

Well someone does ;)

> If I "fold in the patch" to avoid breaking bisection, I have to
> completely rebase my tree screwing up everyone of my downstream
> developers.
> 
> Or is this some patch I'm supposed to remember to fold in several
> months from now, to some random changeset out of thousands, when the
> merge window opens?
> 
> Neither option is tenable, and the headaches of neither are
> worth it purely for the sake of bisection.
> 
> My solution to the bisection problem is to wait a day before pushing
> out usually, it's a best effort thing.  I do as many sanity builds as
> I can, and we also hope that someone during that day might solve the
> problem independantly and post a fix.  That way I can fix it in my
> tree locally before the tree goes public.
> 
> And I think this is the most reasonable approach.
> 
> Once I push something to my public tree, quite frankly, it's the real
> deal, it's staying there, and it's a part of the permanent record.
> And therefore, we'll put fixes on top.

What goes into Linus's tree is there for ever and I do think that all
the short-term things we do should be built around making the permanent
record as good as possible.

This is a(nother) case where a toolchain/process problem is forcing us
to do something which we don't want to do.  In an ideal world we should
tell the git developers "we want x, please" and hopefully they can give
it to us.  Because right now, we're having to work around shortcomings
in git and we are producing a lesser product as a result of this.  A tool
should follow the way in which humans want to work, not vice versa.

Short-term...  dunno.  Perhaps you could have a two-weekly
broadly-announced rebase in which you integrate all these dribs and
drags back into their proper place?  Commit them with some well-known
identifier in the title so that they can all be located when that time
comes?

If you announce such a rebase a day or so beforehand then all the guys
who feed into you could get their stuff merged up into your tree to
minimise their pain when the rebase happens, perhaps.

(That being said, this particular no-compile isn't a huge problem - it
can be worked around with a Kconfig change.  But that isn't generally
the case)

Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

[David Miller]

From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 13 May 2008 21:57:37 -0700

> This is a(nother) case where a toolchain/process problem is forcing us
> to do something which we don't want to do.  In an ideal world we should
> tell the git developers "we want x, please" and hopefully they can give
> it to us.  Because right now, we're having to work around shortcomings
> in git and we are producing a lesser product as a result of this.  A tool
> should follow the way in which humans want to work, not vice versa.

This has beaten like a dead horse a thousand times.  Bringing
it up again isn't likely to cause further progress. :)

> Short-term...  dunno.  Perhaps you could have a two-weekly
> broadly-announced rebase in which you integrate all these dribs and
> drags back into their proper place?  Commit them with some well-known
> identifier in the title so that they can all be located when that time
> comes?
> 
> If you announce such a rebase a day or so beforehand then all the guys
> who feed into you could get their stuff merged up into your tree to
> minimise their pain when the rebase happens, perhaps.

This, along with the idea of taking care of all of the "dribs" right
before the real merge, is error prone.

It means I have to play with large collections of patches all at one
time.  The reason I use GIT is because I'm stupid and make mistakes,
therefore I don't like playing with patches.

I used to play this game, it's a lot of work and it sucks.  One
"drib" can require fixing up 200 patches down the chain.  And
I've had this happen to me all the time in the past when I was
rebasing all the time.

Not this specific case, mind you, but it is a real concern in general.

RE: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

[Winkler, Tomas]

>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, May 14, 2008 7:39 AM
>To: linux-kernel@vger.kernel.org; akpm@linux-foundation.org
>Cc: mm-commits@vger.kernel.org; linville@tuxdriver.com; Rindjunsky,
Ron;
>sfr@canb.auug.org.au; Winkler, Tomas
>Subject: Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added
to -
>mm tree
>
>From: akpm@linux-foundation.org
>Date: Tue, 13 May 2008 21:05:50 -0700
>
>> Subject: wireless: fix "iwlwifi: unify init driver flow"
>> From: Andrew Morton <akpm@linux-foundation.org>
>>
>> drivers/net/wireless/iwlwifi/iwl-core.c: In function
'iwlcore_init_geos':
>> drivers/net/wireless/iwlwifi/iwl-core.c:323: error: implicit
declaration
>of function 'iwlcore_init_ht_hw_capab'
>>
>> This (or something like it) should be folded into the base patch to
avoid
>> breaking bisection, please.
>>
>> Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
>> Cc: Tomas Winkler <tomas.winkler@intel.com>
>> Cc: John W. Linville <linville@tuxdriver.com>
>> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
>Andrew, you have to figure out what we're supposed to do here.
>
>If I "fold in the patch" to avoid breaking bisection, I have to
>completely rebase my tree screwing up everyone of my downstream
>developers.
>
>Or is this some patch I'm supposed to remember to fold in several
>months from now, to some random changeset out of thousands, when the
>merge window opens?
>
>Neither option is tenable, and the headaches of neither are
>worth it purely for the sake of bisection.
>
>My solution to the bisection problem is to wait a day before pushing
>out usually, it's a best effort thing.  I do as many sanity builds as
>I can, and we also hope that someone during that day might solve the
>problem independantly and post a fix.  That way I can fix it in my
>tree locally before the tree goes public.
>
>And I think this is the most reasonable approach.
>
>Once I push something to my public tree, quite frankly, it's the real
>deal, it's staying there, and it's a part of the permanent record.
>And therefore, we'll put fixes on top.

A patch that was sent to wireless-dev among others fixes this problem
I guess it's still stack in the Linville's queue.
http://article.gmane.org/gmane.linux.kernel.wireless.general/14339

Sorry for not catching it earlier.

Thanks
Tomas 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

[John W. Linville]

On Tue, May 13, 2008 at 10:15:29PM -0700, David Miller wrote:

> I used to play this game, it's a lot of work and it sucks.  One
> "drib" can require fixing up 200 patches down the chain.  And
> I've had this happen to me all the time in the past when I was
> rebasing all the time.

I have to agree with Dave.

Moreover, I used to get regular complaints about the old "regular
rebase" process.  We switched to a "pull and merge" process for 2.6.25,
and in that period nearly all of the process-related complaints
disappeared for me.

To some degree this is a "pick your poison" issue, and for most people
rebasing seems like the deadlier poison.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree

[Andrew Morton]

On Wed, 14 May 2008 08:34:32 -0400 "John W. Linville" <linville@tuxdriver.com> wrote:

> On Tue, May 13, 2008 at 10:15:29PM -0700, David Miller wrote:
> 
> > I used to play this game, it's a lot of work and it sucks.  One
> > "drib" can require fixing up 200 patches down the chain.  And
> > I've had this happen to me all the time in the past when I was
> > rebasing all the time.
> 
> I have to agree with Dave.
> 
> Moreover, I used to get regular complaints about the old "regular
> rebase" process.  We switched to a "pull and merge" process for 2.6.25,
> and in that period nearly all of the process-related complaints
> disappeared for me.
> 

Well.  Have you ever been an hour and a half into a bisection at 3AM
then hit a massive oops deep in the TCP code which was spread across a
large number of commits?  I have and it wasn't fun.  iirc I gave up and
went to bed.

> To some degree this is a "pick your poison" issue, and for most people
> rebasing seems like the deadlier poison.

Well yes.  We'd like the best of both worlds, only we cannot have it. 
And the sole _reason_ we cannot have it is due to restrictions in git
<stimulate, stimulate>.