| Message ID | 20180531162615.GA5200@ldmartin-desk.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: >> Virtualized non-PCH systems such as Broxton or Geminilake should use >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a >> specific case to indicate a PCH system without south display. > > Then let's go ahead and document it? Please avoid sending suggestion patches in-reply-to existing series. This confused patchwork and screwed up CI for the series, which was already a resend just to get CI. :( I'm resending the series, with your documentation patch added, but I'm keeping the extra explanatory text in the last patch. I think it's warranted. BR, Jani. > > ------------- > Subject: [PATCH] drm/i915: document PCH_NOP > > There's a difference between PCH_NONE and PCH_NOP: the former means we > don't have a PCH while in the latter we do, but it doesn't have the > south display. > > Cc: Jani Nikula <jani.nikula@intel.com> > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> > --- > drivers/gpu/drm/i915/i915_drv.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 72150f89f200..aa395a898258 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -631,7 +631,7 @@ enum intel_pch { > PCH_KBP, /* Kaby Lake PCH */ > PCH_CNP, /* Cannon Lake PCH */ > PCH_ICP, /* Ice Lake PCH */ > - PCH_NOP, > + PCH_NOP, /* PCH without south display */ > }; > > enum intel_sbi_destination {
On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula <jani.nikula@intel.com> wrote: > > On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > >> Virtualized non-PCH systems such as Broxton or Geminilake should use > >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > >> specific case to indicate a PCH system without south display. > > > > Then let's go ahead and document it? > > Please avoid sending suggestion patches in-reply-to existing > series. This confused patchwork and screwed up CI for the series, which > was already a resend just to get CI. :( ugh, sorry. Sometimes just adding a oneline diff is much better than a hundred words explaining :( ... IMO pw is trying to be smarter than it should here or not being smart enough. Nonetheless I won't do that anymore. Lucas De Marchi > > I'm resending the series, with your documentation patch added, but I'm > keeping the extra explanatory text in the last patch. I think it's > warranted. > > BR, > Jani. > > > > > > ------------- > > Subject: [PATCH] drm/i915: document PCH_NOP > > > > There's a difference between PCH_NONE and PCH_NOP: the former means we > > don't have a PCH while in the latter we do, but it doesn't have the > > south display. > > > > Cc: Jani Nikula <jani.nikula@intel.com> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> > > --- > > drivers/gpu/drm/i915/i915_drv.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > > index 72150f89f200..aa395a898258 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -631,7 +631,7 @@ enum intel_pch { > > PCH_KBP, /* Kaby Lake PCH */ > > PCH_CNP, /* Cannon Lake PCH */ > > PCH_ICP, /* Ice Lake PCH */ > > - PCH_NOP, > > + PCH_NOP, /* PCH without south display */ > > }; > > > > enum intel_sbi_destination { > > -- > Jani Nikula, Intel Open Source Graphics Center
On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula <jani.nikula@intel.com> wrote: >> >> On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a >> >> specific case to indicate a PCH system without south display. >> > >> > Then let's go ahead and document it? >> >> Please avoid sending suggestion patches in-reply-to existing >> series. This confused patchwork and screwed up CI for the series, which >> was already a resend just to get CI. :( > > ugh, sorry. Sometimes just adding a oneline diff is much better than > a hundred words explaining :( ... I feel you, a patch is more precise. > IMO pw is trying to be smarter than it should here or not being smart > enough. Nonetheless I won't do that anymore. I think there were earlier complaints about what it did recognize and what it didn't. I'd be open to only accepting new versions of patches from whoever sent the original patch. Or requiring patch subjects don't start with "Re:". Or both. I was annoyed, but I'm perhaps more annoyed that you can't do this without confusing patchwork. In the end, I wouldn't want to hamper review by blocking something that comes naturally to people. Arek? BR, Jani. > > Lucas De Marchi > >> >> I'm resending the series, with your documentation patch added, but I'm >> keeping the extra explanatory text in the last patch. I think it's >> warranted. >> >> BR, >> Jani. >> >> >> > >> > ------------- >> > Subject: [PATCH] drm/i915: document PCH_NOP >> > >> > There's a difference between PCH_NONE and PCH_NOP: the former means we >> > don't have a PCH while in the latter we do, but it doesn't have the >> > south display. >> > >> > Cc: Jani Nikula <jani.nikula@intel.com> >> > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> >> > --- >> > drivers/gpu/drm/i915/i915_drv.h | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h >> > index 72150f89f200..aa395a898258 100644 >> > --- a/drivers/gpu/drm/i915/i915_drv.h >> > +++ b/drivers/gpu/drm/i915/i915_drv.h >> > @@ -631,7 +631,7 @@ enum intel_pch { >> > PCH_KBP, /* Kaby Lake PCH */ >> > PCH_CNP, /* Cannon Lake PCH */ >> > PCH_ICP, /* Ice Lake PCH */ >> > - PCH_NOP, >> > + PCH_NOP, /* PCH without south display */ >> > }; >> > >> > enum intel_sbi_destination { >> >> -- >> Jani Nikula, Intel Open Source Graphics Center
On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula <jani.nikula@intel.com> wrote: > >> > >> On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > >> >> specific case to indicate a PCH system without south display. > >> > > >> > Then let's go ahead and document it? > >> > >> Please avoid sending suggestion patches in-reply-to existing > >> series. This confused patchwork and screwed up CI for the series, which > >> was already a resend just to get CI. :( > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > a hundred words explaining :( ... > > I feel you, a patch is more precise. > > > IMO pw is trying to be smarter than it should here or not being smart > > enough. Nonetheless I won't do that anymore. > > I think there were earlier complaints about what it did recognize and > what it didn't. I'd be open to only accepting new versions of patches > from whoever sent the original patch. Or requiring patch subjects don't > start with "Re:". Or both. No matter what you do here it will misbehave in some scenarios and break someone's workflow :< Originally we required the patches to have X-Mailer set to git-send-email, which seems reasonable, but that annoyed people because their servers were stripping out those headers. Other people send out the patches by feeding them to the drafts folder through IMAP and then sending them out. This, depending on the provider's configuration, also gobbles up a thing or two. Because of the above I am not sure about trusting "Re:" and matching "From:" headers as good enough indicators either. It just adds more opaque "smartness". I already can foresee questions asking "why my v2 was not picked up?" and someone would have to debug it down the line. Was the address different (+XYZ before @)? Has that someone used --subject-prefix=re:? Is it an actual bug? Etc. > I was annoyed, but I'm perhaps more annoyed that you can't do this > without confusing patchwork. In the end, I wouldn't want to hamper > review by blocking something that comes naturally to people. > > Arek? Just add the following header: "X-Patchwork-Hint: comment" to emails that you type out manually. For mutt it's as easy as adding: "my_hdr X-Patchwork-Hint: comment" to your .muttrc https://github.com/dlespiau/patchwork/commit/148f10115525
On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler <arkadiusz.hiler@intel.com> wrote: > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula <jani.nikula@intel.com> wrote: > > >> > > >> On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > >> >> specific case to indicate a PCH system without south display. > > >> > > > >> > Then let's go ahead and document it? > > >> > > >> Please avoid sending suggestion patches in-reply-to existing > > >> series. This confused patchwork and screwed up CI for the series, which > > >> was already a resend just to get CI. :( > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > a hundred words explaining :( ... > > > > I feel you, a patch is more precise. > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > enough. Nonetheless I won't do that anymore. > > > > I think there were earlier complaints about what it did recognize and > > what it didn't. I'd be open to only accepting new versions of patches > > from whoever sent the original patch. Or requiring patch subjects don't > > start with "Re:". Or both. > > No matter what you do here it will misbehave in some scenarios and > break someone's workflow :< > > Originally we required the patches to have X-Mailer set to > git-send-email, which seems reasonable, but that annoyed people because > their servers were stripping out those headers. > > Other people send out the patches by feeding them to the drafts folder > through IMAP and then sending them out. This, depending on the > provider's configuration, also gobbles up a thing or two. > > Because of the above I am not sure about trusting "Re:" and matching > "From:" headers as good enough indicators either. > > It just adds more opaque "smartness". I already can foresee questions > asking "why my v2 was not picked up?" and someone would have to debug it > down the line. > > Was the address different (+XYZ before @)? Has that someone used > --subject-prefix=re:? Is it an actual bug? Etc. > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > without confusing patchwork. In the end, I wouldn't want to hamper > > review by blocking something that comes naturally to people. > > > > Arek? > > Just add the following header: > "X-Patchwork-Hint: comment" > to emails that you type out manually. > > For mutt it's as easy as adding: > "my_hdr X-Patchwork-Hint: comment" > to your .muttrc This may not work for the same reasons you pointed out that wouldn't work if people are sending patches. Is there a format I can use that will not trigger patchwork from parsing a _reply_? Does removing the "--------" help? Under the hood does it use git am --scissors or similar? Lucas De Marchi > > https://github.com/dlespiau/patchwork/commit/148f10115525 > > -- > Cheers, > Arek
On Wed, Jun 13, 2018 at 10:09 AM Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler > <arkadiusz.hiler@intel.com> wrote: > > > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > > On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula <jani.nikula@intel.com> wrote: > > > >> > > > >> On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > > >> >> specific case to indicate a PCH system without south display. > > > >> > > > > >> > Then let's go ahead and document it? > > > >> > > > >> Please avoid sending suggestion patches in-reply-to existing > > > >> series. This confused patchwork and screwed up CI for the series, which > > > >> was already a resend just to get CI. :( > > > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > > a hundred words explaining :( ... > > > > > > I feel you, a patch is more precise. > > > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > > enough. Nonetheless I won't do that anymore. > > > > > > I think there were earlier complaints about what it did recognize and > > > what it didn't. I'd be open to only accepting new versions of patches > > > from whoever sent the original patch. Or requiring patch subjects don't > > > start with "Re:". Or both. > > > > No matter what you do here it will misbehave in some scenarios and > > break someone's workflow :< > > > > Originally we required the patches to have X-Mailer set to > > git-send-email, which seems reasonable, but that annoyed people because > > their servers were stripping out those headers. > > > > Other people send out the patches by feeding them to the drafts folder > > through IMAP and then sending them out. This, depending on the > > provider's configuration, also gobbles up a thing or two. > > > > Because of the above I am not sure about trusting "Re:" and matching > > "From:" headers as good enough indicators either. > > > > It just adds more opaque "smartness". I already can foresee questions > > asking "why my v2 was not picked up?" and someone would have to debug it > > down the line. > > > > Was the address different (+XYZ before @)? Has that someone used > > --subject-prefix=re:? Is it an actual bug? Etc. > > > > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > > without confusing patchwork. In the end, I wouldn't want to hamper > > > review by blocking something that comes naturally to people. > > > > > > Arek? > > > > Just add the following header: > > "X-Patchwork-Hint: comment" > > to emails that you type out manually. > > > > For mutt it's as easy as adding: > > "my_hdr X-Patchwork-Hint: comment" > > to your .muttrc > > This may not work for the same reasons you pointed out that wouldn't > work if people are sending patches. Is there a format I can use that > will not trigger patchwork from parsing a _reply_? Does removing the > "--------" help? Under the hood does it use git am --scissors or > similar? Humn... it has its own parser. So if I read https://github.com/dlespiau/patchwork/blob/master/patchwork/parser.py#L36 correctly, it should be just a matter of omitting the "diff | ---" lines (or prepending with a "#"). It does make things more difficult if the other person would use "git am --scissors" though. Lucas De Marchi > > > Lucas De Marchi > > > > > https://github.com/dlespiau/patchwork/commit/148f10115525 > > > > -- > > Cheers, > > Arek > > > > -- > Lucas De Marchi
On Wed, Jun 13, 2018 at 10:16:07AM -0700, Lucas De Marchi wrote: > On Wed, Jun 13, 2018 at 10:09 AM Lucas De Marchi > <lucas.de.marchi@gmail.com> wrote: > > > > On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler > > <arkadiusz.hiler@intel.com> wrote: > > > > > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > > > On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula <jani.nikula@intel.com> wrote: > > > > >> > > > > >> On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > > > >> >> specific case to indicate a PCH system without south display. > > > > >> > > > > > >> > Then let's go ahead and document it? > > > > >> > > > > >> Please avoid sending suggestion patches in-reply-to existing > > > > >> series. This confused patchwork and screwed up CI for the series, which > > > > >> was already a resend just to get CI. :( > > > > > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > > > a hundred words explaining :( ... > > > > > > > > I feel you, a patch is more precise. > > > > > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > > > enough. Nonetheless I won't do that anymore. > > > > > > > > I think there were earlier complaints about what it did recognize and > > > > what it didn't. I'd be open to only accepting new versions of patches > > > > from whoever sent the original patch. Or requiring patch subjects don't > > > > start with "Re:". Or both. > > > > > > No matter what you do here it will misbehave in some scenarios and > > > break someone's workflow :< > > > > > > Originally we required the patches to have X-Mailer set to > > > git-send-email, which seems reasonable, but that annoyed people because > > > their servers were stripping out those headers. > > > > > > Other people send out the patches by feeding them to the drafts folder > > > through IMAP and then sending them out. This, depending on the > > > provider's configuration, also gobbles up a thing or two. > > > > > > Because of the above I am not sure about trusting "Re:" and matching > > > "From:" headers as good enough indicators either. > > > > > > It just adds more opaque "smartness". I already can foresee questions > > > asking "why my v2 was not picked up?" and someone would have to debug it > > > down the line. > > > > > > Was the address different (+XYZ before @)? Has that someone used > > > --subject-prefix=re:? Is it an actual bug? Etc. > > > > > > > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > > > without confusing patchwork. In the end, I wouldn't want to hamper > > > > review by blocking something that comes naturally to people. > > > > > > > > Arek? > > > > > > Just add the following header: > > > "X-Patchwork-Hint: comment" > > > to emails that you type out manually. > > > > > > For mutt it's as easy as adding: > > > "my_hdr X-Patchwork-Hint: comment" > > > to your .muttrc > > > > This may not work for the same reasons you pointed out that wouldn't > > work if people are sending patches. Is there a format I can use that > > will not trigger patchwork from parsing a _reply_? Does removing the > > "--------" help? Under the hood does it use git am --scissors or > > similar? Yeah, it's far for perfection and needs additional effort to set the header up. For me it works, but I always send patches via git-send-email and always send replies via mutt - I am the simple case. > Humn... it has its own parser. So if I read > https://github.com/dlespiau/patchwork/blob/master/patchwork/parser.py#L36 > correctly, it should be just a matter of omitting the "diff | ---" > lines (or prepending with a "#"). > > It does make things more difficult if the other person would use "git > am --scissors" though. > > Lucas De Marchi Yes, that is my understanding as well - if you would ommit the "diff header" it should not recognize your mail as a patch. But that's yet another behavior you have to know upfront. It's really hard to strike a balance here. One idea is to optimize for the default case (i.e. behavior of git-send-email), sans the known quirks we have seen so far, and write this down. Then, if some patches are getting ignored, this would make a handy checklist that can be use for troubleshooting and we can also link to it, kindly asking to adhere to a more standard way of sending patches.
On Wed, Jun 13, 2018 at 11:57 PM Arkadiusz Hiler <arkadiusz.hiler@intel.com> wrote: > > On Wed, Jun 13, 2018 at 10:16:07AM -0700, Lucas De Marchi wrote: > > On Wed, Jun 13, 2018 at 10:09 AM Lucas De Marchi > > <lucas.de.marchi@gmail.com> wrote: > > > > > > On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler > > > <arkadiusz.hiler@intel.com> wrote: > > > > > > > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > > > > On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > > > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula <jani.nikula@intel.com> wrote: > > > > > >> > > > > > >> On Thu, 31 May 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote: > > > > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > > > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > > > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > > > > >> >> specific case to indicate a PCH system without south display. > > > > > >> > > > > > > >> > Then let's go ahead and document it? > > > > > >> > > > > > >> Please avoid sending suggestion patches in-reply-to existing > > > > > >> series. This confused patchwork and screwed up CI for the series, which > > > > > >> was already a resend just to get CI. :( > > > > > > > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > > > > a hundred words explaining :( ... > > > > > > > > > > I feel you, a patch is more precise. > > > > > > > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > > > > enough. Nonetheless I won't do that anymore. > > > > > > > > > > I think there were earlier complaints about what it did recognize and > > > > > what it didn't. I'd be open to only accepting new versions of patches > > > > > from whoever sent the original patch. Or requiring patch subjects don't > > > > > start with "Re:". Or both. > > > > > > > > No matter what you do here it will misbehave in some scenarios and > > > > break someone's workflow :< > > > > > > > > Originally we required the patches to have X-Mailer set to > > > > git-send-email, which seems reasonable, but that annoyed people because > > > > their servers were stripping out those headers. > > > > > > > > Other people send out the patches by feeding them to the drafts folder > > > > through IMAP and then sending them out. This, depending on the > > > > provider's configuration, also gobbles up a thing or two. > > > > > > > > Because of the above I am not sure about trusting "Re:" and matching > > > > "From:" headers as good enough indicators either. > > > > > > > > It just adds more opaque "smartness". I already can foresee questions > > > > asking "why my v2 was not picked up?" and someone would have to debug it > > > > down the line. > > > > > > > > Was the address different (+XYZ before @)? Has that someone used > > > > --subject-prefix=re:? Is it an actual bug? Etc. > > > > > > > > > > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > > > > without confusing patchwork. In the end, I wouldn't want to hamper > > > > > review by blocking something that comes naturally to people. > > > > > > > > > > Arek? > > > > > > > > Just add the following header: > > > > "X-Patchwork-Hint: comment" > > > > to emails that you type out manually. > > > > > > > > For mutt it's as easy as adding: > > > > "my_hdr X-Patchwork-Hint: comment" > > > > to your .muttrc > > > > > > This may not work for the same reasons you pointed out that wouldn't > > > work if people are sending patches. Is there a format I can use that > > > will not trigger patchwork from parsing a _reply_? Does removing the > > > "--------" help? Under the hood does it use git am --scissors or > > > similar? > > Yeah, it's far for perfection and needs additional effort to set the > header up. For me it works, but I always send patches via git-send-email > and always send replies via mutt - I am the simple case. > > > Humn... it has its own parser. So if I read > > https://github.com/dlespiau/patchwork/blob/master/patchwork/parser.py#L36 > > correctly, it should be just a matter of omitting the "diff | ---" > > lines (or prepending with a "#"). > > > > It does make things more difficult if the other person would use "git > > am --scissors" though. > > > > Lucas De Marchi > > Yes, that is my understanding as well - if you would ommit the "diff > header" it should not recognize your mail as a patch. But that's yet > another behavior you have to know upfront. > > It's really hard to strike a balance here. > > One idea is to optimize for the default case (i.e. behavior of > git-send-email), sans the known quirks we have seen so far, > and write this down. > > Then, if some patches are getting ignored, this would make a handy > checklist that can be use for troubleshooting and we can also link to > it, kindly asking to adhere to a more standard way of sending patches. Agreed. Lucas De Marchi > > -- > Cheers, > Arek
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 72150f89f200..aa395a898258 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -631,7 +631,7 @@ enum intel_pch { PCH_KBP, /* Kaby Lake PCH */ PCH_CNP, /* Cannon Lake PCH */ PCH_ICP, /* Ice Lake PCH */ - PCH_NOP, + PCH_NOP, /* PCH without south display */ }; enum intel_sbi_destination {