From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A9BBC433FE for ; Fri, 7 Oct 2022 16:43:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230146AbiJGQnh (ORCPT ); Fri, 7 Oct 2022 12:43:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230112AbiJGQnU (ORCPT ); Fri, 7 Oct 2022 12:43:20 -0400 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA0608F26B; Fri, 7 Oct 2022 09:43:17 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 72D7C3200413; Fri, 7 Oct 2022 12:43:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 07 Oct 2022 12:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1665160995; x= 1665247395; bh=ztA8X0oCOrzYe4bRM5wcVboplj1CUUEIc1ilkn7aa30=; b=q FKLdf9EkUFedxcq0I8GMRLbiWqr6NZQZMGydORi7Kxsl3CqTUS/EjjN9Xh0NrbNK +NMDRdSZIVBmKoVd4EUhYiBPy8CFx2ArnKFSawz5/mNw/o7t0NZt8YdKzX1FPSZ9 XoACLMW9kHSmBH7RBRqEbrTHLTERGlwxXMBFIwmsf5cMv/gF1wbLNdqXT3QCWXAA wcuhZtRxilf6WNmv2J4gDJAXPVZiGVW+Hb1EtlzVvrCVw29qO+944jLstNlWNdU4 zT6J3Hy1k4S+DgDQHpG8NwdnurTBV9AbbCQSF3RrFBm8+HLIedUQEab+5RWc1JyV C6En08tpCZxwX0IPjvceg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1665160995; x= 1665247395; bh=ztA8X0oCOrzYe4bRM5wcVboplj1CUUEIc1ilkn7aa30=; b=V iORmYvI9BZfPe8CCIIT79BNszLMcZOEu8k5emi66xDB2mXe1SiUL4fYcl2u77Uq7 KJQE8U0DHZu1AvhCVOxQGlnqA1S/1r6rsb6/jCuNrBRq2dtjpQBeLxt9NscAeFVG j/Wtfy2+QBYUgKmy8TEdiTHaVA3eF2+6moDmbi4HeTjRgRvCycStZPQURPYjsi2/ 3h1dm9GXa2J01SVcCTgCzHUuwnvXHY9cRN4Mqzt0CxwPOA2c9uQ+3z3DyfLycKpB z66utldH6N8O7jjbDH06go6fzVDezOiqGJeJHsG4tirJAlwr0X1nkwU2Kk8HKYRI H92LOs1gO80mq2FwQsQxw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeijedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtugfgjgesthekredttddtjeenucfhrhhomhepifhr vghgucfmjfcuoehgrhgvgheskhhrohgrhhdrtghomheqnecuggftrfgrthhtvghrnhepgf ekffeifeeiveekleetjedvtedvtdeludfgvdfhteejjeeiudeltdefffefvdeinecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrh horghhrdgtohhm X-ME-Proxy: Feedback-ID: i787e41f1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 7 Oct 2022 12:43:14 -0400 (EDT) Date: Fri, 7 Oct 2022 18:43:56 +0200 From: Greg KH To: Jiaxun Yang Cc: "linux-mips@vger.kernel.org" , linux-kernel@vger.kernel.org, Thomas Bogendoerfer , linux-api@vger.kernel.org, f.fainelli@gmail.com Subject: Re: [PATCH v5] MIPS: Expose prid and globalnumber to sysfs Message-ID: References: <20221007141207.30635-1-jiaxun.yang@flygoat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 07, 2022 at 05:37:34PM +0100, Jiaxun Yang wrote: > > > 在2022年10月7日十月 下午3:52，Greg KH写道： > [...] > >> + > >> +static int cpuregs_cpu_offline(unsigned int cpu) > >> +{ > >> + struct device *dev; > >> + struct cpureg *reg = per_cpu(cpuregs, cpu); > >> + > >> + dev = get_cpu_device(cpu); > >> + if (!dev || !reg) > >> + return -ENODEV; > >> + if (reg->kobj.parent) { > > > > Why are you looking at the parent of a kobject? Why not just always > > remove the kobject if you have a reference to it now? How does the > > parent matter? > > Another dummy copy from Arm64 code... kobject_put should be enough here? Why would it not be enough?