> On 7/16/20 8:48 PM, Wu, Hao wrote: > >> Subject: Re: [PATCH 0/2] Modularization of DFL private feature drivers > >> > >> Generally i think this is a good approach. > >> > >> However I do have concern. > >> > >> The feature_id in dfl is magic number, similar to pci id but without a > vendor > >> id. > >> > >> Is it possible to add something like a vendor id so different vendors would > >> not have to be so careful to use a unique id ? > > Hi Tom, > > > > Thanks for the comments. > > > > Here is only one field defined in spec, that is feature id to distinguish one > > feature with another one. There is no vendor id here I think, and several > > cards are using this for now and seems not possible to change DFH format > > for these products. : ( > > There looks like some unused bits in the first word, how about > > #define DFH_EOL BIT_ULL(40) /* End of list */ > > +define DFH_VENDOR GENMAKE_ULL(49,41) /* Vendor ID */ > > #define DFH_TYPE GENMASK_ULL(63, 60) /* Feature type */ > > And Intel gets id 0. > > > > > I fully understand the concern is the feature id management, and potential > > conflicts there from different vendors. One possible method to resolve this > > is managing the ids in a public place (web? Or just the driver header file for > > feature id definition), all vendors can request some feature ids, and other > > people can see which feature ids have been used so that they can avoid > > using conflict ones with other people. > > The conflict will come in development when two vendors use the same > unpublished feature id. > > Also keeping the truth of id's in the kernel source isn't that great because the > public kernel always lags development repositories. I fully understand your point, and it's a good idea to me, but I am not sure if we can update the spec for DFHv0 at this moment. Let me check with spec owner about this. Actually I believe we don't want to add anything in driver code which is not defined in the spec at all. : ( > > > > > And in the later version DFH, this feature id will be replaced with GUID > > I think, so it can resolve the conflict problems from different vendors? > > But now, we still need to handle the existing ones. : ) > > This is why I proposed needing to generalize the matching. Personally I prefer that we can have standard matching functions per DFH specs. Yilun, how do you think about this? Thanks Hao
