Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Wed, 6 Apr 2022 01:01:11 +0530
From:   Pratyush Yadav <p.yadav@ti.com>
To:     <Tudor.Ambarus@microchip.com>
CC:     <michael@walle.cc>, <miquel.raynal@bootlin.com>, <richard@nod.at>,
        <vigneshr@ti.com>, <linux-mtd@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, <Nicolas.Ferre@microchip.com>
Subject: Re: [PATCH v2 4/4] mtd: spi-nor: sfdp: Keep SFDP definitions private
Message-ID: <20220405193111.pnekaivbsj7hronp@ti.com>
References: <20220309144215.179449-1-tudor.ambarus@microchip.com>
 <20220309144215.179449-5-tudor.ambarus@microchip.com>
 <20220401200133.gyyvoe7xdbsww7cv@ti.com>
 <ed093fa5-b514-b0a6-166f-ecf117582b0b@microchip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ed093fa5-b514-b0a6-166f-ecf117582b0b@microchip.com>
Precedence: bulk

On 04/04/22 06:19AM, Tudor.Ambarus@microchip.com wrote:
> On 4/1/22 23:01, Pratyush Yadav wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On 09/03/22 04:42PM, Tudor Ambarus wrote:
> >> Keep the SFDP definitions private and expose just the definitions that are
> >> required by the core and manufacturer drivers.
> > 
> > I am not so sure about this. Since the post_bfpt hook passes in the bfpt
> > table to flash drivers, they might end up wanting to use these for some
> > checks like issi.c does for DWORD 1. They would have to move them back
> > to sfdp.h for that, which just causes extra churn, and also puts some
> > BFPT related defines in sfdp.h and some in sfdp.c.
> > 
> 
> 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? ;-)

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.