Hi, > > (no changes since v1) > > I think you need to work on the method you're using to generate your > patches. There are most definitely changes since v1. You described > them in your cover letter (which you don't really need for a singleton > patch) instead of here. I agree, this was not intentional, I will fix this in the upcoming patches. On Thu, Dec 3, 2020 at 7:34 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Thu, Dec 3, 2020 at 3:33 AM Rakesh Pillai <pillair@xxxxxxxxxxxxxx> wrote: > > > > > What I'm trying to say is this. Imagine that: > > > > > > a) the device tree has the "variant" property. > > > > > > b) the BRD file has two entries, one for "board-id" (1) and one for > > > "board-id + chip-id" (2). It doesn't have one for "board-id + chip-id > > > + variant" (3). > > > > > > With your suggestion we'll see the "variant" property in the device > > > tree. That means we'll search for (1) and (3). (3) isn't there, so > > > we'll pick (1). ...but we really should have picked (2), right? > > > > Do we expect board-2.bin to not be populated with the bdf with variant field (if its necessary ?) > > The whole fact that there is a fallback to begin with implies that > there can be a mismatch between the board-2.bin and the device tree > file. Once we accept that there can be a mismatch, it seems good to > try all 3 fallbacks in order. > > > Seems fine for me, if we have 2 fallback names if that is needed. > OK, sounds good. So hopefully Abhishek can post a v3 based on what's > in <https://crrev.com/c/2556437> and you can confirm you're good with > it there? I agree, with this patch there can be mismatch between what's provided in the Board file and what required board name we are generating, so three calls are needed. So in a sense, we want to keep the V1 patch with fix to reuse the same BDF. I am making V3 changes and will address and push that out. Thanks Abhishek
