linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the sparc-next tree with the dma-mapping tree
@ 2018-12-11 22:30 Stephen Rothwell
  2018-12-12  7:44 ` Christoph Hellwig
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Rothwell @ 2018-12-11 22:30 UTC (permalink / raw)
  To: David Miller, Christoph Hellwig
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Rob Herring

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

Hi all,

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

  arch/sparc/kernel/ioport.c

between commit:

  53b7670e5735 ("sparc: factor the dma coherent mapping into helper")

from the dma-mapping tree and commit:

  86ef771ed543 ("sparc: Use DT node full_name instead of name for resources")

from the sparc-next tree.

I fixed it up (see below - the resolution looks more complex than it
is) 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 arch/sparc/kernel/ioport.c
index 51c128d80193,aeaad04fdd14..000000000000
--- a/arch/sparc/kernel/ioport.c
+++ b/arch/sparc/kernel/ioport.c
@@@ -245,46 -247,97 +245,46 @@@ static void _sparc_free_io(struct resou
  	release_resource(res);
  }
  
 -#ifdef CONFIG_SBUS
 -
 -void sbus_set_sbus64(struct device *dev, int x)
 -{
 -	printk("sbus_set_sbus64: unsupported\n");
 -}
 -EXPORT_SYMBOL(sbus_set_sbus64);
 -
 -/*
 - * Allocate a chunk of memory suitable for DMA.
 - * Typically devices use them for control blocks.
 - * CPU may access them without any explicit flushing.
 - */
 -static void *sbus_alloc_coherent(struct device *dev, size_t len,
 -				 dma_addr_t *dma_addrp, gfp_t gfp,
 -				 unsigned long attrs)
 +unsigned long sparc_dma_alloc_resource(struct device *dev, size_t len)
  {
 -	struct platform_device *op = to_platform_device(dev);
 -	unsigned long len_total = PAGE_ALIGN(len);
 -	unsigned long va;
  	struct resource *res;
 -	int order;
 -
 -	/* XXX why are some lengths signed, others unsigned? */
 -	if (len <= 0) {
 -		return NULL;
 -	}
 -	/* XXX So what is maxphys for us and how do drivers know it? */
 -	if (len > 256*1024) {			/* __get_free_pages() limit */
 -		return NULL;
 -	}
 -
 -	order = get_order(len_total);
 -	va = __get_free_pages(gfp, order);
 -	if (va == 0)
 -		goto err_nopages;
  
 -	if ((res = kzalloc(sizeof(struct resource), GFP_KERNEL)) == NULL)
 -		goto err_nomem;
 +	res = kzalloc(sizeof(*res), GFP_KERNEL);
 +	if (!res)
 +		return 0;
- 	res->name = dev->of_node->name;
++	res->name = dev->of_node->full_name;
  
 -	if (allocate_resource(&_sparc_dvma, res, len_total,
 -	    _sparc_dvma.start, _sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {
 -		printk("sbus_alloc_consistent: cannot occupy 0x%lx", len_total);
 -		goto err_nova;
 +	if (allocate_resource(&_sparc_dvma, res, len, _sparc_dvma.start,
 +			      _sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {
 +		printk("%s: cannot occupy 0x%zx", __func__, len);
 +		kfree(res);
 +		return 0;
  	}
  
 -	// XXX The sbus_map_dma_area does this for us below, see comments.
 -	// srmmu_mapiorange(0, virt_to_phys(va), res->start, len_total);
 -	/*
 -	 * XXX That's where sdev would be used. Currently we load
 -	 * all iommu tables with the same translations.
 -	 */
 -	if (sbus_map_dma_area(dev, dma_addrp, va, res->start, len_total) != 0)
 -		goto err_noiommu;
 -
 -	res->name = op->dev.of_node->full_name;
 -
 -	return (void *)(unsigned long)res->start;
 -
 -err_noiommu:
 -	release_resource(res);
 -err_nova:
 -	kfree(res);
 -err_nomem:
 -	free_pages(va, order);
 -err_nopages:
 -	return NULL;
 +	return res->start;
  }
  
 -static void sbus_free_coherent(struct device *dev, size_t n, void *p,
 -			       dma_addr_t ba, unsigned long attrs)
 +bool sparc_dma_free_resource(void *cpu_addr, size_t size)
  {
 +	unsigned long addr = (unsigned long)cpu_addr;
  	struct resource *res;
 -	struct page *pgv;
  
 -	if ((res = lookup_resource(&_sparc_dvma,
 -	    (unsigned long)p)) == NULL) {
 -		printk("sbus_free_consistent: cannot free %p\n", p);
 -		return;
 +	res = lookup_resource(&_sparc_dvma, addr);
 +	if (!res) {
 +		printk("%s: cannot free %p\n", __func__, cpu_addr);
 +		return false;
  	}
  
 -	if (((unsigned long)p & (PAGE_SIZE-1)) != 0) {
 -		printk("sbus_free_consistent: unaligned va %p\n", p);
 -		return;
 +	if ((addr & (PAGE_SIZE - 1)) != 0) {
 +		printk("%s: unaligned va %p\n", __func__, cpu_addr);
 +		return false;
  	}
  
 -	n = PAGE_ALIGN(n);
 -	if (resource_size(res) != n) {
 -		printk("sbus_free_consistent: region 0x%lx asked 0x%zx\n",
 -		    (long)resource_size(res), n);
 -		return;
 +	size = PAGE_ALIGN(size);
 +	if (resource_size(res) != size) {
 +		printk("%s: region 0x%lx asked 0x%zx\n",
 +			__func__, (long)resource_size(res), size);
 +		return false;
  	}
  
  	release_resource(res);

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: linux-next: manual merge of the sparc-next tree with the dma-mapping tree
  2018-12-11 22:30 linux-next: manual merge of the sparc-next tree with the dma-mapping tree Stephen Rothwell
@ 2018-12-12  7:44 ` Christoph Hellwig
  2018-12-12 16:11   ` Christoph Hellwig
  0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2018-12-12  7:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Christoph Hellwig, Linux Next Mailing List,
	Linux Kernel Mailing List, Rob Herring, Sam Ravnborg

On Wed, Dec 12, 2018 at 09:30:42AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the sparc-next tree got a conflict in:
> 
>   arch/sparc/kernel/ioport.c
> 
> between commit:
> 
>   53b7670e5735 ("sparc: factor the dma coherent mapping into helper")
> 
> from the dma-mapping tree and commit:
> 
>   86ef771ed543 ("sparc: Use DT node full_name instead of name for resources")
> 
> from the sparc-next tree.

Dave, Sam:

should I just apply a version of Rob's tree that takes the refactoring
into account to the dma-mapping tree?  That way we should get the right
result independent of the merge order.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: linux-next: manual merge of the sparc-next tree with the dma-mapping tree
  2018-12-12  7:44 ` Christoph Hellwig
@ 2018-12-12 16:11   ` Christoph Hellwig
  2018-12-12 16:32     ` Sam Ravnborg
  0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2018-12-12 16:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Christoph Hellwig, Linux Next Mailing List,
	Linux Kernel Mailing List, Rob Herring, Sam Ravnborg

On Wed, Dec 12, 2018 at 08:44:20AM +0100, Christoph Hellwig wrote:
> Dave, Sam:
> 
> should I just apply a version of Rob's tree that takes the refactoring
> into account to the dma-mapping tree?  That way we should get the right
> result independent of the merge order.

E.g. something like the patch below:

--
From 6ee3d6c39a0c8bc4b58fa601bb4370bdec785be7 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Wed, 12 Dec 2018 17:09:58 +0100
Subject: sparc: use DT node full_name in sparc_dma_alloc_resource

The sparc tree already has this change for the pre-refactored code,
but pulling it into the dma-mapping tree like this should ease
the merge conflicts a bit.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/sparc/kernel/ioport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
index 51c128d80193..baa235652c27 100644
--- a/arch/sparc/kernel/ioport.c
+++ b/arch/sparc/kernel/ioport.c
@@ -252,7 +252,7 @@ unsigned long sparc_dma_alloc_resource(struct device *dev, size_t len)
 	res = kzalloc(sizeof(*res), GFP_KERNEL);
 	if (!res)
 		return 0;
-	res->name = dev->of_node->name;
+	res->name = dev->of_node->full_name;
 
 	if (allocate_resource(&_sparc_dvma, res, len, _sparc_dvma.start,
 			      _sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {
-- 
2.19.2


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: linux-next: manual merge of the sparc-next tree with the dma-mapping tree
  2018-12-12 16:11   ` Christoph Hellwig
@ 2018-12-12 16:32     ` Sam Ravnborg
  2018-12-12 18:54       ` David Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Sam Ravnborg @ 2018-12-12 16:32 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Stephen Rothwell, David Miller, Linux Next Mailing List,
	Linux Kernel Mailing List, Rob Herring

On Wed, Dec 12, 2018 at 05:11:46PM +0100, Christoph Hellwig wrote:
> On Wed, Dec 12, 2018 at 08:44:20AM +0100, Christoph Hellwig wrote:
> > Dave, Sam:
> > 
> > should I just apply a version of Rob's tree that takes the refactoring
> > into account to the dma-mapping tree?  That way we should get the right
> > result independent of the merge order.
> 
> E.g. something like the patch below:
> 
> --
> >From 6ee3d6c39a0c8bc4b58fa601bb4370bdec785be7 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Wed, 12 Dec 2018 17:09:58 +0100
> Subject: sparc: use DT node full_name in sparc_dma_alloc_resource
> 
> The sparc tree already has this change for the pre-refactored code,
> but pulling it into the dma-mapping tree like this should ease
> the merge conflicts a bit.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/sparc/kernel/ioport.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
> index 51c128d80193..baa235652c27 100644
> --- a/arch/sparc/kernel/ioport.c
> +++ b/arch/sparc/kernel/ioport.c
> @@ -252,7 +252,7 @@ unsigned long sparc_dma_alloc_resource(struct device *dev, size_t len)
>  	res = kzalloc(sizeof(*res), GFP_KERNEL);
>  	if (!res)
>  		return 0;
> -	res->name = dev->of_node->name;
> +	res->name = dev->of_node->full_name;
>  
>  	if (allocate_resource(&_sparc_dvma, res, len, _sparc_dvma.start,
>  			      _sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {

Whatever works best for everyone is fine for me, so ack from me.

	Sam

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: linux-next: manual merge of the sparc-next tree with the dma-mapping tree
  2018-12-12 16:32     ` Sam Ravnborg
@ 2018-12-12 18:54       ` David Miller
  0 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2018-12-12 18:54 UTC (permalink / raw)
  To: sam; +Cc: hch, sfr, linux-next, linux-kernel, robh

From: Sam Ravnborg <sam@ravnborg.org>
Date: Wed, 12 Dec 2018 17:32:08 +0100

> On Wed, Dec 12, 2018 at 05:11:46PM +0100, Christoph Hellwig wrote:
>> On Wed, Dec 12, 2018 at 08:44:20AM +0100, Christoph Hellwig wrote:
>> > Dave, Sam:
>> > 
>> > should I just apply a version of Rob's tree that takes the refactoring
>> > into account to the dma-mapping tree?  That way we should get the right
>> > result independent of the merge order.
>> 
>> E.g. something like the patch below:
>> 
>> --
>> >From 6ee3d6c39a0c8bc4b58fa601bb4370bdec785be7 Mon Sep 17 00:00:00 2001
>> From: Christoph Hellwig <hch@lst.de>
>> Date: Wed, 12 Dec 2018 17:09:58 +0100
>> Subject: sparc: use DT node full_name in sparc_dma_alloc_resource
>> 
>> The sparc tree already has this change for the pre-refactored code,
>> but pulling it into the dma-mapping tree like this should ease
>> the merge conflicts a bit.
>> 
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>>  arch/sparc/kernel/ioport.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
>> index 51c128d80193..baa235652c27 100644
>> --- a/arch/sparc/kernel/ioport.c
>> +++ b/arch/sparc/kernel/ioport.c
>> @@ -252,7 +252,7 @@ unsigned long sparc_dma_alloc_resource(struct device *dev, size_t len)
>>  	res = kzalloc(sizeof(*res), GFP_KERNEL);
>>  	if (!res)
>>  		return 0;
>> -	res->name = dev->of_node->name;
>> +	res->name = dev->of_node->full_name;
>>  
>>  	if (allocate_resource(&_sparc_dvma, res, len, _sparc_dvma.start,
>>  			      _sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {
> 
> Whatever works best for everyone is fine for me, so ack from me.

Yeah I'm fine with this too.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-12-12 18:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-11 22:30 linux-next: manual merge of the sparc-next tree with the dma-mapping tree Stephen Rothwell
2018-12-12  7:44 ` Christoph Hellwig
2018-12-12 16:11   ` Christoph Hellwig
2018-12-12 16:32     ` Sam Ravnborg
2018-12-12 18:54       ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).