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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B16D0E7D240 for ; Tue, 26 Sep 2023 07:01:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7e71GP1Cfp+DA1yawA5Mg6nt1mj2x5/QJjQpjksaRUM=; b=B7hdsUtVo3tjPB BkOZADB63M5oyoQFE7RxP8h7/IGeNmsjwUDgr1TcOgIiZ575Qs/u9olVdjMgwapbMuvl19OCQPqnl DIpVbhXLCtckD0rYEnH1QxX+Hy01zMx1AJ6LW6aZVN8RmMmdDhV9h+o1eRnwLln3mS3kbbeeDA1ya ZTvAJGMBADi/khpY8lvh/YIVPUiYDDPhmwIOE/ThGPcEw/atadK+eKjgFSmCbvCW77lP+ocgOieZR sWktazof3qsUmBOZJK8Ki2x0giiV3llc7FdF8YZ4MDAEQRDLV0VOi/xRCsIzw1PcoLMyGgMrm9q43 cjs2Ey26mgTrX1qCNR6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ql246-00FlHA-1v; Tue, 26 Sep 2023 07:01:03 +0000 Received: from mail-pf1-f180.google.com ([209.85.210.180]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ql243-00FlFj-0J for linux-arm-kernel@lists.infradead.org; Tue, 26 Sep 2023 07:01:00 +0000 Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-690bf8fdd1aso6222624b3a.2 for ; Tue, 26 Sep 2023 00:00:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695711653; x=1696316453; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uR0xWP82gOq4UfhGc/Rjgf6bHjjZPrvgKTMMsFTyoXc=; b=R7uLw74+wvFgdiIPY8u14Rc2NSZBhvgDAdy+tEOl+G5LwGGhj7miiOJnBOxgtyLs2x 8wJPz0MEFPhWejkSQmSXxapcCtqYbT6/Z65O6FYc3Q7UyNwmzLSdIEPpXWnifE7QaxW/ omtFa93EP4h5Ku1dkK6cwGjisiiEh3tNCpQ0uRKPysaV05BjSkA44dOoup93Otg++aCo A7G4sd9fN9h29tisEcadNIBoa8NbJmULHZgVbVhz3Xp8a5zMy1RgpMIP/zf0swPGp+gB XrXuy7+glxISgZHbVGNsz2Es0V2bqygY2tva1Oe4yCFJkvcMuHylCjEGprS1ogwg0YA6 6XFQ== X-Gm-Message-State: AOJu0YwFKoG3AiHF8PreXaMvEeiPVAwvdfHh58Y7k4hbtP38IPXqF4Vr 1BExkv4IEruVooAHEqkSkoI= X-Google-Smtp-Source: AGHT+IG7reiq4YR2nW+K3Ubyh0wSSTKINIDXIAk+Q1Yd5ato0Gf272jWIsPO/R5L/eqwd1TqnYIetw== X-Received: by 2002:a05:6a20:8e08:b0:15a:836:7239 with SMTP id y8-20020a056a208e0800b0015a08367239mr8319847pzj.11.1695711653490; Tue, 26 Sep 2023 00:00:53 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([20.69.120.36]) by smtp.gmail.com with ESMTPSA id jk13-20020a170903330d00b001b9da8b4eb7sm4710872plb.35.2023.09.26.00.00.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 00:00:53 -0700 (PDT) Date: Tue, 26 Sep 2023 07:00:51 +0000 From: Wei Liu To: Greg KH Cc: Wei Liu , Nuno Das Neves , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, patches@lists.linux.dev, mikelley@microsoft.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, apais@linux.microsoft.com, Tianyu.Lan@microsoft.com, ssengar@linux.microsoft.com, mukeshrathor@microsoft.com, stanislav.kinsburskiy@gmail.com, jinankjain@linux.microsoft.com, vkuznets@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, will@kernel.org, catalin.marinas@arm.com Subject: Re: [PATCH v3 15/15] Drivers: hv: Add modules to expose /dev/mshv to VMMs running on Hyper-V Message-ID: References: <1695407915-12216-1-git-send-email-nunodasneves@linux.microsoft.com> <1695407915-12216-16-git-send-email-nunodasneves@linux.microsoft.com> <2023092342-staunch-chafe-1598@gregkh> <2023092630-masculine-clinic-19b6@gregkh> <2023092614-tummy-dwelling-7063@gregkh> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2023092614-tummy-dwelling-7063@gregkh> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230926_000059_133935_6572DD9F X-CRM114-Status: GOOD ( 28.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 26, 2023 at 08:31:03AM +0200, Greg KH wrote: > On Tue, Sep 26, 2023 at 05:54:34AM +0000, Wei Liu wrote: > > On Tue, Sep 26, 2023 at 06:52:46AM +0200, Greg KH wrote: > > > On Mon, Sep 25, 2023 at 05:07:24PM -0700, Nuno Das Neves wrote: > > > > On 9/23/2023 12:58 AM, Greg KH wrote: > > > > > Also, drivers should never call pr_*() calls, always use the proper > > > > > dev_*() calls instead. > > > > > > > > > > > > > We only use struct device in one place in this driver, I think that is the > > > > only place it makes sense to use dev_*() over pr_*() calls. > > > > > > Then the driver needs to be fixed to use struct device properly so that > > > you do have access to it when you want to print messages. That's a > > > valid reason to pass around your device structure when needed. > > > > Greg, ACRN and Nitro drivers do not pass around the device structure. > > Instead, they rely on a global struct device. We can follow the same. > > A single global struct device is wrong, please don't do that. > > Don't copy bad design patterns from other drivers, be better :) > If we're working with real devices like network cards or graphics cards I would agree -- it is easy to imagine that we have several cards of the same model in the system -- but in real world there won't be two hypervisor instances running on the same hardware. We can stash the struct device inside some private data fields, but that doesn't change the fact that we're still having one instance of the structure. Is this what you want? Or do you have something else in mind? Thanks, Wei. > thanks, > > greg k-h > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel