Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1127413pxb; Wed, 6 Apr 2022 09:20:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtc6IswWeSespbyUbapzgRMCH7v7KSCxKlg0x2JNuM02Vc1GpcUQHXttevPfXxLDXZPV9D X-Received: by 2002:a17:902:a40f:b0:14b:61:b19e with SMTP id p15-20020a170902a40f00b0014b0061b19emr9506202plq.20.1649262009271; Wed, 06 Apr 2022 09:20:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649262009; cv=none; d=google.com; s=arc-20160816; b=sc9yGjs9ggCg8vAi6mA06D68cwqktFChxj8eZNNJvM4iM67hT0fDoktZcJsRQkfB+I 1ATmG2bc6/mmlfJm1hyqfBTa84hWGmiyvmo6af3SQvuKui5BYiWBK/bQsAOdwbsPRyvG rVdYdYlyTW8sHCwL+r5qYoFU7IYX75rjbsNPKtMyQSku3GKveXHy261KP0f/wnhOcDEK eBIRCPFFF2GvEDIaxy1BvwvSxijB5CuEo1x7fekJjYlKjLNIrUVGdHUoub0+QEx0001i WqImhuxPC75E85j0Ib+T4TqL58/TznbuT6ilvp/Ru6C/Hjx8XiurkcuxpmDJ8taIhz57 QvSQ== 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=xusxtaIjNVje7kIAPhVOZ5p+5hisSYWMbwUvNtg+Rs4=; b=ueuy13mfmhEDGG267mr6PW+QPYg8QXL2ZHTxlwe6MWzPnESYwct+uvqrP3VvtywdUs etdC3RAIkXNo4iCTF+TfobyeTGJXyUIPwOZPt/pxgbPK0dp4sIUHmH8J26kn/8tvNxwU uAaATn0kyks1E1cAuHeFMs+byHzvCaERweMc1/E40PU9uKXboRkqH9/suGsRnYP+v+KO Y7NC3yJJc2W6CLKQXKGPg4q2pbCaTqWTex0WfsP5mgOJLijBlPPp84b58Hi5vh98JfK6 Uty2LEuP5f7N2ljvSU9EJA+/y148jVpwPItRIuZ62aqy8KIS10U4Wc5IKsr7uhoS6Bol vgog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=BOM0ZDDk; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id u4-20020a17090a6a8400b001c7cd11486bsi4936792pjj.175.2022.04.06.09.20.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 09:20:09 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=BOM0ZDDk; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 52C243ABBD3; Wed, 6 Apr 2022 08:18:05 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235682AbiDFPS5 (ORCPT + 99 others); Wed, 6 Apr 2022 11:18:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236219AbiDFPRw (ORCPT ); Wed, 6 Apr 2022 11:17:52 -0400 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47F9A4027AE for ; Wed, 6 Apr 2022 05:18:01 -0700 (PDT) Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 236CHNtS107207; Wed, 6 Apr 2022 07:17:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1649247443; bh=xusxtaIjNVje7kIAPhVOZ5p+5hisSYWMbwUvNtg+Rs4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=BOM0ZDDkKKGjAqOP2Mqp13aY5ZF5LUN6kSdO3CNXayceuP1ldCdlBLK4anw9Yqs7w vXLMyPUOodcPQsGrfYfG3KR9N8DSlf+nuI5kITXL4xR/u4fCtlqLdFHBo/3/Tydqp2 zkyak3B5LbIFWxkKD/TA7yv6EMGMKRH49Mjz095A= Received: from DLEE115.ent.ti.com (dlee115.ent.ti.com [157.170.170.26]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 236CHMMG100974 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 6 Apr 2022 07:17:23 -0500 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Wed, 6 Apr 2022 07:17:22 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Wed, 6 Apr 2022 07:17:22 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 236CHLBE113571; Wed, 6 Apr 2022 07:17:22 -0500 Date: Wed, 6 Apr 2022 17:47:21 +0530 From: Pratyush Yadav To: CC: , , , , , , Subject: Re: [PATCH v2 4/4] mtd: spi-nor: sfdp: Keep SFDP definitions private Message-ID: <20220406121721.j6wlbzxher4xhtba@ti.com> References: <20220309144215.179449-1-tudor.ambarus@microchip.com> <20220309144215.179449-5-tudor.ambarus@microchip.com> <20220401200133.gyyvoe7xdbsww7cv@ti.com> <20220405193111.pnekaivbsj7hronp@ti.com> <1fa079c4a0341ffe6ad7bdebd3cb8958@walle.cc> <16af88ad-52ea-4ed7-782b-eba28325bf0c@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <16af88ad-52ea-4ed7-782b-eba28325bf0c@microchip.com> X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 06/04/22 11:10AM, Tudor.Ambarus@microchip.com wrote: > On 4/6/22 13:31, Michael Walle wrote: > > > >>> That's correct, but I think exposing just the public defines in sfdp.h > >>> is > >>> the path to follow. We should keep private all the definitions that we > >>> can > >>> private in sfdp.c and expose publicly in sfdp.h just the ones that are > >>> shared. > >>> Flash collisions, and implicitly the need of public SFDP definitions, > >>> should be > >>> an exception, so I expect sfdp.h to be short in size. > >> > >> I disagree. I think we should keep everything in the same place. And > >> since we need to expose this to manufacturer drivers, that place is > >> sfdp.h. Who is going to cast the tiebreaking vote here? ;-) > > > > I'm leaning towards Pratyush opinion unless there is a clear advantage > > to move the defines. > > Okay. Then we should move all the table definitions to sfdp.h, right? We don't pass any other table to manufacturer drivers. Only BFPT. So those can stay private. But I don't mind either in this case. -- Regards, Pratyush Yadav Texas Instruments Inc.