Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp838255pxv; Thu, 24 Jun 2021 22:44:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy23s0j+7qd1WURFW2bGURQEEgQpRx59h2tYOsM4BmP2ePWBRrTcM2nys+i9tV/T5XeH6b6 X-Received: by 2002:a17:907:3396:: with SMTP id zj22mr8973323ejb.155.1624599859026; Thu, 24 Jun 2021 22:44:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624599859; cv=none; d=google.com; s=arc-20160816; b=ZSVjjG9nG1BtlfSFCpxKEvwM4aoncbLguU+u3WSZUi7ylLYrbXJC695fXz2XMagnNL nTHc84DnZS2UiuxwC5123SvKYJSpyiK1HoamJ9Gwt6DdBol6hu9BW036UqmdoxYFOHMW Gzymjqf5dyayD5nahy+4P8+sL2PMDhRriuwrRMzwbGEJCDWYQyzW3aVikqDRGgCvwvPD u4udUu96N7GcLsXpGgjx+/tvzdj2QqX4xctC4oPgd/oroc3BZG6YOmjXPIP+j9LuRpcr eEuUSn0tf3nVd5FH5ofViVnD6aMIvMDHBV6c3YT/vHADijigC03wr1lu2f2/e+GDgYq0 TkZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from; bh=Jup+m3XGH1EKWnKBtIPxuqStdlvo4Vi1iGxUPFGHjx0=; b=hgDTaY/lzAvNv+nILOiREo1+PsQVFl1wL6HlJ/0VzJCxaM1TDRs8HKhWjOyzTx5Miz 9uCvrgFX9wj2r63pcoGUOXWayDcrg8DKNcOjxxwpXjAe+5qLgk6cuZaa5S3H2bS85tHX Auorf0amcwpk6qsng9cOX52EN3MJHGSHyNI3CIfP5pIEF4QX3SGKqgxd6X1u2wQTt5+r SdHb5Rw7rmAVU4t/cQAs+wvVShs7197B6vm7TyLEI9I6wXjkFs64bNnAUmmNAsznWO6U 4p91LEgvx660bp3WRLXDie647R9bZ1EyaOwP/zwY1Vlqr8wi3FN9WffVKlqgtY2G+K+y KMaQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ec39si4998738edb.37.2021.06.24.22.43.54; Thu, 24 Jun 2021 22:44:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230097AbhFYFpZ convert rfc822-to-8bit (ORCPT + 99 others); Fri, 25 Jun 2021 01:45:25 -0400 Received: from smtp1.hiworks.co.kr ([121.254.168.204]:47661 "EHLO smtp1.hiworks.co.kr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230192AbhFYFpY (ORCPT ); Fri, 25 Jun 2021 01:45:24 -0400 Received: (qmail 103729 invoked from network); 25 Jun 2021 14:43:01 +0900 Received: from unknown (HELO hiworks.co.kr) (192.168.10.162) by 0 (qmail 1.03 + ejcp v14) with SMTP; 25 Jun 2021 14:43:01 +0900 Received: (qmail 161327 invoked from network); 25 Jun 2021 14:43:00 +0900 Received: from unknown (HELO DESKTOP3HTLQGF) (tykwon@m2i.co.kr@58.75.176.98) by 0 (qmail 1.03 + ejcp v14) with SMTP; 25 Jun 2021 14:43:00 +0900 X-Authinfo: HIWORKS SMTP authenticated From: "Kwon Tae-young" To: "'Ulf Hansson'" Cc: "'linux-mmc'" , "'Linux Kernel Mailing List'" References: <20210624061418.30361-1-tykwon@m2i.co.kr> In-Reply-To: Subject: RE: [PATCH] mmc: core: Added support for LED trigger only when SD card is connected Date: Fri, 25 Jun 2021 14:43:01 +0900 Message-ID: <038801d76984$f672b0b0$e3581210$@m2i.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQM/ouEl57R0GPXs7J4RkiPdEOUrjgFbgzw3qEjedVA= Content-Language: ko Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index > > f194940c5974..b3156f6c5cfa 100644 > > --- a/drivers/mmc/core/core.c > > +++ b/drivers/mmc/core/core.c > > @@ -352,7 +352,11 @@ int mmc_start_request(struct mmc_host *host, > struct mmc_request *mrq) > > if (err) > > return err; > > > > - led_trigger_event(host->led, LED_FULL); > > + if (host->ops->get_cd) > > No, this is not the right thing to do. Invoking the ->get_cd() callback, > for every request is suboptimal and would likely have effects on > performance. > > Moreover, I wonder how big an issue it is to use the led here. If the > card is being removed, the request will fail anyway, so the led should > soon stop flashing anyway, right? Thanks for the feedback. When I think about it, it seems that an error should be returned from the mmc_card_removed() function when the SD card is removed. However, in my current board, no error is returned from mmc_card_removed(). I'm guessing it's because of the NULL in the mmc_sd_remove() function in drivers/mmc/core/sd.c , but I'm not sure. I think it was clumsy because I was a newbie unfamiliar with mmc drivers. :) I'll take a closer look. Regards, Kwon