mirror of
				https://github.com/torvalds/linux.git
				synced 2025-11-04 02:30:34 +02:00 
			
		
		
		
	drivers/vlynq/vlynq.c: fix resource size off by 1 error
In this case, the calls to request_mem_region, ioremap, and release_mem_region all have a consistent length argument, len, but since in other files (res->end - res->start) + 1, equivalent to resource_size(res), is used for a resource-typed structure res, one could consider whether the same should be done here. The problem was found using the following semantic patch: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ struct resource *res; @@ - (res->end - res->start) + 1 + resource_size(res) @@ struct resource *res; @@ - res->end - res->start + BAD(resource_size(res)) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Acked-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
		
							parent
							
								
									a21f3c2a04
								
							
						
					
					
						commit
						3354f73b24
					
				
					 1 changed files with 1 additions and 1 deletions
				
			
		| 
						 | 
					@ -702,7 +702,7 @@ static int vlynq_probe(struct platform_device *pdev)
 | 
				
			||||||
	dev->mem_start = mem_res->start;
 | 
						dev->mem_start = mem_res->start;
 | 
				
			||||||
	dev->mem_end = mem_res->end;
 | 
						dev->mem_end = mem_res->end;
 | 
				
			||||||
 | 
					
 | 
				
			||||||
	len = regs_res->end - regs_res->start;
 | 
						len = resource_size(regs_res);
 | 
				
			||||||
	if (!request_mem_region(regs_res->start, len, dev_name(&dev->dev))) {
 | 
						if (!request_mem_region(regs_res->start, len, dev_name(&dev->dev))) {
 | 
				
			||||||
		printk(KERN_ERR "%s: Can't request vlynq registers\n",
 | 
							printk(KERN_ERR "%s: Can't request vlynq registers\n",
 | 
				
			||||||
		       dev_name(&dev->dev));
 | 
							       dev_name(&dev->dev));
 | 
				
			||||||
| 
						 | 
					
 | 
				
			||||||
		Loading…
	
		Reference in a new issue