linux-next: manual merge of the char-misc tree with Linus' tree

linux-next: manual merge of the char-misc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in
drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
clean the state on power up") from Linus' tree and commit b950ac1dabfc
("mei: don't get stuck in select during reset") from the char-misc tree.

(Unrelated white space changes are a pest :-()

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/misc/mei/init.c
index e6f16f8,557eed2..0000000
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@@ -148,8 -148,8 +148,9 @@@ void mei_reset(struct mei_device *dev, 
  
  	dev->hbm_state = MEI_HBM_IDLE;
  
 -	if (dev->dev_state != MEI_DEV_INITIALIZING) {
 +	if (dev->dev_state != MEI_DEV_INITIALIZING &&
 +	    dev->dev_state != MEI_DEV_POWER_UP) {
+ 
  		if (dev->dev_state != MEI_DEV_DISABLED &&
  		    dev->dev_state != MEI_DEV_POWER_DOWN)
  			dev->dev_state = MEI_DEV_RESETTING;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Greg KH]

On Mon, Jul 29, 2013 at 03:01:29PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the char-misc tree got a conflict in
> drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
> clean the state on power up") from Linus' tree and commit b950ac1dabfc
> ("mei: don't get stuck in select during reset") from the char-misc tree.
> 
> (Unrelated white space changes are a pest :-()
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
merge problem should no longer be there.

greg k-h

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Tomas Winkler]

>> (Unrelated white space changes are a pest :-()
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> merge problem should no longer be there.

 I've preferred the blank line there as these ifs became a bit  dense
nevertheless thanks for taking care of it.

Tomas

PS: sorry for the previous HTML mistake.

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Greg KH]

On Tue, Jul 30, 2013 at 01:16:38AM +0300, Tomas Winkler wrote:
> >> (Unrelated white space changes are a pest :-()
> >>
> >> I fixed it up (see below) and can carry the fix as necessary (no action
> >> is required).
> >
> > Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> > merge problem should no longer be there.
> 
>  I've preferred the blank line there as these ifs became a bit  dense
> nevertheless thanks for taking care of it.

Ah, sorry about that, feel free to change it back in the next round of
patches you send :)

greg k-h

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

Hi Greg,

On Mon, 29 Jul 2013 12:26:49 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Mon, Jul 29, 2013 at 03:01:29PM +1000, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the char-misc tree got a conflict in
> > drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
> > clean the state on power up") from Linus' tree and commit b950ac1dabfc
> > ("mei: don't get stuck in select during reset") from the char-misc tree.
> > 
> > (Unrelated white space changes are a pest :-()
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> 
> Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> merge problem should no longer be there.

Unfortunately, I think this is exactly the sort of back merge that Linus
hates.  He and I are quite capable of coping with relatively complex
merge conflicts, so ones like this are really not a problem (and "git
rerere" takes care of it once I have resolved it the first time).  That
is why I added "no action is required" to my notification messages.
These messages are really more "this is what I did, please tell me if I
did something wrong", not "please fix this up"  (I know this message from
me has changed over time - we can all learn, even us oldies :-))

Also, if you are doing a merge of fixes that you have submitted to
Linus, it is probably better to merge your fixes branch rather that
Linus' tree after he has merged it - that way you are not dragging
irrelevant stuff from Linus' tree into yours and complicating the git
history/bisecting so much.

Of course, if you need something from Linus' tree that someone else put
there to continue development, then you need to back merge Linus' tree,
but after rc2 or 3 that should be rare.  And, of course, such a back
merge needs a good changelog explaining exactly why it was done.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Greg KH]

On Tue, Jul 30, 2013 at 10:27:54AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 29 Jul 2013 12:26:49 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > On Mon, Jul 29, 2013 at 03:01:29PM +1000, Stephen Rothwell wrote:
> > > 
> > > Today's linux-next merge of the char-misc tree got a conflict in
> > > drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
> > > clean the state on power up") from Linus' tree and commit b950ac1dabfc
> > > ("mei: don't get stuck in select during reset") from the char-misc tree.
> > > 
> > > (Unrelated white space changes are a pest :-()
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> > 
> > Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> > merge problem should no longer be there.
> 
> Unfortunately, I think this is exactly the sort of back merge that Linus
> hates.  He and I are quite capable of coping with relatively complex
> merge conflicts, so ones like this are really not a problem (and "git
> rerere" takes care of it once I have resolved it the first time).  That
> is why I added "no action is required" to my notification messages.
> These messages are really more "this is what I did, please tell me if I
> did something wrong", not "please fix this up"  (I know this message from
> me has changed over time - we can all learn, even us oldies :-))
> 
> Also, if you are doing a merge of fixes that you have submitted to
> Linus, it is probably better to merge your fixes branch rather that
> Linus' tree after he has merged it - that way you are not dragging
> irrelevant stuff from Linus' tree into yours and complicating the git
> history/bisecting so much.
> 
> Of course, if you need something from Linus' tree that someone else put
> there to continue development, then you need to back merge Linus' tree,
> but after rc2 or 3 that should be rare.  And, of course, such a back
> merge needs a good changelog explaining exactly why it was done.

I usually want those fixes from the rcs and merge at that point in time
every other -rc release or so, just to make it much easier for me to
test with, and to pick in the patches I've sent to Linus.

Yes, I could just suck in my fixes branch, but I would be stuck with
trees based on -rc1, which is almost always a pain to test with.

I'm not doing "merges every week", and have been doing it this way for a
few years now with no complaints.  The -rc point in time is a good place
to sync up with it seems.

thanks,

greg k-h

linux-next: manual merge of the char-misc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  drivers/misc/habanalabs/common/command_submission.c

between commit:

  cea7a0449ea3 ("habanalabs: prevent possible out-of-bounds array access")

from Linus' tree and commit:

  3abc99bb7dcb ("habanalabs: configure maximum queues per asic")

from the char-misc tree.

I fixed it up (I used parts of each that no longer conflict) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the char-misc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3717 bytes --]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  drivers/misc/habanalabs/gaudi/gaudi.c

between commit:

  e38bfd30e088 ("habanalabs: set clock gating per engine")

from Linus' tree and commits:

  0b168c8f1d21 ("habanalabs: remove rate limiters from GAUDI")
  fcc6a4e60678 ("habanalabs: Extract ECC information from FW")

from the char-misc 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/misc/habanalabs/gaudi/gaudi.c
index 637a9d608707,4a1a52608fc0..000000000000
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@@ -1823,9 -1766,7 +1772,7 @@@ static void gaudi_init_golden_registers
  
  	gaudi_init_hbm_cred(hdev);
  
- 	gaudi_init_rate_limiter(hdev);
- 
 -	gaudi_disable_clock_gating(hdev);
 +	hdev->asic_funcs->disable_clock_gating(hdev);
  
  	for (tpc_id = 0, tpc_offset = 0;
  				tpc_id < TPC_NUMBER_OF_ENGINES;
@@@ -5275,41 -5166,50 +5211,50 @@@ static int gaudi_extract_ecc_info(struc
  		hdev->asic_funcs->disable_clock_gating(hdev);
  	}
  
- 	switch (num_mem_regs) {
- 	case 1:
- 		dev_err(hdev->dev,
- 			"%s ECC indication: 0x%08x\n",
- 			block_name, RREG32(block_address));
- 		break;
- 	case 2:
- 		dev_err(hdev->dev,
- 			"%s ECC indication: 0x%08x 0x%08x\n",
- 			block_name,
- 			RREG32(block_address), RREG32(block_address + 4));
- 		break;
- 	case 3:
- 		dev_err(hdev->dev,
- 			"%s ECC indication: 0x%08x 0x%08x 0x%08x\n",
- 			block_name,
- 			RREG32(block_address), RREG32(block_address + 4),
- 			RREG32(block_address + 8));
- 		break;
- 	case 4:
- 		dev_err(hdev->dev,
- 			"%s ECC indication: 0x%08x 0x%08x 0x%08x 0x%08x\n",
- 			block_name,
- 			RREG32(block_address), RREG32(block_address + 4),
- 			RREG32(block_address + 8), RREG32(block_address + 0xc));
- 		break;
- 	default:
- 		break;
+ 	/* Set invalid wrapper index */
+ 	*memory_wrapper_idx = 0xFF;
+ 
+ 	/* Iterate through memory wrappers, a single bit must be set */
+ 	for (i = 0 ; i > num_mem_regs ; i++) {
+ 		err_addr += i * 4;
+ 		err_word = RREG32(err_addr);
+ 		if (err_word) {
+ 			err_bit = __ffs(err_word);
+ 			*memory_wrapper_idx = err_bit + (32 * i);
+ 			break;
+ 		}
+ 	}
  
+ 	if (*memory_wrapper_idx == 0xFF) {
+ 		dev_err(hdev->dev, "ECC error information cannot be found\n");
+ 		rc = -EINVAL;
+ 		goto enable_clk_gate;
  	}
  
- 	if (disable_clock_gating) {
+ 	WREG32(params->block_address + GAUDI_ECC_MEM_SEL_OFFSET,
+ 			*memory_wrapper_idx);
+ 
+ 	*ecc_address =
+ 		RREG32(params->block_address + GAUDI_ECC_ADDRESS_OFFSET);
+ 	*ecc_syndrom =
+ 		RREG32(params->block_address + GAUDI_ECC_SYNDROME_OFFSET);
+ 
+ 	/* Clear error indication */
+ 	reg = RREG32(params->block_address + GAUDI_ECC_MEM_INFO_CLR_OFFSET);
+ 	if (params->derr)
+ 		reg |= FIELD_PREP(GAUDI_ECC_MEM_INFO_CLR_DERR_MASK, 1);
+ 	else
+ 		reg |= FIELD_PREP(GAUDI_ECC_MEM_INFO_CLR_SERR_MASK, 1);
+ 
+ 	WREG32(params->block_address + GAUDI_ECC_MEM_INFO_CLR_OFFSET, reg);
+ 
+ enable_clk_gate:
+ 	if (params->disable_clock_gating) {
 -		hdev->asic_funcs->enable_clock_gating(hdev);
 +		hdev->asic_funcs->set_clock_gating(hdev);
  		mutex_unlock(&gaudi->clk_gate_mutex);
  	}
+ 
+ 	return rc;
  }
  
  static void gaudi_handle_qman_err_generic(struct hl_device *hdev,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the char-misc tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

Hi all,

Today's linux-next merge of the char-misc tree got conflicts in:

  drivers/bus/mhi/core/main.c
  net/qrtr/mhi.c

between commit:

  9ebc2758d0bb ("Revert "net: really fix the build..."")

from the origin tree and commit:

  0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")

from the char-misc tree.

I fixed it up (the commit in Linus' tree is basically a revert of the
char-misc tree, so I effectively reverted the latter) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Greg KH]

On Fri, Aug 27, 2021 at 04:49:04PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the char-misc tree got conflicts in:
> 
>   drivers/bus/mhi/core/main.c
>   net/qrtr/mhi.c
> 
> between commit:
> 
>   9ebc2758d0bb ("Revert "net: really fix the build..."")
> 
> from the origin tree and commit:
> 
>   0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
> 
> from the char-misc tree.
> 
> I fixed it up (the commit in Linus' tree is basically a revert of the
> char-misc tree, so I effectively reverted the latter) 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.

Hm, what should I do in my tree here?

Kalle, what commit should I make in the char-misc tree now to handle
this issue, and make the merge with Linus's tree "simple"?  Or any other
ideas?

thanks,

greg k-h

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Kalle Valo]

Greg KH <greg@kroah.com> writes:

> On Fri, Aug 27, 2021 at 04:49:04PM +1000, Stephen Rothwell wrote:
>> Hi all,
>> 
>> Today's linux-next merge of the char-misc tree got conflicts in:
>> 
>>   drivers/bus/mhi/core/main.c
>>   net/qrtr/mhi.c
>> 
>> between commit:
>> 
>>   9ebc2758d0bb ("Revert "net: really fix the build..."")
>> 
>> from the origin tree and commit:
>> 
>>   0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
>> 
>> from the char-misc tree.
>> 
>> I fixed it up (the commit in Linus' tree is basically a revert of the
>> char-misc tree, so I effectively reverted the latter) 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.
>
> Hm, what should I do in my tree here?
>
> Kalle, what commit should I make in the char-misc tree now to handle
> this issue, and make the merge with Linus's tree "simple"?  Or any other
> ideas?

Good news first, I tested next-20210827 with ath11k (using QCA6390) and
it's working fine. So Stephen solved the conflict correctly, at least
from ath11k point of view. And my suggestion is that Linus should do the
same resolution when merging char-misc-next (after he has merged
net-next).

I'll explain that in detail below. But do note that I'm not familiar
with the MHI subsystem and the MHI folks really should look at this in
detail to make sure no new bugs are introduced! I did the conflict
resolution myself and at least ath11k works after this resolution.

In my test merge I first used Linus' tree as of today as the baseline.
I first merged net-next and it went without conflicts. After that I
merged char-misc-next and got conflicts in two files:

$ git merge char-misc/char-misc-next
Auto-merging net/qrtr/mhi.c
CONFLICT (content): Merge conflict in net/qrtr/mhi.c
Auto-merging include/linux/mhi.h
Auto-merging drivers/bus/mhi/pci_generic.c
Auto-merging drivers/bus/mhi/core/main.c
CONFLICT (content): Merge conflict in drivers/bus/mhi/core/main.c
Auto-merging drivers/bus/mhi/core/internal.h
Auto-merging drivers/bus/fsl-mc/fsl-mc-bus.c
Removing Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt
Removing Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt
Removing Documentation/devicetree/bindings/misc/ge-achc.txt
Removing Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
Recorded preimage for 'drivers/bus/mhi/core/main.c'
Recorded preimage for 'net/qrtr/mhi.c'
Automatic merge failed; fix conflicts and then commit the result.

Luckily the conflicts are simple:

diff --cc drivers/bus/mhi/core/main.c
index fc9196f11cb7,c01ec2fef02c..000000000000
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@@ -1455,6 -1455,9 +1455,12 @@@ int mhi_prepare_channel(struct mhi_cont
        if (ret)
                goto error_pm_state;
  
++<<<<<<< HEAD
++=======
+       if (mhi_chan->dir == DMA_FROM_DEVICE)
+               mhi_chan->pre_alloc = !!(flags & MHI_CH_INBOUND_ALLOC_BUFS);
+ 
++>>>>>>> char-misc/char-misc-next
        /* Pre-allocate buffer for xfer ring */
        if (mhi_chan->pre_alloc) {
                int nr_el = get_nr_avail_ring_elements(mhi_cntrl,
diff --cc net/qrtr/mhi.c
index fa611678af05,c609cb724c25..000000000000
--- a/net/qrtr/mhi.c
+++ b/net/qrtr/mhi.c
@@@ -79,7 -84,7 +79,11 @@@ static int qcom_mhi_qrtr_probe(struct m
        int rc;
  
        /* start channels */
++<<<<<<< HEAD
 +      rc = mhi_prepare_for_transfer(mhi_dev);
++=======
+       rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
++>>>>>>> char-misc/char-misc-next
        if (rc)
                return rc;

In both cases just take the first hunk from HEAD and remove the second
hunk from char-misc-next. After the conflict resolution 'git diff'
should show:

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 88dba230f406..b15c5bc37dd4 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1455,9 +1455,6 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
        if (ret)
                goto error_pm_state;
 
-       if (mhi_chan->dir == DMA_FROM_DEVICE)
-               mhi_chan->pre_alloc = !!(flags & MHI_CH_INBOUND_ALLOC_BUFS);
-
        /* Pre-allocate buffer for xfer ring */
        if (mhi_chan->pre_alloc) {
                int nr_el = get_nr_avail_ring_elements(mhi_cntrl,

Greg, does this help? Stephen, do you have any advice how to handle
this?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Manivannan Sadhasivam]

Hi Kalle, Stephen,

On Fri, Aug 27, 2021 at 07:24:49PM +0300, Kalle Valo wrote:
> Greg KH <greg@kroah.com> writes:
> 

[...]

> I'll explain that in detail below. But do note that I'm not familiar
> with the MHI subsystem and the MHI folks really should look at this in
> detail to make sure no new bugs are introduced! I did the conflict
> resolution myself and at least ath11k works after this resolution.
> 

I wanted to fix this thing before breaking for vacation but ended up responding
to it in the middle.

> In my test merge I first used Linus' tree as of today as the baseline.
> I first merged net-next and it went without conflicts. After that I
> merged char-misc-next and got conflicts in two files:
> 

[...]

> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 88dba230f406..b15c5bc37dd4 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1455,9 +1455,6 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
>         if (ret)
>                 goto error_pm_state;
>  
> -       if (mhi_chan->dir == DMA_FROM_DEVICE)
> -               mhi_chan->pre_alloc = !!(flags & MHI_CH_INBOUND_ALLOC_BUFS);
> -
>         /* Pre-allocate buffer for xfer ring */
>         if (mhi_chan->pre_alloc) {
>                 int nr_el = get_nr_avail_ring_elements(mhi_cntrl,
> 
> Greg, does this help? Stephen, do you have any advice how to handle
> this?
> 

Sorry, this fix won't work. I've done the conflict resolution in
mhi-conflict-fix [1] branch for reference.

The MHI diffs are below:

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index fc9196f11cb7d..c01ec2fef02ce 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -193,7 +193,7 @@ int mhi_map_single_no_bb(struct mhi_controller *mhi_cntrl,
 int mhi_map_single_use_bb(struct mhi_controller *mhi_cntrl,
 			  struct mhi_buf_info *buf_info)
 {
-	void *buf = mhi_alloc_coherent(mhi_cntrl, buf_info->len,
+	void *buf = dma_alloc_coherent(mhi_cntrl->cntrl_dev, buf_info->len,
 				       &buf_info->p_addr, GFP_ATOMIC);
 
 	if (!buf)
@@ -220,8 +220,8 @@ void mhi_unmap_single_use_bb(struct mhi_controller *mhi_cntrl,
 	if (buf_info->dir == DMA_FROM_DEVICE)
 		memcpy(buf_info->v_addr, buf_info->bb_addr, buf_info->len);
 
-	mhi_free_coherent(mhi_cntrl, buf_info->len, buf_info->bb_addr,
-			  buf_info->p_addr);
+	dma_free_coherent(mhi_cntrl->cntrl_dev, buf_info->len,
+			  buf_info->bb_addr, buf_info->p_addr);
 }
 
 static int get_nr_avail_ring_elements(struct mhi_controller *mhi_cntrl,
@@ -1430,7 +1430,7 @@ exit_unprepare_channel:
 }
 
 int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
-			struct mhi_chan *mhi_chan)
+			struct mhi_chan *mhi_chan, unsigned int flags)
 {
 	int ret = 0;
 	struct device *dev = &mhi_chan->mhi_dev->dev;
@@ -1455,6 +1455,9 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
 	if (ret)
 		goto error_pm_state;
 
+	if (mhi_chan->dir == DMA_FROM_DEVICE)
+		mhi_chan->pre_alloc = !!(flags & MHI_CH_INBOUND_ALLOC_BUFS);
+
 	/* Pre-allocate buffer for xfer ring */
 	if (mhi_chan->pre_alloc) {
 		int nr_el = get_nr_avail_ring_elements(mhi_cntrl,
@@ -1610,7 +1613,7 @@ void mhi_reset_chan(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan)
 }
 
 /* Move channel to start state */
-int mhi_prepare_for_transfer(struct mhi_device *mhi_dev)
+int mhi_prepare_for_transfer(struct mhi_device *mhi_dev, unsigned int flags)
 {
 	int ret, dir;
 	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
@@ -1621,7 +1624,7 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev)
 		if (!mhi_chan)
 			continue;
 
-		ret = mhi_prepare_channel(mhi_cntrl, mhi_chan);
+		ret = mhi_prepare_channel(mhi_cntrl, mhi_chan, flags);
 		if (ret)
 			goto error_open_chan;
 	}


diff --git a/net/qrtr/mhi.c b/net/qrtr/mhi.c
index fa611678af052..29b4fa3b72abf 100644
--- a/net/qrtr/mhi.c
+++ b/net/qrtr/mhi.c
@@ -79,7 +79,7 @@ static int qcom_mhi_qrtr_probe(struct mhi_device *mhi_dev,
 	int rc;
 
 	/* start channels */
-	rc = mhi_prepare_for_transfer(mhi_dev);
+	rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
 	if (rc)
 		return rc;

But this can be avoided if the below commit is reverted in char-misc-next:

0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")

I won't have any objection to that (the original patch can land in v5.16) and
if Greg prefers that, I can send a quick revert patch.

Please let me know!

NOTE: I haven't tested these two solutions as I'm still on vacation. Kalle,
could you please test them to make sure I haven't missed anything?

Thanks,
Mani

[1] https://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git/log/?h=mhi-conflict-fix

> -- 
> https://patchwork.kernel.org/project/linux-wireless/list/
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Manivannan Sadhasivam]

Hi Greg,

On Fri, Aug 27, 2021 at 03:12:02PM +0200, Greg KH wrote:
> On Fri, Aug 27, 2021 at 04:49:04PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the char-misc tree got conflicts in:
> > 
> >   drivers/bus/mhi/core/main.c
> >   net/qrtr/mhi.c
> > 
> > between commit:
> > 
> >   9ebc2758d0bb ("Revert "net: really fix the build..."")
> > 
> > from the origin tree and commit:
> > 
> >   0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
> > 
> > from the char-misc tree.
> > 
> > I fixed it up (the commit in Linus' tree is basically a revert of the
> > char-misc tree, so I effectively reverted the latter) 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.
> 
> Hm, what should I do in my tree here?
> 
> Kalle, what commit should I make in the char-misc tree now to handle
> this issue, and make the merge with Linus's tree "simple"?  Or any other
> ideas?
> 

For making the merge simpler, I'd suggest we revert below commit in char-misc:

0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")

Thanks,
Mani

> thanks,
> 
> greg k-h

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Greg KH]

On Fri, Aug 27, 2021 at 11:28:52PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
> 
> On Fri, Aug 27, 2021 at 03:12:02PM +0200, Greg KH wrote:
> > On Fri, Aug 27, 2021 at 04:49:04PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the char-misc tree got conflicts in:
> > > 
> > >   drivers/bus/mhi/core/main.c
> > >   net/qrtr/mhi.c
> > > 
> > > between commit:
> > > 
> > >   9ebc2758d0bb ("Revert "net: really fix the build..."")
> > > 
> > > from the origin tree and commit:
> > > 
> > >   0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
> > > 
> > > from the char-misc tree.
> > > 
> > > I fixed it up (the commit in Linus' tree is basically a revert of the
> > > char-misc tree, so I effectively reverted the latter) 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.
> > 
> > Hm, what should I do in my tree here?
> > 
> > Kalle, what commit should I make in the char-misc tree now to handle
> > this issue, and make the merge with Linus's tree "simple"?  Or any other
> > ideas?
> > 
> 
> For making the merge simpler, I'd suggest we revert below commit in char-misc:
> 
> 0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")

Reverting that works for me, I've done that in my tree and that allows
it to be merged cleanly with Linus's tree.

thanks,

greg k-h

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Kalle Valo]

Greg KH <greg@kroah.com> writes:

> On Fri, Aug 27, 2021 at 11:28:52PM +0530, Manivannan Sadhasivam wrote:
>> Hi Greg,
>> 
>> On Fri, Aug 27, 2021 at 03:12:02PM +0200, Greg KH wrote:
>> > On Fri, Aug 27, 2021 at 04:49:04PM +1000, Stephen Rothwell wrote:
>> > > Hi all,
>> > > 
>> > > Today's linux-next merge of the char-misc tree got conflicts in:
>> > > 
>> > >   drivers/bus/mhi/core/main.c
>> > >   net/qrtr/mhi.c
>> > > 
>> > > between commit:
>> > > 
>> > >   9ebc2758d0bb ("Revert "net: really fix the build..."")
>> > > 
>> > > from the origin tree and commit:
>> > > 
>> > >   0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
>> > > 
>> > > from the char-misc tree.
>> > > 
>> > > I fixed it up (the commit in Linus' tree is basically a revert of the
>> > > char-misc tree, so I effectively reverted the latter) 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.
>> > 
>> > Hm, what should I do in my tree here?
>> > 
>> > Kalle, what commit should I make in the char-misc tree now to handle
>> > this issue, and make the merge with Linus's tree "simple"?  Or any other
>> > ideas?
>> > 
>> 
>> For making the merge simpler, I'd suggest we revert below commit in char-misc:
>> 
>> 0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
>
> Reverting that works for me, I've done that in my tree and that allows
> it to be merged cleanly with Linus's tree.

Unfortunately this now breaks the build in char-misc-next (commit
0dc3ad3f859d):

net/qrtr/mhi.c: In function 'qcom_mhi_qrtr_probe':
net/qrtr/mhi.c:105:48: error: 'MHI_CH_INBOUND_ALLOC_BUFS' undeclared (first use in this function)
  105 |         rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
      |                                                ^~~~~~~~~~~~~~~~~~~~~~~~~
net/qrtr/mhi.c:105:48: note: each undeclared identifier is reported only once for each function it appears in
net/qrtr/mhi.c:105:14: error: too many arguments to function 'mhi_prepare_for_transfer'
  105 |         rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
      |              ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from net/qrtr/mhi.c:6:
./include/linux/mhi.h:725:5: note: declared here
  725 | int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~

To see this error make sure CONFIG_QRTR and CONFIG_QRTR_MHI are enabled.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Greg KH]

On Sat, Aug 28, 2021 at 10:27:27AM +0300, Kalle Valo wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > On Fri, Aug 27, 2021 at 11:28:52PM +0530, Manivannan Sadhasivam wrote:
> >> Hi Greg,
> >> 
> >> On Fri, Aug 27, 2021 at 03:12:02PM +0200, Greg KH wrote:
> >> > On Fri, Aug 27, 2021 at 04:49:04PM +1000, Stephen Rothwell wrote:
> >> > > Hi all,
> >> > > 
> >> > > Today's linux-next merge of the char-misc tree got conflicts in:
> >> > > 
> >> > >   drivers/bus/mhi/core/main.c
> >> > >   net/qrtr/mhi.c
> >> > > 
> >> > > between commit:
> >> > > 
> >> > >   9ebc2758d0bb ("Revert "net: really fix the build..."")
> >> > > 
> >> > > from the origin tree and commit:
> >> > > 
> >> > >   0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
> >> > > 
> >> > > from the char-misc tree.
> >> > > 
> >> > > I fixed it up (the commit in Linus' tree is basically a revert of the
> >> > > char-misc tree, so I effectively reverted the latter) 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.
> >> > 
> >> > Hm, what should I do in my tree here?
> >> > 
> >> > Kalle, what commit should I make in the char-misc tree now to handle
> >> > this issue, and make the merge with Linus's tree "simple"?  Or any other
> >> > ideas?
> >> > 
> >> 
> >> For making the merge simpler, I'd suggest we revert below commit in char-misc:
> >> 
> >> 0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
> >
> > Reverting that works for me, I've done that in my tree and that allows
> > it to be merged cleanly with Linus's tree.
> 
> Unfortunately this now breaks the build in char-misc-next (commit
> 0dc3ad3f859d):
> 
> net/qrtr/mhi.c: In function 'qcom_mhi_qrtr_probe':
> net/qrtr/mhi.c:105:48: error: 'MHI_CH_INBOUND_ALLOC_BUFS' undeclared (first use in this function)
>   105 |         rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
>       |                                                ^~~~~~~~~~~~~~~~~~~~~~~~~
> net/qrtr/mhi.c:105:48: note: each undeclared identifier is reported only once for each function it appears in
> net/qrtr/mhi.c:105:14: error: too many arguments to function 'mhi_prepare_for_transfer'
>   105 |         rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from net/qrtr/mhi.c:6:
> ./include/linux/mhi.h:725:5: note: declared here
>   725 | int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);
>       |     ^~~~~~~~~~~~~~~~~~~~~~~~
> 
> To see this error make sure CONFIG_QRTR and CONFIG_QRTR_MHI are enabled.

Ugh.  Ok, I think I need to now just revert all of the mhi changes in my
tree to get to a "clean state".  Then you all can work this out after
5.15-rc1 is released.

thanks,

greg k-h

Re: linux-next: manual merge of the char-misc tree with Linus' tree

[Manivannan Sadhasivam]

Hi Kalle, 

On 28 August 2021 12:57:27 PM IST, Kalle Valo <kvalo@codeaurora.org> wrote:
>Greg KH <greg@kroah.com> writes:
>
>> On Fri, Aug 27, 2021 at 11:28:52PM +0530, Manivannan Sadhasivam wrote:
>>> Hi Greg,
>>> 
>>> On Fri, Aug 27, 2021 at 03:12:02PM +0200, Greg KH wrote:
>>> > On Fri, Aug 27, 2021 at 04:49:04PM +1000, Stephen Rothwell wrote:
>>> > > Hi all,
>>> > > 
>>> > > Today's linux-next merge of the char-misc tree got conflicts in:
>>> > > 
>>> > >   drivers/bus/mhi/core/main.c
>>> > >   net/qrtr/mhi.c
>>> > > 
>>> > > between commit:
>>> > > 
>>> > >   9ebc2758d0bb ("Revert "net: really fix the build..."")
>>> > > 
>>> > > from the origin tree and commit:
>>> > > 
>>> > >   0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
>>> > > 
>>> > > from the char-misc tree.
>>> > > 
>>> > > I fixed it up (the commit in Linus' tree is basically a revert of the
>>> > > char-misc tree, so I effectively reverted the latter) 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.
>>> > 
>>> > Hm, what should I do in my tree here?
>>> > 
>>> > Kalle, what commit should I make in the char-misc tree now to handle
>>> > this issue, and make the merge with Linus's tree "simple"?  Or any other
>>> > ideas?
>>> > 
>>> 
>>> For making the merge simpler, I'd suggest we revert below commit in char-misc:
>>> 
>>> 0092a1e3f763 ("bus: mhi: Add inbound buffers allocation flag")
>>
>> Reverting that works for me, I've done that in my tree and that allows
>> it to be merged cleanly with Linus's tree.
>
>Unfortunately this now breaks the build in char-misc-next (commit
>0dc3ad3f859d):
>

You need to revert ce78ffa3ef16 and that's already done in net-next. So once current net-next and char-misc-next reaches linus tree everything should be fine. 

I forgot to mention that the testing should be done with both char-misc-next and net-next or in linux-next. 

Is it mandatory to make it work with char-misc alone? In usual case I know it is mandatory but I thought with current situation it should be fine. 

Thanks, 
Mani

>net/qrtr/mhi.c: In function 'qcom_mhi_qrtr_probe':
>net/qrtr/mhi.c:105:48: error: 'MHI_CH_INBOUND_ALLOC_BUFS' undeclared (first use in this function)
>  105 |         rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
>      |                                                ^~~~~~~~~~~~~~~~~~~~~~~~~
>net/qrtr/mhi.c:105:48: note: each undeclared identifier is reported only once for each function it appears in
>net/qrtr/mhi.c:105:14: error: too many arguments to function 'mhi_prepare_for_transfer'
>  105 |         rc = mhi_prepare_for_transfer(mhi_dev, MHI_CH_INBOUND_ALLOC_BUFS);
>      |              ^~~~~~~~~~~~~~~~~~~~~~~~
>In file included from net/qrtr/mhi.c:6:
>./include/linux/mhi.h:725:5: note: declared here
>  725 | int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);
>      |     ^~~~~~~~~~~~~~~~~~~~~~~~
>
>To see this error make sure CONFIG_QRTR and CONFIG_QRTR_MHI are enabled.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.