[PATCH] net: make config lines follow common pattern
The Kconfig parser is quite relaxed when parsing config definition lines. However, there are just a few config definition lines that do not follow the common regular expression 'config [0-9A-Z]', i.e., there are only a few cases where config is not followed by exactly one whitespace. To simplify life for kernel developers that use basic regular expressions to find and extract kernel configs, make all config lines follow this common pattern. No functional change, just helpful stylistic clean-up. Signed-off-by: Lukas Bulwahn --- drivers/net/ethernet/cavium/Kconfig | 4 +-- net/caif/Kconfig| 2 +- net/netfilter/ipvs/Kconfig | 54 ++--- net/unix/Kconfig| 2 +- 4 files changed, 31 insertions(+), 31 deletions(-) diff --git a/drivers/net/ethernet/cavium/Kconfig b/drivers/net/ethernet/cavium/Kconfig index ca742cc146d7..fe4203b1bc5f 100644 --- a/drivers/net/ethernet/cavium/Kconfig +++ b/drivers/net/ethernet/cavium/Kconfig @@ -32,7 +32,7 @@ config THUNDER_NIC_VF help This driver supports Thunder's NIC virtual function -config THUNDER_NIC_BGX +config THUNDER_NIC_BGX tristate "Thunder MAC interface driver (BGX)" depends on 64BIT && PCI select PHYLIB @@ -42,7 +42,7 @@ configTHUNDER_NIC_BGX This driver supports programming and controlling of MAC interface from NIC physical function driver. -config THUNDER_NIC_RGX +config THUNDER_NIC_RGX tristate "Thunder MAC interface driver (RGX)" depends on 64BIT && PCI select PHYLIB diff --git a/net/caif/Kconfig b/net/caif/Kconfig index 87205251cc25..1eb271125eb0 100644 --- a/net/caif/Kconfig +++ b/net/caif/Kconfig @@ -22,7 +22,7 @@ menuconfig CAIF See Documentation/networking/caif for a further explanation on how to use and configure CAIF. -config CAIF_DEBUG +config CAIF_DEBUG bool "Enable Debug" depends on CAIF default n diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig index 2a3017b9c001..db6df2ca129d 100644 --- a/net/netfilter/ipvs/Kconfig +++ b/net/netfilter/ipvs/Kconfig @@ -26,7 +26,7 @@ menuconfig IP_VS if IP_VS -config IP_VS_IPV6 +config IP_VS_IPV6 bool "IPv6 support for IPVS" depends on IPV6 = y || IP_VS = IPV6 select NF_DEFRAG_IPV6 @@ -35,14 +35,14 @@ config IP_VS_IPV6 Say Y if unsure. -config IP_VS_DEBUG +config IP_VS_DEBUG bool "IP virtual server debugging" help Say Y here if you want to get additional messages useful in debugging the IP virtual server code. You can change the debug level in /proc/sys/net/ipv4/vs/debug_level -config IP_VS_TAB_BITS +config IP_VS_TAB_BITS int "IPVS connection table size (the Nth power of 2)" range 8 20 if !64BIT range 8 27 if 64BIT @@ -76,34 +76,34 @@ config IP_VS_TAB_BITS comment "IPVS transport protocol load balancing support" -config IP_VS_PROTO_TCP +config IP_VS_PROTO_TCP bool "TCP load balancing support" help This option enables support for load balancing TCP transport protocol. Say Y if unsure. -config IP_VS_PROTO_UDP +config IP_VS_PROTO_UDP bool "UDP load balancing support" help This option enables support for load balancing UDP transport protocol. Say Y if unsure. -config IP_VS_PROTO_AH_ESP +config IP_VS_PROTO_AH_ESP def_bool IP_VS_PROTO_ESP || IP_VS_PROTO_AH -config IP_VS_PROTO_ESP +config IP_VS_PROTO_ESP bool "ESP load balancing support" help This option enables support for load balancing ESP (Encapsulation Security Payload) transport protocol. Say Y if unsure. -config IP_VS_PROTO_AH +config IP_VS_PROTO_AH bool "AH load balancing support" help This option enables support for load balancing AH (Authentication Header) transport protocol. Say Y if unsure. -config IP_VS_PROTO_SCTP +config IP_VS_PROTO_SCTP bool "SCTP load balancing support" select LIBCRC32C help @@ -112,7 +112,7 @@ config IP_VS_PROTO_SCTP comment "IPVS scheduler" -config IP_VS_RR +config IP_VS_RR tristate "round-robin scheduling" help The robin-robin scheduling algorithm simply directs network @@ -121,7 +121,7 @@ config IP_VS_RR If you want to compile it in kernel, say Y. To compile it as a module, choose M here. If unsure, say N. -config IP_VS_WRR +config IP_VS_WRR tristate "weighted round-robin scheduling" help The weighted robin-robin scheduling algorithm directs network @@ -134,7 +134,7 @@ config IP_VS_WRR If you want to compile it in kernel, say Y.
[PATCH] MAINTAINERS: remove section LIBNVDIMM BLK: MMIO-APERTURE DRIVER
Commit f8669f1d6a86 ("nvdimm/blk: Delete the block-aperture window driver")
removes the file drivers/nvdimm/blk.c, but misses to adjust MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a
broken reference.
The section LIBNVDIMM BLK: MMIO-APERTURE DRIVER refers to the driver in
blk.c, and some more generic nvdimm code in region_devs.c.
As the driver is deleted, delete the section LIBNVDIMM BLK: MMIO-APERTURE
DRIVER in MAINTAINERS as well.
The remaining file region_devs.c is still covered by the section LIBNVDIMM:
NON-VOLATILE MEMORY DEVICE SUBSYSTEM, and all patches to region_devs.c will
still reach the same developers as before.
Signed-off-by: Lukas Bulwahn
---
Dan, please pick this minor clean-up patch in your -next tree on top of
the commit above.
MAINTAINERS | 11 ---
1 file changed, 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index faa5e53db1dd..5eacf125e052 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11128,17 +11128,6 @@ F: drivers/ata/
F: include/linux/ata.h
F: include/linux/libata.h
-LIBNVDIMM BLK: MMIO-APERTURE DRIVER
-M: Dan Williams
-M: Vishal Verma
-M: Dave Jiang
-L: nvd...@lists.linux.dev
-S: Supported
-Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
-P: Documentation/nvdimm/maintainer-entry-profile.rst
-F: drivers/nvdimm/blk.c
-F: drivers/nvdimm/region_devs.c
-
LIBNVDIMM BTT: BLOCK TRANSLATION TABLE
M: Vishal Verma
M: Dan Williams
--
2.17.1
Invalid License ID: GPL-3.0 for arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
Dear Qing,
./scripts/spdxcheck.py reports:
arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi: 1:28 Invalid
License ID: GPL-3.0
You have contributed this file with commit b1a792601f26 ("MIPS:
Loongson64: DeviceTree for Loongson-2K1000") to the current
linux-next.
Do you intend to contribute this under this non-default license
(GPL-3.0) for the kernel project or did you simply mean the default
license GPL-2.0?
Best regards,
Lukas
[PATCH 3/3] MAINTAINERS: rectify entry for INTEL KEEM BAY DRM DRIVER
Commit ed794057b052 ("drm/kmb: Build files for KeemBay Display driver")
refers to the non-existing file intel,kmb_display.yaml in
./Documentation/devicetree/bindings/display/.
Commit 5a76b1ed73b9 ("dt-bindings: display: Add support for Intel KeemBay
Display") originating from the same patch series however adds the file
intel,keembay-display.yaml in that directory instead.
So, refer to intel,keembay-display.yaml in the INTEL KEEM BAY DRM DRIVER
section instead.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4f152717365c..421e24e43335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9268,7 +9268,7 @@ INTEL KEEM BAY DRM DRIVER
M: Anitha Chrisanthus
M: Edmund Dea
S: Maintained
-F: Documentation/devicetree/bindings/display/intel,kmb_display.yaml
+F: Documentation/devicetree/bindings/display/intel,keembay-display.yaml
F: drivers/gpu/drm/kmb/
INTEL KEEM BAY OCS AES/SM4 CRYPTO DRIVER
--
2.17.1
[PATCH RESEND 0/3] Rectify file references for dt-bindings in MAINTAINERS
Hi Rob, here is a patch series that cleans up all file references for dt-bindings in MAINTAINERS. It applies cleanly on next-20210416. This is a resend of the still relevant patches from the first submission of the patch series [see Link] on 2021-03-15. Could you pick this series for your devicetree bindings tree? No functional change, just cleaning up MAINTAINERS. Lukas Link: https://lore.kernel.org/lkml/20210315160451.7469-1-lukas.bulw...@gmail.com/ Adjustment from original to resend version: - drop subsumed patches Lukas Bulwahn (3): MAINTAINERS: rectify entry for ARM/TOSHIBA VISCONTI ARCHITECTURE MAINTAINERS: rectify entry for HIKEY960 ONBOARD USB GPIO HUB DRIVER MAINTAINERS: rectify entry for INTEL KEEM BAY DRM DRIVER MAINTAINERS | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.17.1
[PATCH 1/3] MAINTAINERS: rectify entry for ARM/TOSHIBA VISCONTI ARCHITECTURE
Commit 836863a08c99 ("MAINTAINERS: Add information for Toshiba Visconti ARM
SoCs") refers to the non-existing file toshiba,tmpv7700-pinctrl.yaml in
./Documentation/devicetree/bindings/pinctrl/. Commit 1825c1fe0057
("pinctrl: Add DT bindings for Toshiba Visconti TMPV7700 SoC") originating
from the same patch series however adds the file
toshiba,visconti-pinctrl.yaml in that directory instead.
So, refer to toshiba,visconti-pinctrl.yaml in the ARM/TOSHIBA VISCONTI
ARCHITECTURE section instead.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c54b8e4520d1..d31c8058b17f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2669,7 +2669,7 @@ T:git
git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti.git
F: Documentation/devicetree/bindings/arm/toshiba.yaml
F: Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
F: Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
-F: Documentation/devicetree/bindings/pinctrl/toshiba,tmpv7700-pinctrl.yaml
+F: Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml
F: Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
F: arch/arm64/boot/dts/toshiba/
F: drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
--
2.17.1
[PATCH 2/3] MAINTAINERS: rectify entry for HIKEY960 ONBOARD USB GPIO HUB DRIVER
Commit 7a6ff4c4cbc3 ("misc: hisi_hikey_usb: Driver to support onboard USB
gpio hub on Hikey960") refers to the non-existing file
./Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml, but this
commit's patch series does not add any related devicetree binding in misc.
So, just drop this file reference in HIKEY960 ONBOARD USB GPIO HUB DRIVER.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d31c8058b17f..4f152717365c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8239,7 +8239,6 @@ M:John Stultz
L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/misc/hisi_hikey_usb.c
-F: Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml
HISILICON PMU DRIVER
M: Shaokun Zhang
--
2.17.1
[PATCH] MAINTAINERS: adjust to removing i2c designware platform data
Commit 5a517b5bf687 ("i2c: designware: Get rid of legacy platform data")
removes ./include/linux/platform_data/i2c-designware.h, but misses to
adjust the SYNOPSYS DESIGNWARE I2C DRIVER section in MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: include/linux/platform_data/i2c-designware.h
Remove the file entry to this removed file as well.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210419
Andy, please ack.
Lee, please pick this minor patch on your -next tree.
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index bbe356508f29..6b903aad27f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17667,7 +17667,6 @@ R: Mika Westerberg
L: linux-...@vger.kernel.org
S: Maintained
F: drivers/i2c/busses/i2c-designware-*
-F: include/linux/platform_data/i2c-designware.h
SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER
M: Jaehoon Chung
--
2.17.1
[PATCH] MAINTAINERS: repair reference in HYCON HY46XX TOUCHSCREEN SUPPORT
Commit aa2f62cf211a ("Input: add driver for the Hycon HY46XX touchpanel
series") adds the file ./drivers/input/touchscreen/hycon-hy46xx.c, but the
file entry in MAINTAINERS refers to ./drivers/input/touchscreen/hy46xx.c.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matchesF:drivers/input/touchscreen/hy46xx.c
Repair the file entry by referring to the right location.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210419
Guilio, please ack.
Dmitry, please pick this minor clean up patch for your -next tree.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c54b8e4520d1..bbe356508f29 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8425,7 +8425,7 @@ M:Giulio Benetti
L: linux-in...@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml
-F: drivers/input/touchscreen/hy46xx.c
+F: drivers/input/touchscreen/hycon-hy46xx.c
HYGON PROCESSOR SUPPORT
M: Pu Wen
--
2.17.1
[tip: core/rcu] rcu-tasks: Rectify kernel-doc for struct rcu_tasks
The following commit has been merged into the core/rcu branch of tip: Commit-ID: 85b86994284820ec070182ec269e6e79735f523a Gitweb: https://git.kernel.org/tip/85b86994284820ec070182ec269e6e79735f523a Author:Lukas Bulwahn AuthorDate:Mon, 25 Jan 2021 08:41:05 +01:00 Committer: Paul E. McKenney CommitterDate: Mon, 08 Mar 2021 14:22:02 -08:00 rcu-tasks: Rectify kernel-doc for struct rcu_tasks The command 'find ./kernel/rcu/ | xargs ./scripts/kernel-doc -none' reported an issue with the kernel-doc of struct rcu_tasks. This commit rectifies the kernel-doc, such that no issues remain for ./kernel/rcu/. Signed-off-by: Lukas Bulwahn Signed-off-by: Paul E. McKenney --- kernel/rcu/tasks.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index af7c194..17c8ebe 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -20,7 +20,7 @@ typedef void (*holdouts_func_t)(struct list_head *hop, bool ndrpt, bool *frptp); typedef void (*postgp_func_t)(struct rcu_tasks *rtp); /** - * Definition for a Tasks-RCU-like mechanism. + * struct rcu_tasks - Definition for a Tasks-RCU-like mechanism. * @cbs_head: Head of callback list. * @cbs_tail: Tail pointer for callback list. * @cbs_wq: Wait queue allowning new callback to get kthread's attention. @@ -38,7 +38,7 @@ typedef void (*postgp_func_t)(struct rcu_tasks *rtp); * @pregp_func: This flavor's pre-grace-period function (optional). * @pertask_func: This flavor's per-task scan function (optional). * @postscan_func: This flavor's post-task scan function (optional). - * @holdout_func: This flavor's holdout-list scan function (optional). + * @holdouts_func: This flavor's holdout-list scan function (optional). * @postgp_func: This flavor's post-grace-period function (optional). * @call_func: This flavor's call_rcu()-equivalent function. * @name: This flavor's textual name.
[PATCH 2/2] soc: qcom: address kernel-doc warnings
The command:
find ./include/linux/soc/qcom/ | xargs ./scripts/kernel-doc -none
reports:
./include/linux/soc/qcom/qmi.h:26: warning: cannot understand function
prototype: 'struct qmi_header '
./include/linux/soc/qcom/qmi.h:101: warning: cannot understand function
prototype: 'struct qmi_response_type_v01 '
./include/linux/soc/qcom/irq.h:19: warning: expecting prototype for QCOM
specific IRQ domain flags that distinguishes the handling of wakeup().
Prototype was for IRQ_DOMAIN_FLAG_QCOM_PDC_WAKEUP() instead
./include/linux/soc/qcom/apr.h:126: warning: Function parameter or member
'__apr_driver' not described in 'module_apr_driver'
./include/linux/soc/qcom/apr.h:126: warning: Excess function parameter
'__aprbus_driver' description in 'module_apr_driver'
./include/linux/soc/qcom/llcc-qcom.h:43: warning: cannot understand function
prototype: 'struct llcc_slice_desc '
./include/linux/soc/qcom/llcc-qcom.h:60: warning: cannot understand function
prototype: 'struct llcc_edac_reg_data '
./include/linux/soc/qcom/llcc-qcom.h:86: warning: cannot understand function
prototype: 'struct llcc_drv_data '
Address all those warnings by:
- prefixing kernel-doc descriptions for structs with the keyword 'struct',
- turning a kernel-doc comment that does not follow the kernel-doc syntax
into a normal comment, and
- correcting a parameter name in a kernel-doc comment.
Signed-off-by: Lukas Bulwahn
---
include/linux/soc/qcom/apr.h | 2 +-
include/linux/soc/qcom/irq.h | 2 +-
include/linux/soc/qcom/llcc-qcom.h | 6 +++---
include/linux/soc/qcom/qmi.h | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/soc/qcom/apr.h b/include/linux/soc/qcom/apr.h
index 7f0bc3cf4d61..137f9f2ac4c3 100644
--- a/include/linux/soc/qcom/apr.h
+++ b/include/linux/soc/qcom/apr.h
@@ -113,7 +113,7 @@ void apr_driver_unregister(struct apr_driver *drv);
/**
* module_apr_driver() - Helper macro for registering a aprbus driver
- * @__aprbus_driver: aprbus_driver struct
+ * @__apr_driver: apr_driver struct
*
* Helper macro for aprbus drivers which do not do anything special in
* module init/exit. This eliminates a lot of boilerplate. Each module
diff --git a/include/linux/soc/qcom/irq.h b/include/linux/soc/qcom/irq.h
index 9e1ece58e55b..72b9231e9fdd 100644
--- a/include/linux/soc/qcom/irq.h
+++ b/include/linux/soc/qcom/irq.h
@@ -7,7 +7,7 @@
#define GPIO_NO_WAKE_IRQ ~0U
-/**
+/*
* QCOM specific IRQ domain flags that distinguishes the handling of wakeup
* capable interrupts by different interrupt controllers.
*
diff --git a/include/linux/soc/qcom/llcc-qcom.h
b/include/linux/soc/qcom/llcc-qcom.h
index 64fc582ae415..437c9df13229 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -35,7 +35,7 @@
#define LLCC_WRCACHE 31
/**
- * llcc_slice_desc - Cache slice descriptor
+ * struct llcc_slice_desc - Cache slice descriptor
* @slice_id: llcc slice id
* @slice_size: Size allocated for the llcc slice
*/
@@ -45,7 +45,7 @@ struct llcc_slice_desc {
};
/**
- * llcc_edac_reg_data - llcc edac registers data for each error type
+ * struct llcc_edac_reg_data - llcc edac registers data for each error type
* @name: Name of the error
* @synd_reg: Syndrome register address
* @count_status_reg: Status register address to read the error count
@@ -69,7 +69,7 @@ struct llcc_edac_reg_data {
};
/**
- * llcc_drv_data - Data associated with the llcc driver
+ * struct llcc_drv_data - Data associated with the llcc driver
* @regmap: regmap associated with the llcc device
* @bcast_regmap: regmap associated with llcc broadcast offset
* @cfg: pointer to the data structure for slice configuration
diff --git a/include/linux/soc/qcom/qmi.h b/include/linux/soc/qcom/qmi.h
index e712f94b89fc..b1f80e756d2a 100644
--- a/include/linux/soc/qcom/qmi.h
+++ b/include/linux/soc/qcom/qmi.h
@@ -16,7 +16,7 @@
struct socket;
/**
- * qmi_header - wireformat header of QMI messages
+ * struct qmi_header - wireformat header of QMI messages
* @type: type of message
* @txn_id:transaction id
* @msg_id:message id
@@ -93,7 +93,7 @@ struct qmi_elem_info {
#define QMI_ERR_NOT_SUPPORTED_V01 94
/**
- * qmi_response_type_v01 - common response header (decoded)
+ * struct qmi_response_type_v01 - common response header (decoded)
* @result:result of the transaction
* @error: error value, when @result is QMI_RESULT_FAILURE_V01
*/
--
2.17.1
[PATCH 1/2] MAINTAINERS: add another entry for ARM/QUALCOMM SUPPORT
The files in ./include/linux/soc/qcom/ are headers to the corresponding files in ./drivers/soc/qcom/, which are assigned to ARM/QUALCOMM SUPPORT. Possibly, the file pattern include/linux/*/qcom* intended to match this directory and its containing files, but unfortunately, it does not. Hence, add a file entry for this directory to ARM/QUALCOMM SUPPORT. Signed-off-by: Lukas Bulwahn --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 67b104202602..ec43d5c3a1a4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2298,6 +2298,7 @@ F:drivers/tty/serial/msm_serial.c F: drivers/usb/dwc3/dwc3-qcom.c F: include/dt-bindings/*/qcom* F: include/linux/*/qcom* +F: include/linux/soc/qcom/ ARM/RADISYS ENP2611 MACHINE SUPPORT M: Lennert Buytenhek -- 2.17.1
[PATCH 0/2] kernel-doc and MAINTAINERS clean-up
Roughly 900 warnings of about 21.000 kernel-doc warnings in the kernel tree warn with 'cannot understand function prototype:', i.e., the kernel-doc parser cannot parse the function's signature. The majority, about 600 cases of those, are just struct definitions following the kernel-doc description. Further, spot-check investigations suggest that the authors of the specific kernel-doc descriptions simply were not aware that the general format for a kernel-doc description for a structure requires to prefix the struct name with the keyword 'struct', as in 'struct struct_name - Brief description.'. Details on kernel-doc are at the Link below. Without the struct keyword, kernel-doc does not check if the kernel-doc description fits to the actual struct definition in the source code. Fortunately, in roughly a quarter of these cases, the kernel-doc description is actually complete wrt. its corresponding struct definition. So, the trivial change adding the struct keyword will allow us to keep the kernel-doc descriptions more consistent for future changes, by checking for new kernel-doc warnings. Also, some of the files in ./include/ are not assigned to a specific MAINTAINERS section and hence have no dedicated maintainer. So, if needed, the files in ./include/ are also assigned to the fitting MAINTAINERS section, as I need to identify whom to send the clean-up patch anyway. Here is the change from this kernel-doc janitorial work in the ./include/ directory for ARM/QUALCOMM SUPPORT. Andy, Bjorn, please pick this clean-up patch series for your tree. Link: https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Lukas Bulwahn (2): MAINTAINERS: add another entry for ARM/QUALCOMM SUPPORT soc: qcom: address kernel-doc warnings MAINTAINERS| 1 + include/linux/soc/qcom/apr.h | 2 +- include/linux/soc/qcom/irq.h | 2 +- include/linux/soc/qcom/llcc-qcom.h | 6 +++--- include/linux/soc/qcom/qmi.h | 4 ++-- 5 files changed, 8 insertions(+), 7 deletions(-) -- 2.17.1
Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions
On Mon, Mar 22, 2021 at 4:38 PM Thorsten Leemhuis wrote: > > > Lo! I want to provide users with an easier way to search our multitude > of mailing lists for reports about issues (aka bugs), as reporting the > same kernel problem multiple times has known downsides for everyone > involved. That's why I propose to create this new mailing list: > > linux-iss...@lists.linux.dev > > Developers and users reporting or handling issues then can CC it or > search it via lore. But this will only fly if the idea has buy-in from > at least the core kernel maintainers, to make sure they and the > developers actually use it. That's why I'm looking for feedback with > this mail and also CCed ksummit-discuss, as that's the easiest way to > make sure maintainers get aware of this idea and can raise their voice. > > > Note, there is a second reason why ksummit-discuss is CCed: another > reason why I want to create this new list is making it easier to find > and track regressions reported to our various mailing lists (often > without LKML in CC, as for some subsystems it's seems to be custom to > not CC it). Back on the maintainers summit in 2017 it was agreed to > create a dedicated list for this purpose > (https://lwn.net/Articles/738216/). I even requested a > "linux-regressi...@vger.kernel.org" a while later, but didn't hear > anything back; and, sadly, about the same time I started having trouble > finding spare time for working on regression tracking. :-/ > > But I soon will get back into that area: > https://linux-regtracking.leemhuis.info/post/hello-world/ Hence it's a > good time to prepare some groundwork for that. But these days I think > having something like linux-regressi...@lists.linux.dev might be over > engineered, at least for now: a linux-iss...@lists.linux.dev with a > simple "[regressions]" in the subject will suffice, as that tag is > something a lot of people are used to already. And if we think we need > that list we can still create it in the future. Or what do you folks > think about it? > Thorsten, I generally support this initiative. I am just wondering: What is the definition of an issue for you? Just four examples that come to my mind: - all the warnings that Stephen Rothwell reports on linux-next, such as https://lore.kernel.org/linux-next/20210322170452.72652...@canb.auug.org.au/ or https://lore.kernel.org/linux-next/20210322075108.3967d...@canb.auug.org.au/? - all the issues that the kernel test robot reports? - all the errors and warnings that kernel ci reports? Basically, each "issue" that is already aggregated in this email, https://lore.kernel.org/linux-next/6058787c.1c69fb81.d3f10.8...@mx.google.com/? - all the syzbot reports? Are you including all those automatic testing and checking efforts as reporting valid "issues"? Or would you like to keep this list only for reports from single individual human users that need to detect the "issue" without using one of the tools above? Lukas
[PATCH 2/2] pagewalk: prefix struct kernel-doc descriptions
The script './scripts/kernel-doc -none ./include/linux/pagewalk.h' reports:
include/linux/pagewalk.h:37: warning: cannot understand function prototype:
'struct mm_walk_ops '
include/linux/pagewalk.h:85: warning: cannot understand function prototype:
'struct mm_walk '
A kernel-doc description for a structure requires to prefix the struct name
with the keyword 'struct'. So, do that such that no further kernel-doc
warnings are reported for this file.
Signed-off-by: Lukas Bulwahn
---
include/linux/pagewalk.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
index b1cb6b753abb..ac7b38ad5903 100644
--- a/include/linux/pagewalk.h
+++ b/include/linux/pagewalk.h
@@ -7,7 +7,7 @@
struct mm_walk;
/**
- * mm_walk_ops - callbacks for walk_page_range
+ * struct mm_walk_ops - callbacks for walk_page_range
* @pgd_entry: if set, called for each non-empty PGD (top-level) entry
* @p4d_entry: if set, called for each non-empty P4D entry
* @pud_entry: if set, called for each non-empty PUD entry
@@ -71,7 +71,7 @@ enum page_walk_action {
};
/**
- * mm_walk - walk_page_range data
+ * struct mm_walk - walk_page_range data
* @ops: operation to call during the walk
* @mm:mm_struct representing the target process of page table
walk
* @pgd: pointer to PGD; only valid with no_vma (otherwise set to NULL)
--
2.17.1
[PATCH 0/2] kernel-doc and MAINTAINERS clean-up
Roughly 900 warnings of about 21.000 kernel-doc warnings in the kernel tree warn with 'cannot understand function prototype:', i.e., the kernel-doc parser cannot parse the function's signature. The majority, about 600 cases of those, are just struct definitions following the kernel-doc description. Further, spot-check investigations suggest that the authors of the specific kernel-doc descriptions simply were not aware that the general format for a kernel-doc description for a structure requires to prefix the struct name with the keyword 'struct', as in 'struct struct_name - Brief description.'. Details on kernel-doc are at the Link below. Without the struct keyword, kernel-doc does not check if the kernel-doc description fits to the actual struct definition in the source code. Fortunately, in roughly a quarter of these cases, the kernel-doc description is actually complete wrt. its corresponding struct definition. So, the trivial change adding the struct keyword will allow us to keep the kernel-doc descriptions more consistent for future changes, by checking for new kernel-doc warnings. Also, some of the files in ./include/ are not assigned to a specific MAINTAINERS section and hence have no dedicated maintainer. So, if needed, the files in ./include/ are also assigned to the fitting MAINTAINERS section, as I need to identify whom to send the clean-up patch anyway. Here is the change from this kernel-doc janitorial work in the ./include/ directory for MEMORY MANAGEMENT. Andrew, please pick this clean-up patch series for mm. Link: https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Lukas Bulwahn (2): MAINTAINERS: assign pagewalk.h to MEMORY MANAGEMENT pagewalk: prefix struct kernel-doc descriptions MAINTAINERS | 1 + include/linux/pagewalk.h | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) -- 2.17.1
[PATCH 1/2] MAINTAINERS: assign pagewalk.h to MEMORY MANAGEMENT
Commit a520110e4a15 ("mm: split out a new pagewalk.h header from mm.h")
adds a new file in ./include/linux, but misses to update MAINTAINERS
accordingly. Hence, ./scripts/get_maintainers.pl ./include/linux/pagewalk.h
points only to lkml as general fallback for all files, whereas the original
./include/linux/mm.h clearly marks this file part of MEMORY MANAGEMENT.
Assign ./include/linux/pagewalk.h to MEMORY MANAGEMENT.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 728216e3919c..46a1eddbc3e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11622,6 +11622,7 @@ F: include/linux/gfp.h
F: include/linux/memory_hotplug.h
F: include/linux/mm.h
F: include/linux/mmzone.h
+F: include/linux/pagewalk.h
F: include/linux/vmalloc.h
F: mm/
--
2.17.1
Re: [EXTERNAL]Re: [PATCH 0/5] Remove dead linux-mips.org references
On Mon, Feb 22, 2021 at 7:19 PM Kurt Martin wrote: > > Hi Everybody, > > This is Kurt Martin. I'm part of the MIPS Customer Engineering team at Wave > Computing. Some of you may remember me. I have just established contact > with Ralf, and I will be working with him to restore linux-mips.org back to > life. I just got the account and login information for the linux-mips.org > hosting account at Hetzner from Chris Dearman. > > So as Maciej says, please hold off any actions at this time, and I will > attempt to get linux-mips.org working again as quickly as possible. Thanks! > It has been a month by now... I just wanted to check if linux-mips.org is back on its way to be available. Or should Thomas pick up the remaining patches of this series? Lukas
[PATCH] devicetree: replace invalid kernel-doc comment headers
The opening comment mark '/**' is used for indicating the beginning of kernel-doc comments. Replace uses of '/**' for invalid cases in dt-binding headers and dts. Signed-off-by: Lukas Bulwahn --- Rob, please pick this quick kernel-doc cleanup patch. arch/arm64/boot/dts/hisilicon/hip05-d02.dts| 2 +- arch/arm64/boot/dts/hisilicon/hip05.dtsi | 2 +- arch/arm64/boot/dts/hisilicon/hip06-d03.dts| 2 +- arch/arm64/boot/dts/hisilicon/hip06.dtsi | 4 ++-- arch/arm64/boot/dts/hisilicon/hip07-d05.dts| 2 +- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 2 +- include/dt-bindings/reset/hisi,hi6220-resets.h | 2 +- include/dt-bindings/reset/snps,hsdk-reset.h| 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts index 369b69b17b91..3d3d52bf41f5 100644 --- a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts +++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0-only -/** +/* * dts file for Hisilicon D02 Development Board * * Copyright (C) 2014,2015 Hisilicon Ltd. diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi b/arch/arm64/boot/dts/hisilicon/hip05.dtsi index 4aed8d440b3a..5161e3476531 100644 --- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0-only -/** +/* * dts file for Hisilicon D02 Development Board * * Copyright (C) 2014,2015 Hisilicon Ltd. diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts index 9f4a930e734d..97aa42a86fd9 100644 --- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts +++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0-only -/** +/* * dts file for Hisilicon D03 Development Board * * Copyright (C) 2016 Hisilicon Ltd. diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi index 7deca5f763d5..d86ee1d25ab8 100644 --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0-only -/** +/* * dts file for Hisilicon D03 Development Board * * Copyright (C) 2016 Hisilicon Ltd. @@ -315,7 +315,7 @@ }; }; - /** + /* * HiSilicon erratum 161010801: This describes the limitation * of HiSilicon platforms hip06/hip07 to support the SMMUv3 * mappings for PCIe MSI transactions. diff --git a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts index 81a2312c8a26..57debca7b1ac 100644 --- a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts +++ b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0-only -/** +/* * dts file for Hisilicon D05 Development Board * * Copyright (C) 2016 Hisilicon Ltd. diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi index 2172d8071181..553f7c5209ad 100644 --- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0-only -/** +/* * dts file for Hisilicon D05 Development Board * * Copyright (C) 2016 Hisilicon Ltd. diff --git a/include/dt-bindings/reset/hisi,hi6220-resets.h b/include/dt-bindings/reset/hisi,hi6220-resets.h index 63aff7d8aa45..c67f479eede7 100644 --- a/include/dt-bindings/reset/hisi,hi6220-resets.h +++ b/include/dt-bindings/reset/hisi,hi6220-resets.h @@ -1,5 +1,5 @@ /* SPDX-License-Identifier: GPL-2.0 */ -/** +/* * This header provides index for the reset controller * based on hi6220 SoC. */ diff --git a/include/dt-bindings/reset/snps,hsdk-reset.h b/include/dt-bindings/reset/snps,hsdk-reset.h index e1a643e4bc91..6a331c8d834d 100644 --- a/include/dt-bindings/reset/snps,hsdk-reset.h +++ b/include/dt-bindings/reset/snps,hsdk-reset.h @@ -1,4 +1,4 @@ -/** +/* * This header provides index for the HSDK reset controller. */ #ifndef _DT_BINDINGS_RESET_CONTROLLER_SNPS_HSDK -- 2.17.1
[PATCH] watchdog: fix syntactic kernel-doc issues
The command 'find drivers/watchdog | xargs ./scripts/kernel-doc -none'
reports a number of kernel-doc warnings in the watchdog subsystem.
Address the kernel-doc warnings that were purely syntactic issues with
kernel-doc comments.
The remaining kernel-doc warnings are of type "Excess function parameter"
and "Function parameter or member not described". These warnings would
need to be addressed in a second pass with a bit more insight into the
APIs and purpose of the functions in the watchdog subsystem.
Signed-off-by: Lukas Bulwahn
---
Guenter, Wim, please pick this minor clean-up patch.
drivers/watchdog/booke_wdt.c | 2 +-
drivers/watchdog/eurotechwdt.c | 2 +-
drivers/watchdog/mei_wdt.c | 8
drivers/watchdog/octeon-wdt-main.c | 12 +++-
drivers/watchdog/pc87413_wdt.c | 2 +-
drivers/watchdog/wdt.c | 4 ++--
drivers/watchdog/wdt_pci.c | 2 +-
7 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 7817fb976f9c..5e4dc1a0f2c6 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -148,7 +148,7 @@ static void __booke_wdt_enable(void *data)
}
/**
- * booke_wdt_disable - disable the watchdog on the given CPU
+ * __booke_wdt_disable - disable the watchdog on the given CPU
*
* This function is called on each CPU. It disables the watchdog on that CPU.
*
diff --git a/drivers/watchdog/eurotechwdt.c b/drivers/watchdog/eurotechwdt.c
index 2418ebb707bd..ce682942662c 100644
--- a/drivers/watchdog/eurotechwdt.c
+++ b/drivers/watchdog/eurotechwdt.c
@@ -392,7 +392,7 @@ static struct notifier_block eurwdt_notifier = {
};
/**
- * cleanup_module:
+ * eurwdt_exit:
*
* Unload the watchdog. You cannot do this with any file handles open.
* If your watchdog is set to continue ticking on close and you unload
diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
index e023d7d90d66..c7a7235e6224 100644
--- a/drivers/watchdog/mei_wdt.c
+++ b/drivers/watchdog/mei_wdt.c
@@ -105,7 +105,7 @@ struct mei_wdt {
#endif /* CONFIG_DEBUG_FS */
};
-/*
+/**
* struct mei_mc_hdr - Management Control Command Header
*
* @command: Management Control (0x2)
@@ -121,7 +121,7 @@ struct mei_mc_hdr {
};
/**
- * struct mei_wdt_start_request watchdog start/ping
+ * struct mei_wdt_start_request - watchdog start/ping
*
* @hdr: Management Control Command Header
* @timeout: timeout value
@@ -134,7 +134,7 @@ struct mei_wdt_start_request {
} __packed;
/**
- * struct mei_wdt_start_response watchdog start/ping response
+ * struct mei_wdt_start_response - watchdog start/ping response
*
* @hdr: Management Control Command Header
* @status: operation status
@@ -474,7 +474,7 @@ static void mei_wdt_rx(struct mei_cl_device *cldev)
complete(>response);
}
-/*
+/**
* mei_wdt_notif - callback for event notification
*
* @cldev: bus device
diff --git a/drivers/watchdog/octeon-wdt-main.c
b/drivers/watchdog/octeon-wdt-main.c
index fde9e739b436..298c070884c4 100644
--- a/drivers/watchdog/octeon-wdt-main.c
+++ b/drivers/watchdog/octeon-wdt-main.c
@@ -119,7 +119,7 @@ static int cpu2core(int cpu)
}
/**
- * Poke the watchdog when an interrupt is received
+ * octeon_wdt_poke_irq - Poke the watchdog when an interrupt is received
*
* @cpl:
* @dev_id:
@@ -153,7 +153,7 @@ static irqreturn_t octeon_wdt_poke_irq(int cpl, void
*dev_id)
extern int prom_putchar(char c);
/**
- * Write a string to the uart
+ * octeon_wdt_write_string - Write a string to the uart
*
* @str:String to write
*/
@@ -165,7 +165,7 @@ static void octeon_wdt_write_string(const char *str)
}
/**
- * Write a hex number out of the uart
+ * octeon_wdt_write_hex() - Write a hex number out of the uart
*
* @value: Number to display
* @digits: Number of digits to print (1 to 16)
@@ -192,6 +192,8 @@ static const char reg_name[][3] = {
};
/**
+ * octeon_wdt_nmi_stage3:
+ *
* NMI stage 3 handler. NMIs are handled in the following manner:
* 1) The first NMI handler enables CVMSEG and transfers from
* the bootbus region into normal memory. It is careful to not
@@ -513,7 +515,7 @@ static struct watchdog_device octeon_wdt = {
static enum cpuhp_state octeon_wdt_online;
/**
- * Module/ driver initialization.
+ * octeon_wdt_init - Module/ driver initialization.
*
* Returns Zero on success
*/
@@ -585,7 +587,7 @@ static int __init octeon_wdt_init(void)
}
/**
- * Module / driver shutdown
+ * octeon_wdt_cleanup - Module / driver shutdown
*/
static void __exit octeon_wdt_cleanup(void)
{
diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
index 2d4504302c9e..9f9a340427fc 100644
--- a/drivers/watchdog/pc87413_wdt.c
+++ b/drivers/watchdog/pc87413_wdt.c
@@ -445,7 +445,7 @@ static long pc87413_ioctl(struct file *file, unsigned int
cmd,
Re: [PATCH] ntfs: fix incorrect kernel-doc comment syntax in files
On Sat, Mar 20, 2021 at 5:29 PM Aditya Srivastava wrote:
>
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> There are certain files in fs/ntfs which follow this syntax, but the
> content inside does not comply with kernel-doc.
> Such lines were probably not meant for kernel-doc parsing, but are parsed
> due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
> causes unexpected warnings from kernel-doc.
>
> E.g., presence of kernel-doc like comment in the header for
> fs/ntfs/attrib.c, causes these unexpected warnings by kernel-doc:
> "warning: Incorrect use of kernel-doc format: * ntfs_map_runlist_nolock -
> map (a part of) a runlist of an ntfs inode"
> "warning: Function parameter or member 'ni' not described in
> 'ntfs_map_runlist_nolock'"
> "warning: Function parameter or member 'vcn' not described in
> 'ntfs_map_runlist_nolock'"
> "warning: Function parameter or member 'ctx' not described in
> 'ntfs_map_runlist_nolock'"
> "warning: expecting prototype for c(). Prototype was for
> ntfs_map_runlist_nolock() instead"
>
> Similarly for other files too.
>
> Provide a simple fix by replacing such occurrences with general comment
> format, i.e. '/*', to prevent kernel-doc from parsing it.
>
> Signed-off-by: Aditya Srivastava
> ---
> * Applies perfectly on next-20210319
>
> fs/ntfs/aops.c | 2 +-
> fs/ntfs/aops.h | 2 +-
> fs/ntfs/attrib.c | 2 +-
> fs/ntfs/compress.c | 8
> fs/ntfs/dir.c | 4 ++--
> fs/ntfs/inode.c| 2 +-
> fs/ntfs/mft.c | 2 +-
> fs/ntfs/runlist.c | 2 +-
> 8 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/fs/ntfs/aops.c b/fs/ntfs/aops.c
> index bb0a43860ad2..1024cdec136a 100644
> --- a/fs/ntfs/aops.c
> +++ b/fs/ntfs/aops.c
> @@ -1,5 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
> -/**
> +/*
> * aops.c - NTFS kernel address space operations and page cache handling.
> *
> * Copyright (c) 2001-2014 Anton Altaparmakov and Tuxera Inc.
> diff --git a/fs/ntfs/aops.h b/fs/ntfs/aops.h
> index f0962d46bd67..2dcd46befdff 100644
> --- a/fs/ntfs/aops.h
> +++ b/fs/ntfs/aops.h
> @@ -1,5 +1,5 @@
> /* SPDX-License-Identifier: GPL-2.0-or-later */
> -/**
> +/*
> * aops.h - Defines for NTFS kernel address space operations and page cache
> * handling. Part of the Linux-NTFS project.
> *
> diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
> index d563abc3e136..2911c04a33e0 100644
> --- a/fs/ntfs/attrib.c
> +++ b/fs/ntfs/attrib.c
> @@ -1,5 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
> -/**
> +/*
> * attrib.c - NTFS attribute operations. Part of the Linux-NTFS project.
> *
> * Copyright (c) 2001-2012 Anton Altaparmakov and Tuxera Inc.
> diff --git a/fs/ntfs/compress.c b/fs/ntfs/compress.c
> index d2f9d6a0ee32..014dbd079ad5 100644
> --- a/fs/ntfs/compress.c
> +++ b/fs/ntfs/compress.c
> @@ -1,5 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
> -/**
> +/*
> * compress.c - NTFS kernel compressed attributes handling.
> * Part of the Linux-NTFS project.
> *
> @@ -18,7 +18,7 @@
> #include "debug.h"
> #include "ntfs.h"
>
> -/**
> +/*
> * ntfs_compression_constants - enum of constants used in the compression
> code
here this one should probably be prefixed with enum; then, it should
be valid kernel-doc.
> */
> typedef enum {
> @@ -41,12 +41,12 @@ typedef enum {
> NTFS_MAX_CB_SIZE= 64 * 1024,
> } ntfs_compression_constants;
>
> -/**
> +/*
> * ntfs_compression_buffer - one buffer for the decompression engine
> */
> static u8 *ntfs_compression_buffer;
>
> -/**
> +/*
> * ntfs_cb_lock - spinlock which protects ntfs_compression_buffer
> */
> static DEFINE_SPINLOCK(ntfs_cb_lock);
> diff --git a/fs/ntfs/dir.c b/fs/ntfs/dir.c
> index cd96083a12c8..518c3a21a556 100644
> --- a/fs/ntfs/dir.c
> +++ b/fs/ntfs/dir.c
> @@ -1,5 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
> -/**
> +/*
> * dir.c - NTFS kernel directory operations. Part of the Linux-NTFS project.
> *
> * Copyright (c) 2001-2007 Anton Altaparmakov
> @@ -17,7 +17,7 @@
> #include "debug.h"
> #include "ntfs.h"
>
> -/**
> +/*
> * The little endian Unicode string $I30 as a global constant.
> */
> ntfschar I30[5] = { cpu_to_le16('$'), cpu_to_le16('I'),
> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
> index f5c058b3192c..4277d0fd7d88 100644
> --- a/fs/ntfs/inode.c
> +++ b/fs/ntfs/inode.c
> @@ -1,5 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
> -/**
> +/*
> * inode.c - NTFS kernel inode handling.
> *
> * Copyright (c) 2001-2014 Anton Altaparmakov and Tuxera Inc.
> diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c
> index 0d62cd5bb7f8..d197d402933a 100644
> --- a/fs/ntfs/mft.c
> +++ b/fs/ntfs/mft.c
> @@ -1,5 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
> -/**
> +/*
> * mft.c - NTFS kernel mft record operations. Part of the Linux-NTFS project.
> *
> * Copyright (c) 2001-2012 Anton Altaparmakov
Re: [RFC] scripts: kernel-doc: avoid warnings due to initial commented lines in file
On Sat, Mar 20, 2021 at 1:45 PM Aditya Srivastava wrote: > > On 20/3/21 12:23 pm, Aditya wrote: > > On 18/3/21 11:48 pm, Jonathan Corbet wrote: > >> Lukas Bulwahn writes: > >> > >>> Yeah, and as this line-counting is really just a poor man's > >>> heuristics, we might just be better to really turn this heuristics > >>> into a dedicated cleanup warning script, then we can check for more > >>> indicators, such as "does it contain the word Copyright" somewhere in > >>> the kernel-doc comment, which tells us even more that this is not a > >>> kernel-doc as we would expect it. > >> > >> I really don't think we need that kind of heuristic. The format of > >> kerneldoc comments is fairly rigid; it shouldn't be too hard to pick out > >> the /** comments that don't fit that format, right? Am I missing > >> something there? > >> > >> Thanks, > >> > >> jon > >> > > Hi Lukas and Jon! > I have a question, should I clean up the files with '/**' like > comments in only header lines? Or as we are planning for making it > generic, for other lines as well? > Aditya, of course, if you can detect and come across some unintended '/**' comments in some files, clean them in the same go (as you did with ecryptfs). I am just worried that if you extend it to the fully generic case, that the list of cases simply explodes: showing many 1,000 cases across various 1,000 files that need to be cleaned up, and such clean-up work is just too much to get done by yourself. The current list limited to comments in header lines seems to be a set of patches that you can probably get done. Lukas
Re: [RFC] scripts: kernel-doc: avoid warnings due to initial commented lines in file
On Thu, Mar 18, 2021 at 5:37 PM Jonathan Corbet wrote: > > Lukas Bulwahn writes: > > > I wonder if we could extend kernel-doc (not your preferred option as > > it seems) for a new dedicated warning message or maintain a separate > > kernel-doc sanity checking script to emit a dedicated warning based on > > some heuristics that suggests when a "header comment" is probably > > unintentionally declared as a "kernel-doc comment" when it really > > should not be. > > > > Jonathan, would you then prefer to have a separate kernel-doc sanity > > checking script that then allows us to maintain checking for patterns > > we already cleaned up? > > Having a warning in kernel-doc for "This comment starts with /** but > isn't a kerneldoc comment" could be useful, I guess. That is the real > problem, not the fact that it appears at the top of the file. I'm all > for tools that help us to clean things up, but let's not add > line-counting hacks to try to paper it over. > Yeah, and as this line-counting is really just a poor man's heuristics, we might just be better to really turn this heuristics into a dedicated cleanup warning script, then we can check for more indicators, such as "does it contain the word Copyright" somewhere in the kernel-doc comment, which tells us even more that this is not a kernel-doc as we would expect it. Aditya, would you like to try to turn this check into a separate script instead? Lukas
[PATCH] MAINTAINERS: remove obsolete OMAP HWMOD DATA FOR OMAP4-BASED DEVICES
Commit 2584d7e7f87a ("ARM: OMAP2+: Drop legacy platform data for omap4
hwmod") drops the file ./arch/arm/mach-omap2/omap_hwmod_44xx_data.c, but
misses to drop the now obsolete OMAP HWMOD DATA FOR OMAP4-BASED DEVICES
section in MAINTAINERS, which refers to only that file.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c
Remove the obsolete OMAP HWMOD DATA FOR OMAP4-BASED DEVICES section.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 6 --
1 file changed, 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 19707dc45e0a..bf219411d4eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13080,12 +13080,6 @@ L: linux-o...@vger.kernel.org
S: Maintained
F: arch/arm/mach-omap2/omap_hwmod*data*
-OMAP HWMOD DATA FOR OMAP4-BASED DEVICES
-M: Benoît Cousson
-L: linux-o...@vger.kernel.org
-S: Maintained
-F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c
-
OMAP HWMOD SUPPORT
M: Benoît Cousson
M: Paul Walmsley
--
2.17.1
Re: Checkpatch still worries about include/asm/ ?
On Thu, Mar 18, 2021 at 5:47 PM Dwaipayan Ray wrote:
>
> Hello,
> include/asm/ got removed a long time back (probably v1.1.45).
> Checkpatch still worries about that:
>
> if ($realfile =~ m@^include/asm/@) {
> ERROR("MODIFIED_INCLUDE_ASM",
> "do not modify files in include/asm, change architecture specific
> files in include/asm-\n" . "$here$rawline\n");
> }
>
> Can we remove this check?
>
Wow, v1.1.45... that must have been taking quite some digging in the
ancient dirt to find that out.
I agree, let us remove that rule.
Thanks for the documentation effort on checkpatch.pl and cleaning up
obsolete rules while documenting.
Lukas
Re: [RFC] scripts: kernel-doc: avoid warnings due to initial commented lines in file
On Mon, Mar 15, 2021 at 8:25 PM Jonathan Corbet wrote:
>
> Aditya writes:
>
> >> The opening comment mark /** is used for kernel-doc comments [1]
> >>
> >> [1]
> >> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#how-to-format-kernel-doc-comments
> >>
> >
> > Hi Markus!
> > That's true. But the content inside the comment does not follow
> > kernel-doc format.
> > For e.g., try running kernel-doc -none/man/rst on the above file in
> > the example("sound/pci/ctxfi/ctresource.c").
> > The starting 2-3 lines in files generally do not contain any
> > struct/enum/function, etc. declaration.
>
> The problem is that it's marked as a kerneldoc comment without actually
> being one; it looks like somebody's internal corporate formatting. The
> fix is not to put a hack into kernel-doc - we have more than enough of
> those in the file already! The right thing to do is to remove the extra
> "*" so that the comment doesn't look like a kerneldoc comment anymore.
>
Jonathan, I agree that that is the right thing to do. Aditya is
already following through and is cleaning up the repository. So, let
us be optimistic that we will have cleaned up all of those occurrences
within a few weeks. But how to continue? Someone is going to come with
new files and introduce this pattern again in the repository; and as
of now, we do not have a script to identify that pattern and react...
Running kernel-doc on the whole tree continuously and just observing
the new warnings is probably not going to work as of now: there are
20,000 kernel-doc warnings and at least, I cannot see a really good
way to filter out this one specific type of issue among all the
warnings that will might appear in the future (without specifically
applying Aditya's patch and looking at the diff before and after).
I wonder if we could extend kernel-doc (not your preferred option as
it seems) for a new dedicated warning message or maintain a separate
kernel-doc sanity checking script to emit a dedicated warning based on
some heuristics that suggests when a "header comment" is probably
unintentionally declared as a "kernel-doc comment" when it really
should not be.
Jonathan, would you then prefer to have a separate kernel-doc sanity
checking script that then allows us to maintain checking for patterns
we already cleaned up?
Eventually, we might have cleaned up enough to just use kernel-doc and
keep it kind of warning-free (as with make htmldocs now) and then, we
can simply follow up with kernel-doc and some basic monitoring
scripts, but with 20,000 warnings in the whole repository to start
with, it is still a long way to that point, IMHO.
Lukas
Re: [PATCH 13/13] MAINTAINERS: Add entry for the bitmap API
On Wed, Mar 17, 2021 at 5:57 AM Joe Perches wrote: > > On Tue, 2021-03-16 at 21:47 -0700, Yury Norov wrote: > > [CC Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn] > > > > On Tue, Mar 16, 2021 at 01:45:51PM +0200, Andy Shevchenko wrote: > > > On Mon, Mar 15, 2021 at 06:54:24PM -0700, Yury Norov wrote: > > > > Add myself as maintainer for bitmap API and Andy and Rasmus as > > > > reviewers. > > > > > > > > I'm an author of current implementation of lib/find_bit and an active > > > > contributor to lib/bitmap. It was spotted that there's no maintainer for > > > > bitmap API. I'm willing to maintain it. > > > > > > > > Signed-off-by: Yury Norov > > > > Acked-by: Andy Shevchenko > > > > Acked-by: Rasmus Villemoes > > > > --- > > > > MAINTAINERS | 16 > > > > 1 file changed, 16 insertions(+) > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index 3dd20015696e..44f94cdd5a20 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -3151,6 +3151,22 @@ F: Documentation/filesystems/bfs.rst > > > > F: fs/bfs/ > > > > F: include/uapi/linux/bfs_fs.h > > > > > > > > > > > > +BITMAP API > > > > +M: Yury Norov > > > > +R: Andy Shevchenko > > > > +R: Rasmus Villemoes > > > > +S: Maintained > > > > +F: include/asm-generic/bitops/find.h > > > > +F: include/linux/bitmap.h > > > > +F: lib/bitmap.c > > > > +F: lib/find_bit.c > > > > > > > +F: lib/find_find_bit_benchmark.c > > > > > > Does this file exist? > > > I guess checkpatch.pl nowadays has a MAINTAINER data base validation. > > > > No lib/find_find_bit_benchmark.c doesn't exist. It's a typo, it should > > be lib/find_bit_benchmark.c. Checkpatch doesn't warn: > > > > yury:linux$ scripts/checkpatch.pl > > 0013-MAINTAINERS-Add-entry-for-the-bitmap-API.patch > > total: 0 errors, 0 warnings, 22 lines checked > > checkpatch does not validate filenames for each patch. > > checkpatch does have a --self-test=patterns capability that does > validate file accessibility. Joe meant: get_maintainers does have a --self-test=patterns capability that does validate file accessibility. You can run that before patch submission; otherwise, I run that script on linux-next once a week and send out correction patches as far as my "spare" time allows to do so. Lukas
[PATCH 5/5] MAINTAINERS: rectify entries for dt-bindings
Jonathan Cameron converted a number of dt-bindings from txt to yaml in
./Documentation/devicetree/bindings/iio/:
Commit 58ff1b519753 ("dt-bindings:iio:adc:atmel,sama5d2-adc: txt to yaml
conversion"):
adc/at91-sama5d2_adc.txt -> atmel,sama5d2-adc.yaml
Commit 8c41245872e2 ("dt-bindings:iio:adc:renesas,rcar-gyroadc: txt to yaml
conversion."):
adc/renesas,gyroadc.txt -> adc/renesas,rcar-gyroadc.yaml
Commit 9a6ac3138258 ("dt-bindings:iio:humidity:st,hts221 yaml conversion."):
humidity/hts221.txt -> humidity/st,hts221.yaml
Commit 1e6536ee349b ("dt-bindings:iio:dac:adi,ad5758 yaml conversion"):
dac/ad5758.txt -> dac/adi,ad5758.yaml
Commit 7a2cf8e91390 ("dt-bindings:iio:imu:st,lsm6dsx: txt to yaml
conversion"):
imu/st_lsm6dsx.txt -> imu/st,lsm6dsx.yaml
Commit b4be8bd1c6a2 ("dt-bindings:iio:proximity:st,vl53l0x yaml conversion"):
proximity/vl53l0x.txt -> proximity/st,vl53l0x.yaml
All these txt files above are referenced in MAINTAINERS.
Adjust the sections with references to converted dt-bindings yaml files.
As .../dac/adi,ad5758.yaml is already covered by .../*/adi,*, simply
drop the file entry for .../dac/ad5758.txt.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a046e62b619d..7df1e7b37e68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1142,7 +1142,6 @@ W:
http://ez.analog.com/community/linux-device-drivers
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
F: Documentation/devicetree/bindings/iio/*/adi,*
-F: Documentation/devicetree/bindings/iio/dac/ad5758.txt
F: drivers/iio/*/ad*
F: drivers/iio/adc/ltc249*
F: drivers/iio/amplifiers/hmc425a.c
@@ -8224,7 +8223,7 @@ M:Lorenzo Bianconi
L: linux-...@vger.kernel.org
S: Maintained
W: http://www.st.com/
-F: Documentation/devicetree/bindings/iio/humidity/hts221.txt
+F: Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml
F: drivers/iio/humidity/hts221*
HUAWEI ETHERNET DRIVER
@@ -11824,7 +11823,7 @@ MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER
M: Eugen Hristev
L: linux-...@vger.kernel.org
S: Supported
-F: Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
+F: Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
F: drivers/iio/adc/at91-sama5d2_adc.c
F: include/dt-bindings/iio/adc/at91-sama5d2_adc.h
@@ -15294,7 +15293,7 @@ RENESAS R-CAR GYROADC DRIVER
M: Marek Vasut
L: linux-...@vger.kernel.org
S: Supported
-F: Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
+F: Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml
F: drivers/iio/adc/rcar-gyroadc.c
RENESAS R-CAR I2C DRIVERS
@@ -16975,7 +16974,7 @@ M: Lorenzo Bianconi
L: linux-...@vger.kernel.org
S: Maintained
W: http://www.st.com/
-F: Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
+F: Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
F: drivers/iio/imu/st_lsm6dsx/
ST MIPID02 CSI-2 TO PARALLEL BRIDGE DRIVER
@@ -17003,7 +17002,7 @@ ST VL53L0X ToF RANGER(I2C) IIO DRIVER
M: Song Qiang
L: linux-...@vger.kernel.org
S: Maintained
-F: Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
+F: Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml
F: drivers/iio/proximity/vl53l0x-i2c.c
STABLE BRANCH
--
2.17.1
[PATCH 3/5] MAINTAINERS: rectify entry for HIKEY960 ONBOARD USB GPIO HUB DRIVER
Commit 7a6ff4c4cbc3 ("misc: hisi_hikey_usb: Driver to support onboard USB
gpio hub on Hikey960") refers to the non-existing file
./Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml, but this
commit's patch series does not add any related devicetree binding in misc.
So, just drop this file reference in HIKEY960 ONBOARD USB GPIO HUB DRIVER.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 89404ca760b9..66c756c68bfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8085,7 +8085,6 @@ M:John Stultz
L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/misc/hisi_hikey_usb.c
-F: Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml
HISILICON PMU DRIVER
M: Shaokun Zhang
--
2.17.1
[PATCH 4/5] MAINTAINERS: rectify entry for INTEL KEEM BAY DRM DRIVER
Commit ed794057b052 ("drm/kmb: Build files for KeemBay Display driver")
refers to the non-existing file intel,kmb_display.yaml in
./Documentation/devicetree/bindings/display/.
Commit 5a76b1ed73b9 ("dt-bindings: display: Add support for Intel KeemBay
Display") originating from the same patch series however adds the file
intel,keembay-display.yaml in that directory instead.
So, refer to intel,keembay-display.yaml in the INTEL KEEM BAY DRM DRIVER
section instead.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 66c756c68bfd..a046e62b619d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9096,7 +9096,7 @@ INTEL KEEM BAY DRM DRIVER
M: Anitha Chrisanthus
M: Edmund Dea
S: Maintained
-F: Documentation/devicetree/bindings/display/intel,kmb_display.yaml
+F: Documentation/devicetree/bindings/display/intel,keembay-display.yaml
F: drivers/gpu/drm/kmb/
INTEL KEEM BAY OCS AES/SM4 CRYPTO DRIVER
--
2.17.1
[PATCH 1/5] MAINTAINERS: rectify some references automatically
Some references in MAINTAINERS can be automatically rectified with ./scripts/documentation-file-ref-check --fix. Adjust those file entries with this script. Signed-off-by: Lukas Bulwahn --- MAINTAINERS | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4cf10cb2b858..251e205b5444 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5794,7 +5794,7 @@ DRM DRIVER FOR ST-ERICSSON MCDE M: Linus Walleij S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc -F: Documentation/devicetree/bindings/display/ste,mcde.txt +F: Documentation/devicetree/bindings/display/ste,mcde.yaml F: drivers/gpu/drm/mcde/ DRM DRIVER FOR TDFX VIDEO CARDS @@ -6069,7 +6069,7 @@ DRM DRIVERS FOR V3D M: Eric Anholt S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc -F: Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt +F: Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml F: drivers/gpu/drm/v3d/ F: include/uapi/drm/v3d_drm.h @@ -7211,7 +7211,7 @@ M:Li Yang L: linuxppc-...@lists.ozlabs.org L: linux-arm-ker...@lists.infradead.org S: Maintained -F: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt +F: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml F: Documentation/devicetree/bindings/soc/fsl/ F: drivers/soc/fsl/ F: include/linux/fsl/ @@ -8691,7 +8691,7 @@ M:Peter Rosin L: linux-...@vger.kernel.org S: Maintained F: Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac -F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt +F: Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml F: drivers/iio/dac/dpot-dac.c IIO ENVELOPE DETECTOR @@ -8699,7 +8699,7 @@ M:Peter Rosin L: linux-...@vger.kernel.org S: Maintained F: Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector -F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt +F: Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml F: drivers/iio/adc/envelope-detector.c IIO MULTIPLEXER @@ -8728,9 +8728,9 @@ IIO UNIT CONVERTER M: Peter Rosin L: linux-...@vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt -F: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt -F: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt +F: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml +F: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml +F: Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml F: drivers/iio/afe/iio-rescale.c IKANOS/ADI EAGLE ADSL USB DRIVER @@ -9329,7 +9329,7 @@ INVENSENSE MPU-3050 GYROSCOPE DRIVER M: Linus Walleij L: linux-...@vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.txt +F: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml F: drivers/iio/gyro/mpu3050* IOC3 ETHERNET DRIVER @@ -11306,7 +11306,7 @@ F: drivers/media/platform/mtk-vpu/ MEDIATEK MMC/SD/SDIO DRIVER M: Chaotian Jing S: Maintained -F: Documentation/devicetree/bindings/mmc/mtk-sd.txt +F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml F: drivers/mmc/host/mtk-sd.c MEDIATEK MT76 WIRELESS LAN DRIVER @@ -13222,7 +13222,7 @@ M: Rui Miguel Silva L: linux-me...@vger.kernel.org S: Maintained T: git git://linuxtv.org/media_tree.git -F: Documentation/devicetree/bindings/media/i2c/ov2680.yaml +F: Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml F: drivers/media/i2c/ov2680.c OMNIVISION OV2685 SENSOR DRIVER @@ -14317,7 +14317,7 @@ PNI RM3100 IIO DRIVER M: Song Qiang L: linux-...@vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt +F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.yaml F: drivers/iio/magnetometer/rm3100* PNP SUPPORT @@ -15116,7 +15116,7 @@ M: Laurent Pinchart M: Niklas Söderlund L: linux-me...@vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml +F: Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml F: drivers/media/i2c/max9271.c F: drivers/media/i2c/max9271.h F: drivers/media/i2c/rdacm21.c @@ -17324,7 +17324,7 @@ F: drivers/spi/spi-dw* SYNOPSYS DESIGNWARE AXI DMAC DRIVER M: Eugeniy Paltsev S: Maintained -F: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt +F: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml F: drivers/dma/dw-axi-dmac/ SYNOPSYS DESIGNWARE DMAC DRIVER @@ -17740,7 +17740,7 @@ TEXAS INSTRUMENTS' DAC7612 DAC DRIVER M: Ricardo Ribalda L: linux
[PATCH 2/5] MAINTAINERS: rectify entry for ARM/TOSHIBA VISCONTI ARCHITECTURE
Commit 836863a08c99 ("MAINTAINERS: Add information for Toshiba Visconti ARM
SoCs") refers to the non-existing file toshiba,tmpv7700-pinctrl.yaml in
./Documentation/devicetree/bindings/pinctrl/. Commit 1825c1fe0057
("pinctrl: Add DT bindings for Toshiba Visconti TMPV7700 SoC") originating
from the same patch series however adds the file
toshiba,visconti-pinctrl.yaml in that directory instead.
So, refer to toshiba,visconti-pinctrl.yaml in the ARM/TOSHIBA VISCONTI
ARCHITECTURE section instead.
Signed-off-by: Lukas Bulwahn
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 251e205b5444..89404ca760b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2621,7 +2621,7 @@ T:git
git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti.git
F: Documentation/devicetree/bindings/arm/toshiba.yaml
F: Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
F: Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
-F: Documentation/devicetree/bindings/pinctrl/toshiba,tmpv7700-pinctrl.yaml
+F: Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml
F: Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
F: arch/arm64/boot/dts/toshiba/
F: drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
--
2.17.1
[PATCH 0/5] Rectify file references for dt-bindings in MAINTAINERS
Hi Rob, here is a patch series that cleans up all file references for dt-bindings in MAINTAINERS. It applies cleanly on next-20210315. With this patch series and another patch (already accepted elsewhere) [see Link], ./scripts/get_maintainers.pl --self-test=patterns reports no further warning on next-20210315. Could you pick this series for your devicetree bindings tree? No functional change, just cleaning up MAINTAINERS. Lukas Link: https://lore.kernel.org/lkml/20210208071619.3234-1-lukas.bulw...@gmail.com/ Lukas Bulwahn (5): MAINTAINERS: rectify some references automatically MAINTAINERS: rectify entry for ARM/TOSHIBA VISCONTI ARCHITECTURE MAINTAINERS: rectify entry for HIKEY960 ONBOARD USB GPIO HUB DRIVER MAINTAINERS: rectify entry for INTEL KEEM BAY DRM DRIVER MAINTAINERS: rectify entries for dt-bindings MAINTAINERS | 46 ++ 1 file changed, 22 insertions(+), 24 deletions(-) -- 2.17.1
Re: [PATCH 00/10] rsi: fix comment syntax in file headers
On Sun, Mar 14, 2021 at 9:18 PM Aditya Srivastava wrote: > > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > There are files in drivers/net/wireless/rsi which follow this syntax in > their file headers, i.e. start with '/**' like comments, which causes > unexpected warnings from kernel-doc. > > E.g., running scripts/kernel-doc -none on drivers/net/wireless/rsi/rsi_coex.h > causes this warning: > "warning: wrong kernel-doc identifier on line: > * Copyright (c) 2018 Redpine Signals Inc." > > Similarly for other files too. > > Provide a simple fix by replacing the kernel-doc like comment syntax with > general format, i.e. "/*", to prevent kernel-doc from parsing it. > Aditya, thanks for starting to clean up the repository following your investigation on kernel-doc warnings. The changes to all those files look sound. However I think these ten patches are really just _one change_, and hence, all can be put into a single commit. Hints that suggest it is one change: - The commit message is pretty much the same (same motivation, same explanation, same design decisions) - The change is basically the same (same resulting change in different files) - All patches are sent to the same responsible people, all of the patches would be reviewed and accepted by the same people. - All ten patches can be reviewed at once. How about merging all ten patches into one patch and sending out a v2. Lukas
Re: [RFC] scripts: kernel-doc: avoid warnings due to initial commented lines in file
On Thu, Mar 11, 2021 at 10:04 PM Aditya wrote:
>
> On 10/3/21 11:49 am, Lukas Bulwahn wrote:
> > On Tue, Mar 9, 2021 at 10:24 PM Aditya wrote:
> >>
> >> On 9/3/21 7:00 pm, Markus Heiser wrote:
> >>>
> >>> Am 09.03.21 um 13:53 schrieb Aditya Srivastava:
> >>>> Starting commented lines in a file mostly contains comments describing
> >>>> license, copyright or general information about the file.
> >>>>
> >>>> E.g., in sound/pci/ctxfi/ctresource.c, initial comment lines describe
> >>>> its copyright and other related file informations.
> >>>
> >>> The opening comment mark /** is used for kernel-doc comments [1]
> >>>
> >>> [1]
> >>> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#how-to-format-kernel-doc-comments
> >>>
> >>
> >> Hi Markus!
> >> That's true. But the content inside the comment does not follow
> >> kernel-doc format.
> >> For e.g., try running kernel-doc -none/man/rst on the above file in
> >> the example("sound/pci/ctxfi/ctresource.c").
> >> The starting 2-3 lines in files generally do not contain any
> >> struct/enum/function, etc. declaration.
> >>
> >
> > Aditya, can you provide a diff of the warnings over the whole kernel tree?
> >
> > At the moment, your patch just implements ignoring the initial
> > comment, which probably is good for experimentation.
> >
> > Alternatively, we could simply have a dedicated warning and then
> > ignore it or even warn and then parse it as-if.
> >
> > In the "long run", we would probably want to fix all current files in
> > the repository by just replacing '/**' by '/*' and have kernel-doc
> > warn about this suspicious pattern, when new files appear (maybe even
> > configurable, but that is another feature to enable or disable certain
> > kernel-doc checks and warnings). I would certainly assist and
> > contribute to such a clean-up task.
> >
> > I think the first step is to look at the diff, and see how many cases
> > really appear in the tree... then check how many patches throughout
> > the whole tree are required and if they are generally accepted.
> >
>
> Hi Lukas!
> This is the diff of the warnings over kernel tree before and after
> applying these changes.
> There are 2 sections in this report:
> 1) for the warnings present before, but not after, and;
> 2) after but not before
>
> The part (2) contains, for some cases, where the warning for "warning:
> Incorrect use of kernel-doc format:" type has changed to "warning:
> wrong kernel-doc identifier on line:" type.
>
> The diff file can be found at:
> https://github.com/AdityaSrivast/kernel-tasks/blob/master/random/kernel-doc/avoid_init_line_diff.txt
>
Thanks, let us check if we can use this diff to create a patch set
that cleans up those header comments for those files.
Lukas
Re: [RFC] scripts: kernel-doc: avoid warnings due to initial commented lines in file
On Tue, Mar 9, 2021 at 10:24 PM Aditya wrote:
>
> On 9/3/21 7:00 pm, Markus Heiser wrote:
> >
> > Am 09.03.21 um 13:53 schrieb Aditya Srivastava:
> >> Starting commented lines in a file mostly contains comments describing
> >> license, copyright or general information about the file.
> >>
> >> E.g., in sound/pci/ctxfi/ctresource.c, initial comment lines describe
> >> its copyright and other related file informations.
> >
> > The opening comment mark /** is used for kernel-doc comments [1]
> >
> > [1]
> > https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#how-to-format-kernel-doc-comments
> >
>
> Hi Markus!
> That's true. But the content inside the comment does not follow
> kernel-doc format.
> For e.g., try running kernel-doc -none/man/rst on the above file in
> the example("sound/pci/ctxfi/ctresource.c").
> The starting 2-3 lines in files generally do not contain any
> struct/enum/function, etc. declaration.
>
Aditya, can you provide a diff of the warnings over the whole kernel tree?
At the moment, your patch just implements ignoring the initial
comment, which probably is good for experimentation.
Alternatively, we could simply have a dedicated warning and then
ignore it or even warn and then parse it as-if.
In the "long run", we would probably want to fix all current files in
the repository by just replacing '/**' by '/*' and have kernel-doc
warn about this suspicious pattern, when new files appear (maybe even
configurable, but that is another feature to enable or disable certain
kernel-doc checks and warnings). I would certainly assist and
contribute to such a clean-up task.
I think the first step is to look at the diff, and see how many cases
really appear in the tree... then check how many patches throughout
the whole tree are required and if they are generally accepted.
Lukas
Re: [RFC] scripts: kernel-doc: fix attribute capture in function parsing
On Fri, Mar 5, 2021 at 8:38 PM Aditya wrote:
>
> On 6/3/21 12:13 am, Matthew Wilcox wrote:
> > On Fri, Mar 05, 2021 at 11:50:00PM +0530, Aditya Srivastava wrote:
> >> Provide a simple fix by adding "__attribute_const__" in the corresponding
> >> regex expression.
> >>
> >> A quick evaluation by running 'kernel-doc -none' on kernel-tree reveals
> >> that no additional warning or error has been added or removed by the fix.
> >
> > I'm no perlmonger, but why isn't this simply:
> >
> > +++ b/scripts/kernel-doc
> > @@ -1753,6 +1753,7 @@ sub dump_function($$) {
> > $prototype =~ s/^__inline +//;
> > $prototype =~ s/^__always_inline +//;
> > $prototype =~ s/^noinline +//;
> > +$prototype =~ s/__attribute_const__ +//;
> > $prototype =~ s/__init +//;
> > $prototype =~ s/__init_or_module +//;
> > $prototype =~ s/__meminit +//;
> >
> > (completely untested)
> >
> >> +++ b/scripts/kernel-doc
> >> @@ -1753,6 +1753,7 @@ sub dump_function($$) {
> >> my $prototype = shift;
> >> my $file = shift;
> >> my $noret = 0;
> >> +my $attribute_const = qr{__attribute_const__};
> >>
> >> print_lineno($new_start_line);
> >>
> >> @@ -1808,7 +1809,7 @@ sub dump_function($$) {
> >> $prototype =~ m/^(\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~ m/^(\w+\s*\*+)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~ m/^(\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> -$prototype =~
> >> m/^(\w+\s+\w+\s*\*+)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> +$prototype =~
> >> m/^(\w+\s+\w+\s*\*+$attribute_const?)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/
> >> ||
> >> $prototype =~
> >> m/^(\w+\s+\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~
> >> m/^(\w+\s+\w+\s+\w+\s*\*+)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
> >> $prototype =~ m/^()([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
>
> Hi Matthew
> You are correct, it should be placed there. I was considering it as a
> return type instead.
> I'll send a modified v2 with the changes.
>
Aditya, I also ran:
git ls-files | xargs ./scripts/kernel-doc -none 2>&1 | tee kernel-doc-output
cat kernel-doc-output | grep "cannot understand function prototype:" |
sed 's/[^:].*:[0-9]*: \(.*\)$/\1/' | sort
and I found another instance of failed parsing function prototypes in
mm/percpu.c:2671:
struct pcpu_alloc_info * __flatten pcpu_build_alloc_info(size_t
reserved_size, size_t dyn_size, size_t atom_size,
pcpu_fc_cpu_distance_fn_t cpu_distance_fn)
Could you address that one in your patch as well?
Lukas
Re: [RFC v3] scripts: kernel-doc: fix typedef support for struct/union parsing
On Sat, Mar 6, 2021 at 5:35 AM Matthew Wilcox wrote:
>
> On Thu, Feb 25, 2021 at 08:20:33PM +0530, Aditya Srivastava wrote:
> > +++ b/scripts/kernel-doc
> > @@ -1201,12 +1201,23 @@ sub dump_union($$) {
> > sub dump_struct($$) {
> > my $x = shift;
> > my $file = shift;
> > +my $decl_type;
> > +my $members;
> > +my $type = qr{struct|union};
> > +# For capturing struct/union definition body, i.e.
> > "{members*}qualifiers*"
> > +my $definition_body =
> > qr{\{(.*)\}(?:\s*(?:__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*};
> > -if ($x =~
> > /(struct|union)\s+(\w+)\s*\{(.*)\}(\s*(__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*/)
> > {
> > - my $decl_type = $1;
> > +if ($x =~ /($type)\s+(\w+)\s*$definition_body/) {
> > + $decl_type = $1;
> > $declaration_name = $2;
> > - my $members = $3;
> > + $members = $3;
> > +} elsif ($x =~ /typedef\s+($type)\s*$definition_body\s*(\w+)\s*;/) {
> > + $decl_type = $1;
> > + $declaration_name = $3;
> > + $members = $2;
> > +}
>
> In the same spirit as dump_function, would something like this work?
>
I agree. That might be a suitable clean-up to keep the code for
functions and struct/union parsing similar in style/spirit.
Aditya, would you like to create a patch for that?
Lukas
Re: linux kernel bug???
Hi,
On Mon, Mar 1, 2021 at 7:58 AM wrote:
>
> This is the first time for me to report something, so maybe the format is not
> right. Please correct me if I'm wrong. Thank you ~
> When using Syzkaller to fuzz Linux kernel 5.11.0, it reported one
> null-ptr-def bug in file.c. The information is as follows:
>
> The kernel's commit: c03c21ba6
> The syzkaller commit: 52e3731913ab2677be27c29ed8142b04e8f28521
>
This looks like a valid kernel issue found with syzkaller.
Given that it is reproducible, I suggest you continue with the following steps:
1. Check if it reproduces on v5.12-rc1. If not, there is already a fix
in v5.12-rc1. Try to identify the specific fix by bisection.
2. Check since when this issue occurs, e.g., does it appear on v5.10, v5.9 etc.
3. Bisect it to a specific commit.
4. Report back the results of your bisections.
Lukas
>
>
> The report:
> Syzkaller hit 'KASAN: null-ptr-deref Read in __fget_light' bug.
>
> ==
> audit: type=1400 audit(1614571961.594:8): avc: denied { execmem } for
> pid=294 comm="syz-executor894" scontext=system_u:system_r:kernel_t:s0
> tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
> BUG: KASAN: null-ptr-deref in instrument_atomic_read
> include/linux/instrumented.h:71 [inline]
> BUG: KASAN: null-ptr-deref in atomic_read
> include/asm-generic/atomic-instrumented.h:27 [inline]
> BUG: KASAN: null-ptr-deref in __fget_light+0x4f/0x250 fs/file.c:930
> Read of size 4 at addr by task io_wqe_worker-0/296
>
> CPU: 1 PID: 296 Comm: io_wqe_worker-0 Not tainted 5.11.0+ #5
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1
> 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0xaf/0xf2 lib/dump_stack.c:120
> __kasan_report mm/kasan/report.c:400 [inline]
> kasan_report.cold.9+0x10c/0x10e mm/kasan/report.c:413
> check_memory_region_inline mm/kasan/generic.c:179 [inline]
> check_memory_region+0x198/0x200 mm/kasan/generic.c:185
> instrument_atomic_read include/linux/instrumented.h:71 [inline]
> atomic_read include/asm-generic/atomic-instrumented.h:27 [inline]
> __fget_light+0x4f/0x250 fs/file.c:930
> fdget_raw include/linux/file.h:70 [inline]
> path_init+0x940/0x1290 fs/namei.c:2354
> path_lookupat.isra.65+0x2c/0x4e0 fs/namei.c:2410
> filename_lookup.part.80+0x17a/0x370 fs/namei.c:2453
> filename_lookup fs/namei.c:2446 [inline]
> user_path_at_empty+0x4b/0x80 fs/namei.c:2733
> user_path_at include/linux/namei.h:60 [inline]
> vfs_statx+0x108/0x310 fs/stat.c:195
> do_statx+0xa9/0x120 fs/stat.c:590
> io_statx fs/io_uring.c:4525 [inline]
> io_issue_sqe+0x1c31/0x4a50 fs/io_uring.c:6343
> io_wq_submit_work+0x2f7/0x8e0 fs/io_uring.c:6418
> io_worker_handle_work+0xcdd/0x1900 fs/io-wq.c:561
> io_wqe_worker+0xa15/0xeb0 fs/io-wq.c:603
> kthread+0x32a/0x3f0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
> ==
>
>
> Syzkaller reproducer:
> # {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1 Slowdown:1
> Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false NetInjection:false
> NetDevices:false NetReset:false Cgroups:false BinfmtMisc:false CloseFDs:false
> KCSAN:false DevlinkPCI:false USB:false VhciInjection:false Wifi:false
> Sysctl:false UseTmpDir:false HandleSegv:false Repro:false Trace:false}
> r0 = syz_io_uring_setup(0x1, &(0x7f80)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0}, &(0x7f0a)=nil, &(0x7f0b)=nil,
> &(0x7f000100)=0x0, &(0x7f000140)=0x0)
> syz_io_uring_submit(r1, r2, &(0x7f0008c0)=@IORING_OP_STATX={0x15, 0x0,
> 0x0, 0x, 0x0, &(0x7f0003c0)='./file1\x00', 0x20, 0x1000},
> 0x3)
> io_uring_enter(r0, 0x1, 0x1, 0x1, 0x0, 0x0)
>
>
> C reproducer:
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define SIZEOF_IO_URING_SQE 64
> #define SIZEOF_IO_URING_CQE 16
> #define SQ_HEAD_OFFSET 0
> #define SQ_TAIL_OFFSET 64
> #define SQ_RING_MASK_OFFSET 256
> #define SQ_RING_ENTRIES_OFFSET 264
> #define SQ_FLAGS_OFFSET 276
> #define SQ_DROPPED_OFFSET 272
> #define CQ_HEAD_OFFSET 128
> #define CQ_TAIL_OFFSET 192
> #define CQ_RING_MASK_OFFSET 260
> #define CQ_RING_ENTRIES_OFFSET 268
> #define CQ_RING_OVERFLOW_OFFSET 284
> #define CQ_FLAGS_OFFSET 280
> #define CQ_CQES_OFFSET 320
>
> struct io_sqring_offsets {
> uint32_t head;
> uint32_t tail;
> uint32_t ring_mask;
> uint32_t ring_entries;
> uint32_t flags;
> uint32_t dropped;
> uint32_t array;
> uint32_t resv1;
> uint64_t resv2;
> };
>
> struct io_cqring_offsets {
> uint32_t head;
> uint32_t tail;
> uint32_t ring_mask;
> uint32_t ring_entries;
> uint32_t overflow;
> uint32_t cqes;
> uint64_t resv[2];
> };
>
> struct io_uring_params {
>
Re: [PATCH v2] media: add a subsystem profile documentation
On Thu, Feb 25, 2021 at 2:41 PM Mauro Carvalho Chehab wrote: > > Document the basic policies of the media subsystem profile. > > Signed-off-by: Mauro Carvalho Chehab > --- > > v2: fix the Documentation/*/media directories > > > Documentation/driver-api/media/index.rst | 2 + > .../media/maintainer-entry-profile.rst| 161 ++ > .../maintainer/maintainer-entry-profile.rst | 1 + > 3 files changed, 164 insertions(+) > create mode 100644 > Documentation/driver-api/media/maintainer-entry-profile.rst > > diff --git a/Documentation/driver-api/media/index.rst > b/Documentation/driver-api/media/index.rst > index c140692454b1..2ad71dfa8828 100644 > --- a/Documentation/driver-api/media/index.rst > +++ b/Documentation/driver-api/media/index.rst > @@ -28,6 +28,8 @@ Please see: > :maxdepth: 5 > :numbered: > > +maintainer-entry-profile > + > v4l2-core > dtv-core > rc-core > diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst > b/Documentation/driver-api/media/maintainer-entry-profile.rst > new file mode 100644 > index ..6318be833bfb > --- /dev/null > +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst > @@ -0,0 +1,161 @@ > +Media Subsystem Profile > +=== > + > +Overview > + > + > +The media subsystem covers support for a variety of devices: stream > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC > +and media pipeline control. > + > +It covers, mainly, the contents of those directories: > + > + - drivers/media > + - drivers/staging/media > + - Documentation/admin-guide/media > + - Documentation/driver-api/media > + - Documentation/userspace-api/media > + - include/media > + > +Both media userspace and Kernel APIs are documented and should be kept in > +sync with the API changes. It means that all patches that add new > +features to the subsystem should also bring changes to the corresponding > +API files. > + > +Due to the size and wide scope of the media subsystem, media's > +maintainership model is to have sub-maintainers that have a broad > +knowledge of a specific aspect of the subsystem. It is the sub-maintainers' > +task to review the patches, providing feedback to users if the patches are > +following the subsystem rules and are properly using the media kernel and > +userspace APIs. > + > +Patches for the media subsystem should be sent to the media mailing list > +at linux-me...@vger.kernel.org as plain text only e-mail. Emails with > +HTML will be automatically rejected by the mail server. It could be wise > +to also copy the sub-maintainer(s). > + > +Media's workflow is heavily based on Patchwork, meaning that, once a patch > +is submitted, it should appear at: > + > + - https://patchwork.linuxtv.org/project/linux-media/list/ > + > +If it doesn't automatically appear there after a few minutes, then > +probably something got wrong on your submission. Please check if the > +email is in plain text only and if your emailer is not mangling with > +whitespaces before complaining or submitting them again. > + > +Sub-maintainers > > + > +At the media subsystem, we have a group of experienced developers that > +are responsible for doing the code reviews at the drivers (called > +sub-maintainers), and another senior developer responsible for the > +subsystem as a hole. For core changes, whenever possible, multiple > +media (sub-)maintainers do the review. > + > +The sub-maintainers work on specific areas of the subsystem, as > +described below: > + > +Digital TV: > + Sean Young > + > +HDMI CEC: > + Hans Verkuil > + > +Media controller drivers: > + Laurent Pinchart > + > +Remote Controllers: > + Sean Young > + > +Sensor drivers: > + Sakari Ailus > + > +V4L2 drivers: > + Hans Verkuil > + > +Submit Checklist Addendum > +- > + > +Patches that change the Open Firmware/Device Tree bindings should be > +reviewed by the Device Tree maintainers. So, DT maintainers should be > +c/c when those are submitted. > + > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/ > +that should be used in order to check if the drivers are properly > +implementing the media APIs. > + > +Those tests need to pass before the patches go upstream. > + > +Also, please notice that we build the Kernel with:: > + > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 > CHECK=check_script > + > +Where the check script is:: > + > + #!/bin/bash > + /devel/smatch/smatch -p=kernel $@ >&2 > + /devel/sparse/sparse $@ >&2 > + > +Be sure to not introduce new warnings on your patches without a > +very good reason. > + > +Style Cleanup Patches > ++ > + > +Style-cleanups are welcome when they come together with other changes > +at the files where the style changes will affect. > + > +We may accept pure standalone style-cleanups, but they should ideally > +be
Re: [PATCH 2/5] MAINTAINERS: remove linux-mips.org references
On Tue, Feb 23, 2021 at 10:48 AM Philippe Mathieu-Daudé wrote: > > On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote: > > > > The domain lookup for linux-mips.org fails for quite some time now. Hence, > > webpages, the patchwork instance and Ralf Baechle's email there is not > > reachable anymore. > > > > Remove all references of webpages from linux-mips.org in MAINTAINERS, and > > refer to the kernel.org's linux-mips patchwork instance instead. > > > > Signed-off-by: Lukas Bulwahn > > --- > > MAINTAINERS | 5 + > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index e949e561867d..703a50183301 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4980,7 +4980,6 @@ DECSTATION PLATFORM SUPPORT > > M: "Maciej W. Rozycki" > > L: linux-m...@vger.kernel.org > > S: Maintained > > -W: http://www.linux-mips.org/wiki/DECstation > > Why not use the web archive? The information is still valuable. > https://web.archive.org/web/20190704000315/https://www.linux-mips.org/wiki/DECstation > If that information is valuable, how about adding that into the kernel documentation page? If linux-mips.org wiki is back, we will keep this link; if not, we should get a copy of that information into the documentation (where it can survive some time) or we simply drop it. Putting a web.archive.org link into MAINTAINERS sounds like a really bad idea to me. Lukas
[PATCH for Dwaipayan] MAINTAINERS: clarify responsibility for checkpatch documentation
As discussed, Dwaipayan and Lukas take the responsibility for maintaining the checkpatch documentation that is currently being built up. To be sure that the checkpatch maintainers and the corresponding documentation maintainers can keep the content synchronized, add them as reviewers to the counterpart. Link: https://lore.kernel.org/lkml/bcee822d1934772f47702ee257bc735c8f467088.ca...@perches.com/ Signed-off-by: Lukas Bulwahn --- applies cleanly on next-20210226 Dwaipayan, you probably want to add this patch to your patch series for checkpatch documentation. Feel free to add your Signed-off-by tag just following mine. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 16ada1a4b751..6b48b79ba284 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4181,9 +4181,18 @@ X: drivers/char/tpm/ CHECKPATCH M: Andy Whitcroft M: Joe Perches +R: Dwaipayan Ray +R: Lukas Bulwahn S: Maintained F: scripts/checkpatch.pl +CHECKPATCH DOCUMENTATION +M: Dwaipayan Ray +M: Lukas Bulwahn +R: Joe Perches +S: Maintained +F: Documentation/dev-tools/checkpatch.rst + CHINESE DOCUMENTATION M: Harry Wei M: Alex Shi -- 2.17.1
Re: [PATCH v7 0/2] checkpatch: add verbose mode
On Thu, Feb 25, 2021 at 7:08 PM Dwaipayan Ray wrote: > > On Thu, Feb 25, 2021 at 11:03 PM Joe Perches wrote: > > > > On Mon, 2021-02-22 at 13:22 +0530, Dwaipayan Ray wrote: > > > Add a new verbose mode to checkpatch. The verbose test > > > descriptions are read from the checkpatch documentation > > > file at `Documentation/dev-tools/checkpatch.rst`. > > > > > > The verbose mode is optional and can be enabled by the > > > flag -v or --verbose. > > > > > > The documentation file is only parsed by checkpatch.pl > > > if the verbose mode is enabled. The verbose mode can > > > not be used together with the --terse option. > > > > I don't have any real objection to this patch set, but as this > > might be added to the Documentation tree and in .rst format, > > perhaps Jonathan Corbet and/or Mauro Carvalho Chehab might have > > some opinion. > > > > Also I do not want to be a maintainer of this .rst file and > > likely neither Jon nor Mauro would either. Perhaps you? > > > > I could take it up if everybody is okay with it! > And as I set Dwaipayan on this task on documenting checkpatch, I will assist in maintaining this file as well. I will also pull some strings to increase chances that Dwaipayan becomes a longer-term member in this community and on this maintainer task. > > Ideally, the patch order would be reversed so the .rst file > > is added first, then checkpatch updated to use it. > > > > Sure, if Jonathan or Mauro has no objections to it, I will be happy > to resend it so that it can be picked up properly. > > > And _a lot_ more types and descriptive content should be added. > > Yes that's for sure. If this makes it I will try to get all of the > other types in. I agree as well, probably a critical mass for inclusion is that we have at least 25% (so roughly 50 rules) documented. > And if Lukas agrees, a little help from my fellow kernel mentees will > be nice as well! > Completely agree. I will recruit new mentees and go through the exercises with them, until they are ready to send proper patches to checkpatch.rst. As the designated maintainer of that file, you will be busy reviewing, consolidating that content and pushing back if it is not good enough for inclusion (so just as in the typical "good cop-bad cop" game: I will motivate and help them to submit, you make sure you get good content). Lukas
Re: [RFC v2] scripts: kernel-doc: fix typedef support for struct/union parsing
On Wed, Feb 24, 2021 at 2:30 PM Aditya Srivastava wrote: > > Currently, there are 447 files in the kernel tree, which use 'typedef > struct/union' syntax for defining some struct/union. In total, there > are ~1290 such occurrences in the kernel tree. > > However, kernel-doc does not support it currently, and running > scripts/kernel-doc -none on emits: > "error: Cannot parse struct or union!" > I will help rephrasing it more precisely: Currently, there are ~1290 occurrences in 447 files in the kernel tree 'typedef struct/union' syntax for defining some struct/union. However, kernel-doc currently does not support that syntax. Of the ~1290 occurrences, there are four occurrences in ./include/linux/zstd.h with typedef struct/union syntax and a preceding kernel-doc; all other occurrences have no preceding kernel-doc. Add support for parsing struct/union following this syntax. I also tested it; here is my quick diff of "git ls-files | xargs ./scripts/kernel-doc -none 2>&1" before and after patch application: < include/linux/zstd.h:154: error: Cannot parse struct or union! < include/linux/zstd.h:171: error: Cannot parse struct or union! < include/linux/zstd.h:181: error: Cannot parse struct or union! 18857d18853 < include/linux/zstd.h:936: error: Cannot parse struct or union! So, again: Tested-by: Lukas Bulwahn Aditya, can you please pick up my rephrasing and send out a v3. Lukas
Re: [PATCH 0/5] Remove dead linux-mips.org references
On Mon, Feb 22, 2021 at 6:47 PM Maciej W. Rozycki wrote: > > On Mon, 22 Feb 2021, Lukas Bulwahn wrote: > > > The domain lookup for linux-mips.org fails for quite some time now. > > Hence, webpages, the patchwork instance and Ralf Baechle's email there is > > not reachable anymore. > > I have been contacted by Ralf a couple of weeks ago and he told me there > had been a storage failure with the machine running linux-mips.org. > > Due to a complex situation with linux-mips.org I do not want to dive the > details of into here recovery of the site caused some trouble, however I > was told it had been under way now. So I suggest that we wait a couple of > weeks yet and see how it goes before going ahead with this series. > > As to Ralf personal commitments WRT maintenance duties I can't speak, but > I have bcc-ed him on his alternative e-mail address with this message in > case he wants to speak up. > Thanks for the update. Maybe we can then rescue some of the valuable content from linux-mips.org and mirror it somewhere else as well? The code mentioned some patch by referring to a linux-mips.org patchwork id, but without the service running, there is no chance to understand the comment. So, once linux-mips.org is up and running again, we might want to recover that referred patch and change the comment to a lore.kernel.org Link (that may stay with us for longer) or quickly find out if that comment is obsolete by now. Lukas
Re: [RFC] scripts: kernel-doc: fix typedef support for struct parsing
On Mon, Feb 22, 2021 at 5:03 PM Aditya Srivastava wrote:
>
> There are files in kernel, which use 'typedef struct' syntax for defining
stylistic:
s/in kernel/in the kernel tree/
s/defining struct/defining some struct/
> struct. For eg, include/linux/zstd.h, drivers/scsi/megaraid/mega_common.h,
> etc.
stylistic:
s/For eg/E.g./ or
s/For eg/For example/
semantically:
It makes much more sense to name how many occurrences of this pattern
exist in the kernel tree within how many files in order to get a good
impression on the use of that pattern within the kernel tree.
> However, kernel-doc still does not support it, causing a parsing error.
>
> For eg, running scripts/kernel-doc -none on include/linux/zstd.h emits:
> "error: Cannot parse struct or union!"
>
semantically:
Drop the example and turn the two sentences above into one.
> Add support for parsing it.
>
> Signed-off-by: Aditya Srivastava
> ---
> scripts/kernel-doc | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 8b5bc7bf4bb8..46e904dc3f87 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1201,12 +1201,20 @@ sub dump_union($$) {
> sub dump_struct($$) {
> my $x = shift;
> my $file = shift;
> +my $decl_type;
> +my $members;
>
> if ($x =~
> /(struct|union)\s+(\w+)\s*\{(.*)\}(\s*(__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*/)
> {
> - my $decl_type = $1;
> + $decl_type = $1;
> $declaration_name = $2;
> - my $members = $3;
> + $members = $3;
> +} elsif ($x =~
> /typedef\s+(struct|union)\s*\{(.*)\}(?:\s*(?:__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*\s*(\w*)\s*;/)
> {
> + $decl_type = $1;
> + $declaration_name = $3;
> + $members = $2;
> +}
>
Could you put the common expression parts into meaningful variables to
avoid repeating yourself in the two pattern matching expressions?
Other than that, it looks good to me.
Lukas
> +if ($members) {
> if ($identifier ne $declaration_name) {
> print STDERR "${file}:$.: warning: expecting prototype for
> $decl_type $identifier. Prototype was for $decl_type $declaration_name
> instead\n";
> return;
> --
> 2.17.1
>
[PATCH 5/5] MIPS: SGI-IP27: fix spelling in Copyright
This is a Copyright line, and just a typo slipped through. Signed-off-by: Lukas Bulwahn --- arch/mips/sgi-ip27/ip27-timer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/sgi-ip27/ip27-timer.c b/arch/mips/sgi-ip27/ip27-timer.c index 79c434fece52..444b5e0e935f 100644 --- a/arch/mips/sgi-ip27/ip27-timer.c +++ b/arch/mips/sgi-ip27/ip27-timer.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Copytight (C) 1999, 2000, 05, 06 Ralf Baechle (r...@linux-mips.org) - * Copytight (C) 1999, 2000 Silicon Graphics, Inc. + * Copyright (C) 1999, 2000, 05, 06 Ralf Baechle (r...@linux-mips.org) + * Copyright (C) 1999, 2000 Silicon Graphics, Inc. */ #include #include -- 2.17.1
[PATCH 3/5] arch: mips: update references to current linux-mips list
The linux-mips mailing list now lives at kernel.org. Update all references
in the kernel tree.
Signed-off-by: Lukas Bulwahn
---
arch/mips/kernel/r4k-bugs64.c | 2 +-
arch/mips/lib/iomap-pci.c | 2 +-
arch/mips/sgi-ip32/ip32-irq.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/kernel/r4k-bugs64.c b/arch/mips/kernel/r4k-bugs64.c
index 1ff19f1ea5ca..35729c9e6cfa 100644
--- a/arch/mips/kernel/r4k-bugs64.c
+++ b/arch/mips/kernel/r4k-bugs64.c
@@ -18,7 +18,7 @@
static char bug64hit[] __initdata =
"reliable operation impossible!\n%s";
static char nowar[] __initdata =
- "Please report to .";
+ "Please report to .";
static char r4kwar[] __initdata =
"Enable CPU_R4000_WORKAROUNDS to rectify.";
static char daddiwar[] __initdata =
diff --git a/arch/mips/lib/iomap-pci.c b/arch/mips/lib/iomap-pci.c
index 210f5a95ecb1..a9cb28813f0b 100644
--- a/arch/mips/lib/iomap-pci.c
+++ b/arch/mips/lib/iomap-pci.c
@@ -32,7 +32,7 @@ void __iomem *__pci_ioport_map(struct pci_dev *dev,
sprintf(name, "%04x:%02x", pci_domain_nr(bus), bus->number);
printk(KERN_WARNING "io_map_base of root PCI bus %s unset. "
"Trying to continue but you better\nfix this issue or "
- "report it to linux-m...@linux-mips.org or your "
+ "report it to linux-m...@vger.kernel.org or your "
"vendor.\n", name);
#ifdef CONFIG_PCI_DOMAINS
panic("To avoid data corruption io_map_base MUST be set with "
diff --git a/arch/mips/sgi-ip32/ip32-irq.c b/arch/mips/sgi-ip32/ip32-irq.c
index 1bbd5bfb5458..e21ea1de05e3 100644
--- a/arch/mips/sgi-ip32/ip32-irq.c
+++ b/arch/mips/sgi-ip32/ip32-irq.c
@@ -343,7 +343,7 @@ static void ip32_unknown_interrupt(void)
printk("Register dump:\n");
show_regs(get_irq_regs());
- printk("Please mail this report to linux-m...@linux-mips.org\n");
+ printk("Please mail this report to linux-m...@vger.kernel.org\n");
printk("Spinning...");
while(1) ;
}
--
2.17.1
[PATCH 2/5] MAINTAINERS: remove linux-mips.org references
The domain lookup for linux-mips.org fails for quite some time now. Hence, webpages, the patchwork instance and Ralf Baechle's email there is not reachable anymore. Remove all references of webpages from linux-mips.org in MAINTAINERS, and refer to the kernel.org's linux-mips patchwork instance instead. Signed-off-by: Lukas Bulwahn --- MAINTAINERS | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index e949e561867d..703a50183301 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4980,7 +4980,6 @@ DECSTATION PLATFORM SUPPORT M: "Maciej W. Rozycki" L: linux-m...@vger.kernel.org S: Maintained -W: http://www.linux-mips.org/wiki/DECstation F: arch/mips/dec/ F: arch/mips/include/asm/dec/ F: arch/mips/include/asm/mach-dec/ @@ -11932,7 +11931,6 @@ MIPS M: Thomas Bogendoerfer L: linux-m...@vger.kernel.org S: Maintained -W: http://www.linux-mips.org/ Q: https://patchwork.kernel.org/project/linux-mips/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git F: Documentation/devicetree/bindings/mips/ @@ -18248,10 +18246,9 @@ F: arch/um/os-Linux/drivers/ TURBOCHANNEL SUBSYSTEM M: "Maciej W. Rozycki" -M: Ralf Baechle L: linux-m...@vger.kernel.org S: Maintained -Q: http://patchwork.linux-mips.org/project/linux-mips/list/ +Q: https://patchwork.kernel.org/project/linux-mips/list/ F: drivers/tc/ F: include/linux/tc.h -- 2.17.1
[PATCH 4/5] arch: mips: remove dead references
The domain lookup for linux-mips.org fails for quite some time now.
Further, the two links:
http://decstation.unix-ag.org/
http://www.computer-refuge.org/classiccmp/ftp.digital.com/pub/DEC/TriAdd/
refer to old webpages or contain no further technical information.
Remove all those dead references.
Signed-off-by: Lukas Bulwahn
---
arch/mips/Kconfig | 8 +---
arch/mips/jazz/Kconfig| 12 +++-
tools/include/nolibc/nolibc.h | 3 +--
3 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..8cb1e2be5999 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -375,9 +375,7 @@ config MACH_DECSTATION
select SYS_SUPPORTS_1024HZ
select MIPS_L1_CACHE_SHIFT_4
help
- This enables support for DEC's MIPS based workstations. For details
- see the Linux/MIPS FAQ on <http://www.linux-mips.org/> and the
- DECstation porting pages on <http://decstation.unix-ag.org/>.
+ This enables support for DEC's MIPS based workstations.
If you have one of the following DECstation Models you definitely
want to choose R4xx0 for the CPU Type:
@@ -3263,10 +3261,6 @@ config TC
processors. TURBOchannel programming specifications are available
at:
<ftp://ftp.hp.com/pub/alphaserver/archive/triadd/>
- and:
-
<http://www.computer-refuge.org/classiccmp/ftp.digital.com/pub/DEC/TriAdd/>
- Linux driver support status is documented at:
- <http://www.linux-mips.org/wiki/DECstation>
config MMU
bool
diff --git a/arch/mips/jazz/Kconfig b/arch/mips/jazz/Kconfig
index 42932ca98db9..162d11670c75 100644
--- a/arch/mips/jazz/Kconfig
+++ b/arch/mips/jazz/Kconfig
@@ -5,9 +5,7 @@ config ACER_PICA_61
select DMA_NONCOHERENT
help
This is a machine with a R4400 133/150 MHz CPU. To compile a Linux
- kernel that runs on these, say Y here. For details about Linux on
- the MIPS architecture, check out the Linux/MIPS FAQ on the WWW at
- <http://www.linux-mips.org/>.
+ kernel that runs on these, say Y here.
config MIPS_MAGNUM_4000
bool "Support for MIPS Magnum 4000"
@@ -16,9 +14,7 @@ config MIPS_MAGNUM_4000
select SYS_SUPPORTS_BIG_ENDIAN
help
This is a machine with a R4000 100 MHz CPU. To compile a Linux
- kernel that runs on these, say Y here. For details about Linux on
- the MIPS architecture, check out the Linux/MIPS FAQ on the WWW at
- <http://www.linux-mips.org/>.
+ kernel that runs on these, say Y here.
config OLIVETTI_M700
bool "Support for Olivetti M700-10"
@@ -26,6 +22,4 @@ config OLIVETTI_M700
select DMA_NONCOHERENT
help
This is a machine with a R4000 100 MHz CPU. To compile a Linux
- kernel that runs on these, say Y here. For details about Linux on
- the MIPS architecture, check out the Linux/MIPS FAQ on the WWW at
- <http://www.linux-mips.org/>.
+ kernel that runs on these, say Y here.
diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
index 8b7a9830dd22..754e64c4a1d1 100644
--- a/tools/include/nolibc/nolibc.h
+++ b/tools/include/nolibc/nolibc.h
@@ -1027,8 +1027,7 @@ struct sys_stat_struct {
* - arguments are in a0, a1, a2, a3, then the stack. The caller needs to
* leave some room in the stack for the callee to save a0..a3 if needed.
* - Many registers are clobbered, in fact only a0..a2 and s0..s8 are
- * preserved. See: https://www.linux-mips.org/wiki/Syscall as well as
- * scall32-o32.S in the kernel sources.
+ * preserved. See: scall32-o32.S in the kernel sources.
* - the system call is performed by calling "syscall"
* - syscall return comes in v0, and register a3 needs to be checked to know
* if an error occured, in which case errno is in v0.
--
2.17.1
[PATCH 1/5] MAINTAINERS: mark sections from Ralf Baechle orphan
The domain lookup for linux-mips.org fails for quite some time now. Hence, webpages, the patchwork instance and Ralf Baechle's email there is not reachable anymore. Ralf Baechle has not been active since February 2018; so, set all MAINTAINERS sections with Ralf as sole maintainer to Orphan, and give others a chance to claim maintainership if these sections are still of interest. Signed-off-by: Lukas Bulwahn --- MAINTAINERS | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7924907cd7cc..e949e561867d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2997,9 +2997,8 @@ F: Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml F: drivers/iio/adc/hx711.c AX.25 NETWORK LAYER -M: Ralf Baechle L: linux-h...@vger.kernel.org -S: Maintained +S: Orphan W: http://www.linux-ax25.org/ F: include/net/ax25.h F: include/uapi/linux/ax25.h @@ -6341,10 +6340,9 @@ S: Maintained F: drivers/edac/highbank* EDAC-CAVIUM OCTEON -M: Ralf Baechle L: linux-e...@vger.kernel.org L: linux-m...@vger.kernel.org -S: Supported +S: Orphan F: drivers/edac/octeon_edac* EDAC-CAVIUM THUNDERX @@ -9307,9 +9305,8 @@ F: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.txt F: drivers/iio/gyro/mpu3050* IOC3 ETHERNET DRIVER -M: Ralf Baechle L: linux-m...@vger.kernel.org -S: Maintained +S: Orphan F: drivers/net/ethernet/sgi/ioc3-eth.c IOMAP FILESYSTEM LIBRARY @@ -12378,9 +12375,8 @@ F: net/bridge/br_netfilter*.c F: net/netfilter/ NETROM NETWORK LAYER -M: Ralf Baechle L: linux-h...@vger.kernel.org -S: Maintained +S: Orphan W: http://www.linux-ax25.org/ F: include/net/netrom.h F: include/uapi/linux/netrom.h @@ -15473,9 +15469,8 @@ F: include/linux/mfd/rohm-generic.h F: include/linux/mfd/rohm-shared.h ROSE NETWORK LAYER -M: Ralf Baechle L: linux-h...@vger.kernel.org -S: Maintained +S: Orphan W: http://www.linux-ax25.org/ F: include/net/rose.h F: include/uapi/linux/rose.h -- 2.17.1
[PATCH 0/5] Remove dead linux-mips.org references
Dear all,
The domain lookup for linux-mips.org fails for quite some time now.
Hence, webpages, the patchwork instance and Ralf Baechle's email there is
not reachable anymore.
First, I updated all sections in MAINTAINERS for references with linux-mips.org.
Then, I also quickly scanned through the whole git tree for linux-mips.org
references, and step-wise filtered out obvious copyright holder lines and
references to old email addresses.
git ls-files | xargs grep "linux-mips.org" | \
grep -v -i "Copyright" | grep -v -i "MODULE_AUTHOR" | grep -v -i "written"
| \
grep -v "Ralf" | grep -v "Maciej" | grep -v "Yoichi" | grep -v "Ladislav"
I removed dead references or replaced them with their living counterparts if
available. However, these two cases remain and somebody might want to have a
look:
1. case in ./arch/mips/include/asm/page.h:
/*
* RELOC_HIDE was originally added by 6007b903dfe5f1d13e0c711ac2894bdd4a61b1ad
* (lmo) rsp. 8431fd094d625b94d364fe393076ccef88e6ce18 (kernel.org). The
* discussion can be found in
*
https://lore.kernel.org/lkml/a2ebde260608230500o3407b108hc03debb9da6e...@mail.gmail.com
*
* It is unclear if the misscompilations mentioned in
*
https://lore.kernel.org/lkml/1281303490-390-1-git-send-email-namhy...@gmail.com
* also affect MIPS so we keep this one until GCC 3.x has been retired
* before we can apply https://patchwork.linux-mips.org/patch/1541/
*/
Decision: Keep as is. Although GCC 3.x is long retired, it is unclear what
https://patchwork.linux-mips.org/patch/1541/ is and if it has been already
applied or not.
Question: does anyone know how to identify this patch?
2. case in ./drivers/parport/parport_ip32.c:
linux-mips.org tree is referred to in an old To do item:
* To do:
*
* Fully implement ECP mode.
* EPP and ECP mode need to be tested. I currently do not own any
* peripheral supporting these extended mode, and cannot test them.
* If DMA mode works well, decide if support for PIO FIFO modes should be
* dropped.
* Use the io{read,write} family functions when they become available in
* the linux-mips.org tree. Note: the MIPS specific functions readsb()
* and writesb() are to be translated by ioread8_rep() and iowrite8_rep()
* respectively.
Decision: Keep as is; anyone that wants to follow up on this will probably
understand that the reference is outdated anyway.
Please comment on these clean-up patches on this administrative topic.
Patch set applies cleanly on next-20210222.
Thanks,
Lukas
Lukas Bulwahn (5):
MAINTAINERS: mark sections from Ralf Baechle orphan
MAINTAINERS: remove linux-mips.org references
arch: mips: update references to current linux-mips list
arch: mips: remove dead references
MIPS: SGI-IP27: fix spelling in Copyright
MAINTAINERS | 20 ++--
arch/mips/Kconfig | 8 +---
arch/mips/jazz/Kconfig | 12 +++-
arch/mips/kernel/r4k-bugs64.c | 2 +-
arch/mips/lib/iomap-pci.c | 2 +-
arch/mips/sgi-ip27/ip27-timer.c | 4 ++--
arch/mips/sgi-ip32/ip32-irq.c | 2 +-
tools/include/nolibc/nolibc.h | 3 +--
8 files changed, 16 insertions(+), 37 deletions(-)
--
2.17.1
Re: [RFC] scripts: kernel-doc: fix array element capture in pointer-to-func parsing
On Wed, Feb 17, 2021 at 3:56 PM Aditya Srivastava wrote: > > Currently, kernel-doc causes an unexpected error when array element (i.e., > "type (*foo[bar])(args)") is present as pointer parameter in > pointer-to-function parsing. > > For e.g., running kernel-doc -none on kernel/gcov/gcc_4_7.c causes this > error: > "Use of uninitialized value $param in regexp compilation at ...", in > combination with: > "warning: Function parameter or member '' not described in 'gcov_info'" > > Here, the parameter parsing does not take into account the presence of > array element (i.e. square brackets) in $param. > > Provide a simple fix by adding square brackets in the regex, responsible > for capturing $param. > > A quick evaluation, by running 'kernel-doc -none' on entire kernel-tree, > reveals that no additional warning or error has been added or removed by > the fix. > > Suggested-by: Lukas Bulwahn > Signed-off-by: Aditya Srivastava > --- > * Applies perfectly over next-20210217 > Aditya, Jonathan, I have tested this change with: git ls-files | xargs ./scripts/kernel-doc -none 2>&1 | tee kernel-doc-output Applied the patch, and re-ran that command and compared the diff. First, I observed that ./scripts/kernel-doc is not fully deterministic on my machine, although I could not really pinpoint it to the exact reason where that comes in. Secondly, more importantly, the relevant diff affected by this patch is: < Use of uninitialized value $param in regexp compilation at ./scripts/kernel-doc line 1559, line 308. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 308. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 308. < Use of uninitialized value $param in substitution (s///) at ./scripts/kernel-doc line 1617, line 308. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1651, line 308. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1651, line 308. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1652, line 308. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1654, line 308. < Use of uninitialized value $param in concatenation (.) or string at ./scripts/kernel-doc line 1655, line 308. < drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h:308: warning: Function parameter or member '' not described in 'brcmf_fweh_info' < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1672, line 308. < Use of uninitialized value $param in regexp compilation at ./scripts/kernel-doc line 1559, line 96. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 96. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 96. < Use of uninitialized value $param in substitution (s///) at ./scripts/kernel-doc line 1617, line 96. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1651, line 96. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1651, line 96. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1652, line 96. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1654, line 96. < Use of uninitialized value $param in concatenation (.) or string at ./scripts/kernel-doc line 1655, line 96. < kernel/gcov/gcc_4_7.c:96: warning: Function parameter or member '' not described in 'gcov_info' < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1672, line 96. So, I can confirm that the mentioned issue is really resolved with this patch, and that deserves a tag: Tested-by: Lukas Bulwahn Thanks, Aditya. When can we expect the next patch for ./scripts/kernel-doc? Looking forward to running the next test :) Lukas
[PATCH RESEND] MAINTAINERS: replace non-matching patterns for loongson{2,3}
Commit ffe1f9356fbe ("MAINTAINERS: Add Loongson-2/Loongson-3 maintainers")
adds quite generic file entries for drivers/*/*loongson{2,3}* and
drivers/*/*/*loongson{2,3}* to be informed on changes to all loongson{2,3}
files in drivers.
However, only the pattern 'drivers/*/*loongson2*' matches to one file in
the repository, i.e., drivers/cpufreq/loongson2_cpufreq.c; all other
patterns have no file matches.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matchesF:drivers/*/*/*loongson2*
warning: no file matchesF:drivers/*/*/*loongson3*
warning: no file matchesF:drivers/*/*loongson3*
As in the last two and half years, no further files and drivers have
showed up to match those patterns, just name the one file that matches
explicitly and delete the others without a match.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20210209
Keguang, Huacai, Jiaxun, please ack.
Thomas, please pick this minor non-urgent cleanup patch.
MAINTAINERS | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9e2ab01363df..4bdf2fdb0456 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11946,8 +11946,7 @@ L: linux-m...@vger.kernel.org
S: Maintained
F: arch/mips/include/asm/mach-loongson2ef/
F: arch/mips/loongson2ef/
-F: drivers/*/*/*loongson2*
-F: drivers/*/*loongson2*
+F: drivers/cpufreq/loongson2_cpufreq.c
MIPS/LOONGSON64 ARCHITECTURE
M: Huacai Chen
@@ -11956,8 +11955,6 @@ L: linux-m...@vger.kernel.org
S: Maintained
F: arch/mips/include/asm/mach-loongson64/
F: arch/mips/loongson64/
-F: drivers/*/*/*loongson3*
-F: drivers/*/*loongson3*
F: drivers/irqchip/irq-loongson*
F: drivers/platform/mips/cpu_hwmon.c
--
2.17.1
[PATCH] MAINTAINERS: replace non-matching patterns for loongson{2,3}
Commit ffe1f9356fbe ("MAINTAINERS: Add Loongson-2/Loongson-3 maintainers")
adds quite generic file entries for drivers/*/*loongson{2,3}* and
drivers/*/*/*loongson{2,3}* to be informed on changes to all loongson{2,3}
files in drivers.
However, only the pattern 'drivers/*/*loongson2*' matches to one file in
the repository, i.e., drivers/cpufreq/loongson2_cpufreq.c; all other
patterns have no file matches.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matchesF:drivers/*/*/*loongson2*
warning: no file matchesF:drivers/*/*/*loongson3*
warning: no file matchesF:drivers/*/*loongson3*
As in the last two and half years, no further files and drivers have
showed up to match those patterns, just name the one file that matches
explicitly and delete the others without a match.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20201102
Keguang, Huacai, Jiaxun, please ack.
Thomas, please pick this minor non-urgent cleanup patch.
MAINTAINERS | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b4197e9da495..fc08f628e196 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11719,8 +11719,7 @@ L: linux-m...@vger.kernel.org
S: Maintained
F: arch/mips/include/asm/mach-loongson2ef/
F: arch/mips/loongson2ef/
-F: drivers/*/*/*loongson2*
-F: drivers/*/*loongson2*
+F: drivers/cpufreq/loongson2_cpufreq.c
MIPS/LOONGSON64 ARCHITECTURE
M: Huacai Chen
@@ -11729,8 +11728,6 @@ L: linux-m...@vger.kernel.org
S: Maintained
F: arch/mips/include/asm/mach-loongson64/
F: arch/mips/loongson64/
-F: drivers/*/*/*loongson3*
-F: drivers/*/*loongson3*
F: drivers/irqchip/irq-loongson*
F: drivers/platform/mips/cpu_hwmon.c
--
2.17.1
[PATCH] MAINTAINERS: rectify BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER
Commit 8bcac4011ebe ("soc: bcm: add PM driver for Broadcom's PMB") includes
a new MAINTAINERS section BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER with
'drivers/soc/bcm/bcm-pmb.c', but the file was actually added at
'drivers/soc/bcm/bcm63xx/bcm-pmb.c'.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F:drivers/soc/bcm/bcm-pmb.c
Point the file entry to the right location.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210205
Rafal, please ack.
Florian, please pick this minor fixup patch for soc next tree.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b507e8d7828..c23731c88dc2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3647,7 +3647,7 @@ M:bcm-kernel-feedback-l...@broadcom.com
L: linux...@vger.kernel.org
S: Maintained
T: git git://github.com/broadcom/stblinux.git
-F: drivers/soc/bcm/bcm-pmb.c
+F: drivers/soc/bcm/bcm63xx/bcm-pmb.c
F: include/dt-bindings/soc/bcm-pmb.h
BROADCOM SPECIFIC AMBA DRIVER (BCMA)
--
2.17.1
[PATCH] MAINTAINERS: repair file pattern in MEDIATEK IOMMU DRIVER
Commit 6af4873852c4 ("MAINTAINERS: Add entry for MediaTek IOMMU") mentions
the pattern 'drivers/iommu/mtk-iommu*', but the files are actually named
with an underscore, not with a hyphen.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F:drivers/iommu/mtk-iommu*
Repair this minor typo in the file pattern.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210205
Yong, please ack.
Will, please pick this minor fixup for your iommu-next tree.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 674f42375acf..6b507e8d7828 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11200,7 +11200,7 @@ L: io...@lists.linux-foundation.org
L: linux-media...@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/iommu/mediatek*
-F: drivers/iommu/mtk-iommu*
+F: drivers/iommu/mtk_iommu*
F: include/dt-bindings/memory/mt*-port.h
MEDIATEK JPEG DRIVER
--
2.17.1
[PATCH] net/mlx5: docs: correct section reference in table of contents
Commit 142d93d12dc1 ("net/mlx5: Add devlink subfunction port
documentation") refers to a section 'mlx5 port function' in the table of
contents, but includes a section 'mlx5 function attributes' instead.
Hence, make htmldocs warns:
mlx5.rst:16: WARNING: Unknown target name: "mlx5 port function".
Correct the section reference in table of contents to the actual name of
section in the documentation.
Also, tune another section underline while visiting this document.
Signed-off-by: Lukas Bulwahn
---
Saeed, please pick this patch for your -next tree on top of the commit above.
.../networking/device_drivers/ethernet/mellanox/mlx5.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst
b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst
index a1b32fcd0d76..1b7e32d8a61b 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst
@@ -13,12 +13,12 @@ Contents
- `Devlink info`_
- `Devlink parameters`_
- `mlx5 subfunction`_
-- `mlx5 port function`_
+- `mlx5 function attributes`_
- `Devlink health reporters`_
- `mlx5 tracepoints`_
Enabling the driver and kconfig options
-
+===
| mlx5 core is modular and most of the major mlx5 core driver features can be
selected (compiled in/out)
| at build time via kernel Kconfig flags.
--
2.17.1
Re: Small student project idea on appropriate integration trees in MAINTAINERS
On Fri, Jan 29, 2021 at 12:54 AM Jonathan Corbet wrote: > > On Fri, 22 Jan 2021 09:22:24 +0100 > Lukas Bulwahn wrote: > > > In this project, we can make use of: > > > > - gitdm [git://git.lwn.net/gitdm.git]: gitdm includes some scripts to > > parse MAINTAINERS and obtain the integration tree patch of a commit. > > Look also at the 'treeplot' tool there, which determines which tree(s) > each patch went through and makes pretty (OK, not hugely pretty) pictures > from the result. Thanks, we are well aware, and that is a good reminder for Basak and me to get our gitdm treeplot patches in shape for proper submission. > > I suspect you'll find that the tree information is mostly correct. Your suspicion, which is counter to my hypothesis, makes this investigation worthwhile just to see how correct that information really is. > Developers need to know that to be able to base their patches properly; an > incorrect entry would lead to a certain amount of maintainer misery. > Maybe the missing or wrong information in MAINTAINERS or the lack of clear recommendation for new developers to a kernel subsystem on which integration tree a patch shall apply to is one of the reasons for some maintainers' misery. Let us find someone interested to measure and investigate and then we will see... Lukas
[PATCH 1/5] fs: turn some comments into kernel-doc
While reviewing ./include/linux/fs.h, I noticed that three comments can actually be turned into kernel-doc comments. This allows to check the consistency between the descriptions and the functions' signatures in case they may change in the future. A quick validation with the consistency check: ./scripts/kernel-doc -none include/linux/fs.h currently reports no issues in this file. Signed-off-by: Lukas Bulwahn --- include/linux/fs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index 3482146b11b0..04b6b142dfcf 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1739,7 +1739,7 @@ static inline void sb_start_pagefault(struct super_block *sb) __sb_start_write(sb, SB_FREEZE_PAGEFAULT); } -/* +/** * sb_start_intwrite - get write access to a superblock for internal fs purposes * @sb: the super we write to * @@ -3162,7 +3162,7 @@ static inline ssize_t blockdev_direct_IO(struct kiocb *iocb, void inode_dio_wait(struct inode *inode); -/* +/** * inode_dio_begin - signal start of a direct I/O requests * @inode: inode the direct I/O happens on * @@ -3174,7 +3174,7 @@ static inline void inode_dio_begin(struct inode *inode) atomic_inc(>i_dio_count); } -/* +/** * inode_dio_end - signal finish of a direct I/O requests * @inode: inode the direct I/O happens on * -- 2.17.1
[PATCH 5/5] fs: update kernel-doc for new mnt_userns argument
Commit 549c7297717c ("fs: make helpers idmap mount aware") and commit
c7c7a1a18af4 ("xattr: handle idmapped mounts") refactor the inode methods
with mount-user-namespace arguments, but did not adjust the kernel-doc of
some functions.
Hence, make htmldocs warns:
./fs/libfs.c:498: warning: Function parameter or member 'mnt_userns' not
described in 'simple_setattr'
./fs/xattr.c:257: warning: Function parameter or member 'mnt_userns' not
described in '__vfs_setxattr_locked'
./fs/xattr.c:485: warning: Function parameter or member 'mnt_userns' not
described in '__vfs_removexattr_locked'
Copy the existing kernel-doc description for that new argument from
__vfs_setxattr_noperm() to the other functions as well.
Signed-off-by: Lukas Bulwahn
---
fs/libfs.c | 1 +
fs/xattr.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/fs/libfs.c b/fs/libfs.c
index e2de5401abca..61c684014392 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -481,6 +481,7 @@ EXPORT_SYMBOL(simple_rename);
/**
* simple_setattr - setattr for simple filesystem
+ * @mnt_userns: user namespace of the mount the inode was found from
* @dentry: dentry
* @iattr: iattr structure
*
diff --git a/fs/xattr.c b/fs/xattr.c
index b3444e06cded..57f47f0caf22 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -242,6 +242,7 @@ int __vfs_setxattr_noperm(struct user_namespace *mnt_userns,
* __vfs_setxattr_locked - set an extended attribute while holding the inode
* lock
*
+ * @mnt_userns: user namespace of the mount the inode was found from
* @dentry: object to perform setxattr on
* @name: xattr name to set
* @value: value to set @name to
@@ -473,6 +474,7 @@ EXPORT_SYMBOL(__vfs_removexattr);
* __vfs_removexattr_locked - set an extended attribute while holding the inode
* lock
*
+ * @mnt_userns: user namespace of the mount the inode was found from
* @dentry: object to perform setxattr on
* @name: name of xattr to remove
* @delegated_inode: on return, will contain an inode pointer that
--
2.17.1
[PATCH 0/5] kernel-doc fixes to latest fs changes
this patchset was motivated by new warnings with make htmldocs appearing on linux-next in the last week. Please apply this on top of your latest work in fs on top of the mount user namespace refactoring, cf. the commits referred in the individual commit messages. Lukas Bulwahn (5): fs: turn some comments into kernel-doc fs: update kernel-doc for vfs_rename() fs: update kernel-doc for may_create_in_sticky() fs: update kernel-doc for vfs_tmpfile() fs: update kernel-doc for new mnt_userns argument fs/libfs.c | 1 + fs/namei.c | 13 ++--- fs/xattr.c | 2 ++ include/linux/fs.h | 17 ++--- 4 files changed, 19 insertions(+), 14 deletions(-) -- 2.17.1
[PATCH 3/5] fs: update kernel-doc for may_create_in_sticky()
Commit ba73d98745be ("namei: handle idmapped mounts in may_*() helpers")
refactors may_create_in_sticky(), adds kernel-doc for the new argument,
but missed to drop the kernel-doc for the removed arguments.
Hence, make htmldocs warns on ./fs/namei.c:1149:
warning: Excess function parameter 'dir_mode' description in
'may_create_in_sticky'
warning: Excess function parameter 'dir_uid' description in
'may_create_in_sticky'
Drop removed arguments from kernel-doc of may_create_in_sticky().
Signed-off-by: Lukas Bulwahn
---
fs/namei.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 98ea56ebcaf0..64a841dfbb3e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1121,8 +1121,6 @@ int may_linkat(struct user_namespace *mnt_userns, struct
path *link)
* should be allowed, or not, on files that already
* exist.
* @mnt_userns:user namespace of the mount the inode was found from
- * @dir_mode: mode bits of directory
- * @dir_uid: owner of directory
* @inode: the inode of the file to open
*
* Block an O_CREAT open of a FIFO (or a regular file) when:
--
2.17.1
[PATCH 4/5] fs: update kernel-doc for vfs_tmpfile()
Commit 6521f8917082 ("namei: prepare for idmapped mounts") adds kernel-doc
for vfs_tmpfile(), but with a small typo in one argument name.
Hence, make htmldocs warns on ./fs/namei.c:3396:
warning: Function parameter or member 'open_flag' not described in
'vfs_tmpfile'
warning: Excess function parameter 'open_flags' description in 'vfs_tmpfile'
Fix this typo in kernel-doc of vfs_tmpfile().
Signed-off-by: Lukas Bulwahn
---
fs/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namei.c b/fs/namei.c
index 64a841dfbb3e..9f7d260ffb4b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3379,7 +3379,7 @@ static int do_open(struct nameidata *nd,
* @mnt_userns:user namespace of the mount the inode was found from
* @dentry:pointer to dentry of the base directory
* @mode: mode of the new tmpfile
- * @open_flags:flags
+ * @open_flag: flags
*
* Create a temporary file.
*
--
2.17.1
[PATCH 2/5] fs: update kernel-doc for vfs_rename()
Commit 9fe61450972d ("namei: introduce struct renamedata") introduces a
new struct for vfs_rename() and makes the vfs_rename() kernel-doc argument
description out of sync.
Move the description of arguments for vfs_rename() to a new kernel-doc for
the struct renamedata to make these descriptions checkable against the
actual implementation.
Signed-off-by: Lukas Bulwahn
---
fs/namei.c | 9 +
include/linux/fs.h | 11 +++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index f131d3efec63..98ea56ebcaf0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4406,14 +4406,7 @@ SYSCALL_DEFINE2(link, const char __user *, oldname,
const char __user *, newname
/**
* vfs_rename - rename a filesystem object
- * @old_mnt_userns:old user namespace of the mount the inode was found from
- * @old_dir: parent of source
- * @old_dentry:source
- * @new_mnt_userns:new user namespace of the mount the inode was found from
- * @new_dir: parent of destination
- * @new_dentry:destination
- * @delegated_inode: returns an inode needing a delegation break
- * @flags: rename flags
+ * @rd: struct with all information required for renaming
*
* The caller must hold multiple mutexes--see lock_rename()).
*
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 04b6b142dfcf..52b6d9e34b92 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1782,6 +1782,17 @@ int vfs_rmdir(struct user_namespace *, struct inode *,
struct dentry *);
int vfs_unlink(struct user_namespace *, struct inode *, struct dentry *,
struct inode **);
+/**
+ * struct renamedata - contains all information required for renaming
+ * @old_mnt_userns:old user namespace of the mount the inode was found from
+ * @old_dir: parent of source
+ * @old_dentry:source
+ * @new_mnt_userns:new user namespace of the mount the inode was found from
+ * @new_dir: parent of destination
+ * @new_dentry:destination
+ * @delegated_inode: returns an inode needing a delegation break
+ * @flags: rename flags
+ */
struct renamedata {
struct user_namespace *old_mnt_userns;
struct inode *old_dir;
--
2.17.1
[PATCH] fscache: rectify minor kernel-doc issues
The command './scripts/kernel-doc -none include/linux/fscache.h' reports some minor mismatches of the kernel-doc and function signature, which are easily resolved. Rectify the kernel-doc, such that no issues remain for fscache.h. Signed-off-by: Lukas Bulwahn --- applies cleanly on current master and next-20210202 David, please pick the quick kernel-doc fix. include/linux/fscache.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/fscache.h b/include/linux/fscache.h index 3f177faa0ac2..7e1f12e52baf 100644 --- a/include/linux/fscache.h +++ b/include/linux/fscache.h @@ -418,7 +418,7 @@ int fscache_pin_cookie(struct fscache_cookie *cookie) } /** - * fscache_pin_cookie - Unpin a data-storage cache object in its cache + * fscache_unpin_cookie - Unpin a data-storage cache object in its cache * @cookie: The cookie representing the cache object * * Permit data-storage cache objects to be unpinned from the cache. @@ -490,7 +490,7 @@ void fscache_wait_on_invalidate(struct fscache_cookie *cookie) /** * fscache_reserve_space - Reserve data space for a cached object * @cookie: The cookie representing the cache object - * @i_size: The amount of space to be reserved + * @size: The amount of space to be reserved * * Reserve an amount of space in the cache for the cache object attached to a * cookie so that a write to that object within the space can always be -- 2.17.1
Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?
On Mon, Feb 1, 2021 at 5:37 PM Greg KH wrote:
>
> On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > Hi,
> > on linux-next,
> > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > gives:
> > 4a2d78822fdf
> > 12ca45fea91c
> > 09f2724a786f
> >
> > These are patches from the year 2085, 2037 and 2030 respectively.
> >
> > Would a checkpatch rule be helpful for these or are they too
> > isolated to waste runtime on?
>
> Dates come from your email client, not the patch itself, how is
> checkpatch going to catch this?
>
Dwaipayan, there are two ways:
- We build a bot listening to mailing lists and check. I like that
implementation idea for various other checks.
- Stephen Rothwell could include this as a check on linux-next and
inform the git author and committer.
I am wondering though if that is worth the effort, three instances of
a wrong date among 1M commits seems to be very seldom and the harm of
that mistake is quite small as well.
Lukas
[PATCH for -next] docs: hwmon: rectify table in max16601.rst
Commit 90b0f71d62df ("hwmon: (pmbus/max16601) Determine and use number of
populated phases") adjusts content in the table of
./Documentation/hwmon/max16601.rst, but one row went beyond the column's
length.
Hence, make htmldocs warns:
Documentation/hwmon/max16601.rst:94: WARNING: Malformed table.
Adjust the column length of that table for this longer row to fit.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210129
Guenter, please pick this minor fixup for your hwmon-next tree.
Documentation/hwmon/max16601.rst | 143 +++
1 file changed, 71 insertions(+), 72 deletions(-)
diff --git a/Documentation/hwmon/max16601.rst b/Documentation/hwmon/max16601.rst
index d16792be7533..d265a2224354 100644
--- a/Documentation/hwmon/max16601.rst
+++ b/Documentation/hwmon/max16601.rst
@@ -53,75 +53,74 @@ Sysfs entries
The following attributes are supported.
-=== ===
-in1_label "vin1"
-in1_input VCORE input voltage.
-in1_alarm Input voltage alarm.
-
-in2_label "vout1"
-in2_input VCORE output voltage.
-in2_alarm Output voltage alarm.
-
-curr1_label"iin1"
-curr1_inputVCORE input current, derived from duty cycle and output
- current.
-curr1_max Maximum input current.
-curr1_max_alarmCurrent high alarm.
-
-curr[P+2]_label"iin1.P"
-curr[P+2]_inputVCORE phase P input current.
-
-curr[N+2]_label"iin2"
-curr[N+2]_inputVCORE input current, derived from sensor
element.
- 'N' is the number of enabled/populated phases.
-
-curr[N+3]_label"iin3"
-curr[N+3]_inputVSA input current.
-
-curr[N+4]_label"iout1"
-curr[N+4]_inputVCORE output current.
-curr[N+4]_crit Critical output current.
-curr[N+4]_crit_alarm Output current critical alarm.
-curr[N+4]_max Maximum output current.
-curr[N+4]_max_alarmOutput current high alarm.
-
-curr[N+P+5]_label "iout1.P"
-curr[N+P+5]_input VCORE phase P output current.
-
-curr[2*N+5]_label "iout3"
-curr[2*N+5]_input VSA output current.
-curr[2*N+5]_highestHistorical maximum VSA output current.
-curr[2*N+5]_reset_history
- Write any value to reset curr21_highest.
-curr[2*N+5]_crit Critical output current.
-curr[2*N+5]_crit_alarm Output current critical alarm.
-curr[2*N+5]_maxMaximum output current.
-curr[2*N+5]_max_alarm Output current high alarm.
-
-power1_label "pin1"
-power1_input Input power, derived from duty cycle and output current.
-power1_alarm Input power alarm.
-
-power2_label "pin2"
-power2_input Input power, derived from input current sensor.
-
-power3_label "pout"
-power3_input Output power.
-
-temp1_inputVCORE temperature.
-temp1_crit Critical high temperature.
-temp1_crit_alarm Chip temperature critical high alarm.
-temp1_max Maximum temperature.
-temp1_max_alarmChip temperature high alarm.
-
-temp2_inputTSENSE_0 temperature
-temp3_inputTSENSE_1 temperature
-temp4_inputTSENSE_2 temperature
-temp5_inputTSENSE_3 temperature
-
-temp6_inputVSA temperature.
-temp6_crit Critical high temperature.
-temp6_crit_alarm Chip temperature critical high alarm.
-temp6_max Maximum temperature.
-temp6_max_alarmChip temperature high alarm.
-=== ===
+=
===
+in1_label"vin1"
+in1_inputVCORE input voltage.
+in1_alarmInput voltage alarm.
+
+in2_label"vout1"
+in2_inputVCORE output voltage.
+in2_alarmOutput voltage alarm.
+
+curr1_label "iin1"
+curr1_input VCORE input current, derived from duty cycle and
output
+ current.
+curr1_maxMaximum input current.
+curr1_max_alarm Current high alarm.
+
+curr[P+2]_label "iin1.P"
+curr[P+2]_input VCORE phase P input current.
+
+curr[N+2]_label "iin2"
+curr[N+2]_input VCORE input current, derived from sensor
element.
+ 'N' is the number of enabled/populated phases.
+
+curr[N+3]_label "iin3"
+curr[N+3]_input
[PATCH for -next] docs: drop removed pti_intel_mid from driver-api index
Commit 8ba59e9dee31 ("misc: pti: Remove driver for deprecated platform")
removed ./Documentation/driver-api/pti_intel_mid.rst, but missed to remove
it from the index at ./Documentation/driver-api/index.rst.
Hence, make htmldocs warns:
WARNING: toctree contains reference to nonexisting document
'driver-api/pti_intel_mid'
Remove pti_intel_mid from driver-api index.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210129
Greg, please pick this minor fixup on top of the commit above.
Documentation/driver-api/index.rst | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/driver-api/index.rst
b/Documentation/driver-api/index.rst
index 9d9af54d68c5..66c4c01eeec6 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -93,7 +93,6 @@ available subsections can be seen below.
pps
ptp
phy/index
- pti_intel_mid
pwm
pldmfw/index
rfkill
--
2.17.1
[PATCH] MAINTAINERS: adjust to gdth scsi driver removal
Commit 0653c358d2dc ("scsi: Drop gdth driver") misses to adjust MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F:drivers/scsi/gdt*
Remove the GDT SCSI DISK ARRAY CONTROLLER DRIVER section as well, as the
driver is removed now.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210128
Hannes, Martin, please pick this minor fix-up on your scsi-next tree.
MAINTAINERS | 7 ---
1 file changed, 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index dfb1f1af32bb..5e1fec71f21b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7363,13 +7363,6 @@ M: Kieran Bingham
S: Supported
F: scripts/gdb/
-GDT SCSI DISK ARRAY CONTROLLER DRIVER
-M: Achim Leubner
-L: linux-s...@vger.kernel.org
-S: Supported
-W: http://www.icp-vortex.com/
-F: drivers/scsi/gdt*
-
GEMTEK FM RADIO RECEIVER DRIVER
M: Hans Verkuil
L: linux-me...@vger.kernel.org
--
2.17.1
[PATCH] block: drop removed argument from kernel-doc of blk_execute_rq()
Commit 684da7628d93 ("block: remove unnecessary argument from
blk_execute_rq") changes the signature of blk_execute_rq(), but misses
to adjust its kernel-doc.
Hence, make htmldocs warns on ./block/blk-exec.c:78:
warning: Excess function parameter 'q' description in 'blk_execute_rq'
Drop removed argument from kernel-doc of blk_execute_rq() as well.
Signed-off-by: Lukas Bulwahn
---
Jens, please pick this minor fix on your block-next tree.
block/blk-exec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/blk-exec.c b/block/blk-exec.c
index 0ab873f10133..beae70a0e5e5 100644
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@ -65,7 +65,6 @@ EXPORT_SYMBOL_GPL(blk_execute_rq_nowait);
/**
* blk_execute_rq - insert a request into queue for execution
- * @q: queue to insert the request in
* @bd_disk: matching gendisk
* @rq:request to insert
* @at_head:insert request at head or tail of queue
--
2.17.1
[PATCH] block: remove typo in kernel-doc of set_disk_ro()
Commit 52f019d43c22 ("block: add a hard-readonly flag to struct gendisk")
provides some kernel-doc for set_disk_ro(), but introduces a small typo.
Hence, make htmldocs warns on ./block/genhd.c:1441:
warning: Function parameter or member 'read_only' not described in
'set_disk_ro'
warning: Excess function parameter 'ready_only' description in 'set_disk_ro'
Remove that typo in the kernel-doc for set_disk_ro().
Signed-off-by: Lukas Bulwahn
---
Jens, please pick this minor fix on your block-next tree.
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
index d3ef29fbc536..304f8dcc9a9b 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1431,7 +1431,7 @@ static void set_disk_ro_uevent(struct gendisk *gd, int ro)
/**
* set_disk_ro - set a gendisk read-only
* @disk: gendisk to operate on
- * @ready_only:%true to set the disk read-only, %false set the disk
read/write
+ * @read_only: %true to set the disk read-only, %false set the disk read/write
*
* This function is used to indicate whether a given disk device should have
its
* read-only flag set. set_disk_ro() is typically used by device drivers to
--
2.17.1
[PATCH] platform/x86: thinkpad_acpi: rectify length of title underline
Commit d7cbe2773aed ("platform/x86: thinkpad_acpi: set keyboard language")
adds information on keyboard setting to the thinkpad documentation, but
made the subsection title underline too short.
Hence, make htmldocs warns:
Documentation/admin-guide/laptops/thinkpad-acpi.rst:1472: \
WARNING: Title underline too short.
Rectify length of subsection title underline.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210128
Nitin, please ack.
Hans, please pick this minor fixup for your platform/x86 -next tree.
Documentation/admin-guide/laptops/thinkpad-acpi.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst
b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
index b1188f05a99a..0e4c5bb7fb70 100644
--- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst
+++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
@@ -1469,7 +1469,7 @@ Sysfs notes
Setting keyboard language
+-
sysfs: keyboard_lang
--
2.17.1
Re: [PATCH v4] power: suspend: Move dpm_watchdog to suspend.c and enhance it
> diff --git a/MAINTAINERS b/MAINTAINERS > index 867157311dc8..ecd988b4a838 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7788,6 +7788,8 @@ F:include/linux/freezer.h > F: include/linux/pm.h > F: include/linux/suspend.h > F: kernel/power/ > +F: kernel/power/suspend_watchdog.c > +F: kernel/power/suspend_watchdog.h > The kernel/power/ file entry already covers all files in that directory, including suspend_watchdog.[ch]. So, why do you think you need to add these two further entries explicitly here? > HID CORE LAYER > M: Jiri Kosina > @@ -16630,6 +16632,8 @@ F: include/linux/freezer.h > F: include/linux/pm.h > F: include/linux/suspend.h > F: kernel/power/ > +F: kernel/power/suspend_watchdog.c > +F: kernel/power/suspend_watchdog.h > Same here. I think you can simply drop the changes in MAINTAINERS in this patch. Lukas
Re: [PATCH] MAINTAINERS/.mailmap: Use my @kernel.org address
On Tue, Jan 26, 2021 at 10:27 PM Nathan Chancellor wrote: > > Use my @kernel.org for all points of contact so that I am always > accessible. > > Signed-off-by: Nathan Chancellor Congrats, Nathan. You deserve it for all the warning fixes, reports, maintenance, CI, reviews and much more stuff you are doing. Lukas
[PATCH] kgdb: rectify kernel-doc for kgdb_unregister_io_module()
The command 'find ./kernel/debug/ | xargs ./scripts/kernel-doc -none' reported a typo in the kernel-doc of kgdb_unregister_io_module(). Rectify the kernel-doc, such that no issues remain for ./kernel/debug/. Signed-off-by: Lukas Bulwahn --- applies cleanly on v5.11-rc5 and next-20210122 Jason, Daniel, please pick this minor typo fixup. kernel/debug/debug_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c index af6e8b4fb359..7f22c1c0ffe8 100644 --- a/kernel/debug/debug_core.c +++ b/kernel/debug/debug_core.c @@ -1166,7 +1166,7 @@ int kgdb_register_io_module(struct kgdb_io *new_dbg_io_ops) EXPORT_SYMBOL_GPL(kgdb_register_io_module); /** - * kkgdb_unregister_io_module - unregister KGDB IO module + * kgdb_unregister_io_module - unregister KGDB IO module * @old_dbg_io_ops: the io ops vector * * Unregister it with the KGDB core. -- 2.17.1
[PATCH] printk: rectify kernel-doc for prb_rec_init_wr()
The command 'find ./kernel/printk/ | xargs ./scripts/kernel-doc -none' reported a mismatch with the kernel-doc of prb_rec_init_wr(). Rectify the kernel-doc, such that no issues remain for ./kernel/printk/. Signed-off-by: Lukas Bulwahn --- applies cleanly on v5.11-rc5 and next-20210122 John, please ack. Petr, please pick this minor typo fixup. kernel/printk/printk_ringbuffer.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/printk/printk_ringbuffer.h b/kernel/printk/printk_ringbuffer.h index 5dc9d022db07..73cc80e01cef 100644 --- a/kernel/printk/printk_ringbuffer.h +++ b/kernel/printk/printk_ringbuffer.h @@ -287,7 +287,7 @@ _DEFINE_PRINTKRB(name, descbits, avgtextbits, &_##name##_text[0]) /* Writer Interface */ /** - * prb_rec_init_wd() - Initialize a buffer for writing records. + * prb_rec_init_wr() - Initialize a buffer for writing records. * * @r: The record to initialize. * @text_buf_size: The needed text buffer size. -- 2.17.1
[PATCH] watch_queue: rectify kernel-doc for init_watch()
The command './scripts/kernel-doc -none kernel/watch_queue.c' reported a mismatch in the kernel-doc of init_watch(). Rectify the kernel-doc, such that no issues remain for watch_queue.c. Signed-off-by: Lukas Bulwahn --- applies cleanly on v5.11-rc5 and next-20210122 David, please pick this minor kernel-doc fixup. kernel/watch_queue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/watch_queue.c b/kernel/watch_queue.c index 0ef8f65bd2d7..9c9eb20dd2c5 100644 --- a/kernel/watch_queue.c +++ b/kernel/watch_queue.c @@ -413,7 +413,7 @@ static void put_watch(struct watch *watch) } /** - * init_watch_queue - Initialise a watch + * init_watch - Initialise a watch * @watch: The watch to initialise. * @wqueue: The queue to assign. * -- 2.17.1
[PATCH] rcu-tasks: rectify kernel-doc for struct rcu_tasks
The command 'find ./kernel/rcu/ | xargs ./scripts/kernel-doc -none' reported an issue with the kernel-doc of struct rcu_tasks. Rectify the kernel-doc, such that no issues remain for ./kernel/rcu/. Signed-off-by: Lukas Bulwahn --- applies cleanly on v5.11-rc5 and next-20210122 Paul, please pick this minor kerneldoc cleanup. kernel/rcu/tasks.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index af7c19439f4e..17c8ebe131af 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -20,7 +20,7 @@ typedef void (*holdouts_func_t)(struct list_head *hop, bool ndrpt, bool *frptp); typedef void (*postgp_func_t)(struct rcu_tasks *rtp); /** - * Definition for a Tasks-RCU-like mechanism. + * struct rcu_tasks - Definition for a Tasks-RCU-like mechanism. * @cbs_head: Head of callback list. * @cbs_tail: Tail pointer for callback list. * @cbs_wq: Wait queue allowning new callback to get kthread's attention. @@ -38,7 +38,7 @@ typedef void (*postgp_func_t)(struct rcu_tasks *rtp); * @pregp_func: This flavor's pre-grace-period function (optional). * @pertask_func: This flavor's per-task scan function (optional). * @postscan_func: This flavor's post-task scan function (optional). - * @holdout_func: This flavor's holdout-list scan function (optional). + * @holdouts_func: This flavor's holdout-list scan function (optional). * @postgp_func: This flavor's post-grace-period function (optional). * @call_func: This flavor's call_rcu()-equivalent function. * @name: This flavor's textual name. -- 2.17.1
[PATCH for device-mapper/for-next] dm integrity: follow ReST formatting
Commit 61b8b2a834bf ("dm integrity: introduce the "fix_hmac" argument")
adds some new part to dm-integrity.rst, but this causes make htmldocs warn:
dm-integrity.rst:192: WARNING: Unexpected indentation.
dm-integrity.rst:193: WARNING: Block quote ends without a blank line; \
unexpected unindent.
Make dm-integrity.rst follow ReST formatting.
Signed-off-by: Lukas Bulwahn
---
Mike, please pick this quick documentation fix in your for-next branch.
Documentation/admin-guide/device-mapper/dm-integrity.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst
b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 39a9fdc9f6ab..ef762857da95 100644
--- a/Documentation/admin-guide/device-mapper/dm-integrity.rst
+++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst
@@ -188,6 +188,7 @@ fix_padding
fix_hmac
Improve security of internal_hash and journal_mac:
+
- the section number is mixed to the mac, so that an attacker can't
copy sectors from one journal section to another journal section
- the superblock is protected by journal_mac
--
2.17.1
Small student project idea on appropriate integration trees in MAINTAINERS
Dear all, here is a small student project idea: In previous work on MAINTAINERS and process conformance, Pia Eichinger [1] has investigated: are patches integrated by the maintainers defined by the responsibilities in MAINTAINERS? In this project, we are interested in a related (possibly simpler) question: Are the commits integrated into the appropriate integration trees referenced in MAINTAINERS? As I believe, a main difference between considering maintainers and integration trees is that the information in MAINTAINERS about integration trees is more erroneous, as it is not used as prominently as the personal maintainer information, name and email, with the wide-spread use of ./scripts/get_maintainer.pl. So, correcting those errors on integration trees in MAINTAINERS is more dominant (but also simpler) compared to correcting errors on personal maintainer information in MAINTAINERS. The answer on the question above can then ultimately be used to identify which integration tree entries should be added to specific sections in MAINTAINERS to match best against the actual integration observed in git. The factors and metric to determine what is best is of course the challenging task of identifying a suitable heuristics that is: 1. good enough to be used to create a change to MAINTAINERS that is accepted by the community, and 2. simple enough to be implemented with reasonable effort. Background: The MAINTAINERS section includes references, through the T: entries, to the location of a source configuration management (SCM) tree with its type, e.g., git, quilt, hg, For each commit, the kernel git history carries the commit's integration tree path, i.e., the information through with source configuration management (SCM) trees a commit was integrated until it was finally integrated into Linus Torvalds' tree. Ideally the references in the MAINTAINERS sections are: - complete, i.e, all integration trees used for recent kernel releases are mentioned in MAINTAINERS. - sound, i.e., the majority of the commits are integrated through the trees referenced in the MAINTAINERS sections a patch belongs to. - precise, i.e., for each MAINTAINERS section, the majority of the commits that belong to a section are integrated through the tree referenced in that section. Goal: We identify and measure to these properties above, completeness, soundness and precision. Then, we use that information to determine which integration tree entries should be added to which specific sections to maximally increase the three properties. To evaluate the adequacy of this method, we can obtain feedback from the responsible kernel maintainers through proposing patches modifying the MAINTAINERS file, for the additions that we identified as most relevant (maximally increasing the properties, to a reasonable threshold of number of patch proposals [to not swamp maintainers initially] and a threshold on relevance [to not send out minor changes that are largely irrelevant to the community]). In this project, we can make use of: - gitdm [git://git.lwn.net/gitdm.git]: gitdm includes some scripts to parse MAINTAINERS and obtain the integration tree patch of a commit. and/or - pasta [https://github.com/lfd/PaStA]: Similarly to gitdm, pasta provides functionality to parse MAINTAINERS and some functionalities on extracting information on commits. Potential project phases: - In the first phase (PoC phase), we could probably just create a setup that combines or extends the functionality in gitdm and/or in pasta. - In the second phase (MAINTAINERS patch creation phase), we send out some patches and collect feedback from maintainers. - In a third phase, with a better understanding of the individual pieces in gitdm and/or in pasta, we could then create a cleaner design that also refactors gitdm and pasta to share the same implementation when essentially the same basic functionality is used within the various analyses. References: [1] https://lists.elisa.tech/g/devel/message/1269 --- Any thoughts on this small student project? If it is not too crazy, I will mentor a student on this project through one of the next mentoring programs (Google Summer of Code, LF mentorship, etc.). Lukas
Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors
On Fri, Jan 22, 2021 at 6:47 AM 慕冬亮 wrote: > > On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn wrote: > > > > On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 wrote: > > > > > > Dear kernel developers, > > > > > > I found that on the syzbot dashboard, “possible deadlock in > > > console_lock_spinning_enable”[1] and "possible deadlock in > > > console_unlock"[2] should share the same root cause. > > > > > > The reasons for the above statement: > > > 1) the stack trace is the same, and this title difference is due to > > > the inline property of "console_lock_spinning_enable"; > > > 2) their PoCs are the same as each other; > > > > > > If you can have any issues with this statement or our information is > > > useful to you, please let us know. Thanks very much. > > > > > > [1] “possible deadlock in console_lock_spinning_enable” - > > > https://syzkaller.appspot.com/bug?id=2820deb61d92a8d7ab17a56ced58e963e65d76d0 > > > [2] “possible deadlock in console_unlock” - > > > https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a > > > > > > > > > > Dongliang, what is the purpose of this activity? > > Lukas, > > We are conducting some research on the crash deduplication (or > identifying unique bugs) of kernel crash reports. We would like to > share some results from our research to facilitate the bugfix in the > syzbot dashboard. > > > > > Why do inform the kernel maintainers that two issues share the root cause? > > > > How does this activity contribute to fixing the bugs? Why does it > > become easier to fix the issue/create a patch with the information you > > provide? > > I do this for three reasons: > > (1) I think the reports sharing the same root cause may expedite the > patching processing and help generate more complete patches. After > patching bugs in one case, we can close the other cases quicker. > Without these reports, one developer might be misled to develop an > incomplete patch due to a lack of understanding of the underlying bug > [1]. > (2) I think it might help maintainers to better assess the severity of > the bug and thus could prioritize their effort. > (3) Multiple reports might better help maintainers diagnose the bug's > root cause. > > [1] https://groups.google.com/g/syzkaller-bugs/c/9u_hEFvNbLw/m/CO9bfF8zCQAJ > > > (Honestly, I do not see how it does. I believe if anyone becomes > > active and fixes the issue due to either one of the two reports, the > > one report would be closed by the reported-by tag and the other report > > would simply disappear after time because it could never be reproduced > > and hence, syzbot would close it.) > > > > Would it not be more reasonable to fix issues rather than identifying > > duplicates in the automatically filled and managed database? > > Yes, fixing issues or bugs is the ultimate goal. However, crash > deduplication does benefit the bugfix process, and can reduce the > heavy burden on the kernel developers. To make our analysis more > useful, we will try our best to add some root cause analysis and how > to fix the underlying bug. > Well, I am not really convinced, but I guess you will convince me when (thanks to your feature) all bugs reported by syzbot are quickly fixed and quickly closed. good luck :) Lukas
Re: [PATCH] MAINTAINERS: adjust to clang-version.sh removal
On Thu, Jan 21, 2021 at 5:16 PM Nathan Chancellor
wrote:
>
> On Thu, Jan 21, 2021 at 05:01:15PM +0100, Lukas Bulwahn wrote:
> > Commit 6c8ad4427f6e ("kbuild: check the minimum compiler version in
> > Kconfig") removed ./scripts/clang-version.sh and moved its content to
> > ./scripts/cc-version.sh.
> >
> > Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
> >
> > warning: no file matchesF:scripts/clang-version.sh
> >
> > The CLANG/LLVM BUILD SUPPORT section in MAINTAINERS intends to track
> > changes in ./scripts/clang-version.sh; as the file is removed, track
> > changes in ./scripts/cc-version.sh instead now.
> >
> > Signed-off-by: Lukas Bulwahn
> > ---
> > applies cleanly on next-20210121
> >
> > Masahiro-san, please pick this quick fix-up patch.
>
> Masahiro cannot pick this up because the patch to add clang-version.sh
> to MAINTAINERS is in mmotm.
>
> I think the better solution is for Andrew to drop the current version of
>
> maintainers-add-a-couple-more-files-to-the-clang-llvm-section.patch
>
> and pick up the second one I sent, which allows us to deal with this:
>
> https://lore.kernel.org/lkml/20210114171629.592007-1-natechancel...@gmail.com/
>
> I am not sure it is right for us to maintain cc-version.sh but I am open
> to it if Masahiro agrees.
>
Okay, I did not see in linux-next that both changes are coming into
linux-next through to different trees.
Nathan, I guess if you send a follow-up patch to Andrew that is the
best way to handle it, or we wait until both trees land in mainline,
and then just provide a quick fix like this afterwards.
So, Masahiro-san, no need to pick this patch here.
Lukas
Re: [PATCH] MAINTAINERS: adjust to clang-version.sh removal
On Thu, Jan 21, 2021 at 5:16 PM Sedat Dilek wrote:
>
> On Thu, Jan 21, 2021 at 5:01 PM Lukas Bulwahn wrote:
> >
> > Commit 6c8ad4427f6e ("kbuild: check the minimum compiler version in
> > Kconfig") removed ./scripts/clang-version.sh and moved its content to
> > ./scripts/cc-version.sh.
> >
> > Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
> >
> > warning: no file matchesF:scripts/clang-version.sh
> >
> > The CLANG/LLVM BUILD SUPPORT section in MAINTAINERS intends to track
> > changes in ./scripts/clang-version.sh; as the file is removed, track
> > changes in ./scripts/cc-version.sh instead now.
> >
> > Signed-off-by: Lukas Bulwahn
>
> Good catch, Lukas.
>
> As a tipp:
> Next time you can pass '--subject-prefix="PATCH next-MMDD"' when
> doing 'git format-patch ...' (or whatever you use to generate the
> patch).
>
Thanks for the hint.
> Cannot say if we can add a "Fixes:" tag with commit hash-id of
> "kbuild: check the minimum compiler version in Kconfig" - this missed
> that move.
> Maybe Masahiro does a respin and can fold this into above commit?
> That's not my decision.
>
> Reviewed-by: Sedat Dilek
>
...and thanks for the review.
Lukas
[PATCH] MAINTAINERS: adjust to clang-version.sh removal
Commit 6c8ad4427f6e ("kbuild: check the minimum compiler version in
Kconfig") removed ./scripts/clang-version.sh and moved its content to
./scripts/cc-version.sh.
Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matchesF:scripts/clang-version.sh
The CLANG/LLVM BUILD SUPPORT section in MAINTAINERS intends to track
changes in ./scripts/clang-version.sh; as the file is removed, track
changes in ./scripts/cc-version.sh instead now.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210121
Masahiro-san, please pick this quick fix-up patch.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e5d7cf38ec82..aafbea806a82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4355,8 +4355,8 @@ B:https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: include/linux/compiler-clang.h
+F: scripts/cc-version.sh
F: scripts/clang-tools/
-F: scripts/clang-version.sh
F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
--
2.17.1
Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors
On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 wrote: > > Dear kernel developers, > > I found that on the syzbot dashboard, “possible deadlock in > console_lock_spinning_enable”[1] and "possible deadlock in > console_unlock"[2] should share the same root cause. > > The reasons for the above statement: > 1) the stack trace is the same, and this title difference is due to > the inline property of "console_lock_spinning_enable"; > 2) their PoCs are the same as each other; > > If you can have any issues with this statement or our information is > useful to you, please let us know. Thanks very much. > > [1] “possible deadlock in console_lock_spinning_enable” - > https://syzkaller.appspot.com/bug?id=2820deb61d92a8d7ab17a56ced58e963e65d76d0 > [2] “possible deadlock in console_unlock” - > https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a > > Dongliang, what is the purpose of this activity? Why do inform the kernel maintainers that two issues share the root cause? How does this activity contribute to fixing the bugs? Why does it become easier to fix the issue/create a patch with the information you provide? (Honestly, I do not see how it does. I believe if anyone becomes active and fixes the issue due to either one of the two reports, the one report would be closed by the reported-by tag and the other report would simply disappear after time because it could never be reproduced and hence, syzbot would close it.) Would it not be more reasonable to fix issues rather than identifying duplicates in the automatically filled and managed database? Best regards, Lukas
Re: [PATCH bpf-next v3 2/2] docs: bpf: Clarify -mcpu=v3 requirement for atomic ops
On Wed, Jan 20, 2021 at 2:39 PM Brendan Jackman wrote: > > Alexei pointed out [1] that this wording is pretty confusing. Here's > an attempt to be more explicit and clear. > > [1] > https://lore.kernel.org/bpf/CAADnVQJVvwoZsE1K+6qRxzF7+6CvZNzygnoBW9tZNWJELk5c=q...@mail.gmail.com/T/#m07264fc18fdc43af02fc1320968afefcc73d96f4 > It is common practice to use "Link: URL" to refer to other mail threads; and to use the "permalink": https://lore.kernel.org/bpf/CAADnVQJVvwoZsE1K+6qRxzF7+6CvZNzygnoBW9tZNWJELk5c=q...@mail.gmail.com/ which is a bit shorter than the link you provided. If you follow that convention with "Link: URL", checkpatch.pl will not complain about this long line :) Lukas > Signed-off-by: Brendan Jackman > --- > Documentation/networking/filter.rst | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/networking/filter.rst > b/Documentation/networking/filter.rst > index 4c2bb4c6364d..b3f457802836 100644 > --- a/Documentation/networking/filter.rst > +++ b/Documentation/networking/filter.rst > @@ -1081,9 +1081,10 @@ before is loaded back to ``R0``. > > Note that 1 and 2 byte atomic operations are not supported. > > -Except ``BPF_ADD`` *without* ``BPF_FETCH`` (for legacy reasons), all 4 byte > -atomic operations require alu32 mode. Clang enables this mode by default in > -architecture v3 (``-mcpu=v3``). For older versions it can be enabled with > +Clang can generate atomic instructions by default when ``-mcpu=v3`` is > +enabled. If a lower version for ``-mcpu`` is set, the only atomic instruction > +Clang can generate is ``BPF_ADD`` *without* ``BPF_FETCH``. If you need to > enable > +the atomics features, while keeping a lower ``-mcpu`` version, you can use > ``-Xclang -target-feature -Xclang +alu32``. > > You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, > -- > 2.30.0.284.gd98b1dd5eaa7-goog >
[PATCH] arch/Kconfig: update a broken file reference
Commit adab66b71abf ("Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"")
added the config HAVE_64BIT_ALIGNED_ACCESS back into arch/Kconfig with this
revert. In the meantime, commit c9b54d6f362c ("docs: move other kAPI
documents to core-api") changed ./Documentation/unaligned-memory-access.txt
to ./Documentation/core-api/unaligned-memory-access.rst.
Fortunately, ./scripts/documentation-file-ref-check detects this and warns
about this broken reference.
Update the file reference in arch/Kconfig.
Fixes: adab66b71abf ("Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"")
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20210118
Steven, could you pick this fix to your commit or, at least, ack it so that
Jonathan can pick it?
arch/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 24862d15f3a3..dc104b8270c0 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -156,8 +156,8 @@ config HAVE_64BIT_ALIGNED_ACCESS
accesses are required to be 64 bit aligned in this way even
though it is not a 64 bit architecture.
- See Documentation/unaligned-memory-access.txt for more
- information on the topic of unaligned memory accesses.
+ See Documentation/core-api/unaligned-memory-access.rst for
+ more information on the topic of unaligned memory accesses.
config HAVE_EFFICIENT_UNALIGNED_ACCESS
bool
--
2.17.1
Re: [PATCH bpf-next v2 1/2] docs: bpf: Fixup atomics markup
On Mon, Jan 18, 2021 at 4:59 PM Brendan Jackman wrote: > > This fixues up the markup to fix a warning, be more consistent with s/fixues/fixes/ ? > use of monospace, and use the correct .rst syntax for (* instead > of _). > > NB this conflicts with Lukas' patch at [1], which just fixes the > warning. The scope of this one is a little broader. > > [1] > https://lore.kernel.org/bpf/CA+i-1C3cEXqxcXfD4sibQfx+dtmmzvOzruhk8J5pAw3g5v=k...@mail.gmail.com/T/#t > As I wrote in my patch, I did minimal changes. Your bit more extensive changes make sense. I suggest dropping this comment above starting from NB and the link; it is not relevant for the history. You can of course move it below the "---"; so it is not picked up into the git history. Other than that: Reviewed-by: Lukas Bulwahn > Signed-off-by: Brendan Jackman > --- > Documentation/networking/filter.rst | 19 ++- > 1 file changed, 10 insertions(+), 9 deletions(-) > > diff --git a/Documentation/networking/filter.rst > b/Documentation/networking/filter.rst > index f6d8f90e9a56..4c2bb4c6364d 100644 > --- a/Documentation/networking/filter.rst > +++ b/Documentation/networking/filter.rst > @@ -1048,12 +1048,12 @@ Unlike classic BPF instruction set, eBPF has generic > load/store operations:: > Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. > > It also includes atomic operations, which use the immediate field for extra > -encoding. > +encoding:: > > .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32 > *)(dst_reg + off16) += src_reg > .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 > *)(dst_reg + off16) += src_reg > > -The basic atomic operations supported are: > +The basic atomic operations supported are:: > > BPF_ADD > BPF_AND > @@ -1066,12 +1066,12 @@ memory location addresed by ``dst_reg + off`` is > atomically modified, with > immediate, then these operations also overwrite ``src_reg`` with the > value that was in memory before it was modified. > > -The more special operations are: > +The more special operations are:: > > BPF_XCHG > > This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg + > -off``. > +off``. :: > > BPF_CMPXCHG > > @@ -1081,18 +1081,19 @@ before is loaded back to ``R0``. > > Note that 1 and 2 byte atomic operations are not supported. > > -Except ``BPF_ADD`` _without_ ``BPF_FETCH`` (for legacy reasons), all 4 byte > +Except ``BPF_ADD`` *without* ``BPF_FETCH`` (for legacy reasons), all 4 byte > atomic operations require alu32 mode. Clang enables this mode by default in > architecture v3 (``-mcpu=v3``). For older versions it can be enabled with > ``-Xclang -target-feature -Xclang +alu32``. > > -You may encounter BPF_XADD - this is a legacy name for BPF_ATOMIC, referring > to > -the exclusive-add operation encoded when the immediate field is zero. > +You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, > +referring to the exclusive-add operation encoded when the immediate field is > +zero. > > -eBPF has one 16-byte instruction: BPF_LD | BPF_DW | BPF_IMM which consists > +eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which > consists > of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as > single > instruction that loads 64-bit immediate value into a dst_reg. > -Classic BPF has similar instruction: BPF_LD | BPF_W | BPF_IMM which loads > +Classic BPF has similar instruction: ``BPF_LD | BPF_W | BPF_IMM`` which loads > 32-bit immediate value into a register. > > eBPF verifier > -- > 2.30.0.284.gd98b1dd5eaa7-goog >
[PATCH for bpf-next] docs: bpf: add minimal markup to address doc warning
Commit 91c960b00566 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") modified the BPF documentation, but missed some ReST
markup.
Hence, make htmldocs warns on Documentation/networking/filter.rst:1053:
WARNING: Inline emphasis start-string without end-string.
Add some minimal markup to address this warning.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210118
Brendan, please ack.
Alexei, please pick this minor cleanup patch on your bpf-next.
Documentation/networking/filter.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/filter.rst
b/Documentation/networking/filter.rst
index f6d8f90e9a56..45f6fde1776c 100644
--- a/Documentation/networking/filter.rst
+++ b/Documentation/networking/filter.rst
@@ -1048,12 +1048,12 @@ Unlike classic BPF instruction set, eBPF has generic
load/store operations::
Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW.
It also includes atomic operations, which use the immediate field for extra
-encoding.
+encoding::
.imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32
*)(dst_reg + off16) += src_reg
.imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64
*)(dst_reg + off16) += src_reg
-The basic atomic operations supported are:
+The basic atomic operations supported are::
BPF_ADD
BPF_AND
--
2.17.1
Re: [PATCH 00/10] Fix documentation warnings at linux-next
On Fri, Jan 15, 2021 at 10:49 AM Mauro Carvalho Chehab wrote: > > Hi Lukas, > > Em Fri, 15 Jan 2021 07:12:38 +0100 > Lukas Bulwahn escreveu: > > > [reduced the recipient list to the main responsible ones and list] > > > > Hi Mauro, hi Jonathan, > > > > We both, Mauro and I, have been submitting patches to address the > > documentation warnings on linux-next. If it is okay with you, Mauro, I > > would like to take responsibility for the task to send out the patches > > to address all warnings on linux-next in make htmldocs and follow up > > with all the discussions. I can also provide a short weekly summary > > (probably always on Friday) on what is pending where and what I could > > not resolve by myself. > > > > Is that okay for you? > > > > If at some point I do not have the time to take care anymore, I will > > let you know. > > Yeah, sure! > > Anyway, after applying the patches I sent this week, the warnings > I'm getting are all due to the validation scripts I wrote. So, if > everything gets merged (either yours or my version), we'll have zero > Sphinx/kernel-doc warnings again. > It is a never ending story... I already have seen two new warnings on today's linux-next and sent out patches. > $ scripts/documentation-file-ref-check > $ scripts/get_abi.pl validate I will also try out those two scripts, but I cannot commit to follow-up on all of those yet. I am also looking into addressing all kerneldoc warnings, even if not pulled in by make htmldocs. Lukas
[PATCH] fs: anon_inodes: rephrase to appropriate kernel-doc
Commit e7e832ce6fa7 ("fs: add LSM-supporting anon-inode interface") adds
more kerneldoc description, but also a few new warnings on
anon_inode_getfd_secure() due to missing parameter descriptions.
Rephrase to appropriate kernel-doc for anon_inode_getfd_secure().
Signed-off-by: Lukas Bulwahn
---
fs/anon_inodes.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 023337d65a03..a280156138ed 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -202,13 +202,20 @@ int anon_inode_getfd(const char *name, const struct
file_operations *fops,
EXPORT_SYMBOL_GPL(anon_inode_getfd);
/**
- * Like anon_inode_getfd(), but creates a new !S_PRIVATE anon inode rather than
- * reuse the singleton anon inode, and calls the inode_init_security_anon() LSM
- * hook. This allows the inode to have its own security context and for a LSM
- * to reject creation of the inode. An optional @context_inode argument is
- * also added to provide the logical relationship with the new inode. The LSM
- * may use @context_inode in inode_init_security_anon(), but a reference to it
- * is not held.
+ * anon_inode_getfd_secure - Like anon_inode_getfd(), but creates a new
+ * !S_PRIVATE anon inode rather than reuse the singleton anon inode, and calls
+ * the inode_init_security_anon() LSM hook. This allows the inode to have its
+ * own security context and for a LSM to reject creation of the inode.
+ *
+ * @name:[in]name of the "class" of the new file
+ * @fops:[in]file operations for the new file
+ * @priv:[in]private data for the new file (will be file's
private_data)
+ * @flags: [in]flags
+ * @context_inode:
+ * [in]the logical relationship with the new inode (optional)
+ *
+ * The LSM may use @context_inode in inode_init_security_anon(), but a
+ * reference to it is not held.
*/
int anon_inode_getfd_secure(const char *name, const struct file_operations
*fops,
void *priv, int flags,
--
2.17.1
[PATCH] drm/dp_helper: tweak kerneldoc to address warning
Commit 07c9b8634fb6 ("drm/dp_helper: Add helpers to configure PCONs
RGB-YCbCr Conversion") introduces a warning with make htmldocs in
./drivers/gpu/drm/drm_dp_helper.c:965 for
drm_dp_downstream_rgb_to_ycbcr_conversion():
warning: Excess function parameter 'colorspc' description
warning: Function parameter or member 'color_spc' not described
Tweak the kerneldoc for drm_dp_downstream_rgb_to_ycbcr_conversion().
Fixes: 07c9b8634fb6 ("drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr
Conversion")
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210115
Jani, please pick this minor doc warning fixup.
drivers/gpu/drm/drm_dp_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..d60e94ac6fdd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -954,7 +954,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
* RGB->YCbCr conversion
capability
* @dpcd: DisplayPort configuration data
* @port_cap: downstream facing port capabilities
- * @colorspc: Colorspace for which conversion cap is sought
+ * @color_spc: Colorspace for which conversion cap is sought
*
* Returns: whether the downstream facing port can convert RGB->YCbCr for a
given
* colorspace.
@@ -3134,7 +3134,7 @@ int drm_dp_pcon_pps_override_param(struct drm_dp_aux
*aux, u8 pps_param[6])
}
EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
-/*
+/**
* drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert RGB to
Ycbcr
* @aux: displayPort AUX channel
* @color_spc: Color-space/s for which conversion is to be enabled, 0 for
disable.
--
2.17.1
Related work to MAINTAINERS truth and fiction
Hi Jonathan, thanks for your interesting article, MAINTAINERS truth and fiction, https://lwn.net/Articles/842415/. Just some pointers to related work: Pia Eichinger has done some related analysis and work in this area as part of her bachelor's thesis on Maintainers Expectations vs. Maintainers Reality: An Analysis of Organisational and Maintenance Structure of the Linux Kernel. Simply quoting her conclusion: "We showed that around 20% of all patches were theoretically wrongly integrated when strictly analysing MAINTAINERS. The reality of integration and maintenance structure is more complicated than that, which we also explored. Furthermore, we identified 12 major subsystems of the Linux kernel. This is very helpful for an overview of the organisational structure, realistic grouping of subsystems and further Linux kernel topology discussions." Announcement and thesis here: https://lists.elisa.tech/g/devel/message/1269 https://drive.google.com/file/d/12ta2YxgEzEfrIcmWid8kwIyVEywbUjbA/view?usp=sharing As you might have noticed as well, ./scripts/get_maintainer.pl --self-test provides a few checks and warnings on the MAINTAINERS file. For a few months by now, I have been following up on new warnings appearing with ./scripts/get_maintainer.pl --self-test=patterns, excluding Documentation/devicetree/bindings/, as Mauro takes care of those often before my patches usually get accepted. In the past, I also did an analysis of what is only in THE REST, see some discussion here: https://lore.kernel.org/lkml/alpine.DEB.2.21.2003090702440.3325@felia/ After a few manual clean-up attempts for files in include, I concluded that this activity needs to be at least semi-automatically done with some scripted heuristics and then sanity-checked by experts. I have not made any progress beyond that, though; it is certainly a good task for an interested student or mentee. Thanks again for your interesting article. Best regards, Lukas
Re: [PATCH 00/10] Fix documentation warnings at linux-next
[reduced the recipient list to the main responsible ones and list] Hi Mauro, hi Jonathan, We both, Mauro and I, have been submitting patches to address the documentation warnings on linux-next. If it is okay with you, Mauro, I would like to take responsibility for the task to send out the patches to address all warnings on linux-next in make htmldocs and follow up with all the discussions. I can also provide a short weekly summary (probably always on Friday) on what is pending where and what I could not resolve by myself. Is that okay for you? If at some point I do not have the time to take care anymore, I will let you know. Best regards, Lukas
[PATCH for doc-next] doc/zh_CN: mips: use doc references instead
The Chinese mips translations refer to non-existing labels in the original documentation. Hence, make htmldocs warns about those undefined labels on all files in ./Documentation/translations/zh_CN/mips/. Replace the references to non-existing labels with suitable doc references. Signed-off-by: Lukas Bulwahn --- applies cleanly on next-20210113 Yanteng, please ack. Jonathan, please pick this doc warning fixup on your -next tree. Documentation/translations/zh_CN/mips/booting.rst | 2 +- Documentation/translations/zh_CN/mips/features.rst| 2 +- Documentation/translations/zh_CN/mips/index.rst | 2 +- Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/translations/zh_CN/mips/booting.rst b/Documentation/translations/zh_CN/mips/booting.rst index 3099d0fff7a6..96453e1b962e 100644 --- a/Documentation/translations/zh_CN/mips/booting.rst +++ b/Documentation/translations/zh_CN/mips/booting.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/booting.rst ` +:Original: :doc:`../../../mips/booting` :Translator: Yanteng Si .. _cn_booting: diff --git a/Documentation/translations/zh_CN/mips/features.rst b/Documentation/translations/zh_CN/mips/features.rst index 7e67f81a0982..93d93d06b1b3 100644 --- a/Documentation/translations/zh_CN/mips/features.rst +++ b/Documentation/translations/zh_CN/mips/features.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/features.rst ` +:Original: :doc:`../../../mips/features` :Translator: Yanteng Si .. _cn_features: diff --git a/Documentation/translations/zh_CN/mips/index.rst b/Documentation/translations/zh_CN/mips/index.rst index 2c7b836a3da5..27a2eae8484a 100644 --- a/Documentation/translations/zh_CN/mips/index.rst +++ b/Documentation/translations/zh_CN/mips/index.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/index.rst ` +:Original: :doc:`../../../mips/index` :Translator: Yanteng Si .. _cn_index: diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst index 9324a0a26430..f04ba407384a 100644 --- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst +++ b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/ingenic-tcu.rst ` +:Original: :doc:`../../../mips/ingenic-tcu` :Translator: Yanteng Si .. _cn_ingenic-tcu: -- 2.17.1
[PATCH for doc-next] doc/zh_CN: adjust table markup in mips/ingenic-tcu.rst
Commit 419b1d4ed1cb ("doc/zh_CN: add mips ingenic-tcu.rst translation")
introduces a warning with make htmldocs:
./Documentation/translations/zh_CN/mips/ingenic-tcu.rst:
61: WARNING: Malformed table. Text in column margin in table line 6.
Adjust the table markup to address this warning.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210113
Yanteng, please ack.
Jonathan, please pick this doc warning fixup on your -next tree.
Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
index 72b5d409ed89..9324a0a26430 100644
--- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
+++ b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
@@ -53,14 +53,14 @@
TCU硬件的功能分布在多个驱动程序：
-=== =
+== ===
时钟drivers/clk/ingenic/tcu.c
中断drivers/irqchip/irq-ingenic-tcu.c
定时器 drivers/clocksource/ingenic-timer.c
OST drivers/clocksource/ingenic-ost.c
脉冲宽度调制器 drivers/pwm/pwm-jz4740.c
看门狗 drivers/watchdog/jz4740_wdt.c
-=== =
+== ===
因为可以从相同的寄存器控制属于不同驱动程序和框架的TCU的各种功能，所以
所有这些驱动程序都通过相同的控制总线通用接口访问它们的寄存器。
--
2.17.1
[PATCH -next] f2fs: docs: rectify the table header in sysfs-fs-f2fs
Commit 969945899a35 ("f2fs: introduce sb_status sysfs node") documents the
sb_status values in a table in ./Documentation/ABI/testing/sysfs-fs-f2fs,
but the table header of the first column has a wrong length.
Hence, make htmldocs warns:
Documentation/ABI/testing/sysfs-fs-f2fs:382: WARNING: Malformed table.
Rectify the table header.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210112
Documentation/ABI/testing/sysfs-fs-f2fs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index e5918c93f3bf..362803901614 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -383,7 +383,7 @@ Date: December 2020
Contact: "Chao Yu"
Description: Show status of f2fs superblock in real time.
- = = =
+ == = =
value sb status macro description
0x1SBI_IS_DIRTY dirty flag for checkpoint
0x2SBI_IS_CLOSE specify unmounting
--
2.17.1
Re: [PATCH -next] fpga: dfl-pci: rectify ReST formatting
On Mon, Jan 11, 2021 at 4:55 PM Moritz Fischer wrote:
>
> Hi Lukas,
>
> On Mon, Jan 11, 2021 at 12:21:13PM +0100, Lukas Bulwahn wrote:
> > Commit fa41d10589be ("fpga: dfl-pci: locate DFLs by PCIe vendor specific
> > capability") provides documentation to the FPGA Device Feature List (DFL)
> Nit: Do you want to make this a Fixes: tag instead?
IMHO, it is just adjusting the mark-up of the documentation and that
does not deserve a Fixes: tag.
Also, in the past, I got more frequent rejections when adding Fixes:
tags for such patches compared to proposals adding a Fixes: tag. So, I
settled for not adding Fixes: tags for such minor adjustment patches.
Lukas
> > Framework Overview, but introduced new documentation warnings:
> >
> > ./Documentation/fpga/dfl.rst:
> > 505: WARNING: Title underline too short.
> > 523: WARNING: Unexpected indentation.
> > 523: WARNING: Blank line required after table.
> > 524: WARNING: Block quote ends without a blank line; unexpected
> > unindent.
> >
> > Rectify ReST formatting in ./Documentation/fpga/dfl.rst.
> >
> > Signed-off-by: Lukas Bulwahn
> Acked-by: Moritz Fischer
> > ---
> > applies cleanly on next-20210111
> >
> > Moritz, Matthew, please ack.
> >
> > Greg, please pick this doc fixup to your fpga -next tree on top of
> > the commit above.
> >
> > Documentation/fpga/dfl.rst | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> > index ea8cefc18bdb..c41ac76ffaae 100644
> > --- a/Documentation/fpga/dfl.rst
> > +++ b/Documentation/fpga/dfl.rst
> > @@ -502,7 +502,7 @@ FME Partial Reconfiguration Sub Feature driver (see
> > drivers/fpga/dfl-fme-pr.c)
> > could be a reference.
> >
> > Location of DFLs on a PCI Device
> > -===
> > +
> > The original method for finding a DFL on a PCI device assumed the start of
> > the
> > first DFL to offset 0 of bar 0. If the first node of the DFL is an FME,
> > then further DFLs in the port(s) are specified in FME header registers.
> > @@ -514,6 +514,7 @@ data begins with a 4 byte vendor specific register for
> > the number of DFLs follow
> > Offset/BIR vendor specific registers for each DFL. Bits 2:0 of Offset/BIR
> > register
> > indicates the BAR, and bits 31:3 form the 8 byte aligned offset where bits
> > 2:0 are
> > zero.
> > +::
> >
> > ++
> > |31 Number of DFLS 0|
> > --
> > 2.17.1
> >
>
> Thanks for doing this, I was about to send that same patch myself.
>
> - Moritz
Re: [PATCH -next] fpga: dfl-pci: rectify ReST formatting
On Mon, Jan 11, 2021 at 4:52 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Jan 11, 2021 at 12:21:13PM +0100, Lukas Bulwahn wrote:
> > Commit fa41d10589be ("fpga: dfl-pci: locate DFLs by PCIe vendor specific
> > capability") provides documentation to the FPGA Device Feature List (DFL)
> > Framework Overview, but introduced new documentation warnings:
> >
> > ./Documentation/fpga/dfl.rst:
> > 505: WARNING: Title underline too short.
> > 523: WARNING: Unexpected indentation.
> > 523: WARNING: Blank line required after table.
> > 524: WARNING: Block quote ends without a blank line; unexpected
> > unindent.
> >
> > Rectify ReST formatting in ./Documentation/fpga/dfl.rst.
> >
> > Signed-off-by: Lukas Bulwahn
>
> You forgot a Reported-by: tag for the person who notified you of this :(
Greg, would you believe that I run 'make htmldocs' on linux-next myself?
Of course, Stephen Rothwell reports such documentation warnings as
well, but I take care independent of Stephen's reporting.
Lukas
