> - Marketing can make mistakes or have IT glitches The inconsistent use of > "(TM)" and using a 67C2:00 is something one wants to double-check with them. Marketing names are there for a lot of reasons. The code here is to pass the names only. If you are interested in a vendor's marketing names, please reach out to the vendor, e.g. through your contacts in the vendor who also shares your interest.
>- Having a separate file so that clients can update/edit it does not help >much. Please say it to pci.ids/usb.ids :) > Adding ~200 loc for ~170 devices entries sounds like a step in the wrong > direction. Check the vendor's entries in pci.ids, and you might have some better idea. Sam -----Original Message----- From: Emil Velikov [mailto:[email protected]] Sent: Tuesday, May 30, 2017 7:01 AM To: Li, Samuel <[email protected]> Cc: Alex Deucher <[email protected]>; amd-gfx list <[email protected]>; Yuan, Xiaojie <[email protected]> Subject: Re: [PATCH libdrm v3 1/1] amdgpu: move asic id table to a separate file Hi all, Pardon for dropping in uninvited. Just some food for thought. On 29 May 2017 at 22:01, Li, Samuel <[email protected]> wrote: > Understood your point. However as discussed internally before, marketing > names are there for a lot of reasons; my understanding of the policy is we do > not need to touch them as long as there is no error in the names and they are > allowed to be public. > Samuel, It seems that most comments put forward by people are going on deaf ears. While there may be valid arguments behind doing so, do consider the following: - Review is always encouraged Regardless if the information is within or outside of the source code. - Marketing can make mistakes or have IT glitches The inconsistent use of "(TM)" and using a 67C2:00 is something one wants to double-check with them. - Having a separate file so that clients can update/edit it does not help much. You want to ship the whole driver, in order to have a predictable and consistent user experience. - Adding ~200 loc for ~170 devices entries sounds like a step in the wrong direction. In either case, not my call. I might follow-up with some issues in the code itself ;-) HTH Emil _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
