Received: by 10.223.185.116 with SMTP id b49csp6389308wrg; Wed, 28 Feb 2018 08:36:47 -0800 (PST) X-Google-Smtp-Source: AG47ELtQLrH3/PiGF2eMCQY6qLoSrKTZg4UFzGjN2WE+WHHporD3EF7nDb5O6lJik92GXexrsvPB X-Received: by 10.98.16.23 with SMTP id y23mr3456972pfi.84.1519835807827; Wed, 28 Feb 2018 08:36:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519835807; cv=none; d=google.com; s=arc-20160816; b=KwW0/7Hl23xbmB7a2kcU8xa6aW79NrSWO5doqIZ64aRK5WegrCefqau7vksjB8grXr PaVR/l/qtXD5paxBZIGyxh/vcQsLKMYgUkbUKP2QQyef/l2RtmxP+qwEYEGcMDoHR7y9 kRo5j+g3ZUgoTU+cek4h6wt11U/0bPpmO8BG1O6bJcZ/8X7sexSdQ10VtlJdye+kBVkt pMZ9qshXqvHfGzSzWfQ/cx1OlVGHJ4saQ+nVy4ZvGQ64A4AEkB94/UubU2/UOLxqXP4D TOSUfMS7LHszTsK4zCNkpLe5YdOEwD0eBYjmrcEQJ9p3C64spUqB9Ya9jVIOyAY2KeNa oq6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=Gz52Klt/6nnFawGNVMKjVphN1NJ9hGY/GLH/wTrdwSY=; b=lRIdCcSwPZRqy8y3vurRBLSSKIuzzdF9JJPl/NZ1H8a3ajlq/MWmwof1vkH4le4vIA I7a5UE9ENCHFvsXYuXxDx04K/DT+5PBwUK7ED0ud3mcMiVQ2SuOxN4JI3Uotvyi/HQPI TyjQ4Jck04E+VrUlXaF4SNXfSqM48jVeR50zdlDoBpeZ8wjnF1i0qvNbi2Z3RfRrhzuE WrXREWmyN3dge5ZkNF8Z6IAiYXHqeA5iQATI4m8yzSgUHPrNEFgp5A58hQuOX2Mpc5e5 RKG+hDGE4FA1xUw95k2adhFQC+QcazhwFMGWdGO4bELoLIcPPq/CbPiELmSYLsLdX+WS YShQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p33-v6si1507432pld.310.2018.02.28.08.36.32; Wed, 28 Feb 2018 08:36:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934380AbeB1Qfa (ORCPT + 99 others); Wed, 28 Feb 2018 11:35:30 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35066 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934578AbeB1QNm (ORCPT ); Wed, 28 Feb 2018 11:13:42 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yk-0006XS-9Y; Wed, 28 Feb 2018 15:22:23 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yi-0000Bp-Gt; Wed, 28 Feb 2018 15:22:20 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "David S. Miller" , "Sergei Shtylyov" , "Nobuhiro Iwamatsu" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 168/254] sh_eth: fix TSU resource handling In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Sergei Shtylyov commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 upstream. When switching the driver to the managed device API, I managed to break the case of a dual Ether devices sharing a single TSU: the 2nd Ether port wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy and he then dropped the ball... The solution is to limit calling devm_request_mem_region() to the first of the two ports sharing the same TSU, so devm_ioremap_resource() can't be used anymore for the TSU resource... Fixes: d5e07e69218f ("sh_eth: use managed device API") Reported-by: Nobuhiro Iwamatsu Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -2873,10 +2873,29 @@ static int sh_eth_drv_probe(struct platf /* ioremap the TSU registers */ if (mdp->cd->tsu) { struct resource *rtsu; + rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1); - mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu); - if (IS_ERR(mdp->tsu_addr)) { - ret = PTR_ERR(mdp->tsu_addr); + if (!rtsu) { + dev_err(&pdev->dev, "no TSU resource\n"); + ret = -ENODEV; + goto out_release; + } + /* We can only request the TSU region for the first port + * of the two sharing this TSU for the probe to succeed... + */ + if (devno % 2 == 0 && + !devm_request_mem_region(&pdev->dev, rtsu->start, + resource_size(rtsu), + dev_name(&pdev->dev))) { + dev_err(&pdev->dev, "can't request TSU resource.\n"); + ret = -EBUSY; + goto out_release; + } + mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start, + resource_size(rtsu)); + if (!mdp->tsu_addr) { + dev_err(&pdev->dev, "TSU region ioremap() failed.\n"); + ret = -ENOMEM; goto out_release; } mdp->port = devno % 2;