All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Daniel Stone <daniel@fooishbar.org>,
	Alex Deucher <alexdeucher@gmail.com>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
	Arunpravin Paneer Selvam <arunpravin.paneerselvam@amd.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	"Deucher, Alexander" <alexander.deucher@amd.com>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)
Date: Wed, 23 Mar 2022 16:32:11 +0100	[thread overview]
Message-ID: <c41203c8-841b-889f-5c9b-5982ee961849@amd.com> (raw)
In-Reply-To: <CAPj87rPhuVTDJSsY-HsKfvV3xkDhEn7nUd3WLsxNuJD=Mx2Zxg@mail.gmail.com>

Am 23.03.22 um 16:24 schrieb Daniel Stone:
> On Wed, 23 Mar 2022 at 15:14, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone <daniel@fooishbar.org> wrote:
>>> That's not what anyone's saying here ...
>>>
>>> No-one's demanding AMD publish RTL, or internal design docs, or
>>> hardware specs, or URLs to JIRA tickets no-one can access.
>>>
>>> This is a large and invasive commit with pretty big ramifications;
>>> containing exactly two lines of commit message, one of which just
>>> duplicates the subject.
>>>
>>> It cannot be the case that it's completely impossible to provide any
>>> justification, background, or details, about this commit being made.
>>> Unless, of course, it's to fix a non-public security issue, that is
>>> reasonable justification for eliding some of the details. But then
>>> again, 'huge change which is very deliberately opaque' is a really
>>> good way to draw a lot of attention to the commit, and it would be
>>> better to provide more detail about the change to help it slip under
>>> the radar.
>>>
>>> If dri-devel@ isn't allowed to inquire about patches which are posted,
>>> then CCing the list is just a façade; might as well just do it all
>>> internally and periodically dump out pull requests.
>> I think we are in agreement. I think the withheld information
>> Christian was referring to was on another thread with Christian and
>> Paul discussing a workaround for a hardware bug:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Famd-gfx%2Fmsg75908.html&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7C6a3f2815d83b4872577008da0ce1347a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637836458652370599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QtNB0XHMhTgH%2FNHMwF23Qn%2BgSdYyHJSenbpP%2FHG%2BkxE%3D&amp;reserved=0
> Right, that definitely seems like some crossed wires. I don't see
> anything wrong with that commit at all: the commit message and a
> comment notes that there is a hardware issue preventing Raven from
> being able to do TMZ+GTT, and the code does the very straightforward
> and obvious thing to ensure that on VCN 1.0, any TMZ buffer must be
> VRAM-placed.
>
> This one, on the other hand, is much less clear ...

Yes, completely agree. I mean a good bunch of comments on commit 
messages are certainly valid and we could improve them.

But this patch here was worked on by both AMD and Intel developers. 
Where both sides and I think even people from other companies perfectly 
understands why, what, how etc...

When now somebody comes along and asks for a whole explanation of the 
context why we do it then that sounds really strange to me.

Thanks for jumping in here,
Christian.

>
> Cheers,
> Daniel


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Daniel Stone <daniel@fooishbar.org>,
	Alex Deucher <alexdeucher@gmail.com>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
	Arunpravin Paneer Selvam <arunpravin.paneerselvam@amd.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	"Deucher, Alexander" <alexander.deucher@amd.com>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)
Date: Wed, 23 Mar 2022 16:32:11 +0100	[thread overview]
Message-ID: <c41203c8-841b-889f-5c9b-5982ee961849@amd.com> (raw)
In-Reply-To: <CAPj87rPhuVTDJSsY-HsKfvV3xkDhEn7nUd3WLsxNuJD=Mx2Zxg@mail.gmail.com>

Am 23.03.22 um 16:24 schrieb Daniel Stone:
> On Wed, 23 Mar 2022 at 15:14, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone <daniel@fooishbar.org> wrote:
>>> That's not what anyone's saying here ...
>>>
>>> No-one's demanding AMD publish RTL, or internal design docs, or
>>> hardware specs, or URLs to JIRA tickets no-one can access.
>>>
>>> This is a large and invasive commit with pretty big ramifications;
>>> containing exactly two lines of commit message, one of which just
>>> duplicates the subject.
>>>
>>> It cannot be the case that it's completely impossible to provide any
>>> justification, background, or details, about this commit being made.
>>> Unless, of course, it's to fix a non-public security issue, that is
>>> reasonable justification for eliding some of the details. But then
>>> again, 'huge change which is very deliberately opaque' is a really
>>> good way to draw a lot of attention to the commit, and it would be
>>> better to provide more detail about the change to help it slip under
>>> the radar.
>>>
>>> If dri-devel@ isn't allowed to inquire about patches which are posted,
>>> then CCing the list is just a façade; might as well just do it all
>>> internally and periodically dump out pull requests.
>> I think we are in agreement. I think the withheld information
>> Christian was referring to was on another thread with Christian and
>> Paul discussing a workaround for a hardware bug:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Famd-gfx%2Fmsg75908.html&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7C6a3f2815d83b4872577008da0ce1347a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637836458652370599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QtNB0XHMhTgH%2FNHMwF23Qn%2BgSdYyHJSenbpP%2FHG%2BkxE%3D&amp;reserved=0
> Right, that definitely seems like some crossed wires. I don't see
> anything wrong with that commit at all: the commit message and a
> comment notes that there is a hardware issue preventing Raven from
> being able to do TMZ+GTT, and the code does the very straightforward
> and obvious thing to ensure that on VCN 1.0, any TMZ buffer must be
> VRAM-placed.
>
> This one, on the other hand, is much less clear ...

Yes, completely agree. I mean a good bunch of comments on commit 
messages are certainly valid and we could improve them.

But this patch here was worked on by both AMD and Intel developers. 
Where both sides and I think even people from other companies perfectly 
understands why, what, how etc...

When now somebody comes along and asks for a whole explanation of the 
context why we do it then that sounds really strange to me.

Thanks for jumping in here,
Christian.

>
> Cheers,
> Daniel


  reply	other threads:[~2022-03-23 15:32 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23  6:25 [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu Arunpravin Paneer Selvam
2022-03-23  6:25 ` Arunpravin Paneer Selvam
2022-03-23  6:25 ` [Intel-gfx] " Arunpravin Paneer Selvam
2022-03-23  6:42 ` Paul Menzel
2022-03-23  6:42   ` Paul Menzel
2022-03-23  6:42   ` [Intel-gfx] " Paul Menzel
2022-03-23  7:42   ` Christian König
2022-03-23  7:42     ` Christian König
2022-03-23  7:42     ` [Intel-gfx] " Christian König
2022-03-23  8:10     ` Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu) Paul Menzel
2022-03-23  8:10       ` Paul Menzel
2022-03-23  8:10       ` [Intel-gfx] " Paul Menzel
2022-03-23  8:18       ` Christian König
2022-03-23  8:18         ` Christian König
2022-03-23  8:18         ` [Intel-gfx] " Christian König
2022-03-23 14:00         ` Daniel Stone
2022-03-23 14:00           ` [Intel-gfx] " Daniel Stone
2022-03-23 14:42           ` Alex Deucher
2022-03-23 14:42             ` [Intel-gfx] " Alex Deucher
2022-03-23 15:03             ` Daniel Stone
2022-03-23 15:03               ` [Intel-gfx] " Daniel Stone
2022-03-23 15:14               ` Alex Deucher
2022-03-23 15:14                 ` [Intel-gfx] " Alex Deucher
2022-03-23 15:24                 ` Daniel Stone
2022-03-23 15:24                   ` [Intel-gfx] " Daniel Stone
2022-03-23 15:32                   ` Christian König [this message]
2022-03-23 15:32                     ` Christian König
2022-03-24 10:30                     ` [Intel-gfx] " Daniel Vetter
2022-03-24 10:30                       ` Daniel Vetter
2022-03-25 15:56                     ` Commit messages Paul Menzel
2022-03-25 15:56                       ` [Intel-gfx] " Paul Menzel
2022-03-23 15:19           ` Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu) Christian König
2022-03-23 15:19             ` [Intel-gfx] " Christian König
2022-03-23  7:16 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/amdgpu: add drm buddy support to amdgpu (rev2) Patchwork
2022-03-23  7:37 ` [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu Christian König
2022-03-23  7:37   ` [Intel-gfx] " Christian König
2022-03-23  7:37   ` Christian König
     [not found]   ` <MN2PR12MB4342B7FD0CC5C480DEEF8A77E41D9@MN2PR12MB4342.namprd12.prod.outlook.com>
2022-03-29 11:19     ` Arunpravin Paneer Selvam
2022-03-29 11:19       ` Arunpravin Paneer Selvam
2022-03-29 11:19       ` [Intel-gfx] " Arunpravin Paneer Selvam
2022-03-29 11:24       ` Christian König
2022-03-29 11:24         ` Christian König
2022-03-29 11:24         ` [Intel-gfx] " Christian König
2022-03-29 16:00         ` Arunpravin Paneer Selvam
2022-03-29 16:00           ` Arunpravin Paneer Selvam
2022-03-29 16:00           ` [Intel-gfx] " Arunpravin Paneer Selvam
2022-03-29 19:18           ` Arunpravin Paneer Selvam
2022-03-29 19:18             ` Arunpravin Paneer Selvam
2022-03-29 19:18             ` [Intel-gfx] " Arunpravin Paneer Selvam
2022-03-30  6:53             ` Christian König
2022-03-30  6:53               ` Christian König
2022-03-30  6:53               ` [Intel-gfx] " Christian König
2022-03-23 11:26 ` kernel test robot
2022-03-23 11:26   ` [Intel-gfx] " kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c41203c8-841b-889f-5c9b-5982ee961849@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=arunpravin.paneerselvam@amd.com \
    --cc=daniel@fooishbar.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=pmenzel@molgen.mpg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.