linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Patch prefix guidelines
@ 2016-08-17  0:32 Darren Hart
  2016-08-17  0:57 ` Rafael J. Wysocki
  0 siblings, 1 reply; 2+ messages in thread
From: Darren Hart @ 2016-08-17  0:32 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Rafael Wysocki, H. Peter Anvin

Question specifically to other maintainers, do we have a preferred patch prefix
rule set?

To date I try to use a subsystem prefix (with slashes) when a patch updates
multiple drivers or the subsystem Kconfig files,. e.g.

platform/x86: Drop duplicate dependencies on X86

(but I also see things like "platform: x86:")

When a specific driver is involved, I prefer to mention that specific file (or a
subset of the affected files). For example:

intel-hid: Remove duplicated acpi_remove_notify_handler

However, a patch just landed for a particular file that I have not managed a
patch for since I've maintained platform-drivers-x86. Its history is horribly
inconsistent:

$ git log --oneline --no-decorate drivers/platform/x86/intel_pmic_gpio.c 
3769a89 platform: x86: intel-pmic: use gpiochip data pointer
58383c7 gpio: change member .dev to .parent
3493f41 platform: x86: drop owner assignment from platform_drivers
88d5e52 driver:gpio remove all usage of gpio_remove retval in driver
21a3542 platform-drivers-x86: intel_pmic_gpio: Fix off-by-one valid offset range
check
fef8ce16 x86 platform drivers: fix gpio leak
b859f15 Drivers: platform: x86: remove __dev* attributes.
9a2ffd1 intel_pmic_gpio: Convert printks to pr_<level>
21a8d02 x86 platform drivers: Build fix for intel_pmic_gpio
65d7ac03 platform-drivers: x86: pmic: Restore the dropped buslock/unlock
dced35a drivers: Final irq namespace conversion
98401ae platform-drivers: x86: pmic: Use request_irq instead of chained handler
d4b7de6 platform-drivers: x86: pmic: Use irq_chip buslock mechanism
cb8e5e6 platform-drivers: x86: Convert pmic to new irq_chip functions
180e9d1 platform-drivers: x86: pmic: Fix up bogus irq hackery
456dc30 [PATCH] intel_pmic_gpio: modify EOI handling following change of kernel
irq subsystem
61d8e11 Remove duplicate includes from many files
4119617 intel_pmic_gpio: fix off-by-one value range checking
ffcfff3 intel_pmic_gpio: swap the bits and mask args for
intel_scu_ipc_update_register
8950778 gpio: Add PMIC GPIO block support

I don't want to impose arbitrary rules on my contributors, nor do I want to
contribute to an inconsistent git log. In this case, my default would be to
apply the incoming patch (which touches only the one file) as:

intel_pmic_gpio: Make explicitly non-modular

Thoughts? Preferences?

-- 
Darren Hart
Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Patch prefix guidelines
  2016-08-17  0:32 Patch prefix guidelines Darren Hart
@ 2016-08-17  0:57 ` Rafael J. Wysocki
  0 siblings, 0 replies; 2+ messages in thread
From: Rafael J. Wysocki @ 2016-08-17  0:57 UTC (permalink / raw)
  To: Darren Hart; +Cc: Linux Kernel Mailing List, H. Peter Anvin

On Tuesday, August 16, 2016 05:32:15 PM Darren Hart wrote:
> Question specifically to other maintainers, do we have a preferred patch prefix
> rule set?
> 
> To date I try to use a subsystem prefix (with slashes) when a patch updates
> multiple drivers or the subsystem Kconfig files,. e.g.
> 
> platform/x86: Drop duplicate dependencies on X86
> 
> (but I also see things like "platform: x86:")
> 
> When a specific driver is involved, I prefer to mention that specific file (or a
> subset of the affected files). For example:
> 
> intel-hid: Remove duplicated acpi_remove_notify_handler
> 
> However, a patch just landed for a particular file that I have not managed a
> patch for since I've maintained platform-drivers-x86. Its history is horribly
> inconsistent:
> 
> $ git log --oneline --no-decorate drivers/platform/x86/intel_pmic_gpio.c 
> 3769a89 platform: x86: intel-pmic: use gpiochip data pointer
> 58383c7 gpio: change member .dev to .parent
> 3493f41 platform: x86: drop owner assignment from platform_drivers
> 88d5e52 driver:gpio remove all usage of gpio_remove retval in driver
> 21a3542 platform-drivers-x86: intel_pmic_gpio: Fix off-by-one valid offset range
> check
> fef8ce16 x86 platform drivers: fix gpio leak
> b859f15 Drivers: platform: x86: remove __dev* attributes.
> 9a2ffd1 intel_pmic_gpio: Convert printks to pr_<level>
> 21a8d02 x86 platform drivers: Build fix for intel_pmic_gpio
> 65d7ac03 platform-drivers: x86: pmic: Restore the dropped buslock/unlock
> dced35a drivers: Final irq namespace conversion
> 98401ae platform-drivers: x86: pmic: Use request_irq instead of chained handler
> d4b7de6 platform-drivers: x86: pmic: Use irq_chip buslock mechanism
> cb8e5e6 platform-drivers: x86: Convert pmic to new irq_chip functions
> 180e9d1 platform-drivers: x86: pmic: Fix up bogus irq hackery
> 456dc30 [PATCH] intel_pmic_gpio: modify EOI handling following change of kernel
> irq subsystem
> 61d8e11 Remove duplicate includes from many files
> 4119617 intel_pmic_gpio: fix off-by-one value range checking
> ffcfff3 intel_pmic_gpio: swap the bits and mask args for
> intel_scu_ipc_update_register
> 8950778 gpio: Add PMIC GPIO block support
> 
> I don't want to impose arbitrary rules on my contributors, nor do I want to
> contribute to an inconsistent git log. In this case, my default would be to
> apply the incoming patch (which touches only the one file) as:
> 
> intel_pmic_gpio: Make explicitly non-modular
> 
> Thoughts? Preferences?

I generally use the following conventions:

"ACPI / what: " for the ACPI core
"PM / what: " for the PM core
"cpufreq: " for the cpufreq core
"cpufreq: which driver: " for cpufreq drivers (although intel_pstate or cpufreq-dt
can go without the "cpufreq: " prefix, because they are not ambiguous anyway)
"cpuidle: " for the cpuidle core
"cpuidle: which driver: " for cpuidle drivers (again, intel_idle is a bit of
an exception here)

and so on.

If I were you, I'd use "platform/x86: " or "platform/x86: which driver: "
as that clearly identifies the subsystem.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-08-17  0:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-17  0:32 Patch prefix guidelines Darren Hart
2016-08-17  0:57 ` Rafael J. Wysocki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).