Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3090483pxb; Mon, 24 Jan 2022 02:08:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJzhe28wUPgIl0LFtYYE6RaRnxzTBngVwvqXnc3o8kWTDQs3GNPYKa7OaQnYZXJQg/d0adyu X-Received: by 2002:a17:90a:5896:: with SMTP id j22mr1182704pji.182.1643018880040; Mon, 24 Jan 2022 02:08:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643018880; cv=none; d=google.com; s=arc-20160816; b=V68RJxeQ4w74jfyaIdFKLEYikVNHhaccKHG6xtfsiBxHFqUbxqrhoxbOeUNVORkr+8 SygvSvTAxps4uAzvdkakNrARNuCGxRWxZP35h2CE15NdgHqEGToJ4ZElQ7EoiWzd4EYv YAnumtrRS6s90it+6dMY/vMb+7SF8YlLKrqgfBLNsVfl3DIlsqWd/YUsG9sEZrk3OeyM 7MCzlDbPNHIzqSmAvzUVNt2Vn5SDtGdSdCtSPouA4xixBejMfoKHEgwC493vZ/IUPtGY neTLZH0LsvJa9YErO7kLe40JHjaHgYttAXc4rwqOccdpG1Mox5P7wrJRN1AEvS6xn+ld 9sVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=sGzadtO7ltbbyZOZ1G2t5gM0ilrkTLcuedREJT8kOOQ=; b=Ee5JkaMpDUZfXiGAT5+jgPcF7mGFQ6/2bm39Qq+cZo0qbLGOVZ4/oVGWqsNNgEFCqU jjczx3HJwcdL+sL/p6dhZEC2LJva0qrGMbTFOtFJ/Pg4ZIwrdLjyTsgqF/vAWzU1cIk9 IiZCCUizLuqg+mGwlcU/xi20JPonjR4+n1cDnxqiM0Tza19feVylzmIhRTff2XfIGNjt 2wmr2S9l5OPRYBZNT2cgnQHcnC4cw+JmsRUxWrWMdfcBoLaqsrxJ5AQzgzN/AyEA139Y 5Sxourh07TrdWhkYGW0Krt6xyv13XjLQt7Vxa8AhP69D6qTS0y56MaWEB6E1mBHOUn1o mz9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kV9U4eEn; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a70si9838166pge.522.2022.01.24.02.07.47; Mon, 24 Jan 2022 02:08:00 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kV9U4eEn; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238476AbiAWQMY (ORCPT + 99 others); Sun, 23 Jan 2022 11:12:24 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:43860 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230007AbiAWQMX (ORCPT ); Sun, 23 Jan 2022 11:12:23 -0500 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 ams.source.kernel.org (Postfix) with ESMTPS id CC94CB80DBE for ; Sun, 23 Jan 2022 16:12:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88ADEC340E5 for ; Sun, 23 Jan 2022 16:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642954341; bh=6NtAXxaOwFwMGUS7pA4qLbB/J3E9TF2I6pwG0CRZGdk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kV9U4eEndy8waODpnPzSgx0OPmRS1x/cA4W0KYpLBEFD4Qa5NUG8eyyQuAmNVyLLX agdfECE44Cb2m3A0ysbKuzB8DZodBM+bfYSAI61kATLZcM/7e2skZiVb6iEFton629 Yrmtml0ecSW3OyPKjtCeRHOeml7a44L5KsdDEhU01Ji5kJVaP8uVg17kgQKhergpNi kvyaL2tjMN+SV+xXEBRCaKX3GQpNcoem4Iz1w/BgU/4stv/ZwTr0cY+flW0bA+uljd wjZNkcAn6EEH4QZ3FvZOJ6pkcOCgvD51POIbePCQRCsBvA3s3kD8bJlkr7Gt5dxKeO pHY/X+P350oOA== Received: by mail-yb1-f178.google.com with SMTP id 23so43441324ybf.7 for ; Sun, 23 Jan 2022 08:12:21 -0800 (PST) X-Gm-Message-State: AOAM530xL4AHedKsscXTKwvuZflpC0BObWvN9v042AKV/lXr+AKQBw9I wow5TUrGnKkII4cZekiNsaPDyEO/5Z+qMekXSas= X-Received: by 2002:a5b:20c:: with SMTP id z12mr17156535ybl.64.1642954340637; Sun, 23 Jan 2022 08:12:20 -0800 (PST) MIME-Version: 1.0 References: <20220111114724.7987-1-cai.huoqing@linux.dev> In-Reply-To: From: Oded Gabbay Date: Sun, 23 Jan 2022 18:11:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] habanalabs: Remove unused enum member DMA_SRAM_TO_SRAM To: Greg Kroah-Hartman Cc: Cai Huoqing , Arnd Bergmann , "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 23, 2022 at 6:08 PM Greg Kroah-Hartman wrote: > > On Sun, Jan 23, 2022 at 06:01:53PM +0200, Oded Gabbay wrote: > > On Sun, Jan 23, 2022 at 5:04 PM Greg Kroah-Hartman > > wrote: > > > > > > On Sun, Jan 23, 2022 at 04:43:15PM +0200, Oded Gabbay wrote: > > > > On Tue, Jan 11, 2022 at 1:47 PM Cai Huoqing wrote: > > > > > > > > > > The driver don't support the SRAM-to-SRAM translation of DMA, > > > > > so remove 'DMA_SRAM_TO_SRAM'. > > > > > > > > > > Signed-off-by: Cai Huoqing > > > > > --- > > > > > drivers/misc/habanalabs/include/goya/goya_packets.h | 1 - > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > diff --git a/drivers/misc/habanalabs/include/goya/goya_packets.h b/drivers/misc/habanalabs/include/goya/goya_packets.h > > > > > index ef54bad20509..25fbebdc6143 100644 > > > > > --- a/drivers/misc/habanalabs/include/goya/goya_packets.h > > > > > +++ b/drivers/misc/habanalabs/include/goya/goya_packets.h > > > > > @@ -36,7 +36,6 @@ enum goya_dma_direction { > > > > > DMA_SRAM_TO_HOST, > > > > > DMA_DRAM_TO_HOST, > > > > > DMA_DRAM_TO_DRAM, > > > > > - DMA_SRAM_TO_SRAM, > > > > > DMA_ENUM_MAX > > > > > }; > > > > > > > > > > -- > > > > > 2.25.1 > > > > > > > > > > > > > This is a general spec file in our s/w stack, and therefore a change > > > > in it in the driver will cause our driver to be out of sync with our > > > > user-space stack. i.e. the value of DMA_ENUM_MAX will be different in > > > > the driver and in the user-space stack. I don't know if there will be > > > > any consequences but I prefer not to risk it. > > > > > > If this is synced to userspace, shouldn't it be in a uapi file with a > > > specific value associated with it? > > > > > > thanks, > > > > > > greg k-h > > > > Yes, it was a mistake from day 1. A mistake we didn't repeat in future ASICs. > > I take great care of putting anything that is synced between driver > > and userspace in our uapi file. > > > > Having said that, after almost 3 years of having this mistake, I feel > > it is not too disastrous to leave it as is. > > Our Goya s/w stack is pretty much stable and I don't want to make > > changes without good reason. > > You should just move this to a uapi file to show that it is something > that can't be changed. Can't you do that without breaking anything on > the kernel side? On the kernel side there isn't any problem with moving it. What I'm afraid of, is that the userspace will now have a duplicate definition of this enum. Both in the original file, which is included in the user space stack from day 1, and from our uapi file. In short, I'm afraid of breaking its compilation. If you think that's acceptable, I don't have a problem moving it. > > Otherwise maintaining this is going to be hard as no one has a clue that > this is a value that userspace uses. I can document it with a BIG comment in the file. And as I said, Goya s/w stack is pretty much fixed and I don't believe is going to change anymore. Oded > > thanks, > > greg k-h