Re: [PATCH v2] platform/x86: asus-armoury: add support for G614PR

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Mon, 29 Jun 2026, Marco Scardovi wrote:

> Hi Ilpo,
> 
> In data lunedì 29 giugno 2026 13:04:51 Ora legale dell’Europa centrale, Ilpo Järvinen ha scritto:
> > On Sat, 27 Jun 2026, Marco Scardovi wrote:
> > 
> > > you around? I'd need this to be fixed to set the correct values.
> > 
> > I'm not sure what the context here is, whether you're just asking for the 
> > patch to be applied (which is entirely unnecessary, as long as the patch 
> > appears in the patchwork's queue, I've not lost it), or if you're saying 
> > there's a problem in v2 patch?
> >
> There was a problem with the v1 patch, where I wrote 4 values wrongly,
> so I posted the v2 with the correct values.

Hi,

I did take v1 patch and it has in the meantime been merged into Linus' 
tree, making the original change immutable.

Thus, please post a delta patch with a justification instead. Use a Fixes 
tag pointing to the original commit.

For simple patches, placing the patch changelog (patch history) in that 
patch itself under --- line e.g. as bullet points is more effective and 
easy to spot that from the coverletter.

Preferrably post new versions as own thread because sometimes tools may 
get confused when more than one version appears within the same thread.

> > Usually, the merge window is quiet time anyway when it comes to applying 
> > patches so don't expect much to happen for them until clearly after rc1 
> > (= not right after rc1 has been published, because the piled up patch 
> > queue will take some time to drain and there are other things to do around 
> > that timeframe as well).
> > 
> I see, sorry for bothering. I'm new to the kernel patching workflow and
> still learning how it works.

It's no problem, no need to be sorry at all, we value also patches from 
newcomers. I just wrote this to explain how the kernel development cycle 
works. 

Some subsystems accept no new submissions during merge window, in pdx86 
we've no such rule but things are still quieter also here (I usually won't 
apply anything than very very critical fixes during that 2 weeks window of 
time, it's "normal").

-- 
 i.