[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1A7043D5F58CCB44A599DFD55ED4C94846A17FF0@fmsmsx115.amr.corp.intel.com>
Date: Thu, 24 Mar 2016 06:35:44 +0000
From: "Brown, Len" <len.brown@...el.com>
To: "Zheng, Lv" <lv.zheng@...el.com>, Joe Perches <joe@...ches.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>
CC: Lv Zheng <zetalog@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH 01/30] ACPICA: Linuxize: reduce divergences for 20160212
release
> > >
> > > -acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address
> *reg)
> > > +acpi_status acpi_hw_read(u32 *value, struct acpi_generic_address *
> reg)
> >
> > The second argument * style appears the opposite of normal style
> > and a different style than the first argument * style.
> [Lv Zheng]
> The file is drivers/acpi/acpica/hwregs.c, which is coming from ACPICA
> upstream.
> So this is a result of "ACPICA release".
> In other words, this is a result of a "process".
> In order to fix this, things need to be done in "ACPICA release scripts".
> Which should be done in
> https://github.com/acpica/acpica/blob/master/generate/linux/libacpica.sh.
> Otherwise, "ACPICA release" process will require human intervention.
>
> So please leave this patch fragment as is.
> It will be automatically fixed if the "ACPICA release" process is fixed.
> And if you don't leave this fragment as is, the "ACPICA release" process
> will get hurt.
I disagree.
The patch should be correct when it hits the Linux kernel tree.
If the process is broken, then fix the process and re-send
a fixed patch. Linux doesn't care if the process is a program
that runs with the click of a button, or the result of 1000
engineering laboring day and night. Only the result matters,
the result should be correct, and this patch is not correct.
-Len
Powered by blists - more mailing lists