Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp2630006rwb; Fri, 20 Jan 2023 05:33:39 -0800 (PST) X-Google-Smtp-Source: AMrXdXtIFF5K5KPrWXrMW88zG2DDliyKU2coa/f4yCBIt2kqX+JJG5AuDkn7dkDMsSXwRHBt/ssB X-Received: by 2002:a17:907:bb99:b0:877:839c:bd54 with SMTP id xo25-20020a170907bb9900b00877839cbd54mr5285772ejc.5.1674221618902; Fri, 20 Jan 2023 05:33:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674221618; cv=none; d=google.com; s=arc-20160816; b=INjfIKacPJlCMKczbdXvHmzh9xVnNIyJ6/DjY+nu4WD4LaMbJUrrbAp1MdZ0x7hcFM AvR+E+O3eD8j1jqS/NxdkrINoadtCFEzncECAruqzuQ5J6EsFzzaIYKE5hlYH+l8w/f2 9Kh/J1AaL+ETtMUZkKUbMYdPSIOYDDW3Qe+fM1WOOaHAWJ8mc7qIiusu0G5VQ0hawDUV GZinyJbnTN+6lPLF/07GFFR2zYt7GBptn5k7d4qYmxBvIfhOI0Gi2MzXi1D6I0pUEYPI vXUJDEdKyj5rlIdwwwYT1dG8inLQQ66CFKNw4k9gzLxjylhNFDO3htQCZmcuXNfOp6Ck eNrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=prJc7+q9ZCv21AxQq0DthFOBD1g+JSRrYs74BZLv3Gs=; b=FdyBzQIUfB/dHibZOSjd2o2B4EoRYBOg+5jaCIAx7PZzpOiMLRe3f0vQwbkLEvwu2N hzLcdyVwargCxHqHLEtN1aXukI/YEobbzZ8nBU2waScjhiBO4BbQykhfB1UxzXxpcROZ JLsaFfwnhQAYHr+dJZPaqZ4AcgF944EjKZXsuMf5MzgRnCbOoL/vpnB/IctLiVoOHE7l Ks7719pBs6j0q04S6sTL58wpBIRZSA9kLH78vbr5yqp8Bjzhn4Cyb6Siz5q5bbgD0Kka 8l6RLYG6hkxWLjbzncgFjRay0aAmxQrID2d6d6HWA+x9mADtY3KoBqM5yJPAmAWgh3UY +wPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LQHKiHy5; 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=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xi8-20020a170906dac800b007c10bb4eaabsi21924770ejb.156.2023.01.20.05.33.26; Fri, 20 Jan 2023 05:33:38 -0800 (PST) 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=@linuxfoundation.org header.s=korg header.b=LQHKiHy5; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229790AbjATNTK (ORCPT + 49 others); Fri, 20 Jan 2023 08:19:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231138AbjATNSf (ORCPT ); Fri, 20 Jan 2023 08:18:35 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B72E5C41E7 for ; Fri, 20 Jan 2023 05:14:54 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 82AE1CE285B for ; Fri, 20 Jan 2023 13:14:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F275C433B3; Fri, 20 Jan 2023 13:14:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1674220490; bh=l377cVSCj6UHp5jGDRUigM1l/sWippbUo+6Sc1sWSvM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LQHKiHy5wsM0n5EUwROjHeL+qz8bSnTdd8qdv0H+zwJLOOKk75i1BJvpzVyP8/lcx BEo1NCP7pIu55J3FNR67skt6txWVcokT/NmCgXAU7yl2hM4SluLRuH0AVWj0k+pTf0 0XYNSjv/CJ0FK5HvCkECFfCS/cXxKzQieKVkjhJs= Date: Fri, 20 Jan 2023 14:14:48 +0100 From: Greg KH To: Gavin Shan Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@redhat.com, osalvador@suse.de, rafael@kernel.org, shan.gavin@gmail.com Subject: Re: [PATCH 2/2] drivers/base/memory: Use array to show memory block state Message-ID: References: <20230120055727.355483-1-gshan@redhat.com> <20230120055727.355483-3-gshan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230120055727.355483-3-gshan@redhat.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 Fri, Jan 20, 2023 at 01:57:27PM +0800, Gavin Shan wrote: > Use an array to show memory block state from '/sys/devices/system/ > memory/memoryX/state', to simplify the code. > > No functional change intended. > > Signed-off-by: Gavin Shan > --- > drivers/base/memory.c | 25 ++++++------------------- > 1 file changed, 6 insertions(+), 19 deletions(-) > > diff --git a/drivers/base/memory.c b/drivers/base/memory.c > index b456ac213610..9474f25c452c 100644 > --- a/drivers/base/memory.c > +++ b/drivers/base/memory.c > @@ -141,28 +141,15 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr, > char *buf) > { > struct memory_block *mem = to_memory_block(dev); > - const char *output; > + static const char *const mem_state_str[] = { > + NULL, "online", "going-offline", NULL, "offline", > + }; > > - /* > - * We can probably put these states in a nice little array > - * so that they're not open-coded > - */ > - switch (mem->state) { > - case MEM_ONLINE: > - output = "online"; > - break; > - case MEM_OFFLINE: > - output = "offline"; > - break; > - case MEM_GOING_OFFLINE: > - output = "going-offline"; > - break; > - default: > - WARN_ON(1); > + if (WARN_ON(mem->state >= ARRAY_SIZE(mem_state_str) || > + !mem_state_str[mem->state])) Ick, the whole WARN_ON() should just be removed please. We don't want to reboot any systems if this changed incorrectly. Please fix this up to properly handle this and keep going on, don't mess with WARN_ON() anymore in code that can recover properly. thanks, greg k-h