Message ID | 20231026061458.1116276-1-n-yadav@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp458330vqb; Wed, 25 Oct 2023 23:16:01 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG4xs9xL0T6xkDV8DHe1Sg9eqYOygQjYRYKSSGxjgpRRMhqHxsZyslb733IhLHtUpXeMYy8 X-Received: by 2002:a25:e606:0:b0:d9c:ee80:9215 with SMTP id d6-20020a25e606000000b00d9cee809215mr3061073ybh.26.1698300961379; Wed, 25 Oct 2023 23:16:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698300961; cv=none; d=google.com; s=arc-20160816; b=NSb55JWOnK3BSSauL0f7nPJZ66RgMbEHGYMT3vY/TPymwDvR9OUvzicuZLKnNMLASs jPVM489omZ8pgJAZLiYgcoXbZcpIMv3Dm6y0+nZdxK2sp6TEbEQ11LCEBhFNbM3GN64+ XJjaeHubZTnGKl7+qqz+Ei1f+fug2qtlp8ZKx56GfwLDgTto3iikacN29CY//VBMecsw VUFlrhwWP+gu4gJdgddjluszSgxDcKa60QLLwhjMDUy7aKuJMFZ2NXNoADV4K9LTfi2F VojQsUzHgyw9Gl2HdPGGm+uTNLeW5idKHjJLasHj2S+VqlAQu129drTk5ywkdcRW98ea RTrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=LftDA9Y+XGl1ONXZCRa+9Wt1QWlpdij0YsK3eYAGaSc=; fh=6rMBuCdeApEsC0Fr6pDgJL1nfZmH+27r+UC2beMNFxA=; b=kn2pDtJvrehv8hTRL5YknLUQUYpaJLn6EMTBjE/CW9i9VV4kwtSGkrOeV3U2+vd+fB NkrgfraKx0IMcoD3Q6Wtdqasj18I8IkX2KVwdEE+LyT3ytKHnbb5mfxoJr3GqeXUJ9sI n2r4Am3Ksk30JGmigOVq7SvkH8sHQ1DlTN7FrUuHL95kBqHLAR+iv28U6vAoD9maf5qW iPReKp9yFll27rOu0Z8e54M1a4mRRiN0GrjswOKT52X/aorzIbcfYayOxv4C1wI8jY2Y /j/aRM/ZHJcdNjLGjh14Yh2NGacYX6cV2m7eR9sS92KY97ZAFKKbwH3WO65CrEdbFT5c Lpug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=RuB+8Z2L; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id r134-20020a25768c000000b00d9abc7dd745si14000587ybc.144.2023.10.25.23.16.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Oct 2023 23:16:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=RuB+8Z2L; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id AE8F68250DC2; Wed, 25 Oct 2023 23:15:25 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343564AbjJZGPF (ORCPT <rfc822;aposhian.dev@gmail.com> + 26 others); Thu, 26 Oct 2023 02:15:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230478AbjJZGPF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 26 Oct 2023 02:15:05 -0400 Received: from fllv0016.ext.ti.com (fllv0016.ext.ti.com [198.47.19.142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F4051186; Wed, 25 Oct 2023 23:15:02 -0700 (PDT) Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 39Q6F022075460; Thu, 26 Oct 2023 01:15:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1698300900; bh=LftDA9Y+XGl1ONXZCRa+9Wt1QWlpdij0YsK3eYAGaSc=; h=From:To:CC:Subject:Date; b=RuB+8Z2LEDXTj5njYbYMSrz9NKe/JkDT4gAPOqVWobuXyAjA8K0R3uJWbPYYCqqO8 2grBp5gQG29ka4RP8yWP4ZbOkf8e9tfl7IOtpgn7y9iPIB+0MafI3+Q82iLf1t9/Oo 0CPxq0bLfNoA8Bq1ciqPa+ABDDXhGveaEpFTmR+I= Received: from DLEE106.ent.ti.com (dlee106.ent.ti.com [157.170.170.36]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 39Q6F0jh030506 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 26 Oct 2023 01:15:00 -0500 Received: from DLEE113.ent.ti.com (157.170.170.24) by DLEE106.ent.ti.com (157.170.170.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Thu, 26 Oct 2023 01:15:00 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Thu, 26 Oct 2023 01:15:00 -0500 Received: from localhost (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 39Q6ExsW104152; Thu, 26 Oct 2023 01:14:59 -0500 From: Nitin Yadav <n-yadav@ti.com> To: <adrian.hunter@intel.com>, <ulf.hansson@linaro.org> CC: <linux-mmc@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] mmc: sdhci_am654: fix start loop index for TAP value parsing Date: Thu, 26 Oct 2023 11:44:58 +0530 Message-ID: <20231026061458.1116276-1-n-yadav@ti.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 25 Oct 2023 23:15:25 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780797629127183389 X-GMAIL-MSGID: 1780797629127183389 |
Series |
mmc: sdhci_am654: fix start loop index for TAP value parsing
|
|
Commit Message
Nitin Yadav
Oct. 26, 2023, 6:14 a.m. UTC
ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed from DT
are currently ignored for all SD/MMC and eMMC modes. Fix this
by making start loop index to MMC_TIMING_LEGACY.
Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes")
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
---
drivers/mmc/host/sdhci_am654.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 26/10/23 09:14, Nitin Yadav wrote: > ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed from DT > are currently ignored for all SD/MMC and eMMC modes. Fix this > by making start loop index to MMC_TIMING_LEGACY. > > Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes") > There isn't usually a blank line here Perhaps a Cc: stable@vger.kernel.org tag? > Signed-off-by: Nitin Yadav <n-yadav@ti.com> Nevertheless: Acked-by: Adrian Hunter <adrian.hunter@intel.com> > --- > drivers/mmc/host/sdhci_am654.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c > index 544aaaf5cb0f..aae9d255c6a1 100644 > --- a/drivers/mmc/host/sdhci_am654.c > +++ b/drivers/mmc/host/sdhci_am654.c > @@ -606,7 +606,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, > return 0; > } > > - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { > + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { > > ret = device_property_read_u32(dev, td[i].otap_binding, > &sdhci_am654->otap_del_sel[i]);
On 26/10/23 10:00, Adrian Hunter wrote: > On 26/10/23 09:14, Nitin Yadav wrote: >> ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed from DT >> are currently ignored for all SD/MMC and eMMC modes. Fix this >> by making start loop index to MMC_TIMING_LEGACY. >> >> Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes") >> > > There isn't usually a blank line here > > Perhaps a Cc: stable@vger.kernel.org tag? > >> Signed-off-by: Nitin Yadav <n-yadav@ti.com> > > Nevertheless: > > Acked-by: Adrian Hunter <adrian.hunter@intel.com> Sorry, sent that prematurely - see comment below > > >> --- >> drivers/mmc/host/sdhci_am654.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c >> index 544aaaf5cb0f..aae9d255c6a1 100644 >> --- a/drivers/mmc/host/sdhci_am654.c >> +++ b/drivers/mmc/host/sdhci_am654.c >> @@ -606,7 +606,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, >> return 0; >> } >> Isn't the MMC_TIMING_LEGACY information read at the top of sdhci_am654_get_otap_delay()? >> - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { >> + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { >> >> ret = device_property_read_u32(dev, td[i].otap_binding, >> &sdhci_am654->otap_del_sel[i]); >
Hi Adrian, On 26/10/23 12:33, Adrian Hunter wrote: > On 26/10/23 10:00, Adrian Hunter wrote: >> On 26/10/23 09:14, Nitin Yadav wrote: >>> ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed from DT >>> are currently ignored for all SD/MMC and eMMC modes. Fix this >>> by making start loop index to MMC_TIMING_LEGACY. >>> >>> Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes") >>> >> >> There isn't usually a blank line here >> >> Perhaps a Cc: stable@vger.kernel.org tag? >> >>> Signed-off-by: Nitin Yadav <n-yadav@ti.com> >> >> Nevertheless: >> >> Acked-by: Adrian Hunter <adrian.hunter@intel.com> > > Sorry, sent that prematurely - see comment below > >> >> >>> --- >>> drivers/mmc/host/sdhci_am654.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c >>> index 544aaaf5cb0f..aae9d255c6a1 100644 >>> --- a/drivers/mmc/host/sdhci_am654.c >>> +++ b/drivers/mmc/host/sdhci_am654.c >>> @@ -606,7 +606,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, >>> return 0; >>> } >>> > > Isn't the MMC_TIMING_LEGACY information read at the top of > sdhci_am654_get_otap_delay()? Loop also take care of ITAP. Looks like at some point single property ti,otap-del-sel was used for all modes and then we moved to one property per mode: https://lore.kernel.org/r/20200108150920.14547-3-faiz_abbas@ti.com (since v5.7) > >>> - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { >>> + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { >>> >>> ret = device_property_read_u32(dev, td[i].otap_binding, >>> &sdhci_am654->otap_del_sel[i]); >> >
Hi Nitin, Adrian On 27/10/23 11:41, Nitin Yadav wrote: > Hi Adrian, > > On 26/10/23 12:33, Adrian Hunter wrote: >> On 26/10/23 10:00, Adrian Hunter wrote: >>> On 26/10/23 09:14, Nitin Yadav wrote: >>>> ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed from DT >>>> are currently ignored for all SD/MMC and eMMC modes. Fix this >>>> by making start loop index to MMC_TIMING_LEGACY. >>>> >>>> Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes") >>>> >>> >>> There isn't usually a blank line here >>> >>> Perhaps a Cc: stable@vger.kernel.org tag? >>> >>>> Signed-off-by: Nitin Yadav <n-yadav@ti.com> >>> >>> Nevertheless: >>> >>> Acked-by: Adrian Hunter <adrian.hunter@intel.com> >> >> Sorry, sent that prematurely - see comment below >> >>> >>> >>>> --- >>>> drivers/mmc/host/sdhci_am654.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c >>>> index 544aaaf5cb0f..aae9d255c6a1 100644 >>>> --- a/drivers/mmc/host/sdhci_am654.c >>>> +++ b/drivers/mmc/host/sdhci_am654.c >>>> @@ -606,7 +606,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, >>>> return 0; >>>> } >>>> >> >> Isn't the MMC_TIMING_LEGACY information read at the top of >> sdhci_am654_get_otap_delay()? > Loop also take care of ITAP. Looks like at some point single property > ti,otap-del-sel was used for all modes and then we moved to one property > per mode: > https://lore.kernel.org/r/20200108150920.14547-3-faiz_abbas@ti.com > (since v5.7) Looks like ti,otap-del-sel is deprecated for a while now (since v5.7+). I think that's sufficient enough time to drop it now (don't see any in kernel DT use this property). Lets drop the above code which handles MMC_TIMING_LEGACY separately, so that below for() loop can handle the whole set of bindings efficiently. Since this patch is marked for stable, can we get rid of the check for deprecated property in a follow up patch? Something like below? (completely untested): diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c index c125485ba80e..50c8d3051096 100644 --- a/drivers/mmc/host/sdhci_am654.c +++ b/drivers/mmc/host/sdhci_am654.c @@ -577,32 +577,17 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, int i; int ret; - ret = device_property_read_u32(dev, td[MMC_TIMING_LEGACY].otap_binding, - &sdhci_am654->otap_del_sel[MMC_TIMING_LEGACY]); - if (ret) { - /* - * ti,otap-del-sel-legacy is mandatory, look for old binding - * if not found. - */ - ret = device_property_read_u32(dev, "ti,otap-del-sel", - &sdhci_am654->otap_del_sel[0]); - if (ret) { - dev_err(dev, "Couldn't find otap-del-sel\n"); - - return ret; - } - - dev_info(dev, "Using legacy binding ti,otap-del-sel\n"); - sdhci_am654->legacy_otapdly = true; - - return 0; - } - - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { ret = device_property_read_u32(dev, td[i].otap_binding, &sdhci_am654->otap_del_sel[i]); if (ret) { + if (i == MMC_TIMING_LEGACY) { + dev_err(dev, "ti,otap-del-sel-legacy is mandatory"); + return ret; + } + dev_dbg(dev, "Couldn't find %s\n", td[i].otap_binding); /* >> >>>> - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { >>>> + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { >>>> >>>> ret = device_property_read_u32(dev, td[i].otap_binding, >>>> &sdhci_am654->otap_del_sel[i]); >>> >> >
On Thu, 26 Oct 2023 at 08:15, Nitin Yadav <n-yadav@ti.com> wrote: > > ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed from DT > are currently ignored for all SD/MMC and eMMC modes. Fix this > by making start loop index to MMC_TIMING_LEGACY. > > Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes") > > Signed-off-by: Nitin Yadav <n-yadav@ti.com> Applied for fixes and by adding a stable tag, thanks! Kind regards Uffe > --- > drivers/mmc/host/sdhci_am654.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c > index 544aaaf5cb0f..aae9d255c6a1 100644 > --- a/drivers/mmc/host/sdhci_am654.c > +++ b/drivers/mmc/host/sdhci_am654.c > @@ -606,7 +606,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, > return 0; > } > > - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { > + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { > > ret = device_property_read_u32(dev, td[i].otap_binding, > &sdhci_am654->otap_del_sel[i]); > -- > 2.25.1 >
On Mon, 30 Oct 2023 at 09:07, Vignesh Raghavendra <vigneshr@ti.com> wrote: > > Hi Nitin, Adrian > > On 27/10/23 11:41, Nitin Yadav wrote: > > Hi Adrian, > > > > On 26/10/23 12:33, Adrian Hunter wrote: > >> On 26/10/23 10:00, Adrian Hunter wrote: > >>> On 26/10/23 09:14, Nitin Yadav wrote: > >>>> ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed from DT > >>>> are currently ignored for all SD/MMC and eMMC modes. Fix this > >>>> by making start loop index to MMC_TIMING_LEGACY. > >>>> > >>>> Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes") > >>>> > >>> > >>> There isn't usually a blank line here > >>> > >>> Perhaps a Cc: stable@vger.kernel.org tag? > >>> > >>>> Signed-off-by: Nitin Yadav <n-yadav@ti.com> > >>> > >>> Nevertheless: > >>> > >>> Acked-by: Adrian Hunter <adrian.hunter@intel.com> > >> > >> Sorry, sent that prematurely - see comment below > >> > >>> > >>> > >>>> --- > >>>> drivers/mmc/host/sdhci_am654.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c > >>>> index 544aaaf5cb0f..aae9d255c6a1 100644 > >>>> --- a/drivers/mmc/host/sdhci_am654.c > >>>> +++ b/drivers/mmc/host/sdhci_am654.c > >>>> @@ -606,7 +606,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, > >>>> return 0; > >>>> } > >>>> > >> > >> Isn't the MMC_TIMING_LEGACY information read at the top of > >> sdhci_am654_get_otap_delay()? > > Loop also take care of ITAP. Looks like at some point single property > > ti,otap-del-sel was used for all modes and then we moved to one property > > per mode: > > https://lore.kernel.org/r/20200108150920.14547-3-faiz_abbas@ti.com > > (since v5.7) > > Looks like ti,otap-del-sel is deprecated for a while now (since v5.7+). > I think that's sufficient enough time to drop it now (don't see any in > kernel DT use this property). Lets drop the above code which handles > MMC_TIMING_LEGACY separately, so that below for() loop can handle the > whole set of bindings efficiently. > > Since this patch is marked for stable, can we get rid of the check for > deprecated property in a follow up patch? This seems reasonable to me, however, let's also get the DT maintainers view on this. I have queued up $subject patch as a fix and tagged it for stable kernels. Feel free to post the patches to remove the support for the deprecated binding on top. Kind regards Uffe > > Something like below? (completely untested): > > > diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c > index c125485ba80e..50c8d3051096 100644 > --- a/drivers/mmc/host/sdhci_am654.c > +++ b/drivers/mmc/host/sdhci_am654.c > @@ -577,32 +577,17 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, > int i; > int ret; > > - ret = device_property_read_u32(dev, td[MMC_TIMING_LEGACY].otap_binding, > - &sdhci_am654->otap_del_sel[MMC_TIMING_LEGACY]); > - if (ret) { > - /* > - * ti,otap-del-sel-legacy is mandatory, look for old binding > - * if not found. > - */ > - ret = device_property_read_u32(dev, "ti,otap-del-sel", > - &sdhci_am654->otap_del_sel[0]); > - if (ret) { > - dev_err(dev, "Couldn't find otap-del-sel\n"); > - > - return ret; > - } > - > - dev_info(dev, "Using legacy binding ti,otap-del-sel\n"); > - sdhci_am654->legacy_otapdly = true; > - > - return 0; > - } > - > - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { > + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { > > ret = device_property_read_u32(dev, td[i].otap_binding, > &sdhci_am654->otap_del_sel[i]); > if (ret) { > + if (i == MMC_TIMING_LEGACY) { > + dev_err(dev, "ti,otap-del-sel-legacy is mandatory"); > + return ret; > + } > + > dev_dbg(dev, "Couldn't find %s\n", > td[i].otap_binding); > /* > > > > >> > >>>> - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { > >>>> + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { > >>>> > >>>> ret = device_property_read_u32(dev, td[i].otap_binding, > >>>> &sdhci_am654->otap_del_sel[i]); > >>> > >> > > > > -- > Regards > Vignesh
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c index 544aaaf5cb0f..aae9d255c6a1 100644 --- a/drivers/mmc/host/sdhci_am654.c +++ b/drivers/mmc/host/sdhci_am654.c @@ -606,7 +606,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host *host, return 0; } - for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) { + for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) { ret = device_property_read_u32(dev, td[i].otap_binding, &sdhci_am654->otap_del_sel[i]);