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 89B90D2FFE6 for ; Fri, 18 Oct 2024 10:29:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To: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=f5lubNeeLRmHthC4s9tNZn8PtHhfCx2MwTc3L+mSp18=; b=S+n8WhjnyFLwEr5Xjk+ECwjm+x bHEbbSWama7W9119krbxRF03ZWoWYcDOKwiHJt650bAzXEqHPw3Tt1TpVGcmm9d3lmcTF6dP0Cj8u Ryl1kcA4caBpvOVlr64bCsyfFvZp6xAjyQFiVmWaa5PLvMDtgSqt23Yn9IxB7SsQ7A3o+zJ9k6oV3 JwhdJRZ76rWVj049QsWrglWjH0mdcHDUV3gRr1Fs+drC4sPGhj+ILSdEpZKVF1bq8Bc2TF175trUb 1FIpiUORlrRxJSkUPzhpyivOP4JzqYGkVmUXRSuuDTb7teS0sVV/Zn6Auls5o5HrGJ5tCRUKzeAEt bs6ycE0w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1kEX-00000000N95-27oY; Fri, 18 Oct 2024 10:29:25 +0000 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t1jmd-00000000HJo-3QAH for linux-arm-kernel@lists.infradead.org; Fri, 18 Oct 2024 10:00:37 +0000 Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-20c693b68f5so21073305ad.1 for ; Fri, 18 Oct 2024 03:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729245635; x=1729850435; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=f5lubNeeLRmHthC4s9tNZn8PtHhfCx2MwTc3L+mSp18=; b=eGshoQW5jTcrRrSyJBB/+iIFEwXf+DgeHp3eBXG8/HOnGGTS+KaukSloTKczUJ081n vSKrvCoymZuJtgn4ToutrffLCotVABIhoV8npLNdw8mhQBs2nc7J0ed5pIkHmB7fKxuK CyYA/OZvQbGXrczdpyWp3bJwqNs6eDOEbIa0Us0VxGTI5BeTXTZAnL1T+eOZaQDvWcs7 h3+vrGyeX/RRSOWW6OUXtcPPzARDFNHNHjE6LvPmZD4kMyC/VYmdDNEHfMkGSP6/Rg2/ QZmZJ437PaS6P5PzFrYxQuonnjuKLM/7BNcpEFrCSxnamqXe9mAucLtSKPBs34WVaKj/ 9+3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729245635; x=1729850435; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=f5lubNeeLRmHthC4s9tNZn8PtHhfCx2MwTc3L+mSp18=; b=sR3Khm/CpwJdYIL3K74hFbv4FNPWm4FNjS+m9l4/jprhjAetapHiBoS8QX9xpwcKbR VGGxBI+eFXn1JOZVMaQqqqXbBG7mNuhljzxGX+O/qDga32ybt0GPCnNMIcblXeH/xw2t FNALPdq1MeBSoHuZ1nlg+AzdAVRXzl938VT7agaM0xeSAWzUih6asCGsk/2VzILFDz2b 8M4gjHOFI2yCEge4s54q9Oe8H4QsTC8TxNe8Ryw4A1rLJKRScpRPQ1RO4MuxKWGQxAWY Y5aCf4YgDvs9oW0J9lT5Gzz0deN7V6C53O4xer6nVYw6m0Wci3tNGgBBXMzsPskS/8zV T87g== X-Forwarded-Encrypted: i=1; AJvYcCUCxwaof+IKN6CpISFGm3TbzFBDRkwDMQkmp/68nALzVDPl5h2UX4aPgaa3F0GhM3PO0gNXWPpXWoyzv5eu6ye2@lists.infradead.org X-Gm-Message-State: AOJu0YwrneSGqA+8im+IIB1uZ0Tl3Jzigqj546YvQ3eYJXget4iwAGmu WhEcGvAgFMcgGIfgkR8DFYOB+iTqQaCfh5gjPuw7wbPmSULSmtxb X-Google-Smtp-Source: AGHT+IFR6ppSFGXKnbyyRbTLquP9bQee0BM/QDbaB/L3oOWSNl9Ejff+zHPGZ4gjWD8RwNrZRPZWrQ== X-Received: by 2002:a17:902:f60e:b0:20b:ab4b:5432 with SMTP id d9443c01a7336-20e5a70d59amr22619825ad.12.1729245634446; Fri, 18 Oct 2024 03:00:34 -0700 (PDT) Received: from localhost ([129.146.253.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20e5a8d6cd6sm9343225ad.131.2024.10.18.03.00.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2024 03:00:34 -0700 (PDT) Date: Fri, 18 Oct 2024 18:00:23 +0800 From: Furong Xu <0x1207@gmail.com> To: Vladimir Oltean Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Andrew Lunn , Simon Horman , Serge Semin , Alexandre Torgue , Jose Abreu , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , xfr@outlook.com Subject: Re: [PATCH net-next v2 7/8] net: stmmac: xgmac: Complete FPE support Message-ID: <20241018180023.000045d8@gmail.com> In-Reply-To: <20241018091321.gfsdx7qzl4yoixgb@skbuf> References: <1776606b2eda8430077551ca117b035f987b5b70.1729233020.git.0x1207@gmail.com> <20241018091321.gfsdx7qzl4yoixgb@skbuf> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241018_030035_895710_92050302 X-CRM114-Status: GOOD ( 17.84 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 18 Oct 2024 12:13:21 +0300, Vladimir Oltean wrote: > This is much better in terms of visibility into the change. > > Though I cannot stop thinking that this implementation design: > > stmmac_fpe_configure() > -> stmmac_do_void_callback() > -> fpe_ops->fpe_configure() > / \ > / \ > v v > dwmac5_fpe_configure dwxgmac3_fpe_configure > \ / > \ / > v v > common_fpe_configure() > > is, pardon the expression, stuffy. > > If you aren't very opposed to the idea of having struct stmmac_fpe_ops > contain a mix of function pointers and integer constants, I would > suggest removing: > > .fpe_configure() > .fpe_send_mpacket() > .fpe_irq_status() > .fpe_get_add_frag_size() > .fpe_set_add_frag_size() > > and just keeping a single function pointer, .fpe_map_preemption_class(), > inside stmmac_fpe_ops. Only that is sufficiently different to warrant a > completely separate implementation. Then move all current struct > stmmac_fpe_configure_info to struct stmmac_fpe_ops, and reimplement > stmmac_fpe_configure() directly like common_fpe_configure(), > stmmac_fpe_send_mpacket() directly like common_fpe_send_mpacket(), etc etc. > This lets us avoid the antipattern of calling a function pointer (hidden > by an opaque macro) from common code, only to gather some parameters to > call again a common implementation. > > I know this is a preposterous and heretic thing to suggest, but a person > who isn't knee-deep in stmmac has a very hard time locating himself in > space due to the unnecessarily complex layering. If that isn't something > that is important, feel free to ignore. In fact, I can drop the stmmac_fpe_ops at all, avoid the antipattern of calling a function pointer for good. Since this is a new module, we can try something new ;) Thanks.