linux-kernel - Re: Patch prefix guidelines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1627715.n8zyuYAZ2L@vostro.rjw.lan>
Date:	Wed, 17 Aug 2016 02:57:27 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Darren Hart <dvhart@...radead.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Patch prefix guidelines

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