Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp949143rwb; Fri, 7 Oct 2022 06:20:29 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5TFknAMSudoOFcqTcka/X6tBpOaCj/ui0GpS8gIiXEegRMvdRe/wM0ib2U94BIo4AJWQji X-Received: by 2002:a05:6402:28a1:b0:458:81c0:a379 with SMTP id eg33-20020a05640228a100b0045881c0a379mr4546451edb.388.1665148829487; Fri, 07 Oct 2022 06:20:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665148829; cv=none; d=google.com; s=arc-20160816; b=FDpN8uzuB/QkJNFTiI1FxCpxFUpcmhK1f6f8Icr9rUgQ1BJ3TB84GhMcMKpBEXIhk/ 13Sq74Hn9Vdb7j33J7ah9vdqqfnsGuPr1MWAaAD6CtHp5JpUkwbKGSKxe71ttjArUMGW khNTfWCguxUFwJku/PaJ3qFbnghH02AIpzDS9eGD9J5t81D08YoQedo8fTxHS2Rtb9Ic eK9Whdq7uChlRiEB76/Gcnp/o2+oXW2vAy/BcsVPMGDZ1jPftHUOrE+pR0aKy8csk2wE NhV6UKUlutqJHb9I6Rp9DdVKODf+wLi53lQzwrOXwz65GAtKtw7macPovztj6ut63TCO oc2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=L+43/3kVmg+p0ZcrIutD7soToeLt75gKyvKftIXwuQM=; b=FpMaVV8mP0JwtgArWa/zwh6h48Uc5L7nSrlqgVZcE3KLUQY2aoHSZ3R4/xQvPLEvcB 79Rt9hZbmbjJiZndRMH8sdmMIRDhDDc76NyJxao0E5+L/CHzLKTnjhbzkFh2yPg98XOj rHpVXfRcyS8W6N0H5TZojl7+P8pID6bKrRe7yrxubvFXN1s+Z8upXumVhfPsRpRanUbe oEi354led7VspCW+jHYHiLzqxQ/96ImviwdOL99DWp7sEmJwjdWilE09NuXnRREmHK86 j8VGpj2juDfKh8mSa9jNK8gXpyAELIzHvTpjVSvHTc6JMOUI5qghIatjcIwksrmuLh0l 85Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="MMItm/KH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hs10-20020a1709073e8a00b00779b815b8d9si2403649ejc.497.2022.10.07.06.20.03; Fri, 07 Oct 2022 06:20:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="MMItm/KH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229720AbiJGNGi (ORCPT + 99 others); Fri, 7 Oct 2022 09:06:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229569AbiJGNGg (ORCPT ); Fri, 7 Oct 2022 09:06:36 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44B00C7075 for ; Fri, 7 Oct 2022 06:06:35 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id y8so4811569pfp.13 for ; Fri, 07 Oct 2022 06:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=L+43/3kVmg+p0ZcrIutD7soToeLt75gKyvKftIXwuQM=; b=MMItm/KHcYIuEHKofG7TqERR/uBgZrV+dMXPEImmiUIGfdJUSWE6arVGFUQejv3Juq +TmSWp4oLXVYERQWggvLB56hUgLpa10/CNthXnYqbAvL+qUXTXVgUoro3VyXCc8Nuu1G udo/4pBxClWMBvxGBx9hRGe44YqgpqCcdSdW7WCP/ARYL6dRfw+x0G2VUi4Zvx/X6+G/ KT7aJH14eny+pe3SugMtM94voUMP/GnJdhaJGrnlKZyD1nRhl3FA1RxDiHmV0J2Txmg8 5aTfw/fDpveiyaGFk93kgaHT7+cdwOOudVzGRDXjkjiyaqvvkzbkZmyvxwgkJlbaNLGP AH8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=L+43/3kVmg+p0ZcrIutD7soToeLt75gKyvKftIXwuQM=; b=1tGSQatJ5cdoTfA6EZl7fsJgdyVvo7RFGQ9pjES3uxockkoy2ZeWKUwlCQjNRhi4/0 uKYAjmxAkdy6s4hT6uxEopq11sZFkyNtWSEIs9TXUFF6JhiPInXsmJUB/T+44DUAQTY/ 3eU6DbWBlh/p+uTlzA2U6QydBbekRp9+GhpJsfaqTc4gDxHpMcJ9C1fjQq2utkA0PF0n drR6+iTU9FMnCm9IXE9zCFVRDtjp7tOmQpyaIAvzo9WxrW+vTYI8PgCwuw9sviwr6N+9 DHINU2WC2g6EmwyPtlOfdi5Za1YSVxTScrDPCdmxUMliMvEPrzkoZ0dNqQXOnB8Q2PaX 0Fyg== X-Gm-Message-State: ACrzQf2BOtsNmS2V88+BZ/sbXemer00xuPXMbSjC9gumM+2Pl70WcPIx qHyzTX7W/6tiAraQwHfeiFLwn4o+VkB9a7/j5T9C6w== X-Received: by 2002:a63:90c1:0:b0:450:75b5:29fe with SMTP id a184-20020a6390c1000000b0045075b529femr4361488pge.541.1665147994580; Fri, 07 Oct 2022 06:06:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulf Hansson Date: Fri, 7 Oct 2022 15:05:57 +0200 Message-ID: Subject: Re: [PATCH 1/2] mmc: block: Remove error check of hw_reset on reset To: =?UTF-8?Q?Christian_L=C3=B6hle?= Cc: Adrian Hunter , Linux MMC List , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 6 Oct 2022 at 15:38, Christian L=C3=B6hle = wrote: > > Before switching back to the right partition in mmc_blk_reset > there used to be a check if hw_reset was even supported. > This return value was removed, so there is no reason to check. > > Fixes: fefdd3c91e0a ("mmc: core: Drop superfluous validations in mmc_hw|s= w_reset()") > Cc: stable@vger.kernel.org > > Signed-off-by: Christian Loehle > --- > drivers/mmc/core/block.c | 24 ++++++++++-------------- > 1 file changed, 10 insertions(+), 14 deletions(-) > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c > index ce89611a136e..8531f92fd0cb 100644 > --- a/drivers/mmc/core/block.c > +++ b/drivers/mmc/core/block.c > @@ -991,6 +991,8 @@ static int mmc_blk_reset(struct mmc_blk_data *md, str= uct mmc_host *host, > int type) > { > int err; > + struct mmc_blk_data *main_md =3D dev_get_drvdata(&host->card->dev= ); > + int part_err; > > if (md->reset_done & type) > return -EEXIST; > @@ -998,20 +1000,14 @@ static int mmc_blk_reset(struct mmc_blk_data *md, = struct mmc_host *host, > md->reset_done |=3D type; > err =3D mmc_hw_reset(host->card); > /* Ensure we switch back to the correct partition */ > - if (err) { > - struct mmc_blk_data *main_md =3D > - dev_get_drvdata(&host->card->dev); > - int part_err; > - > - main_md->part_curr =3D main_md->part_type; > - part_err =3D mmc_blk_part_switch(host->card, md->part_typ= e); > - if (part_err) { > - /* > - * We have failed to get back into the correct > - * partition, so we need to abort the whole reque= st. > - */ > - return -ENODEV; > - } Yes, this is certainly restoring the behaviour and fixing a bug. Thanks! However, I do wonder about what's the point of trying to switch back to the correct partition if the mmc_hw_reset() failed (returned a negative error code). It looks like that shouldn't matter, if the reset failed we are screwed anyway, right? > + main_md->part_curr =3D main_md->part_type; > + part_err =3D mmc_blk_part_switch(host->card, md->part_type); > + if (part_err) { > + /* > + * We have failed to get back into the correct > + * partition, so we need to abort the whole request. > + */ > + return -ENODEV; > } > return err; > } Kind regards Uffe