Hi all,
Today's linux-next merge of the wireless-drivers-next tree got a
conflict in:
drivers/net/wireless/intel/iwlwifi/iwl-config.h
between commit:
dd05f9aab4426f ("iwlwifi: pcie: dynamic Tx command queue size")
from the wireless-drivers tree and commit:
44fd09dad5d2b7 ("iwlwifi: nvm: set the correct offsets to 3168 series")
from the wireless-drivers-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/net/wireless/intel/iwlwifi/iwl-config.h
index 71cb1ecde0f7,b9f3b350fe34..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
@@@ -332,7 -320,9 +332,9 @@@ struct iwl_pwr_tx_backoff
* @integrated: discrete or integrated
* @gen2: a000 and on transport operation
* @cdb: CDB support
- * @ext_nvm: extended NVM format
+ * @nvm_type: see &enum iwl_nvm_type
+ * @tx_cmd_queue_size: size of the cmd queue. If zero, use the same value as
+ * the regular queues
*
* We enable the driver to be backward compatible wrt. hardware features.
* API differences in uCode shouldn't be handled here but through TLVs
@@@ -382,7 -371,9 +384,8 @@@ struct iwl_cfg
use_tfh:1,
gen2:1,
cdb:1,
- ext_nvm:1,
dbgc_supported:1;
+ u16 tx_cmd_queue_size;
u8 valid_tx_ant;
u8 valid_rx_ant;
u8 non_shared_ant;
On Thu, 2017-10-12 at 18:25 +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
> drivers/net/wireless/intel/iwlwifi/iwl-config.h
>
> between commit:
>
> dd05f9aab4426f ("iwlwifi: pcie: dynamic Tx command queue size")
>
> from the wireless-drivers tree and commit:
>
> 44fd09dad5d2b7 ("iwlwifi: nvm: set the correct offsets to 3168
> series")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.
>
> diff --cc drivers/net/wireless/intel/iwlwifi/iwl-config.h
> index 71cb1ecde0f7,b9f3b350fe34..000000000000
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
> @@@ -332,7 -320,9 +332,9 @@@ struct iwl_pwr_tx_backoff
> * @integrated: discrete or integrated
> * @gen2: a000 and on transport operation
> * @cdb: CDB support
> - * @ext_nvm: extended NVM format
> + * @nvm_type: see &enum iwl_nvm_type
> + * @tx_cmd_queue_size: size of the cmd queue. If zero, use the same
> value as
> + * the regular queues
> *
> * We enable the driver to be backward compatible wrt. hardware
> features.
> * API differences in uCode shouldn't be handled here but through
> TLVs
> @@@ -382,7 -371,9 +384,8 @@@ struct iwl_cfg
> use_tfh:1,
> gen2:1,
> cdb:1,
> - ext_nvm:1,
nvm_type seems to be missing from here?
> dbgc_supported:1;
> + u16 tx_cmd_queue_size;
> u8 valid_tx_ant;
> u8 valid_rx_ant;
> u8 non_shared_ant;
--
Luca.
On Thu, 2017-10-12 at 19:59 +0100, Mark Brown wrote:
> On Thu, Oct 12, 2017 at 09:50:51PM +0300, Luca Coelho wrote:
> > On Thu, 2017-10-12 at 19:35 +0100, Mark Brown wrote:
> > > With trees like this that don't coordinate with their fixes
> > > branch
> > > there
> > > are frequently multiple conflicts introduced so I generally
> > > report
> > > things file by file without even looking at the new ones.
> > Sorry for the trouble. But how do you suggest that we "coordinate
> > our
> > fixes branch"? Merge fixes into the main tree?
>
> That'd be easiest for me! It's not of necessity a problem if the
> conflicts are easy enough to resolve if you just let things get
> merged
> in -next, it's just more an observation that that's a thing that
> happens
> and that this is how I cope with it. Stephen may do things a bit
> differently.
Cool, I'll discuss this with Kalle and make sure I note these potential
conflicts early enough so everyone is aware when they're coming.
Thanks for taking over while Stephen is away! I really appreciate it,
since linux-next is a very important part of our process. :)
--
Luca.
On Thu, Oct 12, 2017 at 09:50:51PM +0300, Luca Coelho wrote:
> On Thu, 2017-10-12 at 19:35 +0100, Mark Brown wrote:
> > With trees like this that don't coordinate with their fixes branch
> > there
> > are frequently multiple conflicts introduced so I generally report
> > things file by file without even looking at the new ones.
> Sorry for the trouble. But how do you suggest that we "coordinate our
> fixes branch"? Merge fixes into the main tree?
That'd be easiest for me! It's not of necessity a problem if the
conflicts are easy enough to resolve if you just let things get merged
in -next, it's just more an observation that that's a thing that happens
and that this is how I cope with it. Stephen may do things a bit
differently.
On Thu, Oct 12, 2017 at 09:16:36PM +0300, Luciano Coelho wrote:
> This is weird... The previous conflict was the exact opposite of this.
> 44fd09 came in from wireless-drivers and dd05f9 came from wireless-
> drivers-next. I don't understand why it is saying the opposite here...
I may have confused the trees when I was pasting things in, the commits
are filled in by hand.
On Thu, Oct 12, 2017 at 09:27:46PM +0300, Luciano Coelho wrote:
> On Thu, 2017-10-12 at 19:21 +0100, Mark Brown wrote:
> > I may have confused the trees when I was pasting things in, the
> > commits
> > are filled in by hand.
> Ah, okay. But still, if the same patches conflicted twice, why wasn't
> there only one occurrence with both conflicts at once?
With trees like this that don't coordinate with their fixes branch there
are frequently multiple conflicts introduced so I generally report
things file by file without even looking at the new ones.
On Thu, 2017-10-12 at 19:21 +0100, Mark Brown wrote:
> On Thu, Oct 12, 2017 at 09:16:36PM +0300, Luciano Coelho wrote:
>
> > This is weird... The previous conflict was the exact opposite of
> > this.
> > 44fd09 came in from wireless-drivers and dd05f9 came from wireless-
> > drivers-next. I don't understand why it is saying the opposite
> > here...
>
> I may have confused the trees when I was pasting things in, the
> commits
> are filled in by hand.
Ah, okay. But still, if the same patches conflicted twice, why wasn't
there only one occurrence with both conflicts at once?
--
Luca.
On Thu, 2017-10-12 at 18:25 +0100, Mark Brown wrote:
> Hi all,
Hi Mark,
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
> drivers/net/wireless/intel/iwlwifi/iwl-config.h
>
> between commit:
>
> dd05f9aab4426f ("iwlwifi: pcie: dynamic Tx command queue size")
>
> from the wireless-drivers tree and commit:
>
> 44fd09dad5d2b7 ("iwlwifi: nvm: set the correct offsets to 3168
> series")
>
> from the wireless-drivers-next tree.
This is weird... The previous conflict was the exact opposite of this.
44fd09 came in from wireless-drivers and dd05f9 came from wireless-
drivers-next. I don't understand why it is saying the opposite here...
--
Cheers,
Luca.
On Thu, Oct 12, 2017 at 09:29:39PM +0300, Luca Coelho wrote:
> On Thu, 2017-10-12 at 18:25 +0100, Mark Brown wrote:
> > @@@ -382,7 -371,9 +384,8 @@@ struct iwl_cfg
> > use_tfh:1,
> > gen2:1,
> > cdb:1,
> > - ext_nvm:1,
> nvm_type seems to be missing from here?
Oh bother. Either my error or git's... but it does seem to be
building so I'm a bit confused about what's going on there.
On Thu, 2017-10-12 at 19:35 +0100, Mark Brown wrote:
> On Thu, Oct 12, 2017 at 09:27:46PM +0300, Luciano Coelho wrote:
> > On Thu, 2017-10-12 at 19:21 +0100, Mark Brown wrote:
> > > I may have confused the trees when I was pasting things in, the
> > > commits
> > > are filled in by hand.
> >
> > Ah, okay. But still, if the same patches conflicted twice, why
> > wasn't
> > there only one occurrence with both conflicts at once?
>
> With trees like this that don't coordinate with their fixes branch
> there
> are frequently multiple conflicts introduced so I generally report
> things file by file without even looking at the new ones.
Sorry for the trouble. But how do you suggest that we "coordinate our
fixes branch"? Merge fixes into the main tree?
--
Luca.